1.3. Профили функциональных стандартов.

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

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

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

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

    Концепция функциональных профилей выросла из концепции профилей OSI, которая была создана для того, чтобы можно было иметь дело с несколькими сотнями стандартов ISO. Из этой большой группы стандартов для пользователя существенно выбрать набор стандартов и возможных вариантов, не только для успешного взаимодействия, но также удовлетворяющих специфические требования по функциональности. По-видимому, наиболее хорошо известной попыткой построения OSI-профиля может служить GOSIP (government OSI profiles) - правительственные профили взаимосвязи открытых систем. Такие работы ведутся в США, Англии и Европе, а также в других странах. Целесообразность объединения усилий в этой работе получила международное признание. Разработка Российского GOSIP является одной из главных задач в проблеме открытых систем, поэтому описанию принципов построения GOSIP (США) посвящен отдельный раздел (см. раздел 1.3.2.).

    Модель MUSIC, которая была рассмотрена выше, дает структуру для построения профиля. Для большинства областей применения соответствующие стандарты будут специфицированны в рамках модели MUSIC. Отсюда следует, что большинство профилей открытых систем будут специфицировать стандарты, которые относятся к одному или к ряду компонент каждого элемента этой модели. На рис. 1.6 показана модификация модели MUSIC в терминах функциональности.

    АЕР должен быть не только полон с точки зрения среды, для которой он предназначен, но он, также, должен быть "когерентным", т.е. логически согласованным. Например, для любого профиля требуется, по крайней мере, хотя бы один язык программирования. Поскольку каждый язык связан с определенной прикладной областью, выбор языка может быть очевиден. Когда же для данного профиля требуется более, чем один язык, профиль должен указать на отношения между выбранными языками, например, требуется ли общая кодировка для данных, или совместное использование файлов и т.д.

    Профили выполняют три наиболее существенные и взаимосвязанные функции.

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

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

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

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

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

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

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

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

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

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

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

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

    1.3.1. Развитие профилей в стандартизующих организациях.
    В настоящее время ведется формальная разработка профилей в рамках аккредитованных организаций, таких как ISO, IEEE и EWOS. Например, в рамках IEEE POSIX, имеются активно работающие группы по профилям в области супер-ЭВМ, в области диалоговой обработки запросов, вычислений в реальном масштабе времени и мультипроцессорной обработки. Работа по профилям представляет основную область активности в рамках EWOS. Результаты работы, проделанной каждой группой, должны быть представлены в комитет ISO по функциональным стандартам для международной "гармонизации" и признания комитетом ISO в качестве утвержденного международного стандартизованного профиля (International Standardized Profile - IPS).

    Профили, представленные стандартизующими организациями, отличаются от других АЕР тем, что они составлены только из утвержденных или представленных к утверждению стандартов, и они, обычно, направлены на более широкую функциональную область применения. Например, стандарт POSIX 1003.13 сконцентрирован на профиле для работы в реальном масштабе времени. Этот АЕР не ориентирован на конкретные применения, такие как сбор данных или анализ треков. ISP имеют в международном сообществе такой же статус, как и международные базовые стандарты. ISP в области взаимосвязи открытых систем описаны в документе ISO/IEC TR 10 000 "Структура таксономии и руководство по профилям" в качестве согласованного на международном уровне гармонизированного документа, который идентифицирует группу стандартов совместно с возможными вариантами и параметрами, необходимыми для выполнения какой-либо функции или набора функций. Стандарт TR 10 000-2-92 утвержден в качестве Российского стандарта.

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

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

    Таксономия профиля, включенная в Часть II документа TR 10 000, представляет собой структуру и классификацию, внутри которой выполняются ISP. Эта структура дает спецификацию первого уровня для профилей, включая некоторые технические ограничения. Она классифицирует их, а также специфицирует некоторые взаимодействия между ними.

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

    Как и любая работа в области стандартизации, работа по формализации профилей в стандартизующих организациях требует времени и ресурсов. Поскольку эта работа в основном направлена на удовлетворение требований пользователей, это - наиболее значительная область для участия пользователей в процессе стандартизации, и это следует подчеркнуть особо. Если пользователи не будут работать в этой области, маловероятно, что профили и стандарты будут соответствовать по своей функциональности требованиям производителей. В качестве одного из пособий для пользователей, заинтересованных в работе такого рода, рабочая группа IEEE POSIX 1003.0 подготовила документ для разработчиков профилей, называемый "Руководство среды открытых систем POSIX". Это руководство используется также как рабочий документ EWOS.

    Работа над профилями в стандартизирующих организациях сильно влияет на работу, проводимую в группах пользователей, правительственных ведомствах и промышленных ассоциациях над средой открытых систем (Open Systems Environment - OSE). Работа над OSE в этих группах не является работой над АЕР или стандартизированными профилями. Скорее, они описывают в общем виде полную среду для работы открытых систем.

    Работа над OSE в каждой организации отражает цели, потребности и опыт, соответствующие характеру данной организации. Например, NIST разработал профиль переносимости прикладных программ (АРР), который включает стандарты ANSI и ISO [12]. Он идентифицирует три функциональные области, к которым необходимо обратиться при дальнейшей работе по стандартам: администрация системы, прозрачный доступ к файлам и окнам. Эти области составляют предмет интереса для сообщества пользователей внутри федерального правительства США. Описанию принципов построения APP посвящен раздел 1.3.3.

    Подобно этому X/Open разработала документ "Общая среда для приложений" (Соммоn Application Environment (CAE)), который включает как стандарты, так и другие спецификации. Фонд открытого программного обеспечения (Open Software Foundation) имеет спецификацию среды прикладных программ (Administration Environment Specification (AES)), включающую в себя широкий набор стандартов ISO, а также расширения, которые OSF вносит в качестве рекомендаций по стандартам.

    EWOS организовал Группу Экспертов CAE, которая начала разрабатывать таксономию профилей для своих OSE. В рамках этой таксономии профили делятся на профили среды открытых систем, профили платформ OSE и профили компонент OSE. Профили компонент делятся, в свою очередь, на профили, которые могут быть отнесены к элементам модели MUSIC.

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

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

    1.3.2. Правительственные профили взаимосвязи открытых систем - GOSIP
    Правительственные организации являются самыми крупными пользователями информационных сетей и поэтому заинтересованы в том, чтобы строить их на самой современной концептуальной основе [3]. Эта основа обеспечивает единство информационных систем и возможность эффективного объединения множеств сетей в правительственных организациях. На это и направлены усилия по созданию правительственных профилей взаимосвязи открытых систем (Government Open Systems Interconnection Profiles - GOSIP). Почти одновременно профили GOSIP начали разрабатываться в США и Великобритании. Имеются некоторые отличия в GOSIP разных стран [3]. Здесь мы рассмотрим GOSIP США, принципы его построения и развития. В настоящее время уже опубликована вторая версия GOSIP США [9,10].

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

    На рис. 1.9 показана структура GOSIP США, версия 2. Как видно, GOSIP строится на базе семиуровневой модели.

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

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

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

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

    Сетевой уровень обеспечивает маршрутизацию сообщения.

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

    Физический уровень обеспечивает физическое соединение для передачи данных между объектами. На первом уровне выполняются кодирование и декодирование.

    Обратим внимание на то, что в GOSIP имеются протоколы, обеспечивающие защиту информации. Этому вопросу посвящен раздел 1.6. Кроме самого документа на профиль выпущено руководство по его применению [10].

    1.3.2.2. Порядок развития GOSIP.
    На примере развития GOSIP можно очень наглядно проследить процедуру согласования спецификаций, характерную для открытых систем (см. раздел 1.1.2.).

    Можно отметить следующие особенности: 1) GOSIP основан на соглашениях, достигаемых в процессе совещаний представителей пользователей, производителей, разработчиков и стандартизаторов, которые проводятся с определенной периодичностью. На этих совещаниях рассматриваются различные варианты из множества стандартов, не документированные подробности, которые необходимы для функционирования, и осуществляется документирование всех этих особенностей; 2) Стандарт на GOSIP будет заменяться через установленные временные интервалы путем выпуска новых версий, отражающих прогресс, достигнутый производителями в оснащении изделий ВОС новыми возможностями, полезными для федеральных ведомств; 3) Новая версия GOSIP будет включать предыдущую версию документа с указанием срока действия для каждого протокола. Обязательным условием является полная совместимость снизу вверх с предыдущей версией, за исключением выявленных ошибочных утверждений; 4) Еще раз следует подчеркнуть, что GOSIP носит рекомендательный характер.

    1.3.3. Правительственный Профиль Мобильности Прикладных Систем.
    В мае 1993 года Национальным институтом стандартов и технологий США был выпущен документ "APPLICATION PORTABILYTY PROFILE APP. The U.S. Government'S Open System Evironment Profile OSE/1 Version 2.0" [12]. Этот документ определяет рекомендуемые для федеральных учреждений США спецификации в области информационных технологий, обеспечивающие мобильность персонала, системных и прикладных программных средств.

    APP строится на основе модели OSE/RM, описанной выше (см. п. 1.2.1.) . APP строится как профиль открытой среды предназначенный для использования Правительством США. Он охватывает широкую область прикладных систем, представляющих интерес для многих Федеральных агенств, однако он не включает всего списка прикладных систем, используемых Правительством. Индивидуальные стандарты и спецификации, входящие в APP, определяют форматы данных, интерфейсы, протоколы и/или их комбинации. Основные стандарты, входящие в APP приведены в Приложении 2.

    1.3.3.1. Функциональные области APP.
    Все виды функционального обслуживания в рамках APP могут быть представлены следующими семью функциональными областями:
    a) функции, реализуемые операционной системой;
    b) функции, реализующие человеко/машинные интерфейсы;
    c) управление данными;
    d) обмен данными;
    e) поддержка разработки программного обеспечения;
    f) машинная графика;
    g) сетевые функции.

    На рис. 1.4 была приведена модель OSE/RF, на которой представлены эти функциональные области и их отношение к элементам модели.

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

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

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

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

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

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

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

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

    c) Параметры окон - спецификации, которые позволяют определить как создаются окна, передвигаются, сохраняются, восстанавливаются, удаляются и взаимодействуют друг с другом.

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

    e) Спецификации мультимедиа, включая API - спецификации, определения функций и форматов данных, которые поддерживают манипуляции различными формами цифровой и аналоговой аудиовизуальной информации в рамках единой прикладной системы.

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

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

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

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

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

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

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

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

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

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

    b) Графические данные - независимые от устройств определения элементов рисунков.

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

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

              -----------------------------------------------
          | Уровень 5  |  Прикладной                    |
          |------------|--------------------------------|
          | Уровень 4  |  Семантика и синтаксис языков  |
          |------------|--------------------------------|
          | Уровень 3  |  Комплексный объект            |
          |------------|--------------------------------|
          | Уровень 2  |  Объект единого контекста      |
          |------------|--------------------------------|
          | Уровень 1  |  Формат данных                 |
          -----------------------------------------------
    1.3.3.7. Область графических функций.
     Эта функциональная область предоставляет функции, используемые для создания и манипуляций с отображаемыми изображениями. Функции такого рода обеспечивают определение и поддержку отображаемого элемента и определение атрибутов изображения. Функции этой области определены в спецификациях многомерных графических объектов и изображений и в форме, независимой от конкретных устройств. Доступность и целостность как функций, поддерживающих разработку программного обеспечения для изображений и графики, а также самих графических данных обеспечивается за счет средств, обеспечивающих безопасность для данной области.

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

    a) Собственно коммуникации, которые включают API, и спецификации протоколов для прозрачной и надежной передачи данных через коммуникационные сети.

    b) Прозрачный доступ к файлам, расположенным в любом месте неоднородной сети.

    c) Поддержка персональных ЭВМ и микро-ЭВМ для обеспечения интероперабельности с системами, базирующимися на различных операционных системах (ОС), в частности микрокомпьютерных ОС, которые могут оказаться не соответствующими международным и национальным стандартам.

    d) Дистанционное обращение к процедурам - спецификации для обращения к процедурам, расположенным во внешней распределенной среде.

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

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

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

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

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

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

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

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

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

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

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

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

    Стадия 3: Подготовка профиля для описания набора свойств среды, требуемых для поддержки приложения.

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

    Стадия 4: Приобретение или создание программного обеспечения, которое соответствует выбранному профилю.

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

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

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

    Стадия 5: Проверка приложения на соответствие характеристи- кам открытых систем.

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

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

    Стадия 6: Проверка на соответствие целям деятельности.

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

    Стадия 7: Повторение последовательности действий.

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

    1.5. Проверка на соответствие требованиям открытых систем.

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

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

    1.5.1. Уровни соответствия приложений.
    Уровень того, насколько прикладная система соответствует стандартам открытых систем, будет влиять на степень ее мобильности. Комитет IEEE POSIX определил несколько уровней соответствия прикладных систем открытым стандартам (см. рис. 1.11).

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

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

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

    Во-первых, такие тесты создаются самими производителями.
    Во-вторых, такие организации, как COS, SPAG, POSI, MAP/TOP, NIST и INTAP совместно работают над тестами всеобщего распространения.

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

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

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

    1.6 Защита информации в открытых системах.

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

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

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

    Разрабатываемые стандарты можно разделить на две категории:

    - стандарты, относящиеся к коммуникациям;
    - стандарты, относящиеся к операционным системам.

    В качестве примера обеспечения защиты в сетях можно обратиться к рис. 1.9, на котором изображен GOSIP США и выделены протоколы, обеспечивающие защиту информации.

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

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

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

    В 80-х годах в мире образовалось большое число групп, разрабатывающих функциональные стандарты в области открытых систем, в том числе:

    - секции реализаторов ВОС, куда входят Европейская секция открытых систем (EWOS), секция США, секция стран Азии и Тихого океана;
    - промышленные консорциумы и организации, включая группы пользователей протокола MAP (Manufacturing Automation Protocol) и TOP (Technical Offices Protocols), группу содействия разработке и применению стандартов SPAG (Standards Promotion and Application Group), корпорацию открытых систем COS (Corporation for Open Systems International), конференцию содействия ВОС POSI (Promoting Conference for OSI);
    - правительственные группы, в том числе Общеевропейская группа, группы США, Великобритании, Японии, Канады и Австралии.

    В 1986 г. к разработке функциональных стандартов приступила ИСО, где была создана специальная группа по функциональной стандартизации (СГФС). Этой группой разработаны основополагающий документ ИСО/МЭК ТО 10000 "Основы и таксономия международных функциональных стандартов" и многочастевые МФС 10607 - 10615, 11181 - 11183 и др.

    Одним из важнейших шагов в достижении консолидации усилий ведущих стран на международном уровне явилось создание концепции и принятие международных стандартов базовой эталонной модели ВОС (ИСО 7498).

    Национальный институт по стандартизации США (NIST) в своем генеральном плане развития потребовал соответствия всех работ по стандартизации в данной области эталонной модели ВОС. Страны ЕЭС приняли решение о строгом соблюдении стандартов ВОС при разработке соответствующего оборудования. Во Франции, например, архитектура ВОС принята под названием Architel. Аналогичную поддержку архитектура ВОС нашла в ФРГ, Японии и многих других странах.

    В подходе к сетевым стандартам существует выбор между различными запатентованными типами сетей, включая сети с архитектурой SNA фирмы IBM, и несколько систем, частично реализующих протоколы верхних уровней ВОС ИСО. В 1985 г. восемнадцать изготовителей вычислительной техники в США образовали организацию COS по созданию сетевых стандартов для открытых систем.

    Но, если среди фирм изготовителей оборудования вычислительных сетей и передачи данных в США интересы к стандартизации своих изделий раздваиваются между концепцией ВОС и концепцией SNA, то европейские изготовители этого оборудования однозначно высказались за стандарты ВОС ИСО. Так, правительства 10 стран - членов ЕЭС намерены закупать для своих систем только то оборудование, которое соответствует стандартам ВОС. Это объясняется, с одной стороны, их стремлением избавиться от диктата американских фирм, а с другой - желанием обеспечить полную совместимость применяемого оборудования.

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

    Фирма IBM, несмотря на продолжающиеся работы по совершенствованию концепции и средств SNA, одна из первых подключилась к реализации протоколов транспортного уровня эталонной модели ВОС и создала в ФРГ Западноевропейский центр вычислительных сетей по исследованиям в области эталонной модели ВОС.

    Национальная академия наук США создала комитет по изучению применения протоколов сетевого и транспортного уровней ВОС и рекомендовала министерству обороны США как можно быстрее перевести свои системы на реализацию этих протоколов. С учетом рекомендаций этого комитета многие компании (AT&T, Charles River, Espirit, Intel, Motorola, NCR, Network Research, Unisoft) разработали и предлагают систему UNIX/OSI с протоколами ВОС.

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

    Так, уже с 1987 г. общую координацию работ по стандартизации в этой области взял на себя совместный комитет ИСО/МЭК СТК 1 "Информационная технология", созданный на основе ИСО/ТК 97, МЭК/ТК 83 и МЭК/ТК 47/ПК 47B.

    Европейская ассоциация производителей вычислительных машин (ECMA) сконцентрировала свою деятельность по стандартизации вычислительных сетей в основном в рамках своего комитета ТК 32 "Передача данных, сети и взаимосвязь систем", деятельность которого направлена на:

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

    Разработка стандартов в ИСО, МККТТ и ECMA ведется на основе тесного взаимодействия и взаимной преемственности результатов.

    Европейский комитет управления информационной технологией (ITSTC) выработал предложения по организации тестирования и сертификации средств информационной технологии в европейском масштабе. Эти работы координируются Европейским комитетом по тестированию и сертификации в области информационной технологии (ECITC). В настоящее время в рамках ECITC действуют два органа:

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

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

    Выводы.

     На основании материалов, изложенных в Части I, можно сделать следующие выводы:
    1. Технология открытых систем представляет в настоящее время основное направление информационных технологий, определяющее эффективность информационных систем.
    2. Технология открытых систем касается систем всех уровней и назначений.
    3. В развитии и применении технологии открытых систем заинтересованы все категории участников информационных технологий:
      - пользователи;
      - производители платформ - базовых средств вычислительной техники;
      - разработчики систем;
      - разработчики стандартов.
    4. Экономический эффект от использования технологии открытых систем оценивается в миллиарды долларов.
    5. Основным конечным продуктом при развитии отрытых систем служат функциональные профили стандартов, представляющие собой набор стандартов для данной области применения.
    6. Процесс развития и применения отрытых систем носит непрерывный характер, содержит много теоретических и практических проблем, в нем участвуют сотни организаций различного статуса.
    7. Даже в странах с рыночной экономикой процесс развития и применения открытых систем осуществляется под руководством федерального правительства.
    ВПЕРЕД: переход к части 2
    ОГЛAВЛЕНИЕ: переход к началу