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

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 82)

Объем работы должен быть ограничен лишь тем, что на самом деле представляет интерес. Такой подход называют стратегическим проектированием. Существует также тактическое проектирование, которое можно без ущербаперенести в фазу реализации. По сути, полное проектирование осуществляется только тогда, когда предполагается генерировать большуючасть кода из модели. И даже в этом случае проектные реализациипрецедентов редко активно используются в генерировании кода. По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. Прецедент ActivateFireOnly (активировать только пожарные датчики) не рассматривается, поскольку основное внимание в этом разделе направлено на аспекты параллелизма системы. Кроме того, эти прецеденты довольноабстрактны и отражают лишь суть того, что должна делать системасигнализации. Более подробно ее поведение будет рассмотрено позже.Теперь надо найти классы. Для встроенных систем превосходным источником классов могут быть аппаратные средства, на которых система выполняется. На практике наилучшей программной архитектуройобычно является та, которая максимально близка к архитектуре фиСистема безопасностиDeactivateSystemSecurityGuardActivateAllActivateFireOnlyTriggerSensorFireРис.

20.6. Модель прецедентов для системы безопасностиIntruder454Глава 20. Реализация прецедента на этапе проектированияПрецедент: DeactivateSystemПрецедент: ActivateAll (АктивироватьВсе)Прецедент: TriggerSensorID: 1Краткое описание:Деактивирует систему.ID: 2Краткое описание:Активирует систему.ID: 3Краткое описание:Срабатывает датчик.Главные актеры:SecurityGuardВторостепенные актеры:Нет.Предусловия:1. У SecurityGuard есть ключ активации.Основной поток:1. SecurityGuard применяет ключактивации для выключения системы.2. Система прекращает отслеживаниедатчиков безопасности и пожарныхдатчиков.Главные актеры:SecurityGuardВторостепенные актеры:Нет.Предусловия:1.

У SecurityGuard есть ключ активации.Основной поток:1. SecurityGuard применяет ключактивации для включения системы.2. Система начинает отслеживатьдатчики безопасности и пожарныедатчики.3. Система воспроизводит звуксирены, демонстрируя готовность.Главные актеры:FireIntruderПостусловия:1. Система безопасностидеактивирована.2. Система безопасности неотслеживает датчики.Альтернативные потоки:Нет.Второстепенные актеры:Нет.Предусловия:1.

Система безопасности активирована.Основной поток:1. Если актер Fire инициируетпожарный датчик (FireSensor).1.1. Сирена воспроизводит сигналпожарной тревоги.2. Если актер Intruder инициируетдатчик безопасности (SecuritySensor).2.1. Сирена воспроизводит сигналтревоги.Постусловия:1. Система безопасности активирована.2. Система безопасности отслеживаетдатчики.Постусловия:1. Звучит сигнал Сирены.Альтернативные потоки:Нет.Альтернативные потоки:Нет.Рис.

20.7. Описание прецедентов системы безопасностизического оборудования. В рассматриваемом случае сигнализация состоит из четырех компонентов: блока управления, сирены, набора пожарных датчиков и набора датчиков безопасности. Если заглянутьв лок управления, там можно найти плату контроллера для каждогоиз типов датчиков.Исходя из прецедентов и информации о физическом оборудованииможно получить диаграмму классов для этой системы, представленную на рис. 20.8.активный классControlBox11Siren11SecuritySensorMonitor10..*SecuritySensor1FireSensorMonitor10..*FireSensorРис. 20.8. Диаграмма классов системы безопасности45520.5. Моделирование параллелизмаЭкземплярами активных классов являются активные объекты.Система безопасности должна непрерывно отслеживать пожарные датчики и датчики безопасности, поэтому необходимо использовать многопоточность (multithreading).

Характеристики

Список файлов книги