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

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

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

12.7 в виде высокоуровневой диаграммы классов анализа. Спецификация прецедента и диаграмма классов обеспечивают объем информации, достаточный для создания диаграммы последовательностей.На рис. 12.8 показана диаграмма последовательностей, реализующаяповедение, описанное прецедентом AddCourse. Согласно спецификацииUML 2, имена диаграмм взаимодействий могут начинаться с приставки sd, для обозначения того, что данная диаграмма является диаграммой взаимодействий.

Довольно странно: sd используется для всех типов диаграмм взаимодействий, а не только для диаграмм последовательностей (sd – sequence diagram)!На данном этапе следует напомнить, что при создании диаграмм последовательностей как части реализации прецедента может обнаружиться необходимость доработки диаграммы классов анализа или дажепрецедента. Это нормально, т. к. все это – часть процесса анализа.sd AddCourseлиния жизнисинхронноесообщение:RegistrationManager:Registrarсообщение создания объектаaddCourse( "UML" )The Registrar selects"add course".«create»The system createsthe new Course.из примечаний можетбыть образован «сценарий»,описывающий потокактивациясообщениявозвратаuml:Courseобъект создаетсяв данной точкеРис.

12.8. Диаграмма последовательностей прецедента AddCourse12.9. Диаграммы последовательностей277Прецедент, диаграмма классов анализа и диаграмма последовательностей – все они вместе эволюционируют со временем.Рассмотрим диаграмму последовательностей, приведенную на рис. 12.8.Время на диаграммах последовательностей развивается сверху вниз,линии жизни выполняются слева направо. Линии жизни размещаются горизонтально, чтобы минимизировать число пересекающихся линий на диаграмме. Их местоположение относительно вертикальнойоси отражает момент их создания.

Пунктирная линия, находящаясявнизу, показывает существование линии жизни в течение времени.Диаграммы взаимодействий не являются дословными копиями прецедента; это иллюстрации того, как классы анализа реализуют поведениепрецедента.Обратите внимание, что рис. 12.8 показывает реализацию поведенияпрецедента, но не является точным представлением каждого его шага.Это важный момент. В шагах 1 и 2 участвует какойто пользовательский интерфейс, которым не занимаются всерьез вплоть до этапа проектирования, поэтому на диаграмме последовательностей он опущен.Слой пользовательского интерфейса, который помогает прояснить некоторые вещи, может быть добавлен в диаграмму последовательностейво время проектирования (раздел 20.4).

В анализе нас интересует только основное поведение классов анализа.Давайте рассмотрим другой пример – прецедент DeleteCourse (удалитькурс) из системы регистрации курсов (рис. 12.9).В данном случае происходит уничтожение объекта. Уничтожение объекта обозначается большим крестом, завершающим линию жизни, какПрецедент: DeleteCourseID: 8Краткое описание:Удаляет курс из системы.Главные актеры:RegistrarВторостепенные актеры:Нет.Предусловия:1. Registrar вошел в систему.Основной поток:1.

Registrar выбирает «delete cource».2. Registrar вводит имя курса.3. Система удаляет курс.Постусловия:1. Курс удален из системы.Альтернативные потоки:CourseDoesNotExistРис. 12.9. Спецификация прецедента DeleteCourse278Глава 12. Реализация прецедентовsd DeleteCourse:RegistrationManageruml:Course:RegistrardeleteCourse( "UML" )самоделегированиеfindCourse( "UML" )вложенная активация«destroy»объект уничтожаетсяв этот моментРис. 12.10. Самоделегированиепоказано на рис. 12.10. Если момент уничтожения объекта неизвестенили неважен, линия жизни завершается без креста.На рис. 12.10 также представлено самоделегирование: линия жизниобъекта посылает сообщение самой себе.

Это создает вложенную активацию (см. следующий раздел). Самоделегирование распространенов ОО системах. Объекты предлагают ряд открытых сервисов (открытых операций), которые могут быть вызваны клиентскими объектами.Но, как правило, они также имеют и закрытые «вспомогательные» операции, разработанные специально для вызова самим объектом. В данном примере линия жизни :RegistrationManager посылает сама себе сообщение findCourse( "UML" ), чтобы найти UMLобъект курса, если таковойсуществует.

Закрытые операции объекта могут быть вызваны толькосамим объектом средствами самоделегирования.12.9.2. АктивацииВытянутые прямоугольники, расположенные на пунктирной линиипод линией жизни, показывают, когда на данной линии жизни находится фокус управления. Эти прямоугольники называются активаци+ями, или фокусом управления.Активации показывают, когда фокус управления располагается в данной линии жизни.Отметим, что в книге «The Unified Modeling Language Reference Manual, Second Edition» [Rumbaugh 1] активация определяется как «терминUML 1, замененный на термин “описание выполнения”».

Однако нигдев «Unified Modeling Language: Superstructure, version 2.0» [UML2S]12.9. Диаграммы последовательностей279термина «описание выполнения» («execution specification») нам найтине удалось, тогда как там есть и «активация», и «фокус управления».Отсюда можно сделать единственный вывод о том, что «активация»и «фокус управления» являются стандартными терминами. Мы вспомнили об этом, потому что в литературе может встретиться термин «описание выполнения» как синоним активации, поскольку он включенв книгу [Rumbaugh 1].На рис. 12.8 фокус управления сначала находится на актере :Registrar.Он посылает сообщение addCourse( "UML" ) актеру :RegistrationManager, который инициирует операцию addCourse(…) с параметром "UML".

Во время выполнения этой операции фокус управления находится у :RegistrationManager. Однако обратите внимание, что этот фокус управления вло+жен в фокус управления актера :Registrar. Это вполне нормально – одинобъект, имеющий фокус управления, инициирует операцию другогообъекта, создавая вложенный фокус управления. Затем этот объектможет инициировать операцию еще одного объекта, еще более углубляя вложенность фокуса управления, и т. д.В рамках выполнения операции addCourse(…) актер :RegistrationManagerсоздает новый объект uml:Course.В последние годы активации вышли из моды. Многие разработчикимоделей не утруждают себя их отображением.

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

Документирование диаграмм последовательностейОдно из замечательных свойств диаграмм последовательностей – возможность добавлять в них «сценарии» путем размещения примечанийв нижней левой части диаграмм (рис. 12.8). Это делает диаграмму намного более понятной заинтересованным лицам, которые не являютсяспециалистами в UML, например пользователям или экспертам. Сценарий может состоять из фактических шагов прецедента или краткогообзора того, что происходит на диаграмме, представленного в текстовой форме.

В любом случае сценарий может быть полезным дополнением, особенно если диаграмма сложна.12.9.4. Инварианты состояния и ограниченияСообщение, получаемое экземпляром, может обусловить изменениеего состояния.280Глава 12. Реализация прецедентовСостояние определяется как «условие или ситуация в ходе жизни объекта, в течение которой он удовлетворяет некоторому условию, осуществляет некоторую деятельность или ожидает некоторое событие»[Rumbaugh 1]. У каждого классификатора может быть автомат, описывающий жизненный цикл его экземпляров с точки зрения состояний, в которых они могут находиться, и событий, которые обуславливают переходы между этими состояниями.Не все сообщения приводят к изменению состояния. Например, сообщение, которое возвращает значение некоторого атрибута и не имеетникаких побочных действий, никогда не генерирует изменения состояния. Состояние экземпляров на линиях жизни объектов можнопоказать с помощью инвариантов состояния (state invariants).Добавление инвариантов состояния на диаграмму последовательностей может быть весьма полезным методом анализа, поскольку позволяет фиксировать ключевые состояния жизненного цикла линии жизни.

Они отражают важные состояния системы и могут быть основойдля автоматов, обсуждаемых в главе 21.Рассмотрим конкретный пример. На рис. 12.11 показан прецедент изпростой системы обработки заказов, имеющей следующие ограничения:•заказ должен полностью оплачиваться единовременным платежом;•позиции, указанные в заказе, могут поставляться только послеоплаты;Прецедент: ProcessAnOrderID: 5Краткое описание:Покупатель делает заказ, который затем оплачивается и доставляется.Главные актеры:CustomerВторостепенные актеры:Нет.Предусловия:Нет.Основной поток:1. Прецедент начинается, когда актер Customer создает новый заказ.2. Customer полностью оплачивает заказ.3. Товары доставляются Customer в течение 28 дней после даты окончательного платежа.Постусловия:1.

Заказ оплачен.2. Товары доставлены в течение 28 дней после окончательного платежа.Альтернативные потоки:ExcessPaymentOrderCancelledGoodsNotDeliveredGoodsDeliveredLatePartialPaymentРис. 12.11. Спецификация прецедента ProcessAnOrder28112.9. Диаграммы последовательностей•позиции доставляются покупателю в течение 28 дней после оплаты.В реальности процесс обработки заказов обычно намного более сложный и гибкий по сравнению с рассматриваемым примером. Тем не менеепример служит иллюстрацией инвариантов состояний. На рис. 12.12показана диаграмма последовательностей для ProcessAnOrder (обработказаказа).Мы видим, что сразу после создания экземпляр Order переходит в состояние unpaid (не оплачено) (изображается в виде прямоугольника соскругленными углами).

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

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