La ingeniería de ida y vuelta ( RTE ) 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 e incluso documentación. [1] La necesidad de ingeniería de ida y vuelta surge cuando la misma información está presente en múltiples artefactos y, por lo tanto, puede ocurrir una inconsistencia si no todos los artefactos se actualizan de manera consistente para reflejar un cambio dado. Por ejemplo, alguna pieza de información se agregó/cambió en un solo artefacto y, como resultado, se perdió en/fue inconsistente con los otros artefactos.
La ingeniería de ida y vuelta está estrechamente relacionada con las disciplinas tradicionales de ingeniería de software : ingeniería directa (creación de software a partir de especificaciones), ingeniería inversa (creación de especificaciones a partir de software existente) y reingeniería (comprensión del software existente y modificación). La ingeniería de ida y vuelta a menudo se define erróneamente como simplemente apoyar 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 los artefactos existentes que evolucionaron al mismo tiempo incrementalmente.actualizar 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 anterior.
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, es diferente de la ingeniería directa e inversa, que puede ser tanto manual (tradicionalmente) como automática (a través de la generación automática o el análisis 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 evolucionar simultáneamente los artefactos (incluso en un entorno distribuido) y, en algún momento, optar por ejecutar coincidencias para identificar incoherencias y optar por propagar algunas de ellas y reconciliar posibles conflictos.
La ingeniería de ida y vuelta admite un proceso de desarrollo iterativo. Una vez que haya sincronizado su modelo con el código revisado, aún puede elegir la mejor manera de trabajar: realice más modificaciones en el código o realice cambios en su modelo. Puede sincronizar en cualquier dirección en cualquier momento y puede repetir el ciclo tantas veces como sea necesario.
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. 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 . [2] Por lo general, los diagramas de clases UML son compatibles hasta cierto punto; sin embargo, ciertos conceptos de UML, como asociaciones y contenciónno tienen representaciones directas en muchos lenguajes de programación, lo que limita la facilidad de uso del código creado y la precisión del análisis del código (por ejemplo, es difícil reconocer la contención en el código). 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 se ayuden con anotaciones laboriosas. [3] Las partes de comportamiento de UML imponen aún más desafíos para RTE.