CC BY
88
УДК004.048
ПРИНЦИПИ ПОБУДОВИ АДАПТИВНИХ АЛГОРИТМІВ ВИРІШЕННЯ ЗАДАЧ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ
ДВУХГЛАВОВ Д.Е.__________________________
На основі аналізу особливостей розробки програмної реалізації алгоритмів вирішення задач підтримки прийняття рішень пропонується підхід до їх розробки, який передбачає використання під час розробки інтелектуальних інформаційних технологій.
Наукова задача
Результат діяльності більшості галузей на сучасному етапі визначається ефективністю рішень, що приймаються безпосередньо людиною. Це стосується і задач аналізу поточної ситуації, в яких необхідно як можливо точніше визначити тип ситуації для визначення подальших дій; і задач прогнозування результатів дій, що дозволить оцінити власну вигоду та затрати; і задач оперативного управління, коли від швидкості реакції на зміни в обстановці залежить загальний успіх. В сучасних умовах прийняття ефективних рішень у встановлені терміни потребує використання систем підтримки прийняття рішень (СІ IIІР).
В роботі [1] проказано, що розробка програмного забезпечення СППР здійснюється на використанні інформаційного або когнітивного підходу. В [2] на основі аналізу показано, що використання тільки одного із підходів на практиці є неможливим та вказано, яким чином можна поєднати переваги кожного з підходів. Але застосування запропонованих принципів стримується через відсутність чітко визначеної технології розробки програмного забезпечення СППР. Таким чином, наукова задача полягає у розробці методики програмного забезпечення СППР на основі підходу, запропонованого в [2]. Задачею дослідження є обґрунтування структури алгоритмів програмних модулів та принципів представлення даних в СППР як складових частин зазначеної методики.
Обґрунтування необхідності розробки адаптивних програмних модулів
введення параметрів (встановлений середній бал та номер групи) та здійснити відбір студентів потоку за заданим критерієм. Варіант форми представлений на рис.1.
ПОШУК ВІДПОВІДІ НА ЗАПИТАННЯ: «Характеристики оВєкту
задовольняють параметри відбору?» на основі
ПРАВИЛ ВІДБОРУ ЕЛЕМЕНТОВ
Всі об'єкти проаналізовані?
Рис. 1. Схема алгоритму відбору
Текст процедури, яка здійснює відбір програмного модуля, створеного в середовищі програмування Borland C++ Builder6, наведений нижче.
void___fastcall TMainForm: :ButtonOtborClick(TObject
*Sender)
{
// TableObjects - таблиця, що містить список об’ єктів, // що аналізуються (список потоку)
// Введеня значень параметрів критерію відбору: AnsiString P1 = EditP1->Text; // Номер групи //Мінімальне значення середнього балу float P2 = StrToFloat(EditP2->Text);
Зміст підходу, що пропонується в роботі, розглянемо на прикладі вирішення задачі відбору у такій постановці . В деканаті вищого навчального закладу створена база даних, яка містить певний перелік відомостей про студентів. За підсумками семестру керівництво факультету прийняло рішення про заохочення студентів, які завершили сесію із середнім балом не нижче 4,5. Навчальній частині поставлене завдання здійснити відбір студентів і представити їх списки по групах.
За традиційною технологією для автоматизованого вирішення такої задачі можна розробити форму для
// Перегляд всіх елементів та перевірка на // відповідність критерію
TableObjects->First(); // Вибір першого елемента // як поточного while (!TableObjects->Eof)
{
// Перевірка відповідності характеристик поточного // елемента заданому критерію if ((TableObjects->Fields->Fields [ 1 ] ->As String
28
РИ, 2008, № 3
= = P1) &&
(TableObjects->Fields->Fields[1]->AsFloat > P2))
{
// Додати у вихідний перелік
ListBoxOtbor->Items->Add
(TableObjects->Fields->Fields[0]->AsString);
}
// Перехід до наступного елемента TableObjects->Next();
}
}
Виділені напівжирним шрифтом елементи є ключовими в роботі алгоритму. Компонент TTable з ім’ям TableObjects пов’язаний із створеною на диску таблицею бази даних у форматі Microsoft Access, яка містить відомості про студентів - прізвище, код групи, середній бал складання останньої сесії. Параметр Р1 -це номер групи, який вводиться співробітником навчальної частини. Також вводиться параметр Р2 -граничний середній бал.
Яким чином може бути використана ця програма у майбутньому і хто зможе її переробити у випадку зміни умов відбору? Модифікація такої програми нескладна - для цього потрібно лише додати одну строчку до оператора if блоку, який позначений коментарем “Перевірка відповідності характеристик поточного елемента заданому критерію”. Але її здійснити може тільки прогр аміст, який має навички розробки програм у даному середовищі. Слід звернути увагу, що в іншу частину коду не вноситься жодних змін. Після зміни програмного коду передбачається перекомпіляція проекту. Для цього принаймні потрібна наявність файлів проекту на персональному комп’ютері (ПК), хоча зазвичай на ПК користувачів розташовується тільки файл програмного додатку, тобто можливі додаткові витрати часу, пов’язані із переміщенням файлу після перекомпіляції безпосередньому користувачу.
Для наближення до технічної галузі розглянемо таку задачу. Для організації обміну інформацією в телекомунікаційній системі існує алгоритм, який виконує такі функції: визначає вузли мережі, в яких зберігаються файли з необхідною інформацією, сегментує файл для реалізації паралельної передачі, підбирає вузли, лінії комунікації забезпечують передачу інфор -мації до користувача із швидкістю, не меншою за встановлену.
Наведений вище алгоритм відбору студентів може бути швидко перероблений у алгоритм відбору вузлів передачі файлів. Що для цього необхідно? Створити базу даних, яка буде містити інформацію про вузли телекомунікаційної системи, відомості про швидкість передачі та файли, що зберігаються у вузлі. Нехай це буде таблиця в форматі Microsoft Access TableNodes
із полями NodeName, Speed, FileName. Параметрами відбору будуть назва файлу (Р1) та встановлена швидкість передачі інформації (Р2).
Передивитися знову процедуру відбору, наведену вище. Вона не зміниться!!! Всі зміни будуть внесені під час підготовки проекту. Необхідними змінами є встановлення зв ’язку компонента TableObj ects із таблицею TableNodes, а також зміна підписів перед параметрами. Слід звернути увагу, що знову для адаптації до певної предметної області необхідно провести модифікацію програмного модуля та перекомпілювати його.
У тому, що процедура не змінилась, немає нічого дивного. Обидва процеси можуть бути представлені однією схемою алгоритму відбору (рис.2).
Рис. 2. Структура для зберігання об’єктів довільної предметної області
Таким чином, розгляд двох задач із різної сфери діяльності людини показує, що вони мають спільну схему вирішення і відрізняються:
об’єктами, аналіз яких проводиться під час відбору;
умовами, на основі яких здійснюється відбір.
Отже, програмний модуль може бути побудований як засіб реалізації команди такого формату:
ВІДБІР (Перелік об’єктів аналізу, система правил відбору).
В роботі [2] запропоновано спосіб представлення правил обробки для пошуку визначення відповіді на питання “Задовольняють характеристики об’єкта параметрам відбору?”, який базується на мережній моделі знань. В статті [3] представлений варіант зберігання системи правил в ПК, а в [4] викладена методика
РИ, 2008, № 3
29
логічного виведення на базі запропонованої моделі. Виходячи з цього, для передачі до процедури правил відбору нео бхідно указати назву відпо відної мер ежно ї моделі.
Представлення даних для адаптивних програмних модулів
Яким чином представити об’єкти аналізу так, щоб їх можна було передавати як параметр до процедури відбору? Для цієї проблеми теж було знайдено рішення - необхідно всі потрібні дані представляти у структурах ЄДИНОГО вигляду, а краще за все - у одній таблиці, розрізняючи класи об ’єктів. Ключовою ідеєю такого представлення є твердження, що елементи будь-якої предметної області є об’єктами, які мають певні характеристики та певним чином взаємодіють між собою.
Характеристика може зберігати значення одного з шести типів: цілі значення (не допускається дробова частина), числові (допускається дробова частина), символьні, логічні (істина або хибне), дата та час.
Крім цього, для кожної хар актеристики встановлюється обмеження на допустимі значення. За цим параметром характеристики поділяються на перечислимі та непе-речислимі. Якщо тип характеристики встановлений „перечислима”, то для неї попередньо визначається набір можливих значень. Для неперечислимих характеристик значення є довільні. Для перечислимих характеристик одне з можливих значень може бути встановлене як значення за замовчуванням. Це те значення, яке буде автоматично присвоюватись характеристиці під час створення певного об’ єкта заданого типу. В загальному випадку введення значення за замовчуванням не є обов’язковим.
Для характеристик, що зберігають числові та цілі значення, якщо вони є неперечисленими, можна визначити обмеження на максимальне і (або) мінімальне значення. У цьому випадку при введенні певних значень буде виконуватися перевірка відповідності значень характеристики введеним обмеженням.
Щоб створити базу даних, яка дозволить зберігати структуру предметної о бласті у такому вигляді, ввести перелік таких суттєвостей:
ТИП ОБ’ЄКТА (таблиця ObjTypes);
ОБ’ЄКТ (таблиця Objects);
ХАРАКТЕРИСТИКА (таблиця Xarakt).
Для семантичної структуризації характеристик вони поєднуються в класи, які призначаються для кожного типу об’єктів (таблиця Classes). Включення характеристики до класу здійснюється шляхом введення відповідного зв’язку до таблиці XarClassType та супроводжується встановленням: значення по замовчуванню, одиниць виміру, мінімального та (або) максимального значення (для числових характеристик) або максимальної довжини строки (для символьних значень). Можливо також встановити змінну, яка буде
визначати, що значення характеристик буде обиратись із завчасно створеного переліку значень.
Значення характеристик, що входять до певного класу, спочатку зберігаються в таблиці (таблиця Zn), а потім пов’язуються із певними об’єктами відповідного типу шляхом введення відповідних записів у таблицю ZnXarObj.
Якщо застосовувати такий спосіб збереження об’ єктів предметної області, то виклик оператора вибору для випадку відбору студентів для заохочення буде виглядати так:
ВІДБІР (“РЕЗУЛЬТАТИ СЕСІЇ 1 КУРС ЛІТО”, “ВІДБІР ЗА СЕРЕДНІМ БАЛОМ ПО ГРУПАХ”).
Передбачається, що мережа “ВІДБІР ЗА СЕРЕДНІМ БАЛОМ ПО ГРУПАХ” створена і внесена до відповідної бази знань, а також введений об’єкт типу “РЕЗУЛЬТАТИ СЕСІЇ 1 КУРС ЛІТО”, який зв’язаний з хар актеристиками “ГРУПА” та “ СЕРЕДНІЙ БАЛ”. До таблиці Objects бази даних будуть вводитись записи, поле Name яких буде містити прізвища студентів. Вторинним ключем в цій таблиці є комбінація полів Name та IDTypObj. Таким чином, для збереження результатів наступної сесії можна буде створити об’єкти, поле Name яких знову буде містити прізвища студентів потоку.
На теперішній час створення оболонки, яка дозволить формувати адаптивні алгоритми вирішення типових задач управління, ще триває. Але все ж таки варіант того, як буде виглядати програмний код реалізації відбору із використанням запропонованого підходу, можна уявити.
void__fastcall VidbirObj(AnsiString NazvaTypeObj,
NazvaRuleModel)
// Процедура відбору містить два параметри
// NazvaTypeObj - назва типу об‘єктів, екземпляри
// якого будуть розглядатись в ході відбору
// NazvaRuleModel - назва мережної моделі, яка представляє правила відбору
{
// QueryObjects - запит до бази даних,
// який дозволяє витягнути список об’єктів,
// за назвою типу об’єктів NazvaTypeObj QueryObjects->SQL->Text = “SELECT Obj.Name FROM Objects Obj, ObjTypes Typ WHERE (Obj.IDTypObj = Typ.ID) AND (Typ.Name
+ NazvaTypeObj + “)”
QueryObjects->Open();
// Перегляд всіх елементів та перевірка // на відповідність критерію
30
РИ, 2008, № 3
QueryObj ects->First();
// Вибір першого елемента як поточного while (!QueryObjects->Eof)
{
// Перевірка відповідності характеристик // поточного елемента заданому критерію // LOGVIV - функція, яка реалізує // логічне виведення на мережній моделі та має // результат, що повертається, булевського типу // OUTPUTREZ - процедура, яка визначає // обробку для варіантів,
// які задовольняють критеріям обробки if (LOGVIV(NazvaRuleModel) = = true) OUTPUTREZ;
// Перехід до наступного елемента QueryObj ects ->Next();
}
}
Якщо порівняти цей алгоритм із наведеним вище, то при зміні або правил відбору, або предметної області зміни до заданої процедури вноситись не будуть. Змінами може бути підверджена мережна модель правил відбору. Але з врахуванням того, що її застосування передбачає модифікацію знань із використанням інтерфейсу, орієнтованого на користувача, залучення програмістів до внесення змін не потрібно. Введення назви об’єктів, які аналізуються під час відбору, можна здійснити у файлі налаштувань програмного модуля, що знову таки виключає залучення програміста. Що стосується зміни границь бази даних (введення нових елементів, зміна складу характеристик введених раніше об’єктів), то все це також може бути здійснено користувачами без залучення програмістів. Це зумовлено тим, що розробка такої структури дозволила створити уніфіковану форму введення даних про об’єкти, використання якої забезпечує як повноту, так і коректність введення інформації про певний об’ єкт.
Наукові результати та їх практична значущість
Основними науковими резльтатами, представленими в статті, є метод побудови адаптивних програмних модулів вирішення задач підтримки прийняття рішень та метод представлення даних для їх функціонування. Запропоновані методи забезпечать створення бази уніфікованих програмних модулів, призначених для вирішення часткових задач виробки рішень. Використання адаптивних модулів забезпечує зменшення часу на розробку та модифікацію програмного забезпечення за рахунок використання готових програмних модулів, які по суті є шаблонами вирішення типових задач під час виробки рішень. Крім того, забезпечується можливість налаштування готових програмних модулів на іншу предметну сферу у випадку, коли виробка рішень здійснюється за єдиною схемою.
Література: 1. Ярушек В.Е., Прохоров В.П., Судаков Б.Н., Мишин А.В. Теоретические основы автоматизации процессов выработки решений в системах управления. Х: ХВУ, 1993. 2. Двухглавов Д.Э. Принципы построения программного обеспечения систем поддержки принятия решений // Вісник НТУ «ХПІ»: Зб.наук.пр. Тематичний випуск «Інформатика і моделювання». Вип.34. Х.: НТУ «ХПІ», 2004. С.62-69. 3. Двухглавов Д.Э., Затхей В.А. Представление процесса решения расчетно-логических задач управления с использованием сетевой модели // Системи обробки інформації. Х.: НАНУ, ПАНМ, ХВУ. 2002. Вип.4(20). С. 117-122. 4.Двухглавов Д.Е., ЗатхейВ.А., Карпов С.І. Організація вирішення логіко-розрахункових задач в процесі вироблення рішень // Моделювання та інформаційні технології. Зб.наук.пр. К.: НАНУ, Інститут проблем моделювання в енергетиці. 2003. Вип.22. С.52-55.
Надійшла до редколегії 15.09.2008
Рецензент: д-р техн. наук, доцент Лемешко О.В.
Двухглавов Дмитро Едуардович, канд. техн. наук, старший науковий співробітник НДВ Наукового центру Повітряних Сил, доцент Харківського університету Повітряних Сил. Адреса: Україна, 61000, Харків, вул.Астрономічна, б.35-А, кв.13 6, тел.: (057) 315-36-89, 8-095-120-30-66, email - [email protected].
РИ, 2008, № 3
31
