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 и другие.
- 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 участника: студент и библиотекарь. Прецеденты для студента: ищет в каталоге, заказывает, работает в читальном зале. Роль библиотекаря: выдача заказа, консультации (рекомендации книг по теме, обучение использованию поисковой системы и заполнению бланков заказа).
Второй пример немного сложнее. Видим, что одно и то же лицо может выступать в нескольких ролях. Например, product manager у нас работает над стратегией и больше ничем не занимается, архитектор работает над стратегией и занимается внедрением, build master занимается тремя вещами одновременно, и так далее. По такой схеме мы можем проследить, какая из ролей связана с какими прецедентами.
Диаграмма классов — Class diagram
Класс (class) — категория вещей, которые имеют общие атрибуты и операции. Сама диаграмма классов являет собой набор статических, декларативных элементов модели. Она дает нам наиболее полное и развернутое представление о связях в программном коде, функциональности и информации об отдельных классах. Приложения генерируются зачастую именно с диаграммы классов. Рассмотрим на простом примере ниже:
Для класса «студент» есть таблица, содержащая атрибуты: имя, адрес, телефон, e-mail, номер зачетки, средняя успеваемость. И также показаны связи данной сущности с другими: прохождением курса, какой курс слушает, кто профессор. В этом примере также добавляются функции, которые могут быть применены к сущности «студент».
Диаграмма активностей — Activity diagram
Тоже крутая штука, которая очень часто используется на практике. Диаграмма активностей описывает динамические аспекты поведения системы в виде блок-схемы, которая отражает бизнес-процессы, логику процедур и потоки работ — переходы от одной деятельности к другой. По сути, мы рисуем алгоритм действий (логику поведения) системы или взаимодействия нескольких систем. Ниже — пример подобной диаграммы для интернет-магазина.
Диаграмма активностей для сайта магазина максимально доступно объясняет, какие есть интеграции в системе. Актер (в нашем случае — покупатель), зашедший на сайт, делает заказ. Далее у нас происходит разветвление: проверяем, является ли пользователь оптовиком (Да/Нет). Если он не зарегистрирован в системе и не оптовик, заказ отправляется в retailCRM. Если пользователь зарегистрирован, его заказ попадает в Navision. При этом между retailCRM и Navision происходит синхронизация остатка и статусов.
Эту базовую диаграмму мы можем дополнить, расширить, она может выступить частью документации и дает общее представление о работе системы.
Диаграмма последовательности — Sequence Diagram
Используется для уточнения диаграмм прецедентов — описывает поведенческие аспекты системы. Диаграмма последовательности отражает взаимодействие объектов в динамике, во времени. При этом информация принимает вид сообщений, а взаимодействие объектов подразумевает обмен этими сообщениями в рамках сценария.
Диаграмма развертывания — Deployment Diagram
Диаграмма развертывания отображает графическое представление инфраструктуры, на которую будет развернуто приложение: топологию системы и распределение компонентов по ее узлам, а также соединения — маршруты передачи данных между узлами. Диаграмма помогает более рационально организовать компоненты, от чего зависит в числе прочего и производительность системы, а также решить вспомогательные задачи, например, связанные с безопасностью.
Заключение
Как видим, на первый взгляд банальный набор фигур и стрелок может значительно упростить решение сложных задач в программировании, помочь при выборе оптимального решения и разработке технической документации. Какие еще выводы можем сделать:
- строить диаграммы несложно;
- диаграммы очень легко читаемы и просты для понимания;
- они — отличный инструмент для проектирования архитектуры и поведения;
- необходимы для документирования любой нетривиальной системы. Позволяют легко понять связи между модулями и интеграциями в системе.
Остались вопросы, хотите обсудить с нами ваш проект или заказать разработку? Пишите!
Моделирование бизнеса — IDEF, UML, ARIS
Статья написана на основе лекций «Моделирование и анализ бизнес-процессов» профессора Томского государственного университета систем управления и радиоэлектроники, Силич Марии Петровны.
Классификация моделей
Понятие модели
Модель представляет искусственный, созданный человеком объект любой природы (умозрительный или материально реализованный), который замещает или воспроизводит исследуемый объект.
Процесс построения, изучения и применения моделей называется моделированием.
Модель — упрощенный, приближенный образ, который отражает наиболее существенные (с точки зрения цели моделирования) свойства оригинала.
Соответствие модели оригиналу называется адекватностью модели.
Адекватность включает требования полноты и точности (правильности). Требования должны выполняться в той мере, которая достаточна для достижения цели.
Для одного и того же объекта может быть построено множество различных моделей, отвечающих различным целям.
Модель внешнего вида часов
Структурная схема часов
Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).
Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.
Классификация моделей
Познавательные (объяснительные) модели отражают уже существующие объекты.
Нормативные (прагматические) модели отражают объекты, которые должны быть осуществлены.
Градации нормативных моделей: от референтной (для целого класса объектов) до модели конкретного объекта.
Статические модели не учитывают временной фактор.
Динамические модели отражают изменения объекта, происходящие с течением времени. Динамическая модель сама может быть статична или находиться в динамике (имитационная модель).
Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.
Декларативные модели отражают свойства, структуры, состояния объектов.
Процедурные модели отражают процедурное, операционное знание.
Детерминированные модели отражают процессы и явления, не подверженные случайностям.
Стохастические – отражают случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями.
Формализованные модели могут не иметь смысловой интерпретации.
В содержательных моделях сохраняется семантика моделируемого объекта.
Языки описания моделей
Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.
Графические модели (схемы, диаграммы, графики, чертежи) – наглядны.
Нотация — система условных обозначений (знаков) и правил их использования, принятая в конкретной методологии.
Требования к нотации:
- простота — простой знак предпочтительнее сложного;
- наглядность — хотя бы отдаленное сходство с оригиналом;
- индивидуальность — достаточное отличие от других обозначений;
- однозначность — нельзя обозначать одним символом различные объекты;
- определенность — четкие правила использования модели;
- учет устоявшихся традиций.
В модели бизнеса отражают:
- функции, которые бизнес-система должна выполнять — что она делает, для кого, с какой целью;
- процессы, последовательность отдельных шагов процессов (работ, операций);
- организационные структуры, обеспечивающие выполнение процессов;
- материальные и информационные потоки, возникающие в ходе выполнения процессов;
- данные, необходимые при выполнении процессов, и отношения между этими данными.
Методы моделирования бизнеса
Структурные методы
Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.
Принципы структурного подхода:
- «разделяй и властвуй» — разбиение сложных проблем на множество меньших задач, легких для понимания и решения;
- иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры.
Две группы методов: моделирующие функциональную структуру и структуру данных
Наибольшее распространение получили методологии:
- 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
Правила создания перекрестков
- Каждому перекрестку слияния должен предшествовать перекресток ветвления.
- Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
- Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
- Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
- Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.
Правило относительно единиц работ
В блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки.
Разрешается множественная декомпозиция работ:
для одной и той же работы может быть создано несколько диаграмм декомпозиции (для описания разных вариантов реализации работы).
Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.
Методология DFD
Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона
Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия), которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные
2. Потоки данных, которые обозначают взаимодействие процессов с внешним миром и между собой. Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта).
3. Хранилища данных — представляют собой собственно данные, к которым осуществляется доступ. Эти данные могут быть созданы или изменены процессами.
4. Внешние сущности — определяют внешние элементы, которые участвуют в процессе обмена информацией с системой. Внешние сущности изображают входы в систему (источники информации) и/или выходы из системы (приемники информации). Примеры: заказчик, персонал, поставщик, клиент, склад, банк
Пример:
Объектно-ориентированный язык UML
Язык 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
Статья про основы применения UML будет полезна начинающим аналитикам, а также разработчикам, тестировщикам, менеджерам продуктов, архитекторам и техническим писателям, которые хотят начать использовать UML-диаграммы в своей работе или структурировать знания об их применении.
Обратите внимание: в этой статье не разбираются правила нотации, значения элементов и способы построения конкретных видов диаграмм. Зато в ответах на вопросы мы обсуждаем практические аспекты применения UML в работе.
Время на чтение статьи: 17 минут
Не любите читать? Посмотрите видео.
Оглавление
- Определение
- История возникновения UML
- Классификация UML диаграмм
- UML для Заказчика
- UML для Аналитика
- UML для Архитектора
- UML для Разработчика
- UML c позиции Тестировщика
- UML для Технического писателя
- Какие задачи на UML встречаются на собеседованиях?
- Правда ли, что UML используют только в больших компаниях?
- Обязательно ли знать программирование для работы с UML?
- На каких практических кейсах можно потренироваться в UML?
- Можно ли моделировать сложную логику UML в MS Visio?
- Как быстро освоить Enterprise Architect?
- Зачем нужна диаграмма классов, если есть ER-диаграмма?
- Как связаны UML и BPMN?
Что такое UML
Определение
UML (Unified Modeling Language, Унифицированный Язык Моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, который также можно применять для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
Давайте подробнее разберём аббревиатуру UML:
- U — Unified (Унифицированный). Большой набор элементов, входящих в нотацию, позволяет покрывать много задач на этапе анализа и проектирования. Ещё одна версия происхождения этого слова кроется в том, что нотация объединила в себе несколько разнородных нотаций, существовавших ранее.
- M — Modeling (Моделирование). Создание диаграмм заключается в разработке моделей, содержащих наполненные информацией и связанные между собой графические объекты.
- L — Language (Язык). UML является искусственным языком и обладает свойствами языка: имеет словарь (графические символы), семантику (смысловые значения элементов) и синтаксис (правила построения конструкций). В нотацию также заложена возможность генерации кода из графической модели и генерация моделей из кода.
История возникновения UML
UML является далеко не первой нотацией моделирования. Графически описывать системы при проектировании и разработке стали давно. В какой-то момент появилась необходимость в том, чтобы использовать при моделировании единые правила, понятные всем.
В основу нотации легли наработки многих специалистов в области программной инженерии, но наиболее весомый вклад внесли Грейди Буч (Grady Booch), Айвар Джейкобсон (Ivar Jacobson) и Джеймс Рамбо (James Rumbaugh). UML вобрала в себя особенности их нотаций моделирования — Booch, OOSE (Object Oriented Software Engineering) и OMT (Object Modeling Technique) соответственно.
Рис. 1 — История возникновения нотации UML
Язык постоянно развивается, появляются новые элементы для моделирования более сложных систем. Актуальная сейчас версия нотации — UML 2.5.1; новости и рекомендации можно найти на официальном сайте UML.org.
Классификация UML диаграмм
Нотация известна тем, что в неё входит много различных видов диаграмм:
Рис. 2 — Классификация диаграмм нотации UML
Структурные диаграммы UML. Описывают систему статически
Диаграмма;Описание
Диаграмма классов (Class Diagram);Описывает систему в виде набора классов со свойствами, доступными методами и взаимосвязями между классами. Диаграмма объектов (Object Diagram);Является экземпляром диаграммы классов и показывает конкретные значения свойств классов. Диаграмма пакетов (Package Diagram);Описывает взаимосвязи пакетов. Пакет — группа классов, объединенных для упрощения сложной диаграммы классов. Диаграмма компонент (Component Diagram);Описывает архитектуру компонентов (сервисы, интерфейсы, приложения и т.д.) и зависимости между ними. Диаграмма развертывания (Deployment Diagram);Описывает архитектуру системы с точки зрения ее развертывания на физическом уровне. Диаграмма профилей (Profile Diagram);Описывает пользовательские стереотипы и ограничения, применяемые к моделям. Диаграмма композитной структуры (Composite Structure Diagram);Описывает внутреннюю структуру классов и взаимодействие элементов класса между собой.
Диаграммы поведения UML. Описывают систему динамически
Диаграмма;Описание
Диаграмма прецедентов (Use Case Diagram). Употребляется также термин «Диаграмма вариантов использования»;Описывает набор функциональности (прецедент), доступной акторам (внешним для системы сущностям, например, пользователям). Диаграмма деятельности (Activity Diagram);Описывает рабочий процесс внутри каждого прецедента. Диаграмма состояний (State Machine Diagram);Описывает состояния, в которых может находиться каждый объект, и правила перехода из одного состояния в другое. Диаграммы взаимодействия; Диаграмма последовательности (Sequence Diagram);Описывает логику взаимодействия и обмена данными между объектами в рамках прецедента в хронологическом порядке. Диаграмма коммуникации (Communication Diagram);Описывает логику взаимодействия и обмена данными между объектами в рамках прецедента. Схожа с sequence diagram, но без раскрытия хронологического порядка. Диаграмма синхронизации (Timing Diagram);Описывает как объекты ведут себя на временной шкале без отображения взаимосвязей между объектами. Диаграмма обзора взаимодействия (Interaction Overview Diagram);Описывает процесс взаимодействия объектов. Похожа на activity diagram, но более высокоуровневую, где каждый узел — другая диаграмма взаимодействия.
С детальным описанием всех элементов нотации и правил их использования можно ознакомиться в официальной документации.
Применение UML к разным задачам
Почти любые задачи описания и проектирования при разработке можно решить с помощью UML. Примеры таких задач перечислены в таблице.
Задача;Диаграммы
На графике ниже приведена статистика упоминания различных видов диаграмм (информация взята из мета-анализа встречаемости UML в статьях и исследованиях по ИТ-дисциплинам за 2021 год, числа указывают абсолютное количество публикаций). В рабочей практике статистика применимости похожая.
- Class Diagram
- Activity Diagram
- Sequence Diagram
- Use Case Diagram
Методы и средства моделирования бизнес-процессов
В современной практике моделирования управленческой и производственной деятельности для обозначения объектов моделирования принято использовать термин «бизнес-процесс» (business-process) [Репин-04]. В международном стандарте ISO 9000:2000 принят термин «процесс», однако в настоящее время эти термины можно считать синонимами.
- отсутствие заинтересованности со стороны высшего руководства организации;
- некорректная постановка целей проекта;
- недостаточная информированность персонала организации относительно целей и результатов проекта;
- непонимание сути и реальных возможностей используемых методов моделирования;
- отсутствие корпоративных стандартов описания и регламентации бизнес-процессов;
- неэффективное применение инструментов моделирования.
По оценкам, приведенным в [Репин-04], типовой сценарий развития событий в большинстве российских организаций заключается в следующем: ставятся «правильные» цели, инициируется проект, создается описание бизнеспроцессов, осуществляются попытки проанализировать их и приступить к реорганизации. Именно на последнем этапе, когда необходимо получить определенные результаты, большинство организаций испытывает значительные трудности. Не получив быстрых, измеримых результатов, предвидя длительную и кропотливую работу, руководство организации сворачивает работы по проекту, и начинается поиск очередных «модных» подходов к управлению.
Сложившаяся ситуация еще более усугубляется следующими обстоятельствами:
- организации сталкиваются с проблемой выбора адекватных методов и инструментов моделирования, которая порождается их разнообразием и отсутствием единых стандартов;
- существующие методы и средства используют различные языки моделирования, терминологию, плохо совместимы друг с другом, дорогостоящи и трудоемки в использовании.
Эти обстоятельства обуславливают многочисленные проекты, предпринимаемые в настоящее время, целью которых является интеграция существующих методов и языков моделирования и создание единого методического и технологического базиса моделирования бизнеспроцессов, а в более широком контексте – моделирования архитектуры предприятий (enterprise modeling) [BPMN-03, UEML-02, BPDM-03].
2. Основные понятия
Бизнес-процесс определяется как логически завершенный набор взаимосвязанных и взаимодействующих видов деятельности, поддерживающий деятельность организации и реализующий ее политику, направленную на достижение поставленных целей. Стандарт ISO 9000:2000 определяет процесс как совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы, представляющие ценность для потребителя. В этом определении под процессом можно понимать любую деятельность, использующую определенные ресурсы (финансовые, материальные, человеческие, информационные) для преобразования входных элементов в выходные. Процесс включает одну или более связанных между собой процедур или функций, которые совместно реализуют некоторую задачу (обычно в рамках организационной структуры). Он может выполняться в пределах одной организационной единицы, охватывать несколько единиц или даже несколько различных организаций.
Авторы
Другие статьи автора
Поделиться
Важным шагом структуризации деятельности любой организации являются выделение и классификация бизнес-процессов.
По отношению к получению добавленной ценности продукта или услуги можно выделить следующие классы процессов:
- основные процессы;
- обеспечивающие процессы.
Основными бизнес-процессами являются процессы, добавляющие ценность. Они ориентированы на производство товаров или оказание услуг, составляющих основную деятельность организации и обеспечивающих получение дохода. Примерами таких процессов на предприятии являются процессы маркетинга, производства, поставки и сервисного обслуживания продукции.
Обеспечивающие бизнес-процессы не добавляют ценность продукта или услуги для потребителя, но увеличивают их стоимость. Они необходимы для деятельности предприятия и предназначены для поддержки выполнения основных бизнес-процессов. Такими процессами являются финансовое обеспечения деятельности, обеспечение кадрами, юридическое обеспечение, администрирование, обеспечение безопасности, поставка комплектующих материалов, ремонт и техническое обслуживание и т.д.
Бизнес-процессы можно также классифицировать по видам деятельности или составу работ (элементам процесса) [Репин-04]:
- планирование деятельности (например, планирование производства готовой продукции);
- осуществление деятельности – собственно выполнение работы (например, изготовление продукции);
- регистрация фактической информации по выполнению процесса (производственный, управленческий и бухгалтерский учет);
- контроль и анализ исполнения плана;
- принятие управленческих решений. Эти процессы охватывают весь комплекс функций управления на уровне каждого бизнеспроцесса и системы в целом. Примерами таких процессов могут быть процессы стратегического, оперативного и текущего планирования, процессы формирования и выполнения управляющих воздействий. Процессы управления оказывают воздействие на все остальные процессы организации.
Бизнес-модель – это формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов, отражающее реально существующую или предполагаемую деятельность предприятия.
В простейшем случае бизнес-модель может состоять из единственной диаграммы, однако на практике это вряд ли допустимо, поскольку бизнес-процессы, как правило, слишком сложны и многоаспектны. Модель таких про цессов включает следующие компоненты [Eriksson-2000]:
- Представления. Каждое представление отражает определенный аспект бизнес-процессов. Представление – это абстракция, отражающая конкретную точку зрения и скрывающая детали, несущественные для данной точки зрения.
- Диаграммы. Каждое представление состоит из ряда диаграмм различных типов, отражающих структурные и динамические аспекты бизнес-процессов.
- Объекты и процессы. Объекты представляют ресурсы, используемые в процессах (финансовые, материальные, человеческие, информационные).
Цели моделирования бизнес-процессов обычно формулируются следующим образом:
- обеспечить понимание структуры организации и динамики происходящих в ней процессов;
- обеспечить понимание текущих проблем организации и возможностей их решения;
- убедиться, что заказчики, пользователи и разработчики одинаково понимают цели и задачи организации;
- создать базу для формирования требований к ПО, автоматизирующему бизнес-процессы организации.
Основная область применения бизнес-моделей – это реинжиниринг бизнес-процессов. При этом предполагается построение моделей текущей и перспективной деятельности, а также плана и программы перехода из первого состояния во второе.
Любое современное предприятие является сложной системой, его деятельность включает в себя исполнение десятков тысяч взаимовлияющих функций и операций. Человек не в состоянии понимать, как такая система функционирует в деталях – это выходит за границы его возможностей. Поэтому главная идея создания так называемых моделей «AS-IS» (как есть) и «AS-TO-BE» (как должно быть) – понять, что делает (будет делать) рассматриваемое предприятие и как оно функционирует (будет функционировать) для достижения своих целей.
Назначением будущих систем ПО является, в первую очередь, решение проблем бизнеса посредством современных информационных технологий. Требования к ПО формируются на основе бизнес-модели, а критерии проектирования систем прежде всего основываются на наиболее полном их удовлетворении.
Следует отметить, что модели бизнес-процессов являются не просто промежуточным результатом, используемым консультантом для выработки каких-либо рекомендаций и заключений. Они представляют собой самостоятельный результат, имеющий большое практическое значение, которое следует из целей их построения.
Модель бизнес-процесса должна давать ответы на вопросы:
1. Какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата?
2. В какой последовательности выполняются эти процедуры?
3. Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса?
4. Кто выполняет процедуры процесса?
5. Какие входящие документы/информацию использует каждая процедура процесса?
6. Какие исходящие документы/информацию генерирует процедура процесса?
7. Какие ресурсы необходимы для выполне ния каждой процедуры процесса?
8. Какая документация/условия регламенти рует выполнение процедуры?
9. Какие параметры характеризуют выполне ние процедур и процесса в целом?
Важным элементом модели бизнес-про цессов являются бизнес-правила или правила предметной области. Типичными бизнес-правилами являются корпоративная политика и государственные законы. Бизнес-правила обычно формулируются в специальном документе и могут отражаться в моделях. Для организации бизнес-правил предлагается множество различных схем классификации. Наиболее полной можно считать следующую классификацию бизнесправил (в скобках приведены примеры правил для гипотетической системы обработки заказов в торговой компании):
- Факты – достоверные утверждения о бизнес-процессах, называемые также инвариантами (оплачивается доставка каждого заказа; со стоимости доставки налог с продаж не берется).
- Правила-ограничения – определяют различные ограничения на выполняемые операции:
- Управляющие воздействия и реакции на воздействия (когда заказ отменен и еще не доставлен, то его обработка завершается).
- Операционные ограничения – предусловия и постусловия (доставить заказ клиен ту только при наличии адреса доставки).
- Структурные ограничения (заказ включает по крайней мере один продукт).
- Активаторы операций – правила, при определенных условиях приводящие к выполнению каких-либо действий (если срок хранения товара на складе истек, об этом надо уведомить ответственное лицо).
- Правила вывода:
- Правила-следствия – правила, устанавли вающие новые факты на основе достоверности определенных условий (клиент получает положительный статус только при условии оплаты счетов в течение 30 дней).
- Вычислительные правила – различные вычисления, выполняемые с использованием математических формул и алгоритмов (цена нетто = цена продукта * (1 + процент налога / 100)).
Для моделирования бизнес-процессов необходимо использовать определенную методику, которая включает:
- описание методов моделирования – способов представления реальных объектов предприятия при помощи объектов модели;
- процедуру – последовательность шагов по сбору информации, ее обработке и представлению в виде моделей (диаграмм и документов).
Методика может существовать как самостоятельный продукт (например, метод EricssonPenker [Eriksson-2000]) или входить в состав комплексной технологии создания ПО (например, метод моделирования бизнес-процессов в технологии Rational Unified Process).
3. Методы моделирования бизнес-процессов
Для моделирования бизнес-процессов используется несколько различных методов, основой которых являются как структурный, так и объектно-ориентированный подходы к моделированию. Однако деление самих методов на структурные и объектные является достаточно условным, поскольку наиболее развитые методы используют элементы обоих подходов. К числу наиболее распространенных методов относятся:
- метод функционального моделирования SADT (IDEF0);
- метод моделирования процессов IDEF3;
- моделирование потоков данных DFD;
- метод ARIS;
- метод Ericsson-Penker;
- метод моделирования, используемый в технологии Rational Unified Process.
3.1. Метод функционального моделирования SADT (IDEF0)
Метод SADT (Structured Analysis and Design Technique) [Марка-93, Черемных-01, Репин-04] считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором в принципе руководству и так известно, иначе оно бы не инициировало соответствующие работы), на ее основе можно только внести предложения об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.
В соответствии с этим принципом бизнесмодель должна выглядеть следующим образом:
1. Верхний уровень модели должен отражать только контекст системы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.
2. На втором уровне модели должны быть отражены основные виды деятельности (тематически сгруппированные бизнес-процессы) предприятия и их взаимосвязи. В случае большого их количества некоторые из них можно вынести на третий уровень модели. Но в любом случае под виды деятельности необходимо отводить не более двух уровней модели.
3. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций – совокупностей операций, сгруппированных по определенным признакам. Бизнес-функции детализируются с помощью элементарных бизнес-операций.
4. Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения.
Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности.
Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном из стандартов этого семейства – IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com. Существует также российская версия данного стандарта [РД-2000]. Вместе со стандартом IDEF0 обычно используются стандарт моделирования процессов IDEF3 и стандарт моделирования данных IDEF1Х.
Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:
- Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют когда и каким образом функции выполняются и управляются.
- Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков – ограничение мощности краткосрочной памяти человека), связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтаксические правила для графики (блоков и дуг), разделение входов и управлений (правило определения роли данных).
- Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель.
Метод SADT может использоваться для моделирования самых разнообразных процессов и систем. В существующих системах метод SADT может быть использован для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются.
3.1.1. Состав функциональной модели
Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 1).
Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
На рис. 2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADTмодели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме.
Построение SADT-модели заключается в выполнении следующих действий:
- сбор информации об объекте, определение его границ;
- определение цели и точки зрения модели;
- построение, обобщение и декомпозиция диаграмм;
- критическая оценка, рецензирование и комментирование.
Построение диаграмм начинается с представления всей системы в виде простейшего компонента – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок отражает систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они также соответствуют полному набору внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки определяют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых показана как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом в целях большей детализации.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д.
3.1.2. Стратегии декомпозиции
При построении иерархии диаграмм используются следующие стратегии декомпозиции:
- Функциональная декомпозиция – декомпозиция в соответствии с функциями, которые выполняют люди или организация. Может оказаться полезной стратегией для создания системы описаний, фиксирующей взаимодействие между людьми в процессеих работы. Очень часто, однако, взаимосвязи между функциями весьма многочисленны и сложны, поэтому рекомендуется использовать эту стратегию только в начале работы над моделью системы.
- Декомпозиция в соответствии с известными стабильными подсистемами – приводит к созданию набора моделей, по одной модели на каждую подсистему или важный компонент. Затем для описания всей системы должна быть построена составная модель, объединяющая все отдельные модели. Рекомендуется использовать разложение на подсистемы, только когда разделение на основные части системы не меняется. Нестабильность границ подсистем быстро обесценит как отдельные модели, так и их объединение.
- Декомпозиция по физическому процессу – выделение функциональных стадий, этапов завершения или шагов выполнения. Хотя эта стратегия полезна при описании существующих процессов (таких, например, как работа промышленного предприятия), результатом ее часто может стать слишком последовательное описание системы, которое не будет в полной мере учитывать ограничения, диктуемые функциями друг другу. При этом может оказаться скрытой последовательность управления. Эта стратегия рекомендуется только если целью модели является описание физического процесса как такового или только в крайнем случае, когда неясно, как действовать.
Одна из наиболее частых проблем, возникающих в процессе построения SADT-моделей, – когда же следует завершить построение конкретной модели? На этот вопрос не всегда легко ответить, хотя существуют некоторые эвристики для определения разумной степени полноты. Здесь представлены правила, которыми пользуются опытные аналитики для определения момента завершения моделирования. Они носят характер рекомендаций. Только длительная практика позволит приобрести знания, необходимые для принятия правильного решения об окончании моделирования.
Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Опыт показал, что для отдельной модели, которая создается независимо от какой-либо другой модели, декомпозиция одного из ее блоков должна прекращаться, если:
- Блок содержит достаточно деталей. Одна из типичных ситуаций, встречающихся в конце моделирования – это блок, который описывает систему с нужным уровнем подробности. Проверить достаточность деталей обычно совсем легко, необходимо просто спросить себя, отвечает ли блок на все или на часть вопросов, составляющих цель модели. Если блок помогает ответить на один или более вопросов, то дальнейшая декомпозиция может не понадобиться.
- Необходимо изменить уровень абстракции, чтобы достичь большей детализации, блока. Блоки подвергаются декомпозиции, если они недостаточно детализированы для удовлетворения цели модели. Но иногда при декомпозиции блока выясняется, что диаграмма начинает описывать, как функционирует блок, вместо описания того, что блок делает. В этом случае происходит изменение уровня абстракции – изменение сути того, что должна представлять модель (т.е. изменение способа описания системы). В SADT изменение уровня абстракции часто означает выход за пределы цели модели и, следовательно, это указывает на прекращение декомпозиции.
- Необходимо изменить точку зрения, чтобы детализировать блок. Изменение точки зрения происходит примерно так же, как изменение уровня абстракции. Это чаще всего характерно для ситуаций, когда точку зрения модели нельзя использовать для декомпозиции конкретного блока, т. е. этот блок можно декомпозировать, только если посмотреть на него с другой позиции. Об этом может свидетельствовать заметное изменение терминологии.
- Блок очень похож на другой блок той же модели или на блок другой модели. Иногда встречается блок, чрезвычайно похожий на другой блок модели. Два блока похожи, если они выполняют примерно одну и ту же функцию и имеют почти одинаковые по типу и количеству входы, управления и выходы. Если второй блок уже декомпозирован, то разумно отложить декомпозицию и тщательно сравнить два блока. Если нужны ничтожные изменения для совпадения первого блока со вторым, то внесение этих изменений сократит усилия на декомпозицию и улучшит модульность модели (т.е. сходные функции уточняются согласованным образом).
- Блок представляет тривиальную функцию. Тривиальная функция – это такая функция, понимание которой не требует никаких объ-яснений. В этом случае очевидна целесообразность отказа от декомпозиции, потому что роль SADT заключается в превращении сложного вопроса в понятный, а не в педантичной разработке очевидных деталей. В таких случаях декомпозиция определенных блоков может принести больше вреда, чем пользы. Тривиальные функции лучше всего описываются небольшим объемом текста. Следует заметить, что «тривиальный» не означает «бесполезный». Тривиальные функции выполняют очень важную роль, поясняя работу более сложных функций, а иногда и соединяя вместе основные подсистемы. Поэтому при анализе не следует пропускать тривиальные функции. Наоборот, их существование должно быть зафиксировано и они должны быть детализированы, как и любые другие функции. Однако следует предостеречь от больших затрат времени на анализ тривиальных функций системы. Усиленное внимание к мелочам может привести к созданию модели, которой будет недоставать абстракции, что сделает ее трудной для понимания и использования.
Общее число уровней в модели (включая контекстный) не должно превышать 5-6. Практика показывает, что этого вполне достаточно для построения полной функциональной модели современного предприятия любой отрасли.
Метод SADT в наибольшей степени подходит для описания процессов верхнего уровня управления. Его основные преимущества заключаются в следующем [Репин-04]:
- полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
- комплексность декомпозиции;
- возможность агрегирования и детализации потоков данных и информации (разделение и слияние дуг);
- наличие жестких требований, обеспечивающих получение моделей стандартного вида; • простота документирования процессов;
- соответствие подхода к описанию процессов стандарту ISO 9000:2000.
В то же время метод SADT обладает рядом недостатков:
- сложность восприятия (большое количество дуг на диаграммах);
- большое количество уровней декомпозиции;
- трудность увязки нескольких процессов, представленных в различных моделях одной и той же организации.
3.2. Метод моделирования процессов IDEF3
Метод моделирования IDEF3 [Черемных-01, Репин-04], являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции).
Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.
Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели – действие, или в терминах IDEF3 «единица работы» (Unit of Work). Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 3).
Существенные взаимоотношения между действиями изображаются с помощью связей. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 1 приведены три возможных типа связей.
Связь типа «временное предшествование» показывает, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия.
Связь типа «объектный поток» используется в том случае, когда некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Обозначение такой связи отличается от связи временного предшествования двойной стрелкой. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования, это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие может начать выполняться.
Связь типа «нечеткое отношение» используется для выделения отношений между действиями, которые невозможно описать с использованием связей предшествования или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа «нечеткое отношение» сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений – отображение взаимоотношений между параллельно выполняющимися действиями.
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для изображения ветвления процесса:
- разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других;
- сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.
Соединения «и» инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему соединению «и», должны завершиться, прежде чем начнется выполнение следующего действия. На рис. 4 после обнаружения пожара инициируются включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены.
Соединение «исключающее «или»» означает, что вне зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением, инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением, сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения. На рис. 5 соединение «исключающее «или»» используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.
Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений.
Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно аналитиком. На рис. 6 соединение J2 может активизировать проверку данных чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных – при оплате наличными. И то, и другое действие инициируются при частичной оплате как чеком, так и наличными.
В рассмотренных примерах все действия выполнялись асинхронно, т.е. они не инициировались одновременно. Однако существуют случаи, когда время начала или окончания параллельно выполняемых действий должно быть одинаковым, т.е. действия должны выполняться синхронно. Для моделирования такого поведения системы используются различные виды синхронных соединений, которые обозначаются двумя двойными вертикальными линиями внутри прямоугольника.
Все соединения на диаграммах должны быть парными, из чего следует, что любое разворачивающее соединение имеет парное себе сворачивающее. Однако типы соединений не обязательно должны совпадать.
Соединения могут комбинироваться для создания более сложных ветвлений. Комбинации соединений следует использовать с осторожностью, поскольку перегруженные ветвлением диаграммы могут оказаться сложными для восприятия.
Действия в IDEF3 могут быть декомпозированы или разложены на составляющие для более детального анализа. Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.
3.3. Моделирование потоков данных
Диаграммы потоков данных (Data Flow Diagrams – DFD) [Калашян-03] представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявитьотношениямеждуэтимипроцессами.
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов (далее в примерах используется нотация ГейнаСэрсона).
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла.
3.3.1. Состав диаграмм потоков данных
Основными компонентами диаграмм потоков данных являются:
- внешние сущности;
- системы и подсистемы;
- процессы;
- накопители данных;
- потоки данных.
Внешняя сущность представляет собой материальный объект или физическое лицо, являющиеся источником или приемником информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рис. 7), расположенным над диаграммой и бросающим на нее тень для того, чтобы можно было выделить этот символ среди других обозначений.
При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем.
Подсистема (или система) на контекстной диаграмме изображается так, как она представлена на рис. 8.
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
Процесс на диаграмме потоков данных изображается, как показано на рис. 9.
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: «Ввести сведения о налогоплательщиках», «Выдать информацию о текущих расходах», «Проверить поступление денег».
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных – это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается, как показано на рис. 10.
Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать модели данных.
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рис. 11). Каждый поток данных имеет имя, отражающее его содержание.
3.3.2. Построение иерархии диаграмм потоков данных
Главная цель построения иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
- Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
- Не загромождать диаграммы несущественными на данном уровне деталями.
- Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой.
- Выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы.
Для проверки контекстной диаграммы можно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному или более потокам данных: входные потоки интерпретируются как воздействия, а выходные потоки – как реакции системы на входные потоки.
Для сложных систем (признаками сложности могут быть наличие большого количества внешних сущностей (десять и более), распределенная природа системы или ее многофункциональность) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:
- наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
- возможности описания преобразования данных процессов в виде последовательного алгоритма;
- выполнения процессом единственной логической функции преобразования входной информации в выходную;
- возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).
Спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Они содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Языки спецификаций могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков моделирования.
Структурированный естественный язык применяется для понятного, достаточно строгого описания спецификаций процессов. При его использовании приняты следующие соглашения:
- логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций;
- глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать);
- логика процесса должна быть выражена четко и недвусмысленно.
При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Для каждого потока данных формируется список всех его элементов данных, затем элементы данных объединяются в структуры данных, соответствующие более крупным объектам данных (например, строкам документов или объектам предметной области). Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре (например, структура «данные о страховании» для объекта «служащий»). Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне (например, элемент «имя ребенка» для объекта «служащий»). Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных могут указываться единица измерения, диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы.
Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей «AS-IS» и «AS-TO-BE», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними. При этом описание используемых в организации данных на концептуальном уровне, независимом от средств реализации базы данных, выполняется с помощью модели «сущность-связь».
Ниже перечислены основные виды и последовательность работ при построении бизнесмоделей с использованием методики Йордона:
1. Описание контекста процессов и построение начальной контекстной диаграммы. Начальная контекстная диаграмма потоков данных должна содержать нулевой процесс с именем, отражающим деятельность организации, внешние сущности, соединенные с нулевым процессом посредством потоков данных. Потоки данных соответствуют документам, запросам или сообщениям, которыми внешние сущности обмениваются с организацией.
2. Спецификация структур данных. Определяется состав потоков данных и готовится исходная информация для построения концептуальной модели данных в виде структур данных. Выделяются все структуры и элементы данных типа «итерация», «условное вхождение» и «альтернатива». Простые структуры и элементы данных объединяются в более крупные структуры. В результате для каждого потока данных должна быть сформирована иерархическая (древовидная) структура, конечные элементы (листья) которой являются элементами данных, узлы дерева являются структурами данных, а верхний узел дерева соответствует потоку данных в целом.
3. Построение начального варианта концептуальной модели данных.Для каждого класса объектов предметной области выделяется сущность. Устанавливаются связи между сущностями и определяются их характеристики. Строится диаграмма «сущность-связь» (без атрибутов сущностей).
4. Построение диаграмм потоков данных нулевого и последующих уровней.
Для завершения анализа функционального аспекта деятельности организации детализируется (декомпозируется) начальная контекстная диаграмма. При этом можно построить диаграмму для каждого события, поставив ему в соответствие процесс и описав входные и выходные потоки, накопители данных, внешние сущности и ссылки на другие процессы для описания связей между этим процессом и его окружением. После этого все построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Процессы разделяются на группы, которые имеют много общего (работают с одинаковыми данными и/или имеют сходные функции). Они изображаются вместе на диаграмме более низкого (первого) уровня, а на диаграмме нулевого уровня объединяются в один процесс. Выделяются накопители данных, используемые процессами из одной группы.
Декомпозируются сложные процессы и проверяется соответствие различных уровней модели процессов.
Накопители данных описываются посредством структур данных, а процессы нижнего уровня – посредством спецификаций.
5. Уточнение концептуальной модели данных. Определяются атрибуты сущностей. Выделяются атрибуты-идентификаторы.
Проверяются связи, выделяются (при необходимости) связи «супертип-подтип». Проверяется соответствие между описанием структур данных и концептуальной моделью (все элементы данных должны присутствовать на диаграмме в качестве атрибутов).
3.4. Метод ARIS
В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS (Architecture of Integrated Information System), разработанный германской фирмой IDS Scheer [Каменнова-01, Репин-04].
Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику.
Методика моделирования ARIS основывается на разработанной профессором Августом Шером теории построения интегрированных ИС, определяющей принципы визуального отображения всех аспектов функционирования анализируемых компаний. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:
- организационные модели, представляющие структуру системы – иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
- функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
- информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
- модели управления, представляющие комплексный взгляд на реализацию бизнеспроцессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, UML.
В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами.
ARIS не накладывает ограничений на последовательность построения указанных выше типов моделей. Процесс моделирования можно начинать с любого из них, в зависимости от конкретных условий и целей, преследуемых разработчиками.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – «функция», «событие», «структурное подразделение», «документ» и т.п. Между объектами устанавливаются разнообразные связи. Так, между объектами «функция» и «структурное подразделение» могут быть установлены связи следующих видов:
- выполняет;
- принимает решение;
- участвует в выполнении;
- должен быть проинформирован о результатах;
- консультирует исполнителей;
- принимает результаты.
Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа.
Таким образом, по результатам выполнения этого этапа возникает набор взаимосвязанных моделей, представляющих собой исходный материал для дальнейшего анализа.
Основная бизнес-модель ARIS – eEPC (extended Event-driven Process Chain – расширенная модель цепочки процессов, управляемых событиями). В табл. 2 приводятся основные объекты, используемые в данной нотации.
Помимо указанных в таблице основных объектов, при построении диаграммы eEPC могут быть использованы многие другие объекты. По существу, модель eEPC расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Применение большого числа различных объектов, связанных различными типами связей, значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC достаточно рассмотреть основные типы объектов и связей. На рис. 12 представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.
На рис. 12 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных правилах:
- каждая функция должна быть инициирована событием и должна завершаться событием;
- в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.
На рис. 13 показано применение различных объектов ARIS при создании модели бизнес-процесса.
Из рис. 12 и 13 видно, что бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, графики Ганта в системе MS Project.
Основное достоинство метода ARIS заключается в его комплексности, которая проявляется во взаимосвязи между моделями различных типов. Метод ARIS позволяет описывать деятельность организации с разных точек зрения и устанавливать связи между различными моделями. Однако такой подход трудно реализуем на практике, поскольку влечет за собой большой расход ресурсов (человеческих и финансовых) в течение длительного времени. Кроме того, инструментальная среда ARIS достаточно дорогостояща и сложна в использовании.
3.5. Метод Ericsson-Penker и образцы моделирования бизнес-процессов
Метод Ericsson-Penker [Eriksson-2000] представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML [Буч-2000] (изначально предназначенного для моделирования архитектуры систем ПО) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения.
Механизмы расширения UML предназначены для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель.
Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и др. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:
- стереотипы;
- тегированные (именованные) значения;
- ограничения.
Стереотип – это новый тип элемента модели, который определяется на основе уже существующего элемента. Стереотипы расширяют нотацию модели, могут применяться к любым элементам модели и представляются в виде текстовой метки или пиктограммы. Стереотипы классов – это механизм, позволяющий разделять классы на категории. Участники проекта (аналитики) могут создавать свои собственные наборы стереотипов, формируя тем самым специализированные подмножества UML (например, для описания бизнес-процессов, Web-приложений, баз данных и т.д.). Такие подмножества (наборы стереотипов) в стандарте языка UML носят название профилей языка.
Именованное значение – это пара строк «тег = значение» или «имя = содержимое», в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т.п.
Ограничение – это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL – Object Constraint Language), которое невозможно выразить с помощью графической нотации UML.
Авторы метода Ericsson-Penker создали свой профиль UML для моделирования бизнеспроцессов под названием Ericsson-Penker Business Extensions, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации.
Метод использует четыре основные категории бизнес-модели:
- Ресурсы – различные объекты, используемые или участвующие в бизнес-процессах (люди, материалы, информация или продукты). Ресурсы структурированы, взаимосвязаны и подразделяются на физические, абстрактные, информационные и человеческие.
- Процессы – виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес-правилами.
- Цели – назначение бизнес-процессов. Цели могут быть разбиты на подцели и соотнесены с отдельными процессами. Цели достигаются в процессах и выражают требуемое состояние ресурсов. Цели могут быть выражены в виде одного или более правил.
- Бизнес-правила – условия или ограничения выполнения процессов (функциональные, поведенческие или структурные).
Правила могут диктоваться внешней средой (инструкциями или законами) или могут быть определены в пределах бизнес-процессов. Правила могут быть определены с использованием языка OCL, который является частью стандарта UML.
Все эти категории связаны между собой: правило может определять способ структурирования ресурсов, ресурс назначается конкретному процессу, цель связана с выполнением конкретного процесса. Метамодель, определяющая связи между категориями, приведена на рис. 14.
Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности (рис. 15).
Основным элементом диаграммы является деятельность (activity). Интерпретация этого термина зависит от той точки зрения, с которой строится диаграмма (это может быть некоторая задача, которую необходимо выполнить вручную или автоматизированным способом, или операция класса). Деятельность изображается в виде закругленного прямоугольника с текстовым описанием.
Любая диаграмма деятельности должна иметь начальную точку, определяющую начало потока событий. Конечная точка необязательна. На диаграмме может быть несколько конечных точек, но только одна начальная.
На диаграмме могут присутствовать объекты и потоки объектов (object flow). Объект может использоваться или изменяться в одной из деятельностей. Показ объектов и их состояний (в дополнение к диаграммам состояний UML) помогает понять, когда и как происходит смена состояний объекта.
Объекты связаны с деятельностями через потоки объектов. Поток объектов отмечается пунктирной стрелкой от деятельности к изменяемому объекту или от объекта к деятельности, использующей объект.
В примере на рис. 15 после ввода пользователем информации о кредитной карточке билет переходит в состояние «не подтвержден».
Когда завершится процесс обработки кредитной карточки и будет подтвержден перевод денег, возникает деятельность «зарезервировать место», переводящая билет в состояние «приобретен», и затем он используется в деятельности «формирование номера подтверждения».
Переход (стрелка) показывает, как поток управления переходит от одной деятельности к другой. Если для перехода определено событие, то переход выполняется только после наступления такого события. Ограничивающие условия определяют, когда переход может, а когда не может осуществиться.
Если необходимо показать, что две или более ветвей потока выполняются параллельно, используются линейки синхронизации. В данном примере параллельно выполняются резервирование места, формирование номера подтверждения и отправка почтового сообщения, а после завершения всех трех процессов пользователю выводится номер подтверждения.
Любая деятельность может быть подвергнута дальнейшей декомпозиции. Описание декомпозированной деятельности может быть представлено в виде другой диаграммы деятельности.
Подобно большинству других средств, моделирующих поведение некоторых объектов, диаграммы деятельности отражают только вполне определенные его аспекты, поэтому их лучше всего использовать в сочетании с другими средствами.
Бизнес-процесс в самом простом виде может быть описан как множество деятельностей. Метод Eriksson-Penker представляет образец процесса на диаграмме деятельности (рис. 16) в виде деятельности со стереотипом «process» (в качестве основы данного образца использовано представление процесса в методе IDEF0, расширенное за счет введения цели процесса). Процесс использует входные ресурсы и формирует выходные ресурсы, показанные в виде объектов со стереотипом «resourse», соединенных с процессом связями зависимости. Ресурсы, играющие в методе IDEF0 роли «управления» и «механизма», также соединены с процессом связями зависимости со стереотипами «supply» и «control». Цель процесса показана как объект со стереотипом «goal».
Полная бизнес-модель включает множество представлений. Каждое представление выражено в одной или более диаграммах. Диаграммы могут иметь различные типы и изображать процессы, правила, цели и ресурсы во взаимодействиях друг с другом.
Метод Eriksson-Penker использует четыре различных представления бизнес-модели:
- концептуальное представление – структура целей и проблем (дерево целей, представленное в виде диаграммы объектов);
- представление процессов – взаимодействие между процессами и ресурсами (в виде набора диаграмм деятельности);
- структурное представление – структура организации и ресурсов (в виде диаграмм классов);
- представление поведения – поведение отдельных ресурсов и детализация процессов (в виде диаграмм деятельности, состояний и взаимодействия).
Метод Ericsson-Penker активно использует набор образцов моделирования бизнес-процессов. Образец (pattern) можно определить как общее решение некоторой проблемной ситуации в заданном контексте. Образец состоит из четырех основных элементов:
Сославшись на имя образца, можно сразу описать проблему, ее решения и их последствия. С помощью словаря образцов можно вести обсуждение с коллегами, упоминать образцы в документации, в тонкостях представлять проект системы.
Проблема – это описание решаемой задачи. Необходимо сформулировать задачу и ее контекст. Также может включаться перечень условий, при выполнении которых имеет смысл применять данный образец.
Решение – это описание элементов решения, связей между ними и функций каждого элемента. Конкретное решение или реализация не имеются в виду, поскольку образец – это шаблон, применимый в самых разных ситуациях. Обычно дается абстрактное описание задачи и того, как она может быть решена с помощью некоего весьма обобщенного сочетания элементов (классов и объектов).
Следствия – это описание области применения, достоинств и недостатков образца. Хотя при описании решений о следствиях часто не упоминают, знать о них необходимо, чтобы можно было выбрать между различными вариантами и оценить преимущества и недостатки применения данного образца.
В языке UML образец представляется с помощью кооперации со стереотипом «pattern». Кооперация (collaboration) определяется как описание совокупности взаимодействующих объектов, реализующих некоторое поведение (например, в рамках варианта использования или операции класса). Кооперация имеет статическую и динамическую части. В статической части (на диаграмме классов) описываются роли, которые могут играть объекты и связи в экземпляре данной кооперации. Динамическая часть состоит из одной или более диаграмм взаимодействия, показывающих потоки сообщений, которыми обмениваются участники кооперации. Кроме того, любой образец содержит стандартную диаграмму классов под названием «Participants» («Участники»), на которой изображается сам образец в виде кооперации с его именем и набор классов, участвующих в реализации образца.
В качестве примера приведем образец бизнес-моделирования под названием Employment (Занятость).
Проблема заключается в моделировании различных форм занятости в пределах организации. Данная задача решается в контексте системы планирования ресурсов предприятия.
Решение: занятость моделируется как контракт между личностью и организацией, указывающий выполняемые обязанности, контрактные условия, даты начала и конца работы. Личность характеризуется набором атрибутов (имя, адрес и дата рождения), может занимать более чем одну должность в одной и той же организации.
На рис. 17 приведена диаграмма «Участники» для данного образца (примеры моделей здесь и далее приводятся в среде CASE-средства Rational Rose). Она содержит кооперацию Employment и набор из пяти классов:
- Employee Profile (Служащий) – описание служащего с набором атрибутов.
- Organization Profile (Организация) – описание самой организации.
- Employment (Занятость) – описание связи между служащим и организацией.
- Position (Должность) – описание должности со своими атрибутами (такими, как должностной оклад и должностные инструкции).
- Position Assignment (Назначение на должность) – описание связи между служащим и занимаемыми должностями.
Статическая часть образца (диаграмма классов) показана на рис. 18.
3.6. Метод моделирования, используемый в технологии Rational Unified Process
Язык UML используется также в методе моделирования бизнес-процессов, являющемся частью технологии Rational Unified Process [Крачтен-02] компании IBM Rational Software. Этот метод, направленный прежде всего на создание основы для формирования требований к ПО, предусматривает построение двух базовых моделей:
- модели бизнес-процессов (Business Use Case Model);
- модели бизнес-анализа (Business Analysis Model).
Модель бизнес-процессов – модель, описывающая бизнес-процессы организации в терминах ролей и их потребностей. Она представляет собой расширение модели вариантов использования (use case) UML [Коберн-02] за счет введения набора стереотипов – Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования).
Business Actor (действующее лицо бизнеспроцессов) – это некоторая роль, внешняя по отношению к бизнес-процессам организации. Потенциальными кандидатами в действующие лица бизнес-процессов являются:
- акционеры;
- заказчики;
- поставщики;
- партнеры;
- потенциальные клиенты;
- местные органы власти;
- сотрудники подразделений организации, деятельность которых не охвачена моделью;
- внешние системы.
Список действующих лиц составляется путем ответа на следующие вопросы:
- Кто извлекает пользу из существования организации?
- Кто помогает организации осуществлять свою деятельность?
- Кому организация передает информацию и от кого получает?
Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу.
Это определение подобно общему определению бизнес-процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.
Данный метод концентрирует внимание в первую очередь на элементарных бизнес-процессах. Такой процесс можно определить как задачу, выполняемую одним человеком в одном месте в одно время в ответ на некоторое событие, приносящую конкретный результат и переводящую данные в некоторое устойчивое состояние (например, подтверждение платежа по кредитной карточке). Выполнение такой задачи обычно включает от пяти до десяти шагов и может занимать от нескольких минут до нескольких дней, но рассматривается как один сеанс взаимодействия действующего лица с исполнителями.
Каждый Business Use Case отражает цель или потребность некоторого действующего лица. Например, если рассмотреть процесс регистрации пассажиров в аэропорту (рис. 19), то его основным действующим лицом будет сам Пассажир, главная цель которого в данном процессе – пройти регистрацию. Эта цель моделируется в виде Business Use Case с наименованием «Пройти регистрацию». Другим действующим лицом является Руководитель туристической группы, регистрирующий группу пассажиров. Стереотипы связей явно показывают роль действующих лиц по отношению к вариантам использования.
Описание Business Use Case представляет собой спецификацию (текстовый документ), которая, подобно обычному варианту использования, состоит из следующих пунктов [Коберн-02]:
- наименование;
- краткое описание;
- цели и результаты (с точки зрения действующего лица);
- описание сценариев (основного и альтернативных);
- специальные требования (ограничения по времени выполнения или другим ресурсам);
- расширения (исключительные ситуации);
- связи с другими Business Use Case;
- диаграммы деятельности (для наглядного описания сценариев – при необходимости).
Пример спецификации Business Use Case:
Наименование – пройти регистрацию. Краткое описание – данный Business Use Case реализует процесс регистрации пассажира на рейс. Цели – получить посадочный талон и сдать багаж. Основной сценарий:
1. Пассажир встает в очередь к стойке регистратора.
2. Пассажир предъявляет билет регистратору.
3. Регистратор подтверждает правильность билета.
4. Регистратор оформляет багаж.
5. Регистратор резервирует место для пассажира.
6. Регистратор печатает посадочный талон.
7. Регистратор выдает пассажиру посадочный талон и квитанцию на багаж.
8. Пассажир уходит от стойки регистратора.
3а. Билет неправильно оформлен – регистратор отсылает пассажира к агенту по перевозкам.
4а. Багаж превышает установленный вес – регистратор оформляет доплату.
Специальные требования – время регистрации не должно превышать одной минуты.
Описание Business Use Case может сопровождаться целью процесса, которая так же, как и в методе Eriksson-Penker, моделируется с помощью класса со стереотипом «goal», а дерево целей изображается в виде диаграммы классов.
Для каждого Business Use Case строится модель бизнес-анализа – объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов – Business Object), принадлежащих к двум классам – Business Worker и Business Entity.
Business Worker (исполнитель) – активный класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют различными сущностями, участвуя в реализациях сценариев Business Use Case. На диаграмме классов UML исполнитель представляется в виде класса со стереотипом «business worker». Например, если рассмотреть Business Use Case «Пройти регистрацию», можно определить в нем двух исполнителей – Регистратора и Координатора багажа.
Business Entity (сущность) – пассивный класс, не инициирующий никаких взаимодействий. Объект такого класса может участвовать в реализациях различных Business Use Case. Сущность является объектом различных действий со стороны исполнителей.
Понятие Business Entity аналогично понятию сущности в модели «сущностьсвязь», за исключением того, что в данной модели не определяется поведение сущности, а в объектной модели сущность может иметь набор обязанностей. На диаграмме классов UML сущность представляется в виде класса со стереотипом «business entity». Например, в Business Use Case «Пройти регистрацию» можно определить следующие сущности: Билет, Рейс, Авиалиния, Багаж, Багажная бирка.
Модель бизнес-анализа может состоять из диаграмм разных типов. В состав модели обязательно должна входить диаграмма классов, содержащая исполнителей и сущности. Пример такой диаграммы для Business Use Case «Пройти регистрацию» приведен на рис. 20.
На данной диаграмме ассоциации между классами-исполнителями отражают наличие взаимодействия между реальными исполнителями (Регистратором и Координатором багажа). Ассоциации между классами-исполнителями и классами-сущностями показывают, какими именно объектами манипулируют конкретные исполнители (Регистратор имеет дело с Багажом и Багажной биркой, а Координатор багажа – только с Багажом). Ассоциации между классами-сущностями отражают различные структурные связи (к одному месту багажа прикрепляется одна багажная бирка).
Кроме диаграммы классов, модель бизнес-анализа может включать:
- Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case в виде последовательности обмена сообщениями между объектами-действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора операций класса. Пример диаграммы последовательности, описывающей основной сценарий Business Use Case «Пройти регистрацию», приведен на рис. 21. Модифицированная диаграмма классов модели бизнес-анализа с операциями приведена на рис. 22.
- Диаграммы деятельности с потоками объектов и «плавательными дорожками», описывающие взаимосвязи между сценариями одного или различных Business Use Case. Пример такой диаграммы для процесса заказа товаров в торговой компании приведен на рис. 23.
- Диаграммы состояний, описывающие поведение отдельных бизнес-объектов (например, для сущности «Багаж» можно описать переходы между состояниями «Определен вес», «Зарегистрирован», «Находится на транспортере» и т.д.).
Метод моделирования Rational Unified Process предусматривает специальное соглашение, связанное с группировкой структурных элементов и диаграмм бизнес-модели. Это соглашение включает следующие правила:
- Все действующие лица, варианты использования и диаграммы вариантов использования для бизнес-процессов помещаются в пакет с именем Business Use Case Model.
- Все классы и диаграммы моделей бизнесанализа помещаются в пакет с именем Business Analysis Model.
- Если моделируется деятельность более чем одного подразделения организации, то совокупность всех классов-исполнителей и классов-сущностей из моделей бизнес-анализа для различных Business Use Case разделяется на пакеты, соответствующие этим подразделениям. Этим пакетам присваиваются наименования подразделений (например, Бухгалтерия, Отдел доставки и т.п.) и стереотип «business system».
- Диаграммы модели бизнес-анализа, относящиеся к конкретному Business Use Case (диаграммы классов, последовательности, деятельности и состояний) помещаются в кооперацию с именем данного Business Use Case и стереотипом «business use-case realization» (реализация бизнес-процесса). Все кооперации помещаются в пакет с именем Business Use Case Realizations.Пример структуры бизнесмодели для процесса регистрации пассажиров в аэропорту приведен на рис. 24.
Метод моделирования Rational Unified Process обладает следующими достоинствами:
- модель бизнес-процессов строится вокруг участников процессов (заинтересованных лиц) и их целей, помогая выявить все потребности клиентов организации. Нетрудно заметить, что такой подход в наибольшей степени применим для организаций, работающих в сфере оказания услуг (торговые организации, банки, страховые компании и т.д.);
- моделирование на основе вариантов использования способствует хорошему пониманию бизнес-модели со стороны заказчиков;
- метод предусматривает достаточно простой переход от бизнес-модели к системным требованиям.
Однако следует отметить, что при моделировании деятельности крупной организации, занимающейся как производством продукции, так и оказанием услуг, необходимо применять различные методы моделирования, поскольку для моделирования производственных процессов более предпочтительным является процессный подход (например, метод Eriksson-Penker).
4. Сравнительный анализ различных методов и инструментальных средств моделирования
Основная задача сравнительного анализа состоит в том, чтобы ответить на ряд вопросов, возникающих у руководителей и специалистов в начале проекта по моделированию и реорганизации бизнес-процессов предприятия:
- Какое инструментальное средство использовать в проекте (ARIS, BPwin, Rational Rose и др.)?
- Какой метод использовать для описания процессов?
- Как моделировать процессы с использованием некоторого инструментального средства?
В настоящее время на российском рынке представлено достаточно большое количество инструментальных средств (ARIS, AllFusion Modeling Suite, Rational Rose и др.), которые позволяют, так или иначе, создавать описания (модели) бизнес-процессов.
Рациональный выбор средств возможен при понимании руководством компании и ее специалистами нескольких аспектов:
- целей проекта;
- требований к информации о бизнес-процессах, необходимой для анализа и принятия решений в рамках конкретного проекта;
- возможностей инструментальных средств в части описания процессов.
Говорить о преимуществе того или иного метода и средств бессмысленно, пока не определены тип и рамки проекта, его основные задачи. Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. Для каждой такой задачи существуют определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться.
В качестве примера можно привести результаты сравнительного анализа методов ARIS и IDEF (IDEF0, IDEF3), а также поддерживающих их инструментальных средств ARIS Toolset и BPwin [Репин-04]. Итак.
Одним из важнейших аспектов описания моделей бизнес-процессов является отражение управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель потока работ (workflow), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются.
Кроме того, если попытаться в нотации ARIS eEPC отразить все условия и ограничения, определяющие выполнение функций, то потребуется описать большое количество событий и входящей информации (например, устных распоряжений руководителей), и модель станет сложной и плохо читаемой (эти недостатки присущи так же и нотации IDEF3). Указанных недостатков нет у нотации IDEF0. В то же время в IDEF0 не предусмотрено использование символов логики выполнения процесса.
Таким образом, нотация ARIS eEPC является расширением достаточно простой нотации IDEF3. Для адекватного описания процесса управления в нотации eEPC необходимо заранее договориться, как будут отражены в модели документы (информация), регламентирующие выполнение процедур процесса.
Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPwin можно корректно сравнивать только по отношению к определенному кругу задач. С точки зрения формирования моделей бизнес-процессов каждая из рассматриваемых систем имеет свои преимущества и недостатки. В зависимости от решаемых задач эти преимущества и недостатки могут как усиливаться, так и наоборот. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPwin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPwin.
Сравнивая две системы, следует отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Естественно, что в ARIS предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPwin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. Для управления групповой разработкой используется средство Model Mart, обеспечивающее многопользовательский доступ к моделям, созданным с помощью ERwin и BPwin.
Часто одним из недостатков BPwin называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно практически использовать (критерий – обозримость), количество объектов в базе данных ARIS или модели BPwin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPwin), содержащие более 500 объектов, фактически невозможно использовать. Следует подчеркнуть, что модель создается для выделения и анализа проблем, т.е. требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, среди руководителей многих компаний существует вера в то, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.
ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться жесткими и объемными соглашениями по моделированию (стандартами). Разработка таких соглашений требует значительного времени (1-3 месяца) и высококвалифицированных специалистов. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%. В свою очередь, BPwin отличается простотой в использовании и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более мощным и «тяжелым» инструментом по сравнению с BPwin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.
Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 25 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов в соответствии со стандартами ISO) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.
По мнению автора, современные методы и инструментальные средства моделирования достигли такого уровня, что их возможности с точки зрения изобразительных средств моделирования в настоящее время стали примерно одинаковыми. При этом одним из основных критериев выбора того или иного метода и инструмента становится степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования, обеспечивающая достаточный уровень понимания моделей со стороны руководителей и специалистов организации. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
5. Перспективные направления в моделировании бизнес-процессов
Как было сказано выше, в настоящее время предпринимаются многочисленные проекты, целью которых является интеграция существующих методов и языков моделирования и создание единого методического и технологического базиса моделирования бизнес-процессов, а в более широком контексте – моделирования предприятий (enterprise modeling) [BPMN-03, UEML-02, BPDM-03].
5.1. Деятельность консорциума Business Process Management Initiative (BPMI)
Консорциум BPMI был создан в августе 2000 г. по инициативе компании Intalio группой из шестнадцати компаний-разработчиков ПО и консалтинговых фирм. BPMI (http://www.bpmi.org) – независимая организация, занимающаяся разработкой открытых спецификаций для управления процессами электронной коммерции. К таким спецификациям относятся проекты стандартов Business Process Modeling Language (BPML) и Business Process Query Language (BPQL), предназначенных для управления бизнес-процессами (аналогично использованию SQL для управления данными с помощью СУБД). BPML – это метаязык для моделирования бизнес-процессов, также как XML – метаязык для моделирования данных. BPML позволяет создать абстрактную исполнимую модель взаимодействующих процессов, основанную на концепции конечного автомата.
В 2003 г. BPMI опубликовал проект стандарта Business Process Modeling Notation (BPMN) [BPMN-03]. Целью этого проекта является создание общей нотации для различных категорий специалистов: от бизнес-аналитиков и экспертов организаций до разработчиков ПО. BPMN состоит из одной диаграммы под названием Business Process Diagram (BPD) (рис. 25), которая непосредственно отображается в конструкции BPML.
Хотя спецификация BPMN в настоящее время существует только в версии 1.0, многие компании уже приняли ее на вооружение. BPMI не является комитетом по стандартизации, поэтому стандарт BPMN будет в конечном счете передан соответствующей организации. Наиболее вероятным кандидатом на роль такой организации является консорциум Object Management Group (OMG), и переговоры относительно такой передачи уже имели место. Учитывая высокую степень сходства между BPMN и диаграммой деятельности UML 2.0, можно допустить их интеграцию в будущем в общую модель.
5.2. Проект UEML
Проект Unified Enterprise Modeling Language (UEML) [UEML-02], финансируемый Европейской Комиссией, был предпринят с целью интеграции многочисленных языков моделирования архитектуры предприятий (Enterprise Modeling Languages) и создания в перспективе унифицированного языка моделирования с четко определенными синтаксисом, семантикой и правилами отображений между различными средствами моделирования. Основой для такой интеграции послужили модели GERAM (Generalised Enterprise Reference Architecture and Methodology) и Захмана [UEML-02]. Проект UEML включает разработку:
- общего визуального, основанного на шаблонах языка для коммерческих инструментальных средств моделирования;
- стандартных, независимых от инструментов механизмов передачи моделей между проектами;
- репозитория моделей предприятий.
Одним из результатов проекта, в частности, явилось создание портала http://www.ueml.org, который содержит всю информацию по данному проекту.
5.3. Работы в рамках проекта OMG MDA
OMG – это консорциум разработчиков ПО и пользователей, представляющих различные коммерческие, государственные и академические организации, насчитывающий около 800 участников. OMG занимается разработкой различных стандартов в области взаимодействия распределенных систем (наиболее известные из них – CORBA и UML).
Работа OMG в области моделирования бизнес-процессов связана в основном с концепцией Model Driven Architecture (MDA) [Кузнецов-03].
MDA интегрирует различные подходы к моделированию и вводит набор отображений между моделями различных уровней абстракции (рис. 26). Любая организация, использующая MDA, может разрабатывать только те модели, которые требуются для ее собственных целей.
В настоящее время тремя главными инициативными проектами OMG являются создание метамоделей для описания бизнес-процессов (Business Process Definition Metamodel – BPDM) [BPDM-03], бизнес-правил (Business Semantics of Business Rules, and Production Rule Representation) и онтологии (Ontology Definition Metamodel). Назначение BPDM (рис. 27) – интеграция и обеспечение взаимодействия между моделями, использующимися различными организациями (такими, как диаграммы UML или BPMN). Предполагается, что BPDM будет реализована в виде профиля UML 2.0.
Аналогично, OMG работает над стандартизацией бизнес-правил и их совместимостью с BPDM. Все это вместе взятое должно в перспективе обеспечить новый уровень совместимости между моделями, используемыми для описания бизнес-процессов и ПО.
Библиография
[Буч-2000] Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя.: Пер. с англ. – М.: ДМК, 2000.
[Калашян-03] Калашян А.Н., Калянов Г.Н. Структурные модели бизнеса: DFD-технологии. – М.: Финансы и статистика, 2003.
[Каменнова-01] Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS. – М.: Весть-МетаТехнология, 2001.
[Коберн-02] Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М.: ЛОРИ, 2002.
[Крачтен-02] Крачтен Ф. Введение в Rational Unified Process.: Пер. с англ. – М.: Вильямс, 2002.
[Кузнецов-03] Кузнецов М. MDA – новая концепция интеграции приложений. – «Открытые системы», No9, 2003.
[Марка-93] Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. – М.: МетаТехнология, 1993.
[Ойхман-97] Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: реинжиниринг организации и информационные технологии. – М.: Финансы и статистика, 1997.
[РД-2000] Методология функционального моделирования IDEF0. Руководящий документ РД IDEF0 – 2000. – М.: Госстандарт России, 2000.
[Репин-04] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004.
[Черемных-01] Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем: IDEF-технологии. – М.: Финансы и статистика, 2001.
[BPDM-03] Business Process Definition Metamodel. Request For Proposal. OMG Document: bei/2003-01. http://www.omg.org
[BPMN-03] Business Process Modeling Notation. Working Draft (1.0) August 25, 2003. http://www.bpmn.org
[Eriksson-2000] Eriksson, Hans-Erik and Penker, Magnus. Business Modeling with UML: Business Patterns at work. Wiley Computer Publishing, 2000.
[UEML-02] Report on the State of the Art in Enterprise Modeling. Project UEML: Unified Enterprise Modeling Language. September 27th 2002. http://www.ueml.org
Читайте также
это уже не магазин ;Татьяна Вандышева;https://www.jetinfo.ru/autor/tatiana-vanfysheva/;https://www.jetinfo.ru/laboratoriya-stoit-15-mln-rublej-i-ne-prinosit-siyuminutnoj-pribyli-no-dlya-kompanii-eto-shans-vyjti-na-ustojchivoe-razvitie/;;|Когда-то топ-менеджмент уделял инновациям 3% своего времени, а теперь 20-30% ;Василий Тарасевич;https://www.jetinfo.ru/speakers/vasilij-tarasevich/;https://www.jetinfo.ru/interviews/pyatiletnie-strategii-menyayutsya-na-ne-provalitsya-zdes-i-sejchas/;;|Решили самостоятельно внедрять iiot? не удивляйтесь, но вас могут посадить.;Сергей Андронов;https://www.jetinfo.ru/autor/sergej-andronov/;https://www.jetinfo.ru/interviews/reshili-samostoyatelno-vnedryat-iiot-ne-udivlyajtes-no-vas-mogut-posadit/;;| 11 млн запросов в час поступало на сайт «утконос» в марте 2020 г.;Антон Тарабрин;https://www.jetinfo.ru/speakers/anton-tarabrin/;https://www.jetinfo.ru/interviews/konkurencziya-drajvit-e-com-rynok/;;| 4 часа потребовалось «делимобиль», чтобы перейти на удаленную работу в марте 2020 г.;Дмитрий Рязанов;https://www.jetinfo.ru/speakers/dmitrij-ryazanov/;https://www.jetinfo.ru/interviews/karshering-eto-didzhital-produkt/;;| 150-200 млн руб может сэкономить за 5 лет крупный ритейлер благодаря омниканальным решениям;Александр Воронцов;https://www.jetinfo.ru/autor/aleksandr-voronczov/;https://www.jetinfo.ru/idealnyj-omniritejler-kakoj-on/;;|Мошенники могут монетизировать похищенные баллы программ лояльности и получить от 30 до 50% их номинальной стоимости.;Алексей Сизов;https://www.jetinfo.ru/autor/aleksei_sizov/;https://www.jetinfo.ru/moshennichestvo-v-programmah-loyalnosti/;;| Более 10% годового дохода инвестирует в исследования Huawei ;Алексей Емельянов;https://www.jetinfo.ru/speakers/aleksej-emelyanov/;https://www.jetinfo.ru/interviews/nelzya-prosto-vzyat-i-dokupit-ibp-no-esli-modulnyj-to-mozhno/;;| 57 видов личных данных будут храниться в «Цифровом профиле» клиента банка.;Денис Кузнецов;https://www.jetinfo.ru/speakers/denis-kuzneczov/;https://www.jetinfo.ru/interviews/skb-bank/;;| Людей можно мотивировать не только деньгами , но и задачами. Иначе войну рублями можно вести бесконечно ;Александр Сабуров;https://www.jetinfo.ru/speakers/aleksandr-saburov/;https://www.jetinfo.ru/interviews/data-sajentistov-u-kotoryh-est-dostup-k-ozeru-my-znaem-v-liczo/;;| Задача катастрофоустойчивости не решена ни в одной финансовой организации Казахстана, поэтому наш проект уникален ;Сергей Караханов;https://www.jetinfo.ru/speakers/sergej-karahanov/;https://www.jetinfo.ru/interviews/novye-servisy-my-vnedryaem-tolko-v-kontejnerah-kak-ustroena-it-infrastruktura-sberbanka-v-kazahstane/;;| Вместо «информационных систем» у нас появляется все больше «ИТ-сервисов» и «микросервисов» ;Сергей Караханов;https://www.jetinfo.ru/speakers/sergej-karahanov/;https://www.jetinfo.ru/interviews/novye-servisy-my-vnedryaem-tolko-v-kontejnerah-kak-ustroena-it-infrastruktura-sberbanka-v-kazahstane/;;| Сейчас инструменты DG легче «приземлить» на реальный бизнес, поэтому их используют в телекоме, логистике, на производстве ;Роман Шемпель;https://www.jetinfo.ru/speakers/roman-shempel/;https://www.jetinfo.ru/interviews/vnedryat-data-governance-pora-kogda-top-menedzhery-perestayut-doveryat-otchetam/;;| А что если ваш конкурент прямо сейчас заказывает сервер в облаке, пока вы обсуждаете, где взять ресурсы для проекта? ;Вячеслав Медведев;https://www.jetinfo.ru/autor/viacheslav-medvedev/;https://www.jetinfo.ru/kak-perejti-v-oblako-i-ne-oblazhatsya/;;| Все чаще в кабинете CIO дашборд «Количество дней без аварий» меняется на «Количество релизов за день» ;Илья Воронин;https://www.jetinfo.ru/autor/ilya_voronin/;https://www.jetinfo.ru/bolshoj-infrastrukturnyj-perehod/;;| 4 из 10 российских компаний хотя бы раз подвергались атакам программ-вымогателей;Роман Харыбин;https://www.jetinfo.ru/autor/roman-harybin/;https://www.jetinfo.ru/kak-nastroit-infrastrukturu-chtoby-zashhititsya-ot-virusov-shifrovalshhikov/;;| Более 400 млн руб. за три года выделила ОМК на научные разработки;Александр Мунтин;https://www.jetinfo.ru/speakers/aleksandr-muntin/;https://www.jetinfo.ru/interviews/samoe-vazhnoe-umenie-prizemlit-razrabotki-na-realnoe-proizvodstvo/;;| У 93% компаний есть выделенные эксперты для проактивного поиска угроз;Александр Ахремчик, Алла Крджоян;https://www.jetinfo.ru/autor/aleksandr-ahremcnik/;https://www.jetinfo.ru/kak-organizovat-threat-hunting/;Алла Крджоян;https://www.jetinfo.ru/autor/alla-krdzhoyan/| Чтобы эффективно реагировать на угрозы, нужно быть проактивным — этот принцип лежит в основе Threat Hunting. ;Александр Ахремчик;https://www.jetinfo.ru/autor/aleksandr-ahremcnik/;https://www.jetinfo.ru/kak-organizovat-threat-hunting/;Алла Крджоян;https://www.jetinfo.ru/autor/alla-krdzhoyan/| 53% сотрудников российских компаний считают биометрию удобнее других методов идентификации. ;Алексей Кузьмин;https://www.jetinfo.ru/autor/aleksej-kuzmin/;https://www.jetinfo.ru/kak-sotrudniki-kompanij-otnosyatsya-k-biometrii-issledovanie-infosistemy-dzhet/;;| 38% сотрудников российских компаний не готовы ни под каким предлогом предоставить работодателям свою биометрию. ;Алексей Кузьмин;https://www.jetinfo.ru/autor/aleksej-kuzmin/;https://www.jetinfo.ru/kak-sotrudniki-kompanij-otnosyatsya-k-biometrii-issledovanie-infosistemy-dzhet/;;|В 250 раз выросло количество противоправных действий в сфере высоких технологий за последние 10 лет. ;Алексей Сизов;https://www.jetinfo.ru/autor/aleksei_sizov/;https://www.jetinfo.ru/o-bankovskom-moshennichestve-v-czelom-i-mnogoobrazii-vnutrennego-v-chastnosti/;;|Всего 40% выданных прав доступа в среднем использует линейный сотрудник банка. ;Алексей Сизов;https://www.jetinfo.ru/autor/aleksei_sizov/;https://www.jetinfo.ru/o-bankovskom-moshennichestve-v-czelom-i-mnogoobrazii-vnutrennego-v-chastnosti/;;| Jet Detective агрегирует сотни тысяч операций в минуту из множества источников — от сетевых каналов до бизнес-систем — и оперативно проводит анализ каждого события. ;Алексей Сизов;https://www.jetinfo.ru/autor/aleksei_sizov/;https://www.jetinfo.ru/o-bankovskom-moshennichestve-v-czelom-i-mnogoobrazii-vnutrennego-v-chastnosti/;;|В 2,5 раза выросло количество атак на e-comm и сферу развлечений весной 2022 г. по сравнению с 2021-м. ;Александр Морковчин;https://www.jetinfo.ru/autor/aleksandr-morkovchin/;https://www.jetinfo.ru/ne-preryvaemsya-10-shagov-k-nepreryvnosti-biznesa/;Алексей Джураев;https://www.jetinfo.ru/autor/aleksej-dzhuraev/| В ближайшем будущем мы увидим реализацию ИБ-атак, подготовка к которым началась после 24 февраля. Вполне возможно, самое страшное уже позади, а самое сложное — впереди. ;Алексей Мальнев;https://www.jetinfo.ru/autor/aleksei-malnev/;https://www.jetinfo.ru/samoe-strashnoe-uzhe-pozadi-a-samoe-slozhnoe-vperedi-ugrozy-2022-glazami-jet-csirt/;;| Порядка 90% значимых ИБ-инцидентов сегодня приходится на социальную инженерию и атаки внешнего периметра компаний. ;Алексей Мальнев;https://www.jetinfo.ru/autor/aleksei-malnev/;https://www.jetinfo.ru/samoe-strashnoe-uzhe-pozadi-a-samoe-slozhnoe-vperedi-ugrozy-2022-glazami-jet-csirt/;;| На 50% дороже в среднем стоят сотрудники, которые умеют работать с открытым кодом.;Евгений Вызулин;https://www.jetinfo.ru/autor/evgenij-vyzulin/;https://www.jetinfo.ru/open-source-v-soc/;;| В SIEM-системе компании, где работают около 1000 сотрудников , в среднем регистрируется до 10 000 событий в секунду. Только за день в таком потоке будет выплывать более 100 подозрительных активностей. ;Гурген Цовян;https://www.jetinfo.ru/autor/gurgen-czovyan/;https://www.jetinfo.ru/para-slov-ob-xdr/; Ринат Сагиров;https://www.jetinfo.ru/autor/rinat-sagirov/| Внедрение DLP — это не разовый проект, а процесс , который нужно легализовать, поддерживать и модифицировать вместе с развитием компании ;Екатерина Краснова;https://www.jetinfo.ru/autor/ekaterina-krasnova/;https://www.jetinfo.ru/dlp-otnosheniya-ot-rabochej-rutiny-do-sudebnyh-proczessov/;;| Лучший ответ, который ИБ может дать на вопрос о приоритетах в защите, — это «мы не знаем и не можем знать». Приоритеты может расставить только руководство компании. ;Андрей Янкин;https://www.jetinfo.ru/autor/andrej-yankin/;https://www.jetinfo.ru/horoshaya-bezopasnost-rabotaet-s-lyudmi/;;|SOC можно запустить за 30 рабочих дней. ;Ринат Сагиров;https://www.jetinfo.ru/autor/rinat-sagirov/;https://www.jetinfo.ru/soc-za-chetyre-nedeli-a-chto-tak-mozhno-bylo/;;| «Меня это не касается» — очень распространенное заблуждение. Если вы еще не сталкивались с угрозой, это не значит, что от нее не нужно защищаться. ;Никита Ступак;https://www.jetinfo.ru/autor/nikita-stupak/;https://www.jetinfo.ru/zashhishhaemsya-ot-ddos-kejsy-i-sovety-infosistemy-dzhet/;;| Уже есть кейсы, когда российские компании заявляли о вредительских действиях зарубежным регуляторам и регистраторам, на что им приходил ответ: «Мы не рассматриваем заявления из России». ;Сергей Гук;https://www.jetinfo.ru/speakers/sergej-guk/;https://www.jetinfo.ru/interviews/sezon-ohoty-na-russkie-informsistemy/;;| С острой фазой кризиса ИБ-отрасль уже справилась. Но сможем ли мы добиться отмены сезона охоты на русские информсистемы? ;Сергей Гук;https://www.jetinfo.ru/speakers/sergej-guk/;https://www.jetinfo.ru/interviews/sezon-ohoty-na-russkie-informsistemy/;;| Российский ИБ-рынок гораздо более зрелый, чем рынок ИТ-продуктов. Да, не все средства защиты эффективны настолько, насколько бы хотелось, но они есть, и с этим можно работать. ;Сергей Барбашин;https://www.jetinfo.ru/speakers/sergej-barbashin/;https://www.jetinfo.ru/interviews/effekt-zarubezhnogo-banka-rosbank-v-novoj-ib-realnosti/;;|Не существует более или менее опасных атак — все угрозы равноценны. ;Сергей Барбашин;https://www.jetinfo.ru/speakers/sergej-barbashin/;https://www.jetinfo.ru/interviews/effekt-zarubezhnogo-banka-rosbank-v-novoj-ib-realnosti/;;|Главный вызов — развеять миф о том, что ИБ-угрозы как микробы: не вижу, значит, их нет. ;Дмитрий Балдин;https://www.jetinfo.ru/speakers/dmitrij-baldin/;https://www.jetinfo.ru/interviews/bez-pilotirovaniya-my-nichego-ne-vnedryaem-eto-vnutrennee-tabu-informaczionnaya-bezopasnost-v-rusgidro/;;| Российское ПО прошло уровень «сырых продуктов» — в основном это достаточно хорошие коробочные решения.;Дмитрий Балдин;https://www.jetinfo.ru/speakers/dmitrij-baldin/;https://www.jetinfo.ru/interviews/bez-pilotirovaniya-my-nichego-ne-vnedryaem-eto-vnutrennee-tabu-informaczionnaya-bezopasnost-v-rusgidro/;;| Мы допускаем, что злоумышленник сможет проникнуть в нашу инфраструктуру, но возможность развития атаки мы должны исключить. ;Дмитрий Балдин;https://www.jetinfo.ru/speakers/dmitrij-baldin/;https://www.jetinfo.ru/interviews/bez-pilotirovaniya-my-nichego-ne-vnedryaem-eto-vnutrennee-tabu-informaczionnaya-bezopasnost-v-rusgidro/;;| Злоумышленники не спят — они стучатся из разных часовых поясов, поэтому нам приходится круглосуточно отслеживать угрозы. ;Александр Данченков;https://www.jetinfo.ru/speakers/aleksandr-danchenkov/;https://www.jetinfo.ru/interviews/my-vozvrashhaemsya-no-v-parallelnoe-ruslo-informaczionnaya-bezopasnost-v-rusagro/;;’ data-object-img=’https://www.jetinfo.ru/wp-content/uploads/2021/06/l-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-2-3.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-2-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-2-1.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-3-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-3-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-3-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-4-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-4-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-4-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-5-3.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-5-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-5-1.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-6-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-6-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-6-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/08/l-7-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/08/l-7-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-6-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/08/l-8-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/06/l-6-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/06/l-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/08/l-9-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/08/l-9-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-10-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-10-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-10-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-11-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-11-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-11-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-11-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-12-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-12-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-13-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-13-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-13-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-10-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-14-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-14-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-15-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-15-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-15-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-15-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-16-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-16-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2021/11/l-17-1.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-17-2.png,https://www.jetinfo.ru/wp-content/uploads/2021/11/l-17-3.png;200,0,30;200,0,30|https://www.jetinfo.ru/wp-content/uploads/2023/01/1-1-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/1-2-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/1-3-3.png;200,,30;200,,30|https://www.jetinfo.ru/wp-content/uploads/2023/01/2-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/2-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/27-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/3-1-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/3-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/3-3-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/4-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/4-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/4-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/5-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/5-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/5-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/6-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/6-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/6-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/7-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/7-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/7-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/8-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/8-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/8-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/9-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/9-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/9-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/10-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/10-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/10-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/11-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/11-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/11-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/12-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/12-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/12-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/13-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/13-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/13-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/14-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/14-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/14-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/15-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/15-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/15-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/16-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/16-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/16-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/18-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/18-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/18-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/19-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/19-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/19-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/20-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/20-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/20-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/22-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/22-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/22-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/23-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/23-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/23-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/24-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/24-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/24-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/25-1.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/25-2.png,https://www.jetinfo.ru/wp-content/uploads/2023/01/25-3.png;200,,60;200,,60|https://www.jetinfo.ru/wp-content/uploads/2023/01/26-1.png;200;200’>
Самое популярное
С острой фазой кризиса ИБ-отрасль уже справилась. Но сможем ли мы добиться отмены сезона охоты на русские информсистемы?