Презентации / Lecture07p

Архитектура ПО

Основы программной инженерии

Кулямин В.В., ВМК МГУ

Деятельности при проектировании ПО

•Анализ области решений

•Для сформулированных задач может быть много совершенно различных методов решения

•Нужно сопоставить их характеристики и выбрать наиболее подходящие для реализации

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

•Проектирование структуры ПО

•Выделение компонентов/модулей выбранных для реализации решений

•Определение их интерфейсов

•Проектирование архитектуры ПО

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

•Детальное проектирование

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

Структура и архитектура ПО

• Структура ПО

•Набор компонентов

•Набор связей между ними (зависимости или использование)

• Архитектура ПО

•Типы компонентов

•Основные сценарии взаимодействия компонентов (в зависимости от типа)

•Правила добавления новых компонентов

•Правила модификации компонентов

Влияние на свойства

•Функциональность

•Может быть реализована с похожим результатом в разных наборах компонентов

•Надежность

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

•Производительность

•Кэширование, распараллеливание, асинхронность, и пр.

•Совмещение задач

•Переносимость

•Внешние модули для работы с разными форматами данных и интерфейсами

•Защищенность

•Отдельные модули политик защиты, их использование во всех местах, где нужна защита

•Удобство сопровождения

•Соответствие между архитектурой и сценариями развития системы

Пример: симулятор полетов

•Структура на предыдущем слайде получена с помощью функциональной декомпозиции

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

•Нужно отнести новую задачу к одному из представленных модулей

•Или вынести ее в отдельный компонент

Пример: симулятор полетов

Пример: симулятор полетов

На предыдущем слайде – архитектура в стиле репозитория

•Все компоненты делятся на

•Репозиторий – хранилище событий всех типов

•Обработчики событий, которые ждут определенные типы событий и при их возникновении модифицируют некоторые события в репозитории по определенным правилам

•Поставщики событий, заносящие новые события в репозиторий

•Потребители событий, которые ждут определенные типы событий и перерабатывают их в некоторые выводимые данные

Разработка архитектура на базе сценариев

•Выделение компонентов

•Определить набор основных сценариев использования

•Выделить компоненты, играющие определенные роли в сценариях

•Переформировать компоненты в соответствии с выбранным архитектурным стилем

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

•Определение интерфейсов

•Сформировать базовый интерфейс на основе обращений к компоненту в сценариях

•Расписать все остальные сценарии

•Переформировать интерфейсы и набор компонентов для реализации всех сценариев

•Достижение нужных свойств

•Переформировать компоненты для получения нужной производительности, надежности, совместимости, защищенности

•Переформировать компоненты для поддержки наиболее вероятных изменений

Оценка архитектур на базе сценариев

SAAM – Software Architecture Analysis Method

•Определить архитектуру (-ры) для анализа

•Определить набор сценариев вероятных изменений

•Оценить поддержку сценариев

•Сценарий может поддерживаться сразу, может требовать добавления компонентов, может требовать модификации компонентов

•Добавление совсем нового компонента оценивается выше, чем добавление типового

•Модификация оценивается выше, чем добавление (небольшая – примерно в добавление 1-2 компонентов, большая – в 2-3)

•Выявить взаимодействие сценариев в рамках одной архитектуры – компоненты, модификации которых требуются во многих сценариях

•Их наличие говорит о (возможно) недостаточной модуляризации

•Оценить архитектуру (-ры) в целом