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

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

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

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

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

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

приложений. Кроме того, рассматривая приложения, параллельно

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

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

Стадия 4: Приобретение или создание программного

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

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

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

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

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

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

приложение использует иные свойства системы, то в лучшем случае

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

в худшем случае утрачены.

Использование стандартов в процессе создания системы позволит

оценить имеющиеся продукты и обосновать решение по поводу выбора:

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

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

рассмотрены открытые спецификации и формальные стандарты. И

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

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

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

кода - двоичного или исходного, поэтому следует решить какой код

использовать.

Даже, если в приложении используются специфические для

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

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

дальнейшие возможности развития системы и возможную

последующую миграцию приложения.

Стадия 5: Проверка приложения на соответствие

характеристи- кам открытых систем.

Минимальная проверка приложения на соответствие

характеристикам открытых систем может быть проведена с помощью

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

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

созданием заданного профиля. Появляются программные средства, для

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

профилем.

Важной частью проверки служит, также, исполнение приложения

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

целесообразно прогнать приложение на двух, совершенно разных

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

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

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

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

идентификация целей деятельности. Для завершения цикла последним

шагом должно быть подтверждение тому, что эти цели достигнуты. Если

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

шагом. Однако, если среда статична, то перспективные

информационные технологии не требуются и открытость не нужна.

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

На самом деле, это только вопрос времени, деятельность

изменится. Это может произойти по нескольким причинам: или как

влияние давления внешнего рынка и конкуренции, или вследствие того,

что появление новой технологии обеспечит новые конкурентные

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

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

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

расширено.

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

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

важным этапом создания открытых систем. Эта процедура относится к

области сертификации информационных технологий, которой в

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

открытых систем свои особенности.

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

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

базовые средства.

Уровни соответствия приложений.

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

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

Комитет IEEE POSIX определил несколько уровней соответствия

прикладных систем открытым стандартам (см. рис. 1.11

Рис. 1.11. Уровни соответствия приложений стандартам РОSIX

Самому высокому уровню соответствия отвечает система,

построенная только на стандартах POSIX. Дальнейшее отклонение от

"коаксиальности" будет означать уменьшение качества мобильности

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

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

проверки на соответствие международным стандартам существуют

наборы тестов, но эта работа пока еще находится в начальной стадии.

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

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

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

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

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

Сертификация систем.

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

производители встраивают в свои изделия "расширения", направленные

на увеличение функциональности платформ. Эти расширения не

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

любая прикладная система шла на любой платформе.

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

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

организациями.

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

Во-вторых, такие организации, как COS, SPAG, POSI, MAP/TOP,

NIST и INTAP совместно работают над тестами всеобщего

распространения.

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

возможности систем, так и их поведение в динамике.

Как и в других случаях, ввиду того, что правительства являются

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

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

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

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

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

соответствие, например, стандарт POSIX 1003.3 представляет стандарт

на тест для POSIX 1003.1.

Выводы

1. Технология открытых систем представляет в настоящее время

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

эффективность информационных систем.

2. Технология открытых систем касается систем всех уровней и

назначений.

3. В развитии и применении технологии открытых систем

заинтересованы все категории участников информационных технологий:

- пользователи;

- производители платформ - базовых средств вычислительной

техники;

- разработчики систем;

- разработчики стандартов.

4. Экономический эффект от использования технологии открытых

систем оценивается в миллиарды долларов.

5. Основным конечным продуктом при развитии отрытых систем

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

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

6. Процесс развития и применения отрытых систем носит

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

проблем, в нем участвуют сотни организаций различного статуса.

7. Даже в странах с рыночной экономикой процесс развития и

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

федерального правительства.

Часть 2. Стандарты POSIX

История создания и текущий статус стандарта POSIX

Обеспечение мобильности (переносимости, портабельности)

программного обеспечения (ПО) - задача исключительной важности и

сложности; в наше время это обстоятельство едва ли нуждается в

пространных обоснованиях. Один из общепринятых способов

повышения мобильности ПО - стандартизация окружения приложений:

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

системных сервисов подобное окружение описывает стандарт POSIX

(Portable Operating System Interface - мобильный интерфейс

операционной системы); название предложено известным специалистом,

основателем Фонда свободного программного обеспечения Ричардом

Столмэном.

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

версий стандарта POSIX, в редакции 2003 г., которую можно назвать

"стандартом втройне", а именно: стандартом IEEE Std 1003.1,

Техническим стандартом Open Group и (см. [6], что для нас важнее

всего, международным стандартом ISO/IEC 9945 (см. [1], [2], [3], [4]).

История создания этой версии такова. В начале 1998 г.

представители трех организаций - Комитета по стандартам мобильных

приложений Института инженеров по электротехнике и электронике,

Open Group и рабочей группы 15 подкомитета 22 совместного

технического комитета 1 (JTC1/SC22/WG15) Международной

организации по стандартизации - начали консультации по вопросу

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

системным сервисам: IEEE Std 1003.1, IEEE Std 1003.2, Базовых

спецификаций от Open Group, ISO/IEC 9945-1, ISO/IEC 9945-2. В

сентябре того же года в городе Остин, штат Техас, в офисе корпорации

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

для достижения поставленной цели (см. http://www.opengroup.org/austin).

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

первый проект которого был представлен в июле 1999 года, стали

Базовые спецификации от Open Group, поскольку они включали

положения стандартов IEEE и ISO/IEC. В 2001 году, по завершении

подготовительной работы, стандарт содержал следующие четыре части:

1. основные определения (термины, концепции и интерфейсы,

общие для всех частей);

2. описание прикладного программного C-интерфейса к

системным сервисам;

3. описание интерфейса к системным сервисам на уровне

командного языка и служебных программ;

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

принятых решений.

Далее в ISO, IEEE и Open Group с большей или меньшей

скоростью (в 2001-2002 гг.) прошло формальное утверждение нового

стандарта POSIX. Тем временем накапливались относительно мелкие

исправления, учтенные в редакции 2003-го года.

С развитием стандарта расширялась и трактовка термина "POSIX".

Первоначально он относился к документу IEEE Std 1003.1-1988,

описывавшему прикладной программный интерфейс ОС класса Unix.

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

служебных программ более правильно понимать под словом "POSIX"

стандарт в целом, обозначая перечисленные выше части 2 и 3 через

POSIX.1 и POSIX.2 в соответствии с нумерацией документов IEEE и

ISO/IEC.

Основные идеи стандарта POSIX

Стандарт POSIX описывает множество базовых, системных

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

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

специфицированного для языка C, командного языка и

общеупотребительных служебных программ.

У каждого интерфейса есть две стороны: вызывающая и

вызываемая. Стандарт POSIX ориентирован в первую очередь на

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

исходного языка. Это значит, в частности, что при переносе C-программ

на другую операционную платформу потребуется перекомпиляция. О

мобильности выполнимых программ и/или объектных файлов речь не

идет.

Стандарт POSIX отнюдь не ограничен рамками Unix-среды.

Существуют операционные системы (ОС) "независимого

происхождения" (например, системы реального времени),

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

выполнение POSIX-совместимых приложений. Можно утверждать, что

следование стандарту POSIX облегчает перенос приложений

практически на любую сколько-нибудь распространенную

операционную платформу. Дополнительные усилия по повышению

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

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

рамками рассмотрения их реализацию. В частности, не различаются

системные вызовы и библиотечные функции. Не являются объектом

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

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

подчеркивает направленность стандарта POSIX на приложения, а не на

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

POSIX нейтрален по отношению к системной архитектуре и

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

приложений.

Ориентация на международный стандарт языка C определила не

только стиль описания функций, но и, до некоторой степени,

направление развития спецификаций POSIX в плане синхронизации

обоих стандартов. Как известно в утвержденной в 1999 г. редакции

спецификаций языка C (см. [5]) узаконен комплексный тип данных, что

вызвало соответствующее пополнение POSIX-функций.

В стандарте POSIX проведено разделение на обязательные и

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

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

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

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

распределенных конфигурациях.

Разработчики новой версии стандарта POSIX очень бережно

отнеслись и к его предыстории, и к предыстории Unix-систем, и,

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

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

развития соблюдался принцип обратной совместимости; новые

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

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

вполне понятным причинам: потребовалось устранить противоречия

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

поддержки "традиционного" варианта языка C и перейти на его

международный стандарт.

Основные понятия стандарта POSIX

Стандарт POSIX в редакции 2003-го года - весьма обширный,

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

категории системных компонентов:

• средства разработки;

• сетевые средства;

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

• потоки управления;

• математические интерфейсы;

• пакетные сервисы;

• заголовочные файлы;

• унаследованные интерфейсы.

Именно такой (на верхнем уровне, далеко не полный) репертуар

должна предоставлять операционная система для работы приложения.

Важнейшим является понятие соответствия стандарту POSIX. Мы

уже отмечали, что всякий интерфейс располагает двумя сторонами:

вызывающей и вызываемой. Две стороны есть и у POSIX-соответствия:

соответствие реализации (операционной системы) и приложения.

Реализация (операционная система), соответствующая стандарту

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

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

стандарте поведения. Константа _POSIX_VERSION имеет значение

200112L.

ОС может предоставлять возможности, помеченные в стандарте в

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

Если утверждается, что поддерживается некоторое расширение, это

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

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

В заголовочном файле <unistd.h> следует определить константы,

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

(например, константа _POSIX2_C_DEV обслуживает средства

разработки на языке C). Анализируя эти константы во время

компиляции, приложение выяснит возможности используемой ОС и

подстроится под них. Аналогичные действия на этапе выполнения могут

быть выполнены с помощью функции sysconf() и/или служебной

программы getconf.

Для минимизации размеров ОС и приложений стандартом POSIX

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

возможностей (всего их сорок). С другой стороны, проведено

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

что во многих случаях избавляет от анализа большого числа опций.

Группы эти таковы:

• шифрование;

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

• продвинутые средства реального времени;

• потоки реального времени;

• продвинутые потоки реального времени;

• трассировка;

• ПОТОКИ;

• унаследованные возможности.

Например, в группу "средства реального времени"

(_XOPEN_REALTIME) входят возможности четырнадцати видов, в том

числе планирование на основе приоритетов, асинхронный ввод/вывод,

семафоры, таймеры и т.п.

Версия ОС Linux, на которой готовился текст данного курса,

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

(см. листинг 1.1).

$ getconf _POSIX_VERSION

199506

$ getconf POSIX2_C_DEV

$ getconf _XOPEN_REALTIME

$ getconf _POSIX_TRACE

undefined

Листинг 1.1. Результат применения утилиты getconf к одной из

версий ОС Linux.

Это значит, что поддерживается устаревшая версия стандарта

POSIX, среди прочих присутствуют средства разработки и возможности

реального времени; средства трассировки отсутствуют.

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

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

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

Для приложений понятие соответствия стандарту POSIX богаче

нюансами. Предусмотрено строгое соответствие, главный

отличительный признак которого - ограничение круга используемых

возможностей рамками стандарта. Рассматривается и соответствие с

применением расширений; в этом случае документация на приложение

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

Желательно, чтобы используемые расширения POSIX-возможностей

описывались международными и/или национальными стандартами.

(Отметим, что для реализации понятие строгого POSIX-

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

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

описываются данным стандартом.)

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

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

соответствие стандарту POSIX и поддержку заданных возможностей.

Разумным образом выбранные профили позволяют учитывать

потребности представительных классов пользователей и/или

приложений.

Допускается существование "подпрофилей", описывающих

подмножества стандартных возможностей. Реализация,

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

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

специфических приложений.

К числу важнейших принадлежат понятия, описывающие

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

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

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

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

неопределенным; приложению не только не следует полагаться на

определенный характер подобного поведения - оно не должно

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

поведение.

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

дополнительно означает, что поведение реализации необходимо

документировать.

Стандарт POSIX - это существующий много лет, развивающийся

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

то утрачивается. Устаревшими называются возможности, которые еще

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

вероятно, отомрут. Новые приложения не должны их использовать; для

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

функциональности современная замена.

Более ограниченный смысл придан термину "унаследованный": он

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

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

Основные понятия операционных систем, соответствующих

стандарту POSIX

Мы рассмотрим следующие основные понятия операционных

систем, соответствующих стандарту POSIX:

• пользователь;

• файл;

• процесс;

• терминал;

• хост;

• узел сети;

• время;

• языково-культурная среда.

Это первичные понятия. Их нельзя строго определить, но можно

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

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

применимые к ним операции.

В тексте стандарта POSIX содержатся следующие пояснения

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

1. У пользователя есть имя и числовой идентификатор.

2. Файл - объект, допускающий чтение и/или запись и

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

относятся обычный файл, символьный и блочный специальные файлы,

канал, символьная ссылка, сокет и каталог. Реализация может

поддерживать и другие типы файлов.

3. Процесс - адресное пространство вместе с выполняемыми в

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

потокам требуются.

4. Терминал (или терминальное устройство) - символьный

специальный файл, подчиняющийся спецификациям общего

терминального интерфейса.

5. Сеть - совокупность взаимосвязанных хостов.

6. Языково-культурная среда - часть пользовательского

окружения, зависящая от языковых и культурных соглашений.

Для работы с большим числом сущностей всегда предоставляются

механизмы группирования и построения иерархий. Существует

иерархия файлов, группы пользователей и процессов, подсети и т.п.