La ingeniería de ida y vuelta ( RTE ) en el contexto de la arquitectura basada en modelos es una funcionalidad de las herramientas de desarrollo de software que sincroniza dos o más artefactos de software relacionados, como código fuente, modelos , archivos de configuración, documentación, etc., entre sí. [1] La necesidad de ingeniería de ida y vuelta surge cuando la misma información está presente en múltiples artefactos y cuando puede surgir una inconsistencia en caso de que algunos artefactos se actualicen. Por ejemplo, se agregó/cambió cierta información en un solo artefacto (código fuente) y, como resultado, desapareció o fue inconsistente con los otros artefactos (en los modelos).
La ingeniería de ida y vuelta está estrechamente relacionada con las disciplinas tradicionales de la ingeniería de software : ingeniería directa (crear software a partir de especificaciones), ingeniería inversa (crear especificaciones a partir de software existente) y reingeniería (comprender el software existente y modificarlo). La ingeniería de ida y vuelta a menudo se define erróneamente como simplemente respaldar tanto la ingeniería directa como la inversa. De hecho, la característica clave de la ingeniería de ida y vuelta que la distingue de la ingeniería directa e inversa es la capacidad de sincronizar artefactos existentes que evolucionaron simultáneamente mediante la actualización incremental de cada artefacto para reflejar los cambios realizados en los otros artefactos. Además, la ingeniería directa puede verse como una instancia especial de RTE en la que solo está presente la especificación y la ingeniería inversa puede verse como una instancia especial de RTE en la que solo está presente el software. Muchas actividades de reingeniería también pueden entenderse como RTE cuando el software se actualiza para reflejar los cambios realizados en la especificación de ingeniería inversa previa.
Varios libros describen dos tipos de RTE: [2] : 459
Otra característica de la ingeniería de ida y vuelta es la actualización automática de los artefactos en respuesta a inconsistencias detectadas automáticamente . En ese sentido, se diferencia de la ingeniería directa e inversa, que puede ser tanto manual (tradicionalmente) como automática (mediante la generación o análisis automático de los artefactos). La actualización automática puede ser instantánea o bajo demanda . En RTE instantáneo, todos los artefactos relacionados se actualizan inmediatamente después de cada cambio realizado en uno de ellos. En RTE bajo demanda, los autores de los artefactos pueden actualizar los artefactos simultáneamente (incluso en un entorno distribuido) y en algún momento elegir ejecutar la coincidencia para identificar inconsistencias y optar por propagar algunas de ellas y reconciliar conflictos potenciales.
La ingeniería de ida y vuelta puede implicar un proceso de desarrollo iterativo. Una vez que haya sincronizado su modelo con el código revisado, aún podrá elegir la mejor forma de trabajar: realizar más modificaciones en el código o realizar cambios en su modelo. Puedes sincronizar en cualquier dirección en cualquier momento y puedes repetir el ciclo tantas veces como sea necesario.
Muchas herramientas comerciales y prototipos de investigación respaldan esta forma de RTE; un libro de 2007 enumera a Rational Rose , Micro Focus Together , ESS-Model, BlueJ y Fujaba entre los capaces, y se dice que Fujaba también es capaz de identificar patrones de diseño . [3]
Un libro de 2005 sobre Visual Studio señala, por ejemplo, que un problema común en las herramientas RTE es que el modelo invertido no es el mismo que el original, a menos que las herramientas reciban ayuda dejando laboriosas anotaciones en el código fuente. [4] Las partes conductuales de UML imponen aún más desafíos para RTE.
Por lo general, los diagramas de clases UML se admiten hasta cierto punto; sin embargo, ciertos conceptos de UML, como asociaciones y contención, no tienen representaciones sencillas en muchos lenguajes de programación, lo que limita la usabilidad del código creado y la precisión del análisis del código/ingeniería inversa (por ejemplo, la contención es difícil de reconocer en el código).
Una forma más manejable de ingeniería de ida y vuelta se implementa en el contexto de las interfaces de programación de aplicaciones (API) del marco, mediante las cuales un modelo que describe el uso de una API del marco por parte de una aplicación se sincroniza con el código de esa aplicación. En esta configuración, la API prescribe todas las formas correctas en que se puede utilizar el marco en las aplicaciones, lo que permite una detección precisa y completa de los usos de la API en el código, así como la creación de código útil que implemente los usos correctos de la API. Dos implementaciones RTE destacadas en esta categoría son los lenguajes de modelado específicos del marco y Spring Roo (Java).
La ingeniería de ida y vuelta es fundamental para mantener la coherencia entre múltiples modelos y entre los modelos y el código en la arquitectura basada en modelos de Object Management Group (OMG) . OMG propuso el estándar QVT (consulta/vista/transformación) para manejar las transformaciones de modelos requeridas para MDA. Hasta la fecha [ ¿cuándo? ] , se han creado algunas implementaciones del estándar. (Necesidad de presentar experiencias prácticas con MDA en relación a RTE).
La generación de código (ingeniería avanzada) a partir de modelos significa que el usuario modela de manera abstracta soluciones, que están connotadas por algunos datos del modelo, y luego una herramienta automatizada deriva de las partes del modelo o de todo el código fuente del sistema de software. En algunas herramientas, el usuario puede proporcionar un esqueleto del código fuente del programa, en forma de una plantilla de código fuente donde los tokens predefinidos se reemplazan con partes del código fuente del programa durante el proceso de generación de código.
La especificación de diagramas UML (si se usa para MDA) fue criticada por falta de detalles necesarios para contener la misma información que la fuente del programa. Algunos desarrolladores incluso afirman que "el Código es el diseño". [5] [6]
Existe un grave riesgo de que el código generado difiera rápidamente del modelo o que el modelo sometido a ingeniería inversa pierda su reflejo en el código o una combinación de estos dos problemas como resultado de los esfuerzos de reingeniería cíclica. [7]
Con respecto a la parte dinámica/de comportamiento de UML para funciones como el diagrama de estado, no existen equivalentes en los lenguajes de programación. Su traducción durante la generación de código dará como resultado if,switch,enumque falte una declaración de programación común (.ej.) o se malinterprete. Si se edita y se vuelve a importar, puede resultar en un modelo diferente o incompleto. [8] [9] Lo mismo ocurre con los fragmentos de código utilizados en la etapa de generación de código para la implementación de patrones y la lógica específica del usuario: entremezclados, es posible que no se puedan aplicar ingeniería inversa fácilmente. [8] [9]
También hay una falta general de herramientas avanzadas para modelado que sean comparables a las de los IDE modernos (para pruebas, depuración, navegación, etc.) para lenguajes de programación de propósito general y lenguajes de dominio específico . [9]
Quizás la forma más común de ingeniería de ida y vuelta es la sincronización entre los modelos UML ( Lenguaje de modelado unificado ) y el código fuente correspondiente y los diagramas entidad-relación en el modelado de datos y el modelado de bases de datos .
La ingeniería de ida y vuelta basada en el Lenguaje Unificado de Modelado (UML) necesita tres herramientas básicas para el desarrollo de software: [ cita necesaria ]