Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
444 Глава 19. Интерфейсы и компоненты
• его внешнее поведение полностью определяется его предостав
ляемыми и требуемыми интерфейсами;
• компоненты представляют один или более артефактов.
• Компонентноориентированная разработка (CBD) занимается по
строением программного обеспечения из подключаемых частей:
• чтобы сделать компоненты «подключаемыми», применяются ин
терфейсы;
• проектирование интерфейса позволяет использовать много раз
ных реализаций множеством различных компонентов.
• Компоненты могут представлять:
• физическую сущность (например, EJBкомпонент);
• логическую сущность (например, подсистему).
• Стандартные стереотипы компонентов:
• «buildComponent» – компонент, определяющий набор сущностей
для организационных или системных целей разработки;
• «entity» – компонент постоянной информации, представляющий
бизнеспонятие;
• «implementation» – компонент, не имеющий собственной специфи
кации; он является реализацией отдельного компонента, обо
значенного стереотипом «specification», с которым имеет отноше
ние зависимости;
• «specification» – классификатор, который определяет набор объ
ектов без описания их физической реализации – например, ком
понент, обозначенный стереотипом «specification», имеет только
предоставляемые и требуемые интерфейсы, но не имеет реали
зующих классификаторов;
• «process» – ориентированный на транзакции компонент;
• «service» – не имеющий состояния функциональный компонент,
вычисляющий значение;
• «subsystem» – элемент иерархической декомпозиции больших
систем.
• Подсистема – компонент, который играет роль элемента декомпо
зиции большой системы:
• компонент, обозначенный стереотипом «subsystem»;
• логическая конструкция, используемая для разложения боль
шой системы на управляемые части;
• во время выполнения экземпляр подсистемы не может быть соз
дан, но экземпляры ее содержимого создать можно;
• разложение системы на подсистемы – ключ к успешной разра
ботке системы с использованием UP.
19.14. Что мы узнали 445
• Подсистемы используются для:
• разделения задач проектирования;
• представления мало детализированных компонентов;
• создания оболочек для унаследованных систем.
• Интерфейсы используются для сокрытия деталей реализации
подсистем:
• шаблон Фасад скрывает сложную реализацию за простым ин
терфейсом;
• шаблон Разбиение на уровни компонует подсистемы в семан
тически связные уровни:
• зависимости между уровнями должны быть направлены
в одну сторону;
• во всех зависимостях между уровнями должны присутст
вовать интерфейсыпосредники;
• примерами уровней могут быть представление, бизнесло
гика и сервисные уровни.
• Выявление интерфейсов:
• ставим под сомнение ассоциации;
• ставим под сомнение отправки сообщений;
• выделяем группы многократно используемых операций;
• выделяем группы повторяющихся операций;
• выделяем группы повторяющихся атрибутов;
• ищем классы, играющие в системе одну и ту же роль;
• ищем возможности будущего расширения;
• ищем зависимости между компонентами.
20
Реализация прецедента
на этапе проектирования
20.1. План главы
В этой главе рассматривается проектная реализация прецедента. Это
процесс уточнения аналитических диаграмм взаимодействий и клас
сов, в результате которого на них будут представлены артефакты проек
тирования. Проектные классы были подробно рассмотрены в главе 17,
а здесь основное внимание обращено на диаграммы взаимодействий.
В частности, обсуждается использование диаграмм взаимодействий
в проектировании для моделирования центральных механизмов. По
следние представляют собой стратегические проектные решения, ко
торые необходимо принять относительно сохранения (persistence) объ
ектов, их распределения (distribution) и т. д. Кроме того, на примере
создания диаграмм взаимодействия подсистем мы научимся использо
вание диаграммы взаимодействий для представления высокоуровне
вых взаимодействий в системе. В этой главе рассказывается о времен
ных диаграммах. Это новый, введенный в UML 2 тип диаграмм, очень
полезный для моделирования аппаратных систем реального времени
и встроенных систем. И завершается глава реальным, но простым при
мером реализации прецедента на этапе проектирования.
20.2. Деятельность UP:
Проектирование прецедента
Деятельность UP Проектирование прецедента (Design a use case) (рис. 20.2)
заключается в выявлении проектных классов, интерфейсов и компо
нентов, взаимодействие которых обеспечивает поведение, описанное
прецедентом (артефакты, измененные по сравнению с оригинальным
рисунком, затушеваны). Это процесс реализации прецедента, который
20.2. Деятельность UP: Проектирование прецедента 447
20.5.3. Параллелизм на коммуникационных диаграммах
20.2. Деятельность UP: Проектирование прецедента
20.3. Проектная реализация
прецедента
20.4. Диаграммы взаимодействий
при проектировании
20.5. Моделирование
параллелизма
20.6. Взаимодействия
подсистем
20.7. Временные
диаграммы
20.5.1. Активные классы
20.9. Что мы узнали
20.8. Пример реализации прецедента на этапе проектирования
20.5.2. Параллелизм на диаграммах последовательностей
Рис. 20.1. План главы
448 Глава 20. Реализация прецедента на этапе проектирования
обсуждался в главе 12, но теперь основное внимание сосредоточено на
проектировании, что имеет несколько важных следствий:
• При проектировании в реализациях прецедентов участвуют про
ектные классы, интерфейсы и компоненты, а не классы анализа.
• Процесс создания реализаций прецедентов на этапе проектирова
ния часто выявляет новые нефункциональные требования и новые
проектные классы.
• Проектирование реализации прецедента помогает найти то, что
Буч называет центральными механизмами [Booch 1]. Это стандарт
ные пути решения конкретных проблем проектирования (напри
мер, организация доступа к базе данных), которые остаются неиз+
менными в течение всего процесса разработки.
Входными артефактами Проектирования прецедента являются:
• Модель прецедентов – см. часть II «Определение требований».
• Модель требований – см. часть II «Определение требований».
• Аналитическая модель – рассматривается в части III «Анализ».
• Проектная модель – это то, что мы создавали в разделе, посвященном
проектированию. UP представляет проектную модель как входной
Разработчик
прецедентов
Проектирование
прецедента
Проектный класс
[в общих чертах]
Аналитическая модель
Модель прецедентов
Модель требований
Интерфейс
[в общих чертах]
Проектная модель
Модель развертывания
Подсистема
[в общих чертах]
«subsystem»
Проектная реализация
прецедента
Рис. 20.2. Деятельность UP Проектирование прецедента. Адаптировано
с рис. 9.34 [Jacobson 1] с разрешения издательства Addison+Wesley
20.3. Проектная реализация прецедента 449
артефакт Проектирования прецедента, чтобы обозначить итеративную
природу этого процесса. По мере выявления в процессе проектиро
вания все большего числа деталей системы происходит уточнение
каждого из артефактов.
• Модель развертывания – обсуждается в главе 24. Модель развертыва
ния также представлена как входной артефакт этой деятельности
проектирования, чтобы проиллюстрировать, как все артефакты со
вместно эволюционируют во времени.
Важно понимать, что проектирование – итеративный процесс, а не по
следовательность шагов. По существу, информация, выявленная в от
ношении одного артефакта, может повлиять на остальные артефакты.
Синхронизация всех артефактов является составной частью проекти
рования.
20.3. Проектная реализация прецедента
«Проектная реализация прецедента» – это взаимодействие проектных
объектов и проектных классов, реализующих прецедент.
Проектная реализация прецедента – это взаимодействие проектных
объектов и проектных классов, реализующих прецедент. Между ана
литической и проектной реализациями прецедента установлено отно
шение «trace». Проектирование реализации прецедента определяет ре
шения уровня реализации и реализует нефункциональные требова
ния. Проектная реализация прецедента состоит из:
• проектных диаграмм взаимодействий;
• диаграмм классов, включающих участвующие в ней проектные
классы.
При анализе основное внимание в реализации прецедентов было сосре
доточено на том, что должна делать система. В проектировании нас
интересует, как система собирается это делать. Таким образом, теперь
нам необходимо определить детали реализации, которые игнорирова
лись на этапе анализа. Поэтому проектные реализации прецедентов
являются намного более детализированными и сложными, чем исход
ные аналитические реализации прецедентов.
Важно помнить, что моделирование осуществляется лишь для того,
чтобы облегчить понимание создаваемой системы. Объем работы дол
жен быть ограничен лишь тем, что на самом деле представляет инте
рес. Такой подход называют стратегическим проектированием. Суще
ствует также тактическое проектирование, которое можно без ущерба
перенести в фазу реализации. По сути, полное проектирование осуще
ствляется только тогда, когда предполагается генерировать большую
часть кода из модели. И даже в этом случае проектные реализации
прецедентов редко активно используются в генерировании кода. По
450 Глава 20. Реализация прецедента на этапе проектирования
этому они создаются, только если необходимо обозначить малопонят
ные аспекты поведения системы.
20.4. Диаграммы взаимодействий
при проектировании
При проектировании можно уточнять основные диаграммы взаимодей
ствий или создавать новые для иллюстрации центральных механизмов,
таких как сохранение объектов.
Диаграммы взаимодействий – основная часть проектной реализации
прецедента. Поскольку большие объемы информации проще показать
на диаграммах последовательностей, то при проектировании зачастую
именно им, а не коммутационным диаграммам, уделяется основное
внимание.
Диаграммы взаимодействий в проектировании могут быть:
• уточнением основных аналитических диаграмм взаимодействий
с дополнением деталей реализации;
• абсолютно новыми диаграммами, созданными для иллюстрации
технических вопросов, возникших при проектировании.
При проектировании вводится ограниченное число центральных ме
ханизмов, таких как сохранение объектов, распределение объектов,
транзакции и т. д. Часто диаграммы взаимодействий создаются имен
но для представления этих механизмов. Диаграммы взаимодействий,
иллюстрирующие центральные механизмы, нередко охватывают не
сколько прецедентов.
Чтобы понять роль диаграмм последовательностей в проектировании,
рассмотрим прецедент AddCourse, который обсуждался ранее в разде
ле 12.9.1 (рис. 20.3).
На рис. 20.4 показана аналитическая диаграмма взаимодействий, соз
данная нами в разделе 12.9.1 (с. 276).
На рис. 20.5 представлена обычная диаграмма последовательностей
для прецедента AddCourse на ранних этапах проектирования. Как види
те, здесь добавлен слой GUI, хотя он и не был смоделирован достаточно
глубоко. Также высокоабстрактные операции аналитической диаграм
мы последовательностей превращены в операции уровня проектирова
ния, достаточно полно описанные для реализации. Например, теперь
подробно показано создание объекта посредством вызова явной опера
ции конструктора.
Рисунок 20.5 также включает центральный механизм – обеспечение
сохранения объектов Course. В данном случае был выбран очень про
стой механизм сохранения: :RegistrationManager использует сервисы
:DBManager для хранения объектов Course в базе данных. Важно, что этот
20.4. Диаграммы взаимодействий при проектировании 451
центральный механизм, будучи определенным один раз, должен оста
ваться неизменным в течение всего проектирования. Однажды нам
пришлось работать над большой системой, в которой было не менее
трех разных механизмов сохранения – конечно, это слишком много!
Прецедент: AddCourse
Главные актеры:
Registrar.
Предусловие:
1. Registrar вошел в систему.
Постусловие:
1. Новый курс добавлен в систему.
Основной поток:
1. Registrar выбирает «add course».
2. Registrar вводит имя нового курса.
3. Система создает новый курс.
Альтернативные потоки:
CourseAlreadyExists
ID: 8
Краткое описание:
Добавляет детали нового курса в систему.
Второстепенные актеры:
Нет.
Рис. 20.3. Спецификация прецедента AddCourse
:Registrar
:RegistrationManager
uml:Course
addCourse( "UML" )
«create»
sd AddCourse
Registrar выбирает
«add course»
Система создает
новый курс
Рис. 20.4. Аналитическая диаграмма взаимодействий
452 Глава 20. Реализация прецедента на этапе проектирования
20.5. Моделирование параллелизма
Параллелизм – один из ключевых вопросов, рассматриваемых при про
ектировании.
Параллелизм означает параллельное выполнение частей системы. Это
один из ключевых вопросов, рассматриваемых при проектировании.
UML 2 обеспечивает хорошую поддержку параллелизма:
• активные классы (раздел 20.5.1);
• ветвления и объединения на диаграммах деятельности (раздел 14.8.3);
• оператор par на диаграммах последовательностей (раздел 20.5.2);
• порядковые номера в качестве префиксов на коммуникационных
диаграммах (раздел 20.5.3);
• различные представления временных диаграмм (раздел 20.7);
• ортогональные составные состояния на диаграммах состояний (раз
дел 22.2.2).
В следующем разделе рассматриваются активные классы, а затем об
суждаются параллелизм на диаграммах последовательностей и ком
муникационных диаграммах.
:Registrar
:RegistrationUI
uml:Course
addCourse( "UML" )
uml= Course("UML")
sd AddCourse – проектирование
:RegistrationManager
:DBManager
save(uml)
Это иллюстрирует центральный механизм сохранения
объектов, который должен использоваться по всей системе
addCourse( "UML" )
Рис. 20.5. Диаграмма последовательностей на ранних этапах
проектирования
20.5. Моделирование параллелизма 453
20.5.1. Активные классы
Параллелизм – каждый активный объект имеет собственный поток вы
полнения.
Основной принцип моделирования параллелизма – каждый поток
управления или параллельный процесс моделируется как активный
объект. Под последним понимают объект, инкапсулирующий собст
венный поток управления. Активные объекты являются экземпляра
ми активных классов. Активные объекты и активные классы изобра
жаются на диаграммах как обычные классы и объекты, но с двойной
рамкой справа и слева, как показано на рис. 20.8.
Параллелизм обычно имеет большое значение для встроенных систем,
таких как программное обеспечение, управляющее минифотолаборато
рией или банкоматом. Для изучения параллелизма рассмотрим очень
простую встроенную систему – систему безопасности. Она отслежива
ет ряд датчиков для обнаружения пожара или проникновения в поме
щение взломщиков. При срабатывании датчика система включает
сигнализацию. Модель прецедентов для системы безопасности показа
на на рис. 20.6.
Описания прецедентов системы приведены на рис. 20.7. Прецедент Ac
tivateFireOnly (активировать только пожарные датчики) не рассматрива
ется, поскольку основное внимание в этом разделе направлено на ас
пекты параллелизма системы. Кроме того, эти прецеденты довольно
абстрактны и отражают лишь суть того, что должна делать система
сигнализации. Более подробно ее поведение будет рассмотрено позже.
Теперь надо найти классы. Для встроенных систем превосходным ис
точником классов могут быть аппаратные средства, на которых систе
ма выполняется. На практике наилучшей программной архитектурой
обычно является та, которая максимально близка к архитектуре фи
DeactivateSystem
Система безопасности
SecurityGuard
Fire Intruder
TriggerSensor
ActivateFireOnly
ActivateAll
Рис. 20.6. Модель прецедентов для системы безопасности