Решение многокритериальных задач с субъективными моделями 5

Программная реализация

Так как целью работы является построение наиболее универсальной автоматической системы, за основу взято J2EE приложение, установленное на Web-сервере Sun Application Server. Исходные данные о задачах, методах и алгоритмах вводятся на формах ввода Web-приложения, или же импортируются в файлах специального формата. Для хранения используется база данных Oracle XE, установленная на том же сервере. В качестве модели данных выбрана объектно-ориентированная метамодель, подобная используемой в NetCracker.

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

Структура данных представлена на следующей схеме:

Таблица DSS_OBJECTS используется для хранения абсолютно всех объектов, так или иначе задействованных в процессе расчетов. Здесь находятся имена, описания, информация о связях типа parent-child, и ссылка на объектный тип.

DSS_OBJECT_TYPES перечисляет все объектные типы, которым могут принадлежать объекты. Объектный тип определяется именем, описанием, положением в parent-child-иерархии, косвенно определяет принадлежность тех или иных атрибутов объектам.

DSS_ATTRIBUTES содержит информацию об атрибутах объектов, их типе, способе вычисления (в случае калькулируемых типов), о возможности редактировать значение атрибута, о необходимости отображения соответствующего значения на форме.

DSS_PARAMS, DSS_REFERENCES содержат непосредственно значения параметров объектам по соответствующим атрибутам (PARAMS для простых типов, REFERENCES для ссылочных). Эти таблицы имеют наибольший объем данных среди остальных.

DSS_ATTR_OBJECT_TYPES связывает объектные типы с атрибутами, которые данному объектному типу принадлежат.

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

На основе изложенной структуры создана специфическая для нашей задачи модель данных, описывающая систему принятия решений. Схема модели имеет следующий вид:

Problems, Marks, Criteria, Scores, Methods – это и есть сущности, используемые в описании алгоритмов в данной работе. Resources, Resource_types, Grades в данный момент не применяются, но были включены в структуру для дальнейшей возможности расширять круг решаемых проблем (например, проблема группового ранжирования – разбиение альтернатив на группы). В том или ином виде эти сущности в данный момент полностью описаны в рамках изложенной метамодели, в таблицах DSS_OBJECT_TYPES, DSS_ATTRIBUTES, DSS_OBJECTS находятся соответствующие записи.

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

Основные классы, используемые в работе можно изобразить на UML диаграмме, что бы показать взаимоотношения между ними:

При решении проблемы выбора с помощью Decision алгоритмов структура классов тривиальна: объект решателя с помощью алгоритмов ранжирования (DecisionAlgorithm) и группировки создает объект решения (DecisionSolution), при этом все вычисления делегируются непосредственно алгоритмам.

В случае когда для решения проблемы применяются алгоритмы, основанные на предпочтении (неважно для нечетких чисел или нет), структура классов заметно усложняется:

Основным отличием здесь является то, что решение происходит в 3 этапа:

• 
  С помощью какого-либо из Preprocessor исходный объект проблемы DecisionProblem преобразуется в объект класса PreferenceProblem, который содержит в себе набор матриц предпочтений между альтернативами отдельно для каждого критерия (объект Preferences)
  
• 
  PreferenceSolver c помощью PreferenceAlgorithm решает эту задачу:
  
• 
  С помощью одного из PreferenceAggregationMethod производится агрегация предпочтений, т.е создание одной матрицы предпочтений между альтернативами. В этом месте происходит переход от многокритериальной задачи к однокритериальной.
  
• 
  C помощью одного из методов ScoreFromPreferenceMethod вычисляется конечный рейтинг альтернативы
  
• 
  PreferenceSolver создает объект DecisionSolution.
  

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

Как видно из кода, сначала в цикле по методам задача решается каждым из предложенных методов «простым» итерационным алгоритмом (sovleSimple()), причем условие выхода из цикла – достижение необходимой точности либо превышение порога допустимого числа итераций. Затем результат сохраняется в базу (storeResult()), предложенная задача решается один раз многометодным алгоритмом (solve()), и затем вступает цикл уже по итерациям многометодного итерацонного алгоритма (execute()). Все необходимые промежуточные и конечные данные сохраняются в базу внутри перечисленных методов, либо же в завершение всего процесса.