Software & Systems

Анализ структуры и процессов разработки компьютерных систем поддержки принятия решений (СППР), таких как DSS/UTES, СППР «Кос­мос», Автоматизированная система мониторинга муниципальных образований, АСКУ, АСМ ВУЗ [1, 2], позволил оценить предпосылки и сформулировать общие принципы унификации этапов проектирования и разработки компонентов СППР.

По мнению авторов, основная потребность в унификации связана со стремлением сделать максимально широким и доступным весь набор информационных и аналитических ресурсов и сервисов для аналитиков и ЛПР. Современные методы системного и информационного моделирования бизнес-процессов (например технология SADT, язык UML), методы проектирования и системной интеграции информационно-аналити- чес­ких систем дают возможность не только формализовать с использованием унифицированных подходов основные процедуры выработки и обоснования решений, рекомендуемые теорией, но и предложить решение по программной реализации ресурсов и сервисов СППР, инвариантных по отношению к предметной области.

Обобщенная схема принятия решений, представленная в работе [3], включает следующие этапы:

–      выявление предпочтений ЛПР в формировании критериев;

–      использование субъективных предпочтений ЛПР в оценке ситуации (анализе результатов мониторинга [4]);

–      использование субъективных предпочтений ЛПР в процессе генерации возможных управленческих решений;

–      оценка альтернатив управленческих решений с учетом предпочтений ЛПР;

–      учет предпочтений ЛПР в прогнозе результатов принимаемых решений;

–      согласование групповых решений;

–      выбор лучшего, с точки зрения ЛПР, варианта решения.

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

Унифицированный подход к разработке ПО СППР состоит из совокупности принципов проектирования, каркасного подхода к разработке архитектуры ПО, шаблона правил качественного кодирования, а также набора характеристик оценки качества.

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

Предполагается, что при проектировании и сборке ПО СППР используются следующие принципы.

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

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

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

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

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

Архитектура СППР, реализующая указанные принципы, строится на каркасном подходе [5]. В этом подходе каркас отвечает за базовое поведение, а все множество вариативных поведений СППР выделяется в модули, которые подключаются через точки расширения. Каркас СППР выполняет следующие функции:

–      реализует механизм описания пространства критериев и параметров модели предметной области;

–      позволяет пользователю выбирать методы поддержки решений и организует информационный обмен между ними;

–      обеспечивает хранение, отображение и редактирование атрибутов альтернатив;

–      обеспечивает контроль доступа.

Альтернативы могут вводиться пользователем в интерфейсе СППР, импортироваться и экспортироваться из внешней системы или генери- роваться поисковыми методами оптимизации. Контроль доступа должен быть организован как к отдельным функциям СППР, так и к отдельным критериям и альтернативам.

Остальные функции СППР реализуются через следующие точки расширения (гнезда) каркаса:

–      ввод и редактирование предпочтений ЛПР;

–      описание системы ограничений для параметров модели предметной области с целью определения множества допустимых решений;

–      описание модели предметной области, в том числе связей между параметрами модели предметной области и критериями эффективности найденных решений;

–      многокритериальная оценка или кластеризация альтернатив с учетом введенных предпочтений;

–      поиск допустимых решений выбранным методом оптимизации;

–      экспорт и импорт данных.

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

На рисунке приведена схема СППР «Космос», созданная на базе данных принципов. Программа реализована в трехзвенной архитектуре: сервер СУБД MS SQL Server, промежуточный уровень – MS Internet Information Server, тонкий клиент – Mozilla Firefox. Разработка велась с использованием языков C#, TSQL, JavaScript.

Разработка ПО базируется на принципах открытости по отношению к новым методам свертки векторного критерия и новым методам оптимизации. Все исходные тексты помещены в открытом репозитории http://code.google.com/p/microgravi­ty/source/browse/.

Структура БД разрабатывается так, чтобы систему можно было настраивать на решение задач из различных предметных областей в единой информационной среде. Таким образом, при разработке СППР обеспечивается свойство инвариантности их использования по отношению к предметной области.

При программной реализации СППР крайне важно обеспечить высокий уровень качества создаваемого ПО. Рассмотрим некоторые правила качественной разработки, применявшиеся при создании СППР «Космос».

·       Все исходные тексты программ, кроме временных скриптов, должны храниться в единой системе контроля версий.

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

·       Недопустимо использование в коде магических чисел. В программе не должно быть закомментированного кода.

·       Переменные, структуры данных, таблицы должны объявляться в начале каждого скрипта, в других местах их объявление недопустимо.

·       Все добавления, изменения и удаления в таблицах должны сохраняться в таблице журнала изменений.

·       Все скрипты должны быть в единой кодировке (рекомендуется выбрать UTF-8).

·       Группу связанных изменений БД необходимо выполнять внутри транзакции.

·       Названия любых объектов (переменные, поля, таблицы) должны отражать смысл своих значений.

·       В части FROM запроса после присоединения новой таблицы оператором JOIN в условии ON должны встречаться только поля логического первичного ключа присоединенной таблицы, при этом должны встречаться все поля этого первичного ключа.

·       Если есть условия, непосредственно не связанные с правилом объединения связываемых таблиц, а накладывающие ограничения на итоговый результирующий набор данных, они записываются в секции WHERE запроса.

·       Во всех случаях, кроме разовых временных запросов, недопустимо использовать конструкцию SELECT INTO для создания таблиц, таблица должна быть явно создана в начале скрипта.

·       При объединении двух таблиц всегда необходимо использовать оператор JOIN, а при выполнении внешнего объединения – LEFT OUTER JOIN.

·       Курсоры и циклы в SQL допустимо использовать только в том случае, когда задачу нельзя решить иначе.

·       Если в select размещено более одной таблицы, то ссылка на поля без имени или псевдонима имени таблицы запрещена.

·       Результат не должен зависеть от не контролируемого разработчиком порядка выборки данных самим SQL-сервером. Запрещено использовать top без order by.

·       Все свойства форматирования веб-страниц должны устанавливаться через CSS-файл.

·       Обращение к БД с веб-сервера должно происходить только через хранимые процедуры.

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

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

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

Первая группа свойств:

–      точность;

–      трудоемкость;

–      размерность по числу критериев, числу градаций на шкалах, числу альтернатив;

–      алгоритмическая сложность;

–      понятность;

–      требования к исходным данным (качественные оценки, количественные оценки, нечеткие оценки).

Свойства программной реализации СППР должны оцениваться по существующим стандартам качества [6]. К требуемым свойствам программной реализации СППР относятся следующие:

–      удобство интерфейса, простота изучения и простота использования;

–      эффективность по времени отклика системы, времени поиска решения;

–      эффективность использования ресурсов (оперативной памяти тонкого клиента, процессоров серверов и клиентов, внешних запоминающих устройств);

–      переносимость;

–      масштабируемость;

–      интегрируемость;

–      надежность;

–      защищенность.

Данные методологические основы разработки систем поддержки решений были успешно использованы в СППР «Космос», применявшейся в задаче формирования этапной программы научно-прикладных исследований и экспериментов, планируемых на Российском сегменте МКС [1].

Литература

1.     Осипов В.П., Судаков В.А., Хахулин Г.Ф. Информационные технологии формирования этапной программы научно-прикладных исследований на Российском сегменте Международной космической станции // Вестн. компьютерных и информационных технологий. 2012. № 12. C. 24–28.

2.     Бомас В.В., Судаков В.А. Поддержка субъективных решений в многокритериальных задачах. М.: Изд-во МАИ, 2011.

3.     Трахтенгерц Э.А. Компьютерная поддержка принятия решений. М.: СИНТЕГ, 1998.

4.     Сивакова Т.В. Компьютерный мониторинг космических экспериментов // NPNJ'2012: матер. IX междунар. конф. по неравновесным процессам в соплах и струях. М.: МАИ-ПРИНТ, 2012. C. 622–623.

5.     Горбунов-Посадов М.М. Расширяемые программы. М.: Полиптих, 1999.

6.     Судаков В.А. Автоматизация процесса управления разработкой корпоративной информационной системы // Вестн. МАИ. 2010. Т. 17. № 1. C. 149–153.

References

1.     Osipov V.P., Sudakov V.A., Khakhulin G.F., Vestnik kompyuternykh i informatsionnykh tekhnology [The bulletin of computer and IT], 2012, no. 12, pp. 24–28.

2.     Bomas V.V., Sudakov V.A., Podderzhka subyektivnykh resheny v mnogokriterialnykh zadachakh [Subjective decision support in multiobjective problems], Moscow, MAI Press, 2011.

3.     Trakhtengerts E.A., Kompyuternaya podderzhka prinya­tiya resheny [Computer-based support of decision making processes], Moscow, SINTEG, 1998.

4.     Sivakova T.V., Materialy IX mezhdunar. konf. po neravnovesnym protsessam v soplakh i struyakh (NPNJ'2012) [Proc. of 9th int. conf. on nonequilibrium processes in orifices and streams], Moscow, MAI-PRINT, 2012, pp. 622–623.

5.   Gorbunov-Posadov M.M., Rasshiryaemye programmy [Expanded programs], Moscow, Poliptikh, 1999.

6.     Sudakov V.A., Vestnik Moskovskogo aviatsionnogo instituta [The Bulletin of Moscow Aviation Institute], Vol. 17, no. 1, pp. 149–153.