Software & Systems

Процессно-ориентированный метод широко применяется в параллельных вычислениях, в системах сбора и обработки данных, при моделировании информационных процессов на производстве [1–4]. Используемые нотации сходны между собой на уровне взаимодействия процессов: это графы, вершины которых обозначают процессы, а дуги – информационные связи. Отличие состоит в способе описания процессов и логики их взаимодействия. В статье предлагается новый метод спецификации перечисленных аспектов процессной модели, позволяющий: 1) описывать протоколы взаимодействия процессов в виде последовательности передаваемых сообщений; 2) представлять логику работы процессов посредством процедур, обрабатывающих сообщения; 3) визуализировать процессы и их взаимодействие при помощи аннотированных графов.

Композиция процессов. Параллельная система в целом моделируется как композиция элементов модели «процесс» и элементов модели «канал». Интерфейсными элементами процессов, участвующих в композиции, являются порты. Система «разветвление–слияние» ForkJoin в описываемой нотации представлена на рисунке 1. Родительский процесс p выдает задания дочерним процессам c1 и c2, а затем выполняет обработку их ответов.

Пометки графа на рисунке 1 обозначают: p:Parent – процесс p типа Parent; p1->p:Call – клиентский порт p1 (процесса p), связанный с серверным портом p (процесса c1) каналом, имеющим тип Call; точка на дуге указывает положение серверного порта.

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

На рисунке 2 показан протокол взаимодействия между родительским и дочерним процессами в системе «разветвление–слияние», описанный каналом Call. Пометки графа на рисунке 2 обозначают: s0 – начальная вершина процесса-клиента; s1 – вершина процесса-сервера; s2 – вершина процесса-клиента; call и ret – передаваемые сообщения.

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

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

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

Граф на рисунке 2 показывает, что вначале клиент (родительский процесс p на рис. 1) передает дочернему процессу сообщение call, затем получает от него сообщение ret. На этом взаимодействие заканчивается.

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

Примеры графических обозначений, используемых на диаграммах процессов, показаны на рисунках 3 и 4. Пометки графов обозначают: fork – начальная вершина, запускающая алгоритм обработки в начальном состоянии; call и ret – получаемые или отправляемые сообщения; p1 и p2 – клиентские порты процессов; p – серверный порт процесса; join, proc, error – методы обработки сообщений в процессах; yes, no – передача управления в случае успешного или неуспешного завершения процедуры обработки.

Состояние процесса – это переменная, хранящая значение текущей вершины графа процесса. Когда обработка не выполняется, переменная хранит специальный признак останова. Если имеется сообщение, отправленное процессу, то рано или поздно начнется обработка данного сообщения с вершины-порта (p, p1 или p2 на рис. 3 и 4). Переменная состояния процесса примет значение соответствующей вершины.

Правило передачи управления для портов: если имеется исходящая дуга с пометкой yes, управление передается по ней; если имеется исходящая дуга, помеченная поступившим сообщением, управление передается по ней; иначе, если имеется дуга с пометкой no, управление передается по ней.

Правило запуска процедуры обработки сообщений: процедура запускается, если одновременно (1) переменная состояния принимает значение вершины, помеченной данной процедурой; (2) возможен прием сообщений, ведущих в эту вершину; (3) возможна отправка сообщений, исходящих из данной вершины.

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

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

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

Рассмотрим примеры процессов, изображенных на рисунках 3 и 4. Вычисления начинаются с выполнения метода fork процесса Parent. Он формирует и отправляет сообщения call дочерним процессам по портам p1 и p2. Так как из вершины не исходят дуги с пометками yes или no, обработка заканчивается. Сообщения call попадают в связанные дочерние процессы Child через порт p. Запускается метод proc. Его параметрами являются поступившее сообщение call и формируемое для отправки сообщение ret. В случае неуспешного завершения метода proc отправка сообщения ret не производится, а запускается метод error. Иначе в родительский процесс отправляется сообщение ret. При поступлении сообщения на порт p1 в процесс Parent управление немедленно передается в метод join. Альтернативную возможность передачи управления реализует порт p2. Здесь происходит проверка типа поступившего сообщения. Метод join родительского процесса Parent запускается, когда ответные сообщения ret придут от обоих дочерних процессов.

Применение и программная реализация. Описанный метод моделирования применяется для разработки параллельных алгоритмов численного моделирования [5], его программная реализация подробно рассмотрена в [6]. Представленные в работе диаграммы кодируются на языке разметки XML. Они преобразуются транслятором моделей с языка разметки в исполняемый код на языке С++. Для исполнения сгенерированных программ имеются модуль системы исполнения с отладочным последовательным кодом, модули многопоточного исполнения для API Win32 и API POSIX, примеры тестовых приложений и графический редактор для создания моделей. Транслятор моделей реализован на языке C/C++, использует SAX-парсер Expat 2.0.1 для разбора XML-файлов. Система автоматизации параллельного программирования, основанная на представленном методе моделирования параллельных процессов, доступна для использования на сайте СГАУ по адресу: http://graphplus.ssau.ru.

Литература

1.     Process Description Capture Method. URL: http://www.id­ef.com/IDEF3.htm (дата обращения: 30.05.2012).

2.     Unified Modeling Language. URL: http://www.omg.org/ spec/UML/ (дата обращения: 30.05.2012).

3.     The Ptolemy Project. URL: http://ptolemy.eecs.berke­ley.edu/ (дата обращения: 30.05.2012).

4.     Шеер А.В. ARIS – моделирование бизнес-процессов. Издат. дом «Вильямс», 2000. 175 с.

5.     Востокин С.В. Визуальное моделирование в разработке параллельных алгоритмов. Метод и программные средства. LAMBERT Academic Publishing, 2011. 304 c.

6.     Востокин С.В. Система автоматизации параллельного программирования Graphplus templet / В сб.: Параллельные вычисления и задачи управления: тр. Пятой междунар. конф. М.: ИПУ РАН, 2010. С. 1143–1156. URL: http://paco.ipu.ru/pa­co2010.iso (дата обращения: 30.05.2012).