Автореферат (Методология унифицированной разработки систем поддержки принятия решений для многокритериальных высокоразмерных задач ракетно-космической отрасли), страница 8

Интерфейс системы должен наглядно показыватьЛПР все настройки и предпочтения на минимальном количестве экранных форм. СППР должнасодержать механизм выявления противоречий в суждениях ЛПР и указывать на них.Данные   принципы   в   достаточной   мере   определяют   особенности   разработки   СППР.  Архитектура СППР, реализующая указанные принципы, строится на основе каркасного подхода,который заключается в создании:- каркаса СППР, отвечающего за базовое функционирование СППР (в том числе, описаниепространства критериев и параметров модели предметной области, контроль доступа иинформационный обмен);- множества вариативных модулей СППР (в том числе, формирование альтернатив, ввод иредактирование предпочтений ЛПР разными способами, описание модели предметной области исистемы ограничений, многокритериальная оценка и оптимизация решений различнымиметодами), которые подключаются через так называемые точки расширения каркаса СППР (точка  32  расширения описывается как спецификация интерфейса взаимодействия каркаса с множествоммодулей, которые к нему подключаются).Каркас СППР обладает следующими функциями:•реализует механизм описания пространства критериев и многоуровневого дерева ихагрегирования, параметров модели предметной области в единой информационной среде;•позволяетпользователювыбиратьметодыподдержкирешенийиорганизуетинформационный обмен между ними;•обеспечиваетхранение,отображениеиредактированиесправочникаатрибутовальтернатив;•обеспечивает контроль доступа.Контроль доступа должен быть организован как к отдельным функциям СППР, так и котдельным критериям и к отдельным альтернативам.Остальные функции СППР реализуются через следующие точки расширения (гнёзда)каркаса:•Ввод и редактирование предпочтений ЛПР.

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

На рисунке 5 приведена схемаунифицированной трехуровневой архитектуры СППР созданной на основе данных принципов.Нижний уровень – это ПО под управлением СУБД, отвечает за хранение всей информациив единой базе данных, реализует алгоритмы многокритериальной оценки альтернатив и хранимыепроцедуры оптимизации модели предметной области. На этом уровне допускается динамическоеподключение новых хранимых процедур для новых методов многокритериальной оценки, дляновых моделей предметных областей и новых методов оптимизации.  33  Промежуточный уровень – это ПО, отвечающее за обработку введенной пользователеминформации и подготовку необходимых форм ввода-вывода данных.

На промежуточном уровнереализуются шаблоны новых форм ввода и редактирования предпочтений ЛПР и шаблоны формввода альтернатив.Рис. 5. Схема унифицированной архитектуры СППРВерхний уровень (тонкий клиент) – это готовое ПО браузера, в котором отображаются всевеб-формы, подготовленные на промежуточном уровне и происходит отправка введенныхпользователями СППР данных. Именно на верхнем уровне с СППР взаимодействует ЛПР.Разработка программного обеспечения должна базироваться на принципах открытости поотношению к новым методам свертки векторного критерия и новым методам оптимизации.

Всеисходные тексты должны быть помещены в открытом репозитории на базе одной из системуправления версиями: GIT, SVN, Fossil.Структура базы данных должна быть разработана так, чтобы систему можно былонастраивать на решение задач из различных предметных областей в единой информационнойсреде. Таким образом, при разработке СППР обеспечивается свойство инвариантностииспользованияпоотношениюкпредметнойобласти.Нарис.6показанфрагментунифицированной концептуальной модели реляционной базы данных (БД) СППР, описывающийпространство критериев и оцениваемые альтернативы. Указанная модель соответствует 3-йнормальной форме.

Схема составлена согласно стандарту IDEF1X, который учитывает такиетребования, как простота изучения и возможность автоматизации.Сущность task отвечает за представление отдельных задач решаемых СППР. Каждая задача(task) характеризуется своим множеством альтернатив, которые на рис. 6 представлены  34  сущностью alternative.

Задача (task) с векторным критерием, компоненты которого хранятся всущности criteria. Отдельные критерии могут быть организованы в многоуровневое дерево, дляэтого используется атрибут prent_crit_id у сущности criteria, который указывает на «родительский»критерий. Доступные методы агрегирования компонент векторного критерия указываются всущности method.Рис. 6. Фрагмент унифицированной концептуальной модели БД СППРОсновной идеей унифицированной модели БД СППР является обеспечение структурнойнезависимости от конкретных оцениваемых объектов.

Для альтернатив, критериев и значенийкритериев применяется подход аналогичный модели Entity–Attribute–Value(EAV). Для этого всущности crit_value содержаться значения критериев для всех альтернатив. Преимуществомданного подхода является то, что добавление новых объектов предметной области не требуетперестроения модели.

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

 35  При программной реализации СППР крайне важно обеспечить высокий уровень качествасоздаваемого ПО. Рассмотрим правила качественной разработки СППР. Затруднительноустановить первоначальный источник отдельных правил из этого списка, они встречаются иобсуждаются на сайтах www.wikipedia.org, www.habrahabr.ru, в работах Р.Гласса.

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

Ниже показаны некоторые из этихправил:•Все исходные тексты программ, кроме временных скриптов, должны храниться в единойсистеме контроля версий.•Все добавления, изменения и удаления в таблицах должны сохраняться в таблице журналаизменений.•Все скрипты должны быть в единой кодировке. В качестве единой кодировки рекомендуетсявыбрать UTF-8.•В части FROM запроса, после присоединения новой таблицы оператором JOIN в условии ONдолжны встречаться только поля логического первичного ключа присоединённой таблицы,при этом должны встречаться все поля этого первичного ключа.•Если есть условия, непосредственно не связанные с правилом объединения связываемыхтаблиц и накладывающие ограничения на итоговый результирующий набор данных, то онизаписываются в секции WHERE запроса.•Курсоры и циклы в SQL допустимо использовать только, если задачу нельзя решить иначе.•Если в select-е более одной таблицы, то запрещена ссылка на поля без имени или псевдонимаимени таблицы.•Результат не должен зависеть от неконтролируемого разработчиком порядка выборки данныхсамим SQL сервером.

Запрещено использовать top без order by.•Все свойства форматирования веб-страниц должны устанавливаться через CSS файл.•Обращение к базе данных с веб-сервера должно происходить только через хранимыепроцедуры. Таким образом, достигается оперативность изменений бизнес-логики, повышаетсяпроизводительность и гибкость, обеспечивается более высокий уровень безопасности.Для некоторых из правил разработаны программные компоненты, проверяющие ихсоблюдение.

Например, проверяется правило на корректность кодировки UTF-8. Специальный  36  модуль на SQL запускается по расписанию и проверяет новые исходные тексты в системеконтроля версий. Данные о нарушениях попадают в специальный отчет на MS Reporting Services.Однако большинство правил невозможно проверять автоматически. Кроме того, качествопрограммного обеспечения СППР во многом обеспечивается в первую очередь качествомпроцессов создания ПО. Поэтому необходимо обеспечить процесс качественного управленияразработкой ПО. Отдельный раздел четвертой главы посвящен средствам автоматизированнойподдержки процесса управления разработкой ПО, а именно:1. Формализован процесс разработки ПО с использованием языка UML (созданы диаграммыUse Case, диаграммы активностей и диаграммы состояний).2. Разработан механизм сбора информации о процессах жизненного цикла ПО СППР.