Индустрия программирования

           

Концепция визуального программирования в IBM VisualAge Smalltalk



В.Орлов, IBM
VisualAge - это мощная среда для разработки приложений для архитектуры клиент-сервер. Она
ориентирована, прежде всего, на разработки бизнес-приложений, включая системы для
онлайновой обработки транзакций и системы поддержки решений. VisualAge позволяет
профессиональным разработчикам строить клиентские части прикладных систем со сложным
графическим интерфейсом, проектировать деловую логику работы приложений с доступом к
локальным и удаленным ресурсам. VisualAge представляет собой чисто обьектно-
ориентированное средство разработки, включающее набор визуальных интерактивных
инструментов, библиотеку готовых компонент и набор средств для построения клиент-
серверной среды. Поддержка графического интерфейса, предоставляемая готовыми
компонентами, отвечает CUA (Common User Access) спецификациям и содержит ряд
расширений для организации гибкого ввода-вывода в сложных формах и таблицах. Библиотека
готовых компонент предоставляет также поддержку устройств

мультимедиа, коммуникаций через протоколы APPC, TCP/IP, NetBIOS, программных
интерфейсов CICS External Call Interface, EHLLAPI, Message Queue Interface (MQI), работу с
реляционными базами данных семейств DB2, Oracle, Sybase и многое другое. Прежде чем
перейти к описанию визуального построения приложений, отметим ряд замечательных качеств
VisualAge, таких как повторное использование кода, поддержка моделей SOM и DSOM,
возможности групповой разработки приложений с использованием центрального репозитория.




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

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

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

Для VisualAge таким языком является чисто обьектно-ориентированный язык IBM Smalltalk.
Сама среда разработки VisualAge создана на Smalltalk. Среди разнообразных средств
визуального программирования VisualAge интересен именно максимально продвинутой и
последовательно реализованной концепцией обьекто-ориентированной технологии.

Приложения написанные на Smalltalk соответствуют схеме MVC (Model-View-Controller). Model
является набором объектов, выражающих бизнес-логику приложения, View представляет
объекты из пользовательского интерфейса, Controller состоит из объектов преобразующих
действия пользователя с View в запросы к Model.

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

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

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

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

Видимая деталь - деталь, имеющая видимое представление во
время исполнения программы.


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

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

Атрибут - Атрибут соединяет два значения данных таким образом, что
при изменении одного из них так же изменяется и другое.
Событие - Действие вызывает выполнение действия при возникновении
события.
Событие - Встроенная программа запускает выполнение встроенной
программы при возникновении события.
Атрибут - Встроенная программа запускает выполнение встроенной
программы когда значение атрибута должно быть вычислено.
Такое представление о деталях в системе VisualAge позволяет реализовать концепцию
визуального объекно-ориентированного программирования. Объекно-ориентированного -
потому что детали являются полноценными программными объектами со свойствами сокрытия
данных, многообразности и наследования.



Для иллюстрации построим несколько простых приложений.

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


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

на рабочую область.


Для запоминания списка выбрана невидимая деталь Ordered Collection (Упорядоченная
коллекция), которая позволяет добавлять и удалять объекты любого типа. Логику
взаимодействия деталей можно описать следующим предложением: "При нажатии кнопки Add
добавить содержимое поля ввода в Упорядоченную коллекцию и отображать находящееся в
ней в Списке; при нажатии кнопки Remove удалить выделенный элемент Списка из
Упорядоченной коллекции". В соответствии с этим установим связи между деталями. При
нажатии кнопка генерирует событие 'clicked'
.Свяжем
это событие с действием 'add' (добавить), выполняемым Упорядоченной коллекцией



Штриховая линия говорит о том, что параметр для вызываемого действия не указан. Так как в
коллекцию добавляется содержимое поля ввода, свяжем атрибут 'object' поля ввода с
атрибутом 'anObject' связи Кнопка-Упорядоченная Коллекция.


Для того, чтобы содержимое Колекции отображалось в Списке, соединим атрибуты '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 152MPModel 514MPModel 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 RingEthernet/FDDI, Token Ring Ethernet/FDDI, Token RingEthernet/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
11-2
1-41-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
ЦП
Тип процессора POWERPOWERPOWER POWERPOWERPOWER POWER POWERPOWER POWER POWER POWERPOWER 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/12832/32 32/64 32/25632/25632/12832/25632/32 32/12832/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 310486 - 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.59.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/204836/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,21001050,21001050,21001050,21001050,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 Model151Model152MP
ЦП     
Тип процессора 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 Ring10/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"
****Delphi9.69.27.3
***Visual Basic8.38.26.9
**SQL Windows5.29.16.7
**Power Builder5.47.86.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 Время циклаОптими-зированный
режим
  maxmin 
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-
пакеты) и аутентификацию (достоверную идентификацию источника) информации. Режимы
инкапсуляции и шифрования могут применяться как совместно, так и раздельно.