Моделирование производственных бизнес - процессов (заочники) презентация

БРС
Отлично – 91-100 баллов;
Хорошо – 74-90 баллов;
Удовлетворительно – 61-73 балла;
Неудовлетворительно – 0-60 баллов.
Лекции (5) – максимум 10 баллов;
Практики (2) – максимум 10 баллов;
Лабораторные работы (3) – максимум 15 баллов;
Экзамен – максимум 65 балла.

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

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

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

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

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

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

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

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

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

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

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

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

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

Средства моделирования бизнес-процессов
Языки визуального моделирования – это формализованные наборы графических символов и правила построения из них визуальных моделей. Сейчас известны и активно используются на практике такие языки визуального моделирования, как UML и BPMN. Однако существуют и более старые языки: SDL и MSC для моделирования
телекоммуникационных систем, SADT/IDEF0 для моделирования бизнес-процессов, IDEF1x для моделирования баз данных и другие.

Средства моделирования бизнес-процессов
Метод SADT (Structured Analysis and Design Technique) предназначен для структурного анализа создаваемой или модифицируемой системы и является способом уменьшить количество дорогостоящих ошибок за счет структуризации знаний о системе на ранних этапах ее разработки, улучшения взаимодействия разработчиков и пользователей/заказчиков, а также сглаживания перехода от анализа к проектированию. Он включает в себя визуальный язык, а также подробно описанные принципы и технологию использования этого языка. Термин "структурный анализ" был введен в обиход Дугласом Россом (Douglas Ross) - главным автором SADT - в конце 60-х годов.

Средства моделирования бизнес-процессов
Историю развития SADT можно представить следующим образом:
60-е годы - группа ученых из MIT (Massachusetts Institute of Technology) под руководством Дугласа Росса создала метод иерархической модульной декомпозиции программных систем под названием SADT;
в 1969 г. авторы SADT основали компанию SoftTech, которая стала развивать и коммерциализировать этот метод;
1973 год - первая масштабная апробация SADT - проект по созданию завода будущего;
конец 70-х годов - SADT был использован в программе интегрированной компьютеризации производства ICAM (Integrated Computer-Aided Manufacturing) военно-воздушных сил США, что привело к стандартизации части SADT под названием IDEF0 и широкому распространению этого стандарта в военной промышленности США.

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

Базовые принципы структурного подхода
принцип «Разделяй и властвуй»
принцип иерархического упорядочивания
принцип абстрагирования
принцип непротиворечивости
принцип структурирования данных

Методология структурного анализа и проектирования
70-е гг. ХХ века – методология SADT
Предложена Дугласом Россом (Douglas Ross)
Основная идея данной методологии – построение древовидной иерархической модели предприятия.
В начале 1990-х на основе SADT принят стандарт моделирования бизнес-процессов IDEF0, являющийся одним из 14 стандартов линейки IDEF – Integration Definition for Functional Modeling (в данном курсе будут рассмотрены некоторые из них, в частности, IDEF0, IDEF1X, IDEF3).
Положения методологии зафиксированы в разработанном в США стандарте IDEF0 (В России – РД IDEF0 – 2000)

Модели структурного подхода
3 типа моделей, используемых в структурном подходе:
1) функциональные модели (ФМ)
2) информационные модели (ИМ)
3) динамические модели (ДМ)

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

Методология IDEF0
В основе IDEF0-методологии лежат 4 основных понятия:
1) функциональный блок;
2) интерфейсная дуга (стрелка);
3) декомпозиция;
4) глоссарий.

Функциональный блок
Олицетворяет некоторую конкретную функцию или работу в рамках рассматриваемой системы
РД IDEF0 – 2000: прямоугольник, содержащий имя и номер и используемый для описания функции

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

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

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

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

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

Декомпозиция
Контекстная диаграмма
Декомпозиция контекстной диаграммы
Декомпозиция блока А1
Декомпозиция блока А3

Декомпозиция
А0 ____________
А1____________
А11___________
А12___________
А13___________
А2____________
А3____________
Дерево узлов
Индекс узлов

Нумерация работ и диаграмм

Основные правила построения диаграмм
1. На одной диаграмме рекомендуется рисовать от 3 до 6 блоков. Иначе диаграмма будет плохо читаемой.
2. Функциональные блоки должны располагаться слева направо сверху вниз в порядке доминирования.
3. Следует избегать излишнего пересечения стрелок.

Основные правила построения диаграмм
4. Выход одного блока может являться входом (управлением) для другого. Могут быть и обратные связи по входу и управлению.

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

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

Граничные стрелки
Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у функционального блока и наоборот. Такие стрелки называются граничными. Граничные стрелки помечаются с помощью ICOM-меток (Input, Control, Output, Mechanism)

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

Глоссарий и FEO-страница
Для каждого из элементов в IDEF0 существует стандарт, подразумевающий создание и поддержку набора соответствующих определений, ключевых слов, повествований, изложений и т.д, которые характеризуют объект, отраженный данным элементом. Этот набор – глоссарий, являющийся описанием сущности данного элемента.
FEO-диаграмма (For Exposition Only) – это диаграмма, которая поясняет особо интересные и тонкие аспекты диаграмм. Эти диаграммы не ограничены синтаксисом IDEF0. В них может быть текстовая, графическая информация, схемы, альтернативная точка зрения на процесс и т.п.

Мастерская страница
(каркас диаграммы)
Стандартный бланк для диаграмм (облегчает подшивку и копирование)
Разделен на 3 основные части:
1) поле рабочей информации (для отслеживания диаграммы в процессе моделирования)
2) поле сообщений (область рисования диаграммы)
3) поле идентификации (идентификация диаграммы и ее позиционирование в иерархии)

Мастерская страница
Поле сообщений

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

Пример модели процесса постройки садового домика
2. Декомпозируем контекстную диаграмму
Заложить
фундамент
Возвести
стены
Положить
крышу
Выполнить
отделку

Пример модели, построенной с использованием CASE-средства BPWin

Пример модели, построенной с использованием CASE-средства BPWin

Дерево узлов

FEO-страница

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

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

Что такое IDEF1X?
Методология IDEF1X (IDEF1 Extended) – язык для семантического моделирования данных, основанных на концепции «сущность-связь». Является расширением стандарта IDEF1.
Диаграмма «сущность-связь» ERD (Entity-Relationship Diagram) предназначена для разработки модели данных и обеспечивает стандартный способ определения данных и отношений между ними.
Теоретической базой построения информационной модели является теория баз данных типа «сущность-связь».

Что такое IDEF1X?
Согласно стандарту , основными составляющими модели IDEF1X являются:
1) люди, предметы, явления, о которых хранится информация (далее – сущности)
2) связи между этими элементами (далее – отношения)
3) характеристики этих элементов (далее – атрибуты)

Определение сущности
Сущность – это множество реальных или абстрактных объектов (людей, мест, событий), обладающих общими атрибутами или характеристиками.
Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована.
Пример. Сущность – Студент. Экземпляр сущности – студент Иванов И.И.

Понятие атрибута
Атрибут – характеристика сущности.
Пример. Сущность «Студент» имеет атрибут «ФИО».
Экземпляр сущности «студент» (конкретный человек) будет иметь экземпляр атрибута «ФИО» (например, Иванов И.И.)

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

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

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

Графическое представление сущности
Различают следующие уровни представления сущности: диаграмма «сущность-связь» (ERD), модель данных, основанная на ключах (KB), полная атрибутивная модель (FA)

Правила определения атрибутов
Каждый атрибут каждой сущности обладает уникальным именем.
Сущность может обладать любым количеством атрибутов.
Различают собственные и наследуемые атрибуты. Собственные атрибуты являются уникальными в рамках модели. Наследуемые передаются от сущности-родителя при определении идентифицирующей связи.

Ключевые атрибуты
Ключевые атрибуты

Примеры ключевых атрибутов

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

Типы зависимых сущностей
Характеристическая - это зависимая дочерняя сущность, которая связана только с одной родительской сущностью и по смыслу хранит информацию о характеристиках родительской сущности
Категориальная – дочерняя сущность в иерархии наследования

Типы зависимых сущностей
Ассоциативная - сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущности

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

Правила отношений
1) При определении отношения типа «родитель-потомок»:
1.1. Экземпляр потомка связан с одним родителем
1.2. Экземпляр-родитель может быть связан с несколькими экземплярами потомков.
2) В идентифицирующем отношении сущность-потомок всегда является зависимой от идентифицирующей сущности.

Виды отношений
г) отношение категоризации (см. далее)

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

4 типа мощности отношений
а) общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности
б) когда одному экземпляру родительской сущности соответствует 1 или много экземпляров дочерней (0 исключается).

4 типа мощности отношений
в) когда одному экземпляру родительской сущности соответствует 0 или 1 экземпляр дочерней сущности.
г) когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

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

Пример отношений категоризации
Описание: Могут быть выделены следующие типы сотрудников: постоянный и совместитель. Категоризация неполная, т.к. могут быть и другие типы, например, консультанты. Тип – признак категоризации

Правила отношений категоризации
1. Сущность типа «категория» может иметь только одну общую сущность.
2. Сущность-категория, принадлежащая одному отношению категоризации, может быть общей сущностью в другом отношении категоризации

Пример иерархии категорий

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

Основные правила построения информационной модели
1. Все стрелки (вход, выход, управление, механизм) функциональной модели становятся потенциальными сущностями, а функции, связывающие их, трансформируются в отношения между этими сущностями. Для этого составляется пул – список потенциальных сущностей.
2. Число сущностей и связей в IDEF1X-модели считается необозримым, если их количество превышает 25-30. Поэтому далее рассматривается совокупность сущностей и отношений для каждой функции.

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

Построение информационной модели процесса постройки садового домика
1. На основе функциональной модели IDEF0 составим пул – список потенциальных сущностей.
Пул:
1. Дом
2. Крыша
3. Материалы
4. Проект дома
5. Стены
6. Строители
7. Фундамент
8. Каменщики
9. Плотники
10. Кровельщики
11. Мастера по отделке

Построение информационной модели процесса постройки садового домика
2. Определим сущности

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

Функциональное моделирование систем с использованием методологии DFD

Что такое DFD-модель
DFD – Data Flow Diagrams – диаграммы потоков данных
Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее входа в систему до выдачи пользователю.

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

Основные компоненты диаграмм потоков данных
Основными компонентами диаграмм потоков данных являются:
внешние сущности
системы и подсистемы
процессы
накопители данных
потоки данных.

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

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

Система и подсистема
При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы, либо в виде ряда подсистем.
Наименование системы/подсистемы представляется в виде словосочетания с отглагольным существительным (рассмотрение повестки дня, решение задачи, получение денег и т.п.).

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

Процесс
!!!!! Процесс отличается от системы/подсистемы по полю наименования!!!!

Накопитель данных
Это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь.
Примеры: ящик в картотеке, таблицы в ОЗУ, файл на электронном носителе
Примечание: В нотациях Гейна-Сарсона и Йордона-ДеМарко графическое представление данного элемента аналогичное.

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

Нумерация объектов

Уровни DFD-модели
Уровень системы

Построение иерархии DFD
1. Построение диаграмм уровня системы и подсистемы

Построение иерархии DFD
2. Построение диаграмм уровня процесса

Пример DFD-модели
постройки дачного домика
1. Контекстная диаграмма уровня системы

Пример DFD-модели
постройки дачного домика
2. Диаграмма уровня подсистемы

Пример DFD-модели
постройки дачного домика
3. Диаграмма уровня процесса

Методология моделирования процессов IDEF3

Что отражает модель IDEF3?
В общем случае, процесс – это упорядоченная последовательность действий.
Следовательно, процессная модель IDEF3 позволяет:
Отразить последовательность процессов
Показать логику взаимодействия элементов системы.
Цель IDEF3 - дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также объекты, участвующие совместно в одном процессе.

Основные компоненты IDEF3-модели
Основными элементами IDEF3-модели являются:
1) единицы работ;
2) связи;
3) перекрестки;
4) объекты ссылок.

Единицы работ
Единица работ (UOW, Unit of Work) является центральным компонентом модели.

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

Связь «старшая стрелка»
Связь типа «временное предшествование» - Precedence
Соединяет единицы работ
Показывает, что работа-источник должна быть закончена прежде, чем начнется работа-цель

Стрелка отношений
Связь типа нечеткое отношение - Relational
Изображается в виде пунктирной линии, используется для изображения связи между единицами работ, а также между единицами работ и объектами ссылок

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

Перекрестки (соединения)
Используются для отображения логики взаимодействия стрелок при их слиянии или разветвлении, для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.
Различают перекрестки для слияния и разветвления стрелок.
Перекрестки не могут быть одновременно использованы для слияния и разветвления стрелок.
Все перекрестки на диаграммах нумеруются, каждый номер имеет префикс J.
В отличие от других методологий (IDEF0, DFD) стрелки могут сливаться или разветвляться только через перекрестки.

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

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

Правила создания перекрестков
1. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.
2. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ»

Правила создания перекрестков
3. Перекресток для слияния «И» не может следовать за перекрестком типа исключительного «ИЛИ»

Правила создания перекрестков
4. Перекресток для слияния типа исключительного «ИЛИ» не может следовать за перекрестком для разветвления типа «И»
5. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

Примеры

Примеры

Примеры

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

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

Объект ссылок
Официальная спецификация IDEF3 различает 3 стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous), асинхронные (asynchronous).
BPWin поддерживает только безусловные объекты ссылок.

Типы объектов ссылок

Типы объектов ссылок

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

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

Структура множественной декомпозиции работ

Пример построения модели IDEF3
Рассмотрим на примере построения динамической модели процесса «Выполнение курсовой работы»
Начнем с построения контекстной диаграммы

Пример построения модели IDEF3
Примечание: Обратите внимание на нумерацию единиц работ. Родительской является работа с собственным номером 1. Она декомпозируется первый раз, следовательно, версия декомпозиции = 1, далее следует собственный номер единицы работ в рамках модели (2-7).
Выполним декомпозицию контекстной диаграммы:

Пример построения модели IDEF3
Выполним декомпозицию UOW №4 – «Выполнение разделов к/р»

Пример построения модели IDEF3
Продекомпозируем повторно контекстную диаграмму (в виде сценария IDEF3 для выполнения курсовой работы по «Информатике и программированию»)

Нотация моделирования бизнес-процессов BPMN

Основные вопросы
Что такое BPMN?
Обзор программных продуктов
Основные компоненты BPMN и их назначение
Пример
Рекомендуемая литература

Что такое BPMN?
Нотация по моделированию бизнес-процессов (The Business Process Modeling Notation, BPMN)
Разработка BPMI – Business Process Management Institute
Май, 2004 – BPMN 1.0 – выпуск первой редакции
Далее – BPMN 1.1, 1.2.
Текущая версия – BPMN 2.0
Модель в нотации BPMN – BPD (Business Process Diagram)

Особенность BPMN
BPMN

К вопросу программного обеспечения
Некоторые программные продукты (так называемые BPM-системы):
1) Oracle BPM Suite (Oracle Corp.)
2) Unify NXJ (Unify Corp.)
3) IBM Web Sphere Business Modeler Advanced (IBM)
4) Lombardi Teamworks (Lombardi Software → с недавних пор IBM, в скором времени будет интегрирован в линейку программных продуктов WebSphere)
5) SAP Netweaver BPM (SAP)
6) TIBCO iProcess Suite (TIBCO Software Inc.)
7) Intalio (Intalio)
8) Active Modeler Avantage (KAISHA Tec. Company)
9) Runa WFE (Консалтинговая группа «Руна»)
И др.

Основные элементы модели бизнес-процесса BPMN
Выделяют четыре основные категории элементов:
Объекты потока управления (Flow Objects): события, действия и логические операторы
Соединяющие объекты (Connecting Objects): поток управления, поток сообщений и ассоциации
Роли или зоны ответственности (Swimlanes): пулы и дорожки
Артефакты (Artifacts): данные, группы и текстовые аннотации.

Объекты потока управления

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

Триггеры (маркеры) событий

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

Подпроцесс (Sub-Process)
2 уровня представления подпроцессов
Стандартное представление подпроцесса
Подпроцесс в IBM WebSphere Business Modeler

Маркеры подпроцессов

Задача (Task)
Задача с маркером
Задача в IBM WebSphere Business Modeler

Шлюзы (Gates)
Шлюзы используются для контроля расхождений и схождений потока операций. Термин шлюз подразумевает пропускное устройство, которое либо позволяет осуществлять переход через шлюз, либо нет.
Виды шлюзов (Gates):
Эксклюзивный шлюз (ИЛИ)
Неэксклюзивный шлюз (ИЛИ)
Комплексный шлюз
Параллельный шлюз (И)

Эксклюзивные шлюзы (ИЛИ) – Exclusive Gates (XOR)

Эксклюзивные шлюзы (ИЛИ) – Exclusive Gates (XOR)
Эксклюзивные шлюзы, основанные на данных (Data-based)
Пример: Фрагмент модели процесса заказа товара через интернет

Эксклюзивные шлюзы (ИЛИ) – Exclusive Gates (XOR)

Эксклюзивные шлюзы (ИЛИ) – Exclusive Gates (XOR)
Эксклюзивный шлюз, основанный на данных (с маркером)
Пример: Фрагмент модели сдачи лабораторных работ

Эксклюзивные шлюзы (ИЛИ) – Exclusive Gates (XOR)
Это одно и то же!!

Эксклюзивные шлюзы (ИЛИ) – Exclusive Gates (XOR)
Шлюзы для слияния…
1)
2)

Эксклюзивные шлюзы (ИЛИ) – Exclusive Gates (XOR)
Эксклюзивные шлюзы, основанные на событиях (Event-based)

Параллельный шлюз (И) – Parallel Gateway (AND)
Параллельный шлюз для разветвления: После задачи А параллельно начинаются задачи В и С
Параллельный шлюз для слияния: Перед началом задачи F заканчиваются задачи C и D.

Параллельный шлюз (И) – Parallel Gateway (AND)
Пример: Процесс «Выполнение расчетно-графической работы»

Параллельный шлюз (И) – Parallel Gateway (AND)
Возможен и такой вариант:

Соединяющие элементы (Connecting Objects)
Спецификация BPMN выделяет следующие виды соединяющих элементов:
Поток операций (Sequence)
Поток сообщений (Message)
Ассоциация (Association)

Зоны ответственности (Swimlanes: Pools and Lanes)
Пул = Участник Процесса = Бизнес-роль

Пример модели с разделением на зоны ответственности

Артефакты