Диаграммы развёртывания

Цели и задачи

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

Какие нужны нефункциональные требования:

Язык программирования (скорее всего, он определился в ЛР 5) серверной и клиентской частей с соответствующими средами выполнения;
СУБД с указанием схем хранимых в них данных (особенно актуально, если для разных компонентов системы и/или для разных задач будут использоваться разные СУБД);
Операционные системы, которые должны использоваться на сервере и на клиентах;
Описание внешних устройств, необходимых для работы ИС (например, датчики);
Требования по использованию прочего ПО, если оно требуется (например, балансировщик нагрузки, очередь сообщений и т.д.).

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

Далее необходимо показать эти нефункциональные требования с помощью диаграммы развёртывания. Что нужно показать:

Аппаратные узлы, необходимые для работы различных компонентов ИС (в том числе внешние устройства);
Среды выполнения различных уровней (среды виртуализации, операционные системы, браузеры, виртуальные машины для ЯП и пр.);
Артефакты, разворачиваемые на каждом из узлов (набор артефактов будет зависеть от выбранного языка программирования), и компоненты/классы/пакеты, которые материализуются с помощью этих артефактов;
Файлы конфигурации, необходимые для развёртывания приложения;
Подключения различных аппаратных и программных узлов с указанием протоколов передачи данных.

Оценивание

Максимум за эту лабораторную работу — 8 баллов. За что снимаются баллы:

Отсутствие диаграмм;
Несоблюдение нотации и методических рекомендаций;
Неудачная вёрстка диаграммы, затрудняющая чтение;
Некорректное оформление отчёта (например, картинки без подписи, водяной знак, закрывающий часть диаграммы или всю диаграмму, скриншот диаграммы вместо экспортированного файла);
Использование неподходящего ПО;
Сдача после дедлайна.

Методические рекомендации

Если описываемая система взаимодействует с внешними системами, взаимодействие с ними можно показать в виде запрашиваемого интерфейса, это позволит не раскрывать устройство “чёрного ящика”, которое мы и так не знаем;
При указании протоколов передачи данных не забывайте про модель OSI, будет неправильно, например, указывать HTTPS в виде протокола передачи данных между двумя аппаратными узлами, а между веб-сервером и браузером — вполне себе правильный вариант;
Если вам не хочется делать матрёшку из узлов и артефактов, воспользуйтесь композицией (больше актуально для узлов) и зависимостью со стереотипом deploy (больше актуально для артефактов);
При указании какого-то ПО (в т.ч. в качестве среды выполнения) стоит также указать и его версию;
Обычно с точки зрения модели именно ИС нас не интересует, какие устройства участвуют в передаче данных между двумя узлами, т.е. сетевое оборудование обычно не показывается. С другой стороны, если оно так или иначе влияет на работу ИС, то это должно быть отражено в модели.