Лаборатория Открытых информационных технологий Проф....

6. Система стандартов окружений окружений открытых систем POSIX открытых систем POSIX ((POSIX POSIX OSEOSE)) и и

эталонная модель эталонная модель RM OSERM OSE

Лаборатория Открытых информационных технологий

Проф. В.А. Сухомлин

1. 1. Методология и система стандартов POSIX OSEМетодология и система стандартов POSIX OSE

Методология и система стандартов POSIX OSE (POSIX - Portable Operating System Interface for Computer Environments, OSE - Open System Environment) -разработка IEEE .

Данный подход описан в документе IEEE P1003.0 “Guide to the POSIX Open System Environment” («Руководство по окружению открытых систем POSIX”).

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

2. Область применения2. Область применения

IEEE P1003.0 ориентирован на потребителей систем (consumers), системных интеграторов (sysmets integrators), разработчиков приложений (application developers), провайдеров систем (systems providers), агенств-поставщиков технологий (procurement agencies).

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

IEEE P1003.0 – не стандарт, а руководство по применению стандартов и каталог стандартов.

33. Ц. Цели подхода POSIX OSEели подхода POSIX OSE

Обеспечение для информационных систем:

1. Переносимости приложений на уровни исходных текстов (Application Portability at the Source Code Level)

2. Системной интероперабельности (System Interoperability)

3. Переносимости пользователей (User Portability)

4. Адаптируемости к стандартам (Accommodation of Standards)

5. Адаптируемости к новым технологиям (Accommodation of new IT)

33. Ц. Цели подхода POSIX OSEели подхода POSIX OSE ( (продолжениепродолжение))

6. Масштабируемости платформ (Applicatoon Platform Scalability)

7. Масштабируемости распределенных систем (Distributed System Scalability)

8. Прозрачности реализаций (Inplementation Transparency)

9. Точности спецификаций пользовательских функциональных требований (User Functional Requirements)

4. Ожидаемый эффект4. Ожидаемый эффект

Руководство 1003.0 предназначено для решения следующих задач:

- Интеграция информационных систем из компонент различных изготовителей

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

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

55. Структура и состав системы стандартов . Структура и состав системы стандартов POSIXPOSIX

Project Standard/Profile

P1003.0 Guide to the POSIX OSE

P1003.1,.1a System Interfaces

P1003.1b,.1d Realtime

P1003.1c Threads

P1003.1e Security API

P1003.1f Transparent File Access

P1003.1g Protocol-Independent Network Specification

P1003.2,.2b Shell and Utilities

P1003.2c Security Utilities

P1003.2d Batch Queuing Extensions

55. Структура и состав системы стандартов . Структура и состав системы стандартов POSIXPOSIXP1003.5 Ada Bindings

1003.5b Ada Realtime Binding

P1003.9 Fortran Bindings

P1003.10 Supercomputing Profile

P1003.13 Realtime Profile

P1003.14 Multiprocessing

P1003.16 C-Language Bindings

P1003.18 POSIX Platform Profile

P1003.21 Realtime Distributed Systems Communications

P1003.22 Guide to POSIX OSE Security Framework

P1201.1 Uniform API for Graphical User Interfaces

55. Структура и состав системы стандартов . Структура и состав системы стандартов POSIXPOSIXP1201.2 User Interface Drivability

P1224 OSI API – Abstract Data Manipulation

P1224.1 OSI API – X.400 Electronic Mail

P1224.2 OSI API – X.500 Directory Services

P1227.0 OSI API Common Support Functions

P1238.1 OSI API FTAM Test Methods and C Binding

P1224 OSI API Abstract Data Manipulation - C Binding

P1224.1 OSI API X.400 - C Binding

P1224.2 OSI API X.500 - C Binding

P1387.n System Administration

P2003.n Test Methods

66. Общий подход . Общий подход

В POSIX OSE информационная система рассматривается как черный ящик, взаимодействие с которым стандартизовано и осуществляется только через ее интерфейсы.

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

Центральным понятием данной модели является понятие окружения открытых систем (Open System Environment – OSE).

Под открытой системой подразумевается система ИТ, реализующая OSE.

77. Определения. Определения

application platform

application program interface (API)

application software

Application Environment Profile (AEP)

base standard

Communications Interface

External Environment Interface (EEI)

external environment

Human/Computer Interface

Information Interchange Interface

77. Определения. Определения ( (продолжениепродолжение))

internationalization

interoperability

language-binding API

language-independent service speci-fication

localization

open specifications

open system

Open System Environment (OSE)

platform profile

portability

77. Определения. Определения ( (продолжениепродолжение))

POSIX Standardized Profile (POSIX SP)

profile

programming language API specification

public specifications

reference model

scalability

specification

standardized profile

standards

validation

88. Принципы п. Принципы построениостроенияя POSIX OSEPOSIX OSE

POSIX OSE состоит из эталонной модели, определений сервисов, стандартов и профилей.

POSIX OSE предоставляет минимальный стандартный набор строительных блоков для построения информационных систем.

В OSE RM определяются два типа интерфейсов (и сервисов):

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

- интерфейс внешнего окружения (External Environment Interface (EEI)).

POSIX OSE основывается на эталонной модели RM OSE.

8.1. Схема п8.1. Схема построениостроенияя OSE RM OSE RM

1) В OSE RM стандарты разбиваются на две категории в соответствии с двумя типами интерфейсов:

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

- стандарты внешнего окружения (External Environment Interface (EEI) Standards).

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

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

8.1. Г8.1. Главнлавнаяая задач задачаа

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


2) Указанные выше группы сервисов и стандартов, разбиваются на четыре основных категории:

- системные или программные сервисы (System Services)

- коммуникационные сервисы (Communication Services)

- информационные сервисы (Information Services)

- сервисы человеко-машинного взаимодействия (Human/Computer Interaction Services).


3) Для каждой категории сервисов определяется функциональное разбиение на подкатегории сервисов

Service Category Subcategories

1. System Services Language Services

Core System Services

2. Communication Services Communication Services

3. Information Services Database Services

Data Interchange Services

Transaction Processing Services

4. H/C Services User Command Interface S.Character-Based User Interf.S.

Windows System Services

Graphics Services

ASDS Services


4) Определяется общее представление RM OSE.

5) Для каждой подкатегории сервисов конкретизируется общая RM OSE с учетом особенностей ее использования.

6) Для каждой подкатегории сервисов на основе соответствующей RM OSE определяется набор сервисов (функциональность) категории.

7) Для каждого сервиса определяются соответствующие ему ссылки на существующие или разрабатываемые стандарты.


8) В RM POSIX выделены, так называемые, межкатегориальные сервисы (Cross-Category Services), элементы которых могут входить в любую группу сервисов.

К ним относятся:- сервисы интернационализации (Internationalization

Services), - сервисы системной безопасности (System Security

Services), - сервисы административного управления (Systems

Management Services).

9. О9. Общее представление бщее представление RM OSERM OSE

Application Software Entity

Application Platform Entity

External Environment

API – Application Program Interface

EEI – External Environment Interface

API services

EEI services

9.1 9.1 RMRM OSE OSE ((entitiesentities))


Program

Data

Documentation


Program

Data

Documentation



Communication Entities

Information Interchange

Entities

People

API API Services

EEI

9.2 9.2 RMRM OSE OSE OSE OSE (Interfaces)(Interfaces)

Application

Software Entity

Application Platform Entities


System Services

Communication Services

Information Services Human/Computer Interaction Services

Communication Services

Information Services Human/Computer

Interaction Services EEI

CSI ISI HCI

API

9.2 API

POSIX OSE API – книжная полка, содержащая стандартизованные спецификации APIs.

POSIX OSE API – полный набор сервисов, предоставляемых прикладной платформой на API.

Сервисы, предоставляемые на API, подразделяются на следующие категории:

- System Services API - Communications Services API- Information Services API- Human/Computer Interaction Services APIПервая категория обеспечивает доступ к внутренним

ресурсам платформы, остальные – к объектам ЕЕ.

9.2 API-спецификации

Формы API-спецификаций:

1) Programming language API specifications – полностью представленные средствами ЯП.

2) Language-independent service specifications – форма представления не зависит от ЯП.

3) Language-binding API specifications – (2), оттранслированные в форму доступа к сервису, соответствующую конкретному языку программирования.

(2) и (3) – наиболее перспективный способ стандартизации API

Поэтому базовые спецификации ЯП и спецификации языко-ориентированного связывания являются главными компонентами API.

9.2 Взаимосвязь сервисов EEI-API

Взаимосвязь может быть сложной – например, storage-сервис на API может предоставлять приложению прозрачный доступ к удаленному файлохранилищу, используя также сетевой сервис.

Доступ в внешним объектам из приложения может осуществляться только через запрос соответствующего сервиса на API.

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

9.9.33 RMRM OSE OSE OSE OSE (Distributed Systes)(Distributed Systes)

Info


Application Platform


HCI Comm System

People People

Information Interchage Entities Communications

Entities

HCI Comm System Info

HCI Comm Info

EEI

HCI Comm Info

API

EEI

API


Communications Entities


Information Interchage Entities

9.9.33 RMRM OSE OSE OSE OSE (Distributed Systes)(Distributed Systes)

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

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

Запрос на API платформа транслирует в соответствующие действия на EEI.

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

9.9.44 RM RM OSE OSE. Platform Internal Interface. Platform Internal Interface



API – Application Program Interface

API services

Service Component

Service Component

Service Component

PII

10. Категории сервисов10. Категории сервисов

System Services: Language ServicesSystem Services

Communications Services: Network ServicesInformation Services:

Database ServicesData Interchange ServicesTransaction Processing Services

Human-Computer Interaction Services:User Command Interface ServicesCharacter-Based User Interf. Ss.Windowing System ServicesGraphic ServicesASDSS

10.1 Методика описания категорий сервисов10.1 Методика описания категорий сервисов

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

4.__n.1 Overview and Rationale

4.__n.2 Scope

4.__n.3 Reference Model

4.__n.4 Services

4.__n.5 Standards, Specifications, and Gaps

4.__n.6 POSIX OSE Cross-Category Services

4.__n.7 Related Standards

4.__n.8 Open Issues

11. 11. Language ServicesLanguage Services

Application Software



Language Services at the API Arithmetic Operation Services Code Structure Services Data Definition Services Data Representation Services Error Handling Services I/O Operation Services Math Function Services Program Control Services Concurrency Control Services Low-Level Programming

Facility Services

11.1 Стандарты языков программирования11.1 Стандарты языков программирования

Ada ISO 8652

C ISO/IEC 9899

C++ ISO/IEC 14882

COBOL ISO 1989

FORTRAN ISO 1539

12. Core System Services




- Process and Thread Mgmt Ss - Environment Services - Node Internal Comm and Sync Ss - Generalized I/O Services - File Storage Services - Event, Error, Exception Mgmt Ss - Time and Timer Services - Memory Management Services - Logical Naming Services

12.1 12.1 Process and Thread Management ServicesProcess and Thread Management Services

- Stop and restart execution of a process or thread (suspend, resume)

- Modify processor allocation to a process or thread (priority, time slice)

- Modify scheduling of the process or thread based on timer (or other) events

- Protect the process or thread from interruption during critical periods

- Create a process or thread and make it ready for execution

- Destroy a process or thread and recover its resources

- Evaluate a reference to a process

- Evaluate a connection to a process or thread, where a connection is a logical communication path between any two concurrency entities

12.2 12.2 Environment ServicesEnvironment Services

- Attributes specific to entity (process/thread): identification, priority, stack size, scheduling attributes, status, memory allocation)

- Processor-specific attributes (node identification, electronic nameplate information)

- User-specific attributes (user identification and terminal ID, user interaction profile)

- Environment variables (command-line arguments, menu selections)

- Current time and date

12.3 12.3 Node Internal Comm and Sync ServicesNode Internal Comm and Sync Services

- Create, delete, open, close, read, and write shared memory

- Create, delete, read, and write event flags

- Create, delete, set, and wait on semaphores

- Create/send and receive signals

- Create, delete, open, close, send to, get from, and control message queues (IPC).

- Create, delete, send, and receive streams

12.4 Core System Services Standards

Process and Tread Management ISO/IEC 9945-1 Task Management ISO/IEC 9945-1 Environment Services ISO/IEC 9945-1 Node Internal Comm/Synch ISO/IEC 9945-1 Generalized I/O ISO/IEC 9945-1 File Oriented Services ISO/IEC 9945-1 Event, Error, and Exception ISO/IEC 9945-1 Time Services ISO/IEC 9945-1 Memory Management ISO/IEC 9945-1 Logical Naming ISO/IEC 9945-1 Scheduling Services ISO/IEC 9945-1Asynchronous I/O IEEE Std 1003.b-1Asynchronous I/O IEEE Std 1003.b-1Realtime Signals IEEE Std 1003.b-1

13. 13. Communications ServicesCommunications Services




Communication services at the API: - Transparent Network Services - Directory Services - Application-to-Platform Services - Application-to-Application Comm Ss - Distributed System Services

Communication services at the EEI: - Network Connectivity Services - Incoming Connection Services - Network User Interface Services

13.1 13.1 Application-to-Platform Communication Application-to-Platform Communication ServicesServices

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

1) File transfer

2) Virtual Terminal

3) Electronic mail

13.2 13.2 Application-to- Application Communication Application-to- Application Communication ServicesServices

- RPC Services

- Simple Network Services

- Detailed Network Services

- Distributed System Services

13.3 13.3 EEI ServicesEEI Services. . Incoming Connection ServicesIncoming Connection Services

- Virtual terminal

- Remote execution of commands

- File transfer services

- Remote authentication

- Remote data access

- Remote status information

- Mail delivery services

- Directory services

14. 14. Методология тестирования Методология тестирования конформности конформности POSIX (Стандарт IEEE P2003)POSIX (Стандарт IEEE P2003)

Разрабатываемые посредством стандарта POSIX 2003 методы тестирования конформности реализаций стандартам и POSIX профилям включают следующие компоненты:

- комплекты тестов конформности (Comformance Test Suites for POSIX- - PCTS);

- процедуры тестов конформности (Comformance Test Procedure for POSIX - PCTP) - набор методик, дополняющий процесс автоматического тестирования посредством исполнения тестовых комплектов;

- проверку документации требованиям конформности (Comformance Documents for POSIX - PCD).

14.1 Подход14.1 Подход тестирования тестирования конформности конформности POSIXPOSIX

Цель подхода POSIX - обеспечить высокую степень уверенности в том, что реализация конформна стандарту(ам).

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

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

14.1 Подход14.1 Подход тестирования тестирования конформности конформности POSIXPOSIX (продолжение)(продолжение)

Основные аспекты методологии тестирования конформности POSIX:

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

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

14.1 Определения для метода14.1 Определения для метода тестирования тестирования конформности конформности POSIXPOSIX

assertion

assertion test

Conformance requierement

Conformance Test Procedure (CTP)

Conformance Test Software (CTS)

conformance testing

conforming test result code (CTRC)

documentation assertion

final test result code (FTRC)

intermediate result code (ITRC)

14.1 Определения для метода14.1 Определения для метода тестирования тестирования конформности конформности POSIXPOSIX

implementation under testing (IUT)

Conformance Document Audit

system under testing (SUT)

test method implementation

test method specification

test method standard

test purpose

test report

test support

verdict criteria

14.2 Шаги процесса установления конформности14.2 Шаги процесса установления конформности

1. систематический анализ текста стандарта и выделение из него фрагментов, выражающих утверждения (assertions) конформности;

2. формулировка требований конформности в виде одного или нескольких более точно сформулированных утверждений (assertions);

3. записи утверждений конформности в стандартной синтаксической нотации и определение для утверждений эталонных результирующих значений (Conforming Test Results Codes);

4. возможное дополнение методов тестирования неавтоматическими методиками проверки и требованиями к документации;

14.2 Шаги процесса установления конформности14.2 Шаги процесса установления конформности

5. реализация методов тестирования в виде комплектов тестов (Conforming Test Suites), а также инсталляция, конфигурирование, исполнение комплектов тестов и протоколирование результатов прогонов;

6. анализ значений промежуточных кодов результата тестирования (Intermediate Test Result Codes - ITRC) и их отображение в конечные коды результата тестирования (Final Test Result Codes - FTRC);

7. проверка конформности реализации посредством сопоставления полученных значений конечных кодов результата тестирования с эталонными значениями кодов конформности (Conforming Test Result Codes - CTRC);

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

IEEE 2003 Std

Base Standard

Test Method Specification

Test Method Implementation Developer

Test Method Implementation

ITRC

FTRC

CTRC

All Test Result Codes

Match?

Non-Conforming IUT

No

Conforming IUT

YES

IUT Conformance Assessment to Single Standard

14.3 И14.3 Идентификацидентификацияя требований конформности требований конформности

1)В исходном тексте стандарта выявляются вхождения слов shall, may, must, should, can, implementation-defined, undefined и unspecified.

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

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

4) Анализируются выделенные фрагменты для решения вопроса, определяют они требования конформности или нет и, если определяют, данные фрагменты выделяются таким же цветом, как и фрагменты, явно определяющие требования.


В процессе анализа особое внимание следует уделить выявлению условных требований, часто определяемых с помощью связок may-shall. Например, следующее утверждение в спецификации:

The implementation may do either A or B / Реализация может делать A или B/.

If A occurs, then A1 shall... / Если A имеет место, тогда A1 должно.../.

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


Также большое внимание следует уделять анализу фрагментов, в которых используются слова unspecified и undefined.

Использование термина unspecified позволяет разработчикам стандарта разрешить неопределенное поведение правильным программным конструкциям. Напротив, undefined позволяет определенным ошибочным условиям иметь место и не требовать диагностики.

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

14.3 Синтаксис для представления утверждений14.3 Синтаксис для представления утверждений

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

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

- идентификатор утверждения;

- текст утверждения, достаточно детальный для реализации тестов;

- конформные или эталонные коды результата тестирования.

14.3 Синтаксис для представления утверждений14.3 Синтаксис для представления утверждений

Различаются следующие типы утверждений:- Основной (Basic), используемый для

представления одного или нескольких требований стандарта, относящихся к единственному элементу (функции);

- Общий (General), использумый для представления утверждений, относящихся к нескольким элементам стандарта;

- Ссылочный (Reference), используемый для ссылок на уже существующие утверждения;

- Документации (Documentation), используемый для представления требований конформности к документу;

- Общая Документация (General Documentation), используемый для представления требований конформности к группе документов.

14.3 Синтаксис родового утверждения14.3 Синтаксис родового утверждения

For <Elemenr_1>, ..., <Element_n>:If <Applicable_Standard> then

If <Option> thenIf <Test_Support> then

(Setup: <Setup_Requirements>)*Test: <Test_Text>(TR: <Testing_Requirements>)*(FTS: <Formal_Test_Specification>)*(Note: <Notes>)*

Else <No_Test_Support>Else <No_Option>

Else <No_Applicable_Standard>{* единственным обязательным элементом для

<Generic_Assertion> является <Test_Text>}.

15. 15. Состав конечных кодов результатов тестированияСостав конечных кодов результатов тестирования

PASS - IUT удовлетворяет требованиям, определенным утверждением конформности;

FAIL - IUT не удовлетворяет требованиям;INCOMPLETE - Тест утверждения не может выработать ни PASS,

ни FAIL; NO_APPLICABLE_STANDARD - стандарт, требуемый для

тестирования утверждения, не поддерживается IUT;NO_OPTION - опция базового стандарта, требуемая для

тестирования утверждения не поддерживается IUT;NOT_APPLICABLE - утверждение не применимо к профилю;NO_TEST_SUPPORT - отсутствует дополнительное программное

обеспечение или оборудование, необходимое для тестирования данного утверждения;

UNTESTED – отсутствует тест для данного утверждения;UNRESOLVED – код неопределенности.

15. Пример утверждений для функции 15. Пример утверждений для функции forkfork().().

3.1.1 Process CreationFunction: fork().3.1.1.2 Description1 IF PCTS_sem_init() THEN

TEST: Any semaphores that are open in the parent process when it makes a fork() call shall also be open in the child process.

ELSE NO_OPTIONConformance for fork: PASS, NO_OPTION3 FOR: mlock() and mlockall() IF PCTS_function THEN

TEST: A child process shall not inherit any address space memory locks established by the parent process via calls to function() after a fork() call.

ELSE NO_OPTIONConformance for fork: PASS, NO_OPTION

ТТаксономии профилей аксономии профилей OSEOSE POSIXPOSIX

PSEab-HIPHigh Performance Application Environmentsa b Substructure 1 0 Supercomputing Application Environment1 1 Multiprocessor Application EnvironmentPSEab-P Realtime Application Environmenta b Substructure 5 1 Minimal Realtime System Profile5 2 Realtime Controller System Profile5 3 Dedicated Realtime System ProfilePSEab-IP Realtime Application Environmenta b Substructure 5 4 Multipurpose Realtime System Profile