Классификация эс по связи с реальным временем

• Статические ЭС - это ЭС, решающие задачи в условиях не изменяющихся во времени исходных данных и знаний.

• Квазидинамические ЭС интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени.

• Динамические ЭС - это ЭС, решающие задачи в условиях изменяющихся во времени исходных данных и знаний.

25. Архитектура статической экспертной системы. Понятие и организация базы знаний

26. Архитектура ЭС. Машина логического вывода.

27. Архитектура ЭС. Подсистема объяснений. Редактор БЗ.

28. Архитектура ЭС. Интеллектуальный интерфейс.

29. Основные этапы создания ЭС.

30. Состав участников процесса создания экспертной системы.

База знаний ЭС создается при помощи трех групп людей:

1. эксперты той проблемной области, к которой относятся задачи, решаемые ЭС;

2. инженеры по знаниям, являющиеся специалистами по разработке ИИС;

3. программисты, осуществляющие реализацию ЭС.

31. Прототипная технология разработки экспертных систем.

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

Стадии разработки прототипа ЭС:

• идентификация;

• концептуализация

• формализация;

• выполнение;

• тестирование;

• опытная эксплуатация.

32. Идентификация проблемной области.

Идентификация проблемы. Уточняется задача, планируется ход разработки прототипа экспертной системы, определяются: необходимые ресурсы (время, люди, ЭВМ и т.д.), источники знаний (книги, дополнительные эксперты, методики), имеющиеся аналогичные экспертные системы, цели (распространение опыта, автоматизация рутинных действий и др.), классы решаемых задач и т.д. Идентификация проблемы - знакомство и обучение коллектива разработчиков, а также создание неформальной формулировки проблемы. Средняя продолжительность 1 - 2 недели.

33. Назначение и виды концептуальных моделей проблемной области. Объектная модель.

Концептуальная модель (содержательная модель) - это абстрактная модель, определяющая состав и структуру объекта, свойства элементов и причинно-следственные связи, присущие анализируемой объекту и существенные для достижения целей моделирования. В концептуальной модели обычно в словесной форме приводятся сведения о природе и параметрах (характеристиках) элементарных явлений исследуемого объекта, о виде и степени взаимодействия между ними, о месте и значении каждого элементарного явления в общем процессе функционирования объекта.

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

34. Назначение и виды концептуальных моделей проблемной области. Поведенческая модель.

35. Назначение и виды концептуальных моделей проблемной области. Функциональная модель.

36. Отражение функциональной модели в дереве целей.

37. Понятие и классификация методов обработки неопределенности данных и знаний.

38. Формализация проблемной области.

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

Основными задачами в процессе формализации являются проблемы структуризации исходной задачи и знаний в выбранном (разработанном) формализме, а именно:

1. структуризация общей задачи на связанные подзадачи;

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

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