CC BY
24
Последний уровень используется для идентификации роли или ответственности, которую каждый из участников играет в бизнес-взаимодействии.
После определения информационных связей внутри системы и правил информационного взаимодействия между разнородными автоматизированными системами можно определять документы, которыми будут обмениваться данные системы. UMM не определяет конкретной техники для создания данных документов, но предлагает использовать UN/CEFACT's Core Components для моделирования бизнес-документов, использующихся при обмене. Второй стандарт рекомендуемый для использования внутри уровня описания бизнес информации - это Core Component Message Assembly (CcmA).
Заключение
Использование предложенной в статье методологии моделирования и методов анализа для разработки системы информационного взаимодействия разнородных автоматизированных систем существенно снижает риск получения неэффективной системы, и принятия неверных решений на начальных этапах разработки.
Список литературы:
1. Братищенко В.В. Проектирование информационных систем. - Иркутск: Издательство БГУЭП, 2004.
2. Комплект стандартов и руководящих документов на автоматизированные системы (ГОСТ 34.201-89, ГОСТ 34.602-89, РД 50-680-88, ГОСТ 34.601-90, ГОСТ 34.401-90, РД 50-34.689-90, ГОСТО 34.003-90, Р 50-34.11990). - издание официальное. - М., 2000.
3. Techniques and Methodologies Group (TMG), UML Profile for UN/CEFACT's Modeling Methodology (UMM) Foundation Module Version 2.0 Technical Specification, 2011.
4. UNITED NATIONS ECONOMIC COMMISSION FOR EUROPE, UNITED NATIONS CENTRE FOR UN/CEFACT, BUSINESS REQUIREMENTS SPECIFICATION, Documentation Template, Version: 2.0, 2010.
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКОГО АЛГОРИТМА ДЛЯ ВОССТАНОВЛЕНИЯ ТОПОЛОГИИ ПРОЦЕССА ПО ЖУРНАЛУ СОБЫТИЙ ИМИТАЦИОННОЙ МОДЕЛИ
© Ланцев Е.А.*
Сибирский государственный технологический университет, г. Красноярск
Исследование заключается в построении топологии процесса на основе журнала работы агентной имитационной модели в системе AnyLogic.
* Аспирант кафедры Системотехники.
Для восстановления топологии процесса используется генетический алгоритм и его реализации в плагине «Генетический анализатор» для программы ProM.
Анализ процессов (Process Mining) представляет собой сравнительно молодую научную дисциплину, основная идея которой заключается в том, чтобы выявить, отследить и произвести улучшение реальных (а не предполагаемых) процессов путем извлечения знаний из журналов событий, легко доступных в информационных системах [1, 2].
Задачи Анализа процесса (Process Mining) согласно манифесту [2]:
а) Построение модели по имеющемуся журналу событий (process discovery).
б) Проверка согласованности лога и модели (conformance checking).
в) Улучшение и расширение процесса (enhancement).
В данной работе решается задача проверки соответствия (conformance) топологии реального процесса и реализованной по его функциональному описанию имитационной модели. Задача решается путем сравнения модели реального процесса в нотации eEPC и журнала событий имитационной модели с помощью алгоритмов интеллектуального анализа, реализованных в программном продукте ProM [1].
Следует отметить, что существуют публикации по использованию журнала событий в процессе работы имитационных моделей для верификации дискретно-событийных моделей сетей Петри в системе CPN Tools [3-5]. Но работы по использованию алгоритмов process mining для верификации топологии агентных имитационных моделей, а также дискретно-событийных моделей для системы имитационного моделирования AnyLogic отсутствуют. Также в данной работе, в отличие от вышеуказанных [3-5], в качестве реальной модели процесса используется не модель восстановленная по журналу событий, а модель взятая из реальной практики, то есть созданная аналитиком.
Рассмотрим исходную модель реального бизнес-процесса «Управление производством медиапродукта» в нотации ARIS eEPC, которая использовалась для построения АИМ (рис. 1). На основе данной модели была создана агентная имитационная модель в системе AnyLogic.
В данном исследовании не будет рассматриваться процесс создания агент-ной имитационной модели (АИМ) на основе модели в нотации eEPC, поскольку здесь мы сосредоточены на построении топологии процесса на основе журнала работы агентной имитационной модели. Развернутое описание подхода к трансляции дискретно-событийной модели EPC в АИМ AnyLogic приведено в работе [6].
В процессе работы АИМ AnyLogic создается журнал работы модели в текстовом файле, в который записываются данные о работе имитационной модели (табл. 1).
Рис. 1. Исходная eEPC модель процесса «Управление производством медиапродукта»
Таблица 1
Структура и принцип формирования журнала работы АИМ в AnyLogic
№ Поле журнала Описание поля Принцип формирования поля в АИМ
1 CASEID Номер экземпляра процесса В поле записывается порядковый номер экземпляра бизнес-процесса.
2 TASK Наименование задачи Записывается название (описательное название на русском) запущенной задачи. Задача соответствует переходу в простое состояние на диаграмме состояний агента.
3 TIME Дата и время Записывалось модельное время
4 EVENTTYPE Тип события В модель используется только тип события «Начало процесса» (Start)
5 RESOURCE Исполнитель Записывается название агента, выполняющего задание
Первые три поля (CASEID, TASK, TIME) обязательно должны быть заполнены для последующего формирования журнала событий.
Полученный журнал работы АИМ с помощью программы XESsame [7] транслируется в журнал событий в формате MXML, который далее анализируется с помощью программы ProM. Журнал событий содержит 2000 экземпляров процесса и 14428 событий.
ProM представляет собой программный инструмент с открытым исходным кодом, специально созданный для поддержки разработки дополнений для анализа процессов [1].
После того, как журнал событий импортирован в ProM, в него добавляется начальная и конечная задачи (с помощью плагинов «Artifical start task» [1] и «Artifical end task» [1]), которые играют роль точки входа в процесс и точки выхода.
Для анализа и восстановления структуры процесса применялся генетический алгоритм, реализованный в плагине генетического анализатора (Genetic Miner [8]) для ProM. Использованные настройки плагина «Генетический анализатор» приведены в табл. 2.
Таблица 2
Настройки плагина «Генетический анализатор» (Genetic Miner) для ProM
Настройка Значение
Размер популяции (Population size) 100
Тип начальной популяции (Initial population type) Возможны повторы (Possible Duplicates)
Максимально количество поколений (Maximum num- 1000
ber of generations)
Seed 1
Для начальной популяции (Power value) 1
Степень элитаризма (Elistism rate) 0.02
Тип целевой функции (Fitness Type) Extra Behavior Punishment
Метод отбора (Selection Method Type) Турнир 5 (Tournament 5)
Тип скрещивания (Crossover Type) Расширеный (Enhanced)
Степень скрещивания (Crossover Rate 0.8
Тип мутации (Mutation Type) Расширеный (Enhanced)
Степень мутации (Mutation Rate) 0.2
Критерий согласованности журнала событий и полученной модели составил 97 %. Структура восстановленного процесса по результатам работы генетического алгоритма представлена на рис. 2.
Рис. 2. Схема восстановленного процесса по результатам работы генетического алгоритма
Далее из схемы, полученной в результате работы генетического алгоритма, генерируем EPC (рис. 3), это осуществляется автоматически с помощью встроенных в ProM средств.
По результатам анализа рис. 3 и рис. 1. можно заключить, что структура процесса, восстановленного из журнала событий АИМ (рис. 3) идентична исходной модели реального процесса (рис. 1), которая и использовалась для построения агентной имитационной модели, лишь за тем исключением, что на восстановленной модели отсутствуют организационные единицы.
Рис. 3. Восстановленная модель ЕРС по журналу событий агентной имитационной модели
Заключение
Структура процесса, восстановленного из журнал событий агентной имитационной модели (рис. 3), идентична по топологии исходной модели реального процесса (рис. 1), которая использовалась для построения агентной имитационной модели. Таким образом показано, что генетический алгоритм анализа процессов (в частности его реализация в виде плагина «Генетический анализатор» для ProM) применим для восстановления топологии агентных имитационных моделей и может применяться в тех случаях, когда по имеющейся имитационной модели необходимо восстановить топологию процесса.
Из недостатков восстановления модели процесса генетическим алгоритмом можно отметить его долгую работу по сравнению с другими алгоритмами анализа процессов - на анализ 2000 экземпляров процесса и 14428 событий тратится 7 часов реального времени на ПК ASUS X51RL, с процессором Intel Celeron CPU 540 1,86 ГГц, 2 Гб ОЗУ, под управлением операционной системы Windows XP Home Edition SP2.
Список литературы:
1. Van der Aalst W.M.P. Process Mining: Discovery, Conformance and Enhancement of Business Processes. - Berlin: Springer-Verlag, 2011.
2. Van der Aalst W. et al. Process Mining Manifesto // Business Process Management Workshops, LNBIP 99 / F. Daniel, K. Barkaoui and S. Dustdar, eds. -Springer-Verlag, 2011.
3. Rozinat A., Mans R.S., Song M. and van der Aalst W.M.P. Discovering Simulation Models // Information Systems. - 2009. - Vol. 34. - Р. 305-327.
4. Maruster L., van Beest N.. Redesigning Business Processes: A Methodology Based on Simulation and Process Mining Techniques. Knowledge and Information Systems. - 2009.
5. Alves de Medeiros A.K., G'unther C.W. Process Mining: Using CPN Tools to Create Test Logs for Mining Algorithms // In K. Jensen, editor, Proceedings of the Sixth Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools. - 2005. - P. 177-190.
6. Ланцев Е.А. Агентный и дискретно-событийный подходы к имитационному моделированию бизнес-процессов в нотации eEPC // В мире научных открытий. - Красноярск, 2013. - С. 278-290.
7. J.C.A.M. Buijs. Mapping Data Sources to XES in a Generic Way. Master Thesis. - 2010. - P. 123.
8. De Medeiros A., van den Brand P., van der Aalst W., Weijters T., Gaaloul W., Pedrinaci C. Semantic Process Mining Tool - Final Implementation, Deliverable 6.11, Project IST 026850 SUPER (Sep 2008).
9. Alves de Medeiros A.K., Weijters A.J.M.M. and van der Aalst W.M.P. Data Mining and Knowledge Discovery. - 2007. - Vol. 14, Iss. 2. - P. 245-304.
ПРОБЛЕМА КОНТЕКСТНОГО ПОИСКА ИНФОРМАЦИИ В ИНФОРМАЦИОННО-ПОИСКОВОЙ СИСТЕМЕ
© Максакова Л.С.*
Московский государственный университет леса, г. Мытищи
В данной статье рассматривается проблема контекстного поиска информации в ИПС. Рассмотрены основные информационные потребности пользователей, состояние разработок систем контекстного поиска, сферы использования современных ИПС, а так же говориться в каких случаях применяется контекстный поиск. В конце статьи подведены промежуточные итоги исследования.
Информационно-поисковые системы появились на свет достаточно давно. Первые автоматизированные информационные системы начали разрабатываться еще в 50-х годах прошлого века, и главной их функцией был именно поиск информации. Поэтому их назвали информационно-поисковыми системами (ИПС). Информационно-поисковые системы (ИПС) появились в середине XX в., когда ученые предупредили о возможности возникновения проблемы информационного взрыва. Стало понятным, что контекстный поиск представляет отдельную задачу, имеющую свой предмет и свои методы решения. Но полностью автоматизировать интеллектуальные поисковые системы оказалось невозможным. В 70-е гг. с внедрением компьютеров в
* Магистрант кафедры Вычислительной техники.
