Hispanopedia WikiLa ingeniería de ida y vuelta ( RTE , por sus siglas en inglés) en el contexto de la arquitectura dirigida por 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. [ 1 ] La necesidad de la ingeniería de ida y vuelta surge cuando la misma información está presente en múltiples artefactos y cuando puede surgir una inconsistencia si algunos de ellos se actualizan. Por ejemplo, se agregó o modificó información en un solo artefacto (código fuente) y, como resultado, dejó de estar presente o se volvió inconsistente con los demás artefactos (en los modelos).
Descripción general
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 su modificación). A menudo se define erróneamente la ingeniería de ida y vuelta como simplemente compatible con la ingeniería directa e inversa. De hecho, la característica clave que la distingue de la ingeniería directa e inversa es la capacidad de sincronizar artefactos existentes que evolucionaron simultáneamente , actualizando incrementalmente cada artefacto para reflejar los cambios realizados en los demás. Además, la ingeniería directa puede considerarse un caso especial de ingeniería de ida y vuelta en el que solo está presente la especificación, y la ingeniería inversa puede considerarse un caso especial de ingeniería de ida y vuelta en el que solo está presente el software. Muchas actividades de reingeniería también pueden entenderse como ingeniería de ida y vuelta cuando el software se actualiza para reflejar los cambios realizados en la especificación previamente analizada mediante ingeniería inversa.
Tipos
Varios libros describen dos tipos de RTE: [ 2 ] : 459
- RTE parcial o unidireccional : los cambios realizados en una representación de nivel superior de un código y un modelo se reflejan en el nivel inferior, pero no al revés; esto último podría permitirse, pero con limitaciones que podrían no afectar a las abstracciones de nivel superior.
- RTE completo o bidireccional : independientemente de los cambios, tanto el código de nivel superior como las representaciones del modelo de nivel inferior se sincronizan si alguno de ellos se modifica.
Sincronización automática
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 este sentido, se diferencia de la ingeniería directa e inversa, que pueden ser tanto manuales (tradicionalmente) como automáticas (mediante 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 ingeniería de ida y vuelta instantánea, todos los artefactos relacionados se actualizan inmediatamente después de cada cambio realizado en uno de ellos. En la ingeniería de ida y vuelta bajo demanda, los autores de los artefactos pueden actualizarlos simultáneamente (incluso en un entorno distribuido) y, en algún momento, optar por ejecutar una comparación para identificar inconsistencias, propagar algunas de ellas y resolver posibles conflictos.
Enfoque iterativo
La ingeniería de ida y vuelta puede implicar un proceso de desarrollo iterativo. Una vez que hayas sincronizado tu modelo con el código revisado, aún puedes elegir la mejor manera de trabajar: realizar más modificaciones al código o hacer cambios en tu modelo. Puedes sincronizar en cualquier dirección en cualquier momento y repetir el ciclo tantas veces como sea necesario.
Software
Muchas herramientas comerciales y prototipos de investigación admiten esta forma de RTE; un libro de 2007 enumera Rational Rose , Together , ESS-Model , BlueJ y Fujaba entre las que son capaces, y se dice que Fujaba también es capaz de identificar patrones de diseño . [ 3 ]
Limitaciones
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 dejando anotaciones laboriosas en el código fuente. [ 4 ] Las partes de comportamiento de UML plantean aún más desafíos para RTE.
Por lo general, los diagramas de clases UML cuentan con cierto grado de soporte; sin embargo, algunos conceptos UML, como las asociaciones y la contención, no tienen representaciones directas en muchos lenguajes de programación, lo que limita la usabilidad del código creado y la precisión del análisis/ingeniería inversa del código (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 los frameworks, donde un modelo que describe el uso de la API de un framework por parte de una aplicación se sincroniza con el código de dicha aplicación. En este entorno, la API prescribe todas las formas correctas en que el framework puede usarse 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 destacadas de ingeniería de ida y vuelta en esta categoría son los lenguajes de modelado específicos de frameworks 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 dirigida por modelos (MDA) 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 , se han creado algunas implementaciones del estándar. (Es necesario presentar experiencias prácticas con MDA en relación con RTE).
Controversias
Controversia sobre la generación de código
La generación de código (ingeniería directa) a partir de modelos implica que el usuario modela de forma abstracta las soluciones, representadas por datos del modelo, y que una herramienta automatizada genera, a partir de estos modelos, partes o la totalidad del 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 plantilla, donde los tokens predefinidos se reemplazan con partes del código fuente durante el proceso de generación.
La especificación de diagramas UML (si se usa 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 ]
Desventajas
Existe un riesgo grave de que el código generado difiera rápidamente del modelo o de que el modelo de ingeniería inversa pierda su reflejo en el código, o una combinación de ambos problemas como resultado de los esfuerzos de reingeniería cíclicos. [ 7 ]
En cuanto a la parte conductual/dinámica de UML para características como el diagrama de estados, no existen equivalentes en los lenguajes de programación. Su traducción durante la generación de código puede provocar que sentencias de programación comunes (por ejemplo, if,switch,enum) falten o se malinterpreten. Si se editan y se vuelven a importar, pueden dar como resultado 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: mezclados, pueden ser difíciles de reconstruir. [ 8 ] [ 9 ]
También existe una falta general de herramientas avanzadas para el 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 ]
Ejemplos en ingeniería de software
Quizás la forma más común de ingeniería de ida y vuelta sea la sincronización entre los modelos UML ( Lenguaje Unificado de Modelado ) 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:
- Editor de código fuente;
- Editor UML para atributos y métodos;
- Visualización de la estructura UML
Referencias
- ↑ Gentle, Anne (2012). Conversación y comunidad: La web social para la documentación (2.ª ed.). XML Press. ISBN 978-1937434106.
- ↑ Sobh, Tarek M. (2008). Avances en ciencias e ingeniería informática y de la información . Conferencia Internacional sobre Sistemas, Ciencias de la Computación e Ingeniería de Software. Nueva York: Springer. ISBN 978-1-4020-8741-7.
- ↑ Stephan Diehl (2007). Visualización de software: Visualizando la estructura, el comportamiento y la evolución del software . Springer Science & Business Media. pág. 63. ISBN 978-3-540-46505-8.
- ↑ Andrew Filev; Tony Loton; Kevin McNeish; Ben Schoellmann; John Slater; Chaur G. Wu (2005). Professional UML Using Visual Studio .Net . John Wiley & Sons. pág. 181. ISBN 978-0-7645-5875-7.
- ↑ http://www.developerdotstar.com/mag/articles/reeves_design_main.html por Jack W. Reeves
- ↑ Reeves, Jack W. (1992). "¿Qué es la ingeniería de software?" . www.bleading-edge.com . C++ Journal . Recuperado el 25 de julio de 2023 .
- ↑ "Ayuda -" . www.modeliosoft.com . Consultado el 25/07/2023 .
- 1 2 Siegl, Daniel. "Por qué la ingeniería de ida y vuelta no funciona | LieberLieber Modelling Expert" . Recuperado el 25 de julio de 2023 .
- 1 2 3 "8 razones por las que los enfoques basados en modelos (fracasarán)" . InfoQ . Consultado el 29 de julio de 2023 .
- Herramientas de programación
- Ingeniería inversa