Диссертация (1090633), страница 15
Текст из файла (страница 15)
Интерфейс редактирования запроса72Пользовательский интерфейс для запроса, формируемый соответствующимагентом системы управления, показан на рисунке 27.Сохраняя сформированную модель в виде элемента онтологии и объединяянаборы подобных элементов, можно формировать сложные запросы.Дерево типов запросов представлено на рисунке 28.Рисунок 28. Типы запросов.Результат поиска оформлятся в виде унифицированным образом, как элементили подкласс класса информациого элемента Множество связаннныхсемантических примитивов (Рисунок 29).
Связь корневой узел определяетобласть поиска. Создавая подклассы и специализируя связь listItemType,опредеяющую тип элемента множества, можно формировать различные видызапросов.73Рисунок 29. Структура результата запросаЗапросы к системе, реализующие различные методы поиска, организованы вмодель задач (рисунок 30). Здесь каждой задаче поставлен в соответствие агентобеспечивающей системы.Рисунок 30. Модель задач получения данных2.4. Разработка моделей, методов и алгоритмов проектированияпрограммных систем2.4.1. Разработка онтологии ISO 24744Общие шаблоны, определяющие способы, работы, модели, программные иаппаратные компоненты и документы, операции жизненного цикла, процессы изадачи управления определены в онтологии ISO 24744. Онтология разработана наоснове метамодели стандарта ISO 24744.
Стандарт определяет способы описаний74процессов жизненного цикла приложения. Таксономия онтологических классовонтологии (Рисунок 31) включает в себя класс Элемент методологии(MethodologyElement), представляющий компонент методологии, расширяемый вспецификацию типов дел, деятельности, моделей, документов, определяет языкии/или нотации которые могут или должны быть использованы при примененииметодологии.Рисунок 31. Онтология ISO-24744.Классы, наследующие Элемент методологии: класс Шаблон (Template) — элемент методологии, который используетсядля представления множества классов и специфических связей между ними; класс Ресурс (Resourse) — элемент методологии, который используетсябез экземпляризации; класс Предпринятие (EndravourElement) также наследует класс Элементметодологии и определяет разработку(проект) с целью поставки некоторогопродукта или услуги, конкретизируемое через систему классов, наследующихкласс Элемент предпринятия.
Система классов включает: класс РабочийПродукт (WorkProduct) — представляет любой элемент,используемый в проекте; класс ЕдиницаРаботы (WorkUnit)— абстрактная выполняемая работа; классы Процесс (Process), Стадия процесса (Stage) используются дляописания последовательности работ.75Классы онтологии ISO24744 находятся в отношении классификации, приэтом класс Шаблон представляет классы классификаторов, а классПредпринятие и наследующие его классы – классифицируемые классы.
Так,например, классу Рабочий Продукт сопоставлен класс Вид Рабочего Продукта.Кроме этого классы, наследующие класс Шаблон, используются для созданияпрототипов связей для классов частных онтологий через механизм аннотации.Класс Процесс выполнения определяет систему связи процессов, задач,пользователей системы, характеризующих временную развертку выполненияпроекта:@Процесс выполнения.включает.@Последовательностьстадий@Стадия.включает.@Последовательность задач.Задача является одним из системообразующих параметров, позволяющимоценить степень согласованности архитектурных описаний. Класс задачаопределен для каждого архитектурного описания объектом классаклассификатора:@Задача.имеет тип=@тип задачи,где тип задачи = {задача пользователя, задача проекта, задача группы описаний,системная задача}.Множество видов задачи определяет уровни декомпозиции каждой задачи.Так задачи пользователя декомпозируются в систему задач уровня проекта,каждая из которых декомпозируется до задачи одной из систем обеспечивающейсистемы.
Задача определяется графом:@Задача.имеет .{@Постановка задачи, @Агент, @Результат},здесь Агент характеризует исполнителя задачи, а Результат — выходныепараметры задачи.Описания классов, используемых для описания задач, приведены в таблице2.Таблица 2. Классы онтологии задачОнтологический классОписаниеTask (Задача)представляет единичную задачу, выполняемую пользователем. Для моделирования иерархической структурызадач введены подклассы задач ComplexTask,SimpleTask, AtomicTask и CompositeTask.TaskKind (Тип задачи) определяет вид задачи, предоставляя описание задачи,ее назначение.Preinformation,наследуют класс Ограничение (Constraint) определяютPostinformaitionконтекст задачи до и после ее выполнения.Producerпредставляет собой обобщенное описание заинтересованного лица, исполнителя задачиGroupслужит для представления групп пользователей, объ(Группа пользователей) единяемых по общности их задач.762.4.2.
Методы и алгоритмы моделирования архитектуры информационнойсистемыМетамодель ISO 24744, как показано в [83], не в полной мере обеспечиваетсистемную поддержку описания ситуации в том смысле, что она не имеет средствдля точного определения возможности использования методов, определенной в еетерминах, в некоторой конкретной ситуации, для определения классификацииметодов и управления ими. В частности, в метамодели нет понятия системы,рассматриваемой как средства решения указанных задач и понятия архитектурысистемы.Архитектуру интеллектуальной ИС [84] можно представить каквзаимосвязанную тройку, состоящей из базы знаний и других информационныхресурсов, решателя задач, реализующего функциональность системы ипользовательского интерфейса.
Частные цели этих компонентов в общем случаеразличны и независимы.Предложенной ранее модели обеспечивающей системыпоставим всоответствие интеллектуальную систему проектирования, являющуюсяинструментальной оболочкой для общего информационного пространства,которая должна позволять хранить онтологии и знания каждой из подсистемпроектирования, а также обеспечивать использование при решении задач техинформационных компонентов, которые в этом случае необходимы, то естьдопускать интеграцию знаний и онтологий разных разделов области в рамкаходного информационного ресурса. Таким образом, к информационной системе,основанной на знаниях, предъявляются требования: обеспечение возможности изменения знаний, структура которыхопределяется онтологией ПО; наличие средств модификации системы понятий предметной области; наличие возможности интеграции систем понятий из различных разделовПО.В этом случае знания, скрытые в кодах программного обеспечения, вкомпонентных моделях дизайна приложения и в других реализационныхописаниях систем, будут представлены в виде сущностного, не зависящего отдеталей реализации описания создаваемой системы.
Таким образом, процесспроектирования в качестве своего контекста имеет сеть различных онтологий ирешателей задач над нею. Решатели задач обеспечивают различныеинтерпретации сети онтологий, к которым следует отнести задачи генеративногопрограммирования полное или частично автоматизированное созданиепрограммных компонент.Обеспечение процесса проектирования и генерации компонентов требуетметодов и инструментов управления как для каждой отдельно взятой онтологии,так и для взаимного согласования указанных «универсальных» онтологий.77В варианте архитектуре интеллектуальной системы, в которой онтологияиспользуется для управления компонентами ИС [85] (рисунок 32) выделяется тримодуля управления, который использует знания, хранимые в онтологии, дляадаптации ИС.Интеллектуальная системаБаза знанийРешательзадачПользовательскийинтерфейсПодсистемауправленияинформационнымиресурсамиПодсистемауправлениярешателемзадачПодсистемауправленияпользовательскиминтерфейсомСистема, управляющая интеллектуальной системойРисунок 32.Архитектура адаптивной ИИСЗдесь архитектура интеллектуальных систем рассматривается каквзаимосвязанная тройка подсистем, характерных для «классической» модели ИС,включающая базу знаний (и других информационных ресурсов – баз данных,онтологий, метаонтологий и т.п.), решатель задач и пользовательский интерфейс.Интеллектуальность системы определяется наличием системы управления еёкомпонентами.
Частные цели управления этими тремя компонентамиинтеллектуальной системы в общем случае различны и в значительной степенинезависимы. В соответствии с этим в архитектуре выделяются подсистемы,управляющиеинформационнымиресурсами,решателемзадачипользовательским интерфейсом. База знаний, выполненная в виде онтологии,хранит модели всех компонентов ИС, при этом изменение в моделях черезсоответствующую подсистему управления изменяет конфигурацию и поведениеуправляемого ею компонента.Наряду с задачами, связанными с получением и управлением знаниями вотдельных предметных областях, можно выделить ряд задач, имеющихуниверсальный характер.
К таким задачам относятся задачи построенияонтологических классов и отношений между ними, импорт, экспорт ивыравнивание онтологий. Все эти задачи связаны с построением базы знаний имогут быть сформулированы в семантике предметной области «Разработка баззнаний».Как указывалось ранее, в соответствии со стандартом ISO 42010, частноеархитектурное описание системы представляет собой модель, которая отображает78представление определенного stakeholder о системе и может использоваться дляпредставления как одного, так и группы аспектов информационной системы.Выделим несколько групп описания для процесса проектирования ИС (Рисунок33).Группа описанийпроцессов и задачОнтологическое описаниеКонцепт предметнойобластиПрезентационнаягруппа описанийГруппа описанийНавигационнаягруппа описаниймодели данныхПрограммнаягруппа описанийРисунок 33. Архитектурное описание системыНавигационная группа описаний (navview) рассматривает его как связьнекоторого идентификатора (url-адреса) с источником данных, определенным вdataview, и его визуальном представлении из guiview.Группа описаний модели данных (dataview) определяет отображенииontoview на различные схемы данных, представляя его в нотациях xml, сущностьсвязь, класс-атрибуты.Презентационная группа описаний (guiview) определяет представлениеконцепта предметной области как множество визуальных элементов, чаще ненепосредственно, а как некоторую визуализацию элементов модели изинформационной группы описаний.Группа описаний процессов и задач (taskrview) определяет процессы изадачи, связанные с концептом предметной области.Программная группа описаний (componentview) определяет программноепредставление компонента предметной области в виде программного компонента,набора сервисов и т.д.В предлагаемой онтологии архитектуры [86] определены классы,соответствующие понятиям стандарта ISO 42010, позволяющие проводитьсогласование моделей, представлять модели проектов информационных систем,79их архитектуры и архитектурные описания.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
