Реферат по предмету "Программирование"


Методология построения ЭС

Методология
построения ЭС.
1. Подход к
проектированию ЭС.

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

В силу
отмеченных особенностей при проектировании ЭС-м применяется концепция “быстрого
прототипа”. Ее суть: разработчики не пытаются сразу построить законченный
продукт. На начальном этапе создается прототип, к-рый должен удовлетворять двум
условиям:

1) он должен
решать типичные задачи предметной области;

2) с другой
стороны трудоемкость его разработки должна быть очень незначительной.

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

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

Кол-во
разработчиков ЭС не должно быть меньше 4 чел., из к-рых 1 явл-ся экспертом ПО,
2 - инженеры по знаниям или проектировщики ЭС, 1 - программист, осуществляющий
модификацию и согласование инструментальных средств.

В дальнейшем, в
процессе преобразования прототипа в конечный продукт, состав программистов
должен быть увеличен.
2. Основные
этапы разработки ЭС.



















1. Идентификация.

2.
Концептуализация.

3.
Формализация.

4. Выполнение.

6.
Тестирование.

a.
Переформулирование

b.
Переконструирование

c.
Усовершенствование

d. Завершение

В состав
функций этапа 1 входит:

1) определение
команды проектировщиков, их роли, а также формы взаимоотоношений;

2) определение
целей разработок и ресурсов;

3) описание
общих характеристик проблемы, входных данных, предполагаемого вида решения,
ключевых понятий и отношений.

Типичные
ресурсы этого этапа: источники знаний, время разработки, вычислительные
ресурсы, объем финансирования.

На этапе 2
эксперт и инжинер по знаниям формализуют ключевые понятия, отношения и
характеристики, которые выявлены на предыдущем этапе. Данный этап призвн решить
следующие вопросы:

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

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

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

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

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

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

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

По результатам
5-го этапа может понадобиться не только модификация программного обеспечения,
но и идеологии разработки интерфейса.

Этап 6. Призван
осуществлять оценку системы в целом. Тут необходимо особое внимание уделить
подбору тестовых примеров. В них должны найти отражение следующие случаи:

неверно
сформулированныые вопросы пользователя;

присутствие
неопределенности в вопросах пользователя;

доступность для
пользователя лексики системы;

доступность для
пользователя объяснений, которые выдает система;

проиворечивость
и неполнота правил;

согласование
контекстов действия правил.

По результатам
6-го этапа осуществляется модификация системы. Наиболее простым её видом явл-ся
усовершенствование прототипов. Этот вид затрагивает только этапы 4 и 6.

Более серьёзным
видом модификации явл-ся переконструирование представлений. Этот вид
модификации необходим в том случае, если обнаруживается, что желаемое поведение
системы не достигнуто. Предполагается возврат на этап формализации и далее
осуществляется весь цикл проектирования. Если проблемы функционирования системы
еще более серьёзны, то приходится возвращаться на этапы 2 и 1 для
переформулирования требований к системе и основных понятий.
3.
Практические аспекты разработки и внедрения ЭС.

В соответствии
с результатами тестирования ЭС может находиться на одной из следующих стадий:

1)
демонстрационный прототип (решает только часть задач в рамках ПО, демонстрируя
правильность выбранного аппарата логического вывода). Срок доведения системы до
этой стадии - около 3-х мес., кол-во правил в базе знаний - 50-100.

2)
исследовательский прототип (решает все задачи в рамках ПО, на недостаточно
устойчива в работе, не полностью проверена). Срок доведения - 1-2 года, кол-во
правил - 200-500.

3) действующий
прототип (решает стабильно все задачи в рамках ПО, но недостаточно эффективна в
работе, в том числе нерациональное использование памяти, невысокое
быстродействие). 2-3 г., 500-1000.

4) промышленная
система (обеспчивает эффективную работу и высокое качество решений, содержит по
сравнению со стадией 3 намного больше правил в базе знаний, программное
обеспечение по сравнению с 3) переписано на язык низкого уровня). 2-4 г.,
1000-1500.

5) коммерческая
система (предполагает обобщение задач, уход от специфики ПО, предназначается
для продажи другим потребителям. Развита по сравнинию с 4) система
редактирования знаний, интерфейса с конкретным пользователем, обучения). 3-6
лет, 1000-3000.

В процессе
проектирования ЭС следует учитывать тот отрицательный опыт, который накоплен
разработчиками на каждой стадии проектирования.

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

Традиционной
ошибкой этапа 3 явл-ся подгонка инструментального средства под понятия и
взаимосвязи конкретной ПО.

Нельзя
соглашаться при разработке прототипа на программирования сразу же на языках
низкого уровня, т. е. без использования инструментальной системы.

На всех стадиях
проектирования инженер по знаниям работает с экспертом и при этом возникает
целый ряд трудностей, которые заранее надо учитывать:

эксперты всегда
должны быть высококвалифицированными, их нужно заинтересовывать материально;

эксперт никогда
не может найти время на работу с инженером по знаниям;

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

с течением
времени эксперт теряет интерес к проекту системы и постоянно сокращает время работы
с проектировщиком. Для устранения этого проектировщик вносит изменения в
систему только вместе с экспертом, тестирует также вместе с ним;

эксперт
незнаком, как правило, с компьютером, поэтому РС устанавливается на его рабочем
месте и доработка системы производится там же;

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

На этапе 4 при
разработке прототипа следует стремиться не разрабатывать самостоятельно
средства объяснения, а использовать только те, что есть в инструментальной
системе.

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

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

Для подготовки
данной работы были использованы материалы с сайта http://www.parny.by.ru/


Не сдавайте скачаную работу преподавателю!
Данный реферат Вы можете использовать для подготовки курсовых проектов.

Поделись с друзьями, за репост + 100 мильонов к студенческой карме :

Пишем реферат самостоятельно:
! Как писать рефераты
Практические рекомендации по написанию студенческих рефератов.
! План реферата Краткий список разделов, отражающий структура и порядок работы над будующим рефератом.
! Введение реферата Вводная часть работы, в которой отражается цель и обозначается список задач.
! Заключение реферата В заключении подводятся итоги, описывается была ли достигнута поставленная цель, каковы результаты.
! Оформление рефератов Методические рекомендации по грамотному оформлению работы по ГОСТ.

Читайте также:
Виды рефератов Какими бывают рефераты по своему назначению и структуре.

Сейчас смотрят :

Реферат ОВД в 1953 е 1970 е годы
Реферат Миансарова Тамара Григорьевна
Реферат Актуальні проблеми визначення об’єкту незаконного заволодіння транспортним засобом
Реферат Органы государственного управления юстиции система правовое положение функции пути реформиро
Реферат Бизнес-план наиболее полного удовлетворения населения хлебобулочными и кондитерскими изделиями
Реферат Еколого гігієнічне об рунтування регламентів безпечного застосуван
Реферат Современное геополитическое пространство в Восточной Европе
Реферат Канада провинция
Реферат Процедуры трансформации бухгалтерской финансовой отчетности
Реферат Содержание и формы управленческих решений
Реферат Послание митрополиту Даниилу
Реферат Конклав 1740 года
Реферат Администрация муниципального образования “кардымовский район” смоленской области постановлени е от 22. 12. 2011 №0737
Реферат Paper Pill Essay Research Paper Sherwood
Реферат Философские мотивы лирики Ахматовой