Процесс, ориентированный на разработку архитектуры системы

Архитектура – общий взгляд на систему, с которым согласны все разработчики системы

Архитектура – ясный взгляд на систему в целом, дающий возможность управлять ее разработкой

Архитектура – описывает наиболее важные элементы модели, которые

· управляют работой в каждой конкретной итерации

· управляют работой через весь жизненный цикл

Архитектура – содержит некоторые из:

· подсистем

· интерфейсов

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

· зависимостей

· взаимодействий

· активных классов

которые позволяют:

· понять систему

· разработать систему

· оценить стоимость разработки системы

Архитектор проходит несколько итераций в фазах:

· Inception (начальная, анализа и планирования)

· Elaboration (исследование) цель фазы исследования – разработать архитектуры в виде выполняемого фундамента (architecture baseline)

· Construction (конструирование) – на фазе конструирования есть прочный фундамент для построения полной системы

· Deployment (внедрение)

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

Архитектор дает взаимосвязанные виды, проекции (view) системы с помощью UML-диаграмм

Архитектор принимает решения о:

· организации программной системы

· структурных элементах и их интерфейсах, о взаимодействии элементов (collaborations)

· композиции элементов структуры и поведения в пакеты

· структурных элементах и их интерфейсах, о взаимодействии элементов (collaborations)

· Описание архитектуры: для каждой модели 4 + 1 вида

Модель представления архитектуры 4 + 1

Модель 4+1

· Прецеденты

o Ключевые сценарии и прецеденты. Используются для задания направления поиска других представлений.

· Логическое представление

o Функциональные требования системы (что нужно пользователю)

o Абстракция модели проектирования

§ Пакеты

§ Подсистемы

§ Классы

· Реализационное представление

o Организация статических программных кодов

§ тексты

§ данные

§ компоненты

§ исполняемые коды

в терминах пакетов, уровней, управления конфигурациями

· Процедурное представление

o Параллельность

§ задач

§ потоков

§ процессов

§ их взаимодействие

o Распределенность объектов

o Отказоустойчивость

· Представление внедрения

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

Описание архитектуры

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

Первая версия описания архитектуры появляется в конце фазы Elaboration

Сложно сохранить описание системы небольшим

Зачем нужна архитектура?

· Для понимания системы

· Для организации разработки системы

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

· Для развития системы в дальнейшем

Понимание системы

· Сложное поведение системы

· Работа в сложном окружении – сложно интегрировать во множество компонент, разработанных сторонними разработчиками

· Используются сложные технологии (EJB или COM)

· Используют и индивидуальные пользователи, и группы пользователей

· Разрабатываются распределено (географически) и поэтому необходимо координировать работу

Организация разработки

· Организация разработки существенно упрощается, если может выполняться распределенно и параллельно

· Назначение групп ответственных за подсистемы дает возможность распределённости и независимости

· Стабильные интерфейсы – позволяют независимо развивать программу по обе стороны интерфейса

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

Шаблоны архитектуры

· Façade – предназначен для создания упрощенного интерфейса для группы подсистем или сложной подсистемы

o Область применения:

§ Необходимо предоставить более простой вариант стандартного интерфейса

§ Уменьшить зависимость клиента от подсистемы

§ Нужно создать слои подсистемы

· Decorator – представление механизма для добавления или удаления функциональности компонентов без изменения их внешнего представления или функции

o Назначение:

§ Необходимо динамически менять свойства классов

· незаметно для пользователя класса

· не испытывая ограничения механизма наследования классов

§ Свойства компонента динамически включаются и отключаются

§ Есть несколько независимых функций, применяемых:

· динамически

· в разной комбинации

· Layers – способ организации модели проектирования на уровни

o Компоненты одного уровня могут ссылаться только на компоненты нижнего уровня:

=> Упрощение: Компоненты нижнего уровня не зависят от:

· интерфейсов верхнего уровня

· реализации верхнего уровня