1.8. Плохие и хорошие архитектуры

Применительно к архитектуре термин «плохая» или «хорошая» следует применять крайне аккуратно. В первую очередь, надо говорить о том, насколько архитектура соответствует специфике требований, предъявляемых к проектируемой системе, т.е. архитектуру можно оценивать в контексте требований, предъявляемых к ИС. Однако можно говорить о том, насколько качественно или аккуратно спроектирована архитектура системы.

Ниже приведены некоторые эмпирические правила, которым надо следовать, чтобы избежать грубых ошибок на этапе архитектурного проектирования. Эти правила можно разделить на 2 группы: правила, связанные с выбором архитектурного проектирования и правила, связанные с процессом архитектурного проектирования [10].

Правила, связанные с выбором архитектурных решений:

1. Архитектура должна описываться в терминах четко определенных модулей, при проектировании которых должны использоваться принципы сокрытия информации и разделения ответственности. Модули должны быть сконструированы таким образом, чтобы в случае необходимости изменений, это можно было сделать в рамках модуля. Модули должны иметь четко определенные интерфейсы, что должно обеспечивать возможность работы над проектами нескольким независимым командам разработчиков.

2. Модули должны отражать разделение ответственностей. Система должна быть построена таким образом, чтобы требуемые значения могли быть достигнуты посредством использования проверенных архитектурных решений (стилей, паттернов) и тактик. (Типовые архитектурные тактики будут описаны в следующем параграфе.)

3. Нет зависимости от конкретных версий коммерческих продуктов и инструментальных средств, которые используются при проектировании системы. Архитектура должна быть спроектирована таким образом, чтобы издержки при портировании системы на новые версии продуктов и другие платформы были минимальны.

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

5. Процессы и задачи, решаемые отдельными модулями, должны быть четко определены.

6. Не следует ставить во главу угла принцип «один модуль - один компонент». Например, функции модуля обработки могут решать несколько параллельно работающих процессоров.

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

8. В рамках архитектуры должно использоваться малое число простых типов взаимодействия между модулями.

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

Правила, связанные с архитектурным процессом:

1. Архитектура должна разрабатываться одним архитектором или небольшой группой архитекторов, имеющей лидера. Это должно обеспечить концептуальную целостность архитектурных решений. Следует отметить, что данная рекомендация относится как к традиционным, так и к гибким методологиям проектирования. Особое внимание следует обратить на необходимости тесной связи между архитектором и командой разработчиков. В противном случае появляются нежизнеспособные архитектурные решения.

2. Архитектор (команда архитекторов) на каждый конкретный момент времени должен иметь актуальный ранжированный список требований. Это касается, прежде всего, нефункциональных требований, поскольку архитектор вынужден постоянно принимать компромиссные решения.

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

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

5. Архитектура должна разрабатываться по инкрементному принципу. Сначала следует спроектировать прототипную (скелетную) архитектуру с минимальной функциональностью, а затем постепенно наращивать функциональность. Попытки решить все проблемы за один проход обычно не приводят к успеху.

Можно выделить несколько формальных признаков того, что архитектурный процесс реализуется ненадлежащим образом, которые можно рассматривать как признаки «плохой» архитектуры:

1. Группа разработчиков не может назвать архитектора.

2. Количество компонентов верхнего уровня очень велико (больше 20).

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

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

5. Одно требование ведет весь проект.

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

7. Определение компонентов идет от используемой аппаратуры.

8. Имеется избыточность, не диктуемая надежностью.

9. Проектом движут исключения.