La reestructura de código legado puede realizarse con fines diferentes, entre los que se encuentran la migración hacia nuevas tecnologías que faciliten el mantenimiento y la reutilización del código. Los marcos orientados a objetos (frameworks) cuentan con características que, de cierta manera, limitan el reuso de su código. En este trabajo se propone un modelo formal que describe un proceso de reestructura de código legado de marcos orientados a objetos (MOO) hacia código conforme a la arquitectura modelo-vista-adaptador (MVA). Este proceso se lleva a cabo aplicando 11 métodos de reestructura, con el objetivo de separar el código de la lógica del negocio (el modelo), la cual es la parte más reusable del marco, del código que implementa la vista y del código que controla el procesamiento específico de la aplicación. Como resultado, el código legado del marco queda preparado para una migración posterior hacia servicios web.
The restructuring of legacy code can be done for different purposes, among which is the migration to new technologies that facilitate the maintenance and code reuse. The frameworks have features that, in some way, limit the reuse of your code. In this paper, we propose a formal model that describes a process of restructuring legacy code object-oriented frameworks (MOO) to code according to the architecture Model-View-Adapter (MVA). This process is carried out using 11 methods of restructuring, with the aim of separating the code from business logic (the model), which is the most reusable framework, the code that implements the view and the code that handles specific processing of the application. As a result, the legacy code of the framework is ready for a subsequent migration to Web services.
El concepto de marco orientado a objetos aportó una nueva dimensión a la noción de reuso de software, al considerar un diseño genérico, adaptable a situaciones específicas. Sin embargo, el grado de dependencia de los componentes que integran el marco ocasiona que las clases no puedan sacarse de su contexto y que el marco deba ser reutilizado como un solo componente.
Para elevar el nivel de reuso del código legado de un marco orientado a objetos, se requiere diseñar un proceso de reingeniería basado en operaciones de transformación, que considere la reestructura arquitectónica del código del marco, de manera que sea posible identificar y separar los elementos de código que pueden ser más reutilizables, sin perder la funcionalidad completa ofrecida por el marco.
En este trabajo se propone un proceso de reestructura de código de marcos orientados a objetos hacia código conforme a la arquitectura modelo-vista-adaptador (MVA), con el objetivo de separar el código de la lógica del negocio (el modelo), el cual es la parte más reusable del marco, del código que implementa la vista y del código que controla el procesamiento específico de la aplicación.
Este proceso implementa el esquema de solución que se muestra en la figura 1, donde TI representa el conjunto de operaciones de transformación aplicado al marco orientado a objetos para obtener un marco orientado a objetos con arquitectura MVA.
El esquema de solución se describe formalmente a través de un modelo construido utilizando elementos de la Teoría de Modelos.
Marcos orientados a objetosEn el contexto de este trabajo, un marco es un conjunto semi-completo de clases en colaboración que incorpora un diseño genérico, el cual puede adaptarse a una variedad de problemas específicos para producir nuevas aplicaciones hechas a la medida Santaolaya (2003).
Generalmente, el marco consiste en clases abstractas que definen la estructura y el comportamiento genérico del marco y forman la base para la aplicación desarrollada a partir del marco. Sin embargo, también puede contener clases concretas e interfaces que sean significativas, porque se utilizan para todas las aplicaciones de un dominio desarrolladas a partir del marco (Froehlich et al., 1998). En el contexto de este trabajo consideramos como elementos estructurales de los marcos, a las clases que los conforman, junto con las relaciones entre ellas. La figura 2 muestra el ejemplo de un marco orientado a objetos.
La funcionalidad de los marcos puede definirse como su capacidad para proveer funciones que responden a necesidades expresadas o implícitas cuando el marco se utiliza en condiciones específicas (ISO/IEC 9126–1).
Marcos orientados a objetos con arquitectura MVAEl patrón Model-View-Adapter (MVA) es una variante del patrón Model-View-Controller (MVC), el cual es un patrón arquitectónico que separa la lógica del negocio (el modelo) de la parte de presentación de datos (la vista) (Hintee, 2009).
En el contexto de este trabajo, un marco de aplicaciones orientado a objetos con arquitectura MVA es un marco reestructurado por medio de un conjunto de operaciones de transformación para implementar el patrón MVA, sin afectar la funcionalidad original del marco orientado a objetos. En la figura 3 se muestra un ejemplo de una arquitectura de clases conformada al patrón MVA.
Descripción del modelo formal
Se utilizó la Teoría de Modelos para describir formalmente el esquema de solución propuesto.
Definición del lenguaje de primer ordenSean P y Q sistemas. Definimos un lenguaje de primer orden ℒ adecuado a P y Q, tal que su alfabeto cuenta con los símbolos siguientes:
Variables: a, m, a1,…,an, m1,…,mn, x, y, r, x1,…,xn, yv,…,ym
Relatores: 〈R1〉1∈J, 〈R2〉2∈J, 〈R3〉3∈J, 〈R4〉4∈J, 〈R5〉5∈J, 〈R6〉6∈J e=, como relator con rango 2 que denota la relación de igualdad o equivalencia.
Descriptor: |
Signos lógicos: ¬, ¿, ¿, →, ↔, ∀, ∃
Signos relacionales: ∈, ∋, ≠
Signos binarios: U, x
Otros signos: ψ, δ, Ø, ≓
Paréntesis: (), [ ], { }, < >
En la definición del lenguaje ℒ se han incluido los signos relacionales e, ∈, ∋, ≠ que corresponden a las operaciones relacionales de la teoría de conjuntos “pertenece a”, “contiene como elemento” y “no es igual a”, respectivamente; el signo binario ∪ que corresponde a la operación binaria “unión” y el signo binario x que corresponde a la operación binaria “producto cartesiano”. También se incluyen otros signos como ψ, δ, Ø, = que corresponden a “configuración”, “funcionalidad”, “conjunto vacío” y “subsistema de”, respectivamente.
Definición de una claseSea AT el conjunto de atributos y MT el conjunto de métodos, es posible definirlos de la siguiente manera:
Se define ahora al conjunto de métodos MT:
donde:
M(m)=“m es un método”
Mi(m)=“m es un método implementado”
Ma(m)=“m es un método abstracto”
Una clase es un conjunto de atributos y métodos, que puede definirse como:
El conjunto de clases que conforman un marco se define como:
Definición de relación
Una relación es una conexión entre elementos de conjuntos. Podríamos definir una relación como:
Sin embargo, en un marco existen diferentes tipos de relaciones, por lo que es necesario entonces, definir cada una de las relaciones existentes en un marco.
Definición de las relaciones de asociaciónSea α la fórmula que define las relaciones de asociación existentes en un marco, tal que:
Definición de las relaciones de dependencia
Sea γ la fórmula que define las relaciones de dependencia existentes en un marco, tal que:
Definición de las relaciones de herencia
Sea β la fórmula que define las relaciones de herencia existentes en un marco, tal que:
Definición de las relaciones de agregación
Sea o la fórmula que define las relaciones de agregación existentes en un marco, tal que:
Definición de las relaciones de composición
Sea ρ la fórmula que define las relaciones de composición existentes en un marco, tal que:
Definición de las relaciones de implementación
Sea η la fórmula que define las relaciones de implementación, existentes en un marco, tal que:
Modelo del marco orientado a objetos
Sea P un sistema relacional, tal que
La configuración (ψP) representa las combinaciones específicas de clases y relaciones existentes en el marco orientado a objetos y se define como:
donde:
La funcionalidad (δP) está soportada por la configuración de las clases y relaciones existentes en el marco orientado a objetos y se define como
Si tenemos ciertas clases y ciertas relaciones en el marco orientado a objetos, entonces estas combinaciones específicas de clases y relaciones soportarán la funcionalidad ofrecida por el marco orientado a objetos.
Modelo del marco orientado a objetos con arquitectura MVAFormalmente un marco orientado a objetos con arquitectura MVA puede describirse como el sistema relacional Q, definido como
En la estructura del patrón arquitectónico MVA existe una conexión entre las partes del adaptador y de la vista, y también entre el adaptador y el modelo, como se muestra en la figura 3. En el contexto de este trabajo, estas conexiones se implementan como relaciones de composición y se consideran individuos destacados del sistema Q, que se describen formalmente como:
Las partes arquitectónicas del marco orientado a objetos con arquitectura MVA (el modelo, la vista y el adaptador) pueden describirse formalmente como los subsistemas M, V y A, respectivamente, de manera que:
Como en el marco orientado a objetos, la configuración (ψ Q) representa las combinaciones específicas de clases y relaciones existentes en el marco MVA y se define como:
donde:
La funcionalidad (δQ) se define como
Descripción formal del esquema de solución
Sean P y Q sistemas relacionales, definidos en las dos secciones anteriores, respectivamente. Tenemos un esquema T1 de solución si
En el cual, T1 representa un conjunto de operaciones de reestructura.
Descripción del proceso de reestructuraPara integrar el conjunto de operaciones T1, se diseñó un proceso de reestructura para transformar la arquitectura original del marco orientado a objetos hacia una arquitectura MVA. El proceso consta de ll métodos (R1, …, R11) que realizan 2 actividades principales y cada una se describe por su intención, precondiciones, procedimiento, suposiciones, poscondiciones e interacción de los métodos:
A1. Analizar el código del MOO original y etiquetar los enunciados, funciones y clases de acuerdo a las partes del patrón MVA a las que pertenecenIntención: identificar a qué parte del patrón MVA corresponde cada uno de los enunciados de código, las funciones y las clases del MOO.
Precondiciones: tener acceso al código del conjunto de clases del MOO original y haber realizado la clasificación de los enunciados del lenguaje en que está escrito el MOO.
Procedimiento:
Paso A1.1 Analizar los enunciados, las funciones y las clases del MOO en estudio, con la finalidad de:
- 1.
Identificar cada enunciado de código del MOO.
- 2.
Etiquetar los elementos de código de acuerdo a la parte del patrón a la que pertenecen.
- 3.
Generar información sobre las clases y las funciones del MOO en estudio, que apoyarán las siguientes actividades del proceso de reestructura.
Suposiciones: a partir de identificar y etiquetar los elementos de código, es posible llevar a cabo la reestructura del MOO en estudio.
Poscondiciones: los elementos del código del MOO en estudio quedan etiquetados de acuerdo a la parte del patrón MVA a la que pertenecen. Se obtiene información de tipos de clases, funciones abstractas, funciones concretas y tipos de variables.
Interacción de los métodos de reestructura: los pasos de esta actividad se llevan a cabo aplicando el método de reestructura Rl y no interacciona con otros métodos.
A2. Reestructurar el código legadoIntención: separar y reubicar los elementos de código del marco orientado a objetos original, de acuerdo a la parte del patrón que les corresponde.
Precondiciones: los enunciados de código, las funciones y las clases del marco orientado a objetos original deben estar etiquetados de acuerdo a la parte del patrón MVA a la que pertenecen. Las tablas “Tipos de clases”, “Funciones abstractas” y “Funciones concretas” deben estar creadas.
Pasos a seguir en el desarrollo de esta actividad:
Paso A2.1 Crear las tablas “Clases Modelo”, “Clases Vista”, “Clases Adaptador”, “Funciones abstractas MVA”, y “Funciones concretas MVA”.
Paso A2.2 Obtener la jerarquía de clases del marco orientado a objetos original, con la finalidad de conservarla en la parte del modelo.
Paso A2.3 Siguiendo el orden de la jerarquía de clases del marco orientado a objetos original, crear las clases del nuevo marco orientado a objetos con arquitectura MVA. Este paso implica:
- 1.
Crear las clases del modelo, la vista y el adaptador que se requieren (Paso A2.3.a, figura 4).
Paso A2.4 Si la clase en estudio es especializada en alguna parte del patrón MVA, reubicar a los miembros de la clase en la parte del patrón a la que pertenecen. Este paso implica:
- 1.
Reubicar los constructores de la clase (Paso A2.4.a, figura 4).
- 2.
Reubicar las funciones de la clase (Paso A2.4.b, figura 4).
- 3.
Reubicar los atributos de la clase (Paso A2.4.c, figura 4).
- 4.
Redefinir las llamadas a las funciones ya reubicadas que se encuentren en el código (Paso A2.4.d, figura 4).
Paso A2.5 Si la clase en estudio es No-especializada, fragmentar la clase para reubicar a sus elementos de código en la parte del patrón a la que pertenecen. Este paso implica:
- 1.
Crear los constructores de las clases MVA (Paso A2.).a, figura 4).
- 2.
Crear nuevas funciones para reubicar los enunciados de código que pertenezcan a la vista y/o al adaptador (Paso A2.).b, figura 4).
- 3.
Reubicar los atributos a los que acceden las funciones reubicadas (Paso A2.).c, figura 4).
- 4.
Redefinir las llamadas a las nuevas funciones (Paso A2.).d, figura 4).
Suposiciones: la parte del modelo mantiene la arquitectura del marco original y no tiene ningún elemento de la vista. La vista contiene solamente los elementos de código que pertenezcan a esta parte del patrón. El adaptador gestiona las interacciones entre el modelo y la vista.
Poscondiciones: se obtiene un marco orientado a objetos con arquitectura MVA.
Interacción de los métodos de reestructura: después de analizar y etiquetar el código fuente del marco orientado a objetos original, se inicia la reestructuración de la arquitectura del marco, aplicando el método R). Este método coordina el proceso de reestructuración llamando a los métodos R7, R8, R9 y R10.
La figura 4 muestra gráficamente este proceso, el cual termina cuando todas las clases del marco orientado a objetos original han sido reubicadas en la arquitectura MVA.
ResultadosPara realizar las pruebas al proceso de reestructuración para obtener un marco orientado a objetos con arquitectura MVA, se construyó un marco orientado a objetos del dominio de la geometría. De la arquitectura original de este marco, se seleccionó el caso práctico cuadrado-rectángulo cuya arquitectura se muestra en la figura 5.
El marco orientado a objetos cuadrado-rectángulo está formado por 7 clases (la clase cliente no es parte del marco orientado a objetos), que están relacionadas entre sí a través de relaciones de herencia. De acuerdo al modelo formal presentado en la sección de modelo del marco orientado a objetos, la descripción formal del marco orientado a objetos cuadrado-rectángulo se define como:
H=〈H, R3〉 donde:
H={〈aFigura, aFiguraGeometrica, aPoligonos, aCuadrilatero, aParalelogramos, cCuadrado, cRectangulo}〉}
La configuración (ψH) se describe formalmente como:
(ψH)={〈aFiguraGeometrica, aFigura, aPoligonos, aFiguraGeometrica, aCuadrilateros, aPoligonos, aParalelogramos, aCuadrilateros, cCuadrado, aParalelogramos, cRectangulo, aParalelogramos〉}
La funcionalidad del marco orientado a objetos cuadrado-rectángulo se describe formalmente como: ψH → δH.
Después de aplicar el conjunto de operaciones que integran el proceso de reestructura que se describe en la sección 5, al marco orientado a objetos cuadrado-rectángulo, se obtiene el marco orientado a objetos con arquitectura MVA (MVA cuadrado-rectángulo), como se muestra en la figura 6.
De acuerdo con el modelo formal presentado en la sección modelo del marco orientado a objetos con arquitectura MVA, el marco MVA cuadrado-rectángulo se describe formalmente como:
1=〈I, ς, ϑ, R3 donde:
I={〈aFiguraV, cCuadradoV, cRectanguloV, aFiguraC, cCuadradoC, cRectanguloC, aFiguraM, aFiguraGeometricaM, aPoligonosM, aCuadrilaterosM, aParalelogramosM, cCuadradoM, cRectanguloM〉}
ς=R5 (aFiguraC, aFiguraV)
ϑ=(aFiguraC, aFiguraM)
La configuración (ψI) se describe formalmente como:
ψI={〈aPoligonosM, aFiguraGeometricaM, cRectanguloV, aFiguraV, cCuadradoC, aFiguraC, cRectanguloC, aFiguraC, aFiguraGeometricaM, aFiguraM, cCuadradoV, aFiguraV, aCuadrilaterosM, aPoligonosM, aParalelogramosM, aCuadrilaterosM, cCuadradoM, aParalelogramosM, cRectanguloM, aParalelogramosM〉}
Una de las características que se debe cumplir para que un proceso de reestructura se considere exitoso, es que no se pierda la funcionalidad original ofrecida por el marco orientado a objetos. En la descripción formal del esquema de solución, que se presenta en la sección de descripción formal del esquema de solución, esta característica se establece en la restricción:
Dos conjuntos son iguales sí y sólo sí tienen los mismos elementos (Hintee, 2009). Al analizar los conjuntos ψH y ψl observamos que se cumple (ψH≠ψl) debido a que la estructura arquitectónica de los marcos es diferente.
La expresión (δH≠ψ l) establece que la funcionalidad de ambos marcos debe ser equivalente. Para verificar que esta condición se cumple se construyó una aplicación cliente con solicitudes de servicio similares para cada uno de los marcos. En las figura 7 se muestra el código de estas aplicaciones.
Los resultados obtenidos al ejecutar las aplicaciones cliente se presentan en las figuras 8 y 9.
El resultado de la ejecución de las aplicaciones Cliente permite observar que existe una equivalencia funcional entre ambos marcos. La restricción (δH≠δ l), se cumple para los casos prácticos presentados.
Trabajos relacionadosLa migración de software legado hacia nuevas plataformas tecnológicas es una de las propuestas de solución más utilizadas para aumentar el nivel de reuso y el mantenimiento de este tipo de código.
Sin embargo, los trabajos que se relacionan más cercanamente con el trabajo que se presenta en este documento son aquéllos que implementan un proceso de reingeniería basado en la reestructuración arquitectónica del código legado hacia una arquitectura de capas (MVC o MVA), como una de las fases o etapas del proceso de migración. Estos trabajos consideran la separación del código de la lógica del negocio (el modelo, donde es posible encontrar más funcionalidades que pueden ser reutilizables) del código de la lógica de presentación (la vista).
En el trabajo que se describe en (Matos y Heckel, 2009), los autores presentan una metodología que se enfoca en el análisis del código fuente para migrar sistemas legados hacia arquitecturas orientadas a servicios. La metodología propuesta transforma la arquitectura del software legado hacia una arquitectura de tres capas que separa la lógica de la aplicación, los datos y la interfaz de usuario; y posteriormente, realiza una descomposición funcional que permite obtener componentes candidatos a servicios web.
El trabajo que se describe en las secciones anteriores, también se enfoca en el análisis del código fuente para realizar la transformación arquitectónica de un marco orientado a objetos hacia una arquitectura de tres capas, aunque difiere del trabajo que se describe en (Matos y Heckel, 2009) en el modelo arquitectónico obtenido, la metodología y las técnicas empleadas para realizar el proceso de reestructuración.
En (Hunold et al., 2008), los autores presentan un conjunto de herramientas de ingeniería que dan soporte a un proceso incremental de transformación arquitectónica. Este proceso separa el software legado original en varios componentes independientes y reemplazables, que facilitan la migración del código legado hacia nuevas plataformas.
El proceso de transformación arquitectónica que se describe en Hunold et al. (2008) coincide con el proceso de reestructuración que se describe en este trabajo, al considerar el análisis y la categorización del código fuente legado como la base del proceso de transformación. Las diferencias entre ambos trabajos se encuentran en el modelo arquitectónico obtenido, la metodología y las técnicas empleadas para llevar a cabo la reestructuración.
En Pahl y Barret (2004), los autores describen un conjunto de requerimientos básicos para el diseño y la implementación de un proceso de reingeniería de sistemas legados distribuidos y/o basados en el Web, hacia arquitecturas orientadas a servicios. Entre estos requerimientos, los autores plantean la reestructuración arquitectónica del sistema legado hacia una arquitectura de 3 capas (implementada de acuerdo al patrón MVC), como una de las fases que se deben considerar en el diseño del proceso de reingeniería. Este planteamiento concuerda con el enfoque del proceso de reestructuración que se describe en este documento.
Finalmente, en el trabajo que se presenta en Ping et al. (2004) los autores describen un marco de reingeniería, cuyo objetivo es transformar la arquitectura de aplicaciones Web legadas hacia una arquitectura basada en el patrón MVC.
Concretamente, el proceso de reingeniería propuesto por los autores consiste en la implementación de 3 fases o etapas, en las cuales se analiza el código de la aplicación Web legada para separar los elementos que pertenecen al modelo (accesos y consultas a la base de datos), a la vista (elementos de código escrito en HTML y páginas JSP) y el control (archivos HTML, páginas JSP generadas y objetos Java Beans). La similitud con el trabajo que se describe en este documento se observa en la realización del análisis del código legado como una actividad básica del proceso de reingeniería; así como en la obtención de una nueva arquitectura organizada en los componentes del patrón MVC.
ConclusionesEn la literatura especializada se han presentado trabajos que demuestran que la transformación arquitectónica del código legado hacia una arquitectura de capas permite separar la lógica de presentación, de la lógica del negocio y puede considerarse como una estrategia que facilita la transición del código legado hacia nuevas plataformas tecnológicas.
El proceso de reestructuración que se describió en este documento presenta las siguientes ventajas:
- •
Permite desacoplar los elementos del marco orientado a objetos sin perder la funcionalidad original.
- •
Al finalizar el proceso de reestructuración se obtiene un marco orientado a objetos con arquitectura MVA completamente funcional.
- •
El código del marco queda ordenado y preparado para migrarlo hacia nuevas plataformas tecnológicas o facilitar su mantenimiento.
Un punto importante que se debe considerar al aplicar el proceso de reestructuración propuesto es que existen enunciados del código fuente del marco orientado a objetos que no son fáciles de clasificar, de acuerdo con la parte arquitectónica del patrón MVA a la que corresponden. Tal es el caso de los enunciados de decisión, los enunciados repetitivos, los enunciados de asignación, que pueden utilizarse en las diferentes partes arquitectónicas del patrón MVA y cuya clasificación requiere un análisis más profundo que la simple identificación.
Debido a que el procedimiento de identificación y clasificación de enunciados es la base del análisis y reestructura del código, esta fase del proceso requiere la participación de un experto en el dominio y en el lenguaje.
Sin embargo, los resultados obtenidos al aplicar el proceso de reestructuración nos permiten concluir que representa una estrategia útil que facilita la migración de marcos orientados a objetos hacia nuevas plataformas tecnológicas.
Actualmente, se continúa trabajando en el diseño e implementación de una herramienta de ingeniería que automatice el proceso reestructuración.
Citación estilo Chicago Santaolaya-Salgado, René, Olivia Graciela Fragoso-Díaz, Sheydi Anel Zamudio-López. Modelo formal para la reestructura de marcos orientados a objetos hacia arquitecturas modelo-vista-adaptador. Ingeniería Investigación y Tecnología, XV, 02 (2014): 187–198.
Citación estilo ISO 690 Santaolaya-Salgado R., Fragoso-Díaz O.G., Zamudio-López S.A. Modelo formal para la reestructura de marcos orientados a objetos hacia arquitecturas modelo-vista-adaptador. Ingeniería Investigación y Tecnología, volumen XV (número 2), abril-junio 2014: 187–198.
Es profesor investigador en el área de ingeniería de Software, del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). Obtuvo el grado de doctor en ciencias de la computación, por el Centro de Investigación en Computación del Instituto Politécnico Nacional y es miembro del Sistema Nacional de Investigadores. Su área de interés es la ingeniería de Software, específicamente en ambientes integrados para el desarrollo de sistemas, programación visual, reusabilidad del Software y servicios Web.
Es profesora investigadora en el área de ingeniería de Software, del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). Obtuvo el grado de doctor en ciencias de la computación, por el Centro Nacional de Investigación y Desarrollo Tecnológico. Tiene el grado de maestría en ciencias computacionales por el Instituto de Ciencia y Tecnología de la Universidad de Manchester (UMIST-UK). Su área de interés es la ingeniería de Software, específicamente, reingeniería, reusabilidad de Software y servicios Web.
Es profesora del Sistema Nacional de Institutos Tecnológicos, en el Instituto Tecnológico de Nuevo León. Obtuvo el grado de maestría en ciencias computacionales por el Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) y actualmente está inscrita en el programa doctoral en ciencias de la computación que imparte el CENIDET. Su área de interés es la ingeniería de Software, específicamente el análisis y diseño de metodologías de reuso de software, patrones de diseño y desarrollo de proyectos de Software.