Интерфейсы прикладного программирования как основа инструментальных средств

Размещено на http://www.allbest.ru/

Федеральное Государственное бюджетное образовательное учреждение высшего профессионального образования

Пермская государственная сельскохозяйственная академия имени академика Д.Н. Прянишникова

Кафедра Информационных систем

Контрольная работа

по дисциплине: "Инструментальные средства информационных систем"

на тему: "Интерфейсы прикладного программирования как основа инструментальных средств"

Выполнил: студент 3 курса заочного отделения

спец-ти: Информационные системы и технологии

Чернов Олег Станиславович

Проверил: Ст. преподаватель

Морозова В.А.

Пермь-2015

Содержание

1. Интерфейс API

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

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

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

2. Сетевой интерфейс прикладного программирования Winsock

Заключение

Список используемой литературы

1. Интерфейс API

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

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

· API прикладных и системных программ, входящих в поставку операционной системы;

· прочие API.

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

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

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

· реализация на уровне ОС;

· реализация на уровне системы программирования (СП);

· реализация на уровне внешней библиотеки процедур и функций.

Возможности API можно оценивать со следующих позиций:

- эффективность выполнения функций API - включает в себя скорость выполнения функций и объем вычислительных ресурсов, потребных для их выполнения;

- широта предоставляемых возможностей;

- зависимость прикладной программы от архитектуры целевой вычислительной системы.

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

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

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

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

Критерии эффективности выполнения приложений с использованием API можно оценивать со следующих позиций:

- время выполнения функций;

- объем необходимых вычислительных ресурсов;

- совокупность предоставляемых сервисов;

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

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

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

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

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

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

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

программирование интерфейс winsock windows

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

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

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

Например, рассмотрим функции динамического выделения памяти в языках С и Pascal. ВС это функции mallос, calloc и free (функции new и delete в С++). В Pascal - new и dispose. Если использовать эти функции в исходном тексте программы, то с точки зрения исходной программы они будут действовать одинаковым образом.

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

Например, те же функции mallос, cal1ос и free в языке С фактически не входят в стандарт ЯП. Они входят в состав стандартной библиотеки, которая входит во все СП, построенные на основе ЯП С. Общепринятые стандарты существуют для многих часто используемых функций языка. Если же взять более специфические функции, такие как функции порождения новых процессов (fork, vfork, nice, kill), то для них нет общепринятого стандарта. Эффективность при реализации функций АPI на уровне СП будет ниже, чем при непосредственном обращении к функциям ОС. Переносимость исходного кода программы в таком варианте будет достаточно высокой. Для выполнения прикладной программы на новой ВС достаточно заново построить код результирующей программы с помощью соответствующей СП.

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

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

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

Например, библиотеки, удовлетворяющие стандарту POSIX, доступны в большинстве СП для языка С. И, если прикладная программа использует только библиотеки этого стандарта, то ее исходный код будет переносимым. Другим примером является известная библиотека графического интерфейса XLib, поддерживающая стандарт графической среды XWindow. Примерами также могут служить библиотеки MFC (Microsoft Foundation Classes) фирмы Microsoft, библиотеки VCL (Visual Controls Library) фирмы Borland, ориентированные на архитектуру ОС семейства Windows, библиотека CLX производства фирмы Borland, ориентированная на архитектуру ОС семейства Unix (Linux) и ОС семейства Windows.

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

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

Отметим следующее: желательно, чтобы API не зависел от СП. Обычно базовые функции API не зависят от СП и могут использоваться из любой СП, хотя и с применением соответствующих правил. В то же время СП может сама генерировать обращения к функциям API. Например, можно написать в программе вызов функции и запросить 512 байт оперативной памяти для размещения данных: unsigned char * ptr = ma11ос (512).

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

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

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

Практически все операционные системы (UNIX, Windows, Mac OS и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем - это множество системных вызовов.

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

С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности - написание "промежуточных" API (API графических интерфейсов WxWidgets, Qt, 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 может быть применён несколькими способами:

· Интегрирован в среду программирования, например C++ или Java API

· В специальном назначении, например Google Maps API или Java API XML для веб-услуг. С помощю Google Maps API можно применить услугу указания местоположения на карте через интерфейс, предоставляемый Google..

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

Различные службы, доступные приложениям через Windows API:

· Базовые службы (Base Services), к которым относятся управление процессами и памятью, функции ввода/вывода и безопасности.

· Службы компонентов (Component Services) - для взаимодействия приложений

· Службы пользовательского интерфейса (User Interface Services) - для взаимодействия с различными меню и окнами

· Службы графики и мультимедиа (Multimedia and Graphics Services)

· Обмен сообщениями и совместная работа (Messaging and Collaboration)

· Сетевые службы (Networking)

· Веб-службы (Web Services)

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

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

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

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

Графический интерфейс программы (GUI, Graphical User Interface) - это совокупность управляющих, визуальных элементов, необходимых для полноценного использования программы, для придания ей эстетической красоты (дружественности). Изображениями же можно назвать иконки, прилагающиеся или скачиваемые отдельно. Как правило, они меняют цветовую гамму интерфейса, а иногда расположение его элементов, их количество или назначение.

Командный интерфейс называется так потому, что в этом виде интерфейса человек подает "команды" компьютеру, а компьютер их выполняет и выдает результат человеку Командный интерфейс реализован в виде пакетной технологии (пакетных файлов) и технологии командной строки. Прикладные программисты используют в своих приложениях обращения к ОС, когда для выполнения тех или иных действий им требуется особый статус, которым обладает только ОС. В большинстве современных ОС все действия, связанные с управлением аппаратными средствами компьютера, другими системными ресурсами может выполнять только ОС. Через обращение к ОС осуществляется выполнение любой задачи. Прикладной программист также может воспользоваться набором сервисных функций ОС, которые упрощают написание приложений. Функции такого типа реализуют универсальные действия, часто требующиеся в различных приложениях, такие, например, как обработка текстовых строк, работа с файлами. Эти функции могли бы быть выполнены самим приложением, однако проще использовать уже готовые, отлаженные процедуры, включенные в состав ОС (например, такие как, creat, open, read, write и др.). В то же время даже при наличии в ОС соответствующей функции программист может реализовать ее самостоятельно в рамках приложения, если предложенный ОС вариант его не устраивает

2. Сетевой интерфейс прикладного программирования Winsock

WinSock - это сетевой интерфейс прикладного программирования, реализованный на всех платформах Win32, основной интерфейс доступа к разным базовым сетевым протоколам. Интерфейс унаследовал многое от реализации Berkeley (BSD) Sockets на платформах UNIX. В средах Win32 он стал абсолютно независимым от протокола, особенно с выпуском WinSock 2.

Термин сокеты (sockets) используется для обозначения описателей поставщиков транспорта. В Win32 сокет отличается от описателя файла, а потому представлен отдельным типом - SOCKET. С позиций эталонной модели OSI интерфейс Winsock расположен м/у сеансовым и транспортным уровнями. Под управлением Windows прикладной, представительский и сеансовый уровни, в основном относятся к вашему приложению. Существуют значительные отличия реализаций сокетов в UNIX и в Windows, что создает очевидные проблемы. Библиотека WinSock поддерживает два вида сокетов - синхронные (блокируемые) и асинхронные (неблокируемые). Синхронные сокеты задерживают управление на время выполнения операции, а асинхронные возвращают его немедленно, продолжая выполнение в фоновом режиме, и, закончив работу, уведомляют об этом вызывающий код.

Заключение

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

Список используемой литературы

1. Гордеев, А.В., Молчанов, А.Ю. Системное программное обеспечение: Учебник. - СПб.: Питер, 2008.

2. Иванова, Г.С. Объектно-ориентированное программирование: Учебник. - М.: Изд-во МГТУ им. Баумана, 2003.

3. Компаниец, Р.И. Системное программирование. Основы построения трансляторов: Учебник. - СПб.: Питер, 2000.

4. Трубачев, Е.С. Троянские программы: механизмы проникновения и заражения // Вестник Волжского университета им. В.Н. Татищева. Серия "Информатика". Вып. 18. - Тольятти: Изд. Волжского университета им. В.Н. Татищева, 2011. - С. 130-135.

5. Трубачева, С.И. Программирование в операционных системах: Учебно-мет.пособие.-Тольятти: Изд-во ВУиТ, 2006.

6. http://www.intuit.ru/studies/courses/631/487/lecture/11048

7. http://www.e-uni.ee/e-kursused/eucip

Размещено на Allbest.ru