La gestión eficaz de versiones y configuración siempre es muy importante en los proyectos de desarrollo de software.
1. El concepto de control de versiones.
En un proyecto MDSD se deben gestionar y versionar los siguientes aspectos:
- Generar herramientas. Actualmente, las herramientas en sí aún se están desarrollando, por lo que tiene sentido controlar su versión.
- Configuración del generador: la parte generada de la arquitectura del dominio, esto incluye definiciones de archivos de configuración/DSL, metamodelos, plantillas y transformaciones.
- La parte no generada de la arquitectura del dominio: la plataforma MDSD.
- La aplicación en sí: modelos, especificaciones y código desarrollado manualmente.
Idealmente, el código generado no está versionado, ya que puede reproducirse a partir del modelo en cualquier momento dado y, por lo tanto, no constituye el código fuente real del programa. Por supuesto, esta idea sólo puede aplicarse de manera realista si existe una separación estructural entre el código creado a mano y el generado en el sistema de archivos.
Uno de los objetivos del desarrollo basado en modelos es desarrollar algunas aplicaciones basadas en la misma arquitectura de dominio. Por lo tanto, es necesario separar completamente la configuración de la plataforma y del generador de la aplicación.
2. Proyectos y dependencias
La atención se centra en la gestión de dependencias de varios proyectos, incluidas sus versiones. Para proyectos de aplicaciones, es necesario especificar en qué versión de la arquitectura de dominio se basa el proyecto. Si la plataforma subyacente mejora, es posible que sea necesario mejorar al mismo tiempo la arquitectura del dominio y posiblemente incluso el proyecto de la aplicación. Se puede utilizar una metáfora del marco para demostrar esto: imagine la arquitectura del dominio como un marco. Si mejora el marco, debe cambiar su aplicación cliente. Estas cosas tienen la misma relevancia, por lo que se aplica el mismo enfoque en la mejora de la arquitectura del dominio.
3. La estructura del proyecto de solicitud.
Proyectos, artefactos y repositorios
El diagrama anterior muestra cómo se configura un proyecto de aplicación en el nivel más alto y cómo lo utilizan el generador y el compilador.
El modelo de la aplicación, así como el código creado manualmente, reside en el repositorio de la aplicación. Los generadores crean código generado respaldado por configuraciones del generador, incluidos archivos de configuración, etc. Los archivos de configuración se encuentran en el repositorio de arquitectura del dominio. A continuación, se genera la aplicación con la ayuda de un script de compilación. Este paso utilizará el código artesanal de la aplicación y la plataforma, obteniendo el código artesanal de la plataforma del repositorio de arquitectura del dominio.
4. Gestión de versiones y proceso de construcción de archivos mixtos.
No siempre es posible o práctico separar completamente el código generado y el no generado. Los ejemplos relevantes incluyen:
- Código personalizado en el descriptor de implementación J2EE;
- Código personalizado en archivos JSP;
- Código personalizado en archivos de propiedades u otros archivos de configuración.
En general, se trata de lugares donde el idioma de destino no proporciona un mecanismo de delegación adecuado.
Evidentemente, el uso de esta área protegida da como resultado un archivo en el que se mezcla código generado y no generado. El problema aquí es que estos archivos normalmente sólo se pueden versionar en su totalidad. Esto lleva al hecho de que se registrará código redundante, ya que el código generado no es la fuente después de todo: la fuente será el modelo a partir del cual se genera el código.
Este código redundante puede generar inconsistencias durante el desarrollo del equipo. Esta inconsistencia se convertirá en un problema creciente a medida que el equipo evolucione.
Los conflictos de fusión entre desarrolladores se detectan exclusivamente utilizando las fuentes de la aplicación en el repositorio.
Cabe recalcar nuevamente que, en nuestra opinión, la separación entre código generado y no generado es el enfoque preferible y debería intentarse en cualquier caso.
5. Modelado en el equipo y versionado de algunos modelos.
Los sistemas grandes deben particionarse. Sus partes o subsistemas constitutivos se desarrollan más o menos independientemente unos de otros. Las interfaces definen cómo interactuará el sistema. El paso normal de integración es juntar las piezas. Este enfoque es especialmente útil si las piezas se desarrollan en diferentes ubicaciones o por diferentes equipos. Por supuesto, esto afecta principalmente al proceso de desarrollo y a la comunicación dentro del equipo, y quizás también a la arquitectura del sistema.
1. Particiones y subdominios
Primero, es importante señalar la diferencia entre partición y uso de subdominio.
Los subdominios son aspectos que aíslan todo el sistema. Cada subdominio tiene su propio metamodelo y DSL. Los diferentes metamodelos se unifican conceptualmente a través de la metaclase gateway. En el contexto de los sistemas empresariales, estos podrían ser procesos de negocio de subdominio, persistencia y GUI.
En cambio, las particiones describen la definición de partes del sistema. Por razones de complejidad o organización eficiente del proyecto, descomponga una gran cantidad de requisitos técnicamente similares en partes separadas que puedan integrarse mediante interfaces.
2. Varias arquitecturas de software generadas
Si se utilizan diferentes arquitecturas de construcción en diferentes particiones del proyecto, surge la pregunta de si los artefactos generados funcionarán juntos. En general, esto significa que la integración debe ocurrir en el nivel del código generado. Como ejemplo, supongamos que se utilizan diferentes versiones de la infraestructura de compilación, todas las cuales crearán partes de una aplicación J2EE integral.
3. Desarrollo de DSL
Los DSL normalmente se desarrollan continuamente durante el transcurso de un proyecto. Los DSL evolucionarán a medida que el conocimiento y la comprensión del dominio crezcan y se profundicen. Para facilitar las cosas, es necesario garantizar que el DSL mantenga la compatibilidad con versiones anteriores durante su desarrollo.
4. Partición e integración
Supongamos que diferentes equipos necesitan la misma interfaz, quizás porque un equipo implementa un componente que usa código de otro equipo.
Cuando el trabajo a realizar está basado en modelos, se requiere aplicar un modelo con interfaces en al menos dos de los modelos. Sin embargo, este enfoque no es ideal debido a los problemas de coherencia que implica la duplicación de información en ambos modelos. Dependiendo de la herramienta, existen otras opciones.
1) Integración en el modelo.
Si la herramienta de modelado lo admite, debe asegurarse de que la interfaz exista en un solo lugar y que se haga referencia a ella desde ambos modelos. Desde el punto de vista del generador, esto producirá un modelo consistente.
La posibilidad de este enfoque depende de la herramienta de modelado. Entre las herramientas UML, la opción ideal es una herramienta basada en repositorio que admita el modelado discreto.
2) Integración mediante sincronización de modelos en el generador.
La integración también puede ocurrir a nivel del generador si la herramienta de modelado no proporciona una opción de integración adecuada. El generador lee algunos modelos de entrada y cada fila contiene elementos de modelo específicos.
En este caso, la tarea del generador es resolver posibles problemas de consistencia.
3) Integración por referencia en el generador.
Otra opción de integración es utilizar referencias.