Для описания логики выполнения бизнес процесса в uml лучше всего подойдет

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

Событийно-процессные нотации бизнес-моделирования: основы диаграмм BPMN, EPC и UML activity

Описать логику выполнения процесса – одна из самых частых задач в профессиональной деятельности системных и бизнес-аналитиков. Она решается с помощью событийно-процессных нотаций моделирования, к которым относятся UML-диаграмма деятельности (UML activity), BPMN (Business Process Model and Notation) и EPC (Event-Process Chain). Хотя построенные по правилам этих нотаций диаграммы немного отличаются внешне, все они по сути представляют собой направленный или ориентированный граф, вершинами которого являются шаги бизнес-процесса, (действия, задачи или функции), а ребрами – стрелки потока управления. Поток управления движется непрерывно от стартовой точки (начало бизнес-процесса) до его окончания (финишной точки), соединяя шаги процесса последовательно или через логические операторы (шлюзы, развилки), не допуская «висячих» вершин. Помимо функций/задач в EPC/BPMN поток управления также соединяет события.

Событийно-процессная диаграмма начинается стартовым событием и заканчивается финишным. Можно сказать, что они ограничивают бизнес-процесс, т.е. определяют его границы (о том, что это такое и зачем это нужно, читайте здесь). В UML activity начало и конец процесса обозначаются черными кругами, в BPMN они могут уточняться типом события (сообщение, таймер и пр.), а в EPC – подробной формулировкой (наступило 1-е число отчетного месяца). Поскольку событие – это уже свершившийся факт, это следует отражать в его названии. Например, «позвонить клиенту» – это НЕ событие, а «сделан звонок клиенту» – это событие.

Шаги бизнес-процесса, их участники и артефакты

Процесс состоит из набора шагов (действия в UML activity, функции в EPC и задачи в BPMN), каждый из которых следует представлять в отдельном блоке с названием в виде глагола или отглагольного существительного. Например, «разработка ТЗ» или «разработать ТЗ».

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

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

Немного булевой алгебры: логические операторы и шлюзы

Поскольку диаграммы UML activity, EPC и BPMN позволяют описать логику выполнения бизнес-процесса, в отличие от просто структуры, которую лучше всего показывать в IDEF0, неудивительно что в событийно-процессных нотациях появляются логические операторы. В бизнес-логике их 3: логическое И (AND), логическое ИЛИ (OR) и исключающее ИЛИ (XOR). Первые два (AND и OR) отражают смысл конъюнкции и дизъюнкции в таблицах истинности, описывающих поведение функций над переменными в булевой алгебре. Чтобы не углубляться в дебри дискретной математики, отметим самое главное свойство логических операторов в контексте описания бизнес-процессов: они позволяют показать ветвления потока управления в зависимости от условий. Например, если условия коммерческого предложения не подошли клиенту, он может сообщить о желании их изменить ИЛИ отказаться от заключения договора. В этом случае один исход исключает другой, поэтому используется оператор XOR – исключающее ИЛИ. А если один поток не противоречит другому, например, позвонить по телефону или написать письмо, или сделать и то, и другое, подойдет оператор OR. Наконец, если запускаются/сливаются несколько потоков управления, каждый из которых должен дождаться остальных, используется AND.

Примечательно, что в UML activity есть только блок «Решение», эквивалентный исключающему ИЛИ (XOR) и блоки слияния/разделения потоков управления, эквивалентные логическому И (AND), а оператор OR отсутствует. В BPMN и EPC есть все 3 логических оператора, причем в BPMN они различаются по типу (управляемый данными, управляемый событиями и пр.). Причем в UML и EPC следует строго соблюдать правило соединения потоков управления через шлюзы, т.е. в 1 блок задачи/функции входит только 1 стрелка потока управления и выходит тоже только 1. Для слияния и разветвления потоков используются AND, OR, XOR. Обычно оператор, разделивший потоки управления, должен их соединить. Это легко проверить, посчитав на диаграмме количество логических операторов одного типа – оно должно быть четным, если одна из веток не прерывается окончанием процесса.

Как описать бизнес-процесс в BPMN, EPC, UML activity: практический пример

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

1. Старт процесса начинается с момента, когда клиент оставил заявку на сайте.
2. На основании заявки, где указан курс, даты и другие вопросы, интересующие клиента, менеджер формирует коммерческое предложение и озвучивает его по телефону или направляет на email, или же делает и то и другое – в зависимости от пожеланий клиента и указанных в заявке контактных данных.
3. Узнав подробности коммерческого предложения, клиент принимает решение: будет обучаться или нет по каким-то причинам, например, не подошли условия (время или формат проведения занятий, оплата и пр.). Если клиент не решил обучаться, на этом процесс работы с ним заканчивается.
4. Если клиента устраивают все условия, он сообщает менеджеру о намерении заключить договор об обучении и передает данные для договора.
5. Менеджер формирует проект договора и отправляет его на согласование клиенту.
6. При отсутствии возражений клиент подписывает договор, договор считается заключенным и на этом бизнес-процесс заканчивается и запускает процесс оплаты, описанный на отдельной диаграмме.
7. В случае возражений к проекту договора клиент вносит в него изменения и направляет менеджеру.
8. Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, т.е. идет возврат к шагу 5.

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

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

А ограниченный алфавит нотации UML activity обусловливает аскетичный вид следующей диаграммы. Например, из-за отсутствия неисключающего ИЛИ (OR) вместо него пришлось использовать AND, что на самом деле не совсем соответствует реальности. AND предполагает выполнение обоих действий (позвонить и отправить письмо), хотя в действительности может быть достаточно одного из них.

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

А подробно освоить все эти нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Методы описания бизнес-процессов (IDEF, BPMN, EPC, UML)
• Основы бизнес-анализа: вход в профессию для начинающих
• UML для бизнес-аналитика

Автор: Александр Марголин, CTO

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

Что такое UML-диаграммы?

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

Для чего используется UML?

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

• Проектирование. UML-диаграммы помогут при моделировании архитектуры больших проектов, в которой можно собрать как крупные, так и более мелкие детали и нарисовать каркас (схему) приложения. По нему впоследствии будет строиться код.  

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

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

Нотация UML для описания логики проекта

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

• фигуры;
• линии;
• значки;
• надписи.

UML-нотация является де-факто отраслевым стандартом в области разработки программного обеспечения, ИТ-инфраструктуры и бизнес-систем.

Часто используемые программы для создания диаграмм

• Diagrams.net — удобный сервис для создания блок-схем, UML-диаграмм, моделей бизнес-процессов онлайн. Совместим с большинством популярных инструментов, включая Google Docs, Git, Dropbox, OneDrive и другие.

Источник: diagrams.net

• Dbdiagram.io — приложение для построения диаграмм связей для баз данных. Хороший инструмент для разработчиков и аналитиков.

• Google Drawings — бесплатный инструмент для создания блок-схем и диаграмм в составе Google Drive (менее удобный по сравнению с diagrams.net);

• xmind.net — программа для построения интеллектуальных карт (mind map), логических схем, сложных структур, проведения брейнсторма и не только.

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

В языке UML есть 12 типов диаграмм:

• 4 типа диаграмм представляют статическую структуру приложения;
• 5 типов представляют поведенческие аспекты системы;
• 3 представляют физические аспекты функционирования системы (диаграммы реализации).

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

• Диаграмма прецедентов (Use-case diagram); 
• Диаграмма классов (Class diagram);
• Диаграмма активностей (Activity diagram); 
• Диаграмма последовательности (Sequence diagram);
• Диаграмма развёртывания (Deployment diagram);
• Диаграмма сотрудничества (Collaboration diagram); 
• Диаграмма объектов (Object diagram); 
• Диаграмма состояний (Statechart diagram).

Диаграмма прецедентов — Use-case diagram

Диаграмма прецедентов использует 2 основных элемента: 

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

2) Use case (прецедент) — описание отдельного аспекта поведения системы с точки зрения пользователя. Прецедент не показывает, «как» достигается некоторый результат, а только «что» именно выполняется.

Рассмотрим классический студенческий пример, в котором есть 2 участника: студент и библиотекарь. Прецеденты для студента: ищет в каталоге, заказывает, работает в читальном зале. Роль библиотекаря: выдача заказа, консультации (рекомендации книг по теме, обучение использованию поисковой системы и заполнению бланков заказа).

Источник: slide-share.ru

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

Источник: slide-share.ru

Диаграмма классов — Class diagram

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

Источник: slide-share.ru

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

Диаграмма активностей — Activity diagram

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

Диаграмма активностей для сайта магазина максимально доступно объясняет, какие есть интеграции в системе. Актер (в нашем случае — покупатель), зашедший на сайт, делает заказ. Далее у нас происходит разветвление: проверяем, является ли пользователь оптовиком (Да/Нет). Если он не зарегистрирован в системе и не оптовик, заказ отправляется в retailCRM. Если пользователь зарегистрирован, его заказ попадает в Navision. При этом между retailCRM и Navision происходит синхронизация остатка и статусов.

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

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

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

 Источник: slide-share.ru

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

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

Источник: slide-share.ru

Заключение

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

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

Остались вопросы, хотите обсудить с нами ваш проект или заказать разработку? Пишите!

06.02.2021

Используемые в статье картинки взяты из открытых источников и используются как иллюстрации.

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 строятся несложно, легко читаются и воспринимаются персоналом, не обладающим специализированными знаниями, подходят для проектирования архитектуры и поведения, позволяют понять связи между модулями и интеграциями в системе.

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

Классификация моделей

Понятие модели

Модель представляет искусственный, созданный человеком объект любой природы (умозрительный или материально реализованный), который замещает или воспроизводит исследуемый объект.
Процесс построения, изучения и применения моделей называется моделированием.

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

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

Модель внешнего вида часов

Структурная схема часов

Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).

Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.

Классификация моделей

Познавательные (объяснительные) модели отражают уже существующие объекты.

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

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

Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.

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

Детерминированные модели отражают процессы и явления, не подверженные случайностям.
Стохастические – отражают случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями.

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

Языки описания моделей

Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.

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

Требования к нотации:

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

Содержание модели бизнеса

В модели бизнеса отражают:

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

Методы моделирования бизнеса

Структурные методы

Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

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

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

Наибольшее распространение получили методологии:

• IDEF0 – функциональные модели, основанные на методе SADT;
• IDEF1X – диаграммы данных «сущность-связь» (ERD);
• IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
• DFD — диаграммы потоков данных (Data Flow Diagrams).

Методы объектно-ориентированного моделирования

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

Наиболее известные методы:

• Booch’93 Г. Буча,
• OMT Дж. Румбаха
• OOSE А. Джекобсона
• UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE

Главным структурообразующим элементом является объект.
В программировании объект — это структура, объединяющая данные и процедуры.
В модели бизнеса объекты – это участники бизнес-процесса (активные объекты) и пассивные объекты (материалы, документы), над которыми выполняют действия активные объекты.

Методы имитационного моделирования

Позволяют имитировать на компьютере (с помощью специальных программ) процессы функционирования реальной системы (в режиме сжатого времени или пошаговом режиме).

Наиболее распространенные методы:

• сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
• GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
• SIMAN (SIMulation ANalysis) – язык визуального моделирования.

Интегрированные методы

Интегрированные методы моделирования объединяют различные виды моделей – структурного анализа, объектно-ориентированные, имитационные и др.

• ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
• G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
• BRM (Business Rules Management) – методология управления бизнес-правилами.

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

Методология IDEF0

Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).

Основные элементы модели:

• Функциональный блок (Activity) – преобразование (активность);
• Выходы (Output) – результат преобразования;
• Входы (Input) — объекты, которые преобразуются в Выходы;
• Управление (Control) — информация, как происходит преобразование;
• Механизм (Mechanism) – объекты, осуществляющие преобразование.

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

Таким образом, IDEF0-модель состоит из набора иерархически связанных диаграмм
На диаграмме блоки соединяются дугами: выходные дуги одних блоков могут являться входами (управлением, механизмом) других.
Дуги с одним свободным концом имеют источник или получатель вне диаграммы. Для обозначения внешних дуг используются буквы:

• I (Input),
• C (Control),
• O (Output) и
• M (Mechanism).

Типы связей между блоками:
Выход-вход

Выход-управление

Выход-механизм

Обратная связь по управлению

Обратная связь по входу

Методология IDEF3

IDEF3-модели используются для документирования технологических (информационных) процессов, где важна последовательность выполнения процесса

Выделяют четыре элемента IDEF3-модели:
Единица работы — отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход

Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).

Связи (Links), которые бывают двух типов:
передают действия от одной единицы работ к другой

соединяют ссылку с единицей работ (активируют единицу работ)

Перекрестки (Junctions) – элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in

перекрестки ветвления – Fan-out

Типы перекрестков

Асинхронное И (Asynchronous AND)
выходной процесс запустится, если завершились все входные процессы

после завершения входного процесса запустятся все выходные процессы

Синхронное И (Synchronous AND)
выходной процесс запустится, если завершились одновременно все входные процессы

после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно

Асинхронное ИЛИ (Asynchronous OR)
выходной процесс запустится, если завершится один или несколько входных процессов

после завершения входного процесса запустятся один или несколько выходных процессов

Синхронное ИЛИ (Synchronous OR)
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно

после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно

Исключающее ИЛИ (XOR, Exclusive OR)
выходной процесс запустится, если завершился только один входной процесс

после завершения входного процесса запустится только один выходной процесс

Пример IDEF3

Правила создания перекрестков

1. Каждому перекрестку слияния должен предшествовать перекресток ветвления.
2. Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
3. Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
5. Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.

Правило относительно единиц работ

В блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки.
Разрешается множественная декомпозиция работ:
для одной и той же работы может быть создано несколько диаграмм декомпозиции (для описания разных вариантов реализации работы).

Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.

Методология DFD

Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона

Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия), которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные

2. Потоки данных, которые обозначают взаимодействие процессов с внешним миром и между собой. Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта).

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

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

Пример:

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

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

Прецедентная модель бизнеса

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

Актор (действующее лицо, business actor) — субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.

Прецедент (вариант использования, business use case) — относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору .
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.

Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.

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

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).

Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.

В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов

Поток событий прецедента

Поток событий — описание прецедентов последовательностью шагов

Поток событий прецедента «Продажа продукта»:

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

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

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

Дорожки:
Если в выполнении прецедента участвуют несколько объектов, то действия, выполняемые каждым объектом, размещаются на соответствующей дорожке

Структурирование прецедентов

Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.

2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).

Объектная модель бизнес-процесса

Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют.
Классы объектов модели бизнеса:
активные — исполнители процессов (стереотип business worker), например, Продавец, Изготовитель, Разработчик;

пассивные — сущности (стереотип business entity), например, Продукт, Заказ, Счет.

Иногда среди активных выделяют:
интерфейсные (стереотип Boundary) – активные объекты, взаимодействующие с окружением, т.е. с акторами. Примеры – Продавец, Регистратор, Секретарь..
управляющие (стереотип Control) – активные объекты, участвующие в выполнении процессов, но не имеющие контакта с окружением. Примеры – Разработчик продукции, Изготовитель, Менеджер проекта..

Классы и объекты

Класс – некоторый тип объектов (множество похожих объектов),
Экземпляр – конкретный объект (представитель класса).

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

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

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

Динамическая диаграмма взаимодействия

Прецедент «Продажа заказного продукта»:
Продавец получает заявку клиента
Продавец формирует заказ и передает его Изготовителю продукта.
Изготовитель изготавливает продукт.
Изготовитель отправляет продукт на Склад и сообщает о готовности Продавцу.
Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату.
Продавец сообщает Отправителю адрес клиента и заказывает транспорт.
Отправитель получает продукт со склада и доставляет его клиенту.

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

В верхней части диаграммы – активные объекты (и акторы) в виде прямоугольника («человечка»), от которого вниз проведена «линия жизни».
Сообщение (message) – отрезок горизонтальной линии со стрелкой, проведенный от линии жизни объекта (актора), посылающего сообщение, до линии жизни объекта (актора), получающего сообщение.

Отношение сообщения моделирует материальный или информационный поток.
Прием сообщений инициирует выполнение некоторого действия получателем

Сообщения упорядочены по времени: первое сообщение изображается вверху диаграммы, следующее – ниже, следующее – еще ниже и т.д.
Однако диаграмма не содержит метрики времени (расстояния между сообщениями – это не интервал времени)

Статическая диаграмма взаимодействия

Диаграмма кооперации (Collaboration Diagram)

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

Диаграмма классов (Class diagram) используется для отображения устойчивых связей между классами объектов
Диаграмма классов для прецедента «Продажа продукта»

Для структурирования классов используются отношения обобщения и включения

Описание объектов

Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).

Интегрированная методология ARIS

Методология ARIS (Architecture of Integrated Information System) разработана в 1990-х годах профессором А.-В. Шеером

Для каждого из этих представлений можно построить несколько типов моделей (в ARIS 5.0 общее количество типов диаграмм — 130)

Выделено четыре основных вида моделей (четыре представления):

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

Организационная схема

К организационным моделям относится Организационная схема (Organizational chat).
Основные типы объектов этой модели:

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

Дерево функций

К функциональным моделям относится Дерево функций (Function Tree).

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

Событийная цепочка процесса

К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)

Основные типы объектов:

Элементы диаграммы eEPC

• Функция – некоторое (шаг процесса). С функцией могут быть связаны: исполнители, входные и выходные документы, программное обеспечение и т.д.
• Событие — какое-либо завершенное состояние объекта, которое влияет на дальнейший ход процесса. С одной стороны события являются стимулом к выполнению функций, с другой – их результатом.
• Логические операторы (И, ИЛИ, XOR) показывают разветвления в потоке процесса.

Примеры:

Интеграция моделей

Взаимосвязь моделей ARIS обеспечивается с помощью двух механизмов: интеграции и детализации
1. Механизм интеграции
Благодаря хранению объектов в едином репозитории (специальной базе данных).
При создании нового объекта в репозитарии появляется отдельная запись, задающая описание объекта.
Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste.

Детализация моделей

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

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

Инструментальные средства

Возможности инструментальных средств

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

Использованная литература

1. Национальный исследовательский Томский политехнический университет. Томск. Силич М.П. 2016. 75 с. Презентация к лекции.

Аве Кодер!

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

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

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

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

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

Происхождение UML

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

UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:

• Техника объектного моделирования OMT [James Rumbaugh 1991], которая была лучшей для анализа информационных систем с большим объемом данных.
• Booch [Grady Booch 1994] — отлично подходит для разработки и реализации. Грэди Буч много работал с языком Ада и был крупным игроком в разработке объектно-ориентированных методов для языка. Хотя метод Буча был сильным, нотация была воспринята менее хорошо, например, в его моделях преобладали формы облаков, что выглядело не очень аккуратно.
• OOSE (объектно-ориентированная программная инженерия [Ivar Jacobson 1992]) — модель, известная как модель прецедентов — это мощная методология для понимания поведения всей системы, область, где ООП традиционно была слабой.

В 1994 году Джим Рамбо, не путать с Джоном Рэмбо, хотя Джим тоже был крут, потому что был, на секундочку, создателем вышеупомянутой техники объектного моделирования, ошеломил мир программного обеспечения, когда он покинул General Electric и присоединился к Грэди Бучу в Rational Corp. Цель партнерства состояла в том, чтобы объединить их идеи в единый унифицированный метод (рабочее название для метода действительно было — «Единый метод»).

К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.

В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».

На UML также повлияли другие объектно-ориентированные нотации:

• Меллор и Шлаер [1998]
• Coad и Yourdon [1995]
• Вирфс-Брок [1990]
• Мартин и Оделл [1992]

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

Почему UML?

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

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

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

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

Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.

Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.

Основные цели дизайна UML:

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

Диаграммы UML подразделяют на два типа — это структурные диаграммы и диаграммы поведения.

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

• Диаграмма составной структуры
• Диаграмма развертывания
• Диаграмма пакетов
• Диаграмма профилей
• Диаграмма классов
• Диаграмма объектов
• Диаграмма компонентов

Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени. А к диаграммам поведения относятся:

• Диаграмма деятельности
• Диаграмма прецедентов
• Диаграмма состояний
• Диаграмма последовательности
• Диаграмма коммуникаций
• Диаграмма обзора взаимодействия
• Временная диаграмма

Теперь пару слов о каждой из них

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

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

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

Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.

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

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

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

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

Диаграмма профилей

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

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

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

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

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

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

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

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

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

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

Диаграмма Коммуникации

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

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

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

Временная диаграмма

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

Зачем в UML столько диаграмм?

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

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

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

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

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

Для тех, кому лень читать:

Аве!

Какие задачи можно решить с помощью UML? Несколько примеров из личного опыта.

Первый пример – это один из кондитерских домов Москвы, для которого я выполнял разные проекты в течении 10 лет. Они за это время успели поменять несколько систем, первые из которых были на 7.7, а текущие уже на 8.3. Наш последний с ними проект охватывал почти все стандартные процессы производственного предприятия. И особенностью этого проекта являлось то, что заказов у компании очень много, и каждый заказ уникален.

Представьте себе ситуацию: система готова, идут приемо-сдаточные мепрориятия с участием Генерального директора. Все идет хорошо, система работает как нужно. Мы прошли все основные бизнес-процессы и директор говорит: «да, мне уже все нравится, давай еще пробники проверим». И тут оказывается, что, несмотря на то, что я делал с этой компанией несколько систем и очень хорошо знаю ее процессы, у них есть такой уникальный процесс, который не «лег» на текущую архитектуру.

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

Другой пример – автотранспортное подразделение крупной нефтегазовой компании. Мы там автоматизировали механизм планирования:

• Расчет годовых планов;
• Календарное планирование;
• И уже непосредственно работу с заказ-нарядами в рамках тех лимитов, которые следуют из планов.

Особенностями проекта были:

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

Мы на этом проекте построили две модели: модель «как есть» и модель «как должно быть». Прописали все последовательности действий пользователей, какие документы и на каком этапе возникают. Выстроили архитектуру системы в целом – организовали для каждого пользователя именно то рабочее место, которое ему нужно. Но после запуска системы у нас возникло много проблем с одной обработкой, и мы на этом «топтались» несколько месяцев. Мы эту обработку переделывали, доделывали, исправляли ошибки. А всему виной было то, что мы неправильно выбрали объект метаданных. Если бы мы заранее построили модель метаданных, то наверняка бы увидели, что конкретно этот объект в каждодневной работе будет неудобен.

Зачем заниматься моделированием? Зачем тратить на него время?

• Это – сокращение рисков на то, что когда вы сдаете систему, вскроется что-то, что вы не учли – какой-то новый процесс, который вы не проговаривали.
• Моделирование помогает заранее выявить особенности реализации для каких-то незаметных функций, которые вроде как в ТЗ обозначены, но не раскрыты полностью.
• Кроме того, когда человеку дают схему, он ее понимает намного быстрее, чем много текста. Соответственно, если вы готовите модели, вы существенно сокращаете время на согласование документации.
• К тому же, не всегда бывает так, что тот ваш сотрудник, который начал выполнять проект, доводит дело до конца. Бывает так, что он заболел, уволился, эмигрировал и т.д. И перед вами встает задача передачи знаний от одного сотрудника к другому. А имея формализованную нотацию описания бизнес-процессов системы, можно сильно сократить время на передачу информации между сотрудниками.

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

Возникающие вопросы

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

• Возможных нотаций описания очень много, но никаких сравнительных анализов по ним я на тот момент не нашел. Было непонятно, чем одна нотация лучше другой? Почему нужно использовать BPMN или IDEF, и как их использовать?
• Какой должна быть модель? Чем больше я занимаюсь построением моделей, тем больше я понимаю, что не всегда нужно рисовать схему. Это может быть текстовое описание, или, возможно, это будет какая-то комбинация нотаций: не только UML, а UML плюс что-то. Не столь важно, что рисовать, важно понимать, модель какого объекта мы хотим представить, хотим понять.
• Когда ко мне на собеседование приходят аналитики, мой любимый вопрос: «когда нужно готовить описание бизнес-процессов – до технического задания или после?» На это мне обычно отвечают, что должно быть две модели – «как есть» и «как должно быть», план перехода и прочие умные слова. Но по факту, на две модели в бюджете ресурсов никогда нет. И к тому же согласовать построение нескольких моделей очень трудно.
• К тому же, когда я только начинал заниматься моделированием, особенность наших проектов была в том, что они проводились на базе типовых конфигураций, и мне не всегда было понятно, а какие процессы рисовать? Как строить модель так, чтобы не перерисовывать все готовые процессы типовой конфигурации, но при этом, чтобы это было эффективно и понятно пользователю?

На все эти вопросы я постараюсь в статье ответить.

Теоретические аспекты моделирования

Итак, немного теории. Я уверен, что все это знают, но чтобы мы друг друга понимали одинаково, я напомню:

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

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

Чтобы проще это понять, можно представить, что:

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

Какие проекции нам нужны?

• Очевидно, что нам нужна модель организационной структуры предприятия и верхнеуровневого состава его бизнес-процессов – такая модель очень хорошо помогает понять, что делает предприятие и чем оно занимается.
• Далее нам нужна модель бизнес-процессов и ролей пользователей, задействованных в этих бизнес-процессах. Модель ролей и профилей очень удобна для того, чтобы понять все действия пользователя в системе в рамках конкретных бизнес-процессов. На слайде еще указано, что нам будут нужны бизнес-правила. Что это такое – я чуть позже расскажу.
• Итогом всего этого является модель взаимосвязи метаданных и укрупненные схемы алгоритмов, отражающие все внесенные нами в конфигурацию изменения.

И все моделирование нашего объекта (нашего предприятия с его информационной системой и его пользователями) проводится в рамках выбранной нотации.

Выбор нотации для моделирования

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

• Если в модели состава бизнес-процессов мы определили, что у предприятия есть процессы:
  • Продажи,
  • Закупки,
  • Финансы
  • И управление,
• Соответственно, на следующем уровне (в модели бизнес-процессов) у нас должно быть 4 диаграммы на каждый бизнес-процесс предприятия.

И уже после того, как мы определили:

• Объект, который мы моделируем;
• Модели – проекции, по которым мы его раскладываем;
• Правила взаимосвязи моделей;
• Только после этого имеет смысл переходить к выбору нотации для построения конкретной диаграммы.

Например, состав бизнес-процессов можно промоделировать, как минимум, в трех нотациях:

• IDEF0;
• UML:UseCase;
• DFD;
• и еще масса вариантов.

Какой выбрать – решать вам. А я постараюсь объяснить, почему UML удобнее всего.

IDEF0

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

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

• Квадратиками изображаются бизнес-процессы.
• Стрелочки слева – это входящие потоки.
• Стрелочки справа – исходящие потоки.

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

BPMN

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

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

DFD

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

ARIS <>EPC

Часто можно слышать про моделирование в нотации ARIS. Такое определение не совсем корректно, потому что ARIS – это не нотация, это целая методология, которая предполагает много представлений предприятия: организационная структура, функциональная структура и т.д. Эта методология реализована в соответствующем программном продукте, в котором наряду с другими нотациями используют EPC – это специальная нотация для построения диаграмм в системе ARIS.

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

UML

Давайте рассмотрим схему модели UML: Use Case. Что здесь изображено?

• Здесь изображено два участника бизнес-процесса – поросенок и волк, которые являются животными.
• Они участвуют в некоторых сценариях.
  • Например, поросенок участвует в сценарии «Строит дом». Что такое сценарий «Строит дом»? Это – съездить на рынок, купить материалов, спроектировать дом, построить его, протестировать на прочность и т.д. Фактически, это – бизнес-процесс.
  • Есть другой сценарий «Кушает», в котором участвует волк и поросенок. Для волка это, наверное, приятно, а для поросенка – не очень.

Я думаю, вы уже догадались, что это – модель сказки «Три поросенка». Как видите, даже сказку можно замоделировать, причем, это будет понятно.

Вот так бы выглядела объектная модель UML сказки «Три поросенка». Обратите внимание, сколько информации несет одна только связь. Здесь мы видим, что один поросенок (это обозначает цифра «1» в начале связи) строит один дом. О том, что он «строит» дом, мы видим надпись на стрелке. Связь «один к одному». Каждый поросенок построил для себя один дом.

Язык UML – это унифицированный язык моделирования для разработки моделей на основе многих видов диаграмм, например:

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

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

• Первый критерий – это то, что диаграммы должны быть наглядными и простыми. Их должны понимать все люди, и понимать на таком уровне, что ты принес пользователю диаграмму и не объясняешь ему, что означает та или иная фигура, а обсуждаешь с ним предметно, что на этой диаграмме изображено. Диаграммы действительно должны помогать нам коммуницировать с пользователями.
• В нотации IDEF думать очень сложно. И рисовать, в общем-то, тоже непросто. Вы на бумаге диаграмму IDEF вряд ли сходу нарисуете. А диаграмму UML: Use case набросать на доске или на бумаге совсем не сложно, и это будет понятно.
• Конечно, было бы удобно, чтобы все модели можно было построить в рамках одной программы, чтобы не переключаться между разными окнами.
• А также, поскольку ни одна из этих нотаций явным образом не предназначена для 1С, нам так или иначе придется расширять ее нашими обозначениями. Поэтому хотелось бы, чтобы нотация гарантированно поддерживала расширение и инструменты, которые эту нотацию поддерживают, также были расширяемыми.

Применение UML на практическом примере

Начнем с диаграмм пакетов.

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

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

• В левом окне мы видим Project Browser – браузер модели, где представлены все элементы модели.
• А справа – диаграмма. В частности, здесь это – диаграмма оргструктуры. Вполне понятно, что нарисовано. Если у нас какая-то сложная оргструктура – подчиненные узлы подразделений можно убирать внутрь пакетов, и диаграмма все равно будет небольшая – будет вмещаться на одном листе А4.

Диаграмма состава бизнес-процессов.

• Посередине перечислены те бизнес-процессы, которые выполняются на предприятии.
• Слева – внутренние участники бизнес-процессов (сотрудники предприятия).
• Справа – внешние участники бизнес-процессов.

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

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

А справа мы видим детальное описание конкретного макро-шага бизнес-процесса:

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

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

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

Немного о бизнес-правилах. Бизнес-правила – это просто скрипт некоторого действия, он не персонифицирован.

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

Модель ролей.

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

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

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

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

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

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

На слайде показана модель метаданных небольшой подсистемы «Управление предложениями».

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

Далее, после того, как мы построили модель метаданных, можно смоделировать алгоритм.

Все ли алгоритмы нужно моделировать? Нет, конечно. Делать модель алгоритма «Ввод на основании», не нужно, потому что программист и без этого напишет, что контрагент одного документа равен контрагенту другого документа. А вот, например, если у вас сложное проведение с множественным контролем остатков по разным регистрам и областям учета,  тогда имеет смысл все-таки построить модель алгоритма именно для проведения этого документа. Причем, используя опять же, инструмент Enterprise Architect у вас этот алгоритм с функцией проведения будет связан, и вы сможете, кликнув по этой функции, перейти к описанию алгоритма.

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

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

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

Требования и модели

Теперь несколько слов о требованиях.

• Требования – это будущая характеристика информационной системы. Техническое задание, которое мы пишем для клиента по ГОСТ 34, содержит требования.
• Модель – это упрощенное представление некоторого объекта.

Как между собой связаны требования и модель? Напрямую они не связаны. Модель показывает как будет выглядеть система, удовлетворяющая требованиям. И если посмотреть на расшифровку видов требований — то согласно ГОСТ34, там про модель ничего не сказано. Можем ли мы модель задокументировать в техническом задании? Если следовать ГОСТ — то, нет. Но если очень хочется, то можно.

Давайте разберем две ситуации.

Первая – когда заказчик сам разработал техническое задание с требованиями и про документ описания бизнес-процессов ничего слышать не хочет. У него есть ТЗ, и он хочет, чтобы его выполнили.

Обращаемся к стандартам ГОСТ 34, по которому работают все крупные заказчики. Стандарт ГОСТ 34 предусматривает этап работ «Технический проект». Обратите внимание, «Технический проект» – это не документ, а этап работ. И в рамках этого этапа работ согласно ГОСТ34 есть документ, который подходит для документирования модели бизнес-процессов — «Описание автоматизируемых функций». А так как этап «Технический проект» – это вполне формализованный этап по  ГОСТ 34, то логично в его рамках модель системы задокументировать и утвердить у заказчика. С крупными заказчиками успешно проходит.

Другой вариант – когда заказчик вас нанимает и говорит: «Техническое задание будете делать вы, но никаких дополнительных документов я на проекте видеть не хочу, я хочу видеть только техническое задание». Лично сталкивался – мне была поставлена задача: «мне нужно техническое задание и все». Я выяснил аргументы того заказчика: опасения были в том, что пользователи привыкли к ТЗ и другие документы рассматривать и изучать не будут. Что в этом случае делать?

В этом случае можно поступить просто – вставить модель в техническое задание. Формально по ГОСТ34 так делать нельзя. Но когда очень хочется, то можно.

• В техническом задании есть «Раздел 2. Характеристика объектов автоматизации». Тут можно разместить состав бизнес-процессов и орг. структура.
• Также в техническом задании есть «Раздел 3. Требования к информационной системе». Вы их группируете по подсистемам, которые автоматизируете. И перед началом блока требований вставляете схему того бизнес-процесса, для которого эти требования были выработаны.

Мне никто ни разу не сказал, что у меня ТЗ не по ГОСТу. Всегда такой документ принимался. Пользователи видят эти схемы, им все понятно, и ТЗ становится понятнее.

Еще один вариант – это когда вы приходите к клиенту, и там не проект, а клиент просто хочет обработку. Например, изобрел какую-то уникальную схему заказа товаров, которую в УТ11 реализовать нельзя, и просит: «сделай мне ее этот отдельный блок».

В этом случае можно:

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

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

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

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

• Сначала вы строите модель одного процесса (первый проект),
• А потом на основании следующего проекта дополняете эту модель.

Получается, что процесс моделирования – непрерывный. Вы им постоянно занимаетесь и органично вписали его в свой процесс.

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

Заключение

Перед тем, как строить модели, обратите внимание на особенности заказчика. Я лично сталкивался с людьми, которые не понимают схемы – они хотят вас слышать, им лучше принести ТЗ и рассказать его голосом. Это лучше выяснить до того, как вы начнете строить модели.

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

Тема моделирования очень важна для повышения эффективности наших проектов, но, к сожалениию, в нашей отрасли пока не очень популярна. Давайте обсуждать эту тему. Если у вас есть какие-то примеры проектов, которые вы хотите обсудить, напишите мне, я с удовольствием подключусь.

***************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2023 DEVELOPER. Больше статей можно прочитать здесь.

В 2023 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2023 в Москве.

Выбрать мероприятие.

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

В UML 2.2 существует 14 типов диаграмм UML, которые делятся на две категории:

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

Эти диаграммы можно классифицировать иерархически, как показано на следующей карте диаграммы UML:

Вопрос: UML огромен и сложен?

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

• Каждая диаграмма UML из 14 типов диаграмм UML предоставляет большой набор конструкций и обозначений, которые охватывают различные потребности для большинства проектов разработки программного обеспечения.
• Спецификация UML насчитывает более 700 страниц и явно считается слишком сложной и отрицательно влияет на восприятие и принятие UML.
• Как правило, пользователи склонны рассматривать и использовать только часть своих диаграмм/конструкций UML.

Ответ: изучите наиболее важные диаграммы и нотации UML.

Грэди Буч, один из самых важных разработчиков унифицированного языка моделирования, заявил, что «для 80% всего программного обеспечения требуется только 20% UML».

Что такое состояния UML Survey*?

Мы могли бы интерпретировать результаты опроса UML, предположив, что если диаграмма

• широко используется, если он ≥ 60% источников
• редко используется, если он составляет ≤ 40% источников

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

Например, диаграмма классов является наиболее широко используемой, поэтому она будет обсуждаться первой в этом разделе и так далее…

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

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

Назначение диаграмм классов

1. Показывает статическую структуру классификаторов в системе
2. Диаграмма обеспечивает базовую нотацию для других структурных диаграмм, предписанных UML.
3. Полезно для разработчиков и других членов команды.
4. Бизнес-аналитики могут использовать диаграммы классов для моделирования систем с точки зрения бизнеса.

Диаграмма классов UML состоит из:

• Набор классов и
• Набор отношений между классами

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

Диаграмма классов может также иметь примечания, прикрепленные к классам или отношениям. Примечания отображаются серым цветом.

В приведенном выше примере:

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

1. Форма — это абстрактный класс. Он показан курсивом.
2. Форма — это суперкласс. Круг, прямоугольник и многоугольник являются производными от формы. Другими словами, Круг — это Форма. Это отношение обобщения/наследования.
3. Существует связь между DialogBox и DataController.
4. Форма является частью окна. Это отношения агрегации. Shape может существовать без Window.
5. Точка является частью Круга. Это композиционные отношения. Точка не может существовать без Окружности.
6. Окно зависит от события. Однако Event не зависит от Window.
7. Атрибутами Circle являются радиус и центр. Это класс сущности.
8. Имена методов Circle: area(),circ(), setCenter() и setRadius().
9. Радиус параметра в Circle является параметром in типа float.
10. Метод area() класса Circle возвращает значение типа double.
11. Атрибуты и имена методов Rectangle скрыты. У некоторых других классов на диаграмме также скрыты атрибуты и имена методов.

Вторым по популярности типом диаграмм в UML является диаграмма деятельности:

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

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

Когда использовать диаграмму деятельности

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

1. Выявление возможных вариантов использования путем изучения бизнес-процессов
2. Определите предварительные и последующие условия (контекст) для вариантов использования.
3. Моделирование рабочих процессов между/внутри вариантов использования
4. Моделирование сложных рабочих процессов в операциях над объектами
5. Подробное моделирование сложных действий на высокоуровневой диаграмме действий

Диаграмма активности — учитесь на примерах

Базовая диаграмма деятельности — блок-схема вроде

Пример диаграммы действий — технологический заказ

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

Технологический заказ — описание проблемы

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

На стороне Fill Order способ доставки определяется условно. В зависимости от условия выполняется операция «Ночная доставка» или «Обычная доставка».

Наконец, параллельные действия объединяются, чтобы закрыть заказ.

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

Третьим наиболее широко используемым типом диаграммы UML является диаграмма последовательности:

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

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

Пример диаграммы последовательности действий: гостиничная система

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

Ниже представлена ​​схема последовательности действий при бронировании отеля. Объектом, инициирующим последовательность сообщений, является окно резервирования.

Обратите внимание: диаграммы классов и объектов представляют собой представления статической модели. Диаграммы взаимодействия являются динамическими. Они описывают, как объекты взаимодействуют.

Четвертыми наиболее широко используемыми типами диаграмм UML (96%) являются:

• диаграмма вариантов использования
• диаграмма конечного автомата

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

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

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

Краткий обзор диаграммы вариантов использования

Стандартная форма диаграммы вариантов использования определена в унифицированном языке моделирования, как показано в примере диаграммы вариантов использования ниже:

Диаграмма вариантов использования — Системы продажи автомобилей

На рисунке ниже показан пример схемы вариантов использования для автомобильной системы. Как видите, даже такая большая система, как система продажи автомобилей, содержит не более 10 вариантов использования! В этом прелесть моделирования вариантов использования.

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

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

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

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

Обозначение простой диаграммы состояний

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

Пример подсостояния — обогреватель

История государств

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

Согласно опросу, использование Communication Diagram составляет 82%:

Диаграмма связи

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

Диаграмма связи с первого взгляда

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

• Объектами являются Объект1, Объект2, Объект…, ОбъектN-1… и ОбъектN.
• Сообщения, передаваемые между объектами, представлены помеченными стрелками, которые начинаются с объекта-отправителя (актора) и заканчиваются объектом-получателем.
• Примеры сообщений, передаваемых между объектами, помечаются 1: сообщение1, 2: сообщение2, 3: сообщение3 и т. д., где числовой префикс имени сообщения указывает его порядок в последовательности.
• Сначала Объект1 отправляет Объекту2 сообщение message1, Объект2, в свою очередь, отправляет ОбъектуN-1 сообщение message2 и так далее.
• Сообщения, которые объекты отправляют сами себе, обозначаются как циклы (например, сообщение message5).

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

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

Из двух типов диаграмм взаимодействия диаграммы последовательности используются гораздо чаще, чем диаграммы связи. Итак, зачем вам использовать диаграммы связи? Прежде всего, они очень полезны для визуализации отношений между объектами, взаимодействующими для выполнения конкретной задачи. Это трудно определить по диаграмме последовательности. Кроме того, диаграммы связи также могут помочь вам определить точность вашей статической модели (например, диаграммы классов).

Использование диаграммы компонентов и диаграммы развертывания составляет 80%:

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

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

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

Краткий обзор схемы компонентов

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

Схема развертывания

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

Краткий обзор схемы развертывания

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

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

Узлы

• Трехмерный блок представляет собой узел, программный или аппаратный.
• Узел HW может быть обозначен <<стереотипом>>
• Соединения между узлами представлены линией с необязательным <<стереотипом>>.
• Узлы могут находиться внутри узла

Другие обозначения

• Зависимость
• Ассоциативные отношения.
• Может также содержать примечания и ограничения.

Согласно опросу, использование диаграммы объектов UML составляет 71%:

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

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

Диаграмма объекта с первого взгляда

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

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

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

Пример диаграммы класса к объекту — система заказов

Использование диаграммы пакета составляет 70%:

Схема пакета

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

Краткий обзор схемы упаковки

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

На диаграмме ниже представлена ​​бизнес-модель, в которой классы сгруппированы в пакеты:

• Пакеты отображаются в виде прямоугольников с небольшими вкладками вверху.
• Имя пакета находится на вкладке или внутри прямоугольника.
• Пунктирные стрелки — зависимости.
• Один пакет зависит от другого, если изменения в другом могут вызвать изменения в первом.

Использование диаграммы составной структуры составляет 52%:

Схема составной структуры

Composite Structure Diagram — один из новых артефактов, добавленных в UML 2.0. Составная структурная диаграмма — это структурная диаграмма UML, содержащая классы, интерфейсы, пакеты и их взаимосвязи и обеспечивающая логическое представление всей программной системы или ее части. Он показывает внутреннюю структуру (включая части и соединители) структурированного классификатора или сотрудничества.

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

Краткий обзор диаграммы составной структуры

• Диаграммы составной структуры показывают внутренние части класса.
• Части имеют имена: partName:partType[множественность]
• Агрегированные классы являются частями класса, но части не обязательно являются классами, часть — это любой элемент, который используется для создания содержащего класса.

Временная диаграмма используется только на 40% и редко используется обычными пользователями.

Временная диаграмма

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

Краткий обзор временной диаграммы

Представление временной шкалы состояния

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

Жизненная линия ценности Представление

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

Интерактивная обзорная диаграмма — это новая диаграмма, добавленная в UML 2.0:

Интерактивная обзорная диаграмма

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

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

Краткий обзор диаграммы взаимодействия

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

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

Диаграмма UML с наименьшим использованием — это диаграмма профиля, она набрала всего 11%:

Диаграмма профиля

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

Диаграмма профиля, своего рода структурная диаграмма в унифицированном языке моделирования (UML), предоставляет общий механизм расширения для настройки моделей UML для определенных доменов и платформ. Механизмы расширения позволяют уточнять стандартную семантику строго аддитивным образом, предотвращая ее противоречие со стандартной семантикой. Профили определяются с использованием  стереотипов ,  определений теговых значений и  ограничений  , которые применяются к определенным элементам модели, таким как классы, атрибуты, операции и действия. Профиль — это набор таких расширений, которые совместно настраивают UML для конкретной области (например, аэрокосмической, медицинской, финансовой) или платформы (J2EE, .NET).

Пример диаграммы профиля — управление ИТ

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

Ищете бесплатный онлайн-инструмент для разработки программного обеспечения?

Вот репозиторий Visual Paradigm Online для примеров дизайна программного обеспечения, это:

• Бесплатно (для личных и некоммерческих целей)
• Онлайн (нулевая установка и настройка)
• Поддержка Google Диска и бесплатного облачного хранилища
• Много примеров
• Используйте его в любое время и в любом месте! нужен только веб-браузер

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

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

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

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

Схема развертывания

Схема пакета

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

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

ER-диаграмма

Диаграмма потока данных

Диаграмма устойчивости

Предприятие Интерн. Ptrns

Диаграмма требований

Диаграмма определения блока

Параметрическая диаграмма

Внутренняя блок-схема

Диаграмма Гейна Сарсона

Йордон и Коуд

Юрдон ДеМарко DFD

ССДМ ДФД