Диаграмма классов в языке моделирования UML относится к структурному типу диаграмм, используется для визуализации структуры классов в системе, атрибутов, методов, интерфейсов и отношений между ними. Применяется при проектировании архитектуры, документировании системы, уточнении требований, а также для поддержки системы.
Что показывает диаграмма классов
Диаграмма классов представляет описание структуры классов в системе и их взаимосвязи. Она отображает как статические аспекты системы, включая классы, атрибуты и методы, а также динамические аспекты, такие как связи между объектами и выполнение методов во время выполнения программы.
Классы на диаграмме представляются в виде прямоугольников, которые могут содержать информацию об атрибутах и методах класса. Атрибуты — это переменные, которые хранят данные внутри объектов, созданных на основе класса. Методы — это функции, которые описывают поведение класса и могут изменять его состояние.
Связи между классами на диаграмме классов могут представлять отношения, такие как ассоциация, наследование и реализацию. Ассоциация показывает отношения между классами, которые могут быть однонаправленными или двунаправленными. Наследование показывает, как класс наследует свойства другого класса, который является его родительским классом. Реализация показывает, как класс реализует интерфейс или абстрактный класс.
UML Diagrams Full Course (Unified Modeling Language)
Использование диаграммы классов помогает лучше понимать структуру системы и ее компоненты.
Основные принципы
Диаграмма классов соответствует принципам объектно-ориентированного программирования (ООП) и является одним из базовых инструментов проектирования ООП-систем.
Диаграмма классов соответствует принципу инкапсуляции. Он заключается в том, что каждый класс должен скрывать свою реализацию от других классов и предоставлять интерфейс для взаимодействия с ним. Это достигается через использование публичных и приватных методов и атрибутов класса, которые определены на диаграмме.
Диаграмма классов также соответствует принципу наследования, который позволяет создавать новые классы на основе уже существующих. Наследование позволяет упростить процесс проектирования системы, так как можно использовать уже реализованные классы и добавлять к ним новые функциональности.
Другим важным принципом, которому соответствует диаграмма классов, является полиморфизм. Он позволяет одному методу работать с различными объектами, реализующими один и тот же интерфейс. Диаграмма классов позволяет определить интерфейсы и абстрактные классы, которые могут быть реализованы различными классами.
Классы
Класс — это основной элемент моделирования, который представляет собой абстракцию реального объекта или сущности в системе. Он определяет свойства (атрибуты) и поведение (методы) объектов, которые являются экземплярами данного класса. На диаграмме классов обычно представляется в виде прямоугольника, разделенного на три части:
UML Class Diagram Tutorial
- Название класса располагается в верхней части прямоугольника.
- Атрибуты класса указываются в средней части прямоугольника.
- Методы класса располагаются в нижней части прямоугольника.
Атрибуты класса — это характеристики объекта, например, имя, возраст, адрес и т.д. Каждый атрибут имеет имя и тип данных. Тип данных может быть примитивным (например, целочисленным, строковым) или ссылочным, то есть типом другого класса.
Методы класса — это действия, которые может выполнять объект, например, получение или изменение значения атрибутов, выполнение какой-либо операции или обработка событий. Каждый метод имеет имя, тип возвращаемого значения (если есть) и список параметров.
Классы могут быть связаны друг с другом на диаграмме классов различными типами отношений, такими как наследование, ассоциация, композиция и агрегация. Такие отношения позволяют определить связи и взаимодействия между классами в системе.
Виды классов
В диаграмме классов UML можно выделить следующие виды классов:
Обычный класс — это класс, который представляет собой абстракцию реального объекта или сущности в системе. Он имеет свои атрибуты и методы, которые описывают характеристики и поведение объектов данного класса.
Абстрактный класс — это класс, который содержит хотя бы один абстрактный метод. Абстрактный метод не имеет реализации в самом классе, а определяется только его сигнатура (имя, параметры, тип возвращаемого значения). Абстрактные классы могут использоваться для определения общих характеристик для нескольких классов, от которых наследуются другие классы.
Интерфейс — это специальный вид класса, который определяет набор методов без их реализации. Интерфейсы используются для определения общих методов, которые должны быть реализованы в классах, которые их имплементируют. Один класс может имплементировать несколько интерфейсов.
Класс перечисления — это класс, который содержит константы, описывающие возможные значения для определенного атрибута. Классы перечисления используются, когда требуется ограничить множество допустимых значений атрибутов.
Класс шаблона — это класс, который представляет общий шаблон для создания конкретных классов, которые определяются позже. Классы шаблоны используются для обобщения классов и уменьшения повторяемости кода.
Каждый класс в диаграмме классов может иметь свою специфическую роль в системе и использоваться для различных целей. Однако, независимо от типа класса, его свойства и методы определяются с целью описания реальных объектов и сущностей в системе.
Видимость
Видимость (visibility) в языке моделирования UML определяет уровень доступности элементов модели. Она определяет, какие части программы могут обращаться к конкретному элементу модели.
В языке UML используется четыре уровня видимости:
- Public (публичный) — элементы с такой видимостью доступны из любой точки модели и внешних модулей. Они могут быть использованы как внутри класса, так и снаружи.
- Protected (защищенный) — элементы с такой видимостью не могут быть использованы вне класса, кроме классов-наследников.
- Private (приватный) — элементы с такой видимостью доступны только внутри класса, в котором они объявлены. Они не доступны из других классов и объектов.
- Package (пакетный) — элементы с такой видимостью доступны всем классам находящимся внутри одного пакета.
Указание видимости осуществляется при объявлении элемента модели с помощью знаков +, #, — и ~, соответственно, для публичного, защищенного, приватного и пакетного типа. Например, при объявлении атрибута с публичной видимостью, он будет помечен знаком «+».
Отношения (Взаимосвязи)
Классы могут быть связаны друг с другом на диаграмме классов различными типами отношений, такими как наследование, ассоциация, композиция и агрегация. Такие отношения позволяют определить связи и взаимодействия между классами в системе.
Зависимость (Dependency)
Зависимость — это отношение между двумя классами, где изменения в одном классе могут повлиять на другой класс. Она обозначается стрелкой, которая указывает на зависимый класс. Например, если класс A зависит от класса B, то на диаграмме классов стрелка будет указывать от класса A к классу B.
Примером зависимости может быть использование объекта одного класса в методе другого класса. Например, если класс Order содержит метод calcTotal(), который использует объект класса Product для расчета общей стоимости заказа, то можно нарисовать зависимость между классами Order и Product.
Зависимость также может возникать в результате передачи объектов как параметров методов других классов или при использовании переменных других классов внутри методов. Она является наименее сильным типом отношений между классами и обычно не включается в диаграммы классов в большом количестве.
Ассоциация (Association)
Ассоциация — это отношение между объектами двух классов, которое описывает, что объекты одного класса могут использоваться в объектах другого класса. Она представляется на диаграмме классов в виде линии, соединяющей два класса, с указанием на концах ассоциации их ролей.
Роль — это название, которое описывает, как именно объекты класса связаны между собой в рамках ассоциации. Роль может быть определена для каждого конца ассоциации и описывать, как объекты каждого класса используются в контексте связи между этими классами.
Множественность — это характеристика ассоциации, которая определяет количество объектов каждого класса, которые могут быть связаны между собой через эту ассоциацию. Множественность отношений может быть выражена числом или диапазоном чисел, которые указывают на допустимое количество связанных объектов. Некоторые распространенные обозначения множественности отношений включают:
| Название | Обозначение | Описание |
| Точное число | 1 | Только один объект связан с другим объектом. |
| Диапазон значений | 1..9 | От одного до девяти объектов класса могут быть связаны с другим классом. |
| Множество | 0..* или * | Ноль или более объектов могут быть связаны с другим объектом |
Множественность указывается на диаграмме классов с использованием чисел или символов, разделенных двоеточием, и располагается рядом с концами связи между классами.
Например, рассмотрим два класса: «Студент» и «Курс». Между ними существует ассоциация, которая показывает, что студент может записаться на несколько курсов или не записаться ни на какой, а курс может как иметь несколько студентов, которые на него записались, так и не иметь записанных на него студентов. На диаграмме классов это отображается в виде линии, соединяющей классы «Студент» и «Курс», с указанием на концах ассоциации их ролей (например, «записывается на» и «имеет студентов»), а также множественности (например, «многие-ко-многим»).
Агрегация (Aggregation)
Агрегация — это отношение между объектами классов, когда один объект является частью другого объекта. В этом случае, объект, содержащий другой объект, называется контейнером, а содержащийся объект — содержимым. Контейнер может содержать несколько объектов-содержимых, а объект-содержимое может быть частью нескольких контейнеров.
В диаграмме классов агрегация обозначается отношением «больше-чем» с пустым ромбом на стороне контейнера. Например, если у нас есть класс «Компания» и класс «Сотрудник», то мы можем использовать агрегацию, чтобы показать, что каждая компания содержит несколько сотрудников. В этом случае, класс «Компания» будет контейнером, а класс «Сотрудник» — содержимым.
В этом примере мы показываем, что каждая компания может содержать несколько сотрудников, используя отношение агрегации «contains». Обратите внимание на пустой ромб на стороне компании, он обозначает что данный класс является контейнером.
Композиция (Composition)
Композиция — это более строгий вариант агрегации, когда объект класса-контейнера создает объект класса-части и полностью управляет его жизненным циклом. Объекты класса-части могут принадлежать только одному объекту класса-контейнера. При удалении объекта класса-контейнера все объекты класса-части также удаляются.
Композиция обозначается на диаграмме классов uml с помощью пустого ромба на стороне класса-контейнера, соединенной линией с классом-частью. Также можно указать имя роли, которую выполняет класс-часть в отношении с классом-контейнером.
В данном примере класс Order содержит список экземпляров класса OrderItem , при этом экземпляры класса OrderItem принадлежат только одному экземпляру класса Order . Обозначение отношения композиции между классами Order и OrderItem указано с помощью пустого ромба со стороны класса Order и надписи composition .
Обобщение (Generalization)
Обобщение — это отношение на диаграмме классов UML, которое представляет собой связь между двумя классами, где один класс является более общим (родительским), а другой класс является более конкретным (дочерним). Описывает иерархию классов и позволяет наследовать атрибуты и методы от родительского класса к дочерним классам. Обобщение также называют наследованием.
На диаграмме классов обобщение отображается в виде стрелки, которая указывает от дочернего класса к родительскому. В конце стрелки иногда указывают слово «extends» или «inherits» (в зависимости от используемого синтаксиса). Родительский класс обычно находится вверху диаграммы, а дочерние классы располагаются под ним.
Примером обобщения может быть класс «Фигура», который является родительским классом для классов «Круг», «Прямоугольник», «Треугольник». У класса «Фигура» могут быть общие атрибуты и методы, которые будут наследоваться всеми дочерними классами.
Реализация (implementation)
Реализация показывает, что класс реализует интерфейс или абстрактный класс. Класс, который реализует интерфейс, обязан предоставить реализацию всех методов, объявленных в этом интерфейсе. Класс, который наследует абстрактный класс, также должен реализовать все его абстрактные методы.
На диаграмме классов связь реализации обозначается пунктирной линией с треугольной стрелкой, которая указывает на интерфейс или абстрактный класс.
В этом примере классы Circle и Square реализуют интерфейс IShape и должны предоставить реализацию метода draw() . Связь реализации обозначена линиями с треугольными стрелками, которые указывают на интерфейс IShape .
Построение диаграммы классов
Построение диаграммы классов включает несколько шагов. Ниже приведены основные этапы процесса и пример на выбранной предметной области (Университет).
Шаг 1. Идентификация классов
Определите основные классы, которые будут присутствовать в вашей системе или программе. В нашем примере на предметную область «Университет» могут входить классы «Студент», «Преподаватель», «Курс» и «Группа».
Шаг 2. Определение атрибутов классов
Для каждого класса определите его атрибуты, то есть переменные, которые описывают его состояние. Например, класс «Студент» может иметь атрибуты «имя», «возраст» и «номер студенческого билета». Запишите атрибуты рядом с соответствующими классами на диаграмме.
Шаг 3. Определение методов классов
Для каждого класса определите его методы, то есть функции или операции, которые класс может выполнять. Например, класс «Студент» может иметь методы «записаться на курс», «получить средний балл» и «изменить информацию о себе». Запишите методы под соответствующими классами на диаграмме.
Шаг 4. Определение отношений между классами
Установите связи между классами, чтобы показать их отношения. Например, класс «Студент» может иметь ассоциацию с классом «Курс», чтобы показать, что студенты записываются на курсы. Используйте стрелки и мощность отношений для указания типа и количество связей между классами.
Источник: itonboard.ru
Как описать программную систему в UML-диаграммах: от Use Case до состояний + краткий ликбез по ООП
Недавно мы разбирали, как построить UML-диаграмму последовательности на примере проведения платежей в интернет-магазине с помощью защищенного банковского шлюза. В продолжение этого кейса, сегодня построим UML-диаграммы вариантов использования, классов и состояний для системы оплаты курса с применением промокода на скидку.
Границы системы, акторы и варианты использования: что такое диаграмма Use Case
Проектируя программную систему, аналитик прежде всего отвечает на вопрос, что она должна делать, т.е. какие возможности представлять для разных пользователей. Для описания таких вариантов использования в UML есть одноименная диаграмма – Use Case. Она позволяет наглядно показать границы системы и ее функции, сгруппированные по контексту – прецеденты. При том, что каждый прецедент фактически отражает одно или сразу несколько функциональных требований, UML-диаграмма Use Case и одноименная форма представления требований – это разные вещи, хоть и связанные между собой. Подробнее об этом мы рассказывали в отдельной статье.
В качестве иллюстративного примера рассмотрим систему онлайн-оплаты учебного курса. Пользователем этой системы является клиент. В терминологии UML он будет называться актор – сущность за пределами системы, которая взаимодействует с ней. На UML-диаграмме Use Case он изображается в виде человечка.
Актору «Клиент» доступен основной вариант использования – «Оплатить договор» (на проведение обучающего курса по бизнес-анализу). Расширением этого варианта использования является «Оплатить со скидкой по промокоду», который уменьшает сумму платежа. Этот вариант использования является опциональным и расширяет основной, поэтому он будет связан с основным через связь extend, которая выглядит как пунктирная стрелочка с соответствующей надписью.
Далее следует детализировать, как именно выполняется процесс оплаты, раскрыв прецедент со схемы Use Case на UML-диаграмме последовательности. Однако, чтобы сделать это с привязкой к внутренним сущностям нашей программной системы, классам, следует сперва описать их на UML-диаграмме классов. Как это сделать, мы рассмотрим далее.
Ликбез по ООП или как построить UML-диаграмму классов
UML соответствует объектно-ориентированной парадигме программирования (ООП), ключевым понятием которой является класс. Класс – это абстракция сущностей с одинаковыми свойствами (атрибутами, полями) и поведением (методами, функциями). Классы могут быть связаны друг с другом через наследование и ассоциации.
При наследовании класс-потомки имеют (наследуют) атрибуты и методы класса-родителя, а также свои собственные. А конкретные значения этих атрибутов задаются в реализации классов в виде их отдельных экземпляров, называемых объектами. Например, ООО «Рога и Копыта» и Иванов Иван Иваныч – это конкретные реализации классов «Юрлицо» и «Физлицо» соответственно. В частности, у объекта класса Физлицо есть поля с паспортными данными (ФИО и № паспорта), а у юрлица обязательно должны быть название и ИНН. При этом оба этих класса наследуют от родителя (Класс «Клиент») общие для них атрибуты (тип, номер телефона, email и адрес).
Ассоциация означает логическую связь между объектами разных классов. Например, договор на обучение связан с курсом. Поскольку в договоре нужно обязательно указать курс, эти классы будут связаны не простой ассоциацией, а ее более сложным вариантом – агрегацией. В этом случае у класса, который является целым, появится значок в виде незакрашенного ромбика.
Если связь между объектами разных классов настолько сильная, что при уничтожении целого, уничтожаются и его части, ромбик будет закрашенным. Такая связь называется композицией и является самым сильным вариантом ассоциации. Можно также указать кратность связи, к примеру, в 1-м договоре на обучение могут быть указаны сразу несколько курсов. При этом над концами связи отобразятся мультипликаторы, обозначающие ее кратность.
Источник: babok-school.ru
UML: от теории к практике
Я думаю, каждый слышал в детстве такую поговорку как «Семь раз отмерь, один раз отрежь». В программировании так же. Лучше всегда обдумать реализацию до того, как вы потратите время на её исполнение. Часто приходится при реализации создавать классы, придумывать их взаимодействие. И часто визуальное представление этого может помочь решить задачу наиболее правильным образом.
В этом нам и помогает UML.
Что такое UML?
Если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики. Что важно, что UML переводится как Unified Modeling Language. Важно тут слово Unified. То есть наши картинки поймём не только мы, но и остальные, кто знает UML. Получается это такой международный язык рисования схем.
Как гласит Википедия
UML — это язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
Самое интересное, о чём не все задумываются или догадываются, UML имеет спецификации. Причём даже есть спецификация UML2. Подробнее со спецификацией можно ознакомиться на сайте Object Management Group. Собственно, эта группа и занимается разработкой спецификаций UML. Интересно и то, что UML не ограничивается описанием структуры классов.
Существует множество типов UML диаграмм. Краткое описание типов UML диаграмм можно увидеть в той же Википедии: UML — диаграммы или в видео Тимура Батыршинова Обзор UML диаграмм. UML так же широко применяется при описании различных процессов, например здесь: Единый вход с использованием JWT.
Возвращаясь к использованию UML диаграмм классов, стоит отметить книгу Head First : Паттерны проектирования, в которой паттерны иллюстрируются теми самыми UML диаграммами. Выходит, что UML действительно используется. И выходит, что знание и понимание его применения довольно полезный навык.
Применение
Разберём, как с этим самым UML можно работать из IDE. В качестве IDE возьмём IntelliJ Idea. Если использовать IntelliJ Idea Ultimate, то у нас «из коробки» будет установлен плагин «UML Support». Он позволяет автоматически генерировать красивые диаграммы классов. Например, через Ctrl+N или пункт меню «Navigate» -> «Class» перейдём в класс ArrayList.
Теперь, через контекстное меню по имени класса выберем «Diagram» -> «Show diagram popup». В результате мы получим красивую диаграмму:
Но что, если хочется самому нарисовать, да ещё и нет Ultimate версии Idea? Если мы используем IntelliJ Idea Community Edition, то у нас нет другого выбора. Для этого нужно понять, как такая UML схема устроена. Для начала нам понадобится установить Graphviz. Это набор утилит для визуализации графов.
Его использует плагин, который мы будем применять. После установки необходимо добавить каталог bin из каталога установленного Graphviz в переменную среды окружения PATH. После этого в IntelliJ Idea в меню выбрать File -> Settings. В окне «Settings» выбрать категорию «Plugins», нажать кнопку «Browse repositories» и установить плагин PlantUML integration. Чем так хорош этот PlantUML?
Он использует для описания UML язык описания графов под названием «dot» и это позволяет ему быть более универсальным, т.к. данный язык используется не только PlantUML. Более того, всё что мы ниже сделаем мы можем выполнить не только в IDE, но и в онлайн сервисе planttext.com. После установки плагина PlantUML у нас появится возможность через «File» -> «New» создавать UML диаграммы.
Давайте выполним создание диаграммы типа «UML class». В ходе этого автоматически генерируется шаблон с примером. Удалим его содержимое и создадим своё, вооружившись статьёй с Хабра: Отношения классов — от UML к коду. А чтобы понять, как это изобразить в тексте, возьмём мануал по PlantUML: plantuml class-diagram. В нём в самом начале представлена табличка с тем, как нужно описывать связи:
Про сами же связи можем ещё подсматривать сюда: «Отношения между классами в UML. Примеры». На основе этих материалов приступим к созданию нашей UML диаграммы. Добавим следующее содержимое, описывающее два класса:
Чтобы увидеть результат в Idea, выберем «View» -> «Tool Windows» -> «PlantUML». Мы получим просто два квадрата, обозначающие классы. Как мы знаем, оба эти класса реализуют интерфейс List. Данное отношение классов так и называют — реализация (realization). Для изображения такой связи используют стрелку с пунктирной линией. Изобразим её:
interface List List <|.. ArrayList List <|.. LinkedList
List — один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization).
Выглядит как стрелка с обычной непрерывной линией. Изобразим её:
interface Collection Collection <|— List
Для следующего типа связи добавим в описание класса ArrayList запись о package private массиве элементов:
~Object[] elementData
Теперь мы хотим показать, что ArrayList содержит какие-то объекты. В данном случае будет тип связи — агрегация (aggregation). Агрегатом в данном случае является ArrayList , т.к. он содержит другие объекты. Агрегацию мы выбираем потому, что объекты в списке могут жить и без списка: они не являются его неотъемлемыми частями.
Их время жизни не привязано к времени жизни списка. Агрегат с латинского переводится как «собранный», то есть что-то, составленное из чего-то. Например, в жизни, есть насосный агрегат, который состоит из насоса и двигателя. Сам агрегат можно разобрать, оставив что-то из его составных частей. Например, чтоб продать или поставить в другой агрегат. Так и в списке.
И выражается это в виде пустого ромбика у агрегата и непрерывной линии. Изобразим это следующим образом:
class Object < >ArrayList o- Object
Теперь мы хотим показать, что в отличие от ArrayList , класс LinkedList содержит в себе Node — контейнеры, ссылающиеся на хранимые данные. В данном случае Node являются частью самого LinkedList и не могут жить отдельно. Node не является непосредственнохранимым содержимым, а только содержит ссылку на него.
Например, когда мы добавляем в LinkedList какую-нибудь строку, мы добавляем новый Node , который содержит ссылку на эту строку, а также ссылку на предыдущий и следующий Node . Такой тип связи называется композицией (Composition). Для отображения у композита (того, кто состоит из частей) рисуется закрашенный робмик, к нему ведёт непрерывная линия. Запишем теперь это в виде текстового отображения связи:
class Node < >LinkedList *— Node
И теперь необходимо научиться отображать ещё один важный тип связи — зависимость (dependency relationship). Он используется тогда, когда один класс использует другой, при этом класс не содержит в себе используемый класс и не является его наследником. Например, LinkedList и ArrayList умеют создавать ListIterator . Отобразим это в виде стрелок с пунктирной линией:
class ListIterator ListIterator
Выглядеть после всего это будет следующим образом:
Детализировать можно настолько, насколько это необходимо. Все обозначения указаны тут: «PlantUML — Диаграмма классов». Кроме того, в рисовании такой схемы нет ничего сверхъестественного, и при работе над своими задачами её можно быстро рисовать от руки. Это позволит развить навыки продумывания архитектуры приложения и поможет выявить недостатки структуры классов на раннем этапе, а не когда вы уже потратите день на реализацию неправильной модели. Мне кажется, это неплохая причина для того, чтобы попробовать? )
Автоматизация
Есть различные способы автоматической генерации PlantUML диаграмм. Например, в Idea есть плагин SketchIT, но рисует он их не совсем правильно. Скажем, неправильно рисуется имплементация интерфейсов (отображается как наследование). Также в интернете есть примеры того, как это встроить в жизненный цикл сборки вашего проекта. Допустим, для Maven есть пример использования uml-java-docklet.
Для того, чтобы показать как это, воспользуемся Maven Archetype для быстрого создания Maven проекта. Выполним команду: mvn archetype:generate На вопросе выбора фильтра (Choose a number or apply filter) оставляем default, просто нажав Enter. Это всегда будет «maven-archetype-quickstart». Выбираем самую последнюю версию. Далее отвечаем на вопросы и завершаем создание проекта:
Так как Maven не является целью данной статьи, ответы на свои вопросы по Maven можно найти в Maven Users Centre. В сгенерированном проекте откроем на редактирование файл описания проекта, pom.xml. В него скопируем содержимое из описания uml-java-docklet installing. Используемый в описании артефакт не удалось найти в репозитории Maven Central.
Но у меня заработало с этим: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. То есть надо в том описании просто заменить groupId с «info.leadinglight» на «com.chfourie» и поставить версию «1.0.0». После этого можем выполнить в каталоге, где находится файл pom.xml эти комманды: mvn clean install и mvn javadoc:javadoc . Теперь, если открыть сгенерированную документацию (explorer targetsiteapidocsindex.html), мы увидим UML схемы. Кстати, имплементация тут уже отображается верно )
Заключение
Как видно, UML позволяет визуализировать структуру вашего приложения. Кроме того, UML не ограничивается только этим. При помощи UML можно описывать различные процессы внутри вашей компании или описывать бизнес-процесс, в рамках которого работает функция, которую вы пишите. На сколько UML полезен лично для вас — решать вам, но найти время и ознакомиться более подробным будет в любом случае полезно. #Viacheslav
Источник: javarush.com