Профили открытых систем

Основные свойства и назначение профилей

Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы, которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды ИС.

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

интерфейс прикладной программы (Application Program Interface - API );

интерфейс коммуникационных услуг (Communication Services Interface - CSI);

интерфейс информационных услуг (Information Services Interface - ISI);

человеко-машинный интерфейс (Human/Computer Interface - HCI).

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

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

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

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

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

Таким образом, определяемая профилем OSE функциональность в общем случае может рассматриваться как композиция функций или сервисов, реализуемых на интерфейсах определенных выше классов профилей F, T, U, R, A, B (рис 3.2). Функциональность профиля специфицируется в терминах вызовов функций, протоколов взаимодействия, форматов данных. Естественным требованием к профилю является согласованность используемых им спецификаций, относящихся к интерфейсам различных классов.

Полный OSE-профиль - это профиль, который специфицирует все поведение ИТ/ИС системы или часть ее поведения на одном или большем числе интерфейсов среды открытых систем OSE. Он состоит из выбранного набора открытых, общедоступных, согласованных стандартов и спецификаций, определяющих различные услуги в среде эталонной модели OSE/RM.

Профиль OSI - конкретный (локальный) профиль, составленный из базовых стандартов, соответствующих модели OSI (Open System Interconnection), и/или базовых стандартов представления форматов и данных, т. е. F-профилей.

На основании этих определений можно сформулировать следующие общие свойства профилей:

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

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

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

Основными целями OSE и OSI профилей является реализация основных свойств открытости проектируемой, внедряемой, эксплуатируемой или развиваемой системы. В связи с этим формируемые профили должны обеспечивать [4]:

Переносимость и многократную используемость программного обеспечения (ПО) на уровне исходного кода и стандартных библиотек (Application Software Portability and Software Reuse at the Source Code Level). Именно переносимость между различными платформами исходного текста ПО считается одной из основных практически достижимых задач, решение которой позволяет организациям защитить себя от необходимости дополнительного инвестирования в существующее ПО для его перепроектирования при переходе на новые прикладные платформы. Если под переносимостью приложений понимается перенос всего соответствующего данному приложению ПО на другие платформы, то под его переиспользумостью, как правило, понимается перенос в новые приложения некоторой части работающих программ, что также имеет большое практическое значение и непосредственно относится к целям открытости систем.

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

Интероперабельность прикладного программного обеспечения (Application Software Interoperability). Здесь имеется в виду возможность обмена данными между сущностями ПО, в том числе между сущностями, реализуемыми на разнородных прикладных платформах, а также возможность совместного использования ими обмениваемых данных. Данное свойство на нижнем уровне обеспечивается построением стандартизованных коммуникационных интерфейсов, т.е. CSI-интерфейсов, систем на основе стандартов сетевых протоколов, в частности OSI-профилей. Реализация его в полном объеме приводит к необходимости решения проблемы семантической интероперабельности, т.е. понимания разнородными платформами семантики данных, которыми они обмениваются друг с другом.

Интероперабельность управления и безопасности (Management and Security Interoperability). Для целей интеграции и совместного использования разнородных платформ в рамках распределенных систем ИТ необходима унификация и концептуальная целостность средств административного управления и управления информационной безопасностью систем ИТ независимо от реализационных окружений. Поэтому для обеспечения бесшовной интеграции систем их средства административного управления и средства защиты должны строиться в соответствии с международными стандартами.

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

Использование существующих стандартов и аккомодацию к стандартам перспективных технологий (Accommodation of Standards). Профили OSE являются эффективным средством продвижения существующих стандартов в практику. В то же время они являются объектами, способными эволюционировать с учетом изменения стандартов, технологий и пользовательских требований, прежде всего потому, что они конструируются посредством ссылок на базовые стандарты. Таким образом, на основе понятия OSE-профиля поддерживается такое свойство открытых систем, как адаптируемость к изменению стандартов.

Легкую настраиваемость на новые технологии создания информационных систем (Accommodation of New Information System Technology). Профили OSE, являясь исходным материалом при построении открытых систем, не связаны непосредственно с нижележащими технологиями. Однако развитие таких технологий влечет развитие системы стандартов. Гибкость аппарата OSE-профилей позволяет учитывать тенденции перехода к новым стандартам и соответственно к новым технологиям.

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

Прозрачность реализаций процессов (Process Implementation Transparency). Данное свойство поддерживается благодаря систематическому использованию через аппарат OSE-профилей стандартизованных спецификаций (стандартов и ISPs), одним из принципов разработки которых является независимость от конкретных реализаций. Таким образом, все особенности реализации OSE-профилей скрываются за интерфейсами открытых систем, что и обеспечивает свойство прозрачности реализаций для конечных пользователей систем ИТ.

Поддержка пользовательских требований (Support Clear Statement of User Requirements). Важным свойством открытых систем является точная спецификация пользовательских требований, определенных в виде наборов сервисов, предоставляемых открытыми системами на их интерфейсах. Это свойство адекватно поддерживается применением аппарата OSE-профилей.

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

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

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

локальный уровень, состав которого отражается в основном документе по формированию профиля ("Главном профиле") в виде перечня действующих локальных профилей.

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

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

(рис 3.5) Структурная модель типизированного профиля стандартизации ИТ

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

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

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

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

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

опубликовать профиль и (или) продвигать его по формальным инстанциям для дальнейшего распространения.

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

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

(рис 3.6) Схема процесса проектирования профиля открытой системы

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

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

Пример компоновки функционального профиля

Разработка и применение профилей являются неотъемлемой частью процессов проектирования, разработки, внедрения и сопровождения ИС. Профили характеризуют каждую конкретную ИС на всех стадиях ее жизненного цикла, задавая гармонизированный набор базовых стандартов, которым должна соответствовать информационная система и ее компоненты. Профиль такой системы не является статичным, он развивается и конкретизируется в процессе установления и специфицирования требований, отражения их в Техническом задании (ТЗ), проектирования ИС и оформляется в составе документации проекта системы. При формировании и применении профилей конкретных ИС можно использовать международные, национальные стандарты и ведомственные нормативные документы, а также стандарты де-факто при условии доступности соответствующих им спецификаций ("общедоступные спецификации"). Для корректного применения описание профиля обязательно должно содержать [1]:

определение целей использования данного профиля;

точное перечисление функций объекта или процесса стандартизации, определяемого данным профилем;

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

сводку требований к ИС или к ее компонентам, определяющих их соответствие профилю, и требований к методам тестирования соответствия;

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

информационные ссылки на все исходные документы.

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

(рис 3.7) Схема реализации открытых систем с использованием стандартных профилей

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

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

Наиболее выпукло проблемы формирования функциональных профилей можно показать на примере открытой распределенной информационной системы с архитектурой "клиент-сервер". Рассмотрим общие подходы к построению профилей таких систем [7].

Профиль среды распределенной ИС должен определять ее архитектуру в соответствии с выбранной моделью распределенной обработки данных, например, Distributed Computing Environment (DCE) или Common Object Request Broker Architecture (CORBA).

В первом случае модель определяется стандартами Консорциума OSF, в частности, используется механизм удаленного вызова процедур (Remote Procedure Call - RPC) с учетом стандартов де-факто, которые специфицируют применяемые мониторы транзакций (например, монитор транзакций Tuxedo) [11].

Во втором случае модель определяется стандартами консорциума OMG, в частности, спецификацией брокера объектных запросов (Object Request Broker - ORB). Стандарты интерфейсов приложений со средой ИС (Application Program Interface - API) должны быть определены по функциональным областям профилей ИС. Декомпозиция структуры среды функционирования ИС на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды ИС по функциональным областям эталонной модели OSE/RM:

графического пользовательского интерфейса (MOTIF консорциума OSF или стандарт X Window IEEE);

реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);

операционных систем с учетом сетевых функций, выполняемых на уровне ОС (например, набора стандартов POSIX - ISO и IEEE);

телекоммуникационной среды в части услуг и сервисов прикладного уровня: электронной почты (по рекомендациям ITU-T X.400, X.500), доступа к удаленным базам данных RDA (по стандарту ISO 9594-1.2), передачи файлов, доступа к файлам и управления файлами (по стандарту ISO 10607 - 1, 2, 3, 4, 5, 6).

Профиль среды распределенной ИС должен включать в себя:

стандарты протоколов транспортного уровня (по ISO/IEC OSI или стандарт де-факто протокола TCP/IP),

стандарты локальных сетей (например, стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 u),

стандарты средств сопряжения проектируемой ИС с сетями передачи данных общего назначения (например, по рекомендациям ITU-T: X.25, X.3, X.29 и др.).

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

Профиль защиты информации в ИС должен обеспечивать реализацию политики информационной безопасности, разрабатываемой в соответствии с требуемой категорией безопасности и критериями безопасности, заданными в техническом задании на систему [Draft ETGnn. Development and Use of OSE Profiles. EMOS/EG-OSE/95/10. ? 1995]. Построение профиля защиты информации в распределенных системах "клиент-сервер" методически связано с точным определением компонентов системы, ответственных за те или иные функции, сервисы и услуги, и средств защиты информации, встроенных в эти компоненты. Функциональная область защиты информации включает в себя функции защиты, реализуемые разными компонентами ИС:

защиты, реализуемые операционной системой;

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

управления данными, реализуемые СУБД;

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

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

администрирования средств безопасности.

Основополагающим документом в области защиты информации в распределенных системах являются рекомендации X.800, принятые МККТТ (сейчас ITU-T). Подмножество указанных рекомендаций должно составлять профиль защиты информации в ИС с учетом распределения функций защиты информации по уровням концептуальной модели ИС и взаимосвязи функций и применяемых механизмов защиты информации.

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

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

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

преобразованием конфигурации ППО, тиражированием версий;

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

перенастройкой приложений в связи с изменениями прикладных функций ИС;

настройкой пользовательских интерфейсов (генерация экранных форм и отчетов);

ведением баз данных системы;

восстановлением работоспособности системы после сбоев и аварий.

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

Поясним сказанное выше на конкретном примере [).

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

(рис 3.8) Пример корпоративной информационной архитектуры

Обозначим для определенности профиль клиентской стороны системы (Client Side of System) как <PC>. Он будет включать спецификации как минимум двух классов интерфейсов, а именно, интерфейса API, определяющего взаимодействие клиентской системы с прикладной программой, а также коммуникационного интерфейса, определяющего состав протоколов сетевого взаимодействия между клиентскими и серверными системами.

Коммуникационный интерфейс можно формировать, начиная с мощного протокола прикладного уровня RDA (ISO 9579), используемого, в частности, для реализации распределенных SQL-приложений с архитектурой "клиент-сервер" над стеком протоколов модели RM OSI. Для большей гибкости решения разобьем стек протоколов модели RM OSI на две группы протоколов - протоколы верхних трех уровней, которые обозначим OSI Stack (7-5), и протоколы транспортной системы, обеспечивающие транспортные услуги OSI в режиме с соединением.

Если мы обратимся к справочнику международных стандартизованных профилей, то обнаружим, что уже существует профиль, описывающий набор протоколов для реализации передачи данных по транспортному протоколу OSI через локальную сеть FDDI. Данный профиль имеет наименование <TC54>. Он включает ссылки на стандарт транспортного протокола OSI, стандарт протокола сетевого уровня (X.25) вместе с дополнениями, адаптирующими этот протокол для использования в локальных сетях, а также ссылки на стандарты протоколов нижних уровней, определяющих функционирование сети FDDI. Профиль <TC54> является типичным примером OSI-профиля, так как определяет только функции сетевого взаимодействия, определенные стандартными протоколами, разработанными в соответствии с моделью RM OSI.

Таким образом, описание коммуникационного интерфейса в профиле <PC> будет включать ссылки на следующие спецификации: стандарт протокола DRA, стандарты протоколов верхних уровней модели RM OSI (OSI Stack (7-5)), профиль <TC54>.

В состав спецификаций API необходимо включить стандарты языков <С++ >и <SQL> (Std "С++" и Std "SQL", соответственно), а также интерфейс RDA, реализующий сервис протокола RDA для клиентских систем. Следовательно, описание интерфейса API в профиле <PC> включает ссылки на следующие спецификации: Std "С++", Std "SQL", интерфейс RDA-клиента.

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

Профиль серверной части (Server Side of System) обозначим как <PS>, будет содержать идентичный с профилем <PC> коммуникационный интерфейс (иначе клиентские и серверные системы не смогли бы взаимодействовать). Интерфейс API профиля <PS> будет почти идентичным соответствующему интерфейсу профиля <PC>, за исключением некоторых различий в программных интерфейсах для сервиса RDA в клиентской и сервисных системах.

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

Отметим, что в соответствии с введенными выше определениями, построенные нами в примере профили <PC> и <PS> относятся к OSE-профилям. С целью наглядного представления случаев применения и функциональности профилей используются специальные схемы (сценарии), на которых, как правило, определяются основные функциональные компоненты описываемой данным профилем технологии, их взаимосвязи, интерфейсы, распределение основных функций в системе и пр. Для профилей <PC> и <PS> таким сценарием может служить схема, показанная на рис 3.9.

(рис 3.9) Сценарий для профилей <PC> и <PS>

Если же коммуникационная структура компании была бы построена на базе Intranet, то в этом случае следует перепроектировать профиль, заменив <T54>, например, на профиль <Ti>, основанный на использовании следующих стандартов:

RFC 1006 (IETF STD 35). ISO Transport Service on top the TCP

RFC 793 (IETF STD 7). Transmission Control Protocol (TCP)

RFC 791 (IETF STD 5). Internet Protocol (IP)

RFC 1390 (IETF STD 36). Transmission of IP and ARP over FDDI Networks

ISO 9314 FDDI LAN.

Основная идея построения новой транспортной системы <Ti> состоит в использовании протокола TS (RFC 1006), эмулирующего интерфейс протокола TP OSI над стеком протоколов TCP/IP, а также протокола (RFC 1390), обеспечивающего передачу IP-пакетов через сеть FDDI. Протокольная структура транспортной системы <Ti> иллюстрируется на рис 3.10.

(рис 3.10) Стек протоколов конечной системы, реализующей транспортный сервис TP OSI над стеком протоколов TCP/IP и FDDI

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

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

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

На основе профиля должно проводиться тестирование и сертификация приложений на соответствие требованиям открытости. Основу большинства применяемых в настоящее время профилей составляют стандарты серии POSIX [13].

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