UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
108 Глава 4. Моделирование прецедентов Как и ключевое слово Для, Пока используется не часто. Пример приве ден на рис. 4.11. Последовательность структурированных строк после выражения Пока повторяется до тех пор, пока логическое условие, оп ределенное в блоке Пока, не станет ложным. 4.5.7. Моделирование альтернативных потоков У каждого прецедента есть один основной поток и может быть множест во альтернативных потоков. У каждого прецедента есть основной поток и может быть множество альтернативных потоков. Они являются альтернативными путями в прецеденте, которые перехватывают ошибки, ответвления и преры вания основного потока. Как мы видели, спецификация прецедента включает основной поток и список имен альтернативных потоков. Альтернативные потоки часто не возвращаются в основной поток пре цедента. ID: 3 Главные актеры: Покупатель Предусловия: Нет. Основной поток: 1. Прецедент начинается, когда Покупатель выбирает опцию «найти продукт». 2. Система запрашивает у Покупателя критерий поиска. 3. Покупатель вводит запрашиваемый критерий. 4. Система ищет продукты, соответствующие критерию Покупателя. 5. Если система находит соответствующие продукты, тогда 5.1. Для каждого найденного продукта 5.1.1. Система выводит на экран миниатюрное представление продукта. 5.1.2. Система выводит на экран краткое описание продукта. 5.1.3. Система выводит на экран цену продукта. 6. Иначе (Else) 6.1. Система сообщает Покупателю о том, что соответствующие продукты не найдены. Постусловия: Нет. Альтернативные потоки: Нет. Прецедент: FindProduct Краткое описание: Система ищет некоторые продукты на основании критерия поиска, заданного Покупателем, и выводит их на экран для Покупателя. Второстепенные актеры: Нет. Рис. 4.10. Моделирование повторений с помощью ключевого слова «Для» 4.5. Спецификация прецедентов 109 Ключевым моментом является то, что альтернативные потоки часто не возвращаются в основной поток. Это происходит потому, что они обычно обрабатывают ошибки и исключения основного потока и име ют другие постусловия. Альтернативные потоки наглядно представле ны на рис. 4.12. ID: 4 Главные актеры: Покупатель Предусловия: Нет. Основной поток: 1. Прецедент начинается, когда Покупатель выбирает опцию «показать данные о компании». 2. Система выводит на экран веб страницу с данными о компании. 3. Пока Покупатель просматривает данные о компании. 3.1. Система воспроизводит некоторую фоновую мелодию. 3.2. Система отображает специальные предложения в баннере. Постусловия: 1. Система показала данные о компании. 2. Система воспроизвела фоновую мелодию. 3. Система показала специальные предложения. Прецедент: ShowCompanyDetails Краткое описание: Система выводит данные о компании для Покупателя. Альтернативные потоки: Нет. Второстепенные актеры: Нет. Рис. 4.11. Моделирование последовательности действий в потоке событий с помощью ключевого слова «Пока» основной поток альтернативные потоки Прецедент Рис. 4.12. Основной и альтернативные потоки 110 Глава 4. Моделирование прецедентов Альтернативные потоки могут быть задокументированы отдельно или добавляться в конце прецедента. Мы предпочитаем документировать их отдельно. В качестве примера модели прецедента с альтернативными потоками рассмотрим рис. 4.13. Как видим, у этого прецедента три альтернативных потока: InvalidEmail Address (недействительный адрес электронной почты), InvalidPassword (недействительный пароль) и Cancel (отмена). На рис. 4.14 задокумен тирован альтернативный поток InvalidEmailAddress. Обратите внимание, что для ввода альтернативных потоков в шаблон прецедента было внесено несколько изменений: • Имя – для альтернативных потоков используется следующая схема присваивания имен: Альтернативный поток: CreateNewCustomerAccount: InvalidEmailAddress Такое имя говорит о том, что это альтернативный поток InvalidEmail Address для прецедента CreateNewCustomerAccount. • ID – обратите внимание на применение иерархической системы ну мерации для обеспечения связи альтернативного потока с основ ным прецедентом. Основной поток: Прецедент: CreateNewCustomerAccount Предусловия: Нет. Краткое описание: Система создает новую учетную запись для Покупателя. Постусловия: 1. Новая учетная запись создана для Покупателя. Альтернативные потоки: InvalidEmailAddress InvalidPassword Cancel 1. Прецедент начинается, когда Покупатель выбирает опцию «создать новую учетную запись Покупателя». 2. Пока данные Покупателя недействительны. 2.1. Система просит Покупателя ввести его данные, включая адрес электронной почты, пароль и еще раз пароль для подтверждения. 2.2. Система проверяет действительность данных Покупателя. 3. Система создает новую учетную запись для Покупателя. ID: 5 Главные актеры: Покупатель Второстепенные актеры: Нет. Рис. 4.13. Спецификация прецедента с альтернативными потоками 4.5. Спецификация прецедентов 111 • Актеры – перечислены актеры, принимающие участие в альтерна тивном потоке. • Предусловия и постусловия – альтернативные потоки могут иметь собст венный набор предусловий и постусловий, отличный от набора пре цедента. Если альтернативный поток возвращается в основной по ток, его постусловия добавляются к постусловиям основного потока. • Альтернативный поток – шаги альтернативного потока. • У альтернативного потока не должно быть альтернативных пото ков, иначе описание прецедента становится слишком запутанным. Альтернативные потоки могут быть инициированы тремя разными способами: 1. Альтернативный поток может быть инициирован вместо основного потока. 2. Альтернативный поток может быть инициирован после определен ного этапа основного потока. 3. Альтернативный поток может быть инициирован в любой момент в ходе выполнения основного потока. Если альтернативный поток выполняется вместо основного потока, он инициируется главным актером и полностью замещает весь прецедент. Если альтернативный поток инициируется после определенного этапа основного потока, он должен начинаться следующим образом: 1. Альтернативный поток начинается после шага X основного потока. Альтернативные потоки: Альтернативный поток: CreateNewCustomerAccount:InvalidEmailAddress Предусловия: 1. Покупатель ввел недействительный адрес электронной почты. Главные актеры: Покупатель Постусловия: Нет. 1. Альтернативный поток начинается после шага 2.2 основного потока. 2. Система сообщает Покупателю, что он ввел недействительный адрес электронной почты. ID: 5.1 Краткое описание: Система сообщает Покупателю, что он ввел недействительный адрес электронной почты. Второстепенные актеры: Нет. Рис. 4.14. Альтернативный поток InvalidEmailAddress 112 Глава 4. Моделирование прецедентов Такой поток – это форма ветвления. Она отличается от рассматривае мого в разделе 4.5.6.1 тем, что является значительным отклонением от основного потока и может в него больше не вернуться. Если альтернативный поток может быть инициирован в любой момент во время выполнения основного потока, начинать его надо следующим образом: 1. Альтернативный поток начинается в любой момент времени. Такие альтернативные потоки используются для моделирования того, что может произойти в любой точке основного потока до заключитель ного этапа. Например, в прецеденте CreateNewCustomerAccount Customer может отменить создание учетной записи в любой момент. Поток Cancel можно задокументировать, как показано на рис. 4.15. Если альтернативный поток должен вернуться в основной, можно вос пользоваться следующей формой записи: N. Альтернативный поток возвращается на шаг M основного потока. В этом примере альтернативный поток выполняет свой последний этап N и продолжается выполнение основного потока с этапа M. 4.5.7.1. Выявление альтернативных потоков Чтобы выявить альтернативные потоки, нужно внимательно изучить основной поток. На каждом шаге основного потока необходимо искать: • возможные альтернативы основному потоку; • ошибки, которые могут возникнуть в основном потоке; • прерывания, которые могут случиться в конкретной точке основно го потока; Альтернативные потоки: 1. Альтернативный поток начинается в любой момент времени. 2. Покупатель отменяет создание учетной записи. Альтернативный поток: CreateNewCustomerAccount:Cancel Предусловия: Нет. Главные актеры: Покупатель Постусловия: 1. Новая учетная запись не была создана для Покупателя. ID: 5.2 Краткое описание: Покупатель отменяет процесс создания учетной записи. Второстепенные актеры: Нет. Рис. 4.15. Альтернативный поток Cancel 4.5. Спецификация прецедентов 113 • прерывания, которые могут произойти в любой точке основного по тока. Каждый из перечисленных факторов является возможным источни ком альтернативного потока. 4.5.7.2. Сколько альтернативных потоков? Документируйте только самые важные альтернативные потоки. Как было сказано, в прецеденте всегда есть один основной поток. Однако наряду с основным может быть много альтернативных пото ков. Вопрос: «Сколько?» Надо свести число альтернативных потоков до необходимого минимума. Есть две стратегии. • Выбрать самые важные альтернативные потоки и задокументиро вать только их. • Если существуют группы очень сходных альтернативных потоков, документировать один из них как образец и (если необходимо) до бавить примечания, объясняющие, чем остальные потоки отлича ются от образца. Вернемся к аналогии с дельтой реки. Помимо основного рукава в дель те может образоваться много ветвящихся и извилистых альтернатив ных рукавов. Нанести на карту все рукава невозможно, поэтому выби раются только наиболее заметные. Также многие из этих ответвлений направлены практически в одну сторону и имеют лишь небольшие от личия. Поэтому можно подробно изобразить на карте только один ру кав и составить примечания, объясняющие, чем отличаются осталь ные меньшие рукава. В этом состоит рациональный и эффективный способ моделирования сложного прецедента. Основной принцип в моделировании прецедентов – обеспечить необхо димый минимум информации. Это значит, что многие альтернативные потоки могут вообще никогда не входить в спецификацию. Для пони мания функционирования системы может оказаться вполне достаточ ным краткое описание альтернативных потоков в виде одной строчки. Это важный момент. Очень легко увязнуть в альтернативных потоках. Не один процесс моделирования прецедентов провалился из за этого. Необходимо помнить, что прецеденты выявляются, чтобы понять требуемое поведение системы, а не с целью создания полной модели прецедентов. Поэтому, когда достигнуто понимание, моделирование прецедентов должно быть остановлено. Кроме того, поскольку UP является итеративным жизненным циклом, всегда можно вернуться к прецедентам и доработать их, если возникли некоторые не до конца понятные аспекты поведения системы. 114 Глава 4. Моделирование прецедентов 4.6. Отображение требований При отображении требований устанавливаются взаимосвязи между мо делью требований и моделью прецедентов. Модель требований и модель прецедентов фактически обеспечивают две «базы данных» функциональных требований. Важно сопоставить эти две модели, чтобы выяснить, нет ли в одной из них чего то, что не охвачено в другой, и наоборот. Такая постановка вопроса – один из ас пектов отображения требований. Отображение функциональных требований осложняется тем фактом, что между отдельными функциональными требованиями и прецеден тами установлены отношения «многие ко многим». Один прецедент будет охватывать множество отдельных функциональных требований, и одно функциональное требование может появляться в нескольких разных прецедентах. Надеемся, в вашем распоряжении будут инструменты для моделиро вания, имеющие поддержку отображения требований. Такие инстру ментальные средства для выработки требований, как RequisitePro и DOORS позволяют связывать отдельные требования в базе данных тре бований с конкретными прецедентами, и наоборот. Кстати, UML пре доставляет достаточно хорошую поддержку отображения требований. С помощью помеченных значений можно ассоциировать список ID тре бований с каждым прецедентом. В инструменте выработки требований можно связать один или более идентификаторов прецедентов с кон кретными требованиями. В случае отсутствия такой поддержки в инструменте для моделирова ния всю эту работу необходимо выполнять вручную. Для этого полезно создать матрицу отображаемости требований. Это простая таблица с номерами ID отдельных требований, расположенными по вертикали, и именами прецедентов (и/или номерами ID) – по горизонтали. Во всех ячейках, где прецедент и требование пересекаются, ставится кре стик. Обычно матрицы прослеживания требований создаются в виде электронных таблиц. Пример приведен в табл. 4.2. Таблица 4.2 Прецедент П 1 П 2 П 3 П 4 Тр еб ов ани е Т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 – Выявление актеров и прецедентов и Детали зация прецедента. • Моделирование прецедентов – еще одна форма выработки требова ний, которая происходит следующим образом: • выявление контекста; • выявление актеров; • выявление прецедентов. • Контекст системы определяет, что является частью системы, а что находится вне системы. • Актеры – это роли, выполняемые сущностями, внешними по отно шению к системе, которые взаимодействуют непосредственно с сис темой. • Выявить актеров можно, выяснив, кто или что использует или взаимодействует непосредственно с системой. • Часто время является актером. • Прецеденты – это функции, осуществляемые системой с точки зре ния конкретных актеров; их цель – принести пользу этим актерам. Для выявления прецедентов необходимо выяснить, как каждый актер взаимодействует с системой. • Прецеденты можно выявить, рассмотрев, какие функциональ ные возможности система предлагает актерам. • Прецеденты всегда инициируются актером. • Прецеденты всегда пишутся с точки зрения актеров. • На диаграмме прецедентов отражены: • контекст; • актеры; • прецеденты; • взаимодействия. • Глоссарий проекта предоставляет определения ключевых бизнес терминов, включает синонимы и омонимы. |