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