UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
UML обеспечивает три представления модели системы:
- Представление функциональных требований (функциональные требования системы с точки зрения пользователя, включая варианты использования);
- Статическое структурное представление (объекты, атрибуты, отношения и операции, включая диаграммы классов)
- Представление динамического поведения (взаимодействие объектов и изменения внутреннего состояния объектов, включая диаграммы последовательностей, деятельностей и состояний)
Назначение
UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
Что такое UML за 7 минут: Диаграмма классов, последовательностей, состояний и деятельности
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.
Диаграммы
Структуру диаграмм UML 2.3 можно представить на диаграмме классов UML:
Структурные диаграммы
- Диаграмма классов
- Диаграмма компонентов
- Диаграмма композитной/составной структуры
- Диаграмма кооперации (UML2.0)
- Диаграмма развёртывания
- Диаграмма объектов
- Диаграмма пакетов
- Диаграмма профилей (UML2.2)
Диаграммы поведения
- Диаграмма деятельности
- Диаграмма состояний
- Диаграмма вариантов использования
- Диаграммы взаимодействия:
- Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
- Диаграмма обзора взаимодействия (UML2.0)
- Диаграмма последовательности
- Диаграмма синхронизации (UML2.0)
Преимущества
- UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
- UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
- Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
- UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
- UML получил широкое распространение и динамично развивается.
Недостатки
- Избыточность языка. UML часто критикуется как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных комитетом» компромиссов.
- Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
- Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
- Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
- Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа одной системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
- Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.
Инструменты
- Sparx Enterprise Architect
- IBM Rational Rose
- ArgoUML
- BOUML
- Dia
- Enterprise Architect
- MagicDraw UML
- Modelio
- PowerDesigner
- Rational Rhapsody
- Rational Software Architect
- StarUML
- Umbrello
- Eclipse
- NetBeans
См. также
Литература
- Мартин Фаулер «UML, основы: краткое руководство по стандартному языку объектного моделирования» (Addison-Wesley Professional, ISBN-10: 0321193687, ISBN-13: 978-0321193681; Символ-Плюс, ISBN 5-93286-060-X)
Ссылки
Источник: sewiki.ru
Использование нотации UML для описания бизнес-процессов
UML как средство описания бизнес-процессов
Начнем рассмотрение с концепции IDEF как более простой и доступной в виде большого числа программных продуктов, поддерживающих эту концепцию (BPWIN, БИГ-Мастер, MS Visio и др.).
IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны США) является основным пользователем данной технологии. Ею пользуются также некоторые крупные корпорации в США.
Графически формат IDEF0 представляет собой следующую структуру (см. Рис. 10). Функции (работы, операции) изображаются прямоугольниками. Названия функций по стандарту формируются в глагольном наклонении: оформить заказ, обработать заготовку.
Каждая из сторон прямоугольника имеет свое назначение:
59. Верхняя сторона — управление;
60. Нижняя сторона-механизмы (ресурсы);
61. Левая сторона — входы;
62. Правая сторона — выходы.
Все ресурсы, участвующие в процессе, изображаются стрелками (потоками). Значение стрелок различно в зависимости от того, с какой стороны процесса они расположены. Названия стрелок уникальны и формируются по правилам стандарта IDEF как обороты существительного.
Рис. 10. Графическое представление процесса в IDEF0 (сделано в MS Visio XP)
Стрелками управления могут быть документы, регламентирующие деятельность (стандарты, технические условия и т.п.) Входами, выходами и механизмами могут быть различные ресурсы: люди, станки, материалы, сырье, документы, базы данных и т. п. (см. Рис. 11).
Рис. 11. Пример блока IDEF диаграммы
Функции 1DEF могут детализироваться в отдельных схемах, это называется декомпозиция. На самом верхнем уровне это может быть все предприятие, отраженное как один блок, а далее — в отдельной схеме — будут раскрыты различные процессы. Декомпозиция обозначается под блоком процесса с правой стороны в виде номера схемы детализации.
В отличие от номера блока, расположенного внутри прямоугольного блока функции, номер схемы детализации находится снаружи прямоугольника (см. Рис. 12). На рисунке номер схемы декомпозиции «АО». Уровень вложенности процессов не ограничивается.
Рис. 12 Декомпозиция процесса в IDEF
Пример процесса в формате IDEF (см. Рис. 13). Надписи на стрелках сделаны выносками в форме молний.
Рис. 13 Пример процесса в формате IDEF
UML — объектно-ориентированный язык моделирования для описания сложных систем. Также весьма распространен, существуют многочисленные инструменты для проектирования систем на данном языке, например: Rational Rose, Paradigm Plus, 4Keeps, MS Visio 2002 XP и др.
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