Архитектурное проектирование. Факторы, влияющие на архитектуру системы: производительность, защищенность, безопасность, надежность, удобство сопровождения.

Этапы архитектурного проектирования:

1) Структурирование системы. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами.

2) Моделирование управления. Разрабатывается базовая модель управления между частями системы.

3) Модульная декомпозиция. Каждая, определённая на первом этапе подсистема, разбивается на отдельные модули.

Как правило, эти этапы перемежаются и накладываются друг на друга. Этапы повторяются для более детальной проработки архитектуры, до тех пор, пока архитектурный проект не будет удовлетворять системным требованиям.

Подсистема – система, операции которой не зависит от сервисов, предоставляемых другими подсистемами. Подсистемы состоят из модулей и имеют определённые интерфейсы, с помощью которых взаимодействуют с другими подсистемами.

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

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

· статическая структурная модель - подсистемы разрабатываются независимо.

· динамическая модель процессов - организация процессов во время работы системы.

· интерфейсная модель - определяются сервисы, предоставляемые каждой подсистемой через общий интерфейс.

· модели отношений - рассматриваются взаимоотношения между частями системы.

 

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

 

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

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

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

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

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

5. Лёгкость сопровождения. В этом случае архитектуру системы следует проектировать

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