Архитектура определяет организационную структуру

Архитектура определяет ограничения реализации

В архитектуре излагаются начальные проектные решения

Программная архитектура отражает самые ранние проектные решения относи­тельно системы. Их труднее всего принять, а по мере разработки — скорректиро­вать; при этом последствия наиболее существенны.

Реализация отражает архитектуру только в том случае, если она соответствует изложенным в ней структурным проектным решениям. Таким образом, реализа­цию следует разделить на ряд установленных архитектурой элементов; взаимо­действие между этими элементами должно производиться в установленном ар­хитектурой порядке; обязательства каждого отдельного элемента в отношении других элементов также должны исполняться согласно требованиям архитектуры.

Решения о распределении ресурсов тоже накладывают на реализацию определенные ограничения. Проблема в том, что конструкторы, работающие над отдельными элементами, иногда не имеют об этих решениях ни малейшего пред­ставления. Рассматриваемые ограничения подразумевают разделение задач, бла­годаря которому менеджерские решения в плане трудовых и вычислительных ресурсов реализуются наилучшим образом. От конструкторов отдельных элемен­тов требуется знание их спецификаций, однако во всем, что касается компро­миссных архитектурных решений, они могут пребывать в полном неведении. Архитекторы, напротив, обычно не являются экспертами в области разнообраз­ных аспектов построения алгоритмов и тонкостей языков программирования, однако именно они ответственны за принятие архитектурных компромиссов.

Мало того что архитектура устанавливает структуру разрабатываемой системы — эта последняя интегрируется в структуру проекта разработки¹ (а иногда, как видно на материале главы 1, даже в структуру компании-разработчика). Стандартный способ разделения труда по разработке крупной системы предполагает распреде­ление отдельных частей системы между несколькими группами конструкторов. Это называется декомпозицией обязанностей по разработке системы. Поскольку в состав системной архитектуры входит высокоуровневая декомпозиция систе­мы, именно она обычно служит основой для декомпозиции обязанностей; та, в свою очередь определяет структуру планирования, определения сроков и бюджета; каналы межгруппового взаимодействия; организацию управления конфигураци­ями и файловой системой; планы и процедуры интеграции и тестирования, и да­же такие мелочи, как организация локальной сети проекта и количество группо­вых попоек. Процесс сопровождения также отражает программную структуру — для сопровождения отдельных структурных элементов создается ряд рабочих групп.

У декомпозиции обязанностей по разработке системы есть один побочный эффект — дело в том, что некоторые аспекты программной архитектуры замора­живаются. Группа, ответственная за одну из подсистем, противится распростра­нению своих обязанностей на другие группы. Если эти обязанности зафиксиро­ваны в договоре, их пересмотр оказывается довольно затратным предприятием. Отслеживание работы по совокупности распределенных задач также усложняется.

¹ Забавная ситуация: в английском языке для обозначения проекта как организационной единицы (project) и проекта как продукта разработки (design) используют два разных слова, в русском -одно. Это доводит муки творчества переводчиков (воздадим им должное!) до невообразимых преде­лов. — Примеч. науч. ред.

Изменить утвержденную архитектуру по управленческим и коммерческим соображениям становится практически невозможно. Это — дополнительный ар­гумент (наряду со многими другими) в пользу комплексной оценки архитекту­ры, которую мы настоятельно рекомендуем проводить перед замораживанием программной архитектуры крупной системы.

Дата добавления: 2015-04-25