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

Подождите немного. Документ загружается.

4.5. Спецификация прецедентов 113

• прерывания, которые могут произойти в любой точке основного по

тока.

Каждый из перечисленных факторов является возможным источни

ком альтернативного потока.

4.5.7.2. Сколько альтернативных потоков?

Документируйте только самые важные альтернативные потоки.

Как было сказано, в прецеденте всегда есть один основной поток.

Однако наряду с основным может быть много альтернативных пото

ков. Вопрос: «Сколько?» Надо свести число альтернативных потоков

до необходимого минимума. Есть две стратегии.

• Выбрать самые важные альтернативные потоки и задокументиро

вать только их.

• Если существуют группы очень сходных альтернативных потоков,

документировать один из них как образец и (если необходимо) до

бавить примечания, объясняющие, чем остальные потоки отлича

ются от образца.

Вернемся к аналогии с дельтой реки. Помимо основного рукава в дель

те может образоваться много ветвящихся и извилистых альтернатив

ных рукавов. Нанести на карту все рукава невозможно, поэтому выби

раются только наиболее заметные. Также многие из этих ответвлений

направлены практически в одну сторону и имеют лишь небольшие от

личия. Поэтому можно подробно изобразить на карте только один ру

кав и составить примечания, объясняющие, чем отличаются осталь

ные меньшие рукава. В этом состоит рациональный и эффективный

способ моделирования сложного прецедента.

Основной принцип в моделировании прецедентов – обеспечить необхо+

димый минимум информации. Это значит, что многие альтернативные

потоки могут вообще никогда не входить в спецификацию. Для пони

мания функционирования системы может оказаться вполне достаточ

ным краткое описание альтернативных потоков в виде одной строчки.

Это важный момент. Очень легко увязнуть в альтернативных потоках.

Не один процесс моделирования прецедентов провалился изза этого.

Необходимо помнить, что прецеденты выявляются, чтобы понять

требуемое поведение системы, а не с целью создания полной модели

прецедентов. Поэтому, когда достигнуто понимание, моделирование

прецедентов должно быть остановлено. Кроме того, поскольку UP

является итеративным жизненным циклом, всегда можно вернуться

к прецедентам и доработать их, если возникли некоторые не до конца

понятные аспекты поведения системы.

114 Глава 4. Моделирование прецедентов

4.6. Отображение требований

При отображении требований устанавливаются взаимосвязи между мо

делью требований и моделью прецедентов.

Модель требований и модель прецедентов фактически обеспечивают

две «базы данных» функциональных требований. Важно сопоставить

эти две модели, чтобы выяснить, нет ли в одной из них чегото, что не

охвачено в другой, и наоборот. Такая постановка вопроса – один из ас

пектов отображения требований.

Отображение функциональных требований осложняется тем фактом,

что между отдельными функциональными требованиями и прецеден

тами установлены отношения «многиекомногим». Один прецедент

будет охватывать множество отдельных функциональных требований,

и одно функциональное требование может появляться в нескольких

разных прецедентах.

Надеемся, в вашем распоряжении будут инструменты для моделиро

вания, имеющие поддержку отображения требований. Такие инстру

ментальные средства для выработки требований, как RequisitePro и

DOORS позволяют связывать отдельные требования в базе данных тре

бований с конкретными прецедентами, и наоборот. Кстати, UML пре

доставляет достаточно хорошую поддержку отображения требований.

С помощью помеченных значений можно ассоциировать список ID тре

бований с каждым прецедентом. В инструменте выработки требований

можно связать один или более идентификаторов прецедентов с кон

кретными требованиями.

В случае отсутствия такой поддержки в инструменте для моделирова

ния всю эту работу необходимо выполнять вручную. Для этого полезно

создать матрицу отображаемости требований. Это простая таблица

с номерами ID отдельных требований, расположенными по вертикали,

и именами прецедентов (и/или номерами ID) – по горизонтали. Во

всех ячейках, где прецедент и требование пересекаются, ставится кре

стик. Обычно матрицы прослеживания требований создаются в виде

электронных таблиц. Пример приведен в табл. 4.2.

Таблица 4.2

Прецедент

Требование

Т1 X

Т2 X X

Т3 X

Т4 X

Т5 X

4.7. Когда применять моделирование прецедентов 115

Матрица отображаемости требований – полезный инструмент для про

верки согласованности. Если существует требование, не отображаю

щееся ни в один прецедент, значит, упущен прецедент. И наоборот, ес

ли есть прецедент, которому не поставлено в соответствие ни одно тре

бование, понятно, что набор требований неполный.

С помощью комплекта инструментов SUMR, который обсуждался в раз

деле 2.2, можно автоматизировать создание матрицы отображаемости

потенциальных требований. Идея проста: если термин глоссария про

екта встречается и в требовании, и в прецеденте, велика вероятность

того, что они както связаны между собой. Так создается матрица про

слеживания предполагаемых требований. Мы говорим «предполагае

мых», потому что в результате такого простого текстового анализа мо

гут появиться ошибки и упущения. Эта матрица нуждается в ручной

доработке. Тем не менее она может существенно сэкономить время

и помочь разработчикам требований решить трудные задачи, которые

в противном случае могли бы быть вообще не реализованы.

4.7. Когда применять моделирование

прецедентов

Прецеденты хорошо применять для определения функциональности сис

темы. Они плохо подходят для выявления ограничений системы.

Прецеденты фиксируют функциональные требования и поэтому не эф

фективны для систем, в которых доминируют нефункциональные тре

бования.

Прецеденты являются лучшим выбором для фиксирования требова

ний в тех случаях, когда:

• в системе преобладают функциональные требования;

• в системе много типов пользователей, которым она предоставляет

разные функциональные возможности (много актеров);

• в системе много интерфейсов (много актеров).

Прецеденты не стоит применять в тех случаях, когда:

• в системе преобладают нефункциональные требования;

• в системе мало пользователей;

• в системе мало интерфейсов.

Примерами систем, для которых не годятся прецеденты, являются

встроенные (embedded) системы и системы со сложным алгоритмом,

но с малым количеством интерфейсов. Для моделирования таких сис

тем намного лучше воспользоваться более традиционными методами

выработки требований. Главное – правильно выбрать инструменталь

ное средство.

116 Глава 4. Моделирование прецедентов

4.8. Что мы узнали

Эта глава была посвящена определению требований, предъявляемых

к системе, путем моделирования прецедентов. Мы узнали следующее.

• Деятельность по моделированию прецедентов является частью ра

бочего потока определения требований.

• Большая часть работы в рабочем потоке определения требований

осуществляется в фазах Начало и Уточнение жизненного цикла UP

проекта.

• Основные деятельности UP – Выявление актеров и прецедентов и Детали

зация прецедента.

• Моделирование прецедентов – еще одна форма выработки требова

ний, которая происходит следующим образом:

• выявление контекста;

• выявление актеров;

• выявление прецедентов.

• Контекст системы определяет, что является частью системы, а что

находится вне системы.

• Актеры – это роли, выполняемые сущностями, внешними по отно

шению к системе, которые взаимодействуют непосредственно с сис

темой.

• Выявить актеров можно, выяснив, кто или что использует или

взаимодействует непосредственно с системой.

• Часто время является актером.

• Прецеденты – это функции, осуществляемые системой с точки зре

ния конкретных актеров; их цель – принести пользу этим актерам.

Для выявления прецедентов необходимо выяснить, как каждый

актер взаимодействует с системой.

• Прецеденты можно выявить, рассмотрев, какие функциональ

ные возможности система предлагает актерам.

• Прецеденты всегда инициируются актером.

• Прецеденты всегда пишутся с точки зрения актеров.

• На диаграмме прецедентов отражены:

• контекст;

• актеры;

• прецеденты;

• взаимодействия.

• Глоссарий проекта предоставляет определения ключевых бизнес

терминов, включает синонимы и омонимы.

4.8. Что мы узнали 117

• Спецификация прецедента включает:

• имя прецедента;

• уникальный идентификатор;

• краткое описание – цель прецедента;

• актеров:

• главных актеров – инициируют прецедент;

• второстепенных актеров – взаимодействуют с прецедентом

после его инициации.

• предусловия – ограничения системы, которые оказывают влия

ние на выполнение прецедента;

• основной поток – последовательность декларативных, упорядо

ченных во времени шагов прецедента;

• постусловия – ограничения системы, возникающие в результате

выполнения прецедента;

• альтернативные потоки – список альтернатив основному потоку.

• Можно сократить число прецедентов, позволив ограниченное коли

чество ветвлений в рамках основного потока событий. Для этого:

• применяйте ключевое слово Если (If) для ветвлений, возникаю

щих на конкретных шагах потока;

• ветвления, которые могут возникнуть на любом шаге основного

потока, помещайте в секцию Альтернативный поток в описании пре

цедента.

• Повторения в рамках потока можно показать с помощью ключевых

слов:

• Для (выражение, описывающее итерации);

• Пока (логическое условие).

• У каждого прецедента есть один основной поток – «идеальный»

сценарий, когда все идет так, как запланировано.

• Более сложные прецеденты могут иметь один или более альтерна

тивных потоков. Это пути в прецеденте, представляющие исключе

ния, ответвления и прерывания.

• Ключевые альтернативные потоки выявляются путем анализа ос

новного потока и поиска:

• альтернатив;

• ситуаций, связанных с появлением ошибки;

• прерываний.

• Прецедент необходимо расщеплять на альтернативные потоки,

только если это повышает ценность модели.

• Требования в модели требований могут быть сопоставлены с преце

дентами при помощи матрицы отображаемости требований.

118 Глава 4. Моделирование прецедентов

• Моделирование прецедентов лучше всего подходит для систем, в ко

торых:

• преобладают функциональные требования;

• много типов пользователей;

• много интерфейсов для взаимодействия с другими системами.

• Моделирование прецедентов меньше подходит для систем, в кото

рых:

• преобладают нефункциональные требования;

• мало пользователей;

• мало интерфейсов.

Дополнительные аспекты

моделирования прецедентов

5.1. План главы

В настоящей главе рассматриваются некоторые дополнительные аспек

ты моделирования прецедентов. И в завершение приводятся несколько

советов и рекомендаций.

Мы обсудим отношения, которые могут возникать между актерами

и актерами и между прецедентами и прецедентами. К ним относятся:

• обобщение актеров – отношение обобщения между обобщенным ак

тером и конкретным актером;

• обобщение прецедентов – отношение обобщения между обобщен

ным прецедентом и специализированным прецедентом;

• «include» (включить) – отношение между прецедентами, которое по

зволяет одному прецеденту включать в себя поведение другого;

• «extend» (расширить) – отношение между прецедентами, которое

позволяет одному прецеденту расширять свое поведение одним или

более фрагментами поведения другого.

Важно сохранять максимальную простоту модели, поэтому эти отно

шения надо применять аккуратно и только там, где они действительно

делают модель прецедентов более понятной. Можно легко увлечься

«include» и «extend», но необходимо избегать этого.

5.2. Обобщение актеров

В примере на рис. 5.2 между двумя актерами, Customer (клиент) и Sales

Agent (торговый агент), можно найти много общего в том, как они взаи

модействуют с системой Sales (товарооборот) (здесь SalesAgent может

управлять куплейпродажей от имени Customer). Оба актера иницииру

ют прецеденты ListProducts (представить список продуктов), OrderProducts

120 Глава 5. Дополнительные аспекты моделирования прецедентов

5.8. Что мы узнали

изучаем отношение «extend»изучаем обобщение актеров изучаем обобщение прецедентов изучаем отношение «include»

5.2. Обобщение актеров 5.3. Обобщение прецедентов 5.4. Отношение «include» 5.5. Отношение «extend»

5.5.1. Расширяющий прецедент

5.5.2. Несколько сегментов вставки

5.5.3. Условные расширения

5.6. Когда использовать дополнительные возможности

5.7. Советы и рекомендации по написанию прецедентов

5.7.1. Делать прецеденты короткими и простыми 5.7.2. Фокусироваться на том что, а не как 5.7.3. Избегать функциональной декомпозиции

Рис. 5.1. План главы

5.2. Обобщение актеров 121

(заказать продукты) и AcceptPayment (принять платеж). По сути, един

ственное отличие между ними в том, что SalesAgent может иницииро

вать прецедент CalculateCommission (вычислить комиссию). Кроме того,

изза сходства поведения этих актеров на диаграмме возникает масса

пересекающихся линий. Это указывает на наличие некоего общего по

ведения, которое может быть вынесено и представлено в виде более

обобщенного актера.

Обобщение актеров выносит поведение, общее для двух или более акте

ров, в актерародителя.

Общее поведение можно вынести путем обобщения актеров (рис. 5.3).

Тем самым мы создаем абстрактного актера, называемого Purchaser (по

купатель), который взаимодействует с прецедентами ListProducts, Order

Products и AcceptPayment. Customer и SalesAgent – это конкретные актеры,

потому что данные роли могут выполнять реальные люди (или другие

системы). Purchaser – абстрактный актер, поскольку он является аб

стракцией, введенной просто для представления общего поведения

(возможности делать покупки) двух конкретных актеров.

Customer и SalesAgent наследуют все роли и отношения с прецедентами

своего абстрактного родителя. Таким образом, как видно из рис. 5.3,

и Customer, и SalesAgent взаимодействуют с прецедентами ListProducts, Or

derProducts и AcceptPayment. Они наследуют это от своего родителя, Pur

chaser. Кроме того, SalesAgent взаимодействует с прецедентом Calculate

Commission. Это поведение не является унаследованным, оно характер

но для актера SalesAgent. Как видим, разумное использование абстракт

ных актеров может упростить диаграмму прецедентов. Это также

упрощает семантику модели прецедентов, потому что появляется воз

можность интерпретировать разные вещи одинаково.

Следует отметить, что актерродитель в обобщении актеров не всегда

абстрактен. Это может быть конкретная роль, исполняемая человеком

OrderProducts

ListProducts

Система Sales

AcceptPayment

CalculateCommission

Customer

SalesAgent

Рис. 5.2. Пример двух актеров с общим поведением

122 Глава 5. Дополнительные аспекты моделирования прецедентов

или системой. Однако хорошим стилем считается делать актерароди

теля абстрактным для сохранения простоты семантики обобщения.

Актерпотомок может использоваться везде, где ожидается актерпредок.

Мы увидели, что если два актера одинаково общаются с одним и тем

же набором прецедентов, их можно обобщить в другом (возможно, аб

страктном) актере. Актерыпотомки наследуют роли и отношения с пре

цедентами от актерародителя. Актерпотомок может использоваться

вместо актерапредка. Это принцип замещаемости, с помощью которо

го можно проверить правильность использования обобщения для лю+

бого классификатора.

В данном примере SalesAgent или Customer могут использоваться вместо

Purchaser везде (т. е. взаимодействовать с прецедентами ListProducts, Or

derProducts и AcceptPayment). Таким образом, обобщение актеров являет

ся правильной стратегией.

5.3. Обобщение прецедентов

Обобщение прецедентов используется, если есть один или более преце

дентов, которые на самом деле являются специализациями более об

щего прецедента. Как и обобщение актеров, этот прием следует приме

нять, только если он упрощает модель прецедентов.

Обобщение прецедентов выносит поведение, общее для одного или бо

лее прецедентов, в родительский прецедент.

Система Sales

Purchaser

SalesAgentCustomer

предок или родитель

потомки или дети

Упрощать можно

с помощью

обобщения актеров!

обобщение

абстрактный актер

ListProducts

OrderProducts

AcceptPayment

CalculateCommission

Рис. 5.3. Общее поведение вынесено в актера+родителя