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

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

Разрабатываемый решатель[1] включает вновь создаваемый уникальный агент (проблемно-ориентированный), «начинающий» работу над поставленной задачей, и совокупность создаваемых или ранее созданных агентов, требующихся для выполнения всех шагов процесса решения задачи. Агент – единица, которая должна выполнять свою работу, если сформировано сообщение для него. Все агенты, к которым сформированы сообщения, могут работать одновременно или в соответствии с некоторым порядком распределения ресурсов.

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

Как отмечено выше, архитектурная модель агентного решателя ИПС представляет связи агентов через сообщения. Для задания структуры передаваемой информации и для различения разных видов сообщений (сообщение - задание или сообщение о результате) удобно ввести множество шаблонов сообщений [Грибова 2012]. Идея большего абстрагирования - рассмотрение ПЕ-агента как единицы, обращающейся к другим агентам с определенным заданием\сообщением без необходимости знать имя исполнителя (т. е. «вшивать» в код агента имя вызываемой единицы) – тоже призвана сделать вклад в повторную используемость.

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

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

2. Этапы проектирования интеллектуального программного обеспечения и соответствующие элементы его конфигурации

Жизненный цикл интеллектуальных систем [Клещев 2012b] является частным случаем проектирования автоматизированных информационных систем или систем управления предприятием [Martin 1989, ГОСТ 2003, Ильин 2006] (см. рис. 2).

Рис. 2. Основные этапы жизненного цикла разработки информационной программной системы и основные элементы ее конфигурации.

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

Системный анализ в интеллектуальных разработках является более содержательным процессом по сравнению с традиционным [Клещев 2012b]. Вместо схемы бизнес-процессов может быть построена схема решаемых специалистами интеллектуальных и обычных задач с их взаимосвязями по формируемым документам. Модели информационных компонентов включают не только формы отчетных документов и входной информации, но и устройство используемых специалистами знаний. А для заключения о реализуемости системы может потребоваться формирование полной базы знаний, приближенной к реальной [Клещев 2012b].

Разрабатываемая в процессе системного анализа онтология профессиональных знаний включает онтологию данных (структуры сущностей из действительности), онтологию знаний (описание структуры причинно-следственных и других связей между сущностями и их окружением, внутреннего устройства и процессов, характеризующих развитие сущностей и других знаний, необходимых для решения задачи специалистом), соглашения о связях между данными и знаниями, структуру базовой терминологии, используемой для описания данных и знаний [Шалфеева 2011]. Часть онтологии знаний, связывающая результат решения с входными данными, выделяется в онтологию объяснения результата, необходимого специалисту для доверия к предлагаемому решению.

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

Одним из ключевых факторов сопровождаемости ПО является возможность построить прозрачную архитектурную модель, соответствующую установленным функциональным требованиям и свойствам качества и обуславливающую воплощение программной системы в виде нужного количества модулей (программных единиц). Архитектура - это представление системы, помогающее управлять сложностью, от нее зависит успех разработки в целом, эффективность функционирования системы, возможность ее сопровождения [Басс 2006, Брукс 2001, Илес 2006, Крачтен 2006, Полубелов 2001]. Правильно выбранная программная архитектура является залогом успешного создания и внедрения программной системы.

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

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

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

3. Построение модели конфигурации управляемого интеллектуального решателя

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

Представляемая модель конфигурации интеллектуального решателя учитывает агентную и декларативную «семантико-сетевую» составляющие нового подхода к разработке ИПС [Грибова 2012]. Она включает декларативные компоненты, исполняемые компоненты и собственно документацию («описательные» компоненты) и моделирует связи декларативных компонентов с исполняемыми компонентами (исходными кодами), описательными компонентами и друг с другом.

Данный параграф рассматривает содержание и структуру для каждого артефакта конфигурации (с примерами) и намечает последовательность ее построения через описание зависимости артефактов друг от друга.

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

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

3.1. Онтология базовой терминологии

Этот артефакт задает структуру словаря терминов предметной области.

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

Примером для задачи медицинской диагностики является т. наз. онтология наблюдений [Москаленко2007], состоящая из описания структуры терминов и ограничений их целостности. Фрагмент ее на языке прикладной логики может выглядеть так [Клещев 2005]: