2. ОБЗОР ТЕРМИНОВ И ПОНЯТИЙ АРХИТЕКТУРИЗАЦИИ
2.1. Основные термины
Основная терминология описания архитектуры закреплена в ГОСТ Р
57100-2016/ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия.
Описание архитектуры».
Архитектуризации (architecting) - процесс понимания, определения, выражения, документирования, взаимодействия, соответствующей сертификации при реализации, сопровождении и улучшении архитектуры в жизненном цикле системы.
Архитектура (системы) (architecture) – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
Описание архитектуры (architecture description) – рабочий продукт, используемый для выражения архитектуры.
Архитектурное представление (architecture view) – рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.
Точка зрения на архитектуру (architecture viewpoint) - рабочий продукт, устанавливающий условности конструирования, интерпретации и использования архитектурного представления для структуризации определенных системных интересов.
Заинтересованная сторона, правообладатель (stakeholder) –индивидуум, команда, организация или их группы, имеющие интерес в системе.
На рисунке 1 изображены понятия, имеющие отношение к практике описания архитектуры для создания одного описания архитектуры, выражающего одну архитектуру для одной рассматриваемой системы.
Рис. 1. Описание архитектуры
10
Принципы архитектуризации:
архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;
уровень детализации архитектуры выбирается таким, что "опускается" вся информация о компонентах, которая не имеет значения вне вопросов взаимодействия с остальными компонентами архитектуры;
поведение компонент является частью архитектуры настолько, насколько это важно с точки зрения взаимодействия с другими компонентами;
каждая система имеет архитектуру – даже система, которая состоит из одной компоненты;
архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;
определения архитектуры не содержат описания самих компонент.
2.2. Уровни архитектуры
Архитектурой предприятия называются информационные составляющие, которые определяют:
-структуру бизнеса;
-информацию, которая необходима для ведения этого бизнеса;
-технологии, которые необходимы, чтобы поддерживать деловые операции;
-переходные процессы (процессы преобразования, развития), которые необходимы для реализации новых технологий в ответ на появление новых изменяющихся бизнес-потребностей.
Модель Архитектуры Предприятия представлена на рис. 2
необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура
Информационная система
IT-инфраструктура предприятия
совокупность программных продуктов
и интерфейсов между ними
базы данных и хранилища данных и
информационные потоки внутренние и внешние
Рис. 2. - Место архитектуры ИС в архитектуре предприятия
11
Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА)
— целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнесархитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.
Информационная архитектура (Enterprise Information Architecture, сокр.
EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:
федеративные данные (метаданные); моделирование данных; системы управления базами данных;
программное обеспечение промежуточного слоя (middleware) для доступа к данным;
механизмы доступа к данным;
безопасность данных.
Архитектура информационных систем (прикладных решений Enterprise Solution Architecture сокр. ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. Делится на два направления:
-область разработки прикладных систем (т.е. собственное ПО, например, для интеграции и сервисов);
-портфель прикладных систем (т.е. имеющегося ПО).
Тем не менее любой компонент – это отдельное ПО (CMS, почтовый сервер). Под "программной архитектурой" может пониматься как архитектура взаимодействия приложений в рамках информационной системы предприятия (т.е. архитектура приложений), так и архитектура программных модулей или архитектура взаимодействия различных классов в рамках одного приложения. Каждая из отмеченных архитектур, в свою очередь, может рассматриваться с тем или иным уровнем детализации и под определенным углом зрения.
Техническая (технологическая) архитектура (Enterprise Technical Architecture сокр. ETA) — совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Описывает полное представление инфраструктуры предприятия, включая:
информацию об инфраструктуре предприятия; системное программное обеспечение (СУБД, системы интеграции); стандарты на программно-аппаратные средства;
средства обеспечения безопасности (программно-аппаратные); системы управления инфраструктурой.
Плюс к этому добавляется и архитектура самого предмета автоматизации, например, датчики в охранной системе.
В данном учебном курсе рассматривается Архитектура программного обеспечения (англ. software architecture), т.е. совокупность важнейших
12
решений об организации программной системы. Архитектура (рис. 3) включает:
-выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
-соединение выбранных элементов структуры и поведения, во всё более крупные системы;
-архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение
Рис. 3. - Контекст описания архитектуры
2.3. Представление архитектуры «4
Представление«4+1» используются для описания системы с точки зрения разных заинтересованных лиц, таких как конечные пользователи, разработчики или руководители проекта. Четыре представления – это логическая структура, разработка, процессы и физическая структура системы. Дополнительно вводятся варианты использования, или сценарии, которые иллюстрируют описываемую архитектуру, т.е. четыре представления для каждого варианта использования. Поэтому говорят, что модель состоит из 4+1 представления (рис. 4).
13
Рис. 4. - Представление 4+1
Logical view: Логическое представление сфокусировано на функциональности, предоставляемой системой для конечных пользователей. В этом представлении используются UML-диаграммы классов, связей и последовательностей.
Development view: Представление разработки показывает систему с точки зрения разработчика и касается управления программой. Это представление также известно как представление реализации. Здесь используются UMLдиаграммы компонентов и пакетов для описания компонентов системы и их объединения в логические пакеты (например, слои).
Process view: Представление процесса отражает динамические аспекты системы, показывает происходящие в системе процессы и связи между ними. Представление процесса фокусируется на поведении системы во время выполнения программы. Представление процесса отражает параллелизм выполнения, распределение, интеграцию, производительность, масштабирование и т.п. Представление процесса использует UML-диаграммы активности.
Physical view: Представление физической структуры показывает систему с точки зрения системного инженера. Она показывает распределение
14
программных компонентов по физическим уровням и физические каналы связи между уровнями. Это представление известно также как представление развёртывания системы. Представление физической структуры системы использует UML-диаграмму развёртывания.
Scenarios: Описание архитектуры системы должно быть проиллюстрировано небольшим набором вариантов использования, или сценариев. Этот набор сценариев составляет пятое представление модели Крачтена. Сценарии должны описывать взаимодействие между объектами и между процессами. Сценарии используются для идентификации архитектурных элементов и для иллюстрирования и проверки качества архитектуры системы. Они также служат отправной точкой для тестирования архитектурного прототипа системы. Сценарии описываются UML-диаграммами вариантов использования.
Рис. 5. - Различные точки зрения на программную систему
15