Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
12
Реализация прецедентов
12.1. План главы
В этой главе обсуждается процесс реалG294
изации прецедентов, в которых осуществляется моделирование взаи
модействий объектов.
12.2. Деятельность UP: Анализ прецедента
В предыдущих главах было показано, как создается класс анализа –
артефакт деятельности Анализ прецедента. Второй артефакт, получае
мый в результате этой деятельности, – реализация прецедента, как по
казано на рис. 12.2. Входные артефакты этой деятельности рассматри
вались в разделе 8.2.
Аналитическая модель классов – это статическая структура системы,
а реализации прецедентов показывают, как взаимодействуют экземп
ляры классов анализа для осуществления функциональности систе
мы. Это часть динамического представления системы.
Цели разработчика при реализации прецедентов во время фазы анали
за следующие:
• Выяснить, взаимодействие каких классов анализа обеспечивает по
ведение, определенное прецедентом; во время реализации преце
дентов могут быть обнаружены новые классы анализа.
• Выяснить, какими сообщениями должны обмениваться экземпля
ры этих классов для реализации заданного поведения. Как будет
показано в этой главе, это выявит:
• ключевые операции, необходимые классам анализа;
• ключевые атрибуты классов анализа;
• важные отношения между классами анализа.
12.2. Деятельность UP: Анализ прецедента 265
изучаем коммуникационные диаграммы
12.2. Деятельность UP: анализ прецедента
12.3. Что такое
реализации прецедентов?
12.4. Реализация
прецедента – элементы
12.5. Взаимодействия
12.6. Линии жизни
12.7. Сообщения
12.7.1. Синхронные, асинхронные
и сообщения возврата
12.7.2. Сообщения создания и уничтожения
12.7.3. Найденные
и потерянные сообщения
12.8. Диаграммы взаимодействий
12.9. Диаграммы последовательностей
12.9.1. Линии жизни и сообщения
12.9.2. Активации
12.9.3. Документирование диаграмм последовательностей
12.9.4. Инварианты состояния и ограничения
12.10. Комбинированные фрагменты и операторы
12.10.1. Ветвление с помощью
операторов opt и alt
12.12. Что мы узнали
12.10.2. Организация итераций
операторами loop и break
12.11. Коммуникационные диаграммы
12.11.1. Итерация 12.11.2. Ветвление
изучаем реализацию прецедента
изучаем диаграммы последовательностей
Рис. 12.1. План главы
266 Глава 12. Реализация прецедентов
• Скорректировать модель прецедентов, модель требований и классы
анализа, добавив в них информацию, полученную при реализации
прецедентов. Все модели должны быть согласованы и синхронизи
рованы друг с другом.
При реализации прецедентов в процессе анализа важно сосредото
читься на отражении ключевых атрибутов, операций и отношений ме
жду классами анализа. На этом этапе не надо заниматьсятакими дета
лями, как параметры операций. Эта информация будет раскрыта при
проектировании.
Также не надо реализовывать все прецеденты. Необходимо выбрать
и проработать только самые основные. Реализация прецедентов долж
на продолжаться до тех пор, пока разработчик не почувствует, что об
ладает достаточной информацией для понимания совместной работы
классов анализа. Получив необходимый набор информации, останови
тесь. UP – итеративный процесс. Поэтому при необходимости вы смо
жете доработать реализацию прецедентов позже.
По завершении реализации прецедентов в процессе анализа вы полу
чите аналитическую модель, обеспечивающую высокоуровневое пред
ставление динамического поведения системы.
12.3. Что такое реализации прецедентов?
После нахождения классов анализа ключевым моментом в анализе яв
ляется поиск реализаций прецедентов. Они включают наборы классов,
реализующих поведение, определенное в прецеденте. Пусть, к приме
Разработчик прецедентов
Анализ прецедента
Описание архитектуры
Класс анализа
Реализация прецедента
Модель прецедентов
Бизнес!модель
[или модель предметной области]
Модель требований
Рис. 12.2. Два артефакта деятельности Анализ прецедента. Адаптировано
с рис. 8.25 [Jacobson 1] с разрешения издательства Addison+Wesley
12.3. Что такое реализации прецедентов? 267
ру, есть прецедент BorrowBook (взять книгу на время) и идентифициро
ваны классы анализа Book (книга), Ticket (формуляр), Borrower (пользо
ватель библиотеки) и актер Librarian (библиотекарь). Необходимо соз
дать реализацию прецедента, демонстрирующую взаимодействие этих
классов и их объектов, которое направлено на реализацию поведения,
определенного в BorrowBook. Таким образом, прецедент, который явля
ется описанием функциональных требований, превращается в диа
граммы классов и взаимодействий, а это уже высокоуровневое описа
ние системы.
Реализации прецедентов показывают, как взаимодействуют классы,
чтобы реализовать функциональность системы.
Хотя UML предлагает символ для реализаций прецедентов (рис. 12.3),
они редко представляются в моделях явно. Причина состоит в том, что
у каждого прецедента только одна реализация. Таким образом, созда
ние диаграммы реализаций прецедентов не привнесет никакой допол
нительной информации. Соответствующие элементы (табл. 12.1) про
сто добавляются в инструмент моделирования, и реализации преце
дентов становятся неявной частью базы (задним планом) модели.
Реализации прецедентов – это неявная часть базы модели; обычно они
не отображаются на диаграммах.
Таблица 12.1
Элемент Назначение
Диаграммы
классов анализа
Показывают классы анализа, взаимодействующие для реа
лизации прецедента.
Диаграммы
взаимодействий
Показывают взаимодействия определенных экземпляров,
реализующих прецедент; это «моментальные снимки» ра
ботающей системы.
Особые
требования
Процесс реализации прецедентов может выявить новые ха
рактерные для прецедента требования; они должны быть
зафиксированы.
Уточнение
прецедентов
Во время реализации может быть обнаружена новая инфор
мация, т. е. происходит обновление исходного прецедента.
Place Order
«trace»
11
зависимость
реализация прецедента
прецедент
«use case realization»
Place Order
Рис. 12.3. Синтаксис реализации прецедента
268 Глава 12. Реализация прецедентов
12.4. Реализация прецедента – элементы
Реализации прецедентов включают элементы, показанные в табл. 12.1.
По сути, реализация прецедента – это процесс уточнения. Вы выбирае
те один из аспектов поведения системы, зафиксированный в прецеден
те и любых ассоциированных с ним требованиях, и моделируете то,
как это все может быть реализовано через взаимодействия экземпля
ров классов анализа, которые были найдены. Тем самым вы проходите
путь от общей спецификации требуемого поведения до довольно под
робного описания взаимодействий между классами и объектами, кото
рые сделают это поведение реальным.
Диаграммы классов анализа «рассказывают историю» об одном или бо
лее прецедентах.
Диаграммы классов анализа – жизненно важная часть реализации
прецедента. Они должны «рассказывать истории» о системе: о том,
как должны быть взаимосвязаны классы, чтобы их экземпляры могли
взаимодействовать для реализации поведения, определенного в одном
или более прецедентах.
Диаграммы взаимодействий показывают, как взаимодействуют экземп
ляры классификаторов для реализации поведения системы.
Кроме диаграмм классов можно создать диаграммы, демонстрирующие
совместную работу и взаимодействие экземпляров этих классов анали
за, направленные на реализацию части или всего поведения прецедента.
Эти диаграммы называют диаграммами взаимодействий. Существует
четыре типа таких диаграмм: диаграммы последовательностей, комму
никационные диаграммы, диаграммы обзора взаимодействий и вре
менные диаграммы. Диаграммы последовательностей и коммуникаци
онные обсуждаются в этой главе, диаграммы обзора взаимодействий –
в разделе 15.12, а временные диаграммы – в разделе 20.7.
ОО моделирование – итеративный процесс. Поэтому не надо удивлять
ся, если при более глубоком моделировании будут выявлены новые
требования или понадобится изменить существующие прецеденты. Все
это – часть реализации прецедентов. Существующие документы долж
ны соответствовать самой последней информации о системе. Необходи
мо обновлять модель прецедентов, модель требований и классы анали
за, чтобы все они были согласованными.
12.5. Взаимодействия
Взаимодействия – это просто единицы поведения классификатора.
Этот классификатор, который называют контекстным классифика+
тором (context classifier), предоставляет контекст взаимодействия.
12.6. Линии жизни 269
Взаимодействие – это единица поведения контекстного классификатора.
Взаимодействие может использовать любую из возможностей своего
контекстного классификатора или любые возможности, к которым
классификатор имеет доступ (например, временные или глобальные
переменные).
В реализации прецедента контекстным классификатором является
прецедент. Создается одно или более взаимодействий, чтобы показать,
как экземпляры классификаторов (в данном случае классов анализа),
обмениваясь сообщениями, могут реализовать определенное преце
дентом поведение.
В ходе работы над диаграммами взаимодействий обнаруживается все
больше и больше операций и атрибутов классов анализа. Как часть
процесса реализации прецедента должно осуществляться обновление
диаграмм классов анализа этой информацией.
Ключевые элементы диаграмм взаимодействий – линии жизни и сооб
щения. Они подробно рассматриваются в следующих двух разделах.
12.6. Линии жизни
Линия жизни – участник взаимодействия.
Линия жизни (lifeline) представляет одного участника взаимодейст
вия, т. е. она представляет, как экземпляр конкретного классифика
тора участвует во взаимодействии. Синтаксис линии жизни приведен
на рис. 12.4.
У каждой линии жизни есть необязательное имя, тип и необязатель
ный селектор.
• Имя используется для обращения к линии жизни во взаимодейст
вии.
• Тип – имя классификатора, экземпляр которого представляет ли
ния жизни.
• Селектор – логическое условие, которое может использоваться для
выбора единственного экземпляра, удовлетворяющего этому усло
вию. Если селектора нет, линия жизни ссылается на произвольный
экземпляр классификатора. Селекторы действительны, только ес
имя селектор тип
jimsAccount [ id = "1234" ] : Account
Рис. 12.4. Синтаксис линии жизни
270 Глава 12. Реализация прецедентов
ли кратность типа больше единицы, т. е. существует множество эк
земпляров, из которых можно выбирать. На рис. 12.4 селектор вы
бирает экземпляр класса Account, id которого – «1234».
Линии жизни изображаются той же пиктограммой, что и их тип, и име
ют вертикальный пунктирный «хвост», когда используются в диа
граммах последовательностей. Некоторые примеры линий жизни при
ведены на рис. 12.5.
Линии жизни представляют, как экземпляр классификатора участвует
во взаимодействии.
Линию жизни объекта можно рассматривать как элемент, который
представляет, как экземпляр классификатора может участвовать во
взаимодействии. Однако она не представляет никакого конкретного
экземпляра классификатора. Это едва различимое, но важное отли
чие. Взаимодействие описывает, как экземпляры классификатора вза
имодействуют в общем, а не выделяет какоето одно конкретное взаи
модействие между рядом конкретных экземпляров. Поэтому можно
считать, что линия жизни объекта представляет роль, которую может
играть во взаимодействии экземпляр классификатора.
Реальные экземпляры можно показать прямо на диаграмме взаимо
действий. Используется обычная нотация для экземпляров: символ
классификатора с именем экземпляра, селектор (если таковой имеет
ся), двоеточие и имя классификатора; все подчеркивается.
Различие между линиями жизни и экземплярами послужило причиной
появления двух разных форм диаграмм взаимодействий. Общая форма
(generic form) диаграммы взаимодействий показывает взаимодействие
между линиями жизни, представляющими произвольные экземпля
ры. Форма экземпляров (instance form) диаграммы взаимодействий
показывает взаимодействие между конкретными экземплярами. Об
щая форма диаграммы является более удобной и часто используемой.
Чтобы взаимодействие было полным, должны быть определены сооб
щения, посылаемые между линиями жизни. Сообщения рассматрива
ются в следующем разделе.
jim:Person :OrderProcessing Orders.jar
имя классификатор
Рис. 12.5. Примеры пиктограмм линии жизни
12.7. Сообщения 271
12.7. Сообщения
Сообщение – это особый вид коммуникации между линиями жизни.
Сообщение представляет особый тип коммуникации между двумя ли
ниями жизни. Такое взаимодействие может включать:
• вызов операции – сообщение вызова;
• создание или уничтожение экземпляра – сообщение создания или
уничтожения;
• отправку сигнала.
Cообщение вызова, получаемое линией жизни, является запросом на
вызов операции, имеющей аналогичную сообщению сигнатуру. Таким
образом, для каждого поступающего на линию жизни сообщения вы
зова в классификаторе этой линии жизни должна существовать соот
ветствующая операция. UML допускает несовпадение (рассинхрониза
цию) сообщений и операций на диаграммах взаимодействий, что обес
печивает возможность динамической и гибкой работы с моделью. Од
нако в ходе дальнейшего анализа сообщения и операции должны быть
синхронизированы.
Когда линия жизни посылает сообщение, в ней находится фокус управ+
ления (focus of control), или активация (activation). По мере развития
взаимодействия во времени активация перемещается между линиями
жизни. Это движение называют потоком управления (flow of control).
Сообщения отображаются в виде стрелок между линиями жизни. Если
линия жизни имеет пунктирный «хвост» (как на диаграммах последо
вательностей), сообщения обычно размещают между пунктирными
линиями. В противном случае сообщения выстраиваются между пик
тограммами линий жизни. В данной книге приводится множество
примеров изображения сообщений. Существует семь типов сообщений
(табл. 12.2).
Таблица 12.2
Синтаксис Имя Семантика
Синхронное
сообщение
Отправитель ожидает завершения выпол
нения сообщения получателем.
Асинхронное
сообщение
Отправитель посылает сообщение и продол
жает исполнение – он не ожидает возврата
от получателя.
Возврат Получатель сообщения возвращает фокус
управления отправителю этого сообщения.
Создание
объекта
Отправитель создает экземпляр классифи
катора, определенного получателем.
aMessage(aParameter)
aMessage(aParameter)
:
A
«create» aMessage()
272 Глава 12. Реализация прецедентов
Таблица 12.2 (продолжение)
12.7.1. Синхронные, асинхронные и сообщения возврата
При синхронном вызове сообщения отправитель ожидает завершения
выполнения получателем запрашиваемой операции. При асинхрон
ном отправитель ничего не ожидает, а переходит к следующему этапу.
Для аналитических моделей различие между синхронными и асин
хронными сообщениями обычно является слишком высоким уровнем
детализации. При анализе нас не интересует глубокая семантика про
цесса обмена сообщениями. Достаточно того факта, что сообщение от
правлено. В этом случае все сообщения можно показывать как синхрон
ные или асинхронные – это на самом деле не важно. Мы предпочитаем
все сообщения отображать как синхронные, потому что это наиболее не
свободный вариант. Синхронные сообщения показывают прямую по
следовательность вызовов операций, тогда как асинхронные сообщения
указывают на возможный параллелизм.
При проектировании различие между синхронными и асинхронными
сообщениями может иметь значение для создания параллельных пото
ков управления.
На уровне анализа реализаций прецедентов сообщение возврата мож
но показывать или не показывать – по желанию разработчика. Обыч
но они не имеют особого значения, и их наносят на диаграмму, только
если это не загромождает ее.
12.7.2. Сообщения создания и уничтожения
В OO анализе обычно нас не интересует конкретная семантика созда
ния или уничтожения объекта, но понимать, что происходит, необхо
димо. Поэтому уделим внимание этому вопросу.
Синтаксис Имя Семантика
Уничтоже
ние объекта
Отправитель уничтожает получателя.
Если у линии жизни есть «хвост», он за
вершается символом X.
Найденное
сообщение
Отправитель сообщения находится вне об
ласти видимости взаимодействия.
Используется, когда необходимо показать
получение сообщения без указания его ис
точника.
Потерянное
сообщение
Сообщение никогда не достигает точки
своего назначения.
Может использоваться для обозначения
состояний ошибки, при которых пропада
ют сообщения.
«destroy»
12.7. Сообщения 273
Сообщение создания объекта обычно изображается как сплошная ли
ния с открытой стрелкой. Создание объекта можно показать с помо
щью сообщения со стереотипом «create» (создать). Или можно послать
конкретное именованное сообщение создания объекта, которое также
может быть обозначено стереотипом «create». В C++, C# или Java опе
рации создания объектов являются специальными операциями, кото
рые называют конструкторами. Имя конструктора совпадает с именем
класса. Конструкторы не имеют возвращаемого значения, они могут
иметь от нуля и более параметров. Например, для создания нового
объекта Account можно было бы послать сообщение Account() и инициа
лизировать его атрибут accountNumber некоторым значением. Однако
конструкторы есть не во всех языках программирования. Например,
в Smalltalk было бы послано сообщение «create» init: accountNumber.
Сообщение уничтожения объекта показывают сплошной линией с от
крытой стрелкой и стереотипом «destroy» (уничтожить). Уничтожение
означает, что экземпляр классификатора, на который ссылается целе
вая линия жизни, больше не доступен для использования. Если у ли
нии жизни есть «хвост», он должен завершаться большим крестом
в точке уничтожения. Для уничтожения объектов нет возвращаемого
значения.
В разных языках программирования семантика уничтожения различ
на. Например, в С++ уничтожение обычно явно обрабатывается про
граммистом, и при уничтожении объекта гарантированно иницииру
ется специальный метод (если он существует), называемый деструкто
ром. Этот метод часто используется для проведения операций очистки,
таких как высвобождение ресурсов, например файлов или соединений
с базой данных. Вызов деструктора высвобождает память, выделен
ную под объект.
В таких языках программирования, как Java и C#, уничтожение объ
ектов обрабатывается виртуальной машиной с помощью механизма под
названием «сборка мусора». Например, если на объект Javaпрограммы
больше не ссылается ни один другой объект, он помечается как готовый
к уничтожению. Уничтожение произойдет в некоторый момент време
ни в соответствии с алгоритмом сборки мусора, но вы не знаете, когда
это случится! У объектов в Java и C# могут быть методы«финализато
ры», которые будут исполняться в момент реального уничтожения, осу
ществляемого сборщиком мусора. Однако использовать этот метод опас
но, потому что мы точно не знаем, когда сборщик мусора вызовет его.
12.7.3. Найденные и потерянные сообщения
Обычно в анализе найденные и потерянные сообщения могут быть
проигнорированы. Мы рассматриваем их здесь в основном для полно
ты обсуждения.
Найденные сообщения могут быть полезны, если необходимо показать
получение сообщения классом, но неизвестно (в данный момент време