Что такое диаграмма бизнес процессов uml

Аннотация: В этой лекции рассказывается о типах диаграмм UML 2.0, подробно рассматриваются диаграммы случаев использования, активностей, компонент, развертывания, коммуникаций и последовательностей, временные диаграммы, диаграммы схем взаимодействия

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

Настала пора познакомиться с одним из визуальных языков — UML ( Unified Modeling Language ) версии 2.0, который является на данный момент самым распространенным и общеизвестным способом моделирования программного обеспечения.

«Скелетом» представленного здесь UML -экскурса является диаграммная структура UML . Его авторы выделяют следующие типы диаграмм ( diagram types) (см. рис. 3.1):

• Структурные диаграммы:

• диаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных приложений — классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом;
• диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;
• диаграммы объектов ( object diagrams ) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;
• диаграммы композитных структур (composite structure diagrams ) используются для моделирования составных структурных элементов моделей — коопераций, композитных компонент и т.д.;
• диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);
• диаграммы пакетов (package diagrams) служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

• диаграммы активностей ( activity diagrams ) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;
• диаграммы случаев использования(use case diagrams) предназначены для «вытягивания» требований из пользователей, заказчика и экспертов предметной области;
• диаграммы конечных автоматов (state machine diagrams) применяются для задания поведения реактивных систем;
• диаграммы взаимодействий (interaction diagrams):

• диаграммы последовательностей ( sequence diagrams ) используются для моделирования временных аспектов внутренних и внешних протоколов ПО;
• диаграммы схем взаимодействия (interaction overview diagrams) служат для организации иерархии диаграмм последовательностей;
• диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой, манере);
• временные диаграммы ( timing diagrams ) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.

На рис. 3.1 не все узлы обозначают типы диаграмм — некоторые изображают лишь группы диаграмм, например, «Структурные», «Поведенческие», «Взаимодействий».

Что такое UML за 7 минут: Диаграмма классов, последовательностей, состояний и деятельности

UML для бизнес-аналитиков

увеличить изображение
Рис. 3.1. Типы диаграмм UML 2.0

Отметим новые типы диаграмм, которые появились в UML 2.0 по сравнению с версией 1.5:

• диаграммы композитных структур (composite structure diagrams ) — сюда, фактически, вошло два типа диаграмм: (i) коопераций (при этом кооперации UML 1.5 были сильно расширены); (ii) сложных компонент, созданных на базе компонент языка ROOM [3.5];
• диаграммы схем взаимодействий (interaction overview diagrams) — прообразом этого типа диаграмм явились диаграммы MSC overview [3.6];
• диаграммы коммуникаций (communication diagrams) — это упрощенный вариант диаграмм коопераций UML 1.5 ;
• временные диаграммы ( timing diagrams ) — это новый тип диаграмм, предназначенный для наглядного изображения потока изменения состояний нескольких объектов.

Я оставлю в стороне тот факт, что английские названия некоторых типов диаграмм изменились, скажу лишь несколько слов о русскоязычной UML -терминологии. К сожалению, она не является устоявшейся: так, «use case» переводят то как «вариант использования», то как «случай использования» или даже просто как «использование», «deployment» — то как «размещение», то как «развертывание», «state machine (statechart)» — то как «состояния и переходы», то как «конечные автоматы» и т. д. На всякий случай для всех терминов в тексте дается исходное, англоязычное название. Я надеюсь, что у читателя не возникнет в голове безнадежной терминологической путаницы.

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

Система «Телефонная служба приема заявок»

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

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

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

Диаграммы случаев использования (use case diagrams)

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

Рис. 3.2. Пример диаграммы случаев использования

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

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

Различные пользователи ПО , изображаемые на диаграммах случаев использования, называются актерами (actors). Актеры могут обозначать:

• типовых пользователей («Менеджер», «Оператор», «Техническая поддержка») — работников компании, сгруппированных по исполняемым обязанностям;
• другие системы, взаимодействующие с данной («Система обработки заявок»);
• выделенного пользователя («Петров А.Б.»).

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

Случай использования (use case) — это независимая часть функциональности системы, обладающая результирующей ценностью для ее пользователей.

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

«Результирующая ценность» случая использования для актера системы подразумевает, что он, данный случай использования , должен приносить актеру некоторый законченный и ценный с точки зрения его бизнеса результат. Будучи реализован системой, этот случай использования действительно делает бизнес актера эффективнее, производительнее. Тем самым разработка системы фокусируется на бизнес-целях, а незначительные случаи использования игнорируются. Строится не абстрактная модель функций системы, а набор самых важных (для заказчика и пользователей) сервисов, чтобы каждый из них правильно понять и не один не упустить. И в дальнейшем контроль разработки системы будет осуществляться именно в терминах этого самого важного — того, что нужно заказчику и пользователям.

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

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

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

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

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

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

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

А сама система будет предоставлять для них бизнес-случаи использования. Пример диаграммы бизнес-случаев использования для системы обработки телефонных заявок показан на рис. 3.3.

Рис. 3.3. Пример диаграммы бизнес-случаев использования

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

Этих бизнес-клиентов можно было бы изобразить и на рис. 3.2, соединив стрелками с оператором (ведь именно через него они взаимодействуют с системой). Но такая диаграмма может вызвать недоумение, хотя некоторые аналитики склонны так делать. Я считаю, что бизнес-актеров лучше изображать на отдельной диаграмме, а на обычной диаграмме случаев использования показывать только пользователей ПО .

Источник: intuit.ru

Диаграммы UML

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

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

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

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

В UML 14 типов диаграмм. Их можно разделить на 2 категории:

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

Иерархия типов диаграмм UML,
представленная диаграммой классов

Структурные диаграммы

1. Диаграмма классов является ключевым элементом в объектно-ориентированном моделировании. С помощью этой диаграммы (собственно, через классы, их атрибуты, методы и зависимости между классами) описывается модель предметной области и структура моделируемой системы.
2. Диаграмма компонентов отображает разбиение программного кода на крупные блоки (структурные компоненты) и показывает зависимости между ними. Компонентами могут быть пакеты, модули, библиотеки, файлы и т.д.
3. Объектная диаграмма показывает полный или частичный срез моделируемой системы в заданный момент времени. Она представляет экземплеры классов (объекты), их состояние (текущие значения аттрибутов) и отношения между ними.
4. Диаграмма композитной структуры демонстрирует внутреннюю структуру классов и, по возможности, взаимодействия между элементами этой структуры.
5. Диаграмма пакетов показывает пакеты и отношения между ними. Этот вид диаграмм служит для упрощения структуры модели (и, соответственно, работы с ней) через объединение элементов модели в группы по некоторым критериям.
6. Диаграмма развертывания моделирует развертывание программных компонентов (артефактов) на вычислительных ресурсах/аппаратных компонентах (узлах).
7. Диаграмма профилей описывает механизм расширения, позволяющий приспособить UML к разнообразным предметным областям и сферам деятельности.

Пример UML-диаграммы классов

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

1. Диаграмма деятельности показывает действия (actions) из которых состоит некоторая деятельность (activity). Диаграммы деятельности используются для моделирования бизнесс-процессов, технологических процессов, последовательных и параллельных вычислений.
2. Диаграмма вариантов использования (или диаграмма прецедентов) описывает отношения между актёрами (действующими лицами) и вариантами использования моделируемой системы (ее возможностями). Основное назначение диаграммы — быть универсальным средством для заказчиков, разработчиков и конечных пользователей, с помощью которого можно было бы совместно обсуждать систему — ее возможности и поведение.
3. Диаграмма состояний изображает динамическое поведение сущности, показывая как эта сущность в зависимости от своего текущего состояния реагирует на различные события. По сути это диаграмма состояний из теории атоматов.
4. Диаграмма коммуникации (в ранних версиях диаграмма кооперации) показывает взаимодействия между частями композитной структуры и ролями кооперации. На диаграмме явно указываются отношения между элементами (объектами).
5. Диаграмма последовательности используется для визуализации последовательности взаимодействий объектов. Показывает жизненный цикл заданного объекта и взаимодействие актеров (действующих лиц) в рамках некоторого варианта использования, последовательность сообщений которыми они обмениваются.
6. Диаграмма обзора взаимодействия включает часть диаграммы последовательности и конструкции потока управления. Помогает рассмотреть взаимодействие объектов с различных точек зрения.
7. Диаграмма синхронизации — отдельный подвид диаграмм взаимодействия, специализируйющийся на тайминге. Диаграммы этого вида используются для исследования поведения объектов в течение определенного периода времени.

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

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

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

Grapholite TM

• Описание программы
• Философия и преимущества
• Альтернатива Visio (англ.)
• Документация (англ.)
• Варианты лицензий и цены

• Скачать для iPad
• Скачать для Android
• Для Windows 10
• Для Windows Desktop

Виды графики «из коробки»

• Блок-схемы, флоучарты
• EPC-диаграммы
• Диаграммы UML
• Плавательные дорожки (swimlanes)
• BPMN диаграммы
• Планы помещений (офиса, дома)
• Циклические диаграммы
• Схемы мозгового штурма
• Интеллект-карты (карты мыслей)
• Организационные диаграммы
• Диаграммы Венна
• Карты сайтов

Примеры применения

• Наглядные пособия и презентации
• Расстановка мебели дома, в офисе
• Создание инфографики
• Описание архитектуры предприятия

Шаблон проектирования «Декоратор»

Примеры схем и диаграмм

План офисного помещения

Шаблон проектирования «Декоратор»

Источник: grapholite.ru

UML-диаграмма. Виды диаграмм UML

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

Зачем она нужна?

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

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

Также стоит отметить, что есть несколько видов таких диаграмм.

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

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

Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:

• Концептуальная. В данном случае диаграмма классов UML осуществляет описание модели определенной предметной области, и в ней предусматриваются только классы прикладных объектов.
• Специфическая. Диаграмма используется в процессе проектирования различных информационных систем.
• Реализационная. Диаграмма классов включает в себя всевозможные классы, которые непосредственно используются в программном коде.

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

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

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

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

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

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

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

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

Между артефактом и тем компонентом, который он реализует, формируется зависимость манифестации.

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