Программные стандарты и их спецификации

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

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

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

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

Наверное, наиболее актуальный набор стандартов в мире операционных систем - это стандарты, составленные рабочими группами POSIX (Portable Operating System Interface). Первая из них была образована в IEEE в 1985 году на основе Unix-ориентированного комитета по стандартизации /usr/group (ныне UniForum). Первоначально работа POSIX была направлена на стандартизацию интерфейсов Unix. Но постепенно тематика рабочих групп (а со временем их стало несколько) расширилась настолько, что стало возможным говорить не о стандартной ОС Unix, а о POSIX-совместимых операционных средах, имея в виду любую операционную среду, интерфейсы которой соответствуют спецификациям POSIX.

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

Из числа прочих упомянем POSIX 1003.2 "Shell и утилиты", POSIX 1003.3 "Общие методы проверки совместимости с POSIX", POSIX 1003.4 "Средства, предоставляемые системой для прикладных программ реального времени", POSIX 1003.5 "Привязка языка Ада к стандартам POSIX", POSIX 1003.6 "Расширения POSIX, связанные с безопасностью" и т.д.

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

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

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