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

Центрированный

Архитектуро-

Резюме

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

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

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

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

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

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

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

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

нужные пользователям варианты использования. Другими словами, вариан-__

и управляют процессом разработки. В этом, вероятно, заключается наиболее важное

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

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

это не все. В следующей главе мы поговорим о другом ключевом аспекте Унифицированного

процесса — его ориентированности на архитектуру.

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

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

в ходе разработки системы. Однако есть и другие способы разрабатывать программы,

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

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

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

систему, необходимо кое-что еще. Это «кое-что» — архитектура. Мы можем думать

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

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

и другие заинтересованные лица). Архитектура дает нам ясное представление обо

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

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

элементы моделей. Как мы определяем, какие элементы особо важны для нас? По

тому, что они направляют нашу работу с системой как в текущем цикле разработки,

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

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

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

класс проектирования» главы 9). Они описывают основу системы, которая

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

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

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

гараж. Один из вариантов использования, разумеется. Держать автомобиль,

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

его оттуда. Нужно ли пользователю что-то еще? Допустим, он хочет устроить там

мастерскую. Это наводит строителя на мысль о необходимости осветить гараж —

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

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

розеток и электрокабель соответствующей мощности. Вот так строитель разрабатывает

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

видел гаражи. Он видел верстак. Он знает, что за верстаком будет работать человек.

Строитель действует не вслепую, он уже знаком с типичной архитектурой не-__

большого гаража. Он просто должен собрать воедино все части, чтобы выполнялись

варианты использования гаража. Если бы строитель никогда не видел гараж

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

в самом деле странное сооружение. Так что он должен принимать во внимание не

только функции гаража, но и его форму.

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

от гаража. Существует множество способов постройки больших зданий. Чтобы

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

команды должны будут обмениваться информацией об архитектурных решениях.

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

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

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

заинтересованным лицам. Наконец, они должны посредством чертежей довести

архитектуру до строителей и поставщиков.

Точно так же развитие большинства программных систем — или програмно-

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

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

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

лица. Кроме того, эти решения, эта архитектура, не появляются как по мановению

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

на фазах анализа и определения требований и проектирования. Фактически

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

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

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

системы.