Модульная структура программ математического моделирования динамических систем
Рис. 1
Сколь разными бы ни казались моделирующие программы, их модульная структура практически неизменна (см. рис.1):
Графический интерфейс ориентирован на человека и отвечает за представление математической модели в виде, понятном широкому кругу специалистов. Это могут быть блок-схемы, схемы физические принципиальные, гибридные карты состояний и пр.
Система управления базой данных отвечает за хранение объектов составленной пользователем модели и требуемые трансформации структуры ее хранилища.
Математическое ядро берет на себя основную вычислительную нагрузку, и, в цикле, согласно заданной программе, руководствуясь готовностью аргументов, а в редких спорных случаях (появление которых всегда можно избежать) приоритетностью математических операций, обеспечивает исполнение потоков математических функций.
Серверы визуализации и Online воздействий обеспечивают интерфейс между функционирующим математическим ядром и пользователем. Серверы визуализации результатов — осциллографирующие, показывающие, и индицирующие приборы — в зависимости от ситуационных требований, могут работать либо в синхронном, либо в асинхронном режиме. Серверы же Online воздействий на модель жестко синхронизированы с математическим ядром.
К большому сожалению разработчики моделирующих программ при создании своих продуктов не придерживаются современных технологий модуляризации (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
