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

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

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

Это принцип замещаемости, с помощью которого можно проверить правильность использования обобщения для лю+бого классификатора.В данном примере SalesAgent или Customer могут использоваться вместоPurchaser везде (т. е. взаимодействовать с прецедентами ListProducts, OrderProducts и AcceptPayment). Таким образом, обобщение актеров является правильной стратегией.5.3. Обобщение прецедентовОбобщение прецедентов используется, если есть один или более прецедентов, которые на самом деле являются специализациями более общего прецедента. Как и обобщение актеров, этот прием следует применять, только если он упрощает модель прецедентов.Обобщение прецедентов выносит поведение, общее для одного или более прецедентов, в родительский прецедент.1235.3. Обобщение прецедентовВ обобщении прецедентов дочерние прецеденты представляют болееспециализированные формы их родителей.

Потомки могут:• наследовать возможности родительского прецедента;• вводить новые возможности;• переопределять (менять) унаследованные возможности.Дочерний прецедент автоматически наследует все возможности своегородителя. Однако не все возможности прецедента могут быть переопределены. Ограничения приведены в табл. 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. Система повторно выводит на экранстраницу поиска «найти книгу».Система SalesFindProductCustomerFindBookFindCDРис. 5.4. Фрагмент диаграммы прецедентов системы SalesПрецедент: FindProductID: 6Краткое описание:Customer ищет продукт.Главные актеры:CustomerВторостепенные актеры:Нет.Предусловия:Нет.Основной поток:1. Customer выбирает опцию «найти продукт».2. Система запрашивает у Customer критерий поиска.3. Customer вводит запрашиваемый критерий.4. Система ищет продукты, соответствующие критерию от Customer.5.

Если система находит соответствующие продукты5.1. Система выводит на экран список соответствующих продуктов.6. Иначе6.1. Система сообщает Customer о том, что соответствующие продукты не найдены.Постусловия:Нет.Альтернативные потоки:Нет.Рис. 5.5. Описание родительского прецедента FindProduct1255.3. Обобщение прецедентовПрецедент: FindBookID: 7ID родителя: 6Краткое описание:Customer ищет книгу.Главные актеры: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.) Система сообщает Покупателю о том, что соответствующиеперенумерованныйкниги не найдены.Постусловия:Нет.Альтернативные потоки:Нет.Рис. 5.6. Описание дочернего прецедента FindBookОдин из дочерних прецедентов, FindBook, показан на рис. 5.6. Здесь демонстрируется применение нашего стандарта обозначения переопределенных или новых возможностей. Как видно из рис. 5.6, дочернийпрецедент FindBook намного более конкретный.

В нем более абстрактный родитель специализирован для работы с конкретным типом продуктов – книгами.Если в родительском прецеденте нет потока событий или поток событийне завершен, это абстрактный прецедент. Абстрактные прецеденты довольно широко распространены, потому что могут использоваться дляописания поведения на самых высоких уровнях абстракции. Поскольку в абстрактных прецедентах поток событий отсутствует или являетсянеполным, они не могут быть выполнены системой. Вместо потока событий в абстрактных прецедентах используется простое высокоуровневое текстовое описание поведения, которое должны реализовать их потомки.

Это описание можно поместить в раздел «Краткое описание».Как мы уже видели, унаследованные возможности в дочерних прецедентах показать сложно. Приходится применять определенный языктегов или соглашение об обозначениях, что обычно сбивает с толку за126Глава 5. Дополнительные аспекты моделирования прецедентовинтересованные стороны. Поскольку прецеденты предназначены дляобщения с заказчиками, это является серьезной проблемой. Другойнедостаток состоит в том, что приходится вручную изменять таблицусоответствия между родителями и потомками, если один из них меняется. Это утомительно и может приводить к большому числу ошибок.Одно из решений данной проблемы – ограничить родительский прецедент так, чтобы в нем не было основного потока, а только краткое описание семантики.

Тогда не надо беспокоиться о наследовании или переопределении. В этом случае с помощью прецедентов можно легко и эффективно показать, что один или более прецедентов на самом деле являются просто особыми вариантами более общего прецедента. Болееобщий прецедент позволяет рассматривать систему более абстрактнои может указать на возможности оптимизации системы ПО.5.4. Отношение «include»Иногда в прецедентах присутствует многократное описание одних и техже действий.

Например, рассмотрим систему Personnel (персонал)(рис. 5.7). Практически любое действие системы начинается с получения данных о конкретном служащем. Если бы эту последовательностьсобытий приходилось писать каждый раз, когда необходимы данныеслужащего, прецеденты имели бы повторяющиеся части. Отношение«include», устанавливаемое между прецедентами, позволяет включитьповедение одного прецедента в поток другого прецедента.Отношение «include» выносит шаги, общие для нескольких прецедентов, в отдельный прецедент, который потом включается в остальные.Включающий прецедент мы называем базовым, а тот прецедент, который включается, включаемым.

Включаемый прецедент предоставляетповедение своему базовому прецеденту.В базовом прецеденте необходимо точно указать место, где должнобыть включено поведение включаемого прецедента. Синтаксис и семантика отношения «include» немного напоминают вызов функции.Cистема Personnelбазовый прецедентChangeEmployeeDetailsViewEmployeeDetailsвключаемыйпрецедент«include»«include»FindEmployeeDetailsde»ManagerDeleteEmployeeDetails«incluотношение включенияРис. 5.7. Отношение «include»1275.5.

Отношение «extend»Прецедент: ChangeEmployeeDetailsПрецедент: ViewEmployeeDetailsПрецедент: DeleteEmployeeDetailsID: 1Краткое описание:Manager меняет данные служащего.ID: 2Краткое описание:Manager просматривает данные служащего.ID: 3Краткое описание:Manager удаляет данные служащего.Главные актеры:ManagerВторостепенные актеры:Нет.Предусловия:1. Manager входит в систему.Основной поток:1. include (FindEmployeeDetails).2. Система выводит данные служащего.3. Manager меняет данные служащего.…Постусловия:1. Данные служащего изменены.Главные актеры:ManagerВторостепенные актеры:Нет.Предусловия:1.

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

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