Uml

Как построить UML-схему

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

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

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

Другие термины на «U»

URLUTMUnityUbuntuUnreal EngineUnit-тестирование
Все термины

Кто пользуется UML

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

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

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

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

Бизнес-аналитики и менеджеры по развитию, которым диаграммы нужны для визуализации бизнес-процессов и структур.

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

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

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

Курс для новичков «IT-специалист с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

Подробнее

Языки (нотации) для описания корпоративной архитектуры

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

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

Кросс-функциональная диаграмма

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

Шаблон IDEF0, построенный в Grapholite из обычного прямоугольника и стрелок

ARIS eEPC (extended event driven process chain) — мощная, оснащенная и технологичная методология. Несмотря на свой возраст, она все еще находит свое применение. Grapholite поддерживает создание EPC диаграмм «из коробки».

Пример EPC-диаграммы

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

Пример диаграммы UML Activity (деятельности)

BPMN (Business Process Model and Notation) в настоящее время является наиболее подходящим решением для описания бизнес-процессов. Эта методология (и нотация) моделирования — отличная альтернатива конкурирующим между собой «частным» решениям.
Это открытый, публичный стандарт. Grapholite поддерживает как предыдущую версию BPMN 1.2, так и новую 2.0.

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

Основные потоки

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

1. Материальный: материалы и комплектующие на входе и готовая продукция на выходе.
2. Клиентский: потенциальный клиент на входе и удовлетворенный на выходе.
3. Финансовый: на входе это обычно инвестиции, платежи клиентов (выручка), кредиты и прочие доходы; на выходе – это платежи поставщикам, налоги, платежи по кредитам и прибыль.
4. Информационный: на входе это все потоки информации о внешней среде (состояние рынка, поведение конкурентов, технологические инновации и пр.), а на выходе – это поток информации, которую компания сообщает о себе миру (вся рекламная информация, а так же все виды отчетности перед контролирующими органами).

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

Пример контекстной диаграммы (нажмите для увеличения)

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

Стрелки управления могут быть представлены только 1 видом потока – информационным, который можно разбить на 2 подвида. Первый – это документы, такие как:

• законы и нормы;
• приказы, распоряжения;
• инструкции и регламенты;
• планы;
• конструкторская документация и пр.

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.

Где еще используется UML

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

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

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

IT-специалист с нуля

Функциональный блок

Центральным элементом модели IDEF0 является функция, которая на схеме отображается в виде функционального блока – прямоугольника, внутри которого указано действие в форме отглагольного существительного. Действие может быть очень разным по масштабу – от деятельности компании вообще и до конкретной манипуляции в частности. Примеры: «Производство и продажа керамической посуды» и «Нанесение рисунка на изделие».

Обязательные элементы функционального блока в IDEF0

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

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

Такой подход позволяет немного сэкономить на пояснениях в схемах и добиться однозначности в отображении потоков, что придает стройности всей модели.

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

1. Входы – это ресурсы, которые переносят свою стоимость в выходы полностью, то есть расходуются на создание результата полностью, а механизмы – это ресурсы, которые переносят свою стоимость только частично (оборудование – через амортизацию, а люди – через заработную плату).
2. Управление – это необходимый элемент модели, так как он привязывает все действия к системе регламентов компании, четко обозначая, какие правила и требования должны быть соблюдены в процессе выполнения функции. Часто к этому потоку относятся формально, но при этом схема теряет строгость, а иногда даже смысл.
3. У каждого функционального блока должна быть как минимум одна стрелка с каждой стороны (так как не может быть работы без ресурсов или результатов, а также неполной будет инструкция без исполнителя или инструкции).

Рассмотренная схема является «кирпичиком» подхода IDEF0. Функциональное моделирование предполагает постепенный переход от общего к частному за счет декомпозиции. Декомпозиция – это «углубление» в рассматриваемую функцию, разделение ее на более мелкие функции. При этом, когда функция верхнего уровня представлена обобщенно и после декомпозирована, ее уместно уже назвать процессом.

Декомпозиция

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

Первый шаг декомпозиции (нажмите для увеличения)

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

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

1. Создание продукта (результата).
2. Продвижение и продажа – работа с клиентским потоком.
3. Обеспечение деятельности по созданию продукта – вторичные процессы, которые необходимы для соблюдения государственных требований или удобства работы (кадровый и бухгалтерский учет, транспортное обслуживание, уборка помещений и прочее).
4. Создание потоков управления – деятельность по разработке управленческих решений, которые будут определять требования ко всем процессам компании.

На рисунке ниже представлена диаграмма декомпозиции нашего примера.

Первый уровень декомпозиции (нажмите для увеличения)

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

Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.

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

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

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

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

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

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

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

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

Недостатки UML

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

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

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

Для чего нужны UML-диаграммы

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

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

Основные понятия и сокращения

Разберемся немного с названиями ключевых элементов методологии. Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). IDEF – это сокращение от ICAM Definition, а ICAM образовано от Integrated Computer Aided Manufacturing, что переводится как интегрированная компьютеризация производства. Методология SADT – это целое семейство из 15 разных моделей, которые в комплексе должны были позволить исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.

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

Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.

Контекстная диаграмма

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

1. Цель – конкретная формулировка назначения модели, по которой можно сверять в дальнейшем точность построения модели.
2. Точка зрения – от чьего лица строится модель, так как модель зависима всегда от ее автора и фокуса внимания. Если мы строим общую модель предприятия, то обычно она представляется с точки зрения его директора.
3. Тип модели – это указание на то, какая информация отображена на схемах. Здесь может быть 2 принципиальных варианта: AS IS («как есть») или TO BE («как будет»). Такое разделение необходимо, так как мы можем строить модели как для анализа деятельности, так и для ее трансформации. Мы должны четко отдавать себе отчет в том, что мы делаем, а также доносить эту информацию до окружающих.

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

Виды UML-схем

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

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

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

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

Выводы об актуальности нотации

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

1. Модель обладает хорошим визуализирующим потенциалом, но, на мой взгляд, большее ее значение – в дисциплинирующем эффекте. Заложенные в методологию правила и ограничения заставляют выработать системное и строгое отношение к моделям, что очень хорошо сказывается на качестве конечного результата.
2. Модель позволяет выстроить потоки связи между внешне не сильно связанными вещами: связать подсистемы фронт и бэк-офисов с управлением, что гораздо хуже удается другим нотациям.
3. Подход прост и понятен для большинства участников проекта. Построение и чтение диаграмм в данной нотации ограничивается только желанием вникать в хитросплетение потоков бизнеса.

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

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

Поэтому если пользоваться данной нотацией для тех задач, для которых она предназначена (структурирование деятельности верхнего уровня), то IDEF0 практически единственная на сегодня нотация, которая позволяет сделать это содержательно и аккуратно.

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