Особенности реализации конструктора моделей gem

Конструктор создан для работы под управлением Windows 95/98/NT и использует удобные диалоговые средства, предоставлен­ные графическим интерфейсом этих операционных систем.

Модель с точки зрения конструктора Pilgrim можно представить как набор следующих компонентов:

• граф модели;

• параметры инициализации модели;

• переменные модели;

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

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

Параметры инициализации модели - это набор переменных, включенных в функции инициализации модели modbeg и заверше­ния модели modend.

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

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

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

Основное достоинство конструктора Pilgrim заключается в том, что он позволяет:

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

• представлять каждый уровень структурной детализации в виде
графического слоя;

• автоматически генерировать программный текст модели.

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

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

При создании новой модели пользователь начинает работу с корневого уровня, и поэтому некоторые процессы модели могут быть представлены здесь в общем виде, с целью дальнейшей детали­зации. Для выполнения структурной декомпозиции к набору узлов, определяемому системой Pilgrim, конструктор добавляет новый осо-166

|ый тип - parent, использующийся исключительно как средство соз-яия наглядных многоуровневых моделей. Узел типа parent содер-ат ссылку на плоскость, его детализирующую, т.е. используется ия описания процессов, которые можно рассмотреть на отдельной носкости. Узел parent не выполняет никаких действий по обработке шанзакта и при генерации программного кода просто заменяется рвоей декомпозицией, т.е. порождаемым им слоем. Например, если Пользователь создал узел типа parent с номером 4, то в программном >айле узел с таким номером сгенерирован не будет. С точки зрения енератора программного файла узел parent представляет собой про-ртой маршрутизатор, который может иметь любое количество вхо* шов, ссылку на детализирующий уровень и единственный выход. | Рассмотрим пример на рис. 5.2, где в плоскости 1 имеется после­довательность узлов Клапан_1-»Действие_1-»Очередь_1. I Узел Действие_1 является узлом типа parent и содержит детали­зирующую плоскость 11. Плоскость 11 содержит цепочку Оче- \ редь_2-¹»Сервер_2.

Рис. 5.2. Детализация узла типа parent

В плоскости 11 стрелка, направленная из левого верхнего угла экрана в узел Очередь_2, обозначает, что этот узел является входом на плоскость, а стрелка из узла Сервер_2 в правый верхний угол — ■ что это выход с плоскости. При запуске генерации программного

файла получим следующую цепочку: Клапан_1-»Очередь_2-» Сер-вер_2->Очередь_1, т. е. узел Действие_1 является лишь средством реализации многоуровневости и будет обработан генератором как узел Pilgrim.

Иногда при построении модели может возникнуть необходимость выделения некоторых типовых действий по обработке данных. Это могут быть запросы на выполнение бухгалтерской проводки, требова­ния выделения моделируемого ресурса или какие-либо другие дейст­вия. При возникновении такой задачи удобно обозначить подпро­граммы, обращение к которым было бы возможно из любого места модели. Для этого используются узлы типа pay, rent, down. Такие уз­лы, так же как и parent, содержат переход на более низкий уровень модели, однако имеют несколько иной механизм действия и область применения. Если с помощью узла типа parent можно создавать ие­рархические модели, имеющие на любой сколько угодно глубоко вложенной плоскости новые узлы parent, то с помощью узлов типа pay, rent, down возможно лишь реализовать подпрограммы на двух слоях модели и невозможно построить общую иерархию уровней.

Рассмотрим принцип работы таких узлов на примере узла pay (рис. 5.3). На плоскости 1 находится узел типа pay, содержащий об­ращение к подпрограмме, расположенной в плоскости 12. Входом плоскости 12 является узел с названием «Расчетный счет фирмы», а выходом - узел с именем «Бухгалтерия». При генерации програм­много файла а узле «Бухгалтерия» в качестве параметра, опреде­ляющего номер следующего узла, на который переходит транзакт, будет указано не конкретное значение, а специальный параметр транзакта updown. При этом предполагается,-что каждый транзакт, попадающий в выходной узел плоскости, содержит в параметре updown номер узла, на который следует выполнить переход. Пара­метр транзакта updown инициализируется в узле типа pay, т.е. в на­шем случае в узле с названием «Плата поставщику».

Аналогичным образом реализуется переход на подпрограмму с использованием узлов типа rent и down. Они также инициализируют переменную транзакта updown. Из вышеизложенного можно сделать вывод о невозможности использовать узлы типа pay, rent и down для реализации иерархических моделей по следующей причине: на уровне подпрограммы узла одного из перечисленных типов нельзя размещать никакой из узлов типа pay, rent, down, так как каждый из этих узлов заново выполнит инициализацию параметра транзакта updown, т.е. заменит значение updown, установленное уровнем вы-168

г, организуя циклическую ссылку (это приведет к семантической

1ибке).

Чтобы защитить пользователя от совершения таких ошибок, ^структор не позволяет создавать в текущей плоскости узлы типа

t

y, rent, down, если управление передано с более высокого уровня рез узел перечисленного типа. Однако узлы обращения к подпро-ше имеют одно важное преимущество перед узлом parent. Оно шт в том, что транзакт сам «помнит», куда ему необходимо энуться; поэтому из нескольких узлов (или слоев) можно обра­щаться к общей плоскости, содержащей детальное выполнение ти­пового действия.

Обратимся еще раз к примеру, приведенному на рис. 5.3. Пред­ложим, что имеется некоторая организация, имеющая собствен-расчетный счет и выполняющая ряд операций по перечислению едств; часть операций необходимо смоделировать. В плоскости 12 раздана подпрограмма «Плата поставщику», выполняющая бухгал-врскую проводку по перечислению средств со счета фирмы. Если Цозникает необходимость смоделировать аналогичную ситуацию с Перечислением средств (например, возврат кредита), то можно соз-новый узел типа pay и указать ему в качестве подпрограммы юскость 12.

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

Иногда в модели можно выделить ряд процессов, независимых на уровне транзактов, но пересекающихся на уровне моделируемых ресурсов. Например, это может быть моделирование процесса про­изводства с участием нескольких независимых торговых компаний, приобретающих товар у производителя и имеющих свой финансо­вый резерв и рынок сбыта. Тогда можно выделить как независимые процессы торговых компаний и процесс функционирования произ­водителя. Для разработчика модели было бы неудобно восприни­мать в одной корневой плоскости несколько параллельных процес­сов, поэтому конструктор предоставляет возможность содержать несколько корневых плоскостей с целью размещения в них непере­секающихся на уровне транзактов процессов.

5.3