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

1. 6. Система стандартов окружений открытых систем POSIX (POSIX OSE) и эталонная модель RM OSE Лаборатория Открытых информационных технологий Проф. В.А. Сухомлин

2. 1. Методология и система стандартов 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 предназначено для проектирования и использования открытых систем обработки информации.

3. 2. Область применения IEEE P1003.0 ориентирован на потребителей систем (consumers), системных интеграторов (sysmets integrators), разработчиков приложений (application developers), провайдеров систем (systems providers), агенств-поставщиков технологий (procurement agencies). Область применения POSIX OSE- стандарты спецификаций пользовательских интерфейсов (API), которые в совокупности покрывают все аспекты создания и использования общецелевых систем обработки информации. IEEE P1003.0 – не стандарт, а руководство по применению стандартов и каталог стандартов.

4. 3. Цели подхода POSIX OSE Обеспечение для информационных систем: • Переносимости приложений на уровни исходных текстов (Application Portability at the Source Code Level) • Системной интероперабельности (System Interoperability) • Переносимости пользователей (User Portability) • Адаптируемостикстандартам (Accommodation of Standards) • Адаптируемостикновымтехнологиям (Accommodation of new IT)

5. 3. Цели подхода POSIX OSE (продолжение) • Масштабируемостиплатформ (Applicatoon Platform Scalability) • Масштабируемости распределенных систем (Distributed System Scalability) • Прозрачностиреализаций (Inplementation Transparency) • Точности спецификаций пользовательских функциональных требований (User Functional Requirements)

6. 4. Ожидаемый эффект Руководство 1003.0 предназначено для решения следующих задач: - Интеграция информационных систем из компонент различных изготовителей - Эффективность реализаций и разработок, благодаря точности спецификаций и соответствию передовым стандартам - Эффективность переноса прикладного программного обеспечения, благодаря использованию стандартных интерфейсов и прозрачности реализации сервисов систем.

7. 5. Структура и состав системы стандартов POSIX 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

8. 5. Структура и состав системы стандартов POSIX P1003.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

9. 5. Структура и состав системы стандартов POSIX P1201.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

10. 6. Общий подход В POSIX OSEинформационная система рассматривается как черный ящик, взаимодействие с которым стандартизовано и осуществляется только через ее интерфейсы. Через интерфейсы система (платформа) может предоставлять сервисы пользователям (приложениям) и использовать сервисы сущностей внешнего окружения. Центральным понятием данной модели является понятие окружения открытых систем (Open System Environment – OSE). Под открытой системой подразумевается система ИТ, реализующая OSE.

11. 7. Определения 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

12. 7. Определения (продолжение) internationalization interoperability language-binding API language-independent service speci- fication localization open specifications open system Open System Environment (OSE) platform profile portability

13. 7. Определения (продолжение) POSIX Standardized Profile (POSIX SP) profile programming language API specification public specifications reference model scalability specification standardized profile standards validation

14. 8. Принципы построенияPOSIX OSE POSIX OSE состоит из эталонной модели, определений сервисов, стандартов и профилей. POSIX OSE предоставляет минимальный стандартный набор строительных блоков для построения информационных систем. В OSE RM определяются два типа интерфейсов (и сервисов): - интерфейсприкладныхпрограмм (Application Program Interface (API)); • интерфейсвнешнегоокружения (External Environment Interface (EEI)). POSIX OSE основывается на эталонной модели RM OSE.

15. 8.1. Схема построения OSE RM 1) В OSE RM стандарты разбиваются на две категории в соответствии с двумя типами интерфейсов: - стандартыинтерфейсовприкладныхпрограмм (Application Program Interface (API) Standards); - стандартывнешнегоокружения (External Environment Interface (EEI) Standards). Первая - специфицирует взаимодействие прикладного программного обеспечения прикладной платформой. (Предназначены для переносимости приложений). Вторая - определяет взаимодействие системы с ее внешним окружением. (Предназначены для обеспечения интероперабельности систем, переносимости пользователей и данных).

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

17. 8.2. Схема построения OSE RM 2) Указанные выше группы сервисов и стандартов, разбиваются на четыре основных категории: - системные или программные сервисы (System Services) - коммуникационные сервисы (Communication Services) - информационные сервисы (Information Services) - сервисы человеко-машинного взаимодействия (Human/Computer Interaction Services).

18. 8.3. Схема построения OSE RM 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

19. 8.4. Схема построения OSE RM 4) Определяется общее представление RM OSE. 5) Для каждой подкатегории сервисов конкретизируется общая RM OSE с учетом особенностей ее использования. 6) Для каждой подкатегории сервисов на основе соответствующей RM OSEопределяется набор сервисов(функциональность) категории. 7) Для каждого сервиса определяются соответствующие ему ссылки на существующие или разрабатываемые стандарты.

20. 8.4. Схема построения OSE RM 8) В RMPOSIX выделены, так называемые, межкатегориальные сервисы (Cross-Category Services), элементы которых могут входить в любую группу сервисов. К ним относятся: • сервисы интернационализации (Internationalization Services), • сервисы системной безопасности (System Security Services), • сервисы административного управления (Systems Management Services).

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

22. 9.1 RM OSE (entities)

23. 9.2 RM OSE OSE(Interfaces)

24. 9.2API POSIX OSE API – книжная полка, содержащая стандартизованные спецификации APIs. POSIX OSE API – полный набор сервисов, предоставляемых прикладной платформой на API. Сервисы, предоставляемые на API, подразделяются на следующие категории: - System Services API - Communications Services API - Information Services API • Human/Computer Interaction Services API Первая категория обеспечивает доступ к внутренним ресурсам платформы, остальные – к объектам ЕЕ.

25. 9.2API-спецификации Формы API-спецификаций: 1) Programming language API specifications – полностью представленные средствами ЯП. 2) Language-independent service specifications – форма представления не зависит от ЯП. 3) Language-binding API specifications – (2),оттранслированные в форму доступа к сервису, соответствующую конкретному языку программирования. (2) и (3) – наиболее перспективный способ стандартизации API Поэтому базовые спецификации ЯП и спецификации языко-ориентированного связывания являются главными компонентами API.

26. 9.2 Взаимосвязь сервисов EEI-API Взаимосвязь может быть сложной – например, storage-сервис на API может предоставлять приложению прозрачный доступ к удаленному файлохранилищу, используя также сетевой сервис. Доступ в внешним объектам из приложения может осуществляться только через запрос соответствующего сервиса на API. В POSIX OSE взаимосвязь детально не конкретизируется, чтобы не ограничивать выбор оптимальных решений при реализации платформ.

27. 9.3RM OSE OSE(Distributed Systes)

28. 9.3RM OSE OSE(Distributed Systes) В распределенных окружениях прикладные платформы могут взаимодействовать посредством коммуникационного сервиса на EEI. Если приложению необходимо взаимодействие с приложением на другой платформе, то оно делает запрос коммуникационного сервиса на своем API. Запрос на API платформа транслирует в соответствующие действия на EEI. Платформа может состоять из нескольких компонент, взаимодействующих через внутриплатформенный интерфейс.

29. 9.4 RM OSE. Platform Internal Interface

30. 10. Категории сервисов System Services: Language Services System Services Communications Services: Network Services Information Services: Database Services Data Interchange Services Transaction Processing Services Human-Computer Interaction Services: User Command Interface Services Character-Based User Interf. Ss. Windowing System Services Graphic Services ASDSS

31. 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

32. 11. Language Services

33. 11.1 Стандарты языков программирования Ada ISO 8652 C ISO/IEC 9899 C++ ISO/IEC 14882 COBOL ISO 1989 FORTRAN ISO 1539

34. 12. Core System Services

35. 12.1 Process 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 threadbased on timer (or other) events - Protect the process or threadfrom interruption during critical periods - Create a process or threadand make it ready for execution - Destroy a process or threadand 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

36. 12.2 Environment 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

37. 12.3 Node 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

38. 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-1 Asynchronous I/O IEEE Std 1003.b-1 Asynchronous I/O IEEE Std 1003.b-1 Realtime Signals IEEE Std 1003.b-1

39. 13. Communications Services

40. 13.1 Application-to-Platform Communication Services Запрашивается приложением, выполняется платформой от имени данного приложения, посредством взаимодействия с удаленным приложением: 1) File transfer 2) Virtual Terminal 3) Electronic mail

41. 13.2 Application-to- Application Communication Services - RPC Services - Simple Network Services - Detailed Network Services - Distributed System Services

42. 13.3 EEI Services. Incoming Connection Services - Virtual terminal - Remote execution of commands - File transfer services - Remote authentication - Remote data access - Remote status information - Mail delivery services - Directory services

43. 14. Методология тестирования конформности POSIX (Стандарт IEEE P2003) Разрабатываемые посредством стандарта POSIX 2003 методы тестирования конформности реализаций стандартам и POSIX профилям включают следующие компоненты: -комплекты тестов конформности (Comformance Test Suites for POSIX- - PCTS); -- процедуры тестов конформности (Comformance Test Procedure for POSIX - PCTP) - набор методик, дополняющий процесс автоматического тестирования посредством исполнения тестовых комплектов; -- проверку документации требованиям конформности (Comformance Documents for POSIX - PCD).

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

45. 14.1 Подход тестирования конформности POSIX (продолжение) Основные аспекты методологии тестирования конформности POSIX: • определение требований конформности; • процесс установления конформности; • синтаксис языка спецификации утверждений конформности; • коды результатов тестирования.

46. 14.1 Определения для метода тестирования конформности POSIX 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)

47. 14.1 Определения для метода тестирования конформности POSIX 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

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

49. 14.2 Шаги процесса установления конформности • реализация методов тестирования в виде комплектов тестов (Conforming Test Suites), а также инсталляция, конфигурирование, исполнение комплектов тестов и протоколирование результатов прогонов; • анализ значений промежуточных кодов результата тестирования (Intermediate Test Result Codes - ITRC) и их отображение в конечные коды результата тестирования(Final Test Result Codes - FTRC); • проверка конформности реализации посредством сопоставления полученных значений конечных кодов результата тестирования с эталонными значениями кодов конформности (Conforming Test Result Codes - CTRC); • вынесение вердикта о конформности реализации.

50. IUT Conformance Assessment to Single Standard