Modelo de sincronización

En el modelo de extracción/registro, los archivos se almacenan individualmente en un repositorio del que se extraen cuando se accede a ellos y se registran cuando se modifican. Este repositorio puede almacenar múltiples versiones de los archivos. Dado que estos archivos pueden ser documentación o código fuente , pero también pueden ser una colección de archivos, a partir de ahora se utilizará el término Elemento de configuración (CI). El mecanismo básico utilizado para evitar conflictos por modificaciones simultáneas es el de bloqueo .

El modelo de composición es una extensión del modelo de extracción/registro. Este modelo permite a los desarrolladores pensar en configuraciones en lugar de archivos individuales. Si bien el modelo de extracción/registro completo está representado en el modelo de composición, permite el uso de diferentes estrategias de actualización mediante un soporte mejorado para la gestión de configuraciones. Una configuración se define como la construcción a partir de un modelo de sistema y reglas de selección de versiones. El modelo de sistema determina qué archivos se utilizan, mientras que las reglas de selección de versiones determinan qué versión de los archivos (por ejemplo, las versiones más recientes o de un estado de desarrollo específico ).

El modelo de transacciones largas adopta un enfoque más amplio al asumir que un sistema se construye a partir de cambios lógicos. Se centra en la coordinación e integración de estos cambios. Básicamente, utiliza versiones de configuraciones y versiones de archivos. Una configuración se crea a partir de una solicitud de cambio , la cual se almacena por separado. Los archivos de esta configuración se pueden sincronizar mediante el modelo de extracción/registro. Una vez completado el cambio, la configuración completa se almacena de nuevo en el repositorio y se integra con los demás cambios.

El modelo de conjuntos de cambios también funciona a partir de solicitudes de cambio y comparte muchas similitudes con el modelo de transacciones largas. Sin embargo, parte de una configuración inicial que sirve de base para las modificaciones. Esta configuración se modifica posteriormente según las solicitudes de cambio independientes recibidas. A continuación, se crean nuevas configuraciones del producto aplicando conjuntos de los cambios almacenados de forma independiente sobre la versión base .

Esta entrada abarca el modelo de sincronización de entrada/salida, incluyendo un metamodelo (un diagrama de procesos y datos ). Dado que el modelo de entrada/salida también forma parte de los demás modelos mencionados anteriormente, se desarrolla con mayor detalle. Los tres modelos de sincronización restantes y la edición de los elementos de configuración, junto con los métodos relacionados, no se abordan en profundidad.

El diagrama de procesos y datos anterior describe los diferentes conceptos aplicables al modelo de sincronización de entrada/salida y su relación con las actividades que se realizan. El elemento central del modelo de metadatos (lado derecho de la figura) es el elemento de configuración. Este se almacena en uno o más repositorios y puede ser, por ejemplo, un archivo de código fuente o una colección de otros elementos de configuración. El repositorio puede contener varias ramas y revisiones de archivos, que a su vez constan de elementos de configuración.

El modelo de metaproceso (lado izquierdo de la figura) describe el proceso de las actividades de salida y entrada. Las actividades se explican en la tabla de actividades que aparece a continuación.

Feiler (1991) evaluó el modelo de sincronización de entrada/salida. Presenta la clara ventaja de ser fácil de usar y comprender. Sin embargo, esta simplicidad conlleva una falta de gestión de configuraciones, como el seguimiento de versiones de productos y la verificación del historial de versiones en múltiples archivos lógicamente conectados.

El mecanismo de bloqueo por turnos también supone un problema real cuando se trabaja con muchos desarrolladores, ya que estos archivos no pueden ser editados por otros una vez que han sido bloqueados.

Para ilustrar el modelo de sincronización de entrada y salida, esta sección incluye un ejemplo de cómo funciona este proceso. La siguiente figura muestra un diagrama de transición de estados de un CI.

Cuando se crea un CI por primera vez, se modifica y se almacena en el repositorio. Cuando alguien solicita abrir el CI, primero se copia a la máquina local del desarrollador (nota: existen sistemas donde la edición se realiza directamente en el repositorio. Sin embargo, el paso de copia sigue el método clásico de extracción/registro). Cuando ese desarrollador también quiere editar el CI, solicita un bloqueo. Esto puede hacerse directamente al solicitar abrir un CI, o después de un tiempo de lectura. Si el CI aún no está bloqueado, se aplica un bloqueo y el desarrollador puede modificarlo. Una vez realizadas las modificaciones, se almacena de nuevo en el repositorio y se desbloquea. Ahora, supongamos que el desarrollador mencionado anteriormente está editando un CI que ya se encuentra en el repositorio. Desea abrir un CI del repositorio, por lo que se copia a su disco local. Comienza a leerlo y encuentra algunos elementos que desea cambiar, por lo que solicita editarlo. Sin embargo, el CI ya está bloqueado y tendrá que esperar a que se desbloquee o cerrar el archivo y continuar con otro.