моделями.
При моделировании часто возникает необходимость выбора пути, по которому будет развиваться бизнес-процесс в зависимости от принятого бизнес-решения.
Точки принятия бизнес-решений реализованы путем введения в модель совокупностей объектов – правил, за которыми следуют совокупности многочисленных событий, объясняющих альтернативы дальнейшего прохождения бизнес-процесса в зависимости от сделанного пользователем бизнес-решения (рис. 16).
Рис. 16
Если в процессе обхода модели встречается правило, то сначала анализируется его тип.
Если правило AND, то начала альтернативных ветвей заносятся в стек, затем в автоматическом режиме продолжается обход ветвей одна за другой, диалоговый режим не возникает. Извлечение из стека начала очередной ветви происходит по достижении конца текущей ветви. Для организации такого режима необходимо, чтобы при ручном создании модели каждому открывающему правилу соответствовало аналогичное закрывающее правило.
Если правило OR, то формируется список альтернативных ветвей процесса, который в диалоговом режиме предлагается пользователю. Пользователь выбирает любую комбинацию ветвей, начала этих ветвей заносятся в стек, затем в автоматическом режиме продолжается обход ветвей одна за другой.
Если правило XOR, то также формируется список альтернативных ветвей, который предъявляется пользователю в диалоговом режиме. Пользователь сможет в этом случае выбрать только одну ветвь. Начало ветви в стек не заносится, затем в автоматическом режиме продолжается обход текущей ветви.
Дисциплина доступа к стеку: последним вошел – первым вышел (LIFO).
Стек может быть организован несколькими способами.
Если надо хранить несколько параметров для одного объекта, применяется или многомерный массив вариантного типа, в каждом измерении которого хранится один параметр объекта, или одномерный массив структур, в котором отдельная структура хранит параметры отдельного объекта.
Если надо хранить один параметр для каждого объекта, может подойти или одномерный массив вариантного типа, или список. Список в этом случае более предпочтителен.
Так как операции с объектами требуют много ресурсов, то обязательна практика возврата ресурсов системе перед завершением работы всех процедур и функций скрипта. Для списка это делается путем присвоения значения Nothing, для массива придется писать код, который обнулит ссылки каждого задействованного объекта в ячейке массива.
На рис. 17 приведен пример выбора альтернативной ветви процесса для правила XOR.
Рис. 17
В приложении 1 приведен пример кода, реализующего этот функционал. Это процедура XOROpen. Строки диалогового окна формируются при помощи функции Getname (), код которой также приведен в приложении 1.
Цветовое выделение «маршрута» на фоне общей модели
В стандартном режиме ARIS позволяет просматривать модели любой группы, свойства модели и любого из ее объектов, менять свойства модели и любого из ее объектов. Журнал посещений моделей не ведется, поэтому запомнить путь, повторить просмотр, пометить как-то просмотренные модели и т. п. невозможно.
Для реализации подобного функционала создан скрипт, позволяющий в интерактивном режиме пройти по любой модели или группе моделей, сделать осознанный выбор альтернативного пути развития бизнес- процесса, пометить уже пройденный путь (выделить отличным от стандартного цветом пройденные объекты), получить журнал – список пройденных моделей. В процессе прохода по модели формируется подробный журнал, типа Технологической карты, в котором отмечаются все точки принятия решений, все пройденные функции, фиксируется окружение каждой пройденной функции.
Создан также скрипт, при помощи которого можно повторить обход модели, так как пройденные объекты на модели помечаются не только цветом, но и последовательным номером. Кроме того, этот скрипт использует навигационную информацию из журнала, созданного при первом проходе.
Создан также скрипт, который производит восстановление всех моделей из списка просмотренных до первоначального состояния – восстановление цветов, сброс номеров объектов, сброс других сервисных атрибутов моделей и объектов на них.
На рис. 18 приведен пример использования описанного скрипта, под ним – список моделей, пройденных скриптом за последний сеанс работы.
Рис. 18
Изменение цвета объекта и присвоение ему последовательного номера производятся путем назначения некоторым атрибутам объектов специальных значений.
Пример кода, реализующего этот функционал, приведен в приложении 2.
Это функции setfunnomer() и setcolor(). Список пройденных моделей:
1. Оформление запрещения выпуска товаров.
2. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи и ЛНП.
3. Проставление штампа «Выпуск разрешен» и соответствующей записи и ЛНП.
4. Проставление штампа «Выпуск запрещен» и соответствующей записи, ЛНП в правом верхнем углу заявления.
5. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи, ЛНП в правом верхнем углу контрольного экземпляра документа.
6. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи и ЛНП.
Сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры
Для того чтобы применить некоторые стандартные средства ARIS (например, стоимостной, временной анализ, симуляцию и т. п.) к моделям, их нужно предварительно готовить, как правило, долго и вручную. Такая подготовка обычно состоит в создании новой Group, копировании в нее моделей – всех или некоторых, модификации моделей – добавлении или удалении объектов, изменении некоторых атрибутов объектов и т. п.
Подобное копирование можно производить или вручную, или при помощи механизма Variants. Однако если модели копируются как Copies occunrence, то любые изменения объектов этих новых моделей автоматически приводят к изменениям occurences этих объектов на моделях-источниках, что далеко не всегда то, что нужно пользователю.
Как правило, модели копируются пользователями как Copies definitions, но в этом случае пропадают все связи объектов этих моделей и на новых моделях все связи приходится восстанавливать вручную, что очень затратно по времени и чревато ошибками.
Был создан скрипт, который, реализуя весь ранее уже описанный функционал, позволял вдобавок создавать в автоматическом режиме новую тестовую Group, копии моделей, по которым «проходил».
На этих новых моделях отражались только те объекты и ветви, которые анализировались скриптом, и помечались цветом и уникальным последовательным номером. Объекты, которые не анализировались, не копировались на новую модель.
В итоге получалось нечто, похожее на приведенное на рис. 19.
Рис. 19
В процессе формирования новой модели проводился соответствующий анализ, состоявший в том, что:
¦ если атрибуты объекта, число и тип связей, число и тип ассоциаций не изменялись, то на новой модели создавался новый occurence уже существующего объекта, при этом, естественно, сохранялись все уже существовавшие связи этого объекта, затем создавались новые occurences связей уже существующего объекта, аналогичные связям объекта – оригинала с модели-источника;
¦ если же менялись атрибуты объекта, или число и тип связей, или число и тип ассоциаций, то:
– в новой группе создавался новый объект, аналогичный оригинальному, но уже со своим,
