Інструментальні програмні засоби інтеграції математичних моделей у системи підтримки прийняття рішень з екологічної безпеки

Предмет:

Тип роботи:

Автореферат

К-сть сторінок:

Мова:

Українська

Оцінка:

прийняття рішень по зниженню наслідків можливих аварій, оптимальному захисту населення в умовах обмежених ресурсів з урахуванням значної кількості взаємопов’язаних екологічних, медичних, економічних, технічних та соціальних факторів на підставі моделюючих прогностичних блоків і інформації про поточний стан технічних об’єктів і навколишнього середовища. Системи, спрямовані на підтримку контрзаходів безпосередньо в перші дні після техногенної аварії повинні включати програмні засоби отримання інформації програмним моделюючим комплексом від системи радіаційного, хімічного і гідрометеорологічного моніторингу території (“он-лайн” режим реального часу). Географічна інформаційна система (ГІС) СППРЕБ повинна включати картографічну інформацію про фізико-географічні, господарські, демографічні і екологічні характеристики території, для якої буде впроваджена система. Висока складність окремих компонент СППРЕБ, необхідність ретельного тестування як системи в цілому, так і її окремих компонент, вимоги “гнучкості” СППРЕБ приводять до того, що компоненти СППРЕБ, програмно реалізуються у вигляді окремих модулів, а СППР будується шляхом інтеграції цих модулів. У розділі проведено аналіз основних властивостей типових програмних реалізацій математичних моделей, баз даних і ГІС, що використовуються в СППРЕБ.

Програмні реалізації математичних моделей, що використовуються у СППРЕБ, мають такі характерні особливості, важливі з точки зору інтеграції:

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

-Найбільш поширеними програмними реалізаціями моделей є: виконувана програма, реалізація моделі у середовищі пакетів “динамічного моделювання” або у вигляді програмного коду на мові FORTRAN.

-У межах одної СППРЕБ моделі, як правило, мають однакову моду виконання (наприклад є програмами) та тип вхідних і вихідних даних (наприклад, передають і одержують інформацію у вигляді текстових файлів). Однак, формат вхідних та вихідних даних, як правило, відрізняється у різних моделей, і, якщо моделі реалізуються незалежно, стандартизація форматів практично неможлива.

-Моделі, як правило, не використовують сучасні засоби відображення інформації та обміну даними.

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

У розділі розглянуто дослідження в областях, що заклали основи методологій інтеграції моделей, ГІС і баз даних у СППРЕБ. Проведено порівняння переваг та недоліків різних методик інтеграції як з точки зору часу і складності розробки системи, так і простоти користування нею. Докладно розглянуті структура, функціональне наповнення і методи інтеграції моделей СППР RODOS.

У другому розділі проведено обгрунтування об’єктно-орієнтованого підходу до побудови СППРЕБ, запропоновано мову програмування LIANA та подано методику інтеграції математичних моделей у системи підтримки прийняття рішень з питань екологічної безпеки на базі опису структури та зв’язків наборів даних, що використовуються у СППР і є вхідними та вихідними наборами даних моделей.

Для інтеграції моделей, що мають вищенаведені властивості, запропоновано використовувати об’єктно-орієнтований підхід при побудові СППР. Відповідно до аналізу, що проведений у розділі 1, ціллю застосування СППРЕБ є підготовка наборів даних для кожного з етапів процесу прийняття рішення та відображення їх засобами інтерфейсу користувача. Зауважимо, що набори даних у СППРЕБ знаходяться у ієрархічній залежності один від одного і можуть бути представлені у вигляді дерева, коренем якого є рішення у формі звіту, що потребує керівник, а листками є вхідні дані. “Рівень” користувача СППРЕБ (експерт, керівник) задається тим, які набори даних він потребує від системи. Розглянуті у розділі 1 властивості моделей дозволяють поставити у відповідність кожному вхідному або вихідному набору даних моделі (наприклад, кожному текстовому файлу) деякий “внутрішній” набір даних.

Типи та ієрархічна залежність усіх “внутрішніх” наборів даних можуть бути зручно задані за допомогою класів об’єктно-орієнтовної мови, що підтримує спадкування об’єктів та можливість використовувати об’єкти як складові інших об’єктів. Нехай кожний ”внутрішній” набір даних відповідає деякому об’єкту (або декільком об’єктам). Автоматична побудова та збереження наборів даних буде забезпечено при умові, що об’єктно-орієнтована мова буде підтримувати властивість сталості об’єктів. Однакова “фізична” природа вхідних та вихідних наборів даних усіх моделей дає змогу описувати ланцюги “вихідний набір даних моделі”  об’єкт та об’єкт  “вихідний набір даних моделі” у рамках операторів вводу-виводу. Мова повинна також підтримувати можливість завдання як мінімум трьох “системних команд” – “виконати модель та прочитати її вихідний набір даних”, “записати внутрішній набір даних як вхідний набір даних моделі”, “сповістити користувача про необхідність створення внутрішнього набору даних за допомогою засобів інтерфейсу користувача”.

Запропонована об'єктноорієнтована мова LIANA (Табл. 1) задовольняє цим вимогам і дозволяє формалізувати різні аспекти розробки та використання СППР з екологічної безпеки.

Для реалізації LA (1) алгоритму розбору, синтаксис мови був представлений з використанням розширеної форми Бекуса-Науера (БНФ). Наприклад, клас задається наступним правилом:

клас =

[Storage Global | Local [Uniq]] Class ім’я_класу *”, ” ім’я_батьківського_класу *

“{“

[Produces”: ”] {oпис_даних_основного_типу | опис_класу }

{Produces”: ” {опис_даних_основного_типу | опис_класу}

| Private”: ” {опис_даних_основного_типу } }

{Produces”: ” {опис_функції} | Private”: ” {опис_функції} }

[Needs”: ” {опис_об’єктів} {базовий_оператор} ]

[Realization”: ” [RUN ім’я_моделі”; ” | SAVE”; ” | MESSAGE строка”; ” | DEFAULT ціле”; ”] ]

[ (Represented AS ім’я_файлу”: ” оператор_виводу | базовий_оператор {оператор_виводу | базовий_оператор}) | (Represented”: ” {оператор_вводу | базовий_оператор}) ]

[Table”: ”[ оператор_опису_таблиці]]

{ базовий_оператор}

“}”.

При використанні вказаної методики,