- •09.03.01 Информатика и вычислительная техника
- •Глава 1 Общие сведения о теории принятия решений
- •1.1 Понятия, связанные с принятием решений
- •1.2 Определенность результатов принимаемых решений
- •1.3 Критерии оценки решения
- •5 Реальные процедуры принятия управленческих решений.
- •1.4 Системы поддержки принятия решения
- •1.5 Математическое моделирование при принятии решений
- •1.6 Классификация математических моделей структурированных систем
- •1.7 Задачи моделирования на различных уровнях принятия решений
- •Глава 2 Системы поддержки принятия решений, основанные на знаниях
- •2.1 Способы описания знаний
- •2.2 Когнитивные модели
- •2.3 Онтологические модели процесса принятия решений
- •Ниже приведены краткие сведения об онтологиях и пример их использования для моделирования процессов принятия решений в системах обучения. Слово «онтология» имеет два значения:
- •Методология создания онтологий. Практическая разработка онтологии включает:
- •2.4 Экспертный подход к принятию решений
- •2.4.1 Методы экспертных оценок
- •2.4.2 Методы средних баллов при оценке альтернатив
- •2.5 Продукционные модели знаний
- •2.5.1 Основные определения
- •2.5.2 Байесовский подход к построению продукционных моделей знаний
- •2.5.3 Структура базы знаний и алгоритм логического вывода
- •Глава 3 Методы оптимизации в задачах принятия решений
- •3.1 Принятие решений на основе методов линейного программирования
- •3.2 Математическая модель планирования производства
- •3.3 Задачи оптимального планирования производства
- •3.4 Транспортная задача
- •3.5 Задачи об упаковке
- •3.5.1 Задача о рюкзаке
- •3.5.2 Задачи упаковки в контейнеры
- •3.6 Задачи о замене оборудования
- •3.6.1 Простейшая задача о замене оборудования
- •3.6.2 Задача об оптимальных сроках замены дискового оборудования
- •3.7 Многокритериальные задачи принятия решений
- •Глава 4 Вероятностные модели формирования и выбора альтернатив решений
- •4.1 Моделирование систем на основе формализма цепей Маркова
- •4.1.1 Определение и динамика цепи Маркова
- •4.1.2 Оценка длительности пребывания процесса во множестве невозвратных состояний
- •4.1.3 Оценка поведения цепей Маркова при большом числе шагов
- •4.2 Модель процесса обучения как цепь Маркова
- •4.3 Система обслуживания заявок с очередью и отказами
- •4.4 Модель динамики информационных ресурсов
- •4.5 Принятие решений об оптимизации инвестиционного портфеля
- •4.6 Имитационное моделирование при принятии решений
- •4.6.1 Система AnyLogic: активные объекты, классы и экземпляры активных объектов
- •4.6.2 Объектно-ориентированный подход
- •4.6.3 Средства описания поведения объектов
- •4.6.4 Анимация поведения и интерактивный анализ модели
- •4.6.5 Примеры имитационного моделирования
- •Глава 5 Сетевые модели поддержки принятия решений
- •5.1 Обыкновенные сети Петри
- •5.1.1 Формальное определение
- •5.1.2 Графы сетей Петри
- •5.1.3 Пространство состояний сети Петри
- •5.1.4 Основные свойства сетей Петри
- •5.1.5 Некоторые обобщения сетей Петри
- •5.1.6 Инварианты сетей Петри
- •5.2 Раскрашенные (цветные) сети Петри (cpn)
- •5.2.1 Мультимножества
- •5.2.2 Формальное определение cpn
- •5.2.3 Функционирование cpn
- •5.2.4 Расширения cpn
- •5.2.5 Сравнение формализмов обыкновенных и раскрашенных сетей Петри
- •5.2.6 О моделирующих возможностях сетей Петри
- •5.3 Моделирование дискретных систем
- •5.3.1 Моделирование вычислительных систем
- •4.3.2 Моделирование программ
- •5.3.3 Моделирование протоколов передачи данных
- •5.3.4. Об исследовании сетей Петри с помощью эвм
- •5.4 Герт-сети
- •5.4.1 Описание герт-сети
- •5.4.2 Производящие функции герт-сетей
- •5.4.3 Вычисление w-функций для типовых соединений дуг
- •5.4.4 Модель процесса обучения как герт-сеть
- •Глава 6 Примеры систем поддержки принятия решений
- •6.1 Система эспла
- •6.1.1 Режимы функционирования системы
- •6.1.2 Принятие решений при техногенных авариях
- •6.1.3 Использование информационных ресурсов
- •6.2 Информационная система дистанционного мониторинга лесных пожаров Федерального агентства лесного хозяйства рф
- •6.2.1 Общая характеристика системы
- •6.2.2 Использование спутниковых данных
- •6.2.3 Центры приема и обработки спутниковых данных
- •6.2.4 Информационные продукты, формируемые системой
- •6.2.5 Прогнозирование параметров лесных пожаров по данным исдм-Рослесхоз
- •Г.А. Доррер методы и системы принятия решений
- •Красноярск 2016
Методология создания онтологий. Практическая разработка онтологии включает:
определение классов в онтологии;
расположение классов в таксономическую иерархию (ПОДКЛАСС- НАДКЛАСС);
определение слотов и описание их допустимых значений;
заполнение значений слотов экземпляров.
После этого можно создать базу знаний, определив отдельные экземпляры этих классов, введя в определенный слот значение и дополнительные ограничения для слота.
Существуют некоторые фундаментальные правила разработки онтологии, которые близки к рассмотренным ранее правилам моделирования «мягких» систем.
Не существует единственно правильного способа моделирования предметной области – всегда существуют жизнеспособные альтернативы.
Лучшее решение почти всегда зависит от предполагаемого приложения и ожидаемых расширений.
Разработка онтологии – это обязательно итеративный процесс.
Понятия в онтологии должны быть близки к объектам (физическим или логическим) и отношениям в интересующей предметной области. Скорее всего, это существительные (объекты) или глаголы (отношения) в предложениях, которые описывают предметную область.
Знание того, для чего предполагается использовать онтологию, и того, насколько детальной или общей она будет, может повлиять на многие решения, касающиеся моделирования. Нужно определить, какая из альтернатив поможет лучше решить поставленную задачу и будет более наглядной, более расширяемой и более простой в обслуживании.
После того, как определена начальная версия онтологии, ее можно оценить и отладить, используя ее в каких-то приложениях и/или обсудив ее с экспертами предметной области. В результате начальную онтологию скорее всего нужно будет пересмотреть. И этот процесс итеративного проектирования будет продолжаться в течение всего жизненного цикла онтологии.
Для создания онтологий разработано множество языковых и программных средств. Из них отметим только так называемые редакторы онтологий. Основная функция любого редактора онтологий состоит в поддержке процесса формализации знаний и представлении онтологии как спецификации (точного и полного описания).
Одним из наиболее популярных редакторов онтологий является Protege (protege.stanford.edu), представляющий собой свободно распространяемую Java-программу, предназначенную для построения (создания, редактирования и просмотра) онтологий той или иной прикладной области. Программа включает редактор онтологий, позволяющий проектировать онтологии, разворачивая иерархическую структуру абстрактных и конкретных классов и слотов. На основе сформированной онтологии Protege позволяет генерировать формы получения знаний для введения экземпляров классов и подклассов.
Данный инструмент поддерживает использование языка OWL(Web Ontology Language, в аббревиатуре буквы намеренно переставлены местами, чтобы получилось английское слово «сова») – язык представления онтологий в Web. Он позволяет генерировать HTML-документы, отображающие структуру онтологий. В редакторе используется фреймовая модель представления знаний, что позволяет адаптировать его и для редактирования моделей предметных областей, представленных не только в OWL, но и в других форматах (UML, XML, SHOE, DAML+OIL, RDF/RDFS и т.п.).
В заключение приведем пример онтологии образовательной программы. На рисунке 2.3 приведен фрагмент онтологии, созданной с помощью редактора Protege и описывающей структуру рабочего учебного плана подготовки бакалавров по направлению 220700.62 – Управление в технических системах.
Рис. 2.3 Фрагмент онтологии учебного плана подготовки бакалавров по направлению 220700.62 «Управление в технических системах».
В этом фрагменте выделены базовые классы: направление, цикл дисциплин, дисциплина, а затем детализирован класс дисциплина, который, в свою очередь, порождает классы: раздел курса, лекция, практика и далее по мере детализации описания процесса обучения. Сплошные линии обозначают связи типа состоитиз или входит в, а пунктирные – наличие других подклассов данного класса.
Полная онтология рабочего учебного плана представляет достаточно обширный документ, который, по сравнению с традиционной табличной формой, позволяет установить межпредметные связи, оценить последовательность приобретения знаний, умений и компетенций (как этого требуют образовательные стандарты 3-го поколения), а также прослеживать возможные индивидуальные траектории обучения.
