Файл: Варианты построения интерфейса программ: особенности и эволюция (Программные интерфейсы).pdf
Добавлен: 28.03.2023
Просмотров: 318
Скачиваний: 4
Практически все операционные системы (UNIX, Windows, OS X и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы.
Для разработчиков приложений все свойства конкретной операционной системы выражаются в свойствах её API. Поэтому операционные системы с различной внутренней организацией, но с одинаковым набором функций API представляются для них одной и той же ОС [2,3]. Это упрощает стандартизацию операционных систем, и обеспечивает переносимость приложений между внутренне различными ОС, соответствующими определенному стандарту на API. Например, общий стандарт API UNIX, одним из которых является стандарт Posix, позволяет говорить о некоторой обобщенной операционной системе UNIX, хотя многочисленные версии этой ОС от разных производителей иногда существенно отличаются внутренней организацией [2].
Приложения выполняют обращения к функциям API с помощью системных вызовов. Способ реализации системных вызовов зависит от структурной организации ОС, которая, в свою очередь, тесно связана с особенностями аппаратной платформы. Кроме того, он зависит от языка программирования. Например, в ОС UNIX системный вызов похож на вызов подпрограммы [2,3].
Операционная система должна обеспечивать удобный интерфейс не только для прикладных программ, но и для человека, работающего за терминалом - пользователя, администратора ОС или программиста.
Современные ОС поддерживают развитые функции пользовательского интерфейса двух типов: алфавитно-цифровой и графический.
В области программного обеспечения общие стандартные API для стандартной функциональности играют важную роль, так как они гарантируют, что все программы, использующие общий API, будут одинаково хорошо работать, или хотя бы более-менее обычным образом. В случае API графических интерфейсов это значит, что программы будут иметь похожий пользовательский интерфейс. Это даст возможность быстрого освоения новых программных продуктов.
С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов wxWidgets, GTK и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написание интерпретируемых языков, реализуемых на разных платформах (sh, Python, Perl, PHP, Tcl, Java и т. д.).
Также в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом каждый API обычно реализован с использованием API программных компонент более низкого уровня абстракции.
Небольшой пример: для того, чтобы увидеть в браузере строку «Hello, world!», нужно лишь создать HTML-документ с минимальным заголовком, и с простейшим телом, содержащим данную строку. При открытии браузером этого документа, программа-браузер передаёт имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, а та при помощи API операционной системы прочитает этот файл, разберётся в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать „Hello, world!“ выбранным шрифтом». При выполнении этих операций библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, а уже эта библиотека обратится к API операционной системы, чтобы записать данные в буфер видеокарты.
В этом примере на каждом из уровней существует несколько возможных альтернативных API: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать различные браузеры. При этом различные браузеры используют различные HTML-библиотеки, всё это может быть собрано с использованием различных библиотек примитивов, и на различных операционных системах.
Таким образом, проявляются основные сложности при использовании современных многоуровневых системах API:
- Сложность портирования программного кода с одной системы API на другую, например, при смене операционной системы;
- Потеря функциональности при переходе с более низкого уровня на более высокий. Каждый уровень API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом или затрудняется, или становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.
Рассмотрим наиболее используемые на сегодняшний день стандарты API операционных систем:
Windows API - общее наименование целого набора базовых функций интерфейсов программирования приложений операционных систем семейств Windows. Является самым прямым способом взаимодействия приложений с Windows.
Windows API спроектирован для использования в языке Си для написания прикладных программ, предназначенных для работы под управлением операционной системы MS Windows. Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.
Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. В то же время, конвенция вызова функций отличается от cdecl, принятой для языка C: Windows API использует stdcall (winapi). Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие. [9]
Windows API состоит из нескольких тысяч вызываемых функций, которые разбиты на следующие основные категории:
1) Базовые службы (Base Services).
2) Службы компонентов (Component Services).
3) Службы пользовательского интерфейса (User Interface Services).
4) Графические и мультимедийные службы (Graphics and Multimedia Services).
5) Обмен сообщениями и совместная работа (Messaging and Collaboration).
6) Сеть (Networking).
7) Веб-службы (Web Services).
Описание Windows API можно найти в документации по набору инструментальных средств разработки программного обеспечения - Windows Software Development Kit (SDK). Эта документация доступна на веб-сайте www.msdn.microsoft.com. Она также включена со всеми уровнями подписки в сеть Microsoft Developer Network (MSDN), предназначенную для разработчиков.
POSIX (Portable operating system interfaces) - Интерфейсы переносимых операционных систем – это группа стандартов, созданная специалистами США под эгидой IEEE (Institute of Electrotechnical and Electronics Engineers), обеспечивающих аффективную по трудоемкости переносимость прикладных программ между различными аппаратными и операционными платформами.
Данный набор стандартов, описывающих интерфейсы между операционной системой и прикладной программой (системный API), библиотеку языка C и набор приложений и их интерфейсов. Стандарт создан для обеспечения совместимости различных UNIX-подобных операционных систем и переносимости прикладных программ на уровне исходного кода, но может быть использован и для не-Unix систем.
Данная группа стандартов сосредоточили проблему переноса программ на унификации интерфейсов операционных систем ЭВМ с различными прикладными программами, а также с окружающей средой: с пользователями, базами данных, средствами коммуникации. Эти стандарты не ориентированы на определенную, конкретную архитектуру ЭВМ, однако предполагают использование современной операционной среды Unix System V как стандарта де-факто, а также международных стандартов на языки программирования и стандартов верхних уровней взаимосвязи открытых систем (ВОС — ISO 07498). В совокупности они образуют нормативную базу открытых компьютерных систем - OCS, обеспечивающих разработку переносимых программных средств и баз данных.
При формировании концепции стандартов POSIX были поставлены следующие задачи:
- содействовать облегчению переноса кода прикладных программ на иные платформы;
- способствовать определению и унификации интерфейсов заранее, а не в процессе их реализации;
- учитывать все главные, созданные ранее и используемые прикладные программы;
- определять необходимый минимум интерфейсов для ускорения создания, одобрения и утверждения документов;
- развивать стандарты в направлении обеспечения коммуникационных сетей, распределенной обработки данных и защиты информации;
-рекомендовать ограничивать использование бинарного (объектного) кода для приложений в простых системах.
Все стандарты POSIX имеют рекомендательный характер. Они не должны служить препятствием для переноса объектного кода, ограничивать или ухудшать исполнение приложений при стандартизированных интерфейсах и ограничивать формирование новых унифицированных интерфейсов по мере необходимости.
Cocoa (в пер. с англ. — какао) — объектно-ориентированный API для операционной системы macOS производства компании Apple. Это один из пяти основных API, доступных в Mac OS X, — - Cocoa, Carbon, Toolbox (для работы старых приложений Mac OS 9), POSIX и Java. Такие языки, как Perl, Python и Ruby, не считаются основными, так как на них пока что пишется не так много серьёзных приложений для Mac OS X.
Приложения, использующие Cocoa, обычно разрабатываются с помощью среды разработки Apple Xcode с использованием языков программирования: C, Objective-C и Swift. Однако, среда Cocoa также доступна и при разработке на других языках, таких как Ruby, Python и Perl с помощью связующих библиотек (MacRuby, PyObjC и CamelBones соответственно). Также можно писать Cocoa-программы на Objective-C в обычном текстовом редакторе и вручную компилировать их с помощью GCC или make-сценариев для GNUstep.
С точки зрения конечного пользователя, Cocoa-приложения - это приложения, написанные с использованием программной среды Cocoa. Такие приложения обычно имеют характерный внешний вид, поскольку эта среда во многом упрощает поддержку принципов «человечного интерфейса» Apple (Apple Human Interface Guidelines).
Одной из особенностей среды Cocoa является механизм для управления динамически выделяемой памятью. В классе NSObject, от которого порождается большинство классов Cocoa, как стандартных, так и пользовательских, для управления памятью реализован механизм подсчёта ссылок (reference counting). Когда количество ссылок достигает нуля, объект удаляется, и занимавшаяся им память освобождается (высвобождение памяти для объектов Objective-C - это то же, что и вызов деструктора у объектов C++. Метод dealloc делает примерно то же самое, что и деструктор в C++. Его вызов не гарантируется.).
Кроме подсчёта ссылок, программисты могут воспользоваться автоматически высвобождаемыми пулами (autorelease pools). они обычно создаются и высвобождаются в начале и в конце цикла сообщений, гарантируя, что выполнение программы выйдет за пределы блока, в котором объекты были зарегистрированы для автоматического высвобождения. Это означает, что приложение выполняется предсказуемо, и освобождение памяти происходит прозрачно для пользователя, в то время как при использовании автоматического сборщика мусора в большинстве случаев программа неожиданно перестаёт реагировать на действия пользователя при его запуске.
Cocoa состоит в основном из двух библиотек объектов Objective-C, называемых фреймворками (Framework). Фреймворки – это, примерно то же, что и динамические библиотеки. Они представляют собой скомпилированные объекты, загружаемые в адресное пространство программы во время исполнения, но помимо этого фреймворки включают ресурсы, заголовочные файлы и документацию. Cocoa также включает систему контроля версий, предупреждающую проблемы, встречающиеся в Microsoft Windows (так называемый «DLL hell»).
Ключевой элемент архитектуры Cocoa — это модель представлений (views). Внешне она организована как обычный фреймворк, но реализована с использованием PDF для всех операций рисования, предоставляемых Quartz. Это позволяет программисту рисовать всё, что угодно, используя команды языка, похожего на PostScript. Кроме того, это автоматически предоставляет возможность вывода любого представления на печать. Поскольку Cocoa обрабатывает обрезку, прокрутку, масштабирование и прочие типичные задачи отображения графики, программист освобождается от необходимости реализовывать базовую инфраструктуру и может сконцентрироваться на уникальных аспектах разрабатываемого приложения.
В архитектуре Cocoa строго соблюдены принципы MVC:
Известная как «парадигма модель-представление-поведение» (MVC), эта концепция предусматривает разделение приложения на три набора взаимодействующих между собой классов. Классы модели представляют данные, такие как документы, файлы настроек или объекты в памяти. Представления, как следует из названия, отображают данные (зачастую визуально). Классы поведения содержат логику, связывающую модели с соответствующими представлениями, и обеспечивают их синхронизацию.
2.2 API графических интерфейсов
Большинству интерфейсов популярных ныне операционных систем свойственно интуитивно-понятное графическое оформление с использованием визуальных эффектов, однако так было не всегда. Первые GUI современному пользователю показались бы достаточно примитивными, хотя в смысле функциональности, по тем временам многие были довольно удобными и качественно справлялись со стоящими перед пользователем задачами.