Управление программным обеспечением

Исторически сложилось так, что разные компоненты современных UNIX-подобных ОС, разрабатывались и продолжают разрабатываться независимо и в разных местах. Наиболее ярко это проявляется в ОС на основе ядра Linux, где независимо разрабатываются все компоненты системы, начиная с ядра и системообразующих библиотек и заканчивая прикладными программами. Такой подход к созданию ОС стал возможен благодаря стандартизации ОС UNIX на всех уровнях (о чём говорилось в разделе «Развитие операционных систем в глобальных сетях»). Собственно, именно благодаря компонентной архитектуре UNIX стало возможным появление в 1990-х полнофункциональных серверных и настольных систем, состоящих исключительно из свободных программ, таких как Linux и FreeBSD: ни одному свободному проекту было не под силу создать полноценную систему, но оказалось возможным объединить усилия многих проектов, создав интегрированную систему на основе стандартов.

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

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

Управление программным обеспечением: роли и задачи

Основные роли в создании и использовании ПО

Презентация 8-01: основные роли при работе с ПО

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

• разработчик;

• системный администратор;

• пользователь.

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

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

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

Рисунок 3.14. Основные роли в процессе создания и использования ПО

Задачи системы управления программным обеспечением

Если вопрос использования и конфигурирования программного обеспечения сильно зависит от конкретной программы (как правило, доступна документация для пользователей системы), то общие задачи администрирования (установка программы, её обновление, удаление) — наоборот, стремятся к унификации для облегчения работы системного администратора.

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

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

Формы распространения программного обеспечения

В двоичной форме или в исходных текстах?

Презентация 8-02: распространение ПО в двоичной форме и в исходных текстах

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

Рисунок 3.15. Распространение ПО в двоичной форме

В настоящий момент распространение программ в бинарном виде характерно только для проприетарных версий UNIX: AIX, HP-UX, MacOS X, Solaris и др. Эти версии UNIX чаще всего поставляются для небольшого регламентированного списка аппаратных платформ.

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

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

Сборочные процедуры как средство управления ПО

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

Рисунок 3.16. Распространение ПО в форме исходных текстов

Make-файл определённого вида к настоящему времени является стандартом де-факто для большинства открытых проектов. С его помощью можно получить готовую к использованию программу из исходных текстов на компилируемом языке (как правило это C или C++). Обычно в make-файле определяются специальные цели для задач системного администрирования: install и uninstall, которые выполняют стандартные действия — соответственно установку и удаление скомпилированной программы из системы. При этом всё, что требуется от администратора для компиляции из исходных текстов и установки программы, это выполнить следующую последовательность команд: