Глава 4. Сравнительное сопоставление архитектурных видов

Все представленные выше архитектурные концептуальные схемы создают и поддерживают эволюционное развитие «собственных» понятийных схем. Причина - разнообразие предметных областей ПО, каждая из которых имеет специфику, которую и стараются учесть в «собственной » концептуальной схеме. На сегодня единой теории и практики архитектуры ПО нет. Стандарт IEEE-1471 - не догма, а руководство к действию. Единая архитектурная концептуальная схема, детализирующая, например, типологию видов, моделей и документов не создана.

4.1. Сопоставление систем видов

Архитектура «4+1»

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

При использовании подхода «4+1» разработчики ПО начинают формирование архитектуры с типичного набора видов, представленного на рис. 26.

Рисунок 26. Модель "4+1"

Набор видов включает:

1. Use case вид, который содержит прецеденты и сценарии, охватывающие архитектурно существенное поведение, классы или технические риски. Вид является подмножеством модели прецедентов.

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

3. Вид с позиции разработки, который содержит краткий обзор модели выполнения в терминах модулей пакетов и уровней. Здесь описывается также распределение пакетов и классов (из логического представления) в пакетах и модулях представления выполнения. Это представление является подмножеством модели выполнения.

4. Вид с позиций процесса, содержащий описание задач (процессов и нитей), их взаимодействия и конфигурации и распределения объектов и классов по задачам. Потребность этого представления возникает, только если система имеет существенную степень параллелизма. В Rational Unified Process 5.1 представление процесса - это подмножество модели проекта.

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

Дополнительные представления, например для представления интерфейса пользователя, представления защиты и представление данных не отвергаются, но ответственность за их связывание с базой «4+1» ложится на разработчиков ПО.

Перечисленные выше представления могут изобразить проект системы в целом. Но архитектура интересуется только некоторыми определенными аспектами:

Структура модели - организационные элементы, например, иерархическое представление.

Существенные элементы - критические прецеденты, главные классы, общие механизмы и так далее, а не все элементы, представленные в модели.

Несколько ключевых сценариев, показывающих главный поток управления в системе.

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

Архитектурные решения SEI

В Институте Программной Инженерии (SEI) [1] разработан подход к формированию архитектуры, исходящий из того, что для конкретного ПО, кроме базовых «точек зрения», может потребоваться дополнительный набор видов. А значит, архитектору должны быть предоставлены возможности создания необходимых ему типовых видов, в частности «box and line» средства.

Предлагается комплект средств выражения и методик для такой работы. Но главный акцент предлагается направить на работу с видами с позиций качества (Рис. 27). Значения характеристик качества должны оцениваться и, если значения не соответствуют требованиям, то в построении архитектуры должен происходить «возврат» к предшествующим шагам архитектурного моделирования для внесения коррекций в архитектуру или даже для принятия новых архитектурных решений.

Рисунок 27. Архитектурные решения SEI

Архитектурные решения SEI согласованы со стандартом ИСО/МЭК 9126. Особое внимание рекомендуется уделять рассуждениям в группе разработчиков и документированию решений.

Архитектурные решения RM ODP

Архитектурные решения RM-ODP [2] предоставляют пять точек зрения (рис. 28) на систему:

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

- информационная точка зрения описывает выражение (проявление) и семантику обрабатываемых системой данных, форматы и модели данных;

- компонентная (вычислительная) точка зрения описывает разделение приложения на функциональные модули и определяет их интерфейсы;

- инженерная точка зрения представляет распределение отдельных элементов системы по физическим ресурсам, а также их связи;

- технологическая точка зрения описывает технологии, используемые при реализации системы.

Рисунок 28. Архитектурные решения RM ODP

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

Архитектурные решения SIMENS

В архитектурных решениях Siemens (Рис. 29) использование «концептуального вида» в системе «видов» было предложено до создания языка UML, в котором необходимость визуального концептуального моделирования в разработках ПО была переведена на уровень стандарта.

Система видов включала:

- концептуальный вид как описание архитектуры системы в понятиях, раскрывающих основные элементы ПО и связи между ними;

- модульный вид, раскрывающий функциональную декомпозицию ПО и распределение по уровням детализации;

- вид исполнения, специфицирующий динамическую структуру ПО;

- вид с позиций кодов, включающий кодовые компоненты и их библиотечную организацию в среде разработки.

Рисунок 29. Архитектурные решения SIMENS

Архитектурные решения ADS

Подход «Cпецификации рационального описания архитектуры (Rational ADS)» развивает подход «4+1» до его применений, включающих автоматизированные производственные системы, встроенные системы и другие системы, в которых может отсутствовать программное обеспечение. Вариант расширения представлен на рис. 30.

Рисунок 30. Архитектурные решения ADS

В архитектуре виды распределены между четырьмя «точками зрения» (Требования, Проектирование, Реализация и Верификация). Содержание видов соответствует содержанию видов, рассмотренных выше, или понятно из названия. Архитектура нашла свое воплощение в инструментально-технологической среде RUP. Она согласована со стандартами ISO/MEK-12207 и IEEE-1471.