Шаги разработки архитектуры

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

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

некоторое взаимодействие. В главе 3 мы кратко рассмотрели, как разрабатывать

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

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

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

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

своей работы. Но как нам получить такую систему? Ответ мы уже знаем:

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

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

Уточним, как происходит этот процесс, рассмотрев сначала, что оказывает влияние

на архитектуру (рис. 4.1), а затем — какие факторы влияют на варианты использования.

Рис. 4. 1. На архитектуру оказывают влияние не только варианты использования,

но и другие типы требований и продуктов. Разрабатывать архитектуру

нам помогает опыт предыдущей работы и образцы архитектуры

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

мы желаем поддерживать в системе. Варианты использования — это направляющие

для архитектуры. В конце концов, мы хотим иметь архитектуру, которая

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

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

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

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

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

выпусках.

Однако на архитектуру будут влиять не только важные для архитектуры варианты

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

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

системы (например, операционной системой или СУБД).

О Программное обеспечение среднего уровня (приложение В), которое мы хотим

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

механизм прозрачного маршалинга и доставки сообщений распределенным

объектам в гетерогенных средах [56] или платформонезависимый

каркас для создания пользовательского графического интерфейса.

О Унаследованные системы, которые войдут в нашу систему. Включая унаследованную

систему, например существующую банковскую систему, в наш про-

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

исходных данных требований пользователей и клиентов (рис. 4.2). Варианты

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

проектирования.

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

полученных от заказчика и пользователей. Также на варианты

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

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

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

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

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

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

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

Клиент пожелал иметь функцию, контролирующую загрузку процессора. Это требование

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

используя высший уровень приоритета процессора. Осуществление этого варианта

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

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

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

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

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

изменять базовую архитектуру.

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

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

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

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

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

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

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

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

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

архитектурой. С другой стороны, мы используем построенную архитектуру,

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

Архитектура управляет вариантами использования (рис. 4.3).

Что будет в начале, варианты использования или архитектура? Это — типичная

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

подходом. Сначала, отталкиваясь от хорошего понимания предметной области

(приложение В), мы строим предварительную архитектуру, не рассматривая

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

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

ее под эти варианты использования. Затем мы выбираем еще варианты

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

Рис. 4.3. Варианты использования управляют разработкой архитектуры,

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

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

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

итерации мы также содействуем реализации архитектуры специфического

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

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

в деле разработки постепенно улучшать архитектуру. Это — одно из преимуществ

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

Мы вернемся к рассмотрению итеративного процесса в главе 5.

Подведем итоги. Добротная архитектура — это такая архитектура, которая позволяет

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

сейчас, так и в будущем.

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

Каждая итерация выполняется так, как описано в главе 3: сначала определение

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

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

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

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

«мышц».

Какие варианты существенны для архитектуры? Мы тщательно рассмотрим этот

вопрос в подразделе «Расстановка приоритетов вариантов использования» главы

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

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

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

все важные функции системы, не оставляя ничего незамеченным. Как показано

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

архитектуры дают архитектору и другим сотрудникам уверенность в том, что архитектура

действительно рабочая. В этом невозможно убедиться при помощи «бумажного

» анализа и проектирования. Работающий базовый уровень архитектуры

наглядно демонстрирует состояние__