Введение в разработку, управляемую

вариантами использования

Определение требований преследует две цели: определить существенные требования

(см. главу 6) и представить их в форме, удобной для пользователей, заказчиков

и разработчиков. Под «существенными требованиями» мы понимаем те требования,

реализация которых принесет пользователям ощутимый и значимый для

них результат. Под «представлением в форме, удобной для пользователей, заказчиков

и разработчиков» мы понимаем главным образом то, что итоговое описание

требований должны понимать пользователи и заказчики. Это один из главных результатов

рабочего процесса определения требований.

Обычно у системы имеется несколько категорий пользователей. Каждая категория

пользователей представляется в виде актанта. Актанты используют систему,

участвуя в вариантах использования. Вариант использования — это последовательность

действий, которые система предпринимает для получения актантом

ценного для него результата. Полный набор актантов и вариантов использования

системы образует модель вариантов использования [35, 36].

В ходе анализа и проектирования модель вариантов использования преобразуется

в модель анализа, а затем в модель проектирования. Если говорить коротко,

и модель анализа, и модель проектирования — это структуры, построенные на основе

классификаторов (приложение А) и набора реализаций вариантов использования

(см. главы 8 и 9), которые определяют, как эти структуры реализуют варианты

использования. Классификаторы в основном представляют собой «клас-

соподобные» сущности. Так, они содержат атрибуты и операции (приложение А),

их можно описывать с помощью диаграмм состояний (приложение А), некоторые

из них допускают создание экземпляров, они могут участвовать в кооперациях

и т. п. В UML существует множество типов классификаторов. Примерами классификаторов

для этих моделей могут быть подсистемы, классы и интерфейсы. Актанты,

варианты использования, компоненты и узлы (приложение А, см. подраздел «Артефакт:

модель развертывания» главы 9) также являются классификаторами.

Модель анализа — это детальное описание требований и предстоящих работ. Она

рассматривается и как отдельная модель, и как первый шаг в создании модели проектирования.

Разработчики используют ее для того, чтобы лучше понять варианты

использования, описанные в рабочем процессе определения требований путем их

уточнения при помощи коопераций между концептуальными классификаторами (в

противоположность классификаторам проектирования, создаваемым позднее). Модель

анализа также используется для построения гибкой и устойчивой системы

(включая архитектуру), с как можно большим употреблением повторно используемых

компонентов. Модель анализа отличается от модели проектирования тем, что

первая — это концептуальная модель, а вторая — чертеж реализации. Модель анализа

нередко существует лишь в течение нескольких первых итераций. Однако иног-__

да, особенно в случае больших и сложных систем, аналитическая модель сопровождает

систему в течение всего срока ее существования. В этом случае между соответствующими

реализациями вариантов использования в модели анализа и модели

проектирования существует прямая связь (через зависимость трассировки). Каждый

элемент модели анализа трассирует реализующий его элемент из модели проектирования,

(Модель анализа, ее свойства и связь с моделью проектирования подробно

рассматриваются в подразделах «Введение в анализ», «Кратко об анализе»

и «Роль анализа в жизненном цикле программы» главы 8.)

Модель проектирования имеет следующие свойства.

О Модель проектирования имеет иерархическую структуру. Она также содержит

отношения, наложенные поверх иерархии. Отношения — ассоциации, обобщения

и зависимости (приложение А) — часто используются в UML.

О Реализации вариантов использования в модели проектирования — это стереотипы

кооперации. Кооперация описывает, как классификаторы используются

в каком-либо виде деятельности, например реализации варианта использования.

О Модель проектирования является чертежом реализации. Существует прямое

отображение подсистем модели проектирования в элементы модели реализации.

Разработчики создают модель анализа, используя модель вариантов использования

в качестве исходных данных [37]. Каждый вариант использования из модели

вариантов использования превращается в реализацию варианта использования

модели анализа. Дуализм вариантов использования/реализаций вариантов использования

позволяет соблюсти полное подобие между определением требований

и анализом. Прорабатывая варианты использования один за другим, разработчики

идентифицируют классы, участвующие в реализации вариантов использования.

Вариант использования Получить наличные, например, превращается в классы

анализа Получение, Банковский счет, Устройство выдачи и еще несколько классов,

которые мы пока идентифицировать не будем. Разработчики выделяют ответственности

конкретных классов в ответственностях (приложение А), определенных

в вариантах использования. В нашем примере класс Банковский счет будет

нести ответственность за выполнение операции ^Списать деньги со счета». Таким

образом, мы можем убедиться в том, что получили набор классов, совместно реализующих

варианты использования и действительно необходимых.

Затем разработчики проектируют классы и реализации вариантов использования

для того, чтобы лучше понять, какие продукты и технологии следует использовать

для построения системы (брокеры объектных запросов, библиотеки для

создания графического интерфейса пользователя, СУБД). Классы проектирования

собираются в подсистемы, и между этими подсистемами определяются интерфейсы.

Разработчики также создают модель развертывания, которая определяет

физическое распределение частей системы по узлам — отдельным компьютерам

сети — и проверяют, могут ли варианты использования быть реализованы в виде

компонентов, выполняемых на этих узлах.

Далее, разработчики реализуют спроектированные классы в виде набора файлов

с исходным текстом компонентов, из которых, если их скомпилировать и скомпоновать,

можно получить исполняемый код — DLL, JavaBeans или ActiveX. Ва__

рианты использования помогают разработчикам определить порядок создания

компонентов и включения их в систему.

И наконец, в ходе рабочего процесса тестирования тестеры проверяют, действительно

ли система выполняет функции, определенные вариантами использования,

и удовлетворяет требованиям к системе. Модель тестирования содержит тестовые

примеры (и еще кое-что, подробнее об этом мы поговорим в главе 11). Тестовый

пример определяет набор исходных данных, условий выполнения и результатов.

Множество тестовых примеров могут быть порождены прямо из вариантов использования,

таким образом, мы можем говорить об отношении трассировки между тестовыми

примерами и соответствующими вариантами использования. Это означает,

что тестеры будут проверять, делает ли система то, чего хотят от нее пользователи,

то есть выполняет ли она варианты использования. Каждый, тестировавший

в прошлом программное обеспечение, фактически тестировал варианты использования,

— хотя тогда это и называлось иначе [64]. А вот что в Унифицированном процессе

действительно изменилось, так это то, что теперь тестирование можно планировать

гораздо раньше. Сразу же после определения вариантов использования можно

начинать создание тестов вариантов использования (тесты для «черного ящика

») и задавать порядок их выполнения, вхсяючения в систему и тестирования. Позднее,

после реализации вариантов использованрш в ходе проектирования, можно

детализировать тесты вариантов использования (тесты для «белого ящика»). Каждый

способ выполнения варианта использования, а значит, каждый путь реализации

варианта использования, является кандидатом на тестовый пример.

Пока мы описывали Унифицированный процесс в виде последовательности

шагов, очень похожей на старый водопадный подход. Однако это делалось только

для сохранения простоты рассуждений. В главе 5 мы увидим, как по-разному можно

пройти эти шаги, используя итеративность и инкрементальность процесса разработки.

На самом деле, все, что мы рассмотрели здесь — это одна итерация. Полный

процесс разработки будет состоять из серии таких итераций, каждая из которых (а

особенно первая) состоит из одного выполнения рабочих процессов определения

требований, анализа, проектирования, реализации и тестирования.

Перед тем как начать детальное изучение различных рабочих процессов, рассмотрим

положительные стороны применения вариантов использования.

Зачем нужны варианты использования?

Существует несколько объяснений удобства, популярности и повсеместного применения

вариантов использования [40]. Две основные причины таковы:

О Варианты использования дают систематический и интуитивно понятный способ

определения функциональных требований (приложение Б, см. также главы 6 и 7),

ориентированный на получение необходимых пользователю результатов.

О Варианты использования управляют всем процессом разработки. Все основные

виды деятельности — анализ, проектирование и тестирование — выполняются

на основе определенных вариантов использования. Проектирование и тестирование

к тому же планируются и координируются в понятиях вариантов

использования. Это особенно хорошо видно после выполнения первых итераций,

когда архитектура системы стабилизируется.__