Диссертация (1090633), страница 17
Текст из файла (страница 17)
Библиотека методовВ исследовании рассматривается тип интеллектуальных систем, в которомвсе задачи обеспечиваются методами, предоставляемыми системой управлениязнаниями. Семантическая модель задач системы управления знаниямипредставлена на рисунке 42.Рисунок 42. Модель задач системы управления знаниями.Задача считается реализованной, если поле типа задачи имеет значение«системная задача» и статус задачи определен как «завершена».
Задача считается87системной, если для ее решения определен конструкционный элемент целевойсистемы.Модель задач может быть представлена в различных видах, к ней могут бытьприменены различные системы классификации. Так, например, при примененииклассификации по роли задачи будут распределены в кластеры, каждый изкоторых содержит задачи, приписанные определенной роли пользователя систем.Класс Модель задач определяет декомпозицию задачи, но не специфицируетсвязывание задачи с подзадачей. Для интеграции задач в рамках модели задачпредложен метод интеграции задач, состоящий в создании набора адаптеровзадач. Для создания аннотаций связей между задачами (условий выполненияподзадач в контексте решаемой корневой задачи, включая условия согласованиявходных и выходных параметров задачи, условия выбора подзадачи и условияциклического выполнения и т.д.) разработан класс Адаптер задачи:Адаптер задачи ={Адаптер условной подзадачи,Адаптер циклической подзадачи,Адаптер альтернативных задач,Адаптер последовательности подзадач}.Граф связей класса Адаптер задачи представлен на рисунке 43.Классы адаптеров организуют поток выполнения задач.
Дальнейшеемоделирование состоит в уточнении модели решателя задачи. При этомпроисходит сопоставление классу задачи, являющемуся функциональнымэлементом системы, соответствующего компонента, реализующего задачу.Решатель задач, как указывалось ранее, является самостоятельнымкомпонентом интеллектуальной системы. Под решателем будем пониматьспециализированный интерпретатор баз знаний, в котором зафиксированыонтология базы знаний (и других обрабатываемых им информационных ресурсов)и алгоритмы решения задач интеллектуальной системы. Решатель задачи основанна онтологии обрабатываемой информации и, таким образом, может бытьповторно использован для различных интеллектуальных систем, имеющих ту жеонтологию обрабатываемой информации.Указанный подход позволяет отделить процедурные знания отдекларативных и решатель задач может быть повторно-используемым для классазадач с общей онтологией обрабатываемой информации.Декларативнойсоставляющей решателя здесь считаются те его представления, изменениекоторых влияет на работу решателя, не требуя перекомпиляции кода, а также те,по которым возможна частичная генерация кода решателя [91].
Для каждой новойинтеллектуальной системы, для которой зафиксированы онтологииобрабатываемых информационных ресурсов и алгоритмы решения задач,решатель задач должен разрабатываться заново.Решатель задачи с точки зрения системного подхода представляет собой систему и поэтому, модель решателя рассматривается нами как специализация88класса Система. В качестве подсистем используются специализации класса Producer которые могут представлять как человека — пользователя или разработчика, так и программную систему.
В дальнейшем, без ограничения общностей будем использовать его подкласс Агент, рассматривая в качестве решателя толькопрограммные системы.Рисунок 43. Граф связей класса Адаптер задачи.Решатель задач интеллектуальной ИС может быть представлен множествомагентов и может включать управляющий граф (рисунок 44) [92].Для разработки модели решателя необходимо расширить модель сети агентов. Создадим класс Сеть агентов, используя в качестве метатипа класс абстрактной семантической сети, в качестве узла сети — класс Узел агента, в качественавигационного контекста у которого выбран класс Агент.89Рисунок 44.
Модель решателяАгент производит модификацию информационных ресурсов. Для построенияпрограммных единиц, решающих задачи системы, предложена модель агента,представленная на рисунке 45.Рисунок 45. Модель сети агентов.Каждый агент является композицией из классов Блок продукций, в которыхопределяются алгоритмы обработки сообщений, представленные классом Блоксообщений:@Продукция.включает продукцию.@Продукция90@Продукция.внутренние операции.@Операция над ресурсом@Продукция.класс входного ресурса.@@Продукция.описание блока.@Описание блока@Продукция.шаблон входного сообщения.@Сообщение@Продукция.класс выходного ресурса.@@Продукция.шаблон выходного сообщения.@СообщениеДля описания связи формальной модели агента (рисунок 46) с реализующимего программным элементом (ПЭ), предусмотрена связь 6.реализуется, областьюопределения которой является множество классов Component.
Множество классов, наследующих класс Component, образуют библиотеку компонентов, предоставляя их внешним системам как решатели задач.Рисунок 46. Модель агентаСеть агентов строится на основе модели задач. Для каждой задачи создаетсяотдельная сеть агентов. Последовательность шагов построения модели: создается класс на основе класса Сеть агентов, используя последний какпрототип; в процессе перебора задач модели задач решателя для каждой текущей задачи и задач, связанных с текущей задачей связью включает задачу, создаетсякласс Узел агента и с ним связывается класс агента; если для задачи установлен метод решения, то класс агента определяетсячерез соответствующую связь класса метода решения задачи; если метод решения не определен, создается новый класс агента; класс узла агента, созданный для активной задачи, связывается с классомсети связью корневой узел;Созданная таким образом сеть не имеет структурных связей, определяющихвзаимный вызов агентов и введение таких связей в рамках класса сети агентовнецелесообразно, поскольку для определенного таким образом множества узлов91может быть созданы различные наборы связей взаимных вызовов.
Такая ситуацияхарактерна для программной разработки, когда разные алгоритмы обработки используют некоторый общий базовый набор ПЭ. Одновременно с этим, агентобычно имеет набор блоков обработки, представленных классом Блок продукций и созданное архитектурное описание Сеть агентов не позволяет указать конкретный блок обработки.Управляющий граф решателя модель, связывающую взаимодействующие программные единицы (агенты, отдельные блоки которых настроены на обработку разных типов сообщений), в которой узлы соответствуют блокам (блокампродукций агентов), а связи аннотируются классами передаваемых сообщений инаборами ограничений.
Архитектурное описание Управляющий граф решателяможет быть создано на основе описания Модель задачи, включающей множествоклассов адаптеров задач.Рисунок 47. Модель управляющего графа решателя.Управляющий граф применяется, когда в состав решателя задач включаютсяпроблемно-независимые агенты, которые, в отличие от проблемно92ориентированных, не должны отправлять сообщения друг другу напрямую,например агенты, представляющие процедурные операции обеспечивающейсистемы. В этом случае для решателя задач формируется свой управляющийграф, который используется системой управления решателями задач приобработке блока продукций некоторого агента для выбора того агента, которомупредназначено передаваемое сообщение.
Модель управляющего графа решателяпредставлена на рисунке 47.Элементом моделирования модели являются классы Коммуникация блоковпродукций который определяет роли агента в процессе коммуникации — серверкоммуникации или клиент коммуникации и класс передаваемого сообщения. Вкачестве сообщения может выступать любой класс информационных элементовонтологии информационных элементов.Представленная модель решателя может быть применена для построенияразличных видов архитектурного представления, включающих диаграммы,текстовые описания, правила интерпретации.Интерфейс пользователя центральный элемент любой современнойпрограммной системы. Снижение стоимости его разработки достигаетсяиспользованием декларативного языка спецификации и автоматическойгенерации интерфейса. С середины 90-х гг.
стал активно развиваться моделеориентированный подход к разработке интерфейса. Основной идеей подхода является автоматическая генерация интерфейса по декларативным, высокоуровневыммоделям составляющих интерфейса. В результате значительно уменьшаетсячисло процедурных компонент, появляется возможность повторно использоватькомпоненты моделей.2.4.4. Методы разработки интерфейса пользователяВ [92] отмечено, что «именно пользовательский интерфейс является той составляющей программной системы, которая подвержена частым изменениям изза наличия широкого круга пользователей с различным уровнем подготовки и требований к программной системе.
Реализация пользовательского интерфейса, удовлетворяющего требованиям пользователей, возможна только путем создания макетов будущего интерфейса и чем больше таких макетов в единицу времени может быть построено, тем больше вероятность построения дружественного пользовательского интерфейса».Автоматизация создание таких макетов может быть достигнута созданием ихвысокоуровневых декларативных описаний с последующей автоматическойгенерацией (полной или частичной) программного средства.
Методы созданиядекларативных описаний базируются на принципах:1. Повторного использования ранее созданных декларативных описаний;2. Раздельного редактирования архитектурных компонент;933. Декомпозиции каждого архитектурного компонента на составляющие,допускающие их раздельное модифицирование.Для реализации такого подхода к разработке интерфейса предлагаетсяиспользование онтологий для моделирования интерфейса [93]. Формированиедекларативной модели пользовательского интерфейса производится на основеэтой онтологии. Исполнимый код интерфейса автоматически генерируется подекларативному описанию.
При этом реализация и модификация интерфейса отделена от прикладной программы.Выделение таких основные системы понятий предполагает также определение связей, существующих между ними, и, таким образом построение онтологиипонятий модели интерфейса.В вышеуказанной работе выделяют следующие универсальные онтологииO= {D, G, L, S, I},где D онтология предметной области, G– онтология выразительных средств интерфейса, L – онтология прикладной программы, S – онтология сценария диалога,I онтология связи, I=I1I2, где I1 онтология связи между онтологиями предметной области и выразительных средств, I2 между онтологиями предметнойобласти и прикладной программы.Модель конкретного пользовательского интерфейса формируется путем выделения подмножества O из O и уточнения значений ее характеристик.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
