Клиначёв Николай Васильевич

Обзор архитектурного построения программ математического моделирования динамических систем

Введение

Известно много хороших математических программ. Отнесем каждую к одной из двух групп:

  1. Мощные калькуляторы для статических вычислений (Matcad, Mathematica, Maple).
  2. Специализированные решатели для моделирования динамических процессов (DyMoLa, Dynast, Multisim, VisSim, MBTY, MVS, Simulink).

При использовании программ и той, и другой группы пользователю нужно определить последовательность математических функций, которые должны быть вычислены математическими ядрами. Фундаментальное отличие проявляется в том, что при использовании программ-калькуляторов пользователь должен рассчитывать лишь на однократное вычисление запрограммированной им последовательности функций, а при использовании динамических решателей может использовать возможности повторных вычислений. Таким образом, с одной стороны, если в вашем распоряжении программа-калькулятор, то вам нужно знать громадное количество методов, позволяющих сократить количество математических операций [2] (что спасет вас от мозоля на пальце). А с другой стороны, нельзя поспорить с тем, что при использовании динамических решателей для решений задач "в лоб" (т.е. в четком соответствии с их физической природой, без использования накрученных на физическую природу математических абстракций второго, третьего порядка или жестко формализованных (матричных) подходов), придется серьезно загрузить "бедный" процессор компьютера несколькими миллиардами математических операций аж на две или даже десять секунд.

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

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

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

Модульная структура программ математического моделирования динамических систем

Модульная структура моделирующих программ
Рис. 1

Сколь разными бы ни казались моделирующие программы, их модульная структура практически неизменна (см. рис. 1):

К большому сожалению разработчики моделирующих программ при создании своих продуктов не придерживаются современных технологий модуляризации (COM, CORBA) и предпочитают все делать самостоятельно. Их консерватизм в этом отношении создает потенциально неустойчивую ситуацию на рынке. Все представленные на рис. 1 модули могут быть не просто автономными, а уже традиционно считаются независимыми программными продуктами. Ирония в том, что математическое ядро — это наиболее простой и легкий в создании модуль. Совершенно очевидно, что создание полноценного редактора векторной графики подобного Visio или CorelDraw или же движка реляционной базы данных — это задача не для фирмы со штатом из 3..10 человек. Именно усилия, потраченные на решение этих второстепенных задач, разорили далеко не одну компанию, а проигрывают от этого пользователи.

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

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

Итак, в качестве графического интерфейса из двух кандидатов был выбран пакет векторной графики Visio, который чуть более популярен у инженеров, чем у художников. Для управления текстовым хранилищем модели с XML-разметкой был выбран не большой, бесплатно распространяемый, имеющий качественную документацию, и присутствующий на каждой машине с ОС Windows движок реляционной базы данных — COM-сервер (файл msxml*.dll). Выбор последнего вспомогательного компонента — сервера визуализации (объекта MSGraph.Chart программы Excel) не оптимален, не перспективен и определен лишь фактом его широкого распространения на машинах читателей этой статьи. Безусловно, здесь более подойдет инструментарий визуализации практически любой SCADA-системы, а лучше — библиотеки "Mearsurement Studio" for Visual Basic and Visual C++ фирмы National Instruments [9].

Вариант модульной структуры моделирующей программы
Рис. 2

Архитектура математического ядра моделирующих программ с поточной моделью управления

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

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

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

Во вторых, в силу действующих стандартов для компиляторов языка Си++, объекты порожденные от разных потомков полиморфного класса (CBlkTemplate) будут иметь реализации виртуальной таблицы функций (vtbl) одной размерности. Это означает, что их можно присвоить элементам одного массива MathBlock[i] (см. рис. 3). Что, в свою очередь, открывает возможности для создания автоматизированных процедур обслуживания объектов математического ядра. Так например, процедура исполнения шага симуляции модели в таких программах, как VisSim, Simulink, MBTY может иметь следующий вид:

Листинг 1

	for (i=0; i < numBlock; i++) {
		MathBlock[i]->Calc();
	}

Подобных процедур не много, и, в случае реализации математического ядра в виде COM-сервера, они образуют его интерфейсы (см. табл. 2).

Уделим внимание деталям реализации математического ядра. В табл. 1 приведён список важнейших атрибутов полиморфного класса, которые наследуются всеми его потомками. К ним относятся: массив указателей на аргументы pInput[j], массив возвращаемых функцией результатов Output[k] и массив параметров функции Param[n]. Размерность массивов задается значениями параметров конструкторов потомков, которые, в свою очередь, передаются им через интерфейс createBlock COM-сервера (см. табл. 2).

Таблица 1
Атрибуты полиморфного класса - общего
предка всех математических классов
CBlkTemplate.pInput[j]
CBlkTemplate.Output[k]
CBlkTemplate.Param[n]
CBlkTemplate.Calc() = 0; // virtual
CBlkTemplate. ...

В графическом представлении, экземпляры математических объектов — это блоки на блок-схеме (см. нижний фрагмент рис. 3). Наличие у каждого математического объекта массива указателей на аргументы pInput[j] делает возможным (в графическом представлении) их соединение линиями связи в требуемом порядке. Эта операция осуществляется через интерфейс createWire COM-сервера (см. табл. 2). Её результатом является присвоение значения указателя на элемент массива Output[k] одного объекта элементу массива pInput[j] другого объекта (см. цепочку повторяющихся фрагментов на рис. 3). Таким образом, совокупность показанных программных решений делает возможным создание моделей систем из любого требуемого набора математических функций, между которыми возможна любая требуемая схема передачи аргументов.

Идея архитектурного построения математического ядра моделирующих программ
Рис. 3

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

Листинг 2

	' Объявляем переменную, как математическое ядро
	Private WithEvents Mdl As SimKernel
	Private mySmplArr(100) As Double

	' Создаём из COM-сервера объект - математическое ядро
	Set Mdl = CreateObject("Klinachyov.SimKernel")

	' Устанавливаем свойства симуляции модели
	Mdl.setSimProp 0, 1, 0.01, 0

	' Создаем блоки (математические объекты или функции)
	Mdl.createBlock L702, 0, 1, 0		' inpVector
	Mdl.createBlock L101, 2, 1, 2		' summingJunction
	Mdl.createBlock L100, 1, 1, 1		' gain
	Mdl.createBlock L951, 1, 1, 1		' 1/S
	Mdl.createBlock L802, 1, 0, 0		' outVector
	Mdl.createBlock L800, 2, 0, 0		' export

	' Устанавливаем параметры блоков и начальные условия
	Mdl.setBlkParam 2, 1, 1
	Mdl.setBlkParam 2, 2, -1
	Mdl.setBlkParam 3, 1, 4
	Mdl.setBlkParam 4, 1, 0

	' Создаем связи между блоками (схему передачи аргументов)
	Mdl.createWire 1, 1, 1, 2
	Mdl.createWire 2, 1, 1, 3
	Mdl.createWire 3, 1, 1, 4
	Mdl.createWire 4, 1, 2, 2
	Mdl.createWire 2, 1, 1, 6
	Mdl.createWire 4, 1, 2, 6
	Mdl.createWire 4, 1, 1, 5

	' Устанавливаем очередность исполнения блоков
	Mdl.BildSimFlow

	' Это не важно - задаем массив выборок для обработки моделью
	For i = 0 To 99
		mySmplArr(i) = Sin(i / 7)
	Next

	' Передаем массив в математическое ядро
	Mdl.swapInputOutputSamples mySmplArr

	' Запускаем процесс симуляции модели
	Mdl.Simulation

	' Считываем обработанный моделью массив
	Mdl.swapInputOutputSamples mySmplArr

	' Запускаем сервер визуализации результатов
	' ...

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

Таблица 2 (SimKernel.dll)
 Интерфейсы (методы) COM-сервера - математического ядра
 SimKernel.setSimProp(timeStart, timeEnd, dT, mode)
 SimKernel.createBlock(IDLIB, numInp, numOut, numPrm)
 SimKernel.setBlkParam(idBlk, indexPrm, prmValue)
 SimKernel.createWire(O_idBlk, indexOut, indexInp, I_idBlk)
 SimKernel.BildSimFlow()
 SimKernel.SimStep()
 SimKernel.Simulation()
 SimKernel.ResetStates()
 SimKernel.SnapStates()
 SimKernel.swapInputOutputSamples(Array)
 SimKernel.getState(idBlk, indexOut)
 SimKernel.ControlPoints.Item(i)
   ControlPoint.onCalc(inpVector)
 SimKernel.UserBlocks.Item(i)
   UserBlock.onCalc(inpVector, outVector, prmVector)
   UserBlock.onFstStep(inpVector, outVector, prmVector)
   UserBlock.onEndStep(inpVector, outVector, prmVector)
   UserBlock.onPrmSet(prmVector)

Завершая обзор математического ядра, отметим, что представленные архитектурные решения позволяют решать системы как чисто дифференциальных уравнений (т.е. ядро может быть явным решателем), так и системы алгебро-дифференциальных уравнений (т.е. ядро может быть неявным (итерационным) решателем). Архитектура ядра не препятствует созданию, ставших уже классическими для моделирующих программ, методов частотного анализа [1]. Пользователь может свободно замещать блоки обладающие эффектом памяти (1/S, 1/Z, e-dTs) собственными процедурами, и, в любой момент, может иметь доступ ко всем координатам модели getState.

Графический интерфейс программ математического моделирования динамических систем

Графический интерфейс — это самое "слабое место" программ математического моделирования динамических систем. Попробуем разобраться с тем, что может понимать русскоязычный специалист под скромным английским термином диаграмма (diagram), если с помощью неё требуется представить описание модели системы на том или ином уровне в графической форме:

  1. Блок-схемы или около десятка именованных направленных графов.
  2. Схемы физические принципиальные электрических, магнитных, тепловых, гидравлических, акустических, механических, ротационных, и др. цепей преобразования энергий. Они же ненаправленные или би(со)направленные графы.
  3. Гибридные карты состояния или импульсные потоковые графы, графы переходных состояний.
  4. Графы алгоритмов программ.
  5. Структурные схемы, функциональные схемы, мнемосхемы.
  6. И многое другое.

Разнообразие впечатляет. Однако цель перечисления не в потрясении воображения читателя, а в том, чтобы подвести к мысли о том, что задача создания графического интерфейса непроста и не соответствует квалификации разработчиков моделирующих программ. Конечный пользователь должен понимать, что без кооперации усилий нескольких фирм эту задачу не решить (спрос пользователя рождает предложение). С задачей качественного отображения всего перечисленного, в любых масштабах, на любых устройствах ввода вывода, могут справиться лишь редакторы векторной графики — это их прямая задача. Дополнительным требованием к претенденту на её выполнение является открытость объектной архитектуры и наличие документации.

Как бы ни было велико разнообразие способов графического описания моделей, четко просматриваются лишь две техники моделирования: структурное моделирование и мультидоменное физическое моделирование. Для поддержки структурного моделирования требуется решатель систем дифференциальных уравнений и блок-схемы [3]. Для поддержки мультидоменного физического моделирования требуется итерационный решатель систем алгебро-дифференциальных уравнений и схемы физические принципиальные [4]. Другие виды графов либо мало эффективны, либо являются предками направленных и ненаправленных графов соответственно. Моделирование же управляемое событиями не является новой техникой моделирования, а лишь дополняет названные совокупностью методов переключения и синхронизации фрагментов моделей в процессе симуляции, обеспечивая тем самым программный контроль над потоком. Т.е. программный контроль над процессом прогонки массива MathBlock[i] или его фрагментов в режиме симуляции:

Листинг 3

	Пока (не случилось любое событие) Циклически исполнять фрагмент модели
		for (i=0; i < numBlock-10; i++) MathBlock[i]->Calc();
	Если (случилось такое событие) Исполнить фрагмент модели
		for (i=numBlock-10; i < numBlock; i++) MathBlock[i]->Calc();
	...
	' Использован синтаксис языка Си, дабы не усложнять список интерфейсов в табл. 2

Шлюз Visio2SimKernel

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

  1. Контроль над процессом создания рисунка блок-схемы или же схемы физической принципиальной (техника выполнения рисунка блок-схемы отличается от техники выполнения чертежа гайки и возможны специфические облегчения некоторых графических процедур; также требуется контролировать соблюдение некоторых правил создания блок-схем, например отсутствие коротких замыканий выходов и др.).
  2. Дешифровка рисунка направленного графа (блок-схемы) и трансформация информации в программирующие математическое ядро инструкции (см. листинг 2).
  3. Трансформация ненаправленного графа (схемы физической принципиальной), путем перебора уточняющих коммутаций, в виртуальный (неначерченный) направленный, точнее би- или сонаправленный граф.
  4. Дешифровка графических образов, отвечающих за программирование потока(ов), и их трансформация в инструкции переключений математического ядра, а лучше ядер, каждое из которых может отвечать за свой поток, т.е. за свой фрагмент модели.
  5. Дешифровка графических образов, отвечающих за синхронизацию потоков (ядер).
  6. Контроль над процессом симуляции модели; управление процессами визуализации результатов и синхронизации Online воздействий (фактически это еще один шлюз).

В случае использования Visio [8], в качестве графического интерфейса, модульная структура моделирующей программы, изображенная на рис. 1, может быть сокращена. Достаточно оставить Visio, COM-сервер математического ядра, а так же серверы визуализации и Online воздействий. Тому способствуют следующие благоприятные моменты. Последние версии Visio ориентированны на сохранение рисунков в файлах с XML разметкой. Роль библиотеки шаблонов блоков SimKernel_Lib.xml может выполнять определяемая пользователем библиотека графических примитивов Visio (vss-файл). Причем, последние могут иметь переопределяемые пользователем параметры, которые сохраняются в файле рисунка. Объектная модель Visio имеет разделённые коллекции для библиотечных графических примитивов (в нашем случае это блоки), для линий связи, и для коннектеров, что упрощает написание шлюза.

Для математических ядер разных производителей шлюз будет отличаться лишь синтаксисом интерфейсов (табл. 2), который должны уточнить сами производители. Реализация первых двух задач, возложенных на шлюз Visio2SimKernel весьма проста (программа на VB не превышает двух сотен строк). Данной, сокращенной версии шлюза достаточно, дабы перекрыть возможности графических интерфейсов таких программ как Simulink, VisSim, MBTY, т.е. закрыть потребности техники структурного моделирования.

Таким образом, производителю математического ядра достаточно поставить: графическую библиотеку блоков, собственный шлюз (Visio2VisSim, Visio2Simulink, Visio2MBTY) и настроенный шаблон документа Visio, дабы пользователь мог использовать его для создания новых моделей. Шлюз может быть оформлен либо в виде вмонтированного в шаблон документа макроса, либо в виде расширений: add-in'а — для контроля над процессом создания рисунка через механизм событий,  и add-on'а — для исполнения процедур дешифраций рисунка, программирования математического ядра и управления серверами визуализации и Online-воздействий.

Завершая обзор шлюза, надо отметить, что благодаря гибкости графического интерфейса на основе редакторов векторной графики, впервые у конечного пользователя моделирующих программ появится возможность решить задачу трансформации ненаправленного графа в граф направленный независимо от производителя. А это означает, что техника мультидоменного физического моделирования сделает громадный рывок вперед, поскольку перестанет быть ноу-хау нескольких фирм (см. программы: Dynast, 20-sim, Dymola, Simplorer, ITI-sim, Micro-Cap, Pspice, Multisim).

XML хранилище модели

Анализ графических примитивов и правил, используемых для выполнения рисунков блок-схем, позволяет выявить ряд объектов и принадлежащих им атрибутов, которые требуется сохранять в файле модели. Отношения между объектами демонстрирует показанная на рис. 4 схема данных. Очевидно, что для поддержания подобной информационной структуры требуется реляционная СУБД с мощными механизмами масштабирования, поиска, сортировки, обеспечения целостности данных и сохранения.

Схема данных хранилища модели
Рис. 4. Схема данных хранилища модели

К большому сожалению разработчики моделирующих программ предпочитают реализовывать собственные СУБД. Судя по функционированию программ, для большинства эта задача оказывается сложной. Вторым досадным моментом является несовместимость хранилищ (рабочих файлов) разных производителей и невозможность их непосредственного восприятия человеком. Как было упомянуто ранее, проблему может снять бесплатный движок реляционной базы данных фирмы Microsoft — COM-сервер msxml*.dll [7], последние версии которого включены в платформу .NET.

Если ориентироваться на Visio, то данный пакет уже использует этот движок для сохранения рисунков. Однако схема данных хранилища объектов Visio отличается от представленной на рис. 4. Это означает, что она не будет оптимальной (речь о нормализации базы данных) для хранения моделей и, в частности, блок-схем. Следует так же отметить, что схема данных для хранения объектов направленного графа (блок-схемы) не подойдет для хранения объектов ненаправленного графа (схемы физической принципиальной). Но различия не существенны, поэтому последнюю не рассматриваем. Более того, при использовании хранилищ с XML-разметкой, производители моделирующих программ могут придерживаться собственных схем данных — это не ограничит пользователя. Таже СУБД предоставляет механизмы XSLT-трансформаций, позволяющие без привлечения производителей переформатировать рабочие файлы одной моделирующей программы (их структуру и синтаксис) в рабочие файлы другой программы.

Одна из возможных XML-схем хранилища направленного графа (блок-схемы) представлена в виде листинга 4 (атрибуты не показаны). Большинство реляционных отношений схемы данных (рис. 4) кодируется инкапсуляцией описания соответствующих объектов внутри тегов объектов-владельцев. Лишь отношение между таблицей входов и таблицей связей задается парными атрибутами тегов <input/> и <wire/>. При отрисовке блок-схем широко используется механизм иерархической инкапсуляции повторяющегося фрагмента модели в одном составном блоке. В хранилище такие блоки имеют тег <space/>. Принцип описания инкапсуляции можно отследить по положению тегов <block/>.

Листинг 4

	<!-- XML-схема хранилища направленного графа (рисунка блок-схемы) -->
	<!-- Created by ModelStoreGate.WSC.1.00 -->
	<directed_bond_graph>
		<block>
			<space>
				<block>...</block>
				<block>...</block>
				...
				<input />
				...
				<output>
					<wire />
					...
				</output>
				...
			</space>
			<param />
			...
			<input />
			...
			<output>
				<wire />
				...
			</output>
			...
			<model>
				<name />
				<simproperties />
				<autor />
				<data />
				<description />
				<ico />
				<library />
			</model>
		</block>
	</directed_bond_graph>

Для создания хранилища и записи его на диск под управлением СУБД msxml*.dll требуется промежуточный COM-сервер, который допустимо написать на скриптах VBScript или JScript [6], но лучше на VB. Листинг 5 демонстрирует порядок использования объекта ModelStoreGate.WSC из этого сервера для экспорта блок-схемы. Сравнение листингов 2 и 5 позволяет выявить их подобие, из которого следует возможность использования шлюза Visio2SimKernel не только для программирования математического ядра, но и для экспорта рисунка блок-схемы в рабочий файл модели той или иной моделирующей программы.

Листинг 5

	/* ************************* Head ***************************** */

	// Определяем имя рабочего файла блок-схемы
	NameMakingFile = "MDL_01c.XML";

	// Создаём из COM-сервера объект для работы с хранилищем
	var	Store = new ActiveXObject("ModelStoreGate.WSC");
		Store.reConnectToLibrary("1stSim_Lib_V2b.xml");
		Store.ModelName = "K/(1+Ts) on SUB_1/S";
		Store.ModelTimeStart = 0;
		Store.ModelTimeStep = 0.01;
		Store.ModelTimeEnd = 1;
		Store.ModelSimMode = 0;
		Store.Autor = "Nikolay Klinachyov";
		Store.Date = "10.11.2003";
		Store.Description = "Модель апериодического звена "
		+ "на субмодели дискретного квазианалога интегратора";
		Store.Ico = "apper.ico";

	// Создаем корневой составной блок
	// Определяем указатель на субобласть составного блока
	rtB = Store.addBlock("L001", null);

	/* ************************* Begin **************************** */

	// Создаем блоки внутри корневого составного блока
	Store.addBlock("L701", rtB);		// 1(t-dT)
	Store.addBlock("L101", rtB);		// summingJunction
	Store.addBlock("L100", rtB);		// gain
	Store.addModel("SUB_1S.XML", rtB);	// 1/S: 6+1 блок
	Store.addBlock("L800", rtB);		// export

	// Добавляем дополнительные входы и выходы блокам
	// Store.addInput(2);
	// Store.addOutput(0);

	// Устанавливаем параметры блоков и начальные условия
	Store.setParam( 1, 1, 1.0);
	Store.setParam( 1, 2, 0.05);
	Store.setParam( 2, 2, -1.0);
	Store.setParam( 3, 1, 4.0);

	// Создаем связи между блоками (схему передачи аргументов)
	Store.addWire( 1, 1, 1, 2);
	Store.addWire( 2, 1, 1, 3);
	Store.addWire( 3, 1, 1, 4);
	Store.addWire( 4, 1, 2, 2);
	Store.addWire( 2, 1, 1,11);
	Store.addWire( 4, 1, 2,11);

	/* ************************* End ****************************** */

	// Сохраняем хранилище в файле
	Store.save( NameMakingFile );
	// WScript.Echo("File " + NameMakingFile + " successfully created");
	// Store.visualizationInMSIE( NameMakingFile );

Фактически, объект ModelStoreGate.WSC отвечает за трансформацию линейного потока команд в иерархическое хранилище. Безусловно, при считывании рабочего файла в целях визуализации редактором векторной графики или же для прямого программирования математического ядра требуется обратное преобразование. Оно может быть выполнено одной процедурой с соответствующими параметрами, примером которой является командный скрипт XML2SimKernelGate.WSF см. рис. 2.

Резюме

В статье описана модульная структура программ математического моделирования динамических систем. К основными компонентам отнесены: редактор векторной графики, СУБД, математическое ядро, серверы визуализации и Online-воздействий.

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

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

Сформулированы задачи, которые должны решать модули стыковки основных компонент программ математического моделирования динамических систем. Предложена схема данных и XML-схема хранилища направленного графа (рисунка блок-схемы), что может вызвать интерес у разработчиков.

Литература

  1. Клиначёв Н. В. Основы моделирования систем или 7 доменов законов Ома и Кирхгофа: Избранные фрагменты. - Offline версия 3.1. - Челябинск, 2000-2004. - 68 файлов, ил.
    – Website: http://model.exponenta.ru/oms_lec.html.
  2. Клиначёв Н. В. О структурном кризисе в методике преподавания блока дисциплин связанных с расчетом цепей преобразования энергий. - Челябинск, 2003.
    - Website: http://model.exponenta.ru/lectures/sml_05.htm.
  3. Клиначёв Н. В. Введение в технологию моделирования на основе направленных графов. - Челябинск, 2003.
    – Website: http://model.exponenta.ru/lectures/sml_02.htm.
  4. Клиначёв Н. В. Введение в технологию мультидоменного физического моделирования с применением ненаправленных графов. - Челябинск, 2003.
    – Website: http://model.exponenta.ru/lectures/sml_03.htm.
  5. Герберт Шилдт. Самоучитель C/C++: пер. с англ. - 3-е издание. - СПб.: БХВ Петербург, 2001. - 688 с.
  6. Microsoft Corporation. Microsoft® Windows Script Technologies Development Center. – Website: http://msdn.microsoft.com/scripting.
  7. Microsoft Corporation. Microsoft® XML Development Center. – Website: http://msdn.microsoft.com/xml.
  8. Microsoft Corporation. Microsoft® Visio Development Center. – Website: http://msdn.microsoft.com/visio.
  9. National Instruments Corporation. NI® Measurement Studio Development Center. - Website: http://www.ni.com/mstudio.

3.02.2004