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

Сергій Кузнецов

Програмні стандарти є основою підходу Відкритих Систем. По закінченню багатьох років я не можу не погодитися з Юрієм Миколайовичем Знам'янський (Привіт, Юра!) в тому, що для створення розподілених систем необхідно використовувати стандартні транспортні протоколи. В тій чи іншій мірі, в залежності від прикладної області, але принаймні, враховувати наявність стандартів потрібно обов'язково. Якщо ... Якщо ви хочете зберегти можливість розширення своєї системи шляхом залучення до неї компонентів, розроблених незалежно, але з урахуванням стандартів. Якщо ... Якщо ви хочете забезпечити інтероперабельність (новоруські слівце, що означає можливість спільного функціонування незалежно розроблених програмних або апаратних елементів) компонентів своєї системи з компонентами інших систем, розроблених незалежно, але з урахуванням стандартів. Якщо ... Якщо ви хочете зберегти можливість переносу додатків на платформи інших виробників, розроблені незалежно, але з урахуванням стандартів.

Дотримання набору загальноприйнятих стандартів практично еквівалентно прихильності підходу Відкритих Систем. Сьогодні це вже всім зрозуміло (звісно, тим людям, для яких це суттєво). Незрозуміло інше: як повинен бути оформлений стандарт, наскільки він повинен бути формалізовано, як перевірити відповідність конкретної реалізації того чи іншого стандарту. Загальна згода з цього питання відсутня. Є маса різних точок зору, пропонуються різні рішення. І зрозуміло, що навряд чи вдасться прийняти стандарт для складання стандартів. Ця замітка спрямована на те, щоб хоча б частково розібратися з сучасними стандартами програмних засобів, за їх специфікаціями, рівнями формалізації стандартів і можливостями перевірки відповідності стандарту конкретної реалізації. Я не претендую на спільність і викладаю лише власні міркування без посилань на авторитети.

Почнемо з позитивних (і не дуже) прикладів. Для мене найулюбленішим стандартом є міжнародний стандарт ANSI/ISO мови Сі. Ось чому я його люблю. Цей стандарт опубліковано у вигляді двох книг. Перша книга являє собою формальний опис мови, включаючи Бекусовскіе визначення синтаксису та природно-мовні (англійською мовою) опису семантики відповідних мовних конструкцій. Друга книга (Rational) включає докладні неформальні роз'яснення сенсу мовних конструкцій, введених в першій книзі. Ідея стандарту полягає в тому, що паралельно читаються обидві книги. Основна інформація міститься в першому томі, але як тільки виклад на (напів) формальному рівні стає незрозумілим, можна звернутися до відповідним місцем другого тому і отримати неформальні людські пояснення. Крім визначення мовних конструкцій Стандарт Сі містить специфікації основних бібліотек, які повинні підтримуватися в будь-якій стандартній реалізації мови Сі. Наявність цих специфікацій винятково важливо саме по собі, оскільки, як відомо, мова Сі не містить конструкцій, забезпечують зв'язок із зовнішнім світом (зокрема, операторів введення/виводу). Для цієї замітки особливо важливо те, що специфікації бібліотечних функцій у Стандарті Сі вводяться з використанням раніше визначених конструкцій мови Сі. Звичайно, ці специфікації носять тільки синтаксичний характер, а семантика бібліотечних функцій визначається природною мовою.

Другим за якістю, з моєї точки зору, є стандарт мови баз даних SQL-92. За мою думку, цей стандарт є кращим в комп'ютерної історії стандартом мов баз даних. Синтаксичні конструкції мови формально визначаються Бекусовскімі формулами. Семантика операторів описується природною мовою, але досить докладно і точно. Подібно до стандарту мови Сі стандарт SQL-92 містить додаткову частину, в якій засобами мови SQL специфікована необхідні таблиці-каталоги, які повинні підтримуватися в будь-якій SQL-орієнтованої базі даних. За своєю значимістю наявність стандартизованих специфікацій таблиць-каталогів рівносильно наявності стандартизованих специфікацій бібліотек у стандарті мови Сі. Ще раз зауважимо, що специфікації стандарту SQL-92 носять виключно синтаксичний характер. Весь сенс мовних конструкцій і стандартизованих таблиць-каталогів пояснюється на природною мовою.

Напевно, найбільш актуальний набір стандартів у світі операційних систем складають стандарти, складені робочими групами POSIX. Перша робоча група POSIX (Portable Operating System Interface) була утворена в IEEE в 1985 р. на основі UNIX-орієнтованого комітету з стандартизації/usr/group (нині UniForum). Звідси видно первісна спрямованість роботи POSIX на стандартизацію інтерфейсів ОС UNIX. Однак поступово тематика роботи робочих груп POSIX (а з часом їх стало декілька) розширилася настільки, що стало можливим говорити не про стандартну ОС 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). Біда в тому, що при використанні будь-якої такої мови семантичні специфікації виходять занадто складними. Складність семантичної специфікації програмної конструкції наближається до складності реалізації цієї конструкції на мові програмування. Тому, зокрема, виникає задача перевірки правильності (або налагодження?) самих специфікацій. А на що при цьому опиратися? Знову на неформальне опис семантики?

Тому, як це не сумно, у найближчому майбутньому нам доведеться приймати на віру заяви виробників програмних продуктів про їх відповідність стандартам. Деяку впевненість може дати процедура сертифікації програмного продукту, вироблена авторитетною і незалежною організацією. Але і ця впевненість може бути тільки відносною, оскільки експерти, які виконують процедуру, теж спираються на неформальні специфікації семантики.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/