Термин «архитектура» IT-команды заимствовали из архитектуры зданий. Чтобы построить дом, архитекторы готовят множество чертежей и документацию к ним — это модели реального дома. Чтобы разработать приложение, IT-архитекторы, так же как и архитекторы зданий, готовят набор моделей будущей системы.

В уроке «Описание архитектуры» вы познакомились с ключевыми терминами архитектуры ПО. Рекомендуем повторить глоссарий основных терминов, он пригодится вам в следующих спринтах.

В уроке «Компоненты системы» вы узнали, из каких элементов состоит программное и аппаратное обеспечение. К программному обеспечению относится логика представления, бизнес-логика, логика доступа к данным и хранилище данных. К аппаратному обеспечению — клиент, сервер и сеть.

В уроке «Компоненты системы» вы узнали, из каких элементов состоит программное обеспечение. Возможности ввода и просмотра информации предоставляет логика представления. Бизнес-логика выполняет бизнес-процессы с учётом набора условий. Логика доступа к данным выполняет функции чтения, записи, обновления и удаления данных, а хранилище данных сохраняет данные и информацию.

К фундаментальным стилям относятся клиент-серверная и серверная архитектура. К монолитным — многослойная архитектура. К распределённым — сервис-ориентированная архитектура (SOA) и микросервисная архитектура.

В теме «Фундаментальные стили» вы узнали об особенностях реализации клиент-серверной и серверной архитектуры. Приложение для МФЦ использует в своей архитектуре терминал — это элемент АО, используемый только в серверной архитектуре. Для других двух примеров подходит клиент-серверная архитектура.

В уроке «Звенья клиент-серверной архитектуры» вы узнали о разных конфигурациях клиент-серверной архитектуры. В приведённом примере рассматривается трёхзвенный тип клиент-серверной архитектуры, состоящий из клиента, сервера приложений и сервера базы данных.

У толстого клиента вся бизнес-логика находится на клиенте. Тонкий клиент содержит лишь небольшую часть бизнес-логики на клиенте, а остальная часть расположена на сервере. Ультратонкий клиент выполняет только логику представления.

В уроке «Архитектура мобильного приложения» вы узнали о технологиях, используемых для разработки мобильных приложений. В приведённом примере правильно было бы использовать нативное приложение. Ведь из-за различных операционных систем команде разработки не остаётся иного выхода, кроме как реализовать отдельные мобильные приложения для каждой конкретной ОС. Такие приложения называют нативными.

В уроке «Многослойная архитектура» вы узнали, из каких компонентов и слоёв состоит данный стиль. Визуализация данных осуществляется на слое представления, алгоритмы и математические расчёты — на бизнес-слое, сжатие данных — на слое доступа к данным, а хранение данных — на слое хранилища данных.

Вспомните урок «Распределённые стили: SOA», в котором вы познакомились с сервис-ориентированным стилем в архитектуре. В SOA выделяют следующие типы сервисов: бизнес-сервис, сервис предприятия, сервис приложения, инфраструктурный сервис.

В уроках по многослойной архитектуре и распределённым стилям вы узнали, когда лучше использовать тот или иной стиль. Многослойную архитектуру используют для небольших и простых приложений, а также в начале разработки приложений. Сервис-ориентированную архитектуру (SOA) часто используют в крупных предприятиях, а также для работы нескольких команд разработки. Микросервисную архитектуру используют для высоконагруженных приложений или для приложений с большим количеством функций.

В уроках по многослойной архитектуре и распределённым стилям вы познакомились с рейтингом архитектурных характеристик. В монолитном стиле хорошо проявляется простота разработки и простота тестирования. В распределённом стиле SOA хорошо проявляется масштабируемость. А в микросервисной архитектуре хорошо проявляются все показатели, кроме простоты разработки.

На картинке представлена ER-диаграмма в нотации Crow’s Foot, где изображена структура данных, с которой вы познакомились в четвёртом спринте.

Первичный ключ в нотации Crow’s Foot выделяется символом «звёздочка» (*). В сущности «Пользователь» атрибут «Электронная почта» выделен именно таким символом.

Исходя из связей, используемых в диаграмме, верны три утверждения: 1) «У пользователя должна быть минимум одна банковская карта» — ведь модальность банковской карты обозначена чертой. 2) «У пользователя может не быть добавлено ни одного избранного медиа» — ведь у избранного модальность обозначена как опциональная связь. 3) «В сезон может входить несколько видео» — ведь у видео кардинальность обозначена как «воронья лапка». Лишь одно утверждение неверно «К медиа всегда должен относиться сезон», ведь в связи между медиа и сезоном около сезона использована опциональная связь — она обозначается кругом.

На картинке представлена диаграмма классов в нотации UML Class Diagram, где изображена структура классов, с которой вы познакомились в одном из уроков в четвёртом спринте.

Класс «Медиа» с классами «Фильм» и «Сериал» соединяет стрелка с пустым наконечником, это связь «Наследование». Это отношение между родительским классом и его наследниками. Наследные классы являются частной формой родительского (обобщённого) класса.

На диаграмме представлено внутреннее устройство компонента «Медиатека», состоящего из 6 компонентов с двумя портами. Компонент «Каталог медиа» имеет один требуемый интерфейс, изображенный в виде круга и один предоставляемый, изображенный в виде полусферы. Компонент «Фильмы» использует требуемый интерфейс для взаимодействия с компонентом «Проигрыватель». Компонент «Сериалы» использует две базы данных — «Видео» и «Сезоны» они подписаны стереотипом dataBase.

На представленной диаграмме изображен микросервисный стиль, у которого выделен слой API и микросервисы с большим количеством требуемых и предоставляемых интерфейсов.

У приложения Otium трехзвенная клиент-серверная архитектура. Представленная диаграмма состоит из клиента, сервера приложений и хранилища данных. На сервере располагаются четыре ноды с подпиской, оплатой, учетной записью и медиатекой, а в хранилище данных расположены четыре базы данных.