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

· Архитектор может определить повторно используемые подсистемы тщательно проектируя их

· Архитектор может определить повторно используемые компоненты

· UML ускоряет создание повторно используемых подсистем и компонент

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

· Архитектор должен решать более общую задачу

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

· Развитие стимулируется изменением окружения системы

· Может потребоваться новая функциональность системы

· Необходима устойчивость системы при ее изменении, а не ее деградация.

Принципы разработки системы

1. Функциональная модульность. Классы группируются в optional сервисные подсистемы SSS. SSS имеют только внутреннее сцепление (cohesion) => SSS независимы.

2. Отделение проектирования интерфейсов от проектирования SSS

a. => несколько SSS могут поддерживать тот же интерфейс

b. => возможна замена подсистем, поскольку зависимость клиента только от интерфейса

3. SSS – на этапе проектирования помещается в отдельную компоненту

a. => компоненты могут быть размещены на разные вычислительные узлы

4. Необходимо уменьшение сцепления между SSS.

a. => единственный способ общения между подсистемами через асинхронные сигналы

b. => поощряется не только инкапсуляция, но и распределенность

Взаимосвязь прецедентов и архитектуры

Шаги к архитектуре

· Результат фазы Elaboration – фундамент архитектуры (скелет системы).

· Выбор прецедентов для построения архитектуры

o те которые позволяют оценить наиболее серьезные риски

o наиболее важная функциональность для пользователя

· Реализация, интеграция и тестирование фундамента архитектуры приводит к демонстрационной версии системы от которой идет обратная связь

· Фундамент архитектуры – небольшая тощая система, которая имеет все модели, которые имеет полная система в конце конструирования

· Фундамент имеет скелет для:

o Подсистем

o Компонент

o Вычислительных узлов

o Поведение

o Исполняемый код

· После стабилизации фундамента архитектуры заканчивается фаза уточнения.

Модель прецедентов

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

В нашей модели (условно) наиболее важным будем считать прецедент WithdrawMoney.

Модель проектирования

· Наиболее важные подсистемы

· Интерфейсы

· Несколько особенно важных классов

· Активные классы

· Реализация наиболее важных прецедентов с помощью описанных в архитектуре классификаторов

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

Модель проектирования архитектуры:

· Активные классы

Все активные классы включаются в описание модели проектирования архитектуры.

Классы необходимые для понимания реализации прецедента WithdrawMoney.

 

· Подсистемы и их интерфейсы

Подсистемы и интерфейсы необходимые для понимания реализации прецедента WithdrawMoney.

· Реализация прецедента WithdrawMoney

Взаимодействие подсистем для реализации прецедента WithdrawMoney