Введение в UML 2.0, Часть I

Диаграммы коммуникаций (communication diagrams)

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

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

Звонок от клиента приходит на офисную АТС, оттуда уходит на телефонный аппарат свободного оператора и на сервер. От сервера через локальную сеть этот звонок приходит на клиентское ПО того же оператора.

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

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

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

увеличить изображение
Рис. 3.8. Пример диаграмм коммуникаций

Диаграммы последовательностей (sequence diagrams).

Обратимся теперь к временным свойствам алгоритмов работы системы приема телефонных заявок. Для этого в UML есть диаграммы последовательностей (и еще временные диаграммы, рассматриваемые ниже). Пример такой диаграммы представлен на рис. 3.9.

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

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

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

Временные диаграммы (timing diagrams)

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

Рис. 3.10. Пример временной диаграммы

На рис. 3.10 показан фрагмент работы системы AccessControl, которая управляет открытием/блокированием двери в помещение по предъявлению человеком электронного ключа. На рисунке показано три компоненты этой системы. Первая, panel, является устройством, у которого есть дисплей для отображения текущего состояния всей системы и устройство считывания электронного ключа. Исходно panel находится в состоянии locked (соответствующая надпись отображается и на дисплее). После того как человек приложил к этому устройству электронный ключ и устройство считало с него информацию, panel посылает эту информацию в виде сообщения verify второй компоненте - процессору ( access_processor ) - и переходит в состояние waiting. Процессор до получения сообщения verify находится в состоянии idle, а после получения этого сообщения он переходит в состояние verifying. После успешного окончания проверки данных электронного ключа процессор посылает компонентам panel и door сообщения unlock и переходит в состояние enable. Компонента panel переходит в состояние open. Третья компонента, door (собственно, сама дверь), до этого находилась в состоянии locked и, получив сообщение unlock, открывается (переходит в состояние unlock ). Открытой она остается ровно 5 секунд, после чего процессор присылает ей команду lock и она закрывается - снова переходит в состояние locked. Одновременно процессор посылает команду lock также и компоненте panel, которая переходит в свое исходное состояние locked и отображает слово "locked" на дисплее.

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

Диаграммная область каждой компоненты - это прямоугольник, отделенный от другого, соседнего (представляющего другую компоненту), прямой линией, параллельной оси абсцисс. Компоненты могут обмениваться сообщениями, с помощью которых происходит синхронизация их поведения. Сообщения изображаются вертикальными линиями со стрелками (вверх или вниз).

Диаграммы схем взаимодействия (interaction overview diagram)

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

Контрольные вопросы

1. Перечислите и кратко охарактеризуйте типы диаграмм UML.
2. Сколь строго разделение UML на типы диаграмм?
3. Что такое актер? Перечислите типы актеров и расскажите об их особенностях.
4. Какие отношения возможны между актерами?
5. Что такое случай использования? Расскажите о критериях создания случев использования.
6. Что такое диаграммы бизнес-случаев использования и зачем они нужны?
7. Расскажите, для чего, на ваш взгляд, нужны диаграммы случаев использования.
8. Расскажите о предназначении диаграмм активностей.
9. Расскажите о структуре диаграмм активностей.
10. Чем параллельный разветвитель отличается от логичеcкого?
11. Какой аспект системы призваны моделировать диаграммы развертывания?
12. Каких видов бывают диаграммы развертывания?
13. Какие виды узлов смогут присутствовать на диаграмме развертывания?
14. Предназначаются ли диаграммы развертывания для полной спецификации аппаратной части системы?
15. Расскажите о вариантах использования диаграмм развертывания.
16. Что такое компонента ПО?
17. В чем может выражаться независимоcть компонент?
18. Что такое интерфейс компоненты?
19. Расскажите о проблеме поддержания UML-диаграмм проекта в актуальном состоянии.
20. Как диаграммы компонент могут быть связаны с диаграммами развертывания? Приведите собственный пример.
21. Чем похожи и в чем различаются диаграммы последовательностей и коммуникаций? Какие из них, на ваш взгляд, ближе к структурным, а какие - к поведенческим?
22. Расскажите, в каких случаях, на ваш взгляд, целесообразно применять временн ы е диаграммы. Что в них есть такого, что отсутствует в других поведенческих диаграммах UML?
23. Приведите примеры ситуаций в разработке ПО, когда полезно использовать диаграммы коммуникаций и последовательностей.
24. На примере использования диаграмм последовательностей, изложенном в лекции, постарайтесь обосновать полезность предварительного проектирования ПО.
25. Расскажите о диаграммах схем взаимодействия.
26. Попробуйте составить несколько диаграмм последовательностей и связать их вместе, используя диаграммы схем взаимодействия.