5 free websites to create uml online
Содержание:
- Введение
- Become a UML evangelist
- Cacoo:
- Draw.io
- Отношение расширения
- Textual database modeling
- Multi-language textual diagramming tools
- Отношения между классами
- Mindmeister
- Замечания (описание)
- Отношение ассоциации
- Виды диаграмм на UML и средства для их построения
- Canva
- Draw.io
- 3.1. Диаграмма вариантов использования (Use-case diagram).
- Состояния активности в диаграмме состояний
- Lucidchart:
- Отношение включения
- Сравнение двух подходов структурирования диаграммы Activity (по мотивам «Белки»)
- Заключение
- Заключение и список литературы
Введение
Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.
Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.
Уверен, многие слышали о PlantUML, по крайней пере, на GitHub у него стоит больше тысячи звезд. Смысл этого инструмента исключительно прост, он всего лишь позволяет задавать диаграммы (по большей части в нотации UML) в виде текста, описывающего элементы и связи между ними. Графический вид создается автоматически. Далее приведен пример диаграммы деятельности.
Несмотря на популярность, на Хабре очень мало статей, рассказывающих о практическом применении этого инструмента. Как мне кажется, PlantUML такого недостатка внимания не заслуживает.
В начале я расскажу, почему выбрал его в качестве основного инструмента визуального моделирования, а в конце приведу ряд рекомендаций, которые бы мне самому очень хотелось услышать, когда начал использовать данный инструмент.
Become a UML evangelist
Sometimes it’s not enough for you to be on board the UML diagramming train: After all, as a software developer, you’re usually working with teams, and it’s important to get everyone else along for the ride.
If your team is reluctant to integrate UML diagrams into the development process, propose using them for just one project to start. Once your team sees what a boon UML diagrams are to documentation, they’ll be more willing to start making them a necessary step.
Plus, with Lucidchart, creating UML diagrams aren’t a chore: They’re an asset. Get started with the UML templates and shape libraries in Lucidchart.
Cacoo:
Cacoo is the second free website on my list to create UML online. Its free plan lets you create and manage 6 UML projects and supports real-time collaboration with up to 15 people. I will prefer it over Draw.io because of its real-time collaboration feature as it lets you add the most number of people to collaborate in the real-time to draw UML diagrams together, as compared to other online UML designer websites on my list. Well, you can design Use Case, ERD, etc UML diagrams with it. The exporting options are also good as you can choose to download the designed UML diagrams as PNG, JPG, and PDF formats.
In the end, you can save the designed UML diagram as an image file on your PC. Use the Export option at the top to download the UML diagram.
You can draw some of these UML diagrams online on Cacoo:
- State Machine
- Use Case
- Sequence
- Class
- Activity
- Package
- ERD
Draw.io
Love its simplicity. Click draw.io in your browser and you immediately get an empty canvas to start drawing. It comes with shapes for basic UML, ER and BPMN modeling. Still, it’s a clear example of a tool that doesn’t really understand at all the semantics of what you’re drawing so you can basically do whatever you want and build some very bizarre diagrams. It also fails in the collaborative aspect but it integrates well with Google Drive, Dropbox , OneDrive and others to automatically save the models in your preferred location.
Draw.io is open source and it has been built using the mxGraph library .
Отношение расширения
Нужно сказать, что в диаграммах вариантов использования применяется ещё один вид связи – отношение расширения. На мой взгляд, применение отношение расширения несколько специфично, поскольку неправильное его использование может запутать читателя диаграммы. Тем не менее, для полноты картины мы всё равно рассмотрим применение этого отношения на практике. В последний раз модифицируем нашу диаграмму!
Во время дистанционного обучения школьникам необходимо выполнять домашние задания и присылать их в виде архива или фотографий учителям. Получается, нужно добавить возможность прикреплять файл к сообщению в нашей системе. Чтобы отобразить это на диаграмме мы будем использовать отношение расширения. Отношение расширения обозначается пунктирной линией с V-образной стрелкой на конце (похоже на отношение включения), над стрелкой добавляется надпись “extend ”.
Чтобы лучше понять этот тип отношений рассмотрим пример. Допустим, вы делаете заказ в сети быстрого питания. Вы хотите заказать бургер. Вам, скорее всего, вам предложат расширить ваш заказ картошкой фри или соусом. Давайте изобразим процесс заказа на диаграмме вариантов использования.
На диаграмме предполагается, что к заказу МОЖЕТ БЫТЬ
добавлена картошка фри или соус (необязательно)
Два нижних варианта использования описывают возможные «расширения» для базового варианта использования
Исходя из этого примера, мы можем сделать важное замечание
Вернёмся к нашему основному примеру. Мы хотим, чтобы действие «прикрепить файл к сообщению» расширяло действие «отправить сообщение». На диаграмме это изображается следующим образом:
Расширяем функционал отправки сообщений
с помощью функции прикрепления файлов к сообщению
(Необязательно прикреплять файл к каждому сообщению)
Как итог, получим такую диаграмму:
Четвёртая версия диаграммы
Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!
Общие рекомендации:
Textual database modeling
There’s life beyond UML. If you’re more into ER than UML (and I agree that ER has some good points), QuickDatabaseDiagrams offers a textual notation to draw ER diagrams. Also, Umple (described above) supports the generation of ER visualizations.
ERD is another option. It takes a plain text description of entities, their attributes and relationships and renders a graphical entity-relationship diagram. The visualization is produced with the help of Dot with GraphViz. ERD takes some inspiration from ERWiz that had the same goal but it’s now abandoned.
DBDiagrams.io is a free, simple tool to draw ER diagrams by just writing “code”. Designed for developers and data analysts, over 250K diagrams have been created with this tool. It comes with some handy features like creating SQL scripts from the diagrams and, conversely, the creation of diagrams from existing SQL databases.
Multi-language textual diagramming tools
Some tools aim to provide generic textual support to a variety of modeling languages.
One API to run them all: Kroki
More than an alternative different syntax/rendering to those mentioned so far, Kroki provides a unified API with support for a number of diagrams. Basically, in one tool (or better said in one API) you have all the model types you may want to create from the text. You can install it on your own machine or use Kroki as a free external service.
Choose the textual notation you prefer
Asciidoctor Diagram
Asciidoctor Diagram is a set of Asciidoctor extensions that enable you to add diagrams (generated as SVG or PNG) to documents. Diagrams can be described using a textual syntax compatible with many of the tools we’ve seen above, which gives you plenty of flexibility to integrate many types of models in your docs.
Отношения между классами
Существует четыре типа связей в UML:
- Зависимость
- Ассоциация
- Обобщение
- Реализация
Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.
Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.
Зависимость – это связь использования, указывающая, что изменение спецификаций одной сущности может повлиять на другие сущности, которые используют ее. Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.
Mindmeister
Сервис для создания ментальных карт и диаграмм. У него неплохой функционал, хорошо реализованные возможности командной работы – поддержка мобильной версии, чат и комментирование. Можно добавлять ссылки, изображения и видео, вставлять созданные файлы в свой блог или сайт, просматривать историю изменений, создавать из проекта презентации и слайд-шоу, есть даже функция рисования. Сохранять можно в PNG, PDF, а также программу Word. Сервис интегрируется с приложениями Гугла.
Имеется бесплатный тариф с 3 проектами карт, но есть и платные версии – от $36 за полгода, с более широкими возможностями.
Замечания (описание)
Здесь представлен основной набор символов диаграммы состояний , необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы состояний самостоятельно!
Термин | Изображение | Описание |
---|---|---|
Начальное псевдосостояние (initial pseudostate) | Начальное состояние системы | |
Переход | Переход (transition) означает перемещение из одного состояния в другое. | |
Состояние | Обозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. | |
Состояние активности (activity state) |
Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй. |
|
Конечное состояние | Позволяет обозначить границы систем или подсистем. | |
Внутренние активности (internal activities) |
Случай когда состояния могут реагировать на события без совершения перехода, и в этом случае событие, защита и активность размещаются внутри прямоугольника состояния. |
|
Входная активность |
Входная активность выполняется всякий раз, когда вы входите в состояние |
|
Выходная активность |
Выходная активность – выполняется всякий раз, когда вы покидаете состояние. |
|
Суперсостояние | Часто бывает, что несколько состояний имеют общие переходы и внутренние активности. В таких случаях можно их превратить в подсостояния (substates), а общее поведение перенести в суперсостояние (superstate). | |
Параллельные состояния | Состояния могут быть разбиты на несколько параллельных состояний, запускаемых одновременно. |
Отношение ассоциации
Мы хотим отображать на диаграмме информацию о том, какие варианты использования могут быть использованы каждым актёром. Сейчас, например, мы хотим показать, что выставлять оценки могут только преподаватели.
Изображаем на диаграмме информацию о том, что преподаватели могут выставлять оценки
Мы соединили актеров с вариантом использования с помощью сплошной линии без стрелки. Такая линия называется отношением ассоциации.
Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.
Изображаем на диаграмме возможность покупателей оплачивать заказы
Если на диаграмме вариантов использования актёр соединен с вариантом использования с помощью отношения ассоциации, это означает, что данный актёр может выполнять действия, описанные вариантом использования.
Добавим еще вариантов использования и соединим их с соответствующими актёрами:
Первая версия диаграммы
Пока что наша диаграмма совсем не впечатляет, поэтому мы продолжим наполнять ее информацией. Заодно мы узнаем все возможности этого вида диаграмм.
Виды диаграмм на UML и средства для их построения
Ранее мы писали, что совместное использование BPMN и UML это наиболее рациональный подход к визуальному моделированию в процессе проектирования сложных информационных систем различного назначения. В этой статье рассмотрим построение UML диаграмм с помощью программных средств различного класса и назначения. Что касается построения BPMN диаграмм с помощью специализированных программ, то можно посмотреть в статье «Программы создания диаграмм BPMN«.
Хорошо известно, что в процессе проектирования информационных систем широкое применение нашел способ организации и управления архитектурой проектируемой системы Model Driven Architecture (MDA). Этот подход поддерживается современными автоматизированными инструментальными средствами разработки информационных систем для определения моделей, а также для облегчения преобразований между различными типами моделей. Для построения моделей в рамках MDA широко используется построение диаграмм на унифицированном языке моделирования UML.
Унифицированный язык моделирования (UML) является стандартным языком для определения, визуализации, конструирования и документирования артефактов информационных и программных систем. Его применение упрощает сложный процесс проектирования информационных систем и их программного обеспечения, дополняя «проект» их построения визуальными представлениями артефактов, в качестве которых выступают модели и диаграммы.
Здесь рассматривается построение UML диаграмм при курсовом и дипломном проектировании, а не полная разработка всех решений, предусмотренных ГОСТ. В курсовом и дипломном проектировании достаточно разработать функционально — алгоритмическую структуру системы, которая в соответствие с принципами объектно-ориентированного проектирования представляется как совокупность взаимодействующих объектов.
Поэтому для построения моделей проектируемых информационных систем в рамках курсового и дипломного проектирования применяются следующие основные диаграммы на языке UML:
- диаграмма деятельности для визуального моделирования предметной области и детализации вариантов использования системы;
- диаграмма вариантов использования для представления функциональных требований к системе;
- диаграмма классов для представления архитектуры проектируемой информационной системы;
- диаграмму последовательности для представления взаимодействия объектов во времени;
- диаграмма компонентов для представления модулей(компонентов) программного обеспечения, из которых реализуется ИС;
- диаграмму развертывания для представления размещения компонентов по узлам вычислительной системы при реализации ИС.
Примечание. Для большей наглядности рекомендуется строить комбинированную диаграмму компонентов и развертывания.
Построение UML диаграмм можно выполнять вручную на листе бумаги или на доске, а также с помощью специализированного программного обеспечения. Среди достаточно большого количества средств построения диаграмм на UML можно выделить два класса. Первый класс – простые и дешевые(иногда бесплатные) программы, позволяющие автоматизировать построения диаграммы без генерации программного кода. К таким программам относятся графический редактор MS Visio, StarUML
Второй класс это, так называемые CASE-средства, представляющие собой набор инструментов, предназначенный для автоматизации визуального моделирования, проектирования, документирования и генерации кода реализации на выбранном алгоритмическом языке. К таким средствам относятся CASE-средства визуального моделирования и проектирования компании IBM Rational Software Corp — Rational Rose и Rational Software Architect, продукт проектирования и интеграции компании Borland – Together и другие.
CASE-средство визуального моделирования Rational Rose является хорошим и достаточно доступным инструментом создания артефактов проектирования информационных систем. В предыдущих статьях мы рассматривали его применение в курсовом и дипломном проектировании в процессе:
- выполнения предпроектного обследования предметной области,
- технического(архитектурного) проектирования и
- рабочего проектирования информационной системы.
Canva
Простой, понятный сервис для создания красивых блок-схем. Набор функций мало отличается от всех вышеперечисленных вариантов, однако Canva может похвастаться возможностью настройки внешнего вида. Фон страницы, шрифт и цвет текстов, добавление изображений – собственных или из огромной библиотеки. Есть даже встроенный фоторедактор. Разумеется, здесь есть и поддержка командной работы. Для работы с мобильных устройств есть приложения как для iOS, так и для Android. Сохранение проектов – в формат PDF.
Сервис бесплатен, но есть премиум-элементы (фото и векторные изображения), они стоят $1 за штуку.
Draw.io
Самый популярный онлайн-сервис для создания блок-схем. Он бесплатный и обладает хорошим набором инструментов и функций, позволяющих создавать организационные диаграммы, блок-схемы (флоучарты), сетевые диаграммы, UML, принципиальные электросхемы. У сервиса есть 5 готовых шаблонов блок-схем. Понятный интерфейс, поддерживает виртуальные хранилища – Google Drive, OneDrive и DropBox, что даёт возможности нескольким пользователям совместно работать над проектом. Сохранить проект можно в форматах JPG, PNG, SVG, PDF, HTML, XML, можно импортировать файлы в VSDX, и сохранять в собственные форматы других сервисов – Lucidchart и Gliffy.
Для большинства пользователей набора его опций хватает. Тем, кому нужны более широкие возможности, стоит рассмотреть другие варианты.
3.1. Диаграмма вариантов использования (Use-case diagram).
Диаграмма вариантов использования является отправной точкой в процессе моделирования. Она предназначена для описания взаимодействия проектируемой системы с любыми внешними или внутренними объектами — пользователями, другими системами и т.п.
Основными понятиями при работе с диаграммой вариантов использования являются Актор (Actor) и Вариант использования (Use case).
Актор – это роль, которую выполняет пользователь или другая система, при взаимодействии с проектируемой системой.
Проектирование диаграммы вариантов использования начинается с определения списка Акторов. На диаграммах Актор обозначается следующим значком:
Каждый Актор обладает уникальным именем.
Друг с другом акторы могут быть связаны различного рода отношениями.
Например, акторы могут наследоваться друг от друга.
Это означает, что акторы-наследники наследуют характеристики базовых акторов.
Следующим этапом после определения списка акторов является определение списка вариантов использования.
Вариант использования – это конечная единица взаимодействия актора и системы. Совокупность всех вариантов использования полностью определяет поведение системы.
Вариант использования обозначается значком:
Каждый вариант использования относится к каком-либо актору. Такое отношение обозначает, что данный актор инициирует данный вариант использования.
Например:
означает, что актор User инициирует вариант использования Login.
Один и тот же вариант использования может использоваться несколькими акторами, например:
вариант использования Login используется двумя акторами.
Варианты использования также могут быть связаны друг с другом различными отношениями.
1.«Включение» одного варианта использования в другой. Означает, что один вариант использования инициируется в процессе другого. Например:
2.«Расширение». Означает, что один вариант использования является дополнением или уточнением другого варианта использования в случае наступления некоторых условий. Например:
3.«Реализация». Означает, что один вариант использования является реализацией другого варианта использования. Например, если один из них описан в терминах бизнес-процессов, а другой – в терминах проектируемой системы.
Например:
Кроме того, варианты использования могут быть связаны отношением «Реализация» с требованиями к системе и с классами. При наличии таких связей есть возможность проследить в каких классах реализованы требования и какие классы могут быть затронуты при изменении требований или вариантов использования.
Например:
Кроме Акторов и Вариантов использования на диаграмме также могут находиться следующие элементы:
“Collaboration” – элемент, предназначенный для визуальной группировки объектов – акторов и вариантов использования – по принципу их совместной работы.
Обозначается значком
Например,
«Boundary» — элемент, предназначенный для визуальной группировки объектов – акторов и вариантов использования – по принципу их распределения на подсистемы или компоненты.
Обозначается значком
Например:
Среди акторов могут быть не только пользователи, но и внешние системы и внутренние подсистемы.
Состояния активности в диаграмме состояний
В состояниях, которые мы описывали до сих пор, объект молчит и ожидает следующего события, прежде чем что-нибудь сделать. Однако возможны состояния, в которых объект проявляет некоторую активность.
Состояние Searching (Поиск) на рис. 10.3 является таким состоянием активности (activity state): ведущаяся активность обозначается символом do/; отсюда термин do-activity (проявлять активность). После того как поиск завершен, выполняются переходы без активности, например показ нового оборудования (Display New Hardware). Если в процессе активности происходит событие отмены (cancel), то do-активность просто прерывается и мы возвращаемся в состояние Update Hardware Window (Обновление окна оборудования).
И do-активности, и обычные активности представляют проявление некоторого поведения. Решающее различие между ними заключается в том, что обычные активности происходят «мгновенно» и не могут быть прерваны обычными событиями, тогда как do-активности могут выполняться в течение некоторого ограниченного времени и могут прерываться, как показано на рис. 10.3. Мгновенность для разных систем трактуется по-разному; для систем реального времени это может занимать несколько машинных инструкций, а для настольного программного обеспечения может составить несколько секунд.
В UML 1 обычные активности обозначались термином action (действие), а термин activity (активность) применялся только для do-активностей.
Lucidchart:
Lucidchart is another free online UML designer website on my list to create UML online. I find its free plan quite limited as you can only keep 3 active UML diagrams but you do get the option to real-time collaborate with peers to design UML diagrams with your colleagues. From its online UML designer app, you can draw Activity, DFD, State, etc diagrams and export them as PDF, JPG, PNG, etc. Once you have created an account on Lucidchart, you can create a new blank UML diagram or choose a UML diagram template to edit. The interface of its online UML designer editor is shown in the screenshot above. All UML diagram symbols are present in the toolbox on the left. All the symbols are categorized under different UML diagrams. You can drag and drop these UML diagrams from the toolbox onto its canvas. After that, you can connect and align them to design your UML diagram. Once done, done you can export the UML diagram as an image or PDF format.
Following are the diagrams supported by Lucidchart:
- ERD & Data Flow
- Activity
- Sequence
- Component
- Class diagram
- Use Case
- State Diagram
Отношение включения
Для заместителя директора мы отмечали, что ему нужно составлять расписания. Условно расписание можно поделить на три категории:
-
Расписание занятий
-
Расписание мероприятий
-
Расписание каникул
Всё это составляется заместителем директора, поэтому покажем это на диаграмме. Для этого будем использовать отношение включения. Отношение включения обозначается пунктирной линией с V-образной стрелкой на конце, над стрелкой добавляется надпись “include”.
В общем случае, отношение включения используется, чтобы показать, что некоторый вариант использования включает в себя другой вариант использования в качестве составной части.
Поясню смысл и этого отношения на небольшом примере. Когда пользователь сохраняет результаты своей работы в файл, он указывает место сохранения и расширение файла (например, если он редактировал фотографию в photoshop, он может сохранить ее в различных форматах). Этот процесс можно изобразить на диаграмме вариантов использования следующим образом:
Отношение включения используется для
изображения составного действия
Снова вернёмся к нашему основному примеру.
Составление расписания ВКЛЮЧАЕТ в себя составление
расписания занятий, мероприятий, каникул(обязательно)
Как итог, наша диаграмма принимает следующий вид:
Третья версия диаграммы
В целом, на этом можно остановиться. Хоть наш пример и демонстрационный, он немного отражает функциональность реального приложения. Тем не менее, остался еще один элемент, который мы не рассмотрели.
Сравнение двух подходов структурирования диаграммы Activity (по мотивам «Белки»)
В 1-ой части статьи «От моделирования процессов к проектированию автоматизированной системы» мы моделировали процессы «сказочной» предметной области — строчки про белку из «Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди» А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.
В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems .
Подробнее о применяемых подходах к моделированию см. .
Заключение
Применение UML диаграмм упрощает сложный процесс проектирования информационных систем и их программного обеспечения, дополняя «проект» их построения визуальными представлениями артефактов.
Построение UML диаграмм на начальном этапе освоения технологии целесообразно осуществлять с использованием простых и дешевых(иногда бесплатных) программ, позволяющих автоматизировать построение диаграммы без генерации программного кода. К таким программам относятся графический редактор MS Visio, StarUML
Для профессиональной работы по проектированию информационных систем и их программного обеспечения следует применять CASE-средства, представляющие собой набор инструментов, предназначенный для автоматизации визуального моделирования, проектирования, документирования и генерации кода реализации на выбранном алгоритмическом языке.
К таким средства относятся CASE-средства визуального моделирования и проектирования компании IBM Rational Software Corp — Rational Rose и Rational Software Architect, продукт проектирования и интеграции компании Borland – Together и другие.
На этом краткий обзор программ заканчивается. Успехов в их применении.
Заключение и список литературы
В статье я постарался описать наиболее существенные элементы диаграммы классов, а также аспекты их применения. Просматривается, что диаграмма строится на начальном этапе проектирования (концептуальная модель) и является его результатом. На всех этапах проектирования созданная в начале диаграмма классов дорабатывается, т.е. я рассматриваю итеративный процесс (такой как RUP или ICONIX). Кроме того, показано, использование диаграммы классов в других целях — эскизирования, документирования, моделирования логической схемы БД. На других страницах этого блога вы можете найти множество примеров использования диаграммы классов.
- диаграмма шаблона проектирования Publish-Subscriber ;
- множество диаграмм, демонстрирующих шаги рефакторинга для приведения проекта в соответствие принципам SOLID ;
- диаграммы классов для паттерна адаптер и сетевого чата .
- Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. — М.: ООО «И.Д. Вильямс», 2010. — 720 с.
- Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ — Петербург, 2007. – 576с.
- Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. — М.: Издательский дом «Вильямс», 2001. — 496 с.
- Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
- Бадд Т. Объектно-ориентированное программирование в действии: Пер с англ. — СПб: «Питер», 1997. — 464 с. 2002
- Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. — М.: ДМК, 2000. — 432 с.
- Фаулер, М. UML. Основы / М. Фаулер, К. Скотт; пер. с англ. – СПб.: Символ – Плюс, 2002. – 192 с.
- SOLID принципы. Рефакторинг — URL: https://pro-prof.com/archives/1914
- Основы UML. Диаграммы последовательности — URL: https://pro-prof.com/archives/2769
- UML data modeling — URL: http://www.agiledata.org/essays/umlDataModelingProfile.html
- Использование doxygen — URL: https://pro-prof.com/archives/887
- Паттерны MVC и Publish-Subscriber — URL: https://pro-prof.com/archives/2400
- Работа с сетью в Qt. Сокеты. Паттерн Adapter — URL: https://pro-prof.com/archives/1372