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

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

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

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

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

Это значит, что многие альтернативныепотоки могут вообще никогда не входить в спецификацию. Для понимания функционирования системы может оказаться вполне достаточным краткое описание альтернативных потоков в виде одной строчки.Это важный момент. Очень легко увязнуть в альтернативных потоках.Не один процесс моделирования прецедентов провалился изза этого.Необходимо помнить, что прецеденты выявляются, чтобы понятьтребуемое поведение системы, а не с целью создания полной моделипрецедентов. Поэтому, когда достигнуто понимание, моделированиепрецедентов должно быть остановлено. Кроме того, поскольку UPявляется итеративным жизненным циклом, всегда можно вернутьсяк прецедентам и доработать их, если возникли некоторые не до концапонятные аспекты поведения системы.114Глава 4.

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

Один прецедентбудет охватывать множество отдельных функциональных требований,и одно функциональное требование может появляться в несколькихразных прецедентах.Надеемся, в вашем распоряжении будут инструменты для моделирования, имеющие поддержку отображения требований. Такие инструментальные средства для выработки требований, как RequisitePro иDOORS позволяют связывать отдельные требования в базе данных требований с конкретными прецедентами, и наоборот. Кстати, UML предоставляет достаточно хорошую поддержку отображения требований.С помощью помеченных значений можно ассоциировать список ID требований с каждым прецедентом.

В инструменте выработки требованийможно связать один или более идентификаторов прецедентов с конкретными требованиями.В случае отсутствия такой поддержки в инструменте для моделирования всю эту работу необходимо выполнять вручную. Для этого полезносоздать матрицу отображаемости требований. Это простая таблицас номерами ID отдельных требований, расположенными по вертикали,и именами прецедентов (и/или номерами ID) – по горизонтали. Вовсех ячейках, где прецедент и требование пересекаются, ставится крестик.

Обычно матрицы прослеживания требований создаются в видеэлектронных таблиц. Пример приведен в табл. 4.2.Таблица 4.2ПрецедентП1ТребованиеТ1П3XXП4XТ2Т3XТ4Т5П2XX4.7. Когда применять моделирование прецедентов115Матрица отображаемости требований – полезный инструмент для проверки согласованности. Если существует требование, не отображающееся ни в один прецедент, значит, упущен прецедент. И наоборот, если есть прецедент, которому не поставлено в соответствие ни одно требование, понятно, что набор требований неполный.С помощью комплекта инструментов SUMR, который обсуждался в разделе 2.2, можно автоматизировать создание матрицы отображаемостипотенциальных требований.

Идея проста: если термин глоссария проекта встречается и в требовании, и в прецеденте, велика вероятностьтого, что они както связаны между собой. Так создается матрица прослеживания предполагаемых требований. Мы говорим «предполагаемых», потому что в результате такого простого текстового анализа могут появиться ошибки и упущения. Эта матрица нуждается в ручнойдоработке. Тем не менее она может существенно сэкономить времяи помочь разработчикам требований решить трудные задачи, которыев противном случае могли бы быть вообще не реализованы.4.7.

Когда применять моделированиепрецедентовПрецеденты хорошо применять для определения функциональности системы. Они плохо подходят для выявления ограничений системы.Прецеденты фиксируют функциональные требования и поэтому не эффективны для систем, в которых доминируют нефункциональные требования.Прецеденты являются лучшим выбором для фиксирования требований в тех случаях, когда:• в системе преобладают функциональные требования;• в системе много типов пользователей, которым она предоставляетразные функциональные возможности (много актеров);• в системе много интерфейсов (много актеров).Прецеденты не стоит применять в тех случаях, когда:• в системе преобладают нефункциональные требования;• в системе мало пользователей;• в системе мало интерфейсов.Примерами систем, для которых не годятся прецеденты, являютсявстроенные (embedded) системы и системы со сложным алгоритмом,но с малым количеством интерфейсов.

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

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

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

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

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

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