Для того, чтобы содержимое Колекции отображалось в Списке, соединим атрибуты 'items'
Списка и 'self' Коллекции. С кнопкой "Remove" поступим аналогично кнопке "Add", только
вызываемым действием Коллекции будет теперь 'remove', а его параметром - атрибут 'selected
item' Списка.


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


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

Если в предыдущем примере список сотрудников необходимо хранить в какой-либо базе
данных, задача несколько усложнится, но подход к созданию приложения не изменится. Мы
только возьмем другую деталь вместо 'Упорядоченной коллекции' - 'Запрос к базе данных'. Она
обладает более широким набором свойств, среди которых нас больше всего интересует
действие 'выполнить запрос' ('executeQuery') и атрибут 'результирующая таблица' ('resultTable').
Действие выполняет заданное SQL выражение, а деталь 'результирующая таблица' позволяет
работать с полученным результатом. Внешне программа изменилась не существенно


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

[]
[]
[]

Критерии выбора корпоративных инструментов в применении к Borland Delphi

Говоря об инструментах, ориентированных на создание систем корпоративных масштабов, мы
должны абсолютно четко представлять предъявляемые к ним требования. Попытаемся
сформулировать некоторые из них.

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

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

"Единство противоположностей": Нейтральность по отношению к используемым форматам
БД + поддержка специфики конкретных способов хранения/доступа к данным
Универсальный механизм доступа к данным.

Требования к производительности
Компиляция, в случае платформо-зависимых решений.

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

Рассмотрим, насколько Delphi удовлетворяет выше перечисленным требованиям.

Delphi использует язык 3-го поколения Object Pascal, обладающий полной реализаций
основных признаков объектной ориентации (инкапсуляция, наследование, полиморфизм),
поддержкой RTTI-RunTime Type Information и встроенной обработкой исключительных ситуаций
(Exception handling).
Компонентная архитектура Delphi является прямым развитием
поддерживаемой объектной модели. Все компоненты являются объектными типами (классами), с
возможностью неограниченного наследования. Компоненты Delphi поддерживают PME-модель
(Property, Method, Events), позволяющую изменять поведение компонентов без необходимости
создания новых классов.

Delphi 2 Client/Server Suite включает систему контроля версий Intersolv PVCS, поддерживает
работу со словарем данных (Data Dictionary) и Репозитарием объектов (Object Repository). Среда
визуальной разработки Delphi позволяет единообразно работать как с предопределенными, так и с
пользовательскими компонентами, которые разрабатываются на том же языке (Object Pascal), на
котором создаются и конечные приложения.

Borland Database Engine (BDE) обеспечивает единообразную работу с локальными данными
(Paradox, dBase) и серверами БД (Oracle, Sybase, MS SQL Server, InterBase и т.д.), за счет
применения навигационных методов доступа к серверным СУБД (двунаправленные курсоры,
закладки и т.п.) и SQL - к локальным форматам (подмножество Local SQL).


Borland Database Engine
Компилятор Delphi является самым быстрым; имеет общий генератор кода с Borland C++
(Delphi 2 & BC++ 5). Компилятор Delphi (точнее, Object Pascal) является продолжением линии
компиляторов Turbo Pascal / Borland Pascal.
Открытые интерфейсы Delphi - Open Tools API - обеспечивают контроль над средой
разработки "из вне" и доступ к информации о проекте.
Delphi 2.01 Client/Server Suite включает CASE Expert, позволяющий
импортировать данные из ведущих CASE в словарь данных Delphi,
интегрировать IDE (Integrated Development Environment) с генераторами кода
(например, Silver Run RDM компании CSA, WithClass 3.0 и т.п.).
"Эксперты" (программные модули, встраиваемые в IDE) позволяют
использовать Delphi как "скелет" - общую среду разработки - для всего
комплекса используемых инструментов.
Delphi 2 включает "генератор дистрибутивов" Install Shield Express.


Интерфейсы - структура

Литература

The Design and Evolution of C++, B. Stroustrup, Addison-Wesley, 1994. 462 pages.
The C++ Programming Language, Second Edition, Bjarne Stroustrup, 1991, 646 pages.
The Annotated C++ Reference Manual, Margaret A. Ellis and Bjarne Stroustrup, 1990, 453 pages.
(Русский перевод М. Эллис, Б. Строуструп. Справочное руководство по языку программирования
С++ с комментариями. М.: Мир. 1992)
P.J. Plauger, The Draft Standard C++ Library; Prentice-Hall, 1995.
X3J16/96-0018; WG21/N0836, Working Paper for Draft Proposed International Standard for
Information Systems-- Programming Language C++.
Е Зуев, А Кротов "Новые возможности языка Си++", PC Magazine/Russian Edition, #7, 1994.
R. Martin "Why C++", http://www.oma.com
The C Programming Language, Second Edition, B.Kernighan, D. Ritchie, Prentice Hall, 1988.
(Русский перевод Керниган, Ричи "Язык программирования Си", М.: Финансы и Статистика,
1992).
Гради Буч. Объектно-ориентированное проектирование с примерами применения: Пер. С
англ.- М.: Конкорд, 1992- 519 с.
R. Martin "Designing Object-Oriented C++ Applications using the Booch Method", Prentice Hall,
1995.
Bjarne Stroustrup "New Casts Revisited", ANSI Doc X3J16/93-142.

Александр Кротов <>

Евгений Зуев <>

Владимир Сухомлин <>



[]
[]
[]


Krukov V.A., Petrenko A.K., Trunov Yu.V., Fedorov K.B. GRAPHIT-graphic in tegrated
environment for real-time system development.- Тезисы межд. конференции "Real-Time Data - RTD-
94", Дубна, июнь 1994.
Крюков В.А., Максимов А.В., Петренко А.К., Полилова Т.А. Иерархическое
конфигурационное управление.- Программирование, 2,1994.
The RAISE Language Group. The RAISE Specification Language.- Prentice Hall, 1992.

[]
[]
[]





Potchukajev V., Tomilin A., Aljoshin V., Aphanasjev V. Global telecommunications in virtual
environments provided by space orbiter systems for communication, navigation, location and
observation. Proceedings of East-West International Conference "MHVR-94", Международный центр
научной и технической информации, Москва, 1994.
В.И.Алешин, В.О.Афанасьев, Р.М.Галис, Ю.М.Баяковский, А.Н.Томилин, Виртуальная
реальность. Проблемы освоения новой технологии. - Программные продукты и системы, N 4,
Главная редакция международного журнала "Проблемы теории и практики управления",
МНИИПУ, Тверь, 1994.
Сборник "Вопросы Кибернетики. Моделирование сложных систем и виртуальная реальность",
N 181, РАН, Научный совет по комплексной проблеме "Кибернетика", Москва, 1995.
С.Клименко, В.Уразметов, INTERNET. Среда обитания информационного сообщества. -
РЦФТИ: Протвино, 1995.

[]
[]
[]





Working Paper for Draft Proposed International Standard for Information
Systems - Programming Language C++. WG21/N0836, Doc No: X3J16/96-0018, 26
January 1996.
Alexander Stepanov, Meng Lee. The Standard Template Library. Doc No:
X3J16/94-0030R1.
Musser D.R, Saini A. "C++ Programming with the Standard Template Library.
STL Tututorial and Reference Guide" New York: Addis-Westley Publ. 1996.
D.R. Musser, A.A.Stepanov. "Algorithm-oriented Generic Libraries" Software
Practice and Experience, Vol. 24(7), July 1994
D.McIlroy. "Mass-Produced Software Components", Petrocelli/Charter, 1976
Майерс. "Надежность программного обеспечения", Москва, 1980
Майерс. "Искусство тестирования программ", Москва, 1982
С.И.Рыбин, В.Ш.Кауфман. Методы и средства контроля языковых
стандартов.- в сб. "Системная информатика", вып.3.- ВО "Наука", Новосибирск,
1993 г.

Владимир Сухомлин <>

Евгений Зуев <>

Александр Кротов <>

Денис Давыдов <>

Николай Недиков <>


[]
[]
[]

Магнитные диски

Время обслуживания

время доступа (2-10 мс)
время ожидания (4-8 мс)
время передачи (1-4 Мбайт/с)

Время доступа в подсистеме SCSI (основной компьютер,
главный адаптер SCSI, контроллер НМД, собственно НМД):

Пересылка команд SCSI в главный адаптер
Фаза выбора устройства (главный адаптер)
Фаза команды
Фаза разъединения
Фаза повторного соединения
Фаза данных
Фаза состояния
Фаза разъединения

Основные характеристики НМД:

Емкость - до 9.1 Гбайт

Среднее время доступа - 8 мс

Скорость вращения - до 7200 оборот/мин

Время наработки на отказ - 1000000 часов
Основные характеристики магнитооптических дисков:

Емкость - до 1.3 Гбайт

Среднее время доступа - 19 мс

Среднее время наработки на отказ - 80000 часов

Механизмы межпроцессных взаимодействий в операционной системе Unix

, учебные материалы конференции ,










Традиционный подход ОС UNIX
- реакция на сложности Multics
Возникшие проблемы
Избыточный набор системных средств, предназначенных для обеспечения
возможности взаимодействия и синхронизации процессов, которые
не обязательно связаны отношением родства

IPC - Inter-Process Communication Facilities
с появлением UNIX System V Release 4.0 все эти средства были
узаконены и вошли в фактический стандарт ОС UNIX современного
образца
в разных вариантах системы средства IPC реализуются по-разному
эффективность реализации различается
усложняется разработка мобильных асинхронных программных комплексов

Пакет средств IPC

UNIX System V Release 3.0
средства, обеспечивающие возможность наличия общей памяти
между процессами (сегменты разделяемой памяти - shared memory
segments)
средства, обеспечивающие возможность синхронизации процессов
при доступе с совместно используемым ресурсам, например, к разделяемой
памяти (семафоры - semaphores)
средства, обеспечивающие возможность посылки процессом сообщений
другому произвольному процессу (очереди сообщений - message
queues)

Общие свойства всех трех механизмов:

для каждого механизма поддерживается общесистемная
таблица, элементы которой описывают всех существующих в данный
момент представителей механизма (конкретные сегменты, семафоры
или очереди сообщений)
элемент таблицы содержит некоторый числовой ключ, который
является выбранным пользователем именем представителя соответствующего
механизма
процесс, желающий начать пользоваться одним из механизмов,
обращается к системе с системным вызовом из семейства "get",
ответным параметром является числовой дескриптор
ключ IPC_PRIVATE
ключ IPC_CREAT
защита доступа основывается на тех же принципах, что и защита
доступа к файлам

Microsoft Exchange

Хранение и совместное использование информации
Передача сообщений
Групповое планирование
Дизайн электронных форм
Разработка приложений

Microsoft SQL Server 6.5 отвечает требованиям крупных заказчиков

Масштабируемая система с высокой производительностью
Создан для работы в распределенных средах
Прост в инсталляции и развертывании
Построен на открытой платформе
Относительно низкая цена
Является частью интегрированной системы приложений Клиент -Сервер

Множественные прикладные среды Windows NT

Виктор Олифер,









Защищенные подсистемы взаимодействуют путем передачи
сообщений, используя механизм LPC

LPC - Local Procedure Call - вызов локальных процедур

Цели подсистем окружения:

Обеспечить несколько программных интерфейсов
Экранировать базовую ОС от изменений API
Объединить общие для всех API глобальные данные, уменьшая
избыточность
Обеспечить возможность включения новых API
Защита окружений от приложений




Множественные прикладные среды обеспечивают совместимость на ДВОИЧНОМ уровне

Цели:

возможность выполнять программы, написанные для
других ОС и процессоров
встроенность средств обеспечения совместимости
в ОС
приемлемая скорость выполнения приложений


Примеры ОС, содержащих встроенные средства
обеспечения множественных прикладных сред:

OS/2 2.x
Workplace OS
Windows NT
PowerOpen
некоторые версии UNIX





Пример различия в системных вызовах:

fork() Наследует адресное пространство родителя Имеет одну нить При завершении потомка нужно послать сигнал родителю

DosExecPgm() Адресное пространство создается заново на основе файла prog.exe Имеет несколько нитей При завершении потомка созданного с опцией EXEC_SYNC идентификатор процесса нельзя повторно использовать

Цели разработки микроядра Mach

Обеспечение базовых функций для создания других
операционных систем (например, UNIX)
Поддержка больших разряженных адресных пространств
Обеспечение прозрачного доступа к сетевым ресурсам
Поддержка параллелизма как в системе, так и в
приложениях
Обеспечение переносимости Mach на различные типы
компьютеров

Абстрактная модель эмуляции UNIX на основе
Mach



Функции микроядра Mach:

управление процессами,
управление памятью,
коммуникации
функции ввода-вывода


Функции управления файлами, каталогами и другие традиционные
для операционных систем функции выполняются в пользовательском
пространстве эмуляторами различных ОС


Модель API на основе DLL





Системные сервисы
Менеджер объектовМонитор ссылокбезопасности
Менеджер процессовСредство вызова локальных процедур
Менеджер виртуальной памяти
Менеджер ввода-выводаЯдро
<


Обращение к системным сервисам в традиционных ОС

аппаратное прерывание
процессор переходит в режим ядра
выполняется требуемая системная функция
возврат процессора в пользовательский режим
выполнение нити с прерванного места


Вызов системной функции (API Win32) в Windows NT

Динамическая библиотека DLL Win32 обращается
к системному сервису NT с просьбой послать сообщение серверу,
выполняющему требуемую функцию
Сервис посылает сообщение и ждет ответ
Сервер получает сообщение, выполняет функцию
и отсылает ответ
NT-executive выполняет следующую последовательность
действий:

сохраняет контекст клиентской нити
выбирает серверную нить для выполнения и загружает
ее контекст
выполняет функцию API Win32, используя серверную
нить
сохраняет контекст серверной нити
загружает контекст клиентской нити и обрабатывает
результаты выполнения функции API



Оптимизация

некоторые функции API реализованы внутри библиотеки
заглушек
некоторые данные Win32 хранятся в адресном пространстве
NT-executive
запросы приложений на выполнение функций API
объединяются в пакеты

Надежность Windows NT

Все приложения выполняются в раздельных адресных пространствах
Изолированность от аппаратуры
Изолированность подсистем
Файловая система NTFS с автовосстановлением
Встроенные средства резервного копирования
Встроенные средства надежной работы с диском

Нетрадиционные среды программирования: от Корнелльского Синтезатора до Java

В.Галатенко, Jet InfoSystems,

П.Христов, Открытые системы

Новые проекты в области информационных

В.Лобачев, В.Алешин, В.Афанасьев, А.Томилин,
Центр управления полетами
и моделирования
Высокий уровень сложности современных космических систем, стоящих перед ними задач, высокий
уровень риска и цена риска требуют развития и применения новых подходов при управлении
этими системами. Среди характерных примеров можно привести стыковку и сборку
крупногабаритных разветвленных конструкций с распределенной массой, дистанционное
управление планетными аппаратами в условиях большой длительности распространения
радиосигнала и т.п. Важной особенностью управления пилотируемыми аппаратами является
необходимость непрерывного тесного взаимодействия между экипажем и персоналом и экспертами
наземных служб слежения, поддержки и т.п. Все острее ощущается потребность в применении
средств коммуникации, более продвинутых по сравнению с традиционными радио-
телевизионными. В этой связи большой интерес может представлять использование в качестве
телекоммуникационного средства технологии Виртуальной Реальности.

В 1993-1995 годах при поддержке Российского фонда фундаментальных исследований в ЦУПе в
рамках инициативного проекта "Гипервизор", проводились исследования целью которых была
разработка концепции и основ системы визуализации сложных трехмерных динамических сцен с
высоким уровнем реализма. Были получены подходы к решению фундаментальных задач синтеза
изображений, в частности, методы обратной трассировки на произвольной картинной
поверхности, методы непосредственной трассировки невыпуклых параметрических поверхностей
на основе решения экстремальной задачи, которые могут использоваться в качестве основы при
построении архитектур системы синтеза изображений. При этом большое внимание в проекте
было уделено принципам построения открытой, доступной развитию архитектуры системы, в
частности, - созданию системы классов с виртуальными методами (в рамках объектно-
ориентированного подхода), позволяющих избежать жесткой привязки алгоритмов к конкретному
типу вычислителя и, по возможности, свести к минимуму адаптацию алгоритма к вычислителю.

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

В систему был заложен целый ряд функциональных возможностей, среди которых, в первую
очередь необходимо отметить возможность параллельного синхронного многоракурсного синтеза
изображений виртуальной сцены, состоящей из заданного числа участников сцены: "актеров" -
наблюдаемых объектов, "зрителей" - наблюдающих объектов и "осветителей" - объектов,
излучающих ЭМ-энергию заданного спектра. Число участников, их положение и ориентация
задаются путем описания сцены на специальном языке в текстовом файле или при помощи
интерфейса типа GUI. Для обработки и интерпретации входного текста описания сцены
разработан компилятор, формирующий образ сцены в оперативной памяти.

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

Для управления состояниями сцены используется интерфейс событий, при наступлении которых
образ сцены, хранимый в памяти в виде описания состояния объектов, оперативно изменяется:


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

С 1996 года инициативные исследования по виртуальной реальности в ЦУПе (также при
непосредственной поддержке РФФИ) продолжены в направлении построения концепции
индуцированной виртуальной среды.

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

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

По сравнению с обычными системами виртуальной реальности, система виртуального присутствия


должна содержать, как минимум, две дополнительные подсистемы:

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

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

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



Предлагаемая методология построения индуцированной виртуальной среды

включает в себя решение следующих основных задач:

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

создание и исследование модели технической системы (сегмента
орбитальной станции), воспроизводящей трехмерный объект сложной
структуры и поведение этого объекта;
исследование процессов индуцирования событий, включающих
регистрацию, передачу вектора состояния, преобразование его вектор
кодирования образа среды и отображение его на различных дисплеях;
исследования феноменов погружения оператора в индуцированную
виртуальную среду и некоторых видов взаимодействия с объектами в
индуцированной среде (в частности, визуального и тактильного);
исследования методологии построения баз структурных, морфологических
и оптических данных о естественных и техногенных 3D- объектах на основе
объектно-ориентированного подхода.
В заключение отметим, что проникновение виртуальной реальности в среду Internet (в частности,
зарождение и бурное развитие концепции VRML) открывает большие возможности для развития
телекоммуникаций в индуцированной виртуальной среде. В перспективе (по мере развития
технических возможностей систем телеметрии, слежения, каналов связи, персональных
вычислительных систем и средств отображения) любой пользователь сети Internet мог бы получить
возможность "виртуального присутствия" на борту, например, международной орбитальной
станции "Альфа" и в реальном времени "принимать участие" в проведении некоторых
экспериментов на борту (как минимум, - наблюдать за их проведением), и даже вместе с экипажем
или самостоятельно "выходить" в открытый (разумеется, виртуальный) космос или на поверхность
планеты.

Объединение подсетей в корпоративную сеть

Windows NT как сервер удаленного доступа
Поддержка NetBEUI, IPX
Поддержка TCP/IP (SLIP, PPP)
Использование RAS на предприятиях
EICON WAN Services for Windows NT

[]
[]
[]

Объектно-ориентированная среда для разработки трехмерных графических приложений

И.Юков, Институт системного программирования РАН
В работе рассмотрены вопросы построения объектно-ориентированной среды для эффективной
реализации высокоинтерактивных трехмерных графических приложений в таких областях как
геометрическое моделирование, САПР и научная визуализация.

Наиболее перспективным направлением работ по созданию интегрированного программного
обеспечения в области трехмерной графики и моделирования является разработка объектно-
ориентированных инструментальных средств, с помощью которых возможна реализация
проблемно-ориентированных приложений на основе единого ядра. Этот подход позволяет,
используя единые базовые средства, реализовывать трехмерные приложения в различных
прикладных областях. Представленная объектно-ориентированная среда для разработки
трехмерных приложений является примером развития объектно-ориентированного подхода и его
применения для создания базового и прикладного программного обеспечения для решения
трудоемких задач геометрического моделирования и научной визуализации. В отличие от
большинства разрабатываемых объектно-ориентированных инструментальных пакетов, которые
организуются в конкретной операционной системе и реализуют тот или иной стандарт,
представленная среда является переносимой для широкого спектра вычислительных платформ,
открытой для поддержки различных стандартов в области геометрического моделирования и
научной визуализации, а также обеспечивает эффективную поддержку нетрадиционных
аппаратных графических акселераторов. Целью работы являлась разработка объектно-
ориентированной технологии построения функционально законченных высокоинтерактивных
трехмерных графических приложений на базе мобильной инструментальной среды, сочетающей
эффективные средства геометрического моделирования, формализованный трехмерный
пользовательский интерфейс и реализующей базовые алгоритмы синтеза, анализа и визуализации
пространственных объектов. Структуризация предметной области позволяет выделить основные
компоненты трехмерного инструментария.
На базе объектно-ориентированного подхода
сформирована смешанная геометрическая модель твердотельных пространственных объектов,
сочетающая конструктивное и граничное представления. В совокупности с базовым набором
синтеза и анализа геометрии пространственных объектов, предложены механизмы параметризации
конструктивной модели и построение на базе геометрии тела его физической модели с реальными
свойствами. Расширяемость разработанной геометрической модели обеспечивает прозрачный
переход к эффективному решению таких задач, как генерация поверхностных и объемных сеток и
последующий конечно-элементный анализ построенных объектов. Формализация понятия
"интерактивная прикладная программа" привела к прозрачной методике построения трехмерных
графических приложений, обладающих базовыми средствами визуализации и навигации в
трехмерном пространстве, позволяющей при решении конкретной прикладной задачи с
минимальными затратами времени на организацию взаимодействия с пользователем получить
мобильное графическое приложение, поддерживающее международные стандарты на
геометрическое моделирование и научную визуализацию. Результаты работы могут быть
использованы при создании систем научной визуализации и САПР, обладающих переносимостью
для широкого класса вычислительных платформ и обеспечивающих поддержку современных
международных стандартов.

[]
[]
[]

Объектно-ориентированные средства анализа, проектирования и реинжениринга информационных систем

Сергей Паронджанов, компания Аргуссофт



















Rational Rose - средство объектно-ориентированного моделирования,
поддерживающие методы Буча и ОMT.

Работа в Rational Rose основывается на построении различного рода
диаграмм, описывающих проект.

Графический диалог ведется с использованием систем обозначений,
подробно изложенных в известных работах: "Объектно-ориентированное
проектирование с примерами применения" Г.Буча, и "Объектно-ориентированное
моделирование и проектирование" Д.Рамбо.

Общие параметры защиты системы

Ограничения для паролей
Срок действия
Минимальная длина
Минимальный интервал жизни
Сохранение истории
Блокировка учетных записей

Очереди сообщений

Четыре системных вызова:

msgget
для образования новой очереди сообщений или получения дескриптора
существующей очереди
msgsnd
для посылки сообщения (его постановки в очередь сообщений)
msgrcv
для приема сообщения (выборки сообщения из очереди)
msgctl для выполнения
управляющих действий

msgqid = msgget(key, flag);
Сообщения хранятся в виде связного списка
Декскриптор очереди сообщений - индекс в массиве
заголовков очередей сообщений
В заголовке очереди хранятся:

указатели на первое и последнее сообщение в данной
очереди
число сообщений
общий размер в байтах сообщений, находящихся в очереди
идентификаторы процессов, которые последними послали или приняли
сообщение через данную очередь
временные метки последних выполненных операций msgsnd,
msgrsv и msgctl

Одна из возможных конфигураций программных гнезд

Допустимые комбинации протоколов и драйверов задаются
при конфигурации системы

во время работы системы менять нельзя

По духу организация программных гнезд близка к идее
потоков
Но менее гибкая схема

не допускает изменения конфигурации "на
ходу"

Взаимодействие процессов основано на модели "клиент-сервер"

процесс-сервер "слушает (listens)"
свое программное гнездо
процесс-клиент пытается общаться с процессом-сервером
через другое программное гнездо
ядро поддерживает внутренние соединения и маршрутизацию
данных от клиента к серверу

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

"домен системы UNIX"
для процессов, которые взаимодействуют через программные гнезда
в пределах одного компьютера
"домен Internet"
для процессов, которые взаимодействуют в сети в соответствии с
семейством протоколов TCP/IP

Два типа программных гнезд

с виртуальным соединением (stream sockets)
дейтаграммные гнезда (datagram sockets)

Виртуальные соединения:

передача данных от клиента к серверу в виде непрерывного
потока байтов с гарантией доставки
до начала передачи данных должно быть установлено
соединение

Дейтаграммные программные гнезда:

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

По умолчанию обеспечивается подходящий протокол
для каждой допустимой комбинации "домен-гнездо"

TCP для виртуальных соединений
UDP для дейтаграммного способа коммуникаций

Создание нового программного гнезда:
sd = socket(domain, type,
protocol);

domain
- домен гнезда
type - тип (с
виртуальным соединением или дейтаграммное)
protocol - желаемый
сетевой протокол
sd - дескриптор
программного гнезда

Закрытие (уничтожение) гнезда
close(sd)
Связывание ранее созданного программного гнезда
с именем:

bind(sd, socknm, socknlen);

sd
- дескриптор ранее созданного программного гнезда
socknm - адрес
структуры, которая содержит имя (идентификатор) гнезда, соответствующее
требованиям домена данного гнезда и используемого протокола
для домена системы UNIX имя является именем объекта в файловой
системе
при создании программного гнезда создается файл
socknlen - длина
в байтах структуры socknm

Запрос связи с существующим программным гнездом
со стороны процесса-клиента:
connect(sd, socknm, socknlen);

смысл параметров, как у функции bind
имя программного гнезда на другой стороне коммуникационного
канала
у гнезда с дескриптором sd
и у гнезда с именем socknm
должны быть одинаковые домен и протокол
если тип гнезда с дескриптором sd
- дейтаграммный, то connect
служит для информирования системы об адресе назначения пакетов,
которые в дальнейшем будут посылаться с помощью функции send

Информирования о том, что процесс-сервер планирует
установление виртуальных соединений через указанное гнездо:
listen(sd, qlength);

qlength
- максимальная длина очереди запросов на установление соединения,
которые должны буферизоваться системой, пока их не выберет процесс-сервер

Выборка процессом-сервером очередного запроса на
установление соединения с указанным программным гнездом служит
функция accept:
nsd = accept(sd, address, addrlen);

sd
- дескриптор существующего программного гнезда, для которого ранее
была выполнена функция listen
address
- массив данных, в который должна быть помещена информация, характеризующая
имя программного гнезда клиента
addrlen
- адрес, по которому находится длина массива address
выполнение функции приводит к установлению виртуального
соединения
nsd
- новый дескриптор программного гнезда, который должен использоваться
при работе через данное соединение
по адресу addrlen
помещается реальный размер массива данных, которые записаны по
адресу address

Передача и прием данных через программные гнезда
с установленным виртуальным соединением:


count = send(sd, msg, length,
flags);
count = recv(sd, buf, length,
flags);
В send:

msg
указывает на буфер с данными, которые требуется послать
length
- длина этого буфера
flags
== MSG_OOB
внеочередная посылка данных

В recv:

buf
указывает на буфер, в который следует поместить принимаемые данные
length
- максимальная длина этого буфера
flags
== MSG_PEEK
перепись сообщения в пользовательский буфер без его удаления
из системных буферов

Вместо send
и recv
можно использовать read
и write

выполняются аналогично send
и recv

Для посылки и приема сообщений в дейтаграммном
режиме:
count = sendto(sd, msg,
length, flags, socknm, socknlen);
count = recvfrom(sd, buf,
length, flags, socknm, socknlen);

смысл параметров sd,
msg,
buf
и lenght
аналогичен смыслу одноименных параметров функций send
и recv
socknm
и socknlen
функции sendto
задают имя программного гнезда, в которое посылается сообщение
могут быть опущены, если до этого вызывалась
функция connect
параметры socknm
и socknlen
функции recvfrom
позволяют серверу получить имя пославшего сообщение процесса-клиента

Немедленная ликвидация установленного соединения:
shutdown(sd, mode);

немедленно остановить коммуникации
со стороны посылающего процесса
со стороны принимающего процесса
с обеих сторон
в зависимости от значения параметра mode

shutdown отличаются
от close:

выполнение close
последней "притормаживается" до окончания попыток системы
доставить уже отправленные сообщения
shutdown разрывает
соединение, но не ликвидирует дескрипторы ранее соединенных гнезд
для ликвидации требуется вызов close

Описание общей схемы функционирования системы

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

Функционально созданное клиентское приложение разбивается на следующие блоки :
Блок инициализации клиентского приложения и установки соединения с серверным
приложением.
Блок обработки заданных удаленным клиентом данных и создания текста запроса на языке
SQL.
Блок, преобразующий данные из результирующего множества, полученные от серверного
приложения, к цепочке HTML документов, которые будут переданы удаленному пользователю.
Блок, отвечающий за деинициализацию клиентского приложения, реакцию на возникающие
исключительные ситуации и прочие организационные действия.
Блок, отвечающий за получение данных, введенных удаленным клиентом в HTML документ.
Блок, организующий пересылку серверному приложению текста составленного SQL запроса и
получение записей из результирующего множества.
В свою очередь, серверное приложения, исходя из набора решаемых задач, функционально
разбивается на следующие блоки:
Блок, отвечающий за подготовку SQL запроса, исполнение, а также за получение данных
из результирующего множества.
Блок, организующий получение от клиентского приложения текста SQL запроса и за
пересылку результатов его исполнения обратно клиентскому приложению.
Блок, инициализирующий серверное приложение, регистрирующий сервис в библиотеке
DDEML и устанавливающий соединение с ODBC драйвером.
Блок деинициализации серверного приложения, обработки исключительных ситуаций и
выполнения прочих служебных функций.

Определение профилей

Определение профиля включает следующие его
элементы:

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

Определения

Стандарт (по определению ISO). Технический стандарт
или другой документ, доступный и опубликованный, коллективно разработанный
или согласованный и общепринятый в интересах тех, кто им пользуется,
основанный на интеграции результатов науки, технологии, опыта,
способствующий повышению общественного блага и принятый организациями,
признанными на национальном, региональном и международном уровне.
Базовый стандарт (часто именуется формальным
стандартом или базовыми спецификациями). Принятый международный
стандарт или Рекомендация организации ITU-T (до 1993 г. - CCITT).
ИТ-система (IT system). Совокупность ресурсов
информационных технологий, предоставляющих сервис (услуги) на
одном или большем числе интерфейсов.
Профиль (Profile) - набор, состоящий из одного
или большего числа базовых стандартов и/или ISPs (см. ниже), содержащий
указание области применимости, а также указание выбранных классов
обслуживания, аттестационных наборов, опций и параметров тех базовых
стандартов и ISPs, которые необходимы для выполнения конкретной
(прикладной) функции.
ISP (International Standardized Profile - Международный
стандартизованный профиль). Согласованный на международном уровне
официальный документ, описывающий один или несколько профилей.
Таксономия (Taxonomy) - классификационная схема,
применяемая для однозначной индентификации профилей или наборов
профилей.
OSE (Open Systems Environment - Окружение открытых
систем).


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

SE-профиль. Профиль, который специфицирует все
поведение ИТ-системы или часть ее поведения на одном или большем
числе интерфейсов OSE.
OSI-профиль - конкретный профиль, составленный
из базовых стандартов, соответствующих модели OSI, и/или базовых
стандартов представления форматов и данных (т.е.
F - профилей).
Переносимость (portability) - свойство системы
(продукта), позволяющее с возможно меньшими накладными расходами
или без таковых осуществлять перенос программного обеспечения,
информации и пользователей системы с одной прикладной платформы
на другую.
Интероперабельность (interoperability) - возможность
совместного использования информации и ресурсов компонентами распределенной
системы.
Масштабируемость (scability) - свойство системы,
позволяющее ей эффективно работать в широком диапазоне параметров,
определяющих технические и ресурсные характеристики системы.
Прикладное ПО (Aplication Software - Прикладное
программное обеспечение). Программное обеспечение - специфическое
для некоторого приложения и состоящее из программ, данных и документации.
Прикладная платформа (Aplication Platform). Набор
программно-аппаратных ресурсов, необходимых для поддержки услуг,
предоставляемых для выполнения прикладного ПО.
API-интерфейс (Application Program Interface
- Интерфейс прикладной программы). Интерфейс между прикладным
ПО и прикладной платформой, через который обеспечиваются все услуги.
CSI-интерфейс (Communication Services Interface
- Интерфейс коммуникационных услуг). Граница, через которую обеспечивается
доступ к услугам, реализующим взаимодействие между внутренними
объектами ПО и внешними объектами прикладной платформы.
HCI-интерфейс (Human/Computer Interface - Человеко-машинный
интерфейс). Граница, через которую имеет место физическое взаимодействие
между человеком и прикладной платформой.
ISI-интерфейс (Information Services Interface
- Интерфейс информационных услуг). Граница, через которую обеспечивается
сервис внешнего хранилища данных

Опыт разработки переносимой банковской

А.Федоров, Национальный банк Республики Татарстан
Во втором полугодии в Национальном Банке Республики Татарстан была поставлена работа по
созданию подсистемы денежного обращения интегрированной информационной системы (ИИС) с
применением методологии и комплекса инструментальных средств, предлагаемых "Аргуссофт
Компани". Комплекс включал CASE-средство SILVERRUN, язык четвертого поколения JAM6 и
JAM/TPi для программирования сервера приложений, монитор транзакций TUXEDO, средство
конфигурационного управления PVCS и работы с различными СУБД Q+E (новое названия
DataDirect).

Основной целью этих работ было создание подсистемы. Однако на этом проекте Центральный
Банк РФ проводил обработку составных частей своего регионального проекта, как переносимых
на достаточно широкий круг аппаратно-программных платформ (HP UX, Solaris, SCO Unix) и
реляционных СУБД (Oracle, Informix).

При разработке ИИС и в частности подсистемы денежного обращения, нами учитывались
следующие требования:

Адаптивность к изменениям административной структуры;
Наращивание выполняемых функций;
Быстрая настройка ИИС на конкретных пользователей;
Возможность получать любые информационные услуги с любых
терминалов, обслуживаемых ИИС, в пределах их полномочий;
Интеграция входной, внутренней и выходной информации;
В ходе выполнения работ перед нашим коллективом стояла задача не только изучить и освоить
комплекс инструментальных средств, но и одновременно, в процессе освоения разработать по
новой технологии подсистему денежного обращения.

Подсистема денежного обращения проектировалась нами как составная часть интегрированной
информационной системы НБ РТ.

Подсистема ОДО включает в себя следующие АРМы:

Составление отчетов по кассовым оборотам;
Анализ выполнения прогноза кассовых оборотов;
Контроль за выдачей средств на потребление;
Составление и анализ выполнения кассового плана;
Анализ сведений о просроченной задолженности по выдаче зарплаты;
Анализ сведений о состоянии лимитов остатка касс;

Анализ состояния и объема денежной массы в обороте;
Учет и анализ эмиссионно-кассовых операций;
АРМ администратора интегрированной информационной системы
(ИИС).
Для построения проектирования подсистемы денежного обращения было использовано CASE-
средство SILVERRUN фирмы CSA.

При выборе CASE-средства в ходе обследования ГУ НБ РТ год назад мы остановились на CASE-
Аналитике фирмы Эйтекс, который выгодно отличался от других аналогичных средств (доступных
для нас) дешевизной, простотой использования, наиболее подходящей нотацией Gane/Sarson.

В процессе работы над системой диаграмм бизнес-модели ГУ выявился ряд недостатков CASE-
Аналитика, поэтому нам стало ясно, что дальнейшее использование СASE-Аналитика в
проектировании интегрированной информационной системы ГУ проблематично. Какие это
недостатки:

очень бедные возможности импорта/экспорта (следовательно, не
возможна коллективная разработка модели),
нет репозитория структур данных, да и сами типы возможных структур
данных сильно ограничены,
нет возможности конструирования базы данных.
Silverrun нас привлек тем, что предоставляет широкие возможности при построении структурных
схем:

компонента BPM (Business Process Models) является очень гибким
инструментом создания целого комплекса типов схем от диаграмм потоков
данных и бизнес-моделей до схем навигации экранов и взаимосвязей
функциональных модулей программ;
компонента ERX (Entity Relationship Expert) помогает построить
концептуальную модель данных проекта;
компонента RDM (Relational Data Modeling) предназначена для построения
реляционной модели данных проекта, позволяет создавать базу данных,
быстро портировать базу с одной платформы на другую;
компонента WRM (Workgroup Repository Manager) управляет общим для
всех компонент репозиторием для хранения и совместного использования
типов данных, доменов, структур данных;
прекрасные возможности формирования отчетов на основе данных и схем
проекта.
В процессе проектирования ИИС диаграммы потоков данных информационно-функциональной


модели Главного Управления НБ РТ были переведены нами в среду Silverrun. Максимально полно
проработана модель подсистемы ОДО как составной части ИИС.

Построена система диаграмм информационных потоков для этих подсистем с помощью
BPM-компоненты Silverrun. На дереве процессов показана иерархическая структура процессов
системы. В модели выделено 84 процесса, 9 внешних сущностей, 24 накопителя данных.
Определены: 26 базисных типов данных, 26 доменов, 54 структуры данных, информационные
потоки связаны со структурами данных и квалификаторами, построены описания всех детальных
процессов. С помощью средств документирования проекта, предоставляемых Silverrun, были
получены описания компонент диаграмм и потоков данных.
Данные, полученные в процессе разработки DFD-модели (модели диаграмм потоков
данных), были перенесены в репозиторий для их дальнейшего использования при построении
реляционной модели данных проекта с помощью RDM-компоненты. На основе базисных
типов, доменов и структур данных, определенных в DFD-диаграммах:
определено 9 основных таблиц:
определено 45 подсхем с подчиненными таблицами, выделенными в
соответствии с подпроцессами 1-го уровня DFD-диаграммы;
выделены уникальные ключи , определены отношения между таблицами;
проведена верификация модели;
сгенерированы внешние ключи подчиненных таблиц;
сформирован SQL-код для Oracle;
проведена портация модели на платформу Informix;
средствами Silverrun получена документация по сформированной
базе.
Навигация экранов. Как было сказано ранее, компонента BPM Silverrun позволяет строить
схемы различного класса. Мы использовали ее для построения схемы навигации типовых
программных модулей (экранов) JAM-программы. Подсистема денежного обращения
проектировалась с учетом требований максимальной гибкости и адаптивности ИИС.
Созданный на языке JAM комплекс программ включает в себя АРМ администратора ИИС и
универсальную программную оболочку для конфигурирования АРМов конкретных
пользователей. Разработаны схемы навигации экранов :


универсальной оболочки конфигурирования АРМов;
отдельных функциональных модулей;
оболочки администратора;
действующего макета подсистемы денежного обращения.
Основным средством разработки программного обеспечения подсистемы денежного обращения
был язык четвертого поколения JAM фирмы JYACC. JAM включает в себя следующие основные
компоненты:

экранный редактор - среду разработки экранов;
редактор меню;
отладчик;
генератор отчетов;
макетную СУБД JDB;
модули интерфейса с конкретными СУБД (ORACLE, INFORMIX);
JAM/TPI - средство программирования сервисов TUXEDO;
Для хранения описаний информационных объектов и реализации механизма наследования
используется репозиторий.

Помимо средств визуального программирования JAM имеет встроенный процедурный язык
интерпретирующего типа JPL с С-образным синтаксисом.

Разработка программного обеспечения подсистемы денежного обращения началась с переноса
функционально-логической модели из SILVERRUN в среду визуальной разработки прикладного
программного обеспечения JAM. На этой стадии были выполнены следующие работы:

Перенос схемы базы данных для СУБД ORACLE в макетную СУБД
JDB. JDB-это встроенная в среду разработки JAM СУБД с SQL языком, которая
позволяет выполнять прототипирование и тестирование приложений,
реализованных на JAM до создания реальной базы данных в СУБД ORACLE
или INFORMIX;
Формирование репозитория подсистемы денежного обращения в среде
JAM. Репозиторий первоначально формируется из схемы базы данных при
помощи операции IMPORT. При этом объекты, хранящиеся в репозитории
наследуют свойства объектов из базы данных. Затем производится
редактирование входов репозитория (вводятся русские наименования данных,
шаблоны внешнего представления данных, объекты управления приложениями
и т.д.;
Затем были выполнены следующие подготовительные работы:

Сформулированы требования к внешнему оформлению
пользовательского интерфейса;
Разработана библиотека типовых программных модулей на языке JPL. JPL
- это процедурный язык интерпретирующего типа, встроенный в среду


разработки JAM. На языке JPL реализуется логика работы
приложений;
Для обеспечения максимальной гибкости и адаптивности ИИС был реализован подход
компоновки конкретных АРМов из набора функциональных модулей при помощи универсальных
средств компоновки и управления АРМами. Под функциональным модулем в данной реализации
понимается группа программных модулей или один модуль, выполняющие законченную
прикладную функцию. Программные модули - это экраны или отчеты JAM. На языке JAM нами
были разработаны АРМ администратора интегрированной информационной системы (ИИС) НБ
РТ и универсальная программная оболочка для реализации АРМов ИИС НБ РТ, включающие в
себя:

Средства регистрации пользователей ИИС НБ РТ;
Средства описания типовых программных комплексов;
Средства конфигурирования АРМов конкретных пользователей;
При помощи АРМа администратора ИИС стала возможной практическая реализация концепции
рабочего стола пользователя, когда на рабочем месте пользователя под единым управлением
интегрируются как конкретные прикладные АРМы, предназначенные для данного пользователя,
так и набор типовых средств, таких как текстовые редакторы, электронные таблицы, электронная
почта и т.д.

Исходными данными для разработки приложений были функционально-логическая модель,
модель базы данных и схема навигации приложений, разработанные в среде CASE-средства
SILVERRUN.

Прикладное программное обеспечение подсистемы денежного обращения разрабатывалось
средствами JAM 6.10. Важным преимуществом данного инструментального комплекса и JAM в
частности является возможность проведения разработки по спиральному циклу с построением
прототипов в конце каждого цикла. В нашем случае первым действующим прототипом системы
являлось описание АРМов средствами АРМ администратора, в результате чего пользователь видел
функции АРМов в виде меню верхнего уровня до начала программирования. Затем средствами
JAM осуществлялось прототипирование экранов и, наконец двухзвенная реализация ряда
приложений служила прототипом для реализации трехзвенного варианта.



Коллективная разработка осуществлялась с использованием общего репозитория проекта и
средства управления версиями PVCS Version Manager фирмы INTERSOLV. Средствами PVCS
осуществлялось управление изменениями прикладных экранов и входов репозитория, а также
контроль состояния разработки. Важным преимущество JAM является интеграция PVCS Version
Manager со средой разработки JAM.;

Ряд приложений в подсистеме денежного обращения был реализован по трехзвенной архитектуре с
применением монитора транзакций TUXEDO и компоненты JAM/TPi. Как показал опыт данной
разработки реализация по трехзвенной архитектуре резко увеличивает эффективность приложений
расчетного характера с большим количеством обращений к базе данных. При этом нами
использовался подход при котором приложение вначале прототипировалось и тестировалось в
двухзвенном варианте, а затем путем анализа SQL-кода определялись сервисы и соответствующие
им сервисные экраны, а также параметры сервисов. Затем вызов SQL в клиентских экранах
заменялся на вызов соответствующих сервисов, а из исходного экрана формировались сервисные
экраны. По окончании данной работы сервисные экраны и файл описания сервисов переносились
на сервисную машину.

Необходимо отметить развитые средства отладки JAM, которые позволяли достаточно
качественно тестировать разрабатываемые приложения. Для анализа содержимого баз данных
нами использовалась средство Q+E.

В ходе разработки было запрограммировано более 160 экранов и отчетов на языке JAM и
средствами АРМа администратора ИИС сконфигурированы 8 АРМов подсистемы денежного
обращения.

Разработка проводилась 3,5 месяца коллективом в 3 человека. Разработка завершилась созданием
подсистемы ОДО и комплекта документации из 14 книг общим объемом 450 страниц.

В ходе работ основная часть системы разработана в среде HP UX, а отдельные компоненты,
особенно для трехзвенной архитектуры клиент-сервер - в среде Solaris. По завершении разработки
подсистемы ОДО, функционировавшей в среде HP UX - Oracle, проведен ее перенос в среду SCO


UNIX - Informix, включая базу данных, наполненную реальной информацией (с русскими
буквами). Объем базы составлял около 1,5 Мб. Перенос осуществлялся в следующем порядке:

осуществлен реинжиниринг базы данных, организованной в СУБД
Oracle, с помощью модуля SILVERRUN-RDM и моста к Oracle с получением ER-
модели;
по полученной ER-модели проведена генерация базы данных для Среды
Informix с помощью SILVERRUN-RDM и моста к Informix;
проведен перенос данных из Oracle в Informix с помощью Q+E.
Общее время переноса составило менее часа.

В заключение доклада приведу выводы об эффективности данного комплекса инструментальных
средств. Данный комплекс действительно обеспечивает разработку портируемых приложений как
по двухзвенной, так и по трехзвенной схеме. Все средства достаточно просты в освоении.
Разработка приложений средствами JAM осуществлялась достаточно быстро, причем
разработчики не имели большого опыта работы с ним. Необходимо отметить, что в настоящее
время фирма Аргуссофт поставила нам новую версию JAM-7, которая содержит генератор
типовых экранов. Его использование повышает производительность программирования в
несколько раз. Использование механизма наследования JAM позволяет резко снизить
трудоемкость внесения изменений при сопровождении.

[]
[]
[]

Организация ITU-T

(International Telecommunication Union-Telecommunications
Международный союз по телекоммуникации-телекоммуникация)

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

Основные исследовательские группы (Study Groups -
SGs):

ITU-T

SG7 Сети передачи данных
SG8 Терминалы для услуг телематики
SG10 Языки для телекоммуникации


Имеется тесное сотрудничество между JTC1 и ITU-T.
Основной формой сотрудничества является соглашение об общем тексте
для стандартов ISO/IEC (т.е. JTC1) и рекомендаций и ITU-T/CCITT,
относящихся к одним и тем же аспектам в областях OSI и ODP.

Организация ввода/вывода

Шины:

шины процессор-память
шины ввода/вывода

Основные возможности шин

Возможность	Высокая производительность	Низкая стоимость
Общая разрядность шины	Отдельные линии адреса и данных	Мультиплексирование линий адреса и данных
Ширина (рязрядность) данных	Чем шире, тем быстрее (например, 32 бит)	Чем уже, тем дешевле (например, 8 бит)
Размер пересылки	Пересылка нескольких слов имеет меньшие накладные расходы	Пересылка одного слова дешевле
Главные устройства шины	Несколько (требуется арбитраж)	Одно (арбитраж не нужен)
Расщепленные транзакции?	Да - отдельные пакеты Запроса и Ответа дают большую полосу пропускания (нужно несколько главных устройств)	Нет - продолжающееся соединение дешевле и имеет меньшую задержку
Тип синхронизации	Синхронные	Асинхронные

Организационная структура в области стандартизации ИТ

Организационная структура, поддерживающая процесс
стандартизации ИТ, включает три основных группы организаций:

а) Международные организации, входящие в структуру
ООН;

ISO (International Organization for Standardization
- Международная организация по стандартизации);
IEC (International Electrotechnical Commision
- Международная электротехническая комиссия);
ITU-T (International Telecommunication Union-Telecommunications
- Международный союз по телекоммуникации - телекоммуникация).
До 1993г. эта организация имела другое название - CCITT (International
Telegraph and Telephone Consultative Committee - Международный
консультативный комитет по телефонии и телеграфии или, сокращенно,
МККТТ). X.200, X-400, X-500, X-600.


б) Промышленные профессиональные или административные
организации;

IEEE (Institute of Electrical and Electronic
Engineers - Институт инженеров по электротехнике и электронике)
LAN IEEE802, POSIX
Internet и IAB (Internet Activities Board - Совет
управления деятельностью Internet) TCP/IP
Regional WOS (Workshops on Open Systems - Рабочие
группы по открытым системам). OSE-profiles


с) Промышленные консорциумы.

ECMA (European Computer Manufactureres Association
- Европейская ассоциация производителей вычислительных машин)
OSI, безопасность, управление, Office Document Architecture (ODE)
OMG (Object Management Group - Группа управления
объектами) RM: Common Object Request Broker Architecture (CORBA)
X/Open (Организована группой поставщиков компьютерной
техники) X/Open Portability Guide (XPG4) Common Application Environment
NMF (Network Management Forum - Форум управления
сетями)


OSF (Open Software Foundation - Основание открытого
программного обеспечения). Имеет следующие предложения:
OSF/1 (Соответствует стандарту POSIX и XPG4)
MOTIF - графический пользовательский интерфейс
(Distributed Computer Environment)
DCE - технология интеграции платформ: DEC, HP, SUN, MIT, Siemens,
Microsoft, Transarc
DME (Distributed Management Environment) ~=~ NMF


Международные организации по стандартизации, входящие в структуру ООН:


ISO (International Organization for Standartization: Международная
организация по стандартизации)

IEC
(International Electrotechnical Commision: Международная Электротехническая
Комиссия)

ITU-T
(International Telecommunications Union - Telecommunications:
Международный союз по телекоммуникации)


Промышленные, профессиональные или административные организации


IEEE (Institute of Electrical and Electronic Engineers: Институт инженеров
по электротехнике и электронике)

Internet и IAB (Internet Activities Board: Совет управления деятельностью Internet)

Regional WOS (Workshops on Open Systems: Рабочие группы по открытым системам)


Промышленные консорциумы


ECMA (European Computer Manufactures Assosiation: Европейская ассоциация производителей вычислительных машин)

OMG (Object Management Group: Группа управления объектами)

X/Open (Организован группой европейских поставщиков компьютерной техники)

NMF (Network Management Forum: Форум управления сетями)

OSF (Open Software Foundation: Фонд открытого программного обеспечения)

Основные архитектурные понятия

CISC - Complete
Instruction Set Computer (IBM/360, Intel x86)
RISC - Reduced
Instruction Set Computer (CDC 6600, Cray, IBM/801, RISC I/II,
MIPS)

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

Основные характеристики популярных шин

Шина IBM PC/XT:

8 бит данных, 20 бит адреса, 4 линии IRQ, 4 линии
запроса DMA
4.77 МГц, 4 Мбайт/с

Шина ISA (Industry Standard Architecture) -
IBM PC/AT:

16 бит данных, 24 бит адреса, 15 линий IRQ, 7
линий запроса DMA
8 МГц, 16 Мбайт/с

Шина EISA (Extended Industry Standard Architecture):

32 бит данных, 32 бит адреса
8 МГц, 32 Мбайт/с

Шина МСА (Micro Channel Architecture):

32 бит данных
10 МГц, 40 Мбайт/с

Шина VL-bus (VESA - Video Electronics Standard
Association):

32 бит данных
40 МГц, 130 Мбайт/с

Шина PCI (Peripheral Component Interconnect):

32 бит данных
33 МГц, 132 Мбайт/с
Шина SBus (IEEE - 1496):

32/64 бит
20/25 МГц, 80/100 Мбайт/с

Шина MBus

мультиплексирование адреса/данных:

64 бит данные
36 бит физического адреса

50 МГц, 400 Мбайт/с (125 Мбайт/с)
поддержка когерентного состояния кэш-памяти в микропроцессорной
системе

Шина XDBus:

расщепление транзакций
до 64 процессоров (SuperServer 6400 Cray Research)
50 МГц, 400 Мбайт/с (310 Мбайт/с)

Шина POWERpath-2 (Chellange - Silicon Graphics):

до 36 R4400
8-кратное расслоение ОЗУ (до 16 Гбайт)
256 бит данных, 40 бит адреса, 50 МГц

Шина SCSI (Small Computer System Interface):
1986 г. - SCSI-1
1992 г. - SCSI-2: fast mode, wide mode
SCSI-1: 8 бит, 5 Мбайт/с
Fast SCSI: 8 бит, 10 Мбайт/с
Wide SCSI: 16/32 бит, 10/20 Мбайт/с
Fast-and-Wide SCSI: 16/32 бит, 20/40 Мбайт/с

Основные характеристики рабочих станций компании SUN Microsystems

МОДЕЛЬ	SPARCstation 4	SPARCstation 5
ЦП
Тип процессора	microSPARC II	microSPARC II
Тактовая частота (МГц)	110	110
Число процессоров	1	1
Системная шина (бит)	64	64
Размер кэша (Кб) (в процессоре/на плате)	24	24
Пропускная способность системной шины (Мб/сек)	105	105
ПАМЯТЬ
Минимальный объем (Мб)	32	32
Максимальный объем (Мб)	160	256
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus
Количество слотов	1	3
Максимальная пропускная способность подсистемы в/в (Мб/сек)	52	52
Периферийные интерфейсы	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	1.05	1.05
Максимальная емкость дисковой памяти (Гб)	56	92
Количество последовательных портов	2	2
Количество параллельных портов	1	1
Сетевые интерфейсы основной/дополни-тельные	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring
ГРАФИЧЕСКАЯ ПОДСИСТЕМА	Color	Grayscale, Accelerated color (TGX, TGX+,SX,ZX)
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	78.6	78.6
SPECfp92	65.3	65.3
SPECbase_int92	68.7	68.7
SPECbase_fp92	63.0	63.0
SPECrate_int92	1864	1864
SPECrate_fp92	1549	1549
SPECrate_base_int92	1630	1630
SPECrate_base_fp92	1494	1494
MIPS	135.5	135.5
MFLOPS	21.7	21.7

МОДЕЛЬ	SPARCstation 20
	Model 71	Model 151	Model 712MP	Model 152MP	Model 514MP	Model HS14MP
ЦП
Тип процессора	SuperSPARCII	hyperSPARC	SuperSPARCII	hyperSPARC	SuperSPARC+	hyperSPARC
Тактовая частота (МГц)	75	150	75	150	50	100
Число процессоров	1	1	2	2	4	4
Системная шина (бит)	64	64	64	64	64	64
Размер кэша (Кб)	36/1024	8/512	36/1024	8/512	36/1024	8/256
(в процессоре/на плате)			/CPU	/CPU	/CPU	/CPU
Пропускная способность системной шины (Мб/сек)	105	105	105	105	105	105
ПАМЯТЬ
Минимальный объем (Мб)	32	32	64	64	64	64
Максимальный объем (Мб)	512	512	512	512	512	512
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus	Sbus	Sbus	Sbus	Sbus
Количество слотов	4	4	4	4	4	4
Максимальная пропускная способность подсистемы в/в (Мб/сек)	52	52	52	52	52	52
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	1.05	1.05	1.05	1.05	1.05	1.05
Максимальная емкость дисковой памяти (Гб)	353	353	353	353	353	353
Количество последовательных портов	2	2	2	2	2	2
Количество параллельных портов	1	1	1	1	1	1
Сетевые интерфейсы основной/дополнительные	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/ FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/ FDDI, Token Ring
ГРАФИЧЕСКАЯ ПОДСИСТЕМА	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)	Grayscale, Accelerated color (TGX, TGX+,SX,ZX)	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)	Grayscale, Accelerated color (TGX, TGX+,SX,ZX)	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	125.8	169.4	-	-	-	-
SPECfp92	121.2	208.2	-	-	-	-
SPECbase_int92	116.4	157.4	-	-	-	-
SPECbase_fp92	109.4	188.2	-	-	-	-
SPECrate_int92	2984	4018	5726	7310	7072	8124
SPECrate_fp92	2875	4938	5439	8758	7341	8906
SPECrate_base_int92	2761	3734	5332	7004	6636	7699
SPECrate_base_fp92	2592	4464	4923	7945	6708	8328
MIPS	204.7	306.0	-	-	-	-
MFLOPS	44.4	62.8	-	-	-	-

<

МОДЕЛЬ	Ultra 1	Ultra 2
	Model 140	Model 170	Model 170E	Model 2200
ЦП
Тип процессора	UltraSPARC-1	UltraSPARC-1
Тактовая частота (МГц)	143	167	167	200
Число процессоров	1	1	1	2
Системная шина (бит)	128/256	128/256	128/256	128/512
Размер кэша (Кб)	16+16/512	16+16/512	16+16/512	16+16/1024
(в процессоре/на плате)				/CPU
Пропускная способность системной шины (Мб/сек)	1300	1300	1300	1300
ПАМЯТЬ
Минимальный объем (Мб)	32	32	32	64
Максимальный объем (Мб)	512	512	512	1024
ВВОД/ВЫВОД
Количество слотов	3 SBus (32/ 64бит,25МГц)	3 SBus (32/ 64бит,25МГц)	2 SBus (32/64бит,25МГц) 1 UPA,83МГц	4 SBus (32/64бит,25МГц) 1 UPA,100МГц
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	1.05	1.05	1.05	2.1
Максимальная емкость дисковой памяти (Гб)	147	147	147	273
Количество последовательных портов	2	2	2	2
Количество параллельных портов	1	1	1	1
Сетевые интерфейсы	10 Мбит/с	10 Мбит/с	10/100 Мбит/с	10/100 Мбит/с
основной/дополнительные	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring
ГРАФИЧЕСКАЯ ПОДСИСТЕМА	TurboGX, TurboGXplus	TurboGX, TurboGXplus	Creator, Creator3D, Freedom	Creator, Creator3D
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	215	252	252	332
SPECfp92	303	351	351	505
SPECbase_int92	180	204	204	260
SPECbase_fp92	271	313	313	368
SPECrate_int92	5107	5982	5982	14962
SPECrate_fp92	7175	8323	8323	18675
SPECrate_base_int92	4267	4893	4893	11927
SPECrate_base_fp92	6428	7403	7403	17464
MIPS	291	341	341	414/CPU
MFLOPS	109	126	126	136/CPU

Основные характеристики серверов AlphaServer

Система/ Характеристики	AlphaServer 400	AlphaServer 1000	AlphaServer 2000	AlphaServer 2100	AlphaServer 8200	AlphaServer 8400
Частота	166 МГц	233 МГц	4/275:275 МГц 4/233:233 МГц	5/250:250 МГц 4/275:275 МГц 4/200:200 МГц	300 МГц	300 МГц
Число процессоров	1	1	1-2	1-4	1-6	1-12
Число транзакций в сек. (tpsA)	До 130	До 300	4/275: До 625 4/233: До 400	5/250: До 1200 4/275: До 850 4/200: До 675	Свыше 2000	Свыше 3000
Макс. память	192 Мб	512 Мб	4/275: 1 Гб 4/233:640 Мб	2 Гб	6 Гб	14 Гб
Память на диске	441 Гб	220 Гб	Свыше 500Гб	500 Гб	10 Тб	10 Тб
Поддержка ввода/ вывода	2 слота PCI 3 слота EISA 1 слот PCI/EISA	2 слота PCI 7 слотов EISA 1 слот PCI/EISA	3 слота PCI 7 слотов EISA	3 слота PCI 8 слотов EISA	108 слотов PCI 8 слотов EISA	144 слота PCI 8 слотов EISA
ECC память	Нет	Да	Да	Да	Да	Да
RAID	Да	Да	Да	Да	Да	Да
Авто-перезагрузка	Да	Да	Да	Да	Да	Да
Дублирование питания	Нет	Да	Да	Да	Да	Да
Управление температурой	Нет	Да	Да	Да	Да	Да

Максимальная емкость дисков включая RAID

МОДЕЛЬ	250	C10	C20	370	380	390	39H	570	580	58H	590	59H	990	R10	R20	R24
ЦП
Тип процессора	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER
	PC601	PC601	PC604		2	2	2			2	2	2	2		2	2
Тактовая частота (МГц)	66/80	80	120	62	59	66.7	66.7	50	62	55	66	66	71.5	50	66	71.5
Число процессоров	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
Системная шина (бит)	64	64	64	64	64	64	128	64	128	256	256	128	256	64	128	128
Размер кэша
L1 (команды/данные) (Кб)	32	32	32/32	32/32	32/64	32/64	32/128	32/32	32/64	32/256	32/256	32/128	32/256	32/32	32/128	32/128
L2 (о-доп.возм.) (Мб)	-	1o	1	-	-	1o	2o	-	-	-	-	1	-	-	1	2
ПАМЯТЬ
Минимальный объем (Мб)	16	16	16	32	32	32	64	32	64	64	64	64	128	128	128	128
Максимальный объем (Мб)	256	256	256	512	512	512	512	1024	2048	2048	2048	2048	2048	1024	2048	2048
ВВОД/ВЫВОД
Количество слотов	2	3	4	4	4	4	4	8	7	7	7	7	15	8	8	15
Периферийные интерфейсы	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI
Максимальная емкость внутренних дисков (Гб)	2	6	6	4	13.5	13.5	13.5	27	27	27	27	27	8	4	4	18
Максимальная емкость дисковой памяти (Гб)	30	70	70	274	279	279	279	499	499	499	499	499	953	476	476	476
Максимальная емкость дисков включая RAID (Гб)	194	294	294	331	336	336	336	613	613	613	613	613	1150	590	590	1160
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	78.8	90.5	90.5	70.3	99.3	114.3	130.2	57.5	73.3	97.6	121.6	122.4	131	57.5	122.4	134.1
SPECfp92	90.4	100.8	100.8	121.1	187.2	205.3	266.6	99.2	134.6	203.9	259.7	250.7	279	99.2	250.7	273.8
MFLOPS (Linpack DP)	15.1	20.3	22.7	25.9	49.7	55.1	-	22.2	38.1	101.1	131.1	132	141.6	22.2	132.0	141
tpmC	310	486	-	495	675	902	1000	395	510	600	726	1122	780	395	1122	1470
K$/tpmC	1.2	0.654	-			0.9		1.4			1.4	0.97				0.9
tpsA								128.5	157.2				275.7
K$/tpsA								8.5	9.2				7
SPECint_base95		2.37	3.85
SPECfp_base95		2.97	3.50

Основные характеристики серверов отделов компании SUN Microsystems

МОДЕЛЬ	SPARCserver 1000E	SPARCcenter 2000E
ЦП
Тип процессора	SuperSPARC
Тактовая частота (МГц)	85	85	85	85	85	85
Число процессоров	2	4	8	2	12	20
Системная шина (бит)	64	64	64	64	64	64
Размер кэша (Кб)	36/1024	36/1024	36/1024	36/2048	36/2048	36/2048
(в процессоре/на плате)	per CPU	per CPU	per CPU	per CPU	per CPU	per CPU
Пропускная способность системной шины (Мб/сек)	250	250	250	500	500	500
ПАМЯТЬ
Минимальный объем (Мб)	32	64	64	64	64	64
Максимальный объем (Мб)	2048	2048	2048	5120	5120	5120
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus	Sbus	Sbus	Sbus	Sbus
Количество слотов	3-12	3-12	3-12	4-40	4-40	4-40
Максимальная пропускная способность подсистемы в/в (Мб/сек)	90	90	90	180	180	180
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Стандартная емкость дисковой памяти (Мб)	1050, 2100	1050,2100	1050,2100	1050,2100	1050,2100	1050,2100
Максимальная емкость дисковой памяти (Гб)	764	764	764	4860	4860	4860
Количество последовательных портов	2-8	2-8	2-8	2-10	2-10	2-10
Сетевые интерфейсы основной/дополнительные	Ethernet, FDDI,ATM, TokenRing, FastEthernet	Ethernet, FDDI,ATM, TokenRing, FastEthernet
ПРОИЗВОДИТЕЛЬНОСТЬ
Транзакция/сек	-	-	10400	-	-	27440
NFS op/sec	-	-	3950	1750	5950	6700
SPECrate_int92	5988	11508	21758	6546	35332	57997
SPECrate_fp92	5805	11322	20851	6284	35948	54206
SPECrate_base_int92	5480	10557	20225	5875	33067	53714
SPECrate_base_fp92	5232	9943	18741	5742	32531	51489
AIM III (job/minute/)	2037/	3654/	6062/	2237/	9637/	12104/
users	1849	3327	5386	2028	8004	9436

МОДЕЛЬ	Enterprise 3000	Enterprise 4000
ЦП
Тип процессора	UltraSPARC
Тактовая частота (МГц)	167	167	167	167	167	167
Число процессоров	2	4	6	8	10	12
Размер кэша (Кб)	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512
(в процессоре/на плате)	per CPU	per CPU	per CPU	per CPU	per CPU	per CPU
Пропускная способность системной шины (Гб/сек)	2.5	2.5	2.5	2.5	2.5	2.5
ПАМЯТЬ
Минимальный объем (Мб)	64	64	64	64	64	64
Максимальный объем (Гб)	6	6	6	12	12	12
ВВОД/ВЫВОД
Количество слотов	3-9SBus	3-9SBus	3-9SBus	3-21SBus	3-21SBus	3-21SBus
Максимальная пропускная способность платы в/в (Мб/сек)	200	200	200	200	200	200
Периферийные интерфейсы	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2
Максимальная емкость внутренних дисков (Гб)	42	42	42	16.8	16.8	16.8
Максимальная емкость дисковой памяти (Тб)	2+	2+	2+	4+	4+	4+
Сетевые интерфейсы основной/дополнительные		10/100Мб/с, FDDI, ATM, TokenRing	Ethernet		10/100Мб/с, FDDI, ATM, TokenRing	Ethernet
ПРОИЗВОДИТЕЛЬНОСТЬ
TPC-C	-	-	-	-	-	11466
$/tpmC	-	-	-	-	-	189
NFS op/sec	3629	6113	8103	10151	12031	13536
SPECrate_int92	11550	22850	34817	44670	55140	65327
SPECrate_fp92	16170	31920	46309	62370	77190	91702
AIM III (job/minute/)	2982/	6090/	9280/	12180/	14790/	18560/
users	2632	5022	7440	9176	10666	11453

Основные характеристики серверов предприятий компании SUN Microsystems

МОДЕЛЬ	Enterprise 5000	Enterprise 6000
ЦП
Тип процессора	UltraSPARC
Тактовая частота (МГц)	167	167	167	167	167	167
Число процессоров	8	10	12	10	16	24
Размер кэша (Кб)	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512
(в процессоре/на плате)	per CPU	per CPU	per CPU	per CPU	per CPU	per CPU
Пропускная способность системной шины (Гб/сек)	2.5	2.5	2.5	2.5	2.5	2.5
ПАМЯТЬ
Минимальный объем (Мб)	64	64	64	64	64	64
Максимальный объем (Гб)	14	14	14	30	30	30
ВВОД/ВЫВОД
Количество слотов	3-21SBus	3-21SBus	3-21SBus	3-45SBus	3-45SBus	3-45SBus
Максимальная пропускная способность платы в/в (Мб/сек)	200	200	200	200	200	200
Периферийные интерфейсы	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2
Максимальная емкость внутренних дисков (Гб)	216	216	216	162	162	162
Максимальная емкость дисковой памяти (Тб)	6+	6+	6+	10+	10+	10+
Сетевые интерфейсы основной/дополнительные		10/100Мб/с FDDI, ATM, TokenRing	Ethernet		10/100Мб/с FDDI, ATM, TokenRing	Ethernet
ПРОИЗВОДИТЕЛЬНОСТЬ
TPC-C	-	-	11466	-	-	17000
$/tpmC	-	-	191	-	-	-
NFS op/sec	10151	12031	13536	-	17771	21014
SPECrate_int92	44670	55140	65327	55140	86520	127913
SPECrate_fp92	62370	77190	91702	77190	118120	165385
AIM III (job/minute/)	12180/	14790/	18560/	-	23200/	33640/
users	9176	10666	11453	-	15000	15000

Основные характеристики серверов рабочих групп компании SUN Microsystems

МОДЕЛЬ	SPARCserver 5	SPARCserver 20
	Model 110	Model 71	Model712MP	Model151	Model152MP
ЦП
Тип процессора	microSPARC II	SuperSPARC-II		hyperSPARC
Тактовая частота (МГц)	110	75	75	150	150
Число процессоров	1	1	2	1	2
Системная шина (бит)	64	64	64	64	64
Размер кэша (Кб)	24	36/1024	36/1024	8/512	8/512
(в процессоре/на плате)			per CPU	per CPU	per CPU
Пропускная способность системной шины (Мб/сек)	105	105	105	105	105
ПАМЯТЬ
Минимальный объем (Мб)	32	32	64	64	64
Максимальный объем (Мб)	256	512	512	512	512
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus	Sbus	Sbus	Sbus
Количество слотов	3	4	4	4	4
Максимальная пропускная способность подсистемы в/в (Мб/сек)	52	52	52	52	52
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	4.2	4.2	4.2	4.2	4.2
Максимальная емкость дисковой памяти (Гб)	118	339	339	339	339
Количество последовательных портов	2	2	2	2	2
Количество параллельных портов	1	1	1	1	1
Сетевые интерфейсы основной/дополнительные	Ethernet/FDDI, ATM, Token Ring, FastEthernet	Ethernet FDDI, ATM, Token Ring, FastEthernet	Ethernet/ FDDI, ATM, Token Ring, FastEthernet	Ethernet/ FDDI, ATM, Token Ring, FastEthernet	Ethernet/ FDDI, ATM, Token Ring, FastEthernet
ПРОИЗВОДИТЕЛЬНОСТЬ
Транзакция/сек	145	200	305	240	315
SPECrate_int92	1864	2984	5726	4018	7310
SPECrate_fp92	1549	2875	5439	4938	8758
SPECrate_base_int92	1630	2761	5332	3734	7004
SPECrate_base_fp92	1494	2595	4923	4464	7945

МОДЕЛЬ	Model 140	Ultra Enterprise 1 Model 170	Model 170E	Ultra Enterprise 150	Model 1170
ЦП
Тип процессора					UltraSPARC-1
Тактовая частота (МГц)	143	167	167	167	167	167	200	200
Число процессоров	1	1	1	1	1	2	1	2
Системная шина (бит)	128/256	128/256	128/256	128/512	128/512	128/512	128/512	128/512
Размер кэша (Кб) (в процессоре/на плате)	16+16/512 per CPU	16+16/512 per CPU	15+16/512 per CPU	16+16/512 per CPU	16+16/512 per CPU	16+16/512 per CPU	16+16/1024	16+16/1024
Пропускная способность системной шины (Мб/сек)	1300	1300	1300	1300	1300	1300	1300	1300
ПАМЯТЬ
Минимальный объем (Мб)	32	32	32	32	64	64	64	64
Максимальный объем (Мб)	1024	1024	1024	1024	2048	2048	2048	2048
ВВОД/ВЫВОД
Количество слотов	3 SBus	3 SBus	2 SBus 1 UPA	2 SBus	4 SBus 1 UPA	4 SBus 1 UPA	4 SBus 1 UPA	4 SBus 1 UPA
Периферийные интерфейсы	Fast SCSI-2	Fast SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2
Минимальная емкость дисковой памяти (Гб)	4.2	4.2	4.2	4.2	4.2	4.2	4.2	4.2
Максимальная емкость дисковой памяти (Гб)	324	324	324	324	1024	1024	1024	1024
Количество последовательных портов	2	2	2	2	2	2	2	2
Количество параллельных портов	1	1	1	1	1	1	1	1
Сетевые интерфейсы основной/дополнительные	10Мбит/с Ethernet/ FDDI, ATM, Token Ring	10Мбит/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring
ПРОИЗВОДИТЕЛЬНОСТЬ
Транзакция/сек	1250	1332	1332	1332	1350	2350	1500	2750
SPECint92	215	252	252	252	252	252	332	332
SPECfp92	303	351	351	351	351	351	505	505
SPECrate_int92	5107	5982	5982	5982	-	-	-	14962
SPECrate_fp92	7175	8323	8323	8323	-	-	-	18675
AIM 3	1305	1450	1450	-	-	-	-	-
Laddis	1812	2102	2102	-	2102	2536	2565	4303

Основные особенности итологии

Предметом итологии являются ИТ, представляемые
в двух видах:

в формальном, в виде спецификаций ИТ;
в виде ИТ-систем, т.е. реализаций спецификаций
ИТ.

Предметом итологии являются динамические развиваемые
сущности.


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

Общезначимая научная дисциплина, играющая такую
же важную междисциплинарную роль как математика или философия.
При этом роль итологии должна рассматриваться:

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

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

Основные свойства Rational Rose

охват всех этапов разработки проекта;
построение моделей на основе методов Буча и OMT с возможностью
автоматического преобразования нотаций;
возможность повторного использования программных разработок
пользователей за счет средств реинжениринга;
наличие средств автоматического контроля, позволяющих вести
отладку проекта по мере его разработки;
возможность описания проекта на разных уровнях для различных
категорий пользователей;
удобный для пользователя графический интерфейс;
автоматическая генерация кодов на языках С++, Ada (компиляторы
поставляются), Smalltalk, SQLWindows, VisualBasic, PowerBuilder;
наличие средств групповой разработки;
широкий спектр применения системы - базы данных, банковские
системы, телекоммуникация, системы реального времени, большие
информационные системы и т.д.

PA-RISC (Precision Architecture)

Этапы развития архитектуры PA-RISC:

1986 г.	PA - RISC 1.1
1992 г.	РА - 7100, 33, 50, 99 МГц
1993 г.	РА - 7100 LC, 64, 80, 100 МГц
1994 г.	РА - 7150, 125 МГЦ
	РА - 7200, 90, 100 МГц
1996 г.	РА - 8000, 200 МГц
1998 г.	? VLIW-архитектура совместно с Intel

Блок-схема процессора PA 7100

Параллелизм на уровне выполнения

CPI конвейера = CPI идеального
конвейера +
+ Приостановки
из-за структурных конфликтов +
+ Приостановки
из-за конфликтов типа RAW +
+ Приостановки
из-за конфликтов типа WAR +
+ Приостановки
из-за конфликтов типа WAW +
+ Приостановки
из-за конфликтов по управлению

Метод	Снижает
Разворачивание циклов	Приостановки по управлению
Базовое планирование конвейера	Приостановки RAW
Динамической планирование с централизованной схемой управления	Приостановки RAW
Динамическое планирование с переименованием регистров	Приостановки WAR и WAW
Динамическое прогнозирование переходов	Приостановки по управлению
Выдача нескольких команд в одном такте	Идеальный CPI
Анализ зависимостей компилятором	Идеальный CPI и приостановки по данным
Программная конвейеризация и планирование трасс	Идеальный CPI и приостановки по данным
Выполнение по предположению	Все приостановки по данным и управлению
Динамическое устранение неоднозначности памяти	Приостановки RAW, связанные с памятью

Планирование загрузки конвейера:

Команда, вырабатыва-ющая результат	Команда, использующая результат	Задержка в тактах
Операция АЛУ с ПТ	Другая операция АЛУ с ПТ	3
Операция АЛУ с ПТ	Запись двойного слова	2
Загрузка двойного слова	Другая операция АЛУ с ПТ	1
Загрузка двойного слова	Запись двойного слова	0

Loop: LD F0,0(R1)
;F0=элемент вектора

ADDD F4,F0,F2
;добавляет скаляр из F2

SD 0(R1),F4
;запись результата

SUBI R1,R1,#8
;пересчитать указатель


;8 байт (в двойном слове)

BNEZ R1, Loop
;переход R1!=нулю
Цикл без планирования загрузки конвейера:

Такт
выдачи

Loop: LD F0,0(R1)
1

приостановка
2

ADDD F4,F0,F2
3

приостановка
4

приостановка
5

SD 0(R1),F4
6

SUBI R1,R1,#8
7

BNEZ R1,Loop
8

приостановка
9

Скорость работы цикла: 9 тактов на элемент
Оптимизированный цикл:

Loop: LD F0,0(R1) 1

приостановка
2

ADDD F4,F0,F2
3

SUBI R1,R1,#8
4

BNEZ R1,Loop ;задержанный
переход 5

SD 8(R1),F4 ;команда
изменяется, когда 6

;меняется
местами с командой SUB1


Скорость работы цикла: 6 тактов на элемент
Развернутый 4 раза цикл без оптимизации:

Loop: LD F0,0(R1)

ADDD F4,F0,F2

SD 0(R1),F4
;выбрасывается SUB1 и BNEZ

LD F6,-8(R1)

ADDD F8,F6,F2

SD -8(R1),F8
;выбрасывается SUB1 и BNEZ

LD F10,-16(R1)

ADDD F12,F10,F2

SD -16(R1),F12
;выбрасывается SUB1 и BNEZ

LD F14,-24(R1)

ADDD F16,F14,F2

SD -24(R1),F16

SUB1 R1,R1,#32

BNEZ R1, Loop

Скорость работы цикла: 6.8 такта на элемент
Развернутый 4 раза цикл после оптимизации:

Loop: LD F0,0(R1)

LD F6,-8(R1)

LD F10,-16(R1)

LD F14,-24(R1)

ADDD F4,F0,F2

ADDD F8,F6,F2

ADDD F12,F10,F2

ADDD F16,F14,F2

SD 0(R1),F4

SD -8(R1),F8

SD -16(R1),F12

SUB1 R1,R1,#32

BNEZ R1, Loop

SD 8(R1),F16
; 8 - 32 = -24

Скорость работы цикла: 3.5 такта на элемент

Передача данных от пользователя к обработчику

Передача данных от удаленного пользователя системы к программе обработчику идет через сеть
Internet на основе интерфейса Windows CGI. Все данные введенные пользователем вначале
передаются WWW серверу, который преобразует их к формату, отвечающему требованиям
стандарта CGI, и передает их программе обработчику, названному выше клиентским
приложением, Данные от удаленного клиента к WWW серверу поступают на основе протокола
HTTP (Hypertext Transfer Protoсol).

Данные передаваемые WWW сервером обработчику можно разделить на две группы, исходя из
источника их получения:

Информация о клиенте, Она включает в себя такие данные как URL адрес удаленного
клиента, его средство навигации по Internet, операционную систему, метод доступа, используемый
клиентом, регистрационные данные пользователя и прочую подобную информацию. Данные
такого рода используются обработчиком для настройки на конкретного клиента.
Информация введенная пользователем в HTML документ. Для осуществления ввода данных в
HTML документы, для их последующей передачи WWW серверу используется язык HTML второго
уровня, который допускает размещение в документе стандартных объектов диалога. Для этого в
HTML второго уровня используется тэг FORM, внутри которого и размещаются тэги,
соответствующие объектам диалога. Для передачи введенных данных HTML предусматривает
использование одного из двух основных методов передачи: GET и POST. Взаимодействие с
использованием метода GET происходит гораздо быстрее, но этот метод в соответствии со
стандартом CGI рекомендуется использовать только, если в результате обработки данных не
произойдет никаких изменений в окружающем мире. В соответствии со стандартом CGI при
использовании метода GET данные введенные пользователем, помещаются в переменную
окружения QUERY_STRING в виде поле1=значение1 & поле2=значение2... с заменой пробелов на
символ '+', а специальных символов на их коды. При использовании метода POST
преобразованные, как и при использовании метода POST, данные поступают в стандартный поток
ввода обработчика. Стандарт Windows CGI при использовании обоих методов помещает значение
переменной QUERY_STRING в раздел [CGI] файла данных, а при использовании метода POST
WWW сервер еще и декодирует строку - значение этой переменной и помещает пары поле-значение
в раздел [Form Literal файла данных, а при необходимости, также и в разделы [Form External] и
[Form Huge].

Переработка результатов SQL запроса и передача их пользователю

Данные получаемые клиентским приложением от серверного приложения подвергаются
дальнейшей обработке. Так как удаленный клиент системы использует одно из средств навигации
по Internet, и согласно стандарту Windows CGI, WWW серверу должен быть передан документ
одного из MIME типов. Исходя из того, что передаваемые данные представляют собой строки
символов , и необходимости разбиения результатов для удобства их анализа на несколько файлов,
для возвращаемых документов был выбран MIME тип "text/html".

Клиентское приложение получает данные от серверного приложения в виде записей, разделенных
символом STRUCTDELIMITER. Поля записи разделены символом FIELDDELIMITER.
Клиентское приложение получает из файла данных CGI имя и путь доступа к файлу, который
должен быть передан WWW серверу, создает этот файл и записывает в него строку,
идентифицирующую MIME тип документа: Content-type text/html. Далее полученную первую
порцию данных от серверного приложения клиентское приложение после декодировки записей и
полей записывает в созданный файл. Клиентское приложение, анализируя полученный от
серверного приложения признак, получает информацию о наличии дополнительной группы
данных, Если серверное приложение готово передать следующую часть данных, то клиентское
приложение создает временный файл и помещает в первый файл после данных ссылку на
созданный файл, то есть указывая его URL. Затем клиентское приложение получает от серверного
приложения и записывает в файл следующую порцию данных. Эти операции, включая создание
очередных файлов, повторяются пока серверное приложение передает результирующее множество
клиентскому приложению. В результате этого создается цепочка HTML файлов, которые
удаленный пользователь может последовательно просматривать с помощью своего средства
навигации по Internet ( Netscape, Microsoft Internet Explorer и т.д.), Просмотр цепочки документов
в прямом направлении обеспечивается наличием встроенных в документы ссылок на следующий
документ, а просмотр в обратном направлении поддерживается встроенной в навигаторы
возможностью отката к предыдущему документу.

Перспективы использования Delphi

При построении систем масштаба предприятия практически невозможно избежать
неоднородности (разные ОС, СУБД, промежуточное ПО и т.п.). Встает вопрос о средствах
объединения разных технологических платформ. Достаточно четко можно разбить архитектурно
грамотную информационную систему на три "модуля" - клиентский, сервер приложений и БД.

В рамках новой инициативы Golden Gate, Borland объединяет уже имеющиеся технологии с
достижениями Open Environment Corporation - OEC (приобретена компанией Borland) в области
средств для построения многоуровневых, распределенных систем. Продукт OEC OLEnterprise
обеспечивает распределенные вычисления на базе технологий OLE automation / RPC (Remote
Procedure Call) поверх D-COM и в отсутствии такового на всех платформах Windows (в том числе
Win16). Полная автоматизация импорта/экспорта объектов в сети позволяет избежать
необходимости изменения кода приложений для их взаимодействия на разных участках сети.

В силу того, что Delphi полностью поддерживает OLE-automation и предоставляет
высокоуровневые средства работы с этими механизмами (специализированные классы, эксперты,
языковые расширения), вариант совместного использования Delphi & OLEnterprise может оказать
решающее воздействие на архитектуру системы => распределенные вычисления и локальные
рабочие места - все в одном коде.


OEC Architecture

Так как Delphi обеспечивает создание "чистого" (native) кода посредством компиляции (например
в самодостаточную - без интерпретатора - динамическую библиотеку DLL), возможна тонкая
интеграция полученных программных модулей не только с 3-ми клиентскими приложениями но и с
серверами приложений и баз данных на платформах Windows (в большей степени Windows NT, как
следствие ее приспособленности для поддержки серверных звеньев). В качестве примера можно
привести построение определяемых пользователем функций UDF для серверов БД Borland
InterBase (например, для специфической обработки BLOB-полей).

Главной целью Golden Gate является объединение лучших черт архитектуры клиент/сервер и

модели intranet. И первым этапом ее реализации является добавление средств интеграции с
Internet-технологиями в уже имеющиеся средства разработки. Delphi не является исключением.
Выпущенная летом 1996 года обновленная версия Delphi 2.01 включает поддержку модулей
сопряжения с Internet для Windows 95/NT - WinINET; возможность построения блоков расширения
Microsoft Information Server через интерфейсы ISAPI & ISAPI Filter; 8 элементов ActiveX,
полностью реализующих логику поддержки основных Internet-протоколов и HTML (обработка +
отображение => построение броузеров) в виде повторно используемых компонентов.


ActiveX

С этих точек зрения, гибкость такого инструмента корпоративного разработчика, как Delphi
становится не менее важным фактором, чем возможность стандартизации бизнес-логики и
организации бизнес-процессов, но это уже тема для другого доклада.


Golden Gate


Delphi 2.0

Software Digest March 1996, NSTL

Client-Server Development Tools
RatingProductPerformanceVersatilityEase of Use"Delphi's performance is head and shoulders above all of its competitors"

****	Delphi	9.6	9.2	7.3
***	Visual Basic	8.3	8.2	6.9
**	SQL Windows	5.2	9.1	6.7
**	Power Builder	5.4	7.8	6.8

[]
[]
[]

Поддержка разнообразных клиентов

Клиентская часть включена в поставку
MS-DOS, Windows, Windows for Workgroups, Windows 95, OS/2, Macintosh, Netware, UNIX
Windows NT Workstation - защищенный клиент

Пользователи и группы

Учетные записи: локальные и глобальные
Встроенные учетные записи
Группы: локальные и глобальные
Встроенные группы
Пользовательские профили
Сценарии регистрации в сети
Использование домашнего каталога

Потоки (streams)

UNIX System V

библиотека TLI (Transport Layer Interface)
транспортный сервис на основе стека протоколов TCP/IP

Позволяют организовывать разнообразные виды коммуникации
процессов
Многообразие и сложность набора функций библиотеки
TLI
Относится к теме реализаций семиуровневой модели
ISO/OSI

Потребности применений

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

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

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

Интеграция систем. Системы эволюционируют от простых, автономных подсистем к более
сложным, интегрированным системам, основанным на интероперабельном взаимодействии
компонентов.

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

Миграция унаследованных систем. Любая система после создания противодействует изменениям и
имеет тенденцию быстрого превращения в бремя организации (т.н. legacy systems - унаследованные
системы, использующие "уставшие" технологии, архитектуры, платформы, а также собственно

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

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

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

Существенно, что свойство интероперабельности информационных ресурсов является
необходимой предпосылкой удовлетворения перечисленных требований.

Архитектура промежуточного слоя (middleware)

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

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


пользовательского интерфейса и др. Такие инфраструктуры использовались как отдельными
компаниями (IBM), так и в международных проектах (UNIX - ориентированная интеграционная
среда) . Применяемые идеи и технологии не позволяли до сих пор решить
радикально архитектуру промежуточного слоя.

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

Объектная модель OMG. Объектная модель OMG определяет общую объектную семантику для
спецификации базовыx характеристик объектов стандартным, независимым от реализации
образом.

Объектная модель OMG определяется в виде объектной модели -- ядра (Core Object Model (COM))
и совокупности расширений. Объектная модель -- ядро специфицирует некоторый набор базовых
понятий. Примерами понятий COM являются объекты, операции, типы, отношение тип/подтип,
наследование, интерфейс типа. Каждое расширение вводит дополнительный набор понятий.
Расширяться может либо COM, либо уже существующие и согласованные расширения.


При этом
вводится понятие профиля, как некоторой комбинации COM и одного, или нескольких
расширений, вместе поддерживающих определенную целевую архитектуру.

Эталонная модель архитектуры OMG. Эталонная Модель определяет
концептуальную схему для поддержки технологии, удовлетворяющей техническим требованиям
OMG. Она идентифицирует и характеризует компоненты, интерфейсы и протоколы, составляющие
Архитектуру Управления Объектами OMG (Object Management Architecture (OMA)), не определяя,
впрочем, их детально.

Согласованная с OMA прикладная система состоит из совокупности классов и экземпляров,
взаимодействующих при помощи Брокера Объектных Заявок (Object Request Broker (ORB)).
Объектные Службы (Object Services) представляют собой коллекцию служб, снабженных
объектными интерфейсами и обеспечивающих поддержку базовых функций объектов. Общие
Средства (Common Facilities) образуют набор классов и объектов, поддерживающих полезные во
многих прикладных системах функции. Прикладные объекты представляют прикладные системы
конечных пользователей и обеспечивают функции, уникальные для данной прикладной
системы.

Пример устранения конфликтов компилятором

Последовательность операторов:
a = b + c
d = e - f

Неоптимизированнаяпоследовательность команд	Оптимизированнаяпоследовательность команд
LW Rb,b	LW Rb,b
LW Rc,c	LW Rc,c
ADD Ra,Rb,Rc	LW Re,e
SW a,Ra	ADD Ra,Rb,Rc
LW Re,e	LW Rf,f
LW Rf,f	SW a,Ra
SUB Rd,Re,Rf	SUB Rd,Re,Rf
SW d,Rd	SW d,Rd

Принципы организации основной памяти

Производительность основной памяти:

задержка
полоса пропускания

Задержка памяти:

время доступа (access time)
длительность цикла (cycle time)

Основные типы ЗУПВ:

СЗУПВ
ДЗУПВ

Обращение к ДЗУПВ:

RAS (row-access strobe) - строб адреса строки
CAS (column-access strobe) - строб адреса столбца

Временные параметры ДЗУПВ
(в последней строке приведены ожидаемые параметры):

Год появления	Емкость кристалла	Длительность RAS	Длительность CAS	Время цикла	Оптими-зированный режим
		max	min
1980 1983 1986 1989 1992 1995?	64 Кбит 256 Кбит 1 Мбит 4 Мбит 16 Мбит 64 Мбит	180 нс 150 нс 120 нс 100 нс 80 нс 65 нс	150 нс 120 нс 100 нс 80 нс 60 нс 45 нс	75 нс 50 нс 25 нс 20 нс 15 нс 10 нс	250 нс 220 нс 190 нс 165 нс 120 нс 100 нс	150 нс 100 нс 50 нс 40 нс 30 нс 20 нс

Увеличение полосы пропускания:

увеличение разрядности
расслоение памяти
использование специфических свойств ДЗУПВ:

блочный режим (nibble mode)
страничный режим (page mode)
режим статического столбца (static column)

оптимизация интерфейса между ДЗУПВ и ЦП (RAMBUS)

Проблема защиты информации в Internet

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

Наивные способы защиты, такие, как запрос пароля с последующей передачей его в открытом виде
по коммуникационному каналу, и простые списки доступа (access list) на серверах и
маршрутизаторах, становятся малоэффективными в условиях прогрессивной коммерциализации
Internet. Что же может быть противопоставлено квалифицированной и технически вооруженной
атакующей стороне?

Технологией, предлагающей необходимые для применения в масштабах Internet универсальность и
общность, представляется существующая на сегодняшний день в виде промышленного стандарта
Sun Microsystems и проекта стандарта Internet (draft RFC, Request for comments) спецификация,
сокращенно называемая SKIP (Simple Key management or Internet Protocol - Простой протокол
управления ключами в интерсети). Эта спецификация была разработана компанией Sun
Microsystems в 1994 году и предложена в качестве стандарта Internet.

Процессоры с архитектурой 80х86 и Pentium

Этапы развития архитектуры 80 х 86:

1978 г.	- Intel 8086 (16 бит)
1980 г.	- Intel 8087 (сопроцессор ПТ)
1982 г.	- Intel 80286 (16 бит)
1987 г.	- Intel 80386 (32 бит)
1989 г.	- Intel 80486 (32 бит)
1993 г.	- Pentium (32 бит)

Рейтинг iCOMP:

Процессор	Тактовая частота (МГц)	Рейтинг iCOMP
386SX 386SL 386DX 386DX i486SX i486SX i486SX i486DX i486DX2 i486DX i486DX2 i486DX4 i486DX4 Pentium Pentium Pentium Pentium Pentium Pentium	25 25 25 33 20 25 33 33 50 50 66 75 100 60 66 90 100 120 133	39 41 49 68 78 100 136 166 231 249 297 319 435 510 567 735 815 1000 1200

Особенности Р6:

4-5 миллионов транзисторов
200 МГц (200 MIPS)
неупорядоченное выполнение команд
переименование регистров
расширение суперскалярных возможностей

Программные гнезда (sockets)

Поддерживаемый ядром механизм, скрывающий особенности
сетевой среды и позволяющий единообразно взаимодействовать процессам

выполняющимся на одном компьютере
в пределах одной локальной сети
разнесенным на разные компьютеры территориально распределенной
сети

Первое решение:

UNIX BSD 4.1 в 1982 г.

Три составляющих:

компонент уровня программных гнезд (независящий
от сетевого протокола и среды передачи данных)
компонентом протокольного уровня (независящий от среды передачи
данных)
компонентом уровня управления сетевым устройством

Программные каналы

Создание неименованного программного канала
pipe(fdptr);

fdptr
- это указатель массива из двух целых чисел для размещения дескриптора
для чтения из программного канала (с помощью read)
и записи в программный канал (с помощью write)
обычные дескрипторы файлов
два элемента таблицы открытых файлов процесса

Создание именованных программных каналов
(или получение доступа к существующим)
Обычный системный вызов open

если канал открывается на запись, и ни один процесс
не открыл его для чтения, то процесс блокируется до тех пор, пока
некоторый процесс не откроет этот канал для чтения
аналогично обрабатывается открытие для чтения
имеется флаг NO_DELAY

Запись и чтение: read
и write

при записи данные помещаются в начало канала
при чтении выбираются из конца канала
возможны откладывания процессов

Окончание работы процесса: close

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

Протокол SKIP

Почему же SKIP представляется решением, адекватным задачам защиты информации в масштабах
такой сети, как Internet?

Прежде всего потому, что SKIP IP-совместим. SKIP аппаратно независим. Протокол
имплементируется в IP-стек выше аппаратно-зависимой его части и работает на всех тех каналах,
на которых работает IP.

Принадлежность SKIP к IP-стеку обеспечивает прозрачность этого протокола для приложений:
SKIP обрабатывает IP-пакеты, не накладывая никаких ограничений на вышележащее программное
обеспечение. В свою очередь, приложения никак не "чувствуют" SKIP.

SKIP сеансонезависим: для организации защищенного взаимодействия между парой абонентов не
требуется никакого дополнительного информационного обмена и не требуется передачи по
каналам связи какой-либо открытой информации.

В основе SKIP лежит криптография открытых ключей Диффи-Хеллмана.

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

---

---