Архитектура ПО

1.

Архитектура ПО
Documentation

2.

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

3.

TET
A
1. Зачем документировать архитектуру?
Что вы
узнаете на
занятии?
2. Архитектурное описание: точки зрения и представления
3. Нотации документирования
4. Инструменты документирования
5. Практика и принципы документирования
6. Домашнее задание
3

4.

Архитектурное
описание

5.

ГОСТ Р 57100
2016 (ISO
42010:2011)
Описание
архитектуры
Архитектура системы включает множество
аспектов, которые не могут быть описаны одним
простым способом, поэтому описание
архитектуры разбивается на отдельные
представления
Представление (view) - это артефакт (рабочий
продукт), который описывает архитектуру
системы с точки зрения (viewpoint) части
заинтересованных сторон
5

6.

Архитектурное
описание
6

7.

1 Структурные представления – описывают структуру системы:
Module, Component-and-connector, Allocation
Виды
архитектурных
представлений
2 Представления поведения – описывают поведение системы:
• трассировка поведения (trace).
Пример: Use Cases, UML Sequence diagram, C4 Dynamic
• полное описание поведения (comprehensive).
Пример: UML State machine
3 Представления атрибутов качества – описывают архитектуру с
точки зрения реализации отдельных атрибутов качества.
Пример: масштабируемость, надежность, ИБ
4 Наборы представлений – согласованные представления различных
видов
Архитектура ПО: RUP/Kruchten “4+1”, Rozanski & Woods, C4 model
Корпоративная архитектура: Zachman (устар.), TOGAF, ArchiMate
7

8.

Структурные
представления

9.

Модульные представления помогают отобразить структуру
программных элементов различного уровня, из которых строится
система (build-time)
Как они декомпозируются на части?
Как эти части относятся друг к другу (включаются, зависят,
наследуют)?
«Module»
Примеры:
UML Class diagram, UML Package diagram, ER diagrams, ArchiMate
Structural Relationships
Заинтересованные стороны: архитекторы, разработчики
9

10.

«Module»
10

11.

Компонентные представления помогают отобразить
программную систему как набор элементов, которые имеют
поведение и взаимодействуют во время выполнения (runtime), а также коммуникации между этими элементами
«Componentand-connector»
Примеры:
UML Component diagram, C4 Container
Заинтересованные стороны:
архитекторы, разработчики, тестировщики, эксплуатация
11

12.

«Componentand-connector»
12

13.

Представления размещения отображают, как
создаваемое программное обеспечение связано с
непрограммными структурами в его окружении
(вычислительные и сетевые ресурсы)
«Allocation»
Примеры:
UML Deployment diagram, C4 Deployment
Заинтересованные стороны:
архитекторы, разработчики, эксплуатация, ИБ,
инфраструктура
13

14.

«Allocation»
14

15.

Документирование обоснования архитектуры
Фиксирует причину принятых архитектурных решений
Помогает команде реализовывать решения, в соответствии с тем, как их
задумал архитектор
Создает основу для дальнейшего изменения системы
Если принятое решение имеет недостатки, то фиксирует, что мы с ними
согласились, и почему мы с ними согласились
15

16.

ADR – Architecture Decision Record
Запись о принятом архитектурном решении для реализации
определенных требований к системе с обоснованием, почему оно было
принято, и рассмотренными альтернативами
Контекст
Описание контекста/окружения решаемой проблемы/задачи
Драйверы
Факторы, влияющие на решение и заинтересованные лица.
Рассматриваемые варианты
Описание рассмотренных вариантов c их плюсами и минусами
Решение
Описание выбранного решения. Решение должно быть сформулировано чётко ("Мы используем...", "Мы не
используем", а не "Желательно.." или "Предлагается...").
Должна быть понятна связь между решением и проблемой.
Последствия
Положительные и отрицательные последствия (trade-offs). Арх. решения, которые потребуется принять как
следствие принятого решения. Если решение содержит риски, то описано, как с ними планируют поступить (за счет
чего снижать, почему принять).
16

17.

MADR
https://adr.github.io/madr/

18.

Выбор технологии C++/POCO для создания сервисов
Date: 2021-10-21
Status
Accepted
Контекст
Для создания сервисов в рамках курсовой работы необходимо выбирать язык
программирования и фреймворк. Технология должна позволять просто подключаться к
СУБД MariaDB, Redis, Apache Ignite и использовать очереди RabbitMQ и Apache Kafka.
Пример ADR
Варианты решения
• C++/ Poco
• Python + FastAPI + SQL Alchemy
Решение
Выбирается язык C++ и фреймворк POCO
Последствия
Позитивные:
•Большинство студентов в рамках программы курса бакалавриата изучали C++ и
знакомы с принципами разработки на нем
•Фреймворк Poco содержит встроенные средства для создания REST сервисов и
работы с SQL базами данных
•Сервисы на C++ требуют мало памяти и достаточно производительны
Негативные:
• Написание кода на C++ сложнее чем на Python

19.

Нотации
архитектурного
описания

20.

Неформальные:
произвольные графические рисунки (box-and-lines) в том
числе специализированные шаблоны и наборы
графических элементов для какой-либо предметной
области Диаграммы облачных архитектур (AWS, Azure,
GCP)
Нотации
Полуформальные:
стандартизированные модели с поддержкой машинночитаемости UML, BPMN, ArchiMate, C4
Формальные:
Полностью машинно-интерпретируемые языки описания
AADL
20

21.

Box-and-lines
Box-and-lines (box-and-arrows,
прямоугольники и стрелочки) –
собирательное название подхода к
архитектурным диаграммам в
произвольной нотации
Плюсы:
• Абсолютная гибкость
• Нетребовательность к инструментам
(хоть на салфетке)
• Простота
Минусы:
• Двусмысленность
• Необходимость толкования (легенда)
• Нет машинно-читаемости
• Не стандартно
21

22.

Диаграммы
облачных
архитектур
Google Cloud Platform
https://cloud.google.com/icons
22

23.

Графический язык моделирования,
предназначенный для спецификации,
визуализации, проектирования и
документирования всех артефактов,
создаваемых при разработке
программных систем
UML
UML 2.5 Specification (2017)
https://www.omg.org/spec/UML/
https://www.uml.org/
http://book.uml3.ru/
23

24.

UML
Плюсы:
• Универсальность
• Поддержка формальных моделей (в т.ч. возможность
машинной интерпретации)
Минусы:
• Избыточность
• Сложность изучения (150 элементов)
• Плохо подходит для коммуникаций между ИТ и бизнесом
24

25.

UML Состав
25

26.

1 Use case
UseCase описывает способ использование системы.
Каждый вариант использования состоит из одного основного
сценария использования и, если необходимо, нескольких
дополнительных сценариев.
• Основной (или базовый) сценарий использования описывает самый
типовой случай работы с системой в рамках данного UseCase. В нем
нет ни ветвлений, ни условий.

27.

Диаграммы
UseCase
Показывают взаимосвязи между
сценариями использования
системы.

28.

Отношения на
диаграммах
UseCase
https://blog.visual-paradigm.com/ru/the-four-types-of-

29.

2 Class Diagram
• структура связей между объектами во время выполнения
программы;
• структура хранения данных;
• структура программного кода;
• структура компонентов в приложении;
• структура сложных объектов, состоящих из
взаимодействующих частей;
• структура артефактов в проекте;
• структура используемых вычислительных ресурсов.

30.

Class
Название класса (ClassName) – это
существительное.
Attribute – это именованное место (или, как
говорят, слот), в котором может храниться
значение.
Operation – это спецификация действия с
объектом: изменение значения его атрибутов,
вычисление нового значения по информации,
хранящейся в объекте и т.д.

31.

Связи в class diagram

32.

пример

33.

3 Sequence Diagram
Одно из основных
отличий Sequence
диаграмм, от других
поведенческих
диаграмм в том, что
они позволяют
сконцентрироваться
на временном аспекте
взаимодействия. Т.е.
на них можно
отображать порядок
вызовов
объектов/систем.

34.

Взаимодействие
Объекты взаимодействуют
посредством сообщений.
Каждое сообщение
изображается стрелочкой,
которая идет от
вызывающего объекта к
вызываемому.
Время «обработки» события
(или ожидания ответа на
событие) отображается
прямоугольником на оси
времени жизни объекта.

35.

4 State Diagram
• При моделировании жизненного цикла
объекта или системы;
• Проектирование логики работы событийноориентированных систем;
• Проектирование работы пользовательского
интерфейса;

36.

Пример state
диаграммы
stm Lamp States
Не сломана
Выключена
Начальное состояние
Супер-состояние «Не сломана»
Состояние «Выключена»
Начальное
псевдосостояние
Включение
Состояние «Включена»
Конечное состояние
«Сломалось»
Переходы между состояниями
Выключение
Включена
[Случилась поломка]
Сломалась

37.

5 Activity Diagram
Показать алгоритм выполнения действий. Особенно если нужно
показать сложные условия ветвления алгоритма.
Отлично подходит что бы специфицировать параллельные
процессы в программах.
Может быть использован для визуализации сценариев вариантов
использования.

38.

Базовые элементы
Блок Decision предназначен для
изображения ветвления поток а
управления. После этого блок а
управление может идти только по
одному пути.
Блок Merge предназначен для
слияния различных ветвей потоков
управления.
Блок Activity предназначен для
обозначения действия
act Activ ity
Быть
Подставить
Розенкранца и
Гильденстерна
Озадачиться
Не быть

39.

Swimlane
Billing
Swimlanes (Partitions) служат для
обозначения ролей
(ответственности) в выполнении
действий.
CRM
act Activ ity
Зарегистрировать
нового клиента
Зарегистрировать
продажу продукта
Предоставить
продукт
Выставить счет и
оплатить

40.

UML: Что
почитать?
− http://www.omg.org/
− http://book.uml3.ru/

41.

Модель и графическая нотация для описания бизнес-процессов
Основная цель — создание стандартного набора условных
обозначений, понятных всем участникам:
• бизнес-аналитикам, создающим и улучшающим процессы
• разработчикам, ответственных за реализацию процессов
• менеджерам, следящим за процессами и управляющим ими
BPMN
BPMN 2.0 Specification (2014)
http://www.omg.org/spec/BPMN/2.0.2/
https://www.bpmn.org/
http://www.bpmb.de/images/BPMN2_0_Poster_RU.pdf
41

42.

BPMN
Плюсы:
• Возможность коммуникаций между ИТ и бизнесом
• Возможность создания машинно-читаемых и машинноисполняемых моделей бизнес-процессов
Минусы:
• Ограничен областью описания бизнес-процессов
42

43.

BPMN Пример
43

44.

Памятка
Ссылка
44

45.

ArchiMate
Графический язык моделирования архитектуры предприятия в
области построения и функционирования бизнес-процессов,
организационных структур, информационных потоков, ИТ систем и
технической инфраструктуры
ArchiMate 3.1 Specification (2019)
https://pubs.opengroup.org/architecture/archimate3-doc/ - спецификация
http://www.hosiaisluoma.fi/ArchiMate-Cookbook.pdf - лучшие практики
45

46.

ArchiMate
Плюсы:
• Поддержка формальных моделей
• Относительная простота изучения (40 элементов)
• Возможность сквозного моделирования архитектуры от
бизнеса до ИТ
Минусы:
• Поддерживает не все необходимые представления для
архитектуры уровня решения и системы
• Не препятствует созданию очень сложных диаграмм,
объединяющих множество представлений (нужно
разумно выбирать используемые элементы)
46

47.

ArchiMate
структура
описания
47

48.

ArchiMate
основные
элементы
48

49.

С4
Плюсы:
• Top-Down проектирование (abstraction-first), из Лекции 1
• Простота изучения (небольшое количество сущностей)
• Подходит для коммуникаций и взаимодействий между ИТ
и бизнесом
Минусы:
• Ограниченный набор представлений (не все можно
смоделировать, например, модель данных или процессы)
49

50.

С4
Модель С4 - простая
графическая нотация для
моделирования
архитектуры
C4 Model Specification
https://c4model.com/
50

51.

С4 Context
Границы:
Система
Заинтересованные
стороны: представители
бизнеса и ИТ, как внутри
команды, так и внешние
https://c4model.com/#SystemContextDiagram
51

52.

С4 Containers
Границы:
Система
Заинтересованные стороны:
архитекторы, разработчики,
тестировщики, эксплуатация
https://c4model.com/#ContainerDiagram
52

53.

С4
Components
Границы:
Контейнер
Заинтересованные стороны:
архитекторы, разработчики
https://c4model.com/#ComponentDiagram
53

54.

С4 Code
Границы:
Компонент
Заинтересованные стороны:
архитекторы, разработчики
https://c4model.com/#CodeDiagram
54

55.

С4 Dynamic
Границы:
Компания, система или
контейнер
Заинтересованные
стороны:
архитектура, разработка,
тестирование,
эксплуатация, ИБ
https://c4model.com/#DynamicDiagram
55

56.

С4
Deployment
Границы:
Одна или несколько систем
Заинтересованные стороны:
архитектура, разработка,
тестирование, эксплуатация,
инфраструктура, ИБ
https://c4model.com/#DeploymentDiagram
56

57.

Инструменты
документирования

58.

«Рисовалки»
создание диаграмм/схем в произвольных нотациях
Draw.IO, Visio, Excalidraw
Инструменты
документиро
вания
Моделеры
создание моделей архитектуры с поддержкой различных
представлений
Sparx Enterprise Architect, Archi, Visual Paradigm, BPMN.IO,
Camunda
Architecture (Diagrams) as a Code
описание моделей/диаграмм в виде кода
PlantUML, Mermaid, Structurizr
58

59.

Модель или
диаграмма?

60.

• Простой способ рисовать произвольные диаграммы
Draw.io
• Есть возможность использования нотаций UML, С4, BPMN,
ArchiMate (но без поддержки выгрузки в форматах
стандартов)
• Есть плагин для Confluence
https://app.diagrams.net/
60

61.

• Поддержка единого архитектурного репозитория
• Моделирование в нотациях UML, ArchiMate, BPMN
• Сложность изучения
Sparx
Enterprise
Architect
• Сложности с публикацией артефактов (необходима
разработка скриптов)
http://www.sparxsystems.com/
61

62.

• Визуальное описание бизнес-процессов на основе BPMN 2.0
BPMN.io
• Поддерживает выгрузку в виде стандартного XML для
использования в “движках” BPM
• Есть плагин для Confluence
https://bpmn.io/
62

63.

• Моделирование в нотации ArchiMate (а также эмуляция C4)
Archi
• Возможность совместной работы на основе системы
контроля версий
https://www.archimatetool.com/
63

64.

Подход Diagrams as code:
• Печатать текст быстрее, чем рисовать
• Легче сравнивать диаграммы
• Возможность совместной работы на
основе системы контроля версий
PlantUML
• Можно анализировать в т.ч.
автоматизировано
• Поддерживает все основные нотации
UML, C4
• Есть плагин для Confluence
https://plantuml.com/
https://kroki.io
64

65.

https://github.com/DVDemon/hl_mai_016_PlantUML

66.

Use Case
@startuml
left to right direction
skinparam packageStyle rect
actor customer
actor clerk
rectangle checkout {
customer -- (checkout)
(checkout) .> (payment) : include
(help) .> (checkout) : extends
(checkout) -- clerk
}
@enduml

67.

Class
@startuml
class User {
-String id
-String name
+String name()
}
User <|-- SpecificUser
@enduml

68.

Activity
@startuml
start
while (data available?)
:read data;
:generate diagrams;
endwhile
if (a> b)
: do aaa;
else
: do bb;
endif
stop
@enduml

69.

Activity
@startuml
(*) -r-> "LOG macro"
-r-> "Record"
-r-> "Logger"
-r-> "Appender"
-d-> "Formatter"
-d-> "Converter"
-u-> "Appender"
-r-> (*)
@enduml

70.

@startuml Basic Sample
!include https://raw.githubusercontent.com/plantumlstdlib/C4-PlantUML/master/C4_Container.puml
C4
Person(admin, "Administrator")
System_Boundary(c1, "Sample System") {
Container(web_app, "Web Application", "C#, ASP.NET Core
2.1 MVC", "Allows users to compare multiple Twitter
timelines")
}
System(twitter, "Twitter")
Rel(admin, web_app, "Uses", "HTTPS")
Rel(web_app, twitter, "Gets tweets from", "HTTPS")
@enduml

71.

Практика
документирования
архитектуры

72.

1. Выяснить, что нужно заинтересованным сторонам, их
цели и интересы.
Если этого не сделаете, получите документацию,
которая никому не нужна
Как создавать
документацию?
2. Предоставить информацию для удовлетворения этих
интересов путем описания проектных решений в виде
артефактов в соответствии с выбранными
представлениями (views)
3. Проверить созданные представления на предмет того,
удовлетворяют ли они интересам команды
4.
Упаковать информацию в полезную форму для
заинтересованных сторон – создать связанную
документацию из представлений
72

73.

• Agile != отсутствие документации
• Роль архитектора может выполняться различными участниками
команды (и коллегиально)
• Приоритезация разработки документации на основе потребностей
заинтересованных сторон
Документирова
ние
архитектуры в
Agile
• Итеративный подход к описанию архитектуры согласованно с
итерациями разработки
• Инкрементальный подход к созданию архитектурных артефактов
(breadth-first), фиксация только необходимой информации
• Доработка артефактов на основе регулярной обратной связи от
заинтересованных сторон
http://agilemodeling.com/
73

74.

• Пишите документацию с точки зрения читателя, а не
писателя
• Создавайте только те артефакты, которые нужны
заинтересованным сторонам
• Избегайте ненужных повторений
Общие принципы
документирования
• Избегайте двусмысленности, всегда объясняйте свои
обозначения (нестандартные)
• Поддерживайте смысловую и структурную согласованность
и связи между отдельными артефактами/представлениями
• Используйте стандартную организацию документации
• Записывайте обоснование архитектурных решений
• Поддерживайте документацию в актуальном состоянии
• Детализируйте только до той степени, которая нужна
заинтересованным сторонам
74

75.

• Документация должна быть оформлена в электронном
виде и хранится в корпоративных системах управления
знаниями (документацией)
• Необходимо обеспечить доступ на чтение всем
заинтересованным сторонам
Принципы и
требования к
документированию
• Система управления знаниями (документацией) должна
позволять выгрузить контекст информации в файл
для предоставления заинтересованным сторонам
• Документация должна поддерживать версионность на
уровне каждого изменяемого раздела (или иерархии
разделов)
• (Рекомендовано) Документация должна генерироваться
из артефактов, создаваемых в инструментах, и
публиковаться в системе управления знаниями
(документацией) в рамках конвейера поставки (CI/CD) в
продуктовой фабрике
75

76.

Практическое
задание

77.

Пример
описание
бизнескейса
Вы решили разработать программное обеспечение для
управление умным домом. Приложение должно содержать вебинтерфейс для управления основными функцимями умного
дома в части контроля безопасности и температуры в
помещении.
Приложение должно содержать как минимум следующие
функциональные блоки:
Возможность регистрировать новых пользователей умного
дома
Возможность поиска/удаления пользователей умного дома
Получать информацию о входах/выходах в дом
Получать информацию о текущем значении температуры дома
и истории изменяя температуры
77

78.

Результат выполнения практического задания по курсу
документируется в виде набора аналитических и
архитектурных артефактов.
Инструменты
Инструменты:
• Клиент Git
• Текстовый редактор (рекомендуется Visual Studio Code)
• Плагины к Visual Studio Code:
vscode-plantuml - поддержка PlantUML
Markdown All in One – расширенная поддержка Markdown
78

79.

1. Установить инструменты из списка
2. Зарегистрироваться на github.com (если еще нет учетной
записи)
Задание по
данной
лекции
3. Клонировать https://github.com/DVDemon/hl_mai_lab_00 с
примером задания
4. Создать публичный репозиторий для выполнения
практической работы у себя в аккаунте
5. Создать файлы с описанием «архитектуры» согласно вашему
варианту задания:
task.md – скопировать задание в формате MarkDown
context.md – контекстная диаграмма C4 согласно вашего
задания (уровень C1)
components.md – контейнерная диаграмма (уровень c2)
79

80.

Что почитать?

81.

Что почитать
про PlantUML
https://github.com/plantuml-stdlib/C4-PlantUML
https://crashedmind.github.io/PlantUMLHitchhikersGuide/index.h
tml

82.

На сегодня все
[email protected]