Программные продукты и системы

Объекты-спецификаторы

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

Для реализации спецификаторов в язык SATL введены следующие встроенные типы данных: PARAMETER_SPEC, OPERATION_SPEC, PRODUCTION_SPEC, PROCESSOR_SPEC, TASK_SPEC, MODULE_SPEC, представляющие собой типы спецификаторов параметров, операций, продукций, процессоров, задач и модулей соответственно. Эти типы данных можно использовать подобно классам С++ для создания конкретных экземпляров спецификаторов и дальнейшей работы с ними. Описания встроенных типов в виде определений классов С++ здесь и далее не приводятся, так как они сильно зависят от реализации, но приводимая ниже информация может помочь в понимании природы этих типов данных как классов и в правильном использовании данных этих типов как экземпляров объектов соответствующих классов.

· Общим предком типов спецификаторов является встроенный тип SPECIFICATOR с конструктором без аргументов, конструктором однотипного копирования, виртуальными нулевыми операторами однотипного присваивания (“=”), сравнения (“==”) и ввода/вывода и виртуальным деструктором. Кроме того, SPECIFICATOR имеет члены-функции для доступа (по чтению и записи) к стандартным атрибутам с соответствующими типами и именами: char*& . . . KEY( ), char*& . . . name( ), char*& . . . COMMENT( ), TIMESTAMP& . . . LASTMOD ( ), TICON& . . . ICON ( ) [1].

· Каждый тип спецификатора конкретного вида объектов ПО имеет конструктор с аргументом в виде ключа объекта ПО соответствующего типа, с конструктором однотипного копирования, операторами однотипного копирования, присваивания (“=”) и сравнения (“==”), операторами ввода/вывода и деструктором. Кроме того, каждый тип спецификатора имеет члены-функции для доступа (по чтению и записи) к своим атрибутам с соответствующими типами и именами. Таким образом, для спецификатора параметра ПО это будут bool& . . . CONST ( ), <TYPE>& . . . TYPE( ), bool& . . . DISINTEGRATE( ), где <TYPE> зависит от реализации (определение типа <TYPE> тесно связано со средством RTTI и может быть раскрыто с принятием окончательной редакции стандарта ANSI/ISO языка С++). Для спецификатора операции ПО это будут PARAMETER_REF& . . . RETURN( ), где PARAMETER_REF специальный тип данных ссылки на параметр ПО (подробности ниже), int& . . . LOGICAL( ), OPERATOR_PARMLIST& . . . PARMLIST( ), где OPERATOR_PARMLIST представляет собой встроенный класс, реализующий список с предком LIST (подробности ниже) и с членами-функциями int SIZE( ), OPERATOR_PARMLIST_ITEM& . . . [ ] (int), где класс OPERATOR_PARMLIST_ITEM в свою очередь имеет члены-функции bool& . . . IN( ), PARAMETER_REF& . . . IN( ), bool& . . . OUT( ), PARAMETER_REF& . . . OUT( ), bool& . . . ASTERISK( ), PARAMETER_REF& . . . PARAMETER( ), bool& . . . DISINTEGRATE( ), bool& . . . EXTRAORDINARY( ), bool& . . . INTEGRATE( ). Для других типов спецификаторов имеется построенный аналогичным образом свой набор членов-функций для доступа к соответствующим атрибутам.

· Встроенные типы ссылок на экземпляры объектов ПО определенного вида (параметры, операции, продукции, процессоры, задачи и модули) имеют имена PARAMETER_REF, OPERATION_REF, PRODUCTION_REF, PROCESSOR_REF, TASK_REF и MODULE_REF соответственно. Их общий предок OBJECT_REF – ссылка на объект встроенного типа OBJECT (в зависимости от реализации). Для OBJECT_REF определен виртуальный оператор разыменования (“*”) для использования доступа к ссылаемому объекту типа OBJECT. Для объектов типа OBJECT определен обратный виртуальный оператор получения ссылки (“*”) с результатом типа OBJECT_REF. Аналогичным образом определены одноименные операторы к парам:

PARAMETER_REF и ключ параметра,

OPERATION_REF и ключ операции,

PRODUCTION_REF и ключ продукции,

PROCESSOR_REF и ключ процессора,

TASK_REF и ключ задачи,

MODULE_REF и ключ модуля.

· Создать конкретный экземпляр произвольного объекта ПО можно с помощью специальной конструкции CREATE(<SPECIFICATOR>[<O>] [=<V>], где <SPECIFICATOR> – спецификатор объекта ПО требуемого типа, содержащий значения атрибутов создаваемого объекта, <O> – переменная типа ссылки на экземпляр объекта ПО требуемого типа, <V> – начальное значение, и удалить – с помощью специальной конструкции DESTROY (<SPECIFICATOR>) или DESTROY (<O>), которые являются исполнимыми операторами программы на SATL.

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

Повсеместное применение таких мощных средств наряду с открывающейся гибкостью и широкими возможностями может привести к нерациональному расходованию ресурсов (времени, памяти) на этапе исполнения программы. Чтобы контролировать этот процесс, в языке SATL предусмотрены специальные средства, помогающие программисту, не жертвуя гибкостью, создавать по возможности более эффективный код. Речь идет о делении объектов ПО на зависимые от динамического изменения других объектов и независимые. Соответствующие необязательные взаимоисключающие атрибуты DEPENDED и INDEPENDED дополняют набор стандартных атрибутов объектов ПО [1].

Объект ПО является зависимым, если выполняется хотя бы одно из следующих условий:

- в описании этого объекта присутствует ключевое слово DEPENDED;

- этот объект создается/уничтожается динамически с помощью конструкций CREATE/DESTROY;

- этот объект явно содержит в своих атрибутах ссылку на другой зависимый объект;

- на стадии компиляции статистического анализа текста программы не исключается возможность зависимости этого объекта от других зависимых объектов, в описании этого объекта отсутствует ключевое слово INDEPENDED, и, кроме того, опции компиляции не предписывают считать по умолчанию все объекты ПО независимыми;

- опции компиляции предписывают считать по умолчанию все объекты ПО зависимыми, и в описании этого объекта отсутствует ключевое слово INDEPENDED.

Если ни одно из вышеперечисленных условий не выполняется, объект ПО считается независимым.

Для повышения эффективности кода следует сводить к минимуму число зависимых объектов в программе.

Примеры работы со спецификаторами:

PARAMETER_SPEC ps1 (p1), ps2; /* создание спецификаторов параметров ps1 на основе параметра p1 и ps2 без начального значения */

ps2=ps1; /* копируем значение спецификатора из ps1 в ps2 */

cout << ps2.KEY( ) << ps2.CONST( ) << OPERATOR_SPEC(01).PARMLIST.SIZE( ); /* печатаем значения атрибутов KEY и CONST из спецификатора параметра ps2 и число фактических параметров операции 01 */

ps2.KEY=“p2”; // изменяем ключ параметра на p2

CREATE ps2; // и создаем параметр с таким ключом

. . .

DESTROY ps2; // уничтожаем параметр с ключом p2

Потоковый ввод/вывод

Для значений параметров ПО и спецификаторов определены потоковые операторы ввода/вывода, имеющие принятые в C++ обозначения (“>>” и “<<”).

Таким образом, чтобы ввести из потока <in> или вывести в поток <out> значение параметра <p>, необходимо записать следующее: <in> >> <p> или <out> << <p> соответственно. При этом файл входного потока должен содержать в отдельной строке вводимое значение параметра <p>, оформленное следующим образом:

<p>=<v>,

где <v> – вводимое значение, оформленное по правилам C++ в соответствии с типом значения <p>. Для массивов, пересечений, структур и классов допускается размещать каждый элемент в отдельной строке, но при этом к <p> следует добавлять индекс(ы) в квадратных скобках или уточнитель(и) в виде имени элемента через точку.

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

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

Примеры потокового ввода/вывода:

cin >> p1 >> VAR(p2) > p3; /* ввод значений параметров p1, p2, p3, причем p2 вводится по правилам C++ */

cout << s1 << p1; /* вывод значения спецификатора s1 и параметра p1 */

Базы знаний и данных

Для долговременного хранения, быстрого поиска и обновления информации в инструментально-технологическом комплексе (ИТК) САТУРН [2] используются базы знаний и данных. Исходя из того, что деление на базы знаний и данных весьма условно (считается, что базы знаний в чистом виде должны применяться только для хранения спецификации ПО, базы данных в чистом виде – только для хранения расчетных данных), а кроме того, из практических соображений в ИТК САТУРН любая база способна хранить и то, и другое, в дальнейшем будем называть их просто базы данных (БД).

В языке SATL для работы с БД применяется встроенный тип данных с именем BASE. В качестве членов-функций для класса BASE определены следующие:

- конструктор для открытия БД с аргументом в виде строки, содержащей путь к соответствующему файлу;

- конструктор однотипного копирования;

- оператор однотипного присваивания (“=”);

- оператор сравнения (“==”);

- функция PATH для получения строки, содержащей путь к файлу БД;

- деструктор для закрытия БД.

В результате компиляции и сборки программы на языке SATL создается целевая БД пакета (база знаний), содержащая все спецификации объектов ПО, определенных в программе. Встроенное значение MAIN объекта типа BASE соответствует этой БД. Встроенное значение DATA объекта типа BASE соответствует БД для автоматического сохранения значений параметров. Встроенное значение с именем NONE объектов типа BASE означает отсутствие БД.

Примеры работы БД:

BASE b1 (“c:\\p\\b1”); /* открываем БД из каталога c:\p\b1 */

BASE b2=b1; /* дублируем b1 в b2*/

if (b1==b2) . . . /* сравниваем b1 и b2*/

count << b2.PATH; /*выводим путь для b2*/

~ b1; /* закрываем b1 */

С объектами типа BASE тесно связаны объекты встроенного типа SET – наборы или множества. В качестве членов-функций для класса SET определены следующие:

· конструктор без аргументов;

· конструктор с аргументами OBJECT& = ALL_PARAMETERS, BASE& = NONE, char* = “1” (вариант значения);

· конструктор с аргументами BASE& = NONE, char* = “1” (вариант значения);

· конструктор с аргументами SET&, BASE& = NONE, char* = “1” (вариант значения);

· конструктор с аргументами LIST&, BASE& = NONE, char* = “1” (вариант значения);

· конструктор однотипного копирования;

· операторы однотипного присваивания (“=”) и сравнения (“==”);

· операторы однотипного множественного сложения (“+”) и вычитания (“-”), фактически выполняющиеся над множествами объектов ПО, над списками и вариантами значений, указанных в качестве аргументов в конструкторах соответствующих операндов (БД только суммируются);

· оператор однотипного ввода (вывода): “>>” (“<<”) с результатом типа SET, копирующий пересечение двух множеств из объектов, заданных левым операндом в объекты, заданные правым операндом (и наоборот). При этом объекты берутся из БД, если операнд содержит БД, или из оперативной памяти, если операнд не содержит БД;

· оператор ввода (вывода): “>>” (“<<”) со вторым операндом типа SPECIFICATOR& и результатом типа SET, копирующие спецификацию объекта, заданного левым операндом, в спецификатор, заданный правым операндом (и наоборот);

· функции доступа к элементам множества: SET_PARMLIST& . . . PARMLIST( ), где SET_PARMLIST представляет собой встроенный класс с предком типа LIST и с членами-функциями: int . . . SIZE( ) и PARAMETER_REF& . . . [ ] (int) для параметров, аналогично построенные функции для доступа к объектам ПО других типов SET_VARILIST . . . VARILIST( ), где SET_VARILIST представляет собой встроенный класс с предком типа LIST и с членами-функциями: int . . . SIZE( ) и char*&. . . [ ] (int) для вариантов значений, SET_BASELIST . . . BASELIST( ), где SET_BASELIST представляет собой встроенный класс с предком типа LIST и с членами-функциями: int . . . SIZE( ) и BASE& . . . [ ] (int) для БД;

· деструктор.

Для типа SET имеется набор встроенных значений: ALL_PARAMETERS, ALL_OPERATIONS, ALL_PRODUCTIONS, ALL_PROCESSORS, ALL_TASK, ALL_MODULES, ALL_ VARIANTS, ALL_BASES – множества всех параметров ПО, операций ПО, продукций, процессоров, задач, модулей, вариантов и БД соответственно, ALL – множество всех перечисленных множеств, кроме БД. Специальное встроенное значение DELETE используется в операциях “<<” и “>>” для удаления.

Примеры работы с множествами:

SET(b1, v1) >> ALL_PARAMETERS; /* копирование значений варианта v1 всех параметров из БД b1 в параметры в оперативной памяти */

SET(p1, b1, v1) << DELETE; /* удаление варианта v1 параметра p1 из БД b1 */

SET(o1, b1) >> o_spec1; /* копирование спецификатора объекта ПО o1 в спецификатор o_spec1 */

SET(ALL, b1) >> SET(ALL, b2) >> SET(ALL_TASK, b3); /* копирование содержимого из БД b1 в БД b2 и всех задач из БД b1 в БД b3 */

SET(PROCESSOR_SPEC(proc1).PARMLIST- p1,b1,v1) >> ALL_PARAMETERS; /* копирование значения варианта v1 всех параметров процессора proc1, кроме p1, из БД b1 в параметры в оперативной памяти */

SET(p1+p2, b1) << DELETE; /* удаление спецификаций параметров p1 и p2 из БД b1 */

Язык SATL содержит специальные средства для автоматизации процесса записи значений параметров в БД. С помощью необязательного атрибута SAVE [(<SAVE>)], добавляемого к атрибутам параметра ПО, можно указать в качестве <SAVE> объект типа SET с определенной БД и именем варианта для автоматического сохранения значения данного параметра. По умолчанию <SAVE> принимается как SET(DATA, “1”). Для параметров ПО, у которых отсутствует атрибут SAVE, можно определить возможность их автоматического сохранения по умолчанию с помощью опций компилятора.

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

Пример:

PARAMETER KEY(p1) TYPE(. . .) SAVE;

PARAMETER KEY(p2) TYPE(. . .) SAVE (SET(b1,“2”);

PARAMETER KEY(p3) TYPE(. . .);

. . .

SAVE;

. . .

Здесь при выполнении оператора SAVE будет произведено автоматическое сохранение значения параметра p1 в БД DATA с именем варианта “1”, параметра p2 в БД b2 с именем варианта “2”. Автоматическое сохранение значения параметра p3 будет произведено в зависимости от опций компилятора.

Специализированная объектно-ориентированная модель данных (СООМД)

Выбор модели данных является ключевым вопросом эффективной реализации языка SATL. В первую очередь речь идет о концептуальной схеме спецификации ПО в ИТК САТУРН [2], общее представление о которой дано в работе [1], а более детальное изложение имеется в [3]. Адекватность представления концептуальной схемы ПО – вот главный критерий выбора необходимой модели данных.

В результате проведенного в [3,4] детального анализа выявлено, что требуемая модель данных должна принадлежать к классу объектно-ориентированных моделей и удовлетворять целому ряду требований, характеризующих ее специализированную природу.

Требования к СООМД

1) Модель должна быть сильно типизированной: каждый объект должен принадлежать к определенному типу данных.

2) Каждый объект должен иметь “внешний ключ” – однозначно его идентифицирующее значение, по которому система обеспечивает наиболее быстрый доступ к объекту. Необходимо, чтобы это значение не менялось в течение всего времени существования объекта. Желательно, чтобы оно не являлось частью объекта.

3) Средства, используемые для описания типа, должны по своей выразительной мощности быть на уровне языков ООП типа C++ (шаблоны, множественное наследование, виртуальные методы/предки, управление событиями, исключительные ситуации). Для вариантных записей может быть использован автоматический выбор актуального варианта. Обязательно должны поддерживаться поля переменной длины.

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

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

6) Объекты могут вступать в n-арные отношения (связи). Каждая конкретная связь должна принадлежать определенному типу. Тип связи определяет типы объектов, выступающих в этой связи в i-той роли, минимальное и максимальное кардинальное число, ограничения целостности, накладываемые на участвующие в связи объекты. Типы связей могут определяться через наследование свойств ранее определенных типов связей.

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

8) Типы являются объектами типа “тип”. В процессе сеанса их можно создавать, изменять и удалять (соответствующий переход в медленный режим интерпретации должен осуществляться только при необходимости).

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

10) Время существования объекта не должно ограничиваться одним сеансом работы. Физически объект может размещаться в специальном долговременном “хранилище” – пространстве. Одновременно может быть открыт доступ к нескольким пространствам. Для сохранения целостности связей между пространствами должна быть предусмотрена автоматически выполняемая процедура актуализации данных на основе версионно-временных зависимостей.

11) Схема БД должна храниться наряду с другими данными в БД с открытым доступом к ней с целью чтения или модификации.

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

Спецификации СООМД

При описании спецификаций СООМД будем ориентироваться по мере возможностей на терминологию, используемую в [5], а по языковым конструкциям на язык программирования С++ [6].

Схема в рамках СООМД представляет собой набор определений классов над алфавитом В, где В состоит из множества символов классов С, множества символов атрибутов А (используемых при определении структуры класса), множества символов n-арных отношений над классами U и множества символов методов М. Далее будем использовать символы c, a, u, m как элементы множеств C, A, U, M соответственно.

Будем считать, что в СООМД изначально встроен некоторый набор базовых классов (целые, вещественные, строки и т.д.).

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

t :: = c | u | <t> : t1, ... tn | <etc_in_C++_style> |

      select by(i) <t> {t1 a1; ...: tn an} |

      enum <t> {<x1> a1; ...: <xn> an} |

      t1 <t> [n1, ..., nn] |

      blob <t> ,

где <t> – тип определяемого типа; t1, ..., tn – ранее определенные типы; <etc_in_C++_style> – определение типа в стиле C++; i и n1, ..., nn – ранее определенные атрибуты целого типа или константы; <x1>, ..., <xn> – необязательные представления перечислимых значений. Сложные структуры интерпретируются следующим образом: select – вариантная запись с автоматическим выбором актуального варианта по значению i; enum – перечислимый тип с возможностью определения представлений перечислимых значений; t1 <t> [n1, ..., nn] – массив с границами n1, ..., nn и элементами типа t1; blob – произвольный двоичный объект без заранее определенного размера.

Определение метода m имеет следующую форму:

method m (c1, ..., cn) returns (c1¢, ..., cn¢) ... ,

где c1, ..., cn – вход метода; c1¢, ..., cn¢ – выход метода. Дополнительно будем считать, что в СООМД имеются средства для определения и реализации методов, по возможностям сравнимые с таким языком, как С++ (перегрузки операций, виртуальные методы и т.д.).

Определение класса c имеет следующую форму:

class c type (t) methods (m1, ..., mn) ,

где t представляет собой тип значений объектов класса с; m1, ..., mn – методы класса.

Определение отношения u имеет следующую форму:

relation u (c1(n1, n2), ..., cn (n3, n4))

      [keys (k1, ..., kn)]

      [constains (constr1, ..., constrn)] ,

что интерпретируется как определение n-арного отношения над классами c1, ..., cn, где n1, n2 – кардинальные числа, которые означают соответственно минимальное и максимальное число объектов класса с1, связанных с объектами классов c2, ..., cn, n3, n4 – кардинальные числа, которые означают соответственно минимальное и максимальное число объектов класса cn, связанных с объектами класса c1,..., cn-1; k1, ..., kn – выражения из атрибутов классов c1, ..., cn, образующие ключи отношения u (уникальные ключи отмечаются префиксом unical); constr1, ..., constrn – ограничение целостности, накладываемое на экземпляры классов c1, ..., cn, участвующие в отношении u.

Объекты и внешние ключи. Экземпляры классов и отношений являются объектами. Различаются внешние и внутренние объекты.

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

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

Следующие операции выполняются над внешними ключами (синтаксис в стиле С++):

new – создать экземпляр внешнего объекта и выдать его внешний ключ;

& – получить внешний ключ данного объекта;

* – получить доступ к внешнему объекту по данному внешнему ключу;

:> – получить доступ к внутреннему объекту по данному внешнему ключу;

–> – получить доступ к элементу структуры внешнего объекта по данному внешнему ключу;

base – получить доступ к экземпляру базы данных по данному внешнему ключу;

++ – следующий экземпляр данного класса/отношения;

-- – предыдущий экземпляр данного класса/отношения;

# – получить внешний ключ по номеру объекта заданного класса/отношения;

count – получить общее число объектов заданного класса/отношения.

Встроенные объекты. В СООМД изначально имеется набор встроенных классов (класс типов сT, класс классов сС, класс отношений сR, класс атрибутов сА, класс методов сМ, класс объектов сО) и встроенных отношений между ними.

Класс типов сT определяет множество типов Т. Все типы данных (t) являются объектами класса сТ.

Класс классов сС определяет множество классов С. Все классы (с) являются объектами класса сС. Все типы, отношения, атрибуты, методы являются объектами (экземплярами) соответствующих классов.

Класс классов сС имеет встроенный метод create для порождения экземпляров классов (в том числе и экземпляров класса классов сС):

method create (cC, cT) returns (cO),

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

Соответственно имеется встроенный метод destroy:

method destroy (cО) returns ( ),

который также вызывает подходящий метод-деструктор класса с1, если в качестве сО передан объект класса с1.

Встроенный метод са11 позволяет вызывать произвольные методы произвольного класса (в том числе create, destroy, call класса сС):

method call (cМ, сО, сТ) returns (cT).

Встроенное отношение над классами hierarhy определяет иерархию классов:

relation hierarhy (cC(O, MAXPARENTS), сС (О, MAXCHILDREN))...

Класс отношений сR определяет множество отношений R. Все отношения (r) являются объектами класса сR. Класс отношений сR имеет встроенный метод create для построения нового отношения r на базе старого r1:

method create (cR, сТ) returns (cR),

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

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

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

Класс атрибутов сА определяет множество атрибутов А. Все атрибуты (а) являются объектами класса сА.

Класс методов сМ определяет множество методов М. Все методы (m) являются объектами класса сМ.

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

Встроенный класс объектов сВ определяет множество объектов БД (независимых распределенных хранилищ информации). Каждый объект хранится в определенной БД.

Описание класса сВ следующее:

class cB (contents) methods (оpen, close, synchronize, ro, rw, sawe, autosave, <controls>),

где contents – отношение, содержащее информацию о содержимом БД; open/close – методы для открытия/закрытия БД; synchronize – метод, обеспечивающий версионно-временную синхронизацию БД; ro/rw – методы, устанавливающие режимы доступа к БД (только чтение/чтение и запись), save/autosave – методы, обеспечивающие режимы сохранения БД; <controls> – другие методы для выполнения служебных функций с БД.

Описание отношения contents следующее:

relation contents (cC(1, MAXCLASS), сО(О,MAXOBJECTS))...,

что позволяет легко получать доступ к содержимому БД.

Встроенный метод base дает возможность получить доступ к экземпляру БД по заданному внешнему ключу, другие операции над внешними ключами позволяют легко оперировать содержимым БД.

Планирование и автоматический синтез программ. При реализации в рамках СООМД ИТК САТУРН [2] классы объектов могут быть объявлены в качестве параметров, методы – в качестве операций проблемной области. Таким образом, реализуется возможность планирования и автоматического синтеза программ над объектами СООМД.

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

1. Журавлев А.Е., Опарин Г.А, SATL – язык для представления и использования пакетных знаний // Программные продукты и системы. – 1996. – № 3. – С. 26–35.

2. Опарин Г.А., Феоктистов Д.Г., Журавлев А.Е. Инструментальные средства построения и эксплуатации гибридных экспертных систем вычислительного типа // Вычислительные технологии. – Новосибирск: ИВТ СО РАН, 1993. – Т. 2, Т. 6. – С.13–26.

3. Журавлев А.Е., Опарин Г.А. Представление знаний о проблемной области в инструментально-технологическом комплексе САТУРН/ПЗ. Концептуальная схема и выбор модели данных // Компьютерная логика, алгебра и интеллектуальное управление. – Иркутск: ИрВЦ СО РАН, 1994. – Т. 1. – С. 76–88.

4. Журавлев А.Е., Опарин Г.А. Специализированная система управления базами данных в инструментальной системе САТУРН-ЕС // Интеллектуализация средств программирования. – Новосибирск: Наука, 1990.

5. Цикритзис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.

6. Stroustrup B. The C++ Programming Language. Second Edition, Addison-Wesley Publishing Company, 1991. – 669 p.

7. Мейер Д. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.