Українська   English
ДонНТУ   Портал магистров

Содержание

Введение

На данный момент программная инженерия является самой востребованной и перспективной инженерной специальность. А задачи программной инженерии являются актуальными. Весь комплекс работ, объединённый терминов – программная инженерия, можно разбить на ряд потоков. Перечислим имеющиеся потоки программной инженерии [1]:

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

1. Место и роль задачи контролей версий в потоке работ программной инженерии

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

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

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

Совместная разработка программных продуктов определенного класса программ в рамках СКВ позволяет накапливать разные варианты рабочих программных решений. Главное достоинство современных СКВ – это возможность накопления и повторного использования экспертных знаний об апробированных программных решениях в форме, удобной для хранения, передачи и редактирования [11].

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

СКВ с расширенным функционалом позволяет создавать надстройки, которые и смогут выполнять интеллектуальный анализ и синтез программ, опираясь на накопленные программные решения.

2. Анализ функций и роли системы контроля версиями

Система управления версиями – это ПО для упрощения работы с документами, которые часто меняются. Система управления версиями может хранить разные версий одного и того же документа, и позволяет перемещаться по разным версиям проекта и даже к самым первым. Так же, при получении любой версии, можно посмотреть все изменения документа, и кто в какое время производил изменения. Данные системы часто применяются при разработке ПО для хранения и управления документов с исходным кодом. Но это не исключает ситуацию, что их можно использовать и в других сферах, в которые работа проходит в часто изменяющихся документах и нужно отслеживать все изменения с ними. Так же стоит отметить, что очень часто СУВ используются в САПР, которые используются в составе системе управления данным об изделии (PDM). Еще можно встретить СУВ при использовании конфигурационного управления [2]. Традиционные системы контролей версий имеет централизованную модель. Система имеет определенное хранилище и управление этой системы происходит на сервере. Порядок основных действий с системой контролей версий:

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

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

В различных системах управления встречаются такие возможности, как:

Существуют еще распределенный системы управления версиями. Их главное отличие в том, что они имеют распределенную модель, а не традиционную клиент-серверную. Они не нуждаются в наличии определенного хранилища: вся история изменения и все версии хранятся на машине, в локальном хранилище, и только при необходимости нужные части документов синхронизируются с подобным хранилищем на другом компьютере. Это дает преимущество перед централизованными в том, что каждый пользователь работает над своей локальной копией, а затем уже добавляет (производит push) на централизованное хранилище. Но перед данным этапом нужно загрузить актуальную копию на своей компьютер (произвести pull). Это делается с той целью, чтобы, если есть конфликты в двух версиях документа (того, который на другом компьютере и того, который на локальном компьютере), их разрешить. У распределенных есть ряд недостатков:

Преимущества распределенных систем управления версиями:

Системы контроля версий могут использоваться, так называемые дельта-компрессии – это такой подход, при котором записывается только изменения документа, а не всего версии. Простой пример может привести на цифрах, вместо записи 2, 4, 6, 7, 9, 5, 15, мы будем записывать 2, 2, 2, 1, 2, -4, 10 [3]. Так как в большинстве случаев нужно последняя версия, то на сервере записываем, заменяя предыдущую актуальную модель.

3. Обзор программный реализаций

В данном пункте будет рассмотрены и проанализированы следующий программные реализации: Система одновременных версий (CVS), Apache Subversion (SVN), Git, Mercurial.

CVS [4] впервые появилась в 1980–х, но несмотря на это является популярной и по сей день. CVS использует открытой лицензионное соглашение GNU. Основной функцией CVS является получать и отправлять на сервер определенную версию документа. Целью создания CVS являлось уметь разрешать конфликта между версиями при разработке. Также стоит отметить, что у каждого пользователя была возможность иметь только самую последнюю версию проекта. Это являлось первой системой контроля версиями. Недостатком было то, что пользователь обязан был успеть отправить новую версию своего документа на сервер, пока другие его не опередили. На данный момент этот недостаток разрешили возможностью работать с ветками проекта.

SVN [5] была создавалась альтернативой CVS. Целью создания базировалось на исправлении недостатков CVS, а также не забывать про обратную совместимость. SVN так же является бесплатной системой контроля версиями с открытым исходным кодом. SVN распространятся под лицензией Apache. Данная СУВ начала использовать атомарные операции, чтобы сохранить целостность БД. Что имеется ввиду, при создании новой версии к последней измененной версии проекта применяются либо все исправления, либо ни одно из них. Это создавала защиту кода от случайных и частичных правок, которые в некоторых случаях вызывают даже ошибки. Причиной того, что разработчики отдали предпочтение SVN и отказались от CVS в том, что SVN взял все лучшие от CVS и еще дали разработчикам больше возможностей. SVN создавалась в первую очередь для более крупных проектов, в которых использовалось ветвление кода и было не одно направление разработки.

Git [6] была создана для управления разработкой ядра Linux [7]. Данная система начала использовать категоричной другой подход от CVS и SVN. При создании Git было целью создать более быструю распределенную СУВ. Если взять во внимание, что Git создавался под Linux, то в этой ОС она работает лучше всего. Но также есть возможность пользоваться на MacOS и Windows. Также стоит заметить, что каждая версия содержит всю историю, что является весомым плюсом, если ведется разработка без интернет-соединения. Присутствует навигация по всей истории.

Mercurial [8] дебютировал в одно время с Git. Mercurial, как и Git, является распределенной системой контроля версиями. Mercurial являлся альтернативой при разработке модулей для ядра Linux. Mercurial используется меньше, но многие ведущие разработчики предпочли работать с этой СУВ, к ним можно отнести и OpenOffice.org [9]. Главное отличие данной системы от остальных является то, что она полностью написана на Python, а не на C. Но некоторые модули-расширения все равно были разработаны на C [10]. Была разработана таблица 1, в которой приведены все преимущества и недостатки каждого варианта.

4. Анализ системы контроля версий с расширенным функционалом

4.1 Назначения возможностей системы контроля версий – git

Рассмотрим систему расширенного функционала, которая является системой контроля версий git. Git – это распределённая система контроля версий. Основное отличие Git’а от любой другой системы контроля версий – это подход Git’а к работе со своими данными. Концептуально, большинство других систем хранят информацию в виде списка изменений в файлах. Эти системы представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени.

Хранение данных как набора изменений относительно первоначальной версии каждого из файлов

Рисунок 1 – Хранение данных как набора изменений относительно первоначальной версии каждого из файлов

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

Хранение данных как снимков проекта во времени

Рисунок 2 – Хранение данных как снимков проекта во времени

Это очень важное отличие между Git и почти любой другой СКВ. Git переосмысливает практически все аспекты контроля версий, которые были скопированы из предыдущего поколения большинством других систем [14].

4.2 Анализ особенностей архитектуры системы контроля версий – git

Нижний уровень git является так называемой контекстно-адресуемой файловой системой. Для каждого объекта в репозитории вычисляется SHA-1-хеш, и именно он становится именем файла, содержащего данный объект в каталоге .git/objects.

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

Кроме того, в репозитории существует каталог refs, который позволяет задать читаемые человеком имена для каких-либо объектов Git. В командах Git оба вида ссылок – читаемые человеком из refs, и нижележащие SHA-1 – полностью взаимозаменяемы.

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

Это снижает требования по ёмкости хранения.

Инструмент командной строки git содержит ряд команд по непосредственной манипуляции этим репозиторием на низком уровне.

Эти команды не нужны при нормальной работе с git как с системой контроля версий, но нужны для реализации сложных операций, а также дают возможность создать на базе репозитория git своё приложение [6].

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

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

Проанализировав основные методы и программные средства системы управления версиями. Было выявлено, что в потоки программной инженерии идет уклон на распараллеливание рабочих процессов, где очень важно, чтобы работа одного программиста не влияла на работу другого. Также к важным моментам нужно отнести недостаточную информативность при работе с разными версиями и ветками в СУВ. При получении новой более актуальной версии, иногда уходить много времени на анализ и понимание того, что было изменено именно в данной версии. Комментарий при загрузке на сервер (так называемый «комит») в большинстве случаев имеет ограниченный размер, и не все способны корректно отметить выполненное. В связи с этим способность выявлять исправления и предоставлять вместо измененных строк сформулированный анализ изменений является уместной в потоке программной инженерии. Составлены основные требования для решения проблем и реализации программного обеспечение:

6. Предлагаемый путь создания интеллектуальной надстройки

Надстройка (плагин) – независимо компилируемый программный модуль, динамически подключаемый к основной программе и предназначенный для расширения.

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

Создание целевого пространства систем (ЦПС), т.е. пространства возможных решений-прототипов. Имеется два пути:

Уровни квалификации пользователя при избранном подходе к созданию экспертной системы отличаются его возможностью построить ЦПС (множество возможных решенийпрототипов) и ПОС (множество ТЗ).

Возможны варианты, когда пользователь может построить:

Порядок создания и использования надстройки

Рисунок 3 – Порядок создания и использования надстройки

Заключение

Широкое применение СКВ открывают дальнейшие перспективы в их развитии, поиске новых решений и направлений их использования.

В данной работе проведён общий анализ возможностей и назначений СКВ, частный анализ систем контроля версий с расширенным функционалом, а также предложены пути создания интеллектуальной надстройки на базе СКВ такого класса.

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

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

Как перспективную работу следует определить создание комплекса конкретных методов и механизмов реализации избранного пути.

Список источников

  1. Анализ требований и другие рабочие потоки программной инженерии [Электронный ресурс] – Режим доступа: https://studfiles.net/preview/1644196/page:17/ – Загл. с экрана.
  2. Система управления версиями [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/....
  3. Дельта-кодирование [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BB%D1%8C%D1%82%D0%B0%D0%BA%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 – Загл. с экрана.
  4. CVS [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/CVS – Загл. с экрана.
  5. Subversion [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Subversion – Загл. с экрана.
  6. Git [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Git – Загл. с экрана.
  7. Linux [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Linux – Загл. с экрана.
  8. Mercurial [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Mercurial – Загл. с экрана.
  9. Apache OpenOffice – свободный и открытый офисный пакет [Электронный ресурс] – Режим доступа: https://www.openoffice.org/ru/ – Загл. с экрана.
  10. Система контроля версий (cvs) 2018 – Сравниваем: Git, SVN, Mercurial [Электронный ресурс] // Википедия – Режим доступа: https://biz30.timedoctor.com/ru/c%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8F%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9/ – Загл. с экрана.
  11. Григорьев А.В., Грищенко Д.А. – Интеллектуализация процесса проектирования аппаратуры средствами языка VHDL [Электронный ресурс] – Режим доступа: http://masters.donntu.ru/2007/fvti/tsatsenkina/library/stat_kosh.htm.
  12. Git – О системе контроля версий [Электронный ресурс] – Режим доступа: https://git-scm.com/book/ru/v2/Введение-О-системе-контроля-версий.
  13. Анализ состояний методов, алгоритмов и программных средств в поддержке управления версиями [Текст] / Григорьев А.В., Гурин А.Г // Программная инженерия: методы и технологии разработки информационно вычислительных систем (ПИИВС-2018): сб. статей. – Донецк, 2018. – С. 43-47.
  14. Git – Основы Git [Электронный ресурс] – Режим доступа: https://gitscm.com/book/ru/v2/Введение-Основы-Git.
  15. Григорьев А.В. – Пути создания интеллектуальных САПР при различных уровнях квалификации экспертов [Электронный ресурс] – Режим доступа: http://masters.donntu.ru/2010/fknt/shaydt/library/article4.htm.