Обычно деградируют, требуя постоянного латания дыр, пока наконец это не

Развитию. Плохо спланированные системы, напротив, с течением времени

Словами, система должна быть гибкой, или устойчивой к изменениям. Другой

Не вызвав при этом разрушения существующего проекта и реализации. Другими

В неожиданном месте системы. В большинстве случаев они должны иметь возможность

Не заботясь о том, что последствия этих изменений вдруг проявятся где-то

В окружающей среде приведут к ее дальнейшему развитию. В течение обоих

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

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

добавить к системе новую функциональность (то есть варианты использования),

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

становится просто невыгодно. __

Пример. Система АХЕ фирмы Ericsson. О важности архитектуры. Начало разработки

системы телекоммуникационного оборудования АХЕ фирмы Ericsson

приходится на 1970-е годы. Уже тогда в разработке использовалась ранняя версия

наших архитектурных постулатов. Описание архитектуры программного обеспечения

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

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

постулатами, которые теперь включены в Унифицированный процесс.

Один из этих постулатов — принцип модульности функций. Классы или эквивалентные

им проектные элементы были сгруппированы в функциональные блоки,

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

модулями (даже если блоки поставлялись всем клиентам). Сервисная

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

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

затрагивали большее число подсистем.

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

подсистем. Целью было создать «подключаемые» проектные решения

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

Смена одной сервисной подсистемы на другую могла бы в этом случае

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

интерфейсы, а не код сервисных подсистем.

Третьим принципом было непосредственное сопоставление сервисных подсистем

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

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

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

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

центральном компьютере (сервере), то существовал всего один компонент сервисной

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

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

вносимыми в программы в различных установках.

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

Единственным средством связи между сервисными подсистемами были

сигналы. Так как сигналы асинхронны (семантика «посылка-без-ожидания», то

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

но и распределенное выполнение.

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

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

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

при условии регулярного обновления она проживет еще десятки лет.