centro nacional de investigación y desarrollo …...de componentes reusables ..... 7 2.1.3....

i

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Definición de métodos heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el

patrón de diseño Modelo-Vista-Controlador

Presentada por

Eduardo Lorenzo Núñez Ortega I.S.C. por la Universidad Autónoma de Ciudad Juárez

Como requisito para la obtención del grado de:

Maestro en Ciencias en Ciencias de la Computación

Director de tesis: Dr. René Santaolaya Salgado

Co-Director de tesis:

M.C. Olivia Graciela Fragoso Díaz

Jurado:

Dr. Máximo López Sánchez Presidente Dr. René Santaolaya Salgado Secretario M.C. Humberto Hernández García Vocal M.C. Felipe de Jesús Alaniz Quezada Vocal suplente

Cuernavaca, Morelos, México. 29 de Febrero de 2008

ii

ÍNDICE ÍNDICE DE FIGURAS .............................................................................................................. v ÍNDICE DE TABLAS ............................................................................................................ viii GLOSARIO ................................................................................................................................ x Capítulo INTRODUCCIÓN ....................................................................................................... 1 1.1. Introducción. ....................................................................................................................... 1 1.2. Objetivo. .............................................................................................................................. 2 1.3. Descripción del problema. ................................................................................................... 3 1.4. Complejidad del problema. ................................................................................................. 3 1.5. Justificación. ........................................................................................................................ 3 1.6. Beneficios. ........................................................................................................................... 4 1.7. Alcances. ............................................................................................................................. 4 1.8. Límites. ................................................................................................................................ 5 1.9. Organización de esta tesis. .................................................................................................. 5 Capítulo 2 ANTECEDENTES ................................................................................................... 6 2.1. Antecedentes. ...................................................................................................................... 6

2.1.1. Factorización de funciones hacia métodos de plantilla ........................................... 7 2.1.2. Reestructuración de código legado a partir del comportamiento para la generación de componentes reusables ................................................................................................. 7 2.1.3. Reestructuración de software escrito por procedimientos conducido por patrones de diseño composicionales ................................................................................................ 8 2.1.4. Refactorización de marcos orientados a objetos para reducir el acoplamiento aplicando el patrón de diseño Mediator ............................................................................ 8 2.1.5. Métodos de refactorización de marcos de aplicaciones orientados a objetos por la separación de interfaces .................................................................................................... 8 2.1.6. Adaptación de interfaces de marcos de aplicaciones orientados a objetos, usando el patrón de diseño Adapter ................................................................................................... 8 2.1.7 Método de refactorización de software legado para desacoplar el código funcional de la vista del código funcional de la aplicación ............................................................... 8

2.2. Estado del arte. .................................................................................................................... 9 2.2.1. Arquitecturas multi-capa. ....................................................................................... 12

2.3. Trabajos relacionados. ....................................................................................................... 13 2.3.1. Migrando sistemas en COBOL a la WEB, usando el patrón de diseño MVC ....... 14 2.3.2. Del código legado a la WEB a través del modelado de la interacción . ................. 14 2.3.3. Modelos para las metas de la ingeniería inversa del código legado ...................... 15 2.3.4. Migrando sistemas interactivos legados a servicios Web ..................................... 15 2.3.5. Migración de soporte para los servicios usando reconstrucción de la arquitectura de software ....................................................................................................................... 16 2.3.6. Transformando aplicaciones Web legadas a la arquitectura MVC ....................... 17 2.3.7. Hacia un Acercamiento Holístico para el rediseño de aplicaciones legadas para la Web con UWAT+ ........................................................................................................... 18 2.3.9. Comentarios finales. ............................................................................................... 19

Capítulo MARCO TEÓRICO .................................................................................................. 22 3.1. Reingeniería. ..................................................................................................................... 22 3.2. Software legado. ................................................................................................................ 23 3.3. Reuso del software. ........................................................................................................... 23 3.4. Patrón de diseño Modelo-Vista-Control MVC. ................................................................ 23

3.4.1. La comunicación entre la vista y el modelo. .......................................................... 24 3.4.2. La comunicación del modelo hacia la vista. .......................................................... 24

iii

3.4.3. La comunicación entre el control y el modelo. ...................................................... 25 3.4.4. Ventajas del patrón MVC. ...................................................................................... 25 3.4.5. El patrón MVC bajo un enfoque de reuso. ............................................................. 26 3.4.6. Patrones de diseño primitivos utilizados en la arquitectura del patrón MVC. ....... 26

3.4.6.1. Patrón de diseño Composite. ........................................................................... 26 3.4.6.2. El patrón de diseño Strategy. ........................................................................... 27 3.4.6.3. Patrón de diseño Factory Method. .................................................................. 28 3.4.6.4. Patrón de diseño Proxy. ................................................................................... 29 3.4.6.5. Patrón de diseño Command. ............................................................................ 30

3.5. El lenguaje de programación Java. .................................................................................... 31 3.5.1. Programación orientada a objetos ......................................................................... 32 3.5.2. Propiedades de la programación orientada a objetos en Java. ............................... 32

3.5.2.1. Abstracción de datos. ..................................................................................... 32 3.5.2.2. Encapsulamiento de datos. .............................................................................. 32 3.5.2.3. Herencia. ......................................................................................................... 33 3.5.2.4. Polimorfismo. .................................................................................................. 34

3.6. Heurísticas. ........................................................................................................................ 34 3.6.1. Métodos heurísticos. ............................................................................................... 34

3.7. MoProSoft. ........................................................................................................................ 34 3.8. Otros conceptos. ................................................................................................................ 34

3.8.1. Función especializada. ........................................................................................... 34 3.8.2. Función no-especializada. ...................................................................................... 35 3.8.3. Clase especializada. ................................................................................................ 35 3.8.4. Clases no-especializadas. ...................................................................................... 35

3.9. Comentarios finales. .......................................................................................................... 36 Capítulo ANÁLISIS DE ESCENARIOS ................................................................................. 37 4.1. Especificación de requerimientos. ..................................................................................... 38

4.1.1. Actores. .................................................................................................................. 38 4.1.2. Diagrama de casos de uso. ..................................................................................... 39

4.1.2.1. Especificación del caso de uso: analizar el código legado. ............................. 40 4.1.2.2. Especificación del caso de uso: reestructurar código legado. ......................... 40 4.1.2.3. Especificación del caso de uso: crear plantilla genérica MVC. ...................... 41 4.1.2.4. Especificación del caso de uso: reestructurar micro-arquitecturas. ................ 41 4.1.2.5. Especificación del caso de uso: reestructurar micro-arquitecturas con herencia. ...................................................................................................................................... 41 4.1.2.6. Especificación del caso de uso: reestructurar micro-arquitecturas con composición. ................................................................................................................ 60 4.1.2.7. Especificación del caso de uso: reestructurar clases. ...................................... 66 ...................................................................................................................................... 67 4.1.2.8. Especificación del caso de uso: reubicar atributo. .......................................... 68 4.1.2.9. Especificación del caso de uso: crear constructor. .......................................... 68 4.1.2.10. Especificación del caso de uso: fragmentar el main. .................................... 69 4.1.2.11. Especificación del caso de uso: reestructurar funciones. .............................. 72 4.1.2.12. Especificación del caso de uso: fragmentar función. .................................... 86 4.1.2.13. Especificación del caso de uso: crear función. .............................................. 86 4.1.2.14. Especificación del caso de uso: redefinir llamadas a funciones. ................... 87 4.1.2.15. Especificación del caso de uso: cohesionar clases. ....................................... 88 4.1.2.16. Especificación del caso de uso: subjerarquizar. ............................................ 89 4.1.2.17. Especificación del caso de uso: superjerarquizar clases. .............................. 89 4.1.2.18. Especificación del caso de uso: crear clases. ................................................ 90

iv

4.2. Comentarios finales. .......................................................................................................... 90 Capítulo 5 DESARROLLO DE MÉTODOS HEURÍSTICOS ................................................ 92 5.1. Desarrollo de los métodos heurísticos. .............................................................................. 92

5.1.1. Método heurístico H0, “Definir plantilla genérica MVC”. .................................... 93 5.1.2. Método heurístico H1, “Análisis del código legado”. ............................................ 96 5.1.3. Método heurístico H2, “Crear clases”. ................................................................... 98 5.1.4. Método heurístico H3, “Crear constructor”. ........................................................ 100 5.1.5. Método heurístico H4, “Crear función”. .............................................................. 102 5.1.6. Método heurístico H5, “Reubicar atributos”. ....................................................... 106 5.1.7. Método heurístico H:10, “Fragmentar funciones”. .............................................. 108 5.1.8. Método heurístico H:11, “Redefinir llamadas funciones”. .................................. 114

5.2. Comentarios finales. ........................................................................................................ 117 Capítulo 6) CONCLUSIONES .............................................................................................. 118 6.1. Conclusiones. .................................................................................................................. 118 6.2. Trabajos futuros. .............................................................................................................. 120 REFERENCIAS ..................................................................................................................... 122

v

ÍNDICE DE FIGURAS Figura 2.1. Antecedentes. ........................................................................................................... 7 Figura 2.2 Ciclo evolutivo de los modelo de desarrollo…...………………………………...10 Figura 2.3. Evolución de las arquitecturas en capas. ............................................................... 13 Figura 3.1. Arquitectura del patrón MVC. ............................................................................... 24 Figura 3.2. Arquitectura del patrón Composite. ....................................................................... 27 Figura 3.3. Arquitectura del patrón Strategy. ........................................................................... 28 Figura 3.4. Arquitectura del patrón Factory Method. .............................................................. 28 Figura 3.5. Arquitectura del patrón Proxy. ............................................................................... 29 Figura 3.6. Arquitectura del patrón Command. ........................................................................ 30 Figura 3.1. Pasos para ejecutar un programa en Java...………………………………………32 Figura 3.8. Clases especializadas. ............................................................................................ 35 Figura 3.9. Clase no-especializada. .......................................................................................... 36 Figura 4.1. Pasos para cumplir con el objetivo de la tesis…………………………………...39 Figura 4.2. Diagrama principal de casos de uso. ...................................................................... 39 Figura 4.3. Micro-arquitectura con herencia de interfaz. ......................................................... 42 Figura 4.4. Reestructura conforme al patrón MVC del flujo básico del caso de uso. .............. 42 Figura 4.5. Micro-arquitectura con herencia de atributos. ....................................................... 43 Figura 4.6. Arquitectura destino del escenario 2, del caso de uso reestructurar micro-arquitecturas con herencia. ....................................................................................................... 44 Figura 4.7. Micro-arquitectura con herencia de atributos inicializados en el constructor. ...... 45 Figura 4.8. Arquitectura destino del escenario 3, del caso de uso reestructurar micro-arquitecturas con herencia. ....................................................................................................... 45 Figura 4.9. Micro-arquitectura con herencia de atributos y funciones implementadas. .......... 46 Figura 4.10. Arquitectura destino del escenario 4, del caso de uso reestructurar reestructurar micro-arquitecturas con herencia. ............................................................................................ 47 Figura 4.11. Micro-arquitectura con herencia de atributos inicializados en el constructor. .... 48 Figura 4.12. Arquitectura destino del escenario 5, del caso de uso reestructurar reestructurar micro-arquitecturas con herencia. ............................................................................................ 48 Figura 4.13. Micro-arquitectura con herencia de atributos sin herencia. ................................. 49 Figura 4.14. Arquitectura destino del escenario 6, del caso de uso reestructurar reestructurar micro-arquitecturas con herencia. ............................................................................................ 50 Figura 4.15. Micro-arquitectura con herencia de atributos inicializados. ................................ 51 Figura 4.16. Arquitectura destino del escenario 7, del caso de uso reestructurar reestructurar micro-arquitecturas con herencia. ............................................................................................ 51 Figura 4.17. Micro-arquitectura con herencia de atributos inicializados en el constructor y .. 53 Figura 4.18. Arquitectura destino del escenario 8, del caso de uso reestructurar .................... 53 Figura 4.19. Micro-arquitectura con herencia de atributos inicializados en el constructor y . 54 Figura 4.20. Arquitectura destino del escenario 9, del caso de uso reestructurar micro-arquitecturas con herencia. ....................................................................................................... 54 Figura 4.21. Micro-arquitectura con herencia de atributos inicializados en el constructor y . 56 Figura 4.22.Arquitectura destino del escenario 10, del caso de uso reestructurar ................... 56 Figura 4.23. Micro-arquitectura con herencia de atributos inicializados en el constructor y .. 57 Figura 4.24. Arquitectura destino del escenario 11, del caso de uso reestructurar micro-arquitecturas ............................................................................................................................. 58 Figura 4.25. Micro-arquitectura con herencia de atributos inicializados en el constructor y . 59 Figura 4.26. Arquitectura destino del escenario 12, del caso de uso reestructurar micro-arquitecturas ............................................................................................................................. 59 Figura 4.27. Clase especializada agregando por composición a otra clase, ............................. 60

vi

Figura 4.28. Arquitectura destino de dos clases agregadas por composición que ................... 61 Figura 4.29. Clase especializada agregando por composición a otra clase, las clases son ...... 61 Figura 4.30. Arquitectura destino de dos clases agregadas por composición ......................... 62 Figura 4.31. Clase especializada agregando por composición a una clase no-especializada. .. 63 Figura 4.32. Arquitectura destino conforme al patrón MVC de una clase especializada que agrega por composición a una clase no-especializada. ............................................................ 63 Figura 4.33. Clase no-especializada agregando por composición a una clase no-especializada. .................................................................................................................................................. 64 Figura 4.34. Arquitectura destino conforme al patrón MVC del caso donde una clase no-especializada ............................................................................................................................. 64 Figura 4.35. Clase no-especializada agregando por composición a una clase no-especializada. .................................................................................................................................................. 65 Figura 4.36. Arquitectura destino conforme al patrón MVC de una clase no-especializada agregando por composición a otra no-especializada. .............................................................. 65 Figura 4.37. Clase especializada en la vista. ............................................................................ 66 Figura 4.38. Arquitectura destino conforme al patrón MVC de una clase especializada. ....... 67 Figura 4.39. Clase no-especializada. ........................................................................................ 67 Figura 4.40. Arquitectura destino conforme al patrón MVC de una clase no-especializada. .. 68 Figura 4.41. Función main que incluye estatutos especializados. ............................................ 70 Figura 4.42. Arquitectura objetivo la función main especializada. .......................................... 70 Figura 4.43. Función main que incluye estatutos de código mezclados. ................................. 71 Figura 4.44. Arquitectura objetivo la función main no-especializada. .................................... 71 Figura 4.45. Función especializada en la vista ........................................................................ 72 Figura 4.46. Arquitectura objetivo conforme al patrón MVC que incluye funciones especializadas reubicadas ......................................................................................................... 73 Figura 4.47. Función especializada con peticiones de servicio a otra función especializada ambas pertenecen a un mismo alcance de clase y a una misma parte del patrón MVC. ......... 73 Figura 4.48. Arquitectura objetivo conforme al patrón MVC obtenida a partir de la reubicación de dos funciones especializadas en la misma parte del patrón MVC. .................. 74 Figura 4.49. Función especializada con peticiones de servicio a otra función especializada, ambas pertenecen a un mismo alcance de clase pero a diferente parte del patrón MVC. ........ 75 Figura 4.50. Arquitectura destino conforme al patrón MVC de dos funciones especializadas en diferente parte del patrón MVC. .......................................................................................... 75 Figura 4.51. Función especializada solicitando servicios a una función no-especializada, ..... 76 Figura 4.52. Arquitectura destino conforme al patrón MVC de una función no-especializada y una especializada. ..................................................................................................................... 76 Figura 4.53. Función especializada solicitando servicios a una función no-especializada, ..... 77 Figura 4.54. Arquitectura destino de dos funciones especializadas en la misma parte del patrón MVC que se encontraban en diferente alcance. ............................................................ 77 Figura 4.55. Función especializada solicitando servicios a una función no-especializada ...... 78 Figura 4.56. Arquitectura destino conforme al patrón MVC de una función especializada que invoca a una función no-especializada. .................................................................................... 78 Figura 4.57. Función especializada solicitando servicios a una función no-especializada ...... 79 Figura 4.58. Función especializada invocando peticiones de servicio a funciones especializadas, generadas a partir de la fragmentación de una función no-especializada. ...... 79 Figura 4.59. Función no-especializada. .................................................................................... 80 Figura 4.60. Arquitectura conforme al patrón MVC, generada a partir de la fragmentación de una función no-especializada. .................................................................................................. 80 Figura 4.61. Función no-especializada invocando a una función especializada. ..................... 81

vii

Figura 4.62. Arquitectura destino conforme al patrón MVC de una función que agrega por composición a una función especializada. ............................................................................... 81 Figura 4.63. Función no-especializada invocando a otra función no-especializada. ............... 82 Figura 4.64. Arquitectura destino conforme al patrón MVC de una función no-especializada que invoca a una función no-especializada. ............................................................................. 83 Figura 4.65. Función no-especializada invocando a una función especializada a través de .... 84 Figura 4.66. Arquitectura destino conforme al patrón MVC de una función no-especializada que agrega por composición a una función especializada. ....................................................... 84 Figura 4.67. Función no-especializada invocando a una función no-especializada ................. 85 Figura 4.68. Arquitectura conforme al patrón MVC de una función agregando por composición ............................................................................................................................. 85 Figura 5.1. Pasos para cumplir con el objetivo de la tesis ………………………………... 94 Figura 5.2. Autómata para crear las clases de la plantilla genérica .…………………95 Figura 5.3. Resultado de la implementación del método heurístico de crear plantilla genérica…………………………………………………………………………...…………. 97 Figura 5.4. Autómata para analizar el código legado .……………………………….. 98 Figura 5.5. Resultado del método heurístico “Análisis del código legado ......…………….. 99 Figura 5.6. Autómata para crear clases, clases abstractas e interfaces ………………...100 Figura 5.7. Clases generadas con el método heurístico “Crear clases” ……………….. 101 Figura 5.8. Autómata para crear constructores ………………………………………..102 Figura 5.9. Creación de constructores ………………………………………………. 103 Figura 5.10. Autómata para crear funciones ………………………………………..104 Figura 5.11. Funciones generadas a partir del método “Crear función” ...…………….. 108 Figura 5.12. Autómata de reubicar atributos ………………………………………..108 Figura 5.13.Una clase con un atributo declarado e inicializado en un constructor ………...110 Figura 5.14. Atributos reubicados en las clases concretas correspondientes ………...110 Figura 5.15. Autómata para fragmentar funciones ………………………………………..111 Figura 5.16. Función no-especializada invocando una función especializada ………...115 Figura 5.17. Función no-especializada fragmentada ………………………………..115 Figura 5.18. Autómata para redefinir llamadas ………………………………………..116 Figura 5.19. Función que incluye llamadas a otras funciones ………………………..118 Figura 5.20. Ejemplo de una función que incluye llamadas que deben ser redefinidas…….119

viii

ÍNDICE DE TABLAS Tabla 2.1. Tabla comparativa de los trabajos relacionados. ..................................................... 20 Tabla 3.1. Ventajas principales del patrón MVC. .................................................................... 25 Tabla 3.2. Patrones que conforman la arquitectura MVC. ...................................................... 26 Tabla 3.3. Categorías de acceso. .............................................................................................. 33 Tabla 4.1. Actores implicados en el desarrollo de los métodos heurísticos. ............................ 38 Tabla 4.2. Descripción del caso de uso analizar el código legado. .......................................... 40 Tabla 4.3. Descripción del caso de uso reestructurar código legado. ...................................... 40 Tabla 4.4. Descripción del caso de uso crear plantilla genérica MVC. ................................... 41 Tabla 4.5. Descripción del caso de uso reestructurar micro-arquitecturas. .............................. 41 Tabla 4.6. Descripción del caso de uso reestructurar micro-arquitecturas con herencia. ........ 41 Tabla 4.7. Escenario 1 ............................................................................................................. 42 Tabla 4.8. Escenario 2 ............................................................................................................. 43 Tabla 4.9. Combinaciones del control de acceso ..................................................................... 44 Tabla 4.10. Escenario 3 . .......................................................................................................... 44 Tabla 4.11. Escenario 4 . .......................................................................................................... 45 Tabla 4.12. Escenario 5 ........................................................................................................... 47 Tabla 4.13. Escenario 6 . .......................................................................................................... 48 Tabla 4.14. Escenario 7 . .......................................................................................................... 50 Tabla 4.15. Escenario 8 . .......................................................................................................... 52 Tabla 4.16. Escenario 9 . .......................................................................................................... 53 Tabla 4.17. Escenario 10 . ........................................................................................................ 55 Tabla 4.18. Escenario 11 ......................................................................................................... 56 Tabla 4.19. Escenario 12 ......................................................................................................... 58 Tabla 4.20. Descripción del caso de uso reestructurar micro-arquitecturas con composición. 60 Tabla 4.21. Escenario 1 . .......................................................................................................... 60 Tabla 4.22. Escenario 2 . .......................................................................................................... 61 Tabla 4.23. Escenario 3 . .......................................................................................................... 62 Tabla 4.24. Escenario 4 . .......................................................................................................... 63 Tabla 4.25. Escenario 5 ........................................................................................................... 65 Tabla 4.26. Descripción del caso de uso reestructurar clases. ................................................. 66 Tabla 4.27. Escenario 1 . .......................................................................................................... 66 Tabla 4.28. Escenario 2 ........................................................................................................... 67 Tabla 4.29. Descripción del caso de uso reubicar atributo. ...................................................... 68 Tabla 4.30. Descripción del caso de uso crear constructor. ..................................................... 68 Tabla 4.31. Descripción del caso de uso fragmentar el main. .................................................. 69 Tabla 4.32. Escenario 1 ........................................................................................................... 69 Tabla 4.33. Escenario 2 ........................................................................................................... 70 Tabla 4.34. Descripción del caso de uso reestructurar funciones. ........................................... 72 Tabla 4.35. Escenario 1 ........................................................................................................... 72 Tabla 4.36. Escenario 2 . .......................................................................................................... 73 Tabla 4.37. Escenario 3 . .......................................................................................................... 74 Tabla 4.38. Escenario 4 . .......................................................................................................... 75 Tabla 4.39. Escenario 5 . .......................................................................................................... 77 Tabla 4.40. Escenario 6 ........................................................................................................... 78 Tabla 4.41. Escenario 7 . .......................................................................................................... 79 Tabla 4.42. Escenario 8 . .......................................................................................................... 80 Tabla 4.43. Escenario 9 . .......................................................................................................... 80 Tabla 4.44. Escenario 10 . ........................................................................................................ 82

ix

Tabla 4.45. Escenario 11 ......................................................................................................... 83 Tabla 4.46. Escenario 12 ......................................................................................................... 84 Tabla 4.47. Descripción del caso de uso fragmentar función. ................................................. 86 Tabla 4.48. Descripción del caso de uso crear función. ........................................................... 86 Tabla 4.49. Descripción del caso de uso redefinir llamadas a funciones. ................................ 87 Tabla 4.50. Descripción del caso de uso cohesionar clases. .................................................... 88 Tabla 4.51. Descripción del caso de uso subjerarquizar. ......................................................... 89 Tabla 4.52. Descripción del caso de uso superjerarquizar. ...................................................... 89 Tabla 4.53. Descripción del caso de uso crear clases. .............................................................. 90

x

GLOSARIO

ALCANCE Conjunto de estatutos de código declarados en la misma unidad del programa. En el contexto de este análisis, dos funciones están en un mismo alcance cuando ambas están declaradas en la misma clase de objetos. Dos funciones están ubicadas en diferentes alcances, cuándo fueron declaradas en diferentes clases de objetos.

API Application Programming Interface. Interfaz de Programación de Aplicaciones.

CASO DE USO Es una descripción narrativa textual de la secuencia de eventos y acciones que ocurren cuando un usuario parte o divide en un diálogo con un sistema durante un proceso significativo.

CENIDET Centro Nacional de Investigación y Desarrollo Tecnológico.

CLASE Es un grupo de objetos que comparten las mismas propiedades y relaciones.

CLASE ABSTRACTA Es una plantilla de otras clases. Generalmente es utilizada como raíz de una jerarquía de clases.

CLASE BASE Es una clase que deriva datos y métodos a otras clases que se encuentran implementadas en un nivel inferior, de la jerarquía de clases.

CLASE CONCRETA Es una clase que específica el comportamiento de la clase padre o extiende a la clase padre.

CLIENTE Es el objeto o clase que utiliza los servicios de otro objeto o clase.

CORBA Common Object Request Broker Architecture. Arquitectura común de trámite a peticiones a objetos.

DATO FRIENDLY

Es un dato delimitado por el especificador de acceso friendly, lo que significa que son accesibles por todos los objetos dentro del mismo paquete, pero no por los externos al paquete.

DATO PRIVADO Es un dato delimitado por el especificador de acceso private, el cual sólo puede ser accedido por las funciones miembro de la clase a la que ambos pertenecen.

DATO PROTEGIDO Es un dato delimitado por el especificador de acceso

xi

protected, el cual es accedido por las funciones miembro de la clase a la que ambos pertenecen y además por las funciones del siguiente nivel en la jerarquía de herencia.

DATO PÚBLICO

Es un dato delimitado por el especificador de acceso public. Un dato público es aquel que puede ser llamado desde otras clases.

DCOM Distributed Component Object Model. Modelo de objetos de componentes distribuidos.

FUNCIÓN Es una implementación de las operaciones relevantes a una clase de objetos.

HERENCIA Es una de las 4 propiedades de la programación orientada a objetos. Es definida como un mecanismo por el cual nuevas clases se definen a partir de otras existentes.

HTML Hyper Text Markup Language, lenguaje de marcado de hipertexto. Es un lenguaje de marcas diseñado para estructurar textos y presentarlos en pantalla como hipertexto (formato estándar de las páginas Web).

INTERFAZ La interfaz es una clase abstracta que no contiene ningún detalle de implementación, sólo una colección de declaraciones de métodos.

JAVA BEANS Son componentes de software reutilizables desarrollados en lenguaje Java.

JEE Java Enterprise Edition, edición empresarial de Java.

JSP Java Server Pages, servidor de páginas de Java. Es la tecnología para generar páginas web de forma dinámica en el servidor y mostradas en la parte del cliente. Concepto desarrollado por Sun Microsystems, basado en scripts que utilizan una variante del lenguaje java.

MAIN Es la función principal de cualquier programa encargada de controlar el flujo y solicitar al programa los recursos necesarios. Ejecuta métodos necesarios para completar la funcionalidad de la aplicación.

MOPROSOFT Modelo de procesos para la industria de software en México que fomenta la estandarización de las mejores prácticas en gestión e ingeniería de software. Tiene como objetivo mejorar la capacidad de los procesos de ingeniería de las empresas.

OBJETO Es una colección de datos y operaciones que actúan sobre

xii

los datos de una clase.

OO Object Oriented. Orientado a objetos.

OMG Object Managment Group. Grupo de gestión de objetos. Es una organización dedicada al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA.

PATRÓN DE DISEÑO

Es una micro-arquitectura que presenta una solución genérica a un problema recurrente. Un patrón de diseño sirve como una plantilla o guía para el desarrollo de aplicaciones.

REUSABILIDAD Es la capacidad de utilizar software o módulos de software bien diseñados y comprobados en diferentes aplicaciones, evitando desarrollar nuevo código.

RMI Remote Method Invocation. Invocación remota de métodos.

SERVLETS Son objetos que se ejecutan dentro del contexto de un servidor de aplicaciones y extienden su funcionalidad. Son diseñados especialmente para ofrecer contenido dinámico desde un servidor Web.

SOA Service Oriented Architecture. Arquitectura orientada a servicios.

SR2 Sistema de reingeniería para reuso que incorpora tecnologías útiles para los procesos de reestructura y refactorización para el control de la evolución y aumento de la vida útil del software.

VARIABLE Es un espacio de memoria reservado para almacenar valores generados durante la ejecución de un programa.

CAPÍTULO 1 INTRODUCCIÓN

1

Capítulo 1) INTRODUCCIÓN La reutilización de sistemas legados ha sido uno de los principales objetivos de la ingeniería de software, esto se debe en gran parte a que los desarrolladores de software pueden aprovechar la experiencia implícita en la lógica de negocio de los sistemas legados y facilitar el desarrollo de nuevas aplicaciones cada vez que los clientes requieran un sistema de software.

En este capítulo se define una breve introducción al tema de tesis, además de las razones que motivaron el llevar a cabo la investigación y por último se lista el contenido de los capítulos siguientes.

1.1. Introducción. Con el crecimiento exponencial de la Internet y de las arquitecturas de sistemas distribuidos de multicapas, ha surgido una demanda para desarrollar aplicaciones basadas en Web y para desarrollar componentes de diferentes dominios.

Se ha puesto mucho interés en analizar la funcionalidad de las aplicaciones legadas y los marcos de aplicaciones legados, para determinar la factibilidad de que sean reutilizados para cubrir la necesidad de desarrollo de aplicaciones distribuidas.

Un sistema legado es una aplicación funcional que ha sido utilizada durante un largo tiempo para un domino particular y que puede seguir siendo utilizada en diferentes arquitecturas de software y hardware.

Por otra parte un marco de aplicaciones legado, es un conjunto semi-completo de clases abstractas con diseños reutilizables, en el que sus instancias interactúan en un dominio para lograr un fin común. Un marco de aplicaciones puede ser considerado como un esqueleto que es flexible y puede adaptarse a las necesidades concretas de los diseñadores.


2

Para la reutilización de aplicaciones y marcos legados en diferentes arquitecturas de hardware y software, se requiere que sean reestructurados a través de procedimientos bien definidos. La reestructura de software es una técnica segura que garantiza que un sistema de software conserve la funcionalidad original.

La comunidad de investigadores de la ingeniería de software, ha puesto interés en trabajar en el desarrollo de procesos y metodologías que lleven a cabo la tarea de reestructura de código legado, ya sea de manera automática, semiautomática o en otros casos con la intervención de usuarios expertos en el área.

Generalmente los procesos de reestructura del código legado son llevados a cabo a través de varias etapas, una primera etapa consiste en el análisis de código en dónde se analizan algunos aspectos como lo son la sintaxis y semántica. Otra etapa es aquella en la que se lleva a cabo la reestructura del código con base a reglas preestablecidas que definen la manera en que se debe reestructurar el código y por último, una etapa final de pruebas, donde se evalúa la funcionalidad del código después de la reestructura, para comprobar que se conserve la funcionalidad.

Muchas de las investigaciones que proponen soluciones para reestructurar código legado han sido maduradas con el tiempo, es decir, paso a paso han logrado conjuntar un proceso completo y eficiente que cumpla con la tarea de reestructura del código legado.

Algunas investigaciones en sus primeros reportes definen el objetivo, las razones que motivaron llevar a cabo la tarea de reestructura o también un primer acercamiento al proceso de reestructura, que puede consistir en una posible solución. En etapas posteriores se define el procedimiento y se desarrollan herramientas de software que lleven a cabo el proceso de reestructura de manera automática, una última etapa generalmente es la de las pruebas.

En esta tesis se plantea un primer acercamiento para reestructurar software legado orientado a objetos desarrollado en lenguaje Java y que consiste en definir un conjunto de métodos heurísticos abstractos, basados en un análisis de escenarios, para que a futuro los métodos puedan ser integrados a un proceso de reestructura automático o semi-automático para migrar aplicaciones legadas hacía arquitecturas de servicios Web.

La tarea de reestructura de aplicaciones legadas hacia servicios Web puede ser una tarea compleja, ya que la arquitectura de servicios Web se caracteriza por incluir diseños bajos en acoplamiento y altamente cohesivos, además de que éstos incluyen sólo la lógica de negocios, es decir la parte que lleva a cabo cálculos, consulta a bases de datos etc. El código de los sistemas y marcos legados generalmente presenta características que no facilitan el que éstos puedan ser adaptados como servicios Web de una manera sencilla, por lo que requieren de un tratamiento de reestructura especial.

Los métodos heurísticos definidos en esta tesis se basaron en el patrón de diseño Modelo-Vista-Controlador, que permite agrupar el código en tres partes. Los métodos tienen como propósito definir la estrategia que separe el código legado conforme al patrón MVC, para incrementar la cohesión y reducir el acoplamiento de los sistemas legados.

Conforme a lo descrito anteriormente los métodos heurísticos resultantes de esta tesis deben favorecer en la implementación de procedimientos de reestructura ya sea semi-automáticos o totalmente automáticos.

1.2. Objetivo. Identificar los posibles escenarios que se puedan presentar en arquitecturas de marcos de aplicaciones orientados a objetos o sistemas legados desarrollados en el lenguaje de programación Java y a partir de los escenarios desarrollar un conjunto de métodos heurísticos para a futuro integrarlos en procedimientos automáticos de reestructura y obtener arquitecturas conforme al patrón MVC a partir del código legado.


3

1.3. Descripción del problema. Los marcos de aplicaciones orientados a objetos legados presentan soluciones reutilizables que evitan que nuevas aplicaciones del mismo dominio tengan que desarrollarse desde cero. La reutilización de los marcos se puede llevar a cabo por el nivel de abstracción que presentan estos, ya sea para usar toda la lógica de negocio o para hacerlos extensibles. Los marcos son una buena opción para la reutilización tanto del diseño, como del código de manera centralizada y de manera propietaria, así reestructurándolos adecuadamente, es posible obtener una arquitectura de marcos más organizada y flexible. Para tener una arquitectura mejor organizada y ordenada de los marcos legados una opción óptima es reestructurarlos conforme el patrón arquitectural MVC, que permite agrupar en tres partes la arquitectura de los marcos: una parte correspondiente a la presentación de datos en pantalla, otra parte que controla la lógica de la aplicación y una última parte para el modelo de datos. Para dirigir los marcos legados hacia al patrón MVC, es necesario desarrollar un proceso de reestructura para llevar a cabo la transformación de los marcos legados conforme al patrón MVC, sin embargo es difícil desarrollar tal proceso mientras no exista un análisis que identifique los posibles escenarios a presentarse en una arquitectura de marcos legados.

1.4. Complejidad del problema. El problema de presentar un análisis que incluya la totalidad de escenarios para reestructurar los marcos legados de diferentes dominios, radica en la existencia de una gran cantidad de escenarios que están basados en la manera que tiene cada programador para desarrollar sistemas o también marcos de aplicaciones. Además, muchos sistemas legados implementan una arquitectura con funciones de distintas librerías y desarrollar un procedimiento para reestructurarlos se vuelve un problema exponencial.

1.5. Justificación. Muchas investigaciones buscan reestructurar arquitecturas de software legado hacia arquitecturas orientadas a servicios, por ejemplo hacia servicios Web. Estas investigaciones han requerido de mucho trabajo, tiempo y esfuerzo.

Para llevar a cabo la tarea de reestructura de aplicaciones legadas conforme al patrón MVC, es necesario desarrollar un estudio de los escenarios presentes en las arquitecturas legadas y establecer las bases para desarrollar un procedimiento de reestructura, que facilite el desarrollo de arquitecturas orientadas a servicios. Así mismo, es favorable proponer soluciones asociadas con el aprovechamiento y reuso de la experiencia implícita en los marcos de aplicaciones legados como lo son aplicaciones de negocios de ingeniería, de educación etc. El ahorro de tiempo y la calidad son detalles afectados en el desarrollo de software, ya que comúnmente por falta de tiempo en los proyectos de software se entregan productos mal diseñados y propensos a fallas durante su uso.

Esta investigación propone un análisis que ayudará a futuros trabajos de investigación para reutilizar la experiencia implícita de los sistemas y marcos legados mediante procedimientos de reestructura, para evitar desarrollar desde cero, aplicaciones para cada nuevo proyecto que se tenga en mente desarrollar, ya que la reutilización del código legado es una práctica que favorece principalmente la reducción del tiempo de desarrollo, ésto se debe a que es menos tardado y costoso reutilizar el software legado, que desarrollarlo desde los requerimientos del cliente.


4

El patrón MVC es tomado en cuenta en este proyecto para demostrar la factibilidad que ofrece su estructura y a futuro migrar las arquitecturas legadas hacia arquitecturas orientadas a servicios por medio de un procedimiento más refinado, ya que este patrón permite tener una arquitectura de software flexible y desacoplada, favoreciendo su reutilización y también futuras modificaciones, ya que alguna modificación en cualquiera de las tres partes de la arquitectura del patrón MVC, no afecta en las otras, debido a su condición de independencia y desacoplamiento.

1.6. Beneficios. El principal beneficio es obtener un conjunto de métodos heurísticos documentados que den solución a los escenarios identificados en una arquitectura de marcos legados.

• Los métodos heurísticos incluyen un análisis que detalla los escenarios a nivel de clase, a nivel de función y a nivel de estatuto de código, éste último servirá para identificar estatutos de código que correspondan a alguna de las partes del patrón MVC.

• Los escenarios identificados deben favorecer en el desarrollo de un conjunto de métodos heurísticos para a futuro integrarlos en procesos automáticos de reestructura.

• Los métodos heurísticos desarrollados presentan una solución genérica, la solución puede tomarse como base para reestructurar sistemas legados que estén desarrollados en otros lenguajes de programación.

• El análisis desarrollado en esta investigación propone las bases para planear una estrategia de reestructura, favoreciendo en evitar desarrollar nuevas arquitecturas para cada nueva aplicación que se tenga en mente desarrollar relativas al mismo dominio.

1.7. Alcances. Los alcances que presenta esta investigación son listados a continuación:

• Se analizaron micro-arquitecturas de sistemas que incluyen herencia y composición con sus respectivas variantes.

• Se analizaron clases y sus variantes (clases que implementan de forma mezclada funciones relacionadas con alguna de las partes del patrón MVC o también funciones no-especiliazadas).

• Se identificó a nivel de función, los escenarios donde los estatutos de código se encuentran mezclados ya sea por bloques de código o línea por línea.

• Se analizó el caso en el que la función principal o main incluye estatutos de código que sólo pertenezcan a una parte del patrón MVC o que incluyan dos o más de las partes del patrón MVC.

• El análisis incluyó casos que presentan atributos y funciones públicas, privadas, protegidas y friendly en una clase.

• Se documentaron una serie de escenarios para cada caso de estudio y a partir de estos se generaron los métodos heurísticos.

• Los métodos heurísticos sólo describen los pasos algorítmicos para manipular los componentes de la arquitectura de los sistemas legados.

• Los métodos heurísticos son definidos con el propósito de reestructurar sistemas desarrollados en lenguaje de programación Java.

• Se generó una plantilla basada en el patrón MVC, la cual deberá incluir sólo funciones especializadas relacionadas con alguna de las tres partes del patrón.


5

1.8. Límites. Los límites son definidos conforme a los detalles del planteamiento del problema y al objetivo de la tesis.

• No se implementó ni diseñó ningún proceso de reestructura, quedando como un trabajo futuro de investigación.

• La evaluación de los métodos heurísticos se dejó para efectuarse en futuros trabajos de investigación.

• El análisis de escenarios que incluyen atributos y funciones estáticos quedaron para trabajos futuros.

• Los métodos heurísticos fueron desarrollados para reestructurar sistemas funcionales, es decir no se analizaron defectos sintácticos, ni se mejoró la funcionalidad de los sistemas legados.

1.9. Organización de esta tesis. A continuación se describe un panorama de la organización de este documento de tesis.

Capítulo 2. Se presentan los antecedentes de esta tesis. Los antecedentes son trabajos de investigación llevados a cabo en el CENIDET que están relacionados con esta investigación. También se documenta el estado del arte que incluye un estudio de los diferentes modelos de programación y de las arquitecturas multicapa. Por último también se documentan los trabajos relacionados a esta tesis.

Capítulo 3. Se presentan los conceptos y temas relacionados con la presente investigación, necesarios para dar el fundamento teórico para que el lector o las personas interesadas en esta investigación se familiaricen con el tema.

Capítulo 4. Se presenta un estudio detallado de los diferentes escenarios que fueron analizados y que fueron la base para el desarrollo de los métodos heurísticos.

Capítulo 5. Se presentan cada uno de los métodos heurísticos, la descripción es de manera detallada e incluye un ejemplo de la manera en que debe funcionar el método ya implementado.

Capítulo 6. Se describen las conclusiones de la tesis, así como también las aportaciones y los trabajos futuros.

CAPÍTULO 2 ANTECEDENTES

6

Capítulo 2) ANTECEDENTES En el presente capítulo son descritos los antecedentes del trabajo de tesis, un estudio de la evolución de los diferentes modelos de desarrollo de software y el análisis de algunos trabajos relacionados.

2.1. Antecedentes. La reestructura de software legado es una de las líneas de investigación, en la que trabaja el grupo de ingeniería de software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET).

Para desarrollar los trabajos de reestructura de código se ha tomado en cuenta el sistema de reingeniería para reuso (SR2), del cual se han derivado varios trabajos enfocados a la reingeniería del software desarrollado bajo el modelo de programación por procedimientos y así reestructurarlo conforme al modelo orientado a objetos.

La figura 2.1 muestra los trabajos realizados. En la figura se muestran dos grupos, el primero agrupa los trabajos enfocados a la reestructura de código legado y el segundo agrupa a aquellos trabajos que basados en un análisis de escenarios, proponen soluciones de reestructura de código legado para integrarlos a futuros trabajos de desarrollo, la presente tesis es parte de ese grupo.


7

Figura 2.1. Antecedentes.

A continuación se describen los siete trabajos identificados en la figura 2.1. Los trabajos forman parte de los antecedentes de la tesis.

2.1.1. Factorización de funciones hacia métodos de plantilla [HERN, 03]. En la investigación se utiliza un analizador de código en lenguaje C generado con la herramienta ANTLR. Con el analizador se obtiene un conjunto de tablas de información extraída desde el código en estudio que sirven para el proceso de reingeniería. Posteriormente se realiza la reestructura del código original utilizando la información del paso previo, para este paso se aplican 7 métodos de reestructura: 1. Método de creación de clases, para construir plantillas o clases para tipos de datos

analizados. 1.1. Conversión de tipos de datos estructurados a clases de objetos, para reubicar los

métodos y los atributos que corresponden a esos datos. 1.2. Conversión de datos globales a clase de objetos.

2. Método de declaración de constructores, para declarar dentro de la definición de cada clase de objetos sus métodos constructores para inicializar estructuras de datos y variables.

3. Método de composición de clases, se aplica cuando un campo de un tipo estructurado también es de tipo estructurado.

4. Método de reubicación de funciones, consiste en reubicar las funciones con sus respectivos parámetros y tipo de la función en su clase correspondiente.

5. Método de fragmentación de funciones, consiste en fragmentar funciones para asociar cada fragmento a los datos que accede en diferentes clases.

6. Método de super-jerarquizar, para reubicar datos comunes a varias clases en una clase padre.

7. Método de fábrica de objetos, define una interfaz para la creación de objetos. El resultado final del proceso es código en lenguaje C++ con una arquitectura orientada a objetos funcionalmente equivalente al código legado original.

2.1.2. Reestructuración de código legado a partir del comportamiento para la generación de componentes reusables [BUST, 03]. Esta investigación se basa en el modelo de referencia SR2. Crea nuevas clases de objetos a partir de la fragmentación de estatutos condicionales que están integrados dentro del código organizado por procedimientos. La solución propuesta por este trabajo de investigación descompone los segmentos genéricos de código reutilizable, minimizando el alto grado de dependencias funcionales y el alto grado de complejidad ciclomática del código legado.


8

2.1.3. Reestructuración de software escrito por procedimientos conducido por patrones de diseño composicionales [MEND, 04]. Esta investigación presenta una solución para llevar a cabo la reestructura de código legado, desarrollado bajo el modelo de programación por procedimientos.

El código legado es reestructurado hacia componentes reutilizables organizados en marcos de aplicaciones orientados a objetos, incorporando en estos marcos, la estructura del patrón de diseño Composite y otros métodos de reestructura desarrollados en otras investigaciones, para facilitar la comunicación entre objetos por medio de la composición de los objetos entre las diferentes micro arquitecturas de clases, obtenidas en el proceso de reestructura del sistema SR2.

2.1.4. Refactorización de marcos orientados a objetos para reducir el acoplamiento aplicando el patrón de diseño Mediator [CARD, 04]. La investigación reduce el acoplamiento de los elementos que componen a los marcos de aplicaciones orientados a objetos, a través de la incorporación de una estructura basada en el patrón de diseño Mediator. El problema que se soluciona en la investigación es: el alto grado de acoplamiento existente entre los marcos reusables. Este problema se genera debido a la gran cantidad de interfaces o canales de comunicación entre módulos, provocando que los componentes de los marcos sean frágiles, rígidos e inmóviles. El patrón Mediator es usado para definir objetos que encapsulen el comportamiento de la interacción entre el conjunto de objetos presentes en las arquitecturas de los marcos reusables y así limitar los canales de comunicación.

2.1.5. Métodos de refactorización de marcos de aplicaciones orientados a objetos por la separación de interfaces [VALD, 04]. Esta investigación implementa un mecanismo de refactorización basado en el patrón de diseño Template Method, para corregir las dependencias de las interfaces en los marcos de aplicaciones, haciendo una separación de interfaces. El problema de las dependencias de interfaces consiste en que la arquitectura de los marcos permite a los clientes a utilizar funciones no implementadas.

En la investigación además de desarrollar una herramienta de refactorización, se presenta una métrica orientada a objetos capaz de medir del problema de dependencia de interfaces.

2.1.6. Adaptación de interfaces de marcos de aplicaciones orientados a objetos, usando el patrón de diseño Adapter [SANT, 05]. Aquí se implementa un mecanismo basado en el patrón de diseño Adapter, para adaptar temporalmente las interfaces de marcos de aplicaciones, que fueron desarrollados en el lenguaje de programación C++, para prevenir la incompatibilidad de las interfaces con futuros clientes.

2.1.7 Método de refactorización de software legado para desacoplar el código funcional de la vista del código funcional de la aplicación [AVIL, 06]. La investigación mencionada en este punto es el primer trabajo orientado a reestructurar los sistemas legados conforme al patrón MVC y es el antecedente principal de la presente tesis.


9

Identifica un conjunto parcial de escenarios, para determinar las partes interactivas del código legado escrito en lenguaje Java, desacoplando la capa de presentación (vista), de la parte funcional de la aplicación, que incluye a la lógica del negocio y el control e implementa la separación automática.

2.2. Estado del arte. La técnica de reuso del software es reconocida como una de las mejores estrategias de manejo de complejidades, asociadas con el desarrollo y mantenimiento del software. Ha tenido éxito en muchas áreas, especialmente en compiladores, sistemas operativos y en numerosas librerías de interfaces graficas de usuario (GUI`s).

Muchas librerías han sido eficientes durante mucho tiempo, sin embargo algunas tienen desventajas para ser reusadas, por ejemplo: generalmente están mezcladas con estructuras de datos, lo que indica que internamente los algoritmos y datos se encuentran altamente acoplados. El alto grado de acoplamiento provoca que no sean extensibles a los tipos de datos requeridos por el usuario.

“Los desarrolladores de software han propuesto varios modelos de desarrollo que han contribuido con el reuso de software, no sólo desarrollando bibliotecas de funciones o de clases reusables, sino también proporcionando mecanismos para que el software desarrollado sea reusado, lo cual aún no se ha conseguido debido a la carencia de varios atributos de calidad que son deseables en los componentes reusables de software” [SANT, 02]. La razón por la que surgieron los diferentes modelos de desarrollo se debe en parte a que cada uno de éstos, presentaba deficiencias en su uso y era difícil cubrir las necesidades de desarrollo con el modelo usado. Después de identificar las deficiencias se implementaban mejoras y como resultado se desarrollaron nuevos modelos, cada vez más eficientes. La figura 2.2 muestra el ciclo evolutivo de los modelos de desarrollo de software.

Los modelos de desarrollo presentados en la figura 2.2, manejan las estructuras de

datos y el código asociado de una manera organizada, mejorando en cada modelo características importantes de calidad de software para su reuso.

El primer modelo en ser implementado fue el modelo de programación por procedimientos, este modelo se caracteriza por agrupar instrucciones en procedimientos, para

Programación por Procemidmientos

Programación Modular

Tipos de datos abstractos

POO

Frameworks

SOA’s

Figura 2.2 Ciclo evolutivo de los modelo de desarrollo, gráfica adaptada de [SANT, 02].


10

realizar una tarea concreta sin ningún conocimiento del resto del programa. Los procedimientos generalmente son invocados desde otras partes del código para aislar las tareas.

Este modelo de desarrollo, tuvo como propósito facilitar a los programadores la ejecución de segmentos de código, organizados en bibliotecas de funciones sin duplicar el código en cada localidad física donde son necesarios. Sin embargo presenta algunas desventajas, por ejemplo: los programas exhiben grandes cantidades de líneas de código; los estatutos condicionales presentan profundos niveles de anidamiento y entre las funciones y los procedimientos existe un alto grado de acoplamiento.

El siguiente modelo en ser implementado fue el modelo de programación modular, que favoreció en superar las desventajas que presentaba el modelo anterior. El modelo es definido a partir de dos aportaciones. La primera aportación la presentó Edsger Dijkstra, afirmando que las piezas de código de un programa pueden desarrollarse de manera independiente. La segunda fue expuesta por David Parnas, quién introdujo el concepto de ocultación de datos [SANT, 02]. En el modelo de programación modular, los estatutos de código están auto-contenidos en módulos que son flexibles para combinarse entre sí, además de ser potencialmente reusables. La estructura de los programas modulares facilita el uso mínimo de variables globales, ya que éstas son declaradas en módulos pudiendo ser ocultadas. Hasta el modelo de programación modular habían sido cumplidas las características relacionadas con el reuso de los programas. Sin embargo, para efectos de reuso era importante contar con mecanismos de abstracción de datos que permitieran declarar componentes de operaciones válidas y aplicables a los módulos de datos y que facilitaran la creación y administración de instancias reusables de tipos definidos por el usuario. El modelo basado en tipos de datos abstractos fue desarrollado para implementar mejoras y superar las debilidades del modelo de programación modular. El modelo de tipos de datos abstractos tiene como objetivo facilitar el desarrollo de sistemas de software con componentes, los cuales tienen características bien identificadas por los desarrolladores. La especificación del modelo de tipos de datos abstractos, proporciona una descripción general de las instancias reusables de los tipos generados por el usuario, independientemente de cualquier implementación particular. Este modelo presentó un requerimiento crítico: las interfaces debían corresponder a una parte de la especificación de acceso a los datos, ya que son los únicos elementos de acceso para que la representación de los datos sea manipulada. La principal desventaja del modelo fue la carencia de facilidades genéricas tales como, la extensión a nuevas funcionalidades, el polimorfismo y el manejo de plantillas. El siguiente modelo de programación fue el orientado a objetos. El modelo está basado en la fragmentación de los programas en pequeñas unidades lógicas de código, llamadas objetos que son unidades independientes. La comunicación entre diferentes objetos se lleva a cabo a través de mensajes. Los objetos son definidos por un plan llamado clase, la cual define las características particulares del objeto, como la visibilidad para interactuar con otros objetos desde el exterior. Una propiedad importante del modelo fue la abstracción de datos que favorece en habilitar las condiciones necesarias de reuso, para los programas desarrollados bajo este modelo que requieran ser desarrollados. Otras propiedades del modelo son la herencia, el polimorfismo y el encapsulamiento de datos.

El modelo facilita el desarrollo de programas estructurados para reutilizarlos dependiendo de su dominio. Sin embargo, los procesos de desarrollo basados en este modelo, no están completamente maduros para establecer las bases para desarrollar componentes que


11

sean ensamblados y en conjunto generar una aplicación completa. Su principal desventaja radica en que únicamente se podía reusar el código a nivel de librerías, cuando la principal dificultad es la de crear buenos diseños para beneficiar el reuso.

Al modelo orientado a objetos, le sigue el modelo de desarrollo basado en componentes. Su objetivo principal es establecer las bases para desarrollar componentes de software reutilizables en entornos abiertos y distribuidos, para estar disponibles y ser utilizados ya sea por los usuarios o aplicaciones.

Un componente es definido como:“una unidad de composición de aplicaciones de software, que posee un conjunto de interfaces y un conjunto de requisitos. El componente puede ser desarrollado, adquirido, incorporado al sistema y compuesto por otros componentes de forma independiente en tiempo y espacio” [FUEN, 06].

Un componente de software reusable tiene la característica de ser extensible y abierto. Puede ser extendido dinámicamente y sus extensiones deben ser desarrolladas de forma independiente por elementos o entidades que no tengan conocimiento entre sí. Un componente de software es abierto cuando permite a otros componentes que son heterogéneos ingresar o abandonar el sistema de forma dinámica.

El modelo de programación basado en componentes tiene dos enfoques: el primero involucra a los marcos de aplicaciones basados en el modelo orientado a objetos. El segundo se relaciona con la definición de los marcos de aplicaciones de caja negra cuya propuesta favorece en exponer componentes reusables en un mercado global [FUEN, 06]. Un marco de aplicaciones orientado a objetos es un sistema compuesto por clases abstractas con diseños reutilizables y con instancias interactuando en un dominio específico. Un marco de aplicación orientado a objetos es usado como una plantilla que fácilmente puede ser adaptado a las necesidades concretas de los desarrolladores. Los marcos de aplicaciones basan su estructura en una arquitectura de software integrada por componentes y conectores. Permiten la agregación de nuevos componentes para ir generando soluciones a problemas complejos. La agregación de los componentes para formar un marco de aplicaciones se lleva a cabo a través de conectores, que son interfaces bien definidas y abstractas llamadas API`s, donde el desarrollador define la manera en que se agregan los componentes [FUEN, 06]. Su principal desventaja radicó en que el reuso sólo podría realizarse en código escrito en el mismo lenguaje, en la misma plataforma y en ambientes centralizados. Después del modelo basado en componentes los desarrolladores comenzaron a trabajar con un nuevo modelo de desarrollo, el modelo de arquitecturas orientadas a servicios SOA, cuyo objetivo principal es desarrollar aplicaciones distribuidas. SOA se define conforme a los principios del modelo basado en componentes distribuidos. En este modelo “Cada plataforma se apoya en los estándares y mecanismos definidos por su modelo de componentes base; puede ser definida una plataforma como una implementación de los mecanismos del modelo, junto con una serie de herramientas asociadas” [FUEN, 06]. Algunas de estas plataformas son ACTIVEX/OLE, Enterprise Beans, Orbix basadas en DCOM, JavaBeans, CORBA y RMI que reúnen requerimientos especiales y proveen un ambiente de integración para las arquitecturas orientadas a componentes.

Uno de los elementos de SOA, es un directorio que publica las descripciones de las aplicaciones conocidas como servicios y que están en estado funcional, para cubrir las necesidades de implementación y composición de los desarrolladores.

Una característica importante de SOA es que tiene la facilidad de ser implementada para combinar su funcionalidad con otras arquitecturas, con ésto se logra un primer paso para generar un proceso de negocio más concreto. Las arquitecturas orientadas a servicios son consideradas como una gran librería con restricciones. No pueden ser copiadas y compiladas en la computadora de un usuario. Otro de


12

los componentes de la arquitectura orientada a servicios es el protocolo de comunicación SOAP que permite a los usuarios tener acceso a servicios a través de la Internet.

2.2.1. Arquitecturas multi-capa. Conforme a la evolución de los diferentes modelos de programación, las aplicaciones desarrolladas se han ido adaptando a las diferentes arquitecturas de software y hardware existentes. Las primeras aplicaciones eran desarrolladas bajo un estilo monolítico, también eran ejecutadas en una sola computadora, toda la carga de trabajo estaba centrada en un equipo. La tarea de despliegue de las aplicaciones previamente mencionadas fue sencilla, pero al momento de facilitar su disposición en una red se convirtió en una tarea difícil ya que toda la aplicación se ejecutaba en una sola máquina [AHOK,03]. Conforme fueron evolucionando las tecnologías se comenzaron a desarrollar aplicaciones que fácilmente eran ejecutadas en dos computadoras distintas, a este tipo de aplicaciones se les llamó aplicaciones cliente-servidor o también arquitecturas de capa simple. Las arquitecturas de capa simple estaban compuestas por dos elementos: un cliente que sólo llevaba a cabo un procesamiento de información mínimo y por sus características, fue llamado thin client1, se utilizaba un monitor como terminal para acceder a una computadora central (mainframe), también llamado servidor en donde se encontraba toda la lógica de la aplicación. La comunicación entre el cliente y el servidor era de forma asíncrona [ERLT,06]. A finales de la década de los años 80´s, se hicieron modificaciones a las arquitecturas de capa simple y surgieron las arquitecturas de dos capas. Las arquitecturas de dos capas implementaban el concepto de la lógica delgada y con esto surgió el concepto de thick client2. Las arquitecturas de dos capas estaban compuestas por múltiples thick clients, cada uno mantenía una conexión a una base de datos en un servidor central. Este modelo de arquitectura, implementaba la mayor parte de la lógica de la aplicación en la parte del cliente. En las arquitecturas de dos capas, la parte del servidor implementaba algunas reglas del negocio, pero principalmente fue utilizado como un servidor de bases de datos [ERLT,06]. Las arquitecturas de dos capas dominaron el mundo de las tecnologías de información desde finales de los 80´s hasta mediados de los 90´s, en donde los desarrolladores se dieron cuenta que éste tipo de arquitecturas no eran la solución para todos los problemas, ya que una modificación en la parte del servidor afectaba directamente al cliente y éste tenía que ser modificado.

Por otra parte en el lado del servidor se generaban problemas de congestionamiento y escalabilidad. Con problemas de ambos lados de la arquitectura (cliente y servidor), era difícil mantener la seguridad de las aplicaciones además de la integridad de los datos [AHOK,03]. Las limitaciones asociadas con las arquitecturas de dos capas, originaron la implementación de las arquitecturas multi-capas, desarrolladas bajo el modelo de programación basado en componentes. Este tipo de arquitecturas dividen la arquitectura de software en 3 partes, la capa de presentación, la de negocios y la de datos. Las arquitecturas multi-capas fueron una opción favorable para desarrollar aplicaciones distribuidas, ya que la lógica de las aplicaciones distribuidas junto con otros componentes, reduce la complejidad de centralizar una gran cantidad de la lógica en los servidores, ésto se debe a que el cliente también incluye parte de la lógica.

1 Un thin client lleva a cabo la mayor parte del procesamiento de la información en el servidor. 2 Un thick client procesa la lógica de presentación y de negocios en la parte del cliente.


13

Las arquitecturas multi-capas son esenciales en el desarrollo de aplicaciones, ya que facilitan la distribución de la carga de trabajo en diferentes componentes, logrando una mayor independencia de los procesos entre las diferentes capas. En la capa de presentación se representa la parte interactiva de manera visual-gráfica, esta capa es la más cercana al usuario final. La capa intermedia es la encargada de manejar todo el procesamiento de las transacciones y las reglas del negocio, esta capa es la encargada de interactuar con la capa de presentación y la capa de datos. La última capa es la de datos, ésta es un repositorio de datos, es la parte más importante de una empresa. La figura 2.3 representa la evolución de las arquitecturas en capas.

Figura 2.3. Evolución de las arquitecturas en capas.

Con la propuesta de la Internet de ser un medio viable de las tecnologías de la computación, las arquitecturas multi-capas comenzaron a incorporarse a esta nueva tecnología. Las arquitecturas de software multi-capas implementadas en la Internet, son aplicaciones en las que sus componentes son altamente cohesivos y además presentan un bajo acoplamiento. Las arquitecturas multi-capas que son implementadas en la Internet generalmente deben incorporar diseños que faciliten la adaptación de éstas, a las plataformas distribuidas. Una buena opción para diseñar aplicaciones para arquitecturas distribuidas es el patrón Modelo-Vista-Controlador (MVC). La arquitectura del patrón MVC es un modelo dividido en 3 capas, compuesto por micro-arquitecturas. Las aplicaciones que son desarrolladas utilizando el modelo MVC, son aplicaciones que con mayor facilidad se pueden adaptar a las arquitecturas distribuidas. El patrón MVC es una arquitectura de diseño ampliamente aceptada por los diseñadores que fácilmente se adapta a distintas plataformas. El patrón MVC permite agrupar los componentes de una arquitectura en tres dimensiones el modelo, que se asocia a la representación de la información específica del dominio [TORR, 06]. La vista que es la representación del sistema en pantalla. El controlador implementa una interfaz entre el modelo y la vista asociada, en relación a los dispositivos o mecanismos de entrada.

2.3. Trabajos relacionados. Para desarrollar aplicaciones orientadas a servicios existen procesos y herramientas que conducen al desarrollador en la creación de nuevas aplicaciones basadas en el modelo mencionado, sin embargo hay grupos de investigación que aún siguen trabajando para desarrollar herramientas o procesos de reingeniería que migran arquitecturas legadas hacia arquitecturas de software para ser implementadas de manera distribuida.


14

De los trabajos que tienen como objetivo migrar aplicaciones legadas hacia arquitecturas distribuidas y aprovechar las aplicaciones legadas tenemos:

2.3.1. Migrando sistemas en COBOL a la WEB, usando el patrón de diseño MVC [BODH,02]. Esta investigación tiene como objetivo reestructurar código legado en COBOL hacia sistemas Web, para aprovechar la experiencia y el dominio de las aplicaciones y reutilizarlas en plataformas distribuidas como lo son las aplicaciones Web.

Desarrolla una estrategia de reingeniería basada en técnicas de wrapper3. Además de la estrategia, la investigación desarrolla un conjunto de siete herramientas que participan en la migración del software legado. La estrategia desarrollada para migrar código legado en COBOL consta de ocho pasos: traducción de instrucciones CICS4, reestructuración del código, análisis estático, descomposición del programa, abstracción del modelo de objetos, reingeniería, reestructura de la interfaz de usuario y por ultimo traducción incremental del código. Todo el proceso de reestructura se resume en lo siguiente: primero se analiza el código fuente con un compilador de lenguaje COBOL llamado PERCobol, el compilador genera dos archivos con información del código legado. De los archivos generados por el compilador se extrae información para evaluar y descomponer el programa, utilizando técnicas de rebanado de código y generar pequeños párrafos de estatutos de código, para luego identificar los objetos asociados con el almacenamiento de datos. El proceso continúa con el procesamiento del código para generar la nueva interfaz de usuario basada en JSP´s, el modelo en Java Beans y la parte del control en Servlets. Las pruebas fueron realizadas sobre un sistema compuesto por 101 módulos y en total suman 38,000 líneas de código. Durante las pruebas se encontró un problema en cuanto a la generación automática de los enlaces entre la interfaz de usuario y la parte del modelo, ya que los enlaces quedaban en la parte del modelo y para solucionar el problema, sólo fue necesario hacer una extensión de forma manual para llamar a la lógica del negocio de manera correcta.

2.3.2. Del código legado a la WEB a través del modelado de la interacción [STRO,02]. La investigación tiene como objetivo desarrollar un procedimiento soportado por una suite de métodos de reingeniería, basados en la comprensión y modelado de la interacción de los usuarios con las interfaces de aplicaciones legadas, para reestructurar código legado hacía aplicaciones Web. El desarrollo del procedimiento está basado en la estructura de las aplicaciones legadas y del dominio de los usuarios sobre la aplicación.

Los métodos que colaboran en el desarrollo del procedimiento son implementados en una suite llamada CelLEST. Estos tienen diferentes tareas, por ejemplo:

• Modelar la interfaz de usuario legada a través de un diagrama de transición de

mecanismos de diálogo (diagrama de transición de estados). • Recuperar la especificación de las funciones, por las tareas de usuario identificadas

como patrones de interacción que frecuentemente ocurren.

3 Representa una interfaz que proporciona un nuevo acceso de las aplicaciones a los componentes del código legado por el intercambio de mensajes. 4 Las instrucciones CICS son instrucciones que procesa el sistema para cambios, estas instrucciones permiten al usuario capturar datos en línea.


15

• Crear nuevas interfaces de usuario para que las funciones legadas recabadas sean accesibles a través de la WEB. El tipo de sistemas con los cuales se probó este proceso son aplicaciones legadas que

generalmente se encuentran depositadas en mainframes. El caso de estudio es sobre el sistema de información IBM 3270 de la universidad Mc Gill.

Los investigadores de este proyecto concluyen que el proceso de migrar aplicaciones con base a la interacción del usuario es una buena alternativa, ya que los resultados obtenidos en las pruebas fueron satisfactorios y totalmente aplicables al contexto de la migración de aplicaciones, ya que para las pruebas utilizaron los mismos datos de entrada y en ambos casos (aplicación legada y reestructurada) los resultados fueron los mismos.

2.3.3. Modelos para las metas de la ingeniería inversa del código legado [YUYI,05]. La investigación está enfocada a migrar código legado hacia arquitecturas orientadas a servicios. Plantea una metodología que requiere de la interacción del usuario para llevar a cabo el proceso de reestructura, en este caso el ingeniero de software es quien conduce la reestructuración y tiene la opción de hacer reestructura de código hacía arquitecturas orientas a servicios o a arquitecturas orientadas a componentes.

Un objetivo principal de esta investigación es reestructurar sistemas legados, para obtener sistemas abstractos de un dominio particular, es decir, el usuario adapta los sistemas legados a sus necesidades a través del proceso de reestructura.

El modelo que adapta la metodología de reestructura está basado en el marco de aplicación GSP5 y sirve como un marco de reingeniería para convertir software legado en software genérico.

El producto resultante de la investigación es la metodología que migra aplicaciones legadas.

Esta investigación adopta el modelo conceptual para reingeniería llamado herradura, el modelo en su forma abstracta distingue diferentes niveles de análisis de reingeniería y provee una base para las transformaciones en cada nivel, especialmente para transformaciones para el nivel arquitectural.

En esta investigación el modelo de herradura fue estructurado en pasos secuenciales a partir del código legado, hasta dirigir las metas del modelo hacia arquitecturas orientadas a componentes o a arquitecturas orientadas a servicios.

Las pruebas se llevaron a cabo sobre dos sistemas legados uno escrito en PHP y otro en Java. Los autores mencionan que para migrar el código en Java se utilizó una función incluida en el IDE de eclipse, que facilita la separación de métodos.

2.3.4. Migrando sistemas interactivos legados a servicios Web [CANF,06]. Esta investigación tiene como objetivo migrar sistemas legados basados en formularios hacia servicios Web.

Como producto resultante se desarrolla una metodología basada en las técnicas de wrapper6. La tarea estas técnicas tiene como objetivo establecer funcionalidades interactivas

5 Es un marco para el desarrollo de requerimientos que incluye modelado y análisis de metas del usuario. 6Las técnicas de wrapper implementadas en esta investigación describen el modelo de la interacción entre el usuario y el sistema legado.


16

en los sistemas legados para después reestructurar el sistema legado hacia una arquitectura de servicios Web.

Para migrar los sistemas legados basados en la metodología desarrollada, se implementaron las técnicas de wrapper junto con una técnica de reingeniería llamada de caja negra, basada en el estudio de las entradas y salidas de un sistema.

Para llevar a cabo el proceso de migración fue necesario hacer una especificación del modelo de la interacción del sistema legado, a través de un autómata de estados finitos para obtener información relevante sobre la especificación de los escenarios de interacción, asociados con los casos de uso del sistema y después aplicar las técnicas de wrapper para reestructurar el código legado hacía la arquitectura de un servicio Web.

La metodología para migrar el código legado consiste en 5 pasos. • Identificación: obtiene el modelo de la interacción entre el usuario y el sistema

legado, mediante el uso de ingeniería inversa a través de técnicas de caja negra. • Diseño: son identificadas las variables para interactuar con el autómata finito. • Implementación: se aplican las técnicas de wrapper para reestructurar el código

legado. • Despliegue del servicio Web: se crean todas las operaciones necesarias para publicar

y exportar el servicio Web hacia una aplicación de servidor. • Validación: se utiliza una estrategia que será usada para validar el servicio legado ya

con la nueva arquitectura, lo anterior con el objetivo de descubrir fallas durante la ejecución del servicio.

Las pruebas de la metodología fueron realizadas sobre un sistema de Internet para el

despliegue de noticias y consulta de correo electrónico. El sistema se basa en formularios. Los autores concluyeron que las técnicas empleadas para el desarrollo de la metodología favorecen la migración de sistemas legados ya que son técnicas que determinan de manera autónoma y dinámica el contexto de los sistemas legados.

2.3.5. Migración de soporte para los servicios usando reconstrucción de la arquitectura de software [OBRI,05]. Esta investigación propone un proceso de análisis para dar soporte en la reestructura de software legado hacia arquitecturas orientadas a servicios, mediante la reconstrucción de la arquitectura del sistema legado. El proceso de análisis está basado en la identificación de componentes y su dependencia, para favorecer en la generación de abstracciones y obtener una pre-arquitectura para a futuro adaptarla hacia arquitecturas orientadas a servicios.

Este trabajo tiene un enfoque orientado a la reconstrucción de la arquitectura como una herramienta de toma de decisiones. La reconstrucción facilita el entendimiento de las aplicaciones legadas para identificar y documentar las dependencias entre los componentes internos del software.

Las dependencias identificadas son de tipo funcional y de datos compartidos entre componentes del sistema. La importancia de identificar las dependencias es para sustituirlas por abstracciones durante el proceso de reestructura y obtener arquitecturas basadas en abstracciones.


17

A partir de la especificación de los componentes del software se lleva a cabo el proceso de análisis. Para identificar los componentes del sistema y su dependencia se utiliza una herramienta llamada ARMIN7.

El proceso de análisis se complementa con la sustitución de dependencias entre componentes por abstracciones. La sustitución se lleva a cabo generando un script de reestructura en lenguaje ARL que es un componente de la herramienta ARMIN. El proceso de reestructura se resume en los siguientes cinco pasos:

1. Llevar a cabo un análisis para generar una base de requerimientos. 2. Revisar y hacer un análisis sobre el objetivo del reuso del código, para proveer un

conjunto de estimaciones. En este punto se identifican el grado de acoplamiento, cohesión y dependencia entre componentes de software así como información relacionada con clases y atributos.

3. Identificar el modelo de datos. 4. Llevar a cabo un análisis del código utilizando herramientas que proporcionen

información relevante del software. Por ejemplo: el diccionario de datos, métricas del proyecto, archivos, clases y árboles de invocaciones.

5. Utilizar ARMIN y con base a la información introducida en el script de reestructura, se obtiene una estructura de código en grupos característicos.

Los cinco pasos son básicos para obtener información relevante que permita crear el

script de reestructura, éste debe ser configurado en ARMIN para iniciar el proceso de análisis, obteniendo código legado dividido en varios grupos, representando la pre-arquitectura del futuro sistema orientado a servicios.

Las pruebas del proceso fueron realizadas sobre un sistema de controles y comandos desarrollado en C++. Los autores concluyeron que el proceso genera un conjunto de métodos analíticos que deben ser complementados con otros métodos y deben ser probados para determinar la reconstrucción de la arquitectura del software.

2.3.6. Transformando aplicaciones Web legadas a la arquitectura MVC

[PING,04]. La investigación propone una metodología para reestructurar sistemas Web legados en ambientes de JEE, hacia la arquitectura Modelo-Vista-Controlador (MVC). La metodología es evaluada por un conjunto de herramientas de reestructura automática, las cuales fueron desarrolladas por el mismo grupo de investigadores que desarrolló la metodología. El objetivo de la investigación es extraer la funcionalidad de la base de datos del código legado para encapsularla en objetos Java Beans. Reestructurar en JSP’s los componentes legados relacionados con la representación de datos en pantalla y mantener una referencia con los objetos Java Beans. Bajo el enfoque del patrón MVC el sistema legado debe quedar re-organizado de la siguiente manera: el modelo presentado en Java Beans, la vista en Java Server Pages y el controlador en Java Servlet. El proceso de refactorización consta de dos etapas, la primera implementa una metodología de transformación basada en trabajos previos de reestructura de código. La aplicación de la metodología de la transformación está basada en tres pasos:

7Herramienta desarrollada por el Instituto de Ingeniería de Software de Carnigie Mellon para identificar dependencias entre componentes de software en distintos lenguajes (Java, C, C++, Fortran).


18

1. Separar el acceso de la base de datos (Modelo), de la lógica de presentación (Vista). 2. Hacer la transición a las páginas JSP. 3. Adoptar una arquitectura centrada en el controlador.

La segunda etapa incluye la implementación de un modelo de transformación compuesto de cinco pasos:

1. Identificar el software legado. 2. Analizar el código y crear un árbol AST. 3. Extraer la información del árbol AST. 4. Generar aplicaciones automáticamente. 5. Obtener el software legado reestructurado conforme el patrón MVC.

Las pruebas fueron realizadas para evaluar la metodología con dos sistemas Web. Los

sistemas evaluados son aplicaciones comerciales utilizadas por IBM WebSphere8. Las herramientas que llevan a cabo el proceso fueron adaptadas para reestructurar los casos de estudio, sin embargo éstas, deben ser extendidas para soportar el análisis de las ligaduras dinámicas entre páginas y la alta cohesión. Los autores concluyen que el reuso de las aplicaciones legadas es una buena práctica de la ingeniería de software, que reduce problemas de mantenimiento en sistemas legados.

2.3.7. Hacia un Acercamiento Holístico para el rediseño de aplicaciones legadas para la Web con UWAT+ [DIST,06]. Esta investigación propone un proceso semiautomático para la reestructura de aplicaciones legadas hacia aplicaciones Web. El proceso consta de tres fases:

1. Licitación de requerimientos: se enfoca en formalizar la meta del proceso de

rediseño. 2. Ingeniería inversa: se enfoca en recuperar la información del sistema legado y

formalizarla. 3. Diseño: utiliza los requerimientos de la primera fase para redefinir el proyecto de

diseño.

El proceso de reestructura se lleva a cabo de la siguiente manera: en la primera fase se hace la licitación de requerimientos, la definición de metas, la identificación de la lógica del negocio. La segunda fase recupera la información del sistema utilizando un marco de aplicación desarrollado previamente por los autores, para luego formalizar la información. La tercera fase es la que lleva a cabo el desarrollo del proceso de rediseño con base a los resultados de las dos fases previas.

El marco de aplicación desarrollado previamente se encarga del diseño de las aplicaciones Web y consta de dos etapas. En una primera etapa se lleva a cabo el desarrollo de aplicaciones Web, adoptando la separación de problemas en el diseño en cuatro actividades fundamentales, licitación de requerimientos, diseño de hipermedia y operación, diseño de transacción y por último el diseño.

La segunda etapa establece las reglas de interacción en el sistema, tales como el contenido y los enlaces de navegación para cada una de las actividades del negocio.

8 Se refiere a una marca de productos de software de IBM, comúnmente propietarios.


19

Esta investigación mezcla tecnologías de recuperación de los diseños, para capturar el conocimiento embebido de las aplicaciones legadas, esta tarea es complementada con el uso de métodos recientes de diseño, estos particularmente satisfacen a los sistemas basados en Web.

Las pruebas del proceso fueron realizadas en un sistema legado desarrollado en Visual Basic 5, el motivo principal de hacer pruebas con este sistema fue para reducir el costo de mantenimiento y mejorar el servicio a los clientes a través de soluciones basadas en Web.

Esta investigación tiene como resultado un procedimiento capaz de recuperar el conocimiento y experiencia de las aplicaciones legadas, así como la transferencia del conocimiento en un modelo conceptual centrado en el usuario para una versión Web del sistema legado. A futuro se tiene contemplado desarrollar herramientas automáticas para las tareas involucradas en las tres fases, que son tareas llevadas a cabo de forma manual.

2.3.9. Comentarios finales. Los trabajos analizados proponen diferentes soluciones para migrar sistemas legados hacia plataformas distribuidas o hacer una reestructura de éstos para generar aplicaciones Web. Algunos de los trabajos analizados como producto resultante presentan metodologías o procesos que llevan a cabo la migración de código legado, por ejemplo: [BODH,02], [STRO,02], [CANF,06] y [PING,04]. Su estrategia de reestructura está basada en la experiencia del usuario, lo que requiere que la tarea sea llevada a cabo por usuarios calificados. Los trabajos mencionados anteriormente validan la estrategia de reestructura con una herramienta.

Otros trabajos como el desarrollado en [YUYI,05], presenta una estrategia de reestructura basada en una metodología, al igual que los trabajos mencionados anteriormente, se requiere de usuarios calificados para llevar a cabo la reestructura del código ya que no cuentan con una herramienta de reestructura, recurriendo a pruebas manuales.

Otros trabajos basan su estrategia de reestructura en procesos, por ejemplo: [OBRI, 05] y [DIST,06]. Con base a las pruebas, concluyen que su trabajo es viable para migrar el código legado hacía aplicaciones Web. El planteamiento, desarrollo e implementación de metodologías y procesos de reestructura presentados por los trabajos relacionados, pueden considerarse como ventajas sobre el trabajo de tesis, ya que han sido probados con sistemas legados en funcionamiento. Sin embargo, para futuras investigaciones que deseen reestructurar código legado hacia servicios Web, el disponer de un conjunto de métodos de reestructura de código legado, basados en escenarios (producto resultante de esta tesis), debe favorecer en la adaptación de éstos en procesos de reestructura, ya que fueron desarrollados a partir de un análisis detallado de los diferentes componentes del lenguaje Java (estatutos de código, funciones, clases y micro-arquitecturas). Los trabajos analizados proponen una solución para migrar sistemas legados, pero a excepción de [PING,04], [YUYI,05], [DIST,06] los demás no proveen las facilidades de adaptar sus soluciones en diferentes escenarios, lenguajes de programación o plataformas. Aunque [BODH,02] incluye un proceso de reestructura basado en la arquitectura MVC para migrar código legado, no define las variantes del código legado a reestructurar.

En el presente trabajo de tesis se desarrolla el conjunto de métodos heurísticos basados en lenguaje Java, para reestructurar el código legado, hacia un marco de aplicaciones basado en la arquitectura MVC y otros patrones primitivos, incrementando la reusabilidad, portabilidad y flexiblidad de los sistemas legados que a futuro vayan a ser reestructurados conforme a los métodos propuestos, ya que sus componentes van a estar altamente cohesionados y con bajo acoplamiento.


20

Comparar el trabajo de tesis con los trabajos analizados anteriormente, permite hacer una descripción de las diversas técnicas de reestructura, para migrar sistemas legados hacia servicios Web e identificar las diferencias con la tesis. La tabla 2.1 presenta un resumen de los trabajos relacionados con algunas ventajas y desventajas.

Tabla 2.1. Tabla comparativa de los trabajos relacionados.

Trabajo Objetivo Tipo de solución Ventaja Desventaja Producto

Resultante [BODH,02] Migrar código en

COBOL hacía arquitecturas Web.

Extrae información del código desarrollado en COBOL y reestructura la parte relacionada con la interfaz de usuario en JSP, el modelo de datos en Java Beans y la parte del control en servlets.

Migra las aplicaciones legadas hacía arquitecturas Web de manera automática.

No define las variantes a reestructurar en Java.

Estrategia de reingeniería y herramientas que la soportan.

[STRO,02] Diseñar un procedimiento de reingeniería basado en la interacción de los usuarios para la reestructura de código legado.

A través de los métodos que conforman el procedimiento se lleva a cabo la reestructura de aplicaciones legadas.

La reestructura del código es de forma semiautomática.

No define las variantes a reestructurar.

Procedimiento de reingeniería basado en la interacción de los usuarios.

[YUYI, 05] Reestructurar sistemas legados para generar sistemas abstractos de dominios particulares.

Adapta un modelo de reingeniería para generar sistemas abstractos.

La metodología facilita la migración hacia SOA´s o arquitecturas basadas en componentes.

Requiere la participación de usuarios expertos para conducir la tarea de reestructura.

La metodología de

migración.

[CANF,06] Migrar sistemas legados basados en formularios hacía servicios Web.

Aplica técnicas de wrapper a un autómata finito, que incluye la descripción de los escenarios asociados a los casos de uso de la interacción del usuario con el sistema.

La metodología para migrar el código legado es evaluada con sistemas funcionales.

____ Una metodología basada en técnicas de wrapper.

[OBRI,05] Desarrollar un proceso de análisis para dar soporte en la reestructura de

Identificar los componentes del sistema legado y su dependencia

__ Se requiere un usuario experto para llevar a cabo el proceso de análisis y

Un proceso de análisis.


21

código legado. para generar pre-arquitectu ras abstractas.

éste de forma manual identifica las partes a reestructurar.

[PING,04] Extraer la funcionalidad de la base de datos del código legado y encapsularla en Java Beans. Reestructurar en JSP´s los componentes relacionados con la representación de datos en pantalla.

Se basa en dos etapas, en la primera implementa una metodología de transformación basada en otras investigaciones y la segunda etapa aplica un modelo de transformación.

El trabajo es una investigación que a futuro puede ser extendida a otros lenguajes de programación orientados a objetos.

No fragmenta el código para reestructurar hacía el patrón MVC, reconstruye aplicaciones previamente separadas.

Una metodología de reestructura.

[DIST,06] Reusar aplicaciones legadas para aprovechar su conocimiento y experiencia en los diferentes dominios.

A partir de la licitación de requerimientos se hace una recuperación de la información del sistema para llevar a cabo el proceso de rediseño.

El procedimiento es funcional.

__ Procedimiento semiautomático de reestructura de aplicaciones.

“ESTA TESIS”

Analizar para distinguir casos de uso y sus distintos escenarios para separar el código legado y reestructurarlo conforme el patrón MVC.

A través de la identificación de las diferentes partes del código legado, se generan métodos heurísticos.

La definición de los métodos heurísticos basados en el análisis de escenarios posibles del código de entrada.

Los métodos heurísticos no están automatizados.

Conjunto de métodos heurísticos.

CAPÍTULO 3 MARCO TEÓRICO

22

Capítulo 3) MARCO TEÓRICO Este capítulo presenta la descripción de los conceptos y elementos necesarios para llevar a cabo el desarrollo de los métodos heurísticos, para su aplicación en la reestructura del software legado.

3.1. Reingeniería. Según [CANF,07] la reingeniería, “es un proceso de análisis para identificar los componentes de un sistema y sus correlaciones, para crear representaciones del sistema de otra manera o en un alto nivel de abstracción. La base principal de la reingeniería consiste en derivar información disponible de los artefactos de software y traducirlos hacia representaciones abstractas de una manera más fácil de comprender por los humanos.” La reingeniería de software generalmente es aplicada a sistemas que han sido funcionales y han servido a las necesidades de un dominio en particular que durante varios años y transcurrido el tiempo se vuelven inestables debido a las correcciones, adaptaciones y a las mejoras realizadas. La reingeniería de software es una buena práctica ya que evita problemas de funcionalidad, que comúnmente aparecen cuándo se le hacen cambios a los sistemas. El objetivo principal de la reingeniería es reimplementar sistemas funcionales para que sean más mantenibles. La reingeniería de los sistemas incluye la redocumentación, la organización, la reestructura, la traducción a un lenguaje de programación más moderno, los valores de los datos y por último la modificación y actualización de la estructura. Cuando a un sistema se le aplica alguna técnica de reingeniería, normalmente el funcionamiento del sistema permanece igual. “Desde una perspectiva de negocios, la reingeniería de software es


23

la única forma viable apara asegurar que los sistemas heredados continúen en servicio” [SOMM,02]. La reingeniería de software puede incluir algunos de los siguientes pasos: la traducción del código fuente, en donde el programa se convierte de un lenguaje antiguo a uno más moderno; la ingeniería inversa, donde el programa es analizado para extraerle información que facilite la documentación; la mejora de la estructura del programa, en donde se analiza y modifica la estructura del control del programa; la modularización que agrupa las partes relacionadas del programa y la redundancia se elimina y la reingeniería de datos, en donde los datos procesados son cambiados por el programa para reflejar cambios [SOMM,02].

3.2. Software legado. Según [FAIS, 98], los sistemas de software legado han sido desarrollados tiempo atrás y son críticos para la operación de las compañías.

Algunos autores le atribuyen el concepto de software legado a aquellos sistemas que fueron desarrollados principalmente en lenguajes de programación estructurada o por procedimientos y que generalmente son sistemas que tienen una arquitectura monolítica y poco reutilizable. Muchos sistemas funcionales desarrollados en el lapso de varios años, fueron implementados en plataformas que han caído en desuso [HERN, 03] y al tiempo que han ido surgiendo nuevas tecnologías y nuevos modelos de desarrollo de software, dichos sistemas funcionales se han quedado obsoletos. Sin embargo la experiencia representada por los años de uso de los sistemas legados, puede ser reutilizada mediante las técnicas apropiadas que faciliten adaptar los sistemas legados a nuevas tecnologías y a nuevos modelos, por ejemplo, la reingeniería del software.

3.3. Reuso del software. El reuso del software, es definido como el proceso de construir o ensamblar aplicaciones y sistemas, a partir de otro software previamente desarrollado. El reuso del software es un área de investigación importante de la ingeniería de software [SHIV,07].

El reuso del software es considerado como una solución favorable, que evita repetir el desarrollo del software, proporcionando a los desarrolladores el conocimiento y la experiencia obtenida a través del tiempo y uso del software legado [LIUY, 07]. El reuso del software puede ser orientado hacia a la reutilización de productos, en donde a partir de la integración de componentes se desarrollan nuevos sistemas.

3.4. Patrón de diseño Modelo-Vista-Control MVC. Un buen diseño de software generalmente debe incluir una alta cohesión y un bajo acoplamiento. Como consecuencia de un bajo acoplamiento y una alta cohesión, los componentes fácilmente son reutilizados en proyectos de diferentes dominios.

La arquitectura del patrón de diseño MVC favorece en la implementación de los principios mencionados anteriormente y también a otros tales como la portabilidad, flexibilidad, modularidad y extensibilidad, favoreciendo el desarrollo de aplicaciones dinámicas y distribuidas [SOFT, 05]. El patrón de diseño MVC tiene una característica muy particular, es implementado en tres partes. La primera parte del patrón es el modelo, representa el objeto de la aplicación; es la parte que implementa algoritmos y controla el acceso a la base de datos, es decir es el modelo del negocio. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada y tiene asociado un elemento de la vista.


24

La segunda parte es la vista, es la representación en pantalla de la información a través de tecnologías de presentación, tales como documentos HTML, formularios o pantallas de texto. La vista asocia los segmentos de código para representar los resultados de operaciones en el modelo. Cada vista tiene asociado un componente control. La tercera parte es el control, es la unión entre la interfaz de usuario y el modelo del negocio. Tiene como tarea centralizar la petición de servicios de la vista y delegarlas al modelo, traduciendo las órdenes en peticiones al modelo. El control tiene asociado un componente del modelo. La figura 3.1 muestra la arquitectura del patrón MVC.

aControlabstract void execute()

cVistaaControl oC

cVista(aControl oC)void invoca()

aModeloabstract void unaAccion()

cControlaModelo oM

cControl(aModelo oM)void execute()

Clientestatic void main()

aVistaabstract void invoca()

cModeloaVista oV

cModelo()void unaAccion()

oC oM oV

Figura 3.2. Arquitectura del patrón MVC.

En la figura 3.1 la nomenclatura de las clases identifica cada parte del modelo, el prefijo “a” se usa para identificar una clase abstracta y el prefijo “c” se utiliza para identificar una clase concreta. Por ejemplo aVista corresponde a la clase abstracta de la vista y cVista corresponde a la clase concreta de la vista. El cliente del patrón se comunica a través de la clase aVista.

3.4.1. La comunicación entre la vista y el modelo. La parte de la vista interactúa con el modelo a través del control. Por ejemplo, si un botón es presionado por el usuario, un mensaje de acción debe enviarse a un objeto de tipo control para conseguir la ejecución de una rutina en la parte del modelo. Si un nuevo valor es capturado en un campo de entrada, un mensaje de actualización puede ser enviado al modelo para obtener ese nuevo valor. Si se requiere un valor para desplegar en pantalla información, entonces se manda un mensaje a un objeto del modelo para obtener el valor. El trabajo de los métodos en la parte del modelo es responder al mensaje para obtener los valores que solicita la vista.

3.4.2. La comunicación del modelo hacia la vista. El modelo se comunica con la vista a través de eventos. Los eventos proveen buenos mecanismos de desacoplamiento, facilitando la comunicación con un mínimo de dependencias [DEAC, 05].

Muchos desarrolladores implementan el patrón de diseño MVC de acuerdo a su experiencia y mejores prácticas, algunos autores citan que la comunicación del modelo a la vista, debe ser a través del control [DEAC,05]. Otros representan la comunicación del modelo con la vista mediante el patrón de diseño Observer [GAMA, 95]. Tomando las dos referencias anteriores como base, la comunicación del modelo a la vista puede variar, esto conforme a la manera en que los desarrolladores lo implementen, pero siempre manteniendo e


25

implementando los principios de desarrollo de software y preferentemente utilizando patrones de diseño.

3.4.3. La comunicación entre el control y el modelo. El control tiene la función de interpretar órdenes de las vistas y delegarlas a la parte correspondiente del modelo. Cuando la vista desea hacer consultas al modelo, se dirige con el control correspondiente y éste mapea las acciones del usuario hacía las actualizaciones del modelo y propicia el cambio de estado de las partes del modelo a través de la invocación de métodos. El proceso de negocio del patrón MVC comienza con la invocación de métodos por parte de la vista al controlador, para conducirlos al modelo. El modelo encapsula el estado de la aplicación y responde a las peticiones del modelo. El modelo también expone la funcionalidad de la aplicación y notifica a las vistas sobre los cambios de estado a través de eventos.

3.4.4. Ventajas del patrón MVC. En la tabla 3.1, se listan las ventajas principales que se obtienen al usar el patrón MVC.

Tabla 3.1. Ventajas principales del patrón MVC.

Ventaja Descripción Menor acoplamiento. • Desacopla la vista del modelo.

• Desacopla el modelo de la forma en que se muestran e ingresan los datos.

Mayor cohesión. • Cada elemento del patrón tiene un alto grado de especialización en su tarea.

• El objetivo de la parte del modelo es implementar las funciones del negocio.

• La vista es el contacto del patrón con el usuario. • El controlador tiene como objetivo el manejo de

eventos entre la vista y el modelo. Las vistas proveen mayor flexibilidad y agilidad.

• Se pueden crear múltiples vistas de un modelo. • Se puede crear, añadir, modificar y eliminar nuevas

vistas dinámicamente. • Las vistas se pueden anidar. • Se puede cambiar el modo en que una vista responde

al usuario sin cambiar su representación visual. • Se pueden sincronizar las vistas. • Las vistas se pueden concentrar en diferentes

aspectos del modelo. Mayor facilidad para el desarrollo de clientes en múltiples dispositivos y canales.

• Una vista para cada dispositivo puede variar según sus capacidades.

• Una vista para la Web y otra para aplicaciones de escritorio.

Más claridad. • El diseño de software se encuentra agrupado en vistas y se puede entender con mayor facilidad.

Facilita el mantenimiento. • El tener un nivel bajo de acoplamiento permite detectar con mayor facilidad las partes que requieran mantenimiento.

Mayor escalabilidad. • La parte de la vista y el control se pueden adaptar fácilmente a las extensiones en la parte del modelo.


26

3.4.5. El patrón MVC bajo un enfoque de reuso. La parte del modelo es la parte más reutilizable y menos susceptible al cambio. Las clases (funciones o estructuras) del modelo tienen conocimiento de las clases de la vista, pero no del control. Esta característica asegura compilar el modelo en librerías independientes y reutilizarlo en cualquier otro programa que así lo requiera. La parte de la vista es lo más cambiante en la arquitectura del patrón MVC, es decir es lo menos reusable. Si se desea hacer un cambio en el modelo o en el control, será necesario recompilar la parte de la vista. El control generalmente puede ver clases del modelo, pero no puede ver clases de la vista. El control es la estructura encargada de delegar las peticiones de la vista al modelo, claramente el control debe tener conocimiento de los elementos del modelo y ejecutar los cambios, pero no tiene conocimiento de la vista para hacer actualizaciones, de esta forma un cambio en la interfaz no influye en la modificación y compilación del algoritmo del control.

3.4.6. Patrones de diseño primitivos utilizados en la arquitectura del patrón MVC. El patrón MVC es un patrón arquitectural y representa el esquema de organización fundamental para sistemas de software. Un patrón arquitectural está constituido por varias micro-arquitecturas (patrones de diseño), la unión de todas constituye una macro-arquitectura que puede reutilizarse al igual que los patrones de diseño, en problemas recurrentes y de forma distinta cada vez que se use. Las micro-arquitecturas deben tener bien claras sus responsabilidades e incluir reglas y guías para organizar las relaciones entre ellos. Los patrones arquitecturales, representan el más alto nivel de los patrones.

El patrón MVC puede estar compuesto por todos o algunos de los patrones representados en la tabla 3.2 [WELI, 06].

Tabla 3.2. Patrones que conforman la arquitectura MVC.

Patrón de diseño Objetivo en la arquitectura MVC Composite Para la creación de vistas compuestas. Utilizando este patrón podemos crear

una jerarquía de vistas y tratar a cada vista compuesta igual que a una vista normal.

Strategy En la relación entre las vistas y el control. Utilizando este patrón podemos cambiar dinámicamente o en tiempo de compilación los algoritmos del controlador, mediante los cuales responde a su entorno.

Factory Method Para especificar la clase control predeterminada de una vista. Proxy Para distribuir la arquitectura (Modelo y Vista-Control) en diferentes

ubicaciones. Command Para crear controles específicos para cada elemento de la vista.

3.4.6.1. Patrón de diseño Composite. Este patrón de diseño es una micro-arquitectura que facilita la creación de vistas compuestas. Con la utilización de este patrón de diseño se puede diseñar una jerarquía de vistas y hacer una composición de vistas. Cada vista compuesta puede ser tratada como una vista normal. Es parte del grupo de los patrones estructurales del catálogo de Gamma.


27

La micro-arquitectura que presenta el patrón Composite comúnmente se implementa en el diseño de sistemas de información, ya que es de gran utilizad para tratar con estructuras compuestas y para objetos individuales [GAMA, 95]. Comúnmente los diseños de software que no implementan este patrón, tratan de una forma diferente a los objetos simples y compuestos, esa distinción genera que las aplicaciones sean más complejas. El patrón Composite describe cómo usar la composición recursiva para que los clientes no tengan que hacer esa distinción [GAMA, 95]. El patrón Composite en su mínima representación está compuesto por una clase abstracta que representa a un componente y subclases de dos tipos, uno de estos representa un objeto compuesto de la clase base y el otro representa un objeto simple o primitivo. La figura 3.2 es una representación de la arquitectura de este patrón.

Cliente

Hoja

operacion()

Compuesto

operacion()añadir()quitar()obtenerHijo()

Componente

operacion()añadir()quitar()obtenerHijo()

+ Hijos

1...*

Figura 3.3. Arquitectura del patrón Composite.

La implementación de este patrón aplica cuando es necesario hacer una representación jerárquica de agregación y otra cuando se requiere que los clientes sean capaces de ignorar la diferencia entre los objetos compuestos y objetos individuales, respecto a determinadas características y comportamientos. Los clientes deben tratar a todos los objetos de la estructura compuesta de manera uniforme.

3.4.6.2. El patrón de diseño Strategy. El patrón Strategy tiene como propósito definir una familia de algoritmos encapsulados, facilitando que sean intercambiables. Una de las facilidades representativas de este patrón es la variación independiente de los clientes que lo usan.

El patrón Strategy en la arquitectura MVC participa en la relación entre las vistas y los controles. Con este patrón se facilita el cambio dinámico a los algoritmos del control, mediante los cuales responde a su entorno. Este patrón debe ser usado cuando están presentes gran cantidad de clases que difieren en su comportamiento. Los algoritmos de estrategia, implementados en la micro-arquitectura del patrón Strategy configuran una clase con comportamientos específicos de muchos posibles. Este patrón también es utilizado para el ocultamiento de estructuras de datos que son dependientes de un algoritmo y se desea que el cliente no conozca dichas estructuras.


28

La figura 3.3 es una representación de la arquitectura de este patrón. Los elementos de este patrón son: una clase cliente definida como Contexto, una clase que representa a una Estrategia abstracta y una o más subclases que son llamadas estrategias concretas EstrategiaConcretaA y EstrategiaConcretaB.

EstrategiaConcretaA

InterfazAlgoritmo()

EstrategiaConcretaB

InterfazAlgoritmo()

Contexto

InterfazContexto()

Estrategia

InterfazAlgoritmo()

Figura 3.4. Arquitectura del patrón Strategy.

Este patrón de diseño favorece el desacoplamiento entre clases hasta determinado punto,

es decir, hay una dependencia mínima entre la clase principal y la clase concreta.

3.4.6.3. Patrón de diseño Factory Method. El patrón de diseño Factory Method pertenece al grupo de los patrones de creación del catálogo de Gamma, este grupo de patrones tienen el propósito de implementar procesos para la creación de objetos.

El patrón Factory Method define una interfaz para crear un objeto delegando la responsabilidad a las subclases para instanciar a otras clases [GAMA, 95].

La figura 3.4 presenta la arquitectura del patrón de diseño Factory Method, compuesta por cuatro componentes.

Producto

ProductoConcreto

Creador

MetodoDeFabricacion()UnaOperacion()

CreadorConcreto

MetodoDeFabricacion()UnaOperacion()

MetodoDeFabricacion{ producto = MetodoDeFabricacion();}

MetodoDeFabricacion{ return new ProductoConcreto}

Figura 3.5. Arquitectura del patrón Factory Method.


29

En la arquitectura del patrón Factory Method, el cliente crea una instancia del Creador y de forma dinámica toma la forma del CreadorConcreto. El cliente utiliza la interfaz del Factory Method para la creación de productos concretos.

En la clase Creador es necesario declarar el método de fabricación para que retorne un objeto de tipo Producto. El CreadorConcreto, redefine el método de fabricación para retornar una instancia de un ProductoConcreto.

Los kits de herramientas y los marcos de aplicaciones reusables generalmente implementan este patrón por las facilidades para desacoplar clases.

En la arquitectura Modelo-Vista-Control, el patrón Factory Method tiene la tarea de especificar la clase control predeterminada de una vista. Algunos diseñadores no utilizan este patrón ya que generalmente utilizan sólo una clase control para todas las vistas y no para cada una de éstas.

3.4.6.4. Patrón de diseño Proxy. El patrón de diseño Proxy pertenece al grupo de los patrones estructurales del catálogo de Gamma. En este catálogo existen muchas similitudes entre los patrones de diseño que lo componen, éstas se deben a que los patrones se basan en un mismo conjunto de mecanismos para estructurar el código y objetos. Para los patrones basados en clase el mecanismo es la herencia simple y la herencia múltiple. Para los patrones basados en objetos, es la composición de objetos. En la arquitectura del patrón MVC, el patrón de diseño Proxy tiene la función de distribuir las vistas en diferentes ubicaciones. La micro-arquitectura que implementa el patrón Proxy, proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.[GAMA,95] En aplicaciones distribuidas, el patrón Proxy es una buena opción para implementar representantes locales de un objeto situado en otro espacio de direcciones. Comúnmente en los sistemas distribuidos los clientes desean tener acceso a servicios de componentes remotos y el acceso directo no es la mejor opción. La figura 3.5 representa la arquitectura del patrón Proxy.

Proxy

Peticion()

SujetoReal

Peticion()

Cliente Sujeto

Peticion()

sujetoReal

Peticion{sujetoReal->Peticion();}

Figura 3.6. Arquitectura del patrón Proxy.

En la arquitectura del patrón Proxy la clase SujetoReal implementa el algoritmo que define la funcionalidad principal de la micro-arquitectura. El Sujeto define los objetos reales representados.


30

La clase Proxy mantiene una referencia que permite el acceso a los objetos reales. También proporciona una interfaz idéntica a la del Sujeto, para que con mayor facilidad los sujetos reales sustituyan a un Proxy. El patrón Proxy no está diseñado para trabajar con propiedades dinámicas, ni tampoco para implementar la composición recursiva.

3.4.6.5. Patrón de diseño Command. El patrón de diseño Command, tiene la tarea de asignar responsabilidades a objetos. Este patrón implementa algoritmos para clases, objetos y para la comunicación entre estos. El patrón Command implementa en cada uno de sus colaboradores (clases de la micro-arquitectura), un mecanismo para la descripción del flujo del control complejo, esto es difícil de conocer y seguir en tiempo de ejecución, favoreciendo la interconexión entre los objetos. Con la micro-arquitectura del patrón Command es fácil encapsular una petición en un objeto y pasarla como parámetro, guardarla en un historial o manipularla de alguna otra forma. La figura 3.6 es una representación de la arquitectura de este patrón.

OrdenConcretaestado

Ejecutar()

Cliente

ReceptorAccion()

Invocador OrdenEjecutar()

receptor->Accion( )

Figura 3.7. Arquitectura del patrón Command.

El patrón Command en su representación más simple está compuesto de cinco elementos [GAMA, 95] la clase Orden declara una interfaz para ejecutar una operación, ésta recibe una referencia de la clase receptora. La OrdenConcreta define un enlace entre un objeto Receptor quien ejecuta una acción. La OrdenConcreta invoca las funciones del Receptor con la referencia que le transfiere el Cliente. El Cliente crea instancias de las clases Receptor, Orden e Invocador. El Invocador le solicita a la clase Orden que ejecute peticiones. El Receptor tiene conocimiento de la manera en que se van a ejecutar las operaciones asociadas a cada una de las peticiones hechas por el invocador.

El patrón MVC fue diseñado en primera instancia, para ser implementado en el lenguaje de programación SmallTalk y en el diseño no se documenta el uso del patrón Command. Sin embargo, los diseñadores de software han implementado la arquitectura MVC para diseños Web como una buena opción de diseño y en este nuevo uso del patrón MVC, algunos desarrolladores implementan al patrón Command para crear las clases controladoras para cada una de las vistas.

Los diseñadores de software para Web que implementan la arquitectura MVC, proponen usar una sola clase controladora para toda la aplicación y la representan en un servlet. Las ventajas que se obtienen son: el control puede gestionar todas las peticiones,


31

incluyendo invocaciones de seguridad, gestión de excepciones, etc. La clase Orden del patrón de diseño Command, fácilmente puede adaptarse a la propuesta de los diseñadores.

3.5. El lenguaje de programación Java. Java es un lenguaje de programación orientado a objetos, desarrollado por la empresa Sun Microsystems en los años 90´s. Java posee una sintaxis clara que para los desarrolladores, es sencilla de comprender para desarrollar programas modulares y de fácil mantenimiento.

Java es un lenguaje de programación que deriva del lenguaje de programación C++, hereda de C++ toda la eficiencia y además gana claridad en cuanto a su uso, característica que C++ no tiene. Java es un lenguaje de programación de alto nivel, esto significa que el lenguaje utiliza un conjunto de microinstrucciones y al tiempo de ser ejecutadas por la computadora tienen que ser traducidas a lenguaje máquina. La traducción del código de alto nivel es una tarea que la llevan a cabo dos elementos importantes del lenguaje, un compilador y un intérprete. El compilador genera un archivo de código de bytes y el intérprete lee el archivo generado y lo ejecuta. La figura 3.7 representa los pasos que se llevan a cabo para ejecutar un programa en Java.

El intérprete de Java es llamado también máquina virtual de Java (JVM), la JVM para

aplicaciones de escritorio generalmente se encuentra en el sistema operativo o fácilmente se puede descargar de la Internet. Ésta interpreta el código en bytes que no es específico de ningún procesador. Java tiene una ventaja importante respecto a los demás lenguajes de programación, es desarrollado para que sea un lenguaje independiente de plataforma. Con esta característica se pretende resolver de manera simultánea, problemas en el desarrollo de software que son causados por la incompatibilidad de las arquitecturas en uso, como sistemas operativos y sistemas de interfaces de usuario, la JVM garantiza la portabilidad de aplicaciones. La JVM tiene las siguientes características:

• Reservar espacio en memoria para los objetos creados. • Liberar la memoria no usada. • Asignar variables a registros y pilas. • Vigilar el cumplimiento de las normas de seguridad de las aplicaciones Java.

Java es un lenguaje de uso simple, elimina muchas propiedades de su predecesor C++, para mantener especificaciones del lenguaje y añadir otras. La administración de la memoria en Java es automática, eliminando la los espacios de memoria a través de un recolector de basura llamado garbage collector, esta misma tarea en C++ se llevaba a cabo utilizando rutinas de código en el cuerpo del sistema [CEBA, 00].

Figura 3.8. Pasos para ejecutar un programa en Java.

Programa en Java

Compilador

Código De

Bytes

Intérprete


32

3.5.1. Programación orientada a objetos (POO). El lenguaje Java tiene definidos los mecanismos básicos de la POO. La POO es un modelo de programación que utiliza objetos, que están ligados mediante mensajes para la solución de problemas. La POO es una extensión natural de la programación estructurada con la intención de aprovechar al máximo los conceptos de modularidad y reutilización del código [CEBA, 00]. La POO tiene 5 mecanismos básicos: los objetos que son una encapsulación genérica de los datos y métodos para ser manipulados. Las instancias que son variables con propiedades definidas en su clase. Los mensajes que son procesos de comunicación entre objetos. Los métodos que representan una implementación de algoritmos que representan operaciones o funciones que los objetos llevan a cabo y por último las clases que son definidas como plantillas para objetos similares.

3.5.2. Propiedades de la programación orientada a objetos en Java. El lenguaje Java implementa las cuatro propiedades de la POO, herencia, abstracción de datos, encapsulamiento de datos y polimorfismo.

3.5.2.1. Abstracción de datos. El lenguaje Java no reconoce la herencia múltiple como otros lenguajes orientados a objetos. Sin embargo, a través de la implementación de un concepto llamado interfaz puede simular la herencia múltiple. Las interfaces ayudan a Java a tener las mismas ventajas que se tiene con la herencia múltiple sin los problemas asociados por la utilización de este tipo de herencia.

Las interfaces son las estructuras que habilitan la propiedad de la abstracción. Las interfaces concentran información esencial de la arquitectura de un sistema desarrollado en Java, ignorando los detalles irrelevantes.

Comúnmente una interfaz es un grupo de métodos con estructura vacía, es decir que no existe ninguna implementación.

3.5.2.2. Encapsulamiento de datos. El encapsulamiento de datos se relaciona con el ocultamiento de los detalles internos de una clase. Un objeto encapsulado es un mecanismo de la clase, es único y tiene límites bien definidos y con la protección de los detalles internos de la clase fomenta la reutilización del código de los componentes de software. El encapsulamiento de variables y métodos en un componente desarrollado en Java, provee dos beneficios importantes para los desarrolladores de software:

• Modularidad: el código fuente es de fácil mantenimiento ya que los cambios sólo

afectan a un componente. • Ocultamiento de la información: un objeto tiene una interfaz a la cual pueden acceder

otros objetos para tener información y comunicación de éste. Una característica importante en la ocultación de la información, es cuando un objeto tiene un cambio y este no afecta a los objetos que dependen de él.

Java tiene la característica de agrupar en paquetes, a clases e interfaces relacionadas

entre sí de alguna forma. Los paquetes representan un conjunto de componentes empacados en una librería que tiene la propiedad de proveer un ambiente de alta cohesión.


33

El tipo de acceso es una característica de la estructura de un programa para generar un ambiente que facilita el encapsulamiento de datos. En Java el tipo de acceso es restringido debido a la presencia de los paquetes (packages). Java al igual que C++, implementa los tres especificadores de acceso comunes private, protected y public y además uno propio el friendly.

El tipo de acceso de los miembros (variables y métodos definidos en la clase), está especificado en la clase, es decir declarando el tipo de acceso en la clase, a todos los miembros les corresponde ese mismo nivel. La tabla 3.3 presenta los cuatro tipos de visibilidad de variables y métodos.

Tabla 3.3. Categorías de acceso.

Elementos private friendly protected publicElementos de la misma clase. SI SI SI SI Elementos de una subclase hacia la clase padre.

NO SI SI SI

Elementos de una clase dentro del mismo paquete.

NO SI NO SI

Elementos de una clase en diferente paquete.

NO NO NO SI

3.5.2.3. Herencia. La herencia es una de las propiedades de mayor importancia en la programación orientada a objetos, en Java tiene un efecto particular de acuerdo a la manera en que son diseñadas las clases. La herencia facilita que una clase pueda heredar todo el comportamiento y atributos de otra clase. Para que una clase pueda heredar su funcionalidad a otra clase, ambas deben estar en una jerarquía de herencia. La clase que hereda la funcionalidad es llamada super clase y la otra es llamada subclase. Una super-clase puede tener varias subclases y éstas, a su vez pueden tener otras subclases, generando una jerarquía de herencia de varios niveles. En una jerarquía de herencia, en las clases de mayor nivel se definen conceptos abstractos y conforme desciende el nivel de herencia, esos se vuelven más concretos. En Java las clases que componen la biblioteca de clases heredan de la clase Object, ésta define el comportamiento y atributos heredados por todas las clases incluidas en la biblioteca. En Java la herencia de clases es sencilla, ya que sólo es permitido heredar de una super clase. El alcance de los métodos y atributos de las super clases es definido en la declaración de la clase. Si se desea que los métodos no puedan ser rediseñados se les antepone la palabra final.

Lo contrario de final es abstract. Una clase marcada como abstracta, únicamente está diseñada para crear subclases a partir de ésta, no siendo posible instanciar ningún objeto a partir de una clase abstracta. Java fue diseñado con la idea de que fuera un lenguaje sencillo y eliminó la herencia múltiple, sin embargo permite implementar herencia múltiple cuando se hereda de una clase abstracta y una interfaz.


34

3.5.2.4. Polimorfismo. El concepto de polimorfismo generalmente se reconoce por la siguiente declaración, “una interfaz, múltiples métodos”, lo que significa diseñar una interfaz para un grupo de actividades relacionadas. Con el polimorfismo se reduce la complejidad en los diseños ya que permite usar una misma interfaz para la especificación de un conjunto de acciones similares. El polimorfismo es habilitado en tiempo de ejecución, en ese instante una instancia cambia de forma y el compilador es el que selecciona la acción concreta (el método) para aplicar en cada situación.

3.6. Heurísticas. Las heurísticas pueden ser criterios, métodos o principios que facilitan identificar entre varias alternativas, la conducta más efectiva para alcanzar una cierta meta. Generalmente, las heurísticas representan compromisos entre dos requerimientos, el primero radica en la necesidad de llevar a cabo una tarea de manera simple y el segundo la necesidad de eliminar correctamente las malas prácticas para llevar a cabo cualquier tarea [PEAR,85]. Una heurística es un conjunto de pasos algorítmicos para llegar a un resultado. En la actualidad, el término es utilizado para referirse a cualquier técnica que coopere en la mejora del desempeño de una tarea de resolución de problemas [STUA,96].

3.6.1. Métodos heurísticos. Bajo el contexto de esta tesis, un método heurístico es un conjunto de pasos algorítmicos que guían en la tarea de reestructura del código legado hacia la arquitectura MVC. Los métodos heurísticos incluyen una intención que define una descripción general del método, además del conjunto de los pasos algorítmicos.

3.7. MoProSoft. El modelo de procesos para la industria del software de México (MoProSoft), es un modelo basado en otros modelos estandarizados, que definen procesos y métodos de evaluación como lo son el SW-CMM y el ISO/IEC 15504. “MoProSoft fomenta la estandarización de su mismo proceso a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. Tiene como objetivo mejorar la capacidad de los procesos de ingeniería de las empresas” [OROZ,05]. El modelo está estructurado en tres categorías: alta dirección, gestión y operación, mediante un mecanismo establecido para alinear las estrategias de las categorías, para que en conjunto facilitar las mejores prácticas y sean implementadas en la gran mayoría de las empresas mexicanas dedicadas al desarrollo y mantenimiento de software.

3.8. Otros conceptos. Dentro del contexto de esta tesis, se utilizan otros conceptos como lo son: función especializada, función no-especializada, clase especializada y clases no-especializadas y se definen a continuación.

3.8.1. Función especializada. Se denominan funciones especializadas a aquellas funciones cuya totalidad de su código, pertenece a una sola parte del patrón MVC, es decir exclusivamente pertenecen a la parte del modelo o de la vista o del control. Por ejemplo:


35

public void ImpResultado(){ System.out.println(“El resultado es :” + x); // Estatuto de código que se relaciona con la } // parte de la vista del patrón MVC.

3.8.2. Función no-especializada. Se denominan funciones no-especializadas a aquellas funciones que tienen estatutos de código que pertenecen a diferentes partes del patrón MVC, es decir unos estatutos pertenecen al modelo, otros a la vista y otros al control, o alguna combinación entre estas tres partes. Por ejemplo: public void OperacionA(){ int a,x,y; System.out.println(“Calcula suma ”); //Estatuto de código que se relaciona con la parte de //la vista del patrón MVC. while(x<100) //Estatutos de código que se relaciona con la parte del modelo. { x = a + y; x++; } }//Fin de función

3.8.3. Clase especializada. Se denominan clases especializadas a aquellas clases compuestas por una o más funciones especializadas de la misma parte del patrón MVC. Por ejemplo, en la figura 3.8, FunA, FunB y FunC son funciones especializadas.

cClaseAfunA()

cClaseBfunB()

cClaseCfunC()

funA(){ System.out.println("Func. de la vista");}

funA(ActionEvent e){ clicEnBoton(e); } }

funC(){ x = 10 *11;}

(a) (b) (c)

Figura 3.9. Clases especializadas, (a) clase especializada en la vista, (b) clase especializada en el control, (c)

clase especializada en el modelo.

3.8.4. Clases no-especializadas. Una clase no-especializada es aquella clase que incluye funciones no-especializadas o una mezcla de funciones especializadas de diferente parte del patrón MVC y no-especializadas. Por ejemplo, en la figura 3.9 FunA y FunC son funciones especializadas y la función OperacionA es una función no-especializada.


36

cClaseMfunA()funC()OperacionA()

funA(){ System.out.println("Fun. de la vista");}funC(){ x = 10 * 11;}publ ic void OperacionA(){ int a,x,y; System.out.println("Calcula suma"); //Estatuto decódigo que se relaciona //con la parte de la vista. x = a + y; //Estatuto de código que se relaciona con la parte del modelo.}

Figura 3.10. Clase no-especializada.

3.9. Comentarios finales. En este capítulo se han definido los conceptos necesarios para comprender la investigación que se ha realizado. Fue necesario hacer una documentación sobre el lenguaje Java para identificar aspectos importantes del lenguaje, tales como la manera en que se manejan las propiedades del paradigma orientado a objetos y de que manera hay que tratarlas al reestructurar los sistemas legados. También se documentó el patrón MVC, que es una pieza clave en el desarrollo del marco de aplicaciones basado en este patrón y que es utilizado para definir la manera en que debe ser reestructurado el código legado mediante los métodos heurísticos. Además se describen los términos con los que hacen referencia a los diferentes tipos de clases y funciones para las que se construyeron las heurísticas de reestructura. Los escenarios del análisis de las clases y funciones se presentan en el capítulo 4 y el diseño de las heurísticas se describe en el capítulo 5.

Funciones especializadas

Función no-especializada

CAPÍTULO 4 ANÁLISIS DE ESCENARIOS

37

Capítulo 4) ANÁLISIS DE ESCENARIOS En este capítulo son identificados un conjunto de casos de uso para después documentar los diferentes escenarios generados a partir de los casos de uso y que posiblemente se encuentren en el código legado. A partir de los escenarios se definirán en el siguiente capítulo un conjunto de métodos heurísticos. La figura 4.1 muestra los pasos que se desarrollan en este capítulo y en el siguiente para cumplir con el objetivo de la tesis.. Para reestructurar aplicaciones legadas hacia la arquitectura MVC, es necesario identificar la manera en que se encuentra implementado el código en las aplicaciones legadas por medio de un análisis y así definir una estrategia de reestructura basada en métodos heurísticos a partir del análisis de casos de uso y escenarios.

Los escenarios fueron documentados tomando como base una plantilla que cubre con los principales puntos para la especificación de requerimientos del modelo MoProSoft.

Figura 4.2. Pasos para cumplir con el objetivo de la tesis.

Pasos definidos en este capítulo


38

4.1. Especificación de requerimientos. La especificación de requerimientos para llevar a cabo la tarea de reestructura, incluye la descripción de los elementos implicados y su rol. El modelo MoProSoft utilizado para documentar los requerimientos, incluye los siguientes 3 puntos.

1. La descripción de los roles o funciones que debe asumir el actor implicado en la reestructura del código legado.

2. El diagrama de casos de uso, que debe ser coherente y consistente para promover una imagen fácil de comprender con relación a los requerimientos y así llevar a cabo la reestructura de código legado.

3. La especificación de los casos de uso, para describir las variantes existentes en la arquitectura de los sistemas legados.

4.1.1. Actores. En la tabla 4.1, se documentan las funciones y roles que debe cumplir el actor implicado en la tarea de reestructura de los sistemas legados.

Tabla 4.1. Actores implicados en el desarrollo de los métodos heurísticos.

CUADRO CONCEPTUAL ACTOR DESCRIPCIÓN RESPONSABILIDAD PRIVILEGIOS

Usuario experto

Es la persona encargada de llevar a cabo la tarea de reestructura del código legado.

• Identificar el sistema a reestructurar. • Probar la funcionalidad del código

legado para que esté libre de errores de ejecución y compilación.

• Llevar a cabo la reestructura. • Reestructura de clases con baja

cohesividad. • Probar y validar la funcionalidad del

sistema.

• N/A


39

4.1.2. Diagrama de casos de uso. El diagrama de casos de uso de la figura 4.2. muestra el conjunto de casos de uso identificados para llevar a cabo las tarea de reestructura de código de los sistemas legados.

uc Diagrama de Casos de Uso

Usuario Experto

2.1. Crear plantilla genérica MVC

2. Reestructurar código legado

3. Cohesionar clases

2.2. Reestructurar micro-arquitecturas

2.2.3 Reestructurar clases

3.3 Crear clases

3.2 Super jerarquizar

3.1 Subjerarquizar

2.2.3.4 Reestructurar funciones

2.2.3.4.1.1 Crear función

2.2.3.4.1 Fragmentar función

2.2.3.1 Reubicar atributo

2.2.3.2 Crear constructor

2.2.1 Reestructurar micro-arquitecturas con

herencia

2.2.2 Reestructurar micro-arquitecturas

con composición1. Analizar el código legado

2.2.3.3 Fragmentar el main 2.2.3.4.1.2 Redefinir

llamada a funciones

«extend»

«include» «extend»

«extend»

«include» «include»

«extend» «include»«extend»

«extend»«extend»

«include»

«extend»

«include»

«include»«include»

Figura 4.3. Diagrama principal de casos de uso.

A continuación se listan los casos de uso identificados. Analizar el código legado. Reestructurar código legado. Crear plantilla genérica MVC. Reestructurar micro-arquitecturas. Reestructurar micro-arquitecturas con herencia (Este caso de uso incluye 12 variantes). Reestructurar micro-arquitecturas con composición (Este caso de uso incluye 5 variantes). Reestructurar clases (Este caso de uso incluye 2 variantes). Reubicar atributo Crear constructor Fragmentar el main (Este caso de uso incluye 2 variantes). Reestructurar funciones (Este caso de uso incluye 12 variantes). Fragmentar función. Crear función. Redefinir llamadas a funciones. Cohesionar clases. Subjerarquizar. Superjerarquizar. Crear clases.


40

4.1.2.1. Especificación del caso de uso: analizar el código legado.

Tabla 4.2. Descripción del caso de uso analizar el código legado. Nombre del C.U. CU-1. Analizar el código legado. Descripción Este caso de uso tiene como objetivo describir los eventos para llevar a cabo la

tarea de identificar los componentes de un marco de aplicaciones orientados a objetos (Clases, funciones y estatutos de código) y etiquetarlos conforme a la parte del patrón MVC correspondiente.

Pre-condiciones Identificar el conjunto de clases del marco en estudio. Flujo básico 1. Se analiza el conjunto de clases del marco en estudio.

2. Agregar a los estatutos de código de la vista la etiqueta “//EV”. 3. Agregar a los estatutos de código del control la etiqueta “//EC”. 4. Agregar a los estatutos de código del modelo la etiqueta “//EM”. 5. Agregar a las funciones especializadas en la vista la etiqueta “//FV”. 6. Agregar a las funciones especializadas en el control la etiqueta “//FC”. 7. Agregar a las funciones especializadas en el modelo la etiqueta “//FM”. 8. Agregar a las funciones no-especializadas la etiqueta “//FMz” 9. Agregar a las clases especializadas en la vista la etiqueta “//CV”. 10. Agregar a las clases especializadas en el control la etiqueta “//CC”. 11. Agregar a las clases especializadas en el modelo la etiqueta “//CM”. 12. Agregar a las clases no-especializadas la etiqueta “//CMz”. 13. Termina la identificación de componentes del marco.

Suposiciones • A partir de la identificación de los componentes se puede llevar a cabo la reestructura del código legado.

Poscondiciones • Los componentes del sistema legado quedan etiquetados de acuerdo a su parte correspondiente del patrón MVC.

4.1.2.2. Especificación del caso de uso: reestructurar código legado.

Tabla 4.3. Descripción del caso de uso reestructurar código legado.

Nombre del C.U. CU-2. Reestructurar código legado. Descripción Este caso de uso tiene como objetivo describir los eventos para llevar a cabo la

tarea de reestructura de código legado, conforme a la arquitectura MVC. Pre-condiciones • Deben estar desarrolladas todos los métodos heurísticos para aplicarlos a la

reestructura de código legado. • Los estatutos de código, funciones y clases deberán estar etiquetados según

la parte a la que correspondan. Flujo básico 1. El usuario selecciona la opción de reestructurar código legado.

2. La reestructura se lleva a cabo a nivel de micro-arquitectura. 3. La reestructura se lleva a cabo a nivel de clase. 4. La reestructura se lleva a cabo a nivel de función. 5. Se hacen pruebas de la funcionalidad del nuevo sistema reestructurado.

Suposiciones • Se debe incluir, la solución propuesta por los casos de uso “Análisis de código legado”, “Crear plantilla genérica MVC” y “reestructurar micro-arquitecturas”.

Poscondiciones • Se tiene un sistema funcional, reestructurado conforme al patrón MVC.


41

4.1.2.3. Especificación del caso de uso: crear plantilla genérica MVC.

Tabla 4.4. Descripción del caso de uso crear plantilla genérica MVC.

Nombre del C.U. CU-2.1. Crear plantilla genérica MVC. Descripción Este caso de uso tiene como objetivo describir los pasos para generar una

arquitectura de clases conforme al patrón Modelo, Vista, Control (MVC). Pre-condiciones • Se debe tener conocimiento de la arquitectura MVC, para diseñar un marco

de aplicaciones dividido en tres capas. Flujo de básico 1. Generar las interfaces para cada una de las partes del patrón MVC.

2. Generar las clases derivadas para cada una de las partes del patrón MVC. 3. Generar los constructores de las clases derivadas. 4. Generar las relaciones de agregación entre las diferentes clases derivadas. 5. Generar la clase cliente.

Suposiciones • Esta plantilla es la base de la reestructura del código legado. • Todo el código reestructurado debe ser reubicado a esta plantilla.

Poscondiciones • Se contará con una plantilla basada en el patrón MVC.

4.1.2.4. Especificación del caso de uso: reestructurar micro-arquitecturas.

Tabla 4.5. Descripción del caso de uso reestructurar micro-arquitecturas.

Nombre del C.U. CU-2.2. Reestructurar micro-arquitecturas. Descripción Este caso de uso tiene como objetivo analizar y reestructurar micro-

arquitecturas que implementan herencia y composición. Pre-condiciones • Se deben identificar en el sistema legado las relaciones de composición y

herencia, entre las clases que conforman el sistema. • Se utilizan las soluciones que generan los casos de uso “Reestructurar

micro-arquitecturas con composición” y “Reestructurar micro-arquitecturas con herencia” y “Reestructura de clases”.

Flujo básico 1. Identificar aquellas clases que tienen relaciones de composición y se utilizan las soluciones del caso de uso “Reestructurar micro-arquitecturas con composición”.

2. Identificar aquellas clases que tienen relaciones de herencia y se utilizan las soluciones del caso de uso “Reestructurar micro-arquitecturas con herencia”.

3. Termina el proceso de reestructura Suposiciones • La micro-arquitecturas quedan reestructuradas y reubicadas en la plantilla

MVC. Poscondiciones • Se tiene un sistema funcional, reestructurado conforme al patrón MVC.

4.1.2.5. Especificación del caso de uso: reestructurar micro-arquitecturas con herencia.

Tabla 4.6. Descripción del caso de uso reestructurar micro-arquitecturas con herencia. Nombre del C.U. CU-2.2.1. Reestructurar micro-arquitecturas con herencia. Descripción Este caso de uso tiene como objetivo describir los eventos para reestructurar

clases que implementan herencia.


42

Tabla 4.7. Escenario 1 del caso de uso reestructurar micro-arquitecturas con herencia.

intMezcabstract void funVista1()abstract void funModelo1()abstract void funMezc1()

cMezcint x

void funVista1()void funModelo1()void funMezc1()

public void funMezc1(){ System.out.println(x); est cont1; } //Esta función debe ser reestructurada.

Figura 4.4. Micro-arquitectura con herencia de interfaz.

oC oM

oV

publ ic static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.invoca();}

publ ic void invoca(){ oC.execute();}publ ic void funVista1(){ System.out.println(x); oC.funControl1();}

publ ic void funControl1(){ est cont1; }

aControlabstract void execute()abstract void funControl1()

cVistaaControl oCint x

cVista()cVista(aControl oC)void invoca()void funVista1()

aModeloabstract void unaAccion()abstract void funModelo1()

cControlaModelo oM

cControl(aModelo oM)void execute()void funControl1()


aVistaabstract void invoca()abstract void funVista1()

cModeloaVista oV

cModelo()void unaAccion()void funModelo1()

Figura 4.5. Reestructura conforme al patrón MVC del flujo básico del caso de uso.

ID Escenario 1 ID Heurística RH1 Pre-condiciones • Las clases derivadas extienden a las interfaces.

• La clase derivada puede implementar funciones especializadas y no- especializadas.

• Por ejemplo, ver figura 4.3. Flujo básico 1. Analizar las clases derivadas.

2. Fragmentar y reubicar las funciones no-especializadas de la clase derivada, utilizando la heurística H:10 (§ 5.1.7).

3. Reubicar las funciones especializadas de la clase derivada utilizando la heurística H:10 (§ 5.1.7).

4. Reubicar los atributos de la clase derivada utilizando la heurística H:5 (§ 5.1.6).

5. Termina el proceso de reestructura. Suposiciones • Debe de haberse generado el código de la plantilla MVC objetivo.

• Se cuenta con el método heurístico de reestructura: “Fragmentar funciones” y “Reubicar atributos”.

Poscondiciones • La micro-arquitectura en estudio queda reestructurada conforme al patrón MVC.

• Los datos son reubicados en las clases derivadas de la plantilla MVC que incluyen a las funciones que acceden a los datos.

• Para los casos que aplique, los datos inicializados son reubicados de la misma manera que la declaración de los datos.

• Por ejemplo, ver figura 4.4.


43


aMezcint x

aMezc()void funVista1()void funMezc1()

aMezc(){x = 10;}publ ic void funVista1(){}publ ic void funMezc1(){}

cMezcvoid funVista1()void funMezc1()

publ ic void funMezc1(){ x += 10; System.out.println("Res =" + x);}

Figura 4.6. Micro-arquitectura con herencia de atributos.

ID Escenario 2 ID Heurística RH2

Pre-condiciones • La clase base define funciones vacías excepto el constructor, lo que

significa que las funciones son implementadas en la clase derivada. • La clase derivada puede implementar funciones especializadas y no-

especializadas. • La clase derivada hereda atributos de la clase base. • Por ejemplo, ver figura 4.5.

Flujo básico 1. Analizar las funciones de las clases derivadas. 1.1. Fragmentar y reubicar las funciones no-especializadas de la clase

derivada utilizando la heurística H:10 (§ 5.1.7). 1.2. Reubicar las funciones especializadas de la clase derivada a la plantilla

MVC utilizando la heurística H:10 (§ 5.1.7). 1.3. Si en la clase derivada hay atributos declarados, entonces reubicarlos

utilizando la H:5 (§ 5.1.6). 1.4. Si los datos son inicializados en el constructor, también utilizar la

heurística H:5 (§ 5.1.6). 2. Analizar la clase base.

2.1. Reubicar los atributos declarados en la clase base utilizando la heurística H:5 (§ 5.1.6).

2.2. Si los atributos son inicializados en el constructor, también utilizar la heurística H:5 (§ 5.1.6).

3. Termina el proceso de reestructura. Suposiciones • La solución de este escenario aplica para la herencia de datos protegidos,

públicos y friendly. • Se cuenta con las heurísticas de reubicación de datos y reestructura de

funciones. • Cuando una función le cambia el valor a un atributo y este nuevo valor es

usado en otra función que se encuentra en diferente parte de la arquitectura MVC, entonces el valor se envía como parámetro.


• Los datos declarados de la clase base y la clase derivada quedan reubicados en las clases derivadas de la plantilla MVC que incluyen a las funciones que acceden a los datos.

• Para los casos que aplique, los datos inicializados son reubicados de la misma manera que la declaración de los datos.



44

oC oM

oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.invoca();}

public void invoca(){ oC.execute();}public void funVista2(int x){ System.out.println("Res =" + x); }

public void execute(){ oM.unaAcción(); }

cModelo(){x = 10;}public void funModelo1(){x += 10;oV.funVista2(x);}


cVistaaControl oC

cVista()cVista(aControl oC)void invoca()void funVista1()void funVista2(int x)


cControlaModelo oM



aVistaabstract void invoca()abstract void funVista1()abstract void funVista2(int x)

cModeloaVista oVint x


Figura 4.7. Arquitectura destino del escenario 2, del caso de uso reestructurar micro-arquitecturas con

herencia.

Para el escenario descrito en la tabla 4.8, existen varias combinaciones relacionadas al control de acceso de funciones, es decir, cuando la misma función en la clase base tiene un tipo de acceso diferente al de la función de la clase derivada. La solución propuesta en la tabla 4.8 también resuelve los casos de la tabla 4.9.

Tabla 4.9. Combinaciones del control de acceso de las funciones implicadas

Clase Base Clase Derivada Protected Protected Protected Public Protected Friendly Friendly Protected Friendly Public Friendly Friendly

Tabla 4.10. Escenario 3 del caso de uso reestructurar micro-arquitecturas con herencia. ID Escenario 3 ID Heurística RH3 Pre-condiciones • La clase base define funciones vacías que son implementadas en la clase

derivada. • La clase base declara atributos que son inicializados en el constructor y las

clases derivadas los heredan. • La clase derivada puede implementar funciones especializadas en diferentes

partes del patrón MVC. • La clase derivada puede implementar funciones especializadas y no-

especializadas. • Por ejemplo, ver figura 4.7.

Flujo básico 1. Analizar la clase derivada. 1.1. Fragmentar y reubicar las funciones no-especializadas de la clase

derivada utilizando la H:10 (§ 5.1.7). 1.2. Reubicar las funciones especializadas de la clase derivada a la plantilla

MVC utilizando la heurística H:10 (§ 5.1.7). 1.3. Si en la clase derivada existen atributos declarados, entonces

reubicarlos utilizando la heurística H:5 (§ 5.1.6).


45

aMezcint x

aMezc()void funVista1()void funMezc1()

aMezc(){x = 10;}publ ic void funVista1(){}publ ic void funMezc1(){}

cMezcint y

void funVista1()void funMezc1()

publ ic void funMezc1(){ y = x + 10; System.out.println("Res =" + y);}

Figura 4.8. Micro-arquitectura con herencia de atributos inicializados en el constructor.

oC oM

oV


public void invoca(){ oC.execute();}public void funVista2(int y){ System.out.println("Res =" + y); }

public void execute(){ oM.unaAcción(); }

cModelo(){x = 10;}public void funModelo1(){y = x +10;oV.funVista2(y);}


cVistaaControl oC

cVista()cVista(aControl oC)void invoca()void funVista1()void funVista2(int x)


cControlaModelo oM



aVistaabstract void invoca()abstract void funVista1()abstract void funVista2(int x)

cModeloaVista oVint xint y



herencia.


2. Analizar la clase base. 2.1. Reubicar la declaración de los atributos de la clase base y su

inicialización, utilizando la heurística H:5 (§ 5.1.6). 3. Termina el proceso de reestructura.

Suposiciones • La solución de este escenario aplica para la herencia de datos protegidos, públicos y friendly.

• Se debe contar con las heurísticas mencionadas anteriormente. Poscondiciones • La micro-arquitectura en estudio queda reestructurada conforme al patrón

MVC. • Los datos de la clase base y clase derivada, son reubicados en la clase

derivada correspondiente de la plantilla MVC, que incluye a las funciones que acceden a los datos.

• La inicialización de los datos es reubicada en los constructores de las clases derivadas de la plantilla MVC correspondientes, que incluyen a las funciones que acceden al dato inicializado.


ID Escenario 4


46

aMezcint x

aMezc()void funModelo1()void funVista1()

public void funModelo1(){}public void funVista1(){est vist1;}

cModeloint y

void funModelo1()

public void funModelo1(){ y = 10; x = 20; y *=x;}

Figura 4.10. Micro-arquitectura con herencia de atributos y funciones implementadas.

ID Heurística RH4

Pre-condiciones • La clase base define funciones vacías y funciones que implementan código. • Las clases derivadas son clases especializadas. • La clase base declara datos y no son inicializados. • Las clases derivadas heredan los datos declarados en la clase base. • Por ejemplo ver figura 4.9.

Flujo básico 1. Analizar la clase derivada. 1.1. Reubicar las funciones de la clase derivada utilizando la heurística H:10

(§ 5.1.7). 1.2. Reubicar los atributos de la clase derivada utilizando la heurística H:5

(§ 5.1.6). 1.3. Si los atributos de la clase derivada son inicializados en el constructor,

entonces reubicar la inicialización mediante la heurística H:5 (§ 5.1.6). 2. Analizar la clase base.

2.1. Reubicar las funciones especializadas de la clase base utilizando la Heurística H:10 (§ 5.1.7).

2.2. Reubicar los datos declarados en la clase base utilizando la H:5 (§ 5.1.6).

3. Termina el proceso de reestructura. Suposiciones • Se debe contar con las heurísticas de mencionadas anteriormente. Poscondiciones • La micro-arquitectura en estudio queda reestructurada conforme al patrón

MVC. • Los datos de la clase base y clase derivada, son reubicados en la clase

derivada correspondiente de la plantilla MVC, que incluye a las funciones que acceden a los datos.

• Para los casos que aplique, la inicialización de los datos es reubicada en los constructores de las clases derivadas de la plantilla MVC, que incluyen a las funciones que acceden al dato inicializado.



47

oC oM

oV


publ ic void invoca(){ oC.execute();}publ ic void funVista1(){est vist1;}

publ ic void exectue(){ oM.unaAccion(); }

publ ic void funModelo1(){ y = 10; x = 20; y *=x;}


cVistaaControl oC



cControlaModelo oM






Figura 4.11. Arquitectura destino del escenario 4, del caso de uso reestructurar reestructurar micro-

arquitecturas con herencia.


ID Escenario 5 ID Heurística RH5 Pre-condiciones • La clase base mezcla funciones especializadas e implementa funciones

vacías. • La clase base inicializa atributos en el constructor. • La clase derivada implementa funciones especializadas. • Por ejemplo, ver figura 4.11.

Flujo básico 1. Analizar la clase derivada. 1.1. Reubicar las funciones especializadas de la clase derivada, utilizando la

heurística H:10 (§ 5.1.7). 1.2. Reubicar los atributos de la clase derivada utilizando la heurística H:5

(§ 5.1.6). 1.3. Si los atributos de la clase derivada son inicializados, entonces

reubicarlos utilizando la heurística H:5 (§ 5.1.6). 2. Analizar la clase base.

2.1. Reubicar las funciones especializadas de la clase base utilizando la heurística H:10 (§ 5.1.7).

2.2. Reubicar los atributos de la clase base, utilizando la heurística H:5 (§ 5.1.6).

2.3. Reubicar la inicialización de los atributos de la clase base mediante la heurística H:5 (§ 5.1.6).

3. Termina el proceso de reestructura. Suposiciones • Se debe contar con las heurísticas de mencionadas anteriormente. Poscondiciones • La micro-arquitectura en estudio queda reestructurada conforme al patrón

MVC. • Los datos declarados en la clase base y en la clase derivada quedan

reubicados en las clases derivadas de la plantilla MVC que incluyen a las funciones que los acceden.

• La inicialización de los datos es reubicada en los constructores de las clases derivadas de la plantilla MVC, que incluyen a las funciones que acceden al dato inicializado.



48

aMezcint x

aMezc()void funModelo1()void funVista1()

aMezc(){ x = 20;}public void funModelo1(){}public void funVista1(){System.out.println(x);}

cModeloint y

void funModelo1()

public void funModelo1(){ y = 10; y *=x;}

Figura 4.12. Micro-arquitectura con herencia de atributos inicializados en el constructor.

oC oM

oV


cVista(){x = 20;}publ ic void invoca(){oC.execute();}publ ic void funVista1(){System.out.println(x);}


cModelo(){x = 20;}publ ic void funModelo1(){ y = 10; y *=x;}





cControlaModelo oM







arquitecturas con herencia. Tabla 4.13. Escenario 6 del caso de uso reestructurar micro-arquitecturas con herencia.

ID Escenario 6 ID Heurística RH6 Pre-condiciones

• La clase base implementa funciones especializadas y funciones no- especializadas.

• La clase base puede implementar sólo funciones especializadas. • La clase base declara atributos y éstos no son inicializados. • La clase derivada declara atributos. • La clase derivada implementa funciones especializadas y funciones no-

especializadas. • La clase derivada puede implementar funciones especializadas. • Por ejemplo, ver figura 4.13.


derivada, utilizando la heurística H:10 (§ 5.1.7). 1.2. Reubicar las funciones especializadas de la clase derivada utilizando la


49

aMezcint x

void funModelo1()void funMezc1()

public void funModelo1(){ x = 10 * 10;}public void funMezc1(){x = 10 * 5;System.out.println(x);}

cMezcint y


public void funModelo2(){ y = 10; x = 12 y *=x;}public void funMezc2(){y = 4*4;System.out.println(y);}

Figura 4.14. Micro-arquitectura con herencia de atributos sin herencia.

heurística H:10 (§ 5.1.7). 1.3. Los atributos de la clase derivada son reubicados utilizando la

heurística H:5 (§ 5.1.6). 1.4. Sí los datos de la clase derivada son inicializados, entonces reubicarlos

utilizando la heurística H:5 (§ 5.1.6). 2. Analizar la clase base.

2.1. Fragmentar y reubicar las funciones no-especializadas de la clase base, utilizando la heurística H:10 (§ 5.1.7).

2.2. Reubicar las funciones especializadas de la clase base, utilizando la H:10 (§ 5.1.7).

2.3. Reubicar los datos declarados en la clase base utilizando la heurística H:5 (§ 5.1.6)

3. Termina el proceso de reestructura. Suposiciones • La clase base sólo hereda datos sin ser inicializados en el constructor.

• Se debe contar con las heurísticas de “Reubicar atributos” y “Fragmentar funciones”.

• La solución presentada en el flujo básico, también aplica para aquellas clases que son especializadas.


• Los datos declarados en la clase base y en la clase derivada quedan reubicados en las clases derivadas de la plantilla MVC que incluyen a las funciones que los acceden.




50

oC oM

oV


public void funVista1(int x){System.out.println(x);}public void funVista2(int y){System.out.println(y);}

public void exectue(){ oM.unaAccion(); }

public void funModelo1(){ x = 10 * 10;}public void funModelo2(){ y = 10; x = 12 y *=x;}public void funModelo3(){x = 10 * 5;oV.funVista1(x);}public void funModelo4(){y = 4 * 4;oV.funVista2(y);}


cVistaaControl oC

cVista()cVista(aControl oC)void invoca()void funVista1(int x)void funVista2(int y)

aModeloabstract void unaAccion()abstract void funModelo1()abstract void funModelo2()abstract void funModelo3()abstract void funModelo4()

cControlaModelo oM



aVistaabstract void invoca()abstract void funVista1(int x)abstract void funVista2(int y)


cModelo()void unaAccion()void funModelo1()void funModelo2()void funModelo3()void funModelo4()




ID Escenario 7 ID Heurística RH7 Pre-condiciones

• La clase base implementa funciones especializadas y funciones no- especializadas.

• Otro caso es que la clase base incluya sólo funciones especializadas. • La clase base declara e inicializa atributos en el constructor y los hereda. • La clase derivada incluye funciones especializadas y funciones no-

especializadas. • Otro caso es que la clase derivada incluya sólo funciones especializadas. • Por ejemplo, ver figura 4.15.

Flujo básico 1. Analizar la clase derivada. 1.1. Fragmentar y reubicar las funciones no especializadas de la clase


heurística H:10 (§ 5.1.7). 1.3. Los atributos de la clase derivada son reubicados utilizando la

heurística H:5 (§ 5.1.6). 1.4. Sí los datos de la clase derivada son inicializados, entonces reubicarlos

utilizando la heurística H:5 (§ 5.1.6). 2. Analizar la clase base.



2.3. Reubicar los datos declarados en la clase base utilizando la heurística H:5 (§ 5.1.6).

2.4. Reubicar la inicialización de los datos de la clase base, utilizando la heurística H:5 (§ 5.1.6).


públicos y friendly. • Se debe contar con las heurísticas de “Reubicar atributos”. • La solución presentada en el flujo básico, también aplica para aquellas


51

aMezcint x

aMezc()void funModelo1()void funMezc1()

aMezc(){x = 10;}public void funModelo1(){ x* = 10;}public void funMezc1(){x *= 15;System.out.println(x);}

cMezcint y


public void funModelo2(){ y = 10; y *=x;}public void funMezc2(){y = 4*4;System.out.println(y);}

Figura 4.16. Micro-arquitectura con herencia de atributos inicializados.

oC oM

oV


public void funVista1(int x){System.out.println(x);}public void funVista2(int y){System.out.println(y);}


cModelo(){x = 10;}public void funModelo1(){ x*= 10;}public void funModelo2(){ y = 10; y *=x;}public void funModelo3(){x *=15;oV.funVista1(x);}public void funModelo4(){y = 4 *4;oV.funVista2(y);}


cVistaaControl oC

cVista()cVista(aControl oC)void invoca()void funVista1(int x)void funVista2(int y)

aModeloabstract void unaAccion()abstract void funModelo1()abstract void funModelo2()abstract void funModelo3()abstract void funModelo4()cControl

aModelo oM



aVistaabstract void invoca()abstract void funVista1(int x)abstract void funVista2(int y)


cModelo()void unaAccion()void funModelo1()void funModelo2()void funModelo3()void funModelo4()



clases que son especializadas. Poscondiciones • La micro-arquitectura analizada queda reestructurada conforme al patrón






52


ID Escenario 8 ID Heurística RH8 Pre-condiciones • La clase base implementa funciones especializadas.

• La clase base inicializa atributos en el constructor y las clases derivadas los heredan.

• La clase derivada implementa funciones especializadas que reemplazan a las funciones de la clase base.

• La clase derivada declara datos. • Las funciones de la clase base y de la clase derivada pertenecen a una

misma parte del patrón MVC. • Por ejemplo, ver figura 4.17.

Flujo básico 1. Sí las clases son especializadas en el modelo, entonces generar una nueva clase llamada “ccModelo”. 1.1. Subjerarquizar la nueva clase creada, a la clase “cModelo”, utilizando

la heurística H:6. 2. Sí las clases son especializadas en la vista, entonces generar una nueva clase

llamada “ccVista”, utilizando la heurística H:2 (§ 5.1.3). 2.1. Subjerarquizar la nueva clase creada, a la clase “cVista”, utilizando la

heurística H:6. 3. Sí las clases son especializadas en el control, entonces generar una nueva

clase llamada “ccControl”, , utilizando la heurística H:2 (§ 5.1.3). 3.1. Subjerarquizar la nueva clase creada, a la clase “cControl”, utilizando

la heurística H:6. 4. Reubicar los atributos de la clase derivada en la nueva clase generada,

utilizando la heurística H:5 (§ 5.1.6). 5. Reubicar las funciones de la clase derivada en la nueva clase generada,

utilizando la heurística H:10 (§ 5.1.7). 6. Reubicar los datos de la clase base a la clase derivada correspondiente,

utilizando la heurística H:5 (§ 5.1.6). 7. Reubicar la inicialización de los datos de la clase base, en el constructor de

la clase derivada intermedia correspondiente, utilizando la heurística H:5 (§ 5.1.6).

8. Reubicar las funciones de la clase base en la clase derivada intermedia correspondiente, utilizando la heurística H:10 (§ 5.1.7).

9. Termina el proceso de reestructura. Suposiciones • Se presenta una solución genérica, para las tres partes del patrón MVC.

• Se debe contar con las heurísticas mencionadas anteriormente. Poscondiciones • La micro-arquitectura analizada queda reestructurada conforme al patrón

MVC. • Las nuevas clases derivadas, heredan el objeto que facilita la interacción

entre las diferentes partes del patrón MVC. • Los datos declarados en la clase base y en la clase derivada quedan





53

aModeloint x

aModelo()void funModelo1()

aModelo(){x = 10;}publ ic void funModelo1(){ x* = 10;}

cModeloint y

void funModelo1()

publ ic void funModelo1(){ y = 10; y *=x;super.funModelo1();}

Figura 4.18. Micro-arquitectura con herencia de atributos inicializados en el constructor y

reemplazo de funciones especializadas por funciones especializadas en una misma parte del patrón MVC.

oC oM

oV


public void invoca(){ oC.execute();}


cModelo(){x = 10;}public void funModelo1(){ x*= 10;}


cVistaaControl oC

cVista()cVista(aControl oC)void invoca()

aModelo1abstract void unaAccion()abstract void funModelo1()

cControlaModelo oM






ccModeloint y

void funModelo1()

class ccModelo extends cModelo() { private int y; public void funModelo1(){ y = 10; y *=x; super.funModelo1(); }}

Figura 4.19. Arquitectura destino del escenario 8, del caso de uso reestructurar

micro-arquitecturas con herencia.

Tabla 4.16. Escenario 9 del caso de uso reestructurar micro-arquitecturas con herencia. ID Escenario 9 ID Heurística RH9 Pre-condiciones • La clase base incluye funciones especializadas, con implementación de

código. • La clase base inicializa atributos en el constructor. • Las funciones de la clase base y de la clase derivada, son de diferente parte

del patrón MVC. • Las funciones de la clase derivada hacen peticiones de servicios a las

funciones de la clase base. • Las funciones de la clase derivada, heredan atributos de la clase base. • Por ejemplo, ver figura 4.19.

Flujo básico 1. Analizar la clase derivada. 1.1. Reubicar las funciones de la clase derivada, utilizando la heurística

H:10 (§ 5.1.7). 1.2. Si la clase derivada declara atributos, estos deben ser reubicados

utilizando la heurística H:5 (§ 5.1.6). 1.3. Si los atributos de la clase derivada son inicializados en el constructor,

la inicialización debe ser reubicada utilizando la heurística H:5 (§ 5.1.6).

2. Analizar la clase base.


54

aModeloint x



cVistaint y

void funVista1()

publ ic void funVista1(){System.out.println(x);super.funModelo1();}


sobre-escritura de funciones especializadas, por funciones de diferente parte del patrón MVC.

oC oMoV


cVista(){x = 10;}publ ic void funVista1(){System.out.println(x);oC.oM.funModelo1();}


cModelo(){x = 10;}publ ic void funModelo1(){ x*= 10;}


cVista1aControl oCint xint y



cControlaModelo oM







herencia.

2.1. Reubicar las funciones de la clase base, utilizando la heurística H:10 (§ 5.1.7).

2.2. Reubicar los atributos de la clase base, utilizando la H:5 (§ 5.1.6). 2.3. Reubicar la inicialización de los atributos de la clase base, utilizando la

heurística H:5. (§ 5.1.6). 2.4. Redefinir las llamadas entre las funciones, utilizando la heurística H:11

(§ 5.1.8). 3. Termina el proceso de reestructura.

Suposiciones • Se presenta una solución genérica, para las tres partes del patrón MVC. • La solución de este escenario también aplica para los casos de la tabla 4.6. • Se debe contar con las heurísticas mencionadas arriba.

Poscondiciones • La micro-arquitectura analizada queda reestructurada conforme al patrón MVC.



• La cláusula super utilizada para llamar a funciones de la clase base es sustituida por los objetos correspondientes definidos en la plantilla MVC.



55


ID Escenario 10 ID Heurística RH10 Pre-condiciones • La clase base implementa funciones especializadas.

• La clase base inicializa datos en el constructor. • La clase derivada puede implementar funciones especializadas y funciones

no-especializadas. • La clase derivada puede implementar funciones especializadas en diferentes

partes del patrón MVC. • Las funciones de la clase derivada hacen peticiones de servicios a las

funciones de la clase base. • Las funciones de la clase derivada, heredan atributos de la clase base. • Por ejemplo, ver figura 4.21.



heurística H:10 (§ 5.1.7). 1.3. Reubicar los atributos de la clase derivada, utilizando la heurística H:5

(§ 5.1.6). 1.4. Sí los datos de la clase derivada son inicializados, reubicar la

inicialización de los datos utilizando la heurística H:5 (§ 5.1.6). 2. Analizar la clase base.

2.1. Reubicar las funciones de la clase base, utilizando la heurística H:10 (§ 5.1.7).

2.2. Reubicar los atributos de la clase base, utilizando la heurística H:5 (§ 5.1.6).

2.3. Reubicar la inicialización de los atributos de la clase base, utilizando la heurística H:5 (§ 5.1.6).

2.4. Redefinir las llamadas entre las funciones, utilizando la heurística H:11 (§ 5.1.8).

4. Termina el proceso de reestructura. Suposiciones • La solución de esté escenario también aplica para los casos de la tabla 4.6.

• Se debe contar con las heurísticas mencionadas arriba. Poscondiciones • La micro-arquitectura analizada queda reestructurada conforme al patrón







56

aModeloint x



cMezcint y

void funMezc1()void funControl1()void funVista1()

publ ic void funMezc1(){y = 10;y *=x;super.funModelo1();System.out.println(x);}


sobre-escritura de funciones especializadas por funciones no especializadas.

oC oM


cVista(){x = 10;}publ ic void funVista1(){System.out.println(x);}


cModelo(){x = 10;}publ ic void funModelo1(){ x*= 10;}publ ic void funModelo2(){y = 10;y*=x;oV.funVista1();funModelo1();}




aModeloabstract void unaAccion()abstract void funModelo1()abstract void funModelo2()

cControlaModelo oM





cModelo()void unaAccion()void funModelo1()void funModelo2()

Figura 4.23.Arquitectura destino del escenario 10, del caso de uso reestructurar

micro-arquitecturas con herencia.

Tabla 4.18. Escenario 11 del caso de uso reestructurar micro-arquitecturas con herencia. ID Escenario 11 ID Heurística RH11 Pre-condiciones • La clase base implementa funciones especializadas y funciones no-

especializadas. • La clase base implementa funciones especializadas en diferente parte del

patrón MVC. • La clase base inicializa atributos en el constructor. • La clase derivada es especializada. • Las funciones de la clase derivada hacen peticiones de servicio a las

funciones de la clase base. • Por ejemplo, ver figura 4.23.

Flujo básico 1. Analizar las funciones de la clase derivada. 1.1. Reubicar las funciones de la clase derivada utilizando la heurística H:10

(§ 5.1.7). 1.2. Si existen atributos en la clase derivada, entonces reubicarlos utilizando

la heurística H:5 (§ 5.1.6). 1.3. Sí los atributos de la clase derivada son inicializados en el constructor,


57

publ ic void funModelo1(){x* = 10;z = x;super.funVista1();super.funMezc1();}

aMezc(){x = 10;}publ ic void funMezc1(){y = 10;y*=x;System.out.println(x);}publ ic void funVista1(){est vist1;}

aMezcint xint y

aMezc()void funMezc1()void funVista1()

cModeloint z

void funModelo1()

Figura 4.24. Micro-arquitectura con herencia de atributos inicializados en el constructor y sobre-escritura de funciones no especializadas por funciones especializadas.

entonces reubicar la inicialización utilizando la heurística H:5 (§ 5.1.6). 2. Analizar las funciones de la clase base.



2.3. Reubicar los atributos de la clase base utilizando la heurística H:5 (§ 5.1.6).

2.4. Reubicar la inicialización de los atributos utilizando la heurística H:5 (§ 5.1.6).

3. Termina el proceso de reestructura. Suposiciones • La solución de este escenario también aplica para los casos de la tabla 4.6.

• Se debe contar con las heurísticas mencionadas anteriormente. Poscondiciones • La micro-arquitectura analizada queda reestructurada conforme al patrón







58

oC oMoV


cVista(){x = 10;}publ ic void funVista1(){est vist1;}publ ic void funVista2(){System.out.println(x);}


cModelo(){x = 10;}publ ic void funModelo1(){x* = 10;z = x;oV.funVista1();funModelo2();}publ ic void funModelo2(){y = 10;y*=x;oV.funVista2();}



cVista()cVista(aControl oC)void invoca()void funVista1()void funVista2()


cControlaModelo oM



aVistaabstract void invoca()abstract void funVista1()abstract void funVista2()

cModeloaVista oVint xint yint z


Figura 4.25. Arquitectura destino del escenario 11, del caso de uso reestructurar micro-arquitecturas

con herencia.

Tabla 4.19. Escenario 12 del caso de uso reestructurar micro-arquitecturas con herencia. ID Escenario 12 ID Heurística RH12 Pre-condiciones • La clase base implementa funciones especializadas y no-especializadas.

• La clase base puede implementar funciones especializadas en diferente parte del patrón MVC.

• La clase base inicializa atributos en el constructor. • La clase derivada puede implementar funciones especializadas y no-

especializadas. • La clase derivada puede implementar funciones especializadas en diferente

parte del patrón MVC. • Las funciones de la clase derivada hacen peticiones de servicio a las

funciones de la clase base. • Por ejemplo, ver figura 4.25.


derivada utilizando la heurística H:10 (§ 5.1.7). 1.2. Reubicar las funciones especializadas de la clase derivada utilizando la

heurística H:10 (§ 5.1.7). 1.3. Si existen atributos en la clase derivada, entonces reubicarlos,

utilizando la heurística H:5 (§ 5.1.6). 1.4. Si los atributos de la clase derivada son inicializados en el constructor,

entonces reubicar la inicialización utilizando la heurística H:5 (§ 5.1.6). 2. Analizar la clase base.



2.3. Reubicar los atributos de la clase base utilizando la heurística H:5 (§ 5.1.6).

2.4. Reubicar la inicialización de los datos utilizando la heurística H:5 (§ 5.1.6).


59

publ ic void funModelo1(){ x* = 10;super.funVista1();}publ ic void funMezc2(){ y = 20; y *=30; System.out.println(y); super.funMezc1();}

aMezc(){x = 10;}publ ic void funMezc1(){y = 10;y*=x;System.out.println(x);}publ ic void funVista1(){est vist1;}

aMezcint xint y

aMezc()void funMezc1()void funVista1()

cMezcvoid funModelo1()void funMezc1()


sobre-escritura de funciones no especializadas por funciones no especializadas.

oC oMoV


cVista(){x = 10;}publ ic void funVista1(){est vist1;}publ ic void funVista2(){System.out.println(x);}publ ic void funVista3(int y){System.out.println(y);}


cModelo(){x = 10;}publ ic void funModelo1(){x* = 10;oV.funVista1();}publ ic void funModelo2(){y = 10;y*=x;oV.funVista2();}publ ic void funModelo3(){y = 20;y*=30;oV.funVista3(y);funModelo2();}



cVista()cVista(aControl oC)void invoca()void funVista1()void funVista2()void funVista3(int y)

aModeloabstract void unaAccion()abstract void funModelo1()abstract void funModelo2()abstract void funModelo3()

cControlaModelo oM



aVistaabstract void invoca()abstract void funVista1()abstract void funVista2()abstract void funVista3(int y)

cModelo1aVista oVint xint y

cModelo()void unaAccion()void funModelo1()void funModelo2()void funModelo3()

Figura 4.27. Arquitectura destino del escenario 12, del caso de uso reestructurar micro-arquitecturas

con herencia.


públicos y friendly. • La solución de esté escenario también aplica para los casos de la tabla 4.6. • Se debe contar con las heurísticas mencionadas anteriormente.

Poscondiciones • La micro-arquitectura analizada queda reestructurada conforme al patrón MVC.






60

4.1.2.6. Especificación del caso de uso: reestructurar micro-arquitecturas con composición.

Tabla 4.20. Descripción del caso de uso reestructurar micro-arquitecturas con composición.

Tabla 4.21. Escenario 1 del caso de uso reestructurar micro-arquitecturas con composición.

ocV

publ ic void funVista1(){ est vist1; ocV.funVista2();}

cVista2float y

void funVista2()

cVista1int x

void funVista1()

Figura 4.28. Clase especializada agregando por composición a otra clase, ambas especializadas en la misma parte del patrón MVC.

Nombre del C.U. CU-2.2.2. Reestructurar micro-arquitecturas con composición. Descripción Este caso de uso tiene como objetivo describir los eventos para reestructurar

clases que implementan composición.

ID Escenario 1 ID Heurística RC1 Pre-condiciones • Una clase en estudio agrega por composición a otra clase.

• Ambas clases son especializadas en (el modelo, la vista o el control). • Por ejemplo ver la figura 4.27.

Flujo básico 1. Analizar ambas clases. 1.1. Reubicar las funciones especializadas de ambas clases utilizando la

heurística H:10 (§ 5.1.7). 1.2. Si las clases implicadas incluyen atributos, estos deben ser reubicados

en la clase de la plantilla MVC que incluye a las funciones que lo acceden, mediante la Heurística H:5 (§ 5.1.6).

2. Termina el proceso de reestructura. Suposiciones • El código de las clases es funcional y está libre de errores.

• Se cuenta con los métodos heurísticos para reubicar las funciones y datos. • La solución de este escenario aplica para las clases que son especializadas

en la vista, control y el modelo. Poscondiciones • Las funciones y atributos quedan reubicados en la parte correspondiente de

la arquitectura MVC. • Las peticiones de servicios a las funciones de la clase agregada se llevan a

cabo eliminado el objeto y sólo se hace la llamada a la función a través del nombre de la clase.

• Por ejemplo ver figura 4.28.


61

oC oM

oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.funVista1(); oV.invoca();}

public void invoca(){ oC.execute();}public void funVista1(){ est vist1; funVista2();}

public void execute(){ oM.unaAccion();}

publ ic void unaAccion(){ // }


cVistaaControl oCint xfloat y



cControlaModelo oM




cModeloaVista oV


Figura 4.29. Arquitectura destino de dos clases agregadas por composición que

pertenecen a la misma parte del patrón MVC.


ocC

publ ic void funVista1(){ est vist1; ocC.funControl1();}

cControlfloat y

void funControl1()

cVistaint x

void funVista1()

Figura 4.30. Clase especializada agregando por composición a otra clase, las clases son especializadas en diferente parte del patrón MVC.

ID Escenario 2 ID Heurística RC2 Pre-condiciones • Una clase en estudio agrega por composición a otra clase.

• Las clases implicadas son especializadas en diferente parte del patrón MVC. • Por ejemplo ver la figura 4.29.

Flujo básico 1. Analizar ambas clases. 1.1. Reubicar las funciones especializadas de ambas clases utilizando la

heurística H:10 (§ 5.1.7). 1.2. Si las clases implicadas incluyen atributos, estos deben ser reubicados

en la clase de la plantilla MVC que incluye a las funciones que los acceden, mediante la Heurística H:5 (§ 5.1.6).


• Se cuenta con los métodos heurísticos para reubicar las funciones y datos. • La solución de este escenario aplica para las clases que son especializadas

en la vista, control y el modelo. Poscondiciones • Las funciones y atributos quedan reubicados en la parte correspondiente de

la arquitectura MVC. • Las peticiones de servicios a las funciones de la clase agregada se llevan a

cabo sustituyendo el objeto original por el correspondiente utilizando la heurística H:11 (§ 5.1.8).



62

oC oM

oV

publ ic static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.funVista1(); oV.invoca();}

publ ic void invoca(){ oC.execute();}publ ic void funVista1(){ est vist1; oC.funControl1();}

publ ic void execute(){ oM.unaAccion();}

publ ic void unaAccion(){ // }





cControlaModelo oMfloat y




cModeloaVista oV


Figura 4.31. Arquitectura destino de dos clases agregadas por composición

especializadas en diferente parte del patrón MVC.

Tabla 4.23. Escenario 3 del caso de uso reestructurar micro-arquitecturas con composición. ID Escenario 3 ID Heurística RC3 Pre-condiciones • Una clase en estudio especializada agrega por composición a una clase no-

especializada. • La clase especializada puede ser especializada en el modelo o en la vista o

en el control. • Por ejemplo ver la figura 4.31.

Flujo básico 1. Analizar la clase especializada. 1.1. Reubicar las funciones de la clase especializada utilizando la heurística

H:10 (§ 5.1.7). 1.2. Si la clase incluye atributos, estos deben ser reubicados en la clase de

la plantilla MVC que incluye a las funciones que los acceden, utilizando la heurística H:5 (§ 5.1.6).

2. Analizar la clase no-especializada. 2.1. Reubicar las funciones especializadas utilizando la heurística H:10 (§

5.1.7). 2.2. Fragmentar las funciones no-especializadas utilizando la heurística

H:10 (§ 5.1.7) . 2.3. Si la clase incluye atributos, estos deben ser reubicados en la clase de

la plantilla MVC que incluye a las funciones que los acceden, mediante la heurística H:5 (§ 5.1.6).


• Se cuenta con los métodos heurísticos mencionados arriba. • Esta solución aplica para los siguientes casos:

1. Clase especializada en la vista agrega por composición a una clase no-especializada.

2. Clase especializada en el control agrega por composición a una clase no-especializada.

3. Clase especializada en el modelo agrega por composición a una clase no-especializada.

Poscondiciones • Las funciones y atributos quedan reubicados en la parte correspondiente de la arquitectura MVC.

• Las funciones no-especializadas de la clase no-especializada son fragmentadas utilizando la heurística H:10 (§ 5.1.7).

• Las peticiones de servicio a las funciones de la clase agregada se llevan a


63

ocMz

publ ic void funVista1(){ est vist1; ocMz.funControl1(); ocMz.funModelo1();}

cMezcfloat y

void funVista2()void funControl1()void funModelo1()

cVistaint x

void funVista1()

publ ic void funModelo1(){ est mod1; y = 10 + 11.2;}

Figura 4.32. Clase especializada agregando por composición a una clase no-especializada.

oC oM


publ ic void invoca(){ oC.execute();}publ ic void funVista1(){ est vist1; oC.funControl1(); oC.oM.funModelo1(); }

publ ic void execute(){ oM.unaAccion();}






cControlaModelo oM




cModeloaVista oVfloat y


oV

Figura 4.33. Arquitectura destino conforme al patrón MVC de una clase especializada que agrega por

composición a una clase no-especializada.


cabo sustituyendo el objeto original por el correspondiente utilizando la heurística H:11 (§ 5.1.8).


ID Escenario 4 ID Heurística RC4 Pre-condiciones • Una clase en estudio no-especializada agrega por composición a una clase

especializada. • Por ejemplo ver la figura 4.33.

Flujo básico 1. Analizar la clase no-especializada. 1.1. Fragmentar las funciones no-especializadas utilizando la heurística

H:10 (§ 5.1.7). 1.2. Reubicar las funciones especializadas utilizando la heurística H:10 (§

5.1.6). 1.3. Si la clase incluye atributos, estos deben ser reubicados en la clase de

la plantilla MVC que incluye a las funciones que lo acceden mediante la heurística H:5 (§ 5.1.6).

2. Analizar la clase especializada.


64

ocMz

publ ic void funVista1(){ est vist1; ocMz.funModelo1();}publ ic void funControl1(){ ocMz.funModelo2();}


cMezc2float y

void funModelo1()void funModelo2()void funModelo3()

cMezc1int x

void funVista1()void funControl1()

Figura 4.34. Clase no-especializada agregando por composición a una clase no-especializada.

oC oM


publ ic void invoca(){ oC.execute();}publ ic void funVista1(){ est vist1; oC.oM.funModelo1(); }

publ ic void funControl1(){ oM.funModelo2();}





aModeloabstract void unaAccion()abstract void funModelo1()abstract void funModelo2()abstract void funModelo3()

cControlaModelo oM





cModelo()void unaAccion()void funModelo1()void funModelo2()void funModelo3()

oV

Figura 4.35. Arquitectura destino conforme al patrón MVC del caso donde una clase no-especializada

que agrega por composición a una clase no-especializada.

2.1. Reubicar las funciones de la clase especializada utilizando la heurística H:10 (§ 5.1.7).

2.2. Si la clase incluye atributos, estos deben ser reubicados en la clase de la plantilla MVC que incluye a las funciones que lo acceden, utilizando la heurística H:5 (§ 5.1.6).


• Se cuenta con los métodos heurísticos mencionados arriba. • Esta solución aplica para los siguientes casos:

1. Clase no-especializada agrega por composición a una clase especializada en la vista.

2. Clase no-especializada agrega por composición a una clase especializada en el control

3. Clase no-especializada agrega por composición a una clase especializada en el modelo.

Poscondiciones • Las funciones y atributos quedan reubicados en la parte correspondiente de la arquitectura MVC.

• Las funciones no-especializadas de la clase no-especializada deben ser fragmentadas utilizando la heurística H:10 (§ 5.1.7).

• La petición de servicios a las funciones de la clase agregada se llevan a cabo sustituyendo el objeto original por el correspondiente utilizando la heurística H:11 (§ 5.1.8).



65


ocMz

publ ic void funVista1(){ est vist1; ocMz.funControl2(); ocMz.funModelo1(); }publ ic void funControl1(){ ocMz.funModelo1();}


cMezc2float y

void funModelo1()void funControl2()

cMezc1int x

void funVista1()void funControl1()

Figura 4.36. Clase no-especializada agregando por composición a una clase no-especializada.

oC oM

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.funVista1(); oV.invoca();}

public void invoca(){ oC.execute();}public void funVista1(){ est vist1; oC.funControl2(); oC.oM.funModelo1(); }

public void funControl1(){ oM.funModelo1();}

public void funModelo1(){ est mod1; y = 10 + 11.2;}

oV

aControlabstract void execute()abstract void funControl1()abstract void funControl2()


cVista(aControl oC)void invoca()void funVista1()


cControlaModelo oM

cControl(aModelo oM)void execute()void funControl1()void funControl2()





Figura 4.37. Arquitectura destino conforme al patrón MVC de una clase no-especializada agregando por

composición a otra no-especializada.

ID Escenario 5 ID Heurística RC5 Pre-condiciones • Una clase en estudio no-especializada agrega por composición a una clase

no-especializada. • Por ejemplo ver la figura 4.35.

Flujo básico 1. Analizar las clases no-especializadas. 1.1. Fragmentar las funciones no-especializadas utilizando la heurística

H:10 (§ 5.1.7). 1.2. Reubicar las funciones especializadas utilizando la heurística H:10 (§

5.1.7). 1.3. Si la clase incluye atributos, estos deben ser reubicados en la clase de

la plantilla MVC que incluye a las funciones que lo acceden. Utilizando la heurística H:5 (§ 5.1.6).


• Se cuenta con los métodos heurísticos mencionados anteriormente. Poscondiciones • Las funciones y atributos quedan reubicados en la parte correspondiente de

la arquitectura MVC. • La petición de servicio a las funciones de la clase agregada se llevan a cabo

sustituyendo el objeto original por el correspondiente utilizando la heurística H:11 (§ 5.1.8).



66

4.1.2.7. Especificación del caso de uso: reestructurar clases.

Tabla 4.26. Descripción del caso de uso reestructurar clases.

Tabla 4.27. Escenario 1 del caso de uso reestructurar clases.

cVistaint xfloat y

void funVista1()void funVista2()void funVista3()

Figura 4.38. Clase especializada en la vista.

Nombre del C.U. CU-2.2.3. Reestructurar clases. Descripción Este caso de uso tiene como objetivo describir los eventos para reestructurar

clases

ID Escenario 1 ID Heurística RCls1 Pre-condiciones • Una clase en estudio es especializada.

• La clase puede ser especializada en la vista o en el control o en el modelo. • Por ejemplo ver la figura 4.37.

Flujo básico 1. Analizar la clase en estudio. 1.1. Reubicar las funciones en su clase correspondiente utilizando la

heurística H:10 (§ 5.1.7). 1.2. Si la clase en estudio incluye atributos, estos deben ser reubicados en

la clase de la plantilla MVC que incluye a las funciones que lo acceden mediante la Heurística H:5 (§ 5.1.6).

2. Termina el proceso de reestructura. Suposiciones • El código de la clase es funcional y está libre de errores.

• Se cuenta con los métodos heurísticos mencionados anteriormente. Poscondiciones • Las funciones y atributos quedan reubicados en la parte correspondiente de

la arquitectura MVC. • La petición de servicios a las clases especializadas debe hacerse de manera

adecuada utilizando la heurística H:11 (§ 5.1.8). • Por ejemplo ver figura 4.38.


67

oC oM oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.funVista1(); oV.funVista2(); oV.funVista3(); oV.invoca();}

public void invoca(){ oC.execute();}


public void unaAccion(){ // }

aControlvoid abstract execute()

cVista2aControl oCint xfloat y

cVista(aControl oC)void funVista1()void funVista2()void funVista3()void invoca()

aModelovoid abstract unaAccion()

cControlaModelo oM



aVistavoid abstract invoca()

cModeloaVista oV


oV

Figura 4.39. Arquitectura destino conforme al patrón MVC de una clase especializada.

.

Tabla 4.28. Escenario 2 del caso de uso reestructurar clases.

cMezcint xfloat y

void funVista1()void funControl1()void funModelo1()

publ ic void funVista1(){ System.out.println(x); System.out.println(y);}publ ic void funModelo1{ x = 12 +10;}

Figura 4.40. Clase no-especializada.

ID Escenario 2 ID Heurística RCls2 Pre-condiciones • Una clase en estudio es no-especializada.

• Por ejemplo ver la figura 4.39. Flujo básico 1. Analizar la clase en estudio.

1.1. Fragmentar las funciones no-especializadas utilizando la heurística H:10 (§ 5.1.7).

1.2. Reubicar las funciones especializadas en la clase correspondiente de la plantilla MVC, utilizando la heurística H:10 (§ 5.1.7).

1.3. Si la clase en estudio incluye atributos, éstos deben ser reubicados en la clase de la plantilla MVC que incluye a las funciones que lo acceden, utilizando la Heurística H:5 (§ 5.1.6).

2. Termina el proceso de reestructura. Suposiciones • El código de la clase es funcional y está libre de errores.

• Se cuenta con los métodos heurísticos mencionados anteriormente. • Las clases pueden incluir funciones especializadas en diferente parte del

patrón MVC o también incluir no-especializadas. Poscondiciones • Las funciones y atributos quedan reubicados en la parte correspondiente de

la arquitectura MVC. • La petición de servicios a las clases especializadas debe hacerse de manera

adecuada utilizando la heurística H:11 (§ 5.1.8). • Por ejemplo ver figura 4.40.


68

oC oM

oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.funVista1(); oV.oC.oM.funModelo1(); oV.invoca();}

public void invoca(){ oC.execute();}public void funVista1(){ System.out.println(x); System.out.println(y);}


public void funModelo1(){ x = 12 + 10; }


cVistaaControl oCint xfloat y

cVista(aControl oC)void invoca()void funVista1()


cControlaModelo oM






oV

Figura 4.41. Arquitectura destino conforme al patrón MVC de una clase no-especializada.

4.1.2.8. Especificación del caso de uso: reubicar atributo.

Tabla 4.29. Descripción del caso de uso reubicar atributo. Nombre del C.U. CU-2.2.3.1. Reubicar atributo. Descripción Este caso de uso describe los eventos para reubicar los atributos de las clases

legadas, en la clase de la plantilla MVC que incluye a las funciones que los acceden.

Pre-condiciones • Debe de haberse generado la plantilla MVC para incluir a los atributos. • Las funciones que acceden a los atributos ya deben de haber sido

reubicadas en alguna de las clases concretas de la plantilla. Flujo básico 1. Abrir el archivo que contiene la clase con atributos.

2. Identificar los atributos. 3. Almacenar los atributos en un vector. 4. Si los atributos son inicializados agregar al vector la inicialización. 5. Identificar la clase en la que se van a guardar los atributos. 6. Abrir el archivo que contiene la clase. 7. Reubicar en la definición de la clase los datos. 8. Reubicar la inicialización de los datos en el constructor. 9. Cerrar el archivo.

Suposiciones • Estos pasos son la base para desarrollar el método heurístico H:5 (§ 5.1.6). Poscondiciones • La definición y la inicialización de los atributos deben quedar reubicados

en la clase concreta correspondiente de la plantilla MVC.

4.1.2.9. Especificación del caso de uso: crear constructor.

Tabla 4.30. Descripción del caso de uso crear constructor. Nombre del C.U. CU-2.2.3.2. Crear constructor. Descripción Este caso de uso tiene como objetivo describir los eventos para crear

constructores sin atributos y constructores con atributos para ser ubicados en las


69

nuevas clases generadas. Pre-condiciones • Deben haber sido creadas las clases donde van a ubicados los

constructores. • Se deben tener identificados los atributos a ser inicializados para definirlos

en el constructor al ser creado. Flujo básico 1. Para generar un constructor sin parámetros:

1.1. Definir el nombre del constructor. 1.2. Incluir el nombre del atributo. 1.3. Agregarle el valor al atributo.

2. Para generar un constructor con parámetros: 2.1. Definir el nombre del constructor. 2.2. Incluir en la firma del constructor el tipo del atributo y el nombre del

atributo. 2.3. Si el nombre de los datos definidos en la firma del constructor son

iguales a los datos correspondientes declarados en la definición de la clase agregar la palabra reservada this más el nombre del atributo y su valor correspondiente.

2.4. En caso contrario incluir el nombre del dato previamente declarado y agregarle el valor.

3. Termina el método heurístico.Suposiciones • Estos pasos son la base para desarrollar el método heurístico H:3. (§ 5.1.4.) Poscondiciones • El constructor creado queda ubicado en su clase correspondiente con

valores inicializados.

4.1.2.10. Especificación del caso de uso: fragmentar el main.

Tabla 4.31. Descripción del caso de uso fragmentar el main.

Tabla 4.32. Escenario 1 del caso de uso fragmentar el main.

Nombre del C.U. CU-2.2.3.3. Fragmentar el main. Descripción Este caso de uso tiene como objetivo describir los eventos para reestructurar la

función main.

ID Escenario 1 ID Heurística RMn1 Pre-condiciones • Haber localizado la función principal o main en alguna de las clases del

código legado en estudio. • Se tiene conocimiento de que la función principal o main es especializada o

contiene código de alguna parte del patrón MVC. • Debe de haberse generado el código de la plantilla MVC objetivo. • Por ejemplo ver la figura 4.41.

Flujo básico 1. Analizar la clase que contiene la función main. 2. Fragmentar la función main y reubicar la nueva función generada utilizando

la heurística H:10 (§ 5.1.7). 3. Termina el proceso de reestructura.

Suposiciones • Sólo existe una función principal o main en la arquitectura del código fuente por analizar.

• Se ha localizado la función principal o main en alguna de las clases de la


70

cEstudiostatic void main()

publ ic static void main(){ est mod1; est mod2; est mod3;}

Figura 4.42. Función main que incluye estatutos especializados.

oC oM oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVist oV = new cVista(oC); oV.oC.oM.funModelo1(); }

public void invoca1(){ oC.funControl1();}

public void execute1(){ oM.unaAccion();}

public void unaAccion(){ //}void funModelo1(){ est mod1; est mod2; est mod3;}

aControlabstract void execute1()abstract void funControl1()

cVistaaControl oC

cVista(aControl oC)void invoca1()


cControlaModelo oM

cControl(aModelo oM)void funControl1()

cModeloaVista oV


aVistaabstract void invoca1()


oV

Figura 4.43. Arquitectura objetivo la función main especializada.

Tabla 4.33. Escenario 2 del caso de uso fragmentar el main.

arquitectura del código fuente. Poscondiciones • Los objetos de la función main quedarán ubicados en la clase Cliente.

• La función principal tendrá una llamada a la función que contiene el código que era ejecutado originalmente por esta función.

• La clase “Cliente” tendrá una referencia a un objeto “oV” de tipo estático “aVista”.

• La función principal o main declara tres objetos. “oC” de tipo estático “aControl” y de tipo dinámico “cControl”. El objeto “oM” de tipo estático “aModelo” y de tipo dinámico “cModelo”. Esta función cambia dinámicamente el tipo del objeto “oV” al tipo “cVista”.

• Por ejemplo ver la figura 4.42.

ID Escenario 2 ID Heurística RMn2 Pre-condiciones • Haber localizado la función principal o main en alguna de las clases del

código legado en estudio. • Se tiene conocimiento de que la función principal o main tiene estatutos de

código mezclados de las partes del patrón MVC.


71

cEstudiostatic void main()

publ ic static void main(){ est vist1; est mod1; est cont1;}

Figura 4.44. Función main que incluye estatutos de código mezclados.

oC oMoV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVist oV = new cVista(oC); oV.invoca1(); oV.oC.oM.funModelo1(); oV.oC.funControl1(); }

public void funVista1(){ est vist1; }

public void execute1(){ oM.unaAccion();}public void funControl1(){est cont1;}

public void unaAccion(){ //}void funModelo1(){ est mod1;}

aControlabstract void execute1()abstract void funControl1()

cVistaaControl oC

cVista(aControl oC)void invoca1()void fubVista1()


cControlaModelo oM

cControl(aModelo oM)void funControl1()


aVistaabstract void invoca1()

cModeloaVista oV


oV

Figura 4.45. Arquitectura objetivo la función main no-especializada.

• Debe de haberse generado el código de la plantilla MVC objetivo. • Por ejemplo ver la figura 4.43.

Flujo básico 1. Analizar la clase que contiene la función main. 2. Fragmentar la función main y reubicar la nueva función generada utilizando


Suposiciones • Sólo existe una función principal o main en la arquitectura del código fuente por analizar.

• Se ha localizado la función principal o main en alguna de las clases de la arquitectura del código fuente.

Poscondiciones • Los objetos de la función main quedarán ubicados en la clase Cliente. • La función principal tendrá una llamada a la función que contiene el código

que era ejecutado originalmente por esta función. • La clase “Cliente” tendrá una referencia a un objeto “oV” de tipo estático

“aVista”. • La función principal o main declara dos objetos locales. “oC” de tipo

estático “aControl” y de tipo dinámico “cControl”. El objeto “oM” de tipo estático “aModelo” y de tipo dinámico “cModelo”. Esta función cambia dinámicamente el tipo del objeto “oV” al tipo “cVista”.



72

4.1.2.11. Especificación del caso de uso: reestructurar funciones.

Tabla 4.34. Descripción del caso de uso reestructurar funciones.

Tabla 4.35. Escenario 1 del caso de uso reestructurar funciones.

cVistavoid funVista1()

publ ic void funVista1(){ est vist1; est vist2;}

Figura 4.46. Función especializada en la vista

Nombre del C.U. CU-2.2.3.4. Reestructurar funciones. Descripción Este caso de uso tiene como objetivo describir los eventos para reestructurar las

funciones. Este caso de uso incluye dos variantes, la primera incluye a las funciones especializadas en alguna parte del patrón MVC. La segunda variante incluye a las funciones no-especializadas. A partir de estas dos variantes son derivados varios escenarios que son descritos para desarrollar un método heurístico y llevar a cabo la reestructura del código legado.

ID Escenario 1 ID Heurística RF1 Pre-condiciones • La función en estudio sólo incluye estatutos de código relacionados a una de

las tres partes del patrón MVC. • La función no declara objetos locales. • La función no llama a otras funciones. • Por ejemplo ver la figura 4.45.

Flujo básico 1. Analizar la función en estudio. 2. La función es identificada como una función especializada. 3. La función es agregada a un vector de tipo cadena de caracteres. 4. La función es reubicada en la clase correspondiente de la plantilla MVC. 5. Se redefinen las llamadas de invocación a las funciones reubicadas mediante


Suposiciones • La función es identificada como una función especializada. Poscondiciones • La función permanece sin ser fragmentada.

• La función es reubicada en la clase correspondiente de la plantilla MVC. • Por ejemplo ver la figura 4.46.


73

oC oM

oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.funVista1();}

public void invoca(){oC.execute();}public void funVista1(){est vist1;est vist2;}


public void unaAccion{}


cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.47. Arquitectura objetivo conforme al patrón MVC que incluye funciones especializadas

reubicadas


cVistavoid funVista1()void funVista2()

publ ic void funVista1(){ est vist1;}publ ic void funVista2(){est vist1;funVista1();}

Figura 4.48. Función especializada con peticiones de servicio a otra función especializada ambas

pertenecen a un mismo alcance de clase y a una misma parte del patrón MVC.


las tres partes del patrón MVC. • La función en estudio incluye una petición de servicio a una función que es

especializada en la misma parte a la que pertenece la función en estudio. • Ambas funciones están en un mismo alcance de clase. • Por ejemplo ver la figura 4.47.

Flujo básico 1. Analizar la función en estudio. 1.1. La función es identificada como una función especializada. 1.2. La función es agregada a un vector de tipo cadena de caracteres. 1.3. La función es reubicada en la clase correspondiente de la plantilla

MVC. 2. Analizar la función que es invocada.

2.1. La función es identificada como una función especializada. 2.2. La función es agregada a un vector de tipo cadena de caracteres. 2.3. La función es reubicada en la clase correspondiente de la plantilla

MVC. 3. Se redefine la llamada de la función en estudio hacia la función invocada

mediante la heurística H:11 (§ 5.1.8). 4. Termina el proceso de reestructura.

Suposiciones • Esta solución también aplica para las funciones especializadas en el control y el modelo.

Poscondiciones • Las funciones implicadas permanecen sin ser fragmentadas. • Las funciones son reubicadas en la clase correspondiente del patrón MVC. • Por ejemplo ver la figura 4.48.


74

oC oM

oV


public void invoca(){oC.execute();}public void funVista1(){est vist1;}public void funVista2(){est vist1;funVista1();}


public void unaAccion(){}


cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.49. Arquitectura objetivo conforme al patrón MVC obtenida a partir de la reubicación de dos

funciones especializadas en la misma parte del patrón MVC.

Tabla 4.37. Escenario 3 del caso de uso reestructurar funciones. ID Escenario 3 ID Heurística RF3 Pre-condiciones • La función en estudio sólo incluye estatutos de código relacionados a una de

las tres partes del patrón MVC. La función en estudio incluye una petición de servicio a una función que es especializada.

• Las funciones son especializadas en diferente parte del patrón MVC. • Ambas funciones están en un mismo alcance de clase. • Por ejemplo ver la figura 4.49.


MVC. 2. Analizar la función que es invocada.

2.1. La función es identificada como una función especializada. 2.2. La función es agregada a un vector de tipo cadena de caracteres. 2.3. La función es reubicada en la clase correspondiente de la plantilla

MVC. 3. Redefinir la llamada de la función en estudio hacia la función invocada

mediante la heurística H:11 (§ 5.1.8). 4. Termina el proceso de reestructura.

Suposiciones • Esta solución también aplica para las funciones especializadas en el control y el modelo, que invocan funciones especializadas y que pertenecen a diferente parte del patrón MVC.

Poscondiciones • Las funciones implicadas permanecen sin ser fragmentadas. • Las funciones son reubicadas en la clase correspondiente del patrón MVC. • Por ejemplo ver la figura 4.50.


75

cVistavoid funModelo1()void funVista1()

publ ic void funModelo1(){ est Mod1;}publ ic void funVista1(){est vist1;funVModelo1();}

Figura 4.50. Función especializada con peticiones de servicio a otra función especializada, ambas

pertenecen a un mismo alcance de clase pero a diferente parte del patrón MVC.

oC oM

oV


public void invoca(){oC.execute();}public void funVista1(){est vist1;oC.oM.funVModelo1();}


cModelo(){}public void funVModelo1(){est Mod1;}


cVistaaControl oC


aModeloabstract void unaAccion()abstract void funVModelo1()

cControlaModelo oM




cModelo1aVista oV

cModelo()void unaAccion()void funVModelo1()

oV

Figura 4.51. Arquitectura destino conforme al patrón MVC de dos funciones especializadas en diferente

parte del patrón MVC.

Tabla 4.38. Escenario 4 del caso de uso reestructurar funciones. ID Escenario 4 ID Heurística RF4

Pre-condiciones • La función en estudio sólo incluye estatutos de código relacionados a una de

las tres partes del patrón MVC. • La función en estudio incluye una petición de servicio a una función no-

especializada. • Ambas funciones están en un mismo alcance de clase. • Por ejemplo ver la figura 4.51.


MVC. 2. Fragmentar la función invocada, utilizando la heurística H:10 (§ 5.1.7). 3. Redefinir la llamada de la función en estudio a la nueva función original

generada, a partir de la fragmentación de la función original, utilizando la heurística H:11 (§ 5.1.8).


76

cMezcvoid funMezc1()void funVista1()

publ ic void funMezc1(){ est vist1; est cont1;}publ ic void funVista1(){ est vist1; funMezc(); est vist2;}

Figura 4.52. Función especializada solicitando servicios a una función no-especializada,

ambas en el mismo alcance de clase.

oC oM

oV


public void invoca(){oC.execute();}public void funVista1(){est vist1;funVista2();est vist2;}public void funVista2(){est vist1();oC.funControl1();}

public void exectue(){ oM.unaAccion(); }public void funControl1(){est cont1;}


cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.53. Arquitectura destino conforme al patrón MVC de una función no-especializada y una

especializada.

4. Termina el proceso de reestructura. Suposiciones • La función no especializada ha quedado fragmentada en nuevas funciones

especializadas. Poscondiciones • La función en estudio permanece sin ser fragmentada.

• La función invocada no-especializada, es fragmentada generando nuevas funciones especializadas.


Las funciones funVista2 y funControl1 son funciones especializadas generadas a partir de la fragmentación de la función funMezc1.


77


public void funVista1(){ cVista1 oVista1 = new cVista1(); oVista1.funVista2(); est vist1;}

cVista1void funVista2()


Figura 4.54. Función especializada solicitando servicios a una función no-especializada,

ambas funciones en diferente alcance de clase.

oC oM

oV


public void invoca(){oC.execute();}public void funVista1(){funVista2();est vist1;}public void funVista2(){est vist1();}






cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.55. Arquitectura destino de dos funciones especializadas en la misma parte del patrón MVC que

se encontraban en diferente alcance.


las tres partes del patrón MVC. • La función especializada declara un objeto local. • La función en estudio incluye una petición de servicio a una función

especializada, a través del objeto local. • Por ejemplo ver la figura 4.53.


MVC. 1.4. Se redefinen las llamadas a las funciones reubicadas utilizando la

heurística H:11 (§ 5.1.8). 2. Termina el proceso de reestructura.

Suposiciones • La función en estudio y la función invocada, se encuentran en diferente alcance de clase.

Poscondiciones • La función en estudio permanece sin ser fragmentada.• La llamada de la función en estudio se mantiene sin ninguna modificación. • Por ejemplo ver la figura 4.54.


78



cMezcvoid funMezc1()

publ ic void funMezc1(){ est vist1; est mod1;}

publ ic void funVista1(){ cMezc obj = new cMezc(); obj.funMezc1(); est vist1; est vist2;}

Figura 4.56. Función especializada solicitando servicios a una función no-especializada

a través de un objeto local.

public void invoca(){oC.execute();}public void funVista1(){funVista2();est vist1;est vist2;}public void funVista2(){est vist1;oC.oM.funModelo1();}

oC oM

oV


public void funModelo1(){est mod1;}


cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.57. Arquitectura destino conforme al patrón MVC de una función especializada que invoca a una

función no-especializada.


las tres partes del patrón MVC. • La función en estudio declara un objeto local. • La función en estudio incluye una petición de servicio a una función no-

especializada, a través del objeto local. • Las funciones se encuentran en diferente alcance. • Por ejemplo ver la figura 4.55.


MVC. 2. Fragmentar la función no-especializada utilizando la heurística H:10 (§

5.1.7). 3. Redefinir la llamada de la función en estudio, a la nueva función original

generada a partir de la fragmentación de la función invocada, utilizando la heurística H:11 (§ 5.1.8).

4. Termina el proceso de reestructura. Suposiciones • La función en estudio y la función invocada, se encuentran en diferente

alcance de clase. Poscondiciones • La función en estudio permanece sin ser fragmentada.

• La función no-especializada queda fragmentada en funciones especializadas.


Nuevas funciones generadas


79


cMezcvoid funMezc1()void funVista1()

cModelovoid funModelo1()

oMezc

public void funMezc1(){ est cont1; est mod1;}

public void funModelo1(){ oMezc.funVista1(); oMezc.funMezc1(); x = x+10;}

Figura 4.58. Función especializada solicitando servicios a una función no-especializada

a través de un objeto.

public void invoca(){oC.execute();}public void funVista1(){est vist1;est vist2;}

oC oM

oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oV.oC.oM.funModelo1();}

public void funModelo1(){oV.funVista1();oV.oC.funControl1();}public void funModelo2(){est mod1;}


cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


public void funControl1(){est cont1;oM.funModelo1();}

oV

Figura 4.59. Función especializada invocando peticiones de servicio a funciones especializadas, generadas

a partir de la fragmentación de una función no-especializada.

ID Escenario 7 ID Heurística RF7 Pre-condiciones • La función en estudio es una función especializada.

• La función en estudio incluye una petición de servicio a una función especializada a través de un objeto declarado en la definición de la clase.

• La función en estudio también puede incluir peticiones de servicios a funciones no-especializadas, a través del objeto declarado en la definición de la clase.

• Por ejemplo ver la figura 4.57. Flujo básico 1. Analizar la función en estudio.

2. La función en estudio debe permanecer sin ser fragmentada. 3. Si la función invocada es especializada, entonces:

1.1. La función es agregada a un vector de tipo cadena de caracteres. 1.2. La función es reubicada en la clase correspondiente de la plantilla

MVC. 2. Si la función invocada es una función no-especializada entonces:

1.1. Fragmentar la función en estudio utilizando H:10 (§ 5.1.7). 1.2. Redefinir la llamada desde la función en estudio, a la nueva función

original generada a partir de la fragmentación de la función invocada mediante la heurística H:11 (§ 5.1.8).

3. Termina el proceso de reestructura. Suposiciones • La función en estudio y la función invocada, se encuentran en diferente

alcance de clase. Poscondiciones • La función en estudio permanece sin ser fragmentada.

• Las funciones no-especializadas quedan fragmentadas en funciones especializadas.



80


publ ic void funMezc1(){ est vist1; est mod1; est vist2; est cont1;}


Figura 4.60. Función no-especializada.

public void invoca(){oC.execute();}public void funVista1(){est vist1;oC.oM.funModelo1();est vist2;oC.funControl1();}

oC oM

oV


public void funModelo1(){est mod1;}



cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.61. Arquitectura conforme al patrón MVC, generada a partir de la fragmentación de una

función no-especializada.


ID Escenario 8 ID Heurística RF8 Pre-condiciones • La función en estudio incluye estatutos de código de 2 o 3 de las partes del

patrón MVC (función no-especializada). • Por ejemplo ver la figura 4.59.

Flujo básico 1. Analizar la función en estudio. 2. Fragmentar la función no-especializada, utilizando la heurística H:11. 3. Termina el proceso de reestructura.

Suposiciones • La función en estudio se localizó en una de las clases de la arquitectura del sistema, es identificada como una función no-especializada.

• La función en estudio queda fragmentada en funciones especializadas y reubicada en la plantilla correspondiente del patrón MVC.

Poscondiciones • La función en estudio es fragmentada en funciones especializadas que incluyen estatutos de la misma parte del patrón MVC.


ID Escenario 9 ID Heurística RF9


81

cMezcvoid funModelo1()void funMezc1()

public void funModelo1(){ est mod1; est mod2;}public void funMezc1(){ est vist1; funModelo1(); est mod1; est cont1;}

Figura 4.62. Función no-especializada invocando a una función especializada.

public void invoca(){oC.execute();}public void funVista1(){est vist1;oC.oM.funModelo1();oC.oM.funModelo2();oC.funControl1();}

oC oM

oV


public void funModelo1(){est mod1;est mod2;}public void funModelo2(){est mod1;}

public void funControl1(){est cont1;}


cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.63. Arquitectura destino conforme al patrón MVC de una función que agrega por composición a

una función especializada.

Pre-condiciones • La función en estudio incluye estatutos de código de 2 o 3 de las partes del patrón MVC (función no-especializada).

• La función en estudio incluye peticiones de servicio a otras funciones, que son especializadas que se encuentran en un mismo alcance de clase.

• Por ejemplo ver la figura 4.61. Flujo básico 1. Analizar la función en estudio.

2. Fragmentar la función no-especializada, utilizando la heurística H:10 (§ 5.1.7).

3. Analizar por clases. Suposiciones • La función en estudio se localizó en una de las clases de la arquitectura del

sistema y es una función no-especializada. • La función en estudio queda fragmentada en funciones especializadas y

reubicada en la plantilla correspondiente del patrón MVC. • Ambas funciones, la función no-especializada y especializada se encuentran

en un mismo alcance. Poscondiciones • La función en estudio es fragmentada en funciones especializadas que

incluyen estatutos de la misma parte del patrón MVC. • La función invocada permanece sin ser fragmentada. • Por ejemplo ver figura 4.62.


82


public void funMezc1(){ est mod1; est vist1;}public void funMezc2(){ est vist1; funMezc1(); est mod1; est cont1;}

cMezcvoid funMezc1()void funMezc2()

Figura 4.64. Función no-especializada invocando a otra función no-especializada.

ID Escenario 10 ID Heurística RF10 Pre-condiciones • La función en estudio incluye estatutos de código de 2 o 3 de las partes del

patrón MVC (función no-especializada). • La función en estudio incluye peticiones de servicio a otras funciones no-

especializadas que se encuentran en un mismo alcance de clase. • Por ejemplo ver la figura 4.63.

Flujo básico 1. Analizar la función en estudio. 2. Fragmentar la función no-especializada en estudio, utilizando la heurística

H:10 (§ 5.1.7). 3. Fragmentar la función no-especializada que es invocada, utilizando la

heurística H:10 (§ 5.1.7). 4. Redefinir la llamada de la función en estudio, a la nueva función original

generada a partir de la fragmentación de la función invocada, utilizando la heurística H:11 (§ 5.1.8).

5. Termina el proceso de reestructura. Suposiciones • La función en estudio se localizó en una de las clases de la arquitectura del

sistema y es una función no-especializada. • Ambas funciones han quedado fragmentadas en funciones especializadas y

reubicadas en las clases correspondientes de la plantilla MVC. • Ambas funciones se encuentran en un mismo alcance.


• La función invocada también debe ser fragmentada. • Por ejemplo ver figura 4.64.


83

public void invoca(){oC.execute();}public void funVista1(){est vist1;oC.oM.funModelo2();oC.oM.funModelo1();oC.funControl1();}public void funVista2(){estVist1}

oC oM

oV


public void funModelo1(){est mod1;}public void funModelo2(){est mod1;oV.funVista2();}



cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


oV

Figura 4.65. Arquitectura destino conforme al patrón MVC de una función no-especializada que invoca a

una función no-especializada.

Tabla 4.45. Escenario 11 del caso de uso reestructurar funciones. ID Escenario 11 ID Heurística RF11 Pre-condiciones • La función en estudio incluye estatutos de código de 2 o 3 de las partes del

patrón MVC (función no-especializada). • La función en estudio declara un objeto localmente. • La función en estudio incluye peticiones de servicio a otras funciones

especializadas utilizando el objeto local. • Por ejemplo ver la figura 4.65.


H:10 (§ 5.1.7) 3. Termina el proceso de reestructura.

Suposiciones • La función en estudio se localizó en una de las clases de la arquitectura del sistema y es una función no-especializada.

• La función en estudio queda fragmentada en funciones especializadas y reubicada en la plantilla correspondiente del patrón MVC.

• Las funciones implicadas en este escenario se encuentran en diferente alcance.


• La función invocada permanece sin ser fragmentada. • Por ejemplo ver figura 4.66.


84


public void funMezc1(){ cModelo oM = new cModelo(); est vist1; est mod1; oM.funModelo1(); est cont1;}

cModelofunModelo1()

Figura 4.66. Función no-especializada invocando a una función especializada a través de

un objeto local.

public void invoca(){oC.execute();}public void funVista1(){est vist1;oC.oM.funModelo2();oC.oM.funModelo1();oC.funControl1();}

oC oM

oV


public void funModelo1(){est mod1;}public void funModelo2(){est mod1;}


oV aControlabstract void execute()abstract void funControl1()

cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


Figura 4.67. Arquitectura destino conforme al patrón MVC de una función no-especializada que agrega

por composición a una función especializada.

Tabla 4.46. Escenario 12 del caso de uso reestructurar funciones. ID Escenario 12 ID Heurística RF12 Pre-condiciones • La función en estudio incluye estatutos de código de 2 o 3 de las partes del

patrón MVC (función no-especializada). • La función en estudio invoca una función a través de un objeto declarado en

la definición de la clase. • Por ejemplo ver la figura 4.67.


H:10 (§ 5.1.7). 3. Si la función invocada es especializada, entonces:

3.1. La función es agregada a un vector de tipo cadena de caracteres. 3.2. La función es reubicada en la clase correspondiente de la plantilla

MVC. 4. Si la función invocada es función no-especializada entonces:

4.1. Fragmentar la función en estudio utilizando H:10 (§ 5.1.7). 4.2. Redefinir la llamada desde la función en estudio, a la nueva función

original generada a partir de la fragmentación de la función invocada mediante la heurística H:11 (§ 5.1.8).


85

cMezc1void funMezc1()

cMezc2void funMezc2()void funVista1()

oMezc2

publ ic void funMezc1(){ oMezc2.funMezc2(); est mod1; est vist1; oMezc2.funVista1();}

publ ic void funMezc2(){ est cont1; est mod1;}

Figura 4.68. Función no-especializada invocando a una función no-especializada

y a una especializada con diferente alcance.

public void invoca(){oC.execute();}public void funVista1(){est vist1;}public void funVista2(){est vist1;}

oC oM

oV

public static void main( ){ aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista(); oC.oM.funModelo1();}

public void funModelo1(){oV.oC.funControl1();est mod1;oV.funVista2();oV.funVista1();}public void funModelo2(){est mod1;}


oV aControlabstract void execute()abstract void funControl1()

cVistaaControl oC



cControlaModelo oM




cModelo1aVista oV


Figura 4.69. Arquitectura conforme al patrón MVC de una función agregando por composición

funciones especializadas y no-especializadas.

5. Termina el proceso de reestructura. Suposiciones • La función en estudio se localizó en una de las clases de la arquitectura del

sistema y es una función no-especializada. • La función en estudio ha quedado fragmentada en funciones especializadas. • Las funciones implicadas en este escenario se encuentran en diferente

alcance. • La función en estudio puede invocar funciones especializadas y no-

especializadas. Poscondiciones • La función en estudio es fragmentada en funciones especializadas que

incluyen estatutos de código de la misma parte del patrón MVC. • Las funciones invocadas que son no-especializadas deben quedar

fragmentas en funciones no-especializadas. • Por ejemplo ver figura 4.68.


86

4.1.2.12. Especificación del caso de uso: fragmentar función.

Tabla 4.47. Descripción del caso de uso fragmentar función. Nombre del C.U. CU-2.2.3.4.1 Fragmentar función. Descripción Este caso de uso tiene como objetivo describir los eventos para fragmentar las

funciones del código legado y generar nuevas funciones que serán especializadas.

Pre-condiciones • Las funciones incluyen estatutos de una, dos o tres de las partes relacionadas con el patrón MVC.

• Se debe contar con las heurísticas “Crear función” y “Redefinir llamadas a funciones”.

Flujo básico 1. Se identifica una función no-especializada. 2. Se generan vectores para almacenar estatutos de código. 3. Se recorre la función estatuto por estatuto. 4. El primer estatuto de código se almacena en un vector llamado

“vOriginal”. 5. Los estatutos restantes se van almacenando el los vectores “vModelo”,

“vVista” y “vControl”, según corresponda. 6. Los estatutos de código de invocaciones son almacenados también en los

vectores pero la llamada se sustituye por el objeto correspondiente, esto se lleva a cabo utilizando la heurística H:11 (§ 5.1.8).

7. Se invoca el método de “Crear función” para crear nuevas funciones y se vacía el contenido del vector en la nueva función.

8. La nueva función se ubica en la clase correspondiente de la plantilla MVC. 9. Termina el proceso de fragmentar funciones.

Suposiciones • Todas las funciones no-especializadas deben ser fragmentadas. • Las funciones especializadas también son almacenadas en vectores para

que el método “Reubicar funciones” las pueda reubicar. Poscondiciones • Se cuenta con un conjunto de funciones especializadas.

• Las nuevas funciones que incluyen llamadas a otras funciones que no pertenecen a su misma parte del patrón MVC, lo hacen a través de objetos.

4.1.2.13. Especificación del caso de uso: crear función.

Tabla 4.48. Descripción del caso de uso crear función. Nombre del C.U. CU-2.2.3.4.1.1 Crear función. Descripción Este caso de uso tiene como objetivo describir los eventos para crear funciones

especializadas en la vista o el control o el modelo. Pre-condiciones • El método heurístico “Fragmentar función” debe hacer la petición para que

se generen nuevas funciones. Flujo básico 1. Inicializar a 1 un contador para crear funciones de la vista.

2. Inicializar a 1 un contador para crear funciones del control. 3. Inicializar a 1 un contador para crear funciones del modelo. 4. Generar funciones sin parámetros.

4.1. Para cada tipo de función, definir el nombre por default más el número del contador o pedir el nombre al usuario.

4.2. Definir el especificador de acceso, el tipo de retorno y concatenarlos con el nombre de la función de manera adecuada.

4.3. Definir el código de la lista vacía de parámetros y concatenarlo.


87

4.4. Definir el código de apertura de función y concatenarlo. 4.5. Leer el vector correspondiente generado a partir del método

heurístico “Fragmentar función” y agregar los estatutos correspondientes al vector.

4.6. Definir el código de retorno de la función. 4.7. Definir el código de cierre de función. 4.8. Incrementar el contador.

5. Generar funciones con parámetros. 5.1. Para cada tipo de función, definir el nombre por default más el

número del contador o pedirlo al usuario. 5.2. Definir el especificador de acceso, el tipo de retorno y concatenarlos

con el nombre de la función de manera adecuada. 5.3. Leer el vector correspondiente generado a partir del método

heurístico “Fragmentar función” y extraer los parámetros y agregarlos a la lista de parámetros.

5.4. Definir el código de apertura de función y concatenarlo. 5.5. Leer el vector correspondiente generado a partir del método

heurístico “Fragmentar función” y agregar los estatutos correspondientes al vector.

5.6. Definir el código de retorno de la función. 5.7. Definir el código de cierre de función. 5.8. Incrementar el contador.

6. Termina el proceso de crear funciones. Suposiciones • El nombre por default para la vista es funVista, para el control es

funControl y para el modelo es funModelo. • A partir de estos eventos se genera el método heurístico “Crear función”.

Poscondiciones • Se cuenta con los pasos para generar funciones especializadas.

4.1.2.14. Especificación del caso de uso: redefinir llamadas a funciones.

Tabla 4.49. Descripción del caso de uso redefinir llamadas a funciones. Nombre del C.U. CU-2.2.3.4.1.2 Redefinir llamadas a funciones Descripción Este caso de uso tiene como objetivo describir los eventos para redefinir

llamadas a funciones. Pre-condiciones • El método heurístico “Fragmentar función” debe hacer la petición para que

se redefinan las llamadas a las funciones. • Debe haber sido generada la plantilla genérica MVC.

Flujo básico 1. Analizar las peticiones de servicio a las funciones. 2. Si el cliente desea hacer peticiones de servicio a la vista o al control o al

modelo, entonces se sustituye el objeto que invoca a las funciones. Por ejemplo: • oV. + nombre de la función. Para peticiones a funciones de la vista. • oV.oC. + nombre de la función. Para peticiones a funciones del

control. • oV.oC.oM. + nombre de la función. Para peticiones a funciones del

modelo. • ¡Nota! Para el caso en donde las peticiones son a través del nombre de

la función sólo se le agregan los objetos anteriores. 3. Si las funciones de la vista requieren del servicio de alguna de las

funciones del control o del modelo, entonces se sustituye el objeto que invoca a las funciones. Por ejemplo: • oC. + nombre de la función. Para peticiones a funciones del control.


88

• oM.+ nombre de la función. Para peticiones a funciones del modelo. • ¡Nota! Para el caso en donde las peticiones son a través del nombre de

la función sólo se le agregan los objetos anteriores. 4. Si las funciones del control requieren del servicio de alguna de las

funciones del modelo, entonces se sustituye el objeto que invoca a las funciones. Por ejemplo: • oM. + nombre de la función. Para peticiones a funciones del modelo. • ¡Nota! Para el caso en donde las peticiones son a través del nombre de

la función sólo se le agregan los objetos anteriores. 5. Si las funciones del Modelo requieren del servicio de alguna de las

funciones de la vista, entonces se sustituye el objeto que invoca a las funciones. Por ejemplo: • oV. + nombre de la función. Para peticiones a funciones del modelo. • ¡Nota! Para el caso en donde las peticiones son a través del nombre de

la función sólo se le agregan los objetos anteriores. 6. Termina el proceso de redefinir llamadas a funciones.

Suposiciones • A partir de estos eventos se genera el método heurístico “Redefinir llamadas a funciones”.

Poscondiciones • Las peticiones a funciones de diferente parte se hacen a través del objeto correspondiente definido en la plantilla genérica del patrón MVC.

4.1.2.15. Especificación del caso de uso: cohesionar clases.

Tabla 4.50. Descripción del caso de uso cohesionar clases. Nombre del C.U. CU-3 Cohesionar clases Descripción A partir de la reestructura de código legado, las clases concretas de la plantilla

MVC contienen a las nuevas funciones especializadas. Este caso de uso tiene como objetivo describir los pasos para agrupar en nuevas clases a aquellas funciones que acceden a un atributo en común, es decir generar clases altamente cohesivas.

Pre-condiciones • La clase concreta tiene declarados varios estatutos los cuales son accedidos por diferentes funciones.

• Se cuenta con el método heurístico de “Crear clases”. Flujo básico 1. Analizar la clase concreta.

2. Si aplica, utilizar la heurística H:7 y generar clases base para contener la declaración de funciones redundantes que realicen una misma tarea.

3. Si aplica utilizar la heurística H:6 y generar clases altamente cohesivas, es decir que contengan funciones que acceden a datos en común.

4. Termina el proceso de cohesionar clases. Suposiciones • A partir de estos eventos se genera el método heurístico “Cohesionar

clases”. • Debe existir una referencia a la nueva clase generada desde el cliente

correspondiente. • Se utilizan los métodos heurísticos “Subjerarquizar”, “Superjerarquizar”,

“Crear clases”. Poscondiciones • Se generan nuevas clases que tienen la propiedad de ser altamente

cohesivas.


89

4.1.2.16. Especificación del caso de uso: subjerarquizar.

Tabla 4.51. Descripción del caso de uso subjerarquizar. Nombre del C.U. CU-3.1 Subjerarquizar. Descripción El método consiste en definir clases y que éstas deriven de clases de un nivel

superior en una jerarquía de herencia para generalizar estructuras de datos. Pre-condiciones • Un conjunto de funciones están asociadas a una estructura de datos común. Flujo básico 1. Para cada subclase a ser definida.

2. Crear una clase utilizando la heurística H:2 (§ 5.1.3). 3. Identificar aquellas funciones que acceden a atributos en común. 4. Reubicar los atributos y las funciones asociadas. 5. Si no existe clase base generarla utilizando la heurística H:2 (§ 5.1.3).

5.4. Reubicar en esa clase todas las partes comunes de todas las subclases. 6. Crear una clase base e incluir aquellos atributos y funciones que no fueron

reubicados. 7. Termina el proceso de Subjerarquizar clases.

Suposiciones • A partir de estos eventos se genera el método heurístico “Subjerarquizar clases”.

• Alternativamente se puede utilizar la solución dada en el caso de uso de “Superjerarquizar clases” para generalizar la configuración de clases.

Poscondiciones • Se crea una subclase para cada subconjunto de características. • La clase base y las subclases creadas se relacionan por herencia.

4.1.2.17. Especificación del caso de uso: superjerarquizar clases.

Tabla 4.52. Descripción del caso de uso superjerarquizar. Nombre del C.U. CU-3.1 Superjerarquizar. Descripción El método consiste en crear una superclase para un conjunto de clases

relacionándolas por herencia a esta superclase. Pre-condiciones • Una función o más funciones se ubiquen en más de una clase y se genere

una redundancia de funciones. • Las funciones redundantes realicen procedimientos similares en la misma

manera. • Las funciones redundantes realicen procedimientos similares de diferente

manera. Flujo básico 1. Analizar las clases concretas.

2. Aplicar la heurística H:10 (§ 5.1.7) para fragmentar funciones. 3. Si las funciones realizan procedimientos de la misma manera entonces.

3.1. Abrir el archivo que contiene la declaración de las clases y reubicar la función redundante.

3.2. Mientras existan clases derivadas. 3.2.1. Eliminar las funciones redundantes de cada función y cerrar el

archivo. 3.2.2. Fin.

4. Si las funciones realizan procedimientos de diferente manera. 4.1. Abrir el archivo que contiene la declaración de las clases y declarar

una función abstracta utilizando la heurística H:4 con la misma firma de la función.

4.2. Agregar a la clase base los atributos y métodos comunes en las


90

subclases. 4.3. Agregar el archivo con la función fragmentada. 4.4. Cerrar el archivo de la clase base. 4.5. Fin

5. Agregar a la clase base los atributos y métodos comunes en las subclases. 6. Agregar el archivo con la función fragmentada. 7. Cerrar el archivo de la clase base. 8. Termina el proceso de Superjerarquizar.

Suposiciones • Estos pasos son la base para desarrollar el método heurístico Superjerarquizar clases.

• Este caso de uso colabora con el caso de uso “Subjerarquizar clases” Poscondiciones • Una clase base contiene a las funciones redundantes.

• La implementación de las funciones queda definida en las clases concretas.

4.1.2.18. Especificación del caso de uso: crear clases.

Tabla 4.53. Descripción del caso de uso crear clases. Nombre del C.U. CU-3.3 Crear clases. Descripción Este caso de uso consiste en describir los eventos para crear clases concretas,

clases abstractas e interfaces en un archivo. Pre-condiciones • Los datos a ser reubicados deben estar almacenados en un vector.

• Las funciones a ser reubicadas deben estar almacenadas en un vector. Flujo básico 1. Crear un archivo para la declaración de la clase.

2. Para todo tipo de clase (clase abstracta, concreta o interfaz), definir el tipo de acceso y el nombre de la clase.

3. Generar el código del constructor utilizando la heurística H:3 (§ 5.1.4). 4. Reubicar los datos y la inicialización en la parte correspondiente,

utilizando la heurística H:5 (§ 5.1.6). 5. Reubicar las funciones utilizando la heurística H:10 (§ 5.1.7). 6. Termina el proceso de crear clases.

Suposiciones 1. A partir de estos eventos se genera el método heurístico “Redefinir llamadas a funciones”.

Poscondiciones 2. Las nuevas clases generadas son especializadas. 3. Las nuevas clases deben ser extendidas de una clase abstracta o interfaz.

4.2. Comentarios finales. Para llevar a cabo cualquier procedimiento de reestructura de código legado, es importante incluir todas las variantes que puedan existir en el código, para desarrollar una solución a cada una de éstas y prevenir posibles problemas en cuanto a que la funcionalidad del código no sea la misma antes y después de la reestructura.

En este capítulo fueron documentados un conjunto de escenarios que incluyen la descripción y la manera en que se puede tratar el escenario para reestructurarlo hacía una arquitectura basada en el patrón arquitectural MVC, éstos fueron identificados a partir de la identificación de los casos de uso. Los escenarios identificados pueden estar presentes en el código legado al momento de ser analizado para su reestructura.


91

A partir de la descripción los escenarios se debe generar una solución genérica que incluya la reestructura de cada caso. La solución para reestructurar el código legado viene descrita con los métodos heurísticos desarrollados en el siguiente capítulo.

CAPÍTULO 5 DESARROLLO DE MÉTODOS HEURÍSTICOS

92

Capítulo 5) Desarrollo de métodos heurísticos Este capítulo presenta la descripción de los métodos heurísticos para llevar a cabo la reestructura del código legado hacia la arquitectura MVC. El conjunto de métodos están definidos con base al estudio de los escenarios identificados a partir de los casos de uso analizados en el capítulo 4.

5.1. Desarrollo de los métodos heurísticos. Para desarrollar los métodos heurísticos de reestructura, se tomó como base el análisis del código legado para identificar las variantes que pueden encontrarse en el código legado escrito en lenguaje Java, el análisis de escenarios propone la manera de separar el código conforme al patrón MVC.

A partir del análisis del código se definieron los casos de uso e identificaron los escenarios relacionados con los casos de uso. Posteriormente se definió un conjunto de métodos heurísticos, para que a futuro sean implementados en un procedimiento de reestructura. La figura 5.1 representa los pasos seguidos para cumplir con el objetivo de la tesis.

Figura 5.1. Pasos para cumplir con el objetivo de la tesis.

Pasos definidos en el capítulo 4

Paso definido en este capítulo


93

En esta tesis se identificaron trece métodos heurísticos, de los cuales sólo se desarrollaron ocho, quedando para futuros trabajos de investigación el desarrollo de los restantes. A continuación se listan el total de los métodos heurísticos y posteriormente son descritos.

5.1.1. Método heurístico H0, “Definir plantilla genérica MVC”. El método consiste en generar una arquitectura de clases conforme al patrón MVC (§ 3.4) utilizando el patrón de diseño Command (§ 3.4.6.5). Intención. En el proceso de reestructura de código legado, tanto atributos de clase como funciones especializadas y no-especializadas después de ser fragmentadas deben ser reubicadas. La arquitectura MVC generada a partir del método heurístico tiene como objetivo incluir esas funciones en las clases especializadas de la arquitectura MVC.

La arquitectura generada está dividida en 3 capas, la capa de presentación de datos (la vista), la capa que controla la aplicación (el control) y la que incluye la lógica de negocios (el modelo). Para la creación de la plantilla genérica se utilizó el autómata de la figura 5.2.

Figura 5.2. Autómata para crear las clases de la plantilla genérica.

Proceso. 1. Crear un archivo de definición llamado “aVista.java” para la declaración de la interfaz

“aVista”. 2. Escribir en este archivo el texto que declara la clase, por ejemplo:

public interface aVista{ 2.1. Generar el código para declarar todas las interfaces de invocación, por ejemplo:

public abstract void invoca();

8. Cohesionar clases. 9. Generación de objetos. 10. Fragmentar funciones. 11. Redefinir llamadas a funciones. 12. Reubicar todos los imports.

0. Definir plantilla genérica MVC. 1. Análisis del código legado. 2. Crear clases. 3. Crear constructor. 4. Crear función. 5. Reubicar atributos. 6. Sub-jerarquizar. 7. Super-jerarquizar.


94

3. Crear un archivo de definición llamado “aControl.java” para la declaración de la interfaz “aControl”.

4. Escribir en este archivo el texto que declara la clase, por ejemplo: public interface aControl {

4.1. Generar el código para declarar todas las interfaces de ejecución, por ejemplo: public abstract void execute(); 5. Crear un archivo de definición llamado “aModelo.java” para la declaración de la interfaz

“aModelo”. 6. Escribir en este archivo el texto que declara la clase, por ejemplo:

public interface aModelo { 6.1. Generar el código para declarar todas las interfaces de acción, por ejemplo:

public abstract void unaAccion(); 7. Crear un archivo de definición llamado “cVista.java” para la declaración de la clase

concreta “cVista” derivada de la clase “aVista”. 8. Escribir en este archivo el texto que declara la clase, por ejemplo: public class cVista implements aVista{

8.1. Establecer una relación de agregación de la clase “aControl” con la clase “cVista”. Esto se hace declarando el objeto “oC” de clase “aControl” dentro de la clase “cVista”.

protected aControl oC; 8.2. Generar un constructor vacío de la clase “cVista”, utilizando la heurística H:3 (§

5.1.4). public cVista(){ }

8.3. Generar un constructor sobrecargado de la clase “cVista” que reciba como parámetro un objeto de tipo “aControl” y generarle código, utilizando la heurística H:3 (§ 5.1.4). Por ejemplo.

public cVista(aControl oC){ this.oC = oC; } // Termina constructor de cVista.

8.4. Generar el código para implementar la interfaz “invoca()” public void invoca(){ oC.execute(); }

9. Crear un archivo de definición llamado “cControl.java” para la declaración de la clase concreta “cControl” derivada de la clase “aControl”.

10. Escribir en este archivo el texto que declara la clase, por ejemplo: public class cControl implements aControl {

10.1. Establecer una relación de agregación de la clase “aModelo” con la clase “cControl”. Esto se hace declarando el objeto “oM” de clase “aModelo” dentro de la clase “cControl”.

protected aModelo oM; 10.2. Generar el código del constructor de la clase “cControl”, utilizando la heurística H:3

(§ 5.1.4). public cControl(aModelo oM){ this.oM = oM; } // Terminar el constructor de cControl.

10.3. Generar el código para implementar todas las interfaces de ejecución de acciones, por ejemplo:

public void execute(){


95

oM.unaAccion(); }

11. Crear un archivo de definición llamado “cModelo.java” para la declaración de la clase concreta “cModelo” derivada de la clase “aModelo”.

12. Escribir en este archivo el texto que declara la clase, por ejemplo: public class cModelo implements aModelo {

12.1. Establecer una relación de agregación de la clase “aVista” con la clase “cModelo”. Esto se hace declarando el objeto “oV” de clase “aVista” dentro de la clase “cModelo”.

aVista oV = new cVista(); 12.2. Generar el código del constructor de la clase “cModelo”, utilizando la heurística H:3

(§ 5.1.4). public cModelo(){ this.oV = oV; } // Termina el constructor de cModelo.

12.3. Generar el código para implementar todas las interfaces de ejecución de acciones, por ejemplo:

public void unaAccion( ){ estatuto 1 del Modelo; estatuto ‘n’ del Modelo; }

13. Crear un archivo de definición llamado “Cliente.java” para la declaración del cliente. 14. Escribir en este archivo el texto que declara la clase, por ejemplo:

public class Cliente { 14.1. Crear la función main.

public static void main(String [] args) { 14.2. Generar las variables locales a la función main, “oM”, “oC” y “oV” con tipo

estático “aModelo”, “aControl” y “aVista” y tipo dinámico “cModelo”, “cControl” y “cVista” respectivamente.

aModelo oM = new cModelo(); aControl oC = new cControl(oM); aVista oV = new cVista( oC);

14.3. Generar el código de cada una de las peticiones de servicio dirigidas a la parte del modelo, por ejemplo:

oV. invoca(); 14.4. Cerrar la declaración de la función main.

}//Termina función main. 14.5. Cerrar la declaración de la clase “Cliente”.

}Termina definición de la clase cliente. 15. Termina el método heurístico. El resultado de este método heurístico está ejemplificado en la figura 5.3.


cVistaaControl oC

cVista()cVista(aControl oC)void invoca()


cControlaModelo oM




cModeloaVista oV


oC oM oV

Figura 5.3. Resultado de la implementación del método heurístico de crear plantilla genérica.


96

5.1.2. Método heurístico H1, “Análisis del código legado”. El método consiste en identificar los estatutos, las funciones y clases del código legado. Intención. Para llevar a cabo la tarea de reestructura del código legado, es necesario llevar a cabo una identificación de los componentes del marco legado.

El método heurístico tiene como objetivo identificar a que parte se relacionan cada uno de los estatutos de código incluidos en las funciones, el mismo caso debe aplicar para las funciones y para las clases. Para el desarrollo del método se utilizó el autómata de la figura 5.4.

Figura 5.4. Autómata para analizar el código legado. Procedimiento. 1. Abrir la carpeta que contiene todos los archivos del marco de aplicaciones legado. 2. Analizar cada uno de los archivos. 3. Abrir un archivo de la carpeta.

3.4. Analizar una clase del archivo. 3.4.1. Analizar una función de la clase en estudio.

3.4.1.1. Analizar un estatuto de código e identificar con cual parte del patrón MVC se relaciona.

3.4.1.1.1. Si el estatuto analizado se relaciona con la parte de la vista entonces ponerle la siguiente etiqueta: “//EV”.

3.4.1.1.2. Si el estatuto analizado se relaciona con la parte del control, entonces ponerle la siguiente etiqueta: “//EC”.

3.4.1.1.3. Si el estatuto analizado se relaciona con la parte del modelo, entonces ponerle la siguiente etiqueta: “//EV”.

3.4.1.1.4. Si el estatuto analizado es un estatuto de invocación, entonces ponerle la siguiente etiqueta: “//EI”.

3.4.1.1.5. Repetir el procedimiento del paso 3.4.1.1. mientras no sea fin de función. “}”.

3.4.1.2. Si todos los estatutos de código analizados en la función actual pertenecen sólo a la vista, entonces ponerle a la función la siguiente etiqueta: “//FV”.

3.4.1.3. Si todos los estatutos de código analizados en la función actual pertenecen sólo al control, entonces ponerle a la función la siguiente etiqueta: “//FC”.

3.4.1.4. Si todos los estatutos de código analizados en la función actual pertenecen sólo al modelo, entonces ponerle la siguiente etiqueta a la función: “//FM”.


97

3.4.1.5. Si los estatutos de código analizados en la función actual pertenecen a diferente parte del patrón MVC, entonces ponerle a la función la siguiente etiqueta: “//FMz”.

3.4.1.6. Repetir el procedimiento desde el paso 3.4.1 mientras no sea fin de clase “}”.

3.4.2. Si todas las funciones incluidas en la clase pertenecen a la vista, entonces etiquetar la clase con la siguiente etiqueta: “//CV”.

3.4.3. Si todas las funciones incluidas en la clase pertenecen al control, entonces etiquetar la clase con la siguiente etiqueta: “//CC”.

3.4.4. Si todas las funciones incluidas en la clase pertenecen al modelo, entonces etiquetar la clase con la siguiente etiqueta: “//CM”.

3.4.5. Si las funciones incluidas en la clase pertenecen a diferentes partes del patrón MVC, entonces etiquetar la clase con la siguiente etiqueta: “//CMz”.

3.5. Repetir el procedimiento desde el paso 3.4 mientras no sea fin de archivo “EOF”. 4. Repetir el procedimiento desde el punto 3 mientras la carpeta no este vacía. 5. Termina el método heurístico.

La figura 5.5. es un ejemplo del resultado obtenido al implementar el método heurístico “Análisis del código legado”.

¡Nota! La función main es analizada y etiquetada como función y con base a los estatutos que la componen, puede ser especializada o no-especializada.

public class Analisis {//CMz int aprobados, reprobados, contador; float resultado,entrada,salida; public Analisis{ aprobados =0; reprobados =0; } public int calcula(){//FM while(contador<=10){//EM entrada = JOptionPane.showInputDialog("Escriba el resultado");//EM resultado = Integer.parseInt(entrada);//EM if(resultado == 1)//EM aprobados = aprobados +1;//EM else reprobados = reprobados + 1;//EM contador = contador +1;//EM return aprobados; //EM } public void resultados(){//FV int apr = calcula(); //EI if(apr>8) System.out.println("Aumentar la colegiatura");//EV }}

Figura 5.5. Resultado del método heurístico “Análisis del código legado”.


98

5.1.3. Método heurístico H2, “Crear clases”. El método consiste en definir la declaración de clases simples, clases abstractas e interfaces en un archivo. Intención. Este método colabora con los métodos de “Cohesionar clases”, “Super-Jerarquizar” y “Sub-Jerarquizar”, generando nuevas clases para que las clases concretas de la arquitectura MVC puedan ser divididas y en cada una de las nuevas clases, se agrupen las funciones con sus respectivos parámetros y tipo de función, en su correspondiente clase de objetos. Para el desarrollo del método se utilizó el autómata de la figura 5.6.

Figura 5.6. Autómata para crear clases, clases abstractas e interfaces.

Procedimiento. 1. Crear un archivo de definición con extensión “java” para la declaración de la clase. 2. Escribir en este archivo el texto que declara la clase. El nombre para esta clase es una

derivación del nombre original de la clase que motiva la creación de la nueva clase o solicitar interactivamente el nombre de la clase. 2.1. Si ésta es una clase simple generar el siguiente código: public class nomClase{

2.1.1. Si ésta es derivada de otra generar el siguiente código: public class nomClase extends nomClaseBase{ 2.1.2. Si se desea crear una nueva clase entonces ir al paso 1. 2.1.3. Si no, entonces ir al paso 3.

2.2. Si esta clase es abstracta generar el siguiente código: public abstract class nomClase{

2.2.1. Si esta clase es derivada de otra generar el siguiente código:


99

public abstract class nomClase extends nomClaseBase{ 2.2.2. Si se desea crear una nueva clase entonces ir al paso 1. 2.2.3. Si no, entonces ir al paso 3.

2.3. Si esta clase es una interfaz generar el siguiente código: public interface nomInterfaz{

2.3.1. Si se desea crear una nueva clase entonces ir al paso 1. 2.3.2. Si no, entonces ir al paso 3.

2.4. Si esta clase implementa una interfaz generar el siguiente código: public nomClase implements nomInterfaz{

2.4.1. Si se desea crear una nueva clase entonces ir al paso 1. 2.4.2. Si no, entonces ir al paso 3.

3. Generar el código del constructor de la clase (sólo para las clases simples), utilizando la heurística H:3 (§ 5.1.4), “Creación del constructor”.

4. Antes de cerrar la definición de la clase deben ubicarse los atributos que corresponden a la clase, mediante la heurística H:5 (§ 5.1.6) de “Reubicar atributos”.

5. También se utiliza la heurística H:10 (§5.1.7) de “Fragmentar funciones” para almacenar la función generada en un vector y agregarlo en la clase correspondiente.

6. Cerrar la definición de la clase de manera apropiada, generando el siguiente código: }//Termina nomClase. 7. Termina el método heurístico. La figura 5.7 representa varias clases que genera el método heurístico “Crear clases”.

cVistacVista()

ccVistaccVista()

public class cVista{}//Termina cVista

public class ccVista extends cVista{}//Termina ccVista

absModelo

public abstract class absModelo{ } //Termina absModelo

cModelocModelo()

public class cModelo extends absModelo{ } //Termina cModelo

aVista

cVistacVista()

public interface aVista{}//Termina aVista

public class cVista implements aVista{}//Termina cVista

Figura 5.7. Clases generadas con el método heurístico “Crear clases”.


100

5.1.4. Método heurístico H3, “Crear constructor”. El método heurístico consiste en crear constructores simples (constructores sin parámetros) y constructores con parámetros. Intención. Este método tiene como intención definir dos tipos de constructores, uno sin parámetros y otro con parámetros. El objetivo es incluir la inicialización de las estructuras de datos de las instancias de las clases. Los constructores sin parámetros inicializan la estructura de datos de las instancias de la clase. El otro tipo de constructores son los que reciben parámetros por cada variable de la estructura de datos que contiene una clase.

Este método colabora con los métodos que generan nuevas clases como lo son: “Método de definir plantilla genérica” o el de “crear clases”. Para el desarrollo del método se utilizó el autómata de la figura 5.8.

Figura 5.8. Autómata para crear constructores.

Procedimiento. 1. Si el constructor es un constructor simple (sin parámetros), generar el código de

inicialización con valores por omisión. nomClase(){

1.1. Para cada atributo de la clase. 1.1.1. Si el dato a inicializar en el constructor es de tipo boolean entonces generar el

siguiente código: dato = literal; 1.1.2. Si el dato a inicializar en el constructor es de tipo byte o short o int o long,

entonces generar el siguiente código: dato = valorEntero; 1.1.3. Si el dato a inicializar en el constructor es de tipo float o double, entonces

generar el siguiente código: dato = valorEntero.valorEntero;


101

1.1.4. Si el dato a inicializar en el constructor es de tipo char, entonces generar el siguiente código:

dato = ‘caracter’; 1.1.5. Si el dato a inicializar en el constructor es de tipo String, entonces generar el

siguiente código: dato = “cadenaDeCaracteres”;

1.2. Cerrar la definición del constructor de manera apropiada, generando el siguiente código:

}//Termina el constructor nomClase. 1.3. Si se desea crear otro constructor, entonces ir al paso 1. 1.4. Fin.

2. Si el constructor es un constructor con parámetros, generar el siguiente código: nomClase(tipoDato dato1,…, tipoDato dato‘n’){

2.1. Para cada atributo declarado en la definición de la clase: 2.1.1. Si el nombre de los datos definidos en la firma del constructor son iguales a los

nombres de los datos correspondientes a los atributos declarados en la definición de la clase, entonces generar el siguiente código:

this.dato1 = dato1; … this.dato‘n’ = dato‘n’;

2.1.2. Si el nombre de los datos definidos en la firma del constructor son diferentes a los nombres de los datos correspondientes a los atributos declarados en la definición de la clase, entonces generar el siguiente código:

datoAtributo1 = dato1; … datoAtributo‘n’ = dato‘n’; 2.2. Cerrar la definición del constructor de manera apropiada, generando el siguiente

código: }//Termina el constructor nomClase.

2.3. Si se desea crear otro constructor, entonces ir al paso 1. 3. Termina el método heurístico. La figura 5.9 es un ejemplo de los constructores generados a partir del método heurístico “Crear constructor”.

public class nomClase{ //Sección para declarar atributos tipoDato1 dato1; tipoDato2 dato1; //Constructor sin parámetros public nomClase(){ //Inicialización de variables. dato1 = valor; dato2 = valor; ... dato'n' = valor; } //Constructor con parámetros public nomClase(tipoDato dato1,tipoDato dato2,...,tipoDato dato'n'){ //Asignación de valores. this.dato1 = dato1; this.dato2 = dato2; } }

Figura 5.9. Creación de constructores.


102

5.1.5. Método heurístico H4, “Crear función”. El método heurístico consiste en crear una función sin parámetros o con parámetros, este método colabora con el método de “Fragmentar funciones”. Intención. En el proceso de reestructura de código legado, para fragmentar funciones es necesario crear nuevas funciones que incluyan estatutos relacionados con una sola de las partes del patrón MVC. Las funciones generadas a través del presente método, son funciones que incluyen los estatutos de código, que utilizando la heurística H:10 (§ 5.1.7) fueron identificados y almacenados en vectores para su reubicación. Este método crea funciones especializadas con parámetros y sin parámetros, al ser creadas éstas son especializadas y están listas para ser reubicadas en las clases correspondientes. Para el desarrollo del método se utilizó el autómata de la figura 5.10.

Figura 5.10. Autómata para crear funciones.

Procedimiento. 1. Se utilizan los siguientes contadores:

• NumFunV inicializado con 1 para las funciones de la Vista. • NumFunC inicializado con 1 para las funciones del Control. • NumFunM inicializado con 1 para las funciones del Modelo.

2. Para cada función a ser creada. 3. Si la función es una función simple (sin parámetros), entonces:

3.1. Si la función es de la Vista, entonces: 3.1.1. Generar el código del especificador de acceso y tipo de la función,

“especificadorDeAcceso tipoDeRetorno”. 3.1.2. El nombre para esta función por omisión es “funVista + NumFunV”, enseguida

incrementar el contador NumFunV en 1. De otro modo solicitar interactivamente el nombre de la función.

3.1.3. Concatenar el código correspondiente a la lista vacía de parámetros de la función “( )”


103

3.1.4. Concatenar el código correspondiente a la apertura de bloque de estatutos “{”

Por ejemplo: public void funVista1(){

3.1.5. Leer el vector vVista o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y sólo reubicar los estatutos de código incluidos en ese vector. Por ejemplo: estatuto Vista1;

… estatuto Vista ‘n’;

3.1.6. Si el vector leído no incluye el código de retorno de la función, entonces éste debe ser incluido según su tipo. Por ejemplo:

return val1; 3.1.7. Cerrar la función de manera apropiada, generando el siguiente código:

}//Termina la función funVista. 3.1.8. Si se desea generar otra función ir al paso 3. 3.1.9. Fin.

3.2. Si la función es del Control, entonces: 3.2.1. Generar el código del especificador de acceso y tipo de la función,

“especificadorDeAcceso tipoDeRetorno”. 3.2.2. El nombre para esta función por omisión es “funControl + NumFunC”,

enseguida incrementar el contador NumFunC en 1. De otro modo solicitar interactivamente el nombre de la función.


3.2.4. Concatenar el código correspondiente a la apertura de bloque de estatutos “{“ Por ejemplo:

public void funControl1(){ 3.2.5. Leer el vector vControl o vOriginal según corresponda, generado en la

heurística H:10 (§ 5.1.7) y sólo reubicar los estatutos de código incluidos en el vector. Por ejemplo: estatuto Control1; … estatuto Control ‘n’;



}//Termina la función funControl. 3.2.8. Si se desea generar otra función ir al paso 3. 3.2.9. Fin.

3.3. Si la función es del Modelo, entonces: 3.3.1. Generar el código del especificador de acceso y tipo de la función,

“especificadorDeAcceso tipoDeRetorno”. 3.3.2. El nombre para esta función por omisión es “funModelo + NumFunM”,

enseguida incrementar el contador NumFunM en 1. De otro modo solicitar interactivamente el nombre de la función.



104

3.3.4. Concatenar el código correspondiente a la apertura de bloque de estatutos “{“

Por ejemplo: public void funModelo1(){

3.3.5. Leer el vector vModelo o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y sólo reubicar los estatutos de código incluidos en ese vector. Por ejemplo: estatuto Modelo1; … estatuto Modelo ‘n’;



}//Termina la función funModelo. 3.3.8. Si se desea generar otra función ir al paso 3. 3.3.9. Fin.

4. Si la función requiere de parámetros en la firma. 4.1. Si la función es de la Vista, entonces:

4.1.1. Generar el código del especificador de acceso y tipo de la función, “especificadorDeAcceso tipoDeRetorno”.

4.1.2. El nombre para esta función por omisión es “funVista + NumFunV”, enseguida incrementar el contador NumFunV en 1, de otro modo solicitar interactivamente el nombre de la función.

4.1.3. Leer el vector vVista o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y concatenar el código correspondiente a la lista de parámetros de la función “(tipoDato dato1,…, tipoDato dato‘n’)”.

4.1.4. Concatenar el código correspondiente a la apertura de bloque de estatutos “{ ”

Por ejemplo: public void funVista1(tipoDato dato1,…, tipoDato dato‘n’){

4.1.5. Leer el vector vVista o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y sólo reubicar los estatutos de código incluidos en ese vector. Por ejemplo: estatuto Vista1; … estatuto Vista ‘n’;



}//Termina la función funVista. 4.1.8. Si se desea generar otra función ir al paso 3. 4.1.9. Fin.

4.2. Si la función es del Control, entonces: 4.2.1. Generar el código del especificador de acceso y tipo de la función,

“especificadorDeAcceso tipoDeRetorno”. 4.2.2. El nombre para esta función por omisión es “funControl + NumFunC”,

enseguida incrementar el contador NumFunC en 1, de otro modo solicitar interactivamente el nombre de la función.


105

4.2.3. Leer el vector vControl o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y concatenar el código correspondiente a la lista de parámetros de la función “(tipoDato dato1,…, tipoDato dato‘n’)”.


Por ejemplo: public void funControl1(tipoDato dato1,…, tipoDato dato‘n’){

4.2.5. Leer el vector vControl o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y sólo reubicar los estatutos de código incluidos en ese vector. Por ejemplo:

estatuto Control1; … estatuto Control ‘n’;



}//Termina la función funControl. 4.2.8. Si se desea generar otra función ir al paso 3. 4.2.9. Fin.

4.3. Si la función es del Modelo, entonces: 4.3.1. Generar el código del especificador de acceso y tipo de la función,

“especificadorDeAcceso tipoDeRetorno”. 4.3.2. El nombre para esta función por omisión es “funModelo + NumFunM”,

enseguida incrementar el contador NumFunM en 1, de otro modo solicitar interactivamente el nombre de la función.

4.3.3. Leer el vector vModelo o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y concatenar el código correspondiente a la lista de parámetros de la función “(tipoDato dato1,…, tipoDato dato‘n’)”.


Por ejemplo: public void funModelo1(tipoDato dato1,…, tipoDato dato‘n’){

4.3.5. Leer el vector vModelo o vOriginal según corresponda, generado en la heurística H:10 (§ 5.1.7) y sólo reubicar los estatutos de código incluidos en ese vector. Por ejemplo:

estatuto Modelo1; … estatuto Modelo ‘n’;



}//Termina la función funModelo. 4.3.8. Si se desea generar otra función ir al paso 3.

5. Termina el método heurístico. La figura 5.11 es un ejemplo de las funciones generadas a partir del método heurístico “Crear función”.


106

5.1.6. Método heurístico H5, “Reubicar atributos”. El método consiste en reubicar los atributos y su inicialización desde las clases legadas a las clases concretas correspondientes de la plantilla MVC. Intención. Los atributos declarados en las clases legadas, pueden ser utilizados por una o más funciones. Los atributos junto con su inicialización deben ser reubicados en las clases concretas correspondientes de la plantilla MVC, es decir en aquellas clases que incluyen las funciones que han sido reubicadas en éstas y que acceden a los datos a ser reubicados. La reubicación de los atributos legados tiene como objetivo el seguir manteniendo la misma definición de atributos, para que no haya variantes en cuanto a funcionalidad al tiempo de que éstos sean reubicados en las clases concretas de la plantilla MVC, que previamente incluyen funciones legadas especializadas y otras reestructuradas a partir de las funciones no-especializadas legadas. Para el desarrollo del método se utilizó el autómata de la figura 5.12.

Figura 5.12. Autómata de reubicar atributos.

Procedimiento. 1. Abrir el archivo que contiene una clase con atributos. 2. Mientras existan atributos declarados en la clase.

2.1. Identificar un atributo y generar un vector para el atributo. Por ejemplo: “String [] vAtributo = NULL;”

2.2. Agregar al vector vAtributo la declaración del atributo.

vOriginal public void print ( ) { System.out.println(“Imprime resultados”); return 0; }

public void funVista1(){ System.out.println(“Imprime resultados”); return 0; } vModelo

public void calc ( int x , int y ) { x = x * (y+2); return x; } public void funModelo1(int x,int y){ x= x * (y+2); return 0; }

Figura 5.11. Funciones generadas a partir del método “Crear función”.


107

vAtributo public int Atributo1;

2.3. Si el atributo es inicializado en el constructor de la clase, entonces agregar la

inicialización en el vector vAtributo. vAtributo

public int Atributo1; Atributo1 = 10;

2.4. Identificar las funciones que acceden al atributo y agregar el nombre de éstas al

vAtributo.

vAtributo public int Atributo1; Atributo1 = 10; funVista1() funModelo1()

2.5. Ir al paso 2.

3. Mientras existan atributos sin ser reubicados. 3.1. Si un atributo es accedido por una función que pertenece a la vista, entonces:

3.1.1.Abrir el archivo “cVista.java”. 3.1.2.Tomar del vector vAtributo la definición del atributo y agregarlo a la definición

de la clase. Por ejemplo: public class cVista implements aVista(){ public int Atributo1; 3.1.3.Si el atributo es inicializado, entonces tomar la inicialización del vector vAtributo y agregarla en el constructor de la clase “cVista”.

public cVista(){ Atributo1 = 10;

3.2. Si un atributo es accedido por una función que pertenece al control, entonces: 3.2.1.Abrir el archivo “cControl.java”. 3.2.2.Tomar del vector vAtributo la definición del atributo y agregarlo a la definición

de la clase. Por ejemplo: public class cControl implements aControl(){ public int Atributo1; 3.2.3.Si el atributo es inicializado, entonces tomar la inicialización del vector

vAtributo y agregarla en el constructor de la clase “cControl”. public cControl(){ Atributo1 = 10;

3.3. Si el atributo es accedido por una función que pertenece al Modelo, entonces: 3.3.1.Abrir el archivo “cModelo.java”. 3.3.2.Tomar del vector vAtributo la definición del atributo y agregarlo a la definición

de la clase. Por ejemplo: public class cModelo implements aModelo(){

public int Atributo1; 3.3.3. Si el atributo es inicializado, entonces tomar la inicialización del vector

vAtributo y agregarla en el constructor de la clase “cModelo”. public cModelo(){ Atributo1 = 10;

4. Termina el método heurístico. La figura 5.13 es un ejemplo una clase legada que incluye un atributo que es

inicializado en el constructor.


108

El vector vAtributo de la figura 5.14 se genera a partir de la identificación del atributo y de su inicialización, para posteriormente reubicar la información en las clases correspondientes, en este caso sería en las clases concretas cVista y cModelo.

5.1.7. Método heurístico H:10, “Fragmentar funciones”. El método consiste en fragmentar las funciones no-especializadas y utilizar el método de crear funciones para generar funciones especializadas. Las funciones especializadas serán agrupadas en los vectores utilizados por el método heurístico que aquí se desarrolla, para que sean reubicadas en la plantilla de la arquitectura MVC. Intención. Generalmente las arquitecturas legadas implementan funciones no-especializadas, éstas deben ser fragmentadas y generar nuevas funciones, mismas que deben se convierten a partir de la fragmentación en funciones especializadas. Lo anterior tiene como objetivo obtener funciones especializadas a partir de las no-especializadas para que éstas queden ubicadas en la clase correspondiente de la plantilla MVC. El método desarrollado en este punto también fragmenta las funciones especializadas, éstas no se les agrega otro nombre, son almacenadas en los vectores utilizados en este

vAtributo

public class cVista{ public int x; public cVista(){ x = 10; } public void funVista1(){ System.out.println(x); } }

public class cModelo{ public int x; public cModelo(){ x = 10; } public void funModelo1(){ x = x*12; } }

public int x; x = 10; funVista1() funModelo1()

public class ClaseA{ public int x; public ClaseA(){ x = 10; } public void funVista1(){ System,out.println(x); } public void funModelo1(){ x = x*12; } }

Figura 5.13. Una clase con un atributo declarado e inicializado en un constructor

Figura 5.14. Atributos reubicados en las clases concretas correspondientes.


109

método, para después reubicarlas utilizando el método heurístico “Reubicar funciones”. Para el desarrollo del método se utilizó el autómata de la figura 5.15.

Figura 5.15. Autómata para fragmentar funciones.

Procedimiento. 1. Abrir el archivo que contiene una clase con funciones. 2. Mientras existan funciones en la clase, identificar la primera función y crear un vector

llamado vOriginal para almacenar los estatutos de código de la función en estudio. “String [] vOriginal =NULL;”

3. Crear una variable de tipo string llamada TA y asignarle el valor de NULL para después almacenar el tipo al que pertenece el estatuto en estudio. “ String TA = NULL;”

4. Crear una variable de tipo string llamada TO y asignarle el valor de NULL para almacenar en ésta, el tipo al que pertenece el primer estatuto de código de la función en estudio. “ String TO = NULL”

5. Asignar a la variable TA la etiqueta que identifica al primer estatuto de la función en estudio. Por ejemplo: TA = EV;

6. Asignar al vector vOriginal el nombre y la firma de la función en estudio. Por ejemplo. vOriginal

public void fun. ( int x; )

7. Si la etiqueta almacenada en TA es igual a EI (lo que significa que es un estatuto de

invocación) entonces: 7.1. Si la función invocada es no-especializada entonces ir al paso 2 para fragmentarla.

7.1.1. Asignarle a TA la etiqueta del siguiente estatuto. Por ejemplo: TA = EC;

7.1.2. Si la etiqueta almacenada en la variable TA es igual a EI entonces ir al paso 7.1.


110

7.1.2.1.Caso contrario. 7.1.2.1.1. Si el valor almacenado en la variable TO es igual a NULL, entonces

almacenar en TO el valor de TA. Por ejemplo: TO = TA;

7.1.2.1.2. Ir al paso 9. 7.1.2.1.3. Si el valor almacenado en la variable TO es diferente de NULL, ir al

paso 9. 7.1.3. Asignar a vOriginal una llamada a la nueva función creada, mediante la

heurística H:11 (§ 5.1.8). 7.2. Si la función invocada es una función especializada entonces:

7.2.1. Crear un nuevo vector para esta función. “String [] vOriginal = NULL”

7.2.2. Recorrer la función especializada invocada en estudio y agregar estatuto por estatuto en el nuevo vector generado.

7.2.3. Asignar a la variable TA la etiqueta del siguiente estatuto. TA = TipoSigEstatuto; 7.2.4. Si el estatuto almacenado en la variable TA es igual a EI entonces ir al paso 7.1. 7.2.5. Caso contrario.

7.2.5.1. Si el valor almacenado en la variable TO es igual a NULL, entonces almacenar en TO el valor de TA para definir a que parte del patrón MVC pertenecerá nueva función que será generada.

TO=TA; 7.2.5.2. Ir al paso 9.

7.2.6. Si el valor almacenado en la variable TO es diferente de NULL, ir al paso 9. 7.3. Si la función especializada analizada es de la vista entonces:

7.3.1. Abrir el archivo “cVista.java”. 7.3.2. Vaciar el contenido del vector vOriginal en el archivo. 7.3.3. Cerrar el archivo “cVista.java”. 7.3.4. Abrir el archivo “aVista.java”. 7.3.5. Concatenar la siguiente cadena public abstract al tipo de retorno y nombre de la

función recién creada. Por ejemplo: public abstract void funVista();

7.3.6. Copiar al archivo la instrucción del paso anterior. 7.3.7. Cerrar el archivo “aVista.java”.

7.4. Si la función especializada analizada es del control entonces: 7.4.1. Abrir el archivo “cControl.java”. 7.4.2. Vaciar el contenido del vector vOriginal en el archivo. 7.4.3. Cerrar el archivo “cControl.java”. 7.4.4. Abrir el archivo “aControl.java”. 7.4.5. Concatenar la siguiente cadena public abstract al tipo de retorno y nombre de la

función recién creada. Por ejemplo: public abstract void funControl();

7.4.6. Copiar al archivo la instrucción del paso anterior. 7.4.7. Cerrar el archivo “aControl.java”.

7.5. Si la función especializada analizada es del modelo entonces: 7.5.1. Abrir el archivo “cModelo.java”. 7.5.2. Vaciar el contenido del vector vOriginal en el archivo. 7.5.3. Cerrar el archivo “cModelo.java”. 7.5.4. Abrir el archivo “aModelo.java”.


111

7.5.5. Concatenar la siguiente cadena public abstract al tipo de retorno y nombre de la función recién creada. Por ejemplo: public abstract void funModelo();

7.5.6. Copiar al archivo la instrucción del paso anterior. 7.5.7. Cerrar el archivo “aModelo.java”.

7.6. Llamar la heurística H:11 (§ 5.1.8) y registrar en el vOriginal el estatuto correspondiente para que invoque a la nueva función generada.

8. Si el estatuto almacenado en la variable TA es diferente de EI entonces. 8.1. Almacenar en la variable TO el valor de TA.

TO = TA; 8.2. Ir al paso 9.

9. Mientras TA sea diferente de fin de bloque. 9.1. Si la etiqueta almacenada en la variable TA es igual a EM entonces:

9.1.1. Si la variable TO es igual a EM. 9.1.1.1. Mientras la variable TA sea igual a EM.

9.1.1.1.1. Registrar el estatuto en estudio en vOriginal. 9.1.1.1.2. Asignarle a la variable TA la etiqueta del siguiente estatuto.

TA = EtSigEstatuto; 9.1.2.Si la variable TO es diferente a EM.

9.1.2.1.Crear el vector vModelo. 9.1.2.2. Mientras la variable TA sea igual a EM.

9.1.2.3. Registrar el estatuto en estudio en el vector vModelo. 9.1.2.4. Asignarle a la variable TA la etiqueta del siguiente estatuto.

TA = EtSigEstatuto; 9.1.3. Abrir el archivo “cModelo.java”. 9.1.4. Llamar la heurística “Crear función” para crear una función del modelo en el

archivo. 9.1.5. Cerrar el archivo “cModelo.java”. 9.1.6. Abrir el archivo “aModelo.java”. 9.1.7. Concatenar la siguiente cadena public abstract al tipo de retorno y nombre de la

función recién creada. Por ejemplo: public abstract void funModelo();

9.1.8. Agregar al archivo la instrucción del paso anterior. 9.1.9. Cerrar el archivo “aModelo.java”. 9.1.10. Llamar la heurística de “Redefinir llamadas a funciones” y registrar en el

vOriginal el estatuto correspondiente para que invoque a la nueva función generada.

9.2. Si la etiqueta almacenada en la variable TA es igual a EV entonces: 9.2.1. Si la variable TO es igual a EV.

9.2.1.1. Mientras la variable TA sea igual a EV. 9.2.1.1.1. Registrar el estatuto en estudio en vOriginal. 9.2.1.1.2. Asignarle a la variable TA la etiqueta del siguiente estatuto.

TA = EtSigEstatuto; 9.2.2.Si la variable TO es diferente a EV.

9.2.2.1.Crear el vector vVista. 9.2.2.2. Mientras la variable TA sea igual a EV.

9.2.2.3. Registrar el estatuto en estudio en el vector vVista. 9.2.2.4. Asignarle a la variable TA la etiqueta del siguiente estatuto.

TA = EtSigEstatuto; 9.2.3. Abrir el archivo “cVista.java”.


112

9.2.4. Llamar la heurística “Crear función” para crear una función de la vista en el archivo.

9.2.5. Cerrar el archivo “cVista.java”. 9.2.6. Abrir el archivo “aVista.java”. 9.2.7. Concatenar la siguiente cadena public abstract al tipo de retorno y nombre de la

función recién creada. Por ejemplo: public abstract void funVista();

9.2.8. Copiar al archivo la instrucción del paso anterior. 9.2.9. Cerrar el archivo “aVista.java”. 9.2.10. Llamar la heurística de “Redefinir llamadas a funciones” y registrar en el


9.3. Si el estatuto almacenado en la variable TA es igual a EC entonces: 9.3.1. Si la variable TO es igual a EC.

9.3.1.1. Mientras la variable TA sea igual a EC. 9.3.1.1.1. Registrar el estatuto en estudio en vOriginal. 9.3.1.1.2. Asignarle a la variable TA el valor del siguiente estatuto.

TA = EtSigEstatuto; 9.3.2.Si la variable TO es diferente a EC.

9.3.2.1.Crear el vector vControl. 9.3.2.2.Mientras la variable TA sea igual a EV.

9.3.2.3. Registrar el estatuto en estudio en el vector vControl. 9.3.2.4. Asignarle a la variable TA el valor del siguiente estatuto.

TA = EtSigEstatuto; 9.3.3. Abrir el archivo “cControl.java”. 9.3.4. Llamar la heurística “Crear función” para crear una función del control en el

archivo. 9.3.5. Cerrar el archivo “cControl.java”. 9.3.6.Abrir el archivo “aControl.java”. 9.3.7. Concatenar la siguiente cadena public abstract al tipo de retorno y nombre de la

función recién creada. Por ejemplo: public abstract void funControl();

9.3.8. Copiar al archivo la instrucción del paso anterior. 9.3.9. Cerrar el archivo “aControl.java”. 9.3.10. Llamar la heurística de “Redefinir llamadas a funciones” y registrar en el


9.4. Si la etiqueta almacenada en la variable TA es igual a EI entonces, ir al paso 7.1. 9.5. Termina el método heurístico.

La figura 5.16 es un ejemplo de una función no-especializada que debe ser

fragmentada, la función además de incluir estatutos de código incluye una invocación a otra función, ésta última es una función especializada.


113

La figura 5.17 representa la manera en que quedó fragmentada la función no-especializada funMez(int x) representada en la figura 5.17.

public void funMezc(int x){//FMz System.out.println(“El valor de x es” + x); //EV x = x * 100; //EM System.out.println(“El valor de x es” + x) //EV funModelo2(); //EI }

public int funModelo2(){//FM int x; //EM int y; //EM while(x!=10){//EM x++; //EM y = x*10; //EM } return y; //EM }

Figura 5.16. Función no-especializada invocando una función especializada.

public int funModelo2(){ int x; int y; while(x!=10){ x++; y = x*10; } return y; }

public int funModelo2 ( ) Int x,y; { while(x!=10){ x++; y = x *10; } }

Vector vOriginal utilizado en la función no-especializada

Vector vOriginal utilizado para reubica la función especializada

public void funVista1(int x){ System.out.println(“ x =” + x); oC.oM.funModelo1(int x); System.out.println(“x =” + x); oC.oM.funModelo2(); }

public void funMezc ( int x ) { System.out.println(“x =” + x); oC.oM.funModelo1(int x); cont…

System.out.println(“x =” + x); oC.oM.funModelo2(); }

Función generada a partir de la función no-especializada: public void funMezc.

La función especializada funModelo2, permanece sin ser fragmentada.

public int funModelo2(){ int x; int y; while(x!=10){ x++; y = x*10; } return y; }

public int funModelo2 ( ) { int x,y; while(x!=10){ x++; y = x *10; } }

Figura 5.17. Función no-especializada fragmentada.


114

5.1.8. Método heurístico H:11, “Redefinir llamadas funciones”. El método consiste en sustituir la actual llamada a una función, que después de ser fragmentada queda ubicada en alguna de las clases de la plantilla MVC. Intención. A partir de la fragmentación de las funciones legadas se generan nuevas funciones que son especializadas, algunas funciones aún mantienen llamadas a otras funciones que ahora se encuentran en otra clase y es necesario sustituir esa invocación por la llamada correspondiente, ya que las funciones generadas deben quedar ubicadas en alguna de las clases de la plantilla del patrón MVC. Para el desarrollo del método se utilizó el autómata de la figura 5.18.

Figura 5.18. Autómata para redefinir llamadas.

Procedimiento. 1. Analizar la función en estudio. 2. Si la función en estudio pertenece a la vista entonces:

2.1. Crear un vector llamado vInvocacionVista. “String [] vInvocacionVista =NULL;”

2.2. Mientras existan estatutos de invocación en la función en estudio. 2.2.1. Identificar el estatuto de invocación y guardarlo en el vector, por ejemplo.

Obj. funVista(); vInvocacionVista


115

2.2.2. Si la llamada es a una función de la vista entonces: 2.2.2.1. Eliminar el objeto concatenado al nombre de la función y sólo dejar el

nombre de la función. Por ejemplo:

2.2.3. Si la llamada es a una función del control entonces:

2.2.3.1. Sustituir el objeto concatenado al nombre de la función por la siguiente cadena “oC.” + “nombreDeFuncion”. Por ejemplo:

2.2.4. Si la llamada es a una función del modelo entonces:

2.2.4.1. Sustituir el objeto concatenado al nombre de la función por la siguiente cadena “oC.oM.” + “nombreDeFuncion”. Por ejemplo:

2.2.5. Reemplazar la invocación original por el contenido del vector en la función en

estudio y dejarlo vacío. 3. Si la función en estudio pertenece al control entonces:

3.1. Crear un vector llamado vInvocacionControl. “String [] vInvocacionControl =NULL;”

3.2. Mientras existan estatutos de invocación en la función en estudio. 3.2.1. Identificar el estatuto de invocación y guardarlo en el vector, por ejemplo.

3.2.2. Si la llamada es a una función de la vista entonces: 3.2.2.1. Sustituir el objeto concatenado al nombre de la función por la siguiente

cadena: “oM.oV.” + “nombreDeFuncion”. Por ejemplo:


3.2.3.1. Eliminar el objeto concatenado al nombre de la función y sólo dejar el nombre de la función. Por ejemplo


3.2.4.1. Sustituir el objeto concatenado al nombre de la función por la siguiente cadena “oM.” + “nombreDeFuncion”. Por ejemplo:

3.2.5. Reemplazar la invocación original por el contenido del vector en la función en

estudio y dejarlo vacío. 4. Si la función en estudio pertenece al modelo entonces:

4.1. Crear un vector llamado vInvocacionModelo.

funVista();

oC.funControl();

oC.oM.funModelo();

Obj. funControl();

oM.oV.funVista();

funControl();

oM.funModelo();

vInvocacionVista

vInvocacionVista

vInvocacionVista

vInvocacionControl

vInvocacionControl

vInvocacionControl

vInvocacionControl


116

“String [] vInvocacionModelo =NULL;” 4.2. Mientras existan estatutos de invocación en la función en estudio.

4.2.1. Identificar el estatuto de invocación y guardarlo en el vector, por ejemplo.

4.2.2. Si la llamada es a una función de la vista entonces: 4.2.2.1. Sustituir el objeto concatenado al nombre de la función por la siguiente

cadena: “oV.” + “nombreDeFuncion”. Por ejemplo:


4.2.3.1. Sustituir el objeto concatenado al nombre de la función por la siguiente cadena “oV.oC.” + “nombreDeFuncion”. Por ejemplo:


4.2.4.1. Eliminar el objeto concatenado al nombre de la función y sólo dejar el nombre de la función. Por ejemplo:

4.2.5. Escribir el contenido del vector en la función en estudio y dejarlo vacío. 5. Termina el método heurístico.

La figura 5.19 representa un ejemplo que muestra a una función que incluye llamadas a otras funciones especializadas, a través de un objeto.

La figura 5.20 presenta los distintos valores que va tomando el vector generado para

almacenar los estatutos de invocación. En la figura 5.20 también está incluida la manera en que quedan redefinidos los estatutos de invocación.

Obj. funModelo();

oV.funVista();

oV.oC.funControl();

funModelo();

Figura 5.19. Función que incluye llamadas a otras funciones.

vInvocacionModelo

vInvocacionModelo

vInvocacionModelo

vInvocacionModelo

Función que incluye llamadas a otras funciones.

public void funModelo(int x){ System.out.println(“x =” + x); Obj.funModelo1(int x); Obj.funVista(); System.out.println(“x =” + x); Obj.funControl(); }


117

5.2. Comentarios finales.

5.2. Comentarios finales. Han sido desarrollados un total de 8 métodos heurísticos como un primer acercamiento para migrar marcos de aplicaciones orientados a objetos, conforme a una arquitectura basada en el patrón de diseño MVC. Los métodos necesariamente deben ser probados con aplicaciones reales para demostrar su correcta funcionalidad. Hasta este punto los métodos fueron probados con ejemplos de escritorio.

Con los métodos heurísticos desarrollados en este capítulo se logró llegar a una plantilla basada en el patrón MVC, generada a partir de la arquitectura de un marco orientado a objetos legado.

Los métodos heurísticos “Sub-jerarquizar”, “Super-jerarquizar” y “Cohesionar clases”, no fueron desarrollados debido a que no estaban definidos en el alcance de la tesis, además de que sólo proporcionarán una mejor estructura a la arquitectura obtenida a partir de la utilización de los métodos aquí desarrollados, por tal motivo es necesario probar primero la correcta funcionalidad de los métodos que sí fueron desarrollados. Los métodos heurísticos “Generación de objetos” y “Reubicar todos los imports”, deben colaborar con los tres métodos no desarrollados que fueron mencionados previamente, por tal motivo se propone que sean desarrollados después de los métodos de Sub-jerarquizar, Super-jerarquizar y Cohesionar clases.

Figura 5.20. Ejemplo de una función que incluye llamadas que deben ser redefinidas.

Vector vInvocacionModelo tomando diferentes valores

Obj. funModelo1(int x);

funModelo1(int x);

Primer valor que toma el vector. Se sustituye la llamada de acuerdo al método heurístico

Obj. funVista();

oV.funVista();

Segundo valor que toma el vector. Se sustituye la llamada de acuerdo al método heurístico

Obj. funControl();

oV.oC.funControl();

Tercer valor que toma el vector. Se sustituye la llamada de acuerdo al método heurístico

public void funModelo(int x){ System.out.println(“ x =” + x); funModelo1(int x); oV.funVista(); System.out.println(“x =” + x); oV.oC.funControl(); }

Función con las nuevas llamadas.

CAPÍTULO 6 CONCLUSIONES

118

Capítulo 6) CONCLUSIONES Este capítulo describe las conclusiones generadas a partir del trabajo de tesis, así como también algunas ideas que pueden ser consideradas para futuras investigaciones.

6.1. Conclusiones. La reutilización de los sistemas de software legado ha sido una práctica favorable que permite incrementar la productividad de los desarrolladores, que además promete reducir el tiempo y costo de desarrollo de nuevos sistemas.

Reutilizar el software legado no resuelve todos los problemas generados a raíz de la crisis del software, pero con el gran número de técnicas implementadas para la reutilización del software legado, se favorece la productividad en el desarrollo.

En esta tesis se han documentado el mayor número de escenarios que posiblemente se encontrarán en el código de los sistemas o marcos legados escritos en lenguaje Java. Con el análisis de escenarios fue posible desarrollar un conjunto de ocho métodos heurísticos, mismos que son el producto resultante de esta tesis.

Con el desarrollo de los métodos heurísticos, se tiene un primer acercamiento en la migración de sistemas legados hacia arquitecturas de sistemas distribuidos, se espera seguir contribuyendo para que los sistemas legados sean reutilizados en nuevas arquitecturas de software. Los métodos heurísticos son la principal aportación de la tesis.

Según lo analizado en el estudio de los trabajos relacionados, investigaciones similares a la presente tesis son muy laboriosas, debido a que requieren de mucho tiempo y habilidad para cumplir con los objetivos planteados. Esto se debe principalmente en que para migrar un sistema legado se tienen que desarrollar varias etapas, por ejemplo: hacer un análisis del código legado para desarrollar soluciones que identifiquen el código y luego lo reestructuren, estas soluciones deben ser programadas en una herramienta de reestructura, para que de


119

preferencia la reestructura se lleve a cabo de manera automática. Sumado a lo anterior también viene la etapa de pruebas la cual valida que el resultado del sistema obtenido a partir de la reestructura conserve la misma funcionalidad que el código original.

La etapa de análisis es la etapa que más habilidad demanda para los encargados de llevar a cabo la tarea de reestructura por tal motivo debe de incluir el mayor conjunto de escenarios que puedan presentarse en los sistemas legados, ya que el no contar con una solución para un escenario no analizado, puede provocar que la tarea de reestructura fracase y que no se conserve la funcionalidad del código legado. Con base a lo descrito anteriormente, las aportaciones de esta tesis son:

La aportación principal de esta tesis es la generación del conocimiento de los principales fenómenos que suceden cuando se requieren llevar a cabo trabajos de reestructura de sistemas legados.

Otra aportación es mostrar la cantidad de escenarios que pueden estar presentes al momento de llevar a cabo la reestructura de código legado, así como también el conocimiento que muestra la complejidad y factibilidad de este tipo de trabajos.

Los escenarios identificados documentan la manera en que el código puede estar presente en los sistemas legados y una solución de reestructura utilizando los métodos heurísticos. Estos escenarios pueden ser utilizados en otras investigaciones, ya sea para desarrollar sus propios algoritmos de reestructura o completar este conjunto de escenarios y utilizar los métodos heurísticos.

Los escenarios analizados son aquellos que incluyen los siguientes casos:

• A nivel de micro-arquitecturas que presentan herencia y composición con sus respectivas variantes.

• A nivel de clases, los casos de clases especializadas y clases no-especializadas. • A nivel de función, escenarios en el que la función en estudio incluye estatutos

relacionados a una misma parte del patrón MVC o en otros casos la función incluye estatutos de diferente parte.

• El análisis también incluye los casos en los cuales existen atributos y funciones que tienen la característica de ser públicos, privados, protegidos y friendly dentro de una clase.

• Los escenarios identificados fueron basados en un diagrama de casos de uso. Con este análisis de escenarios se pretende cubrir la mayor parte de casos que puedan

estar presentes en el código de los sistemas legados y generar una solución para reestructurarlos, sin embargo, al llevar a cabo el análisis se detectó que a partir de un escenario pueden ir surgiendo nuevas variantes si se conjuntan uno o más escenarios, propiciando que la cantidad de variantes pueda convertirse en un problema exponencial y difícil de delimitar.

A partir del análisis también se concluye que pueden presentarse tantos escenarios como maneras de programar existentes. Es decir cada programador tiene su estilo y técnica para desarrollar software y de cada estilo distinto pueden surgir distintas variantes, es por eso que a partir del análisis de escenarios se deben generar soluciones abstractas para cualquier sistema legado.

Una importante aportación es el desarrollo de los métodos heurísticos de reestructura para darle tratamiento a las diferentes situaciones que pueden ocurrir por las variaciones de estilo y habilidad de los desarrolladores para crear sistemas, lo que puede impactar en la reestructura de los sistemas legados.


120

Con los métodos se crea una solución abstracta, misma que puede ser incluida en un futuro proceso de reestructura de código legado, es decir, que los métodos heurísticos sean programados en alguna herramienta para la reestructura del código legado ya sea de forma semi-automática o automática.

Se desarrollaron un total de ocho métodos heurísticos, la solución que éstos generan es: a partir de un análisis del código legado, se crea una plantilla genérica conforme al patrón MVC, a la cual se le va agregando partes del código legado, como lo son atributos, métodos, constructores e inicialización de datos.

También se detalla una solución con el método heurístico “Crear función”, para que a partir de la fragmentación de funciones no-especializadas generar nuevas funciones. Para el caso de las funciones especializadas, deben ser agregadas a una nueva función utilizando también el mismo procedimiento que utiliza las funciones no-especializadas. El objetivo final es tener en cada una de las clases concretas de la plantilla MVC, funciones especializadas relacionadas con una parte del patrón MVC.

Con la descripción de las aportaciones se justifica que el objetivo de esta tesis fue cumplido, ya que además de que se cubrió con el análisis de un amplio conjunto de escenarios y la información obtenida sirvió para generar los métodos, además como una aportación derivada se pudieron ver características importantes relacionados con la factibilidad de llevar a cabo trabajos que tienen como línea de investigación, la reestructura de sistemas legados.

Trabajos futuros. Hasta esta tesis se han presentado un conjunto de ocho métodos heurísticos que deben ayudar en la tarea de reestructura de sistemas legados, para la migración pueda llevar a cabo en su totalidad a continuación se propone como trabajos futuros lo siguiente:

• Se propone continuar con el desarrollo de los métodos heurísticos pendientes. Esta tesis no incluye la fragmentación de las clases concretas de la plantilla MVC, ya que el alcance de la tesis era llegar a componer una arquitectura basada en el patrón MVC, generada con la heurística “Definir plantilla genérica MVC”. Por tal motivo se propone que se desarrollen los métodos heurísticos de “Cohesionar clases”, “Sub-Jerarquizar” y “Super-jerarquizar” que deben incluir la solución para fragmentar las clases concretas.

• Se propone que se desarrollen los métodos heurísticos de “Generación de objetos” y “Reubicar todos los imports”, con la intensión de que colaboren con los tres métodos mencionados en el punto anterior, ya que al volver a reestructurar la arquitectura se requiera de alguna modificación en las partes internas.

• Una de las primeras actividades en la reestructura de sistemas legados, es llevar a cabo un análisis del código que generalmente es de forma automática. Para la parte de análisis se propone que se realice un estudio de la gramática de Java y de las librerías de Java “AWT” y “SWING”, para identificar los objetos (clases, funciones y constructores) relacionados con las diferentes partes del patrón MVC y generar un analizador que permita obtener la información necesaria para implementarla en algún software de reestructura.

• Para el analizador se deben tomar en cuenta las diferentes relaciones y dependencias presentes en el código legado, ya sea en marcos orientados a objetos o en el código de los sistemas legados. El objetivo de esta etapa es incluir la información necesaria para que con base a los métodos heurísticos correspondientes se genere la plantilla MVC y sea reubicada la información analizada.


121

• Otro trabajo que puede derivarse a partir de esta tesis es el completar el proceso de reestructura con la automatización de los métodos heurísticos. La automatización puede ser llevada a cabo desarrollando una herramienta de reestructura de preferencia automática.

• Por último se propone desarrollar una estrategia para integrar todas las heurísticas y verificar su buen funcionamiento antes de su automatización mediante pruebas manuales.

REFERENCIAS

122

REFERENCIAS [AHOK,03] Ahokas, T., “Using XML in parking legacy application data accesible through

Web services.” Tesis de Maestría, Universidad de tecnología de Helskinki. Helsinki Finlandia, 2003. Consultado en 25/10/07 en http://www.tml.tkk.fi/Publications/Thesis/ahokas.pdf.

[AVIL,06] Ávila, E., “Sistema de separación automática de las interfaces al usuario y

funcionales para Servicios Web a partir de su código legado.” Tesis de maestría, Departamento de Ciencias Computacionales, CENIDET, 2006.

[BODH,02] Bodhuin, T., Guardabascio E., Tortorella M. “Migrating COBOL Systems to

the WEB by using the MVC Desing Pattern”, Proc. of the 9th IEEE Working Conference on Reverse Engineering, Richmond, VA, USA, IEEE CS Press, 2002 pp. 329-338.

[BUST,03] Bustamante, C., “Reestructuración de código legado a partir del

comportamiento para la generación de componentes reutilizables.” Tesis de maestría, Departamento de Ciencias Computacionales, CENIDET, 2003.

[CANF,06] Canfora G., Fasolino A., Frattolillo G., Tramontana P., “Migrating Interactive

Legacy Systems to Web Services”, Proc. of the 10th Conference on Software Maintenance and reengineering, Bari, Italia, IEEE CS Press, 2006 pp. 24-36.

[CANF,07] Canfora, G. Di Penta, M., (2007) “New Frontiers of Reverse Engineering”

Future of Software Engineering – FoSE, Editores, Lionel C. Briand y Alexander L. Wolf, IEEE Computer Society Press, pp. 326-341.

[CARD,04] Cárdenas, L., (2004). “Refactorización de marcos orientados a objetos para

reducir el acoplamiento aplicando el patrón de diseño MEDIATOR.” Tesis de Maestría, Departamento de Ciencias Computacionales, CENIDET, 2004.

[CEBA,00] Ceballos, F. (2000) “Java 2 Curso de programación.” Alfaomega, pp. 7-9, 23-

33. [DEAC,05] Deacon, J. “Arquitectura Modelo-Vista-Controlador (MVC)”, Consultado en

11/10/2007 en http://www.jdl.co.uk/briefings/MVC.pdf [DIST,06] Distante, D., et al. “Towards a Holistic Approach to Redesigning Legacy

Applications for the Web with UWAT” Proc. of the 10th Conference on Software Maintenance and Reengineering, Bari, Italy, IEEE CS Press, 2006, pp. 295-299

[ERLT,04] Erl, T., (2004). “Service-Oriented-Architecture a field guide to integrating

XMl and Web Services” Prentice Hall pp 53. [ERLT,06] Erl, T., (2006). “Service-Oriented-Architecture concepts, technology, and

design”. Prentice Hall pp.86-103.

REFERENCIAS

123

[FAIS,98] Faisal, B., “What is legacy software?”, Consultado en 16/10/2007 en http://www.suite101.com/article.cfm/reengineering/9540

[FRAN,03] France, R., et. Al. “A Metamodeling Approach to Pattern-Based Model

Refactoring”, IEEE Software, Vol 20, pp 52-58. [FUEN,06] Fuentes L., et. Al. “Desarrollo de Software Basado en Componentes”.

Consultado en 08/10/2006 en http://www.lcc.uma.es/~av/Docencia/Doctorado/tema1.pdf [GAJA,04] Gajardo, F., Mateu L. Análisis semántico de programas escritos en Java.

Theoria, Ciencia, arte y humanidades.2004 Consultado en 27/11/06 en http://redalyc.uaemex.mx/redalyc/src/inicio/ArtPdfRed.jsp?iCve=29901304&iCveNum=1392.

[GAMA,95] Gamma, E., et. al. (1995). “Patrones de diseño elementos de software orientado

a objetos reutilizable.” Addison Wesley, pp. 99-108, 215-223, 269-278. [HERN,03] Hernández, L., “Factorización de funciones hacia métodos de plantilla.” Tesis

de maestría, Departamento de Ciencias Computacionales, CENIDET, 2003. [KOSA,04] Kosar, T., Mernik M., Zumer V., “JART: Grammar-Based Approach to

Refactoring”, Proc. of the 28th Annual International Computer Software and Applications Conference, Hong Kong IEEE CS Press, 2004 pp. 183-188.

[LIUY,07] Liu, Y., Yang, A., "Research and Applications of Software-reuse", Proc. of the

8th ACIS international conference on Software Engineering, Artificial Intelligence, networking and parallel/distributed computing, Qingdao, China, IEEE CS Press, 2007, pp. 588-593.

[MEND,04] Méndez, A., “Reestructuración de software escrito por procedimientos

conducido por patrones de diseño composicionales.” Tesis de maestría, Departamento de Ciencias Computacionales, CENIDET, 2004.

[OBRI,05] O`Brien L., Smith D., Lewis G., “Supporting Migration to Services using

Software Architecture Reconstruction”, Proc. of the 13th IEEE International Workshop on Software Technology and Engineering Practice, Budapest, Hungría, IEEE CS Press, 2005 pp. 81-91.

[OROZ,05] Orozco, J., Alquicira, C., (2205) “MoProSoft en la práctica”, Software Gurú,

pp 32-34. [PEAR,85] Pearl, J., (1985) “Heurísticas: estrategias de búsqueda inteligente para resolver

problemas computacionales.” Addison Wesley, pp. 3. [PING,04] Ping, Y., Kontogiannis K., Lau T., “Transforming Legacy Web Applications to

the MVC Architecture”, Proc. of the 11th Annual International Workshop on Software Technology and Engineering Practice, Chicago, IL, USA, IEEE CS Press, 2004 pp. 133-142.

REFERENCIAS

124

[REAL,05] Real Software, “Diseño de aplicaciones Internet usando los Patrones de diseño J2EE”, Consultado en 31/10/2006 en http://www.r-software.com/Doctos/patrones.pdf

[SANT,02] Santaolaya, R., “Modelo de representación de patrones de código para la

construcción de componentes reusables.” Tesis de Doctorado, Departamento de Ciencias Computacionales, Centro de Investigación en Computación, IPN, 2002.

[SANT,05] Santos, L., “Adaptación de interfaces de marcos de aplicaciones orientados a

objetos, usando el patrón de diseño ADAPTER.” Tesis de maestría, Departamento de Ciencias Computacionales, CENIDET, 2005.

[SHIV,07] Shiva, S., Abou, L., "Software Reuse:Research and Practice", Proc. of the

international conference of information technology, Las Vegas, NV, USA, IEEE CS Press, 2007 pp. 603-609.

[SOFT,05] Real Software, “Diseño de aplicaciones Internet, usando los Patrones de diseño

J2EE”, Consultado en 31/10/2006 en http://www.r-software.com/Doctos/patrones.pdf

[SOMM,02] Sommerville, I., (2002). “Ingeniería de software.”, Addison Wesley pp. 623-

625. [STRO,02] Stroulia E., Mohammad E., Sorenson P., “From Legacy to Web through

Interaction Modeling”, Proc. of the International Conference on Software Maintenance, Montreal, QC, Canada, IEEE CS Press, 2002 pp. 320-329.

[STUA,96] Stuart, R., (1996). “Inteligencia artificial: un enfoque moderno.” Prentice Hall,

pp. 101-102. [TORR,06] Torres C., “Estado del arte referente a patrones de software en aplicaciones

Web corporativas y su implementación en las tecnologías Java Enterprise Edition 5 y ASP. Net 2.0”, Memorias del 4to congreso internacional en innovación y desarrollo tecnológico, Cuernavaca, Mor, IEEE, 2006.

[VALD,04] Valdés, M., “Métodos de refactorización de marcos de aplicaciones orientados

a objetos por la separación de interfaces.” Tesis de maestría, Departamento de Ciencias Computacionales, CENIDET, 2004.

[WELI,06] Welicki, L., “Patrones y Antipatrones: una Introducción – Parte II” Consultado

en 03/11/06 en http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/MTJ_3317.asp

[YUYI,05] Yu Y., et. al. “Reverse Engineering Goal Models from Legacy Code”, Proc. of

the 13th IEEE International Conference of Requirements Engineering, Paris, Francia, IEEE CS Press, 2005 pp. 363-372.

REFERENCIAS

125

[ZOUY,00] Zou Y., Kontogiannis K., “Web-based Legacy System Migration and Integration”. Consultado en 09/10/2006 en http://www.swen.uwaterloo.ca/~kostas/publications/conferences/C5-2000.pdf

centro nacional de investigación y desarrollo …...de componentes reusables ..... 7 2.1.3....

Documents