MINISTERUL EDUCAŢIEI ŞI 

TINERETULUI AL REPUBLICII MOLDOVA

UNIVERSITATEA TEHNICA A MOLDOVEI

FACULTATEA CALCULATOARE, INFORMATICĂ ŞI MICROELECTRONICĂ

Proect de an
ПО ПРЕДМЕТУ «AMOO»

Выполнил: студент группы TI-182 Ватаманюк Игорь

Проверил: Sava N. și Melnic R., lect.univ.

UTM 2020
 Оглавление

1. Введение ………………………………………………………………………………………………………………….….………. 3

2. Теория UML …………………………………….……………………………………………………………………………………. 4

3. Моделирование информационной системы …………………………………………..…………….…………… 9

- Диаграмма вариантов использования …………………………………………………………………..…….. 9

- Диаграмма последовательности …………………………………………………………………………………. 12

- Диаграмма коммуникации …………………………………………………………………………………………...14

- Диаграмма классов ………………………………………………………………………………………………..…….. 16

- Диаграмма состояний …………………………………………………………………………………………….……..17

- Диаграмма действий …………………………………………………………………….……………………………….18

- Диаграмма компонентов …………………………………………………………………………………………….. 20

- Диаграмма развёртывания ………………………………………………………………………………………..… 22

4. Вывод …………………………………….……………………………………………………………………………………………. 23

5. Библиография …………………………………………………………………………………………………………..………... 24
 1. Введение
В данной работе будут представлены диаграммы для описания системы базы данных и взаимодействия
с ней поставщиков, продавцов и покупателей. На самом деле это система очень обширна, и может
состоять из десятков компонентов, но будут показаны основные модули и компоненты.
Я выбрал именно эту тему, так как эта тема мне близка. Я работаю Full-Stack Web Developer, уже более 9
лет, и знаю не понаслышке о всех компонентах системы, так как за эти годы был участником реализации
более 50 проектов, и вел разработку дополнительного функционала на более чем 30 проектах.
 2. Теория UML

Что такое UML?

Унифицированный язык моделирования (UML) был разработан с целью обеспечить единый визуальный
язык с богатой семантикой и развернутым синтаксисом для проектирования и внедрения программных
систем со сложной структурой и комплексным поведением. Стоит отметить, что UML применяется не
только в разработке программ, но и в других сферах, например, в схематизации потоков
производственных процессов.
UML напоминает стандарты, используемые в других отраслях, и поддерживает диаграммы нескольких
типов. В целом, диаграммы UML описывают границы, структуру и поведение как всей системы, так и
отдельных объектов в ее составе.
UML не является языком программирования, однако на базе диаграмм UML можно сгенерировать код на
разных языках, и для этого существует ряд специальных инструментов. Зато с объектно-
ориентированным анализом и дизайном унифицированный язык моделирования связан напрямую.

UML и его роль в объектно-ориентированном анализе и дизайне

В информатике, науке об алгоритмах и данных, существует множество парадигм и моделей решения
задач. Выделяется четыре категории таких моделей — императивные, функциональные, декларативные
и объектно-ориентированные. Объектно-ориентированные языки представляют алгоритмы посредством
определения объектов и их взаимодействия друг с другом. Объекты существуют в реальном мире и
подвергаются тем или иным действиям. Объектами могут быть здания, виджеты рабочего стола и даже
люди.
Объектно-ориентированные языки преобладают в сфере программирования, так как моделируют
объекты реального мира. UML сочетает в себе несколько разновидностей объектно-ориентированной
нотации — объектно-ориентированный дизайн, технику объектного моделирования и разработку
объектно-ориентированного программного обеспечения.
Объединяя в себе сильные стороны всех трех подходов, UML обеспечивает своим пользователям
удобную и последовательную методологию и представляет собой набор эффективных методов
схематизации и документирования различных аспектов моделирования программ и бизнес-систем.

Истоки возникновения UML

В 1996 году совместная работа трех светлых умов вылилась в релиз документов, составленных по
принципам UML 0.9 и 0.91. Вскоре стало ясно, что некоторые крупные компании, включая Microsoft,
Oracle и IBM, полагаются на UML как на один из ключевых инструментов развития своего бизнеса. Вместе
с другими организациями и отдельными лицами эти компании обеспечили необходимые ресурсы для
развития UML до уровня полностью сформировавшегося языка моделирования. В 1999 году «три амиго»
опубликовали «Справочник пользователя унифицированного языка моделирования», а затем, в 2005
году, его вторую редакцию, где была представлена информация по UML 2.0.

OMG: новое значение знакомой аббревиатуры

Согласно сайту компании,Object Management Group® (OMG®) — международная некоммерческая
организация с открытым членством, которая была основана в 1989 году и занимается стандартизацией
технологий. Запрос на стандартизацию поступает от коммерческих организаций, конечных
пользователей, учебных заведений и правительственных органов. Специалисты OMG разрабатывают
стандарты интеграции корпоративной информации для широкого набора технологий и еще более
широкого спектра отраслей. Стандарты моделирования OMG, включая UML и MDA® (Model Driven
Architecture® — «архитектура, управляемая моделью»), позволяют своим пользователям эффективно
проектировать, внедрять и поддерживать программные и другие процессы.
OMG контролирует постоянство определений и параметров UML, давая программистам и разработчикам
возможность применять единый язык в разных целях на всех этапах жизненного цикла программного
обеспечения независимо от масштабов системы.

Цель существования UML согласно OMG

OMG определяет цель UML так:

 предоставить системным архитекторам, программистам и разработчикам инструменты для

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

UML выполняет следующие функции:

 задает формальное определение общей метамодели стандарта MOF (Meta-Object Facility —

«метаобъектное средство»), где изложен абстактный синтаксис UML. Абстрактный синтаксис
определяет набор концепций моделирования UML, а также их атрибуты, связи и правила
объединения для построения моделей, частично или полностью основанных на UML;
 дает подробное объяснение семантике каждой концепции моделирования UML. Семантика
определяет (без привязки к определенной технологии), как UML-концепции должны
реализовываться компьютерами;
 задает понятные для человека элементы нотации для отображения отдельных концепций
моделирования UML, а также правила объединения этих концепций в различные виды схем
согласно тем или иным аспектам моделируемых систем;
 определяет требования, которым должны отвечать UML-инструменты в рамках данного
стандарта. В дополнение прилагается отдельный стандарт на базе XML с указанием форматов
обмена моделями (XMI), которые должны поддерживаться инструментами для работы с UML.

UML и моделирование данных

Язык UML получил широкое распространение в среде программистов, однако в целом мало
используется в разработке баз данных. Одна из причин этого заключается в том, что создатели UML не
ставили базы данных в центр внимания. Тем не менее, UML эффективно применяется в концептуальном
моделировании данных высоких уровней и подходит для создания различных видов диаграмм UML.
Более подробно о том, как при помощи слоев преобразовать объектно-ориентированную модель в
схему реляционной базы данных, можно узнать в нашей статье по моделированию баз данных с
помощью UML.
Что нового в UML 2.0
Язык UML не перестает совершенствоваться. Стандарт UML 2.0 расширяет границы UML, охватывая
новые аспекты разработки, в том числе в гибкой среде. Новый стандарт был введен с целью
реструктурировать, усовершенствовать и упростить UML для удобства использования, внедрения и
адаптации. Вот несколько примеров того, как изменились диаграммы UML:

 более тесная интеграция между структурными и поведенческими моделями;

 возможность задавать иерархию и разбивать структуру программ на компоненты и
подкомпоненты;
 повышение количества схем в UML 2.0 с 9 до 13.

Термины UML
 Правила абстрактного синтаксиса — пользователи могут перемещать модели из одной
платформы в другую, даже если в них применяются разные системы нотации
 Общая метамодель хранилища данных (CWM) — набор стандартных интерфейсов,
обеспечивающих возможность обмена метаданными хранилища и бизнес-аналитики между
инструментами и платформами хранения, а также хранилищами метаданных в распределенных
однородных средах
 Правила конкретного синтаксиса — возможность пользоваться знакомой системой нотации на
разных платформах
 Ядро — в контексте UML, под ядром обычно подразумевается «ядерный пакет», который
представляет собой полноценную метамодель, разработанную специально для эффективного
многократного применения
 Языковая единица — коллекция тесно связанных концепций моделирования, которые дают
пользователям возможность представить исследуемые аспекты системы согласно выбранной
парадигме или формальной теории
 0-й уровень (L0) — нижний уровень соответствия инфраструктуры правилам UML, то есть одна
языковая единица, обеспечивающая возможность моделирования разнообразных классовых
структур, которые встречаются в наиболее распространенных объектно-ориентированных языках
программирования
 Метаобъектное средство (MOF) — набор правил моделирования OMG, на основе которого
составляются определения метамодели в семействе MDA-языков OMG
 Метамодель — определяет язык и процессы, на основе которых составляется модель
 Конструктив метамодели (LM) — второй уровень соответствия инфраструктуры правилам UML, то
есть дополнительная языковая единица, необходимая для более сложных классовых структур,
применяемых для построения метамоделей с использованием полного объема метаобъектных
средств (сокращенно CMOF), например, непосредственно языка UML. В UML выделяется только
два уровня соответствия правилам языка.
 Архитектура, управляемая моделью (MDA) — подход, а также план по созданию целостного
набора правил и технических характеристик, задаваемых моделью
 Объектный язык ограничений (OCL) — декларативный язык, описывающий правила,
применимые к унифицированному языку моделирования. OCL дополняет UML терминами и
символами блок-схем, которые характеризуются большей точностью, чем естественный язык, но
при этом усваиваются проще, чем математические символы.
 Object Management Group (OMG) — некоммерческая организация, занимающаяся разработкой
стандартов в сфере вычислительных технологий. Именно ее участники определяют и
поддерживают стандарты UML.
 UML 1 — первая версия унифицированного языка моделирования
  Унифицированный язык моделирования (UML) — визуальный язык, позволяющий
характеризовать, конструировать и документировать артефакты систем
 XMI — стандарт на основе XML, предназначенный для обмена моделями разных форматов

Концепции моделирования в рамках UML

В целом, в разработке систем выделяется три основных системных модели:

 Функциональная — схемы сценариев использования, описывающие функционал системы с точки

зрения ее пользователя.
 Объектная — диаграммы классов, описывающие структуру системы при помощи объектов,
атрибутов, связей и операций.
 Динамическая — диаграммы взаимодействия, состояний и активности, применяемые для
описания внутренней работы системы.
Наглядное представление этих системных моделей осуществляется с помощью схем двух разных типов
— структурных и поведенческих.

Объектно-ориентированные концепции в UML

Объекты в UML — это упрощенное представление предметов окружающего нас мира. В разработке
программного обеспечения объекты используются для описания (или моделирования) создаваемой
системы с применением терминологии соответствующей сферы. Объекты также позволяют разбить
сложные системы на понятные составляющие и выстроить схему блок за блоком.

Ниже приведены некоторые фундаментальные концепции объектно-ориентированной методологии:

 Объекты — сущности и простейшие строительные элементы схемы.

 Класс — прообраз объекта.
 Абстракция — поведение объекта реального мира.
 Инкапсуляция — механизм, позволяющий объединить данные и скрыть их от внешнего мира.
 Наследование — механизм создания новых классов на основе уже имеющихся.
 Полиморфизм — механизм, позволяющий объектам существовать в разных формах.

Разновидности диаграмм UML

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

Структурные диаграммы UML

 Диаграммы классов — наиболее распространенная разновидность диаграмм UML и

фундаментальная база любого объектно-ориентированного решения. Отображают классы внутри
системы, а также атрибуты, операции и отношения между классами. Диаграммы классов
применяются при схематизации крупных систем, так как позволяют объединять классы в группы.
 Диаграммы компонентов отражают структурные отношения между элементами программной
системы и чаще всего применяются при работе с комплексными структурами, состоящими из
 множества компонентов. Взаимодействие между компонентами осуществляется посредством
интерфейсов.
 Диаграммы композитной структуры применяются для схематизации внутренней структуры
класса.
 Диаграммы развертывания иллюстрируют аппаратное и программное обеспечение системы.
Удобны в тех случаях, когда программный продукт применяется на нескольких компьютерах с
индивидуальными настройками.
 Диаграммы объектов отражают отношения между объектами посредством примеров из
реального мира и показывают, как система будет выглядеть в заданный момент времени.
Данные, содержащиеся в объектах, могут использоваться для характеризации связей между
ними.
 Диаграммы пакетов. Между пакетами выделяется два особых вида зависимости —
импортирование и слияние. Пакеты могут символизировать разные уровни системы, позволяя
воссоздать ее архитектуру. Чтобы показать механизм взаимодействия между уровнями, на схеме
также можно отметить зависимость между пакетами.

Поведенческие диаграммы UML

 Диаграммы активности схематично отображают потоки рабочих или операционных процессов,

иллюстрируя активность в разных частях или компонентах системы. Диаграммы активности
используются в качестве альтернативы диаграммам состояний.
 Схемы коммуникации напоминают диаграммы последовательностей, однако во главу угла ставят
сообщения, передаваемые между объектами. Диаграммы последовательностей позволяют
донести ту же информацию с помощью другого набора объектов.
 Диаграммы обзора взаимодействий. Существует семь разновидностей диаграмм
взаимодействий, и на этой схеме показана последовательность их применения.
 Диаграммы последовательностей показывают, как и в какой последовательности объекты
взаимодействуют между собой. Взаимодействие иллюстрирует определенный сценарий.
 Диаграммы состояний похожи на диаграммы активности, они описывают поведение объектов,
которые ведут себя по-разному в их текущем состоянии.
 Временные диаграммы напоминают диаграммы последовательности, так как отображают
поведение объектов в заданный отрезок времени. Простые диаграммы описывают один объект,
тогда как сложные показывают взаимодействие нескольких объектов за указанный период.
 Схемы сценариев использования отображают конкретные функции системы и объясняют, как
они соотносятся с внутренними/внешними контроллерами (агентами).

3. Моделирование информационной системы

Диаграмма вариантов использования
Диаграмма вариантов использования в UML — диаграмма, отражающая отношения между акторами и
прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на
концептуальном уровне.

Рис. 1. Диаграмма взаимодействия клиента с системой

На Рис. 1 изображена диаграмма, которая описывает взаимодействие клиента с системой. В данном
случае клиент использует логику формирования заказа, которая включает в себя выбор товара. А выбор
товара включает в себя такие компоненты как «Получение наличия товаров», «Получение списка
товаров» и «Получение актуальных цен товара».
Формирование заказа предшествует добавлению заказа в бд. А добавление заказа в БД включает в себя
следующие компоненты «Привязка товаров к заказу», «Запись адреса доставки в БД» и «Обновление
наличия товаров»

Рис. 2. Диаграмма взаимодействия продавца с системой

На Рис. 2 изображена диаграмма, которая описывает взаимодействие продавца с системой. В данном

случае продавец анализирует спрос и формирует заказ на поставку товаров у поставщика. Анализ спроса
включает в себя такие компоненты как «Выгрузка наличия товаров», «Выгрузка цен», «Выгрузка заказов»
и «Выгрузка товаров»
 Рис. 3. Диаграмма взаимодействия поставщика с системой

На Рис. 3 изображена диаграмма, которая описывает взаимодействие поставщика с системой. В данном

случае поставщик использует заказ на поставку товаров от продавца и реализует доставку товаров в
магазин. В свою очередь, Доставка товаров в магазин влияет на изменение асортимента. Изменение
асортимента включает в себя «Обновление цен», «Обновление товаров» и «Обновление наличия»
Диаграмма последовательности
Диаграмма последовательности — UML-диаграмма, на которой для некоторого набора объектов на
единой временной оси показан жизненный цикл объекта (создание-деятельность-уничтожение некой
сущности) и взаимодействие актеров (действующих лиц) информационной системы в рамках
прецедента.

Рис. 4. Диаграмма последовательности работы клиента с системой

На Рис. 4 изображена диаграмма, которая описывает последовательность работы клиента с системой. В
данном случае клиент не работает напрямую с БД. Клиент работает с frontend частью интернет магазина
(со скомпилированными шаблонами). А backend код, который выполняется до компиляции шаблонов,
работает с бд. В данном случае нет необходимости в асинхронных запросах. Так как тут важна четкая
последовательность действий, именно поэтому все запросы являются синхронными и ответы также
синхронны.

Рис. 5. Диаграмма последовательности работы продавца с системой для формирования заказа на

поставку товаров

На Рис. 5 изображена диаграмма, которая описывает последовательность работы продавца с системой.

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

Диаграмма коммуникации
Диаграмма коммуникации — диаграмма, на которой изображаются взаимодействия между частями
композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на
диаграмме коммуникации явно указываются отношения между объектами, а время как отдельное
измерение не используется (применяются порядковые номера вызовов).
 Рис. 7. Диаграмма коммуникации клиента с системой

На Рис. 7 изображена диаграмма коммуникации, которая моделирует взаимодействия между

объектами. А именно показана последовательность взаимодействий пользователя с сайтом, для выбора
товаров, добавления их в корзину и оформления заказов.

Рис. 8. Диаграмма коммуникации продавца с системой

На Рис. 8 изображена диаграмма коммуникации, которая моделирует взаимодействия продавца с
сайтом, для анализа спроса и получения актуальной информации по заказам и наличию товаров.

Диаграмма классов
Диаграмма классов — структурная диаграмма языка моделирования UML, демонстрирующая общую
структуру иерархии классов системы, их коопераций, атрибутов (полей), методов, интерфейсов и
взаимосвязей между ними. Широко применяется не только для документирования и визуализации, но
также для конструирования посредством прямого или обратного проектирования.

Рис. 9. Диаграмма классов для работы клиента с системой

На Рис. 9 изображена диаграмма классов для отображения взаимодействия интерфейса интернет

магазина который реализован при помощи класса ShowPageTemplates(), и который в свою очередь
взаимодействует с другими классами для получения от них данных, и выполнения интерактивных
действий на сайте.
 Рис. 10. Диаграмма классов для работы продавца с системой

На Рис. 10 изображена диаграмма классов для отображения взаимодействия интерфейса админ панели
интернет магазина который реализован при помощи класса ShowAminPageTemplates(), и который в свою
очередь взаимодействует с другими классами для получения от них данных и администрирования
админпанели.

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

На Рис. 11 изображена диаграмма состояний, которая моделирует авторизацию пользователя с учетом

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

Диаграмма действий
Диаграмма деятельности (англ. activity diagram) — UML-диаграмма, на которой показаны действия,
состояния которых описано на диаграмме состояний. Под деятельностью (англ. activity) понимается
спецификация исполняемого поведения в виде координированного последовательного и параллельного
выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий англ.
action, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.
 Рис. 12. Диаграмма действий расчета стоимости доставки в зависимости от суммы заказа

На Рис. 12 изображена диаграмма действий, которая показывает модель расчета стоимости доставки, в
зависимости от суммы заказа в корзине. Аналагичную диаграмму можно построить для различных
условий, не только цены. А например города заказчика, или веса товаров в корзине.
 Рис. 13. Диаграмма действий от авторизации пользователя до оформления заказа

На Рис. 13 изображена диаграмма действий, которая показывает модель действий от авторизации

пользователя на портале, до оформления заказа. Данная диаграмма дает представление о структуре
сайта, при проектировании юзабилити интернет магазина. Что в свою очередь снижает количество
отказов, из за сложности frontend функционала интернет магазина.

Диаграмма компонентов
Диаграмма компон2ентов (англ. Component diagram) — элемент языка моделирования UML, статическая
структурная диаграмма, которая показывает разбиение программной системы на структурные
компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут
выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п
 Рис. 14. Диаграмма компонентов связей заказа с другими компонентами
На Рис. 14 изображена диаграмма компонентов, которая показывает связь компонентов заказа и
образует заказ. Например, в данном случае заказ содержит в себе детали аккаунта, детали о заказчике и
коды товаров, а также данные об оплате заказа.

Рис. 15. Диаграмма компонентов (таблиц базы данных) между собой

На Рис. 15 изображена диаграмма компонентов, которая показывает связи таблиц Базы данных интернет
магазина между собой. Связующими компонентами являются ID различных компонентов, которые
пересекаются в разных таблицах.
Диаграмма развёртывания
Диаграмма развёртывания (англ. Deployment diagram) в UML моделирует физическое развертывание
артефактов на узлах. Например, чтобы описать веб-сайт, диаграмма развертывания должна показывать,
какие аппаратные компоненты («узлы») существуют (например, веб-сервер, сервер базы данных, сервер
приложения), какие программные компоненты («артефакты») работают на каждом узле (например, веб-
приложение, база данных), и как различные части этого комплекса соединяются друг с другом
(например, JDBC, REST, RMI).

Рис. 16. Диаграмма развёртывания узлов сайта

На Рис. 16 изображена диаграмма развёртывания, которая показывает связи узлов и компонентов узлов.
В данном случае диаграмма описывает связи между клиентским устройством и серверами интернет
магазина.
 Вывод
Этот курс показался мне очень интересным, я для себя узнал много нового. И познакомился с новым
способом выражения и постановки задач, через моделирование диаграмм.
В ходе этого учебного курса я выделил для себя определенные плюсы и минусы использования UML
диаграмм. Основным минусом является необходимость знания различных диаграмм и их нотаций.
Но у диаграмм есть и множество плюсов. Диаграммы дают возможность посмотреть на задачу с разных
точек зрения. При описании задачи диаграммой другим программистам легче понять суть задачи и
способ ее реализации. Так же диаграммы сравнительно просты для чтения после достаточно быстрого
ознакомления с их синтаксисом.
 Библиография
Что такое Enterprise Architect?: [сайт]. - URL: https://www.uml2.ru/faq/faq-ea/1/#:~:text=Enterprise
%20Architect%20(EA)%20%E2%80%93%20CASE,%D0%BC%D0%BE
%D0%B3%D1%83%D1%82%20%D0%B1%D1%8B%D1%82%D1%8C%20%D0%BE%D0%BF
%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D1%8B%20%D0%BC%D0%BE
%D0%B4%D0%B5%D0%BB%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA
%D1%82%D0%B0. (дата обращения: 14.01.2021). - Текст: электронный.
Диаграмма прецедентов: [сайт]. - URL: https://ru.wikipedia.org/wiki/
%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BF
%D1%80%D0%B5%D1%86%D0%B5%D0%B4%D0%B5%D0%BD%D1%82%D0%BE%D0%B2.
(дата обращения: 14.01.2021). - Текст: электронный.
Диаграмма последовательности: [сайт]. - URL: https://ru.wikipedia.org/wiki/
%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BF
%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE
%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE
%D1%81%D1%82%D0%B8 (дата обращения: 14.01.2021). - Текст: электронный.
Диаграмма коммуникации: [сайт]. - URL: https://ru.wikipedia.org/wiki/
%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BA
%D0%BE%D0%BC%D0%BC%D1%83%D0%BD%D0%B8%D0%BA
%D0%B0%D1%86%D0%B8%D0%B8. (дата обращения: 14.01.2021). - Текст: электронный.
Диаграмма классов: [сайт]. - URL: https://ru.wikipedia.org/wiki/
%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BA
%D0%BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2. (дата обращения: 14.01.2021). - Текст:
электронный.
Диаграмма коммуникации: [сайт]. - URL: https://ru.wikipedia.org/wiki/
%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BA
%D0%BE%D0%BC%D0%BC%D1%83%D0%BD%D0%B8%D0%BA
%D0%B0%D1%86%D0%B8%D0%B8. (дата обращения: 14.01.2021). - Текст: электронный.
Диаграмма развёртывания: [сайт]. - URL: https://ru.wikipedia.org/wiki/
%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_
%D1%80%D0%B0%D0%B7%D0%B2%D1%91%D1%80%D1%82%D1%8B
%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F. (дата обращения: 14.01.2021). - Текст:
электронный.
Диаграмма компонентов: [сайт]. - URL: https://ru.wikipedia.org/wiki/
%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BA
%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BE%D0%B2.
(дата обращения: 14.01.2021). - Текст: электронный.