Программное инструментальное средство «Инфолог» было создано автором совместно с Ф.Ф. Оськиным, которым были разработаны пользовательский интерфейс и обработка запросов на ограниченном естественном языке. Это средство работает под управлением операционных систем семейства Windows. «Инфолог» поставляется в виде загрузочного модуля infolog.exe и файлов *.dat, которые содержат описания (заголовки) таблиц, представленных в БЗ. Программное обеспечение включает 11 модулей, написанных на языке Си ++. Структура некоторых таблиц, содержащихся в БЗ, представлена на рис.29.
Таблицы экстенсиональной составляющей БЗ (БД) создаются программным средством «Инфолог» в процессе моделирования проблемной области. Структура некоторых из них представлена на рис.30.
Средство «Инфолог» поддерживает «свободное соединение» БЗ и БД под управлением СУБД Paradox. Такая его реализация обеспечивает использование всех возможностей СУБД Paradox, такие как распределенная обработка, высокая производительность, сложный контроль, обеспечение целостности и безопасности данных, отказ и восстановление БД, поддержка больших БД.
Долго запускается и тормозит. Автоочистка info.log. QUIK
имя класса объек-тов1
имя класса объектов4
Рис.29. Структура таблиц БЗ
Рис. 30. Структура таблиц БД
5. Технология разработки интеллектуальных систем «логсемис»
5.1. Методология разработки интеллектуальных систем «логсемис»
В связи с широкомасштабным применением вычислительной техники в различных сферах деятельности человека наиболее остро встала проблема разработки программных систем, помогающих человеку в процессах принятия решений. Одним из наиболее широко применяемых классов таких программных систем являются интеллектуальные системы, среди которых выделяются интеллектуальные системы поддержки принятия решений. Далее под интеллектуальными системами будем понимать интеллектуальные системы поддержки принятия решений.
Основными характеристиками проблемных сред, для функционирования в которых разрабатываются интеллектуальные системы, являются открытость, структурная сложность, наличие внутренней активности, трудность построения или отсутствие математической модели. Для описания проблемных сред с такими характеристиками Г. Бучем и Л.А. Растригиным был введен термин «сложные проблемные среды».
Одной из проблем, которая встает перед разработчиками интеллектуальных систем поддержки принятия решений, является проблема увеличения их эффективности, которая непосредственно связана с проблемами повышения эффективности процедур поиска решений и повышения надежности таких систем. В последние годы эти проблемы встали наиболее остро в связи с расширением сферы применения интеллектуальных систем, увеличением сложности задач, для решения которых человек хотел бы использовать компьютер.
Одной из таких задач является задача целеполагания. Эта задача также поставлена, поскольку для создания интеллектуальных систем поддержки принятия решений должна быть сформулирована проблема, которая и формализуется в задаче целеполагания. Например, задача целеполагания может заключаться в выработке рекомендаций лицу, принимающему решение, (ЛПР), описывающих управляющие воздействия на объект управления (ОУ) для достижения им требуемого (желаемого) состояния (цели). Для решения этой задачи разрабатываются интеллектуальные системы поддержки принятия решений, применяемые в различных сферах деятельности человека, в том числе и в таких сферах, в которых велика цена ошибки. Например, в таких сферах они могут использоваться для выработки рекомендаций ЛПР для перевода ОУ из внештатного режима в штатный (или из нежелательной ситуации в требуемую, если проблемная ситуация еще не стала необратимой).
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=1, …, Mn> – множество прикладных логических моделей представления знаний, используемых для решения задач; ℛТМ – отношение перехода между моделями.
Следует отметить, что элементы множества M могут изменяться, добавляться и удаляться при увеличении знаний эксперта о проблемной среде.
Опишем один из способов задания отношения перехода между моделями, которым являются метаправила. Термин «Метаправила» введен, чтобы отличать их от продукционных правил. Специфичность метаправил заключается в том, что они применяются для выбора прикладных логических моделей в процессе поиска решений в интеллектуальной системе. Метаправила позволяют не только задавать переходы между прикладными логическими моделями, но и условия перехода. Они имеют вид:
[i>:] IF THEN к>, где i> является идентификатором модели, в которой метаправило применяется; к> является идентификатором модели, на которую меняется i>; является логическая формула, определяемая спецификой решаемой задачи. Отметим, что параметр в метаправиле, заключенный в квадратные скобки, может отсутствовать.
Для решения задачи целеполагания задаются множество прикладных логических моделей М=1, М2, …, Мn>, в состав которых входят факты и аксиомы, описывающие общие законы проблемной среды, и отношение перехода между прикладными моделями ℛТМ, заданное метаправилами.
Приведем два типа запросов, предложенных в соответствии с постановкой задачи целеполагания. Запросы 1-го типа имеют вид:
x1 x2 …xn Ф[x1,x2,…,xn] является запросом, заданным в виде формулы логики 1-го порядка, на который необходимо получить ответ в логико-семиотической модели.
Запросы 2-го типа имеют вид: x1 x2…xn Q1[x1]…, где – логическая формула, описывающая изменения во внешней среде. Далее происходит поиск метаправила, на основе которого осуществляется переход из текущей модели к модели, указанной в заключении метаправила.
Такое метаправило имеет вид: Мi: IF THEN Мk, где – логическая формула, задающая изменения во внешней среде, или Δt. При этом логическая формула, которая доказывается, (запрос) в условии метаправила не указывается. Считается, что это тот же самый запрос. Если такое метаправило найдено, то следствия, выведенные на основе предыдущей модели, не считаются выведенными.
Далее в новой прикладной модели происходит вывод следствий. Если метаправило не найдено, то осуществляется обращение к эксперту для пополнения логико-семиотической модели представления знаний.
3. Пусть формула Ф[x1,x2,…,xn], используемая в запросе x1x2…xn Ф[x1,x2,…,xn], имеет вид: Goal1[x1] …
2) срабатывает метаправило, отличное от метаправила, выполненного в ситуации si (si+1 S);
3) ни одно из метаправил не срабатывает (si+1 S’, S’≠S).
Для случая 1 осуществляется вывод следствий, задающих рекомендации ЛПР, в прикладной логической модели представления знаний, стоящей в заключении метаправила. При этом рекомендации ЛПР, вырабатываемые в ситуациях si, si+1 S, различны, поскольку прикладная логическая модель, в которой происходил вывод следствий в ситуации si, отличается множеством фактов от прикладной логической модели, в которой осуществляется вывод следствий в ситуации si+1. Для случая 2 выработка рекомендаций ЛПР осуществляется на основе прикладной логической модели, стоящей в заключении метаправила, условие которого выполняется. Для случая 3 происходит возврат в блоки целеполагания и адаптации для перегенерирования метаправил.
Метаправила могут быть разработаны инженером по знаниям совместно с экспертом. Предложена процедура их проверки на достижимость требуемого остояния ОУ (цели) для решения задачи целеполагания (вариант б). Как уже отмечалось, метаправила, для решения задачи целеполагания, заданной в этой постановке, могут быть сформированы по И/ИЛИ-графу «цель-подцель».
В этом случае метаправила могут быть перегенерированы, если не срабатывает ни одно из метаправил. Разработан метод автоматического генерирования метаправил, который положен в основу блоков целеполагания и адаптации в интеллектуальной системе, созданной на основе методологии «ЛОГСЕМИС». В основе этого метода лежат алгоритмы генерирования метаправил по найденному наилучшему пути, их проверки на применимость для решения задачи целеполагания и их перегенерирования в случае изменений во внешней среде. Приведем описание алгоритма генерирования метаправил.
Пусть имеется запрос 2-го типа, описывающий начальное состояние ОУ. Он соотносится с вершиной И/ИЛИ-графа «цель-подцель», задающей требуемое состояние или цель, которую необходимо достигнуть из начального состояния. Метаправила формируются по И/ИЛИ-графу «цель-подцель», в котором определена последовательность целей, условия которых удовлетворяют запросу. При этом осуществляется выбор из альтернативных целей на основе предложенной эвристической функции. Целям сопоставляются прикладные логические модели, в которых происходит вывод следствий.
Источник: studfile.net
ИнфоЖурнал (InfoLog) — Управление Задачами eGroupware
ИнфоЖурнал — InfoLog системы eGroupware позволяет вести список дел, планируемых и выполняемых пользователями системы, причём пользователи могут назначать («делегировать») задания друг другу и представляет собой упрощенную систему назначения поручений с контролем выполнения.
ИнфоЖурнал тесно интегрирован с другими компонентами EGW – Адресной книгой, Календарём, Электронной почтой и системой Управления проектами (Менеджером проектов), которые образуют ядро EGW.
Однако ИнфоЖурнал может быть использован и сам по себе для управления в едином интерфейсе различными задачами – заданиями, заметками и действиями типа «позвонить» и «отправить письмо», как нечто, вроде внутреннего документооборота (без использования внешних каналов связи) и имеет для этой цели следующие возможности:
- Назначение задач и получение отчётов об их выполнении.
- Обмен файлами
- Фиксация истории взаимодействия пользователей
Категории для задач позволяют разделять задачи по различным признакам, например, по их характеру. Список категорий может формироваться любым участниками группы. В то же время ИнфоЖурнал использует общие (глобальные) категории для всего контента, используемого в EGW, которые создаёт администратор системы.
К записям ИнфоЖурнала можно присоединять файлы, которые записываются в виртуальной файловой системе (VFS) EGW и доступны в файловом менеджере в подкаталогах каталога /apps/infolog/.
Визуальные возможности Infolog — Инфожурнала:
- Формировать бизнес-процессы из отдельных типов задач
- Использовать предустановленный фильтр критериев для управления задачами
- Создавать поля статуса связанные с типом задачи и дополнительные поля
- Гибкая фильтрация по владельцу / ответственному, дате последнего изменения, категории, проекту, приоритету, типу и статусу
- Визуализировать ссылки и вложенные файлы
- Аналог CRM — показывать задачи в разрезе контактов/организаций
- Показывать задачи в календаре в качестве события
- Ограничение видимых строк и ширину столбцов полей описания
- Выбор отображаемые столбцы
Функциональные возможности Infolog — Инфожурнала:
- Создавать задачи и подзадачи
- Делегировать задачи пользователям и/или группам
- Устанавливать даты начала и даты окончания
- Устанавливать статусы, приоритеты, и проценты завершения задач
- Связывать задачи с другими данными в EGroupware например, контактами и проектами
- Получать предварительно заполненный табель рабочего времени записи по щелчку мыши
- Использовать общий прайс-лист для формирования табеля
- Прикреплять файлы к задаче
- Быстрый доступ к файловому хранилищу InfoLog
- Просмотр версий прикрепленных файлов, восстановление удаленных файлов
- Преобразование сообщений электронной почты в записи InfoLog
- Управлять несколькими задачами одновременно
- Получать автоматические уведомления по электронной почте по событиям
- Функции копирования и печати
- Полнотекстовый поиск
Возможности по обеспечению безопасности Infolog — Инфожурнала:
- Функции хранения истории
- ACL — уточненные списки контроля доступа
- Категории настроек: обязательные, по умолчанию и личные
Источник: www.oslogic.ru
Заметки от Геннадия
Infolog это диалоговая система (фрэймворк, набор классов), которую вы можете использовать для вывода сообщений информационных, предупреждающих, об ошибках.
Есть несколько глобальных методов, которые выводят сообщения в InfoLog. Пробуем. Создайте джоб: static void BLG36_Job(Args _args)
Выполни джоб, увидишь типовой набор фраз гопника:
Примечателен метод «checkFailed» , визуально он не отличается от «warning». Но есть особенность: метод всегда возвращает «false», что крайне удобно.
Например, есть метод «checkSomething», проверяющий некоторые условия. Он возвратит «true», если все в порядке, иначе «false». В случае невыполнения условий проверки, нужно также выдать сообщение пользователю: boolean checkSomething() < if (I_Am_A_Moscow_Citizen) return true; else return checkFailed( ‘Понаехали! Москва не резиновая’); >Здесь проверяется булево поле «I_Am_A_Moscow_Citizen»; и, если оно равно «false», метод «checkSomething» возращает «false» и выводит сообщение пользователю одним махом.
Итог:
- InfoLog объект для вывода сообщений пользователю;
- глобальные методы для вывода сообщений: info, warning, checkFailed, error.
- info простое информационное сообщение для пользователя.
- warning, checkFailed предупреждающее сообщение, означает «Случилась какая-то нехорошая вещь, но жить можно».
- error сообщение об ошибке, означает «Все плохо, я не могу так дальше работать, это не выносимо».
Источник: gennadyyun.blogspot.com