в цикле для каждой модели проверяет наличие на ней функций, имеющих ассоциации с eEPC-моделями, чувствительными по выбранному параметру, например по типу транспорта;
при наличии таких функций:
– создается новое definition (определение) функции;
– атрибуты новой функции делаются такими же, как у функции-источника;
– из списка ассоциаций новой функции удаляются ссылки на модели, не удовлетворяющие выбранному параметру (остается только ссылка на модель, имеющая атрибут чувствительности по транспорту, равный выбранному);
– создается новое occurrence (представление) новой функции;
– создаются новые occurrences (представления) связей между occurrence (представлением) новой функции и occurrences (представлениями) объектов, составляющих окружение функции-источника;
– удаляется «старое» occurrence функции на модели.
В итоге автоматически, быстро, очень корректно и безошибочно получаем группу моделей, сохранивших связи с моделями, независимыми от, например, транспорта.
Такие группы моделей после соответствующей подготовки (назначения вероятностей событиям или формирования диаграмм событий, формирования дополнительных моделей, например графиков смен) можно оптимизировать Simulation или анализировать другими стандартными средствами ARIS (ABC или Balanced Scoreboard).
Документы в любом виде – печатном или электронном – представляют собой или элементы нормативной системы, придающей бизнес-процессам легитимность, или элементы оперативной среды, обеспечивающие процедурную, смысловую поддержку бизнес-процессов. Группирование документов на нормативные и оперативные – логичная и повсеместно применяемая практика моделирования бизнес-процессов. Часто бывает оправданной или даже необходимой дальнейшая, более подробная группировка. Например, нормативные документы делятся на законы, приказы, кодексы, распоряжения и т. д., а оперативные – на коммерческие, государственные, ведомственные и т. д. Кроме того, в зависимости от особенностей протекания бизнес-процессов документы должны группироваться по многим другим признакам. Таким образом, становится актуальной проблема – сделать документы «чувствительными» к режимам функционирования, к особенностям протекания бизнес-процессов.
Чтобы сделать документы «чувствительными» к режимам функционирования бизнес-процессов, применяется механизм назначения определенным атрибутам документов специальных значений, закрепленных в Соглашении о моделировании.
Например, значение атрибута документа Identifier= «DOC_NP_*» «делает» документ нормативным, а «DOC_OP_*» – оперативным. Добавление постфикса вместо символа «*» позволяет ввести дополнительную градацию. Например, «PSM» – это письма, а «LAW» – законы и т. д. На рис. 26, 27 приведены примеры применения такой практики к документам.
Рис. 26
Рис. 27
Для задания чувствительности документов к, например, типу товара, некоему режиму и типу транспорта происходит присвоение атрибутам документа «User attribute Text 1», «User attribute Text 2» и «User attribute Text 3» специальных значений, определенных в «Соглашении о моделировании» в соответствующей, также согласованной нотации. Пример применения этих соглашений приведен на рис. 28.
Рис. 28
В процессе работы специально разработанных скриптов происходит анализ атрибутов документов из окружения функции, и, если совокупность атрибутов документа соответствует совокупности атрибутов, определяемых при выборе входных параметров скрипта (тип товара, таможенный режим, тип транспорта), документ помечается цветом при проходе по модели и его название помещается в выходной отчет.
Тестирование
Создаваемые в процессе моделирования диаграммы должны удовлетворять спецификациям ARIS по структуре, синтаксису, другим согласованным требованиям. Соответствие этим требованиям проверяется при помощи скриптов семантического анализа среды ARIS. Нужно признать, что разработчики часто отходят от соглашений ARIS, создавая диаграммы в соответствии со своими «Соглашениями о моделировании». В этом случае семантическая проверка ARIS применяется в ограниченном режиме. Проблемы же корректности моделей решаются путем написания и запуска на моделях тестирующих скриптов, учитывающих особенности «своих» «Соглашений о моделировании».
Например, при потоковом тестировании моделей при формировании помеченного «маршрута» применялись генераторы случайных чисел, с помощью которых формировались случайные условия на входе и случайные условия в процессе формирования «маршрута».
При формировании входных параметров использовались случайным образом выбранные тип товара, некий режим, тип транспорта. В приложении 2 приведен пример кода, формирующего случайным образом тип транспорта. Это Function seltransrand As String.