Метод определения противоречий в demo-моделях бизнес-процессов Текст научной статьи по специальности «Компьютерные и информационные науки»

метод определения противоречий

в demo-моделях бизнес-процессов

Э.А. Бабкин,

кандидат технических наук, PhD in Computer Science, профессор кафедры информационных систем и технологий, факультет бизнес-информатики и прикладной математики, Национальный исследовательский университет «Высшая школа экономики»

Адрес: 603155, г. Нижний Новгород, ул. Б.Печерская, д. 25/12 E-mail: eababkin@hse.ru

А.А. Бузуева,

студент кафедры информационных систем и технологий, факультет бизнес-информатики и прикладной математики, Национальный исследовательский университет «Высшая школа экономики» Адрес: 603155, г. Нижний Новгород, ул. Б.Печерская, д. 25/12 E-mail: anna.a.buzueva@gmail.com

К.В. Логвинова,

кандидат физико-математических наук, PhD in Mathematics, профессор кафедры информационных систем и технологий, факультет бизнес-информатики и прикладной математики, Национальный исследовательский университет «Высшая школа экономики» Адрес: 603155, г. Нижний Новгород, ул. Б.Печерская, д. 25/12 E-mail: klogvinova@hse.ru

В статье рассматривается проблема обнаружения логических противоречий в моделях бизнес процессов и предлагается способ решения этой проблемы с иллюстрацией на примере анализа сложных бизнес-процессов системы здравоохранения на основе формального подхода реляционной логики. Предлагаемый способ должен способствовать повышению эффективности управления муниципальными учреждениями здравоохранения прежде всего в аспекте повышения качества предоставления комплексных услуг для лиц пожилого возраста. Предлагаемый метод основан на формальных инструментах реляционной логики системы моделирования MIT Alloy Analyzer. Для моделирования бизнес-процессов был выбран перспективный подход онтологии организации и конкретная методология моделирования DEMO (Design & Engineering Methodology for Organizations). Эта методология дает возможность полного и объективного описания организации и функционирования современного предприятия. Анализ построенных по методологии DEMO моделей организации позволяет получить детальное представление о процессах управления и взаимодействия и служит основой для проведения бизнес-реинжиниринга и развития информационной инфраструктуры, согласованной с требованиями бизнеса. Важной частью нашего исследования является разработка формальных спецификаций построенных моделей бизнес-процессов, пригодных для применения формальных методов верификации. Поэтому с целью повторного использования разработанных нами методов трансляции моделей бизнес-процессов на язык системы Alloy Analyzer была создана метамодель ключевых конструктивных элементов методологии моделирования DEMO.

На основе разработанной мета-модели и конкретных бизнес-процессов предоставления медицинских услуг в ходе исследования были построены формальные модели и проведен анализ их логической непротиворечивости, ^в том числе и во временном аспекте. ^

Ключевые слова: бизнес-процесс, здравоохранение, языки моделирования, анализ непротиворечивости, формальные методы.

1. Введение в проблему

Моделирование бизнес-процессов является одним из перспективных методов объективного понимания сути организаций и выработки методик повышения эффективности организационной деятельности. В настоящее время под моделированием бизнес-процессов понимают отражение субъективного видения потока работ в виде формальной модели, состоящей из взаимосвязанный операций [1]. Одним из актуальных направлений научных исследований в этой области является разработка научных методов анализа непротиворечивости моделей бизнес-процессов.

Целью нашего исследования является определение способов решения проблемы обнаружения логических противоречий в моделях бизнес-процессов системы здравоохранения на основе формальных методов. Предлагаемые способы должны способствовать повышению эффективности управления муниципальными учреждениями здравоохранения прежде всего в аспекте повышения качества предоставления комплексных услуг для лиц пожилого возраста. Курс социальной политики нашего государства сейчас как раз направлен на поддержку и повышение качества жизни престарелых членов общества, регулирование взаимоотношений и распределение ресурсов между поколениями [7].

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

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

Для моделирования был выбран перспективный подход онтологии организации [2] и конкретная методология моделирования DEMO (акроним от Design & Engineering Methodology for Organizations). Эта методология дает возможность полного и объективного описания организации и функционирования современного предприятия. Анализ

построенных по методологии DEMO моделей организации позволяет получить детальное представление о процессах управления и взаимодействия и служит основой для проведения бизнес-реинжиниринга и развития информационной инфраструктуры, согласованной с требованиями бизнеса. Методология хорошо зарекомендовала себя на практике в различных предметных областях (бизнес, государственное управление и прочие). Наиболее специфичной чертой описания процессов по этой методологии является изображение глубинной структуры процессов в организации, вне зависимости от того, как они реализованы [5]. Это резко отличает выбранную нами методологию от традиционных подходов к описанию процессов, таких как IDEF3, сети Петри или eEPC [6].

Важной частью нашего исследования является разработка формальных спецификаций построенных моделей бизнес-процессов, пригодных для применения формальных методов верификации. В качестве инструмента для этой цели был использован язык и логика известной системы Alloy Analyzer [8,9]. С целью повторного использования разработанных нами методов трансляции моделей бизнес-процессов на язык этой системы была создана метамодель ключевых конструктивных элементов методологии моделирования DEMO.

В данной статье результаты представлены следующим образом. В разделе 2 изложены основные сведения об используемом языке и логике системы Alloy Analyzer. В разделе 3 представлены основные результаты моделирования бизнес-процессов отделения сестринского ухода. Раздел 4 содержит результаты анализа непротиворечивости построенных моделей с использованием системы Alloy Analyzer. В заключении подводятся итоги исследования и определяются пути дальнейших работ.

2. Назначение, язык и логика системы Alloy Analyzer

Применяемый в нашей работе инструментарий Alloy Analyzer [8], разработанный в Массачусет-ском технологическом институте, призван помочь бизнес-аналитику обозначить и обнаружить противоречия в бизнес-процессах. В настоящее время этот инструмент обладает полноценным структурированным языком моделирования на основе языка спецификаций Z и реляционного исчисления Тар-ского, который способен выразить всевозможные сложные структурные ограничения и отразить логику поведения моделей.

Язык и инстументарий системы Alloy Analyzer позволяет выполнять анализ ограничений модели в терминах реляционной логики путем автоматической генерации структур, которые удовлетворяют требованиям логической модели. Таким образом аналитик может изучать эти модели как путем генерации образцовых структур, так и для проверки свойств модели путем генерации контр-примеров. Результаты анализа модели могут быть представ -лены в текстовой форме, в форме дерева, а также диаграммой.

Важной особенностью применяемого инструментария является специфический язык моделирования, который удачно сочетает принципы логики предикатов первого порядка и реляционного исчисления. В ходе определения модели с использованием принципов логики предикатов первого порядка применяются два типа выражений: реляционные переменные, которые используются как предикаты, и кортежи, основанные на количественных переменных. Подход к описанию моделей с использованием предикатов широко используется в выражениях, позволяющих получить набор или отношение из ограничений. Этот подход применим для описания сложных условий, т.к. он точный и конкретный, при этом использование кванторов помогает составить ограничение в естественном и ясном виде. В случае использования логики реляционного исчисления кванторы не используются в принципе, а выражения обозначают отношения. Данный подход считается более компактным, поэтому эксперты находят данный подход удобным для описания часто повторяющихся ограничений.

Структуры, определяемые языком Alloy Analyzer, состоят из атомов и отношений, основанных на простейших сущностях и связях между ними. Атом является простейшей сущностью, которая: неделима, не может быть разделена на составные части; неизменна, ее свойства не меняются со временем; неинтерпретируема, не содержит заранее предопределенных свойств. При помощи отдельных атомов могут быть представлены лишь простейшие понятия реального мира, поэтому для моделирования необходимо использовать отношения — структуры, объединяющие атомы.

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

в каждом столбце. Количество строк называется размером. Возможны любые размеры отношений, включая ноль. Арностью называется количество столбцов в таблице или атомов в кортеже, их должно быть одно или более. Так выделяют унарные, бинарные, тернарные и n-нарные отношения. Отношение с арностью от трех и более называют мультиотношением.

3. Моделирование бизнес-процессов

Объектом нашего исследования выступает отделение сестринского ухода (ОСУ) ГБУЗ НО «Городская клиническая больница №34 Советского района города Нижнего Новгорода» [10]. Данное отделение предназначено для оказания медико-социальной помощи, ухода и поддерживающего лечения больным пожилого и старческого возраста, страдающим хроническими заболеваниями и по состоянию здоровья нуждающимся в поддерживающем лечении и сестринском уходе [11]. Направления на госпитализацию в ОСУ осуществляется участковыми врачами территориальных поликлиник и заведующими стационарами. В направлении на госпитализацию отражается полный клинический диагноз и рекомендации по проведению поддерживающего лечения. Противопоказаниями для направления больных в ОСУ являются: активные формы туберкулеза, острые психозы, острые инфекционные заболевания и венерические заболевания.

Все диаграммы бизнес-процессов ОСУ были выполнены с помощью среды моделирования Xemod в соответствии с принципами моделирования по методологии DEMO [5]. Но наибольший интерес для последующей имплементации DEMO моделей на языке Alloy Analyzer представляют модели конструкций и процессов. Рассмотрим их применения к исследуемой предметной области более подробно.

Модель конструкции (Construction Model (CM)) определяет строение организации в соответствии с операционной аксиомой. Это самый высокий уровень организации и самая лаконичная модель DEMO. CM состоит из двух частей: модели взаимодействия Interaction Model (IAM) и модели взаимного обусловливания Interstriction Model (ISM). IAM показывает активное влияние акторных ролей друг на друга в ходе выполнения транзакций.

Описание организации начинаем с ядра. Такая диаграмма в методологии DEMO называется глобальной или Global Actor Transaction Diagram (GATD) (рис. 1).

Модель взаимодействия, в которой ядро содержит лишь простые акторные роли, является детализированной ATD. Множества всех (значимых) акторных ролей в составе и окружении разделяются границей.

Для описания всех типов транзакций и результатов организации создается Transaction Result Table (TRT). Для нашего случая отделения сестринского ухода TRT выглядят следующим образом (табл. 1).

Таблица. 1. Моделирование в терминах DEMO: Transaction Result Tabl

Тип транзакции Тип результата

T01 nursing care completion R01 nursing care has been completed

T02 nutrition R02 nutrition for nursing care has been provided

T03 placement R03 nursing care has been placed

T04 hygiene procedures R04 hygiene procedures for nursing care have been done

T05 medical inspection R05 medical inspection has been done for nursing care

T06 monitoring R06 monitoring has been provided for nursing care

T07 treatment R07 treatment has been done for medical inspection

T08 expert consultation R08 expert consultation has been provided

T09 first emergence care R09 first care has been executed for monitoring

T10 financial planning creation R10 financing planning has been created for finance period

T11 financial planning approval R11 financing planning for finance period has been approved

T12 resource scheduling R12 resources for resource period have been scheduled

T13 resource management R13 resource management for resource period has been done

T14 reporting R14 reporting for reporting period has been prepared

На основе определенных транзакций следует определить модель процессов (PM). Эта модель определяет шаблоны действий каждой транзакции в модели конструкции организации (CM). Также модель процессов показывает причинные и условные отношения между транзакциями. Таким образом, эта модель показывает состояние и пространство транзакций «координационного мира» организации. Модель процессов представляется диаграммой под названием «Process Structure Diagram (PSD)». В иерархии моделей по методологии DEMO (так называемом онтологическом треугольнике) модель процессов расположена непосредственно под моделью конструкции организации (CM), так как данная модель является первым уровнем детализации CM-модели.

Ключевое значение для понимания структуры бизнес-процесса и взаимосвязи элементов DEMO-транзакций имеет построенная нами диаграмма PSD для отделения сестринского ухода. На графическом языке DEMO эта диаграмма выглядит следующим образом (рис. 2):

4. Анализ противоречий в моделях процессов

На данном этапе наша исследовательская задача состояла в определении противоречий в бизнес -процессах. Тогда проблема сводится к проверке определенных последовательностей действий в рамках описанной предметной области.

Стартовой точкой при моделировании является создание метамодели, на основе которой впоследствии идет построение конкретных процессов рассматриваемой области. Метамодель — это модель, которая описывает структуру, свойства, связи и принципы действия другой модели. Процесс создания метамодели называют метамоделированием. Являясь средством построения моделей, метамо-дель может быть выражена формальным языком или графической нотацией [13].

Метамодель методологии DEMO в Alloy строится на следующих ключевых сущностях: акторная роль (actor role), акт (act) и факт (fact), транзакция (transaction) и шаг процесса (process step kind). Согласно аксиоме операций, акторная роль представляет «продуктивную» единицу организации и является элементарной частицей полномочия и ответственности. Акторные роли могут выступать как инициаторами, так и исполнителями транзакций. В общем случаи акторные роли считаются сложными (composite actor role), и при необходимости разукрупнения разбиваются на простые (elementary actor role). Простая акторная роль имеет ровно одну связь исполнителя, поскольку является исполнителем ровно одного типа транзакций.

Существует два вида активностей для исполнения акторных ролей субъектами: производственные и координационные действия. Координационные действия или C-акты (C-acts) — это отношения, связывающие производственные действия. Производственные действия или P-акты (P-acts) — это действия, через которые субъекты вносят вклад в реализацию товаров или предоставление услуг окружению предприятия. Результатом успешного производственного действия является производственный факт или P-факт (P-fact) [4]. Следовательно, результатом успешного координационного действия является координационный факт или С-факт (С-fact). Согласно аксиоме транзакций — транзакция это социономический шаблон в соответствии с которым осуществляются все действия (C-acts и P-acts) в организации. Транзакция происходит между двумя акторными

СА01 А10

ролями — инициализатором и исполнителем. С указанными оговорками, опуская некоторые несущественные детали, приведем ниже метамодель DEMO на языке Alloy Analyzer в графическом виде в соответствии с рис. 4.

Анализ, являясь ключевым моментом моделирования, позволяет бизнес-аналитику помимо проверки корректности описания модели на языке Alloy рассмотреть также альтернативные сценарии работы модели и выявить существенные дефекты, не обнаруженные при моделировании ранее.

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

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

черпывающего поиска примеров и контрпримеров. Пример — это сценарий поведения модели, при котором ограничения факта и предиката, основанного на данном факте, выполняются. Контрпример — сценарий поведения программы, при котором выполнение факта не влечет за собой выполнение суждения, основанного на обозначенном факте.

Очевидно, что моделирование сущностей предметной области основывается на сущностях мета-модели. В качестве каркаса области сестринского ухода в Alloy возьмем транзакции, описанные в Transaction Result Table. При этом мы рассматриваем исключительно основной функционал отделения (не затрагиваем транзакций планирования, финансирования и т.п.).

В соответствии со структурой диаграммы ATD были выделены следующие акторные роли: эксперт-консультант, пациент, исполнитель, сестра, исполнитель исполнитель гигиенических процедур, медицинский инспектор, монитор, исполнитель первой помощи, сиделка. На языке моделирования системы Alloy Analyzer эти роли определены следующим образом:

accept_step

decline_step extends extends

leads ^ j

ProcessStepKind

^ psk_pr e

initiate(Initializer) 1 , 1

CompositeActorRole

^^ t

^^^execute extends

Executer ElementaryActorRole

Рис. 4. Метамодель методологии DEMO в Alloy Analyzer

sig ExpertConsultant, Patient extends CompositeActorRole {}

sig NursingCareCompleter, Nurisher, PlacementExecuter, HygieneProceduresExecuter, Medicallnspecter, Monitor, FirstEmergencyExecuter, Treater, extends ElementaryActorRole {}

Далее были последовательно заданы транзакции предметной области, являющиеся наследниками сигнатуры «транзакция» в метамодели. Стартовой и ключевой из них является позиция «nursing care completion», инициализируемая пациентом. Пациент рассматривается как сложная акторная роль, т.к. он внешний участник транзакции, ведь мы не можем знать точно, является ли акторная роль из окружения простой или сложной.

Исполнитель «NursingCareCompleter» в свою очередь инициализирует следующие транзакции: питание, размещение, проведение гигиенических процедур, проведение медицинского осмотра, наблюдение. У каждой из этих операций есть свой исполнитель, который не пересекается с исполнителями других транзакций.

sig Nutrision extends Transaction{}

{execute_trans=Nurisher

initiate_trans=NursingCareCompleter}

sig Placement extends Transaction{} {execute_trans=PlacementExecuter initiate_trans=NursingCareCompleter}

sig HygieneProcedures extends Transaction{} {execute_trans=HygieneProceduresExecuter initiate_trans=NursingCareCompleter}

sig Medicallnspection extends Transaction{}

{execute_trans=MedicalInspecter

initiate_trans=NursingCareCompleter}

sig Monitoring extends Transaction{}

{execute_trans=Monitor

initiate_trans=NursingCareCompleter}

Исполнитель «MedicalInspecter» в свою очередь инициализирует лечение и консультацию со специалистом. Причем специалист также является сложной акторной ролью из окружения.

sig Treatment extends Transaction{}

{execute_trans=Treater

initiate_trans=MedicalInspecter}

sig ExpertConsultation extends Transaction{}

{execute_trans=ExpertConsultant

initiate_trans=MedicalInspecter}

В свою очередь экземпляр сигнатуры, исполнитель «Monitor», при необходимости запускает транзакцию оказания первой экстренной помощи:

sig FirstEmergencyCare extends Transaction{}

{execute_trans=FirstEmergencyExecuter

initiate_trans=Monitor}

Проверки созданной модели реализуются на нескольких типовых запросах, которые определят интересующие нас последовательности действий, т.е. последовательности появления P и С фактов в DEMO. Приведем пример проверки на непровоти-воречивость выполнения транзакции Nursing Care. Для Проверки временной согласованности модели, запустим ее следующим образом: run show for 2 but 4 Time, 3 Transaction, 3 CompositeActorRole . Первоначальная структура экземпляров сигнатур представлена на рис. 5.

Экземпляр сигнатуры «Patient» инициализирует транзакцию (TransactionO) и она в соответствии с правилом, описанным в модели предметной области, передается на исполнение «NursingCareComleter». При запуске транзакции ей присваивается временное состояние t_pre и модель переключается на следующий момент времени — Timel (рис. 6).

Экземпляр сигнатуры «NursingCareCompleter» являясь исполнителем одной транзакции, запускает другую и тем самым становится ее инициализатором. На каждом моменте времени транзакция может характеризоваться либо состоянием «до» , либо состоянием «после». Причем время исполнения предшествующей транзакции совпадает со временем последующей, как это и было обозначено в нашей модели, т.е. TransactionO (tr_post) = Transaction1(tr_pre) (рис. 7).

При завершении транзакции на третьем шаге (рис. 8) значения атрибутов экземпляров сигнатур и отношений не вызывают логической ошибки, что подтверждает тот факт, что Модель является согласованной и валидной.

5. Заключение

В данной работе нами была построена модель метамодель методологии DEMO на языке Alloy Analyzer с соответствующим выделением основных сущностей, взаимосвязей и правил поведения присущих методологии. Для анализа бизнес-процессов реально действующего предприятия (отделения сестринского ухода) клинической больницы была смоделирована система ключевых транзакций и акторных ролей. Результатом явились разбор и ана-

DEMO_metamodel/Transaction 0

($show_t 1, tr_1)

initiatejrans ^

executejrans

Patient

execute: 2 executejrans: 4 initiate: 2 initiate trans: 5

DEMO_metamodel/Transaction 1

($show_tr2)

execute trans initiate trans ^s,

DEMO_metamodel/Transaction 2

executejrans

executejrans

ueir //a//.:'

PlatimentExecuter

NursingCareCompleter

execute

.....

initiate

initiate

Рис. 5. Отношения и экземпляры модели -TimeO

execute

DEMO_metamodel/Transaction 0 ($show_tr1, tr_pre)

initiate_trans executejrans

Patient

execute: 2 execute_trans: 4 initiate: 2 initiate_trans: 5

DEMO metamodel/Transaction 1

($show_tr2)

execute trans

DEMO_metamodel/Transaction 2

executejrans

executejrans

PlatimentExecuter

NursingCareCompleter

execute ............

.....

......execute

Initiate

initiate

Рис. 6. Отношения и экземпляры модели -Timel

DEMO_metamodel/Transaction 0 ($show_tr1, tr_post)

execute: 2 execute_trans: 4 initiate: 2 initiate_trans: 5

initiatejrans executejrans

Patient

DEMO_metamodel/Transaction 1

($show_tr2, tr_post)

execute trans

executejrans

DEMO_metamodel/Transaction 2

^initiatejrans initiate_trans

PlatimentExecuter

NursingCareCompleter

execute ............

.....

......execute

initiate

DEMO_metamodel/Executer

DEMO_metamodel/Initializer

Рис. 7. Отношения и экземпляры модели -Time2

DEMO_metamodel/Transaction 0 ($show_tr1)

DEMO_metamodel/Transaction 1

($show_tr2, tr_post)

execute trans

DEMO_metamodel/Transaction 2 tr_pre

Рис. 8. Отношения и экземпляры модели -Time3

лиз существующих процессов в ключе временной и информационной непротиворечивости. Созданная модель формализует последовательность актов в транзакциях DEMO, тем самым проверяет непротиворечивость выполнения транзакций. Была проверена возможность использования DEMO и Alloy для случаев, когда конкретные исполнители назначены на конкретные DEMO роли.

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

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

Созданная метамодель методологии DEMO на языке Alloy Analyzer может быть использована для верификации и заведомо более сложных DEMO моделей. Предполагается, что полученные результаты будут усовершенствованы в аналитическом направлении с использованием ранее полученных результатов в области онтологического инжиниринга [3, 4]. Это подразумевает под собой детализацию модели предметной области на инфологиче-ском уровне в методологии DEMO и последующую адаптацию на язык системы Alloy Analyzer. ■

Литература

1. Becker J., Kugeler M., Rosemann M. Process Management. A Guide for the Design of Business Processes. New York: Springer. 2011. 596 p.

2. Dietz J.L.G. Enterprise Ontology: Theory and Methodology. New York, Springer. 2006. 243 p.

3. Козырев О.Р., Климова Н.А., Литвинцева М.И. Анализ подходов к формальной спецификации правил корпоративной безопасности ИС на основе онтологий // Бизнес-информатика. 2010, № 3 (13). С. 28-33.

4. Abdulrab H., Babkin E., Doucy J. Dynamic Composition and Analysis of Modern Service-Oriented Information Systems // Dynamics of Information Systems: Algorithmic Approaches / A.Sorokin, P.M.Pardalos (eds.). Springer Proceedings in Mathematics & Statistics 51, 2013. P. 67-98.

5. Dietz J.L.G. Enterprise Ontology and Enterprise Architecture — how to let them evolve into effective complementary notions. GEAO Journal of Enterprise Architecture. 2007, vol. 2, no. 1. P. 121-149.

6. Бабкин Э.А., Князькин В.П., Шиткова М.С. Сравнительный анализ языковых средств, применяемых в методологиях бизнес моделирования // Бизнес-информатика. 2011, № 2 (16). С. 31-42.

7. Приказ Министерства социальной политики и Министерства здравоохранения Нижегородской области от 09.07.2009 №331/738 «Об утверждении порядка взаимодействия органов исполнительной власти при направлении граждан пожилого возраста и инвалидов, находящихся на лечении в отделениях сестринского ухода лечебно-профилактических учреждений, на стационарное социальное обслуживание».

8. Jackson D. Software Abstractions: Logic, Language and Analysis. MIT Press, 2006. 350 p.

9. Jackson D. Alloy 3.0 reference manual. 2004. 44 p.

10.Информационный сайт ГБУЗ НО «Городская клиническая больница № 34 Советского района wi\ Нижнего Новгорода» [Электронный ресурс]: http://www.gkb34.zdrav-nnov.ru/ (дата обращения 20.12.2013).

11. Положение об организации деятельности отделения сестринского ухода государственного бюджетного учреждения здравоохранения Нижегородской области «Городская клиническая больница №34 Советского района г. Нижнего Новгорода».

12.Семухина А.С., Никифоров Д.А. Пример автоматизации некоторых поддерживающих бизнес-процессов в медицинском учреждении // Системная интеграция в здравоохранении. 2010, №4 (10). - с. 76-84.

13.Кларк Э.М., Грамберг О., Пелед Д. Верификация моделей программ: Model Checking: Пер. с англ. М.: Изд. Московского центра непрерывного математического образования, 2002. - 416 с.

A METHOD FOR DETERMINATION OF CONTROVERSIES IN DEMO-MODELS OF BUSINESS PROCESSES

Eduard BABKIN, PhD in Computer Science, Professor, Department of Information Systems and Technologies, Faculty of Business Informatics and Applied Mathematics, National Research University Higher School of Economics

Address: 25/12, Bolshaya Pecherskaya str., Nizhniy Novgorod, 603155, Russian Federation E-mail: eababkin@hse.ru

Anna BUZUEVA, Student, Department of Information Systems and Technologies, Faculty of Business Informatics and Applied Mathematics, National Research University Higher School of Economics Address: 25/12, Bolshaya Pecherskaya str., Nizhniy Novgorod, 603155, Russian Federation E-mail: anna.a.buzueva@gmail.com

Kira LOGVINOVA, PhD in Mathematics, Professor, Department of Information Systems and Technologies, Faculty of Business Informatics and Applied Mathematics, National Research University Higher School of Economics

Address: 25/12, Bolshaya Pecherskaya str., Nizhniy Novgorod, 603155, Russian Federation E-mail: klogvinova@hse.ru

r

V

The article considers a problem of controversy analysis in business processes, and offers a solution of this problem proving the readers with the illustration based on the analyzing of complex healthcare business processes by the formal approach of relational logic. The approach suggested should facilitate efficiency of management in municipal healthcare organizations, specifically focusing on the aspect of quality improvement of integrated healthcare services for elder people. The scientific method of analysis is based on the particular formalism of relational logic which is implemented in the language of a widely used logical tool — MIT Alloy Analyzer. For business-process modeling we use a prospective approach of enterprise ontology and particular modeling methodology DEMO (Design & EngineeringMethodologyfor Organizations). Thatmethodology allowsforcomplete and unbiased description ofthe constructional

model of modern enterprises. Analysis of DEMO models provides for detailed understanding of management processes and plays the foundational role in business reengineering and the developing of business-aligned ICT-infrastructure. An important part of our research includes developing the formal specifications of created business-process models which are suitable forapplication offormalverification methods. Aimed at the improving reusability of the developed methods of translation from DEMO models to the language of MIT Alloy Analyzer, a new meta-model of DEMO transactions was created. Given the meta-model developed and real-life business processes of municipal healthcare enterprise we have built formal models of business-processes and have carried out their analysis of logical consistency including the temporal aspect.

Key words: business processes, healthcare, modeling languages, verification, consistency checking, formal methods.

J

References

Becker J., Kugeler M., Rosemann M. (2011) Process Management. A Guide for the Design of Business Processes, New York: Springer. Dietz J.L.G. (2006) Enterprise Ontology: Theory and Methodology, New York: Springer.

Kozyrev O.R., Klimova N.A., Litvinceva M.I. (2010) Analiz podhodov k formal'noj specifikacii pravil korporativnoj bezopasnosti IS na osnove ontologij [Analysis of approaches to the formal specification of the rules of corporate security of IS based on ontology]. Business Informatics, no. 3 (13), pp. 28-33. (in Russian)

Abdulrab H., Babkin E., Doucy J. (2013) Dynamic Composition and Analysis of Modern Service-Oriented Information Systems. Dynamics of Information Systems: Algorithmic Approaches (eds. A.Sorokin, P.M.Pardalos). Springer Proceedings in Mathematics & Statistics 51, pp. 67-98. Dietz J.L.G. (2007) Enterprise Ontology and Enterprise Architecture — how to let them evolve into effective complementary notions. GEAO Journal of Enterprise Architecture, vol. 2, no. 1, pp. 121-149.

Babkin E.A., Knyazkin V.P., Shitkova M.S. (2011) Sravnitel'nyj analiz jazykovyh sredstv, primenjaemyh v metodologijah biznes modelirovanija [Comparative analysis of the linguistic resources used in business modeling methodologies], Business Informatics, no. 2 (16), pp. 31-42. (in Russian) Order of the Ministry of Social Policy and Ministry of Healthcare of Nizhny Novgorod Region dated 09.07.2009 No.331/738 «Ob utverzhdenii porjadka vzaimodejstvija organov ispolnitel'noj vlasti pri napravlenii grazhdan pozhilogo vozrasta i invalidov, nahodjashhihsja na lechenii v otdelenijah sestrinskogo uhoda lechebno-profilakticheskih uchrezhdenij, na stacionarnoe social'noe obsluzhivanie» [About approval of the procedure of coordination of executive authorities related with assignment of aged and disabled people to social hospital service]. (in Russian)

8. Jackson D. (2006) Software Abstractions: Logic, Language and Analysis. MIT Press.

9. Jackson D. (2004) Alloy 3.0reference manual.

10. Website of the Municipal Clinical Hospital No.34, Sovetsky District, Nizhny Novgorod. Available at: http://www.gkb34.zdrav-nnov.ru/ (accessed 20 December 2013). (in Russian)

11. Statement of functioning of the nursing department of the Municipal Clinical Hospital No.34, Sovetsky District, Nizhny Novgorod. (in Russian)

12. Semukhina A.S., Nikiforov DA. (2010) Primer avtomatizacii nekotoryh podderzhivajushhih biznes-processov v medicinskom uchrezhdenii [Example of automation of some supporting business processes in medical institution]. System integration in health care, no. 4 (10), pp. 76-84. (in Russian)

13. Clarke E.M., Grumberg O., Peled D. (2002) Verifikacija modelejprogramm: Model Checking [Verification of program models: Model Checking]. Moscow: Moscow Center for Continuous Mathematical Education. (in Russian)

4.

5.

6.

7.