Лекция 4. Информационные системы

Лекция 4. Стандарты пользовательского интерфейса ИТ

4.1. Интерфейс прикладного программирования

Прежде всего необходимо однозначно разделить общий термин API (application program interface, интерфейс прикладного программирования) на следующие направления:

API как интерфейс высокого уровня, принадлежащий к библиотекам RTL;
API прикладных и системных программ, входящих в поставку операционной системы;
прочие API.

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

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

Существует несколько вариантов реализации API:

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

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

Что касается двух других показателей, то в принципе нет никаких технических ограничений на их реализацию. Однако существуют организационные проблемы и узкие корпоративные интересы, тормозящие создание такого рода библиотек.

Реализация функций API на уровне ОС

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

В таком варианте результирующая программа обращается непосредственно к ОС. Поэтому достигается наибольшая эффективность выполнения функций API по сравнению со всеми другими вариантами реализации API.

Недостатком организации API по такой схеме является практически полное отсутствие переносимости не только кода результирующей программы, но и кода исходной программы.

Реализация функций API на уровне системы программирования

Если функции API реализуются на уровне системы программирования, они предоставляются пользователю в виде библиотеки функций соответствующего языка программирования. Обычно речь идет о библиотеке времени исполнения - RTL (run time library). Система программирования предоставляет пользователю библиотеку соответствующего языка программирования и обеспечивает подключение к результирующей программе объектного кода, ответственного за выполнение этих функций.

Очевидно, что эффективность функций API в таком варианте будет несколько ниже, чем при непосредственном обращении к функциям ОС. Так происходит, поскольку для выполнения многих функций API библиотека RTL языка программирования должна все равно выполнять обращения к функциям ОС. Наличие всех необходимых вызовов и обращений к функциям ОС в объектном коде RTL обеспечивает система программирования.

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

Реализация функций API с помощью внешних библиотек

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

Система программирования ответственна только за то, чтобы подключить объектный код библиотеки к результирующей программе. Причем внешняя библиотека может быть и динамически загружаемой (загружаемой во время выполнения программы).

С точки зрения эффективности выполнения этот метод реализации API имеет самые низкие результаты, поскольку внешняя библиотека обращается как к функциям ОС, так и к функциям RTL языка программирования. Только при очень высоком качестве внешней библиотеки ее эффективность становится сравнимой с библиотекой RTL.

Если говорить о переносимости исходного кода, то здесь требование только одно - используемая внешняя библиотека должна быть доступна в любой из архитектур вычислительных систем, на которые ориентирована прикладная программа. Тогда удается достигнуть переносимости. Это возможно, если используемая библиотека удовлетворяет какому-то принятому стандарту, а система программирования поддерживает этот стандарт.

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

4.2. Платформенно-независимый интерфейс POSIX

POSIX (Portable Operating System Interface for Computer Environments) - платформенно-независимый системный интерфейс для компьютерного окружения. Это стандарт IEEE, описывающий системные интерфейсы для открытых операционных систем, в том числе оболочки, утилиты и инструментарии. Помимо этого, согласно POSIX, стандартизированными являются задачи обеспечения безопасности, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС.

Этот стандарт подробно описывает VMS (virtual memory system, систему виртуальной памяти), многозадачность (МРЕ, multiprocess executing) и технологию переноса операционных систем (CTOS). Таким образом, на самом деле POSIX представляет собой множество стандартов, именуемых POSIX.1 - POSIX.12.

Программы, написанные с соблюдением данных стандартов, будут одинаково выполняться на всех POSIX-совместимых системах. Однако, часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования. На рис. 4 изображена типовая схема реализации строго соответствующего POSIX приложения.

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

4.3. Проектирование пользовательского интерфейса

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

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

физическом, который относится к техническим средствам;
синтаксическом, который относится к последовательности и порядку появления элементов на экране (язык общения) и последовательности запросов (язык действий);
семантическом, который относится к значениям элементов, составляющих интерфейс. Согласованность интерфейса экономит время пользователя и разработчика. Для пользователя уменьшается время изучения, а затем использования системы, сокращается число ошибок, появляется чувство комфортности и уверенности. Разработчику согласованный интерфейс позволяет выделить общие блоки, стандартизировать отдельные элементы и правила взаимодействия с ними, сократить время проектирования новой системы.

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

Преимущество использования меню действий заключается в том, что эти действия наглядны и могут быть запрошены пользователем установкой курсора, функциональной клавишей, вводом команды либо каким-то другим простым способом. Меню действий содержит объекты, состоящие из одного или нескольких слов. Последний из них резервируется для действия «справка». Размещаются объекты слева направо по мере убывания частоты их использования. Возможны системы с многоуровневой системой выпадающих меню, но оптимальное число уровней - три, так как иначе могут появиться трудности в понимании многоуровневых меню.

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

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

Разбивка панели на области основана на принципе «объект- действия». Этот принцип разрешает пользователю сначала выбрать объект, затем произвести действия с этим объектом, что минимизирует число режимов, упрощает и ускоряет обучение работе с приложениями и создает для пользователя комфорт. Если панель располагается в отдельной ограниченной части экрана, то она называется окном, которое может быть первичным или вторичным. первичное окно может содержать столько панелей, сколько нужно для ведения диалога. Вторичные окна вызываются из первичных. Они часто используются для подсказки.

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

Путь, по которому движется диалог, называется навигацией. Диалог состоит из двух частей: запросов на обработку информации и навигации по приложению. Часть запросов на обработку и навигацию является унифицированной, т.е. это действия, имеющие одинаковый смысл во всехприложениях. К унифицированным действиям можно отнести «отказ» («отмена»), «ввод», «выход», «справка» и другие.

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