🗊Презентация Разработка поведенческой модели

 РАЗРАБОТКА ПОВЕДЕНЧЕСКОЙ МОДЕЛИ

- блок-схемы алгоритмов; - EPC-диаграммы; - методология BPMN

БЛОК-СХЕМЫ АЛГОРИТМОВ ГОСТ 19.701-90 под схемой понимается графическое представление определения, анализа или метода решения задачи. С помощью схем можно отобразить как статические, так и динамические аспекты системы. Символы, приведенные в государственном стандарте, могут использоваться в следующих типах схем: схемы данных – определяют последовательность обработки данных и их носители; схемы программ – отображают последовательность операций в программе (по сути, это и есть блок-схемы алгоритмов в традиционном понимании); схемы работы системы – отображают управление операциями и потоки данных в системе; схемы взаимодействия программ – отображают путь активации программ (модулей) и их взаимодействие с соответствующими данными; схемы ресурсов системы – отображают конфигурацию блоков данных и обрабатывающих блоков.

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

Условные обозначения на блок-схемах

СИМВОЛЫ ДАННЫХ. Основные

СИМВОЛЫ ДАННЫХ. Специфические

СИМВОЛЫ ПРОЦЕССА. Основной

СИМВОЛЫ ПРОЦЕССА. Специфические

СИМВОЛЫ ЛИНИЙ. Основной

СИМВОЛЫ ЛИНИЙ. Специфические

СПЕЦИАЛЬНЫЕ СИМВОЛЫ

Правила и рекомендации построения блок-схем 1. Допускается зеркально отображать символы и поворачивать их вокруг оси. В частности, запоминающие устройства с прямым доступом (таблицы на жестком диске) на схемах, как правило, поворачивают на 90опротив часовой стрелки. 2. Большинство символов допускают задание внутри них текстовых пояснений. Если текст не помещается внутри символа, то лучше его приводить, используя комментарии. 3. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами потоки данных или управления в местах пересечений не меняют своего направления.

4. Если две или более линий объединятся в одну, то место объединения должно быть смещено.

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

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

7. Если направление стрелки не указано, то направление потока считается сверху вниз, слева направо.

EPC-ДИАГРАММЫ

Событийная цепочка процессов (EPC, event-driven process chain) - тип диаграмм, используемых для моделирования, анализа и реорганизации бизнес-процессов. В тоже время EPC-диаграммы могут использоваться для моделирования поведения отдельных частей системы при реализации функций и служить заменой традиционных блок-схем EPC-метод был разработан Августом-Вильгельмом Шеером (August-Wilhelm Scheer) в рамках работ над созданием методологии ARIS (Architecture of Integrated Information Systems - Архитектура интегрированных информационных систем) в начале 1990-х годов. Диаграмма процесса (функции) в нотации EPC представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и информационные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни.

СИМВОЛЫ ПРОЦЕССА

СИМВОЛЫ ОБЪЕКТОВ

СИМВОЛЫ ИСПОЛНИТЕЛЕЙ

СИМВОЛЫ ПО

СИМВОЛЫ ЛИНИЙ

ЛОГИЧЕСКИЕ СИМВОЛЫ

СПЕЦИАЛЬНЫЕ (ДОПОЛНИТЕЛЬНЫЕ) СИМВОЛЫ

Условные обозначения элементов графической нотации EPC в ARIS а) организационная единица   б) информационная система

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

4. События и функции должны содержать строго по одной входящей и одной исходящей связи (потоку управления), отражающей ход выполнения процесса. 5. На диаграмме не должны присутствовать элементы без единой связи. Исключение может составлять элемент «цель» всего процесса (диаграммы). 6. События и логические операторы, окружавшие функцию на вышележащей (родительской) диаграмме, должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции.

7. Каждый оператор слияния должен обладать минимум двумя входящими связями и только одной исходящей, оператор ветвления - только одной входящей связью и минимум двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями. 8. Логические операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно. 9. Логический оператор, разветвляющий ветви, и оператор, объединяющий эти ветви, должны совпадать. Допускается также ситуация, когда оператор ветвления «И», оператор объединения – «ИЛИ».

допустимые ситуации

недопустимые ситуации

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

МЕТОДОЛОГИЯ BPMN

Модель и нотация бизнес-процессов (BPMN, Business Process Model and Notation) – методология моделирования, анализа и реорганизации бизнес-процессов. Разработана Business Process Management Initiative (BPMI), с 2005 г. поддерживается и развивается Object Management Group (OMG). В отличие от других методологий бизнес-моделирования, имеющих статус «фирменного» (EPC) или «национального» (IDEF0) стандарта, BPMN получила «международный» статус – Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology - Object Management Group. Business Process Model and Notation». Основной целью BPMN является обеспечение доступной нотацией описания бизнес-процессов всех пользователей: от аналитиков, создающих схемы процессов, и разработчиков, ответственных за внедрение технологий выполнения бизнес-процессов, до руководителей и обычных пользователей, управляющих этими бизнес-процессами и отслеживающих их выполнение. Таким образом, BPMN нацелен на устранение расхождения между моделями бизнес-процессов и их реализацией.

Идеи - UML (Unified Modeling Language, Унифицированный язык моделирования): o Activity Diagram (диаграмма деятельности); o EDOC (Enterprise Distributed Object Computing, корпоративная распределенная обработка объектов) – Business Processes (бизнес-процессы); - IDEF (SADT); - ebXML (Electronic Business eXtensible Markup Language, расширяемый язык разметки для электронного бизнеса) BPSS (Business Process Specification Schema, схемы спецификации бизнес-процессов); - ADF (Activity-Decision Flow, поток «деятельность-результат») Diagram; - RosettaNet; - LOVEM (Line of Visibility Engineering Methodology, визуальная методология проектирования); - EPC.

Элементы (символы) графической нотации BPMN по назначению объединены в категории - объекты потока (Flow Objects); - данные (Data); - зоны ответственности (Swimlanes); - соединяющие элементы (Connecting Objects); - артефакты (Artifacts).

СИМВОЛЫ ОБЪЕКТОВ ПОТОКА

СИМВОЛЫ ДАННЫХ

СИМВОЛЫ ЗОНЫ ОТВЕТСТВЕННОСТИ

СИМВОЛЫ СОЕДИНЯЮЩИХ ЭЛЕМЕНТОВ (ЛИНИЙ)

СИМВОЛЫ АРТЕФАКТОВ (СПЕЦИАЛЬНЫЕ СИМВОЛЫ)

События по времени наступления стартовое событие – инициирует начало процесса (диаграммы). Из стартового события поток управления может только исходить, а поток сообщений - как входить, так и исходить. На диаграмме процесса, как правило, отображается только одно стартовое событие, но оно может отсутствовать или их может быть несколько при отображении процесса с пулами, дорожками или развернутыми подпроцессами. Контур события отображается одинарной тонкой линией; конечное событие – является результатом выполнения процесса. В конечное событие поток управления может только входить, а поток сообщений - как входить, так и исходить. В конечное событие может только входить поток (стрелка). На диаграмме конечное событие, как и стартовое, может быть одно, несколько (даже при отсутствии пулов и дорожек) или ни одного. Контур события отображается одинарной жирной линией; промежуточное событие – все остальные события, возникающие в ходе выполнения процесса. В промежуточное событие обязательно должен входить и выходить один поток. Исключение составляет граничные (Boundary) события, возникающие и обрабатываемые непосредственно либо в самом начале действия либо в его конце. Такие события отображаются на границе (контуре) действия и у них может быть только либо входящий либо исходящий поток. Контур события отображается двойной тонкой линией;

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

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

по причине возникновения (триггеру) См далее 

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

Пример использование различных типов событий по возможности прерывания выполнения действия

Действие задача (Task) – элементарное (неделимое, атомарное) действие. Специфика (разновидность) задачи может быть отображена иконкой (маркером) в левом верхнем углу символа действия подпроцесс (Sub-Process) – составное действие, включающее в себя другие действия, шлюзы, события и потоки операций. Части подпроцесса могут непосредственно отображены на диаграмме внутри символа действия или вынесены на отдельную диаграмму декомпозиции. Во втором случае на родительской диаграмме в центре нижнего края действия (подпроцесса) отображается символ + . вызов (Call). Позволяет включать в состав диаграммы повторно используемые задачи и подпроцессы. На диаграмме выделяется жирным контуром.

Задача

Подпроцесс

Вызов

Дополнительные особенности реализации или выполнения

Шлюз

Пример использование различных типов шлюзов

Объект данных

Потоки операций

Пример использование специфических потоков управления

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

Диаграмма открытого процесса

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

Диаграмма хореографии

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

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

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

7. Шлюз, разветвляющий ветки, и шлюз, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда шлюз ветвления «И», шлюз объединения – «ИЛИ».

допустимые ситуации

недопустимые ситуации

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