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

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

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

то В-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(нижняя граница (Периоды развития (заболевание) (номер периода развития), верхняя граница (Периоды развития (заболевание) (номер периода развития)])

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

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

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