CC BY
21Объектно-ориентированный анализ как средство моделирования параллельных интероперабельных систем с динамически изменяемой конфигурацией
Рожков К.Н. (rozhkov@mail.primorye. ru)
Институт математики и компьютерных наук ДВГУ, г. Владивосток
Введение
В настоящее время в процессе развития науки и техники создаются все более сложные технические и природно-технические системы, состоящие из сотен и тысяч объектов, характеристики которых меняются чрезвычайно быстро. В связи с этим возникает проблема обеспечения их нормального и безопасного функционирования. Существо этой проблемы состоит в том, что для эффективного функционирования таких систем необходимо, с одной стороны, достаточно высокое быстродействие, а с другой - необходимость быстрого реагирования на изменения состояния системы. Практическое значение этой проблемы состоит в существенном снижении затрат на управление, с одновременным увеличением безопасности таких систем для человека и человечества в целом.
Одним из вариантов решения этих проблем являются параллельные интероперабельные системы, сочетающие в себе как высокое быстродействие, так и очень высокую степень независимости от используемых аппаратных средств и операционных систем.
В качестве примеров параллельных интероперабельных систем можно привести проекты «Virtual Engine» компании Pratt & Whitney, США, предназначенный для мониторинга и моделирования основных параметров функционирования авиационных двигателей [14] и проект «РОМАНС» (Распределенная Обрабатывающая Мобильная Архитектура Наземных Средств) Института космических исследований РАН, предназначенный для управления системой космических аппаратов [5].
В проекте «Virtual Engine» для решения задач используется параллельная интероперабельная система, что позволяет существенно увеличить вычислительную мощность и добиться очень высокой степени повторного использования программного обеспечения. Проект «РОМАНС» предоставляет целостную концепцию создания, функционирования и развития наземных средств управления космическими аппаратами.
В статье представлены результаты разработки математической модели параллельной интероперабельной системы с динамически изменяемой конфигурацией, представляющей собой метакомпьютер (сетевой суперкомпьютер [4]).
Разработка произведена методом ориентированного анализа, а результаты ее представлены в виде диаграмм «Сущность-Связь» в нотации Шлеер-Меллора [6].
Архитектура метакомпьютера
Под метакомпьютером принято понимать виртуальный компьютер, динамически создающийся из территориально распределенных ресурсов, соединенных высокоскоростными сетями передачи данных.
В [4] приводится следующая классификация метакомпьютеров:
1. Настольный суперкомпьютер, представляющий собой рабочую станцию, позволяющую выполнять свои задачи на удаленных компьютерах большой мощности. При этом поиск свободных ресурсов и управление ими происходит автоматически.
2. Интеллектуальный инструментальный комплекс, под которым понимается система, позволяющая в реальном времени собирать большие объемы данных, поступающие с датчиков, производить анализ текущей ситуации, вырабатывать решения и выдавать управляющие воздействия.
3. Сетевой суперкомпьютер, представляющий собой прозрачное бесшовное объединение через локальную сеть отдельных вычислительных установок разной мощности и архитектуры. Составляющими элементами такой конструкции могут быть суперкомпьютеры, серверы, рабочие станции и персональные компьютеры.
Программные и аппаратные средства
Для организации процесса функционирования системы необходимо решить задачи объединения станций локальной сети в единое вычислительное устройство; управления всей системой и отдельными ее компонентами, состоящими из «процессорных элементов»; взаимодействия с пользователями (потребителями информации).
Из особенностей предметной области вытекает, что в качестве «управляющих» и «процессорных» элементов могут выступать компьютеры различной аппаратной архитектуры, оснащенные различными операционными системами. Объединение таких разнородных вычислительных средств в единую систему возможно произвести на основе технологии CORBA.
Объединение «процессорных элементов» в единую систему можно произвести на основе программных систем PVM / DVM, а для решения задач, требующих очень большой вычислительной мощности (например, визуализации процесса функционирования) использовать Linux-кластеры на основе стандарта MPI или компьютеры семейства МВС (МВС-100 или МВС-1000).
Возможная архитектура такой системы представлена на рис. 1 . С точки зрения технологии CORBA, система представляет собой совокупность CORBA-объектов, у которых некоторые методы выполняются на обыкновенной вычислительной системе, а некоторые - на параллельной.
С точки зрения технологии PVM / DVM, предлагаемая система представляет собой вычислительную систему с динамически изменяемой конфигурацией, т.е., другими словами, набор "процессорных элементов", из которых создается вычислительное устройство требуемой конфигурации.
С точки зрения технологии MPI, система может представлять собой конструкцию, предназначенную для визуализации трехмерных изображений, исходные данные для работы которой поступают параллельно по нескольким каналам.
Кроме того, такая система должна иметь возможность динамического изменения конфигурации в зависимости от различных условий.
Сеть рабочий станций РУМ / РЧ^М
Рис.1 Архитектура метакомпьютера Математическая модель
Для построения формальной модели с точки зрения объектно-ориентированного анализа необходимо разработать: [1, 2, 9, 12]
• Информационную модель - с целью абстрагирования концептуальных сущностей в терминах абстракций и атрибутов;
• Модель состояний - с целью выявления поведения наиболее важных абстракций и связей во времени.
• Модель процессов - с целью расчленения наиболее важных действий на фундаментальные процессы.
Введем аксиоматические определения:
Под объектом будем понимать конкретный опознаваемый предмет, единицу или сущность (реальную или абстрактную), имеющую четко определенное функциональное назначение в данной предметной области. [3, 9]
Под абстракцией (сущностью) будем понимать существенные характеристики объекта, которые отличают его от всех других объектов и четко определяют его концептуальные границы для наблюдателя. [1]
Под атрибутом будем понимать абстракцию одной характеристики, которой обладают все абстрагированные как объект сущности. [6]
Для атрибутов устанавливаются следующие правила:
1. Один экземпляр объекта имеет одно единственное значение для каждого атрибута в любое данное время.
2. Атрибут не должен содержать никакой внутренней структуры.
3. Когда объект имеет составной идентификатор, т.е. состоящий из двух или более атрибутов, каждый атрибут, не являющийся частью идентификатора, представляет характеристику всего объекта, а не его части, а тем более не характеристику чего-либо другого.
4. Каждый атрибут, не являющийся частью идентификатора, представляет характеристику экземпляра, указанного идентификатором, а не характеристику некоторого другого атрибута-идентификатора.
Под связью будем понимать абстракцию наборов отношений, которые систематически возникают между различными абстракциями предметной области. [6] Связь обладает следующими атрибутами:
1. Идентификатор.
2. Имена связи со стороны каждой из участвующих абстракций.
3. Размерность.
Под состоянием будем понимать положение объекта, в котором применяется определенный набор правил, линий поведения, предписаний и физических законов. [9]
Под жизненным циклом будем понимать регулярную составную часть динамического поведения абстракции, которая обеспечивает формализованное описание модели поведения. [7]
Под событием будем понимать абстракцию инцидента или сигнала в реальном мире, который сообщает о перемещении какой-либо абстракции в новое состояние. [7]
Под действием будем понимать деятельность или операцию, которая должна быть выполнена абстракцией, когда она достигает состояния. [11]
Информационная модель
Для описания информационной модели необходимо разработать:
1. Диаграмму информационной структуры - графическое представление информационной модели в форме диаграммы «Сущность - Связь». [8]
2. Описание связей: перечень каждой связи модели вместе с описанием связи.
3. Описание атрибутов: список всех абстракций и их атрибутов в модели.
4. Модель взаимодействия абстракций - графическое представление взаимодействия абстракций при выполнении наиболее важных действий в форме диаграммы «Сущность - Связь».
Основные абстракции
Введем основные абстракции. Под Узлом будем понимать совокупность необходимого программного обеспечения на компьютере, функционирующем в локальной вычислительной сети. Под Файлом будем понимать именованную совокупность данных. Под Базой данных будем понимать совокупность файлов некоторой структуры. Под Данными узла будем понимать совокупность всех баз данных, расположенных в данном узле.
Под Процессом будем понимать реализацию алгоритмов, обеспечивающих обработку конкретной базы данных на узле.
Под Прикладным процессом будем понимать реализацию алгоритма, непосредственно выполняющего обработку конкретной базы данных на узле в интересах решения задачи.
Под Задачей будем понимать совокупность процессов обработки данных с целью получения требуемого результата и механизм управления ими. Под Блоком управления задачами будем понимать абстракцию, описывающую совокупность задач, порядок взаимодействия между Задачами с точки зрения тиражирования и реализующую управление ими.
Под Доменом будем понимать абстракцию динамически изменяющейся совокупности узлов, принимающих участие в решении данной задачи, и реализующую алгоритм управления ими.
Под Системой будем понимать абстракцию совокупности доменов, решающих различные задачи, и механизмов управления.
Под Блоком управления резервированием будем понимать абстракцию, реализующую формирование таблицы резервирования исходя из некоторых критериев для назначения стратегии резервирования, списка объектов и субъектов резервирования.
Под Блоком управления тиражированием будем понимать абстракцию, реализующую формирование таблицы тиражирования исходя из некоторых критериев для назначения стратегии тиражирования, списка объектов и субъектов тиражирования.
Под Блоком управления восстановлением будем понимать абстракцию, реализующую формирование таблицы восстановления исходя из имеющихся таблиц резервирования и тиражирования, ее анализ и выбор оптимальных (в смысле определенных критериев) субъектов восстановления.
Под Таблицей резервирования будем понимать структуру, содержащую информацию для объекта резервирования о субъектах резервирования, временных интервалах и стратегиях резервирования.
Под Таблицей тиражирования будем понимать структуру, содержащую информацию для объекта тиражирования о субъектах тиражирования, временных интервалах и стратегиях тиражирования.
Под Таблицей восстановления будем понимать структуру, содержащую информацию для объекта восстановления о субъектах восстановления. Под Механизмом тиражирования будем понимать совокупность алгоритмов, реализующих стратегии тиражирования с использованием данных из таблиц тиражирования.
Под Механизмом резервирования будем понимать совокупность алгоритмов, реализующих стратегии резервирования с использованием данных из таблиц резервирования.
Под Механизмом восстановления будем понимать алгоритм, реализующий восстановление с использованием данных из таблицы восстановления. Под Монитором прикладного процесса будем понимать абстракцию, реализующую назначение состояний Прикладному процессу, обрабатывающему Базу данных.
Под Монитором резервирования будем понимать абстракцию, реализующую назначение состояний механизму резервирования.
Под Монитором тиражирования будем понимать абстракцию, реализующую назначение состояний механизму тиражирования.
Под Монитором процесса будем понимать абстракцию, реализующую назначение состояний процессу и, при необходимости, вызов механизма восстановления.
Под Монитором узла будем понимать абстракцию, реализующую опрос монитора резервирования и назначение состояний узлу, данным узла и, при необходимости, вызов механизма восстановления.
Под Монитором домена будем понимать абстракцию, реализующую опрос мониторов состояния узлов и назначение состояний узлу и домену. Под Монитором задачи будем понимать абстракцию, реализующую опрос монитора состояния процессов и назначение состояний задаче. Под Журналом будем понимать абстракцию, реализующую хранение информации о ходе резервирования.
Соотношения между некоторыми понятиями представлены на рис. 1.
Рис. 1. Соотношения между некоторыми понятиями
Описание типов связей
1. Связь типа «Часть - Целое»
Связь типа «Часть - Целое» определяет отношение между двумя абстракциями, при котором одна абстракция является частью другой.
2. Связь типа «Использует - Используется»
Связь типа «Использует - Используется» определяет отношение между двумя абстракциями, при котором одна абстракция использует другую в своем жизненном цикле.
3. Связь типа «Опрос - Ответ»
Связь типа «Опрос - Ответ» определяет отношение между двумя абстракциями, при котором одна абстракция производит опрос состояния другой абстракции, а та, в свою очередь сообщает свое состояние опрашивающей абстракции.
4. Связь типа «Запуск»
Связь типа «Запуск» определяет отношение между двумя абстракциями, при котором одна абстракция инициирует жизненный цикл другой.
5. Связь типа «Поддерживает - Поддерживается»
Связь типа «Поддерживает - Поддерживается» определяет отношение между двумя абстракциями, при котором одна абстракция обеспечивает установку и изменение значений атрибутов другой абстракции с точки зрения некоторого критерия.
6. Связь типа «Является»
Связь типа «Является» определяет отношение между двумя абстракциями, при котором одна абстракция помимо своих атрибутов, которые обеспечива-
ют ее специализацию по отношению к другой, содержит в себе все атрибуты другой абстракции и имеет такой же жизненный цикл.
7. Связь типа «Уведомляет»
Связь типа «Уведомляет» определяет отношение между двумя абстракциями, при котором одна абстракция сообщает другой значение атрибута своего состояния.
8. Связь типа «Управляет - Уведомляет»
Связь типа «Управляет - Уведомляет» определяет отношение между двумя абстракциями, при котором одна абстракция управляет другой, а другая уведомляет ее об изменении значения какого-либо из своих атрибутов.
Описание связей между основными абстракциями
В Таблице 1 представлено описание связей между абстракциями.
Таблица 1
_Описание связей между абстракциями_
№ Абстракции Идентификатор Атрибуты Тип Раз-
мер
1 2 3 4 5 6
1 Система - Блок управления задачами т «Идентификатор системы. Идентификатор блока управления задачами» «Использует - Используется» 1:1
(остальные связи описываются аналогично)
69. Механизм резервирования -Журнал Р69 «Идентификатор механизма резервирования.Идентификатор журнала» «Использует - Используется» 1:1
Диаграмма информационной структуры
В результате выполнения действий, описанных выше, может быть создана диаграмма информационной структуры, которая представлена на рис. 3.
Электронный журнал «ИССЛЕДОВАНО В РОССИИ» 73 8
Шр ://гЬигпа1. аре .ге1агп .ги/агйс1е!з/2002/068. pdf
Использует Управляет
Управляет
Уведомляет
1
Уведомляет
яГ,
Блок управления
Резервированием
^ Уведомляет
Я17
Восстановлением
Уведомляет
Я8
Уведомляет 'Йспользуётся~
Тиражированием
Е
Поддерживает Поддерживается
Поддщерживаетщ 9 Поддще^живаетсд
Поддерживает И14 Поддерживается
П о дд^ерживает^ Поддерживается^
Поддерживает Я20 Поддерживается
Используется
Управляет „
Резервирования
_, Используется 2 Используется] И11I,
Используется
Восстановления
Тиражирования
Уведомляет
Блок управления задачами
Целое^
Таблицы
Используется
Управляет
Опрос^ Уведомляет^
Задачи
Уведомляет Уведомляет
Используется | |
Й22 ¡Тспо,
Процесса
Прикладного процесса
/?29
Запуск ] /?32
, ОП£0£- - -Уведомляет
Тиражирования
I—.
Опрос Я45
Резервирования
Домена
Уведомляет
рлро_с___ Я47
^Опрос Уведомляет ~
К 52 Уведомляет
Узла 2
Ответ
ШШ
Опрос |
Я55А Уведомляет
И53
Уведомляет
_.— —
Ответ
Прикладной процесс А ~
-Г
11-
уведомляет | |
ИЗО
__Я49
Механизм тиражирования ж I ~
Испмьзует \ Уведомля
Механизм восстановления
Использует
Уведомля
Уведомляет ------Ответу-
^ Использует^ Использу^г
Л
ИспользуетАИспользует
Использует
Запуск
Журнал
—— дтвет
Использует ^ —'
Используется Уведомляет Р156
Механизм резервирования
Использует^
I /?59
/?5§1
—Ь
I
Используется
тт -А-J
Целое
Используется
Уведом
[Использует А I Использует
> I I
I I I I
ТТ
4
Задача
Целое4
Управляет
I—
|ябЗ
I
11
И641 |Я65
Процесс
Испбльзует ^
Целое4 Я63 | Часть+
Используется^
База данных
Целое А
Я68 I
Часть^
Рис. 3. Диаграмма информационной структуры
Атрибуты основных абстракций
В Таблице 2 представлены атрибуты основных абстракций.
Таблица 2
_Атрибуты основных абстракций_
№ Абстракция Атрибуты
1 2 3
1. Узел 1. Идентификатор. 2. Режим функционирования: стационарный или переходный. 3. Состояние узла. 4. Идентификатор монитора узла (Р55). 5. Идентификатор механизма резервирования (Р56). 6. Идентификатор механизма восстановления (Р57). 7. Идентификатор процесса (Р60). 8. Идентификатор монитора резервирования (Р48). 9. Идентификатор блока управления резервированием (Р9). 10. Идентификатор блока управления восстановлением (Р17). 11. Идентификатор данных узла (Р61).
(атрибуты остальных абстракций описываются аналогично)
27. Журнал 1. Идентификатор.
Модель состояний
Жизненный цикл абстракций формализуется через модель состояний (в модифицированной нотации Мура [12]). Модель состояний Мура состоит:
1. из множества состояний. Каждое состояние представляет стадию в жизненном цикле абстракции.
2. из множества событий. Каждое событие представляет инцидент или указание на то, что происходит эволюционирование.
3. из переходов (правил перехода). Правило перехода определяет, какое новое состояние достигается, когда с абстракцией в данном состоянии происходит некоторое событие.
4. из действий. Действие - это деятельность или операция, которые должны быть выполнены, когда экземпляр достигает состояния.
Для описания модели состояний необходимо разработать:
1. Описания состояний.
2. Диаграммы переходов в состояния.
Примечание: нотация Мура предписывает выполнение только одного действия при достижении каждого состояния, однако это приводит к сильному увеличению объема материала и ухудшает восприятие смысла. Поэтому, с целью увеличения логичности изложения и сокращения объема, допускается выполнение более чем одного действия в каждом состоянии. Действия пронумерованы с целью сохранения порядка их выполнения при достижении состояния.
Пример: Модель состояний Узла
Узел может находиться в следующих состояниях: 1. «Подготовка» - это такое состояние Узла, при котором происходит формирование данных, необходимых для работы Процесса и запуск Процесса.
2. «Работа» - рабочее состояние Узла. Это такое состояние Узла, при котором на Узле активен хотя бы один Процесс.
3. «Сбой» - это такое состояние Узла, при котором на Узле не может работать ни один Процесс.
4. «Возвращение» - это состояние соответствует восстановлению Узла после сбоя (возвращение в состояние «Работа» с использованием работоспособных копий Данных узла и/или предысторий оперативного резерва).
5. «Отказ» - это такое состояние Узла, при котором обмен информацией с Узлом становится невозможен (например, физическое разрушение узла или потеря с ним связи).
6. «Ожидание» - это состояние соответствует наличию на Узле работоспособных данных и их резерва в промежутке между работой различных Процессов.
7. «Окончание работы» - это такое состояние Узла, при котором происходит завершение работы Процесса.
Все состояния, кроме специально оговоренных, назначаются узлу Монитором узла.
Диаграмма перехода в состояния для узла представлена на рис. 4.
Назначение состояния «Ожидание» Системой
-1. Запустить Процесс -2. Получить идентификатор Базы данных от Процесса -3. Запустить Блок управления резервированием для Базы данных
-4. Запустить Блок управления восстановлением для Базы данных
Возвращение
Завершить Механизм резервирования. Завершить Монитор резервирования
Завершить Блок управления резервированием для Базы данных Завершить Блок управления восстановлением для Базы данных
Завершить Монитор резервирования
Завершить Механизм резервирования
—1. Запросить Журнал резервирования Данных узла и получить его. 2. Завершить Механизм резервирования Данных узла Передать Журнал Домену. Сформировать критерий восстановления и передать его и Журнал Блоку управления восстановлением. Уведомить Монитор узла о получении идентификатора Таблицы восстановления для Данных узла
3.
4.
1—5.
1 . Передать Механизму восстановления для Данных узла идентификатор Таблицы восстановления. 2. Ждать завершения работы Механизма восстановления
Назначение состояния «Работа» Монитором домена
Отказ
. Передать Блоку управления резервированием для Базы данных:
• Идентификатор узла;
• Идентификатор Базы данных;
• Режим функционирования Узла;
• Данные для работы стратегий резервирования . Выдать команду на формирование таблицы
резервирования для Базы данных . Передать Процессу идентификатор Таблицы
резервирования Базы данных. . Передать Процессу идентификатор Таблицы
тиражирования. . Передать Процессу идентификатор Таблицы
восстановления для Базы данных. . Запустить Механизм резервирования для Данных узла
. Передать Механизму резервирования для Данных узла идентификатор Данных узла и идентификатор Таблицы резервирования . Запустить Монитор резервирования для Данных узла
. Передать Блоку управления восстановлением для Базы данных:
• Критерий для восстановления
• Журнал резервирования для Базы данных
1
1
Рис. 4. Диаграмма перехода в состояния для Узла
Модель взаимодействия абстракций
Модель взаимодействия абстракций обеспечивает краткое графическое изложение событий взаимодействия между моделями состояний и внешними сущностями, такими как операторы, физические устройства и абстракции в других подсистемах.
В данном разделе будут рассмотрены модели взаимодействия между различными абстракциями при выполнении действий, имеющих непосредственное отношение к резервированию, тиражированию и восстановлению данных.
Пример: Взаимодействие абстракций при формировании Таблицы резервирования
Формирование Таблицы резервирования для Базы данных происходит следующим образом:
1. Администратор определяет:
• Критерий для резервирования Базы данных;
• Идентификатор приемника для резервирования Базы данных; формирует:
• параметры, необходимые для работы стратегий резервирования Базы данных;
и передает их в Систему.
2. Система в состоянии «Реконфигурация» формирует и передает в Блок управления резервированием Базы данных на Узле:
• Параметры, необходимые для работы стратегий резервирования Базы данных;
• Идентификатор приемника для резервирования Базы данных;
3. Система переходит в состояние «Работа» и производит запуск Задачи (через Блок управления задачами), передавая ей критерий резервирования.
4. Задача в состоянии «Запуск» передает Домену критерий для резервирования.
5. Домен в состоянии «Запуск» производит запуск своих Процессов, передавая им критерий для резервирования.
6. Процесс в состоянии «Запуск» передает Узлу идентификатор Базы данных и критерий для ее резервирования.
7. Узел в состоянии «Подготовка» получает идентификатор Базы данных и критерий для ее резервирования от процесса.
8. Узел в состоянии «Работа» передает в Блок управления резервированием Базы данных:
• Идентификатор источника;
• Идентификатор Базы данных;
• Режим своего функционирования;
• Критерий для резервирования Базы данных.
9. Узел в состоянии «Работа» выдает команду Блоку управления резервированием для Базы данных команду на формирование таблицы резервирования.
Взаимодействие абстракций при формировании Таблицы резервирования представлено на рис. 5.
Рис. 5. Взаимодействие абстракций при формировании Таблицы резервирования
Модель процессов
Все процессы, происходящие в системе, устанавливаются в действиях. В этом разделе будут рассмотрены процессы, составляющие действия, необходимые для выполнения резервирования, тиражирования и восстановления.
Необходимо расчленить указанные действия на фундаментальные процессы, которые, взятые вместе, определяют требуемую функциональность.
Модели процессов представляются в виде диаграмм потоков данных действий, которые обеспечивают графическое представление модулей процесса в пределах действия и взаимодействие между ними.
Пример: Модель процессов при формировании Таблицы резервирования
Блоком управления резервированием
Формирование таблицы резервирования Базы данных Блоком управления
резервированием происходит следующим образом:
1. Формируется идентификатор источника из идентификатора узла и пути к источнику.
2. Формируется идентификатор получателя из идентификатора узла и пути к приемнику.
3. Осуществляется выбор стратегии резервирования с использованием критерия резервирования, режима функционирования Узла и параметров стратегии.
4. Формируются параметры стратегии исходя из выбранной стратегии и внешних параметров.
5. В Таблицу включается идентификатор Базы данных.
В результате формируется таблица следующего вида:
Идентификатор источни- Идентификатор получа- Идентификатор Ба- Стратегия Параметры
ка данных теля данных зы данных стратегии
«\\Идентификатор Уз-ла\Путь к источнику» «\\Идентификатор Уз-лаПуть к приемнику» Идентификатор Базы данных 1 - 3 Периодичность и др.
Диаграмма потоков данных действий представлена на рис. 6.
Рис. 6. Диаграмма потоков данных действий при формировании Таблицы резервирования для Базы данных
Заключение
В этой статье методом объектно-ориентированного анализа была построена математическая модель параллельной интероперабельной системы с динамически изменяемой конфигурацией. Для выполнения этой задачи были разработаны определения основных абстракций, построена информационная модель, модель взаимодействия абстракций, модель состояний и модель процессов, что, взятое в целом, определило требуемую функциональность.
Литература
1. Буч Г. Объектно-ориентированный анализ и проектирование: с примерами приложений на C++. - СПб.: Издательство Бином, 1998. - 560 с., ил.
2. Громов А., Каменнова М. Особенности реализации больших проектов // Computerworld. - 1996. - №22. - С. 33 - 36.
3. Долгов П. и др. Объектно-ориентированное расширение технологии RTST / Долгов П. Иванов А., Кознов Д., и др. // Записки семинара кафедры системного программирования "CASE-средства RTST++". Вып. 1. - СПб.: Издательство С.-Петербургского университета, 1998. - С. 17-36.
4. Коваленко В., Корягин Д. Вычислительная инфраструктура будущего // Открытые системы. - 1999. - № 11-12. - С. 45 - 52.
5. Концепция построения информационных систем перспективных научных космических проектов [электронный ресурс]. - Доступно из URL: http://hipo.iki.rssi.ru/rusrom/concept.html [Дата обращения: 12.02.2002]
6. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. - Киев: Диалектика, 1993. - 150 с.
7. Berzins V., Gray M. Naumann, D. Abstraction-Based Software Development / Berzins V., Gray M. Naumann, D. // Communications of the ACM. - 1986. -vol.29(5) May. - P. 34-40.
8. Barker R. CASE Method. Entity-Relationship Modeling. / Barker R. - Oracle Corporation UK Limited: Addison-Wesley Publishing Co., 1990. - 231 p.
9. Booch G. The Visual Modeling of Software Architecture for the Enterprise // Rose Architect. - 1998. - Vol. 1. - No 1. - P. 18-25
10. Darwin С. The Origin of Species // Great Books of the Western World. - Vol.49. -Chicago, IL: Encyclopedia Britannica. - 1984. - P.207.
11. Graham J,. Object-Oriented Methods. - Workingham, England: Addison-Wesley Publishing Company, 1991. - 432 p.
12. Moore E.F. Gedanken-experiments on Sequential Machines. - In Automata Studies, Princeton, N.J.: Princeton University Press, 1956. - 237 p.
13. Rumbaugh J., Blacha M. Premerlani W. Lorensen Eddy F. Object-Oriented Modeling and Design / Rumbaugh J., Blacha M. Premerlani W. - New York: Prentice-Hall, Inc., 1991. - 170 p.
14.Virtual Engine project. - [электронный ресурс]. - Доступно из URL: http://www.corba.org/industries/aerodef/pSw.html [Дата обращения: 17.01.2002].
