Проектирование информационных систем 8. Разработка поведенческой модели EPC-ДИАГРАММЫ
8.6. Правила и рекомендации построения EPC-диаграмм. 8.7. Пример построения EPC-диаграммы.
EPC-метод был разработан Августом-Вильгельмом Шеером (August-Wilhelm Scheer) в рамках работ над созданием методологии ARIS (Architecture of Integrated Information Systems - Архитектура интегрированных информационных систем) в начале 1990-х годов. Событийная цепочка процессов (EPC, event-driven process chain) - тип диаграмм, используемых для моделирования, анализа и реорганизации бизнес-процессов (функционального моделирования) [39]. В то же время EPC-диаграммы могут использоваться для моделирования поведения отдельных частей системы при реализации функций и служить заменой традиционных блок-схем (поведенческого моделирования). Диаграмма процесса (функции) в нотации EPC представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и информационные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни. Как и в случае с DFD, методология EPC «разрослась» интерпретациями, поддерживающими различные нотации (синтаксис и семантику элементов). К этому «приложили руку» как сам автор методологии, так и производители ПО, в котором реализована возможность моделирования бизнес-процессов посредством EPC (ARIS, Microsoft Visio, Business Studio, Bflow). По аналогии с блок-схемами, символы (элементы) графической нотации можно сгруппировать по назначению. В следующей таблице приведены символы EPC и их альтернативные изображения, наиболее часто встречающиеся в литературе и ПО. Таблица 8.2. Условные обозначения на EPC-диаграммах
Следует отметить, что некоторые элементы нотации представлены одним и тем же графическим примитивом (информация и исполнитель, кластер и приложение), но различаются цветом фона. Несмотря на отличия в синтаксисе и семантике, можно выделить основные элементы (ядро) методологии EPC, присутствующие и остающиеся неизменными в различных нотациях. К ним относятся: функция, событие, логические символы (правила) и поток управления. Остальные элементы при одинаковой семантике могут иметь различный внешний вид. В частности в последней версии программного продукта ARIS (версия 2.4) все дополнительные (документ, персона и т.д.) и новые (риск) элементы отображаются в виде четырехугольника со скругленными углами, но с различным цветом фона и иконкой в левом верхнем углу.
Рис. 8.6. Условные обозначения элементов графической нотации EPC в ARIS
8.6. Правила и рекомендации построения EPC-диаграмм
Процесс моделирования процессов с помощью EPC подчиняется классическим принципам моделирования: декомпозиции и иерархического упорядочивания. Декомпозиция (с отображением на отдельных диаграммах) выполняется для функций, подобно функциям на диаграммах IDEF0 или предопределенным процессам на блок-схемах. Ниже приводятся другие правила и рекомендации [40]. 1. Диаграмма процесса EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса). 2. События и функции по ходу выполнения процесса должны чередоваться. 3. Рекомендуемое количество функций на диаграмме - не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели. 4. События и функции должны содержать строго по одной входящей и одной исходящей связи (потоку управления), отражающей ход выполнения процесса. 5. На диаграмме не должны присутствовать элементы без единой связи. Исключение может составлять элемент «цель» всего процесса (диаграммы). 6. События и логические операторы, окружавшие функцию на вышележащей (родительской) диаграмме, должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции. 7. Каждый оператор слияния должен обладать минимум двумя входящими связями и только одной исходящей, оператор ветвления - только одной входящей связью и минимум двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями. 8. Логические операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно. 9. Логический оператор, разветвляющий ветви, и оператор, объединяющий эти ветви, должны совпадать. Допускается также ситуация, когда оператор ветвления «И», оператор объединения – «ИЛИ». Примеры допустимых и недопустимых ситуаций приведены на следующем рисунке. а) допустимые ситуации
б) недопустимые ситуации
Рис. 8.7. Примеры допустимого и недопустимого использования логических операторов 10. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами, потоки в местах пересечений не меняют своего направления.
8.7. Пример построения EPC-диаграммы
На следующем рисунке приведен пример диаграммы EPC процесса «Предпроектное обследование» из обучающих материалов к программному продукту Business Studio [40].
Рис. 8.8. Диаграмма EPC для процесса «Предпроектное обследование» Одной из отличительных особенностей нотации, применяемой в Business Studio, является использование обобщенного символа исполнителя («Субъект»). Несмотря на отображение его в виде организационной единицы, под ним может пониматься также должность или персона. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
