CC BY
9
Посилання на статтю_
Дёмин М.К. Представление динамики развития информационно-управленческих архитектур в объектноориентированных базах данных / М.К. Дёмин // Управлшня проектами та розвиток виробництва: Зб.наук.пр. - Луганськ: вид-во СНУ iм. В.Даля, 2008. - № 1(25). - С.75-85.___
УДК 004.65:330.47
М.К. Дёмин
ПРЕДСТАВЛЕНИЕ ДИНАМИКИ РАЗВИТИЯ ИНФОРМАЦИОННО-УПРАВЛЕНЧЕСКИХ АРХИТЕКТУР В ОБЪЕКТНООРИЕНТИРОВАННЫХ БАЗАХ ДАННЫХ
Рассмотрены проблемы организации объектноориентированных темпоральных баз данных с использованием интеллектуальных указателей. Предложена модель информационно-управленческой архитектуры, способная эффективно представлять данные о динамике ее развития. Рис. 9, ист. 5.
Ключевые слова: информационно-управленческая архитектура, объектно-ориентированная модель, темпоральная база данных.
М.К. Дьомш
ПРЕДСТАВЛЕННЯ ДИНАМ1КИ РОЗВИТКУ 1НФОРМАЦ1ЙНО-УПРАВЛ1НСЬКИХ АРХ1ТЕКТУР В ОБ'СКТНО-ОР1СНТОВАНИХ БАЗАХ ДАНИХ
Розглянут проблеми оргаызацп об'eктно-орieнтованих темпоральних баз даних з використанням Ытелектуальних покажчикiв. Запропонована модель Ыформацмно-управлЫсько'Т архiтектуру, що здатна представляти динамку ТТ розвитку. Рис. 9, дж. 5.
M.K. Dyomin
PRESENTATION OF INFORMATION-ADMINISTRATIVE ARCHITECTURES DEVELOPMENT DYNAMIC IN OBJECT-ORIENTED DATABASES
Problems of object-oriented databases design using smart objects are examined. Information-administrative architectures model is offered. It affords to present information-administrative architectures development dynamic.
Постановка проблемы. В статьях [1-3] предложена объектно-ориентированная модель информационно-управленческих архитектур (ИУА) с динамическим определением типов. В этих и последующих работах не затрагивалась проблема представления динамики развития ИУА. А именно возможность хранения такой динамики является одним из ключевых требований к базам данных (БД) ИУА (БД должна быть темпоральной). Такая информация необходима при осуществлении проектов повышения организационной эффективности предприятий. Некоторые объектноориентированные СУБД (например, Versant [4]) предоставляют для подобных задач средства поддержки версионности данных. Их использование требует, чтобы объектные модели
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
1
были разработаны с учетом специфики этих средств. Требуется исследовать возможность использования средств версионности данных Versant при создании темпоральных баз данных ИУА, основанных на модели с динамическим определением типов.
Целью статьи является дальнейшее развитие модели ИУА с динамическим определением типов с целью обеспечения возможности представления динамики развития архитектур, оценка эффективности соответствующих средств объектноориентированной СУБД Versant, выявление общих проблем, специфических для БД, обладающих версионностью данных.
Анализ публикаций. В [2] был представлен концептуальный уровень модели ИУА с динамическим определением типов. Он включает такие сущности, как «элемент ИУА», «тип элемента», «информационный слой», «тип слоя» и др. Было отмечено, что ИУА предприятия состоит из общей информации и данных о его структуре, представленной в виде совокупности слоев. Концептуальный уровень требует лишь незначительных изменений для поддержки представления динамики. Так, ранее понятия «предприятие» и «ИУА предприятия» в рамках концептуального уровня рассматривались как идентичные, точнее, они использовались для обозначения одной сущности -информационно-управленческой архитектуры, так как именно она являлось объектом моделирования. Для решения поставленной задачи эти понятия удобно разграничить. Содержание понятия «ИУА предприятия» остается прежним. А для понятия «предприятие» дается следующее определение. Предприятие представляет собой набор снимков ИУА, отражающих динамику развития с момента образования до нынешнего времени. Снимок - состояние ИУА на определенный момент времени.
Основные изменения модели касаются физического уровня. Физический уровень модели ИУА для объектноориентированной СУБД содержит систему классов, реализующую сущности концептуального уровня.
Теперь остановимся на кратком анализе средств Versant, которые могут применяться для поддержки представления динамики развития ИУА. СУБД Versant предоставляет сразу несколько методов решения подобных задач. Так, механизм версионности данных (data versioning) позволяет создавать версии объекта и управлять деревом версий. Версия объекта создается путем копирования. В случае использования этого способа в БД ИУА хранение информации о различных снимках ИУА будет неэффективным.
Другой метод носит название «управление конфигурациями» (configuration management). Он основан на использовании специальных указателей (smart object). Наиболее предпочтительным переводом для «smart object» является «интеллектуальный указатель». Вариант «умный указатель» не подходит, так как под умным указателем понимается относительно простой класс, инкапсулирующий семантику указателей [5]. Функции, возложенные на интеллектуальные указатели, являются более сложными, чем в случае с умными указателями. «Интеллектуальные указатели полезны в случаях, когда большие составные объекты требуют версионности отдельных компонент, а хранить несколько версий всего объекта непрактично» [4]. Интеллектуальный указатель концептуально моделируется таблицей:
Configuration Target object
C1 T1
C2 T2
NULL T3
C3 T1
2
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
T4
T5
Рис. 1. Таблица конфигураций интеллектуального указателя (рис. взят из [4])
Здесь С1, С2, С3 - объекты, описывающие конфигурацию, а Т1, Т2, Т3, Т4, Т5 - объекты, соответствующие конфигурациям и представляющие информацию о некоторой части предметной области. Назовем первый столбец столбцом конфигураций, а второй - столбцом целевых объектов. Формирование этой таблицы возложено на разработчика. Процедура разрешения связи полностью обеспечивается СУБД. Ее результат зависит от так называемого списка конфигураций, установленного для текущей сессии.
Изложение основного материала. Поясним, как работают механизмы управления конфигурациями (Configuration Management Framework, далее -CMF) на конкретном примере. Объектами-конфигурациями могут служить экземпляры класса VDate - специального класса Versant, предназначенного для описания дат.
Предположим, что необходимо хранить информацию об изменениях некоторой древовидной структуры. Приведем фрагмент объявления класса, моделирующего узел дерева:
class Node : public PObject{ public:
private: LinkVstr<Node> m_children; // информация, связанная с узлом
}■
PObject - класс, от которого наследуются все классы, сохраняемые в БД Versant, LinkVstr - специальный контейнер, динамический массив, содержащий ссылки на объекты. Требуется сохранить информацию о таком изменении дерева:
1.09.07 2.09.07 3.09.07
Рис. 2. Изменение иерархической структуры в течение интервала времени
Теперь рассмотрим, как эта информация может представляться объектами Versant.
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
3
1.09.07
2.09.07
3.09.07
Рис. 3. Представление информации об изменениях иерархической структуры
Здесь N3.1, N3.2, N3.3 и N5.1, N5.2 - объекты, описывающие узлы N3 и N5 в различные моменты времени. Узел N3.2 получается из N3.1 путем копирования, затем в него вносятся необходимые изменения. Для представления изменений некоторой части узла приходится хранить всю информацию об узле дважды, но объекты, описывающие другие узлы, останутся неизменными. Сократить дублирование информации можно при помощи дополнительной группировки данных по объектам. Конечно, классы должны создаваться таким образом, чтобы в первую очередь обеспечивать представление концептуальных объектов, но в отдельных случаях возможно создание дополнительных служебных классов с целью обеспечения эффективного представления информации, изменяющейся с течением времени. Примеры таких служебных классов будут рассмотрены позже. В модели ИУА с динамическим определением типов узел слоя содержит только иерархическую информацию и ссылки на объекты, хранящие описания элементов ИУА. Дублируется ссылка на объект, представляющий элемент ИУА, и ссылки на дочерние объекты, то есть повторно хранится незначительное количество информации.
В снимок «2.09.07» были внесены два изменения по сравнению со снимком «1.09.07». Это добавление дочернего элемента к узлу N5 и удаление дочернего у N3. Поэтому эти узлы представлены другими объектами. Объекты, соответствующие другим узлам, остались неизменными. Но N1 в первом снимке ссылается на N3.1, а во втором - на N3.2. Достигается это за счет использования интеллектуальных указателей. Рассмотрим этот механизм подробнее.
Пусть D1, D2, D3 - объекты, описывающие даты «1.09.07», «2.09.07», «3.09.07» соответственно. Для того чтобы интеллектуальный указатель был направлен на объект N3.1, его таблица конфигураций должна иметь вид, представленный на рис. 4 а.
Снимок 1
Столбец конфигураций Столбец целевых объектов
01 N3.1
Столбец конфигураций Столбец целевых объектов
01 N5.1
a) второй указатель объекта N1.1 б) первый указатель объекта N3.1
Рис. 4. Начальный вид таблиц конфигураций интеллектуальных указателей
Для последующих снимков таблицы примут вид: Снимок 2
4
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
Столбец конфигураций Столбец целевых объектов
D2 N3.2
D1 N3.1
Столбец конфигураций Столбец целевых объектов
D2 N5.2
D1 N5.1
Снимок 3
Столбец конфигураций Столбец целевых объектов
D3 N3.3
D2 N3.2
D1 N3.1
Столбец конфигураций Столбец целевых объектов
D2 N5.2
D1 N5.1
а) второй указатель объекта N1.1 б) первый указатель объекта N3.1
Рис. 5. Вид таблиц конфигураций интеллектуальных указателей для снимков 2 и 3 Для того чтобы могло осуществляться разыменование интеллектуальных указателей, должен быть установлен специальный список конфигураций, действующий для текущей сессии. В рассмотренном примере он будет определять необходимую дату. На рис. 6 представлен вид требуемых списков конфигураций.
«1.09.07» «2.09.07» _«3.09.07» _
I 01 I I 01 I 02 I I 01 I 02 I 03 I
Рис. 6. Списки конфигураций для различных дат
Недопустимым является использование различных объектов, представляющих одни и те же даты, так как в списках конфигураций системой учитываются исключительно уникальные идентификаторы объектов, а не их значения. Интеллектуальные указатели создаются при помощи статической функции класса Link - new_smart(). После программист использует два метода -get_configurations() и get_targets() для управления таблицей конфигураций. Первый метод возвращает указатель на список, являющийся столбцом конфигураций, а второй - столбцом целевых объектов. В таблице конфигураций объекты, соответствующие более поздним снимкам, должны идти первыми, а в списке конфигураций сессии - наоборот.
Предположим, есть два снимка - S1 и S2. Для снимка S2 к узлу добавляются два дочерних элемента. При добавлении первого элемента необходимо создать копию родительского узла и выполнить ее модификацию. При добавлении второго - копию создавать не требуется, так как объект, описывающий состояние узла для снимка S2, уже существует. При модификации данных возможны два случая. Первый, когда необходимо вначале создать копию модифицируемого объекта и после выполнить требуемые операции для этой копии. Во втором случае необходимо модифицировать уже существующий объект. Возможна модификация и не самого последнего снимка, поэтому необходимо определять, в какую позицию в таблице конфигураций будет осуществляться вставка копируемого объекта. Приведем функцию определения этой позиции.
o 4b find insert position(Link<LinkType> &smart, VDate&
required date) {
o u4b sz = smart.get configurations()->size();
VDate* cur date;
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
5
for(o_u4b i = 0; i < sz; ++i) {
cur date = AS(VDate, (*(smart.get configurations()))[i]) ; if(*cur date == required date)
return -1; if(*cur date < required date) return i;
}
return sz;
} .
Если функция возвращает -1, то производить копирование и вставку не требуется, а можно использовать уже существующий объект. Его позицию определять не нужно, так как он получается автоматически при разыменовании интеллектуального указателя.
Во все объекты, состояние которых может изменяться с течением времени, удобно добавить функцию for_modify(), которая будет возвращать указатель на объект, представляющий элемент предметной области для текущего снимка. Функция for_modify() в случае необходимости создает копию объекта, который и будет модифицироваться. Названная функция может использоваться клиентским приложением перед каждой модификацией данных. Это оправдано, если за один раз вносится сразу несколько изменений. Другим вариантом является инкапсуляция этого механизма внутри класса. В таком случае for_modify() должна вызываться из каждой операции модификации данных с целью определения объекта, подлежащего изменениям.
Любая функция-член оперирует неявным указателем this, который не является интеллектуальным указателем. Функции for_modify() недостаточно указателя this, необходима возможность получения интеллектуального указателя на используемый объект. Для этого можно использовать функцию класса PObject get_smart(), только объект предварительно должен быть связан с соответствующим интеллектуальным указателем вызовом set_smart().
Учитывая предложенные решения, использование интеллектуальных указателей сводится к следующему. При первом использовании необходимо инициализировать таблицу конфигураций интеллектуального указателя и установить обратную ссылку при помощи функции-члена set_smart(). Приведем пример кода для объектов класса Node:
Link<Node> ln = Link<Node>::new smart();//создаем интеллектуальный указатель
Node* root = O_NEW_PERSISTENT(Node)();//создаем объект ln.get configurations()->add(Link<VDate>(current date()));/*за полняем столбец конфигураций*/
ln.get targets()->add(Link<Node>(root));//заполняем столбец целевых объектов
root->set smart(ln);//устанавливаем обратную ссылку.
При последующих модификациях данных необходимо использовать функцию for_modify(), если ее использование не инкапсулировано в методах класса. В противном случае необходимо пользоваться требуемыми методами модификации данных.
Для представления динамики изменения ИУА в модель [1] требуется внести следующие изменения. Во-первых, вместо ссылок на объекты классов Node и ObjectInstance необходимо использовать интеллектуальные указатели. Во-вторых, нужно ввести служебные классы EnterpriseGenerallnfo и LayerStore,
6
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
которые будут содержать общую информацию о предприятии и набор слоев ИУА. Эти классы необходимы для использования возможностей управления конфигурациями и предназначены исключительно для рациональной группировки данных об ИУА предприятия. Благодаря их использованию доступ к общей информации о предприятии и к перечню информационных слоев, актуальным на указанный момент времени, осуществляется при помощи интеллектуальных указателей. В классе Enterprise необходимо хранить набор дат, когда в ИУА вносились изменения, иначе отслеживать динамику развития будет неудобно и списки конфигураций для сессий будут слишком длинными.
Теперь проанализируем проблемы, которые могут возникнуть при использовании интеллектуальных указателей. Предложенные решения действуют хорошо и не нуждаются в доработках, если не требуется редактировать данные не самых последних снимков. Но это может понадобиться, так как в данных могут содержаться ошибки и неточности. Рассмотрим небольшой пример:
Снимок 1
иерархия 1
иерархия 2
Снимок 2
[N2
иерархия 1
иерархия 2
Рис. 7. Неоднозначность поведения интеллектуальных указателей при изменении данных
не самого последнего снитка
Допустим, и в иерархии 1 и в иерархии 2 требуется добавить для узла N1 еще один дочерний элемент. Сделать это необходимо в снимке 1. После осуществления этой операции в снимке 2 также добавится новый узел в иерархии 1, но не в иерархии 2. С точки зрения реализации такое поведение объясняется достаточно просто, так как для иерархии 2 корневые узлы в различных снимках представлены разными объектами. Но эти различные объекты описывают один и тот же логический объект. Такое неоднозначное поведение системы на концептуальном уровне является недопустимым.
Для решения указанной проблемы при добавлении некоторого дочернего узла нужно добавлять его же и ко всем объектам, которые представляют родительский элемент в последующих снимках. Поскольку для любого объекта устанавливается обратная ссылка на интеллектуальный указатель, получить перечень требующих модификации объектов можно из таблицы конфигураций. При любой модификации данных следует выполнять изменения для объекта текущей конфигурации, который получается автоматически после разыменования интеллектуального указателя, а также для объектов, представляющих этот элемент в последующих конфигурациях. В некоторых случаях обновление данных в последующих конфигурациях может быть более сложным, чем в приведенном примере. Так, при удалении узла дерева приходится обрабатывать последующие версии не только родительского, но и дочернего узлов. Кроме того, необходимо управлять временем жизни объектов. Учитывая эти особенности, соответствующие функции-члены классов значительно усложняются.
Способ обновления данных для значений, хранимых объектами ObjectInstance, несколько отличается. Значения некоторых атрибутов могут
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
7
содержать массивы. При обновлении единственного значения из массива нет возможности изменять в последующих снимках значения с таким же индексом, так как позиция значения может не совпадать. Хранимые значения представляются элементарными типами, поэтому воспользоваться таблицами конфигураций интеллектуальных указателей для определения данных, которые требуют модификации, нет возможности. В таком случае можно осуществлять поиск по старому значению, и если такое найдено, осуществлять его изменение.
Теперь остановимся на сложностях управления временем жизни объектов. Обратимся к примеру, представленному на рис. 7. Допустим, необходимо удалить узел N1 иерархии 2 в снимке 2. В большинстве случаев использования иерархических структур при удалении родительского узла удаляются и все дочерние. Но узлы N2 и N3 удалять нельзя, так как они присутствуют в снимке 1. Узел N4 нужно удалить. Для решения проблемы можно использовать механизм подсчета ссылок. Но и организация подсчета ссылок в таком случае является нетривиальной задачей.
Предположим, есть ряд снимков S-ь S2, ..., SN, а также узел, который в этих снимках не изменялся и имеет n ссылок (n < N). В случае, если этот узел требуется изменить для i-го снимка, то на объект, описывающий его для снимков S-ь ..., Si-1 , будет n-i ссылок, а на объект, описывающий его для снимков S,, ... , SN, будет n2 ссылок. Известно, что Пч+п2 = N, но наиболее простым способом определить n и n2 является перебор всех объектов, которые могут ссылаться на модифицируемый узел. Если считать, что переподчинение узлов невозможно, то определить перечень искомых объектов достаточно просто. Это объекты, описывающие родительский узел в различных конфигурациях. Но необходимо поддерживать переподчинение узлов на концептуальном уровне. Для этого создается копия переподчиняемого поддерева, которое вставляется в необходимую позицию, а исходное поддерево удаляется. При копировании необходимо учитывать все последующие конфигурации.
Такое решение имеет одну особенность. Если было выполнено переподчинение узла в снимке Si, то в случае удаления этого узла в снимке Sk, где k<i, узел будет удален из снимков Sk,...,SM, но не из снимков Si,.,SN. Такое поведение системы можно разъяснить пользователю, и работа программы будет прогнозируемой. Поэтому меры для изменения поведения системы в описанном случае не предпринимались.
В некоторых случаях различные ссылки должны указывать на один и тот же объект. Так происходит, когда некоторый элемент ИУА должен одновременно присутствовать в нескольких слоях. Все такие указатели должны одинаково разыменовываться при различных конфигурациях. Требуемое поведение достигается за счет того, что различные копии интеллектуальных указателей используют одни и те же таблицы конфигураций. Именно такое поведение является наиболее обоснованным. Интеллектуальный указатель в таком случае можно представить в виде объекта-заместителя (proxy).
Рис. 8. Интеллектуальный указатель как объект-заместитель 8 "Управлшня проектами та розвиток виробництва", 2008, № 1(25)
Важно учитывать это свойство интеллектуальных указателей, так как не всегда его можно использовать как простую ссылку. Например, для задания значения атрибута-ссылки (в модели ИУА с динамическим определением типов) используется метод класса Value set_link. Его прототип может выглядеть следующим образом:
void set_link(ObjectInstance* inst, o_u4b index).
Если на основе inst создать ссылку типа Link< ObjectInstance> при помощи конструктора, аргументом которого является обычный указатель, то она не будет использовать механизм интеллектуальных указателей. Если в следующих снимках узел изменить, то он будет представлен другим объектом, а ссылка продолжит указывать на объект, актуальный для предыдущих снимков. Так как объекты класса Node ссылаются на объекты ObjectInstance с использованием интеллектуальных указателей, то при установке значения атрибута-ссылки достаточно создать копию интеллектуального указателя. Соответствующее объявление метода set_link будет примет такой вид:
void set_link(Link<ObjectInstance>& inst, o_u4b index).
Изменять таблицу конфигураций интеллектуального указателя можно только с целью внесения новых версий указываемого объекта. Попытка изменять значения интеллектуального указателя редактированием таблицы конфигураций может привести к трудно локализуемым ошибкам. Предположим, что разрешено непосредственное переподчинение узла, а не только переподчинение копированием. Рассмотрим пример на рис. 9.
а Ь с
Рис. 9. Ошибки, возникающие вследствие некорректного редактирования таблицы конфигураций интеллектуального указателя
Здесь каждый узел содержит ссылку на родительский в виде интеллектуального указателя. На корень иерархии существует ссылка из объекта, описывающего слой ИУА (И). Ссылки из объекта И и N2 используют один и тот же интеллектуальный указатель, так как в случае модификации узла N1 необходимо, чтобы обе ссылки указывали на нужный объект. Узел N2 необходимо переподчинить и сделать дочерним узла N3. Ссылку на родительский объект следует обновить, в результате чего должна получиться ситуация, изображенная на рис. 9 б. Если изменить значение ссылки на родительский объект путем редактирования таблиц конфигураций, то и другие ссылки на этот объект тоже изменятся. На рис. 9 в представлено, как будут выглядеть ссылки в таком случае. Правильным вариантом был бы следующий:
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
9
proxy (собственно таблица конфигураций, см рис. 8) для узла N1 остается без изменений, а ссылка из узла N2 перенаправляется на другой proxy (узла N3).
Остановимся на особенностях создания шаблонов элементов ИУА. В соответствии с [2] шаблон - это «описание части ИУА, содержащее как ее общие характеристики, так и структуру». Для представления шаблонов используются те же классы, что и для структуры предприятия: Node, Layer, ObjectInstance. В отличие от ИУА предприятия шаблон не может иметь снимков. Но перечисленные классы рассчитаны на использование интеллектуальных указателей. Поэтому для шаблонов создается объект со специальным значением даты: год - 0, месяц - 0, день - 0, назовем его null_config. Для шаблонов столбец конфигураций любого интеллектуального указателя содержит только null_config, столбец целевых объектов - единственный объект, на который и ссылается указатель. При создании шаблона требуется осуществлять копирование многослойной структуры с последующим обновлением значений всех атрибутов-ссылок. При таком копировании следует учитывать, что исходная структура и копия должны использовать различные конфигурации. Приведем пример кода:
Link<ObjectInstance> src = /*получить интеллектуальный
указатель на объект-элемент ИУА*/ Link<ObjectInstance> dst = /*получить интеллектуальный
указатель на объект-элемент шаблона*/ dst->set name(src->name()).
Последняя строка не работает, так как для использования интеллектуального указателя src необходим один список конфигураций, а для dst - другой. Корректный код может выглядеть так: Link<ObjectInstance> src = /*получить интеллектуальный
указатель на объект-элемент ИУА*/ Link<ObjectInstance> dst = /*получить интеллектуальный
указатель на объект-элемент шаблона*/ LinkVstrAny src config = /*получить список конфигураций для
текущего снимка ИУА*/ LinkVstrAny dst config = /*получить список конфигураций для
шаблона (содержит только null config)*/ session->set configuration list(src config); PString nm = src->name();
session->set configuration list(dst config); dst->set name(nm).
В приведенном примере каждый интеллектуальный указатель разыменовывается при требуемом списке конфигураций. Необходимость постоянного переключения списков усложняет код и делает его более медленным. Поскольку создание и использование шаблонов не должно выполняться автоматически, а происходит в интерактивном взаимодействии пользователя с системой, то обеспечиваемая производительность является достаточной.
Выводы. В статье впервые предложен физический уровень модели ИУА с динамическим определением типов, способный эффективно представлять информацию о динамике развития ИУА. Выявлены и проанализированы проблемы, специфические для любой БД, обладающей версионностью. Получили дальнейшее развитие методы создания темпоральных баз данных (БД, которые позволяют хранить разновременные портреты архитектур и отслеживать динамику их развития), основанные на использовании интеллектуальных указателей, а именно решена задача инкапсуляции методов
10
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
управления интеллектуальными указателями в базовых классах модели, выявлены и решены проблемы модификации снимков ИУА, которые не являются финальными.
Направлением дальнейших исследований является разработка языка запросов к БД ИУА, учитывающего динамику развития ИУА и содержащего высокоуровневые средства анализа снимков ИУА за различные периоды времени.
ЛИТЕРАТУРА
1. Данич В.Н., Демин М.К., Чернышев Г.Е. Система классов в задаче моделирования информационно-управленческих архитектур // Прац Луганського вщдтення Мiжнародноï академи шформатизаци: Науковий журнал / Пщ ред. д.т.н. В.О. Ульшина. - Луганськ: СНУ iм. В. Даля, 2005. - С. 39-46.
2. Данич В.Н., Дёмин М.К. Концептуальный уровень модели информационно-управленческих архитектур с динамическим определением типов // Вестник ВНУ. -2007. - №4. - С. 30-42.
3. Данич В.Н. Демин М.К., Чернышев Г.Е. Структура объектно-ориентированной базы данных информационно-управленческих архитектур и ее реализация в ООСУБД Jasmine. Економка. Менеджмент. Пщприемництво.- Луганськ: вид-во СНУ iм. В. Даля, 2003.
4. Versant. [Electronic resource] - Access order: http://www.versant.com, free. - Title from screen.
5. Элджер Дж. С++: библиотека программиста. - СПб: Питер, 2000. - 320 с.
Стаття надмшла до редакцп' 03.12.2007 р.
"Управлшня проектами та розвиток виробництва", 2008, № 1(25)
11
