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

Требования, предъявляемые к программномуобеспечению – метамодельelseизучаем различные типы требований72Глава 3. Рабочий поток определения требований733.2. Рабочий поток определения требованийНачалоУточнениеПостроениеВнедрениеОпределениетребованийАнализПроектированиеРеализацияТестированиеПредварительныеитерацииШаг1Шаг2ШагnШагn+1Шагn+2ШагmШагm+1Рис. 3.2.

Определение требований выполняется в фазах Начало и Уточнение.Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательстваAddison+Wesleyботка требований состоит в выявлении и классификации требований,предъявляемых к системе заинтересованными сторонами. Это переговорный процесс, поскольку часто выдвигаются противоречивые требования, которые должны быть согласованы.

Например, одной группехочется добавлять большое количество пользователей, что может привести к нереальному трафику в существующей базе данных и инфраструктуре связи. В настоящее время это наиболее распространенныйконфликт, поскольку все большее и большее число компаний открывают части разработанных ими систем громадной аудитории пользователей через Интернет.Некоторые книги по UML (и конечно, учебные курсы) отмечают, чтопрецеденты UML являются единственным способом фиксирования требований. Но это утверждение оказывается неверным при более тщательном рассмотрении.

Прецеденты могут отражать только функциональные требования, которые являются описанием того, что будетделать система. Однако есть и другие требования, не относящиесяк функциональности, которые являются описаниями ограничений, на+кладываемых на систему (производительность, надежность и т. п.),и не могут быть представлены в виде прецедентов. Поэтому в книгепредлагается надежный подход к выработке требований, иллюстрирующий дополнительные эффективные способы выявления обоих видовтребований.74Глава 3. Рабочий поток определения требований3.3. Метамодель требований, предъявляемыхк программному обеспечениюНа рис.

3.3 показана метамодель применяемого в данной книге подхода к выработке требований. Здесь используется синтаксис UML, который нами еще не был рассмотрен. Не беспокойтесь! Все это детальнообсуждается позже, а пока необходимо знать лишь следующее:• Пиктограммы, напоминающие папки, – это пакеты UML. Они являются механизмом группировки UML и содержат группы элементов модели UML.

В сущности, они очень напоминают настоящиепапки файловой системы тем, что используются для организациии группировки взаимосвязанных сущностей. Маленький треугольник в верхнем правом углу пакета указывает на то, что в пакете находится модель.• Пиктограмма якоря показывает, что сущность, изображенная со стороны кружка, содержит сущность, находящуюся на другом концелинии.Наша метамодель показывает, что Спецификация требований к программномуобеспечению (Software requirements specification, SRS) включает Модельтребований (Requirements model) и Модель прецедентов (Use case model).Эти две модели являются разными, но тем не менее взаимодополняющими способами представления требований, предъявляемых к системе.Можно видеть, что в Модель требований входят Функциональные требования(требования, определяющие, что должна делать система) и НефункциоФункциональныетребованияМодельтребованийНефункциональныетребованияСпецификациятребованийк программномуобеспечениюпакетP1P3пиктограммаякоряМодельпрецедентовпрецедентP2актерРис.

3.3. Метамодель требований753.4. Детализация рабочего потока определения требованийнальные требования (требования, выражающие ограничения системы, неотносящиеся к ее функциональности).Модель прецедентов включает множество пакетов прецедентов (здесь показаны только три из них), которые содержат прецеденты (спецификации функциональных возможностей системы), актеров (внешниероли, непосредственно взаимодействующие с системой) и отношения.По сути, SRS – это начальная стадия процесса построения программного обеспечения.

Это отправная точка ОО анализа и проектирования.Далее настоящая глава посвящена подробному рассмотрению разработки требований. Прецеденты и актеры обсуждаются в главе 4.3.4. Детализация рабочего потокаопределения требованийНа рис. 3.4 показаны конкретные задачи рабочего потока определениятребований в UP. Такие диаграммы называют детализацией рабочегопотока, поскольку они детализируют составляющие задачи определенного потока работ.Детализация рабочего потока показывает исполнителей и деятельности,вовлеченные в конкретный рабочий поток.Детализации потока работ UP моделируются в виде исполнителей(пиктограммы в левой части рисунка) и деятельностей (пиктограммыв форме шестеренок). Разновидности UP, такие как RUP, могут исВыявить актеров и прецедентыПостроить модель прецедентовСистемный аналитикАрхитекторСоставитель спецификации прецедентовРазработчик пользовательского интерфейсаНазначить приоритеты прецедентовДетализировать прецедентСоздать прототип пользовательского интерфейсаРис.

3.4. Задачи рабочего потока определения требований. Воспроизведенос рис. 7.10 [Jacobson 1] с разрешения издательства Addison+Wesley76Глава 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.

Рабочий поток определения требованийХотя теоретически, конечно же, очень привлекательно отделить «что»от «как», но на практике набор требований скорее будет смесью «что»и «как». Отчасти изза того, что обычно проще писать и понимать описание реализации, нежели абстрактное изложение проблемы. Отчастипотому, что могут существовать ограничения на реализацию, которыепредопределяют «как» системы.Несмотря на тот факт, что поведение системы, и особенно удовлетворение конечного пользователя, закладывается в процессе выработки требований, многие компании попрежнему не считают это важным.