Новиков Ф.А. Учебно-методическое пособие по дисциплине Анализ и проектирование на UML
Подождите немного. Документ загружается.
4.4.2. Диаграммы последовательности
Диаграмма последовательности предназначена для моделирования поведения в
форме описания протокола сеанса обмена сообщениями между
взаимодействующими объектами во время выполнения одного из возможных
сценариев. Из этого определения вытекают несколько следствий, определяющих
состав сущностей и набор отношений, используемых на диаграмме
последовательности (равно как и на диаграмме кооперации).
•
На диаграмме присутствуют только те объекты, которые задействованы в
данном сеансе. Прочие объекты не показываются, хотя возможно и
присутствуют в системе.
•
Отображаются только те связи (экземпляры ассоциаций), которые нужны для
передачи данной последовательности сообщений, прочие ассоциации не
показываются.
• Состав сообщений (а тем самым операций и сигналов) определяется
назначением данного взаимодействия; в других взаимодействиях эти же
объекты могут обмениваться другими сообщениями.
Перейдем к описанию особенностей нотации диаграммы последовательности.
Напомним, что в UML семантика первична, а нотация вторична: возможны
различные вариации в способах рисования диаграмм, особенно это характерно для
диаграмм последовательности. В наших примерах мы придерживаемся самого
"скромного" стиля отображения диаграмм, с минимумом украшений. Однако все
допустимые возможности
На диаграмме последовательности считается выделенным одно направление,
соответствующее течению времени. По умолчанию считается, что время течет
сверху вниз, но это не обязательно, например, можно считать, что время течет
слева направо, оговорив это специальным примечанием. В наших примерах
используется исключительно нотация по умолчанию: время всегда течет сверху
вниз. Саму ось времени не отображают.
Сообщения изображаются прямыми стрелками разного вида (табл. 4.5). Если
передача сообщения считается мгновенной (т. е. время передачи пренебрежимо
мало), то стрелка горизонтальна (т. е. перпендикулярна оси времени). Если же
нужно отобразить задержанную доставку сообщения, то стрелку немного
наклоняют, так чтобы конец стрелки был ниже начала.
Среди сообщений есть первое, которое кладет начало данному взаимодействию.
Стрелка этого сообщения расположена выше всех других стрелок сообщений. Все
объекты, которые находятся выше первого сообщения, существуют до начала
данного взаимодействия; все объекты, которые расположены ниже, возникают в
процессе данного взаимодействия. Обычно объект возникает в результате
выполнения конструктора класса данного объекта. Стрелку сообщения,
соответствующую вызову операции конструктора, принято направлять к фигуре
(прямоугольнику), обозначающей созданный объект.
ЗАМЕЧАНИЕ
Иногда на диаграмме не отображают объект, отправляющий первое сообщение
(например потому, что этот объект не участвует в дальнейшем взаимодействии).
Стрелка первого сообщения приходит "ниоткуда". Вообще говоря, синтаксически
это допустимо, но мы не рекомендуем использовать такой стиль, поскольку он
расходится с общепринятым способом отображения графов (вместе с отношениями
всегда отображать инцидентные им сущности).
В направлении оси времени от всех участвующих во взаимодействии объектов
отходит прямая пунктирная линия, которая называется линией жизни. Линия жизни
представляет объект во взаимодействии: если стрелка отходит от линии жизни
объекта, то это означает, что данный объект отправляет сообщение, а если стрелка
сообщения входит в линию жизни, то это означает, что данный объект получает
сообщение. Если же стрелка пересекает линию жизни объекта, то это ничего не
значит — сообщение пролетело мимо.
120
Если в процессе взаимодействия объект
заканчивает свое существование, то линия жизни обрывается и в этом месте
ставится жирный косой крест.
121
Над стрелкой сообщения указывается текстовая часть описания сообщения.
Синтаксис этой части приведен в разд. 4.4.1. Заметим, что номер сообщения, равно
как и номера предшествующих сообщений (см. разд. 4.4.1), на диаграммах
последовательности обычно не указывают, поскольку в этом нет нужны:
относительный порядок сообщений и так хорошо определяется осью времени.
Мы еще не закончили описание особенностей нотации диаграммы сообщений, но
чувствуем, что пора привести пример. Рассмотрим взаимодействие, возникающее
при одном из простых сценариев в нашей информационной системе отдела кадров,
а именно, создание подразделения. Данное взаимодействие инициируется внешним
действующим лицом — менеджером штатного расписания, который открывает
соответствующую форму и запускает выполнение операции создания
подразделения, после чего закрывает более не нужную ему форму (рис. 4.49).
Рис. 4.49. Диаграмма последовательности
Продолжим описание нотации диаграмм последовательности.
120
Обычно на диаграмме последовательности стараются располагать объекты таким образом, чтобы
стрелки сообщений не пересекали линий жизни. Впрочем, это не всегда возможно.
121
Некоторые авторы считают этот знак буквой "Х". Посмотрите на рис. 4.49 и решите сами, кто
прав.
Вообще говоря, подразумеваемая ось времени на диаграмме последовательности не
является осью координат, на ней нет никакого масштаба и она задает только
отношения "раньше–позже" для сообщений. Если же нужно в явном виде указать
ограничения по времени, например, указать, что время задержки доставки
сообщения должно быть ограничено сверху, то на диаграмму в нужном месте
(имеет значение только положение по вертикали) рядом с началом или концом
стрелки сообщения помещают произвольные идентификаторы, которые
называются метками времени, и добавляют ограничение, задающее требуемое
условие на значения меток времени.
Метка времени — это именованная точка на оси времени.
Допустим, что наша информационная система отдела кадров предназначена для
организации, имеющей удаленный филиал. В этом филиале имеется и работает
свой экземпляр информационной системы, который очевидно, должен быть
проинформирован, что в головной организации создано новое подразделение.
Возможно, эта информация дойдет с некоторой задержкой, поскольку для связи
используется медленный канал. Такую ситуацию можно промоделировать
диаграммой, приведенной на рис. 4.50.
Staff Manager
Staff Form
«utility»
Headquarters
open()
create_deparment ()
CreateDpt()
close()
«utility»
Filial
Notification()
t1
t2
{t2 - t1 < 24 h}
Асинхронный
сигнал
Задержанная
доставка
сообщения
Метка времени
Ограничение
Рис. 4.50. Метки времени и задержанная доставка сообщения
Мы уже отмечали, что сообщение передает не только данные, но и поток
управления. Чтобы показать, что некоторый объект в определенный период
взаимодействия имеет фокус управления, или, как еще говорят, активизирован, на
диаграмме последовательности соответствующую часть линии жизни объекта
изображают в виде узкой полоски. Фактически такая полоска означает выполнение
операции объекта и называется активацией объекта. Начало активации
соответствует приему сообщения вызова операции, а конец активации —
завершению выполнения операции и возврату управления. При этом, если во время
выполнения данной операции будет вызвана еще раз вызвана операция этого же
объекта (та же самая операция, или другая), то это отмечается с помощью еще
одной полоски активации, которая накладывается сбоку на первую. И так далее,
глубина стека вызовов и, соответственно, количество наложенных полосок
активации для одного объекта в UML, естественно, не ограничиваются.
Стек вызовов процедур
За время развития языков программирования были придуманы и
реализованы самые различные механизмы обращения к
подпрограммам, некоторые из них довольно причудливы. Один из них
получил наибольшее распространение в традиционных языках
программирования. При этом способе административная система
времени выполнения поддерживает так называемый
стек вызовов. При
вызове подпрограммы в этот стек помещается новый элемент (его
часто называют фреймом), в котором хранятся переданные аргументы,
локальные переменные подпрограммы и адрес возврата (т. е.
информация о том, куда нужно вернуть управление после завершения
выполнения подпрограммы). Если в процессе выполнения вызванной
подпрограммы происходит еще один вызов, то на стек
вызовов
помещается новый фрейм и т. д. При завершении подпрограммы
верхний элемент стека вызовов снимается со стека и управление
возвращается по сохраненному адресу возврата. Данная структура
данных является именно стеком, поскольку фреймы всегда
помещаются на стек и снимаются со стека в соответствии с
дисциплиной LIFO (Last In First Out: первым пришел — последним
ушел). На вершине стека
вызовов всегда находится фрейм
подпрограммы, выполняющейся в данный момент. Это соответствует
следующей семантике вызова: при вызове выполнение вызывающей
программы приостанавливается, управление (и аргументы) передается
вызываемой подпрограмме, а когда выполнение последней закончится,
возобновляется выполнение вызывающей программы. Другими
словами, выполнение вызывающей программы не может возобновиться
ранее, чем закончится выполнение вызванной. Данный механизм
является простым, эффективным и удобным, что объясняет его
широкое распространение и использование в большинстве случаев по
умолчанию.
Для наглядности на диаграмме последовательности можно показать в явном виде
возврат управления (и, может быть, возвращаемое значение), хотя это не
обязательно: возврат управления подразумевается при использовании сообщения
типа вызов операции. Более того, если использовать полоски для явного указания
активации объектов, стрелки возврата не нужны: их легко можно мысленно
восстановить.
Рассмотрим применение этой группы обозначений на следующем примере из
информационной системы отдела кадров. Допустим, при создании нового
подразделения немедленно выполняется операция
createPos по созданию новой
должности в этом подразделении (для начальника — свято место пусто не бывает),
а после успешного создания подразделения форма демонстрирует менеджеру
штатного расписания измененную организационную диаграмму компании
(рис. 4.51). Здесь мы используем как активации, так и возвраты, чтобы показать
применение всех средств, хотя, может быть, это немного перегружает диаграмму.
Рис. 4.51. Активации и возвраты
Следующее средство, которое нам необходимо обсудить — это ветвления. Как
сказано в разд. 4.4.1, сообщение может иметь сторожевое условие. Если
сторожевое условие ложно, то сообщение просто не будет отправлено.
Соответственно, далее процесс взаимодействия пойдет иным путем. Таким
образом, сторожевые условия на сообщениях позволяют отобразить на одной
диаграмме взаимодействия несколько альтернативных сценариев. Но UML
позволяет больше: можно из одной точки активации отправить несколько
различных сообщений (в том числе адресованным разным объектам), снабженных
альтернативными сторожевыми условиями. Не более чем одно из этих условий
должно оказаться истинным — в противном случае это будет означать
одновременный вызов двух операций в одном потоке управления, что вряд ли
может иметь смысл
и считается нарушением непротиворечивости модели.
Что будет, если два альтернативных сообщения (вызовы разных операций)
отправляются из данной точки активации одному и тому же объекту? Вызываемый
объект в любом случае будет активизирован (мы предполагаем, что ровно одно из
сторожевых условий истинно). Однако, это разные активации. Чтобы отразить это
обстоятельство на диаграмме, в UML введено еще одно обозначение:
альтернативные линии жизни для одного объекта. Альтернативная линия жизни
изображается как пунктирная линия, которая ответвляется от основной линии
жизни объекта, а ниже сливается в ней. Как основная, так и альтернативные линии
жизни могут содержать активации.
Рассмотрим пример (он получился немного искусственным и был создан вопреки
возможностям
используемого инструмента — все-таки диаграммы состояний
больше приспособлены для показа протоколов чисто линейных программ).
Допустим, мы хотим отобразить два сценария создания подразделения: "под
начальника" и исходя из потребностей организации. В обоих случаях при создании
подразделения создается должность начальника, но в первом случае она
немедленно заполняется имеющимся "нужным" человеком (операция occupy), а во
втором объявляется вакантной (операция
setVacant). Чтобы не перегружать
диаграмму, мы включили описание только части взаимодействия, а именно, часть,
соответствующую выполнению операции
createDpt класса Company (рис. 4.52).
Рис. 4.52. Сообщения со сторожевыми условиями и альтернативные линии жизни
Последний, сравнительно редко используемый элемент нотации диаграмм
последовательности, который мы хотим рассмотреть — это отображения на
диаграмме последовательностей состояний пассивных объектов. Данный прием
имеет много общего с траекторией объекта на диаграмме деятельности —
визуализация смены состояний объекта по ходу вычислений, поэтому мы покажем
его на том же примере: прием сотрудника на работу (см
. рис. 4.42–4.46). Допустим
для простоты, что менеджер персонала выполняет свою часть работы с помощью
информационной системы отдела кадров, а собственно принятие решения о найме
выполняется "вручную" где-то вне отдела кадров и менеджер персонала становится
известным данное решение помимо нашей системы. Тогда деятельность менеджера
сводится к тому, чтобы провести интервью и полученную информацию сохранить
во вновь созданном объекте класса
Person, а получив решение, либо выполнить
дальнейшие действия (заполнить документы и т. д., подробности мы опускаем),
либо сообщить кандидату об отказе. В первом случае созданный объект переходит
в состояние Accepted, а во втором — Rejected. Сам созданный объект участвует в
«utility»
Company
New Department
new()
boss
CreateDpt()
createPos()
new()
[has candidate] occupy()
[else] setVacant()
Альтернативные
линии жизни
с активациями
Альтернативные
сообщения
со сторожевыми
условиями
этом взаимодействии пассивным образом: он хранит данные и меняет свое
состояние по командам извне. Сообщений данный объект никаких не посылает. В
таком случае можно на диаграмме последовательности на линии жизни данного
объекта вместо активации показать состояния, в которые он переходит получая
сообщения, как показано на рис. 4.53.
Рис. 4.53. Состояния объекта на диаграмме последовательности
Диаграмма на рис. 4.52–4.53 выглядят не очень убедительно. Действительно,
сообщения передаются мгновенно, и это естественно изображать прямыми
горизонтальными линиями, поскольку время течет на диаграмм
последовательности сверху вниз. Но тогда линии альтернативных сообщений
должны быть нарисованы горизонтально и проходить через одну точку. Как
заметил еще Евклид, в обычной геометрии на плоскости это невозможно. Нам
пришлось прибегнуть к ухищрениям: на рис. 4.52 линия сообщения не прямая, а на
рис. 4.53 не горизонтальная.
К счастью эта же проблема встала перед проетировщиками программного
обесечения очень давно и тогда же была решена. Дело в том, что диаграммы
последовательности UML по существу заимствованы из другого графического
языка описания поведения — MSC (Message Sequence Chart), который был
разработан и успешно применяется производителями встроенных систем. Часть
конструкций MSC была заимствована в UML 1, а оставшиеся в UML 2. В том числе
были заимствованы составные шаги взаимодействия. Составные шаги позволяют
на диаграмме последовательности, которая фактически является диаграммой
Personnel Manager
Hire Form
open()
introduce()
Person
new()
Accepted
Rejected
[accepted]: hire()
[rejected]: refuse()
hire
refuse
close()
протокола взаимодействия, отражать и алгоритмические аспекты, а не только
последовательность передачи сообщений. Составне шаги позволяют графически
изображать на диаграмме последовательности ветвления, циклы и другие полезные
конструкции управления. Делается это очень просто: на диаграмме рисуется рамка,
в углу которой указавается тип составного шага, а внутри шага указываются
частичные последовтельности сообщений в соотвествии с правилами, присущими
шагам данного типа. Например, для ветвлений используется имя alt, а
альтернативные последовательности сообщений рисуются внутри рамки просто
последовательно, друг под другом. Подпоследовательности отделяются
пунктирной лининей и для них указываются соотвествующие сторожевые условия.
На рис. 4.54. приведена та же диаграмма последовательности, что и на рис. 4.52 с
использованием составного шага взаимодействия. Согласитесь, что нотация MSC
достачно выразительна и удобна.
Рис. 4.54. Составной шаг взаимодействия
4.4.3. Диаграммы кооперации
Графических ухищрений на диаграмме кооперации
122
значительно меньше —
данный тип диаграмм графически очень лаконичен и, тем не менее, чрезвычайно
выразителен. Поэтому при рассмотрении элементов диаграмм кооперации мы
больше внимания уделяем семантике, оставляя самоочевидную нотацию для
примеров. В частности, описания некоторых семантических тонкостей,
относящиеся также и к диаграммам последовательности и опущенные в двух
предыдущих разделах, здесь восполнены. Для начала мы остановимся на трех
важных семантических понятиях, присущих диаграммам кооперации, которые не
имеют броского графического выражения, но являются важным аспектом
прагматики диаграмм взаимодействия и могут быть просто не замечены и
пропущены читателем, если он знакомится с языком, глядя только на картинки.
Поскольку данные понятия относятся к сфере семантики и прагматики, с ними не
связано громких ключевых слов и броских графических символов, а потому
возникает терминологическая путаница, особенно в русских переводах. Читателю
не следует пугаться необычных слов в следующих абзацах. Итак, первые три
понятия этого раздела:
• роль классификатора;
• роль ассоциации;
• контекст взаимодействия.
Как уже много раз было сказано, сущностями на диаграммах взаимодействия (в
частности, кооперации) являются объекты. Это действительно так, но с одной
оговоркой: объект на диаграмме взаимодействия может выступать в двух
ипостасях. Это может быть конкретный индивидуальный объект и тогда диаграмма
описывает конкретное взаимодействие с участием данного объекта (диаграмма
является экземпляром взаимодействия). Но также же это может быть слот во
фрейме взаимодействия, подлежащий заполнению конкретным объектом, и тогда
диаграмма описывает множество взаимодействий, задавая их общую схему
(диаграмма является дескриптором взаимодействия).
Представление знаний с помощью фреймов
Одной из ключевых проблем искусственного интеллекта является
представление знаний, т. е. выбор формы хранения знаний в памяти
компьютера. (Примером другой ключевой проблемы искусственного
интеллекта является исследование алгоритмов поиска решения.) Были
предложение различные способы представления знаний: с помощью
правил продукции, с помощью логических формул и др. Одной из самых
удачных была концепция
фреймов, предложенная Минским более 30
лет тому назад. Согласно этой концепции, знания представляются в
виде множества взаимосвязанных структур, которые Минский назвал
фреймами.
123
Фрейм предназначен для описания одного понятия или
122
Напомним, что в UML 2.0 эти диаграммы переименованы в диаграммы коммуникации.
123
Этому термину не повезло: иногда его переводят (рамка, кадр), иногда оставляют в виде
транслитерации, но всегда используют без всяких оговорок о многозначности данного термина,
хотя в разных областях информатики он обозначает совершенно разные вещи: от группы битов в
телекоммуникационном сообщении до области на странице Интернета.
ситуации. Он имеет имя и набор именованных слотов. Слот может
быть не заполнен или заполнен, т. е. содержать конкретное значение,
процедуру или (ссылку на) другой фрейм. Несмотря на внешнюю
простоту этой идеи, она оказалась удивительно плодотворной, как в
смысле конкретной разработки искусственно интеллектуальных
программ, так и в смысле развития фундаментальных понятий в других
областях информатики и программирования.
Второй из рассмотренных случаев, т. е. когда на диаграмме подразумевается слот
объекта, подлежащий заполнению объектом, называется в UML ролью
классификатора.
124
Синтаксически роль классификатора и конкретный объект
почти неразличимы: в обоих случаях изображается стандартная фигура
классификатора (прямоугольник), в которой вписано имя и классификатор,
разделенные двоеточием. Различие заключается в том, что в случает роли
классификатора имя предлагается не подчеркивать.
ЗАМЕЧАНИЕ
К сожалению, данное тонкое семантическое различие многие инструменты
игнорируют и подчеркивают имя роли классификатора. В использованный при
подготовке книги трафарет Visio, хотя и правильно называет фигуру — Classifier
Role — но изображает ее неправильно, с подчеркиванием имени. Впрочем,
поскольку также поступают и многие другие инструменты, данная неправильность
стала уже правилом. Вообще говоря, вопрос о подчеркивании имени роли
классификатора является спорным. С одной стороны, это не конкретный объект: в
слот может быть подставлен любой подходящий объект (имя не нужно
подчеркивать), с другой стороны, это все-таки слот объекта (имя объекта). В таких
спорных случаях проще полагаться на инструмент (оставляя в уме собственное
мнение). В частности, на некоторых наших диаграммах имена подчеркнуты, а на
других — нет.
Семантически объект и слот объекта —это разные вещи. В случае конкретного
объекта имя — это личное имя объекта, а в случае роли классификатора имя — это
имя слота (или, как пишут авторы языка, имя роли, которую объект данного
классификатора играет во взаимодействии). Самое замечательное состоит в том,
что с прагматической точки зрения, это
и не важно: ведь схема взаимодействия
остается одной и той же, она не зависит от того, чем именно заполнен слот (лишь
бы там был объект подходящего класса и посылал те сообщения, которые от него
требуются).
Мы не уверены в абсолютной правомерности следующей аналогии, но все же
приведем ее. Мы надеемся, что следующие две фразы для читателей прозвучат как
цитаты (может из забытого источника). От перемены мест слагаемых сумма не
меняется: 2+3=3+2. Сложение коммутативно: a+b=b+a. Первый пример — это
экземпляр, второй — дескриптор. По нашему мнению, использование роли
классификатора на диаграмме взаимодействия аналогично использованию
алгебраической переменной a при описании арифметических законов.
Совершенно аналогично понятию роли классификатора вводится понятие роли
ассоциации. Отношения между объектами (ролями классификаторов) — это
124
Название, прямо скажем, не очень удачное, а потому трудно переводимое. Все-таки речь идет об
объекте, хотя и являющегося экземпляром определенного классификатора.