автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Методы информационно-аналитической поддержки разработки и использования стандартов на интерфейсы операционной системы Linux

0046 1658

Российская академия наук Институт системного программирования

УДК 519.685 Яа правах рукописи

Силаков Денис Владимирович

МЕТОДЫ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ ПОДДЕРЖКИ РАЗРАБОТКИ И ИСПОЛЬЗОВАНИЯ СТАНДАРТОВ НА ИНТЕРФЕЙСЫ ОПЕРАЦИОННОЙ СИСТЕМЫ LINUX

Специальность 05.13.11 -математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата физико-математических наук

Москва 2010

2 8 0КТ 2010

004611658

Работа выполнена в Институте системного программирования РАН.

Научный руководитель:

доктор физико-математических наук Петренко Александр Константинович

Официальные оппоненты:

профессор, доктор физико-

математических наук,

Васенин Валерий Александрович,

профессор, доктор технических наук, Кузнецов Сергей Дмитриевич

Ведущая организация:

Институт электронных управляющих машин им. И.С. Брука (ИНЭУМ)

Защита диссертации состоится « 14 » октября 2010 г. в 15 часов на заседании диссертационного совета Д.002.087.01 при Институте системного программирования РАН по адресу:

109004, Москва, ул. Александра Солженицына, д.25,

Институт системного программирования РАН, конференц-зал (комн. 110).

С диссертацией можно ознакомиться в библиотеке Института системного программирования РАН.

Автореферат разослан « » сентября 2010 г.

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

/Прохоров С.П./

Общая характеристика работы

Актуальность темы

По данным порталов lwn.net и distrowatch.com, в настоящее время насчитывается более 500 дистрибутивов операционной системы Linux, основанных на ядре Linux, библиотеках и инструментарии проекта GNU. Несмотря на близость этих систем, обеспечение переносимости приложений между ними во многих случаях требует серьезных трудозатрат — различные системы могут использовать различные версии базовых компонентов, а многие производители дистрибутивов вносят в эти компоненты модификации, отражающие специфику конкретной системы. Как результат, функциональность, предоставляемая одним и тем же компонентом в разных дистрибутивах, может существенно различаться.

Многие разработчики программного обеспечения не считают экономически целесообразной проверку приложений на совместимость с каждым дистрибутивом, и ограничиваются поддержкой наиболее популярных систем (как правило, от 2 до 10). По этой причине, несмотря на богатый выбор, пользователи зачастую ограничены теми дистрибутивами, которые поддерживаются необходимыми им приложениями.

Одним из основных подходов к обеспечению переносимости является стандартизация — определение набора свойств, которыми должна обладать любая платформа, где может быть запущено приложение. Одним из важнейших типов свойств, определяемых стандартами в области разработки ПО, является интерфейс взаимодействия операционной системы с приложениями. Основным, хотя и не единственным видом такого взаимодействия, является программный интерфейс, включающий набор функций (как правило, сгруппированных в библиотеки), предоставляемых системой и доступных выполняемым в ней программам. Соответственно, основные усилия в области стандартизации интерфейса взаимодействия ОС с приложениями направлены на стандартизацию программного интерфейса. Наиболее известными стандартами на интерфейсы ОС являются POSIX и LSB (Linux Standard Base). LSB более молодой стандарт, но он уже охватывает практически в 20 раз больше интерфейсов, чем POSIX.

Качественная поддержка процедуры переноса приложений требует рассмотрения широкого спектра интерфейсных сущностей. Помимо непосредственно библиотечных функций, необходимы описания заголовочных файлов, типов данных, вспомогательных констант и макроопределений. Часть этих сущностей отражает специфику конкретных языков программирования и их стандартизация требует исследования особенностей как самих языков, так и соответствующих систем трансляции. Используемые в Linux компиляторы GCC поддерживают целый ряд языков, для которых осуществляется сборка бинарных файлов в формате ELF; помимо этого, в приложениях Linux активно используются несколько десятков интерпретируемых языков.

Кроме значительного числа разнообразных видов интерфейсных сущностей, трудности возникают в связи с большим количеством сущностей каждого вида. Например, современные дистрибутивы Linux предоставляют до нескольких тысяч библиотек и сотен тысяч функций. Большинство приложений используют от нескольких десятков до нескольких тысяч функций. Количество приложений велико. Порталы freshmeat.net и sourceforge.net, например, содержат более десяти тысяч программ для ОС Linux. В процессе стандартизации важно оценить реальные потребности приложений и возможности существующих систем, чтобы включать в стандарт с одной стороны, наиболее востребованные приложениями интерфейсы, с другой — интерфейсы, поддерживаемые большим количеством различных дистрибутивов. Подобный подход используется, в частности, при разработке POSIX и LSB. По причине большого количества интерфейсов во множестве программных средств на основе ОС Linux (далее для краткости — экосистеме Linux), необходимы средства автоматизации подобного анализа.

Кроме упомянутой автоматизации, нецелесообразно разрабатывать стандарты «с нуля». А именно, необходимо опираться на уже существующие спецификации. Документация различного характера доступна для многих библиотек и функций Linux, однако она сильно разрознена и при разработке стандарта необходимы средства для ее консолидации и унификации. Важным аспектом является формирование профилей — объединений стандартов либо их подмножеств, охватывающих определенный класс систем. При выделении подмножеств стандартов, равно как и при их объединении, встает задача

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

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

Цель и задачи работы

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

1. Исследовать многообразие видов интерфейсов приложений с ОС Linux и построить логическую модель системы интерфейсов.

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

a. возможность адаптации информационной системы к изменениям модели системы интерфейсов;

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

3. Разработать информационно-аналитическую систему, обеспечивающую:

a. поддержку создания и сопровождения среды разработки приложений, отвечающих требованиям стандарта;

b. поддержку принятия решений в процессе стандартизации на основе анализа существующих реализаций;

c. возможность создания профилей стандартов.

4. Провести апробацию предложенного подхода на современных интерфейсных стандартах операционных систем.

Научная новизна

Научной новизной характеризуются следующие результаты работы:

1. Логическая модель системы интерфейсов приложений с ОС Linux.

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

3. Новый метод построения системы поддержки принятия решений в процессе разработки интерфейсных стандартов, базирующийся на анализе интерфейсов, присутствующих в экосистеме Linux.

Практическая значимость

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

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

Разработанные методы были успешно использованы при построении информационно-аналитической системы стандарта Linux Standard Base (LSB) в рамках совместного проекта ИСП РАН и консорциума Linux Foundation по развитию инфраструктуры LSB, стартовавшего в 2006 г. В 2009 г., также совместно с Linux Foundation, была построена информационно-аналитическая система для профиля стандарта мобильных устройств на базе платформы Moblin (Moblin Compliance Specification).

Апробация и публикации

Результаты работы докладывались на семинаре Института проблем информационной безопасности в 2010 году, на 51й Научной конференции МФТИ в 2008 году, на IX Международной научно-технической конференции "Кибернетика и высокие технологии XXI века" (Воронеж) в 2008 году, на семинарах ИСП РАН в 2009-2010 гг., на конференциях SYRCoSE в 2007-2009 гг., на конференциях разработчиков свободных программ на Протве (Обнинск) в 2007-2009 гг., на конференции OpenCert (Милан, Италия) в 2008 году.

По теме диссертации автором опубликовано 15 работ (из них 2 в изданиях по перечню ВАК), список которых приведен в конце автореферата.

Структура и объем диссертации

Диссертация состоит из введения, четырех глав, заключения, списка литературы (96 наименований) и одного приложения. Основной текст диссертации (без приложений и списка литературы) занимает 135 страниц.

Краткое содержание диссертации

Во введении обосновывается актуальность темы работы, определяются ее цели и задачи, раскрывается практическая значимость.

Глава 1 посвящена обзору существующих подходов к повышению уровня переносимости программного обеспечения между различными программно-аппаратными платформами на примере программ для ОС Linux. Рассматриваются методы управления требованиями при разработке программного обеспечения.

В первом разделе дается краткий обзор подходов к повышению уровня переносимости приложений между дистрибутивами Linux. Рассматриваются как методы, используемые разработчиками приложений, так и подходы к решению проблемы со стороны производителей дистрибутивов. Отмечается, что методы, применяемые создателями дистрибутивов, жестко привязаны к инфраструктурам разработки конкретных дистрибутивов (системам сборки, структуре репозиториев, способам установки на машины пользователей). Кроме того, эти методы ориентированы только на открытые приложения.

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

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

Во втором разделе рассматриваются существующие подходы к разработке стандартов ПО. Особое внимание уделяется процессам создания современных стандартов на интерфейсы между операционной системой и приложениями — таких, как POSIX и Linux Standard Base (LSB). Рассматриваются близкие задачи централизованного управления требованиями ПО. Раскрывается схожесть этих задач с задачами, возникающими при создании стандартов на интерфейсы. Проводится анализ возможности переноса подходов, используемых в системах управления требованиями, в область разработки стандартов.

Третий раздел содержит сравнительный анализ рассмотренных решений задачи повышения уровня переносимости приложений ОС Linux, из которого делаются перечисленные далее выводы.

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

2. Перспективным способом обеспечения переносимости ПО является следование стандартам на бинарный интерфейс приложений с ОС.

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

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

Отмечается также, что обязательным требованием к технологии разработки стандартов в ОС Linux является необходимость предоставления средств сбора и анализа информации об экосистеме Linux.

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

• структурные характеристики, которые могут быть проверены статически - например, состав библиотек или сигнатуры функций;

• семантические характеристики, для проверки которых в общем случае необходимо проведение тестирования, например, — поведение функций.

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

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

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

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

• атрибуты формата ELF, используемого в ОС Linux для исполнимых бинарных файлов и разделяемых библиотек: разрядность, целевая аппаратная архитектура и типы секций, присутствующих в файле;

• бинарные символы — элементы файлов формата ELF, соответствующие функциям и глобальным переменным,

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

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

Диаграмма «сущность-связь» для элементов модели интерфейсов приложений с ОС Linux, задействованных в процессе запуска бинарных приложений, представлена на Рис.1.

Рис. 1. Модель интерфейсов бинарных приложений с ОС Linux, задействованных в процессе запуска программы.

В последующем изложении используются следующие обозначения:

• FiIeUsedELF(f) — атрибуты формата ELF, используемые в файле/;

• SysSupportedELF(Distr) и SysRequiredELF(Distr) — атрибуты формата ELF, поддерживаемые загрузчиком системы Distr, и

секции ELF, наличие которых обязательно для успешной обработки файла этим загрузчиком;

• FileReqLibs(f) и FileLoadedLibstf, Distr) — библиотеки, перечисленные в зависимостях файла /, и библиотеки, подгружаемые при загрузке файла / в системе Distr; для этих множеств справедливо

V/, Distr FUr.UeqLibs(f ) С FUcLoadedLibs(f, Distr)-,

• SysProvLibs(Distr)— библиотеки, предоставляемые дистрибутивом;

• FileReqSyms(f) и Fi!eReqVers(f) — внешние бинарные символы и их версии, импортируемые файлом/,

• SysProvSyms(f, Distr) и SysProvVersff, Distr) — бинарные символы и их версии, экспортируемые библиотеками FileLoadedLibs(f, Distr);

• AppReqLibs(App) — библиотеки, требуемые файлами приложения, и не предоставляемые самим приложением.

В терминах введенных определений формулируется и доказывается теорема о необходимых условиях успешного запуска бинарного приложения Арр в дистрибутиве Linux Distr. Доказывается необходимость выполнения следующих условий:

V/ £ Арр FileUsedELF(f) С SysSitpportedELF{Distr) (1):

V/ € Арр -> Sysllequ i г с dEL F (Distr) С FUeUsedELF(f) (2);

App[lf>qLibs{App) С SysProvLibs(Dislr) (3): V/ 6 App-i FilcRcqVersif) С SysProvVers(ft Distr) (4).

Если для файлов приложения не используется режим «ленивого» связывания, то необходимым также является требование:

V/ € Арр-* FücRcqSyms(f) С SysProvSyms(f,Distr) (5).

Также доказывается, что объединение условий (1), (2), (3) и (5) является достаточным условием успешного запуска.

Для бинарных приложений, написанных на объектно-ориентированных языках программирования, дополнительно выделены следующие виды интерфейсов с ОС:

• классы (вместе с полной иерархией предков и потомков);

• символы информации о типе (atypeinfo symbols»), используемые для динамической идентификации типа данных (Run-Time Туре Information, или Run-Time Type Identification, RTTI);

• защитные переменные («guard variables»), используемые для гарантии того, что статические переменные в ходе работы программы инициализируются только один раз;

• виртуальные таблицы классов;

• тшош-переходники («thunks») — обертки для вызова функций, осуществляющие необходимые преобразования аргументов;

• информация о базовых классах — иерархия классов, а также данные о классах, содержащих реализации виртуальных функций.

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

• характеристики программы-интерпретатора — имя, версия и местоположение в системе;

• модули, предоставляемые окружением интерпретатора;

• функции и переменные, экспортируемые модулями, которые могут использоваться в приложениях.

Диаграмма «сущность-связь» для элементов модели интерфейсов интерпретируемых приложений с ОС Linux представлена на Рис.2.

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

Рис. 2. Модель интерфейсов интерпретируемых приложений с ОС Linux.

Достаточным условием успешного запуска интерпретируемого приложения Арр в дистрибутиве Distr является удовлетворение следующих требований:

1. наличие в дистрибутиве интерпретатора с требуемыми приложением именем, версией и расположением в файловой системе;

2. предоставление окружением интерпретатора всех необходимых приложению модулей, классов, функций и переменных.

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

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

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

Ядром информационно-аналитической системы является база данных, состоящая из двух основных частей:

• спецификационная часть, содержащая информацию об интерфейсах, входящих в стандарт;

• сведения об интерфейсах, существующих в экосистеме Linux.

Спецификационная часть используется для решения следующих задач:

• обеспечение согласованности текста стандарта и компонентов окружения стандарта;

• поддержка формирования профилей стандарта;

• хранение информации об истории развитш стандарта.

Для обеспечения взаимной согласованности текста стандарта и компонентов его окружения, все характеристики стандартизованных интерфейсов хранятся в базе данных и извлекаются оттуда при необходимости использования. Необходимые данные могут быть встроены в код компонента непосредственно при его сборке, либо могут извлекаться из базы в ходе работы. Схема использования базы данных отражена на Рис. 3.

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

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

Рис. 3. Использование единой базы данных для разработки стандарта и компонентов его окружения.

Для хранения информации об истории развития стандарта, в схему базы вносятся дополнительные темпоральные свойства. Используемый подход основывается на временной реляционной модели данных (Temporal Relational Model, TRM), являющейся расширением реляционной модели, что позволяет использовать для управления базой данных реляционные СУБД.

Для отслеживания изменений свойств некоторого объекта вводится понятие временного интервала — отрезка времени [Ts.. TJ, на протяжении которого имеют силу определенные свойства объекта. Множество Std_Versions возможных значений границ отрезка есть объединение множества версий стандарта и специального значения NULL'.

Std_Versions = {Версия1, Версия2, ... ВерсияN, NULL}

Ts € Std.Versions; ТЕ € Std-Versioria

Для всех значений, кроме NULL, существует естественный порядок, согласно времени появления соответствующих версий стандарта. Будем считать, что версия Ti следует за версией Тг, если между этими версиями не появлялось других версий стандарта. Для однозначности потребуем, чтобы

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

На множестве значений Std Versions, отличных от NULL, вводятся операции сравнения — больше (>) и меньше (<)•.

Wi,Va € Std.Versions \ {NULL} - Vi < V2 <=> <=> версия Vi появилась раньше версии V2.

Wi.Vj € StiLVersions \ {NULL} - \\ > V2 <=> <=> версия Vj появилась позднее версии У2.

Введенные таким образом операции являются транзитивными.

Для любого периода жизни [Ts.. Те], условимся считать, что Ts < Те, если Ts и Те отличны от NULL. Если Ts равно NULL, то Те также должно иметь значение NULL. Те может принимать значение NULL при любом значении Ts.

Временные интервалы, задающие период жизни, вводятся для каждой сущности и для каждой связи между сущностями. Значения Ts и Те для экземпляра сущности представляют собой версии стандарта, в которых он был добавлен и удален соответственно. Если экземпляр не исключался из стандарта, то для него Те равно NULL. Повторное включение некоторого объекта в стандарт рассматривается как добавление нового объекта со своим периодом жизни.

В работе показано, что если реляционная модель объектов стандарта расширяется до временной модели посредством добавления временных интервалов предложенным способом с соблюдением сформулированных ограничений и отношения реляционной модели объектов стандарта находятся в нормальной форме Бойса-Кодда, то отношения полученной темпоральной модели находятся во временной нормальной форме (Time Normal Form, TNF).

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

1. Проведение анализа экосистемы Linux, включая:

a. выделение популярных приложений, анализ их требований к интерфейсам ОС;

b. сбор информации об интерфейсах, предоставляемых основными дистрибутивами.

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

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

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

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

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

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

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

• средства сбора и первичной обработки данных об интерфейсах, существующих и используемых в экосистеме Linux;

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

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

Сбор данных осуществляется для следующих видов интерфейсов:

• интерфейсов бинарных приложений (библиотеки, бинарные символы, типы секций ELF-файлов);

• интерфейсов приложений, написанных на языках Perl и Python (модули интерпретируемых языков);

• интерфейсов приложений, разработанных на языке Java (классы, их поля, методы и информация об иерархии).

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

• списка интерфейсов заданного вида, включенных в определенную версию стандарта;

• статистических данных по использованию конкретного интерфейса в приложениях и его наличию в дистрибутивах;

• сведений об интерфейсах, используемых конкретным приложением;

• информации об интерфейсах, предоставляемых конкретным дистрибутивом.

Шаблоны сопровождаются инструментарием автоматизированной генерации тестов для приложений, созданных на их основе.

В разделе 4.3 представлены результаты практического применения предлагаемого в данной работе метода и инструментария в совместных проектах ИСП РАН и консорциума The Linux Foundation по построению и развитию инфраструктур стандарта Linux Standard Base (начало проекта — 2006г.) и спецификации Moblin Compliance Specification (начало проекта — 2009г.).

Основные виды интерфейсов, входящие в последние (по состоянию на ноябрь 2009г.) версии спецификаций LSB и Moblin, и их количество приведены в Таблице 1. Сведения обо всех стандартизированных объектах и их свойствах хранится в спецификациотой части баз данных соответствующих информационно-аналитических систем.

Таблица 1. Основные интерфейсы, входящие в LSB 4.0 и Moblin 2.1

Объекты стандартизации LSB 4.0 Moblin 2.1

Библиотеки 57 217

Бинарные символы: -38.000 -78.000

Классы. С++ 985 985

Команды и утилиты 158 158

Модули 1'erl и Python 323 325

Таблица 2. Характеристики данных об экосистеме Linux, содержащихся в базах данных LSB и Moblin.

Объекты хранения БД Moblin

Дистрибутивы : 102 3

Приложения 1219 73

Библиотеки ■ -7.200 -20.000

Бинарные символы -2.000.000 -5.700.000

Классы С++ -120.000 -310.000

Команды и утилиты -15.500 -24.000

Модули Perl и Python -31.000 -29.000

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

компьютерах, причем анализируется только библиотеки, список которых составлен членами рабочей группы LSB. В случае Moblin анализируются продукты, предназначенные для использования на мобильных устройствах, и проводится анализ всех библиотек каждого дистрибутива. Характеристики сведений об экосистеме Linux, хранящиеся в базах данных LSB и Moblin, приведены в таблице 2. Средства автоматизированного анализа данных предоставляются веб-системами LSB Navigator и Moblin Navigator.

Разработанная система поддержки принятия решений позволила существенно расширить охват продуктов, исследуемых в процессе отбора интерфейсов для включения в спецификации LSB и Moblin. Так, при создании LSB 3.0 рассматривались только интерфейсы в последних (на тот момент) версиях трех дистрибутивов (RHEL, SLES и Debian), а сведения о приложениях сводились к запросам, поступившим от разработчиков ПО. При создании же LSB 4.0 использовались данные о дистрибутивах 12 производителей (причем обо всех версиях, вышедших в течение четырех лет) и более чем о тысяче приложений. При разработке Moblin Compliance Specification учитываются все дистрибутивы и приложения, официально зарегистрированные в программе Intel Atom Developer Program.

Новая MAC позволила существенно ускорить темпы развития стандарта LSB — если за период с 2001 по 2005 годы (годы выпуска LSB 1.0 и LSB 3.0 соответственно) в стандарт было добавлено около 3.000 функций из 5 библиотек, то за период с 2006 по 2009 годы (выпуск LSB 4.0) было добавлено более 30.000 функций из 37 библиотек, при этом за второй период в стандарт были добавлены и качественно новые интерфейсные сущности, относящиеся к интерпретируемым языкам.

Наличие информации об истории развития стандарта позволяет использовать единую базу данных и набор инструментальных средств генерации тестов и текста спецификации как для разработки текущих версий спецификаций LSB и Moblin, так и для поддержки уже выпущенных (с целью исправления найденных ошибок и неточностей). Эта информация также используется веб-системами LSB Navigator и Moblin Navigator для отображения сведений, относящихся к произвольной версии спецификаций.

В заключении перечисляются основные результаты работы.

Основные результаты работы

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

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

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

4. На основе предложенных методов разработана информационно-аналитическая система поддержки разработки и использования стандартов на интерфейсы операционной системы Lima - Linux Standard Base (LSB) и расширенного профиля этого стандарта Moblin Compliance Specification. Информационно-аналитическая система размещена в открытом доступе и активно используется Linux-сообществом. По состоянию на лето 2010 года она поддерживала более 2-х миллионов бинарных символов стандарта LSB и около 6-ти миллионов бинарных символов Moblin Compliance Specification, что охватывает информацию о более чем 100 дистрибутивах Linux и о более чем тысяче приложений для ОС Linux.

Перечисленные в пп.1-3 результаты получены лично автором. Информационно-аналитическая система была разработана в рамках промышленных проектов сектора Операционных систем Института системного программирования РАН при непосредственном участии автора в качестве проектировщика и одного из основных разработчиков.

Работы автора по теме диссертации

1. Д. Силаков. Информационно-аналитическая система для разработки и использования базового стандарта операционной системы Linux (LSB). // Информационные технологии. 2010. №5. С. 53-58.

2. Д. Силаков. Linux: интерфейсные стандарты и профили. // Открытые системы. 2010. №1. С. 44-47.

3. V. Rubanov, D. Silakov. Certification Infrastructure for the Linux Standard Base (LSB).

// Proceedings of OpenCert 2008 (Milan, Italy). P. 79-88.

4. В. Рубанов, Д. Силаков. Центр верификации ОС Linux: вклад в развитие стандарта LSB и тестирование Linux-платформы.

// Тезисы докладов IV Конференции разработчиков свободных программ на Протве. Обнинск, 2007. С. 25-27.

5. D. Silakov. Tracking Specification Requirements Evolution: Database Approach.

// Proceedings of SYRCoSE 2007 (Moscow). Vol. 2, pp. 15-22.

6. Д. Силаков. Текущее состояние и перспективы развития инфраструктуры LSB.

// Труды ИСП РАН, том 13, часть 1. 2006. С. 31-45.

7. Д. Силаков, В. Рубанов. LSB Navigator - онлайн справочник для разработчиков Linux приложений.

// Тезисы докладов V Конференции разработчиков свободных программ на Протве. Обнинск, 2008. С. 36-39.

8. Д. Силаков. Создание единой системы документации для поддержки разработки приложений, удовлетворяющих стандарту LSB.

// Труды 51й Научной конференции МФТИ. Москва, 2008. Том 3, с. 122-124.

9. Д. Силаков. Использование базы данных для принятия решений в процессе стандартизации.

// Сборник докладов IX Международной научно-технической конференции "Кибернетика и высокие технологии XXI века". Воронеж, 2008. Том 1, с. 220-229.

10.D. Silakov. Linux Distributions and Applications Analysis During Linux Standard Base Development.

// Proceedings of SYRCoSE 2008 (St.Petersburg). Vol. 1, pp. 11-18.

11.Д. Силаков, А. Хорошилов. Проблема переносимости приложений -сорок лет спустя.

//Материалы конференции SEC(R)2008 (Москва). С. 318-331.

12.D. Silakov. Designing a Development Environment to Support Creation of Standard-Compliant Applications.

//Proceedings of SYRCoSE 2009 (Moscow). Pp. 7-16.

13.Д. Силаков, В. Рубанов. LSB SDK - инструментарий разработки переносимых Linux приложений.

// Тезисы докладов VI Конференции разработчиков свободных программ на Протве. Обнинск, 2009. С. 37-41.

14.P.Shved, D.Silakov. Binary Compatibility of Shared Libraries Implemented in С++ on GNU/Linux Systems.

// Proceedings of SYRCoSE 2009 (Moscow). Pp. 17-26.

15.E.Novikov, D.Silakov. The Automated Analysis of Header Files for Support of the Standardization Process.

// Proceedings of SYRCoSE 2009 (Moscow). Pp. 27-34.

Подписано в печать:

03.09.2010

Заказ № 4086 Тираж -100 экз. Печать трафаретная. Типография «11-й ФОРМАТ» ИНН 7726330900 115230, Москва, Варшавское ш., 36 (499) 788-78-56 www.autoreferat.ru

Введение.

Глава 1. Существующие методы повышения переносимости ПО.

1.1 Обеспечение переносимости приложений ОС Linux между различными дистрибутивами.

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

1.1.2 Использование стандартов для создания переносимых приложений.

1.2 Подходы к разработке интерфейсных стандартов.

1.2.1 Разработка стандартов на интерфейсы приложений с ОС.

1.2.2 Составление текста стандарта.

1.2.3 Разработка согласованного окружения стандарта.

1.2.4 Отслеживание изменений стандарта и его окружения.

1.2.5 Управление требованиями при разработке ПО.

1.3 Анализ существующих подходов и постановка задачи.

1.3.1 Оценка существующих решений.

1.3.2 Постановка задачи.

Глава 2. Модель системы интерфейсов приложений с ОС Linux.

2.1 Классификация приложений по способу взаимодействия с ОС.

2.2 Система интерфейсов бинарных приложений с ОС Linux.

2.2.1 Интерфейсы, общие для всех бинарных приложений.

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

2.2.3 Интерфейсы программ, реализованных на объектно-ориентированных языках.

2.2.4 Достаточное и необходимые условия успешного запуска бинарного приложения.

2.2.5 Ограничения модели интерфейсов бинарных приложений.

2.2.6 Автоматизация процессов анализа интерфейсов бинарных приложений.

2.3 Система интерфейсов интерпретируемых приложений с ОС Linux

2.3.1 Интерфейсы, общие для всех интерпретируемых приложений.

2.3.2 Языки со статической типизацией.

2.3.3 Языки с динамической типизацией.

2.3.4 Достаточное условие запуска интерпретируемого приложения.

2.3.5 Ограничения модели интерфейсов интерпретируемых приложений.

2.4 Использование модели.

Глава 3. Архитектура информационно-аналитической системы для поддержки процессов создания, развития и использования интерфейсных стандартов.

3.1 Общее описание архитектуры.

3.2 База данных ИАС.

3.3 Хранение информации об истории развития стандарта.

3.3.1 Период жизни объектов.

3.3.2 Периоды жизни экземпляров сущностей и связей между ними

3.3.3 Нормализация.

3.3.4 Изменение видов стандартизованных элементов.

3.4 Построение окружения стандарта.

3.4.1 ' Обеспечение согласованности окружения с текстом стандарта.

3.4.2 Поддержка нескольких версий стандарта в компонентах окружения.

3.5 Поддержка профилей стандарта.

3.5.1 Профиль как подмножество стандарта.

3.5.2 Возможные оптимизации ИАС.

3.5.3 Хранение истории развития профиля стандарта.

3.5.4 Профиль как объединение нескольких стандартов.

3.5.5 Использование единой информационной системы для разработки нескольких стандартов.

3.6 Сбор информации для заполнения базы данных.

3.7 Использование данных о существующих реализациях при принятии решений в процессе стандартизации.

3.8 Метод построения системы поддержки принятия решений в процессе стандартизации.

3.9 Выводы.

Глава 4. Инструментарий поддержки информационно-аналитической системы и его практические применения.

4.1 Инструментарий анализа интерфейсов приложений и дистрибутивов Linux

4.2 Средства поддержки создания веб-интерфейса для информационной системы.

4.3 Практические применения метода и инструментария.

4.4 Выводы.

По данным [1], в настоящее время существует более 500 дистрибутивов ОС Linux, основанных на ядре Linux, библиотеках и инструментарии GNU. Несмотря на близость этих систем, обеспечение переносимости некоторого приложения между ними во многих случаях требует серьезных трудозатрат — различные системы могут использовать различные версии базовых компонентов, а многие производители дистрибутивов вносят в эти компоненты модификации, отражающие специфику конкретной системы. Как результат, функциональность, предоставляемая одним и тем же компонентом в разных дистрибутивах, может существенно различаться.

Многие разработчики ПО не считают экономически целесообразной проверку приложений на совместимость с каждым дистрибутивом, и ограничиваются поддержкой наиболее популярных систем (как правило, от 2 до 10 [2]). По этой причине, несмотря на богатый выбор дистрибутивов, пользователи зачастую ограничены тем набором, который поддерживается необходимыми им программными продуктами.

Одним из основных подходов к обеспечению переносимости приложений между различными платформами является стандартизация — определение набора свойств, которыми должна обладать любая платформа, где может быть запущено приложение. Одним из важнейших типов свойств, определяемых стандартами в области разработки ПО, является интерфейс взаимодействия операционной системы с приложениями. Основным, хотя и не единственным видом такого взаимодействия, является программный интерфейс, включающий набор функций (как правило, сгруппированных в библиотеки), предоставляемых системой и доступных выполняемым в ней программам. Соответственно, основные усилия в области стандартизации интерфейса взаимодействия ОС с приложениями направлены на стандартизацию программного интерфейса [3], При этом специфицироваться может как интерфейс на уровне исходного кода (Application Programming Interface, API), так и на уровне исполпимых бинарных файлов (Application Binary Interface, ABI) — файлов, содержащих двоичное представление машинных инструкций для определённого процессора. Следование стандартам API позволяет осуществлять перенос приложений на новые платформы путем перекомпиляции из исходного кода. Целыо стандартизации ABI является возможность переноса непосредственно бинарных файлов приложения, без внесения в них каких-либо изменений. В качестве примеров соответствующих стандартов, активно использующихся в мире Linux, можно привести POSIX и LSB. Следование POSIX при разработке приложения позволяет осуществить сборку приложения из исходного кода в любой POSlX-совместимой среде [4]; следование LSB гарантирует успешный запуск и корректность функционирования приложения в любой системе, отвечающей требованиям LSB [5].

Качественная поддержка процедуры переноса приложений требует рассмотрения широкого спектра интерфейсных сущностей. Помимо непосредственно библиотечиых функций, необходимы описания заголовочных файлов, типов данных, вспомогательных констант и макроопределений. Часть этих сущностей отражает специфику конкретных языков программирования и их стандартизация требует исследования особенностей как самих языков, так и соответствующих систем трансляции. Используемые в Linux компиляторы GCC поддерживают целый ряд языков, для которых осуществляется сборка бинарных файлов в формате ELF; помимо этого, в приложениях Linux активно используются несколько десятков интерпретируемых языков.

Кроме значительного числа разнообразных видов интерфейсных сущностей, трудности возникают в связи с большим количеством сущностей каждого вида. Например, современные дистрибутивы Linux предоставляют до нескольких тысяч библиотек и сотен тысяч функций. Большинство приложений используют от нескольких десятков до нескольких тысяч функций. Количество приложений велико. Порталы freshmeat.net и sourccforge.net, например, содержат более десяти тысяч программ для ОС Linux. В процессе стандартизации важно оценить реальные потребности приложений и возможности существующих систем, чтобы включать в стандарт наиболее востребованные интерфейсы. Подобный подход используется при разработке POSIX, LSB и ряде основанных на них спецификаций (например, Moblin Compliance Specification). По причине большого количества интерфейсов во множестве программных средств на основе ОС Linux (далее для краткости — экосистеме Linux), необходимы средства автоматизации подобного анализа.

Кроме упомянутой автоматизации, нецелесообразно разрабатывать стандарты «с нуля». А именно, необходимо опираться на уже существующие спецификации. Документация различного характера доступна для многих библиотек и функций Linux, однако она сильно разрознена и при разработке стандарта необходимы средства для ее консолидации и унификации. Важным аспектом является формирование профилей — объединений стандартов либо их подмножеств, охватывающих определенный класс систем [6]. При выделении подмножеств стандартов, равно как и при их объединении, встает задача обеспечения непротиворечивости и согласованности получаемого профиля. При больших объемах данных, решение этой задачи также требует автоматизации [7].

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

1. Исследовать многообразие видов интерфейсов приложений с ОС Linux и построить логическую модель системы интерфейсов.

2. Разработать архитектуру информационно-аналитической системы, предназначенной для поддержки процессов создания, развития и использования стандартов на интерфейсы ОС Linux, обеспечивающую: a. возможность адаптации информационной системы к изменениям модели системы интерфейсов; b. масштабируемость информационной системы, необходимую для хранения и обработки данных о постоянно увеличивающемся количестве приложений и дистрибутивов ОС Linux.

3. Разработать информационно-аналитическую систему, обеспечивающую: a. поддержку создания и сопровождения среды разработки приложений, отвечающих требованиям стандарта; b. поддержку принятия решений в процессе стандартизации на основе анализа существующих реализаций; c. возможность создания профилей стандартов.

4. Провести апробацию предложенного подхода на современных интерфейсных стандартах операционных систем.

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

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

Разработанные методы были успешно использованы при построении информационно-аналитической системы стандарта Linux Standard Base (LSB) в рамках совместного проекта ИСП РАН и консорциума Linux Foundation по развитию инфраструктуры LSB, стартовавшего в 2006 г. В 2009 г., также совместно с Linux Foundation, была построена информационно-аналитическая система для профиля стандарта мобильных устройств на базе платформы Moblin (Moblin Compliance Specification).

Результаты работы докладывались на семинаре Института проблем информационной безопасности в 2010 году, на 51 й Научной конференции МФТИ в 2008 году, на IX Международной научно-технической конференции "Кибернетика и высокие технологии XXI века" (Воронеж) в 2008 году, на семинарах ИСП РАН в 2009-2010 гг., на конференциях SYRCoSE в 2007-2009 гг., на IV, V и VI конференциях разработчиков свободных программ на Протве (Обнинск) в 2007-2009 гг, на конференции OpenCert (Милан, Италия) в 2008 году.

По теме диссертации опубликовано 15 работ [82]-[96], раскрывающих все основные результаты диссертации.

Диссертация состоит из введения, четырех глав, заключения, списка литературы и одного приложения. Список литературы включает 96 наименований. Основной текст диссертации (без приложений и списка литературы) занимает 135 страниц.

4.4 Выводы

В данной главе представлены результаты применения предлагаемых в работе методов и инструментальных средств, разработанных для их поддержки.

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

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

Разработанные методы и инструментальные средства успешно применяются в совместном проекте ИСП РАН и The Linux Foundation по развитию инфраструктуры стандарта Linux Standard Base (LSB), стартовавшем в 2006 году, а также в проекте по построению инфраструктуры для разработки и использования спецификации мобильных платформ Moblin Compliance Specification, осуществляемым ИСП РАН совместно с Linux Foundation с 2009 года.

Заключение

В диссертации получены следующие результаты:

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

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

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

4. На основе предложенных методов разработана информационно-аналитическая система поддерэюки разработки и использования стандартов на интерфейсы операционной системы Linux - Linux Standard Base (LSB) и расширенного профиля этого стандарта Moblin Compliance Specification. Информационно-аналитическая система размещена в открытом доступе и активно используется Linux-сообществом. По состоянию на лето 2010 года она поддерживала более 2-х миллионов бинарных символов стандарта LSB и около 6-ти миллионов бинарных символов Moblin Compliance Specification, что охватывает информацию о более чем 100 дистрибутивах Linux и о более чем тысяче приложений для ОС Linux.

Перечисленные в nri.l-З результаты получены лично автором. Информационно-аналитическая система была разработана в рамках промышленных проектов сектора Операционных систем Института системного программирования РАН при непосредственном участии автора в качестве проектировщика и одного из основных разработчиков.

1. The LWN.net Linux Distribution List. HTML. (http://lwn.net/DistributionsA).

2. Jem Matzan. The Differences between GNU/Linux Distributions.

3. The Jem Report, January 2006. HTML. (http://www.theiemreport.eom/content/vicw/215/74/).

4. А. Гриневич, Д. Марковцев, В. Рубанов. Проблемы совместимости Linux-систем. // Открытые системы. 2007. №1. С. 10-15.

5. IEEE POSIX Certification Authority. HTML. ('http://standards.icee.org/regauth/posix/).

6. Linux Standard Base. HTML. (http://www.linuxbase.org,).

7. С. Кузнецов. Открытые системы, процессы стандартизации и профили стандартов. // CITForum HTML. nittp://www.citforum.ru/database/articles/art 19.shtml).

8. В. Липаев, Е. Филинов. Формирование и применение профилей открытых информационных систем.

9. Информационные технологии. 1997. №4. С.2-11.

10. DistroWatch database summary.

11. Distro Watch Weekly, Issue 299, 20 April 2009. HTML. nittp://distrowatch.com/weekly.php?issue=20090420).

12. Сэм Варгес. Почему люди не переходят на GNU/Linux? Из-за приложений! // «Linux по-русски», 2009. HTML. (http://rus-linux.nct/lib.php?name=/MyLDP/freesoft/apps.html).

13. O.Mats Wichmann. Increasing the Appeal of Open Source Projects.

14. Proc. of the Linux Symposium, Ottawa, Canada. 2004. Vol.2, pp. 547-556.11 .E. Raymond. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary.

15. O'Reilly Media, Inc.; Revised & Expanded edition, 2001.

16. А. Федорчук. Дистрибутивы Linux сегодня: определение и классификация. // CitKit.ru, ноябрь 2009. HTML.

17. Thttp ://citkit.m/articles/1549Л.

18. Проект Gentoo Quality Assurance. HTML. fhttp: //www. gentoo.org/proi/en/q a/).

19. Diego Petteno, Serkan Kaba. Automagic dependencies, what they are and how to fix them. // Gentoo Quality Assurance materials. HTML. fhttp://www.gentoo.org/proi/en/qa/automagic.xml).15.«--as-needed» Introduction and Fixing Guide.

20. Gentoo Linux Documentation. HTML. (http://www.gentoo.org/proi/en/qa/asneeded.xml).

21. Building Packages in Arch Linux. HTML. (http://wiki.archlinux.org/index.php/Building Packages in Arch Linux).

22. GNU binutils. HTML. (http://www.gnu.org/software/binutilsA.lS.Milos .Takubicek. Comparison of binary package formats.

23. Materials of course PV208 — Advanced Topics of Linux Administration. Masaryk University. Czech Republic, Brno, 2008.

24. А. Турбин. Автоматический поиск зависимостей в rpm-пакетах.

25. Тезисы докладов IV Конференции разработчиков свободных программ на Протве. Обнинск, 2007. С. 59-63.

26. А. Турбин. Анализ бинарной совместимости репозитория rpm-пакетов. // Тезисы докладов III конференции разработчиков свободных программ на Протве. Обнинск, 2006. С. 60-62.

27. Single Unix Specification. HTML.http://www.unix.org/whatis unix/single unix specification.html).

28. Ian Murdock. LSB Overview and Progress Report. // LSB face-to-face (December 2006). Free Standards Group, 2006. PDF. (http.7/wvvw.linuxfoundation.org/images/c/c2/Lsb-f2f-200612-overview.pdf).

29. Carlo Zaniolo. Time Versus Standards: A Tale of Temporal Databases. // Proc. of ER Workshops 2008, LNCS 5232. Springer-Verlag Berlin Heidelberg, 2008. P. 67.

30. Jian-Cheng Dai, Gwo-Dong Chen, Chen-Chung Liu, Baw-Jiune Liu. A temporal behavioral object model for object-oriented databases.

31. Proc. of 21st International Computer Software and Applications Conference (COMPSAC '97). Washington, DC August 11-August 15, 1997.

32. Fusheng Wang, Carlo Zaniolo, Xin Zhou, Hyun J. Moon. Managing Multiversion Documents & Historical Databases: a Unified Solution Based on XML.

33. Proc. of Eighth International Workshop on the Web and Databases (WebDB 2005), June 16-17, 2005, Baltimore, Maryland. P. 151-153.

34. Б.Б. Костенко, С.Д. Кузнецов. История и актуальные проблемы темпоральных баз данных.

35. Сборник трудов ИСП PAFI, том. 13, ч.2, 2007, С. 77-114.

36. Rational Software — IBM Rational RequisitePro. // IBM Corporation. HTML.http://www-01 .ibm.com/software/awdtools/reqpro/).

37. M. Tim Jones. Anatomy of Linux dynamic libraries. // IBM developerWorks, 2008. HTML.http.V/www.ibm.com/developerworks/linux/librai'y/l-dynamic-libraries/).

38. P. С. Зыбин, В. В. Кулямин, А. В. Пономаренко, В. В. Рубанов, Е. С. Чернов. Автоматизация массового создания тестов работоспособности. // Программирование, №34 (6). 2008. С. 64-80.

39. Ян Джойнер. Критика Си++. Виртуальные функции.

40. Мир ПК, №8, 2001. HTML. (http://www.osp.ru/pcworld/2001/08/162109/У

41. Policies/Binary Compatibility Issues With С++. // KDE TechBase, 2009. HTML.http://techbase.kde.org/Policies/Binary Compatibility Issues With С++).

42. Notes on Multiple Inheritance in GCC С++ Compiler v4.0.1.

43. Programming Language Seminar Materials. Washington University in St.Louis, 2005.

44. GCC Extensions to the С++ Language — Where's the Template? // GCC 4.4.0 Manual, Section 6.5. Free Software Foundation, Inc., 2009. HTML.http://gcc.gnu.Org/onlinedocs/gcc4.4.0/gcc/Template-Instantiation.htmn.

45. Reji Thomas and Bhasker Reddy. Dynamic Linking in Linux and Windows. // Security Focus, August, 2006. HTML. (http://www.securityfocus.com/infocus/1872).

46. System V Application Binary Interface. December, 2003.

47. ELF-64 Object File Format. Version 1.5. May, 1998.

48. Brian Proffitt. More Compatibility Issues Easily Managed With LSB.

49. И Linux development Network, 2008. HTML.https://ldn.linuxfoundation.org/article/more-compatibility-issues-easilv-managed-with-lsb-tools),

50. Ulrich Drepper. ELF Symbol Versioning. // RedHat. inc. 2003. HTML. (http://people.redhat.com/drepper/symbol-versioning).

51. Ulrich Drepper. How To Write Shared Libraries. // RedHat. Inc. 2003. PDF. (http://people.redhat.com/drepper/dsohowto.pdf).

52. Coding practices for compatibility.

53. Hewlett-Packard Developer & Solution Partner Program, 1999. PDF. (http://svsdoc.doors.ch/HP/compat.pdf).

54. S. B. Navathe, R. Ahmed. Temporal Extensions to the Relational Model and SQL. // In Tansel et al., Temporal Databases. 1993. P. 92-109.

55. Linux Standard Base Team. Building Applications with the Linux Standard Base. Chapter 13. Using the LSB Development Environment.1. IBM Press, 2004. HTML.http://www.linuxfoundation.org/en/Book/HowToDeven.

56. Mark Murphy. The Busy Coder's Guide to Android Development. Chapter 37. Development Tools. // CommonsWare, July 2008. HTML. (http://commonsware.com/Android/?p=developerlife).

57. The Moblin Software Development Kit. HTML. (http://moblin.org/documentation/moblin-sdk).

58. The Open Group — Bookstore and Downloads. HTML. (http://www.opengroup.org/bookstore/catalog/).

59. TET-based LSB Test Suites. HTML. (http://www.linuxbase.org/test/build test suites.html).

60. Modulefinder — Find modules used by a script. // Python 2.6 documentation. HTML. (http://docs.pYthon.org/library/modulefinder.html4).

61. The Byte Code Engineering Library. // The Apache Jakarta Project. HTML. (http://iakarta.apache.org/bcel/).

62. Brief overview of the Dalvik virtual machine and its insights. // Dalvik Virtual Machine project. HTML. (http://www.dalvikvm.com/).

63. Linux Standard Base Core Specification 4.0. Executable and Linking Format. HTML.http://refspecs.linux-foundation.org/LSB 4.0.0/LSB-Core-generic/LSB-Core-generic.html#ELF-GENERIC).

64. Jerry Cashin. Bloom Fading From Posix Rose As Open Focus Shifts. // Software Magazine, Volume 14, N3, March 1994. HTML. (http://findarticles.eom/p/articles/mim0SMG/isn3vl4/ai 1506143 5Л.

65. Project Proposal and Call for Participation: The Linux Standard Base (LSB) Project. // Linux Weekly News, 28, May, 1998. HTML.htt p: //о 1 d. 1 wn. net/1998/0528/a/l sb. htm 1).

66. Закон РФ от 27.12.95 №211 — Федеральный Закон «О ста! 1 д артизации».

67. ISO Standards Development— Processes and Procedures. HTML.http://www.iso.org/iso/standards development/processes and procedures.il to).

68. LSB Specification Database. HTML.http://wwvv.linuxfoundation.org/en/SpecDatabaseUsage). 61 .Adding New Interfaces to the LSB Specification. HTML. (http://www.linuxfoundation.org/en/Book/NewABI).

69. Using LSB Resources. HTML. (http://www.linuxfoundation.org/en/Book/UseLSB).

70. Janel Garvin. Source Code Management Systems: Trends, Analysis and Best Features. // CIO, June, 2007. HTML.http://www.cio.com/article/120802/).

71. X/Open Alpha and Beta Test Activity Procedures. Issue 3.0. // X/Open Company Limited, 1994.

72. RPM Guide. PDF. (http:/^m5.org/docs/rpm-guide.pdf).

73. ISO/IEC directives and ISO supplement. HTML. (http ://www, i so. or g/directi ves).

74. А. Федорчук. Форматы пакетов. // FOSSBook, 2009. HTML. (http://fossbook.info/packages/313).

75. ГОСТ P 1.2-92 — Государственная система стандартизации Российской Федерации. Порядок разработки государственных стандартов.

76. Hewlett-Packard Company, IBM Corp., The Santa Cruz Operation, SunSoft, Inc., Univel, UNIX System Laboratories, Inc. UNIX Leaders Announce Common Open Software Environment.

77. Pressrelease, March, 17, 1993.

78. Д.Силаков. Автоматизация тестирования web-приложений, основанных па скриптовых языках.

79. Сборник трудов ИСП РАН, том 14, ч.2. 2008. С. 159-178.

80. Andrew Josey. API Standards for Open Systems. // The Open Group. TXT. ('http://www.opengroup.org/austin/papers/wp-apis.txO.

81. Gentoo Ebuild Policy. // Gentoo Handbook, 2009. HTML. (http://www.gentoo.org/proi/en/devrel/handbook/handbook.xml?part=3&cha ezi).

82. Basics of the Debian package management system. // The Debian GNU/Linux FAQ, 2009. HTML. Qittp://www.debian.org/doc/FAQ/ch-pkg basics.en.html).

83. Fedora Packaging: Naming Guidelines.

84. Fedora Project Documentation. HTML.http://fedoraproiect.Org/w/index.php7title-Packaging/NamingGuidelines) 75.0penSUSE Packaging Guide. HTML. (http://en.opensuse.org/Packaging)

85. Тим Джоуис. Системы управления версиями для Linux — Обзор архитектуры, моделей и примеров.

86. IBM developerWorks Россия, октябрь 2006. HTML.http://www.ibm.com/developerworks/ru/library/l-vercon/)

87. А. Хорошилов. Linux Standard Base: история успеха? // Сборник трудов ИСП РАН, том 10, 2006. С. 29-50.

88. Stuart Anderson, Matt Elder. Runtime Testing of LSB Applications.

89. Proc. of the Linux Symposium, Ottawa, Canada. 2004. Vol.1, pp. 41-50. 80.Carrier Grade Linux 4.0. HTML.http://www.linuxfoundation.org/collaborate/workgroups/cgl).

90. Paul Browning, Mike Lowndes. JISC TechWatch Report: Content Management Systems. // JISC, September 2001. PDF. (http://www.iisc.ac.uk/media/doeuments/techwatch/tsw 01 -02.pdf).

91. Д. Силаков. Информационно-аналитическая система для разработки и использования базового стандарта операционной системы Linux (LSB). // Информационные технологии. 2010. №5. С. 53-58.

92. Д. Силаков. Linux: интерфейсные стандарты и профили. // Открытые системы. 2010. №1. С. 44-47.

93. V. Rubanov, D. Silakov. Certification Infrastructure for the Linux Standard Base (LSB).

94. Proceedings of the Second International Workshop on Foundations and Techniques for Open Source Software Certification (OpenCert). Milan, Italy, 2008. P. 79-88.

95. В. Рубанов, Д. Силаков. Центр верификации ОС Linux: вклад в развитие стандарта LSB и тестирование Linux-платформы.

96. Тезисы докладов IV Конференции разработчиков свободных программ на Протве. Обнинск, 2007. С. 25-27.

97. D. Silakov. Tracking Specification Requirements Evolution: Database Approach.

98. Proceedings of SYRCoSE 2007. Moscow. Vol. 2, pp. 15-22.

99. Д. Силаков, В. Рубанов. LSB Navigator — онлайн справочник для разработчиков Linux приложений.

100. Тезисы докладов V Конференции разработчиков свободных программ на Протве. Обнинск, 2008. С. 36-39.

101. Д. Силаков. Текущее состояние и перспективы развития инфраструктуры LSB.

102. Сборник трудов ИСП РАН, том 13, часть 1. 2006. С. 31-45.

103. Д. Силаков. Создание единой системы документации для поддержки разработки приложений, удовлетворяющих стандарту LSB.

104. Труды 51й Научной конференции МФТИ. Москва, 2008. Том 3, с. 122-124.

105. Д. Силаков. Использование базы данных для принятия решений в процессе стандартизации.

106. Сборник докладов IX Международной научно-технической конференции "Кибернетика и высокие технологии XXI века". Воронеж, 2008. Том 1, с. 220-229.

107. D. Silakov. Linux Distributions and Applications Analysis During Linux Standard Base Development.

108. Proceedings of SYRCoSE 2008. St.Petersburg. Vol. 1, pp. 11-18.

109. Д. Силаков, А. Хорошилов. Проблема переносимости приложений -сорок лет спустя.

110. Материалы конференции SEC(R) 2008. Москва. С. 318-331.

111. D. Silakov. Designing a Development Environment to Support Creation of Standard-Compliant Applications.

112. Proceedings of SYRCoSE 2009. Moscow. Pp. 7-16.

113. Д. Силаков, В. Рубанов. LSB SDK инструментарий разработки переносимых Linux приложений.

114. Тезисы докладов VI Конференции разработчиков свободных программ на Протве. Обнинск, 2009. С. 37-41.

115. P.Shved, D.Silakov. Binary Compatibility of Shared Libraries Implemented in С++ on GNU/Linux Systems.

116. Proceedings of SYRCoSE 2009. Moscow. Pp. 17-26.

117. E.Novikov, D.Silakov. The Automated Analysis of Header Files for Support of the Standardization Process.

118. Proceedings of SYRCoSE 2009. Moscow. Pp. 27-34.