Инструментальные средства проектирования ПО

Сегодня все работают с файлами, на компьютерах создают их в больших количествах, например, журналисты, которые подготавливают материалы статей, фотографы и художники, а так же программисты, разрабатывающие крупные проекты.
Но ни кто не застрахован от потери данных, все труды могут пропасть при возникновении нештатной ситуации. Дабы не тратить силы и время на возобновление утерянной информации, можно предусмотреть самый примитивный способ, это создание копий файлов. Обычно применяют в таких случаях утилиту diff (создают две копии, одну для работы, а другую для модификации), а затем их совмещают утилитой patch.
Описанный ранее способ идеален при небольших объёмах информации, но если файлов с данными много, то проще воспользоваться системой управления версиями (СУВ). Это ПО позволяет, не только файлы, но и откатывать целые проекты к изначальным данным. Можно пошагово отследить действия совершённые в программе и узнать время изменения её, что повлекло за собой сбой в функционировании.
Целью реферативной исследовательской работы служат системы управления версиями.
В ходе исследования требуется решить такие задачи:
Рассмотреть локальные системы управления версиями.
Рассмотреть централизованные СУВ.
Рассмотреть и проанализировать распределённые системы управления версиями.
В работе будут использованы статьи, учебные пособия, ресурсы сети Интернет.
1. Локальные системы управления версиями
Локальная СКВ, которую чаще всего используют, называется RCS (Revision Control System, Система контроля ревизий), её и сейчас инсталлируют на ПК [1]. К примеру, в операционной системе Mac OS X утилита rcs инсталлируется совместно с Developer Tools. Хотя RCS появилась в начале восьмидесятых годов прошлого века (разработчик Вальтер Тичи (Walter F. Tichy)).
Возможности системы ограничены хранением одного файла, большим количеством она управлять не может. Для каждого файла находящегося под контролем системы информация о версиях хранится в специальном файле с именем оригинального файла к которому в конце добавлены символы ',v'.
Например, для файла file.txt версии будут храниться в файле file.txt,v. Данная утилита ориентирована на функционировании с наборами патчей между парами версий, что даёт пересоздать любой файл на любой момент времени, последовательно накладывая патчи.
Для хранения версий система применяет утилиту diff. RCS может осуществлять контроль версий, имея минимальные возможности для этого, но недостатков у неё много:
Работа только с одним файлом, каждый файл должен контролироваться отдельно;
Неудобный механизм одновременной работы нескольких пользователей с системой, хранилище просто блокируется пока заблокировавший его пользователь не разблокирует его.
2. Централизованные системы контроля версий
Для решения задачи, которая заключалась в том, что надо было взаимодействовать с разработчиками, которые находились за другими ПК. Для этого разработали централизованные системы контроля версий (ЦСКВ) (рис.1). В таких системах, например CVS, Subversion и Perforce, существует центральный сервер, на нём держат все файлы под версионным управлением, и ряд клиентов, которым отправляют копии файлов из него. Не которое время это было правилом для всех систем контроля версий[2].
Рис.1 Централизованные VCS.
Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей.
CVS (Concurrent Versions System, Система совместных версий) в настоящий момент является наиболее применяемой системой, хотя начинает проигрывать более современным системам

. Подобно RCS, система CVS применяет файлы формата RCS, но даёт возможность контролировать множество файлов, которые находятся в директориях[3].
Применяет CVS архитектуру клиент-сервер. При этом все варианты модификаций содержатся на сервере. Клиенты в системе имеют возможность работать одновременно. Если произойдут противоречия при модификации одного и того же файла, то будет изменена только его итоговый вариант.
Таким образом всегда рекомендуется перед заливкой своих изменений обновлять свою рабочую копию файлов на случай возможных конфликтующих изменений. При обновлении система вносит изменения в рабочую копию автоматически и только в случае конфликтующих изменений в одном из мест файла требуется ручное исправление места конфликта.
CVS также позволяет вести несколько линий разработки проекта с помощью ветвей (branches) разработки. Таким образом, как уже упоминалось выше, можно исправлять ошибки в первой версии проекта и параллельно разрабатывать новую функциональность.
CVS применялась для значительного числа решений, хотя имеет значительные минусы, которые заставили разработчиков создавать ей замену. Значительные недостатки CVS:
Так как версии хранятся в файлах RCS нет возможности сохранять версии директорий. Оптимальный метод справится с этой проблемой существует, он заключается в сохранении, к примеру, README.txt в директории;
Нельзя в данном ПО переименовать или переместить файл. Приходится идти окольным путём, удалять файл, применив команду cvs remove (изначально его скопировать), а потом уже переименованный добавить в систему командой cvs add.
SVN изначально разрабатывался как "лучший CVS" и основной задачей разработчиков было исправление ошибок допущенных в дизайне CVS при сохранении похожего интерфейса. SVN также как и CVS использует клиент-сервер архитектуру.
Из наиболее значительных изменений по сравнению с CVS можно отметить: Атомарное внесение изменений (commit). В случае если обработка коммита была прервана, то не будет внесено никаких изменений. Переименование, копирование и перемещение файлов сохраняет всю историю изменений. Директории, символические ссылки и метаданные подвержены контролю версий. Эффективное хранение изменений для бинарных файлов.
3. Распределённые системы контроля версий
Наиболее современны и универсальны распределённые системы контроля версий (РСКВ) (рис.2). Git, Mercurial, Bazaar и Darcs системы характеризуются тем, что репозиторий тиражируется для всех клиентов полностью. При форс-мажорных обстоятельствах, когда перестаёт работать сервер, при помощи любого клиента вероятно возобновить базу на новом сервере. Тираж всей информации получается при каждой загрузке нового варианта [4].
Рис.2 Распределённые VCS.
Помимо этого, во многих системах есть возможность взаимодействовать с множеством удалённых репозиториев, таким образом, можно одновременно работать по-разному с разными группами людей в рамках одного проекта. Так, в одном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах. Как следует из названия одна из основных идей распределенных систем — это отсутствие четко выделенного центрального хранилища версий - репозитория. В случае распределенных систем набор версий может быть полностью, или частично распределен между различными хранилищами, в том числе и удаленными. Такая модель отлично вписывается в работу распределенных команд, например, распределенной по всему миру команды разработчиков работающих над одним проектом с открытым исходным кодом.
Разработчик такой команды может скачать себе всю информацию по версиям и после этого работать только на локальной машине