Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
274 Глава 12. Реализация прецедентов
ни), откуда поступило это сообщение. На практике такое встречается
редко.
Потерянные сообщения позволяют показать, что сообщение потеряно –
оно никогда не достигает точки своего назначения. Это может быть по
лезно при проектировании, чтобы показать, как могут теряться сооб
щения в условиях возникновения ошибки. Однако у нас никогда не
возникало крайней необходимости использовать это понятие.
12.8. Диаграммы взаимодействий
Диаграммы взаимодействий UML могут использоваться для модели
рования любого типа взаимодействия между экземплярами классифи
каторов. В частности, в реализации прецедентов диаграммы взаимо
действий используются для моделирования взаимодействий между
объектами, реализующими прецедент или его часть. Существует четы
ре разных типа диаграмм взаимодействий, каждый из которых делает
акцент на различных аспектах взаимодействия.
Четыре типа диаграмм взаимодействий предоставляют разные проек
ции взаимодействий объектов.
• Диаграммы последовательностей (sequence diagrams) акцентируют
внимание на временной упорядоченности сообщений. Обычно поль
зователи лучше понимают диаграммы последовательностей, чем
коммуникационные диаграммы, поскольку они намного легче чи
таются. Как правило, коммуникационные диаграммы очень быстро
загромождаются. Диаграммы последовательностей обсуждаются
вразделе 12.9.
• Коммуникационные диаграммы (communication diagrams) выделя
ют структурные отношения между объектами и очень полезны при
анализе, особенно для создания эскиза совместной работы объек
тов. В UML 2 эти диаграммы предлагают только лишь подмножест
во функциональности диаграмм последовательностей. Коммуника
ционные диаграммы обсуждаются в разделе 12.11.
• Диаграммы обзора взаимодействий (interaction overview diagrams)
показывают, как сложное взаимодействие реализуется рядом прос
тых взаимодействий. Это особый случай диаграммы деятельности,
в которой узлы ссылаются на другие взаимодействия. Они полезны
для моделирования потока управления системы. Диаграммы обзо
ра взаимодействий обсуждаются в разделе 15.12.
• Временные диаграммы (timing diagrams) обращают внимание на
фактическое время взаимодействия. Их основное назначение – по
мочь оценить временные затраты. Временные диаграммы рассмат
риваются в разделе 20.7.
12.9. Диаграммы последовательностей 275
Диаграммы последовательностей и коммуникационные диаграммы
являются самыми важными с точки зрения реализации прецедентов.
Оставшаяся часть этой главы посвящена их детальному обсуждению.
12.9. Диаграммы последовательностей
Диаграммы последовательностей представляют взаимодействия меж
ду линиями жизни как упорядоченную последовательность событий.
Это самая богатая и гибкая форма диаграммы взаимодействий.
Диаграммы последовательностей представляют взаимодействия между
линиями жизни как упорядоченную последовательность событий.
Иногда моделирование начинают с создания эскиза реализации преце
дента с помощью коммуникационной диаграммы (раздел 12.11), пото
му что на диаграмме легко размещать и соединять линии жизни. Од
нако если необходимо сфокусировать внимание на установлении фак
тической последовательности событий, удобнее работать с диаграм
мой последовательностей.
12.9.1. Линии жизни и сообщения
Чтобы разобраться с линиями жизни и сообщениями, возьмем пример
из простой системы регистрации курсов. Рассмотрим реализацию пре
цедента AddCourse (добавить курс) (рис. 12.6). Чтобы пример был прос
тым, сохранен очень высокий уровень абстракции этого прецедента.
Прецедент: AddCourse
Главные актеры:
Registrar
Предусловия:
1. Registrar вошел в систему.
Постусловия:
1. Новый курс добавлен в систему.
Основной поток:
1. Registrar выбирает «add course».
2. Registrar вводит имя нового курса.
3. Система создает новый курс.
Альтернативные потоки:
CourseAlreadyExists
ID: 8
Краткое описание:
Добавляет детали нового курса в систему.
Второстепенные актеры:
Нет.
Рис. 12.6. Спецификация прецедента AddCourse
276 Глава 12. Реализация прецедентов
Исходный анализ созданного прецедента представлен на рис. 12.7 в ви
де высокоуровневой диаграммы классов анализа. Спецификация пре
цедента и диаграмма классов обеспечивают объем информации, доста
точный для создания диаграммы последовательностей.
На рис. 12.8 показана диаграмма последовательностей, реализующая
поведение, описанное прецедентом AddCourse. Согласно спецификации
UML 2, имена диаграмм взаимодействий могут начинаться с пристав
ки sd, для обозначения того, что данная диаграмма является диаграм
мой взаимодействий. Довольно странно: sd используется для всех ти
пов диаграмм взаимодействий, а не только для диаграмм последова
тельностей (sd – sequence diagram)!
На данном этапе следует напомнить, что при создании диаграмм после
довательностей как части реализации прецедента может обнаружить
ся необходимость доработки диаграммы классов анализа или даже
прецедента. Это нормально, т. к. все это – часть процесса анализа.
RegistrationManager
Course
1 0..*
courses
Student
1 0..*
students
registration
0..*
0..*
Рис. 12.7. Диаграмма классов анализа прецедента AddCourse
:Registrar
:RegistrationManager
uml:Course
addCourse( "UML" )
«create»
из примечаний может
быть образован «сценарий»,
описывающий поток
линия жизни
sd AddCourse
сообщение создания объекта
синхронное
сообщение
объект создается
в данной точке
сообщения
возврата
активация
The Registrar selects
"add course".
The system creates
the new Course.
Рис. 12.8. Диаграмма последовательностей прецедента AddCourse
12.9. Диаграммы последовательностей 277
Прецедент, диаграмма классов анализа и диаграмма последовательно
стей – все они вместе эволюционируют со временем.
Рассмотрим диаграмму последовательностей, приведенную на рис. 12.8.
Время на диаграммах последовательностей развивается сверху вниз,
линии жизни выполняются слева направо. Линии жизни размещают
ся горизонтально, чтобы минимизировать число пересекающихся ли
ний на диаграмме. Их местоположение относительно вертикальной
оси отражает момент их создания. Пунктирная линия, находящаяся
внизу, показывает существование линии жизни в течение времени.
Диаграммы взаимодействий не являются дословными копиями преце
дента; это иллюстрации того, как классы анализа реализуют поведение
прецедента.
Обратите внимание, что рис. 12.8 показывает реализацию поведения
прецедента, но не является точным представлением каждого его шага.
Это важный момент. В шагах 1 и 2 участвует какойто пользователь
ский интерфейс, которым не занимаются всерьез вплоть до этапа проек
тирования, поэтому на диаграмме последовательностей он опущен.
Слой пользовательского интерфейса, который помогает прояснить не
которые вещи, может быть добавлен в диаграмму последовательностей
во время проектирования (раздел 20.4). В анализе нас интересует толь
ко основное поведение классов анализа.
Давайте рассмотрим другой пример – прецедент DeleteCourse (удалить
курс) из системы регистрации курсов (рис. 12.9).
В данном случае происходит уничтожение объекта. Уничтожение объ
екта обозначается большим крестом, завершающим линию жизни, как
Прецедент: DeleteCourse
Главные актеры:
Registrar
Предусловия:
1. Registrar вошел в систему.
Постусловия:
1. Курс удален из системы.
Основной поток:
1. Registrar выбирает «delete cource».
2. Registrar вводит имя курса.
3. Система удаляет курс.
Альтернативные потоки:
CourseDoesNotExist
ID: 8
Краткое описание:
Удаляет курс из системы.
Второстепенные актеры:
Нет.
Рис. 12.9. Спецификация прецедента DeleteCourse
278 Глава 12. Реализация прецедентов
показано на рис. 12.10. Если момент уничтожения объекта неизвестен
или неважен, линия жизни завершается без креста.
На рис. 12.10 также представлено самоделегирование: линия жизни
объекта посылает сообщение самой себе. Это создает вложенную акти
вацию (см. следующий раздел). Самоделегирование распространено
в ОО системах. Объекты предлагают ряд открытых сервисов (откры
тых операций), которые могут быть вызваны клиентскими объектами.
Но, как правило, они также имеют и закрытые «вспомогательные» опе
рации, разработанные специально для вызова самим объектом. В дан
ном примере линия жизни :RegistrationManager посылает сама себе сооб
щение findCourse( "UML" ), чтобы найти UMLобъект курса, если таковой
существует. Закрытые операции объекта могут быть вызваны только
самим объектом средствами самоделегирования.
12.9.2. Активации
Вытянутые прямоугольники, расположенные на пунктирной линии
под линией жизни, показывают, когда на данной линии жизни нахо
дится фокус управления. Эти прямоугольники называются активаци+
ями, или фокусом управления.
Активации показывают, когда фокус управления располагается в дан
ной линии жизни.
Отметим, что в книге «The Unified Modeling Language Reference Manu
al, Second Edition» [Rumbaugh 1] активация определяется как «термин
UML 1, замененный на термин “описание выполнения”». Однако нигде
в «Unified Modeling Language: Superstructure, version 2.0» [UML2S]
:Registrar
:RegistrationManager uml:Course
deleteCourse( "UML" )
sd DeleteCourse
объект уничтожается
в этот момент
«destroy»
самоделегирование
findCourse( "UML" )
вложенная активация
Рис. 12.10. Самоделегирование
12.9. Диаграммы последовательностей 279
термина «описание выполнения» («execution specification») нам найти
не удалось, тогда как там есть и «активация», и «фокус управления».
Отсюда можно сделать единственный вывод о том, что «активация»
и «фокус управления» являются стандартными терминами. Мы вспом
нили об этом, потому что в литературе может встретиться термин «опи
сание выполнения» как синоним активации, поскольку он включен
в книгу [Rumbaugh 1].
На рис. 12.8 фокус управления сначала находится на актере :Registrar.
Он посылает сообщение addCourse( "UML" ) актеру :RegistrationManager, ко
торый инициирует операцию addCourse(…) с параметром "UML". Во вре
мя выполнения этой операции фокус управления находится у :Registra
tionManager. Однако обратите внимание, что этот фокус управления вло+
жен в фокус управления актера :Registrar. Это вполне нормально – один
объект, имеющий фокус управления, инициирует операцию другого
объекта, создавая вложенный фокус управления. Затем этот объект
может инициировать операцию еще одного объекта, еще более углуб
ляя вложенность фокуса управления, и т. д.
В рамках выполнения операции addCourse(…) актер :RegistrationManager
создает новый объект uml:Course.
В последние годы активации вышли из моды. Многие разработчики
моделей не утруждают себя их отображением. Отчасти это объясняется
плохой поддержкой активаций некоторыми инструментами UML, от
части тем, что обычно активации не так важны, особенно в аналитиче
ских моделях. В исполняющейся ОО системе активации и так просмат
риваются через обычную семантику вызова операции. На практике чи
тать сложные диаграммы последовательностей без активаций может
быть немного проще. Мы используем активации, только если они не
уменьшают читаемость диаграммы.
12.9.3. Документирование диаграмм последовательностей
Одно из замечательных свойств диаграмм последовательностей – воз
можность добавлять в них «сценарии» путем размещения примечаний
в нижней левой части диаграмм (рис. 12.8). Это делает диаграмму на
много более понятной заинтересованным лицам, которые не являются
специалистами в UML, например пользователям или экспертам. Сце
нарий может состоять из фактических шагов прецедента или краткого
обзора того, что происходит на диаграмме, представленного в тексто
вой форме. В любом случае сценарий может быть полезным дополне
нием, особенно если диаграмма сложна.
12.9.4. Инварианты состояния и ограничения
Сообщение, получаемое экземпляром, может обусловить изменение
его состояния.
280 Глава 12. Реализация прецедентов
Состояние определяется как «условие или ситуация в ходе жизни объ
екта, в течение которой он удовлетворяет некоторому условию, осуще
ствляет некоторую деятельность или ожидает некоторое событие»
[Rumbaugh 1]. У каждого классификатора может быть автомат, опи
сывающий жизненный цикл его экземпляров с точки зрения состоя
ний, в которых они могут находиться, и событий, которые обуславли
вают переходы между этими состояниями.
Не все сообщения приводят к изменению состояния. Например, сооб
щение, которое возвращает значение некоторого атрибута и не имеет
никаких побочных действий, никогда не генерирует изменения со
стояния. Состояние экземпляров на линиях жизни объектов можно
показать с помощью инвариантов состояния (state invariants).
Добавление инвариантов состояния на диаграмму последовательно
стей может быть весьма полезным методом анализа, поскольку позво
ляет фиксировать ключевые состояния жизненного цикла линии жиз
ни. Они отражают важные состояния системы и могут быть основой
для автоматов, обсуждаемых в главе 21.
Рассмотрим конкретный пример. На рис. 12.11 показан прецедент из
простой системы обработки заказов, имеющей следующие ограничения:
• заказ должен полностью оплачиваться единовременным платежом;
• позиции, указанные в заказе, могут поставляться только после
оплаты;
Основной поток:
1. Прецедент начинается, когда актер Customer создает новый заказ.
2. Customer полностью оплачивает заказ.
3. Товары доставляются Customer в течение 28 дней после даты окончательного платежа.
Прецедент: ProcessAnOrder
Предусловия:
Нет.
Краткое описание:
Покупатель делает заказ, который затем оплачивается и доставляется.
Постусловия:
1. Заказ оплачен.
2. Товары доставлены в течение 28 дней после окончательного платежа.
Альтернативные потоки:
ExcessPayment
OrderCancelled
GoodsNotDelivered
GoodsDeliveredLate
PartialPayment
ID: 5
Главные актеры:
Customer
Второстепенные актеры:
Нет.
Рис. 12.11. Спецификация прецедента ProcessAnOrder
12.9. Диаграммы последовательностей 281
• позиции доставляются покупателю в течение 28 дней после оплаты.
В реальности процесс обработки заказов обычно намного более слож
ный и гибкий по сравнению с рассматриваемым примером. Тем не менее
пример служит иллюстрацией инвариантов состояний. На рис. 12.12
показана диаграмма последовательностей для ProcessAnOrder (обработка
заказа).
Мы видим, что сразу после создания экземпляр Order переходит в со
стояние unpaid (не оплачено) (изображается в виде прямоугольника со
скругленными углами). Это сообщает о том, что все вновь создаваемые
экземпляры Order находятся в состоянии unpaid. При получении сообще
ния acceptPayment() (принять платеж), которое должно обозначать пол
ную оплату, экземпляр переходит в состояние paid (оплачено). После
этого экземпляр DeliveryManager (менеджер по доставке) посылает сооб
щение deliver() (доставить). Он передает это сообщение экземпляру Order,
что приводит к его переходу в состояние delivered (доставлено).
Если класс Order также имеет автомат, его состояния должны соответ
ствовать всем инвариантам состояний, присутствующим на его диа
граммах последовательностей.
Рисунок 12.12 иллюстрирует применение ограничений. Они записы
ваются в фигурных скобках и размещаются на (или рядом) линиях
жизни. Ограничение, обозначенное на линии жизни, указывает на
чтото, что должно быть истинным для экземпляров, начиная с этого
момента и далее. Ограничения часто формулируются на естественном
языке, хотя в UML есть формальный язык ограничений (OCL), кото
рый обсуждается в главе 25.
На рисунке показано ограничение продолжительности. Линия жизни
объекта :Customer имеет две метки, A и B, и ограничение {B – A <= 28 days}.
:Customer
:Order
:DeliveryManager:OrderManager
«create»
raiseOrder()
acceptPayment()
acceptPayment()
deliver()
deliver()
инвариант состояния
A
B
{B – A <= 28 days}
метка
sd ProcessAnOrder
ограничение
unpaid
paid
delivered
Рис. 12.12. Диаграмма последовательностей прецедента ProcessAnOrder
282 Глава 12. Реализация прецедентов
Это говорит о том, что промежуток времени между точками A и B не
должен превышать 28 дней. Точка A обозначает момент оплаты, а точ
ка B – момент доставки товаров покупателю. На естественном языке
это ограничение означает, что «заказ должен быть доставлен в течение
28 дней после получения платежа».
На линию жизни может быть помещен любой тип ограничения. Широ
ко распространены ограничения значений атрибутов экземпляров.
И наконец, обратите внимание, что на рис. 12.12 не использовались ни
активации, ни возвраты сообщений. Это объясняется тем, что основ
ное внимание данной диаграммы направлено на сроки и инварианты
состояний, и упомянутые характеристики не добавили бы сюда ника
кой полезной информации.
12.10. Комбинированные фрагменты и операторы
Диаграммы последовательностей можно разделить на области, называе
мые комбинированными фрагментами (combined fragments). Рис. 12.13
иллюстрирует довольно богатый синтаксис комбинированного фраг
мента.
Комбинированные фрагменты разделяют диаграмму последовательно
стей на области с различным поведением.
У каждого комбинированного фрагмента есть один оператор (operator),
один или более операндов (operands) и нуль или более сторожевых
условий (guard conditions).
Оператор определяет, как исполняются его операнды.
Оператор определяет, как исполняются его операнды.
[сторожевоеУсловие2]
b( )
c( )
любые сторожевые условия должны
размещаться над первым сообщением операнда
:A :B :C
операнд
a( )
комбинированный фрагмент
операнд
sd OperatorSyntax
имя оператор [сторожевоеУсловие1]
Рис. 12.13. Синтаксис комбинированного фрагмента
12.10. Комбинированные фрагменты и операторы 283
Сторожевые условия определяют, будут ли исполняться эти операн
ды. Сторожевое условие – это логическое выражение, и операнд испол
няется тогда и только тогда, когда это выражение истинно. Одно сторо
жевое условие может применяться ко всем операндам или каждый опе
ранд может иметь собственное уникальное сторожевое условие.
Сторожевые условия определяют, будут ли выполняться данные опе
ранды.
Полный список операторов приведен в табл. 12.3.
Таблица 12.3
Оператор Полное имя Семантика Раздел
opt option Единственный операнд выполняется, если
условие истинно (как if … then).
12.10.1
alt alternatives Выполняется тот операнд, условие которого
истинно. Вместо логического выражения
может использоваться ключевое слово else
(как select … case).
12.10.1
loop loop Имеет специальный синтаксис:
loop min, max [condition]
повторять минимальное количество раз, за
тем, пока условие истинно, повторять еще
(max – min) число раз.
12.10.2
break break Если сторожевое условие истинно, выполня
ется операнд, а не все остальное взаимодей
ствие, в которое он входит.
12.10.2
ref reference Комбинированный фрагмент ссылается на
другое взаимодействие.
13.2
par parallel Все операнды выполняются параллельно. 20.5.2
critical critical Операнд выполняется автоматически без
прерывания.
20.5.2
seq weak
sequencing
Все операнды выполняются параллельно
при условии выполнения следующего огра
ничения: последовательность поступления
событий на одну линию жизни от разных
операндов такая же, как и последователь
ность операндов.
В результате наблюдается слабая форма
упорядочения; отсюда название (weak se
quencing – слабое упорядочение).
12.10
strict strict
sequencing
Операнды выполняются в строгой последо
вательности.
12.10