4. Описание архитектуры

Базовый уровень архитектуры, разработанный во время фазы проектирования, сохраняется, в форме описания архитектуры. Описание архитектуры — это выдержка или, как мы говорим, набор представлений — возможно, аккуратно приведенный в удобный для чтения вид моделей базового уровня архитектуры. Представления моделей содержат существенные для архитектуры элементы. Множество элементов моделей, входящих в базовый уровень архитектуры, разумеется, войдет также и в описание архитектуры. Однако в описание архитектуры войдут не все элементы базового уровня, потому что для получения работающего базового уровня мы вынуждены были разработать некоторые элементы моделей, не существенные для архитектуры, но необходимые для создания исполняемого кода. Так как базовый уровень архитектуры используется не только для разработки архитектуры, но и для определения требований к системе на таком уровне, когда возможно создание детального плана, модель варианта использования этого базового уровня также может содержать не только те варианты использования, которые важны для построения архитектуры.

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

• обнаружение новых абстрактных классов и интерфейсов;

• добавление новых функциональных возможностей к существующим подсистемам;

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

перестройку структуры процесса.

4. Интеративный и инкрементный процесс

1. Введение в итеративность и инкрементность

Достижение правильного баланса между вариантами использования и архитектурой во многом подобно достижению правильного баланса между функциями и формой при создании любого другого изделия. Достижение баланса требует некоторого времени. То, что мы имеем вначале, соответствует проблеме курицы и яйца, такие, какими мы их видим теперь, возникли в результате почти бесконечных итераций в ходе длительного процесса эволюции. Точно так же в ходе гораздо более короткого процесса разработки программного обеспечения разработчики сознательно создают этот баланс (между вариантами использования и архитектурой) в процессе ряда итераций. Таким образом, итеративный и инкрементный подход к разработке представляет собой третье ключевое положение Унифицированного процесса.

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

В трех словах: программы получаются лучше. Немного более развернуто: чтобы пройти главные и вспомогательные вехи, по которым мы контролируем ход разработки. И еще более развернуто.

• Чтобы как можно раньше получить описание критических и опасных рисков.

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

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

• Чтобы создавать систему в несколько приемов путем приращений, а не всю сразу и до конца, что сильно поднимает стоимость изменений.

• Чтобы обеспечить процесс разработки, который повысит эффективность работы сотрудников.