Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 24
Текст из файла (страница 24)
Моделирование прецедентов••Моделирование прецедентов лучше всего подходит для систем, в ко торых:• преобладают функциональные требования;• много типов пользователей;• много интерфейсов для взаимодействия с другими системами.Моделирование прецедентов меньше подходит для систем, в кото рых:• преобладают нефункциональные требования;• мало пользователей;• мало интерфейсов.5Дополнительные аспектымоделирования прецедентов5.1. План главыВ настоящей главе рассматриваются некоторые дополнительные аспек ты моделирования прецедентов. И в завершение приводятся несколькосоветов и рекомендаций.Мы обсудим отношения, которые могут возникать между актерамии актерами и между прецедентами и прецедентами.
К ним относятся:• обобщение актеров – отношение обобщения между обобщенным ак тером и конкретным актером;• обобщение прецедентов – отношение обобщения между обобщен ным прецедентом и специализированным прецедентом;• «include» (включить) – отношение между прецедентами, которое по зволяет одному прецеденту включать в себя поведение другого;• «extend» (расширить) – отношение между прецедентами, котороепозволяет одному прецеденту расширять свое поведение одним илиболее фрагментами поведения другого.Важно сохранять максимальную простоту модели, поэтому эти отно шения надо применять аккуратно и только там, где они действительноделают модель прецедентов более понятной. Можно легко увлечься«include» и «extend», но необходимо избегать этого.5.2.
Обобщение актеровВ примере на рис. 5.2 между двумя актерами, Customer (клиент) и SalesAgent (торговый агент), можно найти много общего в том, как они взаи модействуют с системой Sales (товарооборот) (здесь SalesAgent можетуправлять куплей продажей от имени Customer). Оба актера иницииру ют прецеденты ListProducts (представить список продуктов), OrderProductsРис.
5.1. План главы5.7.1. Делать прецеденты короткими и простыми5.2. Обобщение актеровизучаем обобщение актеров5.4. Отношение «include»изучаем отношение «include»5.8. Что мы узнали5.7.2. Фокусироваться на том что, а не как5.7. Советы и рекомендации по написанию прецедентов5.6. Когда использовать дополнительные возможности5.3.
Обобщение прецедентовизучаем обобщение прецедентов5.7.3. Избегать функциональной декомпозиции5.5.3. Условные расширения5.5.2. Несколько сегментов вставки5.5.1. Расширяющий прецедент5.5. Отношение «extend»изучаем отношение «extend»120Глава 5. Дополнительные аспекты моделирования прецедентов1215.2. Обобщение актеровСистема SalesListProductsCustomerOrderProductsAcceptPaymentCalculateCommissionSalesAgentРис. 5.2. Пример двух актеров с общим поведением(заказать продукты) и AcceptPayment (принять платеж). По сути, един ственное отличие между ними в том, что SalesAgent может иницииро вать прецедент CalculateCommission (вычислить комиссию). Кроме того,из за сходства поведения этих актеров на диаграмме возникает массапересекающихся линий.
Это указывает на наличие некоего общего по ведения, которое может быть вынесено и представлено в виде болееобобщенного актера.Обобщение актеров выносит поведение, общее для двух или более актеров, в актерародителя.Общее поведение можно вынести путем обобщения актеров (рис. 5.3).Тем самым мы создаем абстрактного актера, называемого Purchaser (по купатель), который взаимодействует с прецедентами ListProducts, OrderProducts и AcceptPayment. Customer и SalesAgent – это конкретные актеры,потому что данные роли могут выполнять реальные люди (или другиесистемы). Purchaser – абстрактный актер, поскольку он является аб стракцией, введенной просто для представления общего поведения(возможности делать покупки) двух конкретных актеров.Customer и SalesAgent наследуют все роли и отношения с прецедентамисвоего абстрактного родителя.
Таким образом, как видно из рис. 5.3,и Customer, и SalesAgent взаимодействуют с прецедентами ListProducts, OrderProducts и AcceptPayment. Они наследуют это от своего родителя, Purchaser. Кроме того, SalesAgent взаимодействует с прецедентом CalculateCommission.
Это поведение не является унаследованным, оно характер но для актера SalesAgent. Как видим, разумное использование абстракт ных актеров может упростить диаграмму прецедентов. Это такжеупрощает семантику модели прецедентов, потому что появляется воз можность интерпретировать разные вещи одинаково.Следует отметить, что актер родитель в обобщении актеров не всегдаабстрактен. Это может быть конкретная роль, исполняемая человеком122Глава 5. Дополнительные аспекты моделирования прецедентовСистема Salesпредок или родительабстрактный актерListProductsобобщениеPurchaserOrderProductsУпрощать можнос помощьюобобщения актеров!AcceptPaymentCalculateCommissionCustomerSalesAgentпотомки или детиРис.
5.3. Общее поведение вынесено в актера+родителяили системой. Однако хорошим стилем считается делать актера роди теля абстрактным для сохранения простоты семантики обобщения.Актерпотомок может использоваться везде, где ожидается актерпредок.Мы увидели, что если два актера одинаково общаются с одним и темже набором прецедентов, их можно обобщить в другом (возможно, аб страктном) актере. Актеры потомки наследуют роли и отношения с пре цедентами от актера родителя. Актер потомок может использоватьсявместо актера предка. Это принцип замещаемости, с помощью которо го можно проверить правильность использования обобщения для лю+бого классификатора.В данном примере 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.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
