Русский   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 - Зберігання даних як набору змін щодо первісної версії кожного з файлів

Малюнок 1 - Зберігання даних як набору змін щодо первісної версії кожного з файлів

Git не зберігає і не обробляє дані таким способом. Замість цього, підхід Git'а до зберігання даних більше схожий на набір знімків файлової системи. Кожен раз, коли ви робите Комміт (збереження стану свого проекту в Git'е), система запам'ятовує, як виглядає кожен файл в цей момент і зберігає посилання на цей знімок. Для збільшення ефективності, якщо файли не були змінені, Git не запам'ятовує ці файли знову, а тільки створює посилання на попередню версію ідентичного файлу, який вже збережений. Git представляє свої дані як, скажімо, потік знімків.

Малюнок 2 - Зберігання даних як знімків проекту в часі

Малюнок 2 - Зберігання даних як знімків проекту в часі

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

4.2 Аналіз особливостей архітектури системи контролю версій - git

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

Для оптимізації роботи з файловими системами, які не використовують дерева для каталогів, перший байт хешу стає ім'ям підкаталогу, а решта - ім'ям файлу в ній, що знижує кількість файлів в одному каталозі.

Крім того, в репозиторії існує каталог refs, який дозволяє задати читаються людиною імена для будь-яких об'єктів Git. У командах Git обидва види посилань - читаються людиною з refs, і нижележащие SHA-1 - повністю взаємозамінні.

У репозиторії іноді проводиться прибирання сміття, під час якої застарілі файли замінюються на «дельти» між ними і актуальними файлами, де актуальна версія файлу зберігається неінкрементально, інкремент використовуються тільки для повернення до попередніх версій, після чого дані «дельти» складаються в один великий файл , до якого будується індекс.

Це знижує вимоги по ємності зберігання.

Інструмент командного рядка git містить ряд команд по безпосередньої маніпуляції цим репозиторієм на низькому рівні.

Ці команди не потрібні при нормальній роботі з git як з системою контролю версій, але потрібні для реалізації складних операцій, а також дають можливість створити на базі сховища git свій додаток [6].

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

5. Аналіз головних проблем і формування основних вимог/h2>

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

  • можливість запам'ятовувати попередні версії проекту і кожного документа;
  • наявність повної і докладної історії зміни;
  • можливість перейти до будь-якої версії проекту;
  • можливість перейти до будь-якої версії окремого документа;
  • наявність «гілок» з докладною історією для кожної з них;
  • можливість працювати з проектом, або окремим файлом одночасно декільком користувачам;
  • можливість вирішення конфліктів;
  • можливість працювати без підключення до інтернету;
  • система повинна самостійно відстежувати і автоматично аналізувати будь-які зміни, записувати детальну інформацію по кожній зміні.

6. Пропонований шлях створення інтелектуальної надбудови

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

Для вирішення завдання пропонується використовувати шлях створення інтелектуальної надбудови над git. Надбудова на базі git, як конкретний проблемно-орієнтований САПР, повинна має такі характерні риси:

Створення цільового простору систем (ЦПС), тобто простору можливих рішень-прототипів. Є два шляхи:

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

Можливі варіанти, коли користувач може побудувати:

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

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

Висновок

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

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

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

Суть запропонованого шляху полягає в створенні інтелектуальної надбудови, яка дозволить виконувати інтелектуальний аналіз і синтез програм, використовуючи накопичений в рамках ВКВ досвід програмістів в розробці програмного продукту в конкретній програмної області.

Як перспективну роботу слід визначити створення комплексу конкретних методів і механізмів реалізації обраного шляху.

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

  1. Аналіз вимог та інші робочі потоки програмної інженерії [Електронний ресурс] - Режим доступу: https://studfiles.net/preview/1644196/page:17/ - Загл. з екрану.
  2. Система управління версіями [Електронний ресурс] // Вікіпедія - Режим доступу: https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC % D0% B0_% D1% 83% D0% BF% D1% 80% D0% B0% D0% B2% D0% BB% D0% B5% D0% BD% D0% B8% D1% 8F_% D0% B2% D0 % B5% D1% 80% D1% 81% D0% B8% D1% 8F% D0% BC% D0% B8.
  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.