Сущности и иерархии классов

Класс в G2 является основой представления знаний. Все, что хранится в БЗ и чем оперирует система, является экземпляром того или иного класса. Все синтаксические конструкции G2 тоже являются классами. Для сохранения общности даже базовые типы данных- символьные, числовые, булевские и истинностные значения нечеткой логики представлены соответствующими классами. Описание класса (тоже экземпляр специального класса) включает ссылку на суперкласс (is-a-иерархия) и перечень атрибутов, специфичных для класса (part-of-иерархия).

Концептуально иерархия классов G2 берет свое начало от корневого класса, именуемого item-or-value (сущность или значение). Класс item-or-value сам по себе не может иметь экземпляров. Однако так как он является корнем всей иерархии классов, он определяет основное поведение всех классов G2. Item-or-value имеет два производных класса - value (хотя концептуально ветвь value представляется классом, в действительности это типы данных G2) и item. Каждый из этих классов имеет свои производные классы. Сущность (item) является корнем разветвленной иерархии классов. Наиболее важные ветви этой иерархии могут быть сгруппированы в небольшое число категорий.

Иерархия модулей и рабочих пространств

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

Приложение в G2 может быть организовано в виде одной БЗ или в виде нескольких БЗ, называемых модулями. В последнем случае говорят, что приложение модуляризировано (структурировано на модули). Модули приложения организованы в древовидную иерархию с одним модулем верхнего уровня. Модули следующего уровня состоят из тех модулей, без которых не может работать модуль предыдущего уровня. Эти модули называют "непосредственно требуемые модули".

Существуют 2 способа создать G2-приложения.

1. Разрабатывается одномодульное приложение, которое затем при необходимости разделяется на отдельные модули.

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

Структурирование приложения на модули обеспечивает следующие преимущества:

- позволяет разрабатывать приложение одновременно нескольким группам разработчиков;

- упрощает разработку, отладку и тестирование;

- позволяет изменять модули независимо друг от друга;

- упрощает повторное использование знаний.

Рабочие пространства являются контейнерным классом, в котором размещаются другие классы и их экземпляры, например объекты, связи, правила, процедуры и т.д. Каждый модуль (база знаний) может содержать любое количество рабочих пространств. Рабочие пространства образуют одну или несколько древовидных иерархий с отношением is-a-part-of (является частью). С каждым модулем (базой знаний) ассоциируется одно или несколько рабочих пространств верхнего (нулевого) уровня, каждое из этих рабочих пространств является корнем соответствующей древовидной иерархии. В свою очередь, с каждым объектом (определением объекта или связи), расположенным в нулевом уровне, может быть ассоциировано рабочее пространство первого уровня, связанное с ним отношением "является частью", и т.д.

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

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

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