Использования

Направляемый

вариантами

Задача Унифицированного процесса — предоставлять разработчикам план эффективного

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

Эффективность при этом измеряется в понятиях стоимости, качества и затраченного

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

Проблемы начинаются с определения требований заказчиков. Этот процесс

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

их без ошибок до всех участников проекта. После этого мы должны быть в состоянии

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

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

в том, что требования пользователей выполнены. Сложность процесса заставляет

нас описывать его в виде серии рабочих процессов, последовательно создающих

работающую систему.

Как мы говорили в главе 1, Унифицированный процесс управляется вариантами

использования, ориентирован на архитектуру, итеративен и инкрементен.

В этой главе мы рассмотрим, каким образом Унифицированный процесс управляется

вариантами использования. Эта концепция была впервые представлена в [32]

и внимательно рассмотрена в [34]. Ориентированность на архитектуру будет подробно

описана в главе 4, а итеративность и инкрементность — в главе 5. Разбивая

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

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

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

проектировать высокоинтегрированные системы, разрабатывать хорошие компоненты

реализации (см. подраздел «Артефакт: компонент» главы 10) и проводить

специальные виды тестирования. Эти темы не помогут нам лучше понять варианты

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

изучение этих тем мы отложим до второй части книги.

На рис. 3.1 изображена последовательность рабочих процессов и моделей Унифицированного

процесса. Разработчики начинают с определения требований за-

казчика в виде вариантов использования и формирования на их основе модели

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

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

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

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

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

им проверить, обеспечивает ли система функциональность, описанную в вариантах

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

Модель реализации наиболее формальна, а самая неформальная модель — это

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

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

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

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

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

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

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

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

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

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

итераций разработки и системной интеграции (см. главу И).

Требования

Модель вариантов

использования

Анализ -

Модель

анализа

Проектирование-

Модель Модель

проектирования развертывания

Реализация

Модель

реализации

Тестирование •

Модель

тестирования

.

Рис. 3.1. Унифицированный процесс представляет собой последовательность рабочих

процессов от определения требований до тестирования (слева, сверху вниз).

В ходе рабочих процессов разрабатываются модели,

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

до модели тестирования

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

Таким образом они связывают различные рабочие процессы между собой.