Разработка модели конфигурации для декларативного программирования управляемых агентных решателей (стр. 7 )

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

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

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

Пример экспертной системы медицинской диагностики при онтологическом программировании представлен в Приложении 1 на рис. Д-К.

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

Этот артефакт также взаимосвязан с декларациями ПЕ, реализующих функции и предикаты.

Способ представления: семантическая сеть.

3.14. Декларативная модель программных единиц

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

Пример. Спецификация агента «проверить норму признака» (для агентного подхода) описывает агента с одним блоком продукций:

Рис. 9. Декларативная модель агента «проверить норму признака».

Спецификация является частью конфигурации агента (см. рис. 11).

Пример спецификации операции-функции «Взять названия всех признаков»:

Формат входного ИР: онтология ИБ;

Формат выходного ИР: -;

Формат результата операции: множество названий.

Взаимосвязи артефактов: этот артефакт зависит от расширенной модели подзадач и архитектуры; если агент – обрабатывающий (связан с ИР), то взаимосвязан со спецификациями соответствующих операций. На этапе реализации агентов принципиально опираться на платформу [Клещев 2011], осуществляющую загрузку требуемых агентов в зависимости от состояния очереди сообщений.

Рис. 10. Декларативная модель агента «принадлежность».

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

3.15. Артефакт «байт-коды»

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

Тестирование работоспособности агента производится на соответствующей платформе, где агент есть пара – декларативное описание совокупности его блоков, запускаемых разными сообщениями, и байт-кода этих блоков, загружаемых по мере появления соответствующих сообщений. Сообщение – часть теста.

Тесты агента – множество <входная ситуация, ожидаемый выход>, а входная ситуация – одно входное сообщение и последовательность состояний входных ИР, ссылки на которые будут переданы агенту (например, через параметры сообщения).

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

Способ представления: язык программирования Java.

Рис. 11. Модель конфигурации для агента.

3.16. Тесты для испытаний решателя

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

Под результатом прогона может пониматься при тестировании не объяснение результата, а только сам результат решения задачи (для снижения трудоемкости составления тестов).

Пример. Тесты для задачи медицинской диагностики – по сути ИБ с диагнозами.

Примечание. Помимо проверки логики решателя необходима и проверка базы знаний. Возможен следующий подход: сначала решатель проверяется на проверенной вручную небольшой БЗ; затем тестируется полная БЗ в расчете на то, что ошибки логики решателя найдены. Обнаруженные несоответствия тем не менее могут привести как к отладке БЗ, так и логики.

Взаимосвязи артефактов: этот артефакт зависит от назначения решателя, расширенной модели подзадач и онтологии данных.

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

3.17. Артефакт «отчет о тестировании»

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

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

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

3.18. Руководство по использованию

Этот артефакт является важным элементом конфигурации решателя, но для него не требуется декларативное представление.

Создается на основе назначения решателя и требований к нему (с учетом описания структуры и взаимосвязей данных из онтологии предметной области) и принимая во внимание результаты тестирования решателя, сохраненные в артефакте «отчет о тестировании».

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

Способ представления: текст.

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

Заключение

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

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

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

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

Благодарности. Работа выполнена при финансовой поддержке гранта РФФИ № 12-07-00179-а и при финансовой поддержке ДВО РАН в рамках Программы фундаментальных исследований Отделения нанотехнологий и информационных технологий РАН (ОНИТ РАН), проект № 12-I-ОНИТ-04.

Список литературы

[Басс 2006] Р. Кацман. Архитектура программного обеспечения на практике. 2-е изд. – Л.:Питер, 2006. 576 с.