System Engineering

# Системная инженерия. <br/> Архитектурное моделирование компьютерных систем

## Лекция 7-8

### Архитектурное документирование. Решения. Представления. <br/> Архитектурные стили

Пенской А.В., 2025

---

### Architecture. Architectural Specification

<dl>
  <dt> Architecture </dt>
  <dd>  is fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [ISO 42010]. </dd>
</dl>
 
<dl>
  <dt> Architectural Specification </dt>
  <dd>  work product used to express an architecture. </dd>
</dl>
 
</div><div class="col">

![](figures/hor-arch-desc.png)

![](figures/hor-arch-desc-processes.png)

</div></div>

----

## Архитектурное документирование

Architecture serves as:

1. a means of education
2. a primary vehicle for communication among stakeholders
3. the basis for system analysis and construction

В составе архитектурной документации:

1. Архитектурные представления
1. Архитектурные решения

</div><div class="col">

Все подробности тут:

![](figures/documenting-arch-book.png)

</div></div>

---

## Шаблон: <br/> Архитектурное представление

Структура документа:

1. Наименование представления
1. Основное представление
1. Каталог элементов (~ архитектурный стиль)
    - Элементы и их свойства
    - Отношения и их свойства
    - Интерфейсы элементов
    - Поведение элементов
1. Диаграмма контекста
1. Инструкции по вариативности
1. Обоснование

</div><div class="col">

<dl>
  <dt> Представление (View) </dt>
  <dd>  Представление системы с заданной точки зрения. </dd>
</dl>
 
![](figures/arch-view-template.png)

</div></div>

----

### Наименование представления

What you describe in the view.

### Основное представление

The **primary presentation** shows the elements and relations of the view. The primary presentation should contain the information you wish to convey about the system.

----

### Каталог элементов (Element Catalog)

The **element catalog** details at least those elements depicted in the primary presentation. E.g., if a diagram shows elements A, B, and C, then the element catalog needs to explain what A, B, and C are and their purposes or the roles they play.

Подразделы:

- Элементы и их свойства
- Отношения и их свойства
- Интерфейсы элементов
- Поведение элементов

----

#### Элементы и их свойства (Elements and properties)

This section names each element in the view and lists their properties. Properties depend on the architectural style, e.g., a decomposition style might have a "responsibility" property — the module's role in the system.

#### Отношения и их свойства (Relations and properties)

Mostly, these relations are shown in the primary presentation. If not, or if the description requires additional details — this is the place to record them.

#### Интерфейсы элементов (Element interfaces)

This section documents element interfaces.

#### Поведение элементов (Element behavior)

Some elements have complex interactions with the environment. For purposes of understanding or analysis, they need to be documented.

----

### Диаграмма контекста (Context Diagram)

Shows how the system or portion of the system depicted in this view relates to its environment.

### Инструкции по вариативности <br/> (Variability Guide)

Shows how to exercise any variation points that are a part of the architecture shown in this view.

### Обоснование (Rationale)

**Rationale** explains why the design reflected in the view came to be. The goal of this section is to explain why the design is as it is and to provide a convincing argument that it is sound. The use of a pattern or style in this view should be justified here.

---

## Шаблон: <br/> Архитектурное решение

1. Наименование проблемы
1. Решение
1. `*` Статус: `pending` | `decided` | `approved`
1. `*` Группа
1. Предположения
1. Альтернативы
1. Аргументы
1. Последствия
1. `*` Связанные решения
1. Связанные требования
1. `*` Связанные артефакты
1. `*` Заметки

</div><div class="col">

$\leftarrow$ Структура документа

<dl>
  <dt> Архитектурное решение </dt>
  <dd>  решение, ошибка в котором может привести к провалу проекта. </dd>
</dl>
 
`*` можно опустить в курсовике

![](figures/decision-making.jpg)

</div></div>

----

### Наименование проблемы (Issue)

State the architectural design issue being addressed. This should leave no questions about the reason why this issue is to be addressed now.

### Решение (Decision)

Clearly state the solution chosen.

### * Статус: pending | decided | approved

State the status of the decision, such as pending, decided, or approved. (This is not the status of implementing the decision.)

### * Группа (Group)

Grouping allows for filtering based on technical stakeholder interests. A simple group label, such as "integration," "presentation," "data," and so on can be used to help organize the set of decisions.

----

### Предположения (Assumptions)

Clearly describe the underlying assumptions in the environment in which a decision is being made. These could be cost, schedule, technology, and so on. Note that constraints in the environment (such as a list of accepted technology standards, an enterprise architecture, or commonly employed patterns) may limit the set of alternatives considered.

![](figures/assumptions.jpg)

----

### Альтернативы (Alternatives)

List alternatives considered. Explain alternatives with sufficient detail to judge their suitability; refer to external documentation if necessary.

Only **viable positions** should be described here. But we don't want to hear the question "Did you think about...?" during a review.

</div><div class="col">

![](figures/alternative.jpeg)

</div></div>

----

### Аргументы (Argument)

Outline why a position was selected. This is probably as **important as the decision itself**. The argument for a decision can include items such as implementation cost, total cost of ownership, time to market, and availability of required development resources.

### Последствия (Implications)

Describe the decision's implications. For example:

- Introduce a need to make other decisions
- Create new or modify existing requirements
- Pose additional constraints to the environment
- Require renegotiation of scope
- Require renegotiation of the schedule with customers
- Require additional training for staff

----

### * Связанные решения (Related Decisions)

List decisions related to this one (traceability matrix or decision tree or diagrammatically). Useful relations among decisions include causality, structure, or temporality.

### Связанные требования (Related Requirements)

Map decisions to objectives or requirements. Each architecture decision is assessed as to its contribution to each major objective.

### * Связанные артефакты (Affected Artifacts)

List the architecture elements and/or relations affected by this decision. Also: the effects on other scope decisions, management artifacts such as budgets and schedules.

### * Заметки (Notes)

Capture notes and issues that are discussed during the decision process.

---

## Ключевые аспекты архитектурных представлений

1. Behavior Diagram
1. Context Diagram
1. Interface Diagram

Представление, язык и нотация определяются нуждами заинтересованных сторон.

Обычно аспекты смешиваются (подробности в разделе архитектурных стилей).

---

### Behavior Diagram

#### Сценарии использования. Последовательности

![](figures/behavior-1.png) 
![](figures/behavior-2.png)

1. Взаимодействие пользователя с функциями системы и операционным окружением (UML: Use case diagram).
2. Реакция системы (её компонент) на действие пользователя <br/> (UML: Sequence diagram).

----

#### Порядок взаимодействия компонент в системе

![](figures/behavior-3.png)

----

#### Пошаговый алгоритм поведения системы

![](figures/behavior-5.png)
![](figures/behavior-4.png)

1. Алгоритмическое описание (UML: Activity diagram)
2. Структурное описание / описание интерфейсов.

----

#### Алгоритм поверх диаграммы развёртывания

![](figures/behavior-8.png)

----

#### Состояние системы и переходы

![](figures/behavior-6.png)

----

#### Вложенные состояния системы и переходы

![](figures/behavior-7.png)

---

### Context Diagram

![](figures/context-diagram.png)

Операционное окружение с разных точек зрения: <br/> состав, интерфейсы, поведение.

---

### Interface Diagram

![](figures/arch-interface-documentation-1.png)

</div><div class="col">

![](figures/arch-interface-documentation-2.png)

</div></div>

Интерфейс — основа вариативности, расширяемости и гибкости <br/> для любой системы.

---

## Формирование инструмента архитектурного представления

Инструмент складывается из:

1. нотации
1. подхода
1. архитектурных стилей

----

## Notations for Architecture Views

1. **Informal notations**. Views are depicted (often graphically) using general-purpose diagramming. The semantics are in natural language.
2. **Semiformal notations**. Views are expressed in a standardized notation that prescribes graphical elements and rules of construction, but does not provide a complete semantic treatment (e.g., UML).
3. **Formal notations**. Views are described in a notation that has a precise (usually mathematically based) semantics (Architecture description language — ADL).

</div><div class="col">

![](figures/meme-architecture-notation.jpg)

</div></div>

----

### Выбор нотации

![](figures/style-specialization-due-lifecycle.png)

- Чем раньше, тем "легче" нотация для снижения затрат на внесение изменений.
- Чем позднее, тем выше детализация и формализация для автоматизации.

----

### Подход к рассмотрению архитектуры

![](figures/vertical-horizontal-arch.png)

</div><div class="col">

**$\leftrightarrow$ Горизонтальный** — рассмотрение системы в рамках одного уровня организации:

- язык программирования;
- микросервисы;
- сетевое взаимодействие.

--------------------

**$\updownarrow$ Вертикальный** — рассмотрение взаимодействия уровней организации между собой:

- программа на C и её машинный код;
- машинный код и процессор;
- код IEC 61499 и группа ПЛК.

</div></div>

---

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

<dl>
  <dt> Архитектурный стиль (framework) </dt>
  <dd>  соглашения, принципы, практики для описания архитектуры, созданной для конкретной области применения и/или заинтересованных сторон (перевод ISO 42010). </dd>
</dl>
 
</div><div class="col">

![](figures/capella.png)

</div></div>

Качество архитектурных спецификаций выражается в совокупном снижении затрат заинтересованных сторон (stakeholders) на протяжении всего жизненного цикла системы.

----

## Классы архитектурных стилей

<dl>
  <dt> Module Styles </dt>
  <dd>  Работа с артефактами разработки (документацией). </dd>
</dl>
 
--------------------

<dl>
  <dt> Component & Connector Styles </dt>
  <dd>  Работа с элементами системы времени исполнения. </dd>
</dl>
 
--------------------

<dl>
  <dt> Allocation Styles </dt>
  <dd>  Отображение между уровнями. </dd>
</dl>
 
</div><div class="col">

![](figures/arch-style-allocation.png)

(Allocation Styles)

</div></div>

----

### Modules vs. Components

<dl>
  <dt> Модуль </dt>
  <dd>  элемент проектной документации (класс, дистрибутив, библиотека). </dd>
</dl>
 
--------------------

<dl>
  <dt> Компонент </dt>
  <dd>  элемент системы времени исполнения (экземпляр, сервис, процесс). </dd>
</dl>
 
</div><div class="col">

![](figures/arch-model-component.png)
![](figures/module-vs-component-in-detail.png)

</div></div>

----

#### Выбор архитектурного стиля под stakeholder-а

![](figures/arch-view-selection.png)

---

## Module Styles

![](figures/style-model.png)

- Про документацию проекта (исходный код).

----

### Decomposition Style

![](figures/style-decomposition.png)

- Простая декомпозиция системы на модули.
- В чистом виде на практике практически не используется.

</div><div class="col">

![](figures/style-decomposition-simple.png) 
![](figures/style-decomposition-complex.png)

</div></div>

----

### Uses Style /1

![](figures/style-uses.png)

- Декомпозиция и использование одними модулями других.
- Планирование разработки.
- Отладка и составление планов регрессионного тестирования.

</div><div class="col">

![](figures/style-uses-simple.png) 
![](figures/style-uses-complex.png)

</div></div>

----

### Uses Style /2. Complex Example

![](figures/style-uses-table-2.png)

</div><div class="col">

![](figures/style-uses-table-1.png)

</div></div>

Графический и текстовый язык документирования.

----

### Generalization Style

![](figures/style-generalization.png)

![](figures/style-generalization-1.png) 
![](figures/style-generalization-2.png)

- Вариативность кода системы.
- Сценарии повторного [частичного] использования.

</div><div class="col">

![](figures/style-generalization-3.png)

</div></div>

----

### Layered Style

![](figures/style-layered.png)

- Формирование вычислительной платформы.
- Разделение интересов и уровней абстракций.

</div><div class="col">

![](figures/style-layered-2.png)

![](figures/style-layered-3.png) 
![](figures/style-layered-4.png)

</div></div>

----

### Aspect Style

![](figures/style-aspect.png)

- Анализ "сквозных" ограничений в системе (права доступа, журналирование, валидация и верификация данных).
- Повторное использование и изоляция.

</div><div class="col">

![](figures/style-aspect-1.png)

![](figures/style-aspect-2.png)

</div></div>

----

### Data Model

![](figures/style-data-model.png)

- Представление предметной области.
- Структура и корректность представления данных в системе.
- Механизмы доступа и обработки данных.

</div><div class="col">

![](figures/style-data-model-1.png)

![](figures/style-data-model-2.png)

</div></div>

---

## Component & Connector Styles

![](figures/style-component.png)

- Отображение элементов системы времени исполнения.
- Демонстрация того, как система функционирует во время работы.

----

### Data Flow Style /1

![](figures/style-data-flow.png)

- Этапы и обработчики данных.
- Форматы данных между ними.

</div><div class="col">

![](figures/data-flow-diagram-of-the-data-compiler.png)
![](figures/data-flow-within-MOSILAB.png)

</div></div>

----

#### Data Flow Style /2

![](figures/style-data-flow-2.png)

----

#### Data Flow Style /3. Node programming

![](figures/data-flow-blender-procedural-rust.webp)

----

### Call-Return Style /1

![](figures/style-call-return.png)

----

#### Call-Return Style /2

![](figures/style-call-return-1.png)
![](figures/style-call-return-2.png)

- Цепочки вызовов и взаимосвязей компонент.
- Интерфейсы подключения и взаимодействия.
- Показать поток управления.

----

### Event-Based Style

![](figures/styles-event-based.png)

- Реактивные системы.
- Множество событий, открытый список обработчиков.

</div><div class="col">

![](figures/style-event-based.png)

</div></div>

----

### Repository Style

![](figures/style-repository.png)

- Системы, выстроенные вокруг баз данных.
- Разделение данных.

</div><div class="col">

![](figures/style-repository-1.png)

</div></div>

----

### Component & Connector Styles. Frankenstein

![](figures/style-hybrid.png)

---

## Allocation Styles

![](figures/style-allocation.png)

Отображение элементов архитектуры разрабатываемой системы на:

- операционное окружение
- обеспечивающие системы

----

### Deployment Style

![](figures/style-deployment.png)  
![](figures/style-deployment-1.png)

----

### Install Style

![](figures/style-install.png) 
![](figures/style-install-1.png)

----

### Work Assignment Style

![](figures/style-assignment.png) 
![](figures/style-assignment-1.png)