Развитию. Плохо спланированные системы, напротив, с течением времени
Словами, система должна быть гибкой, или устойчивой к изменениям. Другой
Не вызвав при этом разрушения существующего проекта и реализации. Другими
В неожиданном месте системы. В большинстве случаев они должны иметь возможность
Не заботясь о том, что последствия этих изменений вдруг проявятся где-то
В окружающей среде приведут к ее дальнейшему развитию. В течение обоих
этих периодов система должна с легкостью воспринимать изменения. Это означает,
что разработчики должны иметь возможность изменять части проекта и реализации,
добавить к системе новую функциональность (то есть варианты использования),
способ обозначить эту цель — сказать, что система должна быть способна к аккуратному
становится просто невыгодно. __
Пример. Система АХЕ фирмы Ericsson. О важности архитектуры. Начало разработки
системы телекоммуникационного оборудования АХЕ фирмы Ericsson
|
|
приходится на 1970-е годы. Уже тогда в разработке использовалась ранняя версия
наших архитектурных постулатов. Описание архитектуры программного обеспечения
было важным артефактом, направляющим процессы разработки в течение
всего срока жизни системы. Разработка архитектуры направлялась несколькими
постулатами, которые теперь включены в Унифицированный процесс.
Один из этих постулатов — принцип модульности функций. Классы или эквивалентные
им проектные элементы были сгруппированы в функциональные блоки,
или сервисные подсистемы, с которыми клиенты могли работать как с дополнительными
модулями (даже если блоки поставлялись всем клиентам). Сервисная
подсистема имела большую внутреннюю связность. Изменения, вносимые
в систему, обычно локализовались в пределах одной сервисной подсистемы и редко
затрагивали большее число подсистем.
Другим принципом было разделение проектирования интерфейсов и проектирования
подсистем. Целью было создать «подключаемые» проектные решения
с тем, чтобы несколько сервисных подсистем могли использовать одинаковый интерфейс.
Смена одной сервисной подсистемы на другую могла бы в этом случае
быть проделана без изменения клиентам сервисной подсистемы, которым важны
интерфейсы, а не код сервисных подсистем.
Третьим принципом было непосредственное сопоставление сервисных подсистем
проектирования одному или нескольким компонентам реализации. Компоненты
сервисных подсистем могли быть по-разному распределены между узлами.
Для каждого узла, на котором выполнялась сервисная подсистема, существовал
|
|
ровно один компонент. Таким образом, если сервисная подсистема запускалась на
центральном компьютере (сервере), то существовал всего один компонент сервисной
подсистемы. Если сервисная подсистема запускалась и на сервере, и на клиенте,
компонентов было два. Применение этого принципа помогало управлять изменениями,
вносимыми в программы в различных установках.
Еще один принцип предусматривал низкую связность между сервисными подсистемами.
Единственным средством связи между сервисными подсистемами были
сигналы. Так как сигналы асинхронны (семантика «посылка-без-ожидания», то
есть система, послав сигнал, не ждет ответа), они поддерживают не только инкапсуляцию,
но и распределенное выполнение.
Поскольку и начало ее разработки, и ее продолжение производилось на основе
правильно разработанной архитектуры, система АХЕ продолжает использоваться
и сегодня, имея более ста клиентов и несколько тысяч установок. Ожидается, что
при условии регулярного обновления она проживет еще десятки лет.