Характеристика этапов проектирования ЭС

Большое количество статей и публикаций в последнее время, которые можно найти в сети Интернет и журналах, и которые раскрывают вопросы, связанные с развитием и применением технологий экспертных систем, на самом деле опираются на тот самый «классический» устаревший подход, определенный еще в 80 годы прошлого века. А реализация справочных поисковых систем разных направлений может выдаваться за экспертные системы. В таких проектах, как CLIPS JNI (JAVA NATIVE INTERFACE) и .NET энтузиасты попытались объединить «классические» и современные подходы к проектированию и разработке пользовательских интерфейсов экспертных систем, но из-за отсутствия поддержки этих проектов крупными компаниями, проекты так и остаются на экспериментальном этапе. ...

Введение
Основная часть
1. Экспертные системы, их особенности
2. Этапы проектирования экспертных систем, их характеристики
Заключение
Глоссарий
Список использованных источников
Приложения

Цель работы:
дать характеристику этапам проектирования ЭС для повышения результативности, полезности, надежности и производительности разрабатываемой системы, которые бы удовлетворили требования пользователя.
Задачи:
1. Найти, выбрать и проанализировать информационные источники;
2. Классифицировать и дать определение ЭС, указать достоинства и недостатки ЭС;
3. Дать характеристику этапам проектирования ЭС.

Классификация по связи с реальным временем.
Статические экспертные системы разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени. Они стабильны.
Пример. Выявление неисправностей в сложных технических устройствах.
Квазидинамические экспертные системы истолковывают ситуацию, которая изменяется в определенный фиксированный интервал времени.
Пример. Микробиологические экспертные системы, где в определенный период снимаются показания лабораторных исследований, и измерения один раз за определенное время записываются, динамика полученных данных анализируются по отношению к предыдущим.
Динамические экспертные системы работают в взаимосвязи с датчиками объектов в режиме реального времени с непрерывным толкованием поступающих данных.
Пример. Мониторинг за процессами производственных комплексов, состоянием пациентов в реанимационных палатах и т.п.
Классификация по типу ЭВМ
На сегодняшний день существуют:
• ЭС для специфических стратегически важных задач;
• ЭС на ЭВМ средней производительности;
• ЭС на символьных процессорах и рабочих станциях;
• ЭС на мини ЭВМ;
• ЭС на персональных компьютерах (IВМ РС, МАС II и т.д.).
Классификация по степени интеграции с другими программами
Автономные экспертные системы работают напрямую в режиме консультаций с пользователем для узкоспециализированных «экспертных» задач, для их решения не нужно привлекать традиционные методы обработки данных (расчёты, моделирование и так далее.).
Гибридные экспертные системы – это программный комплекс, объединяющий стандартные пакеты прикладных программ (например, математическую статистику, линейное программирование или системы управления базами данных) и средства манипулирования знаниями. Фактически это можно представить себе в виде интеллектуальным пакетом, стоящим над пакетом прикладных программ или в виде некоторой интегрированной среды, которая адаптирована для решения тяжелой задачи, в которую включены элементы экспертных знаний.
Внешне, гибридный подход выглядит наиболее привлекательным, но стоит выделить момент, что проектирование гибридных ЭС является задачей, выполнение которой на порядок сложнее, чем разработка автономной ЭС. Стыковка не просто разных пакетов, а разных методологий (что происходит в гибридных системах) порождает целый комплекс теоретических и практических трудностей.
2 Этапы проектирования экспертных систем, их характеристики
2.1 Этап I – идентификация
В процессе проектирования ЭС в технологии разработки было выделено шесть основных этапов: идентификация, концептуализация, формализация, реализация, тестирование, опытная эксплуатация и внедрение.
На этапе идентификации выясняются задачи, которые ЭС будет выполнять, определяется круг участников процесса разработки и их роль в процессе разработки, предварительно определяются ресурсы необходимые для всего проекта, а так же определяются цели проектирования. Определение круга участников и роль каждого участника, необходимо для определения количества экспертов и инженеров по знаниям, а так же определяется взаимосвязь информационных потоков между ними. В большинстве случаев в основном цикле разработки экспертной системы принимают участие от трех-четырех человек (один эксперт, один или два инженера по знаниям и один программист). Программист нужен для модификации и согласования инструментальных средств. Так же к основному этапу ЭС могут быть привлечены и другие участники, это зависит от сложности и особенностей проекта. Обычно форма связи экспертов и инженеров по знаниям определяется следующим образом: эксперты выступает в роли учителя или консультанта, инженер – в роли ученика. В обязанности инженера по знаниям входят следующие обязательные и необходимые функции: изучение особенностей, специфики, проблем в рамках предметной области в которой ведется разработка ЭС. Изучение дополнительных источников знаний (книги, инструкции) инженером по знаниям необходимо, несмотря на то, что в основе знаний ЭС будут лежать знания эксперта.
Идентификация задачи состоит в работе по составлению описания задачи. Это одна из сложных задач, в ней раскрываются способности инженера по знаниям правильно получать информацию, систематизировать и записывать ее. Сложность в получении информации заключается в том, что большая ее часть получается вербально, зачастую в неформальной обстановке. Описание необходимо для определения общих характеристик задачи; разделение на подзадачи; определение ключевых понятий, их характеристик и отношений; определение входных и выходных данных; определение предполагаемого результата, его вид и объем; определение вида и объема знаний в рамках решаемых задач; составление примеров решения задачи и тестов.
Целью этапа идентификации является в определении структуры и характеристики базы знаний. Это необходимо для того, что бы приступить к непосредственному проектированию базы знаний. Этап идентификации может быть итерационным, это зависит от сложности задачи возложенной на выделенные ресурсы.
В процессе тесной работы эксперта и инженера по знаниям создается содержательное описание задачи, уточняются термины и ключевые понятия – создается некий словарь – «общий код». Общий код помогает преодолеть языковой барьер, между участниками этапа идентификации. Эксперт уточняет описание и объясняет, как решать эту задачу, а так же определяет какие рассуждения лежат в основе решения.
При создании ЭС типичными ресурсами являются: источники знаний, время разработки, вычислительные средства (возможности ЭВМ и программного инструментария) и объем финансирования. Экспертом и инженером по знаниям необходимо использовать все доступные источники знаний, это является необходимым условием для достижения успеха. Эксперт использует свой опыт и свои знания, документацию, инструкции, книги. Инженер по знаниям может использовать свой опыт в решении подобных проблем, программный инструментарий и методы представления знаний.
Одной из важных задач является определение(планирование) временных ресурсов для всех этапов проектирования ЭС. Обычно, сроки проектирования всех этапов начинаются от шести месяцев это при трудоемкости от двух до пяти человеко-лет (данные примерные и конечно могут изменяться в большую или меньшую сторону). Важность планирования временного ресурса напрямую связано с финансированием, от которого зависит выделенные ресурсы и при недостаточности запланированного финансирования первоначальные планы, направленные на создание новой ЭС, могут быть переориентированы на реинжиниринг существующей.
Необходимо в явном виде сформулировать цели построения ЭС – это основная задача идентификации целей. При этом важно отличать цели, ради которых строится система, от задач, которые она должна решать. Как пример, можно определить: формализация неформальных знаний экспертов; улучшение качества решений, принимаемых экспертом; автоматизация рутинных аспектов работы эксперта (пользователя); тиражирование знаний эксперта.
Задача должна быть достаточно узкой в своей специальной области знаний, это нужно для положительного ответа на главный вопрос: «Подходят ли методы инженерии знаний для решения предложенной задачи?» От уровня сложности и ясности формулировки поставленной задачи зависит качество ЭС. Но при этом задача не должна быть слишком легкой или сверхсложной. Как правило, количество связанных понятий, актуальных проблеме, должно быть около нескольких сотен. По-другому говоря, экспертная система предназначена для того, чтобы решать определенную задачу в некоторой предметной области, а не заменить эксперта в этой области.
В последнее время, для снижения затрат и увеличения эффективности при разработке ЭС в процесс включаются пользователи. Это связанно с тем, что пользователи обладают конечным пониманием того, что нужно выходе ЭС, чего не могут сделать системные аналитики и программисты на достаточно компетентном уровне. Привлечение пользователей позволяет снизить временные затраты и затраты на обучение прикладным задачам системных аналитиков и программистов. Экономия затрат находится в прямой зависимости сложности решаемой задачи.
2.2 Этап II – концептуализация
Формулируются базовые концепции и отношения между ними. Сюда же входят и характеристика различных видов используемых данных, анализ информационных потоков и лежащих в их основе структур в предметной области в терминах причинно-следственных связей, отношений частное/целое, постоянное/временное и т.п.
На этом уровне предполагается формальное описание знаний в терминах принципиальных концепций и отношений между концепциями. Выделяются ключевые понятия, отношения и характеристики, необходимые для описания процесса решения задачи. Выделяются следующие задачи:
• типы доступных данных;
• исходные и выводимые данные;
• подзадачи общей задачи;
• используемые стратегии и гипотезы;
• виды взаимосвязей между объектами проблемной области;
• типы используемых отношений;
• процессы, используемые в ходе решения задачи;
• типы ограничений;
• состав знаний.
Необходимо составить подробный протокол действий для определения характеристик перечисленных задач. По каждой задаче в ходе её решения необходимо рассуждения эксперта оформлять в виде протокола. Такие протоколы обеспечивают инженера по знаниям словарем терминов (объектов), а так же дает некоторое представление о тех направлениях, которые использует эксперт. Протокол помогает в ходе всего этапа разработки, отвечая на большинство вопросов. На этапе концептуализации только рассматриваются вопросы о выборе методов решения и способах представления знаний, выбор конкретных способов и методов на этом этапе не производится.
Отличным средством представления и выделения ключевых понятий, отношения и характеристик является использование диаграмм. Их предпочтительно использовать как средство документирования, проектирования и сопровождения, для их составления, как правило, используются самые современные инструментальные средства и методологии. Диаграммы – являются языком описания требований и проектирования систем. Диаграммы должны быть простыми, понятными, не перегруженными, правдивыми и полными.
При составлении диаграмм опираются на формальные правила и используются некоторые абстрактные символы присущие определенной методологии. К числу базовых типов диаграмм относятся:
• SADT IDEF0 – структурно-функциональные диаграммы;
• SADT IDEF1X диаграммы «сущность-связь»;
• диаграммы потоков данных, например нотация DFD;
• диаграммы «состояния-переходы», например нотация UML.
SADT – аббревиатура слов Structured Analysis and Design Technique (Технология структурного анализа и проектирования). Методологию SADT IDEF0 успешно используют уже с 1973 года для графического описания модели проекта. SADT-модель (диаграмма) дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Целью модели является получение ответов на некоторую совокупность вопросов, которые определяются на самом раннем этапе проектирования системы. Диаграмма является некоторым толкованием системы, поэтому, чтобы показать, что система должна делать, надо отобразить всю систему, ее части и их взаимодействие. Это делается с помощью контекстных диаграмм(SADT-модели). На этих диаграммах система представлена в виде взаимосвязанных блоков и дуг, каждый блок является некоторым процессом системы, дуги связывают блоки вместе и отображают взаимодействие и взаимосвязь между ними. Каждая диаграмма имеет набор функциональных блоков и дуг. Дуги являются отношениями между функциональными блоками, они определяют: вход, выход, управление и механизм.
Любая контекстная диаграмма в сочетании со списком системных требований должна отвечать на вопрос: «Что делает система?», и, как правило, дает только частичный ответ.
Если система имеет сложные связи между объектами, то необходимо представлять взаимоотношения и взаимосвязи боле детально. Как раз для этого используются диаграммы IDEF1X «сущность-связь» (например, описание структуры БД). В таких диаграммах объекты представленный в виде прямоугольника, а связи между объектами указываются стрелками. Тип связи и направление отношения задается с помощью стрелок, которые указываются в начале или в конце линии. Отношение множественности между объектами так же задается с помощью линий связи.
Описанные и указанные выше типы диаграмм, отражают статическое поведение системы, Для отображения динамического поведения, для указания событий системы, реагирование системы и в какие состояния система может попасть используются диаграммы «состояний-переходов». возможно Типы диаграмм, упомянутые выше, отражали статическое поведение системы. Для того чтобы показать динамическое поведение системы, какие события происходят в системе, как система на них реагирует и в какие состояния она попадает, используются диаграммы «состояний-переходов» SDT. В диаграммах такого вида узлы соответствуют состояниям динамической системы, а дуги — переходу системы из одного состояния в другое. Узел, из которого выходит дуга, является начальным состоянием, узел, в который дуга входит, — следующим. Поведение системы показывается в виде множества дискретных, исключительных и конечных состояний.
2.3 Этап III - формализация
На некотором формальном языке, предложенном инженером по знаниям, все ключевые понятия и отношения формализуются. В рамках решаемой проблемы определяется, подходят или нет имеющиеся инструментальные средства, требуется ли выбор другого инструментария, или требуется разработка своего инструментария.
Главными задачами в процессе формализации являются проблемы структуризации начальной задачи и знаний в выбранном (разработанном) формализме, а именно: структуризация общей задачи на связанные подзадачи, структуризация предметной области на основе иерархии классов, структуризация знаний на декларативные и процедурные, структуризация приложения на основе иерархии «часть/целое».
1. Структуризация общей задачи на связанные подзадачи
Нет единственно правильного способа разбиения системы на модули, но точно можно сказать, что разбиение на модули, есть важная составляющая часть разработки системы. В процессе сопровождения и доработки прикладной системы может потребоваться пересмотр всей её модульной структуры. Разбиение базы знаний на модули в большинстве современных ЭС является обязательной составляющей. Так же можно отметить, что разбиение на модули, существенно ускоряет разработку, так как можно осуществлять параллельную разработку несколькими группами программистов; в дальнейшем возможно снижение затрат на сопровождение и поддержку; позволит использовать модули в других системах или новых разработках. Есть и обратная сторона, само разбиение, поддержка, загрузка и сборка увеличивает накладные расходы на всем этапе проектирования.
2. Структуризация предметной области на основе иерархии классов
Ускорение темпов разработки и ее модификации всегда являлось актуальной и востребованной задачей прикладной инженерии знаний.
Необходимость ускорения темпов разработки и модификации экспертной системы всегда являлась актуальной задачей прикладной инженерии знаний. Это достигается путем естественного разбиения (декомпозиции) задачи на совокупность подзадач. При таком подходе знания организуются в классы. Классы организуют некоторую иерархию, где каждый класс обладает набором своих специфических атрибутов и наследует атрибуты родительского класса.
Как правило, в ЭС пользователю разрешается создавать новый класс только на базе одного родительского класса. Это проще в реализации, но сложнее в определении предметно-ориентированной иерархии классов на этапе моделирования, так как иерархия наследования в этом случае будет представляться в виде дерева.
Обобщение и специализация (конкретизация) – два противоположно направленных взаимосвязанных процесса, являются основными механизмами структурирования проблемно-ориентированной иерархии класса.
Процесс обобщения реализуется путем обобщения одинаковых свойств разных классов в родительском классе, например, млекопитающие, птицы и насекомые характеризуются средой обитания, в приложении, целесообразно будет ввести новый класс «животный мир», обладающий свойством «среда обитания». Соответственно, классы «млекопитающие», «птицы», «насекомые» будут производными от класса «животный мир» и унаследуют атрибут «среда обитания». Целесообразно проводить обобщение всех аспектов создаваемой системы.
3. Структуризация знаний
По форме описания знания подразделяются на декларативные и процедурные.
Декларативные знания — это совокупность сведений о качественных и количественных характеристиках объектов, явлений, представленных в виде фактов и эвристик. Традиционно такие знания накапливались в виде разнообразных таблиц и справочников, а с появлением ЭВМ приобрели форму информационных массивов и баз данных. Декларативные знания часто называют просто данными. По форме представления декларативные знания противопоставляются процедурным знаниям.
Процедурные знания – описывают принципы и порядок преобразования объектов предметной области. Это могут быть алгоритмы, методики, инструкции, рецепты, стратегии принятия решений. К процедурным знаниям следует отнести правила, которые состоят больше, чем из одного высказывания, одной фразы.
2.4 Этап IV - реализация
Создание одного и более прототипов системы для решения требуемой задачи является целью этого этапа. На этом этапе создается конечный, пригодный для промышленной эксплуатации продукт, но только по результатам тестирования и опытной эксплуатации. Разработка прототипа заключается в программировании его модулей и заполнении базы знаний.
Самая распространенная ошибка на этапе реализации – это начало разработки по созданию прототипа до полного и детального понимания структуры базы знаний откладывая процесс приобретения знаний на потом. Из-за этого самая трудоемкая часть работы отодвигается на поздние этапы. Как только выбраны инструментальные средства, необходимо сразу приступить к накоплению знаний, что на ранних стадиях позволит уточнить используемые понятия и отношения. Такой подход позволит раньше начать выполнение отдельных подзадач и обнаружить, что для решения проблем или в некоторых случаях необходимы дополнительные знания.
2.5 Этап V - тестирование
Этап тестирования ЭС есть в каждой стадии разработки прикладной системы. Выделяют три аспекта тестирования ЭС:
• тестирование исходных данных (проверка фактографической информации, которая служит основой для проведения экспертизы),
• логическое тестирование базы знаний (поиск логических ошибок, избыточных и конфликтных правил),
• концептуальное тестирование (проверка общей структуры системы с привлечением конечных пользователей).