UxiflVar

ShofWar

SVar

1 I \ \ i I \ 1 \ 1 1 \ 1 Г

00000000

00000101

65.535 Л

-65.535 A

0000 0000 1111 1111 1000 0000 1111 1111 => 0000 0000 1111 1111 0000 0000 1111 1111

I . I . I . I I I . I I . I

I . I . I . I

fffi

ffef

ffed

(Teb

ffe9

ffe7

ffeS

ffe3

fff4 TO fHO ffee ffec ffea fte8

A/c. 18.2. Те же отношения наследования, но с учетом соглашений UML

ffe6

ffe4

в соответствии с соглашениями UML классы изображаются в виде прямоугольников, а наследование - в виде стрелки, направленной от производного класса к базовому, Направление стрелки противоречит тому, что подсказывает интуиция большинства из нас, но это не страшно: когда мы все договоримся, система заработает как надо.

Соглашения UML совсем несложные. Диаграммы нетрудно понимать и использовать. Мы рассмотрим эти соглашения на конкретных примерах в ходе освоения этой главы, что гораздо проше изучения UML вне контекста. Хотя этой теме можно посвятить целую книгу, по правде говоря, это будет пустая трата времени и бумаги, поскольку язык UML вполне соответствует принципу: лучше один раз увидеть на практике, чем десять раз прочитать.

Правильное выполнение анализа и проектирования объектно-ориентированной программы намного важнее, чем соблюдение соглашений языка моделирования. Именно этой тематики посвяшено большинство публикаций и конференций. И если по поводу языка моделирования удалось прийти к обшим соглашениям и выработать UML, то споры по поводу основополагаюших принципов анализа и проектирования программ продолжаются по сей день.

Появшшсь даже новая профессия - методологи: это профаммисты, которые изучают и разрабатывают методы профаммирования. Часто в литературе можно встретить статьи, посвященные описанию нового метода профаммирования. Метод - это совокупность языка моделирования и подходов анализа и проектирования. Три наиболее известных методолога в мире - это Грейди Буч (Grady Boocli), создавший метод Буча, Айвер Якобсон (Ivar Ja-cobson), разработавший подходы объектно-ориентированного профаммирования, и Джеймс Рпмбо (Jnmes Rumbniigli), создавший технологию объектного моделирования. Вместе они создали метод Ohjectoiy - коммерческий продукт от фирмы Rational Software, Inc. Это фирма, в которой они работают и где их любовно величают три амигос .

Материал, изложенный на этом занятии, приблизительно следует методам Objectory. Точного соответствия не будет, так как я не верю в рабское следование академической теории. Я считаю создание конкурентноспособпой профессиональной программы более важным, чем точное соответствие этой программы каким бы то ни было абстрактным методам, В конце концов па Objectory свет клином не сошелся, и я рекомендую вам быть эклектиками и выбирать все лучшее из всех методов, которые вам известны.

Процесс проектирования программ итеративен. Это значит, что при разработке программы мы периодически повторяем весь процесс, по мере того как растет понимание требований. Проект нацелен на решение задачи, но нюансы, возникающие в ходе поиска оптимального решения, воздействуют на сам проект. Невозможно разработать серьезный крупный проект идя по прямой от начала до конца. Вместо этого на отдельных этапах приходится возвращаться к началу, постоянно совершенствуя интерфейсы и процедуры выполнения отдельных объектов.

Итеративную разработку следует отличать от каскадной, при которой выход из одной стадии становится входом в следующую и назад дороги нет (рис. 18,3). Этот процесс напоминает конвейер сборки автомобилей, где на каждом этапе собирается и тестируется один узел, nocTctievnio формируя автомобиль. Но программа, в отличие от автомобиля, продукт штучный. Разработку программ редко удается поставить на конвейер.

При итеративном проектировании теоретик предлагает новую идею, а прикладник начинает творческую реа;п1зацию этой абстрактной идеи в программе. По мере того как начнут прорисовываться детали проекта, будут меняться наши представления о форме реализации исходной идеи. Работа над проектом начинается с формулирования требо-

49589

ваний к проекту, которые в ходе разработки могут менеться, что потребует внесения изменений в уже созданные профаммные блоки. Большой проект разбивается на отдельные блоки, для которых сначала создаются прототипы, а затем процедуры их вьшолне-ния. Тестирование выполнения отдельных модулей может привести к необходимости внесения изменений в их прототипы, а изменения отдельных блоков заставляют время от времени пересмафивать принципы их взаимодействия в целом проекте.

Рис. 18.3. Каскадный процесс проектирования

Хотя цикличность работы над проектом очевидна, описать эти процессы в виде какого-то стабильного цикла довольно сложно. Поэтому предлагаю вам лишь логическую последовательность действий: возникновение идеи, анализ и осмысление ее, проектирование, программирование, тестирование и возврашение к тому этапу, который можно модернизировать. Таким образом, итеративность разработки проекта не заставляет вас кружить по замкнутому циклу, а позволяет творчески подойти к решению задач и возвращаться всякий раз к тому этапу, где вы видите возможность повысить эффективность выполнения программы.

Еще раз повторим последовательность действий.

1. Разработка концепции.

2. Анализ.

3. Проектирование.

4. Реализация.

5. Тестирование.

6. Возвращение.

Разработка концепции - это вынашивание чистой идеи, к сожалению, далекой от реальной жизни. Анализ - это процесс осознания требований к проекту. Проектирование - процесс формирования модели классов, на основе которой будет создаваться код. Реализация - написание кода (например, на С++); тестирование - проверка того, все ли в порядке, и возвращение - это шлифовка вашего продукта до того состояния, когда его можно будет отдать заказчику. Осталось реализовать все это на практике.

Идея

Любая гениальная программа начинается с идеи. Некто думает о продукте, который, с его точки зрения, было бы хорошо создать. Реже сногшибательную идею вьщают комитеты. На самой первой стадии анализа и проектирования объектно-ориентированного