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

1.

Моделирование производственных
бизнес-процессов
Ризванов Константин Анварович
доцент каф. АСУ
6-215а

2. БРС

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

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

19. Сущность структурного подхода к моделированию систем

Система разбивается на функциональные подсистемы,
которые, в свою очередь, делятся на подфункции,
подфункции – на задачи и т.д. до конкретных процедур
Функция 1
Система
Функция 2
…
…
…
Подфункция 1
Задача 1
Подфункция 2
Задача 2
…
Подфункция n
Функция n
…
…
Задача n
…
…
…
…

20. Базовые принципы структурного подхода

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

21. Методология структурного анализа и проектирования

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

22. Модели структурного подхода

3 типа моделей, используемых в структурном подходе:
1) функциональные модели (ФМ)
2) информационные модели (ИМ)
3) динамические модели (ДМ)
ФМ
SADT (IDEF0)-модели
DFD-модели
Пакеты BPWin, Design/IDEF
Пакет BPWin
ИМ
ERD (IDEF1X)
Пакеты Design/IDEF, ERWin
ДМ
IDEF/CPN
IDEF3
Пакет Design/IDEF
Пакет BPWin

23. Сущность функционального моделирования

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

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

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

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

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

26. Интерфейсная дуга

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

27. Интерфейсная дуга

Ресурсы,
перерабатываемые
системой
управление
вход
Регулирует работу
системы, управляет
(нормативная
документация и т.п.)
выход
Функциональный
блок
А0
Ресурсы, необходимые для
проведения работы
(человеческие ресурсы,
оборудование, ИС).
механизм
Результат работы
системы,
переработанные
ресурсы, продукт
деятельности
Стрелки входа может не быть. Остальные интерфейсные дуги обязательны.

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

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

29. Цель моделирования

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

30. Точка зрения

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

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

Контекстная
диаграмма
А0
Цель:
Т.зрения:
А-0
Декомпозиция
контекстной
диаграммы
А1
А2
А3
А0
А11
А31
А12
А32
А13
А1
Декомпозиция блока А1
А33
А3
Декомпозиция блока А3

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

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

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

Номер
функционального
блока на
контекстной
диаграмме
Формат номера
блока:
1. Префикс
2. Номер
родительской
работы
3. Собственный
порядковый
номер
Номер контекстной
диаграммы
А0
Цель:
Т.зрения:
А-0
Диаграммы
декомпозиции
имеют номер
декомпозируемого
блока
А1
А2
А3
А0
А11
А31
А12
А32
А13
А1
А33
А3

34. Основные правила построения диаграмм

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

35. Основные правила построения диаграмм

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

36. Основные правила построения диаграмм

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

37. Основные правила построения диаграмм

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

38. Граничные стрелки

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

39. Тоннельные стрелки

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

40. Глоссарий и FEO-страница

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

41. Мастерская страница (каркас диаграммы)

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

42. Мастерская страница

USED AT:
AUTHOR: FIO
DATE: 27. 02.2009
WORKING
PROJECT: model1
REV:
DRAFT
27. 02.2009
READER
DATE CONTEXT:
TOP
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Поле рабочей информации
Статусы проекта:
Сведения оСведения о
родительской
1) Рабочая версия –читателяхдиаграмма
с
работе
большим числом изменений
стадии
экспертахна
и дате
Сведения о модели:
разработки
экспертизы
-автор;
2) Эскиз имеет меньше изменений и
свидетельствует о достижении
-название проекта;
некоторого согласия ряда читателей
Поле
сообщений
-замечания;
3) Рекомендовано – сопутствующие
тексты утверждены
-дата создания и пересмотра.
4) Публикация – материал может
печататься.
Номер
диаграммы
Название диаграммы
(совпадает с названием
родительской работы)
Поле идентификации
NODE:
TITLE:
A-0
Уникальный
номер версии
диаграммы
NUMBER:

43. Пример модели процесса постройки садового домика

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

44. Пример модели процесса постройки садового домика

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

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

USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 27.02.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
NOTES: 1 2 3 4 5 6 7 8 9 10
READER
DATE CONTEXT:
TOP
Проект дома
Материалы
Дом
Построить
дом
A0
Цель: определить действ ия, необходимые
для постройки дачного домика
Строители
Точка зрения: Владельца дачного у частка
NODE:
TITLE:
A-0
Построить дом
NUMBER:

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

USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 10.03.2010
WORKING
DRAFT
RECOMMENDED
PUBLICATION
C1
Проект дома
NOTES: 1 2 3 4 5 6 7 8 9 10
Материалы
I1
Заложить
фу ндамент
A1
READER
DATE CONTEXT:
A-0
Фу ндамент
Возв ести
стены
Стены
A2
Положить
крышу
Крыша
A3
Выполнить
отделочные
работы
A4
Каменщики
Кров ельщики
Плотники
M1
NODE:
TITLE:
A0
Мастера
по отделке
Строители
Построить дом
NUMBER:
Дом
O1

47. Дерево узлов

USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE CONTEXT:
TOP
A-0
Построить
дом
A0
Заложить
фу ндамент
Возв ести
стены
A1
A2
NODE:
Положить
крышу
TITLE:
A0
A3
Выполнить
отделочные
работы
A4
Построить дом
NUMBER:

48. FEO-страница

USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE CONTEXT:
A-0
Проект дома
Материалы
Фу ндамент
Заложить
фу ндамент
A0.1
Стены
Возв ести
стены
A0.2
Положить
крышу
A0.3
Крыша
Выполнить
отделочные
работы
A0.4
Каменщики
Плотники
Кров ельщики
Мастера
по отделке
Строители
NODE:
TITLE:
A0F
Построить дом
NUMBER:
Дом

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

50. Основные вопросы

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

51. Что такое IDEF1X?

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

52. Что такое IDEF1X?

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

53. Определение сущности

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

54. Понятие атрибута

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

55. Понятие отношения

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

56. Правила определения сущности

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

57. Правила определения сущности

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

58. Графическое представление сущности

Различают следующие уровни представления сущности:
диаграмма «сущность-связь» (ERD), модель данных,
основанная на ключах (KB), полная атрибутивная модель
(FA)
Студент
Поле
наименования
Первичный
ключ
Вид сущности на
диаграмме ERD
Неключевые
атрибуты
Студент
№_зачетнойКнижки
ФИО
Группа
Специальность
пол
дата_рождения
дом_адрес
семейное_положение
Вид сущности на диаграмме FA

59. Правила определения атрибутов

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

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

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

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

Студент
№_зачетнойКнижки
ФИО
Группа
Специальность
пол
дата_рождения
дом_адрес
семейное_положение
Студент
ФИО
дата_рождения
№_зачетнойКнижки
Группа
Специальность
пол
дом_адрес
семейное_положение
№_зачетнойКнижки – первичный
простой ключ;
ФИО+дата_рождения –
первичный составной ключ;
ФИО+дата_рождения –
альтернативный ключ
№_зачетнойКнижки –
альтернативынй ключ

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

Сущность IDEF1X
Независимая
представляет собой
независимые данные,
которые всегда
присутствуют в
системе, при этом
отношения с другими
сущностями могут как
существовать, так и
отсутствовать
Зависимая
представляет
данные, зависимые
от других сущностей
в системе, поэтому
она всегда должна
иметь отношения с
другими сущностями

63. Типы зависимых сущностей

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

64. Типы зависимых сущностей

3.
Ассоциативная - сущность, связанная с несколькими
родительскими сущностями. Такая сущность содержит
информацию о связях сущности
Расписание
Преподаватель
ФИО
кафедра
дисциплина
должность
ученая степень
ФИО (FK)
кафедра (FK)
дисциплина (FK)
№группы (FK)
курс (FK)
время
аудитория
Группа
№группы
курс
список студентов
Ассоциативная сущность

65. Типы зависимых сущностей

4.
Именующая - частный случай ассоциативной сущности,
не имеет собственных атрибутов, только атрибуты
родительской сущности
Расписание
Преподаватель
ФИО
кафедра
дисциплина
должность
ученая степень
ФИО (FK)
кафедра (FK)
дисциплина (FK)
№группы (FK)
курс (FK)
время
аудитория
Занятие
ФИО (FK)
кафедра (FK)
дисциплина (FK)
№группы (FK)
курс (FK)
время (FK)
аудитория (FK)
Группа
№группы
курс
список студентов
Именующая
Именующая
сущность
сущность

66. Правила отношений

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

67. Виды отношений

А1/1
ПК_А1
А_А1
А1/1
ПК_А1
А_А1
А1/1
а) идентифицирующее отношение
Сущность А1 однозначно определяет
ПК_А2
сущность А2. Ее первичный ключ
ПК_А1 (FK)
наследуется в качестве первичного
А_А2
ключа сущностью А2 (внешний ключ)
б) неидентифицирующее отношение
А2/2
Сущность А1 связана с сущностью А2,
ПК_А2
но однозначно не определяет ее.
ПК_А1 (FK) Первичный ключ сущности А1
А_А2
наследуется в качестве неключевого
атрибута сущности А2
А2/2
А2/2
ПК_А1
ПК_А2
А_А1
А_А2
в) отношение «многие-ко-многим»
(неспецифическое). Сущности А1 и А2
имеют формальную связь, но
наследования атрибутов не
происходит.
г) отношение категоризации (см.
далее)

68. Правила отношений

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

69. 4 типа мощности отношений

а) общий случай, когда одному экземпляру родительской
сущности соответствуют 0, 1 или много экземпляров
дочерней сущности
А2/2
А1/1
ПК_А2
ПК_А1 (FK)
ПК_А1
А_А1
А_А2
б) когда одному экземпляру родительской сущности
соответствует 1 или много экземпляров дочерней (0
исключается).
А2/2
А1/1
ПК_А2
ПК_А1 (FK)
ПК_А1
А_А1
P
А_А2

70. 4 типа мощности отношений

в) когда одному экземпляру родительской сущности
соответствует 0 или 1 экземпляр дочерней сущности.
А2/2
А1/1
ПК_А2
ПК_А1 (FK)
ПК_А1
А_А1
Z
А_А2
г) когда одному экземпляру родительской сущности
соответствует заранее заданное число экземпляров
дочерней сущности.
А2/2
А1/1
ПК_А2
ПК_А1 (FK)
ПК_А1
А_А1
5
А_А2

71. Отношения категоризации

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

72. Пример отношений категоризации

Сотрудник
Табельный_номер
ФИО
Дата_рождения
Должность
Тип
Z
Тип
Z
Постоянный сотрудник
Табельный_номер (FK)
Z
Совместитель
Табельный_номер (FK)
Описание: Могут быть выделены следующие типы сотрудников:
постоянный и совместитель. Категоризация неполная, т.к. могут быть и
другие типы, например, консультанты. Тип – признак категоризации

73. Правила отношений категоризации

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

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

Сотрудник
Табельный_номер
ФИО
Дата_рождения
Должность
Тип
Z
Тип
Z
Z
Постоянный сотрудник
Совместитель
Табельный_номер (FK)
Табельный_номер (FK)
пол
Z
пол
Z
М
Табельный_номер (FK)
Z
Ж
Табельный_номер (FK)

75. Правила отношений категоризации

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

76. Основные правила построения информационной модели

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

77. Основные правила построения информационной модели

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

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

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

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

2. Определим сущности
Проект дома
Материал
Дом
Строитель
Фундамент
Стены
Крыша
Каменщ ик
Кровельщ ик
Плотник
Мастер по отделке

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

Материал
Проект дома
№_проекта
Код_материала
ФИО_архитектора
Дата_создания
Стоимость_проекта
Название
Вид_материала
Характеристики
3. Зададим атрибуты для каждой сущности и
установим связи между ними
используется
используется для
P
Строитель
P
Табельный_номер
Дом
ФИО
Профессия
Стаж_работы
Адрес
Адрес
ФИО_хозяина
строит
Фундамент
Стены
Крыша
№_проекта (FK)
Код_материала (FK)
Табельный_номер (FK)
Вид
Дата_сдачи
Z
Профессия
Z
Каменщ ик
Табельный_номер (FK)
Z
Кровельщ ик
Табельный_номер (FK)
Z
Плотник
Табельный_номер (FK)
Z
Мастер по отделке
Табельный_номер (FK)

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

82. Что такое DFD-модель

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

83. Что такое DFD-модель?

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

84. Основные компоненты диаграмм потоков данных

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

85. Нотации, используемые в DFD-моделировании

Нотации, используемые в DFDмоделировании
Нотации
DFD-моделирования
Гейна-Сарсона
(Gene-Sarson)
Йордона-ДеМарко
(Yordon-DeMarco)
Примечание. В зависимости от используемой нотации графическое
представление элементов диаграмм будет различным

86. Внешняя сущность

• Представляет собой материальный объект или физическое
лицо, являющееся источником или приемником информации
(например, заказчики, клиенты, поставщики, склад, персонал,
банк).
USED
AT: AUTHOR:
asu
• Внешняя сущность находится за
пределами
границ
PROJECT: уу
анализируемой системы.
• Одна и та же внешняя сущность может быть
использована
NOTES:
1 2 3 4 5 6
многократно на одной или нескольких диаграммах.
1
Имя
Внешняя сущность в
нотации Йордона-ДеМарко
Имя
Внешняя сущность в
нотации Гейна-Сарсона
7 8 9

87. Система и подсистема

• При построении модели сложной системы она может быть
представлена в самом общем виде на так называемой контекстной
диаграмме в виде одной системы, либо в виде ряда подсистем.
• Наименование системы/подсистемы представляется в виде
словосочетания с отглагольным существительным (рассмотрение
повестки дня, решение задачи, получение денег и т.п.).
Поле идентификации
1
Система/подсистема
Наименование
системы
в нотации ГейнаСарсона
Персонал, оборуд-е
Имя системы/
подсистемы
1
или
имя
Поле имени
Поле физической реализации
Система/подсистема в
нотации ЙордонаДеМарко

88. Процесс

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

89. Процесс

Поле идентификации
1.1
Наименование
процесса
Поле имени
Персонал, оборуд-е
Имя
процесса
Поле физической реализации
1
или
Процесс в нотации
Гейна-Сарсона
имя
Процесс в нотации
Йордона-ДеМарко
!!!!! Процесс отличается от системы/подсистемы по
полю наименования!!!!

90. Накопитель данных

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

91. Поток данных

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

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

USED AT:
Нумерация объектов
AUTHOR: asu
PROJECT: уу
USED AT:
AUTHOR:
asu
DATE:
06.03.2009
USED AT: AUTHOR: asu
PROJECT:
уу
REV:
06.03.2009
PROJECT:
уу
DATE:
WORKING
DAT
DRAFT REV:
REV
RECOMMEND
1 2 31 2
4 35 46 PUBLICATION
NOTES:
57 687 98 10
9 10
NOTES: 1 2 3 4 5 6 7 8 9 10 NOTES:
Системы, подсистемы
Процессы
2.1
E1
1
Имя
Наименование
процесса
Наименование
подсистемы
WORKING
READER
2
[Префикс]+номер
родительской
DRAFT
RECOMMENDED номер
[Префикс] + собственный номер подсистемы+собственный
USED AT:
AUTHOR: asu
PROJECT: уу
DATE: 06.03.2009
REV:
06.03.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
Внешние сущности
PUBLICATION
Хранилища данных
0
E1
Имя
D1 Имя
Наименование
системы
[Префикс]+номер
[Префикс]+номер

93. Уровни DFD-модели

Уровень системы
Уровень подсистемы
Уровень процесса

94. Построение иерархии DFD

AUTHOR: 1
PROJECT: 1
DATE: 02.03.2009
REV: 02.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
Построение иерархии DFD
NOTES: 1 2 3 4 5 6 7 8 9 10
1. Построение диаграмм уровня системы и подсистемы
1
Преподаватель
2
Знания
Деканат
Сведения об
успеваемости
0р.
A0
Обучение
в университете
Книги
3
Библиотека
Оснащ ение
4
Дисплейные
классы
DATE CO

95. Построение иерархии DFD

USED AT:
DATE: 02.03.2009
WORKING
READER
Построение
иерархии
DFD
REV: 02.03.2009
DRAFT
AUTHOR: 1
PROJECT: 1
DATE CONTEXT:
RECOMMENDED
2. Построение
NOTES: 1 2 3 4 5диаграмм
6 7 8 9 10 уровня процесса
PUBLICATION
5
Клиенты
БД
1 заказов
Сведения
о заказе
0р.
Заказы
A1
Информация о доставке
Сведения о
клиенте
Обработать
заказы
A-0
6
3
Данные о клиенте
БД
клиентов
Данные о клиенте
Склад
Продукция
Данные счета
0р.
2 БД счетов
Данные счета
A2
Проконтроллировать
оплату
A3 Продукция
0р.
Доставить
продукцию
Платежные документы
5
Клиенты

96. Пример DFD-модели постройки дачного домика

Пример DFD-модели
USED AT:AUTHOR: Шилина постройки
DATE: 10.03.2010
WORKING
READER
дачного
домика
PROJECT : Постройка домаREV: 10.03.2010
DATE CONTEXT:
DRAFT
1. Контекстная диаграмма уровня системы
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Проект дома
0р.
3
Магазин
1
Архитектор
0
Прайс-лист на
материалы
Пос тройка
дома
Акт приемки
2
Заказчик
TOP

97. Пример DFD-модели постройки дачного домика

USED AT:AUTHOR: Шилина
DATE: 10.03.2010
PROJECT:
Постройка
дома
REV: 10.03.2010
2. Диаграмма уровня подсистемы
WORKING
READER
DRAFT
RECOMMENDED
PUBLICATION
NOTES: 1 2 3 4 5 6 7 8 9 10
Проект
Спис ок
дома
ис правлений
0р.
Согласование
проекта
Прайс-лист на
материалы
DATE CONT EXT:
A-0
2
Заказчик
1
Утвержденный
проект
0р.
2
Выполнение
строительных
работ
Чеки на
материалы
1 Документация
Акты
выполненных
работ
0р.
3
Сдача
работ
Акт
приемки

98. Пример DFD-модели постройки дачного домика

USED AT:AUTHOR: Шилина
DATE: 10.03.2010
3. Диаграмма
уровнядома
процесса
PROJECT: Постройка
REV: 10.03.2010
WORKING
READER
DRAFT
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Утвержденный
Чеки на материалы
проект
0р.
1
Заложить
фундамент
Прайс-лист на
материалы
DATE CONT EXT:
A0
Акты
выполненных
работ
0р.
2
Возвести
стены
0р.
3
Положить
крышу
0р.
4
Выполнить
отделку

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

100. Что отражает модель IDEF3?

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

101. Основные компоненты IDEF3-модели

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

102. Единицы работ

AT:
AUTHOR: as u
PROJECT: 123
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE: 18.03.2009
REV: 18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
CONTEXT:
TOP
Единицы работ
• Единица работ (UOW, Unit of Work) является
центральным компонентом модели.
Номер работы
является
уникальным,
присваивается
при ее создании и
не меняется
никогда
Им я работы
1.1
Словосочетание с
отглагольным
существительным,
изображающим
действие
(выполнение,
изготовление,…)
Или
Инфинитив
глагола
(изготовить
продукцию)

103. Связи

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

104. Связь «старшая стрелка»

AUTH OR: as u
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WOR KING
DR AFT
REC OMMEN DED
PUBLICATION
READER
DATE
• Связь типа «временное предшествование» - Precedence
NOTES: 1 2 3 4 5 6 7 8 9 10
• Соединяет единицы работ
• Показывает, что работа-источник должна быть закончена
прежде, чем начнется работа-цель
Принятие
рекомендаций
рецензента
Внесение
исправлений
1.1
1.2
1.1
1.1´ 1.2
1.2´
CONTEXT
TO

105. Стрелка отношений

TH OR: as u
ROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WOR KING
DR AFT
REC OMMEN DED
PUBLICATION
READER
• Связь типа нечеткое отношение - Relational
OTES: 1 2 3 4 5 6 7 8 9 10
• Изображается в виде пунктирной линии,
используется для изображения связи между
единицами работ, а также между единицами
работ и объектами ссылок
Принятие
рекомендаций
рецензента
Внесение
исправлений
1.1
1.2
1.1
1.2
1.1´ 1.2´
DATE
CON

106. Поток объектов

HOR: as u
JECT: 123
ES: 1
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
• Стрелка, изображающая поток объектов - Object Flow
2• 3 Применяется
4 5 6 7 8 9 10
для описания того факта, что объект
используется в двух и более единицах работ,
например, когда объект порождается в одной работе
и используется в другой
Получение
счета
на оплату услуг
1.1
Оплата
1.2
C

107. Перекрестки (соединения)

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

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

Обозначение
Наименов
ание
Смысл в случае
слияния стрелок
Смысл в случае
разветвления стрелок
Асинхрон- Все предшествующие Все последующие
ное «И»
процессы должны
процессы должны быть
быть завершены
Синхронное «И»
запущены
Все предшествующие Все последующие
процессы должны
процессы запускаются
быть завершены
одновременно
одновременно
Асинхрон- Один или несколько
ное
предшествующих
процессов должны
«ИЛИ»
быть завершены
Один или несколько
следующих процессов
должны быть запущены

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

Обозна- Наименов
ание
чение
Смысл в случае
слияния стрелок
Синхронн Один или несколько
ое «ИЛИ» предшествующих
процессов должны
быть завершены
Эксклюзи
вное
(исключа
ющее)
«ИЛИ»
Смысл в случае
разветвления стрелок
Один или несколько
следующих процессов
должны быть
запущены
одновременно
одновременно
Только один
предшествующий
процесс должен
Только один
следующий процесс
быть завершен
запускается

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

:
Правила создания перекрестков
1. Каждому перекрестку
слияния должен
DATE:для
18.03.2009
WORKING
READER
REV:
18.03.2009
DRAFT
предшествовать перекресток
для разветвления.
RECOMMENDED
2. Перекресток
следовать за
NOTES:
1 2 3 4 5 6 7 8 9для
10 слияния «И» не может
PUBLICATION
перекрестком для разветвления типа синхронного или
асинхронного «ИЛИ»
AUTHOR: asu
PROJECT: 123
2.1.6
O
2.1.5
&
J1
J2
2.1.7
2.1.8
DAT

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

AUTHOR: asu
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
3. Перекресток для слияния «И» не может следовать
NOTES: 1 2 3 4 5 6 7 8 9 10
за перекрестком типа исключительного «ИЛИ»
2.1.6
X
2.1.5
&
J1
J2
2.1.7
2.1.8
DAT

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

AT:
AUTHOR: asu
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
Правила создания перекрестков
NOTES: 1 2 3 4 5 6 7 8 9 10
4. Перекресток для слияния типа исключительного «ИЛИ» не
может следовать за перекрестком для разветвления типа
«И»
2.1.6
&
2.1.5
X
J1
J2
2.1.8
2.1.7
5. Перекресток, имеющий одну стрелку на одной
стороне, должен иметь более одной стрелки на другой.
DATE

113. Примеры

UT HOR: asu
ROJECT : р
DAT E: 18 .03.200 9
REV: 18 .03.200 9
WO RKING
READER
DAT E
CON
DRAFT
RECOM MENDED
OTES: 1 2 3 4 5 6 7 8 9 10
PUBLICAT ION
1
Примеры
Включен ие
по жар ной
си гна лизации
1.1 .3
Обн аружени е
по жар а
1.1 .2
Набо р
но ме ра
01
O
J1
1.1 .4
Самосто яте льн ое
тушени е
по жар а
1.1 .5
За пис ь
в жур нале
де журс тв
O
J2
1.1 .6

114. Примеры

RECOM MENDED
1
PUBLI CAT ION
Примеры
Оплата
на личн ыми
1.1 .7
X
X
J4
J3
Безналичная
оп лата
1.1 .8

115. Примеры

RECOMMENDED
PUBLICATION
1
Примеры
Выстрел
из стартового
пистолета
1.1.3
Начало
состязания
1.1.2
Запуск
секундомера
&
J1
1.1.4
J2
Начало
забега
1.1.5
&

116. Комбинации перекрестков

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

117. Объект ссылок

• выражает идею, концепцию данных, которые
нельзя связать со стрелкой, перекрестком,
03.2009
WORKING
READER
DATE CONTEXT:
работой
03.2009
DRAFT
RECOMMENDED
• используется
при построении диаграммы для
PUBLICATIONвнимания пользователя к каким1.1
привлечения
либо важным аспектам модели
Тип / Имя объекта
ссылок

118. Объект ссылок

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

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

Тип
объекта
ссылок
Назначение
1. Object
Используется для описания того, что в действии
принимает участие какой-либо заслуживающий
отдельного внимания объект
2. Ссылка
Используется для реализации цикличности
выполнения действий. Этот объект также может
относиться к перекрестку
GOTO
3. Единица Используется для многократного отображения на
действий
диаграмме одного и того же действия, но без цикла
UOB (Unit of
Behavior)

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

Тип объекта
ссылок
Назначение
4. Заметка
(Note)
Используется для документирования какой-либо
важной информации общего характера,
относящейся к изображаемому на диаграммах.
Служит альтернативой методу помещения
текстовых заметок непосредственно на диаграммах
5. Уточнение
Elaboration
(ELAB)
Для уточнения или более подробного описания
изображаемого на диаграмме. Обычно
используется для детального описания
разветвления или слияния стрелок на перекрестках

121. Декомпозиция работ в IDEF3

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

122. Нумерация работ в IDEF3

X
1.1.2
Нумерация
работ в IDEF3
J1
J2
• Номер работы состоит из номера
родительской работы, версии
декомпозиции и собственного номера
работы на текущей диаграмме
Номер родительской
работы
Версия
декомпозиции
1.1.7
Собственный номер
единицы работ
1.1
1.1

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

USED AT:
AUTHOR: Øèëèíà Ì.À.
DATE: 18.03.2009
WORKING
PROJECT: ï
REV: 18.03.2009
DRAFT
READER
DATE CONTE
Структура множественной
декомпозиции работ
RECOMMENDED
AUTHOR: 1
PROJECT: 1
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
DATE: 19.03.2009
WORKING
REV:
DRAFT
19.03.2009
2.1
READE
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
Первая
декомпозиция
работы 1.2
PUBLICATION
1.1
1.2
2.1.4
2.1.5
Вторая
декомпозиция
работы 1.2
2.2.7
NODE:
1.3
2.1.6
2.2.8
TITLE:
2.2.9
Context
NUMBER:

124. Пример построения модели IDEF3

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

125. Пример построения модели IDEF3

Выполним декомпозицию контекстной диаграммы:
Выполнение
разделов к/р
Получение
задания
1.1.2
Подбор
литературы
1.1.3
1.1.4
&
&
J1
Посещение
консультаций
J2
Оформление
пояснит.
записки
1.1.6
1.1.5
OBJECT/
Преподаватель
Защита
1.1.7
Примечание: Обратите внимание на нумерацию единиц работ. Родительской
является работа с собственным номером 1. Она декомпозируется первый раз,
следовательно, версия декомпозиции = 1, далее следует собственный номер
единицы работ в рамках модели (2-7).

126. Пример построения модели IDEF3

Выполним декомпозицию UOW №4 – «Выполнение разделов к/р»
ELAB/ Если есть ошибки
в расчетах – внесение
исправлений
Выполнение
расчетов
4.1.9
Написание
теор.части
4.1.8
Оформление
Х
&
&
Х
4.1.11
J6
J3
J4
Построение
графиков
4.1.10
J5

127. Пример построения модели IDEF3

Продекомпозируем повторно контекстную диаграмму (в виде сценария IDEF3
для выполнения курсовой работы по «Информатике и программированию»)
Построение
блок-схемы
1.2.13
Получение
задания
1.2.12
&
&
J7
Написание
программы
Математическое
моделирование
J8
1.2.15
1.2.14
GOTO/ При обнаружении
ошибок при тестировании
возврат к 1.2.15
Тестирование
и отладка
1.2.16
Оформление
поясн. записки
1.2.17

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

129. Основные вопросы

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

130. Что такое 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)

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

BPMN
Простая
графическая нотация
Комплексная
нотация
(Simple Notation)
(Powerful Notation)

132. К вопросу программного обеспечения

• Некоторые программные продукты (так называемые 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 (Консалтинговая группа «Руна»)
И др.

133. Основные элементы модели бизнес-процесса BPMN

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

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

События
Действия
Шлюзы

135. Событие

• Событие – это то, что происходит в течение бизнеспроцесса и оказывает влияние на его ход. Чаще всего
событие имеет причину (триггер) или воздействие
(результат).
Виды событий
Стартовое
событие
(Start Event)
Промежуточное
событие
(Intermediate
Event)
Конечное
событие
(End Event)

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

137. Действия

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

138. Подпроцесс (Sub-Process)

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

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

Маркер
цикла
Многоэкземплярный
маркер
Маркер
Ad-Hoc
Маркер
Компенсации

140. Задача (Task)

Задача с маркером
Задача в IBM WebSphere
Business Modeler
Общий вид
задачи
Ручное
выполнение
Задача
бизнесправил

141. Шлюзы (Gates)

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

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

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

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

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

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

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

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

Это одно и то же!!

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

• Шлюзы для слияния…
1)
2)

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

• Эксклюзивные шлюзы, основанные на событиях (Event-based)

149. Параллельный шлюз (И) – Parallel Gateway (AND)

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

150. Параллельный шлюз (И) – Parallel Gateway (AND)

• Пример: Процесс «Выполнение расчетно-графической работы»

151. Параллельный шлюз (И) – Parallel Gateway (AND)

• Возможен и такой вариант:

152. Соединяющие элементы (Connecting Objects)

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

153. Зоны ответственности (Swimlanes: Pools and Lanes)

Пул =
Участник
Процесса =
Бизнесроль
Дорожки = Подразделения внутри Пула

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

155. Артефакты

Текстовая
аннотация
Объект данных
Группа

156. BPD с артефактами