Модели синхронизации в управлении конфигурациями: обзор и модель "выдача/возврат"
Synchronization model
Управление конфигурациями: контроль изменений ПО и документации. Модели синхронизации (Feiler, 1991) обеспечивают контроль версий и параллельную работу.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
В управлении конфигурацией (CM) необходимо контролировать (в частности) изменения, вносимые в программное обеспечение и документацию. Это называется управлением версиями, которое позволяет отслеживать несколько версий одного и того же элемента информации. Хотя управление версиями важно для CM, оно не тождественно ему. Модели синхронизации, также известные как модели управления конфигурацией (Feiler, 1991), описывают методы, обеспечивающие управление версиями за счет разрешения одновременного, параллельного изменения отдельных файлов.
In configuration management (CM), one has to control (among other things) changes made to software and documentation. This is called revision control, which manages multiple versions of the same unit of information. Although revision control is important to CM, it is not equal to it. Synchronization Models, also known as Configuration Management Models (Feiler, 1991), describe methods to enable revision control through allowing simultaneous, concurrent changes to individual files.
Модели синхронизации
Фейлер (1991) сообщает о четырех различных моделях синхронизации, которые кратко описаны ниже.
Feiler (1991) reports on four different synchronization models, shortly described below.
Выезд/прибытие
В модели "check out/check in" файлы хранятся индивидуально в репозитории, откуда они извлекаются при доступе и возвращаются в репозиторий после внесения изменений. Этот репозиторий может хранить несколько версий файлов. Поскольку эти файлы могут быть документацией или исходным кодом, а также представлять собой набор файлов, отныне будет использоваться термин "элемент конфигурации" (CI). Основным механизмом предотвращения конфликтов при одновременном изменении является блокировка.
In the check out/check in model, files are stored individually in a repository from which they are checked out whenever the files are accessed, and checked in when they have changed. This repository can store multiple versions of the files. Because these files can be documentation or source code, but can also be a collection of files, the term Configuration item (CI) will be used from now on. The basic mechanism used to prevent conflicts by simultaneous modifications is that of locking.
Состав
Модель композиции является расширением модели выписки/возврата. Эта модель позволяет разработчикам мыслить категориями конфигураций, а не отдельных файлов. Хотя модель выписки/возврата полностью представлена в модели композиции, она обеспечивает использование различных стратегий обновления благодаря улучшенной поддержке управления конфигурациями. Конфигурация определяется как формируемая на основе системной модели и правил выбора версий. Системная модель определяет, какие файлы используются, а правила выбора версий – какая версия файлов используется (например, последние версии или версия определенного этапа разработки).
The composition model is an extension on the check out/check in model. This model allows developers to think in configurations instead of individual files. Although the complete check out/check in model is represented in the composition model, it enables the use of different strategies for updating through the use of improved support for the management of configurations. A configuration is defined as being built up from a system model and version selection rules. The system model determines which files are used, while the version selection rules determine which version of the files (e. g. the latest versions or of a certain development state).
Долгие сделки
Модель длинных транзакций рассматривает систему как результат последовательных логических изменений, делая акцент на координации и интеграции этих изменений. В основе подхода лежит использование версий конфигураций и версий файлов. Конфигурация создается на основе запроса на изменение, который хранится отдельно. Файлы в рамках этой конфигурации могут синхронизироваться по модели "выборка-возврат". После завершения изменения вся конфигурация сохраняется в репозиторий и интегрируется с другими изменениями.
The long transactions model takes a broader approach by assuming that a system is built up out of logical changes. Its focus is on the coordination and integration of these changes. Basically, it uses versions of configurations and versions of files. A configuration is created based on a change request which is stored separately. Files in this configuration can be synchronized using the check out/check in model. When the change is completed, the complete configuration is stored back into the repository and integrated with other changes.
Настройка изменений
Модель набора изменений также работает на основе запросов на изменения и имеет много общего с моделью длительных транзакций. Однако она начинается с определенной конфигурации, которая служит основой для изменений. Эта конфигурация затем изменяется в соответствии с поступающими независимыми запросами на изменение. Новые конфигурации продукта создаются путем применения наборов независимо сохраненных изменений к базовой версии. В данной статье рассматривается модель синхронизации "check out/check in", включая метамодель (диаграмму данных процесса). Поскольку модель "check out/check in" также является частью других описанных выше моделей, она будет рассмотрена более подробно. Вопросы, которые не обсуждаются подробно, включают три оставшиеся модели синхронизации и непосредственное редактирование элементов конфигурации (CI) вместе с соответствующими методами.
The change set model also works based on change requests and has a lot in common with the long transactions model. However, it starts with a certain configuration as the basis for changes. This is then changed according to the independent change requests that come in. New configurations of the product are then created by applying sets of the independently stored changes on the baseline version. This entry covers the check out/check in synchronization model, including a meta model (a process data diagram). Because the check out/check in model is also included as a part of the other models discussed above, it is therefore further elaborated upon. Issues that are not discussed in detail are the three remaining synchronization models and the actual editing of CIs together with the methods related to this.
Словарь
Определение понятия
Версия – это состояние объекта или концепции, отличающееся от его предыдущего состояния или условий.
Элемент конфигурации – элемент программного обеспечения или документа, находящийся под контролем версий. Группа элементов конфигурации (ИК) также может быть определена как ИК (Crnkovic et al., 2003).
История элементов конфигурации – концепция, облегчающая присвоение меток версии. Разделяет атрибуты, специфичные для версии, от атрибутов, общих для всех версий (Van de Weerd, 2005).
Документ – к документам относится множество типов документации, используемых в разработке программного обеспечения, например, документы, описывающие архитектуру программного обеспечения, техническая документация, руководства пользователя и т.д.
Файл исходного кода – файл исходного кода содержит любую последовательность операторов, написанных на каком-либо читаемом для человека языке программирования. Исходный код компьютерной программы – это совокупность файлов, которые могут быть преобразованы из читаемой человеком формы в эквивалентную исполняемую компьютером форму.
Репозиторий – репозиторий также называют хранилищем. Репозиторий содержит только одну полную версию элемента конфигурации. Различия между версиями обычно хранятся с использованием дельта-алгоритма (Crnkovic, Asklund & Persson Dahlqvist, 2003).
Организация версий – версии ИК могут быть организованы различными способами. Это родительская концепция для концепций, описывающих организацию версий (Crnkovic et al., 2003).
Ветвь – версии, организованные как параллельные линии разработки (Crnkovic et al., 2003).
Ревизия – версии, организованные в последовательности (Crnkovic et al., 2003).
Состояние разработки – отражает прогресс разработки программного обеспечения и объем дальнейшей разработки, который может потребоваться. Каждая основная версия продукта обычно проходит стадию добавления новых функций (альфа-стадия / состояние), затем стадию активной отладки (бета-стадия / состояние) и, наконец, стадию, на которой все важные ошибки устранены (стабильная стадия / состояние).
Concept DefinitionVersionA version is a state of an object or concept that varies from its previous state or condition. Configuration itemAn element of software or a document placed under version control. A group of CIs can also be defined as a CI (Crnkovic et al., 2003). Configuration item historyA concept to facilitate version stamping. Splits version specific attributes from attributes common to all versions (Van de Weerd, 2005)DocumentMany types of documentation are part of software engineering. Consider documents that describe the software architecture, technical documentation, user manuals, etc. Source code fileA source code file contains any series of statements written in some human readable computer programming language. A computer program's source code is the collection of files that can be converted from human readable form to an equivalent computer executable form. RepositoryA repository is also called a vault. A repository contains only one complete version of a configuration item. Differences between versions are usually stored using a delta algorithm (Crnkovic, Asklund & Persson Dahlqvist, 2003). Versioning organizationVersions of a CI may be organized in a number of different ways. This is the parent for the concepts that describe the organization of versions (Crnkovic et al., 2003). BranchVersions organized as parallel development lines (Crnkovic et al., 2003). RevisionVersions organized in a sequence (Crnkovic et al., 2003). Development stateExpresses how the development of a piece of software has progressed and how much further development it may require. Each major version of a product usually goes through a stage when new features are added (alpha stage / state), then a stage when it is actively debugged (beta stage / state), and finally a stage when all important bugs have been removed (stable stage / state).
Разработка модели "Check-out/Check-in"
В этом разделе приводится подробное описание модели синхронизации выписки/записи.
This section contains an elaboration on the check out/check in synchronization model.
Диаграмма данных процесса
На приведенной выше схеме данных процесса описаны различные концепции, применимые в модели синхронизации "выдача/возврат", и их связь с выполняемыми действиями. Центральным элементом модели метаданных (справа на рисунке) является элемент конфигурации (КИ). Он хранится в одном или нескольких репозиториях и может быть, например, файлом исходного кода или набором других КИ. Репозиторий может содержать несколько веток и ревизий файлов, которые, в свою очередь, состоят из элементов конфигурации. Мета-модель процесса (слева на рисунке) описывает процесс выдачи и возврата. Эти действия подробно описаны в таблице ниже.
The process data diagram above describes the different concepts that are applicable in the check out/check in synchronization model and their relation to the activities that take place. Central to the meta data model (right side of the figure) is the Configuration Item. This is stored in one or more repositories and can for example be a source code file or a collection of other CIs. The repository can contain multiple branches and revisions of files. These in turn consist of configuration items. The meta process model (left side of the figure) describes the process of the check out and check in activities. The activities are explained in the table of activities below. Activity Sub activity DefinitionCheck Out Files are not read or changed directly from the repository. Checking out describes these activities. Copy CI A particular version of a CI is copied from the repository. Lock CIIf write access is required and if the CI is not already locked by someone else, the CI is locked. Otherwise the CI cannot be written back to the repository (read only access). Modify CIThe person editing the CI makes changes to it. This is out of the scope of the current meta model regarding version management. Check InThe CI needs to be placed back into the repository. Checking in describes these activities. Select versioning strategyThe new CI has to be placed back in the repository using a versioning strategy. This describes the selection of the strategy used to place the CI back into the repository. Create branchThe CI is selected to be the start of a new branch. Create revisionThe CI is selected to be a revision of another CI. Select development stateThe CI is determined to be of a certain development state. Write CIThe CI is stored in the repository. Unlock CIThe CI is unlocked.
Действие | Поддействие | Определение
------- | -------- | --------
Выдача | | Файлы не читаются и не изменяются напрямую из репозитория. Выдача описывает эти действия.
Копировать КИ | | Определенная версия КИ копируется из репозитория.
Заблокировать КИ | | Если требуется доступ на запись и КИ не заблокирован другим пользователем, КИ блокируется. В противном случае запись КИ в репозиторий невозможна (доступ только для чтения).
Изменить КИ | | Пользователь, редактирующий КИ, вносит в него изменения. Это выходит за рамки текущей метамодели в части управления версиями.
Возврат | | КИ необходимо поместить обратно в репозиторий. Возврат описывает эти действия.
Выбрать стратегию версионирования | | Новый КИ должен быть возвращен в репозиторий с использованием стратегии версионирования. Это описывает выбор стратегии, используемой для возврата КИ в репозиторий.
Создать ветку | | КИ выбирается в качестве начала новой ветки.
Создать ревизию | | КИ выбирается в качестве ревизии другого КИ.
Выбрать состояние разработки | | КИ определяется как находящийся в определенном состоянии разработки.
Записать КИ | | КИ сохраняется в репозитории.
Разблокировать КИ | | КИ разблокируется.
The process data diagram above describes the different concepts that are applicable in the check out/check in synchronization model and their relation to the activities that take place. Central to the meta data model (right side of the figure) is the Configuration Item. This is stored in one or more repositories and can for example be a source code file or a collection of other CIs. The repository can contain multiple branches and revisions of files. These in turn consist of configuration items. The meta process model (left side of the figure) describes the process of the check out and check in activities. The activities are explained in the table of activities below. Activity Sub activity DefinitionCheck Out Files are not read or changed directly from the repository. Checking out describes these activities. Copy CI A particular version of a CI is copied from the repository. Lock CIIf write access is required and if the CI is not already locked by someone else, the CI is locked. Otherwise the CI cannot be written back to the repository (read only access). Modify CIThe person editing the CI makes changes to it. This is out of the scope of the current meta model regarding version management. Check InThe CI needs to be placed back into the repository. Checking in describes these activities. Select versioning strategyThe new CI has to be placed back in the repository using a versioning strategy. This describes the selection of the strategy used to place the CI back into the repository. Create branchThe CI is selected to be the start of a new branch. Create revisionThe CI is selected to be a revision of another CI. Select development stateThe CI is determined to be of a certain development state. Write CIThe CI is stored in the repository. Unlock CIThe CI is unlocked.
Оценка
Файлер (1991) оценил модель синхронизации "check out/check in". Ее несомненное преимущество – простота использования и понимания. Однако эта простота приводит к недостатку управления конфигурациями, например, к отсутствию отслеживания версий продукта и проверки истории изменений в нескольких логически связанных файлах. Механизм блокировки также представляет собой серьезную проблему при работе с большим количеством разработчиков, поскольку после блокировки файлы становятся недоступными для редактирования другими пользователями.
Feiler (1991) evaluated the check out/check in synchronization model. It has the clear advantage that it's easy to use and understand. However, this simplicity results in a lack of management of configurations, such as product version tracking and checking version history across multiple logically connected files. The turn taking mechanism of locking is a real problem as well when working with many developers, as these files cannot be edited by others once it has been locked.
Пример
Для иллюстрации модели синхронизации "check out/check in" в этом разделе приведён пример работы этого процесса. На рисунке ниже представлена диаграмма переходов состояний КИ. Когда КИ впервые создаётся, он изменяется и сохраняется в репозитории. Когда кто-то запрашивает открытие КИ, он сначала копируется на локальный компьютер разработчика (примечание: существуют системы, где редактирование происходит непосредственно в репозитории. Однако этап копирования является классическим способом "check out/check in"). Когда разработчик также хочет отредактировать КИ, он запрашивает блокировку. Это можно сделать непосредственно при запросе открытия КИ, но также и спустя некоторое время после его чтения. Если КИ ещё не заблокирован, применяется блокировка, и разработчик может его изменять. После внесения изменений он сохраняется обратно в репозиторий и разблокируется. Теперь предположим, что разработчик, о котором шла речь, в данный момент редактирует КИ, который уже находится в репозитории. Вы хотите открыть КИ из репозитория, поэтому он копируется на ваш локальный диск. Вы начинаете его читать и находите то, что хотите изменить, поэтому запрашиваете разрешение на редактирование. Однако КИ уже заблокирован, и вам придётся ждать, пока он будет разблокирован, или закрыть файл и перейти к другому.
To illustrate the check out/check in synchronization model, this section contains an example of how this process works. The figure below contains a state transition diagram of a CI. When a CI is first created, it is modified and stored in the repository. When someone requests to open the CI, it is first copied to the local machine of the developer (note: there are systems where editing occurs directly in the repository. The copy step however is the classic check out/check in way). When that developer also wants to edit the CI, it requests a lock. This can be done directly at the request of opening a CI, but also after some time of reading it. When the CI is not locked yet, a lock is applied and it can be modified by the developer. After modifications have been done, it is stored back in the repository and unlocked. Now, assume that the developer that was just discussed is in the process of editing a CI that is already in the repository. You want to open a CI from the repository and so it is copied to your local drive. You start reading it and find some things you wish to change, so you request to edit it. However, the CI is already locked and you will have to wait for it to be unlocked or close the file and proceed to another one.