Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
5.3. Обобщение прецедентов 123
В обобщении прецедентов дочерние прецеденты представляют более
специализированные формы их родителей. Потомки могут:
• наследовать возможности родительского прецедента;
• вводить новые возможности;
• переопределять (менять) унаследованные возможности.
Дочерний прецедент автоматически наследует все возможности своего
родителя. Однако не все возможности прецедента могут быть переоп
ределены. Ограничения приведены в табл. 5.1.
Таблица 5.1
В UML 1.5 прецеденты имели атрибуты и операции, в UML 2 их нет.
Фактически атрибуты и операции прецедентов не имели особого зна
чения, они редко использовались и редко поддерживались инструмен
тальными средствами UML. Согласно спецификации UML 1.5, опера
ции прецедента даже не могли быть запрошены извне, поэтому трудно
представить, зачем они вообще были нужны.
Итак, как же осуществляется документирование обобщения прецеден
тов в описаниях прецедентов? Спецификация UML по этому поводу
безмолвствует. Однако существует несколько довольно стандартных
методов. Мы предпочитаем использовать простой язык тегов для обо
значения пяти возможностей в дочернем прецеденте. Есть два правила
применения этого метода:
• Каждый номер шага в потомке сопровождается номером эквива
лентного шага родителя, если таковой имеется.
Например: 1. (2.). Некоторый шаг.
• Если шаг потомка переопределяет шаг родителя, его номер сопро
вождается буквой «o» (что значит overridden – переопределенный)
и родительским номером шага. Например: 6. (o6.) Другой шаг.
В табл. 5.2 представлен синтаксис всех пяти возможных вариантов.
На рис. 5.4 показан фрагмент диаграммы прецедентов системы Sales.
Здесь есть родительский прецедент FindProduct (найти продукт) и две
его специализации: FindBook (найти книгу) и FindCD (найти CD).
На рис. 5.5 показано описание родительского прецедента FindProduct.
Обратите внимание на ее очень высокий уровень абстракции.
Возможность прецедента Наследование Добавление Переопределение
Отношение Да Да Нет
Точка расширения Да Да Нет
Предусловие Да Да Да
Постусловие Да Да Да
Шаг основного потока Да Да Да
Альтернативный поток Да Да Да
124 Глава 5. Дополнительные аспекты моделирования прецедентов
Таблица 5.2
Возможность… Пример обозначения
Унаследована без изменений 3. (3.) Покупатель вводит запрашиваемый
критерий.
Унаследована и перенумерована 6.2. (6.1.) Система сообщает Покупателю,
что соответствующие продукты не найдены.
Унаследована и переопределена 1. (о1.) Покупатель выбирает опцию «найти
книгу».
Унаследована, переопределена
и перенумерована
5.2. (о5.1.) Система выводит на экран стра
ницу с данными максимум пяти книг.
Добавлена 6.3. Система повторно выводит на экран
страницу поиска «найти книгу».
Система Sales
FindProduct
FindBook FindCD
Customer
Рис. 5.4. Фрагмент диаграммы прецедентов системы Sales
Прецедент:
FindProduct
Главные актеры:
Customer
Предусловия:
Нет.
Постусловия:
Нет.
Основной поток:
1. Customer выбирает опцию «найти продукт».
2. Система запрашивает у Customer критерий поиска.
3. Customer вводит запрашиваемый критерий.
4. Система ищет продукты, соответствующие критерию от Customer.
5. Если система находит соответствующие продукты
5.1. Система выводит на экран список соответствующих продуктов.
6. Иначе
6.1. Система сообщает Customer о том, что соответствующие продукты не найдены.
ID: 6
Краткое описание:
Customer ищет продукт.
Альтернативные потоки:
Нет.
Второстепенные актеры:
Нет.
Рис. 5.5. Описание родительского прецедента FindProduct
5.3. Обобщение прецедентов 125
Один из дочерних прецедентов, FindBook, показан на рис. 5.6. Здесь де
монстрируется применение нашего стандарта обозначения переопре
деленных или новых возможностей. Как видно из рис. 5.6, дочерний
прецедент FindBook намного более конкретный. В нем более абстракт
ный родитель специализирован для работы с конкретным типом про
дуктов – книгами.
Если в родительском прецеденте нет потока событий или поток событий
не завершен, это абстрактный прецедент. Абстрактные прецеденты до
вольно широко распространены, потому что могут использоваться для
описания поведения на самых высоких уровнях абстракции. Посколь
ку в абстрактных прецедентах поток событий отсутствует или является
неполным, они не могут быть выполнены системой. Вместо потока со
бытий в абстрактных прецедентах используется простое высокоуровне
вое текстовое описание поведения, которое должны реализовать их по
томки. Это описание можно поместить в раздел «Краткое описание».
Как мы уже видели, унаследованные возможности в дочерних преце
дентах показать сложно. Приходится применять определенный язык
тегов или соглашение об обозначениях, что обычно сбивает с толку за
переопределенный
переопределенный
унаследованный без изменений
переопределенный
переопределенный
добавленный
переопределенный и перенумерованный
добавленный
добавленный
унаследованный без изменений
добавленный
перенумерованный
Прецедент: FindBook
Главные актеры:
Customer
Предусловия:
Нет.
Постусловия:
Нет.
Основной поток:
1. (o1.) Customer выбирает опцию «найти книгу».
2. (o2.) Система запрашивает у Customer критерий поиска книги,
включающий автора, название, ISBN или тематику.
3. (3.) Customer вводит запрашиваемый критерий.
4. (o4.) Система ищет книги, соответствующие критерию от Customer.
5. (o5.) Если система находит соответствующие книги.
5.1. Система выводит на экран текущий бестселлер.
5.2. (o5.1.) Система выводит на экран данные по максимум пяти книгам.
5.3. Для каждой книги система выводит название, автора, цену и ISBN.
5.4. Пока есть другие соответствующие запросу книги, система предостав!
ляет Customer опцию для отображения следующей страницы с книгами
.
6. (6.) Иначе
6.1. Система выводит на экран текущий бестселлер.
6.2. (6.1.) Система сообщает Покупателю о том, что соответствующие
книги не найдены.
ID: 7
Краткое описание:
Customer ищет книгу.
Альтернативные потоки:
Нет.
ID родителя: 6
Второстепенные актеры:
Нет.
Рис. 5.6. Описание дочернего прецедента FindBook
126 Глава 5. Дополнительные аспекты моделирования прецедентов
интересованные стороны. Поскольку прецеденты предназначены для
общения с заказчиками, это является серьезной проблемой. Другой
недостаток состоит в том, что приходится вручную изменять таблицу
соответствия между родителями и потомками, если один из них меня
ется. Это утомительно и может приводить к большому числу ошибок.
Одно из решений данной проблемы – ограничить родительский преце
дент так, чтобы в нем не было основного потока, а только краткое опи
сание семантики. Тогда не надо беспокоиться о наследовании или пере
определении. В этом случае с помощью прецедентов можно легко и эф
фективно показать, что один или более прецедентов на самом деле яв
ляются просто особыми вариантами более общего прецедента. Более
общий прецедент позволяет рассматривать систему более абстрактно
и может указать на возможности оптимизации системы ПО.
5.4. Отношение «include»
Иногда в прецедентах присутствует многократное описание одних и тех
же действий. Например, рассмотрим систему Personnel (персонал)
(рис. 5.7). Практически любое действие системы начинается с получе
ния данных о конкретном служащем. Если бы эту последовательность
событий приходилось писать каждый раз, когда необходимы данные
служащего, прецеденты имели бы повторяющиеся части. Отношение
«include», устанавливаемое между прецедентами, позволяет включить
поведение одного прецедента в поток другого прецедента.
Отношение «include» выносит шаги, общие для нескольких прецеден
тов, в отдельный прецедент, который потом включается в остальные.
Включающий прецедент мы называем базовым, а тот прецедент, кото
рый включается, включаемым. Включаемый прецедент предоставляет
поведение своему базовому прецеденту.
В базовом прецеденте необходимо точно указать место, где должно
быть включено поведение включаемого прецедента. Синтаксис и се
мантика отношения «include» немного напоминают вызов функции.
FindEmployeeDetailsViewEmployeeDetails
ChangeEmployeeDetails
DeleteEmployeeDetails
«include»
«include»
Cистема Personnel
базовый прецедент
отношение включения
включаемый
прецедент
«include»
Manager
Рис. 5.7. Отношение «include»
5.5. Отношение «extend» 127
Отношение «include» имеет простую семантику (рис. 5.8). Базовый пре
цедент выполняется до момента включения. Затем выполнение пере
ходит во включаемый прецедент. По завершении включаемого преце
дента управление вновь возвращается в базовый прецедент.
Базовый прецедент является незавершенным без всех его включаемых
прецедентов. Они – неотъемлемые части базового прецедента. Однако
включаемые прецеденты могут быть как полными, так и неполными.
Если включаемый прецедент неполный, он просто содержит часть по
тока событий, которая имеет смысл только тогда, когда включена в со
ответствующий базовый прецедент. Обычно такие прецеденты называ
ют фрагментом поведения. В этом случае говорят, что экземпляр вклю
чаемого прецедента не может быть создан, т. е. он не может быть ини
циирован актерами напрямую. Он может выполняться, только если он
включен в соответствующий базовый прецедент. Однако если включае
мый прецедент полный, он ведет себя как обычный прецедент. Его эк
земпляры могут быть созданы, и он может инициироваться актерами.
Включаемый прецедент приведен на рис. 5.9. Он является неполным
и, следовательно, его экземпляры не могут быть созданы.
5.5. Отношение «extend»
Отношение «extend» – способ введения нового поведения в существую
щий прецедент.
Прецедент: ChangeEmployeeDetails
Второстепенные актеры:
Нет.
Предусловия:
1. Manager входит в систему.
Постусловия:
1. Данные служащего изменены.
Основной поток:
1. include (FindEmployeeDetails).
2. Система выводит данные служащего.
3. Manager меняет данные служащего.
…
ID: 1
Краткое описание:
Manager меняет данные служащего.
Альтернативные потоки:
Нет.
Прецедент: ViewEmployeeDetails
Второстепенные актеры:
Нет.
Предусловия:
1. Manager входит в систему.
Постусловия:
1. Система вывела на экран данные
служащего.
Основной поток:
1. include (FindEmployeeDetails).
2. Система выводит данные служащего.
…
ID: 2
Краткое описание:
Manager просматривает данные служащего.
Альтернативные потоки:
Нет.
Прецедент: DeleteEmployeeDetails
Второстепенные актеры:
Нет.
Предусловия:
1. Manager входит в систему.
Постусловия:
1. Данные служащего удалены.
Основной поток:
1. include (FindEmployeeDetails).
2. Система выводит данные служащего.
3. Manager удаляет данные служащего.
…
ID: 3
Краткое описание:
Manager удаляет данные служащего.
Альтернативные потоки:
Нет.
Главные актеры:
Manager
Главные актеры:
Manager
Главные актеры:
Manager
Рис. 5.8. Семантика отношения «include»
128 Глава 5. Дополнительные аспекты моделирования прецедентов
Отношение «extend» предоставляет возможность ввести новое поведе
ние в существующий прецедент (рис. 5.10). Базовый прецедент пре
доставляет набор точек расширения (extension points) – точек входа,
в которые может быть добавлено новое поведение. А расширяющий
прецедент предоставляет ряд сегментов вставки, которые можно ввести
в базовый прецедент в места, указанные точками входа. Как вскоре бу
дет показано, отношение «extend» может использоваться для того, чтобы
точно указать, какие именно точки расширения базового прецедента
подлежат расширению.
В отношении «extend» любопытно то, что базовый прецедент ничего не
знает о расширяющих прецедентах, он просто предоставляет для них
точки входа. Базовый прецедент абсолютно полон и без расширений.
Это существенно отличает «extend» от отношения «include», где базовые
Issue fine
Borrow book
Librarian
Return book
Find book
«e
xte
n
d»
Cистема Library
базовый прецедент
расширяющий прецедент
отношение
расширения
Рис. 5.10. Отношение «extend»
Прецедент: FindEmployeeDetails
Главные актеры:
Manager
Предусловия:
1. Manager входит в систему.
Постусловия:
1. Система нашла данные служащего.
Основной поток:
1. Manager вводит ID служащего.
2. Система ищет данные служащего.
ID: 4
Краткое описание:
Manager ищет данные служащего.
Альтернативные потоки:
Нет.
Второстепенные актеры:
Нет.
Рис. 5.9. Пример неполного включаемого прецедента
5.5. Отношение «extend» 129
прецеденты остаются неполными без включаемых прецедентов. Более
того, точки расширения на самом деле не вводятся в поток событий ба
зового прецедента; они накладываются поверх потока.
Точки расширения обозначаются в потоке событий базового прецеден
та, как показано на рис. 5.11. Точки расширения также можно пока
зать на диаграмме прецедентов, перечислив их в новой ячейке пикто
граммы базового прецедента.
Обратите внимание на то, что точки расширения в основном потоке не
пронумерованы. Они появляются между пронумерованными шагами
потока. UML явно определяет тот факт, что точки расширения факти
чески существуют в слое поверх основного потока. Следовательно, они
вообще не являются его частью. Этот слой подобен прозрачной пленке,
наложенной поверх основного потока, на которую нанесены точки рас
ширения. Основная идея введения этого слоя – сделать поток базового
прецедента полностью независимым от точек расширения. Иначе го
воря, поток базового прецедента не знает (или не интересуется), в ка
ких точках происходит его расширение. Это позволяет использовать
отношение «extend» для создания произвольных или специальных рас
ширений потока базового прецедента.
При использовании «extend» базовый прецедент выступает в роли мо
дульного каркаса, к которому можно подключать расширения в пред
определенных точках расширения. В примере на рис. 5.11 в базовом
Прецедент: ReturnBook
Второстепенные актеры:
Нет.
Предусловия:
1. Librarian входит в систему.
Постусловия:
1. Книга возвращена.
Основной поток:
1. Librarian вводит ID читателя.
2. Система выводит данные читателя, включая
список взятых им книг.
3. Librarian находит возвращаемую книгу
в списке книг.
точка расширения: overdueBook
4. Librarian возвращает книгу.
…
ID: 9
Краткое описание:
Librarian возвращает взятую книгу.
Альтернативные потоки:
Нет.
IssueFine
точка
расширения
базовый прецедент
расширяющий прецедент
extension point:
overdueBook
имя точки
расширения
Главные актеры:
Librarian
«extend»
extension points
overdueBook
ReturnBook
Рис. 5.11. Обозначение точек расширения
130 Глава 5. Дополнительные аспекты моделирования прецедентов
прецеденте ReturnBook точка расширения overdueBook находится между
шагами 3 и 4 потока событий.
Отношение «extend» предоставляет хороший способ обработки исклю
чительных ситуаций или ситуаций, когда нужен гибкий каркас, по
скольку невозможно предсказать (или просто не известны) все воз
можные расширения.
5.5.1. Расширяющий прецедент
Расширяющие прецеденты обычно не являются полными прецедента
ми, поэтому, как правило, их экземпляр не может быть создан. Обыч
но они состоят всего из одного или нескольких фрагментов поведения,
называемых сегментами вставки. Отношение «extend» определяет точ
ку расширения в базовом прецеденте, в которой будет введен сегмент
вставки. Здесь действуют следующие правила:
• Отношение «extend» должно определять одну или несколько точек
расширения базового прецедента. В противном случае предполага
ется, что отношение «extend» относится ко всем точкам расширения.
• В расширяющем прецеденте должно быть столько же сегментов
вставки, сколько точек расширения определено в отношении
«extend».
• Два расширяющих прецедента могут «расширять» один базовый
прецедент в одной и той же точке расширения. Но в этом случае по
рядок выполнения расширений не определен.
В примере на рис. 5.12 в расширяющем прецеденте всего один сегмент
вставки IssueFine (назначить штраф).
Расширяющий прецедент может также иметь предусловия и постусло
вия. Предусловия должны быть выполнены, в противном случае сег
Расширяющий прецедент: IssueFine
Главные актеры:
Librarian
Сегмент 1 предусловия:
1. Возвращенная книга просрочена.
Сегмент 1 постусловия:
1. Штраф записан в системе.
2. Система распечатала штраф.
Поток сегмента 1:
1. Librarian вводит данные штрафа в систему.
2. Система распечатывает штраф.
ID: 10
Краткое описание:
Сегмент 1: Librarian записывает и распечатывает штраф.
ReturnBook
extension points
overdueBook
IssueFine
extension point: overdueBook
единственная вставка расширяющего
прецедента IssueFine вводится
в точке вставки overdueBook
прецедента ReturnBook
Второстепенные актеры:
Нет.
«extend»
Рис. 5.12. Расширяющий прецедент с одним сегментом вставки
5.5. Отношение «extend» 131
мент не выполняется. Постусловия ограничивают состояние системы
после выполнения сегмента.
У самих расширяющих прецедентов могут быть расширяющие или
включаемые прецеденты. Однако лучше избегать такой вложенности,
поскольку это сильно усложняет систему.
5.5.2. Несколько сегментов вставки
В расширяющем прецеденте может быть несколько сегментов встав
ки. Это полезно в тех случаях, когда не получается полностью реали
зовать расширение в одном сегменте изза того, что необходимо вер
нуться и чтото сделать в основном потоке базового прецедента. Обра
тимся к примеру, изображенному на рис. 5.13. Пусть после записи
и распечатки штрафа выполнение возвращается в основной поток для
обработки других просроченных книг, после чего в точке расширения
payFine (выплатить штраф) должнику предлагается заплатить общую
сумму штрафа. Конечно, такая процедура более эффективна, чем взи
мание платежей по каждому штрафу в отдельности (так произошло
бы, если бы эти два сегмента были сведены в один сегмент IssueFine).
При создании расширяющих прецедентов с несколькими сегментами
необходимо четко нумеровать каждый сегмент, как показано на
рис. 5.13, поскольку здесь важен порядок сегментов: первый сегмент
Расширяющий прецедент: IssueFine
Второстепенные актеры:
Нет.
Сегмент 1 предусловия:
1. Возвращенная книга просрочена.
Сегмент 1 постусловия:
1. Штраф записан в системе.
2. Система распечатала штраф.
Поток сегмента 1:
1. Librarian вводит данные штрафа в систему.
2. Система распечатывает штраф.
ID: 10
Краткое описание:
Сегмент 1: Librarian записывает и распечатывает штраф.
Сегмент 2: Librarian принимает платеж по штрафу.
ReturnBook
extension points
overdueBook
payFine
IssueFine
extension points: overdueBook, payFine
первый сегмент расширяющего
прецедента IssueFine вводится в точке
расширения overdueBook, а второй
сегмент – в точке payFine
Сегмент 2 предусловия:
1. Штраф взыскан с должника.
Сегмент 2 постусловия:
1. Штраф зарегистрирован как выплаченный.
2. Система распечатала квитанцию об уплате штрафа.
Поток сегмента 2:
1. Librarian принимает платеж по штрафу от должника.
2. Librarian вводит выплаченный штраф в систему.
3. Librarian распечатывает квитанцию об уплате штрафа.
Главные актеры:
Librarian
«extend»
Рис. 5.13. Расширяющий прецедент с двумя сегментами вставки
132 Глава 5. Дополнительные аспекты моделирования прецедентов
вставляется в первой точке расширения и т. д. Поэтому надо очень ак
куратно записывать сегменты в правильном порядке, а затем придер
живаться его.
5.5.3. Условные расширения
Пример на рис. 5.14 демонстрирует другой, более гуманный подход
к должнику: если он впервые задержал книгу, выдается предупрежде
ние, а штраф выписывается только при повторном нарушении правил.
Это можно смоделировать путем добавления нового расширяющего
прецедента IssueWarning (выдать предупреждение) и введения условий
вотношения «extend». Условия (conditions) – это логические выраже
ния. Вставка осуществляется только в том случае, если выражение
истинно.
Обратите внимание, что расширяющий прецедент IssueWarning вводит
ся только в точке расширения overdueBook (просроченная книга). Одна
ко (как и ранее) расширяющий прецедент IssueFine вводится и в точке
ReturnBook
extension points
overdueBook
payFine
condition: {первое нарушение}
extension points:
overdueBook
IssueWarning
условие
condition: {!первое нарушение}
extension points:
overdueBook, payFine
IssueFine
«extend» «extend»
Рис. 5.14. Добавление условного расширяющего прецедента
Расширяющий прецедент: IssueWarning
Второстепенные актеры:
Нет.
Сегмент 1 предусловия:
1. Возвращенная книга просрочена.
Сегмент 1 постусловия:
1. Предупреждение записано в системе.
Поток сегмента 1:
1. Librarian вводит данные предупреждения в систему.
ID: 11
Краткое описание:
Сегмент 1: Librarian выдает предупреждение.
Главные актеры:
Librarian
Рис. 5.15. Описание условного расширяющего прецедента