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

Более-менее существенного размера будет эволюционировать. Она эволюционирует

Если есть что-то, в чем мы можем быть уверены, так это то, что любая система

Развитие системы

Повторное использование

Для того чтобы объяснить важность архитектуры для повторного использования

компонентов, приведем аналогию. Такое занятие, как прокладка труб, уже давно__

дартизации

компонентов. Вместо того, чтобы биться над подгонкой размеров «творчески

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

стандартного набора всегда совместимых деталей.

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

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

В) и уметь подобрать подходящие для данной архитектуры компоненты. Разработчики

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

требования и реализовать модель вариантов использования. Если многократно

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

водопроводная арматура, программные компоненты, предназначенные для

многократного использования, разрабатываются и тестируются в расчете на совместную

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

и дешевле обходится. Результат предсказуем. Как и в сантехнике, где стандартизация

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

также требует опыта, но мы ожидаем, что массовая «компонентизация» произойдет

всего за несколько лет. На самом деле она уже началась.

Производству программ еще предстоит достичь того уровня стандартизации, который

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

и четкие интерфейсы — это шаги в правильном направлении. Хорошая архитектура

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

дальше. Работа архитектора — создать этот базис и определить, какие подсистемы

многократного использования должны использовать разработчики. Многократно

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

они могли использоваться совместно [49]. Хорошая архитектура помогает разработчикам

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

и находить их. UML ускорит процесс перехода на компоненты, поскольку

стандартный язык моделирования — это предпосылка для построения проблемно-

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