Архитектура системы

спринт Архитектура системы
Проектирование архитектуры
3/3
О чём этот спринт
Описание архитектуры ПО
Компоненты системы
Фундаментальный стиль
4/4
Монолитные и распределенные стили
4/4
Моделирование архитектуры
2/2
Вебинар и домашнее задание
2/2
Заключение
1/1

Описание архитектуры ПО

В этом уроке вы узнаете, из каких типов элементов состоит архитектура ПО, в какие структуры их объединяют и как описывают эти элементы и их связи. Вы также сможете скачать глоссарий с основными понятиями архитектуры ПО, который пригодится не только в этом спринте, но и в следующем.
Даня и Айгуль стоят перед доской, на ней изображены схемы с элементами (кубы с кубами) из этого урока. На доску смотрят не только Даня и Айгуль, но и Бэнкси (он, наверное, не в духе) с Гамлетом. Даня: «Откуда в офисе собака?», Айгуль: «Знакомься, мой пёс Гамлет!».
Даня
Я всё ещё не понимаю, как именно мы будем участвовать в проектировании архитектуры 🙄
Айгуль
Давай по порядку! Сначала расскажу тебе об основных понятиях.

Описание архитектуры ПО

Описание архитектуры ПО (Software Architecture Description) — это набор документов, содержащий часть информации о программном обеспечении системы. Этот набор появляется в результате проектирования архитектуры ПО.
Описание архитектуры ПО системы составляет архитектор ПО вместе с командой разработки и другими заинтересованными лицами. В этом ему часто помогает системный аналитик.
Перед тем как ознакомиться с описанием архитектуры ПО, системному аналитику необходимо разобраться в основных понятиях, которые будут встречаться в этой предметной области:
  • Элемент.
  • Структура.
  • Стиль (шаблон).

Элемент

В спринте «Разработка требований» вы узнали, что разные заинтересованные лица системы имеют разные потребности, которые система должна удовлетворить. Например, пользователи ожидают, что система предоставит им определённые функциональные возможности, а регуляторы — что она будет соответствовать установленным нормам.
Исходя из своих потребностей, заинтересованные лица смотрят на систему с разных сторон — их интересует разнородная информация. Например, пользователей в большей степени интересует информация о функциях системы, а команду разработки — информация о внутренней организации системы, такая как организация данных.
человечки около куба. одни смотрят на куб целиком, другие заглядывают внутрь большого куба — там еще много кубиков.
Разных заинтересованных лиц также занимает информация о системе с различной степенью детализации. Например, разработчиков программного обеспечения определённой части системы интересуют любые, касающиеся её нюансы, тогда как разработчики других частей могут представлять её себе как «чёрный ящик» (Black Box).
Чёрным ящиком называют упрощённое представление о каком-либо объекте, внутреннее устройство и механизм работы которого очень сложны для понимания заинтересованным лицом, неизвестны или неважны ему. Такие ящики — это модели. В области знаний об архитектуре ПО их называют элементами.
Элемент (Element) — это абстракция части системы.
Элемент придаёт системе доступную для понимания заинтересованными лицами структуру. Представление архитектуры системы как набора взаимодействующих элементов позволяет понять её устройство, а также проанализировать её свойства и характеристики.
В зависимости от необходимой заинтересованному лицу информации архитектура системы будет представлена в виде элементов разного размера и будет иметь разное количество элементов.
шесть кубиков, каждый из которых разделен на части. Первый целый, последний состоит из 125 кубиков.
В системе выделяют следующие основные типы элементов:
  • Сущности/таблицы.
  • Классы.
  • Объекты.
  • Слои.
  • Сервисы.
  • Компоненты, элементы аппаратного обеспечения.
Сущности, классы и объекты — это те самые понятия моделей данных, о которых вы узнали в спринте «Моделирование данных».

Взаимодействие элементов

Элементы связаны между собой: они обмениваются информацией и дают друг другу указания. Они взаимодействуют через интерфейсы (Interfaces).
Интерфейс одного объекта предоставляет интерфейсу другого объекта механизмы для взаимодействия с ним. Механизмы — это функции, которые элемент может выполнить по указанию другого элемента. При этом каждый элемент скрывает от других элементов организацию своей внутренней структуры и процесс выполнения функций.
Рассмотрим пример взаимодействия элементов с типом «Класс».
В спринте «Моделирование данных» вы узнали, что классы могут иметь набор методов для взаимодействия друг с другом. Метод класса представляет собой функцию, которую класс может выполнить. Методы добавляют, удаляют объекты и изменяют значения их атрибутов. Методы класса — это и есть механизмы его интерфейса.
Класс «Авиакомпания» может вызвать методы «отменить()» и «перенести()» класса «Рейс». При этом классу «Авиакомпания» не важно то, как именно класс «Рейс» выполнит эту и другие функции, достаточно знать перечень возможных функций.

Структура

Элементы одного типа и их связи объединяют в структуру для удобства представления информации об архитектуре системы заинтересованным лицам.
Структура (Structure) — это набор связанных по определённому принципу элементов архитектуры системы.
Представленная в виде структуры информация об архитектуре системы упрощает заинтересованным лицам её изучение, обсуждение и принятие решений. Разделение системы на структуры помогает сфокусировать заинтересованных лиц на ограниченном объёме информации, уменьшая сложность её восприятия.
Каждая структура объединяет элементы определённых типов.
таблица в кате ниже
Структура информации или структура данных — это та самая ER-модель, которую вы научились составлять ранее в этом курсе. Структура классов — это модели классов и дополняющие её модели объектов.
Каждая структура может быть интересна одному или нескольким заинтересованным лицам. Например, структуры данных и классов системы важны и архитектору хранилищ данных, и разработчикам, потому что значения атрибутов объектов сохраняются в хранилище. Архитектор и разработчики должны совместно убедиться, что для каждого атрибута класса предусмотрено, например, хотя бы одно поле таблицы базы данных.

Стиль (шаблон)

Как правило, все системы сталкиваются с одними и теми же проблемами. Например каждый пользователь хочет, чтобы система быстро выполняла его указания, то есть чтобы система была производительной. Для решения распространённых проблем существуют готовые архитектурные решения, эффективность которых доказана многолетним использованием командами разработки по всему миру. Такие решения называют стилями или шаблонами.
Стиль или шаблон (Style / Pattern) — это общепринятый способ организации элементов архитектуры системы, направленный на решение определённой проблемы.
Каждый стиль оказывает влияние на атрибуты качества системы. Поэтому требования к ним являются основой для принятия решения о стиле архитектуры ПО.
Стиль решает проблему благодаря определённой организации элементов системы и их связей. Для каждого типа элементов существуют свои стили.
Не существует идеального стиля. Любой стиль имеет свои преимущества и недостатки. Выбор стиля — это всегда компромисс. Решая одни проблемы, стиль негативно влияет на другие свойства или характеристики системы.
Архитектор ПО доводит до всех заинтересованных лиц преимущества и недостатки подходящих для решения проблемы стилей и выявляет уступки касательно качества, на которые они готовы пойти. Задача системного аналитика — предоставить архитектору ПО всю информацию, которая нужна для принятия решения о выборе стиля.
Основными стилями архитектуры ПО являются:
  • Клиент-серверная архитектура (двухзвенная, трёхзвенная, многозвенная).
  • Серверная архитектура.
  • Монолитная архитектура.
  • Сервис-ориентированная архитектура.
  • Микросервисная архитектура.
Соотнесите термины из области архитектуры ПО с их определениями.
Упрощённое представление о какой-либо части системы, внутреннее устройство и механизм работы которой очень сложны для понимания заинтересованным лицом, неизвестны или неважны ему.
Элемент
Набор связанных по определённому принципу элементов архитектуры системы
Структура
Общепринятый способ организации элементов архитектуры системы и их связей, направленный на решение распространённой проблемы
Стиль (шаблон)

Представление архитектуры

Если описать все элементы системы и их связи в одном документе, то им невозможно будет пользоваться даже архитектору ПО из-за объёма и сложности этой информации. Пользователи, скорее всего, не смогут понять даже его часть, потому что не обладают знаниями в предметной области разработки ПО.
Поэтому описание элементов разбивают на отдельные документы, каждый из которых предназначен только части заинтересованных лиц. Такие документы называются представлениями.
Представление архитектуры (Architecture View) — это описание части выбранных по определённому принципу элементов архитектуры системы и их связей.
Представление архитектуры описывает элементы и их связи, необходимые для моделирования определённой проблемы заинтересованных лиц и её последующего анализа, проектирования её решения и его реализации.
В представлении могут быть описаны:
  • Все элементы и связи одной структуры (как на иллюстрации 1). Например, если команде разработки нужно спроектировать хранилище данных системы, ей потребуется описать все сущности и связи структуры информации (структуры данных).
  • Все элементы и связи нескольких структур (как на иллюстрации 2). Например, если команде разработки нужно спроектировать связи между классами программного кода и сущностями хранилища данных, ей потребуется описать все классы структуры классов и все сущности структуры информации (структуры данных). В таком случае, скорее всего, документ будет также слишком сложным для восприятия, поэтому его следует разделить, например, по подсистемам.
  • Часть элементов и связей одной структуры (как на иллюстрации 3). Например, если команде разработки нужно внести изменения в отдельные сущности хранилища данных, ей потребуется описать только изменяемые сущности и, возможно, связанные с ними сущности.
  • Часть элементов и связей нескольких структур (как на иллюстрации 4). Например, если команде разработки нужно внести изменения в существующее программное обеспечение, и эти изменения затрагивают некоторые классы и сущности, ей потребуется описать только изменяемые элементы.
4 иллюстрации кубов, состоящих из других кубиков. у первого куба выделен слой кубиков, у второго выделены разными цветами двая слоя рядом, у третьего выделены одним отдельные кубики в слое, у четвёртого кубика выделены двумя цветами несколько кубиков рядом, в двух соседних слоях.
Представления архитектуры описывают в графической форме — в виде диаграмм. Для описания разных структур используются соответствующие нотации. Например, структуры информации (структуры данных) описывают в нотации Crow’s foot, а структуры классов — с помощью UML Class Diagram и UML Object Diagram.
система -> проблема -> элементы и их связи -> представление.
Системному аналитику нужно уметь разбираться в описании архитектуры ПО и в связях между разными документами, чтобы эффективно участвовать в обсуждениях и принимать решения, которые согласуются с архитектурой.

Комбинирование представлений

Так как все структуры относятся к архитектуре ПО одной системы, они тесно связаны между собой. Проектирование и описание связей между архитектурными структурами — важная часть работы архитектора ПО.
Комбинированное представление (Combined View) — это представление архитектуры ПО, описывающее входящие в разные представления элементы и их связи.
два куба, состоящие из элементов. в первом выделены два слоя элентов рядом с друг другом. во втором кубе выделена часть двух слоёв.
Все представления, в том числе комбинацию представлений, составляют для моделирования проблемы или проектирования решения. Важно осознавать цель комбинирования представлений, потому что результат может быть слишком объёмным и сложным для понимания. Как правило, архитектор ПО составляет их однократно и не поддерживает в актуальном состоянии.
Системному аналитику важно помнить, что разные представления архитектуры могут быть связаны друг с другом. В таком случае при изменении одного представления ему следует обновить все связанные с изменением представления или обратиться за помощью к архитектору ПО.

Представление качества архитектуры

Представления архитектуры могут, в частности, описывать влияющие на определённые атрибуты качества элементы системы и их связи. Они называются представлениями качества (Quality View) и могут включать элементы различных типов. Например:
  • Представление защищённости (Security View) описывает элементы системы, которые выполняют определённые роли и обязанности в части информационной безопасности, их связи. Например, такой документ может описывать структуру защищённого хранилища данных. Это представление также может включать анализ рисков, методы разработки, внедрения, эксплуатации и сопровождения системы, а также описание того, как система реагирует на определённые угрозы и уязвимости.
  • Представление надёжности (Reliability View) — описывает модель механизмов надёжности, такие как репликация (Replication) и переключение (Switch-over).
  • Представление производительности (Performance View) — описывает элементы системы, влияющие на её производительность, и их связи. Например, модели сетевого трафика, максимальные задержки операций и прочее.
Представления качества архитектуры, как правило, находятся далеко за пределами зоны ответственности СА. Такие представления составляет архитектор ПО, потому что они требуют широкого технического кругозора и глубоких знаний о системе и архитектуре ПО.
Системному аналитику следует понимать, какое представление он изучает в данный момент, какую проблему оно моделирует или решение какой проблемы проектирует. Тогда он сможет лучше понимать архитектуру ПО, более эффективно участвовать в обсуждениях и принимать согласующиеся с ней решения.

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

Системный аналитик может составлять представления архитектуры или участвовать в их составлении вместе с архитектором ПО (или архитектором хранилищ данных).
Перед тем как приступить к составлению представления, СА следует ответить на вопросы, которые помогут сделать документ более понятным и удобным:
  • Какую проблему нужно смоделировать? Для какой проблемы нужно спроектировать решение?
  • Кто целевая аудитория документа?
  • Какой у целевой аудитории документа уровень знаний о разработке ПО?
  • Какие структуры и элементы затрагивает проблема/решение?
  • Какой степени детализации нужно предоставить информацию целевой аудитории документа?
Представьте, что для определения потребностей в информации у пользователей будущей подсистемы СА требуется описать её структуру данных.
В этом случае системный аналитик может самостоятельно составить логическую ER-диаграмму и показать её пользователям. Возможно, он даже включит в ER-диаграмму только те сущности, требования к которым нужно уточнить.
Теперь представьте, что потребности в информации определены, и команда разработки готова приступить к реализации подсистемы.
В этом случае СА следует доверить составление представления структуры данных архитектору хранилищ, потому что для её реализации команде разработки требуется физическая ER-диаграмма. Такая диаграмма будет описывать все необходимые таблицы и поля, а также рассматривать проблемы оптимизации хранения и извлечения данных.

Дополнительная документация

Представление архитектуры включает не только модели структур системы, но и другую важную для заинтересованных лиц информацию:
  • Используемые стили (шаблоны). Если при проектировании архитектуры ПО были использованы определённые стили, это должно быть зафиксировано в документации. В частности, следует описать использованный стиль, обосновать выбор этого стиля и проблему, которую требовалось решить с его помощью.
  • Диаграммы контекста показывают, как ПО или его часть взаимодействует с операционной средой: людьми, другим ПО или оборудованием, например сенсорами и управляемыми устройствами (умными лампочками, цоколями, замками и другими). Диаграммы контекста особенно полезны в начале проектирования ПО, потому что операционная среда является источником множества ограничений и может существенно повлиять на систему в целом.
  • Глоссарий и список сокращений. Скорее всего, описание архитектуры будет содержать множество специализированных терминов и сокращений. Их расшифровка для читателей позволит говорить с ними на одном языке.
  • Обоснование объясняет, как принимались решения об архитектуре ПО. Например, этот документ описывает, почему был выбран текущий вариант архитектуры ПО, какие варианты рассматривались, на какие компромиссы пришлось пойти, какие предположения были выдвинуты.
  • Контроль изменений документации. Например, текущая версия документа, её дата и статус, автор изменений, история изменений и процесс внесения изменений.
Системный аналитик также может оказать существенную помощь архитектору ПО в составлении и обновлении дополнительной документации.
Подберите правильный ответ для каждого вопроса.
Какой документ описывает модель атрибута качества или удовлетворяющий ему проект решения?
Представление качества
Какой набор документов описывает использованные в представлениях стили (шаблоны)?
Дополнительная документация
Какой документ описывает входящие в разные представления элементы и их связи?
Комбинированное представление
Какой документ описывает относящиеся к одной структуре элементы и их связи?
Представление

Подведём итоги

Основные понятия архитектуры ПО системы:
  • Элемент — абстракция части системы.
  • Структура — набор элементов, которые объединяют для удобства представления информации о системе.
  • Стиль (шаблон) — общепринятый способ организации элементов системы, направленный на решение определённой проблемы. Выбор стиля — это всегда компромисс.
Каждая структура данных объединяет элементы определённых типов:
  • Информации (сущности/таблицы). Её также называют структурой данных.
  • Классов (классы и объекты).
  • Слоёв (слои).
  • Сервисов (сервисы).
  • Развёртывания (компоненты, элементы аппаратного обеспечения).
Если описать все элементы системы и их связи в одном документе, им невозможно будет пользоваться. Поэтому описание элементов разбивают на отдельные документы. Такие документы называются представлением архитектуры:
  • Представления архитектуры.
  • Комбинированные представления.
  • Представления качества архитектуры.
  • Дополнительная документация.
Описание архитектуры ПО системы составляет архитектор ПО вместе с командой разработки и другими заинтересованными лицами. В этом ему часто помогает системный аналитик. СА нужно уметь разбираться в описании архитектуры ПО и в связях между разными документами, чтобы эффективно участвовать в обсуждениях и принимать согласующиеся с ней решения.

Глоссарий

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

Диаграмма понятий

Диаграмма описывает понятия (в прямоугольниках) и связи между ними (в подписях к стрелкам). Читать диаграмму можно, начиная с любого понятия, двигаясь по стрелке к другому понятию. Например: «Стиль (1) является способом организации элементов (2), который решает проблему (3)».
система -> проблема -> элементы и их связи -> представление.