Язык графического описания для объектного моделирования в области разработки по моделирования бизнес

Время на прочтение
5 мин

Количество просмотров 235K

Многие программисты, столкнувшись со сложной задачей, пренебрегают этапом проектирования, ссылаясь на то, что проектирование — это потеря времени, и в данном случае оно будет мне только мешать.

Зачастую это утверждение оказывается верным, если задача и правда небольшая и квалификации программиста достаточно для определения наиболее оптимального решения.

Программисты, не использующие UML, делятся на несколько групп:

• начну писать код, а в процессе пойму, что да как;
• почитаю форумы, хабр, medium, stack overflow, книгу, записи на стенах, знаки свыше…;
• поспрашиваю у коллег, может, кто-то знает, как решить подобную задачу;
• начну рисовать квадратики и схематично покажу, какое видение задачи сформировалось у меня в сознании.

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

Можно провести аналогию с постройкой дома. Когда кто-то хочет построить дом, он не просто бьет молотком и приступает к работе. Ему нужно иметь план — план проектирования, чтобы он мог анализировать и модифицировать свою систему.

Если вы уже начали описывать на бумаге вашу задачу, это уже огромный плюс.

Что такое UML

Официальное определение из википедии.

UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.

Проще говоря, если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики.

Важно, что UML переводится как Unified Modeling Language. Главное здесь слово Unified. То есть наши картинки поймём не только мы, но и остальные, знающие UML. Получается, это такой международный язык рисования схем.

Плюсы и минусы UML проектирования

Минусы:

• трата времени;
• необходимость знания различных диаграмм и их нотаций.

Плюсы:

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

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

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

Предлагаю познакомиться с одними из самых полезных и часто используемых диаграмм.
Речь пойдет о диаграммах последовательности, состояний, деятельности и самой сложной из них — диаграмме классов.

Сначала я <…>, а потом <…>, а потом… Диаграмма последовательностей

Представьте, что вам нужно описать последовательность действий для заказа товара в интернет-магазине. Кто должен участвовать в процессе? Какие фазы проходит заказ прежде, чем он будет оформлен?

Обычно, мы пишем длинный список этапов, которые должна пройти заявка, чтобы получить гордый статус «Оформлена». Затем описываем, кто именно будет выполнять конкретное действие. И только после этого начинаем программировать.

В чем недостаток данного подхода? Он не нагляден.

Представьте, перед вами лежит длинный список описанных ранее этапов и комментариев к ним. Насколько просто вам будет разобраться в нем? Сколько времени может на это потребоваться? Предполагаю, что достаточно.

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

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

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

Диаграмма состояний. Настраиваем старые электронные часы

Диаграмма состояний позволяет описать поведение отдельно взятого объекта при определенных условиях. Также она покажет нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния.

Предположим, мы программируем советские электронные часы.

Для настройки нам дано всего несколько кнопок. Довольно негусто. При этом мы знаем, что одна из кнопок переключает режим настройки часов. Другая кнопка в первом режиме меняет минуты, а во втором часы.



Инструкция по настройке и так достаточно небольшая, но благодаря диаграмме состояний она визуально воспринимается гораздо проще.

Диаграмма состояний

Подробнее о диаграмме состояний можно прочитать здесь.

Диаграмма классов, или как рассказать о своем коде без кода

Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.

В различных документациях, описании паттернов проектирования, а также, читая хабр, все мы часто встречаем диаграмму классов. Почему же ее так часто используют?

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

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

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

Рассмотрим, как с помощью диаграммы классов описать известный паттерн проектирования «Посетитель».

«Посетитель» — это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться.

Диаграмма классов

Самыми значимыми достоинствами этой диаграммы являются:

• экономия времени при объяснении задачи другим программистам;
• более точное и наглядное представление структуры основных элементов системы.

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

Подробнее о диаграмме классов можно прочитать здесь, а о паттерне «Посетитель» здесь.

Диаграмма деятельности

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

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

Именно на диаграмме деятельности представлены переходы от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми активностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей.


Диаграмма деятельности

Смысл диаграммы вполне понятен. На ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Обратите внимание на расположение активностей на этой диаграмме: они как бы разбросаны по трем колонкам, каждая из которых соответствует поведению одного из трех объектов — клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из деятельностей.

Подробнее о диаграмме деятельности можно прочитать здесь.

Заключение

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

Оставьте комментарий, если вы думаете (или знаете), что что-то не так или могло быть описано лучше.

UML, или Unified Modeling Language, — унифицированный язык моделирования. Это графический язык, который с помощью диаграмм и схем описывает разнообразные процессы и структуры. Это не язык программирования, но чаще всего UML применяют именно в IT — с его помощью можно автоматически генерировать код.

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

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

• Разработчики, которым важно продемонстрировать, как будет устроена программа или те или иные ее компоненты, и визуализировать это.
• Системные аналитики и архитекторы, которым такой способ представления может помочь в создании логичной и грамотной структуры ПО или отдельных его частей.
• Технические писатели, так как UML, помимо всего прочего, используется для составления документации и автоматической генерации технических описаний.
• Дизайнеры, которые занимаются созданием интерфейсов или визуализацией чего-то сложного. Они могут пользоваться и другими инструментами, но знать UML им стоит.
• Бизнес-аналитики и менеджеры по развитию, которым диаграммы нужны для визуализации бизнес-процессов и структур.

• Для создания «чертежей» программы, схем, которые показывают, как будет устроено программное обеспечение изнутри, — то есть для проектирования. Это может быть описание связей между компонентами, модулей или сервисов, программных процессов и многого другого. В качестве инструмента проектирования UML может использоваться и вне IT.
• Для визуализации уже имеющейся программной структуры. Ряд инструментов позволяет создать UML на основе существующего кода, в таком случае диаграмма сгенерируется автоматически. Это называется реверс-инжинирингом.
• Для автоматической генерации кода или технической документации по нему, так как UML поддерживает возможность создания продукта на основе диаграмм. Но с этой функцией нужно быть крайне аккуратным: автоматически сгенерированный код позже нуждается в доработке. А вот созданная таким образом документация обычно наглядная и понятная.
• Для внутренней и внешней коммуникации между сотрудниками, заказчиками и другими: картинки и диаграммы UML понятнее людям, чем текстовые описания.
  

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

Схема UML — концептуальная: это значит, что она оперирует концепциями и связями между ними. Сама диаграмма состоит из фигур, значков, надписей, линий и контуров.

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

Существует множество типов UML-диаграмм, и мы не будем описывать их все. Просто скажем, что условно они разделяются на три категории.

Объектные, или структурные — диаграммы, которые описывают статическую структуру системы. Это, например, диаграммы классов в программе. В них показываются сами объекты и классы, связи между ними, зависимости и атрибуты.

Поведенческие — схемы для описания поведения в динамике. Их еще называют динамическими. Это, например, диаграммы, которые описывают процессы.

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

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

Наглядность. Изображение понятнее и нагляднее, чем текст. Сложную структуру проще описать в виде схемы, чем как-либо еще. UML-диаграммы хорошо показывают, как устроена та или иная структура, и помогают ничего не пропустить.

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

Широкое применение. UML активно используется во множестве отраслей, не только в IT. Благодаря широкому применению по модели много материалов, и высок шанс, что описанные с ее помощью диаграммы поймут специалисты из другой сферы. К тому же потенциальная широта применения дает возможность удобно описать большинство моделей, где бы вы ни работали.

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

Удобная генерация. Речь идет и о генерации кода из UML, и о создании документации на основе диаграмм, и о реверс-инжиниринге. Все эти действия довольно простые, их не так сложно освоить.

Снижение риска ошибки. Человеческий фактор — проблема, которая может привести к ошибкам в описаниях, схемах или непосредственно в программных реализациях. Благодаря наглядности и высокому уровню автоматизации UML снижает риск возникновения таких ошибок.

Избыточность. Ранние версии UML критиковали из-за того, что некоторые обозначения и сущности избыточны и практически не используются в реальных проектах — в них просто нет необходимости, а язык они делают более громоздким. Со временем проблема стала менее заметной, но при начале работы с UML все равно стоит быть готовым к тому, что многие сущности понадобятся вам далеко не сразу — или не понадобятся вовсе.

Большое количество обозначений. Чтобы работать с UML правильно и корректно использовать составляющие диаграммы, понадобится выучить как минимум около ста обозначений. Но это важно, только если вы составляете UML-диаграмму вручную. При автоматической генерации нужные обозначения подставляются сами собой.

Существует два варианта: с помощью любого сервиса для построения диаграмм или благодаря программным модулям.

Сервисы и редакторы. Сервисы дают возможность рисовать диаграммы вручную. Они похожи на графические редакторы, только вместо кистей и ручек в них есть уже готовые компоненты, из которых «собирается» схема. Человек проектирует диаграмму, подписывает элементы, оставляет заметки — такие редакторы предоставляют все необходимое. Некоторые из них могут связываться с сервисами для редактирования документов, хранения данных и других действий. Например, веб-приложение diagrams.net совместимо с облачными сервисами Google и с системами контроля версий Git. Подробнее о Git можно прочесть в нашей статье.

Модули и библиотеки. Модули для IDE и библиотеки для популярных языков программирования позволяют создавать UML с помощью программного кода. Тут тоже есть две версии использования: сгенерировать диаграмму на основе имеющегося кода проекта или запрограммировать ее вручную. Можно описывать на языке программирования элементы и связи между ними, а потом «рисовать» визуализацию с помощью других инструментов. Такие утилиты и библиотеки существуют, например, для Java, JavaScript, PHP и других распространенных языков.

UML (Unified Modeling Language — унифицированный язык моделирования) — это тип нотации, используемый для визуализации, определения, конструирования и документирования компонентов программных и непрограммных систем.

Краткая история

История создания языка программирования берет свое начало в 1967 году при появлении языка SimulaF67: он существенно отличается от современного, однако задает базовые идеи, которые существуют и сегодня. Официальное создание UML началось в 1994 году и первая версия 0.8 получила статус пробной.

В 1995 году концепция была расширена и дополнена языком OOSE. Таким образом повилась версия 0.9, с которой началось полноценное развитие UML, имеющего стратегическое значение для бизнеса.

Первая официальная всемирная версия UML появилась в январе 1997 года. Язык UML стал основой моделирования для различных классов систем и их программного обеспечения. Нотация начала применять объектно-ориентированные методы, обрела концептуальный, логический и физический уровни моделирования систем.

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

Плюсы и минусы методологии

Среди ключевых преимуществ модели выделим следующие характеристики:

1. UML — это объектно-ориентированный язык, поэтому методы, с помощью которых описываются результаты анализа и проектирования являются семантически идентичными к методам программирования на ключевых ОО-языках, используемых в современных технологиях.
2. С помощью UML можно описать ситуацию или ключевую задачу с различных точек зрения и аспектов поведения системы.
3. UML диаграммы простые в восприятии: прочитать схему и ознакомится с ее синтаксисом сможет даже работник, не имеющих специальных знаний в области программирования и постройки бизнес-моделей (речь идет о стандартных схемах с 20-40 условными обозначениями).
4. UML минимизирует процент возможных ошибок при создании бизнес-процесса. Например, она исключает несогласованность параметров дополнительных программ или изменение основных атрибутов.
5. Любой этап бизнес-процеса может быть использован повторно в уже существующем или новом проекте организации.
6. UML можно применять не только для решения вопросов программной инженерии, но и для введения собственных текстовых и графических стереотипов.
7. В отличие от аналогичных нотаций, UML стремительно развивается и получает широкое распространение в построении моделей различных сферах бизнеса.

Как и другие нотации, UML имеет недостатки:

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

Типы сущностей

Нотации UML — это ключевые элементы для моделирования и визуализации бизнес-процессов. Если цель изображена некорректно, выбраны неправильные и малоэффективные обозначения, то модель считается бесполезной и не содержательной.

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

Структурные

Структурные сущности — это имена существительные, представленные в статистической части модели: они соответствуют как концептуальным, так и физическим элементам системы. Среди основных структурных элементов выделают:

• Классы используются для представления объектов (требуют ответственных и имеют конкретные свойства). Диаграмма визуально разделена на четыре части: верхняя позиция (1) называет класс, вторая — отображает его атрибуты и основные инструменты, третья — детализирует операции и процессы, конечная — содержит дополнительную информацию и является необязательной.
• Объекты (экземпляр класса) — процессы, являющиеся фактической реализацией класса. Графически изображены как предшественники, единственное отличие в том, что название дополнительно подчеркивается.
• Интерфейсы используются для описания функционала по соответствующим требованиям. Интерфейс является своеобразным шаблоном, в котором расписаны этапы бизнес-процессов без их фактической реализации. На схеме отображается кружком с соответствующим названием, указанным под обозначением.
• Сотрудничество — это условное обозначение ответственности: отвечает за распределение задач в группе и назначении ответственных, чьи имена будут вписаны внутри круга с пунктирным контуром.
• Случаи использования подразумевают ситуации, для которых применимы функциональные возможности высокого уровня системы. Графически вариант использования прописывается под фигурой с обозначением сотрудничества.
• Актер — внутренняя или внешняя сущность, которая используется для описания внутренних или внешних задач бизнес-процесса. Актер взаимодействует с системой и может быть обозначен на любом этапе схемы.
• Нотация начального состояния — отображает начало бизнес-процесса; конечная государственная запись — конец процесса и соответственно результат.
• Компонент — представляет объект системы, для которого была создана диаграмма UML. Графически отображается в виде прямоугольника, в котором указан исполнитель и название задачи.
• Нотация активного класса — представляет параллельность задач в системе и изображается в формате квадрата, разделенного на три блока: 1 — название класса, 2 — параллельные требования системы, требующие описания, 3 — операции и процессы.
• Узел обозначает физический компонент системы (использование сети, серверов или оборудования). На схеме представлен в виде куба, в котором указано название узла и исполнитель.

Поведенческие

К данном классу относятся динамические и составляющее модели UML — глаголы, описывающие поведение модели во времени и пространстве. Рассмотрим основные поведенческие сущности:

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

Группирующие

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

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

Аннотационные

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

Рассмотрим основные типы аннотационных сущностей:

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

Виды диаграмм, используемых в Unified Modeling Language

В языке UML представлено 12 диаграмм, обуславливающих статистическую, поведенческую и физическую деятельность компонентов систем. Рассмотрим доступные и актуальные в современных бизнес-процессах диаграммы:

1. Диаграмма прецедентов (Use-case diagram). В основе — Actor (исполнитель), который устанавливает логические связи между ролями и прецедентами и Use case (сам прецедент), демонстрирующий какой именно процесс исполняется.
2. Диаграмма классов (Class diagram) представляет собой набор статических и декларативных элементов модели, имеющие общие атрибуты и операции. Диаграмма имеет наиболее полное и развернутое описание связей в программном коде, функциональности и информации об отдельных классах.
3. Диаграмма активностей (Activity diagram) отображает динамические аспекты поведения и общее представление о работе системы в формате блок-схемы. Диаграмма необходима для описания бизнес-процессов, взаимодействия нескольких систем, логики процедур и потоков работ, особенно при переходе от одной деятельности к другой.
4. Диаграмма последовательности (Sequence diagram) описывает поведенческие аспекты системы, вид сообщений и уточняет прецедентов. Необходима для отображения взаимодействия объектов в динамике и во времени, подразумевает обмен сообщениями в рамках конкретного сценария.
5. Диаграмма развёртывания (Deployment diagram) отображает графическое представление инфраструктуры, а именно распределение компонентов системы по узлам и маршруты их соединений. Диаграмма организовывает компоненты и решает второстепенные задачи, связанные с определенным аспектом бизнес-процесса.

Упрощение моделирования с помощью программного обеспечения

Для упрощения моделирования доступны разнообразные инструменты моделирования UML, а также разработанные ПО. Среди всех доступных возможностей, следует выделить IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner и Dia. Они обладают хорошим функционалом и широким спектром инструментов для построения диаграмм и рациональным распределением задач между исполнителями.

Вне зависимости от выбранного ПО, необходимо учитывать, что язык UML основывается на общих принципах моделирования, которыми не следует пренебрегать:

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

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

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

Использование

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

История

Предпосылки появления языка моделирования UML обозначились в связи с бурным развитием во второй половине XX века объектно-ориентированных языков программирования (Simula 67, Smalltalk, Objective C, C++ и др). Вследствие непрекращающегося усложнения создаваемых программных продуктов возникла нужда в учёте всё новых и новых возможностей языков и средств разработки при анализе, формулировании требований и в процессе проектирования программных приложений. Например, в короткий промежуток времени с 1989 года по 1994 год количество объектно-ориентированных инструментов выросло с десятка до более, чем полусотни. Однако, многие разработчики затруднялись подобрать язык моделирования, который бы полностью отвечал всем их потребностям. В результате выделилось новое поколение методов разработки, среди, которого особую популярность приобрели метод Буча, созданный Якобсоном ObjectFOriented Software Engineering (OOSE) и разработанный Рамбо (Object Modeling Technique (OMT). Помимо них существовали и другие завершённые технологии, например Fusion, Shlaer-Mellor и Coad-Yourdon, однако всем из них были присущи не только преимущества, но и существенные недостатки^[1].

До UML 1.x

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования Object-Modeling Technique и Booch. OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Ивар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.

На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон («три амиго»), выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.

UML 1.x

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно, в июне 1999, сентябре 2001 и марте 2003 года.

UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005^[12].

UML 2.x

Формальная спецификация версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.5 опубликована в июне 2015 года.

UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2^[12].

Диаграммы

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Структуру диаграмм UML 2.3 можно представить на диаграмме классов UML:

Диаграмма классов

Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

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

Диаграмма компонентов

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

Диаграмма композитной/составной структуры

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

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

Диаграмма развёртывания (Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Диаграмма объектов

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

Диаграмма пакетов

Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

Диаграмма деятельности

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

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

Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90 и дракон-схемы.

Диаграмма автомата

Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

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

Аналогом диаграмм автомата (диаграмм состояний) являются дракон-схемы.

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

Диаграмма вариантов использования (Use case diagram, диаграмма прецедентов) — диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.

Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

Диаграммы коммуникации и последовательности

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

Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

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

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграмма обзора взаимодействия

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

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации

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

Преимущества UML

• UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
• UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
• Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
• UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
• UML получил широкое распространение и динамично развивается.

Критика

Несмотря на то, что UML — достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

• Избыточность языка. UML часто критикуется как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных комитетом» компромиссов.
• Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
• Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков^[13].
• Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»)^[14][15]. В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
• Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа одной системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
• Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.

См. также

• SysML
• IDEF
• DFD
• ДРАКОН

Примечания

Литература

• Крэг Ларман. Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. — 3-е изд. — М.: Вильямс, 2006. — 736 с. — ISBN 0-13-148906-2.
• Джозеф Шмуллер. Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. — М.: Вильямс, 2005. — 416 с. — ISBN 0-672-32640-X.
• Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. Язык UML. Руководство пользователя = The Unified Modeling Language user guide. — 2-е изд. — М., СПб.: ДМК Пресс, Питер, 2004. — 432 с. — ISBN 5-94074-260-2.
• Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS / С. Орлов. — 2-е изд.. — СПб.: Питер, 2006. — 736 с. — ISBN 5-46900-599-2.

Ссылки

• Спецификация текущей версии UML
• Сайт ресурсов UML (англ.), поддерживаемый Object Management Group
• UML Resource Center (англ.) IBM
• Unified Modeling Language, версия 2.0 IBM / developerWorks
• UML 2.2 — заготовки и шаблоны для MS Visio
• Простые UML диаграммы для вставки на веб-страницы

UML (Unified Modeling Language) — стандартный язык для описания, визуализации, проектирования и документации элементов информационных систем. Нотация принадлежит консорциуму OMG (Object Management Group), который разрабатывает ее с 1997 года. OMG также разрабатывает BPMN 2.0 — нотацию для проектирования бизнес-процессов.

Диаграммы UML отражают какой-то один аспектов информационной системы, а не систему в целом. Например, диаграмма вариантов использования (use-case model) показывают систему с точки зрения взаимодействия с конечным пользователем. За счет комбинации различных диаграмм можно достичь целостного взгляда на модель проектируемой системы, что крайне полезно при разработке.

Принципы нотации UML

Как и любая нотация, UML служит средством коммуникации между разработчиками системы.

Задачи UML

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

Цель UML — создать точные, исчерпывающие и предельно понятные модели информационных систем.

Особенности UML

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

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

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

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

Теперь легко понять базовые принцип работы с нотацией UML:

1. Установить объект и все его функции. Совокупность функции объектов определяют цели проектируемой системы.
2. Соотнести объекты друг с другом с учетом всех задуманных связей в рамках целого.
3. Реализовать полученную модель с помощью языков программирования Java, С++ и др.

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

Типы UML диаграмм

Мы уже сказали, что для моделирования UML использует несколько типов диаграмм. Давайте посмотрим на них подробнее. Существуют 14 типов диаграмм, которые делятся на 2 большие группы диаграммы поведения (и взаимодействия), а также структурные диаграммы

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

Модель использования в нотации UML (Use-case model)

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

Диаграммы прецедентов

Показывают набор действий, доступных отдельному пользователю при работе в системе. Прецедент в данном случае — это стандартный вариант использования функциональных возможностей. Его принято обозначать эллипсом с подписью в форме глагола. Например, ввести логин и пароль, заполнить заявку на закупку, внести данные клиента или согласовать проект договора.

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

Диаграмма деятельности (активности)

Показывает причинно-следственные взаимосвязи между действиями в системе. Диаграмму можно использовать для проектирования бизнес-процессов, бизнес-правил, потока работ, алгоритмов, сценариев тестирования и других последовательных, скоординированных операций. Точка входа в процесс по правилам UML должна быть только одна, а вот выходов может быть несколько.

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

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

Показывает порядок взаимодействия с объектами системы. Взаимодействие осуществляется в рамках прецедента, или стандартного сценария использования функциональных возможностей.

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

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

Подведем некоторые итоги. Модели UML позволяют рационально организовать процесс разработки, и не только в плане коммуникации между заказчиком и техническим исполнителем. Однако уловить различие между разными типами диаграмм UML с первого раза не так просто. Нужна определенная практика.

BPMN 2.0 — интуитивно-понятная нотация для бизнеса и ИТ

Немного скажем о нотации BPMN 2.0. Противопоставлять UML и BPMN 2.0 не очень правильно, поскольку эти две нотации решают разные задачи, и к тому же принадлежат одному консорциуму.

• UML — инструмент проектирования систем, чаще всего информационных
• BPMN 2.0 — инструмент проектирования бизнес-процессов.

BPMN не позволяет моделировать системы с нуля, но отлично справляется с бизнес-процессами. BPMN диаграммы гораздо наглядней, чем диаграммы процессов в UML, и ориентированы не столько на задачи разработки, сколько именно на задачи управления. Для бизнеса BPMN служит не только средством коммуникации с разработчиком, но и инструментом оптимизации бизнес-процессов.

Comindware Business Application Platform использует для моделирования процессов именно нотацию BPMN 2.0, что упрощает создание бизнес-ориентированных решений. Платформа использует простые Low-code методы разработки, которые можно освоить за 2 дня, не владея навыками программирования. Метод разработки, предложенный платформой, позволяет проектировать системы на основе диаграмм BPMN.