WikiDer > Модель синхронизации
В управление конфигурацией (CM), необходимо контролировать (среди прочего) изменения, внесенные в программное обеспечение и документацию. Это называется контроль версий, который управляет несколькими версиями одной и той же единицы информации. Хотя контроль версий важен для CM, он не равен ему.
Модели синхронизации, также известные как модели управления конфигурацией (Feiler, 1991), описывают методы, позволяющие управлять версиями за счет разрешения одновременных одновременных изменений отдельных файлов.
Модели синхронизации
Feiler (1991) сообщает о четырех различных моделях синхронизации, кратко описанных ниже.
Выселение / заселение
В модели выписки / заселения файлы хранятся индивидуально в хранилище из которого они извлекаются при каждом доступе к файлам и возвращаются при их изменении. В этом репозитории можно хранить несколько версий файлов. Поскольку эти файлы могут быть документация или же исходный код, но также может быть набором файлов, термин Элемент конфигурации (CI) будет использоваться с этого момента. Основной механизм, используемый для предотвращения конфликтов путем одновременных модификаций, - это механизм запирание.
Сочинение
Модель композиции является расширением модели регистрации отъезда / регистрации. Эта модель позволяет разработчикам мыслить конфигурации вместо отдельных файлов. Хотя полная модель извлечения / возврата представлена в модели композиции, она позволяет использовать различные стратегии для обновления за счет использования улучшенной поддержки для управления конфигурациями. Конфигурация определяется как построенная на основе модели системы и правил выбора версии. Системная модель определяет, какие файлы используются, а правила выбора версии определяют, какая версия файлов (например, последние версии или определенные состояние развития).
Длинные сделки
Модель длинных транзакций использует более широкий подход, предполагая, что система построена на основе логических изменений. Его внимание сосредоточено на координации и интеграции этих изменений. В основном он использует версии конфигураций и версии файлов. Конфигурация создается на основе Запрос на изменение который хранится отдельно. Файлы в этой конфигурации могут быть синхронизированы с использованием модели выписки / возврата. По завершении изменения полная конфигурация сохраняется в репозитории и интегрируется с другими изменениями.
Изменить набор
Модель набора изменений также работает на основе запросов на изменение и имеет много общего с моделью длинных транзакций. Однако он начинается с определенной конфигурации как основы для изменений. Затем он изменяется в соответствии с поступающими независимыми запросами на изменение. Затем создаются новые конфигурации продукта путем применения наборов независимо сохраненных изменений на исходный уровень версия.
В этой записи описывается модель синхронизации выписки / прихода, включая метамодель (а диаграмма данных процесса). Поскольку модель выписки / заселения также включена как часть других моделей, рассмотренных выше, поэтому она подвергается дальнейшему развитию. Вопросы, которые не обсуждаются подробно, - это три оставшиеся модели синхронизации и фактическое редактирование CI вместе с методами, связанными с этим.
Словарный запас
| Концепция | Определение |
|---|---|
| Версия | Версия - это состояние объекта или концепции, которое отличается от предыдущего состояния или состояния. |
| Элемент конфигурации | Элемент программного обеспечения или документ, находящийся под контролем версий. Группа КИ также может быть определена как КИ (Crnkovic et al., 2003). |
| История элемента конфигурации | Концепция облегчения штамповки версий. Отделяет атрибуты версии от атрибутов, общих для всех версий (Van de Weerd, 2005). |
| Документ | Многие виды документация являются частью программной инженерии. Рассмотрим документы, описывающие архитектуру программного обеспечения, техническую документацию, руководства пользователя и т. Д. |
| Исходный код файл | Файл исходного кода содержит любую серию операторов, написанных на каком-либо понятном человеку языке программирования. Исходный код компьютерной программы - это набор файлов, которые можно преобразовать из удобочитаемой формы в эквивалентную исполняемую на компьютере форму. |
| Репозиторий | Репозиторий также называют хранилищем. Репозиторий содержит только одну полную версию элемента конфигурации. Различия между версиями обычно сохраняются с использованием дельта-алгоритма (Crnkovic, Asklund & Persson-Dahlqvist, 2003). |
| Организация управления версиями | Версии CI могут быть организованы по-разному. Это родительская концепция, описывающая организацию версий (Crnkovic et al., 2003). |
| Ответвляться | Версии организованы как параллельные линии разработки (Crnkovic et al., 2003). |
| Редакция | Версии организованы в определенной последовательности (Crnkovic et al., 2003). |
| Состояние развития | Показывает, как продвигалась разработка программного обеспечения и сколько для этого может потребоваться доработка. Каждая основная версия продукта обычно проходит этап, когда добавляются новые функции (этап / состояние альфа), затем этап, когда он активно отлаживается (этап / состояние бета), и, наконец, этап, когда все важные ошибки были удалены ( стабильный этап / состояние). |
Разработка модели выезда / заселения
В этом разделе подробно описана модель синхронизации выписки / прихода.
Диаграмма данных процесса
Диаграмма данных процесса, приведенная выше, описывает различные концепции, применимые в модели синхронизации выписки / прихода, и их связь с выполняемыми действиями. Центральным элементом модели метаданных (правая часть рисунка) является элемент конфигурации. Он хранится в одном или нескольких репозиториях и может, например, быть файлом исходного кода или набором других КЭ. Репозиторий может содержать несколько веток и ревизий файлов. Они, в свою очередь, состоят из элементов конфигурации.
Модель метапроцесса (левая часть рисунка) описывает процесс выписки и регистрации. Действия объясняются в таблице мероприятий ниже.
| Мероприятия | Подвид деятельности | Определение |
|---|---|---|
| Проверить | Файлы не читаются и не изменяются напрямую из репозитория. Проверка описывает эти действия. | |
| Копировать CI | Конкретная версия CI копируется из репозитория. | |
| Блокировка CI | Если требуется доступ для записи и если CI еще не заблокирован кем-то другим, этот CI блокируется. В противном случае CI нельзя будет записать обратно в репозиторий (доступ только для чтения). | |
| Изменить CI | Человек, редактирующий CI, вносит в него изменения. Это выходит за рамки текущей метамодели, касающейся управления версиями. | |
| Регистрироваться | CI необходимо вернуть в репозиторий. Проверка описывает эти действия. | |
| Выберите стратегию управления версиями | Новый CI должен быть помещен обратно в репозиторий с использованием стратегии управления версиями. Здесь описывается выбор стратегии, используемой для помещения CI обратно в репозиторий. | |
| Создать ветку | CI выбран как начало новой ветви. | |
| Создать ревизию | CI выбирается как версия другого CI. | |
| Выберите состояние разработки | Определено, что CI находится в определенном состоянии разработки. | |
| Написать CI | CI хранится в репозитории. | |
| Разблокировать CI | CI разблокирован. |
Оценка
Feiler (1991) оценил модель синхронизации выписки / регистрации. Его очевидное преимущество - простота использования и понимания. Однако такая простота приводит к отсутствию управления конфигурациями, например отслеживания версий продукта и проверки истории версий для нескольких логически связанных файлов.
Механизм очередности блокировки также является реальной проблемой при работе со многими разработчиками, поскольку эти файлы не могут редактироваться другими после того, как они были заблокированы.
Пример
Чтобы проиллюстрировать модель синхронизации выписки / прихода, в этом разделе содержится пример того, как работает этот процесс. Рисунок ниже содержит диаграмма перехода состояний КИ.
Когда CI создается впервые, он изменяется и сохраняется в репозитории. Когда кто-то запрашивает открыть CI, он сначала копируется на локальный компьютер разработчика (примечание: есть системы, в которых редактирование происходит непосредственно в репозитории. Однако этап копирования является классическим способом извлечения / возврата). Когда этот разработчик также хочет отредактировать CI, он запрашивает блокировку. Это можно сделать как непосредственно по запросу открытия CI, так и через некоторое время после его чтения. Когда CI еще не заблокирован, применяется блокировка, и разработчик может ее изменить. После внесения изменений он сохраняется в репозитории и разблокируется. Теперь предположим, что только что обсужденный разработчик находится в процессе редактирования CI, который уже находится в репозитории. Вы хотите открыть CI из репозитория и скопировать его на ваш локальный диск. Вы начинаете читать и находите некоторые вещи, которые хотите изменить, поэтому вы просите отредактировать его. Однако CI уже заблокирован, и вам придется подождать, пока он будет разблокирован, или закрыть файл и перейти к другому.
Смотрите также
- Управление конфигурацией
- Контроль версий
- Процесс управления изменениями
- Управление релизами
- Моделирование структуры продукта
- Разработка семейства продуктов
- Управление жизненным циклом продукта
- Список программного обеспечения для контроля версий
Рекомендации
- Црнкович, I .; Asklund, U .; Перссон-Дальквист, А. (2003), Внедрение и интеграция управления данными о продукте и управления конфигурацией программного обеспечения, Лондон: Издательство Artech House.
- Фейлер, П. Х. (1991), "Модели управления конфигурацией в коммерческих средах", Технический отчет CMU / SEI-91-TR-7, Институт программной инженерии, Университет Карнеги-Меллона
- Ван де Верд, И. (2005), Методика метамоделирования - черновик курса Методология 05/06