Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 82

Деятельность UP Проектирование прецедента. Адаптированос рис. 9.34 [Jacobson 1] с разрешения издательства Addison+Wesleyобсуждался в главе 12, но теперь основное внимание сосредоточено напроектировании, что имеет несколько важных следствий:• При проектировании в реализациях прецедентов участвуют проектные классы, интерфейсы и компоненты, а не классы анализа.• Процесс создания реализаций прецедентов на этапе проектирования часто выявляет новые нефункциональные требования и новыепроектные классы.• Проектирование реализации прецедента помогает найти то, чтоБуч называет центральными механизмами [Booch 1]. Это стандартные пути решения конкретных проблем проектирования (например, организация доступа к базе данных), которые остаются неиз+менными в течение всего процесса разработки.Входными артефактами Проектирования прецедента являются:• Модель прецедентов – см.

часть II «Определение требований».• Модель требований – см. часть II «Определение требований».• Аналитическая модель – рассматривается в части III «Анализ».• Проектная модель – это то, что мы создавали в разделе, посвященномпроектированию. UP представляет проектную модель как входной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 в базе данных. Важно, что этот45120.4. Диаграммы взаимодействий при проектированииПрецедент: AddCourseID: 8Краткое описание:Добавляет детали нового курса в систему.Главные актеры:Registrar.Второстепенные актеры:Нет.Предусловие:1. Registrar вошел в систему.Основной поток:1. Registrar выбирает «add course».2. Registrar вводит имя нового курса.3. Система создает новый курс.Постусловие:1.

Новый курс добавлен в систему.Альтернативные потоки:CourseAlreadyExistsРис. 20.3. Спецификация прецедента AddCoursesd AddCourse:RegistrationManager:RegistrarRegistrar выбирает«add course»Система создаетновый курсaddCourse( "UML" )«create»uml:CourseРис. 20.4. Аналитическая диаграмма взаимодействийцентральный механизм, будучи определенным один раз, должен оставаться неизменным в течение всего проектирования. Однажды нампришлось работать над большой системой, в которой было не менеетрех разных механизмов сохранения – конечно, это слишком много!452Глава 20.

Реализация прецедента на этапе проектированияsd AddCourse – проектирование:RegistrationUI:RegistrationManager:DBManager:RegistraraddCourse( "UML" )addCourse( "UML" )uml= Course("UML")uml:Coursesave(uml)Это иллюстрирует центральный механизм сохраненияобъектов, который должен использоваться по всей системеРис. 20.5.

Диаграмма последовательностей на ранних этапахпроектирования20.5. Моделирование параллелизмаПараллелизм – один из ключевых вопросов, рассматриваемых при проектировании.Параллелизм означает параллельное выполнение частей системы. Этоодин из ключевых вопросов, рассматриваемых при проектировании.UML 2 обеспечивает хорошую поддержку параллелизма:•активные классы (раздел 20.5.1);•ветвления и объединения на диаграммах деятельности (раздел 14.8.3);•оператор par на диаграммах последовательностей (раздел 20.5.2);•порядковые номера в качестве префиксов на коммуникационныхдиаграммах (раздел 20.5.3);•различные представления временных диаграмм (раздел 20.7);•ортогональные составные состояния на диаграммах состояний (раздел 22.2.2).В следующем разделе рассматриваются активные классы, а затем обсуждаются параллелизм на диаграммах последовательностей и коммуникационных диаграммах.45320.5. Моделирование параллелизма20.5.1.

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

Она отслеживает ряд датчиков для обнаружения пожара или проникновения в помещение взломщиков. При срабатывании датчика система включаетсигнализацию. Модель прецедентов для системы безопасности показана на рис. 20.6.Описания прецедентов системы приведены на рис. 20.7.