CC BY
353
УДК: 004.45 ББК: 32.97-018.2
Трубачева С.И.
ОПЕРАЦИОННЫЕ СИСТЕМЫ: ИНТЕРФЕЙСЫ ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ
Trubachyova S.I.
OPERATING SYSTEM: AN APPLICATION PROGRAMMING INTERFACE
Ключевые слова: вычислительная техника, вычислительная машина, вычислительная система, операционная система, программные модули, интерфейс прикладного программирования, программный интерфейс, командный, графический интерфейсы, системные, пользовательские библиотеки.
Keywords: computer technology, computer, computer system, operating system, software modules, application programming interface, software interface, command, graphical interfaces, system, user libraries
Аннотация: различные операционные системы на одних и тех же технических средствах могут предоставить пользователю различные возможности для организации автоматизированной обработки данных. Наличие отлаженных модулей ОС существенно сокращает время написания, выполнения пользовательских приложений. Разработка, внедрение, использование механизмов, обеспечивающих эффективное взаимодействие программных модулей, как системных, так и пользовательских с использованием стандартных функций интерфейсного взаимодействия, позволяют расширить функциональные возможности ОС, эффективность ее функционирования.
Abstract: different operating systems on the same technical means can provide the user with various options for automated data processing organization. The presence of established modules OS significantly reduces the time of writing, running custom applications. Development, implementation and use of mechanisms to ensure effective interaction of software modules, both system and user-defined functions using standard interface interaction allows you to extend the functionality of the operating system, the efficiency of its operation.
Цель научного исследования:
изучение механизмов повышения эффективности разработки, выполнения системных и пользовательских
программных модулей.
Введение
При включении компьютера операционная система (ОС) загружается в оперативную память раньше остальных программ и затем служит платформой и средой для их работы. Без ОС невозможно представить работу с компьютером. Знание операционной системы необходимо для успешного пользования современными компьютерами, ноутбуками, мобильными устройствами.
На сегодняшний момент ОС Windows фирмы Microsoft во всех ее проявлениях, бесспорно, считается самой
распространенной ОС. Конкурируют с ней
ОС семейства Unix. Знание систем Windows, Unix - необходимые кирпичики в стене познания компьютеров.
ОС - комплекс системных, управляющих программ, предназначенных для наиболее эффективного использования всех ресурсов вычислительной системы (ВС). ВС - взаимосвязанная совокупность аппаратных средств вычислительной техники (ВТ) и программного обеспечения (ПО). ВС предназначена для обработки информации и удобства работы с ней. Назначение ОС - организация вычислительного процесса в ВС, рациональное распределение
вычислительных ресурсов между
отдельными решаемыми задачами; предоставление пользователям
многочисленных сервисных средств, облегчающих процессы работы с системой,
программирования и отладки программ. ОС исполняет роль своеобразного интерфейса между пользователем и ВС. Следует заметить, что ОС предоставляет пользователю виртуальную ВС. Это означает, что ОС в значительной степени формирует у пользователя представление о возможностях ВС, удобстве работы с ней, ее пропускной способности, скрывая реальные протекающие процессы.
Различные ОС на одних и тех же технических средствах могут предоставить пользователю разные возможности для организации вычислительного процесса или автоматизированной обработки данных. Кроме того, ОС - это набор системных программ, часть из которых являются библиотеками.
Пользовательские программы
используют системные вызовы для выполнения конкретных задач. Системные вызовы перехватываются библиотеками ОС и обрабатываются. Наличие большого количества библиотек расширяет функциональные возможности ОС.
Постановка задачи
Наличие большого количества библиотек расширяет функциональные возможности ОС. Наличие отлаженных модулей ОС существенно сокращает время написания пользовательских приложений.
Обеспечение эффективного
взаимодействия программных модулей с использованием интерфейса прикладного программирования позволяет повысить эффективность работы системы в целом.
Разработка системных и
пользовательских библиотек, других программных модулей (ПМ), исследование методов взаимодействия ПМ, разработка и внедрение методов, повышающих эффективность работы системы, являются в настоящее время достаточно актуальными.
Задачей научного исследования является исследование существующих и разработка новых механизмов
интерфейсного взаимодействия
пользовательских и системных приложений с целью уменьшения времени создания пользовательских программных модулей, повышения быстродействия их выполнения, обеспечения переносимости программных
модулей с одной аппаратно-программной платформы на другую.
Решение
Одной из основных частей ОС является набор функций, определяющих интерфейс взаимодействия. Интерфейс -универсальный механизм управления ОС любым приложением, независимо от его назначения и предметной области. Интерфейс является оболочкой, с которой общается пользователь. Существуют аппаратный, программный,
пользовательский, графический, командный интерфейсы.
К аппаратному обеспечению компьютерного интерфейса относятся клавиатура, манипулятор типа мыши, джойстика или трекбола, системный блок, монитор.
Программный интерфейс - функции, обеспечивающие доступ к возможностям ресурсов системы, ядра ОС со стороны пользовательских процессов. Используется механизм системных вызовов,
оформленных в виде библиотек.
Пользовательский интерфейс - это совокупность программных и аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером. Основу такого взаимодействия составляют диалоги. Под диалогом в данном случае понимают регламентированный обмен информацией между человеком и компьютером, осуществляемый в реальном масштабе времени и направленный на совместное решение конкретной задачи. Каждый диалог состоит из отдельных процессов ввода / вывода, которые физически обеспечивают связь пользователя и компьютера. Обмен информацией осуществляется передачей и приемом сообщений.
Графический интерфейс программы (GUI, Graphical User Interface) - это совокупность управляющих, визуальных элементов, необходимых для полноценного использования программы, для придания ей эстетической красоты (дружественности). Изображениями же можно назвать иконки, прилагающиеся или скачиваемые отдельно. Как правило, они меняют цветовую гамму интерфейса, а иногда расположение его элементов, их количество или назначение.
Командный интерфейс называется так потому, что в этом виде интерфейса человек подает "команды" компьютеру, а компьютер их выполняет и выдает результат человеку. Командный интерфейс реализован в виде пакетной технологии (пакетных файлов) и технологии командной строки.
Прикладные программисты
используют в своих приложениях обращения к ОС, когда для выполнения тех или иных действий им требуется особый статус, которым обладает только ОС. В большинстве современных ОС все действия, связанные с управлением аппаратными средствами компьютера, другими системными ресурсами может выполнять только ОС.
Через обращение к ОС осуществляется выполнение любой задачи.
Прикладной программист также может воспользоваться набором сервисных функций ОС, которые упрощают написание приложений.
Функции такого типа реализуют универсальные действия, часто
требующиеся в различных приложениях, такие, например, как обработка текстовых строк, работа с файлами. Эти функции могли бы быть выполнены самим приложением, однако проще использовать уже готовые, отлаженные процедуры, включенные в состав ОС (например, такие как, creat, open, read, write и др.). В то же время даже при наличии в ОС соответствующей функции программист может реализовать ее самостоятельно в рамках приложения, если предложенный ОС вариант его не устраивает.
Возможности ОС доступны прикладному программисту в виде набора функций, называющегося интерфейсом прикладного программирования (Application Programming Interface, АР1). От конечного
пользователя эти функции скрыты за оболочкой пользовательского интерфейса.
Для разработчиков приложений все особенности конкретной операционной системы представлены особенностями ее API. Поэтому ОС с различной внутренней организацией, но с одинаковым набором функций API кажутся им одной и той же ОС, что обеспечивается стандартизацией API. Одинаковый набор API обеспечивает переносимость приложений между внутренне различными ОС, но соответствующими определенному
стандарту. Например, соответствие общим стандартам API UNIX, одним из которых является стандарт POSIX, позволяет говорить о некоторой обобщенной ОС UNIX, хотя многочисленные версии этой ОС разных производителей существенно отличаются внутренней организацией.
API имеет следующие направления использования (рисунок 1).
API предназначен для использования прикладными программами системных ресурсов ОС и реализуемых ею функций, представляет собой набор функций, принадлежащих ядру или надстройкам ОС.
API предоставляется системой разработчику, ориентирован на
организацию взаимодействия
результирующей прикладной программы с целевой ВС. Целевая ВС представляет собой совокупность программных и аппаратных средств, в окружении которых выполняется результирующая программа. Сама результирующая программа порождается системой программирования (СП) на основании кода исходной программы, созданного разработчиком, а также объектных модулей и библиотек, входящих в системы программирования, операционные системы.
* - библиотека времени исполнения (RTL - run time library)
Рисунок 1 - Основные направления использования набора функций интерфейса прикладного программирования
Направления использования API
1 г
i 1
Набор функций - API как интерфейс высокого уровня, принадлежащий библиотекам RTL* Набор функций - API прикладных и системных программ, входящих в ОС Другие наборы функций интерфейса прикладного программирования
Приложения выполняют обращения к функциям API с помощью системных вызовов\ Способ, которым приложение получает услуги ОС, похож на вызов подпрограмм. Информация, нужная ОС и состоящая обычно из идентификатора команды и данных, помещается в определенное место оперативной памяти (чаще это стек). Затем управление передается ОС, которая выполняет требуемую функцию и возвращает результат. Если операция проведена неуспешно, то результат включает значение ошибки.
Способ реализации системных вызовов зависит от структурной организации ОС, которая, в свою очередь, тесно связана с особенностями аппаратной платформы. Кроме того, он зависит от языка программирования, СП.
При использовании ассемблера программист устанавливает значения областей памяти, а затем выполняет специальную инструкцию вызова для обращения к некоторой функции ОС.
При использовании языков высокого уровня функции ОС вызываются тем же способом, что и написанные пользователем подпрограммы, требуя задания
определенных аргументов в определенном порядке. Соответствие реальных и виртуальных адресов памяти компонентов программы определяется транслятором СП и ОС. ОС должна обеспечивать удобный интерфейс не только для прикладных
1 Трубачева С.И. Программирование в ОС: Уч. -мет. пособие. Тольятти: Изд. ВУиТ, 2006.
программ, но и для человека, работающего за компьютером.
В ранних ОС пакетной обработки функции пользовательского интерфейса были сведены к минимуму. Команды языка управления заданиями набивались на перфокарты, а результаты выводились на печатающее устройство. Современные ОС поддерживают развитые функции пользовательского интерфейса для интерактивной работы с ВС.
Пользователь имеет в своем распоряжении систему команд, мощность которой отражает функциональные возможности данной ОС. Обычно командный язык ОС позволяет запускать и останавливать приложения, выполнять различные операции с файлами, получать информацию о состоянии ВС (количество работающих процессов, объем свободного и занятого пространства на дисках и т.п.), администрировать ВС. Команды могут вводиться не только в интерактивном режиме, но и считываться из так называемого командного файла,
содержащего некоторую последовательность команд. ПМ ОС, ответственный за чтение последовательности команд из командного файла, называют командным
интерпретатором.
Ввод команды может быть упрощен, если ОС поддерживает графический пользовательский интерфейс. В этом случае пользователь для выполнения нужного действия с помощью мыши выбирает на экране нужный пункт меню или графический символ. Таким образом, разработка системных и пользовательских
библиотек, встраиваемых или в ОС, или в СП, или используемых как внешние модули, существенно упрощает создание пользовательских приложений.
Использование унифицированного набора функций упрощает стандартизацию ОС, обеспечивает переносимость приложений.
Существует несколько вариантов реализации API:
- реализация на уровне ОС;
- реализация на уровне СП;
- реализация на уровне внешней библиотеки.
СП в каждом из этих вариантов предоставляет разработчику средства для подключения функций API к коду программы и организации их вызовов. Объектный код функций (заголовочный файл) API подключается к результирующей программе компоновщиком при
необходимости (статическое, динамическое связывание).
Критерии эффективности
выполнения приложений с использованием API можно оценивать со следующих позиций:
- время выполнения функций;
- объем необходимых вычислительных ресурсов;
- совокупность предоставляемых сервисов;
- зависимость прикладной программы от архитектуры целевой ВС.
В идеале хотелось бы иметь набор функций API, выполняющихся с наибольшей эффективностью,
предоставляющих пользователю все возможности современных ОС и имеющих минимальную зависимость от архитектуры ВС, максимальную защиту данных1.
1 Трубачев Е.С. Троянские программы: методы проникновения и заражения // Вестник Волжского университета им. В.Н. Татищева. Серия Информатика. Вып. 18. - Тольятти: Изд. Волжского университета им. В.Н. Татищева, 2011. С. 130-135.
Реализация функций API на уровне
ОС. При реализации функций API на уровне ОС за их выполнение ответственность несет ОС. Объектный код библиотеки, позволяющий выполнять функции, либо непосредственно входит в состав ОС, либо поставляется в составе динамически загружаемых библиотек, разработанных для данной ОС. СП ответственна только за то, чтобы организовать интерфейс для вызова этого кода. В таком варианте результирующая программа обращается непосредственно к ОС. Этим достигается высокая эффективность выполнения приложений и функций.
Недостатком организации API по такой схеме является непереносимость не только кода результирующей программы, но и кода исходной программы.
Программа, созданная для одной архитектуры ВС, не сможет исполняться на ВС другой архитектуры даже после того, как ее объектный код будет полностью перестроен. Чаще всего СП не сможет выполнить перестроение исходного кода для новой архитектуры ВС, поскольку многие функции API, ориентированные на определенную ОС, могут в новой архитектуре просто отсутствовать.
Таким образом, в данной схеме для переноса прикладной программы с одной целевой ВС на другую будет требоваться изменение исходного кода программы.
Переносимости можно добиться, если унифицировать функции API в различных ОС.
Примером API такого рода может служить набор функций, предоставляемых пользователю со стороны ОС семейства Microsoft Windows - WinAPI (Win 16, Win32, WinCE и др.). Надо сказать, что даже внутри этого корпоративного API существует некая несогласованность, которая ограничивает переносимость программ между различными ОС семейства Windows.
Таким образом, при реализации функций API на уровне ОС достигается высокая эффективность выполнения функций. Недостатком организации API по такой схеме является практически полное
отсутствие переносимости не только кода результирующей программы, но и кода исходной программы.
Реализация функций АPI на уровне системы программирования. Если функции API реализуются на уровне СП, они предоставляются пользователю в виде библиотеки функций соответствующего языка программирования (ЯП). Обычно речь идет о библиотеке времени исполнения. СП предоставляет
пользователю библиотеку
соответствующего ЯП и обеспечивает подключение к результирующей программе объектного кода, ответственного за выполнение этих функций.
Очевидно, что эффективность выполнения функций в таком варианте будет несколько ниже, чем при непосредственном обращении к функциям ОС. Так происходит, поскольку для выполнения многих функций API библиотека RTL ЯП должна все равно выполнять обращения к функциям ОС. Наличие всех необходимых вызовов и обращений к функциям ОС в объектном коде RTL обеспечивает СП.
Однако переносимость исходного кода программы в таком варианте будет достаточно высокой, поскольку синтаксис и семантика всех функций будут строго регламентированы в стандарте
соответствующего ЯП. Они зависят от ЯП и не зависят от архитектуры целевой ВС. Поэтому для выполнения прикладной программы на новой ВС достаточно заново построить код результирующей программы с помощью соответствующей СП. Единообразное выполнение функций ЯП обеспечивается СП. При ориентации на различные архитектуры целевой ВС в СП могут потребоваться различные
комбинации системных вызовов функций ОС для выполнения одних и тех же функций исходного кода. Это должно быть учтено в коде библиотек RTL. В общем случае для каждой архитектуры целевой ВС будет требоваться свой код библиотеки RTL ЯП. Выбор объектного кода RTL для подключения к результирующей программе СП обеспечивает автоматически. Например, рассмотрим функции динамического
выделения памяти в языках С и Pascal. В С это функции malloc, calloc и free (функции new и delete в С++)1. В Pascal -new и dispose.
Если использовать эти функции в исходном тексте программы, то с точки зрения исходной программы они будут действовать одинаковым образом. Для разработчика не имеет значения, на какую архитектуру ориентирована его программа. Это имеет значение для СП, которая для каждой из этих функций должна подключить к результирующей программе объектный код библиотеки. Этот код b будет выполнять обращение к соответствующим функциям ОС.
Проблема, главным образом, заключается в том, что большинство ЯП предоставляют пользователю не очень широкий набор функций, разработчик существенно ограничен в выборе доступных API.
Разработчик может обратиться к функциям других библиотек, имеющихся в составе СП. В этом случае нет гарантии, что функции, включенные в состав СП, но не входящие в стандарт ЯП, будут доступны в другой СП. Особенно, если она ориентирована на другую архитектуру целевой ВС. Такая ситуация уже ближе к третьему варианту реализации API.
Например, те же функции malto^ cal1ос и free в языке С фактически не входят в стандарт ЯП. Они входят в состав стандартной библиотеки, которая входит во все СП, построенные на основе ЯП С. Общепринятые стандарты существуют для многих часто используемых функций языка.
Если же взять более специфические функции, такие как функции порождения новых процессов (fork, vfork, nice, kill), то для них нет общепринятого стандарта.
Таким образом, эффективность при реализации функций API на уровне СП будет ниже, чем при непосредственном обращении к функциям ОС. Переносимость исходного кода программы в таком варианте будет достаточно высокой. Для выполнения прикладной программы на
1 Трубачева С.И. Программирование на СИ: Учебное пособие. Тольятти: Изд. ВУиТ, 2006.
новой ВС достаточно заново построить код результирующей программы с помощью соответствующей СП.
Реализация функций 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 = та11ос (512). СП языка С сгенерирует последовательность
обращений: из кода пользовательской программы будет осуществлен вызов библиотечной функции malloc;
библиотека времени выполнения TRL в
данном случае реализует вызов функции malloc, как вызов системной функции API.. Параметры выделяемого блока памяти в таком случае задаются СП, и пользователь лишен возможности задавать их напрямую.
С другой стороны, если это необходимо, возможно использование функций API прямо в тексте программы. Непосредственное обращение к функциям API позволяет пользователю обращаться к системным ресурсам более эффективным способом. Однако это требует знания функций API, количество которых нередко достигает нескольких сотен. Как правило, API не стандартизированы. В каждом конкретном случае набор вызовов API определяется, прежде всего, архитектурой ОС и ее назначением. В то же время принимаются попытки стандартизировать некоторый базовый набор функций, поскольку это существенно облегчает перенос приложений с одной ОС в другую. Таким примером может служить очень известный и, пожалуй, один из самых распространенных стандартов - стандарт POSIX. В этом стандарте перечислен большой набор функций, их параметров и возвращаемых значений.
Стандартизированными, согласно POSIX, являются не только обращения к API, но и файловая система, организация доступа к внешним устройствам, набор системных команд. Использование в приложениях этого стандарта позволяет в дальнейшем легко переносить такие программы с одной ОС в другую путем перекомпиляции исходного текста.
Ниже приведен пример части программы копирования файла в файл. Программа иллюстрирует использование некоторых системных вызовов для работы с файлами. Первый параметр содержит имя существующего файла, второй параметр -имя нового файла.
... /* Открываем первый файл для чтения */
if (fd1 = open(argv[1], 0_RDONLY) < 0)
{
fprintf (stderr, "Не могу открыть файл %s \ n", argv[1]);
exit (1);
}
/* Создаем новый файл для записи */
if (fd2 = open(argv[2], 0_WRONLY |
O_CREAT, mode) < 0)
{
fprintf (stderr, "Не могу создать файл %s \ n", argv[2]);
exit (1);
}
/*Считываем BUFSIZE байт в массив buf */
while(nbytes = read(fd1, buf, BUFSIZE) < 0) {
/* Записываем во второй файл из массива buf nbytes байт */
if (write(fd2, buf, nbytes) < 0)
{
fprintf (stderr, "Ошибка записи \ n"); break; } }
if(nbytes < 0) fprintf (stderr, "Ошибка чтения \ n"); ...
Заключение
При реализации функций API на уровне ОС достигается высокая эффективность выполнения функций. Недостатком организации API по такой схеме является практически полное отсутствие переносимости не только кода результирующей программы, но и кода исходной программы.
При реализации функций API на уровне СП эффективность будет ниже, чем при непосредственном обращении к функциям ОС. Переносимость исходного кода программы в таком варианте будет достаточно высокой. Для выполнения прикладной программы на новой ВС достаточно заново построить код результирующей программы с помощью соответствующей СП.
При реализации функций API с помощью внешних библиотек
эффективность выполнения имеет низкие результаты. Только при высоком качестве внешней библиотеки ее эффективность становится сравнимой с библиотекой RTL. Если говорить о переносимости исходного кода, то здесь требование одно -используемая внешняя библиотека должна быть доступна в любой из архитектур ВС,
на которые ориентирована прикладная программа. Тогда удается достигнуть переносимости. Это возможно, если используемая библиотека удовлетворяет какому-то принятому стандарту, а СП поддерживает этот стандарт.
Итак, были рассмотрены основные цели, задачи, принципы и подходы к реализации API, преимущества и недостатки способов взаимодействия программных модулей. Разработка программных модулей ОС, системных и пользовательских библиотек увеличивает функциональные возможности системы, облегчает работу прикладного
программиста за счет использования отлаженных библиотек.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Гордеев, А.В., Молчанов, А.Ю. Системное программное обеспечение: Учебник. -СПб.: Питер, 2008.
2. Иванова, Г.С. Объектно-ориентированное программирование: Учебник. - М.: Изд-во МГТУ им. Баумана, 2003.
3. Компаниец, Р.И. Системное программирование. Основы построения трансляторов: Учебник. - СПб.: Питер, 2000.
4. Трубачев, Е.С. Троянские программы: механизмы проникновения и заражения // Вестник Волжского университета им. В.Н. Татищева. Серия «Информатика». Вып. 18. - Тольятти: Изд. Волжского университета им. В.Н. Татищева, 2011. - С. 130-135.
5. Трубачева, С.И. Программирование в операционных системах: Учебно-мет. пособие.-Тольятти: Изд-во ВУиТ, 2006.
6. Трубачева, С.И. Влияние информационных технологий на формирование профессиональных компетенций / Материалы международной научно-практической конференции «Татищевские чтения: актуальные проблемы науки и практики». - Тольятти: Изд. ВУиТ, 2010. - С. 26-35.
7. Трубачева, С.И. Системное программное обеспечение: Учебное пособие. -Тольятти: Изд-во ВУиТ, 2010.
8. Трубачева, С.И. Основные аспекты защиты персональных данных на предприятии // Вестник Волжского университета им. В.Н. Татищева. Серия «Информатика». Вып. 16. - Тольятти: Изд. ВУиТ, 2010. - С. 25-32.
