Архитектура программной системы
Архитектура программы или компьютерной системы - это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними. [Басс (Bass) и др.]5
[Архитектура - это] структура организации и связанное с ней поведение системы. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы. [UML 1.5]6
Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Модель архитектуры 4+1 (RUP)
Представление прецедентов
Прецеденты и сценарии, охватывающие архитектурно-значимое поведение,
затрагивающие архитектурно-значимые классы и технические риски
Является подмножеством модели прецедентов.
Логическое представление
Наиболее существенные классы проекта, их организация в пакеты (подсистемы)
Описание прецедентов в терминах классов
Подмножество проектной модели.
Представление реализации (выполнения)
Модель реализации в терминах модулей, пакетов и уровней (в многослойных архитектурах)
Распределение пакетов и классов логического представления в пакетах и модулях модели реализации
Подмножество модели реализации.
Представление процесса
Описание задач (процессов и нитей), их взаимодействия и распределения объектов и классов по задачам
Используется для существенно распараллеленных систем
Подмножество проектной модели.
Представление развертывания
Описание физических узлов для типичных конфигураций платформы
Распределение задач по физическим узлам
Используется для распределенных систем
Подмножество модели развертывания.
" Круг интересов" архитектуры
Структура
Контекстная диаграмма (например, DFD)
Диаграмма пакетов
Диаграмма классов
Диаграмма компонентов
Диаграмма развертывания.
Поведение
Возможности
Сервисы
Варианты использования.
Значимые элементы
Критические прецеденты
Главные классы
Основные протоколы взаимодействия
Схемы управления.
Потребности заинтересованных лиц
Конечный пользователь заинтересован в интуитивно понятном и корректном поведении, производительности, надежности, удобстве использования, доступности и безопасности;
Системный администратор заинтересован в интуитивно понятном поведении, управлении и инструментах мониторинга;
Специалист по маркетингу заинтересован в конкурентоспособных функциях, времени до выхода программы, позиционировании среди других продуктов и в стоимости.
Клиент заинтересован в цене, стабильности и возможности планировать;
Разработчик заинтересован в понятных требованиях и простом и непротиворечивом принципе проектирования;
Руководитель проекта заинтересован в предсказуемости хода проектирования, планировании, продуктивном использовании ресурсов и бюджета;
Специалист по сопровождению заинтересован в понятном, непротиворечивом и документируемом принципе проекта, а также в легкости, с которой можно вносить изменения.
Логическое обоснование
Документирование архитектуры
Документирование аргументов в пользу тех или иных архитектурных решений
Архитектурный стиль
Окружение
Окружение влияет на архитектуру («Архитектура в контексте»):
Особенности бизнеса
Позиции заинтересованных лиц
Внутренние и внешние ограничения
Архитектура влияет на окружение.
Команда разработчиков.
Архитектура влияет на команду:
Архитектура определяет компетенции
Архитектура определяет параллелизм выполнения.
Команда влияет на архитектуру.
Значимые элементы
Критические прецеденты
Главные классы
Основные протоколы взаимодействия
Схемы управления.
То есть общие механизмы проектируемой системы
Архитектурный стиль
Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Например, архитектура распределенной сервисно-ориентированной системы может строится в стиле обмена сообщениями через соответствующие очереди сообщений, может проектироваться на основе идеи взаимодействия между компонентами и приложениями через общую объектную шину, а может использовать концепцию брокера как единого узла пересылки запросов. В то же время, на более концептуальном уровне, мы можем говорить о выборе клиент-серверного стиля или распределенного стиля архитектуры системы. Таким образом, архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям.
Метафора "что и как"
По сути своей это понимание того, что и как система будет делать.
Метафоры
Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем понятное явление с чем-то похожим, но более понятным, вы можете догадаться, как справиться с проблемой. Такое использование метафор называется моделированием».
Анализ и Проектирование
Цель процесса анализа и проектирования состоит в разработке технических инструкций, предписывающих, как реализовать ПС, удовлетворяющую сформулированным требованиям. Для этого следует хорошо понять требования к ПС и преобразовать их в проект системы, выбрав правильную стратегию реализации. На ранних стадиях процесса должна быть создана устойчивая архитектура, на основе которой можно спроектировать ПС, легкую для понимания, построения и развертывания. Архитектура должна быть согласована со средой реализации с целью удовлетворения требований к производительности, устойчивости, безопасности, расширяемости и тестируемости.
К числу решаемых задач при этом относятся:
разработка точной архитектуры распределенной программной системы;
преобразование модели требований в модель проектную разрабатываемой системы;
адаптация проекта системы к среде реализации с целью повышения производительности разработки;
выбор механизмов реализации и определение ограничений на реализацию;
разработка компонентной структуры;
распределение компонентов по узлам.
Главной задачей анализа является преобразование требований в форму, понятную разработчику, то есть, определение подсистем, компонентов и классов, с помощью которых реализуется требуемое поведение ПС. В основе такого преобразования лежат ВИ, созданные при определении требований к ПС. При этом рассматриваются только функциональные требования и игнорируются нефункциональные.