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

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

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

Покупатель ввел недействительный адрес электронной почты.Альтернативные потоки:1. Альтернативный поток начинается после шага 2.2 основного потока.2. Система сообщает Покупателю, что он ввел недействительный адресэлектронной почты.Постусловия:Нет.Рис. 4.14. Альтернативный поток InvalidEmailAddress•Актеры – перечислены актеры, принимающие участие в альтернативном потоке.•Предусловия и постусловия – альтернативные потоки могут иметь собственный набор предусловий и постусловий, отличный от набора прецедента. Если альтернативный поток возвращается в основной поток, его постусловия добавляются к постусловиям основного потока.•Альтернативный поток – шаги альтернативного потока.•У альтернативного потока не должно быть альтернативных потоков, иначе описание прецедента становится слишком запутанным.Альтернативные потоки могут быть инициированы тремя разнымиспособами:1.

Альтернативный поток может быть инициирован вместо основногопотока.2. Альтернативный поток может быть инициирован после определен+ного этапа основного потока.3. Альтернативный поток может быть инициирован в любой моментв ходе выполнения основного потока.Если альтернативный поток выполняется вместо основного потока, онинициируется главным актером и полностью замещает весь прецедент.Если альтернативный поток инициируется после определенного этапаосновного потока, он должен начинаться следующим образом:1.

Альтернативный поток начинается после шага X основного потока.112Глава 4. Моделирование прецедентовАльтернативный поток: CreateNewCustomerAccount:CancelID: 5.2Краткое описание:Покупатель отменяет процесс создания учетной записи.Главные актеры:ПокупательВторостепенные актеры:Нет.Предусловия:Нет.Альтернативные потоки:1. Альтернативный поток начинается в любой момент времени.2. Покупатель отменяет создание учетной записи.Постусловия:1.

Новая учетная запись не была создана для Покупателя.Рис. 4.15. Альтернативный поток CancelТакой поток – это форма ветвления. Она отличается от рассматриваемого в разделе 4.5.6.1 тем, что является значительным отклонениемот основного потока и может в него больше не вернуться.Если альтернативный поток может быть инициирован в любой моментво время выполнения основного потока, начинать его надо следующимобразом:1. Альтернативный поток начинается в любой момент времени.Такие альтернативные потоки используются для моделирования того,что может произойти в любой точке основного потока до заключительного этапа. Например, в прецеденте CreateNewCustomerAccount Customerможет отменить создание учетной записи в любой момент.

Поток Cancelможно задокументировать, как показано на рис. 4.15.Если альтернативный поток должен вернуться в основной, можно воспользоваться следующей формой записи:N. Альтернативный поток возвращается на шаг M основного потока.В этом примере альтернативный поток выполняет свой последнийэтап N и продолжается выполнение основного потока с этапа M.4.5.7.1. Выявление альтернативных потоковЧтобы выявить альтернативные потоки, нужно внимательно изучитьосновной поток.

На каждом шаге основного потока необходимо искать:•возможные альтернативы основному потоку;•ошибки, которые могут возникнуть в основном потоке;•прерывания, которые могут случиться в конкретной точке основного потока;4.5. Спецификация прецедентов•113прерывания, которые могут произойти в любой точке основного потока.Каждый из перечисленных факторов является возможным источником альтернативного потока.4.5.7.2. Сколько альтернативных потоков?Документируйте только самые важные альтернативные потоки.Как было сказано, в прецеденте всегда есть один основной поток.Однако наряду с основным может быть много альтернативных потоков.

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

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

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

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

Кроме того, поскольку 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) системы и системы со сложным алгоритмом,но с малым количеством интерфейсов.

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

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