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

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

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

Однако если необходимо сфокусировать внимание на установлении фактической последовательности событий, удобнее работать с диаграммой последовательностей.12.9.1. Линии жизни и сообщенияЧтобы разобраться с линиями жизни и сообщениями, возьмем примериз простой системы регистрации курсов. Рассмотрим реализацию прецедента AddCourse (добавить курс) (рис. 12.6). Чтобы пример был простым, сохранен очень высокий уровень абстракции этого прецедента.Прецедент: AddCourseID: 8Краткое описание:Добавляет детали нового курса в систему.Главные актеры:RegistrarВторостепенные актеры:Нет.Предусловия:1.

Registrar вошел в систему.Основной поток:1. Registrar выбирает «add course».2. Registrar вводит имя нового курса.3. Система создает новый курс.Постусловия:1. Новый курс добавлен в систему.Альтернативные потоки:CourseAlreadyExistsРис. 12.6. Спецификация прецедента AddCourse276Глава 12.

Реализация прецедентовRegistrationManager10..*Coursecourses0..*registration0..*10..*StudentstudentsРис. 12.7. Диаграмма классов анализа прецедента AddCourseИсходный анализ созданного прецедента представлен на рис. 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]. У каждого классификатора может быть автомат, описывающий жизненный цикл его экземпляров с точки зрения состояний, в которых они могут находиться, и событий, которые обуславливают переходы между этими состояниями.Не все сообщения приводят к изменению состояния.

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

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