Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
364 Глава 16. Рабочий поток проектирования
ляются высокоуровневым концептуальным представлением классов
системы. Когда дело доходит до физического моделирования (проекти
рования), для реализации этих концептуальных классов может пона
добиться один или более физических проектных классов и/или интер
фейсов.
Между аналитическими и проектными реализациями прецедентов ус
танавливается простое одинкодному отношение «trace». При проекти
ровании реализация прецедента просто становится более детализиро
ванной.
16.3.2. Нужно ли поддерживать две модели?
В идеальном мире для системы создавалась бы единственная модель,
и средство моделирования могло бы предоставлять на выбор или анали
тическое, или проектное представление. Однако это требование слож
нее, чем кажется на первый взгляд. Ни одно из присутствующих в на
стоящее время на рынке инструментальных средств UMLмоделирова
ния не может удовлетворительно справиться с задачей создания анали
тического и проектного представлений на основании одной базовой
модели. Похоже, нам ничего не остается, как пользоваться четырьмя
стратегиями, описанными в табл. 16.1.
Сохраняйте аналитические модели для больших, сложных или стратеги
чески важных систем.
Таблица 16.1
Идеальной стратегии нет, все зависит от проекта. Однако необходимо
задать себе фундаментальный вопрос: нужно ли сохранять аналитичес
кое представление системы? Аналитические представления обеспечи
Стратегия Результаты
1 Берется аналитическая модель и до
полняется до проектной модели.
Имеется единственная проектная мо
дель, но утеряно аналитическое пред
ставление.
2 Берется аналитическая модель, до
полняется до проектной модели, а
с помощью инструмента моделиро
вания восстанавливается «аналити
ческое представление».
Имеется единственная проектная мо
дель, но восстановленное инструмен
том моделирования аналитическое
представление может быть неприем
лемым.
3 Аналитическая модель заморажива
ется в некоторой точке фазы Уточне
ние. До проектной модели дополня
ется копия аналитической модели.
Имеются две модели, но они не син
хронизированы.
4 Поддерживаются две отдельные мо
дели – аналитическая и проектная.
Имеются две модели – они синхрони
зованы, но их обслуживание очень
трудоемко.
16.4. Детализация рабочего потока проектирования 365
вают «общую картину» системы. В них может быть лишь от 1 до 10%
классов подробного проектного представления, поэтому они более по
нятны. Их роль неоценима для следующих действий:
• введения в проект новых людей;
• понимания системы спустя месяцы или годы после ее поставки;
• понимания того, как система выполняет требования пользователей;
• обеспечения прослеживаемости требований;
• планирования обслуживания и улучшения;
• понимания логической архитектуры системы;
• привлечения внешних ресурсов к разработке системы.
Если необходимо чтото из перечисленного выше, несомненно, анали
тическое представление должно быть сохранено. Обычно аналитиче
ское представление должно сохраняться для любой большой, сложной,
стратегически важной системы или системы с предположительно боль
шим ресурсом. Это означает, что необходимо выбирать между страте
гиями 3 и 4. Возможность рассинхронизации аналитической и проект
ной моделей должна быть всегда очень тщательно продумана. Допус
тимо ли это для разрабатываемого проекта?
Если система небольшая (скажем, меньше 200 проектных классов), то
гда непосредственно проектная модель достаточно мала и понятна, по
этому в отдельной аналитической модели, возможно, и нет необходи
мости. Также, если система не имеет стратегического значения или
недолговечна, разделение аналитической и проектной моделей – из
лишнее требование. В этом случае необходимо выбирать между страте
гиями 1 и 2, и решающим фактором будут возможности используемого
инструментального средства UMLмоделирования. Некоторые инстру
менты моделирования сохраняют одну базовую модель и обеспечивают
возможность применения фильтров и сокрытия информации для вос
становления «аналитического» представления из проектной модели.
Это разумный компромисс для многих систем среднего размера, но для
очень больших систем этого, скорее всего, недостаточно.
И наконец, стоит помнить о том, что реальный срок службы многих
систем существенно превышает предполагаемый!
16.4. Детализация рабочего потока
проектирования
Рабочий поток UP для проектирования представлен на рис. 16.6. Ос
новные его участники: архитектор, разработчик прецедентов и разра
ботчик компонентов. В большинстве ОО проектов роль архитектора
выполняют один или несколько специалистов, но часто они же потом
являются разработчиками прецедентов и компонентов.
366 Глава 16. Рабочий поток проектирования
Одна из целей UP состоит в том, чтобы определенные члены команды
отвечали за отдельные части системы, начиная с анализа и заканчивая
реализацией. Таким образом, специалист или команда, ответственные
за создание конкретной части ОО аналитической модели, будут допол
нять ее до проектной модели и, возможно с помощью программистов,
превращать ее в код. При таком подходе (в этом его основное преиму
щество) нет «перекладывания ответственности» друг на друга между
аналитиками, проектировщиками и программистами, что распростра
нено в ОО проектах.
16.5. Деятельность UP: проектирование
архитектуры
В UP начало всему процессу проектирования дает деятельность под
названием Проектирование архитектуры (architectural design). Ее осущест
вляют один или более архитекторов. Детали этой деятельности пред
ставлены на рис. 16.7.
Как видно из рисунка, результатом Проектирования архитектуры является
множество артефактов (затушеванные артефакты указывают на изме
нения, внесенные в оригинальный рисунок). В следующих главах этой
части книги будет подробно рассмотрено, что представляют собой эти
артефакты и как их найти. Самое главное, необходимо понять, что
проектирование архитектуры заключается в предварительном описа
нии артефактов, важных с архитектурной точки зрения, с целью соз
дания общего плана архитектуры системы. Обозначенные в общих
чертах артефакты являются входными данными для более детального
проектирования, в процессе которого происходит их конкретизация.
Проектирование прецедента
Проектирование класса
Разработчик компонентов
Архитектор
Разработчик прецедентов
Проектирование подсистемы
Проектирование архитектуры
Рис. 16.6. Рабочий поток проектирования. Воспроизведено с рис. 9.16 [Jacobson 1]
с разрешения издательства Addison+Wesley
16.6. Что мы узнали 367
Обычно Проектирование архитектуры не выделяется в отдельный шаг. Не
следует забывать, что UP – итеративный процесс. Таким образом, про
работка деталей архитектуры системы ведется на всем протяжении
завершающих этапов Уточнения и в начале Построения.
16.6. Что мы узнали
В рабочем потоке проектирования определяется, как будет реализовы
ваться функциональность, описанная в аналитической модели. Мы уз
нали следующее:
• Проектирование – основная деятельность при моделировании в по
следней части фазы Уточнение и первой части фазы Построение.
• Анализ и проектирование в некоторой степени могут происхо
дить параллельно.
• Одна команда должна провести артефакт от анализа до проекти
рования.
• ОО проектировщики основное внимание должны уделять глав
нейшим вопросам проектирования, таким как арихитектуры
распределенных компонентов – политики и стандарты должны
Архитектор
Проектирование
архитектуры
Описание
архитектуры
А
налитическая
модель
Модель
прецедентов
Модель
требований
Проектный класс
[в общих чертах]
Модель развертывания
[в общих чертах]
Интерфейс
[в общих чертах]
Подсистема
[в общих чертах]
«subsystem»
Описание архитектуры
Рис. 16.7. Деятельность UP Проектирование архитектуры. Адаптировано
с рис. 9.17 [Jacobson 1] с разрешения издательства Addison+Wesley
368 Глава 16. Рабочий поток проектирования
вводиться для решения тактически важных вопросов проекти
рования.
• Проектная модель включает:
• проектные подсистемы;
• проектные классы;
• интерфейсы;
• реализации прецедентов – проектные;
• диаграмму развертывания (в первом приближении).
• Отношения отображения существуют между:
• проектной и аналитической моделями;
• одной или более проектными подсистемами и пакетом анализа.
• Следует поддерживать две отдельные модели, аналитическую и про
ектную, если система:
• большая;
• сложная;
• стратегически важная;
• подвержена частым изменениям;
• предположительно с большим сроком службы;
• для ее разработки привлекаются внешние ресурсы.
• Деятельность UP Проектирование архитектуры – это итеративный про
цесс, имеющий место в конце фазы Уточнение и в начале фазы По
строение:
• в ходе процесса создаются и описываются в общих чертах арте
факты, которые в дальнейшем конкретизируются.
17
Проектные классы
17.1. План главы
В этой главе рассказывается о проектных классах – строительных бло
ках проектной модели. Для ОО проектировщика жизненно важно по
нимать, как моделировать эти классы эффективно.
После описания контекста UP мы рассмотрим анатомию проектного
класса, а затем в разделе 17.5 перейдем к анализу того, что образует
правильно сформированный проектный класс. Здесь будут рассмотре
ны требования полноты и достаточности, простоты, высокой внутрен
ней связности, низкой связанности с другими классами и применимо
сти агрегации вместо наследования.
17.2. Деятельность UP: Проектирование класса
В детализации рабочего потока проектирования в UP (рис. 16.6) после
Проектирования архитектуры (Architectural design) следуют деятельности
Проектирование класса (Design a class) и Проектирование прецедента (Design
a use case) (раздел 20.2). Они являются параллельными и итеративными.
В этом разделе рассматривается деятельность UP Проектирование класса,
представленная на рис. 17.2. Мы расширили ее и показали Интерфейс
[полный] как явный результат Проектирования класса. Этот артефакт за
тушеван, чтобы показать, что он был изменен. В оригинальном описа
нии деятельности он был неявным результатом.
Создание входного артефакта Класс анализа [полный] уже обсуждалось
в части книги, посвященной анализу, поэтому мы больше не будем воз
вращаться к этому вопросу.
Стоит более подробно рассмотреть артефакт Проектный класс [в общих
чертах]. С точки зрения деятельности кажется, что здесь присутствуют
два отдельных самостоятельных артефакта, Проектный класс [в общих
370 Глава 17. Проектные классы
17.2. Деятельность UP: Проектирование класса
17.4. Анатомия проектного класса
17.3. Что такое проектные классы?
17.5. Правильно сформированные проектные классы
17.5.1. Полнота и достаточность 17.5.2. Простота
17.5.4. Низкая связанность
с другими классами
17.5.3. Высокая
внутренняя связность
17.6.3. Сравнение наследования
и реализации интерфейса
17.6.1. Сравнение агрегации
и наследования
17.6. Наследование
17.9. Что мы узнали
17.8. Вложенные классы
17.7. Шаблоны
17.6.2. Множественное
наследование
Рис. 17.1. План главы
17.2. Деятельность UP: Проектирование класса 371
чертах] и Проектный класс [полный]. Однако это не так. Они просто пред
ставляют один и тот же артефакт (проектный класс) на разных этапах
развития.
Если взять набор артефактов UPпроекта в конце фазы Уточнение или
в начале Построения, то не найдется артефактов под названием Проект
ный класс [в общих чертах] или Проектный класс [полный]. Там будут только
проектные классы, находящиеся на разных этапах своего развития.
С точки зрения UP «полный» проектный класс – это класс, достаточно
детализированный, чтобы служить базой для создания исходного ко
да. Это основное положение, о котором начинающие разработчики мо
делей часто забывают. Проектные классы моделируются с той степе
нью детализации, которая позволяет создать код, полученный на их
основе. Поэтому модели проектных классов редко бывают исчерпы
вающими. Необходимый уровень детализации определяется проек
том. Если предполагается генерировать код прямо из модели, то про
ектные классы необходимо моделировать очень подробно. С другой
стороны, если программисты не будут использовать их в качестве ра
бочего прототипа, модели проектных классов могут быть менее де
тальными. В этой главе рассказывается, как моделировать проектные
классы, достаточно подробные для любого проекта.
Проектный класс
[полный]
Интерфейс
[полный]
Разработчик
компонентов
Проектирование
класса
Проектный класс
[в общих чертах]
Интерфейс
[в общих чертах]
Реализация прецедента –
проектирование
Класс анализа
[полный]
Рис. 17.2. Деятельность Проектирование класса. Адаптировано с рис. 9.39
[Jacobson 1] с разрешения издательства Addison+Wesley
372 Глава 17. Проектные классы
Соображения по поводу артефактов Проектный класс [в общих чертах]
и Проектный класс [полный] также применимы к Интерфейсу [в общих чер
тах] и Интерфейсу [полный].
Входной артефакт Реализация прецедента – проектирование (use case realiza
tion – design) – это всегонавсего завершающий этап жизненного цикла
реализации прецедента. Хотя он изображен вливающимся в Проектиро
вание класса, на самом деле он включает проектные классы как часть
своей структуры и разрабатывается параллельно с ними. Отложим об
суждение Реализации прецедента – проектирование до главы 20, посколь
ку, по нашему мнению, эффективнее (и понятней для читателя) снача
ла рассмотреть его составляющие части.
17.3. Что такое проектные классы?
Проектные классы – это классы, описания которых настолько пол
ные, что они могут быть реализованы.
При анализе источником классов является предметная область. Это на
бор требований, описывающий задачу, которую необходимо решить.
Как мы видели, прецеденты, описания требований, глоссарии и любая
другая относящаяся к делу информация могут использоваться как ис
точник классов анализа.
Предметная область и область решения являются источником проект
ных классов.
У проектных классов два источника:
• Предметная область посредством уточнения классов анализа; это
уточнение включает добавление деталей реализации. В ходе этого
процесса часто обнаруживается, что высокоабстрактный класс ана
лиза необходимо разбить на два или более детализированных про
ектных класса. Реализацию класса анализа описывает отношение
«trace», устанавливаемое между ним и одним или более проектными
классами.
• Область решения – это царство библиотек утилитных классов и мно
гократно используемых компонентов, таких как Time, Date, String,
коллекции и т. д. Здесь находится промежуточное программное
обеспечение (middleware), такое как коммуникационное ПО, базы
данных (и реляционные, и объектные) и компонентные инфраструк
туры, например .NET, CORBA или Enterprise JavaBeans, а также
средства для построения GUI. Эта область предоставляет техниче
ские инструментальные средства для реализации системы.
Это проиллюстрировано на рис. 17.3.
При анализе моделируется, что должна делать система. При проекти
ровании моделируется то, как это поведение может быть реализовано.
17.3. Что такое проектные классы? 373
Почему класс анализа может быть уточнен в один или более проект
ных классов или интерфейсов? Это понятно, поскольку класс анализа
описан на очень высоком уровне абстракции. Здесь нет полного набора
атрибутов, а набор операций – это фактически только эскиз, отражаю
щий ключевые сервисы, предлагаемые классом.
При переходе к проектированию все операции и атрибуты класса долж
ны быть полностью описаны, поэтому нередко он становится слишком
большим. Если это происходит, необходимо разбить его на два или бо
лее меньших классов. Помните, что всегда надо стремиться проектиро
вать небольшие классы, являющиеся самодостаточными, связными
элементами, которые хорошо справляются с однойдвумя функциями.
Любой ценой необходимо избегать больших классов, напоминающих
«швейцарский армейский нож», которые делают все.
Выбранный метод реализации определяет требуемую степень полноты
описаний проектных классов. Если планируется передать модель про
ектного класса программистам в качестве руководства для написания
кода, проектные классы должны быть полными лишь настолько, что
бы обеспечить им возможность эффективного выполнения задания.
Все зависит от квалификации программистов и того, насколько хоро
шо они понимают предметную область и область решения. Это выясня
ется для каждого конкретного проекта индивидуально.
Однако если предполагается использовать проектные классы для гене
рации кода с помощью соответствующим образом оснащенного инст
рументального средства моделирования, их описания должны быть
полными во всех отношениях. Генератор кода, в отличие от програм
миста, не может заполнять пробелы. Далее в этой главе обсуждение
материала ведется исходя из предположения, что требуется очень вы
сокая степень детализации.
java.util
Область решения
Предметная область
Классы анализа
Проектные классы
Рис. 17.3. Два источника проектных классов: предметная область
и область решения