Рис. 3.5. Диаграмма классов библиотеки численных методов для задач гидромеханики и массопереноса (теплопереноса) в нотации UML
На рис. 3.5 представлена диаграмма классов элементов библиотеки, соответствующая сокращённой объектной нотации UML (Unified Modeling Language). Каждый класс на диаграмме характеризуется (помимо названия) физически значимыми данными (параметрами); а вспомогательные данные, необходимые для реализации численных методов, опущены. Например, опущены элементы, с которыми взаимодействуют экземпляры данного класса, поскольку эта информация представлена в табл. 4 приложения. В связи с тем, что язык программирования Java, на котором написана библиотека, не поддерживает множественного наследования классов, аналогичный множественному наследованию результат получен за счёт механизма агрегации (делегирования некоторых функций объекта агрегируемому объекту), а также за счёт использования интерфейсов (на диаграмме не показаны). По соображениям наглядности диаграмма русифицирована, и в ней опущены названия всех методов элементов. Более подробная информация о физическом смысле элементов библиотеки и их назначении приведена в приложении.
В данной главе с точки зрения вычислительной математики проанализирован предложенный в главе 2 подход к построению и реализации моделей сложных систем. Для многих понятий, встречающихся в области численных методов, (система уравнений, схема, сетка и т.п.) разработаны объектные эквиваленты и указаны алгоритмы их взаимодействия. Обоснована эффективность использования объектно-ориентированных методов, связанных с некоторыми более специфическими понятиями (например, с гибридными схемами или нерегулярными сетками), в то время как для других понятий (например, для неявных схем и адаптивных сеток) отмечены (и, отчасти, решены) проблемы их объектного представления. Исследован также вопрос о повышенной ресурсоёмкости объектных вычислений по сравнению с процедурными, на который, однако, дан неоднозначный ответ. Многие свойства объектно-ориентированного подхода проиллюстрированы на широко известных численных методах, из которых выбраны наиболее ему соответствующие, а также указаны методы, которые следует реализовывать только в процедурных программах. Показано, что основанные на объектах алгоритмы реализации численных методов, в особенности на нерегулярных сетках, могут стимулировать развитие этих методов как таковых. Эффективность подхода также показана при описании структуры библиотеки численных методов, связанной с конкретной предметной областью (гидромеханика и массоперенос).
До сих пор были описаны проблемы оптимального представления структуры моделей (глава 2) и численных методов (глава 3) в оперативной памяти компьютера, прежде всего в процессе создания моделей и выполнения расчётов с ними. В данной главе процесс моделирования рассматривается на большем временном интервале, затрагивается хранение данных модели в постоянной памяти и работа со многими версиями моделей. В этой области также возникает несколько проблем, которые эффективно решаются на основе объектно-ориентированного подхода.
Прежде всего, данные математических и имитационных моделей (а особенно комплексных моделей, соединяющие в себе оба подхода) имеют чрезвычайно различную природу. Их можно условно классифицировать по следующим критериям:
1) входные и выходные (важно для всех моделей);
2) данные о предметной области и данные о расчётных алгоритмах (для моделей с редактируемыми численными методами);
3) качественные и количественные (для моделей с редактируемой структурой);
4) структурные и функциональные (для моделей с экспертными зависимостями);
5) статические и динамические (для нестационарных моделей);
6) точные (константные) и неточные (часто изменяемые);
7) распределённые и сосредоточенные данные (для математических моделей, основанных на уравнениях в частных производных).
Для всех этих типов данных способ их хранения должен, так или иначе, отличаться. Если для хранения в оперативной памяти компьютера структуры данных объектно-ориентированных языков программирования в какой-то мере решают эту проблему, то для хранения данных в постоянной памяти объектно-ориентированного подхода (по крайней мере, в его традиционном понимании) недостаточно. Объектно-ориентированные базы данных – интенсивно развивающееся в настоящее время направление теории и реализации БД – могут облегчить унифицированное хранение входных и выходных, качественных и количественных, распределённых и сосредоточенных данных, но отнюдь не статических и динамических; они также не в состоянии оптимизировать хранение точных (часто изменяемых) и неточных (редко изменяемых) данных.
неоднородные данные | вычислительные | |||||||
качественные | количественные | данные ПО | ||||||
структурные | распределённые | входные | ||||||
функциональные | сосредоточенные | выходные | ||||||
динамические | неточные (часто изменяемые) | |||||||
статические | точные (редко изменяемые) |
Рис. 4.1. Неоднородность данных моделей
Таким образом, без преувеличения можно сказать, что при моделировании сложных систем возникает самые большое число типов данных, чем в любой другой области применения компьютеров. И тем не менее, в настоящее время не существует не только системы управления базой данных (СУБД), которая бы поддерживала эту особенность задач моделирования, не существует даже теоретической основы для такой системы. С одной стороны, это обусловлено тем, что на проблему хранения данных вычислители не обращают внимания, а разработчики СУБД не задумываются над потребностями относительно узкой предметной области, реализация которых требует серьёзных исследований. Если же говорить об объективных причинах, то разнообразие данных моделей действительно кажется слишком большим, чтобы применять к ним какой-либо универсальный подход. Как следствие, разработчики каждой модели придумывают свою нестандартизованную файловую структуру для хранения её «уникальных» данных, и эта структура не отвечает даже тем требованиям, которые предъявляются к обычным базам данных.
В данной части работы (в главе 4) исследуются общие черты данных, возникающих в разнообразных моделях, показывается, что они не являются уникальными, и на основе этого разрабатывается подход к стандартной СУБД, которой удобно пользоваться как в универсальных системах моделирования, так и в частных моделях.
Построение модели любой системы начинается с качественного описания входящих в неё подсистем, их параметров и связей, то есть с создания схемы модели (см. рис. 4.2 и табл. 4.1). Например, если создаётся распределённая модель, данные схемы включают геометрию системы и построенную на ней сетку. При этом используются метаданные о тех вычислительных алгоритмах, которые предполагается использовать, и эти метаданные тоже должны быть явно представлены и где-то храниться. После создания схемы задаются числовые значения всех её параметров, а также функциональные зависимости между ними. После того, как и эта информация заложена в базу данных, модель формально готова к вычислениям. Однако на этапе использования модели возникает ещё множество динамических результатов, которые соответствуют конкретному сценарию моделирования, то есть набору некоторых исходных данных.
База данных | |||||||||
Ожидаемые результаты | |||||||||
Метаданные 1 | Метаданные 2 | ||||||||
Схема 1.1 | Схема 1.2 | …… | |||||||
Модель 1.1.1 | Модель 1.1.2 | …… | |||||||
Сценарий 1.1.1.1 | Сценарий 1.1.1.2 | …… |
Рис. 4.2. Влияние методологии моделирования на структуру данных