UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
3.1. План главы В этой главе рассматривается все, что необходимо для понимания тре бований, предъявляемых к системе. Здесь вводится понятие требова ний и обсуждаются детали рабочего потока определения требований в UP. Также представлено расширение UP для работы с требованиями без применения прецедентов UML. 3.2. Рабочий поток определения требований Как показано на рис. 3.2, большая часть работы в процессе определе ния требований выполняется в фазах Начало и Уточнение в самом на чале жизненного цикла проекта. Это и не удивительно, поскольку не возможно продвигаться вперед, за фазу Уточнение, до тех пор, пока не известно, хотя бы приблизительно, что предполагается разрабатывать! До начала работы над ОО анализом и проектированием уже необходи мо иметь некоторое представление о том, что должно получиться в ре зультате. Именно в этом состоит цель рабочего потока определения требований. С точки зрения ОО аналитика или дизайнера его цель – это поиск и достижение соглашения о функциях системы, написанно го на языке пользователей системы. Создание высокоуровневой специ фикации того, что должна делать система, – это часть процесса выра ботки требований (requirements engineering). Большая часть работы с требованиями проводится в начале проекта, в фазах Начало и Уточнение. У любой заданной системы может быть множество различных заинте ресованных сторон: разные типы пользователей, специалисты по экс плуатации, штат по обслуживанию, продаже, управлению и т. д. Выра 72 Глава 3. Рабочий поток определения требований else else else else else изучаем, какое место рабочий поток определения требований занимает в UP изучаем различные типы требований изучаем детали рабочего потока определения требований изучаем, почему требования так необходимы учимся находить требования 3.2. Рабочий поток определения требований 3.3. Требования, предъявляемые к программному обеспечению – метамодель 3.4. Детализация рабочего потока определения требований 3.5. Важное значение определения требований 3.6. Определение понятия требования 3.6.1. Модель требований 3.6.2. Правильно сформированные требования 3.6.3. Функциональные и нефункциональные требования 3.6.4. Организация требований 3.6.5. Атрибуты требований 3.7. Поиск требований 3.7.1. Выяснение требований 3.7.2. Интервью 3.7.3. Анкеты 3.7.4. Семинар по определению требований 3.8. Что мы узнали Ри с. 3 .1. Пл ан гл ав ы 3.2. Рабочий поток определения требований 73 ботка требований состоит в выявлении и классификации требований, предъявляемых к системе заинтересованными сторонами. Это перего ворный процесс, поскольку часто выдвигаются противоречивые требо вания, которые должны быть согласованы. Например, одной группе хочется добавлять большое количество пользователей, что может при вести к нереальному трафику в существующей базе данных и инфра структуре связи. В настоящее время это наиболее распространенный конфликт, поскольку все большее и большее число компаний откры вают части разработанных ими систем громадной аудитории пользова телей через Интернет. Некоторые книги по UML (и конечно, учебные курсы) отмечают, что прецеденты UML являются единственным способом фиксирования тре бований. Но это утверждение оказывается неверным при более тща тельном рассмотрении. Прецеденты могут отражать только функцио нальные требования, которые являются описанием того, что будет делать система . Однако есть и другие требования, не относящиеся к функциональности, которые являются описаниями ограничений, на кладываемых на систему (производительность, надежность и т. п.), и не могут быть представлены в виде прецедентов. Поэтому в книге предлагается надежный подход к выработке требований, иллюстриру ющий дополнительные эффективные способы выявления обоих видов требований. Начало Уточнение Построение Внедрение Определение требований Анализ Проектирование Реализация Тестирование Предварительные итерации Шаг 1 Шаг 2 Шаг n Шаг n+1 Шаг n+2 Шаг m Шаг m+1 Рис. 3.2. Определение требований выполняется в фазах Начало и Уточнение. Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательства Addison Wesley 74 Глава 3. Рабочий поток определения требований 3.3. Метамодель требований, предъявляемых к программному обеспечению На рис. 3.3 показана метамодель применяемого в данной книге подхо да к выработке требований. Здесь используется синтаксис UML, кото рый нами еще не был рассмотрен. Не беспокойтесь! Все это детально обсуждается позже, а пока необходимо знать лишь следующее: • Пиктограммы, напоминающие папки, – это пакеты UML. Они яв ляются механизмом группировки UML и содержат группы элемен тов модели UML. В сущности, они очень напоминают настоящие папки файловой системы тем, что используются для организации и группировки взаимосвязанных сущностей. Маленький треуголь ник в верхнем правом углу пакета указывает на то, что в пакете на ходится модель. • Пиктограмма якоря показывает, что сущность, изображенная со сто роны кружка, содержит сущность, находящуюся на другом конце линии. Наша метамодель показывает, что Спецификация требований к программному обеспечению (Software requirements specification, SRS) включает Модель требований (Requirements model) и Модель прецедентов (Use case model). Эти две модели являются разными, но тем не менее взаимодополняю щими способами представления требований, предъявляемых к системе. Можно видеть, что в Модель требований входят Функциональные требования (требования, определяющие, что должна делать система) и Нефункцио Модель прецедентов Нефункциональные требования P1 P2 P3 пиктограмма якоря пакет актер прецедент Функциональные требования Спецификация требований к программному обеспечению Модель требований Рис. 3.3. Метамодель требований 3.4. Детализация рабочего потока определения требований 75 нальные требования (требования, выражающие ограничения системы, не относящиеся к ее функциональности). Модель прецедентов включает множество пакетов прецедентов (здесь по казаны только три из них), которые содержат прецеденты (специфи кации функциональных возможностей системы), актеров (внешние роли, непосредственно взаимодействующие с системой) и отношения. По сути, SRS – это начальная стадия процесса построения программ ного обеспечения. Это отправная точка ОО анализа и проектирования. Далее настоящая глава посвящена подробному рассмотрению разработ ки требований. Прецеденты и актеры обсуждаются в главе 4. 3.4. Детализация рабочего потока определения требований На рис. 3.4 показаны конкретные задачи рабочего потока определения требований в UP. Такие диаграммы называют детализацией рабочего потока, поскольку они детализируют составляющие задачи опреде ленного потока работ. Детализация рабочего потока показывает исполнителей и деятельности, вовлеченные в конкретный рабочий поток. Детализации потока работ UP моделируются в виде исполнителей (пиктограммы в левой части рисунка) и деятельностей (пиктограммы в форме шестеренок). Разновидности UP, такие как RUP, могут ис Выявить актеров и прецеденты Назначить приоритеты прецедентов Детализировать прецедент Составитель спецификации прецедентов Системный аналитик Архитектор Построить модель прецедентов Разработчик пользовательского интерфейса Создать прототип пользовательского интерфейса Рис. 3.4. Задачи рабочего потока определения требований. Воспроизведено с рис. 7.10 [Jacobson 1] с разрешения издательства Addison Wesley 76 Глава 3. Рабочий поток определения требований пользовать другие пиктограммы, но с той же семантикой (краткое об суждение отношений между UP и RUP см. в разделе 2.4). Стрелки – это отношения, показывающие нормальный поток выполнения рабо ты от одной задачи к следующей. Однако следует помнить, что это только приближенное представление рабочего потока для «усреднен ного» случая. Оно может и не быть точным представлением происхо дящего в действительности. В реальности в зависимости от обстоя тельств некоторые задачи могут выполняться в другом порядке или параллельно. Поскольку данная книга посвящена анализу и проектированию, основ ное внимание сосредоточено только на задачах, важных для ОО анали тиков и разработчиков. Поэтому нас интересует следующее: • Выявление актеров и прецедентов. • Детализация прецедента. • Построение модели прецедентов. Другие задачи рабочего потока определения требований не так важны для нас как аналитиков и разработчиков. Назначение приоритетов преце дентов – это деятельность в основном по планированию архитектуры и проекта, а Создание прототипа пользовательского интерфейса – это дея тельность, касающаяся программирования. Более подробно о данных видах деятельности можно узнать в книге [Jacobson 1]. Мы расширяем рабочий поток определения требований в UP, чтобы ра ботать с требованиями, описанными на структурированном английском (или другом естественном) языке. На рис. 3.4 показано, что стандартный рабочий поток UP сосредоточен на прецедентах, исключая все остальные методы выявления требова ний. В этом нет ничего страшного, но, как было отмечено выше, такой подход не может в достаточной мере реализовать нефункциональные требования к системе. Чтобы досконально рассмотреть все требования, Выявление функциональных требований Разработчик требований Выявление нефункциональных требований Отображение (trace) требований в прецеденты Назначение приоритетов требований Архитектор Рис. 3.5. Расширенный рабочий поток определения требований: новые задачи и исполнители 3.5. Важное значение определения требований 77 необходимо расширить рабочий поток определения требований в UP и добавить следующие новые задачи: • Выявление функциональных требований. • Выявление нефункциональных требований. • Назначение приоритетов требований. • Отображение (trace) требований в прецеденты. Также был введен новый исполнитель – разработчик требований. Но вые задачи и исполнители показаны на рис. 3.5. 3.5. Важное значение определения требований Выработка требований – термин, используемый для описания деятель ности по выявлению, документированию и обслуживанию ряда требо ваний, предъявляемых к программной системе. Речь идет о выяснении того, что хотят получить от системы заинтересованные стороны. Согласно [Standish 1], неполные требования и неучастие пользовате лей являлись двумя основными причинами провала проектов. Обе проблемы – результат ошибок в выработке требований. Поскольку конечная программная система основывается на наборе требований, эффективная выработка требований – решающий фактор успеха в проектах по разработке программного обеспечения. 3.6. Определение понятия требования Требование можно определить как «подробное описание того, что должно быть реализовано». Существует два основных типа требований: • функциональные требования – какое поведение должна предлагать система; • нефункциональные требования – особое свойство или ограничение, накладываемое на систему. Требования указывают, что должно быть построено, но не говорят, как это сделать. Требования – это (по крайней мере, так должно быть) основа всех систем. Это, по сути, формулировка того, что должна делать система. В принципе требования должны быть только изложением того, что система должна делать, но не того, как она должна это делать. Это важное различие. Можно определить, что должна делать и какое по ведение должна демонстрировать система, но при этом не обязательно что либо говорить о том, как эта функциональность может быть реа лизована. 78 Глава 3. Рабочий поток определения требований Хотя теоретически, конечно же, очень привлекательно отделить «что» от «как», но на практике набор требований скорее будет смесью «что» и «как». Отчасти из за того, что обычно проще писать и понимать опи сание реализации, нежели абстрактное изложение проблемы. Отчасти потому, что могут существовать ограничения на реализацию, которые предопределяют «как» системы. Несмотря на тот факт, что поведение системы, и особенно удовлетворе ние конечного пользователя, закладывается в процессе выработки тре бований, многие компании по прежнему не считают это важным. Как было упомянуто, основная причина провалов проектов по разработке программного обеспечения заключается в проблемах с требованиями. 3.6.1. Модель требований Во многих компаниях до сих пор нет формальной системы представле ния требований или модели требований. Программное обеспечение описывается в одном или более выполненных в произвольной форме и в разной степени полезных «документах с требованиями». Зачастую они написаны на естественном языке, имеют произвольные форму и размер. Для любого документа с требованиями, в какой бы форме он ни был представлен, ключевыми вопросами являются «насколько он полезен мне?» и «помогает ли он мне понять, что должна делать систе ма?» К сожалению, полезность таких произвольным образом оформ ленных документов ограничена. UP обладает формальным подходом к определению требований, осно ванным на модели прецедентов. Здесь мы расширяем его моделью тре бований, базирующейся на традиционных представлениях о функцио нальных и нефункциональных требованиях. Это расширение прямо соответствует более сложному подходу к выработке требований, при меняемому в RUP. Наша метамодель требований (рис. 3.3) показыва ет, что SRS состоит из модели прецедентов и модели требований. Модель прецедентов обычно создается в инструменте моделирования UML, таком как Rational Rose. Прецеденты подробно рассматривают ся в главах 4 и 5. Модель требований может быть создана в текстовом редакторе или в специальном инструментальном средстве выработки требований, на пример RequisitePro (www.ibm.com) или DOORS (www.telelogic.com). Мы рекомендуем использовать инструменты выработки требований по мере возможности. Как создавать правильно сформированные требо вания, обсуждается в следующих нескольких разделах. 3.6.2. Правильно сформированные требования UML не дает каких либо рекомендаций по написанию традиционных требований. Фактически требования в UML представляются исключи тельно через механизм прецедентов, который будет рассмотрен позже. 3.6. Определение понятия требования 79 Однако многие разработчики моделей (включая и нас) полагают, что прецедентов недостаточно и все же нужны традиционные инструмен тальные средства выработки и управления требованиями. Для записи требований используйте утверждение «shall» («должен»). Мы рекомендуем очень простой формат формулировки требований (рис. 3.6). Каждое требование имеет уникальный идентификатор (обыч но это число), ключевое слово ( shall (должен)) и описание действия. Пре имущество применения унифицированной структуры состоит в упро щении задачи синтаксического разбора требований для инструментов управления требованиями, таких как DOORS. 3.6.3. Функциональные и нефункциональные требования Полезно разделять требования на функциональные и нефункциональ ные. Существует много других способов систематизации требований, но для простоты начнем с этих двух категорий. Функциональное требование – это то, что система должна делать. Функциональное требование – это формулировка того, что должна де лать система, это описание назначения системы. Например, для бан комата (automated teller machine, ATM) можно было бы определить следующие функциональные требования: 1. Система ATM shall (должна) проверять действительность вставлен ной в банкомат карточки. 2. Система ATM shall (должна) проверять достоверность PIN кода, введенного пользователем. 3. Система ATM shall (должна) выдавать по одной ATM карточке не более $250 в сутки. Нефункциональное требование – ограничение, накладываемое на сис тему. ключевое слово уникальный идентификатор имя системы действие, которое должно быть выполнено Рис. 3.6. Формат формулировки требований 80 Глава 3. Рабочий поток определения требований Нефункциональное требование – это ограничение, накладываемое на систему. Система ATM может иметь следующие нефункциональные требования? 1. Система ATM shall (должна) быть написана на C++. 2. Система ATM shall (должна) обмениваться информацией с банком, используя 256 разрядную кодировку. 3. Система ATM shall (должна) проверять действительность карточки ATM в течение не более трех секунд. 4. Система ATM shall (должна) проверять достоверность PIN кода в те чение не более трех секунд. Можно заметить, что нефункциональные требования определяют или накладывают ограничения на то, как будет реализована система. 3.6.4. Организация требований При использовании инструментального средства управления требова ниями можно организовать требования в таксономию – иерархию ти пов требований, которая может использоваться при классификации требований. Типы требований применяются главным образом для соз дания небольших групп из громадного числа неструктурированных требований. Такими группами легче управлять, что делает работу с требованиями более эффективной. Базовое разделение на функциональные и нефункциональные требова ния, описанное выше, является очень простой таксономией. Но можно пойти дальше и ввести категории требований, расширяя таксономию, как показано на рис. 3.7. Нефункциональные требования Производительность Производственная мощность Наличие Соответствие стандартам Безопасность Функциональные требования Клиенты Продукты Заказы Каналы сбыта Платежи |