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

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

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

3.3) показывает, что существуетдва способа представления требований: 1) функциональные и нефункциональные требования и 2) прецеденты и актеры.• Детализация рабочего потока определения требований в UP включает следующие деятельности, представляющие интерес для ООаналитиков и разработчиков:••••Стандартный рабочий поток определения требований в UP расширяется:• актером: Разработчик требований;• деятельностью: Выявление функциональных требований;•••Выявление актеров и прецедентов;Детализация прецедента;Построение модели прецедентов.деятельностью: Выявление нефункциональных требований;деятельностью: Назначение приоритетов требований;• деятельностью: Отображение (trace) требований в прецеденты.Большинство провалов проектов обусловлено недостатками выработки требований.88Глава 3.

Рабочий поток определения требований••••••••Существует два типа требований:• функциональные требования – какое поведение должна предлагать система;• нефункциональные требования – определенное свойство илиограничение, накладываемое на систему.Правильно сформированные требования должны быть выраженыв простых структурированных фразах на английском языке, использующих выражения shall (должен), для того чтобы инструментальные средства выработки требований могли без труда проводить ихсинтаксический анализ.<id> <система> shall <действие>Модель требований содержит функциональные и нефункциональные требования к системе. Это может быть:• документ;• база данных в системе управления требованиями.Требования могут быть организованы в таксономию – иерархию типов требований, которая классифицирует требования.Требования могут иметь атрибуты – дополнительную информацию(метаданные), ассоциированную с каждым требованием:• например приоритет – MoSCoW (Must have, Should have, Couldhave, Want to have);• например атрибуты RUP (Status, Benefit, Effort, Risk, Stability,TargetRelease);• количество атрибутов требований должно быть минимальным,от этого проект только выиграет.Карта местности еще не территория.

Естественный язык содержит:• пропуски – информация отфильтровывается;• искажения – информация модифицируется;• обобщения – информация обобщается в правила, убеждения и понятия об истинности и ложности.Кванторы общности (например, «все», «каждый») могут указыватьграницы чьейлибо ментальной карты сферы деятельности; их необходимо ставить под сомнение.Техники выявления требований:• интервью;• анкеты;• семинары.4Моделирование прецедентов4.1. План главыВ этой главе обсуждаются основы моделирования прецедентов, что является еще одной формой выработки требований. Моделирование прецедентов будет рассмотрено так, как оно описано в UP. Основное внимание уделяется конкретным методам и стратегиям, которые могутприменяться ОО аналитиком или дизайнером для эффективного моделирования прецедентов.

В разделе приведены только самые простыепрецеденты, чтобы ничто не отвлекало от рассмотрения этих методов.Полный (и более сложный) учебный пример можно найти на нашемвебсайте www.umlandtheunifiedprocess.com.UML не определяет какойлибо формальной структуры для описанияпрецедентов. В этом кроется проблема, поскольку разные разработчики моделей используют разные стандарты. Чтобы както справитьсяс этим, в этой главе и в учебном примере мы приняли простой и эффективный стандарт. Наш вебсайт предоставляет схему XML (eXtensibleMarkup Language, расширяемый язык разметки) с открытым исходным кодом для прецедентов и актеров, которую читатели могут свободно использовать в своих проектах.

Эти шаблоны основываются налучших практиках индустрии и обеспечивают простой, но при этомэффективный стандарт записи спецификаций прецедентов.На нашем вебсайте также можно найти очень простую таблицу стилей XSL (eXtensible Stylesheet Language, расширяемый язык стилей),которая превращает XMLдокументы прецедентов в HTML, отображаемый в броузере. Эта таблица стилей – полезный пример. Она можетбыть запросто настроена под стандарты фирменного оформления илидругие стандарты оформления документов для различных организаций.

Подробное обсуждение XML выходит за рамки нашей книги, нодля эффективной работы с такими документами, возможно, понадобится обратиться к учебникам по XML, таким как [Pitts 1] и [Kay 1].90Глава 4. Моделирование прецедентовобзор4.2. Моделирование прецедентовelse4.3. Деятельность UP: выявление актеров и прецедентовизучаем границы системыизучаем актеровизучаем прецедентыизучаем глоссарий проекта4.3.1. Контекст системы(границы системы)4.3.2. Что такое актеры?4.3.3.

Что такое прецеденты?4.3.4. Глоссарий проекта4.3.2.1. Идентификация актеров4.3.3.1. Идентификация прецедентов4.3.2.2. Время как актер4.3.3.2. Диаграмма прецедентов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.6.1. Ветвление потока4.5.6.3. Повторение в потоке4.5.7. Моделированиеальтернативных потоков4.5.6.2. Ключевое слово Если (If)4.5.7.1. Выявлениеальтернативных потоков4.5.6.4.

Ключевоеслово Для (For)4.5.6.5. Ключевоеслово Пока (While)4.6. Отображение требований4.7. Когда применять моделирование прецедентов4.8. Что мы узналиРис. 4.1. План главы4.5.7.2. Сколькоальтернативных потоков?4.2. Моделирование прецедентов91Помимо схемы с открытым исходным кодом и таблиц стилей мы работаем над более гибким подходом под названием SUMR (Simple Use caseMarkup 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+Wesley4.3. Деятельность UP: Выявление актеров и прецедентов93В оригинальной работе Джекобсона [Jacobson 1] вместо Модели требований (на рис. 4.2 этот прямоугольник затушеван, чтобы обозначить изменение, внесенное в исходный рисунок) присутствовали дополнительные требования. Сюда были включены требования (обычно нефункциональные), не относящиеся ни к одному из конкретных прецедентов. Этот документ являлся, главным образом, вместилищем длявсех нефункциональных требований, противоречащих прецедентам.В нашем более устойчивом подходе к выработке требований дополнительные требования были разбиты на категории и включены в Модельтребований в качестве подраздела.4.3.1.

Контекст системы (границы системы)Контекст системы отделяет систему от остального мира.Первое, что необходимо сделать при построении системы, – обозначитьее границы. Иначе говоря, надо определить, что является частью системы (находится внутри границ системы) и что находится вне системы(вне ее границ). Это кажется очевидным, но встречается немало проектов, в которых изза неясности границы системы возникают серьезныепроблемы. Точное определение границ системы обычно играет важную роль в выявлении функциональных (а иногда и нефункциональных) требований. Мы уже были свидетелями того, как неполные и неправильно заданные требования могут стать основной причиной неудач проектов.

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

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