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 se actualicen algunos artefactos. Por ejemplo, se agregó o modificó alguna información en un solo artefacto (código fuente) y, como resultado, se perdió o se volvió inconsistente con los otros artefactos (en los modelos).
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 (comprender el software existente y modificarlo). La ingeniería de ida y vuelta se suele definir erróneamente como un simple soporte tanto de la ingeniería directa como de 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 simultáneamente mediante la actualización incremental de cada artefacto para reflejar los cambios realizados en los demás artefactos. Además, la ingeniería directa puede considerarse una instancia especial de RTE en la que solo está presente la especificación y la ingeniería inversa puede considerarse 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.
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 las inconsistencias detectadas automáticamente . En ese sentido, es diferente de la ingeniería directa e inversa, que pueden ser tanto manuales (tradicionalmente) como automáticas (a través de la generación o el análisis automáticos de los artefactos). La actualización automática puede ser instantánea o bajo demanda . En la RTE instantánea, todos los artefactos relacionados se actualizan inmediatamente después de cada cambio realizado en uno de ellos. En la 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 comparación para identificar inconsistencias y elegir propagar algunas de ellas y conciliar posibles conflictos.
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 manera de trabajar: realizar más modificaciones al código o realizar cambios en su modelo. Puede sincronizar en cualquier dirección en cualquier momento y puede repetir el ciclo tantas veces como sea necesario.
Muchas herramientas comerciales y prototipos de investigación admiten 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 sean ayudadas dejando anotaciones laboriosas en el código fuente. [4] Las partes conductuales de UML imponen aún más desafíos para RTE.
Generalmente, los diagramas de clases UML son compatibles hasta cierto punto; sin embargo, ciertos conceptos 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) de marcos de trabajo, mediante las cuales un modelo que describe el uso de una API de marco de trabajo por parte de una aplicación se sincroniza con el código de esa aplicación. En este contexto, la API prescribe todas las formas correctas en que se puede utilizar el marco de trabajo en las aplicaciones, lo que permite la 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 implementa los usos correctos de la API. Dos implementaciones de RTE destacadas en esta categoría son los lenguajes de modelado específicos de marcos de trabajo y Spring Roo (Java).
La ingeniería de ida y vuelta es fundamental para mantener la coherencia entre varios 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 gestionar las transformaciones de modelos necesarias para MDA. Hasta la fecha [ ¿cuándo? ] , se han creado algunas implementaciones del estándar. (Es necesario presentar experiencias prácticas con MDA en relación con RTE).
La generación de código (ingeniería avanzada) a partir de modelos implica que el usuario modela de manera abstracta soluciones, que están connotadas por algunos datos del modelo, y luego una herramienta automatizada deriva de los modelos partes o la totalidad del código fuente para el 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 luego 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 utiliza para MDA) fue criticada por carecer del detalle necesario para contener la misma información que se incluye en el código fuente del programa. Algunos desarrolladores incluso afirman que "el código es el diseño". [5] [6]
Existe un riesgo grave de que el código generado difiera rápidamente del modelo o que el modelo diseñado a la inversa pierda su reflejo en el código o una combinación de estos dos problemas como resultado de esfuerzos de reingeniería cíclicos. [7]
En cuanto a la parte dinámica/conductual de UML para funciones como el diagrama de estado, no hay equivalentes en los lenguajes de programación. Su traducción durante la generación de código dará como resultado que una declaración de programación común (.eg if,switch,enum) se pierda o se interprete incorrectamente. 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 para la etapa de generación de código para la implementación de patrones y la lógica específica del usuario: si se mezclan, es posible que no sea fácil aplicar ingeniería inversa. [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 específicos de dominio . [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 de modelado unificado (UML) necesita tres herramientas básicas para el desarrollo de software: [ cita requerida ]