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

Для моделирования таких систем намного лучше воспользоваться более традиционными методамивыработки требований. Главное – правильно выбрать инструментальное средство.116Глава 4. Моделирование прецедентов4.8. Что мы узналиЭта глава была посвящена определению требований, предъявляемыхк системе, путем моделирования прецедентов.

Мы узнали следующее.•Деятельность по моделированию прецедентов является частью рабочего потока определения требований.•Большая часть работы в рабочем потоке определения требованийосуществляется в фазах Начало и Уточнение жизненного цикла UPпроекта.•Основные деятельности UP – Выявление актеров и прецедентов и Детализация прецедента.•Моделирование прецедентов – еще одна форма выработки требований, которая происходит следующим образом:•выявление контекста;•выявление актеров;•выявление прецедентов.•Контекст системы определяет, что является частью системы, а чтонаходится вне системы.•Актеры – это роли, выполняемые сущностями, внешними по отношению к системе, которые взаимодействуют непосредственно с системой.••••Выявить актеров можно, выяснив, кто или что использует иливзаимодействует непосредственно с системой.•Часто время является актером.Прецеденты – это функции, осуществляемые системой с точки зрения конкретных актеров; их цель – принести пользу этим актерам.Для выявления прецедентов необходимо выяснить, как каждыйактер взаимодействует с системой.•Прецеденты можно выявить, рассмотрев, какие функциональные возможности система предлагает актерам.•Прецеденты всегда инициируются актером.•Прецеденты всегда пишутся с точки зрения актеров.На диаграмме прецедентов отражены:•контекст;•актеры;•прецеденты;•взаимодействия.Глоссарий проекта предоставляет определения ключевых бизнестерминов, включает синонимы и омонимы.4.8.

Что мы узнали••••••••117Спецификация прецедента включает:• имя прецедента;• уникальный идентификатор;• краткое описание – цель прецедента;• актеров:• главных актеров – инициируют прецедент;• второстепенных актеров – взаимодействуют с прецедентомпосле его инициации.• предусловия – ограничения системы, которые оказывают влияние на выполнение прецедента;• основной поток – последовательность декларативных, упорядоченных во времени шагов прецедента;• постусловия – ограничения системы, возникающие в результатевыполнения прецедента;• альтернативные потоки – список альтернатив основному потоку.Можно сократить число прецедентов, позволив ограниченное количество ветвлений в рамках основного потока событий.

Для этого:• применяйте ключевое слово Если (If) для ветвлений, возникающих на конкретных шагах потока;• ветвления, которые могут возникнуть на любом шаге основногопотока, помещайте в секцию Альтернативный поток в описании прецедента.Повторения в рамках потока можно показать с помощью ключевыхслов:• Для (выражение, описывающее итерации);• Пока (логическое условие).У каждого прецедента есть один основной поток – «идеальный»сценарий, когда все идет так, как запланировано.Более сложные прецеденты могут иметь один или более альтернативных потоков. Это пути в прецеденте, представляющие исключения, ответвления и прерывания.Ключевые альтернативные потоки выявляются путем анализа основного потока и поиска:• альтернатив;• ситуаций, связанных с появлением ошибки;• прерываний.Прецедент необходимо расщеплять на альтернативные потоки,только если это повышает ценность модели.Требования в модели требований могут быть сопоставлены с прецедентами при помощи матрицы отображаемости требований.118Глава 4.

Моделирование прецедентов••Моделирование прецедентов лучше всего подходит для систем, в которых:• преобладают функциональные требования;• много типов пользователей;• много интерфейсов для взаимодействия с другими системами.Моделирование прецедентов меньше подходит для систем, в которых:• преобладают нефункциональные требования;• мало пользователей;• мало интерфейсов.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. Общее поведение вынесено в актера+родителяили системой. Однако хорошим стилем считается делать актерародителя абстрактным для сохранения простоты семантики обобщения.Актерпотомок может использоваться везде, где ожидается актерпредок.Мы увидели, что если два актера одинаково общаются с одним и темже набором прецедентов, их можно обобщить в другом (возможно, абстрактном) актере. Актерыпотомки наследуют роли и отношения с прецедентами от актерародителя. Актерпотомок может использоватьсявместо актерапредка.