СРАВНИТЕЛЬНОЕ АРХИТЕКТУРНЫХ ОПОСТАВЛЕНИЕ ВИДОВ

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

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

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

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

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

Логический вид ___

Физический вид

Use-case

Вид процессов |

Рис. 26. Модель «4+1»

Набор видов включает следующее.

  • 1. Use case вид, который содержит прецеденты и сценарии, охватывающие архитектурно существенное поведение, классы или технические риски. Вид является подмножеством модели прецедентов.
  • 2. Логический вид, который содержит наиболее важные классы проекта, их организацию в пакеты и подсистемы различных уровней. Здесь содержится уже некоторая реализация прецедента. Это представление является подмножеством модели проекта.
  • 3. Вид с позиции разработки, который содержит краткий обзор модели выполнения в терминах модулей пакетов и уровней. Здесь описывается также распределение пакетов и классов (из логического представления) в пакетах и модулях представления выполнения. Это представление является подмножеством модели выполнения.
  • 4. Вид с позиций процесса, содержащий описание задач (процессов и нитей), их взаимодействия и конфигурации и распределения объектов и классов по задачам. Потребность этого представления возникает, только если система имеет существенную степень параллелизма. В Rational Unified Process 5.1 представление процесса — это подмножество модели проекта.
  • 5. Физический вид, который содержит описание различных физических узлов для наиболее типичных конфигураций платформы, и расположение задач (из представления процесса) по физическим узлам. Потребность этого представления возникает, только если система распределена.

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

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

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

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

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

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

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

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

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

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

^ Эффективность г

Качество

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

Г ~

Фнукциональность Мобильность Надежность

Сопровождаемость

Удобство

Архитектурные решения КМ (ЮР

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

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

Организационный вид

Архитектурные решения ЯМ СЮР

Рис. 28. Архитектурные решения ЯМ СЮР

Определение

требований

Определение

спецификаций

Проектирование

Реализация

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

Архитектурные решения БІМЕМБ

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

I___I

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

Концептуальный вид

Мобильный вид

И

С

П

О

Л

Н

Е

Н

И

Е

Г“

А

П

I П

I А

Р А I Т

I У

Р

А

Кодовый вид

| Исходный код

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

языка UML, в котором необходимость визуального концептуального моделирования в разработках ПО была переведена на уровень стандарта [21.

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

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

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

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

В архитектуре виды распределены между четырьмя «точками зрения» (Требования, Проектирование, Реализация и Верификация). Содержание видов соответствует содержанию видов, рассмотренных

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

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

выше, или понятно из названия. Архитектура нашла свое воплощение в инструментально-технологической среде RUP. Она согласована со стандартами ISO/MEK-12207 и IEEE-1471.

 
< Пред   СОДЕРЖАНИЕ     След >