Организация разработки

Глава 4 • Архитектуро-центрированный процесс

Понимание системы

Зачем нужна архитектура?

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

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

систему, не существующую в нашем трехмерном мире. Программные

системы часто бывают в какой-то степени беспрецедентны или уникальны. Нередко

они используют прогрессивные технологии или новое сочетание технологий. Часто

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

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

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

«проблема проектирования находится вне алгоритмов и структур данных:

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

иного типа» [2].

Кроме того, часто имеется существующая система, которая исполняет некоторые

из функций проектируемой системы. Определение того, что делает эта система,

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

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

добавляет разработке сложности.

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

О понять систему;

О организовать разработку;

О способствовать повторному использованию кода;

О развивать систему в дальнейшем.

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

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

по многим причинам.

О Они реализуют сложное поведение.

о Они работают в сложном окружении.

О Они сложны технологически.

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

и платформы (например, операционные системы и СУБД) и многократно используемые

компоненты и структуры.

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

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

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

местах. Это добавляет ко всему вышеперечисленному еще и трудности с координацией

работ.

Кроме того, эти факторы постоянно изменяются. Все это вызывает постоянную

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

Способ предотвратить подобную потерю понятности — сделать разработку ар-

хитектуро-центрированной (приложение В). Поэтому первое требование, предъявляемое

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

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

достаточно полно, чтобы это облегчило их работу. Нам помогут в этом модели

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

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

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

ее понимание.

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

тем больше будут затраты на общение между разработчиками с целью координации

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

местах. Разделяя систему на подсистемы с четко определенными интерфейсами

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

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

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

ли они в одном здании или на разных континентах. Хорошей считается та архитектура,

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

затрат на общение. Хорошо определенный интерфейс успешно «сообщает» разработчикам

ту информацию о работе других групп, которая им необходима.

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

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

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

правильные интерфейсы между подсистемами. Примером может послужить шаблон

Граничгьый класс-Управляющий класс-Класс сущности (см. подраздел «Создание

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

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

данных.