UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
90 Глава 4. Моделирование прецедентов Рис. 4.1. План главы 4.3.1. Контекст системы (границы системы) обзор изучаем глоссарий проекта изучаем границы системы изучаем актеров изучаем прецеденты изучаем, как моделировать альтернативные потоки изучаем, как сократить количество прецедентов изучаем, как моделировать повторение в потоке прецедента 4.2. Моделирование прецедентов 4.3. Деятельность UP: выявление актеров и прецедентов 4.4. Деятельность UP: Детализация прецедента 4.5. Спецификация прецедентов 4.5.1. Имя прецедента 4.5.2. ID прецедента 4.5.3. Краткое описание 4.5.4. Актеры 4.5.5. Предусловия и постусловия 4.5.6. Основной поток 4.5.7. Моделирование альтернативных потоков 4.5.7.1. Выявление альтернативных потоков 4.5.7.2. Сколько альтернативных потоков? 4.8. Что мы узнали 4.7. Когда применять моделирование прецедентов 4.6. Отображение требований 4.5.6.5. Ключевое слово Пока (While) 4.5.6.4. Ключевое слово Для (For) 4.5.6.2. Ключевое слово Если (If) 4.5.6.3. Повторение в потоке 4.5.6.1. Ветвление потока 4.3.3.2. Диаграмма прецедентов 4.3.2.2. Время как актер 4.3.3.1. Идентификация прецедентов 4.3.2.1. Идентификация актеров 4.3.4. Глоссарий проекта 4.3.3. Что такое прецеденты? 4.3.2. Что такое актеры? else 4.2. Моделирование прецедентов 91 Помимо схемы с открытым исходным кодом и таблиц стилей мы рабо таем над более гибким подходом под названием SUMR (Simple Use case Markup Restructured – простая реструктурированная разметка преце дентов, произносится «summer»). Это простой язык структурирован ной разметки текстов с открытым исходным кодом для прецедентов и актеров. Примеры схемы SUMR, синтаксические анализаторы и ге нераторы XML и HTML предоставлены на нашем веб сайте, подробнее см. в разделе 2.2. 4.2. Моделирование прецедентов Моделирование прецедентов – это форма выработки требований. В раз деле 3.6 было показано, как создавать модель требований, объединяя функциональные и нефункциональные требования так называемым «традиционным» способом. Моделирование прецедентов – это другой, дополнительный способ выявления и документирования требований. Моделирование прецедентов обычно происходит следующим образом: • Устанавливаются границы потенциальной системы. • Выявляются актеры. • Выявляются прецеденты: • определяется прецедент; • устанавливаются основные альтернативные потоки. • Предыдущие шаги повторяются, пока прецеденты, актеры и грани цы системы не стабилизируются. Обычно начинают с самой общей оценки границ системы, чтобы обо значить область моделирования. Затем все действия осуществляются итеративно и зачастую параллельно. Прецеденты – способ записи требований. Результат этой деятельности – модель прецедентов. В этой модели че тыре компонента: • Граница системы – прямоугольник, очерчивающий прецеденты для обозначения края, или границы, моделируемой системы. В UML 2 эту границу называют контекстом системы (subject). • Актеры – роли, выполняемые людьми или сущностями, исполь зующими систему. • Прецеденты – то, что актеры могут делать с системой. • Отношения – значимые отношения между актерами и прецедента ми. Модель прецедентов является основным источником объектов и клас сов. Это основные исходные данные для моделирования классов. 92 Глава 4. Моделирование прецедентов 4.3. Деятельность UP: Выявление актеров и прецедентов Моделирование прецедентов включает выявление актеров и прецедентов. В этом разделе основное внимание сосредоточено на деятельности Вы явление актеров и прецедентов рабочего потока определения требований (см. раздел 3.4), изображенной на рис. 4.2. В разделе 4.4 мы рассмот рим деятельность Детализация прецедента. Рассмотрим исходные данные для деятельности Выявление актеров и пре цедентов. • Бизнес модель – может быть предоставлена в распоряжение разработ чиков модели системы, но это не всегда выполняется. Если она есть, это превосходный источник для сбора требований. • Модель требований – создание этой модели было описано в главе 3. Эти требования являются хорошим исходным материалом для про цесса моделирования прецедентов. В частности, функциональные требования предложат прецеденты и актеров. Нефункциональные требования – то, о чем надо помнить при создании модели преце дентов. • Список возможностей – это набор потенциальных требований, кото рые могут быть представлены в форме общего описания (vision) проекта или чего либо подобного. Глоссарий проекта Модель прецедентов [в общих чертах] Системный аналитик Выявление актеров и прецедентов Бизнес модель [или модель предметной области] Список возможностей Модель требований Рис. 4.2. Деятельность UP: Выявление актеров и прецедентов. Адаптировано с рис. 7.11 [Jacobson 1] с разрешения издательства Addison Wesley 4.3. Деятельность UP: Выявление актеров и прецедентов 93 В оригинальной работе Джекобсона [Jacobson 1] вместо Модели требова ний (на рис. 4.2 этот прямоугольник затушеван, чтобы обозначить из менение, внесенное в исходный рисунок) присутствовали дополни тельные требования. Сюда были включены требования (обычно не функциональные), не относящиеся ни к одному из конкретных преце дентов. Этот документ являлся, главным образом, вместилищем для всех нефункциональных требований, противоречащих прецедентам. В нашем более устойчивом подходе к выработке требований дополни тельные требования были разбиты на категории и включены в Модель требований в качестве подраздела. 4.3.1. Контекст системы (границы системы) Контекст системы отделяет систему от остального мира. Первое, что необходимо сделать при построении системы, – обозначить ее границы. Иначе говоря, надо определить, что является частью сис темы (находится внутри границ системы) и что находится вне системы (вне ее границ). Это кажется очевидным, но встречается немало проек тов, в которых из за неясности границы системы возникают серьезные проблемы. Точное определение границ системы обычно играет важ ную роль в выявлении функциональных (а иногда и нефункциональ ных) требований. Мы уже были свидетелями того, как неполные и не правильно заданные требования могут стать основной причиной не удач проектов. В UML 2 границу системы называют контекстом сис темы (subject). Этого термина будем придерживаться и мы. Контекст системы определяется тем, кто или что использует систему (т. е. актерами), и тем, какие конкретные преимущества система пред лагает этим актерам (т. е. прецедентами). Контекст изображается в виде прямоугольника с именем системы. Ак теры размещаются вне границ блока, а прецеденты – внутри. В нача ле моделирования прецедентов имеется лишь предварительное пред ставление о том, где находятся границы системы. По мере выявления актеров и прецедентов контекст системы обретает все более четкие очертания. 4.3.2. Что такое актеры? Актеры – это роли, исполняемые сущностями, непосредственно взаимо действующими с системой. Актер определяет роль, которую выполняет некоторая внешняя сущ ность при непосредственном взаимодействии с данной системой. Он может представлять роль пользователя или роль, исполняемую другой 94 Глава 4. Моделирование прецедентов системой или частью аппаратных средств, которые касаются границ системы. В UML 2 актеры могут также представлять другие контексты системы, обеспечивая возможность объединения разных моделей прецедентов. Роль подобна шляпе, которую надевают в определенной ситуации. Для понимания актеров важно понимать концепцию ролей. Роль мож но рассматривать как шляпу, которую надевают в определенной си туации. Сущности могут играть несколько ролей одновременно либо исполнять их последовательно во времени. Это означает, что данная роль может исполняться многими разными сущностями одновременно либо последовательно во времени. Например, если в системе определен актер Customer (покупатель), то эту роль могут исполнять реальные люди – Джим, Ила, Вольфганг, Роланд и многие другие. Эти люди могут играть и другие роли. Напри мер, Роланд может быть и системным администратором (актер System Administrator), и пользователем Customer. Основная ошибка новичков в моделировании прецедентов – смешива ние роли, выполняемой некоторой сущностью в контексте системы, с самой сущностью. Всегда спрашивайте себя: «Какую роль играет эта сущность по отношению к системе?» Так можно выявить общность по ведения разных сущностей и таким образом упростить модель преце дентов. В UML актеры изображаются так, как показано на рис. 4.3. Они могут быть изображены в виде пиктограммы класса с указанием стереотипа « actor» или в виде пиктограммы «анимационный человечек». Допус каются обе формы, но многие разработчики моделей предпочитают ис пользовать «человечка» для тех ролей, которые, скорее всего, будут выполняться людьми, а пиктограммы класса для ролей, которые бу дут играть другие системы. Актеры являются внешними по отношению к системе. Важно осознавать, что актеры всегда являются внешними по отноше нию к системе. Например, покупатель является внешним звеном в сис теме электронной торговли, такой как книжный интернет магазин. Однако интересно отметить, что хотя сами актеры всегда находятся «actor» Customer Customer Рис. 4.3. Варианты изображения актера 4.3. Деятельность UP: Выявление актеров и прецедентов 95 вне системы, системы обычно имеют некоторое внутреннее представ ление одного или более актеров. Например, книжный интернет мага зин сохраняет сведения о большинстве покупателей, содержащие имя, адрес и другую информацию. Это внутреннее представление внешнего актера Customer. Важно четко разобраться в этом различии. Актер Cus tomer является внешним по отношению к системе, но система может обслуживать класс CustomerDetails (информация о покупателе), кото рый является внутренним представлением субъектов, играющих роль актера Customer. 4.3.2.1. Идентификация актеров Для идентификации актеров необходимо ответить на вопросы: кто или что использует систему и какие роли выполняются актерами при взаи модействии с системой. Чтобы выявить роли, которые люди или сущ ности играют во взаимодействии с системой, можно учесть, а затем обобщить примеры конкретных людей и сущностей. Следующие во просы помогут идентифицировать актеров. Чтобы выявить актеров, спросите: «Кто или что использует или взаимо действует с системой?» • Кто или что использует систему? • Какие роли они играю во взаимодействии? • Кто устанавливает систему? • Кто или что запускает и выключает систему? • Кто обслуживает систему? • Какие системы взаимодействуют с данной системой? • Кто или что получает и предоставляет информацию системе? • Происходит ли что нибудь в точно установленное время? При моделировании актеров необходимо помнить следующие моменты. • Актеры всегда являются внешними по отношению к системе, сле довательно, находятся вне вашего контроля. • Актеры взаимодействуют непосредственно с системой – так они по могают в определении контекста системы. • Актеры представляют роли, исполняемые людьми или сущностями по отношению к системе, а не конкретных людей или сущностей. • Один человек или сущность может играть по отношению к системе множество ролей одновременно или последовательно во времени. Например, вы составляете и ведете учебные курсы. С точки зрения системы планирования курсов вы играете две роли: Trainer (инструк тор) и CourseAuthor (автор курса). • У каждого актера должно быть короткое, осмысленное с приклад ной точки зрения имя. 96 Глава 4. Моделирование прецедентов • Каждого актера должно сопровождать краткое описание (одна или две строчки), объясняющее, что данный актер из себя представляет с прикладной точки зрения. • Как и в классах, в обозначении актеров могут быть представлены атрибуты актера и события, которые он может получать. Такие обо значения не часто используются и редко отображаются на диаграм мах прецедентов. Далее в этой книге они не упоминаются. 4.3.2.2. Время как актер Если необходимо смоделировать что то, происходящее с системой в оп ределенный момент времени, но не инициируемое ни одним из акте ров, можно ввести актера под названием Time (время) (рис. 4.4). В каче стве примера приведем автоматическое сохранение резервной копии системы, выполняемое ежедневно вечером. 4.3.3. Что такое прецеденты? В книге «UML Reference Manual» [Rumbaugh 1] прецедент определен как «Описание последовательности действий, включая альтернативные и ошибочные последовательности, которые система, подсистема или класс могут осуществлять, взаимодействуя с внешними актерами». Прецедент описывает поведение, демонстрируемое системой с целью получения значимого результата для одного или более актеров. Прецедент – это что то, что должна делать система по желанию акте ра. Это «вариант использования» системы конкретным актером: • прецеденты всегда инициируются актером; • прецеденты всегда описываются с точки зрения актеров. Обычно прецеденты рассматриваются на уровне системы, но согласно определению они могут применяться также и для описания «варианта использования» подсистемы (части системы) или даже отдельного класса. Прецеденты также могут быть очень эффективными при моде лировании бизнес процессов, хотя данный вопрос не рассматривается в этой книге. На рис. 4.5 показана пиктограмма UML для прецедентов. Имя преце дента может быть написано внутри овала или под ним. Time Рис. 4.4. АктерTime 4.3. Деятельность UP: Выявление актеров и прецедентов 97 4.3.3.1. Идентификация прецедентов Чтобы найти прецедент, надо спросить: «Как каждый из актеров ис пользует систему?» и «Что система делает для каждого актера?» Идентификацию прецедентов лучше всего начать со списка актеров, а затем рассмотреть, как каждый актер собирается использовать сис тему. С помощью такой стратегии можно получить список потенци альных прецедентов. Каждому прецеденту должно быть присвоено ко роткое описательное имя, представляющее собой глагольную группу (в конце концов, прецедент означает «выполнить» что нибудь!). Во время идентификации прецедентов могут обнаружиться некоторые новые актеры. Это нормально. Иногда приходится очень тщательно анализировать функциональность системы, чтобы выявить всех акте ров, причем правильно выявить. Моделирование прецедентов – итеративный процесс, осуществляемый путем поэтапного уточнения. Все начинается с имени прецедента, а детали дополняются позже. Эти детали состоят из исходного кратко го описания, которое уточняется до полной спецификации. Ниже при водится полезный список вопросов, которые можно задавать при иден тификации прецедентов. • Какие функциональные возможности понадобятся конкретному актеру от системы? • Система сохраняет и извлекает информацию? Если да, какой из ак теров инициирует это поведение? • Что происходит, когда система изменяет состояние (например, при запуске и выключении системы)? Кто нибудь из актеров получает при этом уведомление? • Какие либо внешние события оказывают влияние на систему? Как система узнает об этих событиях? • Система взаимодействует с какой либо внешней системой? • Система генерирует какие либо отчеты? 4.3.3.2. Диаграмма прецедентов На диаграмме прецедентов контекст модели прецедентов изображает ся в виде блока с именем контекста. Этот блок является контекстом и, как упоминалось в разделе 4.3.1, он представляет границу системы, GetStatus OnOrder PlaceOrder Рис. 4.5. Пиктограмма прецедента 98 Глава 4. Моделирование прецедентов моделируемую прецедентами. Актеры располагаются вне контекста (они внешние по отношению к системе), а прецеденты, составляющие поведение системы, располагаются внутри контекста (они внутренние по отношению к системе). Это проиллюстрировано на рис. 4.6. Отношение между актером и прецедентом обозначается сплошной лини ей. Это символ ассоциации в UML. Ассоциациям посвящена глава 9. Ас социация между актером и прецедентом показывает, что актер и преце дент каким то образом взаимодействуют. 4.3.4. Глоссарий проекта В глоссариий проекта должна быть отражена бизнес терминология и жаргон. Глоссарий проекта – возможно, один из самых важных артефактов проекта. Любая область деятельности имеет собственный уникальный язык, и основной целью процесса выработки и анализа требований яв ляется понимание и фиксация этого языка. Глоссарий обеспечивает словарь ключевых деловых терминов и определений. Он должен быть понятен всем участникам проекта, включая все заинтересованные сто роны. Кроме определения ключевых терминов глоссарий проекта должен включать синонимы и омонимы. • Синонимы – это разные слова, обозначающие одно и то же. ОО ана литик должен выбрать и придерживаться одного из этих слов (того, которое имеет наиболее широкое применение). Остальные вариан Mail order system PlaceOrder Customer CancelOrder RequestCatalog CheckOrderStatus ShipProduct ShippingCompany Dispatcher актер отношение взаимодействия имя контекста системы граница системы прецедент Рис. 4.6. Диаграмма прецедентов |