Структура UML 2 страница

Рис. 3.21. Графическое изображение составного состояния.

Частными случаями составного состояния являются последовательные состояния (на рис. 3.22 это состояния А, Б, В) и параллельные состояния (на рис. 3.22 это состояние Г по отношению к последовательности состояний А, Б, В).

Рис. 3.22. Графическое изображение составного состояния.

Историческое состояние (history state) – это такое составное состояние, последующие переходы в которое означают переход к последнему подсостоянию объекта. В качестве примера можно привести систему ведения журнал сбоев (рис. 3.23). При втором и последующем обращении к этому состоянию нет необходимости еще раз создавать журнал сбоев, поэтому переход приведет сразу к подсостоянию Запись в журнал. Историческое состояние обозначается символом H в кружке.

Рис. 3.23. Графическое изображение исторического состояния.

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

Переходы между состояниями изображаются на диаграммах состояний стрелками, над которыми могут указываться событие (event), вызвавшее этот переход, условие допустимости этого перехода (сторожевое условие) и действия, сопровождающие этот переход, в формате:

событие(список параметров) [сторожевое условие] выполняемые действия

События на диаграммах состояний исполняют роль триггеров – переход не произойдет, пока не случится соответствующее событие. Если рядом со стрелкой, обозначающей переход, не указано событие, его специфицирующее, то такой переход называется нетриггерным. Нетриггерный переход происходит сразу после выполнения действий в этом состоянии.

Сторожевое условие (guard condition) – некоторое логическое выражение, являющееся дополнительным условием перехода. Переход не произойдет, если сторожевое условие принимает значение false, даже в случае наступления соответствующего события. Сторожевые условия удобно использовать, когда из одного состояния при наступлении одного и того же события возможен переход в несколько других состояний. Например, пусть клиент в виртуальном магазине выбрал товары (состояние – выбор) и по окончании послал команду оплатить покупку (событие). Тогда товары доставляются клиенту только в том случае, если на его счету есть достаточная сумма (сработает переход в состояние, в котором выполняется действие доставки), если же необходимая сумма отсутствует, возможны переходы в другие состояния.

Переходы могут быть простыми и сложными. Простой переход – это переход в другое или в то же состояние объекта. Переход в то же состояние на диаграммах изображается стрелкой, начинающейся и заканчивающейся у этого состояния (рис. 3.24). При каждом переходе такого рода выполняются соответствующие входные и выходные действия.

Рис. 3.24. Графическое изображение перехода в то же состояние.

Сложные переходы – это переходы с несколькими исходными (или конечными) состояниями объекта, а также переходы между подсостояниями разных состояний. Переход с несколькими исходными или несколькими конечными состояниями объекта (параллельный переход) обозначается жирной вертикальной или горизонтальной линией (линией синхронизации), как показано на рис. 3.25.

Рис. 3.25. Графическое изображение параллельного перехода.

Пример перехода между подсостояниями разных состояний показан на рис. 3.26 (переход из A2 в B1).

Рис. 3.26. Пример перехода между подсостояниями разных состояний.

В общем случае, переходы на диаграммах состояний принимаются асинхронными, то есть не зависящими от других переходов. Однако при проектировании может возникнуть необходимость показать синхронность переходов между состояниями объекта. Это достигается введением синхронизирующих состояний, обозначаемых символом * внутри окружности. В примере на рис. 3.27 объект не перейдет в подсостояние B, пока не произойдет переход от С к D, который «синхронизирует» переход от A к B.

Рис. 3.27. Пример использования синхронизирующего состояния.

Совет.

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

Диаграмма активности.

Диаграммы активности позволяют показать движения потоков данных в проектируемой системе.

Диаграммы активности напоминают хорошо знакомые многим алгоритмы, только несколько модифицированные. Пример диаграммы активности показан на рис. 3.28. Диаграмма демонстрирует процесс рассмотрения заявки на получение кредита в некоторой организации.

Рис. 3.28. Пример диаграммы активности.

Поясним применяемые обозначения. Начальное и конечное состояния изображаются так же, как на диаграмме состояний. Прямоугольником с округлыми боковыми сторонами изображается действие над данными (состояние действия). Внутри такого прямоугольника указывается производимое действие (это может быть текст, математическое выражение и т. д.).

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

Движение данных (переходы) изображается сплошными стрелками. Возле стрелок может быть указано сторожевое условие. Если движение данных предусматривает ветвление, то указание условия обязательно (в примере на рис. 3.28 оно не показано). Символ ветвления графически изображается ромбом, из которого выходят две или более стрелки. Разделение потока данных и слияние параллельных потоков данных изображается сплошной жирной чертой, связывающей стрелки движения потоков данных.

Диаграммы активности позволяют показать разделение ответственности различных субъектов за выполнение операций путем введения дорожек (swimlanes). В приведенном примере таких дорожек четыре: Регистратор, Специалист по финансовым рискам, Управляющий, Служба безопасности.

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

Вектор времени на диаграммах активности в явном виде не воспроизводится.

Рис. 3.29. Движение заказа между отделами.

Диаграмма последовательности.

Идеология объектно‑ориентированного программирования заключается в описании поставленной задачи образами некоторых самостоятельных сущностей (объектов), которые в процессе функционирования системы обмениваются сообщениями. Диаграммы последовательности служат инструментом отображения такого обмена.

Основными компонентами диаграмм последовательности являются пользователь, объект, линия жизни объекта (object lifeline), сообщение (message) и фокус управления (focus of control). Объект графически изображается, как и на других UML‑диаграммах, прямоугольником с подчеркнутым именем, линия жизни объекта – вертикальной пунктирной линией, сообщение – горизонтальной стрелкой, фокус управления – прямоугольником на линии жизни объекта.

Примеры диаграмм последовательности приведены на рис. 3.30. На рис. 3.30, а пользователь создает объект, который через некоторое время уничтожается (символ уничтожения объекта – жирный крест). Рис. 3.30, б наглядно демонстрирует идею и параметры замера температурно‑влажностного режима в помещении хранилища музея.

Рис. 3.30. Примеры диаграмм последовательности.

Фокус управления показывает, какой именно элемент находится в активном состоянии (действует). Фокус управления может быть одновременно как у одного, так и у нескольких объектов системы. Фокус управления может передаваться от одного объекта другому. На рис. 3.31 приведен пример передачи фокуса управления от объекта А объекту Б или В в зависимости от условия õ = 0 или x > 0, записываемого возле символа ветвления.

Рис. 3.31. Передача фокуса управления.

Сообщения на диаграммах последовательности могут быть помечены идентификаторами, поясняющими их смысловую нагрузку (стереотипы):

• «call» – вызов объектом другого объекта;

• «return» – возврат значения вызвавшему объекту;

• «create» – создание объекта;

• «destroy» – уничтожение объекта, которому передается это сообщение;

• «send» – посылка асинхронного сигнала.

Рекурсия (самовызов) объекта на диаграммах последовательности может быть показана как сообщение вызова, обращенное объектом самому себе (рис. 3.32, а), или специальным символом на изображении фокуса управления (рис. 3.32, б).

Рис. 3.32. Варианты изображения рекурсии.

Диаграмма сотрудничества.

Диаграмма сотрудничества, как и диаграмма последовательности, является разновидностью диаграмм взаимодействия. Современные программные средства построения диаграмм обеспечивают автоматическое преобразование диаграмм данных видов друг в друга.

Если диаграмма последовательности ориентирована на отображение временных аспектов взаимодействия, то диаграмма сотрудничества (диаграмма кооперации) показывает структурные особенности взаимодействия между объектами и является развитием идеи построения диаграмм сущность‑связь.

Диаграммы сотрудничества бывают двух видов.

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

Рис. 3.33. Пример диаграммы сотрудничества уровня спецификаций.

• Диаграммы сотрудничества уровня примеров оперируют экземплярами классов (объектами), связями между ними и сообщениями, которыми обмениваются объекты.

Объекты на диаграммах сотрудничества обозначаются так же, как и на других UML‑диаграммах – прямоугольниками. Однако на диаграммах данного вида имя объекта может дополняться его ролью в сотрудничестве. На рис. 3.34, а показан образец, на рис. 3.34, б – пример обозначения имени объекта, любая из трех частей которого может отсутствовать.

Рис. 3.34. Графическое изображение объектов на диаграммах сотрудничества.

Объекты, которые могут управлять другими объектами, называются активными (active object) и помечаются словом {active}.

Для обозначения группы объектов, которым адресован один и тот же сигнал, вводится понятие мультиобъекта, изображаемого графически двумя прямоугольниками, наложенными друг на друга (рис. 3.35).

Рис. 3.35. Графическое изображение мультиобъекта.

В отличие от мультиобъекта составной объект действительно состоит из других объектов (рис. 3.36).

Рис. 3.36. Графическое изображение составного объекта.

Между объектами диаграммы сотрудничества существуют связи (links), по которым объекты посылают друг другу сообщения. Связи не имеют названий (в терминах UML они являются анонимными), но могут быть специфицированы ключевыми словами (стереотипами):

• «association» – связь означает некую зависимость объектов;

• «parameter» – объект полагается параметром метода;

• «Local» – локальная переменная метода, область видимости которой ограничена соседним объектом;

• «global» – глобальная переменная, область видимости которой ограничена диаграммой сотрудничества;

• «self» – связь объекта с самим собой.

Приведенные стереотипы требуют пояснения. Связь между объектами в информационной системе на уровне программирования на определенном языке осуществляется посредством передачи параметров (переменных) от одного объекта другому объекту. Например, объект Отдел продаж передает объекту Склад некоторый принятый в организации документ (переменную), в котором сообщает о необходимости выделения продукции той или иной номенклатуры. Значение передаваемых параметров является содержанием передаваемого посредством связи сообщения.

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

• сплошной линией с треугольной стрелкой – такое сообщение означает вызов процедуры (метода объекта) или вызов другого потока управления (рис. 3.37, а);

• сплошной линией с обычной стрелкой – такое сообщение означает простой поток управления, то есть просто передачу данных (рис. 3.37, б);

• сплошной линией с полустрелкой – такое сообщение не имеет заранее обусловленного времени передачи, являясь, как правило, асинхронным (рис. 3.37, в);

• пунктирной линией с обычной стрелкой – такое сообщение означает возврат значения из процедуры (рис. 3.37, г).

Рис. 3.37. Графическое изображение сообщений на диаграммах сотрудничества.

Сообщение записывается в определенном формате. Например, показанная ниже запись означает, что данное сообщение будет передано только после сообщений с номерами 1 и 2 (предшествующие сообщения), при условии истинности введенного пароля (сторожевое условие). В потоке последовательных сообщений оно будет занимать место между сообщениями 3.1 и 3.3, при этом возможна параллельная передача сообщения с другими сообщениями, имеющими номер 3.2. Само сообщение вызывает метод нахождения сведений о человеке по фамилии, имени и отчеству (список аргументов), предполагая предоставление карточки по форме 1А на запрашиваемое лицо (возвращаемое значение):

1, 2 / [пароль] 3.2 Форма_1А:= найти_сведения (Фамилия, Имя, Отчество)

В заключение приведем пример диаграммы сотрудничества. На рис. 3.38 показана диаграмма, иллюстрирующая отношения по расчетам чеками, широко используемые в хозяйственной деятельности предприятий (см. параграф 5 в главе 46 Гражданского кодекса Российской Федерации).

Рис. 3.38. Расчеты чеками.

Примечание.

Приведенный пример значительно упрощен. В частности, не показаны действия в случае неоплаты чека, опущены параметры сообщений.

Диаграмма компонентов.

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

Примечание.

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

Основным элементом диаграмм компонентов является компонент (component), который графически изображается прямоугольником со встроенными слева прямоугольными секциями. Внутри прямоугольника указывается имя компонента, которым может быть имя исполняемого файла, базы данных и т. д., а также служебная информация: версия, язык реализации, разработчик (рис. 3.39).

Рис. 3.39. Графическое изображение компонента.

Иногда перед именем компонента указывается его спецификация:

• library – библиотека;

• table – база данных, отдельная таблица;

• file – исходный текст программ;

• document – документ;

• executable – исполняемый файл.

Для ряда компонентов приняты специальные обозначения. К таким компонентам относятся динамические библиотеки (рис. 3.40, а), справочные файлы (рис. 3.40, б), исходные тексты программ (рис. 3.40, в), веб‑документы (рис. 3.40, г). Эти обозначения вместе с обозначениями исполняемых модулей иногда называют артефактами.

Рис. 3.40. Графическое изображение артефактов.

Между компонентами и другими элементами диаграммы компонентов существуют отношения зависимости (рис. 3.41), показывающие, что один компонент зависит от другого и при его изменении тоже должен меняться, а также отношения реализации, изображаемые сплошной линией (3.42, а), либо указанием на соответствующие элементы внутри обозначения компонента (3.42, б).

Рис. 3.41. Графическое изображение отношения зависимости.

Рис. 3.42. Графическое изображение отношений реализации.

Диаграмма развертывания.

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

Основным обозначением, используемым на диаграммах данного вида, является узел (node), который графически изображается аксонометрической проекцией куба (рис. 3.43). Внутри обозначения узла указывается его имя (например, Сервер) и развертываемые на нем компоненты, изображаемые так же, как на диаграмме компонентов.

Рис. 3.43. Графическое изображение узла.

Между узлами сплошными линиями показывают соединения, которые могут содержать пояснения относительно характера реализации связи между компонентами (рис. 3.44).

Рис. 3.44. Графическое изображение соединения.

Глава 4