Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Інтерфейси Еталонної моделі

Читайте также:
  1. Етапи і моделі стандартизації ІТ
  2. Інтерфейси користувача
  3. Лттық экономиканы реттеудің кейнстік моделі.
  4. Моделі демократизації
  5. МОДЕЛІ МАСОВОЇ КОМУНІКАЦІЇ
  6. Моделі ринкової економіки та переходу до неї

Рис. 1.4 розширює рис. 1.2 у частині ідентифікації категорій служб, доступних в інтерфейсах API і EEI Еталонної моделі.

Інтерфейс EEI між прикладною платформою і зовнішнім середовищем сприяє обміну даними, тобто він стосується інтеропера­бель­ності системи і прикладного ПЗ. Мобільність користувача і даних безпосередньо забезпечу­ють­ся EEI, але аналогічно мобільність прикладного ПЗ побічно підтримується посилан­нями на спільну концепцію, що зв'язує специфікації в обох різновидах інтерфейсу. Приклад спільного принципу інтеграції взаємодії людина-комп'ютер через API і EEI – вікно. У API нотація Open_Window (x1, y1, x2, y2) визначена для виводу прямокутної зони з координатами верхнього лівого кута (x1, y1) і правого нижнього кута (x2, y2) на площині екрана. Згідно EEI, поява і поведінка вікна може реєструватися незалежно від API. Наприклад, можна прийняти, що всі вікна мають рамки і кнопки у кутах, надані користувачеві для зміни розмірів вікна.

Зміни у специфікаціях для API і EEI робляться певною мірою незалежно, але завжди принцип вікна фундаментальний. Для мобільності цих служб спільний принцип вікна має прийматися для сукупності платформ, щодо яких визначається мобільність. Інші спільні угоди пов'язані з кожним із типів зовнішнього інтерфейсу.

Інтерфейси типу EEI:

- HCI (інтерфейс людина/комп'ютер);

- ISI (інтерфейс інформаційних служб);

- CSI (інтерфейс комунікаційних служб).

HCI – межа-стик, через який відбувається фізична взаємодія між користувачем і прикладною платформою. Приклади інтерфейсу – екран дисплею, клавіатура, миша чи інші пристрої керуван­ня позиціонуванням і звукового вводу-виводу. Зі стандартизацією такого інтерфейсу користувачі звертаються до служб POSIX-OSE без дорогої перекваліфікації.

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

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

POSIX-OSE API – комбінація стандартних інтерфейсів. Можна порівняти POSIX-OSE із книжковою полицею, де стоїть кілька стандартних API, причому кожен API – окрема книга на полиці. POSIX-OSE API описує повний набір служб і їхніх послуг, наданих інтерфейсом між застосуванням і прикладною платформою. Служби API ділять на п’ять категорій за їхніми функціями, див. табл.1.1

Таблиця 1.1 – Перелік категорій і служб POSIX-OSE

Категорія служб Підкатегорії
Системні Мовна підтримка
Системне ядро
Комунікації Комунікаційні сервіси
Інформаційні Підтримка баз даних
Обмін даними
Обробка транзакцій
Взаємодія людина-комп'ютер Командний інтерфейс
Символьно-орієнтований інтерфейс
Система керування поліекранним відображенням
Підтримка графіки
Підтримка розробки застосувань
Перехресні Інтернаціоналізація
Безпека
Адміністрування систем

Специфікації можна описувати як:

- API-специфікації мов програмування, традиційно пов'язані з мовами: тип керування програмами (if... then... else), математичні функції, маніпулювання рядками, паралелізм, механізми програмування низького рівня тощо;

- мовно-незалежні специфікації сервісів, наданих прикладною платформою: тип обміну між процесами, міжоб’єктних повідомлень, доступу до інтерфейсу користувача і сховищ даних;

- API-специфікації мовних прив'язок утворюються, коли мовно-незалежні специфікації служб транслюються у специфікації, орієнтовані на конкретну мову, і використовуються програмістами у застосуваннях, що надають доступ до служб на основі методів, які не суперечать специфіці мови програмування.

Хоча мовно-незалежні специфікації не загальні, вини полегшують керування і розробку несуперечливих (сумісних) стандартів мовних прив'язок. Дихотомія (розподіл класу на два протилежних підкласи) «мова програмування/мовна прив'язка» – результат розвитку стандартів ІТ. Специфікації мов програмування розроблені з метою стати "системно-незалежними" (Сі/С++, Кобол, Фортран). Специфікації мовної прив'язки (наприклад, ISO/IEC 9945-1, MOSI, GKS, SQL) транслюються у " мовно-незалежні" специфікації з однієї чи більшою кількістю прив'язок до мов. Як тільки програміст вирішить, якою мовою користуватися, йому знадобиться настанова з мови програмування і специфікації мовних прив'язок, що забезпечують потрібні сервіси (наприклад, використання Cі/С++ для графіки, мережної обробки). Звідси видно, що головний компонент API – специфікація мови, тому більшість корисних програм створені з використанням тільки основних специфікацій мови.

Відношення служб EEI-API – не просто взаємно однозначне. Наприклад, інтерфейс обслуговування сховища даних може забезпечувати прикладну програму прозорим доступом до віддаленого файлу через мережу. Тоді підтримка обслуговування сховища даних, проведеного в API, залежить від і переноситься на служби комунікацій, наданих у EEI.

Загалом об'єкти застосування ніколи не звертаються безпосередньо до EEI, хоча сервісні запити в API часто закінчуються викликом послуг EEI. Це зазвичай відбувається у механізмах, про які розробник прикладної програми ніколи не піклується, поки задовольняється службовий запит. Аналогічно інформаційні запити (на послуги), доступні в API, іноді виконуються відокремлено (локально), без виклику функцій EEI. Щодо вимог POSIX-OSE немає потреби докладно визначати подібні зв'язки. Фактично занадто деталізований опис суттєво обмежує реалізацію, а кожна прикладна платформа по різному визначає зв'язок між API і EEI.

 


Дата добавления: 2015-11-26; просмотров: 101 | Нарушение авторских прав



mybiblioteka.su - 2015-2024 год. (0.007 сек.)