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

РОССИЙСКАЯ АКАДЕМИЯ НАУК

ДАЛЬНЕВОСТОЧНОЕ ОТДЕЛЕНИЕ

Федеральное государственное бюджетное учреждение науки

Институт автоматики и процессов управления

РАЗРАБОТКА МОДЕЛИ КОНФИГУРАЦИИ ДЛЯ ДЕКЛАРАТИВНОГО ПРОГРАММИРОВАНИЯ УПРАВЛЯЕМЫХ АГЕНТНЫХ РЕШАТЕЛЕЙ

Владивосток

2012

УДК 004.89

РАЗРАБОТКА МОДЕЛИ КОНФИГУРАЦИИ ДЛЯ ДЕКЛАРАТИВНОГО ПРОГРАММИРОВАНИЯ УПРАВЛЯЕМЫХ АГЕНТНЫХ РЕШАТЕЛЕЙ. Владивосток: ИАПУ ДВО РАН, 2012, 48 с.

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

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

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

Ответственный редактор д. ф.-м. н.

Рецензент д. т.н.

© Институт автоматики и процессов управления ДВО РАН

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

Достаточно важными при разработке таких сервисов становятся возможности и средства их адаптации к изменениям в предметной области и возможность их модификации без переписывания значительной части программы [Тарасов 1998, Козьминых 2012], совместимость между собой программных единиц, из которых может быть скомпонован решатель, удовлетворяющий необходимым требованиям [Заливако 2012]. Одним из перспективных вариантов создания таких сервисов является использование агентной технологии [Раздобарина 2010, Смелянский и др. 2000, Заливако 2012]. Хотя такие свойства агентов, как автономность, восприятие среды посредством сенсоров, модифицируемость агентов прямо в ходе функционирования не слишком важны для интеллектуальных систем информационной поддержки специалистов при принятии ими ответственных решений. Поэтому для производства сопровождаемых и управляемых ИИС требуется разработка теории, методов и технологии их создания на основе развития и совершенствования методов и технологии построения мультиагентных систем.

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

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

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

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

1. Декларативное агентно-ориентированное программирование как способ повышения сопровождаемости интеллектуальных программных систем

База знаний, отвечающая современным требованиям сопровождаемости, должна обладать удобным инструментом ввода и сопровождения знаний. Разработка языков представления и методов редактирования знаний дала толчок развитию способов декларативного их представления, разработке онтологий знаний и созданию на их основе удобных (или даже интеллектуальных) редакторов знаний [Грибова 2010, Клещев 2003, Москаленко 2007]. Концептуальная база знаний обеспечивает редактирование знаний в понятных эксперту терминах [Грибова 2011, Лезин 2000].

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

Рис.1. Основные компоненты интеллектуальной системы.

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

Современные многоагентные системы часто строятся как взаимодействующая совокупность отдельных распределенных интеллектуальных компонентов, обладающих своими базами знаний и средствами рассуждений. Определяющей является парадигма интеллектуальных агентов, поведение которых определяется базой знаний (БЗ) [Раздобарина 2010]. «Уровень интеллектуальности» определенного агента рассматривают как способность агента использовать старые знания в новых, может быть, заранее неизвестных ему ситуациях или даже проблемных областях. Как правило, каждый агент «работает с определенной метафорой», определяющей функции и особенности исполнителя. Интеллектуальный агент поддерживает взаимодействие с окружающим миром, посылает и получает сообщения от других агентов [Раздобарина 2010].

Расширяются возможности использования многоагентных технологий в интеллектуальных системах дистанционного обучения [Пашкин 2006, Гаврилова 2000]. Агентный подход используют для построения сложных интеллектуальных систем по созданию современных тренажеров, обучающих систем, интеллектуальных сред обучения. В таких инструментах интеллектуальный агент позволяет упростить процессы разработки и отладки достаточно сложных систем [Лазырин 2006].

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

Поскольку представление баз знаний и данных в форме семантических сетей достаточно распространено [Нильсон 1990, Гаврилова 2001, Некрашевич 2006, Голенков 2012], то современная концепция проектирования интеллектуальных сервисов как совокупности процедурно-декларативных ресурсов [Клещев 2011, Клещев 2009] становится наиболее перспективной. Предлагается все компоненты ИПС (данные, знания, решатель задач с пользовательским интерфейсом и его программные единицы - агенты) представлять в едином унифицированном формате (в форме семантических сетей), обеспечив единые принципы для их формирования, доступа и модифицирования. Декларативная программа «относительно легко может быть подвергнута логическому анализу, оценке правильности программы (чрезвычайно трудоёмкой при использовании языков типа Си). Чем более декларативен язык программирования, тем более вероятно наличие неявного параллелизма и тем проще будет параллельное выполнение программы» [Гулякина 2012].

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

Разрабатываемый решатель[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]:

4.1.1. сорт признаки: {}N\{ Ø } 4.1.2. сорт события: {}N 4.1.3. сорт особенности: {}N 4.1.5. наблюдения = признаки и события и особенности 4.1.6. множества значений ={}N\{Ø} 4.1.8. сорт возможные значения: наблюдения->множества значений 4.1.12. сорт заболевания: {}N\{Ø}

Ограничения целостности для онтологии наблюдений:

4.1.4. признаки ∩ события = Ø & & особенности ∩ события = Ø& & признаки ∩ особенности = Ø 4.1.7. наблюдения ∩ (È (множество: множества значений) множество) = Ø 4.1.9. (наблюдение: наблюдения) μ(возможные значения (наблюдение)) ≥ 2

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

Если рассмотреть другой современный способ разработки - онтологическое программирование, представляющее данные и процесс их преобразования в виде семантических сетей [Клещев 2012], то артефакт приобретет форму другой семантической сети (см. Приложение.1, рис. А). Примечание. Для определенности в качестве семантических сетей рассматриваются иерархические семантические сети, определяемые [Клещев 2012] как связный ориентированный граф без циклов, в котором каждая дуга имеет метку, а вершины могут быть одного из двух типов — простые и структурные; каждая простая терминальная вершина сети имеет в качестве метки константу некоторого сорта; …каждая структурная вершина сети является контейнером, содержащим упорядоченное конечное множество иерархических семантических сетей...

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

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

3.2. База терминов

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

Пример фрагмента базы наблюдений в области иммунологии и аллергологии [Черняховская 2005]:

наблюдение «Затруднение носового дыхания» описывается следующими характеристиками: присутствие, сторона, время возникновения, периодичность, наличие выделений из полости носа, количество выделений, характер выделений;

характеристика «Присутствие» имеет значения: имеется, отсутствует;

характеристика «Сторона» имеет значения: слева, справа, с обеих сторон;

характеристика «Время возникновения» имеет значения: днем, в ночное время, в утренние часы;

характеристика «Периодичность» имеет значения: постоянно, периодически;

характеристика «Наличие выделений» из полости носа имеет значения: имеется, отсутствует.

Другой вариант представления терминов - в Приложении 1 на рис. Б.

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

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

Способ представления: семантическая сеть, доступная инженеру знания (реже – эксперту) посредством редактора знаний.

3.3. Онтология данных

Этот артефакт задает структуру хранимых документов и других входных данных и вырабатываемых результатов (информационных ресурсов).

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

Примером такого артефакта для задачи медицинской диагностики является схема истории болезни [Клещев 2012а]:

Схема истории болезни =

паспортная часть +

особенности пациента (возраст, пол,…) + другие паспортные данные

жалобы, опрос и осмотр в приемном покое +

предварительный диагноз +

дневник наблюдений (в том числе обследований) +

диагноз

[+ дневник лечения (план лечения)].

Дневник наблюдений / лечения = * {запись}.

Запись =

дата и время записи +

автор записи (возможно, цифровая подпись лечащего врача или консультанта или другого специалиста) +

медицинское содержание [ГОСТ 2008].

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

Симптом = (название, значение).

Элемент плана лечения = (вид лечения, конкретизация (название препарата, режим приема, дозировка)).

На языке прикладной логики это может выглядеть так [Клещев 2005]:

Термины истории болезни (наблюдаемые неизвестные):

4.2.1. сорт моменты: признаки и события -> {}I [0, ¥) 4.2.2. (признак или событие: признаки È события) сорт признак или событие: моменты (признак или событие) -> возможные значения (признак или событие) 4.2.3. сорт наблюдавшиеся особенности: {}особенности 4.2.4. (особенность: наблюдавшиеся особенности) сорт особенность: возможные значения (осо6енностъ)

Термины - ненаблюдаемые неизвестные:

4.2.7. сорт диагноз: {}заболевания 4.2.9. сорт развитие: диагноз È {(признак: признаки) моменты(признак) ≠ Ø} -> разбиения 4.2.11. интервалы развития признака = = (признак —> признаки, номер интервала -> I[1, lепgth(развитие(признак)) - 1]) 5.1.4. нормальные реакции = = (следствие -> признаки, вариант -> варианты нормы) 5.3.3. клинические проявления = = (причина -> диагноз, период развития заболевания -> -> 1[1, число периодов развития(причина)], следствие —> признаки, вариант -> варианты кп, динамика значений -> разбиения, модальность -> {возможность, необходимость})

Ограничения целостности ситуаций действительности:

4.2.10. (признак: признаки) моменты(признак) ≠ Ø => => е1етеnt (развитие(признак), 0) ≤ inf (моменты(признак)) & & element (paзвumue (npизнaк), length(paзвumue(признак))) ≥ > sир (моменты(признак)) 5.3.4. (клиническое проявление: клинические проявления) е1етеnt (динамика значений (клиническое проявление), 0) = = е1етеnt (развитие (причина (клиническое проявление)), период развития заболевания (клиническое проявление& & е1етеnt (динамика значений(клиническое проявление), length (динамика значений (клиническое проявление))) = = е1етеnt (развитие(причина (клиническое проявление)), период развития заболевания (клиническое проявление))

Пример фрагмента семантической сети для онтологического программирования представлен на рис. В Приложения 1.

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

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

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

3.4. Онтология знаний

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

Пример для задачи медицинской диагностики:

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

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

Вариант 1:

4.1.10. условия == {}{(условие: (особенность -> особенности, область значений -> множества значений)) область значений (условие) Ì возможные значения (особенность (условие))} 4.1.11. сорт необходимое условие: признаки -> условия 4.1.12. сорт заболевания: {}N\ { Ø } 4.1.13. (заболевание: заболевания) сорт заболевание: (число периодов развития -> I[1, ¥), периоды развития -> (I[1, число периодов развития] -> интервал) необходимое условие -> условия) 4.1.14. периоды динамики = = (длительность -> интервал, область значений следствия -> множества значений) 4.1.15. интервал = (нижняя граница -> I[1, ¥), верхняя граница -> I (нижняя граница + 1, ¥)) 5.1.1. знания о нормальных реакциях = = ( следствие —> признаки, варианты -> {} варианты нормы, воздействующие факторы -> {}особенности) 5.1.2. варианты нормы = = ( область значений следствия -> множества значений словие на воздействующие факторы -> условия) 5.3.1. знания о клинических проявлениях = = (причина -> заболевания, период развития заболевания -> I [1, число периодов развития(причина)], следствие -> признаки, варианты -> {}варианты кп, воздействующие факторы -> {}особенности, необходимое условие ->условия, модальность -> {возможность, необходимость} ) 5.3.2. варианты кп == (число периодов динамики ->1[1,¥), описание динамики -> (I[1, число периодов динамики] -> периоды динамики), условие на воздействующие факторы -> условия )

Ограничения целостности (для онтологии заболеваний):

5.1.3. (знания о нормальной реакции: знания о нормальных реакциях) (вариант: варианты (знания о нормальной реакции)) область значений следствия (вариант) Î возможные значения (следствие (знания о нормальной реакции))

Вариант 2 представлен на рис. Г Приложения.

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

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

3.5. Соглашения о связях действительности и знаний

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

Пример для задачи медицинской диагностики (для декларативного и для онтологического программирования соглашения удобно представлять на языке прикладной логики):

4.2.5. выполнено = (λ (условие: условия) условие ≠ Ø => => (& (составляющая: условие) особенность (составляющая) Î Î наблюдавшиеся особенности => j(особенность (составляющая)) Î область значений (составляющая))) 4.2.6. (признак: признаки) моменты (признак) ≠ Ø => => выполнено (необходимое условие (признак)) 4.2.8. (заболевание: диагноз) выполнено (необходимое условие (заболевание)) (заболевание: диагноз) Length (развитие(заболевание)) = число периодов развития(заболевание)+\& & (& (номер периода развития: I[1, length (развитие(заболевание)) - 1]) е1етеnt (развитие(заболевание), номер периода развития) - - е1етеnt (развитие(заболевание), номер периода развития - 1) Î I(нижняя граница (Периоды развития (заболевание)(номер периода развития), верхняя граница (Периоды развития(заболевание)(номер периода развития)]) (нормальная реакция: нормальные реакции) (v (знания о нормальной реакции: знания о нормальных реакциях) следствие (знания о нормальной реакции) = следствие (нормальная реакция)& & вариант (нормальная реакция) Î варианты (знания о нормальной реакции)& & выполнено (условие на воздействующие факторы(вариант(нормальная реакция))))

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

Способ представления: как правило, текстовый документ.

3.6. Описание назначения решателя

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

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

Пример 1.

Задача «диагностика заболевания»:

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

Субъект: пациент;

Входная информация: Истории болезни;

Используемое знание: – знание диагностики заболевания (о клинических проявлениях),

Результат: объяснение решения (предлагаемого диагноза и этиологии).

Пример 2. задача «опрос пациента»:

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

Субъект: пациент;

Входная информация: история болезни (пасп +особенности+жалобы);

Используемое знание: – знание диагностики заболевания (о клинических проявлениях),

Результирующая информация: список вопросов пациенту.

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

Способ представления: текстовый документ (реже - семантическая сеть со строковыми полями длины, достаточной для описания задачи).

3.7. Требования к решателю

Артефакт представляет собой (текст или) список пользовательских требований к функционированию и\или поведению решателя.

Пример требований к подсистеме поддержки диагностики.

Предусловие: врач (или решатель задачи обследования) сформировал список необходимых вопросов и обследований; обследования произведены и занесены в историю болезни (ИБ).

Шаги выполнения задачи:

А) Решатель предлагает выбрать ИБ;

Врач указывает ИБ;

Б) Решатель производит решение и сохраняет объяснение в базе решений.

Если предложено объяснение одного диагноза,

то В-1) Врач соглашается с мнение (диагноз) решателя или ставит другой диагноз.

Решатель заносит диагноз врача в ИБ;

Или Г).

Если предложено более одного диагноза (не отвергнуто более одного диагноза),

то В-2) Врач а) выбирает один, совпадающий с его мнением, или ставит свой диагноз.

Решатель заносит диагноз врача в ИБ;

Или Г).

Если отвергнуты все диагнозы,

то В-3) Врач ставит свой диагноз.

Решатель заносит диагноз врача в ИБ.

Или Г).

Г) Врач отказывается от диагностики и возвращается на этап обследования (к соответствующему решателю).

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

Способ представления: текстовый документ (реже - семантическая сеть). Оформляется на естественном языке или с помощью диаграмм, таких как use-cases.

3.8. Архитектурно-контекстная диаграмма

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

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

Рис. 4. АКД для подсистемы диагностики.

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

Способ представления: диаграмма на языке UML (реже - семантическая сеть).

3.9 Проект информационного хранилища

Этот артефакт является онтологией всей информации, хранимой в интересах контроля текущих решений и качества будущих решений.

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

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

Пример структуры хранимой информации для задачи медицинской диагностики:

Формат хранилища – упорядоченное множество ИБ; онтология которых учитывает возможность заполнения частичного (жалобы, анамнез жизни, анамнез болезни, объективные данные, лабораторные и инструментальные данные, предварительный диагноз) и полного (плюс диагноз, протоколы лечения и т. п.).

Формат хранилища знаний – онтология диагностики заболевания, включает наблюдения для этих заболеваний, значения наблюдений в нормальном состоянии, варианты развития заболеваний - варианты динамики значений наблюдений для каждого заболевания [Черняховская 2010].

Формат хранилища решений – упорядоченное множество троек (ИБ, объяснение диагноза и этиологии, решение врача о диагнозе и этиологии), формируемых под управлением онтологии ИБ, онтологии объяснения диагноза и этиологии.

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

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

3.10 База знаний

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

Пример. Используемое знание – знание диагностики заболевания (знание о клинических проявлениях заболевания). Фрагмент базы знаний о конъюнктивитах [Черняховская 2010]:

Пневмококковый (стафилоккоковый) конъюнктивит

Наблюдение «Выделение из глаз»

Присутствие = имеется.

Глаз - Варианты динамики:

1. справа, слева, справа И слева постоянно;

2. справа 1-2 дня, затем справа И слева;

3. слева 1-2 дня, затем справа И слева.

Характер начала = острое.

Локализация = на ресницах.

Характер отделяемого - Варианты динамики:

1. серозно-гнойное, слизисто-гнойное 1-3 дня, затем гнойное;

2. слизисто-гнойное постоянно.

Количество = обильное…

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

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

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

3.11. Модель подзадач

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

Пример 1. Представление шага «Решатель производит решение (объяснение диагноза)» в виде дерева подзадач (рис. 5).

Рис. 5. Пример дерева подзадач для задачи диагностики заболевания.

Пример 2.

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

«формирование списка для опроса»

Ввод имеющихся данных

Ввод паспортных данных (пол, возраст)

Ввод особенностей (перенесенные заболевания, состояние на учете, вредные условия работы…)

Ввод жалоб пациента

Формирование списка вопросов для исключения распространенных заболеваний

Формирование списка вопросов по введенным фактам о пациенте

Поиск признаков (среди жалоб), которые не в норме

Поиск для признаков, которые не в норме, заболеваний, для которых эти признаки важны

Формирование списка признаков (вопросов), недостающих для формирования гипотезы о каждом из этих заболеваний

Формирование объяснения списка вопросов (для каждого «заподозренного» заболевания).

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

(заболевание: диагноз) Length (развитие(заболевание)) = число периодов развития(заболевание)+\& & (& (номер периода развития: I[1, length (развитие(заболевание)) - 1]) е1етеnt (развитие(заболевание), номер периода развития) - - е1етеnt (развитие(заболевание), номер периода развития - 1) Î I(нижняя граница (Периоды развития (заболевание) (номер периода развития), верхняя граница (Периоды развития (заболевание) (номер периода развития)])

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

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

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

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

3.12. Расширенная модель подзадач

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

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

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

Рис. 6. Расширенная модель подзадач для подсистемы диагностики.

Пример. Фрагмент такой модели для решателя задачи диагностики представлен на рис. 6. Подзадача «Оценить принадлежность значения норме» связана с более «старшей» задачей «оценить для всех моментов наблюдения» (или «оценить гипотезу - признак в норме»), связана со своим входом – вершиной, отвечающей за множество нормальных значений одного признака (в сети «база знаний»), и со своим выходом - вершиной-ответом «подтвердить или опровергнуть» (в выходном ИР «объяснение»).

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

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

3.13. Архитектура решателя

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

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

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

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

Пример. Сеть ПЕ (блоков агентов) может быть такой.

<Корневой> «Начать формирование объяснения»

<Управл> «Оценка гипотезы здоров»

<Обрабат> «Оценка принадлежности значений признака «норме»

<Обрабат> Вывод о здоровье

<Управл> «Оценка гипотезы «имеется заболевание»

<Управл> «Оценка гипотезы «признак-не-КК[3] в норме»

<Обрабат> «Оценка принадлежности значения «норме»

<Обрабат> «Вывод о том, в норме ли признак»

<Управл> «Оценка гипотезы «КК - признак соотв заболеванию»

<Обрабат> «Проверка варианта КП»

<Обрабат> «Вывод о том, соответствует ли КК - признак заболеванию»

<Обрабат> «Вывод о заболевании»

Это представление показывает, в «услугах» какой ПЕ нуждается каждая ПЕ решателя. Например, ПЕ «Оценка гипотезы здоров» для выполнения своей работы должна проверить нормальность всех относящихся к делу признаков, т. е обратиться к ПЕ «Оценка гипотезы «признак в норме» для каждого из признаков. После того, как все признаки будут оценены, можно будет делать общий вывод о том, здоров ли пациент. Две ПЕ «Оценка гипотезы здоров» и «Вывод о здоровье» могут рассматриваться как единый агент с двумя блоками.

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

Более подробная архитектура решателя (сеть программных единиц), представляющая не только агентов, но и операции доступа к ИР, может быть такой.

«Постановка диагноза»

УправлАгент «Оценка гипотезы здоров»

Взять названия всех признаков

Обрабат «Оценка принадлежности значений признака «норме»

Взять все значения указанного признака

Взять значение указанного признака

Запись в отчет, в норме ли признак

Обрабат Вывод о здоровье

Управл «Оценка гипотезы «имеется заболевание»

Взять названия всех заболеваний

Управл «Оценка гипотезы «признак-не-КК в норме»

Взять названия всех признаков-не-из-КК

Обрабат «Оценка принадлежности значения «норме»

Взять все значения указанного признака

Взять значение указанного признака

Запись в отчет, в норме ли признак-не-из-КК

Обрабат «Вывод о том, в норме ли все признаки не-КК»

Управл «Оценка гипотезы «КК- признаки соотв заболеванию»

Взять названия всех признаков-из-КК

Обрабат «Проверка варианта КП»

Взять варианты КП

Взять динамику указанного признака

Запись в отчет, в норме ли признак-из-КК

Обрабат «Вывод о том, соотв-ют ли КК-признаки заболеванию»

Обрабат «Вывод о заболевании».

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

Рис. 7. Пример управляющего графа для решателя из шести агентов.

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

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

Рис. 8. Пример управляющего графа для решателя из восьми агентов.

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

Этот артефакт взаимосвязан с декларациями агентов и программных единиц, реализующих операции. На этапе реализации агентов принципиально опираться на платформу [Клещев 2011], ориентированную на выполнение многоагентного программного обеспечения как Интернет-сервиса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

[Брукс 2001] Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс, 2001.

[Гаврилова 2001] , Хорошевский знаний интеллектуальных систем. − СПб.: Питер, 2001.

[Гаврилова 2000] , Яшин A. M., Фертман интеллектуальных агентов для поддержки сервера дистанционного обучения // Материалы междунар. конф. ”Интеллектуальные системы и информационные технологии в управлении IS&ITC”, Псков, 2000, с.224-227.

[Голенков 2012] , Гулякина модели параллельной обработки знаний: принципы построения, реализации и проектирования // OSTIS-2012, стр. 32-50, Минск, БГУИР

[ГОСТ 2003] ГОСТ Р ИСО/МЭК . Информационная технология. Процессы жизненного цикла программных средств. Дата введения 01.07.2003.

[ГОСТ, 2008] «Электронная история болезни. Общие положения». / ред. // ГОСТ Р . Дата введения .

[Грибова 2012] , , Шалфеева подход к разработке интеллектуальных интернет-сервисов // Труды Конгресса по интеллектуальным системам и информационным технологиям «IS&IT’12». М.: Физматлит, 2012 –Т.1. с. 218-223.

[Грибова 2011] , Клещев создания жизнеспособных интеллектуальных систем и методы их решения // International Journal "Information Technologies & Knowledge". Bulgaria. Sofia: ITHEA. 2011. Vol. 5, № 3. P. 250-258.

[Грибова 2010] , , Шалфеева интеллектуальными системами // Известия РАН. Теории и системы управления.2010. № 6. С. 122-137.

[Гулякина 2012] , , Лазуркин и технологии программирования, ориентированные на обработку семантических сетей // OSTIS-2012, стр. 221-228, Минск, БГУИР

[Дехтяренко 2003] Дехтяренко в повествовательном наклонении // SoftCraft. Декларативное программирование. 2003. URL: http://www. *****/paradigm/dp/dp01.shtml.

[Заливако 2012] , Cемантическая технология компонентного проектирования интеллектуальных решателей задач // OSTIS-2012, стр. 297-314, Минск, БГУИР.

[Илес 2006] Что такое архитектура программного обеспечения. 2006. URL: http://www. /developerworks/ru/library/eeles/index. html

[Ильин 2006] Ильин бизнес-процессов. Практическое использование ARIS // Williams, 2006, 176с.

[Клещев 2012] , Грибова парадигма программирования // Материалы международной научно-технической конференции OSTIS-2012, стр. 213-220, Минск, БГУИР

[Клещев 2012а] , , Шалфеева медицинской интеллектуальной профессиональной деятельности с точки зрения её возможностей её автоматизации // OSTIS-2012, стр. 473-478, Минск, БГУИР

[Клещев 2012b] С., Шалфеева системного анализа при автоматизации интеллектуальной профессиональной деятельности // Материалы 22-ой международной - Крымской конференции «СВЧ-техника и телекоммуникационные технологии» (КрыМиКо’2012). Севастополь, 10—14 сентября 2012 г. Севастополь: Вебер, 2012. Т.2 С. 419-420

[Клещев 2011] , и др. Проект IACPaaS. Комплекс для интеллектуальных систем на основе облачных вычислений // Искусственный интеллект и принятие решений. 2011. № 1. С.27-35.

[Клещев 2009] Клещев многоагентной системы в многоцелевом компьютерном банке знаний // Четвертая международная конференция по проблемам управления: Сборник трудов. М.: Учреждение РАН Институт проблем управления имени РАН.- 2009.- С. .

[Клещев 2005] , , Москаленко онтологии предметной области "медицинская диагностика". Часть 1. Неформальное описание и определение базовых терминов. Журнал НТИ, Серия 2, № 12, 2005

[Клещев 2003] , Орлов банк знаний. Часть 3. Концепция универсального редактора ИРУО. Владивосток: ИАПУ ДВО РАН, 20с. http://www. iacp. *****/is/publications/186_3.pdf

[Козьминых 2012] , Голованов подход в системах информационной поддержки управленческих решений // Программные продукты и системы. 2012. № 1. - С. 21-23

[Крачтен 2006] Ретроспектива программных архитектур // Открытые системы. – 2006. – № 3.

[Лазырин 2005] Лазырин технологии многоагентных систем при разработке тактических тренажеров // Сборник материалов Всероссийской конференции «Тренажеростроение: современное состояние, перспективы развития», — Тверь: ЗАО НИИ «Центрпрограммсистем», 2005. - С.53-57.

[Лапыгин 2004] Конфигурационное управление проектами разработки программного обеспечения. 2004 г // URL: http://*****/SE/quality/configuration_management.

[Лезин 2000] Лезин Г. В., . О представлении семантики концептуальных моделей в базах знаний // Труды международного семинара ДИАЛОГ’2000 по компьютерной лингвистике и ее приложениям. - М.: РосНИИ Искусственного Интеллекта, 2000. Т. 2. - С. 235–242.

[Москаленко 2007] Москаленко компьютерного банка знаний по медицинской диагностике // Информатика и системы управления. Изд-во АмГУ. 2007. №2 (14).

[Нильсон 1990] Принципы искусственного интеллекта. М.: Радио и связь. 19с.

[Некрашевич 2006] , Божко данных в Интернет на основе семантических сетей // Искусственный интеллект. – 2006. – № 1. – C. 57-59

[Пашкин 2006] Пашкин интеллектуальная система дистанционного обучения // Труды СПИИРАН. Вып. 3, т. 1. — СПб.: Наука, 2006.

[Полубелов 2001] Архитектура и технология разработки комплексов Базикмед, Компьютер-Информ. 2001. №URL: http://www. *****/index. html или http://www. *****/inform18_01/p04-05.htm

[Раздобарина 2010] Раздобарина технологии многоагентных систем для интеллектуальной поддержки принятия решения. 2010. Сайт ООО "Смарт Автоматикс". URL: http://www. /

[Смелянский 2000] , Козлов интеллектуальных агентов для поиска информации в Интернет. //Искусственный интеллект (Донецк), 2000, No 2, c.378-382.

[Тарасов 1998] Тарасов , многоагентные системы, виртуальные сообщества: стратегическое направление в информатике и искусственном интеллекте // Новости искусственного интеллекта. 1998. №2. С. 5-63.

[Черняховская 2010] , Москаленко заболеваний «конъюнктивит» для компьютерного банка знаний // Информатика и системы управления. Журнал. Изд-во АмГУ. №4(26), 20с. С. 94-103.

[Черняховская 2005] , Петряева наблюдений в области иммунологии и аллергологии - составляющая информационного наполнения банка медицинских знаний // Информатика и системы управления, 2005. № 2. С. 71-77.

[Шалфеева 2011] Шалфеева онтологий при разработке управляемых интеллектуальных систем. Владивосток: ИАПУ ДВО РАН, 20с.

[Martin 1989] Martin, J. Information Engineering: Book I - Introduction. Englewood, NJ: Prentice Hall, 1989.

[wiki] Конфигурационное управление // Материал из Википедии — свободной энциклопедии. URL: http://ru. wikipedia. org/wiki/Конфигурационное_управление.

Приложение 1.

Артефакты проектирования интеллектуальной системы в рамках онтологической парадигмы

Онтология реальных наблюдений для медицинской диагностики на языке онтологического программирования может представлять собой следующую сеть [Клещев 2012]:

Рис. А. Онтология базы наблюдений

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

Простая база наблюдений для некоторого раздела медицина представляется, как на рис. Б. [Клещев 2012].

Это сеть из одной структурной вершины (с меткой класса "База наблюдений" и индивидуальной меткой «эндокринология»), которая, как контейнер, содержит упорядоченное множество различных наблюдений (подсетей). Корень каждой подсети является простой вершиной с меткой класса "наблюдение" и индивидуальной меткой  («аппетит», «алопеция», …). Из этого корня выходит единственная дуга с меткой "Возможные значения", входящая в структурную вершину, содержащую упорядоченное множество возможных значений наблюдений.

Рис. Б. Иерархическая семантическая сеть, представляющая простую базу наблюдений «эндокринология».

Пример фрагмента семантической сети для хранения дневника наблюдений истории болезни [Клещев 2012]:

Рис. В. Онтология простых историй болезни.

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

Онтология медицинских знаний о заболеваниях выглядит следующим образом [Клещев 2012]:

Рис. Г. Контекстно-зависимая грамматика языка представления медицинских знаний.

Входными данными приложения «Экспертная система медицинской диагностики» являются база наблюдений S1 и база заболеваний S2 - семантические сети постоянного хранения: S1 (сформированная с помощью функции «Простая база наблюдений») и S2 (сформированная с помощью функции «База» с аргументом S1. Приложение состоит в последовательном выполнении вызовов двух функций – «ввод истории болезни» с аргументом S1 и результатом S3, а также «Объяснение» (формирование объяснения) (рис. А) с аргументом S3 и результатом S4, который является результатом всего приложения.

Ниже даются некоторые пояснения к программе функции «Объяснение» на OPL.

Семантическая сеть S4 представляет объяснение, формируемое экспертной системой медицинской диагностики. Объяснение состоит из двух частей – объяснения гипотезы о том, что пациент здоров, и объяснения гипотез о том, что пациент болен одним из заболеваний, представленных в базе заболеваний S2.

Рис. Д. Объяснение экспертной системы медицинской диагностики.

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

Импликация МИ1 (рис. Б) формирует значение переменной v1, которым является множество всех наблюдаемых признаков в истории болезни S3; для каждого из этих признаков объяснение гипотезы о том, что он находится в норме, состоит из объяснения гипотез о том, что все наблюдавшиеся значения этого признака являются нормальными, и из оценки гипотезы о том, что этот признак находится в норме.

Рис. Е. Описание гипотезы “признак в норме».

Импликация МИ2 (рис. В)для каждого значения v1* переменной v1 формирует значение переменной v2, которым является множество моментов наблюдения признака v1* в истории болезни S3; для каждого из этих моментов наблюдения формируется оценка гипотезы о том, что значение признака v1*, наблюдавшееся в этот момент, является нормальным.

Рис. Ж. Описание гипотезы «значение нормальное».

Первая импликация (рис. Г) из множества МИ3 для каждого значения v1* переменной v1 и для каждого значения v2* переменной v2 формирует значение переменной v3, которым является значение, наблюдавшееся в момент v2* у признака v1* в истории болезни S3, а также формирует значение переменной v4, которым является множество нормальных значений признака v1* в базе заболеваний S2, а затем выполняется вычисляемый предикат «принадлежность» (принадлежность элемента v3 множеству v4); если значение этого предиката есть «истина», то формируется оценка «подтверждена» гипотезы о том, что значение признака v1*, наблюдавшееся в момент v2*, является нормальным. Вторая импликация, если значение этого предиката есть «ложь», формирует оценку «опровергнута» гипотезы о том, что значение признака v1*, наблюдавшееся в момент v2*, является нормальным.

Первая импликация (рис. Д) из множества МИ4 для значения v1* переменной v1 формирует оценку «подтверждена» гипотезы о том, что признак v1* находится в норме, если в объяснении S4 оценки гипотез о том, что значения признака v1*, наблюдавшееся в моменты, равные всем значениям переменной v2, являются нормальными, «подтверждена». Вторая импликация, для значения v1* переменной v1 формирует оценку «опровергнута» гипотезы о том, что признак v1* находится в норме, если в объяснении S4 оценки гипотез о том, что значения признака v1*, наблюдавшееся в моменты, равные некоторым элементам множества - значения переменной v2, являются нормальными, «опровергнута».

Рис. З. Описание оценки гипотезы «значение нормальное».

Рис. И. Описание оценки гипотезы «признак в норме».

Первая импликация из множества МИ5 (рис. Е) формирует оценку «подтверждена» гипотезы о том, что пациент здоров, если в объяснении S4 оценка гипотезы о том, что признаки, равные всем значениям переменной v1, есть «подтверждена». Вторая импликация формирует оценку «опровергнута» гипотезы о том, что пациент здоров, если в объяснении S4 оценка гипотезы о том, что признаки, равные некоторым элементам множества - значения переменной v1, есть «опровергнута» [Клещев 2012].

Рис. К. Описание оценки гипотезы «пациент здоров».

Гипотеза «пациент болен» описывается аналогичным образом [Клещев 2012].

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

(заболевание: диагноз) Length (развитие(заболевание)) = число периодов развития(заболевание)+\& & (& (номер периода развития: I[1, length (развитие(заболевание)) - 1]) е1етеnt (развитие(заболевание), номер периода развития) - е1етеnt (развитие(заболевание), номер периода развития - 1) Î I(нижняя граница (Периоды развития (заболевание)(номер периода развития), верхняя граница (Периоды развития (заболевание) (номер периода развития)])

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

Примечание. При сопровождении ИПС возможно, например, такое влияние изменений: если усложняем простую онтологию наблюдений (на рис. Д) - добавляем «составные значения», то в онтологии знаний о норме и заболеваниях МИ4 претерпит изменение: вместо «возможные значения» будет вариант «возможные качественные значения» и вариант «составные значения», для каждого – своя импликация.

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

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

Подписано к печати 25.09.2012 г. Усл. п.л. 2,4 Уч.-изд. л. 2,0

Формат 60х84/16. Тираж 100. Заказ 24.

________________________________________________________________

Издано ИАПУ ДВО РАН. Владивосток, Радио, 5.

Отпечатано участком оперативной печати ИАПУ ДВО РАН.

Владивосток, Радио, 5.

 

[1] Здесь и далее при описании модели конфигурации термин решатель используется для простоты в узком смысле – как компонент ИПС без пользовательского интефейса, связывающийся с внешним миром через хранимые ИР (или с интерфейсным компонентом – через сообщения).

[2] Конфигурационную идентификацию, соответствующую завершению стадии жизненного цикла продукта, называют базовой версией [Лапыгин 2004].

[3] КК - клиническая картина, КП – клиническое проявление