Смекни!
smekni.com

Программная оболочка поддержки и синтеза рациональных решений (стр. 1 из 2)

Программная оболочка поддержки и синтеза рациональных решений

И. Е. Воронина, Е. Ю. Митрофанова, Воронежский государственный университет

Введение

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

Задача принятия решений (ЗПР) — одна из самых распространенных в любой предметной области. ЗПР заключается в выборе одной или нескольких лучших альтернатив из некоторого первоначального набора. Для того чтобы сделать такой выбор правильно и как можно ближе к идеальному результату, необходимо четко определить цель и критерии, по которым будет проводиться оценка набора альтернатив. Выбор метода решения такой задачи зависит от количества и качества предоставленной информации. Методы принятия, планирования и синтеза решений основываются на применении знаний (в частности, системы предпочтений) лица или коллектива лиц, то есть коллективные решения могут приниматься лишь в связи с какими-либо целями деятельности лица, принимающего решение (ЛПР). Под целью понимается в широком смысле идеальное представление желаемого состояния или результата деятельности. Вариант решения (или просто решение) — это возможный способ достижения поставленной цели. Варианты должны быть взаимоисключающими или альтернативными, поэтому вариант решения по-другому называется альтернативой. Реализация каждой альтернативы приводит к наступлению некоторых последствий (исходов), анализ и оценка которых осуществляется по одному критерию или нескольким, образующим множество критериев, однозначно характеризующих свойства альтернатив [1].

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

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

Процедуры выявления знаний, предпочтения самого ЛПР, настолько сложны и неоднозначны, что требуют участия консультанта в процессе выбора решения из множества пред-94 ВЕСТНИК ВГУ, СЕРИЯ: СИСТЕМНЫЙ АНАЛИЗ И ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. 2009. № 2 И. Е. Воронина, Е. Ю. Митрофанова ставленных альтернатив. Консультант, как правило, должен полностью владеть всей информацией о методах принятия и синтеза решений, приемлемых при различных критериях, альтернатив, шкалах критериев, типах оценок и т. п. Привлекаемые к процессу решения поставленной задачи специалисты помогают ЛПР более четко разобраться в сложившейся ситуации выбора решений, обучают его применяемым методам. Опыт консультанта обеспечивает целенаправленность размышлений ЛПР. Все это дает пользователям возможность синтеза и выявления наиболее обоснованных вариантов из всего множества допустимых.

Выявление данных, знаний и системы предпочтений ЛПР для решения задачи осуществляется путем сбора экспертной информации. Разработка различных анкет для вариантов задач принятия и синтеза решений невозможна. Следовательно, требуется постоянное участие консультанта, направляющего последовательность рассуждений ЛПР в процессе сбора экспертной информации, что, в свою очередь, может привести к нарушению принципов конфиденциальности и необходимой документированности информации. Если решение, выбранное из множества альтернатив предлагаемым образом, является неудовлетворительным для ЛПР, консультант не имеет никакой возможности восстановить процедуру принятия решения. Это, в свою очередь, приводит к тому, что невозможно обосновать справедливость полученного решения. Создание инструментальных средств, которые программно реализуют механизм принятия и синтеза решений и берут на себя роль консультанта, позволяет обеспечить как конфиденциальность принятия решения, так и рациональное распределение функций между пользователем и ЭВМ.

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

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

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

Для демонстрации работы оболочка дополнена реализациями конкретных методов: метода анализа иерархий (МАИ) [2] и метода ассоциаций.

1. ОСОБЕННОСТИ ПРОГРАММНОЙ РЕАЛИЗАЦИИ Как правило, коммерческие системы принятия решения базируются только на использовании одного из методов принятия решений, что не является достаточно удобным при необходимости провести исследовательскую работу с использованием более чем одного метода. В случае, когда необходимо воспользоваться сразу несколькими методами, исследователю придется оперировать набором программ, реализующими эти методы и обладающими различными интерфейсами. Это не только ухудшает зрительное восприятие, но и увеличивает время получения необходимого результата. Отсутствует возможность непосредственного изучения самих методов, возможно лишь их использование.

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

Динамическая загрузка произвольных классов — возможность расширения и изменения функциональности приложения без его перекомпиляции.

В различных языках подобный механизм реализуется по-своему. Например, он поддерживается в Java и реализуется классом Class. В других языках, типа С++ или Delphi, аналогичных целей можно достичь, используя специальные средства конкретной операционной системы (типа загрузки dll в Windows функцией loadLibrary()).

Существуют два метода работы с DLL:

1. Привязка DLL к программе. Это наиболее простой и легкий метод для использования функций, импортируемых из DLL. Однако (и на это следует обратить внимание), этот способ имеет очень весомый недостаток — если библиотека, которую использует программа, не будет найдена, то программа просто не запустится, выдавая ошибку и сообщая о том, что ресурс DLL не найден. А поиск библиотеки будет вестись в текущем каталоге, в каталоге программы, в каталоге WINDOWS\SYSTEM, и т.д. Например: Implementation function FunctionName(Par1: Par1Type; Par2: Par2Type; ...): ReturnType; stdcall; external ‘DLLNAME.DLL’ name ‘FunctionName’ index FuncIndex; // или (если не функция, а процедура): procedure ProcedureName(Par1: Par1Type; Par2: Par2Type; ...); stdcall; external ‘DLLNAME. DLL’ name ‘ProcedureName’ index ProcIndex;

Здесь:

• FunctionName (либо ProcedureName) — имя функции (или процедуры), которое будет использоваться в программе.

• Par1, Par2, ... — имена параметров функции или процедуры.

• Par1Type, Par2Type, ... — типы параметров функции или процедуры.

• ReturnType — тип возвращаемого значения (только для функции).

• stdcall — директива, которая должна точно совпадать с используемой в самой DLL.

• external ‘DLLNAME.DLL’ — директива, указывающая имя внешней DLL, из которой будет импортирована данная функция или процедура.

• name ‘FunctionName’ (‘ProcedureName’) — директива, указывающая точное имя функции в самой DLL. Это необязательная директива, которая позволяет использовать в программе функцию, имеющую название, отличное от того которое она имеет в библиотеке.

• index FunctionIndex (ProcedureIndex) — директива, указывающая порядковый номер функции или процедуры в DLL. Это также необязательная директива.

1. Динамическая загрузка DLL. Это гораздо более сложный, но и более элегантный метод. Он лишен недостатка первого метода. Недостаток — объем кода, необходимого для осуществления этого приема, причем сложность в том, что функция, импортируемая из DLL доступна лишь тогда, когда эта DLL загружена и находится в памяти.

Краткое описание используемых этим методом функций WinAPI:

• LoadLibrary(LibFileName: PChar) — загрузка указанной библиотеки LibFileName в память. При успешном завершении функция возвращает дескриптор (THandle) DLL в памяти.

• GetProcAddress(Module: THandle; Proc-Name: PChar) — считывает адрес экспортированной библиотечной функции. При успешном завершении функция возвращает дескриптор (TFarProc) функции в загруженной DLL.

• FreeLibrary(LibModule: THandle) — делает недействительным LibModule и освобождает связанную с ним память. Следует заметить, что после вызова этой процедуры функции данной библиотеки больше недоступны.

В Java динамическая загрузка классов встроена непосредственно в Java и реализуется классом Class, посредством следующих статических методов: Class.forName() и Class.newInstance().

Вот его формальное объявление: public static Class forName(String class-Name) Throws ClassNotFoundException Метод отыскивает в системе (среди путей поиска классов CLASSPATH) класс с заданным именем className и возвращает соответствующий экземпляр класса. Имя класса должно быть полным, то есть включать имя пакета. Если такой класс отсутствует, возбуждается исключение ClassNotFoundException. После получения переменной типа Class, следующее наиболее типичное действие — создание экземпляра только что загруженного класса. Для этого служит метод Class.newInstance(). Его объявление: public Object newInstance() throws InstantiationException, IllegalAccessException Чтобы этот метод мог выполниться, у загруженного класса должен существовать пустой конструктор (без аргументов), либо — что по существу то же самое — не должно быть описано вообще никаких конструкторов. В противном случае будет возбуждено исключение InstantiationException. Программная оболочка поддержки и синтеза рациональных решений