Архитектура программной системы

Архитектура программы или компьютерной системы - это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними. [Басс (Bass) и др.]5

[Архитектура - это] структура организации и связанное с ней поведение системы. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы. [UML 1.5]6

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

Модель архитектуры 4+1 (RUP)

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

• Прецеденты и сценарии, охватывающие архитектурно-значимое поведение,

• затрагивающие архитектурно-значимые классы и технические риски

• Является подмножеством модели прецедентов.

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

• Наиболее существенные классы проекта, их организация в пакеты (подсистемы)

• Описание прецедентов в терминах классов

• Подмножество проектной модели.

Представление реализации (выполнения)

• Модель реализации в терминах модулей, пакетов и уровней (в многослойных архитектурах)

• Распределение пакетов и классов логического представления в пакетах и модулях модели реализации

• Подмножество модели реализации.

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

• Описание задач (процессов и нитей), их взаимодействия и распределения объектов и классов по задачам

• Используется для существенно распараллеленных систем

• Подмножество проектной модели.

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

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

• Распределение задач по физическим узлам

• Используется для распределенных систем

• Подмножество модели развертывания.

" Круг интересов" архитектуры

• Структура

• Контекстная диаграмма (например, DFD)

• Диаграмма пакетов

• Диаграмма классов

• Диаграмма компонентов

• Диаграмма развертывания.

• Поведение

• Возможности

• Сервисы

• Варианты использования.

• Значимые элементы

• Критические прецеденты

• Главные классы

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

• Схемы управления.

• Потребности заинтересованных лиц

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

• Системный администратор заинтересован в интуитивно понятном поведении, управлении и инструментах мониторинга;

• Специалист по маркетингу заинтересован в конкурентоспособных функциях, времени до выхода программы, позиционировании среди других продуктов и в стоимости.

• Клиент заинтересован в цене, стабильности и возможности планировать;

• Разработчик заинтересован в понятных требованиях и простом и непротиворечивом принципе проектирования;

• Руководитель проекта заинтересован в предсказуемости хода проектирования, планировании, продуктивном использовании ресурсов и бюджета;

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

• Логическое обоснование

• Документирование архитектуры

• Документирование аргументов в пользу тех или иных архитектурных решений

• Архитектурный стиль

• Окружение

• Окружение влияет на архитектуру («Архитектура в контексте»):

• Особенности бизнеса

• Позиции заинтересованных лиц

• Внутренние и внешние ограничения

• Архитектура влияет на окружение.

• Команда разработчиков.

• Архитектура влияет на команду:

• Архитектура определяет компетенции

• Архитектура определяет параллелизм выполнения.

• Команда влияет на архитектуру.

Значимые элементы

• Критические прецеденты

• Главные классы

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

• Схемы управления.

То есть общие механизмы проектируемой системы

Архитектурный стиль

Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Например, архитектура распределенной сервисно-ориентированной системы может строится в стиле обмена сообщениями через соответствующие очереди сообщений, может проектироваться на основе идеи взаимодействия между компонентами и приложениями через общую объектную шину, а может использовать концепцию брокера как единого узла пересылки запросов. В то же время, на более концептуальном уровне, мы можем говорить о выборе клиент-серверного стиля или распределенного стиля архитектуры системы. Таким образом, архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям.

Метафора "что и как"

По сути своей это понимание того, что и как система будет делать.

Метафоры

Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем  понятное явление с чем-то похожим, но более понятным, вы можете догадаться,  как справиться с проблемой. Такое использование метафор называется моделированием». 

Анализ и Проектирование

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

К числу решаемых задач при этом относятся:

• разработка точной архитектуры распределенной программной системы;

• преобразование модели требований в модель проектную разрабатываемой системы;

• адаптация проекта системы к среде реализации с целью повышения производительности разработки;

• выбор механизмов реализации и определение ограничений на реализацию;

• разработка компонентной структуры;

• распределение компонентов по узлам.

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