CC BY
217
УДК 004.4
И. В. Кузьмина, В. Р. Фидельман
РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СЛОЖНЫХ АППАРАТНО-ПРОГРАММНЫХ КОМПЛЕКСОВ С ИСПОЛЬЗОВАНИЕМ ПРИНЦИПОВ НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ
Аннотация. Представлена поэтапная эволюция процесса интеграции программного обеспечения. Обозначены проблемы, связанные с различными факторами: кросс-платформенность разрабатываемых систем, тесная взаимосвязь программных компонентов, ограничение временных и человеческих ресурсов; предложены варианты их решения.
Ключевые слова: аппаратно-программный комплекс, процесс разработки программного обеспечения, непрерывная интеграция.
Abstract. The article describes stage-by-stage evolution of integration process. The authors suggest a set of measures intended to solve revealed problems: crossplatform development, component interdependency, lack of human and time resources.
Key words: hardware-software system, software development process, continuous integration.
Введение
Современные аппаратно-программные комплексы (АПК) содержат компоненты как на базе операционных систем общего назначения, так и встраиваемых операционных систем. Такие системы обычно относят к классу гетерогенных АПК. Их успешное функционирование зависит от многих факторов, одним из которых является корректность работы управляющего программного обеспечения (ПО), что в свою очередь определяется уровнем организации процессов, в частности процесса разработки ПО.
В настоящее время существует большое количество стандартов, регламентирующих все этапы жизненного цикла АПК, которые должны служить основой для создания надежных аппаратно-программных средств. При создании таких комплексов возникают проблемы, обусловленные как спецификой проектируемых систем, так и особенностями процесса их разработки. Создание программной и аппаратной частей комплекса ведется параллельно на всех этапах разработки - от эскизного проектирования до предварительных испытаний - и характеризуется необходимостью постоянного согласования зачастую противоречивых требований, предъявляемых к их функциональности.
Подобная ситуация характерна также и для программных компонентов, имеющих между собой сложную взаимосвязь интерфейсов. В этом случае изменение интерфейса одного из них может привести к сбою в работе всего комплекса. Описанные выше проблемы, а также тот факт, что этап отладки и верификации программной и аппаратной частей по отдельности невозможен, резко увеличивают время на разработку всего комплекса. Одним из подходов к сокращению временных затрат на каждый этап процесса разработки АПК и уменьшения количества сбоев при эксплуатации является выявление и устранение дефектов программного обеспечения до интеграции программной и аппаратной частей.
1. Основные принципы непрерывной интеграции
Для повышения качества разрабатываемых решений и повышения эффективности разработки программного обеспечения широкое применение на сегодня находят принципы непрерывной интеграции (НИ) [1]. Непрерывная интеграция представляет собой практику разработки ПО, заключающуюся в выполнении частых автоматизированных сборок проекта с целью своевременного выявления и решения интеграционных проблем. В частности, выделены следующие составные части НИ: непрерывная интеграция баз данных, непрерывное тестирование, непрерывная инспекция кода, непрерывное развертывание, непрерывная обратная связь. Применение такого подхода обусловлено желанием снизить риски и временные затраты при разработке программных продуктов. На сегодня существует большой выбор инструментальных средств, поддерживающих непрерывную интеграцию как автоматизированный процесс. К таким продуктам относятся Сгш8еСоп1хо1.№1, CruiseControl, Hudson, TeamCity и др. [2].
2. Внедрение непрерывной интеграции в процесс
разработки программного обеспечения
При создании программной части АПК для поддержания требуемого уровня разработки программного обеспечения в качестве примера может быть использована линейка продуктов IBM Rational: система версионного контроля ClearCase LT, система управления изменениями ClearQuest, система управления требованиями RequsitePro.
На рис. 1 представлена схема процесса разработки ПО.
Setup.exe Setup.exe
*.ехе, *.(111 *.ехе, *.(111
Рис. 1. Схема процесса разработки ПО
Анализ опыта реализации таких проектов позволяет обозначить ряд недостатков, сопровождающих основные процессы разработки ПО. Во-первых, отсутствие этапа интеграции программных компонентов при разработке. Интеграция осуществляется непосредственно при сборке готовых исполняемых файлов и библиотек, собранных каждым разработчиком локально в своем
конфигурационном пространстве, т.е. в индивидуально настроенной структуре каталогов и программном окружении, и помещенных в систему версион-ного контроля. При этом удовлетворение зависимостей обеспечивается путем установки ПО разрабатываемого комплекса более ранней (в лучшем случае последней) версии на ПЭВМ разработчика (рис. 1). Очевидно, что такой подход не обеспечивает своевременного выявления проблем интеграции программных компонентов.
Во-вторых, отсутствие согласования размещенных в системе версион-ного контроля исходных кодов и бинарных файлов. При таком подходе невозможно получить комплект ПО комплекса заданной версии, что является критичным фактором при необходимости возвращения к более ранней версии в случае выявления фатального дефекта.
В-третьих, высокий риск потери возможности разработки компонента в случае болезни или увольнения разработчика, необходимость дополнительных затрат на разработку компонента с нуля после передачи его другому специалисту.
Кроме того, при отладке комплекса после разворачивания на целевой системе, в качестве которой используются виртуальные или реальные вычислительные узлы с различными операционными системами в сборе с аппаратной частью комплекса, постоянно возникают проблемы взаимодействия с аппаратурой, обусловленные отсутствием отладочных версий программных компонентов.
Анализ временных затрат на разработку ПО согласно описанной схеме свидетельствует о необходимости изменения такого процесса разработки ПО и внедрения подхода непрерывной интеграции.
Для построения системы непрерывной интеграции предлагается выделить процесс интеграции программных компонентов и организовать сборочные серверы на всех поддерживаемых платформах (Windows и СепЮ8). Сборочный сервер выполняет задачу автоматизации всех этапов сборки: компиляция исходного кода, модульное тестирование, инспекция исходного кода, уведомление разработчиков о результатах сборки. Для платформы Windows ХР в качестве сервера сборки может быть выбран CruiseControl.Net. Специфика разрабатываемого ПО обусловливает следующие проблемы:
- невозможность проведения модульного тестирования на этапе сборки вследствие зависимости тестов от аппаратуры;
- тесная взаимосвязь программных компонентов и, как следствие, необходимость постоянного согласования интерфейсов.
Одним из принципов непрерывной интеграции является автоматический запуск тестов сразу после внесения изменений исходного кода в систему версионного контроля.
При разработке АПК вследствие тесной взаимосвязи аппаратной и программных частей невозможно тестирование программных компонентов комплекса в отсутствие целевой системы [3]. Решить эту проблему эффективным методом позволяет разделение модульного и функционального тестирования совместно с формализацией требований написания модульных тестов, не зависящих от аппаратуры. Выполнение последнего требования часто вызывает возражения со стороны разработчиков, считающих, что невозможно тестировать программу, предназначенную для работы с аппаратурой в ее отсутствие. Однако такое разделение необходимо, и модульные тесты в этом случае
должны быть направлены не на проверку работы программы с приборами, а на тестирование окружения, проверку наличия в целевой системе всех требуемых библиотек и конфигурационных файлов, тестирование алгоритмов.
Большое количество компонентов в составе сложных АПК и тесная взаимосвязь их интерфейсов приведет к тому, что запуск сборки всего комплекса после каждого изменения исходного кода задержит обратную связь с разработчиками, даже если сборка включает в себя только компиляцию исходных кодов и запуск простых модульных тестов. Для решения данной проблемы предлагается разделить процесс интеграции на этапы: интеграция компонентов, направленная на выявление конфликтов рассогласования интерфейсов, и непосредственно сборка очередной версии комплекта ПО комплекса. Выявление проблем взаимодействия интерфейсов зависимых компонентов осуществляется на сборочном сервере сразу после внесения изменений каждого из них в систему версионного контроля. При этом собираются только измененный компонент и все зависимые от него. Таким образом, к моменту сборки комплекса ошибки интеграции должны быть выявлены и исправлены. Такой подход позволит значительно сократить время на создание конечного комплекта ПО, обеспечит возможность своевременного выявления и устранения ошибок рассогласования зависимых интерфейсов, а также существенно повысит эффективность и производительность труда интегратора.
Возможность применения описанной схемы процесса интеграции при разработке ПО на Unix-подобных системах (Linux и QNX) ограничивается отсутствием клиента системы версионного контроля ClearCase LT для выбранных платформ. Наличие связи сервера автоматической сборки с системой версионного контроля является ключевым условием возможности организации процесса непрерывной сборки, независимо от выбранного инструмента (сервера автоматической сборки), поддерживающего этот процесс. Переход на другую систему нецелесообразен вследствие того, что продукты линейки Rational интегрированы между собой и активно используются при разработке для управления смежными процессами. Таким образом, задача автоматизации процесса интеграции при разработке ПО сводится к автоматизации всех этапов процесса интеграции на Unix-подобных операционных системах. Для решения этой проблемы в качестве примера можно предложить проведение интеграции компонентов и сборки дистрибутива комплекса согласно следующей схеме (рис. 2).
Необходимо выделить два (по числу используемых в проекте операционных систем) сервера сборки: «build-win» (MS Windows), «build-qnx» (QNX 6.3); на ПЭВМ «build-win» развернуть сервер CruiseControl.Net и клиент ClearCaseLT; между серверами настроить клиент-серверное соединение. Отсутствие связи с версионным хранилищем компенсируется созданием ресурса общего доступа на ПЭВМ «build-qnx», содержащего структуру каталогов, находящихся под контролем в системе ClearCase. Это позволяет использовать для сборки одни и те же файлы исходного кода на обоих серверах. Цикл интеграции начинается в тот момент, когда разработчик вносит изменения исходного кода компонента в репозиторий. Сервер «build-win» автоматически получает изменения из репозитория и последовательно запускает все этапы сборки этого и всех зависимых компонентов: компиляция, модульное тестирование, инспекция кода. Далее автоматически осуществляется запуск этих же этапов на сервере «build-qnx». Если были обнаружены проблемы,
разработчики всех зависимых компонентов получают по электронной почте отчеты. После исправления ошибок и внесения исходного кода в репозиторий начинается следующий цикл интеграции.
Setup.qpr; Setup.exe; label Рис. 2. Схема процесса интеграции после автоматизации
Таким образом, еще до возникновения необходимости создания дистрибутива комплекса процесс интеграции всех его компонентов выполнен.
Заключение
В данной работе рассмотрен процесс поэтапного внедрения методологии непрерывной интеграции, позволяющей существенно сократить временные затраты, необходимые на создание новой версии ПО АПК. Кроме того, описанная схема процесса интеграции является универсальной и может быть применена в проектах, независимо от операционной системы, на которой ведется разработка ПО. Вместе с тем следует отметить, что для успешного внедрения непрерывной интеграции необходимо, чтобы все процедуры процесса были хорошо документированы и донесены до сведения разработчиков до начала этапа разработки ПО.
Список литературы
1. Дюваль, П. М. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска / П. М. Дюваль. - М. : Вильямс, 2008. - 345 с.
2. CI Feature Matrix [Электронный ресурс]. - URL: http://confluence.public. thoughtworks.org/display/CC/Cl+Feature+.
3. Федоров, В. К. Контроль и испытания в проектировании и производстве радиоэлектронных средств / В. К. Федоров, Н. П. Сергеев, А. А. Кондрашин. - М. : Техносфера, 2005. - 504 с.
Кузьмина Ирина Валентиновна
младший научный сотрудник, отдел № 14, Научно-исследовательский физико-технический институт Нижегородского государственного университета им. Н. И. Лобачевского
E-mail: kiv@nifti.unn.ru
Фидельман Владимир Романович доктор технических наук, профессор, заведующий кафедрой информационных технологий в физических исследованиях, Нижегородский государственный университет им. Н. И. Лобачевского
E-mail: fidelman@nifti.unn.ru
Kuzmina Irina Valentinovna Junior researcher, department № 14, Research institute of applied physics of Nizhny Novgorod State University named after N. I. Lobachevsky
Fidelman Vladimir Romanovich Doctor of engineering sciences, professor, head of sub-department of information technologies in physical research,
Nizhny Novgorod State University named after N. I. Lobachevsky
УДК 004.4 Кузьмина, И. В.
Разработка программного обеспечения сложных аппаратно-программных комплексов с использованием принципов непрерывной интеграции / И. В. Кузьмина, В. Р. Фидельман // Известия высших учебных заведений. Поволжский регион. Технические науки. - 2012. - № 2 (22). - С. 44-49.
