
- •Оглавление
- •1. Классификации технологий разработки информационных систем
- •1.1. Классификация технологий разработки информационных систем в соответствии с научно-техническими направлениями их создания
- •1.2. Классификация технологий разработки информационных систем, созданная в рамках направления менеджмента – реинжиниринга бизнес-процессов
- •2. Жизненный цикл разработки информационных систем и его модели
- •2.1. Каскадная модель
- •2.2. Спиральная модель
- •3. Методологии разработки информационных систем
- •3.1. Структурная методология разработки информационных систем idef
- •Правила определения сущностей
- •Правила определения атрибутов
- •Первичные и альтернативные ключи
- •Правила определения отношений
- •Отношения категоризации
- •Правила определения отношений категоризации
- •Основные правила формирования информационной модели
- •"Функциональный аспект" рассмотрения системы
- •3.2. Объектно-ориентированные методологии разработки информационных систем
- •3.2.1. Методики объектно-ориентированного анализа
- •3.2.2. Объектно-ориентированный процесс разработки rup
- •3.3. Методология создания информационных систем Datarun, ориентированая на данные
- •4. Case-средства разработки информационных систем
- •4.1. Классификация case-средств
- •Диаграммные средства
- •4.2. Подход к интеллектуализации case-средств
- •4.2.1. Гибридная модель проблемной области case-системы
- •4.2.2. Синтаксис многоуровневой логики
- •4.2.3. Дедуктивный вывод в многоуровневой логике
- •4.2.3.1. Алгоритм сколемизации
- •4.2.3.2. Алгоритм унификации
- •4.2.3.3. Особенности использования линейной входной резолюции в многоуровневой логике
- •4.2.3.4. Иерархическая абстракция и продукционная модель
- •4.2.4. Программное инструментальное средство для моделирования сложноструктурированной проблемной области как компонента информационной базы проекта в case-системах
- •4.2.4.1. Архитектура программного инструментального средства «Инфолог»
- •4.2.4.2. Концептуальный язык описания сложноструктурированной проблемной области
- •4.2.4.3 Реализация программного инструментального средства «Инфолог»
- •5. Технология разработки интеллектуальных систем «логсемис»
- •5.1. Методология разработки интеллектуальных систем «логсемис»
- •Алгоритм генерирования метаправил
- •5.2. Программное инструментальное средство поддержки методологии «логсемис»
- •6. Задания на лабораторные работы
- •7. Контрольные вопросы
- •Библиографический список рекомендуемой литературы «Информационная инженерия»
4.2.4.3 Реализация программного инструментального средства «Инфолог»
Программное инструментальное средство «Инфолог» было создано автором совместно с Ф.Ф. Оськиным, которым были разработаны пользовательский интерфейс и обработка запросов на ограниченном естественном языке. Это средство работает под управлением операционных систем семейства Windows. «Инфолог» поставляется в виде загрузочного модуля infolog.exe и файлов *.dat, которые содержат описания (заголовки) таблиц, представленных в БЗ. Программное обеспечение включает 11 модулей, написанных на языке Си ++. Структура некоторых таблиц, содержащихся в БЗ, представлена на рис.29.
Таблицы экстенсиональной составляющей БЗ (БД) создаются программным средством «Инфолог» в процессе моделирования проблемной области. Структура некоторых из них представлена на рис.30.
Средство «Инфолог» поддерживает "свободное соединение" БЗ и БД под управлением СУБД Paradox. Такая его реализация обеспечивает использование всех возможностей СУБД Paradox, такие как распределенная обработка, высокая производительность, сложный контроль, обеспечение целостности и безопасности данных, отказ и восстановление БД, поддержка больших БД.
Класс объектов |
уровень |
подкласс |
“целое” |
уровень |
“часть” |
Тип отношения |
имя отношения |
имя класса объек-тов1 |
… |
имя класса объектов4 |
арность |
метод опред. экстен. |
<объект> |
описание |
Класс объектов |
атрибут |
имя преди-ката |
имя терма 1 |
имя доме-на1 |
имя SQN- пре-дка1 |
… |
имя терма4 |
имя доме-на4 |
имя SQN- пре-дка4 |
Рис.29. Структура таблиц БЗ
класс объектов |
представитель |
представитель “целого” |
уровень |
представитель “части” |
класс “целого” |
класс “части” |
Атрибут i
имя класса объектов |
значение |
тип атрибута |
способ определения значения |
Отношение i
имя класса объектов1 |
… |
имя класса объектов 4 |
Рис. 30. Структура таблиц БД
5. Технология разработки интеллектуальных систем «логсемис»
5.1. Методология разработки интеллектуальных систем «логсемис»
В связи с широкомасштабным применением вычислительной техники в различных сферах деятельности человека наиболее остро встала проблема разработки программных систем, помогающих человеку в процессах принятия решений. Одним из наиболее широко применяемых классов таких программных систем являются интеллектуальные системы, среди которых выделяются интеллектуальные системы поддержки принятия решений. Далее под интеллектуальными системами будем понимать интеллектуальные системы поддержки принятия решений.
Основными характеристиками проблемных сред, для функционирования в которых разрабатываются интеллектуальные системы, являются открытость, структурная сложность, наличие внутренней активности, трудность построения или отсутствие математической модели. Для описания проблемных сред с такими характеристиками Г. Бучем и Л.А. Растригиным был введен термин «сложные проблемные среды».
Одной из проблем, которая встает перед разработчиками интеллектуальных систем поддержки принятия решений, является проблема увеличения их эффективности, которая непосредственно связана с проблемами повышения эффективности процедур поиска решений и повышения надежности таких систем. В последние годы эти проблемы встали наиболее остро в связи с расширением сферы применения интеллектуальных систем, увеличением сложности задач, для решения которых человек хотел бы использовать компьютер. Одной из таких задач является задача целеполагания. Эта задача также поставлена, поскольку для создания интеллектуальных систем поддержки принятия решений должна быть сформулирована проблема, которая и формализуется в задаче целеполагания. Например, задача целеполагания может заключаться в выработке рекомендаций лицу, принимающему решение, (ЛПР), описывающих управляющие воздействия на объект управления (ОУ) для достижения им требуемого (желаемого) состояния (цели). Для решения этой задачи разрабатываются интеллектуальные системы поддержки принятия решений, применяемые в различных сферах деятельности человека, в том числе и в таких сферах, в которых велика цена ошибки. Например, в таких сферах они могут использоваться для выработки рекомендаций ЛПР для перевода ОУ из внештатного режима в штатный (или из нежелательной ситуации в требуемую, если проблемная ситуация еще не стала необратимой).
Сформулируем задачу целеполагания. На основе начального состояния ОУ, заданного множеством фактов, и множества аксиом, описывающих общие законы проблемной среды, получить: а) ответ на запрос, заданный в виде формулы логики 1-го порядка:
x1 x2 …xn Ф[x1,x2,…,xn]; б) множество следствий, задающих рекомендации ЛПР по управлению ОУ для достижения им поставленной цели.
В постановке задачи целеполагания выделены два варианта, поскольку они широко применяются для формулировки практических задач в области принятия решений. В ней вариант а) является частным случаем варианта б). Он выделен для того, чтобы предоставить ЛПР возможность задавать запросы, в процессе поиска ответа на которые вырабатывается совокупность рекомендаций. Эти рекомендации предлагается выполнить ЛПР для достижения поставленной в запросе цели, заданной формулой x1 x2 …xn Ф[x1,x2,…,xn].
Перечисленные проблемы и особенности проблемных сред определили нецелесообразность применения традиционных интеллектуальных методов, методов теорий управления и принятия решений и необходимость создания новых подходов к созданию интеллектуальных систем, а также их воплощение в методологиях и технологиях их разработки.
Одним из подходов к созданию интеллектуальных систем такого типа является подход семиотического моделирования, предложенный Д.А. Поспеловым и предоставляющий математический базис для построения интеллектуальных систем качественно нового уровня. Так, на смену формальной системы и ее частичных модификаций приходит семиотическая система, являющаяся фундаментом для создания семиотических моделей, позволяющих адекватно описывать сложные проблемные среды за счет изменения элементов формальной системы.
Слабая формализуемость и специфичность задач, решаемых интеллектуальными системами, отсутствие завершенной теории построения таких систем и методологий их разработки приводят к необходимости создания методологий и технологий разработки таких систем. Рассмотрим предложенную автором методологию «ЛОГСЕМИС», предназначенную для создания интеллектуальных систем различного назначения, функционирующих в сложных проблемных средах и используемых для решения задачи целеполагания. Для таких систем в данной методологии делается попытка автоматизировать наиболее высокий уровень процессов принятия решений человеком – уровень целеполагания. Методология включает методы создания интеллектуальных систем данного типа и описание работ, выполняемых на всех этапах их построения: идентификации, концептуализации, формализации, выполнения, тестирования и опытной эксплуатации. В описании методологии в скобках приведены названия работ, выполняемых в процессе разработки программных средств по Государственному стандарту РФ «Информационная технология. Процессы жизненного цикла программных средств» (ГОСТ Р ИСО/МЭК 12207-99). Особенностью созданной методологии являются работы, выполняемые на перечисленных этапах для создания интеллектуальных систем такого типа. Эти работы выполняются с использованием программного инструментального средства поддержки созданной методологии, установка и эксплуатация которого или его базовых компонент выполняется в процессе эксплуатации жизненного цикла программного обеспечения в соответствии с упомянутым Государственным стандартом РФ.
Методология «ЛОГСЕМИС» состоит из следующих этапов.
I. Этапа идентификации (анализ требований к системе и архитектурное проектирование системы).
На этом этапе осуществляется постановка задачи целеполагания, для решения которой создается интеллектуальная система.
На ее основе выделяются требования к блоку целеполагания и осуществляется его разработка.
II. Этапа концептуализации (анализ требований к программному обеспечению).
На этом этапе выделяются объекты, классы объектов, атрибуты и отношения между объектами, также осуществляется определение закономерностей проблемной среды.
В результате выполнения перечисленных работ осуществляется разработка спецификации требований к информационно-логическому блоку интеллектуальной системы.
III. Этапа формализации (архитектурное и детальное проектирование программного обеспечения).
На этом этапе выполняются следующие работы.
1. Генерирование по найденному наилучшему* пути достижения целей метаправил, используемых для выбора прикладных моделей представления знаний, применяемых в процессе поиска решений задачи целеполагания.
2. Автоматическая проверка сгенерированных метаправил на применимость для решения задачи целеполагания.
В результате выполнения перечисленных работ осуществляется построение блока адаптации.
3. Формализация закономерностей проблемной среды с целью пополнения информационно-логического блока разрабатываемой интеллектуальной системы. Проверка описания проблемной среды на непротиворечивость.
4. Построение иерархии объяснений с целью проектирования блока объяснений интеллектуальной системы.
IV. Этапа реализации (кодирование программного обеспечения).
На этом этапе разрабатываются прикладные логические модели представления знаний, используемые для решения задач и хранящиеся в базе знаний интеллектуальной системы.
V. Этапа тестирования (тестирование и интеграция программного обеспечения).
На этом этапе выполняется отладка метаправил и прикладных логических моделей представления знаний; также осуществляется тестирование всех разработанных блоков интеллектуальной системы и их взаимодействия в программном инструментальном средстве поддержки методологии.
VI. Этапа опытной эксплуатации (квалификационные испытания, установка программного обеспечения, поддержка приема программного обеспечения).
На этом этапе выполняется установка интеллектуальной системы, созданной на базе программного инструментального средства, и ее приемка.
Следует отметить, что перечисленные работы, базирующиеся на предложенных методах, охватывают весь спектр работ по созданию интеллектуальных систем, функционирующих в сложных проблемных средах, принятых у специалистов по интеллектуальным технологиям.
На основе методологии осуществляется создание блоков: целеполагания, адаптации, объяснений и информационно-логического блока. Разработанные методы создания этих блоков реализованы в программном инструментальном средстве поддержки методологии «ЛОГСЕМИС». Также встроенными блоками в этом средстве являются база знаний, метарешатель, решатель и блок моделирования, которые тоже входят в состав интеллектуальной системы. Метод построения информационно-логического блока приведен в п. 4.2.
Опишем логико-семиотическую модель, положенную в основу методологии «ЛОСЕМИС». Рассматривается логико-семиотическая модель, базирующаяся на логических моделях представления знаний, в основе которых лежит формальная система, и отношении перехода между моделями.
Определение. Структура логико-семиотической модели есть SMR=<M, ℛТМ>, где M={M1, …, Mn} – множество прикладных логических моделей представления знаний, используемых для решения задач; ℛТМ – отношение перехода между моделями.
Следует отметить, что элементы множества M могут изменяться, добавляться и удаляться при увеличении знаний эксперта о проблемной среде.
Опишем один из способов задания отношения перехода между моделями, которым являются метаправила. Термин «Метаправила» введен, чтобы отличать их от продукционных правил. Специфичность метаправил заключается в том, что они применяются для выбора прикладных логических моделей в процессе поиска решений в интеллектуальной системе. Метаправила позволяют не только задавать переходы между прикладными логическими моделями, но и условия перехода. Они имеют вид:
[<Мi>:] IF <условие> THEN <Мк>, где <Мi> является идентификатором модели, в которой метаправило применяется; <Мк> является идентификатором модели, на которую меняется <Мi>; <условием> является логическая формула, определяемая спецификой решаемой задачи. Отметим, что параметр в метаправиле, заключенный в квадратные скобки, может отсутствовать.
Для решения задачи целеполагания задаются множество прикладных логических моделей М={М1, М2, …, Мn}, в состав которых входят факты и аксиомы, описывающие общие законы проблемной среды, и отношение перехода между прикладными моделями ℛТМ, заданное метаправилами.
Приведем два типа запросов, предложенных в соответствии с постановкой задачи целеполагания. Запросы 1-го типа имеют вид:
а) x1 x2 …xn Ф[x1,x2,…,xn]→;
б) (x1 x2 …xn Ф[x1,x2,…,xn]) ANS(x1,x2,…,xn), где
x1 x2 …xn Ф[x1,x2,…,xn] является запросом, заданным в виде формулы логики 1-го порядка, на который необходимо получить ответ в логико-семиотической модели.
Запросы 2-го типа имеют вид: x1 x2…xn Q1[x1]&Q2[x2]&…&Qn[xn], где Qi[xi], i=1..n, – логическая формула, используемая для описания состояния ОУ. Запросы 2-го типа являются частным случаем запросов 1-го типа. Они выделены, поскольку для получения ответов на них в логико-семиотической модели существует возможность генерирования метаправил.
Рассмотрим процесс поиска ответа на запросы 1-го типа. В этих запросах может присутствовать предикат ANS, используемый для описания совокупности рекомендаций ЛПР, выполнение которых позволит достигнуть поставленную им цель, заданную логической формулой. При получении ответа на запросы возможны три случая.
1. В прикладной логической модели получен пустой дизъюнкт (), свидетельствующий, что формула, заданная в запросе и описывающая требуемое состояние ОУ (цель), является выводимой из прикладной логической модели. При этом в предикате ANS сформирована совокупность рекомендаций ЛПР, выполнение которых позволит достигнуть поставленную им цель, заданную формулой в запросе.
2. В прикладной логической модели не может быть за время Δt выведен пустой дизъюнкт (). Это может произойти из-за не хватки вычислительных ресурсов для доказательства выводимости формулы, заданной в запросе, из прикладной логической модели. Также это может произойти при возникновении изменений во внешней среде, которые могут быть промоделированы правилами системы «STRIPS»: IF <условие> THEN {список фактов для добавления} &{список фактов для удаления}, где <условие> – логическая формула, описывающая изменения во внешней среде. Далее происходит поиск метаправила, на основе которого осуществляется переход из текущей модели к модели, указанной в заключении метаправила. Такое метаправило имеет вид: Мi: IF <условие> THEN Мk, где <условие> – логическая формула, задающая изменения во внешней среде, или Δt. При этом логическая формула, которая доказывается, (запрос) в условии метаправила не указывается. Считается, что это тот же самый запрос. Если такое метаправило найдено, то следствия, выведенные на основе предыдущей модели, не считаются выведенными. Далее в новой прикладной модели происходит вывод следствий. Если метаправило не найдено, то осуществляется обращение к эксперту для пополнения логико-семиотической модели представления знаний.
3. Пусть формула Ф[x1,x2,…,xn], используемая в запросе x1x2…xn Ф[x1,x2,…,xn], имеет вид: Goal1[x1] & Goal2[x2] &…& Goaln[xn], где Goali[xi], i=1..n, является запросом к Mi, представленным в конъюнктивной нормальной форме. Тогда возможно параллельное доказательство формул Goali[xi] в модели Mi, i=1..n. Отметим, что для доказательства формул, входящих в Goali[xi], i=1..n, также могут быть применены различные виды параллелизма (AND-, OR- и DCDP- параллелизм). Если в некоторой прикладной модели за время Δt не может быть получен пустой дизъюнкт, то см. п.2.
Также ЛПР может задавать запросы 1-го типа для подтверждения имеющейся у него информации о состоянии ОУ.
Рассмотрим процесс поиска ответа на запросы 2-го типа. Для этого процесса необходимо разработать прикладные логические модели, в каждой из которых происходит вывод следствий, описывающих рекомендации ЛПР для достижения подцели поставленной цели, процесс достижения которой описывается аксиомами. В этом случае метаправила задают переходы между прикладными логическими моделями, в качестве условий в которых могут быть выведенные следствия и логические формулы, описывающие состояние ОУ. При выводе очередного следствия или после обновления фактов происходит проверка метаправил на срабатывание. При срабатывании метаправила происходит смена текущей прикладной логической модели на модель, указанную в заключении метаправила, в которой и продолжается вывод следствий. Процесс останавливается, если выполнено метаправило, заключением которого является ключевое слово «stop». При этом считается, что цель, поставленная ЛПР, является достигнутой.
Пусть si S является текущей ситуацией, где S – класс ситуаций. Для класса ситуаций S формируются метаправила по найденному наилучшему пути для обработки текущей ситуации в И/ИЛИ-графе «цель-подцель», модифицированному в соответствии с задачей целеполагания. Далее метарешателем и решателем вырабатывается совокупность рекомендаций ЛПР. В ситуации si+1 возможны три случая:
1) срабатывает метаправило, что и в ситуации si;
2) срабатывает метаправило, отличное от метаправила, выполненного в ситуации si (si+1 S);
3) ни одно из метаправил не срабатывает (si+1 S’, S’≠S).
Для случая 1 осуществляется вывод следствий, задающих рекомендации ЛПР, в прикладной логической модели представления знаний, стоящей в заключении метаправила. При этом рекомендации ЛПР, вырабатываемые в ситуациях si, si+1 S, различны, поскольку прикладная логическая модель, в которой происходил вывод следствий в ситуации si, отличается множеством фактов от прикладной логической модели, в которой осуществляется вывод следствий в ситуации si+1. Для случая 2 выработка рекомендаций ЛПР осуществляется на основе прикладной логической модели, стоящей в заключении метаправила, условие которого выполняется. Для случая 3 происходит возврат в блоки целеполагания и адаптации для перегенерирования метаправил.
Метаправила могут быть разработаны инженером по знаниям совместно с экспертом. Предложена процедура их проверки на достижимость требуемого остояния ОУ (цели) для решения задачи целеполагания (вариант б). Как уже отмечалось, метаправила, для решения задачи целеполагания, заданной в этой постановке, могут быть сформированы по И/ИЛИ-графу «цель-подцель». В этом случае метаправила могут быть перегенерированы, если не срабатывает ни одно из метаправил. Разработан метод автоматического генерирования метаправил, который положен в основу блоков целеполагания и адаптации в интеллектуальной системе, созданной на основе методологии «ЛОГСЕМИС». В основе этого метода лежат алгоритмы генерирования метаправил по найденному наилучшему пути, их проверки на применимость для решения задачи целеполагания и их перегенерирования в случае изменений во внешней среде. Приведем описание алгоритма генерирования метаправил.
Пусть имеется запрос 2-го типа, описывающий начальное состояние ОУ. Он соотносится с вершиной И/ИЛИ-графа «цель-подцель», задающей требуемое состояние или цель, которую необходимо достигнуть из начального состояния. Метаправила формируются по И/ИЛИ-графу «цель-подцель», в котором определена последовательность целей, условия которых удовлетворяют запросу. При этом осуществляется выбор из альтернативных целей на основе предложенной эвристической функции. Целям сопоставляются прикладные логические модели, в которых происходит вывод следствий.