Portage
Portage — основная система управления пакетами в Gentoo Linux. Аналог системы портов FreeBSD. Представляет собой набор утилит на Python и Bash, призванных облегчить и упорядочить установку программного обеспечения из исходных кодов или бинарных пакетов, с учётом всех зависимостей.
Основной пользовательский интерфейс Portage — консольная программа emerge, которая позволяет устанавливать новые пакеты с учётом зависимостей и с возможностью управления вариантами установки — например с поддержкой определенных функций или без поддержки ненужных функций (управление параметрами сборки осуществляется через так называемые USE-флаги), удалять ненужные пакеты, обновлять установленные пакеты, проводить синхронизацию с деревом портежей (по протоколу rsync) и т. д. Программа ebuild служит интерфейсом низкого уровня к Portage, а emerge — высокоуровневая оболочка для неё.
Проектирование системы управления пакетами
Для фазы проектирования были выбраны следующие технологии и инструментарии:
UML — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью.
Диаграмма связей — способ изображения процесса общего системного мышления с помощью схем
Microsoft Visio — векторный графический редактор, редактор диаграмм и блок-схем для Windows.
Выбор именно этих технологий и инструментариев был обусловлен тем, что они являются унифицированными и общепризнанными. Есть возможность найти большое количество материала описывающего best practices по их использованию.
Первым этапом проектирования пакетного менеджера стал сбор требований. После окончания этого этапа мы могли сказать что:
Мы будем разрабатывать программный продукт - программа, которую независимо от ее разработчиков можно использовать в предусмотренных целях на разных компьютерах, если только они удовлетворяют ее системным требованиям.
Основной функцией разрабатываемого ПО будет выкачка неких пакетов, заранее определенного формата, из общедоступного репозитория и обработка их на локальном компьютере – системы управления пакетами. Система управления пакетами — набор программного обеспечения, позволяющего управлять процессом установки, удаления, настройки и обновления различных компонентов программного обеспечения.
Разрабатываемый пакетный менеджер должен легко инсталлироваться и быть кроссплатформенным. Исходя из требований были частично определены solution компоненты будущей системы. После чего для структуризации знаний была построена диаграмма связей.
После этого мы перешли к стадии выделения основных сущностей и решения концептуальных вопросов касательно разрабатываемого продукта.
На этой стадии оформилась идея о «формулах» описывающих логику установки пакета и было принято решение о том, что лучшим форматом для этих формул будет JSON — текстовый формат обмена данными, основный на концепции ключ-значения и легко читаемый людьми.
Была разработана начальная архитектура пакетного менеджера и оформлена в виде диаграммы классов. В UML диаграмма классов является типом диаграммы статической структуры. Она описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов.
Как видно из диаграммы были выделены следующие сущности:
PackageManagerFacade – класс, предоставляющий унифицированный интерфейс клиенту
PackageService - основной контролер по обработке запросов
Formula – entity класс для маршализации передаваемых формул
Operation – атомарная операция совершаемая пакетным менеджером
Package – класс, хранящий информацию о пакете
ConnectionManager – интерфейс описывающий методы подключения к серверу
GitManager – реализация ConnectionManager для git-а
На следующем этапе нужно было разработать архитектуру высокого уровня по взаимодействию таких абстрактных компонентов системы как БД, клиент, сервер. Для этих целей были выбраны диаграмма последовательности и диаграмма компонентов. Диаграмма последовательности— диаграмма, использующаяся в языке UML, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.
Диаграмма компонентов — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Как видно из диаграмм, у нас получилось выделить три основных высокоуровневых компонента: база данных, клиент, сервер(git). И если с архитектурными особенностями двух последних работа была закончена (сервер не требовал проработки так как было решено использовать github — самый большой веб-сервис для хостинга проектов и их совместной разработки) то архитектура базы данных требовала уточнения. Для этих целей мы воспользовались моделью сущность-связь (ER-модель) — модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
Заключительным этапом проектирования стало построение диаграммы деятельности для основной операции install. Диаграмма деятельности — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого. Это позволило устранить потенциальные неоднозначности предыдущих диаграмм и в дальнейшем облегчило реализацию всех остальных методов.
