схвалені стандарти, підтримувані акредитованими організаціями з розроблення міжнародних стандартів;
схвалені стандарти, розроблені акредитованими регіональними представниками;
схвалені стандарти, розроблені акредитованими національними представниками;
проекти стандартів, розроблені акредитованими міжнародними представниками.
Правила об’єднаного технічного комітету JTC1 ISO/IEC допускають цитування проектів міжнародних стандартів (Draft International Standards — DISs) як нормативні посилання на міжнародні стандарти; отже, їх розглядають як частину POSIX-OSE. Сюди не вміщені документи робочих груп (Committee Documents — CDs) чи будь-який регіональний або національний проект стандарту, розглянуто як стандарти, що лише створюються.
Форум можна кваліфікувати акредитованим, якщо він функціонує під егідою ISO, ІЕС, ISO/IEC JTC1 чи ITU-T. Сюди входять форуми національних представників і регіональні симпозіуми, санкціоновані для участі безпосередньо в міжнародних форумах.
Пріоритетність вибору специфікацій, відмінних від стандартів. Для специфікацій, відмінних від стандартів, дискутованих за контекстом тимчасових заходів І спрямованих на ліквідацію прогалин у доступних стандартах, рекомендовано використовувати наступний порядок пріоритетності вибору серед специфіка ці й-кандидатів, якщо доступні специфікації множинного застосування:
проекти стандартів, розроблені акредитованими регіональними представниками;
проекти стандартів, розроблені акредитованими національними представниками;
схвалені (на противагу проекту) специфікації (широко прийняті, але неофіційні стандарти), розроблені і (або) підтримувані відкритим форумом, специфікації консорціумів чи деякі де- факто стандарти ;
специфікації, розроблені на закритому форумі.
Стандарт де-факто — одиничний стандарт, широко прийнятий користувачами на практиці. Він може містити широко використовувані офіційні стандарти, документи консорціумів чи запропоновані продукти. Корисна форма специфікації, що становить одночасно де-факто й офіційний стандарт.
Стандарти проектують у тому випадку, коли відсутній включений у POS1X-OSE проект чи схвалений стандарт. В основному тексті перелічено чи обговорено тільки специфікації найвищого пріоритету.
У Настанові зацитовано тільки урядові і де-факто стандарти та специфікації, що дискутуються як прогалини в доступних стандартах.
POSIX-профілі
Результати розробок у стандартизації відкритих систем сприяють розширенню набору базових стандартів, спрямованих на підмножину функціональних вимог, яка постійно зростає.
Профіль проектують, потім здійснюють добір серед основних стандартів для створення відповідного несуперечливого набору стандартів, спрямованого на специфічніші види систем чи групи прикладного програмного забезпечення. Профілі задовольняють вимоги таких предметних областей (domains), як автоматизація офісів чи промисловості, оброблення транзакцій чи керування в реальному часі.
Модель POSIX-OSE забезпечує спосіб для характеристики функціональності щодо дії профілів. Актуальні OSI-профілі мають тенденцію зосереджуватися строго на службах комунікацій ЕЕІ. Відмінні від них профілі могли б зосередитися на одиничному компоненті чи охопити множинні типи інтерфейсу.
Внутрішньоплатформний інтерфейс Plls
У Настанові прикладну платформу трактують як одиничну монолітну комбінацію апаратних засобів і програмного забезпечення, що підтримує інтероперабельність і мобільність застосувань. У деяких моделях чи архітектурі потрібно показати часткову внутрішню деталізацію порядку створення прикладної платформи з різних апаратних або програмних компонентів служб.
Рисунок 6 — Компоненти служб і їхній інтерфейс
Модель, у якій інтерфейс між компонентами служб становить платформу, названа РІІ (Platform internal Interface) і наведена на рисунку 6. Існують види інтерфейсу усередині прикладної платформи, важливі у збиранні комп’ютерних систем. Йдеться про інтерфейс:
між програмними компонентами операційної системи;
між операційною системою й апаратними засобами;
об’єднувальної плати;
пристроїв вводу-виводу.
В Еталонній моделі POSIX-OSE немає намагань ідентифікувати чи застосовувати стандарти до перелічених видів інтерфейсу. Розгляд подібних видів Інтерфейсу лежить поза Настановою, оскільки вони:
не впливають на мобільність та інтероперабельність застосувань;
не впливають на специфікації АРІ й ЕЕІ;
регулюються специфічним технічним підходом до реалізації прикладної платформи.
У Настанові для специфікації АРІ і ЕЕІ не потрібні РІІ-специфікації; оскільки вона наклала би непотрібне обмеження на реалізацію прикладної платформи.4 СЛУЖБИ POSIX-OSE
У цьому розділі описані служби, які підтримують вимоги Настанови. У таблиці 3 подано детальну розбивку на підкатегорії чотирьох головних категорій служб.
Таблиця 3 — Відображення категорій служб за підрозділами розділу 4
|
Категорія служб |
Підрозділ |
Під категорії |
|
Системні |
4.1 4.2 |
Мовна підтримка Системне ядро |
|
Комунікації |
4.3 |
Комунікаційні служби |
|
Інформаційні |
4.4 4.5 4.6 |
Ведення баз даних Обмін даними Оброблення транзакцій |
|
Взаємодія людина/комп’ютер |
4.7 4.8 4.9 4.10 4.11 |
Командний інтерфейс користувача Символьно-орієнтований інтерфейс Система керування попіекранним відображенням Підтримування графіки Розроблення застосувань |
Критерії, використовувані для виділення служб у розділи, визначені в 3.2, їх обговорено на початку кожного розділу. Обговорення для кожного з підрозділів категорії служб побудовано за такою самою ієрархією.
4.П.1 Пояснення. Дано короткий огляд категорій служб І пояснення щодо їхнього використання.
4.п.2Ділянка дії. Описано контекст І критерії ідентифікації категорій служб.
4.п.3 Еталонна модель. Підрозділ побудовано на моделі з 3.2 і додатково деталізує розглянуті у розділі Інтерфейс і служби. Додатково, аналогічно до обговорення 3.6, тут можна розглядати можливі реалізації,
4,п.4 Служби. Розглянуто відповідно до описаної в 4.П.2 ділянки дії.
4.п.5 Стандарти, специфікації і недокументовані служби. У таблицях перелічені стандарти і специфікації, що відповідають службам, переліченим у 4.Л.4. Наведено короткий опис служб, для яких стандарти недоступні. Список стандартів у таблицях повністю охоплює область, що перекриває подані в 4.П.4 служби; не застосовують інші стандарти (визнані ISO як законні нормативні посилання), не включені в POSIX-OSE. У таблицях стовпець «Тип» указує на стан стандарту:
S — актуальний стандарт
Е — вихідний стандарт
Р — загальна специфікація
G— недокументовані служби
Аналогічну познаку для вказівки стану стандарту застосовано і в усіх інших таблицях, де відсутній стовпець «Тип» (наприклад, у таблицях мовних прив'язок).
4.П.5.1 POSIX-OSE-стандарти, За порядком старшинства номерів відповідно до 3.4.2, перелічені стандарти, розглянуті як частина POSIX-OSE, — наявні специфікації, схвалені як стандарти акредитованими представництвами стандартизації. Якщо служби розглянуті на більш високому рівні, не перелічують порівнювані специфікації на більш низькому рівні.
4.П.5.2 Додаткові специфікації
4.п.5.2.1 Вихідні стандарти. У підпункті подано алфавітний список специфікацій і (або) дій, спрямованих на незавершені функціональні області, подані в розділі 4. У підпункті обговорено тільки служби, у цей момент не адресовані до чинних стандартів. Очікується, що документи будуть переміщатися з 4.п.5.2.1 у 4.П.5.1, оскільки вони знаходяться в завершальній стадії обговорення і Настанова відповідно буде модифікуватися.
Специфікації, перелічені в підпункті, не є частиною POSIX-OSE. Вони спрямовані на служби, вміщені до Настанови, і одержать право на включення в POSIX- OSE після офіційного затвердження їх провідними організаціями розроблення стандартів. Використання цих специфікацій треба ретельно розглядати. Існує певний ризик використання вихідних стандартів до їхнього заключного затвердження. Ризик повинен бути збалансованим твердою впевненістю в нестандартних або часткових рішеннях.
4.П.5.2.2 Загальні специфікації. Підпункт вносить до списку будь-які специфікації родини неофіційних стандартів, включаючи державні, де-факто стандарти і стандарти консорціумів, загалом доступні будь-кому без обмеження (наприклад, без вимоги членства) для реалізації і поширення (у тому числі продажу) згідно факторів вибору з 3.4.1.
Специфікації, перелічені у підпункті, можуть становити інтерес, хоча вони і не є частиною POSIX-OSE. Використання цих специфікацій треба ретельно розглядати. Існує певний ризик використання вихідних стандартів до їхнього заключного затвердження. Аналогічно ризик полягає в тому, що такі специфікації не схвалені акредитованою організацією розроблення стандартів. Ризик повинен бути збалансованим твердою впевненістю в нестандартних або часткових рішеннях. Специфікації, включені в Настанову, показують ту частину проведеної роботи, що виконана в областях, які є недокументованими службами POSIX-OSE.
4.П.5.3 Недокументовані служби. Перелічені служби неспецифіковані в Настанові. Тут можуть наводитися продукти (програми) для ілюстрації можливостей, не підтримуваних стандартами.
4.П.6 Перехресна категорія служб POSIX-OSE. У пункті розглянуто будь-які перехресні категорії служб, обговорені в розділі 5 і специфічні ДЛЯ 4.П.
4.П.7 Пов’язані стандарти. Необов’язковий пункт; ідентифікує взяті до уваги залежності між стандартами щодо їхнього вибору.
4.П.8 Відкриті проблеми. Необов’язковий пункт; відбиває проблеми і розбіжності в обговоренні родини відкритих систем.
Мовна підтримка
Пояснення
Якщо несуперечливий інтерфейс до операційної системи необхідний для мобільності застосувань, то в розробленні застосувань використовують мови І системний Інструментарій, що у свою чергу вимагає стандартизації для досягнення мобільності початкового тексту.
У 3.2.2.2 показано, що програміст, який бажає написати пристойний початковий текст програми, використовує одну чи більше стандартних мов програмування. Посилаючись на відповідні настанови з мов програмування і специфікації прив’язок до мови, програміст одержує доступ до будь-яких необхідних служб прикладної платформи. Отже, цього досить для ідентифікації мов програмування як елементів OSE. На вибір мови впливають кілька факторів, зокрема функціональність, відповідність прикладній програмі, особисте уміння й управлінські методи, застосовування в організації.
Впевненість у мобільності програмного компонента зміцнює знання, що він написаний мовою, підтримуваною міжнародними стандартами, а код отриманий транслятором, що має сертифікат відповідності, виданий акредитованим тест-центром. Для мобільності застосувань варто уникати неузго- джених доповнень.
Мови, розглянуті у Настанові, сьогодні найбільш популярні для розроблення програмного забезпечення. Мова командних оболонок (Shell command language) ISO/IEC 9945-2:1993 і деякі утиліти типу awk розглянуто в 4.7. Розглянуті стандарти сьогодні поширені, та їх застосовують в індустрії інформаційних технологій для широкого діапазону процесорів.
Ділянка дії
Далі описані служби, що покривають найбільш розповсюджені неструктурні мови (Кобол, Фортран) і блочно-структурні мови (Сі, Паскаль), які використовують сьогодні для розроблення застосувань; тобто мови для написання прикладних програм. Вони згадуються зазвичай як мови третього покоління. У Настанові не обговорено мови четвертого покоління, які розвилися з мов типу Кобол і Фортран2. За порядком адресації програм до API-служб, описаним в інших розділах Настанови, відповідна прив'язка до мови потрібна для цього інтерфейсу. Посилання на ці прив’язки можна знайти в розділах, що описують відповідні служби.
2 Мови четвертого покоління складають частину майбутньої POSIX-стандартизації.
М овна підтримка в АРІ:
обслуговування арифметичних операцій;
підтримка структурування коду;
визначення даних;
подання даних;
оброблення помилок;
обслуговування операцій вводу-виводу;
оброблення математичних функцій;
логічне керування програмами;
керування паралелізмом;
програмування низького рівня;
аппаратні служби.
Рисунок 7 — Еталонна модель мовної підтримки POSIX OSE
Еталонна модель
Далі розглянуто об’єкти й інтерфейс, що забезпечують мовну підтримку. Еталонна модель для мовної підтримки, наведена на рисунку 7, заснована на Еталонній моделі POSIX-OSE (рисунок 1). Мовна підтримка потрібна для забезпечення прив’язки застосувань у АРІ. Зовнішнє середовище показано на рисунку 7 для завершеності, оскільки мовна підтримка не видима на рівні ЕЕІ.
У спрощеному варіанті програміст, що розробляє застосування, яке вимагає доступу до служб тільки базової операційної системи, використовує транслятор, що задовольняє обом фундаментальним стандартам мови (наприклад, ISO 1989:1985 для Коболу, ISO/IEC 1539-3:1999 для Фортрану) І будь- якої прив’язки, встановленої для відповідного АРІ згідно ISO/IEC 9945-1:1996.
Прикладна програма може вимагати такі служби інших Інформаційних технологій, як ведення баз даних і графіки, мережні служби. У таких випадках постачальники служб повинні пропонувати АРІ, що задовольняють вимоги популярних мов програмування.
