CC BY
34
размерностью и многоэкстремальностью решаемой задачи синтеза, несовершенством используемых методов оптимизации. Перечисленные трудности вызывают необходимость использования декомпозиционного подхода, позволяющего свести решение сложной задачи к ряду более простых. В практике проектирования общая задача синтеза топологической структуры сети разбивается на ряд подзадач:
• определения числа и местоположения узлов коммутации;
• синтез низовых сетей;
• синтез магистральной сети.
Решение перечисленных задач, в совокупности представляющих собой задачу синтеза осуществляется, как правило, с использованием приближенных эвристических методов.
Предложенная объектная модель позволяет, с учетом декомпозиции задач проектирования, использовать бионические методы, в том числе - на этапе описания объектной модели методы теории графов, а на этапе реализации алгоритмов трассировки -методы генетических алгоритмов. Развитие такого подхода к автоматизации проектирования топологий ЛВС представляется авторам перспективным как с научной, так и с практической точек зрения.
Литература
1. Мешков В.Е., Решение задачи распознавания изоморфизма графов нейросетевыми методами в процессе структурного синтеза схем РЭА // Мешков В.Е., Пономарев Д.П. Изв. Вузов. Северо-Кавказский регион. Сер. Технические науки.- 1999.- № 3.- С. 79-83.
2. Мешков В.Е., Применение генетических алгоритмов при создании локальных вычислительных сетей // Мешков В.Е., Карпенко С.С. Теория, методы и средства измерений, контроля и диагностики: Материалы II Международной научно-практической конференции, ЮРГТУ (НПИ).- Новочеркасск: ООО «Темп», 2001. Ч.4. - 76 с.
3. Мешков В.Е., Решение задачи синтеза топологии ЛВС на основе эволюционных методов проектирования // Мешков В.Е., Береза А.Н. Труды Международных научно-технических конференций «Интеллектуальные системы» (AIS”05) и «Интеллектуальные САПР» (CAD-2005). Научное издание в 4-х томах.- М. ФИЗМАТЛИТ. 2005. Т4.- 256с.- ISBN 5-9221-0621-х.-с.120-126.
4. Мешков В.Е., Информатика. Часть 3. Локальные сети в информационных системах// Мешков В.Е., Лантратов О.И. Шахты: Издательство Южно-Российского отделения Академии горных наук РФ «Недра», 2000.
УДК 004.021
РЕАЛИЗАЦИЯ НЕПОСРЕДСТВЕННОЙ ИНТЕРПРЕТАЦИИ ПРОИЗВОЛЬНЫХ
ДИАГРАММ БИЗНЕС-ПРОЦЕССОВ
Иртегов Дмитрий Валентинович, доцент, заведующий лабораторией, Новосибирский Государственный Университет, Россия, Новосибирск, [email protected] Попов Игорь Васильевич, студент, Сибирский Государственный Университет Телекоммуникаций и Информатики, Россия, Новосибирск, [email protected]
Системы управления потоками работ (workflow engines) являются важной составляющей информационной поддержки бизнеса.
Поток работ представляет собой формализованный бизнес-процесс, в ходе которого пользователи (сотрудники организаций) выполняют определенные действия в соответствии с отведенными им ролями. [1] За прошедшее время было предпринято множество попыток формализовать описание бизнес-процессов, а именно были разработаны такие стандарты как: Business Process Modeling Notation (BPMN) [2], Web Services Business Process Execution Language (WS-BPEL или сокращенно BPEL) [2, 3], XML Process Definition Language (XPDL) [2] и другие. Рассмотрим указанные стандарты подробнее.
51
BPMN - стандарт для графического описания бизнес-процессов в виде диаграмм. Основная цель BPMN - предоставить стандартизованное описание, которое было бы понятно всем участникам бизнес-процесса. BPMN ориентирован на описание абстрактных бизнеспроцессов.
BPEL - язык для описания бизнес-процессов, основанный на веб-службах. BPEL ориентирован как на описание абстрактных бизнес-процессов, так и процессов, предназначенных для непосредственного исполнения (детализированных). Из других особенностей языка следует выделить то, что для описания процессов в BPEL используется язык на основе XML, и кроме формального описания процесса BPEL также определяет принципы взаимодействия между процессами, структуры данных, а также методы работы с ними.
XPDL - язык на основе XML, предназначенный для описания всех аспектов диаграмм бизнес процессов (как непосредственно самой логики процесса, так и графической информации). Изначально XPDL задумывался как средство для обмена данными о разработанных процессах между различными продуктами.
Несмотря на предпринятые попытки, все еще не существует общепризнанного стандарта для описания бизнес-процессов и их исполнения. Одним из препятствий для выработки единого стандарта такого рода являются неясности в семантике параллельных потоков (нитей, threads) при исполнении бизнес-процессов. В частности, BPMN точно не определяет интерпретацию элемента, используемого для слияния и порождения параллельных нитей - Parallel Gateway. [4] Проблема в том, что в отсутствие ограничений на структуру, довольно просто описать противоречивый процесс - процесс, содержащий одну или несколько «мертвых» или «живых» блокировок. Некоторые противоречивые процессы можно обнаружить при анализе, но это часто требует неприемлемых затрат вычислительных ресурсов, экспоненциально растущих с возрастанием сложности диаграммы бизнеспроцесса.
Существующие системы моделирования бизнес процессов пытаются так или иначе не допустить появление противоречивых диаграмм. Многие системы, основанные на популярном языке описания бизнес-процессов BPEL [3], сильно ограничивают использование параллелизма - допускаются только процессы с блочной структурой параллельных потоков (все нити, выходящие из одного ветвления, должны заканчиваться в одном и том же слиянии).
В данной работе описывается реализация семантики, впервые предложенной Д.В. Иртеговым [1], которая позволяет интерпретировать произвольный бизнес-процесс, описанный с помощью BPMN. Этот подход не решает проблему противоречивых процессов, но позволяет обнаруживать такие процессы в ходе отладки и затем вносить в них исправления «на ходу». В данном докладе не ставится цели описать упомянутую выше семантику. Скажем лишь то, что она вводит понятие идентификатора нити, который присваивается каждому выходу элементов типа Start Event и Gateway. По этому идентификатору исполняющая система и будет определять, какие из запущенных потоков следует ждать в точках слияния.
На основе описанной выше семантики планируется разработать систему электронного документооборота, которая позволяла бы работать с бизнес-процессами, описанными с использованием BPMN. Архитектура такой системы представляет собой архитектуру клиент-сервер. При этом сервер будет хранить описание бизнес-процессов, информацию о пользователях системы и их правах, а также данные о присутствующих в системе документах. Клиенты (их может быть несколько) в свою очередь будут предназначены для хранения самих документов, а также для предоставления пользователям интерфейса для работы с системой.
На данный момент реализован прототип разрабатываемой системы. Прототип выполнен в виде плагина (plug-in) к популярной платформе XWiki Enterprise и написан на
52
языке Java. [5] Пользовательский интерфейс системы формируется документами XWiki, с использованием сценариев на языке Velocity от The Apache Software Foundation.
Рис. 1. Общая схема прототипа системы
На рис. 1 представлена общая структурная и функциональная схема прототипа. BPMN диаграмма, экспортированная в XPDL файл (обычно средствами редактора диаграмм), загружается в систему и анализируется. На этом этапе и происходит обработка диаграммы в соответствии с предложенной семантикой. После обработки информация о диаграмме заносится в базу данных.
При движении по диаграмме подшивки разделяются в точках ветвления (порождающий Parallel Gateway, Inclusive и Exclusive Gateway) и объединяются в точках слияния (слияющий Parallel Gateway). Алгоритм слияния может быть задан пользователем с помощью сценария JavaScript (используется встраиваемый интерпретатор Rhino от Mozilla.org). Состояние бизнес-процесса на каждом шаге отображается графически в виде диаграммы процесса с выделенными на ней активными элементами.
Управление продвижением процесса по диаграмме осуществляется с учетом ролей. За каждую активность на диаграмме отвечает пользователь, обладающий определенной ролью, информация о которой извлекается из XPDL файла.
Для каждого пользователя имеется возможность вывести список всех заданий, требующих его внимания на данный момент. Пользователь может произвести действие, связанное с конкретным заданием, соответствующим образом отредактировав рабочий документ. На данный момент структура рабочих документов не контролируется и может быть произвольной. После выполнения задания пользователь информирует об этом систему, отправляя подшивку дальше по диаграмме. При этом права на редактирование рабочих документов выставляются только для пользователей, чья роль соответствует текущей активности, в которой участвует подшивка.
На рис. 2 представлена UML (unified modeling language) диаграмма классов, используемых для представления BPMN диаграммы.
Рис. 2. Диаграмма классов, используемых для представления BPMN-диаграммы
53
Поясним, что представляет собой каждый класс на диаграмме:
• ProcessDefinition — класс описания бизнес-процесса (собственно класс диаграммы).
• FlowObject — класс элемента диаграммы (активности, точки слияния\ветвления, события).
• Connector - класс перехода, связывающего два элемента диаграммы.
• Script - класс, представляющий сценарий, запускающийся при выполнении элемента диаграммы (для точек слияния — алгоритм слияния подшивок).
• Role - класс, представляющий роль, которой должен обладать пользователь для работы с определенным элементом диаграммы.
• JoinGatewayThread - класс, представляющий идентификатор нити, которая может достичь данной точки слияния (см. описание самантики).
Подводя итог, можно сказать, что прототип, являясь лишь упрощенной демонстрацией работы будущей системы, может быть основой для простой системы электронного документоборота.
Работа над прототипом следующего уровня — прототипом, имеющим архитектуру клиент-сервер, ведется с осени 2009 года.
Литература
1. Иртегов Д.В. Система моделирования параллельных процессов, предназначенная для описания потоков работ // Проблемы вычислительной математики, математического моделирования и информатики: Сб. науч. тр. - М.: МЗ Пресс, 2006. - С. 232-254.
2. Havey M. Essential Business Process Modeling. - O'Reilly Media, Inc., 2005.
3. Juric Matjaz B. Business Process Execution Language for Web Services. - Packt Publishing, 2006.
4. Dijkman R., Dumas M., Ouyang C. Formal Semantics and Automated Analysis of BPMN Process Models. - Queensland University of Technology, 2007.
5. Hunter J. Java Servlet Programming. - O'Reilly, 1998.
CODE GENERATION AND TRANSFORMATION FOR VISUAL QUERIES IN UML
Wiktor Filipowicz, Polish-Japanese Institute of Information Technology, Warsaw, Poland,
Piotr Habela, Polish-Japanese Institute of Information Technology, Warsaw, Poland, [email protected] Krzysztof Kaczmarski, Warsaw University of Technology, Warsaw, Poland, [email protected] Krzysztof Stencel, Polish-Japanese Institute of Information Technology, Warsaw, Poland,
Introduction
In the VIDE project [1] we aimed at investigating the capability of executable modelling in the spirit of Model Driven Architecture (MDA) [2], following the standardized modelling languages: UML 2.1 [3], with its Actions and Structured Activities seamlessly integrated with OMG OCL 2.0 [4] expressions. This resulted in a textual programming language for precise UML behaviour specification; OCL expressions being its potentially most complex constituents. The visual nature of the high level UML constructs, inherent complexity of the expressions in some applications and the peculiarities of OCL syntax, motivated the search for a visual notation, especially for the expression part of the language. Several attempts and experimenting led us to a conclusion that the most promising solution would be exploiting the well-known concept of Query By Example (QBE) [5, 6] and applying it to UML models.
In this paper we describe a declarative, object-oriented, QBE-based approach to visualizing OCL expressions over a UML model instance, focusing on the underlying code generation and query rewriting issues.
1. Related Work
54
