Храмцов П.Б. Открытые системы

Подождите немного. Документ загружается.

пользователь запускает свою программу или сохраняет файл. Вторая

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

с собственно прикладной программой.

Функции, с которыми мы имеем дело в рамках этого элемента,

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

и характеристиками пользовательского интерфейса, которые

обеспечивают возможность безболезненного перехода пользователя с

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

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

команд и получения от системы однотипной информации, т. е, как уже

было сформулировано выше, с мобильностью персонала.

Вне зависимости от того, какая ЭВМ используется для данной

программной системы, реакция системы на одни и те же действия в

идеале должна быть идентичной. Это относится как к управляющим

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

данные. Такого рода ситуация существует всегда, когда используется

одна и та же операционная система, когда для вывода графических

данных применяется один и тот же графический стандарт и т.д.

Один из примеров реализации функций, определяемых элементом

"U" - это известный графический пользовательский интерфейс X

Windows. Интерфейс представляет собой реализацию концепции

обобщенного терминала, разработанной в рамках совместного проекта

МТИ (Массачузетского Технологического Института), Digital Equipment

Corp. и AT&T в течение 1985-1988 года. Система X Windows

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

на одном устройстве в нескольких различных окнах виртуальные

терминалы для разных заданий или программ. Интерфейс является

"прозрачным" для сетей, он разрабатывался как машинонезависимый и

принят в большинстве используемых сегодня операционных систем. В

1988 году был создан Х консорциум, объединивший основных

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

поддержавших стандарт X Windows, который взял на себя поддержку

его дальнейшей разработки, развития и сопровождения.

Технический комитет по компьютерной графике X3H3.6 ANSI

выбрал оконный протокол системы X Windows и функциональный

интерфейс X Lib в качестве исходных для создания своего стандарта

пользовательского интерфейса. NIST одобрил в качестве национального

стандарта США FIPS 158 протокол системы X Windows версии 11, X

Lib, инструментальный пакет Xt. Компания X/Open также приняла

основные компоненты системы X Windows как часть своей стандартной

среды Common Applications Environment.

Ряд коммерческих продуктов также построены на основе системы

X Windows. К числу таких продуктов относится графический

пользовательский интерфейс OPEN Windows фирмы SUN Microsistem.

Этот продукт создан по спецификации Open Look, разработанной

совместно SUN Microsystems и AT&T.

На основе X Windows версии 11 создан также графический

пользовательский интерфейс OSF/Motif. Корпорация OSF предоставляет

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

программного обеспечения и конечным пользователям.

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

язык Shell. Рабочей группой POSIX 1003.2 создан стандарт Shell,

обеспечивающий обращение к операционной системе как из программы

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

Обслуживание в системе (Service interfaces for programs).

Элемент S (Service interfaces for programs) включает интерфейсы

для взаимодействия прикладной программы с системными средствами

ЭВМ, на которой эта программа выполняется (аппаратура и программы).

Функции этого типа реализуются, главным образом, программами

операционной системы.

Этот элемент включает Интерфейсы для Прикладной Программы

(API - Application Programming Interfaces), с помощью которых

осуществляется прямое обращение к операционной системе, к

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

процессорам. Именно этот элемент наиболее сильно влияет на

мобильность и представляет наибольший интерес для программистов.

Языки программирования обеспечивают самую непосредственную

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

интерфейсами. Язык, который использован для написания прикладной

программы, устанавливает парадигму для описания этой программы, как

в терминах данных, так и в терминах функций.

Существует ряд требований, которым обязательно должны

удовлетворять языки. Они должны иметь средства для описания типов

используемых данных и определять допустимые диапазоны значений

этих данных. Именно различия в структуре таких описаний определяют

основные различия между языками. Как следствие этих различий,

определенные языки связаны со специфическими типами прикладных

программ.

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

последовательностью выполнения программы (циклы, передачи

управления), условные ветвления в точках принятия решений,

манипуляции с данными, операции ввода/вывода.

Особенности ввода/вывода являются еще одним значительным

свойством, по которому языки могут заметно отличаться. Так, для

КОБОЛ'а и PL/1 характерен индексно-последовательный доступ к

файлам (ISAM), однако для других языков стандартные способы доступа

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

пользователем.

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

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

данным языком и другими стандартами, которые с ним связаны. Так

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

из алгоритмического языка к графическим стандартам и стандартам

доступа к базам данных.

Языковые процессоры разрабатываются уже давно и хорошо

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

программирования. Так стандартом ISO 8652 описывается язык АДА.

Имеются стандарты на языки Pascal, Fortran77, PL/1. Стандартом ISO

9899, описан язык С.

Графические пакеты представлены стандартом GKS, ISO 7942

1985 (двумерная графика), GKS -3D ISO 8805-1988 (трехмерная графика,

PHIGS ISO 9592 (двумерная и трехмерная графика), а также

библиотекой X Lib, входящей в состав уже упомянутой системы X

Windows.

В таблице 1.1 приведены основные характеристики языков

программирования и их статус как международных стандартов, в

таблице 1.2 - отношение языков со стандартами ISO.

Обслуживание доступа к информации и форматы данных

(Information and Data Formats).

Элемент I (Information and Data Formats) объединяет средства,

обеспечивающие доступ к данным и обмен данными. Функции, которые

реализуются в рамках этого элемента, можно разбить на три основные

подгруппы:

- определение типов и способов представления данных, и доступ к

ним в прикладных программах;

- хранение и управление данными;

- поддержка форматов обмена данными.

Сюда же входят и средства, обеспечивающие объектно-

ориентированное представление данных. Функции, объединяемые этим

элементом, имеют решающее значение для обеспечения

интероперабельности в открытой (и в распределенной) системе. В

рамках элемента "I" обращение к файловой системе, в частности, может

осуществляться через систему IRDS (Data Depository and Management

System). Система обеспечивает разделение доступа к файлам между

различными заданиями как на локальной ЭВМ, так и через сеть.

Наиболее известным и широко используемым стандартом,

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

SQL. Существующий стандарт ISO 9075-1989 с дополнением ANSI

X3.168 определяет SQL интерфейс для всех основных языков

программирования. SQL обеспечивает доступ к СУБД ORACLE, Ingres,

SYBASE и другим.

Коммуникационные интерфейсы (Communications interfaces).

Элемент C (Comunications interfaces). Компоненты, объединяемые

в этот элемент, обеспечивают взаимодействие через локальные и

глобальные сети. Интерфейсы, которые соответствуют элементу C,

обеспечивают возможность соединения в неоднородных сетях.

Одним из наиболее значительных достижений информационных

технологий в девяностых годах является создание глобальных

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

информацией между разнородными вычислительными и

информационными системами. В этой области за прошедшее

десятилетие возник ряд решений, поддержанных в той или иной степени

международными стандартизующими организациями. Два их них,

которые стали наиболее известными: это модель ВОС (OSI) и протокол

TCP/IP (Transmission Control Protocol/Internet Protocol).

Совокупность стандартов, связанных с моделью ВОС, служит для

построения сетевой среды объединяющей разнородные ЭВМ и

вычислительные сети, реализованные на основе различных технологий.

На протяжении последних десяти лет были предприняты

гигантские усилия, которые привели к разработке нескольких сотен

новых международных стандартов, относящихся ко всем ВОС. Однако,

несмотря на такое изобилие новых стандартов, работа по их созданию

вряд ли когда-либо будет завершена - новые прикладные системы,

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

стандартов.

С точки зрения пользователя нижние уровни модели относятся к

типу применяемой локальной сети: Ethernet, Token Ring, FDDI и т.д., а

верхние уровни к таким службам, как передача файлов (стандарт

FTAM), электронная почта (X.400), каталогизация удаленных данных

(X.500).

Для того, чтобы реализовать действительно открытую систему,

недостаточно только обеспечить соответствие выбранным стандартам

OSI. Это связано с тем, что стандарты OSI предполагают значительную

гибкость и широкий набор функций и могут содержать много

дополнительных классов, наборов и параметров. Внедрение стандартов

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

снижению производительности систем или увеличению стоимости их

внедрения.

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

способствовавшим работам по международной модели OSI. В рамках

единого рынка необходимо, чтобы стандарты, которые были выбраны

для обеспечения совместимости, были одинаковы для всех.

Протокол TCP/IP (Internet) был разработан как набор

функциональных стандартов для военных сетей Соединенных Штатов и

стал общепринятым индустриальным стандартом де-факто. TCP/IP

предоставляет средства, определяемые транспортным уровнем модели

OSI, и ряд функций, обслуживающих пакетные передачи данных (почта,

передача файлов). TCP/IP организован как многоуровневая структура

протоколов более низкого уровня, которые определяют функции

низкого уровня, используемые прикладными программами. Ряд

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

в модели OSI, функции TCP/IP группируются по независимым уровням.

Существует четыре таких уровня: уровень сетевого доступа, межсетевой

уровень, уровень межмашинного (host-to-host) взаимодействия и

уровень процессов. Каждый уровень состоит из взаимосвязанных и

управляемых заданий и обеспечивает взаимодействие со смежными

уровнями.

Элементы модели MUSIC имеют различную функциональную

нагрузку и в этом смысле неэквивалентны. Так, например, компоненты

элемента M, в общем случае, не будут непосредственно

взаимодействовать с прикладной программой, в отличие от элемента I,

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

Пользовательский интерфейс (элемент U), элементы I и C связаны с

внешней средой (пользователи, сети, сетевые файловые серверы), а

элемент S - связывает непосредственно данную ЭВМ (аппаратура и

системное обеспечение) и прикладную программу.

Большая часть известных программных продуктов и

соответствующих стандартов не укладывается в точности в рамки,

ограничивающие элементы MUSIC или любой другой модели.

Большинство программных продуктов включает компоненты более, чем

одного элемента и одиночный стандарт также сочетает функции

нескольких элементов. Так стандарт SQL, описывающий интерфейсы

систем управления базами данных (СУБД), может быть определен как

стандарт элемента "S", как сервисный интерфейс. С другой стороны,

этот же стандарт можно отнести и к элементу "I", поскольку он

обеспечивает доступ к данным.

К числу стандартов, обеспечивающих функции элемента "U" (

интерфейс пользователя), относится язык SHELL операционной системы

UNIX. Однако SHELL представляет собой и программный интерфейс, с

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

системы из программ. Таким образом, SHELL входит также и в элемент

"S".

Подобная ситуация возникает и со стандартом графического

пользовательского интерфейса X Windows. Входящая в состав X

Windows графическая библиотека X Lib также обеспечивает

графический вывод из прикладной программы. Таким образом, X

Windows удовлетворяет не только элементу "U", но и обеспечивает

часть функций, определяемых элементом "S".

Взаимодействие с системами обслуживания доступа к данным

относится к функциям элемента "S", поскольку именно этот элемент

ответственен за обращения к системным программам. Одновременно эти

системы соответствуют и элементу "I".

Профили стандартов Открытых Систем

Интеграция компонентов в открытой системе должна следовать

профилям стандартов на интерфейсы этих компонент.

Профили выполняют три наиболее существенные и

взаимосвязанные функции.

Во-первых, они дают четкую основу для связи между

характеристиками открытых систем, которые нужны пользователю или

прикладной системе. Профиль может быть также использован как

основа при составлении спецификаций для приобретения как платформ,

так и прикладных программ. Он позволяет также оценить насколько

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

Во-вторых, профиль задает ориентиры для построения

прикладных программ и систем. Профиль является руководством,

которое определяет, насколько должным образом реализованы пакеты

прикладных программ или система. Прикладная система, которая

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

этого профиля построена должным образом.

Профиль обеспечивает логическую группировку стандартов,

которые разработчики могут использовать, чтобы упростить задачу по

ориентации приложений для конкретной среды. Восприятие профилей

промышленностью будет расширять пространство, заданное

разработчиками.

Для поставщиков систем, профили предлагают сходное

преимущество, обеспечивая основу для того, чтобы сфокусировать

внимание на конкретных секторах рынка. Один какой-нибудь

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

свои системы под эти требования. Кто-то другой может производить

системы общего назначения, отвечающие требованиям многих

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

Этот факт, сам по себе, поможет производителям убедиться, что они

отвечают потребностям выбранного ими рынка.

В-третьих, в терминах профилей может быть осуществлено

тестирование на соответствие как систем, так и приложений. Профили

должны уменьшать неопределенность, которая существует в

сегодняшних тестах на соответствие, когда каждый стандарт

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

возможных вариантов или связей между стандартами.

Профили могут также оказывать влияние на развитие стандартов,

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

стандартам. Если разработчики профиля указывают требование на

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

обеспечивающие эту функциональность, притом таким путем, что они

будут соответствовать и дополнять имеющиеся. Если две группы

разработчиков профилей предъявляют взаимоисключающие требования

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

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

соответствующий вариант в своем профиле.

На рис. 1.7 проиллюстрирована центральная роль, которую могут

играть AEP при разработке функциональной открытой системы.

Рис. 1.7. Роль функциональных профилей в реализации

Построенные профили могут относится к разным уровням. Внутри

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

потребностей отдела или корпорации. Но профили не обязательно

являются уникальными для данной фирмы. АЕР могут строиться для

определенной прикладной области, такой, как настольные ЭВМ, общей

для многих организаций или для приложения, характерного для

конкретной отрасли промышленности.

Профиль составляют набор согласованных стандартов

интерфейсов компонентов на каждом уровне системы (как было

показано выше на примере системы обработки данных) и обеспечивают

их совместимость.

Для определенности рассмотрения интерфейсов компонент и

проведения необходимых анализов их реализуемости можно

использовать модель среды открытых систем MUSIC, разработанную

центральным агентством по компьютерам и телекоммуникациям

(ССТА) Великобритании. Эта модель используется в руководстве

фирмы Digital Equipment по построению открытых систем. Модель

MUSIC содержит пять групп компонентов, из которых строятся

открытые системы:

• управление (Management) - функции системной администрации,

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

управление;

• пользовательский интерфейс (User Interface) - интерфейс

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

приложений;

• системные интерфейсы для программ (Service Interface for

Programs) - интерфейсы между прикладными программами и между

прикладными программами и операционной системой, в частности API

(Application Programs Interface);

• форматы информации и данных;

• интерфейсы коммуникаций.

Рис.1.6. Компоненты профиля открытых систем

Европейская рабочая группа по открытым системам (EWOS)

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

систем:

• среда рабочих станций,

• среда серверов процессов,

• среда серверов данных,

• среда транзакций,

• среда реального времени,

• среда суперкомпьютеров.

Кроме указанного набора профилей по классам аппаратно-

программных средств существует необходимость формирования

вертикальных профилей открытых систем, ориентированных на

проблемно-ориентированные области применения. В качестве таких

первоочередных областей применения открытых систем в России можно

назвать:

• интегрированные производственные системы,

• информационные системы (системы информационного

обслуживания) с удаленным доступом к ресурсам,

• системы автоматизации учреждений,

• системы автоматизации банков,

• системы автоматизации научных исследований,

• системы передачи данных.

Технологический цикл построения открытых систем.

Разработка конкретной информационно-вычислительной системы

встречает много трудностей, с которыми сталкиваются разработчики

любых сложных систем. Трудности, которые обусловлены современной

компьютерной средой, приносят особые проблемы. Компьютерная среда

данной организации может содержать различные компоненты,

построенные на базе различных технических средств и операционных

систем. Среда может включать различные базы данных. Компоненты

среды могут распределяться по различным регионам, удаленным на

значительные расстояния. Очень вероятно, что разработчики решат

иметь дело с уже существующими базами данных и уже имеющимися

техническими и программными средствами, предпочтя их проблемам, с

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

спецификаций. К тому же, и разработчики, и пользователи, чаще имеют

представление лишь об определенной части компьютерной среды.

Создание среды открытых систем для организации является

сложной задачей, допускающей различные подходы. Не бывает двух

одинаковых ситуаций. На ранней стадии определения требований и

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

которые будут включены в среду открытых систем, и те, которые будут

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

переписаны заново.

Факторы, которые влияют на выбор, могут включать уже

сделанные инвестиции в технические и программные средства,

приложения с критическими характеристиками, нужды и требования

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

ресурсах. Частью процесса принятия решения будет, также, учет

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

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

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

необходимые функции только тогда, когда они построены

соответствующим поставленным задачам образом.

Стадии внедрения среды открытых систем

Открытые системы лишь тогда дадут ощутимый эффект, если мы

можем применить их сегодня и это даст возможность воспользоваться

новыми технологиями завтра. Необходимо предпринять ряд шагов,

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

продлить жизнь сделанных инвестиций в будущем. Сущность этих

шагов не нова. Новым является лишь то, что в этот процесс включаются

средства открытых систем (см. рис. 1.10

Стадия 1: Определение целей деятельности.

Информационные технологии служат инструментом для

достижения конкурентноспособности нашего бизнеса. Использование

информационных технологий следует рассматривать именно в этом

контексте. Поэтому очень существенно определить цели деятельности, а

также ограничения и критерии успеха, прежде чем начать применение

технологии к стоящей задаче.

Среди многих прочих, всегда имеется один важный фактор,

способствующий успеху любого предприятия, который состоит в том,

чтобы сосредоточить ограниченные ресурсы и добиться быстрого

возвращения инвестиций. Ирония заключается в том, что необходимы

инвестиции в инфраструктуру сегодня для того, чтобы избежать

повторных инвестиций завтра, или даже еще раз сегодня, но в другое

подразделение.

Однако, открытые системы не могут обеспечить решения всех

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

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

стабильности для того, чтобы отвечать вашим целям. Некоторые

приложения играют слишком критическую роль, чтобы их можно было

включить в общий процесс, и в этом случае оптимальнее использовать

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

задачу лучше, чем другой, мобильный.

Стадия 2: Идентификация требований к прикладной системе.

Часть требований к прикладной системе может быть

сформулирована в терминах производительности, надежности и т.д. Эти

характеристики чаще всего не зависят от открытости системы. Свойства,

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

персонала и условия взаимодействия в системе прямо определяют

открытость. Такие свойства приложений должны быть рассмотрены и

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

преимущества концепции открытых систем.

Стадия 3: Подготовка профиля для описания набора свойств

среды, требуемых для поддержки приложения.

Прикладной профиль описывает свойства и характеристики,

необходимые для того, чтобы прикладная система могла

функционировать. Профиль должен идентифицировать как стандартные,

так и не стандартные характеристики так, чтобы можно было учесть все