Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Refactorización de Marcos Orientados a Objetos hacia Arquitecturas MVC presentada por Luz Christina Gaitán Torres Ing. en Telemática por la Universidad de Colima como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: Dr. René Santaolaya Salgado Co-Directora de tesis: Dra. Olivia Graciela Fragoso Díaz Cuernavaca, Morelos, México. 16 de febrero de 2012 Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Refactorización de Marcos Orientados a Objetos hacia Arquitecturas MVC presentada por Luz Christina Gaitán Torres Ing. en Telemática por la Universidad de Colima como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: Dr. René Santaolaya Salgado Co-Directora de tesis: Dra. Olivia Graciela Fragoso Díaz Jurado: Dr. Joaquín Pérez Ortega– Presidente M.C. Mario Guillén Rodríguez – Secretario M.C. Humberto Hernández García – Vocal Dr. René Santaolaya Salgado – Vocal Suplente Cuernavaca, Morelos, México. 16 de febrero de 2012 Dedicatorias A mi familia Mis padres Efrén Gaitán y Rita Ycela Torres; y a mis hermanas Martha y Mary, cuyo amor y apoyo incondicional me han motivado siempre a superarme. A pesar de la distancia siempre han estado presentes en mi corazón. Los amo. A la familia Salazar Robles Al Sr. José y la Sra. Alicia, por su gran cariño e invaluable apoyo durante todo este tiempo, por acogerme como un miembro más de su familia, muchas gracias. A Pepe Por ser un gran pilar en mi vida, por apoyarme siempre en todos los ámbitos, por escucharme y motivarme en los momentos difíciles y por su paciencia en los momentos de estrés; pero sobre todo por su gran amor, muchas gracias. Te amo. A mis amigos Quienes a pesar de la distancia siempre estuvieron conmigo y aunque sólo los veía unas cuantas veces al año siempre me recibían con gran cariño y me recargaban de energía, gracias Chuy, Lupita y Manuel. A Fideo Por alegrarnos la vida con su existencia durante el tiempo que estuvo con nosotros. Te extrañamos. Agradecimientos Agradezco al Consejo Nacional de Ciencia y Tecnología CONACYT por el apoyo económico que me brindó durante todo este tiempo. Al Centro Nacional de Investigación y Desarrollo Tecnológico CENIDET que me abrió las puertas y me permitió superarme tanto en el ámbito profesional como en el personal, a todos los que labora en el Centro mi más grande agradecimiento. A mi director de tesis el Dr. René Santaolaya Salgado y mi codirectora la Dra. Olivia Graciela Fragoso Díaz, por guiarme y brindarme sus conocimientos ayudándome a llevar a cabo esta investigación. Les agradezco su invaluable apoyo, su paciencia, sus buenos consejos y la confianza que depositaron en mí. A mis revisores Dr. Joaquín Pérez Ortega, M.C. Mario Guillén Rodríguez y M.C. Humberto Hernández García, quienes me guiaron y aconsejaron durante la realización de esta tesis, gracias por su compromiso con este trabajo y por el tiempo que le brindaron. A la M.C. Sheydi Anel Zamudio López con quien tuve la fortuna de trabajar estrechamente, por ayudarme, aconsejarme, por compartir su conocimiento conmigo y por convertirse en una buena amiga. A los distintos maestros que participaron en mi formación profesional durante mi estancia en el CENIDET muchísimas gracias. A mi familia, abuelita, tías, tíos y primos; a Pepe y a las familias Salazar Aviña y Robles López; quienes con su confianza y apoyo colaboraron en la realización de esta tesis. A mis compañeros y nuevos grandes amigos: Adrián, Lucy, Blanca, Liz, Ricardo E. y Ricardo G. por todos los buenos momentos que vivimos, por su gran cariño y apoyo. Siempre ocuparán un lugar muy importante en mi corazón. A mis amigos de toda la vida por estar siempre a mi lado brindándome su apoyo y su amistad. Y a mis excompañeros de trabajo quienes me apoyaron siempre. Muchas gracias. A todos ustedes mil gracias por todo lo que han hecho en mi vida desde que los conocí. Contenido Pag. Contenido ............................................................................................................................................. i Lista de Tablas .....................................................................................................................................iii Lista de Figuras .................................................................................................................................... v Glosario de Términos ......................................................................................................................... vii Resumen..............................................................................................................................................xi Abstract ............................................................................................................................................. xiii Capítulo 1. Introducción ................................................................................................................ 1 1.1 Introducción ........................................................................................................................ 1 1.2 Descripción del problema ................................................................................................... 2 1.3 Objetivo ............................................................................................................................... 3 1.4 Justificación ......................................................................................................................... 3 1.5 Beneficios ............................................................................................................................ 3 1.6 Alcances y Limitaciones ....................................................................................................... 4 1.7 Organización de esta tesis ................................................................................................... 5 Capítulo 2. Antecedentes .............................................................................................................. 7 2.1 Antecedentes ...................................................................................................................... 7 2.2 Estado del arte .................................................................................................................. 10 Capítulo 3. Marco Teórico ........................................................................................................... 19 3.1 Refactorización .................................................................................................................. 19 3.2 Programación Orientada a Objetos................................................................................... 20 3.3 Marcos de aplicaciones orientadas a objetos ................................................................... 21 3.4 Patrón Modelo Vista Controlador (MVC) .......................................................................... 22 3.5 Lenguaje de programación Java ........................................................................................ 26 3.6 Compilador ........................................................................................................................ 30 3.7 Servicio Web...................................................................................................................... 34 3.8 Otros conceptos. ............................................................................................................... 34 Capítulo 4. 4.1 Modelo Conceptual del Sistema ............................................................................... 37 Diseño del Proceso de Refactorización ............................................................................. 37 i Contenido 4.2 MOO2MVA: Marco de Aplicaciones Orientadas a Objetos hacia una arquitectura MVA 40 4.3 A1. Analizar el código del MOO original y etiquetar los estatutos, funciones y clases de acuerdo a las partes del patrón MVA a las que pertenecen. ........................................................ 41 4.4 A2. Reestructurar el código legado. .................................................................................. 51 Capítulo 5. Implementación del Sistema ..................................................................................... 63 5.1 Implementación del proceso de refactorización en la herramienta MOO2MVA ............. 63 5.2 Implementación de la actividad A1. Analizar el código del MOO ..................................... 68 5.3 Implementación de la actividad A2. Reestructurar el código legado. .............................. 73 Capítulo 6. Pruebas del Sistema .................................................................................................. 75 6.1 Identificador del Plan de Pruebas ..................................................................................... 75 6.2 Documentación de Prueba ................................................................................................ 76 6.3 Descripción del Plan de Pruebas ....................................................................................... 76 6.4 Especificación del Diseño de Pruebas ............................................................................... 80 6.5 Especificación de Casos de Prueba ................................................................................... 84 6.6 Resultados de las Pruebas ................................................................................................. 90 6.7 Análisis de Resultados ....................................................................................................... 91 Capítulo 7. Conclusiones y Trabajos Futuros ............................................................................... 93 7.1 Conclusiones...................................................................................................................... 93 7.2 Trabajos futuros ................................................................................................................ 95 Bibliografía ........................................................................................................................................ 97 Anexo A: Métodos de Reestructura ................................................................................................ 101 Anexo B: Descripción de los Casos de Prueba................................................................................. 123 ii Lista de Tablas Pag. Tabla 1. Comparación de trabajos relacionados. .............................................................................. 17 Tabla 2. Descripción del patrón MVC y sus variaciones. ................................................................... 26 Tabla 3. Descripción de la tabla Tipos de clases ............................................................................... 42 Tabla 4. Descripción de la tabla Funciones Abstractas ..................................................................... 43 Tabla 5. Descripción de la tabla Funciones Concretas ...................................................................... 43 Tabla 6. Descripción de la tabla Tipos de Variables .......................................................................... 43 Tabla 7. Descripción de la tabla Jerarquía de Clases ......................................................................... 52 Tabla 8. Descripción de la tabla Variables MVA ................................................................................ 58 Tabla 9. Documentos del plan de pruebas ........................................................................................ 76 Tabla 10. Clases de Java a usarse como elementos de prueba......................................................... 77 Tabla 11. Resumen de los resultados obtenidos en las pruebas ...................................................... 90 Tabla 12. Resultados del MOO2MVA-CP-01: Tabla Tipos de Variables .......................................... 127 Tabla 13. Resultado del MOO2MVA-CP-01: Tabla Funciones abstractas ....................................... 131 Tabla 14. Resultado del MOO2MVA-CP-01: Tabla Funciones concretas ........................................ 133 Tabla 15. Resultado del MOO2MVA-CP-01: Tabla Tipos de Clases................................................. 138 Tabla 16. Resultado del MOO2MVA-CP-02: Tabla Jerarquía de Clases .......................................... 139 Tabla 17. Tabla Variables MVA para el caso de prueba MOO2MVA-CP-05 .................................... 144 Tabla 18. Resultado del MOO2MVA-CP-06: Instancia 1, tabla Funciones Concretas MVA ............ 146 Tabla 19. Resultado del MOO2MVA-CP-06: Instancia 2, tabla Funciones Concretas MVA ............ 146 iii Lista de Figuras Pag. Figura 1. Arquitectura del patrón MVC ............................................................................................. 23 Figura 2. Arquitectura del patrón MVA ............................................................................................. 25 Figura 3. Fases de un Compilador ..................................................................................................... 31 Figura 4. Ejemplo de función especializada. ..................................................................................... 34 Figura 5. Ejemplo de función no-especializada ................................................................................. 35 Figura 6. Ejemplo de clase especializada .......................................................................................... 35 Figura 7. Ejemplo de clase no-especializada ..................................................................................... 36 Figura 8. Proceso de refactorización de MOO a arquitectura MVA.................................................. 41 Figura 9. Diagrama de Actividad del Método R1: “Analizar Código Legado” ................................... 44 Figura 10. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 2)................... 45 Figura 11. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 3)................... 46 Figura 12. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 4)................... 47 Figura 13. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 5)................... 48 Figura 14. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 6)................... 49 Figura 15. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 7)................... 50 Figura 16. Diagrama de Actividad del Método R7: “Estructura jerárquica de clases” ...................... 53 Figura 17. Diagrama de Actividad del Método R2: “Crear clases” .................................................... 55 Figura 18. Diagrama de Actividad del Método R3: “Crear constructor” ........................................... 57 Figura 19. Diagrama de Actividad del Método R3: “Crear constructor” (parte 2) ............................ 58 Figura 20. Diagrama de Actividad del Método R5: “Reubicar atributos” ......................................... 59 Figura 21. Diagrama de Actividad del Método R4: “Crear funciones” .............................................. 61 Figura 22. Diagrama de Actividad del Método R4: “Crear funciones” (parte 2) ............................... 62 Figura 23. Diagrama general de la herramienta MOO2MVA ............................................................ 64 Figura 24. Diagrama de clases del paquete InterfazGrafica ............................................................. 65 Figura 25. Diagrama de clases del paquete Adaptador .................................................................... 65 Figura 26. Diagrama de clases del paquete MOO2MVA ................................................................... 66 Figura 27. Diagrama de clases del paquete MOO2MVA.baseDatos ................................................. 67 Figura 28. Diagrama de clases del paquete MOO2MVA.A1.Analizar ............................................... 68 Figura 29. Proceso de obtención de la tabla de símbolos................................................................. 69 Figura 30. Proceso de etiquetación utilizando la tabla de símbolos ................................................. 71 Figura 31. Diagrama de clases del paquete MOO2MVA.A1.Analizar.TablaSímbolos ....................... 72 Figura 32. Diagrama de clases del paquete MOO2MVA.A2.Refactorizar ......................................... 74 Figura 33. Diagrama de clases del MOO Figuras Geométricas ......................................................... 78 Figura 34. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 1) .. 124 Figura 35. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 2) .. 125 Figura 36. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEquilatero.java. 125 Figura 37. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEscaleno.java ... 126 v Lista de Figuras Figura 38. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloIsoceles.java .... 126 Figura 39. Resultado del MOO2MVA-CP-03: Instancia 1 ................................................................ 141 Figura 40. Resultado del MOO2MVA-CP-03: Instancia 2 ................................................................ 141 Figura 41. Resultado del MOO2MVA-CP-03: Instancia 3 ................................................................ 141 Figura 42. Resultado del MOO2MVA-CP-03: Instancia 4 ................................................................ 141 Figura 43. Resultado del MOO2MVA-CP-03: Instancia 5 ................................................................ 142 Figura 44. Resultado del MOO2MVA-CP-03: Instancia 6 ................................................................ 142 Figura 45. Resultado del MOO2MVA-CP-03: Instancia 7 ................................................................ 142 Figura 46. Resultado del MOO2MVA-CP-03: Instancia 8 ................................................................ 142 Figura 47. Resultado del MOO2MVA-CP-03: Instancia 9 ................................................................ 142 Figura 48. Constructor en la clase cCubo ........................................................................................ 143 Figura 49. Resultado del MOO2MVA-CP-04: Instancia 1 ................................................................ 143 Figura 50. Resultado del MOO2MVA-CP-04: Instancia 2 ................................................................ 143 Figura 51. Resultado del MOO2MVA-CP-04: Instancia 3 ................................................................ 143 Figura 52. Clase cCuadradoC en donde se reubicarán atributos .................................................... 144 Figura 53. Resultado del MOO2MVA-CP-05: clase cCuadradoC ..................................................... 144 Figura 54. Clase cRectanguloM donde se copiará una función sin parámetros ............................. 145 Figura 55. Clase cRectanguloV donde se copiará una función con parámetros ............................. 146 Figura 56. Resultado del MOO2MVA-CP-06: Instancia 1 ................................................................ 146 Figura 57. Resultado del MOO2MVA-CP-06: Instancia 2 ................................................................ 146 vi Glosario de Términos Acoplamiento Nivel de dependencia entre las unidades de software de un sistema informático, es decir, el grado en que una unidad puede funcionar sin recurrir a otras. Se recomienda que exista bajo acoplamiento. ANTLR Siglas en inglés de ANother Tool for Language Recognition cuya traducción al español es Otra Herramienta para Reconocimiento de Lenguajes. Es una herramienta de software que opera sobre lenguajes, proporcionando un marco para construir reconocedores, intérpretes, compiladores y traductores de lenguajes a partir de las descripciones gramaticales de los mismos. ASP Siglas en inglés de Active Server Pages cuya traducción al español es Páginas Activas en el Servidor. Es una tecnología de Microsoft que se ejecuta de lado del servidor, se utiliza para páginas web generadas dinámicamente, que ha sido comercializada como un anexo a Internet Information Services (IIS). AST Siglas en inglés de Abstract Syntax Tree cuya traducción al español es Árbol de Sintaxis Abstracta. Es una representación del árbol de la estructura sintáctica abstracta de código fuente escrito en un lenguaje de programación. Capa Estructura lógica de los diferentes elementos que componen el software. COBOL Siglas en inglés de COmmon Business-Oriented Language cuya traducción al español es Lenguaje Común Orientado a Negocios. Es un lenguaje de programación creado con la intención de que fuera un lenguaje universal que pudiera ser usado en cualquier ordenador, y que estuviera orientado principalmente a los negocios. Código legado Se refiere a sistemas de software desarrollados o diseñados tiempo atrás del proyecto actual de diseño. Por lo general son sistemas que los clientes desean que sean reusados o actualizados Cohesividad Hace referencia a la forma en que agrupamos unidades de software en una unidad mayor. El consenso general para una buena programación o un buen diseño es que la cohesión debe ser alta. Componente Unidad de composición con interfaces especificadas en forma de contrato y con dependencias de contexto explícitas. Un componente puede ser desplegado o instalado independientemente y es sujeto a ser composición por terceras entidades. Composición Tipo de relación que se establece entre dos objetos que tienen comunicación persistente. Se utiliza para expresar que un par de objetos vii Glosario de Términos tienen una relación de dependencia para llevar a cabo su función, de modo que uno de los objetos involucrados está compuesto por el otro. Enfoque holístico Tendencia o corriente que analiza los eventos desde el punto de vista de las múltiples interacciones que los caracterizan IDE Siglas en inglés de Integrated Development Environment cuya traducción al español es Entorno de Desarrollo Integrado. Es un programa informático compuesto por un conjunto de herramientas de programación. Puede dedicarse en exclusiva a un solo lenguaje de programación o bien poder utilizarse para varios. IIS Siglas en inglés de Internet Information Services cuya traducción al español es Servicios de Información de Internet. Es un servidor web y un conjunto de servicios para el sistema operativo Microsoft Windows JavaBeans Son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones en Java. Se usan para encapsular varios objetos en un único objeto (la vaina o Bean en inglés), para hacer uso de un solo objeto en lugar de varios más simples. Java Servlets Son objetos que han sido programados en Java y se ejecutan dentro del contexto de un contenedor de servlets y extienden su funcionalidad. El uso más común de los servlets es generar páginas web de forma dinámica a partir de los parámetros de la petición que envíe el navegador web. JSP Siglas en inglés de JavaServer Pages cuya traducción al español es Páginas de Servidor de Java. Es una tecnología Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo. Lexer Analizador léxico o analizador lexicográfico, es la primera fase de un compilador consistente en un programa que recibe como entrada el código fuente de otro programa (secuencia de caracteres) y produce una salida compuesta de tokens (componentes léxicos) o símbolos. Microsoft SQL Server Sistema para la gestión de bases de datos producido por Microsoft basado en el modelo relacional. Sus lenguajes para consultas son T-SQL y ANSI SQL. Paradigma de programación Propuesta tecnológica que es adoptada por una comunidad de programadores cuyo núcleo central es incuestionable en cuanto a que unívocamente trata de resolver uno o varios problemas claramente delimitados. Un paradigma de programación está delimitado en el tiempo en cuanto a aceptación y uso ya que nuevos paradigmas aportan nuevas o mejores soluciones que la sustituyen parcial o totalmente. viii Glosario de Términos Parser Es una de las partes de un compilador que convierte el texto de entrada en otras estructuras (comúnmente árboles), que son más útiles para el posterior análisis y capturan la jerarquía implícita de la entrada. Patrón arquitectural Expresa un esquema de estructura de organización fundamental para el sistema software. Este provee un conjunto de subsistemas predefinidos, especifica responsabilidades e incluye reglas y guías para organizar las relaciones entre ellas. Patrón de diseño Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Plataforma de desarrollo Reuso Es el entorno de software común en el cual se desenvuelve la programación de un grupo definido de aplicaciones. El reuso de código, o también llamado reuso de software, se refiere al uso de software existente, o a la lógica de algún software, para construir nuevo software. SQL Siglas en inglés de Structured Query Language cuya traducción al español es Lenguaje de consulta estructurado. Es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en estas. XML Siglas en inglés de eXtensible Markup Language cuya traducción al español es Lenguaje de Marcado Extensible. es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos, permite definir lenguajes para diferentes necesidades, de ahí que se le denomine metalenguaje. VBScript Siglas en inglés de Visual Basic Script Edition cuya traducción al español es Visual Basic Edición para Script. Es un lenguaje interpretado por el Windows Scripting Host de Microsoft. Su sintaxis refleja su origen como variación del lenguaje de programación Visual Basic. ix Resumen Un Marco de Aplicación Orientado a Objetos es una colección semicompleta de clases que se ha transformado en una aplicación reusable, la cual puede ser utilizada para dar soluciones a un grupo de problemas relacionados. Una manera en la que se podrían aprovechar mejor estos marcos de aplicación, es colocándolos a disposición de una mayor cantidad de personas, utilizando Internet para compartirlos como servicios Web. Lo anterior provoca la necesidad de transformar los MOO a servicios Web, pero antes de realizar esta transformación es necesario adaptar la arquitectura del código según el patrón Modelo-Vista-Controlador (MVC por sus siglas), ya que se debe separar la parte de la Vista y el Control de la parte del Modelo, la cual contiene la lógica del negocio. La complejidad que se presenta al refactorizar los MOO bajo una arquitectura MVC, radica en que las diferentes capas (Modelo, Vista y Controlador) pueden estar estrechamente acopladas dentro de las diferentes aplicaciones, lo que provoca que se dificulte su separación. El presente trabajo describe un primer acercamiento para el desarrollo de una herramienta llamada MOO2MVA, la cual tiene como objetivo automatizar la refactorización de MOO hacia una arquitectura según el patrón MVC. En este primer acercamiento se implementaron seis de los once métodos que conforman el proceso de refactorización. Dicho proceso utiliza como base los métodos propuestos en “Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador”, tesis de maestría realizada en el laboratorio de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). Aunque se sabe que existen trabajos relacionados con el tema de la refactorización hacia el patrón MVC, también se sabe que no todos están orientados hacia la total refactorización del código; ni se enfocan en mantener la separación total de las capas de la Vista y el Modelo. Entre las herramientas que se conocen están: M&S SW, PerCobol, UWAT+, HEDGEHOG, entre otros. La diferencia entre las herramientas anteriores y el presente trabajo es que MOO2MVA es una herramienta que apuesta por la total separación de la lógica del negocio (Modelo) y de la presentación de los datos (Vista), así como un análisis profundo del código original que permita la preservación de la lógica de negocio. Los métodos implementados actualmente en la herramienta MOO2MVA fueron probados con un MOO que consistía en 44 clases cuyo dominio estaba basado en el área de la geometría. De las pruebas realizadas a estos métodos, se obtuvo el cien por ciento de resultados positivos. Con base en los resultados obtenidos de las pruebas, se concluyó que la refactorización automática hacia el patrón MVC, realizada por una herramienta, es posible. También se propone como trabajo futuro la implementación de los cinco métodos restantes. xi Abstract A Framework for Object-Oriented Application is a semi-complete collection of classes that have been transformed into a reusable application, which can be used to provide solutions to a group of related problems. One way in which these application frameworks could be better used, is by placing them at the disposal of a greater number of people by using the Internet to share them as Web services. This causes the need to transform the MOOs into Web services, but before achieving this, it is necessary to adapt the architecture of code according to the Model-View-Controller architectural pattern (MVC for short), since the View and Control layer must be separated from the Model layer, which contains the business logic. The complexity presented when refactoring the MOOs into a MVC architecture, is that the different layers (Model, View and Controller) can be tightly coupled in different applications, leading to a difficult separation. This paper describes a first approach for developing a tool called MOO2MVA, which aims to automate refactoring MOO towards an architecture according to the MVC pattern. In this first approach, were implemented six of the eleven methods that make the process of refactoring. This process uses the proposed methods based on "Heuristic Methods for restructuring application frameworks towards the object-oriented Model-View-Controller design pattern", a Master degree thesis conducted at the Software Engineering Laboratory of the National Center for Research and Development of Technology (CENIDET). Although it is known that there are papers related to the topic of refactoring towards the MVC pattern, it is also known that not all are aimed towards complete refactoring of the code, nor focus on maintaining the complete separation of the View and Model layers. Among the tools that are known are: M&S SW, PerCobol, UWAT + HEDGEHOG, among others. The difference between the previous tools and the present work is that MOO2MVA is a tool that is committed to total separation of business logic (Model) and data presentation (View), and a thorough analysis of the original code that allows the preservation of the business logic. The first stage in the development of the MOO2MVA tool was tested with a framework for object-oriented applications consisting of 44 classes whose domain was based on the field of geometry. From the tested implemented methods, we obtained one hundred percent positive results. Based on the results of the tests it was concluded that the automatic refactoring towards the MVC pattern by a tool is possible. Also, the implementation of the five remaining methods was also proposed as future work. xiii Introducción Capítulo 1. Introducción En este capítulo se presenta una introducción al tema de tesis, la descripción del problema, objetivo, alcances, limitaciones, justificación, beneficios y la organización general de este documento. 1.1 Introducción Un Marco de Aplicación Orientado a Objetos (MOO por sus siglas) es una colección semicompleta de clases que se ha transformado en una aplicación reusable, la cual puede ser utilizada para dar soluciones a un grupo de problemas relacionados, de esta manera dicho MOO puede ser utilizado para generar nuevas aplicaciones hechas a la medida [FAYA,97]. Sin embargo, los MOO, generalmente son explotados de manera centralizada y propietaria dentro de cada una de las empresas que los posee. Una manera en la que se podrían aprovechar mejor estos marcos de aplicación, es poniéndolos a disposición de una mayor cantidad de personas utilizando Internet para compartirlos como servicios Web, estos servicios tendrían la misma funcionalidad que los MOO pero podrían ser explotados por una mayor cantidad de personas. 1 Capítulo 1 Lo anterior provoca una nueva necesidad, que es la de transformar los MOO a servicios Web. Una solución a esta nueva necesidad es la refactorización de los MOO para obtener servicios Web, pero antes es necesario adecuar la arquitectura del código según el patrón MVC ya que se debe separar la parte de la Vista y el Control de la parte del Modelo, la cual contiene la lógica del negocio. Es decir, para poder realizar la refactorización de un MOO hacia servicios Web es necesario hacer una transformación intermedia, en la cual se reestructura la arquitectura del MOO y sus componentes se hacen menos dependientes entre sí, para esto se utiliza el patrón arquitectural MVC el cual separará el código de las aplicaciones en tres capas (Modelo, Vista y Controlador) generando así la estructura adecuada para eliminar las capas de la Vista y el Control y transformar la capa del Modelo a servicios Web. En el laboratorio de Ingeniería de Software del CENIDET, se han realizado varios trabajos relacionados a la refactorización de código legado, y el principal antecedente para la refactorización de MOO hacia el patrón MVC, es la tesis de maestría titulada “Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño ModeloVista-Controlador” [NUÑE,08]. Con la implementación de los métodos propuestos en dicha tesis se da continuidad a esta línea de investigación. Por lo que en este trabajo de tesis se propuso la generación de una herramienta que ayude a realizar esta refactorización de los MOO hacia una arquitectura MVC, utilizando los métodos propuestos en [NUÑE,08]. Para que así, después de realizar la refactorización se pueda tomar la parte correspondiente al Modelo y transformarlo a servicios Web. 1.2 Descripción del problema Los MOO representan una buena opción para el reuso tanto del diseño como de código de manera centralizada y propietaria, pero si se quiere poner a disposición de un mayor número de usuarios a través de Internet para el desarrollo de nuevas aplicaciones, es casi imposible lograrlo debido a que los MOO no están escritos en un lenguaje estandarizado para ser utilizados por diferentes plataformas de desarrollo. Una de las estrategias para reusar los MOO a través de Internet, es transformarlos a servicios Web, los cuales proporcionan mecanismos de comunicación estándar entre diferentes aplicaciones. El problema radica en que no se pueden transformar los MOO a servicios Web directamente sin antes separar las clases y funciones que son altamente interactivas con el usuario (capa de la Vista) y la parte que controlan la lógica de la aplicación (capa del Controlador); de la parte que contiene la lógica del negocio (capa del Modelo); y muchas veces en la arquitectura de los MOO estas tres capas se encuentran mezcladas, por lo que primero se debe realizar la transformación a una arquitectura que permite separar estas tres capas, es decir, a la arquitectura del patrón MVC. 2 Introducción La complejidad que se presenta al refactorizar los MOO bajo una arquitectura MVC, radica en que estas capas (Modelo, Vista y Controlador) pueden estar estrechamente acopladas dentro de las diferentes aplicaciones, lo que provoca que se dificulte su separación. 1.3 Objetivo Dividir la arquitectura original de los MOO hacia una arquitectura MVC con el propósito de favorecer su reúso como servicios Web, mediante el desarrollo de una herramienta que implemente los métodos desarrollados en “Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador” [NUÑE,08]. 1.4 Justificación El desarrollo de una herramienta que separe la arquitectura de los MOO en las diferentes capas que conforman el patrón MVC, es de utilidad para satisfacer la necesidad de refactorizar los MOO para obtener servicios Web. La necesidad de llevar los MOO hacia servicios Web existe debido a que, aunque existen procesos y herramientas para refactorizar o transformar código legado, ya sea al patrón arquitectural MVC o a la Web, relativamente poco esfuerzo se ha invertido en trabajos de investigación enfocados en buscar formas para extender el aprovechamiento y reuso de MOO en mayor escala. De acuerdo a [BOSC,97] existe una gran cantidad de investigación y desarrollo de software tanto en compañías como en universidades e incluso a nivel gubernamental, lo que ha provocado la creación de un gran número de MOO. Por otro lado, actualmente es común colocar en Internet, a disposición de otros desarrolladores, componentes de software como recursos de la Web, los cuales proporcionan las mismas ventajas que los MOO, pero ahora lo hacen en internet y de manera independiente a la plataforma de desarrollo, y además pueden ser accedidos por una mayor cantidad de clientes. Lo que provoca la necesidad de transformar MOO a servicios Web, ya que el tiempo y conocimiento invertido en el desarrollo de los MOO no debería ser desperdiciado, sino adaptado a las nuevas tecnologías. 1.5 Beneficios El desarrollo de una herramienta que ayuda a realizar la refactorización de MOO hacia una arquitectura MVC favorece la productividad de los desarrolladores de software, pues al separar la lógica de negocios de la presentación al usuario, se simplifican las tareas de mantenimiento y reuso, lo que aumentaría la productividad de los desarrolladores y se obtendrían aplicaciones de 3 Capítulo 1 mayor calidad y confiabilidad, ya que dichos componentes provendrían de aplicaciones maduras, probadas y confiables. Además, una vez realizada la separación del MOO en las diferentes capas que conforman el patrón MVC, la parte del Modelo puede ser aprovechada como servicios Web posibilitando el aprovechamiento de toda la experiencia implícita en estos MOO, por ejemplo, en las aplicaciones de negocios, de ingeniería, en la educación, el comercio electrónico, etc. 1.6 Alcances y Limitaciones 1.6.1 Alcances A continuación se presentan los alcances bajo los cuales se llevó a cabo la presente investigación: Probar y refinar los métodos propuestos en la tesis de maestría titulada “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” [NUÑE,08]. Diseño de un proceso de refactorización utilizando los métodos propuestos en [NUÑE,08] una vez que estos han sido refinados. La cantidad de métodos implementados está limitado por el tiempo y las dificultades encontradas durante el desarrollo de la investigación. 1.6.2 Limitaciones Las limitaciones bajo los cuales se llevó a cabo el desarrollo de la investigación son las siguientes: 4 Se implementaron seis de los once métodos necesarios para realizar la refactorización, por lo que el proceso de refactorización no se realiza completamente. El proceso de refactorización no fue diseñado para refactorizar MOO cuyo dominio sean las interfaces de usuario. La herramienta funciona para MOO escritos en Java. La herramienta funciona para MOO que contengan código libre de defectos de compilación y ejecución. Las interacciones del usuario consideradas son: entrada y salida de datos a través la línea de comandos, es decir, con elementos de la librería java.io. No se realizan transformaciones hacia servicios Web. Introducción 1.7 Organización de esta tesis La estructura restante de este documento se compone de seis capítulos más, los cuales se describen a continuación. Capítulo 2 En este capítulo se presentan los trabajos relacionados a esta investigación que fueron desarrollados anteriormente en el CENIDET, el estado del arte y el análisis comparativo de algunas investigaciones y herramientas de refactorización. Capítulo 3 En este capítulo se presentan algunos conceptos teóricos relevantes y tecnologías estudiadas para realizar la refactorización de los Marcos Orientados a Objetos hacia una arquitectura MVC. Capítulo 4 En este capítulo se describe el modelo conceptual en el que se basa el desarrollo de la herramienta. Se describe el proceso de refactorización, las actividades y los métodos que lo conforman. Capítulo 5 En este capítulo se describe la implementación de los métodos de refactorización en la herramienta. Se presentan los diagramas de clases y paquetes utilizados, los criterios de etiquetación de código de acuerdo a la parte del patrón MVC a la que pertenecen y las tecnologías utilizadas para el desarrollo de la herramienta. Capítulo 6 En este capítulo se presentan el plan de pruebas para los métodos implementados en la herramienta, la descripción del plan de pruebas y la especificación del diseño de pruebas. Capítulo 7 En este capítulo se detallan las conclusiones alcanzadas, las aportaciones obtenidas con esta investigación y los que se podrían considerar trabajos futuros. Finalmente se presentan las referencias bibliográficas y dos anexos, el primero contiene los métodos de refactorización y el segundo los resultados de las pruebas realizadas. 5 Antecedentes Capítulo 2. Antecedentes En este capítulo se presentan los trabajos relacionados a esta investigación que fueron desarrollados anteriormente en el CENIDET, el estado del arte y el análisis comparativo de algunas investigaciones y herramientas de refactorización. 2.1 Antecedentes En el laboratorio de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET), se han realizado varios trabajos relacionados a la refactorización de código legado, pero el principal antecedente para la refactorización de Marcos de Aplicación Orientados a Objetos hacia el patrón MVC, es la tesis de maestría titulada “Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-VistaControlador” [NUÑE,08]. A continuación se hace una breve descripción de las diferentes investigaciones. 7 Capítulo 2 2.1.1 Factorización de Funciones hacia Métodos de Plantilla [HERN,03] El objetivo de este trabajo fue desarrollar una herramienta de software que realiza automáticamente la refactorización de código legado escrito en el lenguaje C bajo el paradigma de programación por procedimientos y obtiene como resultado arquitecturas de clases reusables orientadas a objetos escritos en el lenguaje C++. El proceso de refactorización parte de un conjunto de tablas, generadas al analizar el código fuente, las cuales contienen la información importante para la refactorización (variables locales, globales, nombres de funciones, etc.). Para el proceso de refactorización se incorporan siete métodos que en conjunto cumplen con la función de generar marcos de componentes reusables orientados a objetos. Los métodos de la refactorización son: Método de creación de clases: Se construyen plantillas o clases que con la integración de otros métodos se van convirtiendo en clases de objetos. Método de declaración de constructores: Consiste en declarar dentro de cada clase de objetos dos constructores, el primero contiene la inicialización de la estructura de datos de las instancias de la clase y el segundo recibe un parámetro por cada variable de la clase. Método de composición de clases: Se definen los elementos de composición que puedan ser empleados por una clase y los cuales definen la forma en que la clase se familiariza con otra. Método de reubicación de funciones: Reubica las funciones en su correspondiente clase de objetos con sus respectivos parámetros y tipo de la función. Método de fragmentación de funciones: Fragmenta una misma función que es redundante en varias clases de objetos, para evitar la duplicidad de código. Método de superjerarquizar: Se declaran clases abstractas para evitar la duplicidad de funciones, en este método se identifican clases candidatas a superjerarquizar pero se necesita la intervención de un experto el dominio para determinar cómo actuar en estos casos. Método de fábrica de objetos: Consiste en definir una interfaz para crear objetos dejando a las subclases la decisión de cual clase instanciar, éste método es influenciado por el patrón de diseño “Abstract Factory”. 2.1.2 Reestructuración de Código Legado a partir del Comportamiento para la Generación de Componentes Reutilizables [BUST,03] El objetivo de este trabajo fue el desarrollo de una herramienta que permite restructurar de forma automatizada y en base a patrones de diseño, la arquitectura de los fragmentos de código legado escritos en lenguaje C, que presenten las características de tener estatutos condicionales con más de tres alternativas o que puedan presentar varios niveles de anidamiento, debido al alto grado de 8 Antecedentes complejidad que exhiben; lo anterior tiene el objetivo de hacer una descomposición de segmentos genéricos de código reutilizable, para que puedan ser probados e incorporados en marcos de componentes reutilizables orientados a objetos para su reutilización. Para la restructuración, se toma como entrada código fuente basado en procedimientos escrito en lenguaje C, al cual se le aplica un proceso de análisis y extracción de información, la cual se almacena en un conjunto de tablas. Estas tablas son la fuente de información que se utilizará para llevar a cabo el proceso de restructura y la generación de clases que presentará la estructura de los patrones de diseño “State” y “Strategy”. Para de esta manera automatizar el proceso de refactorización de software legado, de una organización basada en procedimientos hacia una arquitectura de clases en colaboración o marco de trabajo de componentes reusables. 2.1.3 Reestructuración de Software Escrito por Procedimientos Conducido por Patrones de Diseño Composicionales [MEND,04] Este trabajo tuvo como objetivo la restructuración de código escrito en C, el cual exhibe muchas líneas de código, un bajo nivel de cohesividad, altos costos de mantenimiento, alto nivel de dependencia, alto nivel de complejidad, ausencia de mecanismos de herencia, composición y delegación; y carencia de interfaces. La restructuración se hace hacia marcos de aplicaciones orientados a objetos que incorporen la arquitectura de patrones de diseño que permiten la composición de objetos, con el fin de obtener segmentos genéricos de código reusables, que pueden ser ejercitados e incorporados en depósitos de componentes para su reúso en aplicaciones posteriores, mejorando los aspectos mencionados, además de repercutir en la mejor calidad del sistema y en la simplificación de las tareas de mantenimiento y reúso. 2.1.4 Métodos Heurísticos para Reestructurar Marcos de Aplicaciones Orientados a Objetos hacia el Patrón de Diseño Modelo-Vista-Controlador [NUÑE,08] El objetivo de esta investigación fue identificar los posibles escenarios que se pueden 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 identificados desarrollar un conjunto de métodos heurísticos para la restructura de los Marcos de Aplicación Orientados a Objetos conforme al patrón MVC. En esta investigación se generó conocimiento sobre los principales escenarios que se presentan cuando se requieren restructurar sistemas legados. Se muestra la cantidad de escenarios que pueden suceder cuando se lleva a cabo la restructura de código legado, la complejidad y factibilidad de este tipo de trabajos. 9 Capítulo 2 Además, los escenarios identificados documentan la manera en que se puede llegar a presentar el código de los Marcos de Aplicación Orientados a Objetos legados y una solución para llevar a cabo la restructura utilizando los métodos heurísticos. Fueron 8 los métodos generados en esta investigación, los cuales establecen los pasos para manipular los componentes presentes en los sistemas legados; dichos métodos se describen a continuación: Definir plantilla genérica MVC: Utilizando el patrón de diseño “Command” genera una arquitectura de clases conforme al patrón MVC. Análisis del Código Legado: Identifica con qué parte del patrón MVC se relaciona cada uno de los estatutos de código incluido en las clases. Crear Clases: Define la declaración de clases simples, abstractas e interfaces, colabora con los métodos de “Cohesionar clases”, “Super-Jerarquizar” y “Sub-Jeraquizar”. Crear Constructor: Define dos tipos de constructores con parámetros y sin ellos. Incluye la inicialización de las estructuras de datos de las instancias de las clases. Crear función: Crea funciones especializadas con parámetros y sin parámetros, al crearse se especializan y están listas para reubicarse en las clases correspondientes. Reubicar Atributos: Reubica los atributos y su inicialización desde las clases legadas a las clases concretas correspondientes de la plantilla MVC. Fragmentar funciones: Fragmenta las funciones no especializadas y utiliza el método de Crear Funciones para generar funciones especializadas las cuales serán reubicadas en la plantilla MVC. Redefinir llamadas a funciones: Sustituye la actual llamada a una función que después de ser fragmentada queda ubicada en alguna de las clases de la plantilla MVC. 2.2 Estado del arte Aunque existen varios procesos y herramientas para refactorizar o transformar código legado, ya sea al patrón arquitectural MVC o a la Web, durante esta investigación no se encontraron herramientas que tengan como entrada código Java y su salida sea código Java refactorizado hacia una arquitectura MVC. A continuación se presentan algunas de estas investigaciones y herramientas. 2.2.1 Tranforming Legacy Web Applications to the MVC Architecture (Transformando Aplicaciones Web Legadas hacia la Arquitectura MVC) [PING,04] Este artículo relacionado presenta un marco de reingeniería cuyo objetivo es crear un sistema con arquitectura basada en el patrón MVC y que sea compatible con la plataforma Java. Este marco está enfocado principalmente en la fragmentación de aplicaciones web legadas mediante la identificación de los componentes de software que serán transformados en objetos java. 10 Antecedentes Se desarrollaron herramientas programadas en Java que son capaces de restructurar la arquitectura de sitios Web basados en JSP a una arquitectura enfocada en el controlador, todo esto mediante la extracción de la información obtenido del análisis de la aplicación JSP. Los autores dicen que como se obtiene información de un sistema web, las mismas páginas pueden ser reutilizadas. También afirman que el proceso de migración de un sistema, además de traducir de un lenguaje origen a otro, también debería de mejorar la calidad de las características del sistema migrado. Las herramientas presentadas en este trabajo relacionado adoptan la arquitectura MVC en el ambiente Enterprise de Java, y como resultado de esto la aplicación fuente es restructurada en JavaBeans (Modelo), Java Server Pages (Vista) y Java Servlets (Control). Para la parte del modelo, se utilizaron tres tipos de JavaBeans: Bean de consulta: Se encarga de ejecutar las consultas SQL extraídas desde el programa fuente. Bean de acceso de datos: Este es un objeto java serializable, el cual consiste casi exclusivamente de métodos “setters” y “getters”. Lleva un conjunto de información desde los Bean de consulta a los Bean de datos. Bean de datos: Es un contenedor de objetos que encapsula la invocación de un Bean de consultas en una página JSP. Lleva a cabo cierto conjunto de acciones, tales como establecer los parámetros del Bean de consulta y llenar de información al Bean de acceso de datos. Los autores utilizan el mismo término y significado de “contenedores” que se utilizó en el artículo pasado, y afirman que utilizándolos para JavaBeans, se reduce significativamente la cantidad de código Java utilizado en las páginas JSP, debido a que la implementación en Java del acceso a datos está encapsulada dentro de Beans de datos. En el enfoque mostrado en este artículo, se construyó un componente controlador central sobre el sistema Web para llevar a cabo la administración de las peticiones de procesamiento del cliente y los resultados de las páginas Web. En otras palabras, ninguna página Web está enlazada directamente a ninguna otra. En vez de eso, las páginas se conectan a un controlador asociado, el cual renvía la petición de una página origen a la página destino. La metodología que siguieron se divide en tres pasos: Separar el acceso de base de datos de la presentación lógica, mediante la extracción de sentencias SQL del programa legado. Hacer la transición a páginas JSP al separar los elementos desplegables del programa legado, que necesiten ser remplazados por páginas JSP, con una cierta combinación JavaBeans generados de la primera etapa. Adoptar una arquitectura centrada en el controlador. En esta etapa se adapta la arquitectura original al patrón MVC mediante el análisis del flujo de control (que puede ser extraído de las primeras dos etapas), el cual es representado por una colección de archivos HTML, páginas JSP generadas y objetos JavaBeans. 11 Capítulo 2 Para llevar a cabo estas tres etapas, se utilizaron cinco procesos que contienen actividades basados en la restructuración de código. Los procesos son: Sistema fuente: Representa a la aplicación de software que será restructurada. Análisis de software: Aquí se trabaja con un analizador de lenguaje que lee el código fuente y reconoce la estructura del programa de acuerdo a la gramática del lenguaje original. Aquí se utiliza un Lexer y un Parser y se obtiene un AST (Árbol Abstracto de Sintaxis). Extracción de información: Aquí se extrae la información generada en el AST y se transforma a objetos reconocibles por Java. Generación de código nuevo: Este proceso apoya a la generación automática de nuevas aplicaciones. Sistema Destino: Etapa final del proceso de restructuración. Esta etapa representa la plataforma recién creada basada en el proceso de restructura. 2.2.2 Migrating Legacy Systems to the Web: An Experience Report (Migrando Sistemas Legados a la Web: Un Reporte de las Experiencias) [AVER,01] En este trabajo relacionado se presenta un proyecto de migración cuya intención es integrar un sistema existente escrito en COBOL a una infraestructura Web. El sistema original ha sido dividido en componentes de interfaz de usuario (páginas ASP) y servidor (lógica de la aplicación y el acceso a base de datos). Los autores aseveran que “Normalmente los componentes del sistema que son parte de la interfaz de usuario son restructurados en forma de página Web, y utilizan al navegador Web como un contenedor y los componentes que implementan las funciones de negocio pueden ser contenidos o remplazados por componentes estándar o nuevos”. En este artículo se menciona que la interfaz de usuario (Vista) fue restructurada con tecnología ASP (Páginas Activas en el Servidor) y VBScript, mientras que la parte de la lógica (Modelo) fue implementada utilizando Microfocus Object COBOL. Los autores utilizaron una solución de corto plazo que consiste en agregar una estructura contenedora al código legado, para permitir la comunicación de éste con código nuevo mediante mensajes, en lugar de la restructura de código total. Pero los autores reconocen que una solución a largo plazo podría ser la restructura del código legado hacia la orientación a objetos en la parte del servidor, y migrar incrementalmente los objetos obtenidos de dicha restructura, hacia una arquitectura de componentes distribuida. Los autores indican que basados en trabajos anteriores se considera que los sistemas de software pueden tener tres tipos de componentes: componentes de interfaz, componentes de la lógica de aplicación y componentes de base de datos. Basados en esta clasificación, los autores de [AVER, 2001] agruparon a los componentes de interfaz como parte del cliente, mientras los últimos dos en la parte del servidor. También hablan que dependiendo de qué tan separados y 12 Antecedentes definidos estén estos componentes mencionados, se puede clasificar a los sistemas en Desfragmentable, semi-desfragmentable e indesfragmentable. Los pasos de restructuración y desfragmentación requieren de un análisis estático para la extracción de información relevante desde el código fuente para guardarlos en un repositorio. Como resultado de esta actividad, los programas legados son restructurados en un estilo clienteservidor. La manera en la que los autores capturaron la estructura del programa legado fue mediante Grafos de Llamadas, los cuales capturan la interacción que se tiene entre las páginas o módulos del sistema legado. Para capturar estos grafos de llamadas, se utilizó una herramienta comercial. Después de haber capturado al grafo, se utilizó una herramienta desarrollada por ellos que transformó este grafo en árbol de jerarquía. Para confirmar que capturaron bien el sistema, se entrevistaron con el equipo de programadores del sistema original. Los autores mencionan que uno de sus objetivos fue encontrar el balance entre el esfuerzo necesario entre restructurar o volver a desarrollar programas legados, y el esfuerzo requerido para envolverlos. Debido a esto, mencionan que los programas que mantienen la comunicación con la nueva interfaz gráfica fueron restructurados y envueltos, mientras que las interacciones con los programas que mantienen comunicaciones con la base de datos, aún son implementados a través de archivos en COBOL sin restructurar. Los archivos COBOL tienen forma de librerías dinámicas escritas en Microfocus Object COBOL, son cargadas en el servidor Web IIS (Internet Information Services) de Microsoft y la interfaz de usuario accede a ellas mediante las funciones VBScript embebidas en las páginas ASP. Los autores concluyen el artículo diciendo que están en vías de un nuevo proyecto que se dedicará a restructurar la parte del servidor hacia una arquitectura orientada a objetos. 2.2.3 Towards a Holistic Approach to Redisigning Legacy Applications for the Web with UWAT+ (Hacia un Enfoque Holístico para el Rediseño de Aplicaciones Legadas para la Web con UWAT+) [DIST,06] En este artículo se propone un enfoque holístico utilizando UWA (Marco Ubicuo de Diseño de Aplicaciones Web) y UWAT+(la versión extendida de UWA) que combina tecnologías de recuperación de diseño para capturar las reglas del dominio embebidas dentro de las aplicaciones legadas, y métodos de diseño específicos para aplicaciones Web. El artículo explica que los marcos de diseño UWA y UWAT+ ofrecen al diseñador un conjunto de metodologías, meta modelos, y herramientas para el diseño centrado en el usuario de aplicaciones ubicuas de datos y sensible a operaciones. También explican la manera en la que se conforma el marco UWA y UWAT+. Los procesos por los que se conforman UWAT+ son: Elicitación de requisitos: Está orientada a la formalización de las metas del proceso de rediseño y a los requisitos para la versión Web del código legado. En este proceso se 13 Capítulo 2 trabaja en conjunto con los usuarios del sistema para ponerse de acuerdo con los diseñadores en qué opciones del sistema legado se mantendrán. Ingeniería inversa: Está orientado la extracción y formalización de la información desde el código legado. Como resultado se obtiene un boceto de la nueva aplicación. Aquí también se identifica a los componentes que pueden o tienen que ser reutilizados en la nueva versión del software. De esta etapa se extraen productos tales como documentación, tipos de usuario de la aplicación, modelos de proceso etc. Pero los productos más importantes son la obtención de la lógica del negocio y sus componentes. Diseño directo: Aquí se utilizan los requisitos definidos en la primera etapa y se utilizan para refinar el boceto obtenido de la segunda etapa, produciendo así el diseño final de la nueva versión Web de la aplicación. El enfoque presentado en este trabajo relacionado se probó en una aplicación llamada GPA, la cual estaba programada en Visual Basic 5 y utilizaba la base de datos Microsoft SQL, la cual fue restructurada con éxito. 2.2.4 Re-Approaching the Refactoring Rubicon (Re-Abordando el Rubicon de la Refactorización) [ABAD,08] En este artículo relacionado, los autores llevaron a cabo un caso de estudio en el que convirtieron un Java Servlet hacia el patrón Modelo-Vista-Controlador utilizando la mayor cantidad soporte automatizado posible. Basado en los descubrimientos de este trabajo relacionado, los autores definieron los requisitos para un marco de restructurar, el cual hará posible la fragmentación de una transformación compleja mediante pasos de restructura bien definidos. Los autores exponen que los métodos de restructura modernos soportados por las IDEs, no son capaces de restructurar el Método de Extracción de Fowler. Las transformaciones que se utilizaron en este trabajo relacionado fueron expresadas como una serie de 36 pasos de restructura, los cuales consistían en 14 tipos de restructuraciones. Se menciona que todos ellos, menos cuatro, se encuentran documentados en el catálogo de Fowler. El Método de Extracción se encuentra dentro del catálogo de Restructuras de Martin Fowler. Basados en una serie de pruebas, los autores concluyen que los ambientes de desarrollo modernos no tienen mucha capacidad de restructuración de código, y que muchas de esas capacidades de restructura de alto nivel, requieren de métodos más pequeños de restructuración. Además de que en ciertos casos existe más de una forma de implementar la misma restructuración. Se menciona que el Método de Extracción debería de dar a elegir al usuario entre varias formas de restructuración. También se menciona que las implementaciones actuales contienen precondiciones demasiado fuertes para la restructuración, y todo debido al análisis insuficiente acerca de la restructuración. Según dicen los autores, un marco de restructuración que sea capaz de invocar varios métodos pequeños para llevar a cabo una restructuración mayor, sería de gran ayuda para los 14 Antecedentes desarrolladores y les facilitaría el trabajo. Y para que un marco de restructura sea realmente efectivo es necesario que posea capacidades profundas de análisis. 2.2.5 Migrating COBOL Systems to the Web by Using the MVC Design Pattern (Migrando Sistemas COBOL a la Web Utilizando el Patrón de Diseño MVC) [BODH,02] Este trabajo relacionado presenta una estrategia de migración cuyo objetivo es un sistema con arquitectura web basado en el patrón MVC, además de un conjunto de herramientas con propósitos definidos dentro de la estrategia. Al extraer toda la información necesaria desde el código fuente en COBOL, las herramientas presentadas en este artículo pueden generar contenedores para la lógica de negocio y el modelo de datos, y generar una interfaz de usuario web en forma de JSP (Java Server Pages). Los autores del artículo afirman que “A menudo, el código legado es la única fuente del conocimiento del dominio así como también es la única descripción real de las reglas del dominio actual”. Por lo tanto, mantienen la reestructura de código legado al mínimo, mientras toman el enfoque de los contenedores de código. Los autores definen a los contenedores de código como clases de código nuevo que “envuelve” al código legado, sin traducir de un lenguaje a otro, o sin tener que cambiar la estructura del código original. Siguiendo la definición de “contenedor”, también afirman que éstos representan una interfaz que le da acceso a las nuevas aplicaciones por parte los componentes de código legado mediante el intercambio de mensajes. Las llamadas recibidas por el contenedor, son convertidas en llamadas a los componentes del sistema que realizan el servicio requerido. Para comunicar al objeto contenedor con el código COBOL, se utilizó PERCobol, el cual es un compilador comercial desarrollado por la empresa LegacyJ, que es capaz de compilar más de 15 dialectos de Cobol, puede traducir código COBOL a Java y puede encontrarse en su sitio web www.legacyj.com. De esta manera, al mantener la parte del dominio en el modelo, se enfocan en restructurar la parte de la vista para convertirlo en páginas Web JSP. La metodología propuesta por los autores se llama M&S SW (Métodos y Herramientas para la Producción de Software, Formación y Aplicaciones). Está compuesta por 8 etapas en las cuales se utilizan siete herramientas programadas en Java para las diferentes etapas. Las herramientas son: Analizador: Ejecuta un análisis estático del código legado y utiliza ANTLR para realizar el análisis. Controlador: Produce reportes gráficos y textuales al procesar la información almacenada en el repositorio. Genera los servlets pertenecientes a la capa del controlador. Cortadora: Descompone los programas al aplicar algoritmos de cortes basados en el análisis de control de dependencias. 15 Capítulo 2 Extractor: Identifica los objetos asociados con el almacenamiento de datos dentro del código legado. Cada objeto corresponde a un almacén de datos que contiene atributos que son asociados a la estructura de datos. Reingeniería: Crea la división de datos en el nuevo programa COBOL que contenga los métodos extraídos del código original. Re-Implementador: Genera una nueva interfaz de usuario para los componentes del sistema mediante JSP. Generador de contenedor: Genera un objeto en Java para envolver y acceder al código legado restructurado. Repositorio: Sirve para guardar la información que se obtiene de cada etapa. No es una herramienta, pero interactúa con todas las anteriores. La información que se almacena aquí está en formato XML. Mediante el patrón MVC se puede mantener la lógica del programa en la parte del modelo, y la interfaz de usuario en la vista. Las correspondencia entre la interfaz HTML y los componentes son determinados mediante el análisis estático. 2.2.6 Análisis comparativo La Tabla 1 muestra un resumen de las características encontradas entre los trabajos relacionados y el trabajo de esta tesis. 16 Antecedentes Tabla 1. Comparación de trabajos relacionados. Proyecto/Atribut o Tipo de proyecto Arquitectura resultante Entradas [PING,04] Marco reingeniería [AVER,01] Metodología Cliente-Servidor (Vista-Modelo) [DIST,06] Metodología Cliente servidor Visual Basic 5 (Vista-Modelo) Código Visual No, es manual. Basic y HTML [ABAD,08] Caso de estudio MVC Java Servlets Código Java No, es Soporte de la semiautomática, pues IDE Eclipse utilizaron el soporte de reestructuración de la IDE Eclipse [BODH,02] Estrategia herramientas Código COBOL JSP, XML Sí, el usuario interviene directamente. Tesis (MOO2MVA) Herramienta de MVC centrado en Páginas JSP el controlador y MVC Salidas Es Automática JavaBeans, JSP y Sí, el usuario Java Servlets interviene directamente. Lenguaje no Java Código COBOL, ASP, VBScript y No, es manual. Se Metodología Grafos de llamada Librerías sigue la metodología MORPH Dinámicas de ASP MORPH para la separación de código. MVA (Variante de Código Java MVC) Metodología UWAT+ no Java Código Java Sí, el usuario elige el Java refactorizado proyecto a refactorizar y el sistema lo hace automáticamente. 17 Capítulo 2 Como se puede observar en la Tabla 1 los proyectos no utilizan el mismo tipo de metodología o herramienta, y algunos manejan una arquitectura diferente al proyecto de esta tesis. Algunos proyectos usan sólo metodologías mientras que otros ya han adaptado dichas metodologías y han creado herramientas que automatizan el trabajo. A diferencia de las metodologías manuales, la herramienta presentada en este trabajo sería automática, lo que evita que el usuario pueda cometer algún tipo de error. Los proyectos que manejan la refactorización de código, se pueden dividir en dos filosofías: Los que envuelven el código legado con un contenedor que sirve de adaptador, y los que refactorizan totalmente el código legado. Al ser una herramienta que refactoriza todo el código de entrada, se podría decir que el proyecto de esta tesis presenta una solución a largo plazo, en lugar de corto plazo como indican los proyectos con filosofías de contenedores de código legado. La mayoría de los proyectos utilizan la arquitectura MVC o algún derivado de ella, mientras que los restantes son considerados por sus autores como una arquitectura de dos niveles (ClienteServidor) con vías a expandirse al patrón MVC. En este proyecto de tesis se propone una herramienta que refactorice código Java hacia código Java, bajo la arquitectura MVC en su variante MVA, la cual se considera que podría adaptarse al medio Web sin perder la flexibilidad del patrón MVC. Las entradas son variadas, pero siempre es código que en algún momento del proyecto se analiza automáticamente o manualmente, y se refactoriza teniendo como salidas código Java u otros lenguajes orientados a objetos. La herramienta desarrollada en este proyecto de tesis está programada en Java y ofrece como entradas y salidas código Java. Si bien no todos los proyectos utilizan una herramienta automática, queda asentado por los autores de los respectivos trabajos, que se encuentran en vías de desarrollar soporte automático para la implementación de sus marcos y metodologías. Si tomamos el trabajo relacionado [BODH, 02] y lo comparamos con el el trabajo realizado en esta tesis, se puede observar que los dos utilizan una metodología como base del proceso para la refactorización, y basado en cada metodología, se produce una herramienta que implementa dicho proceso de refactorización. Ambas herramientas están basadas en el patrón MVC, y están construidas en el lenguaje Java. Las entradas y salidas varían, puesto que el trabajo [BODH, 02] necesita código COBOL como entrada y produce páginas JSP y datos en formato XML, mientras que la herramienta actual toma como entrada código Java y produce código Java. Las dos herramientas son consideradas como automáticas, pues no se requiere la intervención del usuario más que para seleccionar algunos aspectos que no involucran a la parte del análisis de código. 18 Marco Teórico Capítulo 3. Marco Teórico En este capítulo se presentan algunos conceptos teóricos relevantes y tecnologías estudiadas para realizar la refactorización de los Marcos Orientados a Objetos hacia una arquitectura MVC. 3.1 Refactorización Fowler define la refactorización como: “Proceso de cambiar un sistema de software de tal manera que no se altere el comportamiento externo del código pero se mejora su estructura interna.” [FOWL,99] Se dice que al refactorizar se mejora el diseño del código después de que éste fue escrito, ya que el proceso permite “limpiarlo” y reduce las posibilidades de errores [FOWL,99]. Con la refactorización se puede tomar un mal diseño y restructurarlo como código bien diseñado, con pasos simples se puede mejorar el diseño radicalmente o adaptarlo a nuestras nuevas necesidades. Durante la refactorización se considera que a partir cómo está construido un sistema se puede aprender cómo mejorarlo. El resultado de esto nos permite mantener un sistema con un buen diseño conforme su desarrollo continúa. 19 Capítulo 3 3.2 Programación Orientada a Objetos La Programación Orientada a Objetos (POO) es uno de los muchos paradigmas (o modelos) de programación que existen. En este paradigma, el sistema de software es visto como un conjunto de objetos que colaboran entre sí, mediante el envío de mensajes para resolver un problema [PILL,06]. La Programación Orientada a Objetos tiene 5 componentes clave: Clase, Objeto, Instancia, Mensaje y Método. Clase: Una clase es una plantilla que define las variables y métodos comunes a todos los objetos de un cierto tipo. Una vez que se creó una clase se pueden crear cualquier número de objetos de esa clase. Objeto: Un objeto es un paquete de software que contiene variables y métodos relacionados. Las variables son elementos de datos identificados por un nombre y los métodos son funciones asociadas al objeto. Instancia: Todos los objetos son instancias de una clase. El método invocado por un objeto en respuesta a un mensaje es determinado por su clase. Todas las instancias de una clase usan el mismo método para responder a un mismo mensaje. Mensaje: Un mensaje es una petición para realizar una acción. El mensaje codifica la petición de una acción y, en algunos casos, es acompañado por información adicional (en forma de parámetros) necesaria para realizar la acción. El receptor es el objeto al que se le envía el mensaje. Si el receptor acepta el mensaje deberá llevar a cabo la acción indicada (un método) para satisfacer la solicitud. Método: Un método es una función asociada al objeto de una clase. Es cómo un objeto responde a un mensaje. 3.2.1 Propiedades de la POO La POO se basa en 4 propiedades que todos los lenguajes de programación orientados a objetos deben ser capaces de soportar: Abstracción de datos, Encapsulamiento de datos, Herencia y Polimorfismo. 3.2.1.1 Abstracción Según Timothy Budd: “La abstracción es la supresión deliberada, con el fin de ocultar algunos detalles de un proceso o artefacto, para poner de manifiesto más claramente otros aspectos, detalles o estructuras.” [PILL,06]. En la programación orientada a objetos se manejan diferentes niveles de abstracción. Los objetos y mensajes se pueden ver como ejemplos de la aplicación de la abstracción. 20 Marco Teórico 3.2.1.2 Encapsulamiento: Se le llama encapsulamiento a empaquetar las variables de los objetos dentro de la custodia protectora de sus métodos. El encapsulamiento se usa para esconder detalles internos de la implementación, los cuales no son importantes para otros objetos. Con el encapsulamiento se permite la modularidad, es decir, que el código fuente de un objeto puede escribirse y mantenerse sin afectar al código fuente de otros objetos. Y el ocultamiento de información; un objeto tiene una interfaz que los otros objetos pueden usar para comunicarse con él. 3.2.1.3 Herencia El término de herencia se refiere al hecho que una clase puede heredar parte o toda la estructura o comportamiento de otras clases. A la clase que hereda se le llama subclase o clase derivada. Si la clase B es una subclase de la clase A, entonces decimos que A es la superclase de B o clase base. Una subclase puede agregar variables o métodos de la clase que hereda. Puede remplazar o modificar el comportamiento heredado pero sin modificar las interfaces de los métodos heredados. 3.2.1.4 Polimorfismo El polimorfismo permite “programar de forma general”, en vez de “programar en forma específica”. Permite escribir programas que procesen objetos que compartan una misma estructura base dentro de una jerarquía de clases, como si todos los objetos fueran del mismo tipo; esto puede simplificar la programación. El polimorfismo se implementa mediante la invalidación y reemplazo de los métodos dentro de las subclases, y la asociación de tipo durante el tiempo de ejecución. Permite a los programadores tratar con las generalidades mientras se deja que el entorno se encargue de los detalles específicos durante el tiempo de ejecución. Con el polimorfismo se promueve la extensibilidad: el software que invoque el comportamiento polimórfico será independiente de los tipos de objetos a los cuales se envían los mensajes. En un sistema se pueden incorporar nuevos tipos de objetos que puedan responder a llamadas de métodos de objetos previos, sin necesidad de modificar el sistema base. Para agregar nuevos objetos, sólo se tendría que modificar el código cliente para adaptar las llamadas hacia estosa nuevos objetos [DEIT,08]. 3.3 Marcos de aplicaciones orientadas a objetos Un Marco de Aplicación Orientado a Objetos (Object-Oriented Application Framework) es un grupo de clases “semicompleto” que se ha transformado en una aplicación reusable, que puede ser utilizada para dar soluciones a una familia de problemas relacionados. A diferencia del reuso de aplicaciones Orientadas a Objetos que se basa en las librerías de clases, los Marcos de 21 Capítulo 3 aplicación Orientados a Objetos (MOO) tienen como objetivo sectores de negocios particulares y aplicaciones de dominio específicos. Algunos de los marcos de aplicaciones más importantes para el desarrollo de software son: MacApp, ET++, Interviews, ACE, Microsoft's MFC and DCOM, JavaSoft's RMI, e implementaciones de OMG's CORBA [FAYA,97]. Los principales beneficios que proporcionan los MOO son la modularidad, el reuso, extensibilidad y la inversión de control que se proporciona a los desarrolladores. Además de por su ámbito de aplicación, los marcos también se pueden clasificar por las técnicas utilizadas para extenderlo; existen los marcos de caja blanca y los marcos de caja negra. En los marcos de caja blanca la funcionalidad es reusada y extendida utilizando la herencia y sobreescritura de los métodos contenidos en las clases del marco; además, se pueden utilizar métodos gancho usando patrones de diseño como el Template Method. Por otro lado, en los marcos de caja negra, la extensión se realiza por la definición de interfaces de los componentes que se pueden conectar en el marco a través de la composición de objetos. La funcionalidad es reusada por la definición de componentes que se ajustan a una interfaz en particular y por la integración de dichos componentes en el marco utilizando patrones de diseño como el Strategy y Functor. Los MOO han demostrado ser una poderosa herramienta para el reuso, así como para capturar la esencia de los patrones, arquitecturas, componentes, políticas, servicios y mecanismos de programación exitosos [FAYA,97]. 3.4 Patrón Modelo Vista Controlador (MVC) La arquitectura del patrón MVC (Modelo-Vista-Controlador) originalmente fue aplicada en el modelo de interacción gráfica de usuarios, para entradas, procesamientos y salidas. Esta arquitectura descompone una aplicación en tres capas, donde cada capa es una estructura lógica de los diferentes elementos que componen el software. Las capas en que se divide el patrón MVC son el Modelo, la Vista y el Controlador [GULZ,02]. A continuación se describen brevemente: Modelo El modelo representa los datos de una aplicación y contiene la lógica para acceder a ellos y manipularlos. Los servicios que maneja el modelo deben ser lo suficientemente genéricos como para soportar varios tipos de clientes y debe ser fácil entender cómo controlar la conducta del modelo con tan solo revisar brevemente la lista de sus métodos. El modelo notifica a las vistas cuando cambia su estado y proporciona facilidades para que las vistas consulten el modelo acerca de su estado. También proporciona facilidades para que el controlador acceda a la funcionalidad de la aplicación encapsulada por el modelo. Vista 22 Marco Teórico La vista se encarga de acceder a los datos del modelo, especifica cómo se deben presentar esos datos y actualiza la presentación de los mismos cuando ocurren cambios en el modelo. La semántica de presentación está dentro de la vista, por lo tanto, la información contenida en el modelo se puede adaptar a diferentes tipos de vistas. La vista se modifica cuando el modelo se comunica con ella y a su vez, la vista envía información introducida por el usuario al controlador. Controlador El controlador define el comportamiento de la aplicación. Despacha las peticiones del usuario y selecciona las vistas de presentación siguiente basándose en la información introducida por el usuario y en el resultado de las operaciones realizadas por el modelo. Es decir, interpreta las entradas del usuario y las mapea en acciones a ser efectuadas por el modelo. Figura 1. Arquitectura del patrón MVC 3.4.1 Variaciones del patrón MVC Algunos autores consideran al patrón MVC no como a un solo patrón, sino como a una familia de patrones [SIML,09], esto es debido a que a partir del patrón MVC han surgido diferentes variaciones del mismo, algunas de las cuales se describen brevemente a continuación: Patrón Modelo Vista Presentador (MVP) Es un patrón derivado del patrón MVC, que mayoritariamente es utilizado para construir interfaces de usuario. En este patrón el Presentador asume el equivalente al Control en MVC. Y la Vista es el responsable de manejar los eventos de Interfaces de Usuario Gráficas (clics con el ratón o teclas presionadas) [BOOD,06]. Modelo: es una interfaz que define los datos a ser desplegados o no en la interfaz de usuario. Vista: es una interfaz que despliega los datos (el Modelo) y dirige los comandos del usuario (eventos) al Presentador para que actúe sobre los datos. 23 Capítulo 3 Presentador: actúa sobre el Modelo y la Vista. Recupera datos del Modelo y les da formato para mostrarlos en la Vista. Patrón Presentación-Abstracción-Control (PAC) El patrón PAC es usado como una estructura jerárquica de agentes, cada una constituida de una triada de Presentación, Abstracción y Control. Los agentes (o triadas) se comunican entre sí sólo a través de la parte del Control de cada triada. Y en cada triada se aísla por completo la presentación y la abstracción [SIML,09]. Presentación: juega el mismo papel que la Vista en el patrón MVC. Muestra la información desde la abstracción. Abstracción: contiene los datos, y a diferencia del MVC original, estos datos pueden ser sólo una parte de la estructura Control: actúa sobre el Modelo y la Vista. Recupera datos del Modelo y les da formato para mostrarlos en la Vista. Patrón Modelo Vista Vista-Modelo (MVVM) El patrón MVVM se basa en gran parte en el patrón MVC y está dirigido a las plataformas modernas de desarrollo de interfaz de usuario (Windows Presentation Foundation o WPF y Silverlight) en las que está involucrada la interfaz de usuario [SMIT,09]. Modelo: se refiere la capa que contiene los datos que representan el contenido de la aplicación, al igual que en el patrón MVC. Vista: son los elementos que se muestran en la interfaz de usuario (botones, ventanas, gráficos, etc.) VistaModelo: es un Modelo de la Vista, esto significa que es una abstracción de la Vista que también sirve de enlace de los datos entre la Vista y el Modelo, podría ser visto como el equivalente al Controlador del patrón MVC Patrón Modelo Delegado (MD) Es una variación del patrón MVC. Dos de las tres responsabilidades del MVC, en este caso se unen la capa de la Vista y la capa del Control en una sola que representa a la interfaz de usuario llamada Delegado [CUNN,05]. Modelo: contienen los datos específicos de la aplicación. Vista/Controlador: presentan la información e interactúan con el usuario. Patrón Modelo Vista Adaptador (MVA) El patrón MVA también es conocido como Mediador-Controlador MVC. Y al igual que el patrón MVC, el patrón MVA separa la lógica de negocios (el Modelo) de la capa de presentación (la Vista). Pero, en el patrón MVA la separación entre la Vista y el Modelo es absoluta, evitando la mezcla de elementos de la lógica del negocio con la presentación, lo cual es común con el patrón MVC [BUNG,11]. Las capas del patrón MVA son los siguientes: 24 Marco Teórico Modelo: al igual que en el patrón MVC esta capa contiene la lógica de negocios de la aplicación. Vista: al igual que en el patrón MVC esta capa contiene las interfaces de usuarios y es con la que el usuario interactúa. Adaptador: maneja todas las interacciones, actualización y flujo de control de la aplicación y permite la separación estricta entre el Modelo y la Vista. Es responsable de la sincronización y los aspectos dinámicos de la interfaz de usuario Como se puede observar en la Figura 1, mostrada anteriormente, tradicionalmente el MVC maneja las tres capas (Vista, Modelo y Control) interconectadas, de tal manera que hay cierto flujo de información entre la Vista y el Modelo sin pasar por la capa del Control. El patrón MVA resuelve este problema evitando que el Modelo y la Vista tengan comunicación directa, como se observa en la Figura 2 a continuación. Figura 2. Arquitectura del patrón MVA El Adaptador mantiene un apuntador al Modelo y a la Vista de tal manera que directamente llama a los métodos de ambos y es el responsable de mantenerlos en sincronía, cada uno de ellos no sabe nada sobre el otro [SIML,09]. La Vista se encuentra completamente desacoplada del Modelo, de tal manera que el Modelo sólo puede interactuar con la Vista a través del Adaptador. Con este arreglo, sólo el Adaptador tiene conocimiento del Modelo y la Vista, porque es responsabilidad solamente de él realizar esta comunicación. Esta completa separación permite a una gran variedad de diferentes Vistas acceder indirectamente al mismo Modelo con exactamente el mismo Adaptador o la misma clase de adaptadores. El adaptador o clases de adaptadores mantienen al Modelo completamente desinformado de que está siendo utilizado por múltiples interfaces de usuario aunque tal vez lo esté haciendo concurrentemente. Para el Modelo, estos múltiples tipos de interfaces de usuario lucen como instancias múltiples de un usuario genérico. De la misma manera, ninguna interfaz de usuario sabe sobre la variedad de diferentes Modelos que puede manejar el Adaptador. Porque la Vista sólo interactúa con un Adaptador y 25 Capítulo 3 nunca directamente con el Modelo. Además, varios Adaptadores pueden ser creados para cambiar la manera en que una Vista presenta datos para un Modelo dado. Algunas de las ventajas del patrón MVA sobre el patrón MVC son; todas las partes “movibles” se concentran en el Adaptador; la separación de interfaces entre la Vista y el Adaptador. La Vista es responsable de la distribución y la presentación visual, mientras que el Adaptador es responsable de la sincronización y los aspectos dinámicos de la interfaz de usuario; con esto se logra un mejor desacoplamiento entre Modelos y Vistas ya que la Vista no necesita saber nada sobre el Modelo y viceversa. La siguiente tabla presenta una descripción del patrón MVC y sus diferentes variaciones. Patrón Tabla 2. Descripción del patrón MVC y sus variaciones. Descripción Modelo Vista Controlador (MVC) La arquitectura de este patrón originalmente fue aplicada en el modelo de interacción gráfica de usuarios, para entradas, procesamientos y salidas. Esta arquitectura descompone una aplicación en tres capas, donde cada capa es una estructura lógica de los diferentes elementos que componen el software. Las capas en que se divide el patrón MVC son el Modelo, la Vista y el Controlador [GULZ,02]. Modelo Vista Presentador (MVP) Es un patrón derivado del patrón MVC, que mayoritariamente es utilizado para construir interfaces de usuario. En este patrón el Presentador asume el equivalente al Control en MVC. Y la Vista es el responsable de manejar los eventos de Interfaces de Usuario Gráficas (clics con el ratón o teclas presionadas) [BOOD,06]. PresentaciónAbstracciónControl (PAC) Es usado como una estructura jerárquica de agentes, cada una constituida de una triada de Presentación, Abstracción y Control. Los agentes (o triadas) se comunican entre sí sólo a través de la parte del Control de cada triada. Y en cada triada se aísla por completo la presentación y la abstracción [SIML,09]. Modelo Vista Vista-Modelo (MVVM) Se basa en gran parte en el patrón MVC y está dirigido a las plataformas modernas de desarrollo de interfaz de usuario (Windows Presentation Foundation o WPF y Silverlight) en las que está involucrada la interfaz de usuario [SMIT,09]. Modelo Delegado (MD) Es una variación del patrón MVC. Dos de las tres responsabilidades del MVC, en este caso se unen la capa de la Vista y la capa del Control en una sola que representa a la interfaz de usuario llamada Delegado [CUNN,05]. Modelo Vista Adaptador (MVA) También es conocido como Mediador-Controlador MVC. Y al igual que el patrón MVC, el patrón MVA separa la lógica de negocios (el Modelo) de la capa de presentación (la Vista). Pero, en el patrón MVA la separación entre la Vista y el Modelo es absoluta, evitando la mezcla de elementos de la lógica del negocio con la presentación, lo cual es común con el patrón MVC [BUNG,11]. 3.5 Lenguaje de programación Java El lenguaje de programación Java es un lenguaje de propósito general, concurrente, basado en clases y orientado a objetos [GOSL,05]. Está muy relacionado a los lenguajes C y C++ pero se organiza de manera un poco diferente. 26 Marco Teórico Java omite algunos aspectos de C y C++ como el soporte a la expresión goto; la utilización de estructuras y uniones; y elimina herramientas de bajo nivel como la manipulación directa de punteros o memoria. E incluye algunas ideas de otros lenguajes como la administración automática de memoria de Eiffel y la utilización de una máquina virtual de Smalltalk. Este lenguaje es de tipo estático fijo, es decir, sus variables no cambian de tipo una vez declaradas, y es considerado relativamente de alto nivel, incluye manejo de almacenamiento automático para el que se usa un colector de basura. 3.5.1 Paquetes En java, los programas se organizan en conjuntos de paquetes. La estructura de los nombres para los paquetes es jerárquica. Los miembros de un paquete son tipos clase, tipos interfaz y subpaquetes, estos subpaquetes contienen unidades de compilación y subpaquetes a la vez. Un paquete consta de unidades de compilación. Una unidad de compilación automáticamente tiene acceso a todos los tipos declarados dentro del paquete y automáticamente importa los tipos public declarados en el paquete predefinido java.lang. Para programas pequeños y desarrollos casuales, un paquete puede no tener nombre o tiene un nombre simple, pero si el código va a ser distribuido, deben de escogerse nombres únicos para prevenir conflictos, en [GOSL,05] se menciona cómo realizar esta construcción de nombres. 3.5.2 Clases En Java, una declaración de clase define un nuevo tipo de referencia y describe como es implementado. Una clase anidada es una clase cuya declaración ocurre dentro del cuerpo de otra clase o dentro de una interfaz. Una clase de nivel superior es una clase que no es anidada. Una clase puede ser declarada abstract, y debe serlo, cuando no está implementada completamente, tal clase no puede ser instanciada pero puede ser extendida por subclases. Las clases que son declaradas final no pueden tener subclases. Si es declarada public, entonces puede ser accedida desde otros paquetes. El cuerpo de una clase declara miembros (campos, métodos, clases e interfaces anidadas), instancias e inicializadores estáticos, y constructores. El ámbito de un miembro es el cuerpo entero de la declaración de la clase a la cual el miembro pertenece, las declaraciones de campos, métodos de clase, clases miembro, interfaces miembro y constructores pueden incluir modificadores de acceso public, protected o private. 3.5.3 Interfaces Una interfaz especifica un nuevo tipo de referencia cuyos miembros son clases, constantes y métodos abstractos. Estos tipos no tienen implementación, pero otras clases pueden implementarlos proveyendo implementación para sus métodos abstractos. 27 Capítulo 3 Una interfaz anidada es una interfaz cuya declaración aparece dentro del cuerpo de otra clase o interfaz. Una interfaz de nivel superior, es una interfaz que no es anidada. Hay dos tipos de interfaces, interfaces normales y tipos anotación. Las interfaces son usadas con el propósito de evitar que clases relacionadas, compartan una superclase abstracta común. Una interfaz puede ser declarada para ser una extensión directa de uno o más interfaces, esto significa que implícitamente especifica todos los tipos miembros, métodos abstractos y constantes de las interfaces que extiende, excepto por cualquier tipo miembro y constantes que se oculten. Una clase puede declarar que directamente implementa una o más interfaces, esto significa que cualquier instancia de la clase implementa todos los métodos abstractos especificados por la interfaz o interfaces. Esta múltiple herencia de interfaces permite a los objetos soportar múltiples comportamientos comunes sin compartir ninguna implementación. Una variable cuyo tipo es una interfaz puede tener como sus valores, una referencia a cualquier instancia de una clase la cual implementa la interfaz especificada. 3.5.4 Constructores Un constructor es usado en la declaración de un objeto, el cual es una instancia de una clase. Su nombre debe ser el mismo que el de la clase que lo contiene. En todos lo demás, la declaración del constructor luce sólo como una declaración de método que no tiene tipo de retorno. Los constructores son invocados por expresiones de creación de instancia de clase y nunca son invocados por expresiones de invocación de métodos. El acceso a constructores es determinado por modificadores de acceso; nunca son heredados y por lo tanto no son sujetos al ocultamiento o sobreescritura. 3.5.5 Métodos Un método declara código ejecutable que puede ser invocado, pasando un número de argumentos. El cuerpo del método es un bloque de código que contiene un conjunto de instrucciones y que implementa el comportamiento del método. Sí se tuviese simplemente un punto y coma, esto indicaría que falta la implementación, es decir, que se trata de un método abstracto. Si una implementación va a ser provista para una declaración de método void, pero la implementación no requiere código ejecutable, el cuerpo del método debería ser escrito como un bloque con no contiene sentencias “{}”. Si un método es declarado void, entonces su cuerpo no debe contener la sentencia return que retorna un valor. Si un método es declarado para tener un tipo de retorno, entonces cada sentencia return en su cuerpo tiene un valor de retorno. Nótese que para un método es posible tener declarado un tipo de retorno y no contener sentencia return. 28 Marco Teórico 3.5.6 Variables Una variable es una ubicación de almacenamiento y tiene un tipo asociado, ya sea un tipo primitivo o un tipo de referencia. El valor de una variable es cambiado con una asignación o por un operador prefijo o postfijo ++ (incremento) o -- (decremento). El lenguaje de programación Java, garantiza la compatibilidad del valor de una variable con su tipo, siempre y cuando, no se presenten advertencias en tiempo de compilación del programa. 3.5.6.1 Variables de tipo primitivo Una variable de tipo primitivo siempre mantiene un valor de ese mismo tipo exactamente. Los tipos primitivos son: boolean, byte, short, int, long, char, float o double. 3.5.6.2 Variables de tipo de referencia Una variable de tipo de referencia es una variable de tipo complejo que hace referencia a objetos basados en alguna clase. Una variable de tipo clase T puede almacenar una referencia a null o una referencia a una instancia de la clase T o a cualquier clase que sea una subclase de T. Una variable de tipo interfaz puede almacenar una referencia a null o una referencia a cualquier instancia de cualquier clase que implementa la interfaz. 3.5.6.3 Tipos de variables. En Java existen siete tipos de variables: 1. Una variable de clase es un campo declarado usando la palabra reservada static dentro de la declaración de clase, podríaestar o no contener la palabra reservada static dentro de una declaración de interfaz. 2. Una variable de instancia es un campo declarado dentro de una clase sin usar la palabra reservada static. 3. Componentes array son variables sin nombre, que son creados e inicializados a valores por defaul en donde se cree un nuevo objeto que es de tipo array. 4. Parámetros de método, llamados valores de argumento, los cuales son enviados a un método. Para cada parámetro declarado en una declaración de método, una nueva variable de parámetro es creada cada vez que el método es invocado. 5. Parámetros de constructor llamados valores de argumento enviados a un constructor. Por cada parámetro declarado en una declaración de constructor, una nueva variable de parámetro es creada cada vez que se invoca ese constructor. 6. Un parámetro de manejador de excepciones es creado cada vez que una excepción es capturada por una cláusula catch o una sentencia try. La nueva variable es inicializada con el objeto actual asociado con la excepción. 7. Variables locales, son declaradas por un estatuto de declaración de variables locales. Puede estar declaradas en cualquier lugar del flujo de control, dentro de un bloque o en un estatuto for. Una declaración de variable local puede contener una expresión en la 29 Capítulo 3 cual se inicialice la variable, sin embargo, no se inicializa hasta que el estatuto de declaración de variable local es ejecutado. 3.5.7 Modificadores de acceso En Java, existen 4 modificadores de acceso: Public: un miembro con este modificador puede ser accedido por los elementos de la clase en que se declara; por los elementos de una subclase; los elementos de otra clase dentro del mismo paquete y elementos de una clase en diferente paquete. Protected: un miembro con este modificador puede ser accedido por los elementos de la clase en que se declara; y por los elementos de una subclase. Private: Los miembros private sólo pueden ser accedidos por los elementos de la clase en que se declara. Default: también conocido como package friendly. Cuando no se especifica alguno de los modificadores de acceso anteriormente mencionados, se establece este modificador de acceso por default, con el cual el miembro puede ser accedido por los elementos de la clase en que se declara; por los elementos de una subclase; y los elementos de otra clase dentro del mismo paquete. 3.6 Compilador Un compilador es un programa que lee un programa escrito en un lenguaje, conocido como lenguaje fuente, y lo traduce a un programa equivalente, en otro lenguaje, conocido como lenguaje objeto. Los lenguajes objeto son variados; pueden ser otro lenguaje de programación o lenguaje máquina [AHO,98]. Los compiladores pueden clasificarse como de una pasada, múltiples pasadas, de carga y ejecución, de depuración o de optimización, dependiendo de cómo se construyan o de la función que realicen. Sea como sea, las tareas básicas que debe realizar un compilador son esencialmente las mismas. 3.6.1 Fases de un compilador Se considera que en la compilación hay dos tareas principales; el Análisis y la Síntesis. El Análisis consta de las fases de Análisis Léxico, Análisis Sintáctico y Análisis Semántico. Y la Síntesis de las fases de Generación de Código Intermedio, Optimización de Código y Generación de Código. Otras actividades que se realizan simultáneamente a las seis fases anteriormente mencionadas son la Administración de la Tabla de Símbolos y el Manejo de Errores. A continuación, se muestra estas fases. 30 Marco Teórico Figura 3. Fases de un Compilador 3.6.1.1 Fases del Análisis Durante el Análisis se divide al programa fuente en elementos y se crea una representación intermedia del mismo. En esta fase se determinan las operaciones que implica el programa fuente y se registra en una estructura jerárquica llamada árbol. Frecuentemente se utiliza un árbol sintáctico, en el cual, cada nodo representa una operación y los hijos del nodo son los argumentos de la operación. Análisis Léxico También conocido como exploración. En esta fase, la cadena de caracteres que constituye el programa fuente se lee de izquierda a derecha y se agrupa en componentes léxicos, que son secuencias de caracteres con un significado colectivo. Análisis Sintáctico Se agrupan los componentes léxicos del programa fuente en frases gramaticales que el compilador utiliza para sintetizar la salida. Generalmente, las frases gramaticales se representan mediante un árbol de análisis sintáctico. 31 Capítulo 3 Análisis Semántico En esta fase se revisa el programa fuente para encontrar errores semánticos y se reúne la información sobre los tipos para la fase posterior de generación de código. Se utiliza la estructura jerárquica resultante de la fase de análisis sintáctico para identificar los operadores y operandos de expresiones y proposiciones. En esta fase se realiza la verificación de tipos, lo cual es una parte importante en la que el compilador verifica si los operadores tienen operandos permitidos por la especificación del lenguaje fuente. 3.6.1.2 Fases de Síntesis Durante estas fases se construye el programa objeto deseado a partir de la representación intermedia. Esta parte es la que requiere más técnicas especializadas. Generación de Código Intermedio Después del análisis sintáctico y semántico, algunos compiladores generan una representación intermedia explícita del programa fuente. Esta representación intermedia puede ser considerada como un programa para un a máquina abstracta y debe tener dos propiedades importantes; debe ser fácil de producir y fácil de traducir al programa objeto. La representación intermedia puede tener diversas formas. Una de ellas es el código de tres direcciones, que podría considerarse como el lenguaje ensamblador para una máquina en la que cada posición de memoria puede actuar como un registro. Optimización de Código En esta fase se trata de mejorar el código intermedio, para obtener un código máquina más rápido de ejecutar. Varía mucho la cantidad de optimización de código que ejecutan los diferentes compiladores. En los llamados “compiladores optimizadores” una gran parte del tiempo se ocupa en esta fase. Pero también, hay optimizaciones sencillas que mejoran sensiblemente el tiempo de ejecución del programa objeto y sin tomar mucho tiempo de compilación. Generación de Código La fase final de un compilador es la generación de código objeto, que por lo general consiste en código de máquina relocalizable o código ensamblador. En esta fase se seleccionan las posiciones de memoria para cada variable usada por el programa. Después, cada instrucción intermedia se traduce a una secuencia de instrucciones de máquina que ejecutan la misma tarea. En esta fase, un aspecto decisivo es la asignación de variables a registros. 3.6.1.3 Otras Actividades Otras dos actividades; la Administración de la Tabla de Símbolos y el Manejo de Errores, son actividades que interactúan con las seis fases del compilador. Administración de la tabla de símbolos 32 Marco Teórico Una función esencial de un compilador es registrar los identificadores utilizados en el programa fuente y reunir información de los distintos atributos de cada identificador, para lo cual es utilizada una tabla de símbolos. La tabla de símbolos es una estructura de datos que contiene un registro por cada identificador, y puede almacenar sus diferentes características. La estructura de datos permite encontrar rápidamente cada identificador y almacenar o consultar sus datos. Los atributos almacenados pueden proporcionar información sobre la memoria asignada a un identificador, su tipo, su ámbito (la parte del programa donde tiene validez) y, en caso de las funciones, el número y tipos de sus argumentos, el tipo que devuelve, etc. Detección de errores Durante todas las fases del compilador se pueden encontrar errores. Sin embargo, al detectar un error, cada fase debe tratar de alguna forma ese error, para poder continuar con la compilación, permitiendo la detección de más errores en el programa fuente. Las fases en las que se presenta la mayor cantidad de errores son las fases del análisis sintáctico y semántico. En la fase de análisis léxico se puede detectar errores cuando los caracteres de entrada no forman ningún componente léxico del lenguaje. Un compilador que se detiene cuando encuentra el primer error, no resulta tan útil como debería. 3.6.2 Programas similares a un Compilador Otros programas similares a un compilador son los Intérpretes y los Traductores los cuales se definen a continuación: Intérprete Es un programa que en lugar de producir un programa objeto, realiza las operaciones que se indican en el programa fuente. Algunos lenguajes de programación, Java entre ellos, utilizan un intérprete para traducir al instante el código que se va leyendo a lenguaje máquina para que pueda ser ejecutado. La principal ventaja de un Intérprete sobre un Compilador es que dado cualquier programa, si éste fue interpretado, entonces se podrá interpretar en cualquier sistema operativo. Pero por otro lado, el archivo generado por el compilador solo funciona en el sistema operativo para el que fue creado [DIRE,11]. Traductor Programa que recibe una entrada en un lenguaje y produce una salida en otro lenguaje. Como se puede notar, la definición de un Traductor incluye a los Compiladores y los Intérpretes, pues los dos programas reciben una entrada en un lenguaje y obtienen una salida en otro lenguaje. 33 Capítulo 3 3.7 Servicio Web Los servicios Web son un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web, dichas aplicaciones intercambian datos entre sí, de esta manera ofrecen nuevos servicios. A través de la Web los proveedores ofrecen sus servicios como procedimientos remotos y los clientes los solicitan llamando a estos procedimientos. Estos servicios proporcionan mecanismos de comunicación estandar entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica [W3C,10]. 3.8 Otros conceptos. Otros conceptos utilizados en el contexto de esta tesis, son los términos que se definen a continuación [NUÑE,08]. 3.8.1 Función especializada Son las funciones en las que la totalidad del código que la conforman, pertenece a una sola parte del patrón MVC, es decir pertenecen exclusivamente a la parte del Modelo, de la Vista o del Control. Es importante señalar que en el contexto de la presente tesis, el papel que desempeña la parte del Control en la arquitectura MVC es tomado por el Adaptador. En la Figura 4 se muestra un ejemplo de función especializada de la Vista. Figura 4. Ejemplo de función especializada. 3.8.2 Función no-especializada. Se denominan funciones no-especializadas a las funciones que tienen estatutos de código que pertenecen a más de dos partes diferentes del patrón MVC. La Figura 5 muestra un ejemplo de una función no especializada pues contiene tanto estatutos de la Vista como del Modelo. 34 Marco Teórico Figura 5. Ejemplo de función no-especializada 3.8.3 Clase especializada Una clase especializadas es una clase compuestas por una o más funciones especializadas de la misma parte del patrón MVC. Como se mencionó anteriormente, en el contexto de la presente tesis, el papel que desempeña la parte del Control en la arquitectura MVC es tomado por el Adaptador. En la Figura 6 se presenta un ejemplo de una clase especializada. Figura 6. Ejemplo de clase especializada 3.8.4 Clase no-especializada Una clase no-especializada es una clase que incluye funciones no-especializadas o una mezcla de funciones especializadas de diferente parte del patrón MVC y no-especializadas. La Figura 7 muestra un ejemplo de una clase no-especializada pues contiene funciones especializadas tanto de la Vista como del Modelo. 35 Capítulo 3 Figura 7. Ejemplo de clase no-especializada 36 Modelo Conceptual del Sistema Capítulo 4. Modelo Conceptual del Sistema El proceso de refactorización de marcos de aplicaciones orientado a objetos hacia una arquitectura MVC se basa en el análisis del código del MOO para obtener información sobre su arquitectura inicial; y en seguida se utiliza dicha información para realizar la separación de los elementos pertenecientes a las diferentes partes del patrón. En este capítulo se describe la manera en que fue diseñado el proceso de refactorización. Y además se describen a detalle el proceso, las actividades y los métodos utilizados para realizar la refactorización de MOO hacia una arquitectura MVC. 4.1 Diseño del Proceso de Refactorización Para cumplir con el objetivo del presente trabajo de tesis se realizaron distintas pruebas de escritorio a los métodos presentados en [NUÑE,08]. A continuación se muestra una lista de los métodos probados junto con una pequeña descripción de cada uno de ellos. 37 Capítulo 4 Método heurístico H0, “Definir plantilla genérica MVC”: genera una arquitectura de clases conforme al patrón MVC. Método heurístico H1, “Análisis del código legado”: identifica los estatutos, las funciones y clases del código legado de acuerdo a la parte del patrón MVC a la que pertenecen. Método heurístico H2, “Crear clases”: define la declaración de clases simples, clases abstractas e interfaces en un archivo. Método heurístico H3, “Crear constructor”: crea constructores simples y constructores con parámetros. Método heurístico H4, “Crear función”: crea una función sin parámetros o con parámetros. Método heurístico H5, “Reubicar atributos”: reubica los atributos y su inicialización desde las clases legadas a las clases concretas correspondientes de la plantilla MVC. Método heurístico H10, “Fragmentar funciones”: fragmenta las funciones noespecializadas y utiliza el método de crear funciones para generar funciones especializadas. Método heurístico H11, “Redefinir llamadas funciones”: sustituye la actual llamada a una función, que después de ser fragmentada queda ubicada en alguna de las clases de la plantilla MVC. Durante la ejecución de las pruebas de escritorio se determinó que era necesario realizar modificaciones, tanto para hacer algunas correcciones como para adaptarlos al patrón MVA, el cual, como se mencionó en el Capítulo 3, es un patrón derivado del patrón MVC que se apega más al objetivo y la intención de desacoplar completamente la parte de presentación de los MOO (la Vista), de la parte de la lógica de negocios (el Modelo). Debido a que en el trabajo [NUÑE,08] no se establece un proceso de reestructura que integre los métodos que fueron desarrollados, además del refinamiento de los métodos, también fue necesario definir el proceso de refactorización. Las modificaciones a los métodos y la definición del proceso de refactorización se realizó en colaboración con la estudiante de doctorado del CENIDET M.C. Sheydi Anel Zamudio López, quien está desarrollando un proyecto titulado “Migración de marcos de aplicaciones orientados a objetos hacia servicios web”, en el cual realiza la especificación formal de los métodos; y con quien se trabajó estrechamente. La terminología utilizada para la identificación de las actividades y los métodos es la siguiente: An: Rn: N-esima actividad del proceso de refactorización. N-esimo método de reestructura. En donde n representa un número consecutivo o identificador. Una actividad (A) se conforma de métodos (R). La actividad A1 está conformada por el método R1 y la actividad A2 por los métodos del R2 al R11. 38 Modelo Conceptual del Sistema El resultado del refinamiento de los métodos propuestos en [NUÑE,08], y nuevos métodos creados ante la necesidad de diseñar el proceso de refactorización, son los 11 métodos descritos a continuación: Método de reestructura R1: “Analizar código legado”: método equivalente al método H1 “Análisis del código legado”. En este método se conservó la intención de identificar los estatutos, las funciones y clases del código legado de acuerdo a la parte del patrón MVC a la que pertenecen. Las modificaciones realizadas fueron en el sentido de no sólo etiquetar el código sino también almacenar información del código del MOO en tablas. Método de reestructura R2: “Crear clases”: se conservó la intención del método H2 “Crear clases”, de definir la declaración de clases simples, clases abstractas e interfaces en un archivo. Las modificaciones realizadas tuvieron que ver con las diferentes opciones de clases que se pueden crear. Método de reestructura R3: “Crear constructor”: se conserva la intención del método H3 “Crear constructor”, de crear constructores simples y constructores con parámetros, y se agregó la opción de copiar constructores desde otra clase. Método de reestructura R4: “Crear funciones”: se mantiene la intención de crear una función con parámetros o sin parámetros y además se considera la inserción de estatutos de código en el cuerpo de la función. Método de reestructura R5: “Reubicar atributos”: al igual que el método H5 “Reubicar atributos”, reubica los atributos, pero en lugar de copiarlos desde otra clase, ahora se obtienen los atributos a reubicar desde una tabla especialmente diseñada con ese objetivo. Método de reestructura R6: “Reestructurar clases”: este método es el orquestador de todo el proceso de refactorización. Método de reestructura R7: “Estructura jerárquica de clases”: con este método se obtiene la arquitectura original de los MOO con el objetivo de conservarla en la parte del modelo durante el proceso de reestructura. Método de reestructura R8: “Coordinador de la creación de clases”: se puede considerar este método como el equivalente al método H0 “Definir plantilla genérica MVC”, las modificaciones están relacionadas con la manera en que se crea la nueva arquitectura de acuerdo al patrón MVA. Método de reestructura R9: "Reubicar funciones especializadas": se reubican las funciones especializadas, actividad realizada anteriormente por el método H10 “Fragmentar funciones”. Método de reestructura R10: "Fragmentar funciones no especializadas": se fragmentan las funciones no-especializadas, actividad realizada anteriormente por el método H10 “Fragmentar funciones”. Método de reestructura R11: "Redefinir llamadas a funciones": al igual que con el método H11 “Redefinir llamadas funciones”, en este método se sustituye la actual llamada a una función que ha sido reubicada. 39 Capítulo 4 En las siguientes secciones se presenta una descripción más amplia del proceso de refactorización y de las actividades y métodos utilizados durante el mismo. 4.2 MOO2MVA: Marco de Aplicaciones Orientadas a Objetos hacia una arquitectura MVA El proceso de refactorización de Marcos de Aplicaciones Orientados a Objetos hacia una arquitectura MVA está constituido de 11 métodos (R1-R11) los cuales están divididos en dos actividades principales: A1. Analizar el código del MOO original y etiquetar los estatutos, funciones y clases de acuerdo a las partes del patrón MVA a las que pertenecen. A2. Reestructurar el código legado. Dichas actividades son descritas por su intención, procedimiento, suposiciones, poscondiciones e interacción de los métodos. Durante la actividad A1 se obtiene una descripción inicial del MOO. Las salidas obtenidas son: el código del MOO etiquetado; y un diccionario de datos compuesto de un conjunto de tablas, las cuales contienen información sobre las clases, métodos y atributos de clase que conforman el MOO. En la actividad A2, se utiliza la información obtenida en la primera actividad para realizar la refactorización; como salida se obtiene el código del MOO con una arquitectura MVA. En la Figura 8 se muestra el proceso de refactorización. 40 Modelo Conceptual del Sistema Figura 8. Proceso de refactorización de MOO a arquitectura MVA 4.3 A1. Analizar el código del MOO original y etiquetar los estatutos, funciones y clases de acuerdo a las partes del patrón MVA a las que pertenecen. A continuación se describe la actividad A1. “Analizar el código del MOO original y etiquetar los estatutos, funciones y clases de acuerdo a las partes del patrón MVA a las que pertenecen”. Dicha descripción se realiza mediante su intención, procedimiento, suposiciones, poscondiciones e interacción de los métodos. Intención: Identificar a qué parte del patrón MVA corresponde cada uno de los estatutos de código, las funciones y las clases del MOO. Precondiciones: Tener acceso al código del conjunto de clases del MOO original y haber realizado la clasificación de los estatutos del lenguaje en que está escrito el MOO. Procedimiento: Paso A1.1: Analizar los estatutos, las funciones y las clases del MOO en estudio, con la finalidad de: 41 Capítulo 4 a) Identificar cada estatuto de código del MOO. b) Etiquetar los elementos de código de acuerdo a la parte del patrón a la que pertenecen. c) Generar información sobre las clases y las funciones del MOO en estudio, que apoyarán las siguientes actividades del proceso de reestructura. Suposiciones: A partir de identificar y etiquetar los elementos de código, es posible llevar a cabo la reestructura del MOO en estudio. Poscondiciones: Los elementos del código del MOO en estudio quedan etiquetados de acuerdo a la parte del patrón MVA a la que pertenecen. Se obtiene información de tipos de clases, funciones abstractas, funciones concretas y tipos de variables. Interacción de los métodos de reestructura: Los pasos de esta actividad se llevan a cabo aplicando el método de reestructura R1 y no interacciona con otros métodos. 4.3.1 Método de reestructura R1: “Analizar código legado” La intención del método R1 es analizar el código legado de tal manera que se etiquete cada estatuto dependiendo de la parte del patrón MVA a la que pertenece, en seguida, etiquetar y almacenar funciones, ya sean especializadas o no especializadas y finalmente las clases, también especializadas y no especializadas. Por otro lado, mientras se realiza la etiquetación, se va almacenando información sobre las variables, funciones y clases en las tablas: “Tipos de clases”, “Funciones abstractas”, “Funciones concretas”, “Tipos de Variables”. Dichas tablas se describen a continuación. Tabla 3. Descripción de la tabla Tipos de clases Campo Nombre Paquete Tipo Tipo Relación 1 Clase Base 1 Tipo Relación 2 42 Tipos de clases Descripción Nombre de la clase identificada durante el análisis de código. Nombre del paquete al que pertenece la clase identificada. Tipo de la clase, puede ser “concreta”, “abstract” o “interface”. Primer tipo de relación que mantiene la clase, puede ser ninguna, “extends” (herencia) o “implements” (implementación). Nombre de la clase con la cual se tiene la relación establecida en el campo Tipo Relación 1. Segundo tipo de relación que mantiene la clase, puede ser ninguna, “extends” (herencia) o “implements” (implementación). Modelo Conceptual del Sistema Clase Base 2 Patrón MVC Nombre de la clase con la cual se tiene la relación establecida en el campo Tipo Relación 2. Parte del patrón MVA a la que pertenece la clase identificada, puede ser “Modelo”, “Vista”, “Control”, “Sin definir” o “No especializada” Tabla 4. Descripción de la tabla Funciones Abstractas Campo Firma Especificador Tipo de retorno Clase Patrón MVC Funciones abstractas Descripción Firma de la función abstracta que ha sido detectada durante el análisis de código. Especificador de acceso de la función abstracta. Tipo del valor de retorno de la función abstracta. Nombre de la clase a la que pertenece la función abstracta. Nombre de la parte del patrón a la que pertenece la función (Modelo, Vista o Control). Tabla 5. Descripción de la tabla Funciones Concretas Funciones concretas Campo Descripción Firma Firma de la función concreta que ha sido detectada durante el análisis de código. Especificador Especificador de acceso de la función concreta. Tipo de retorno Tipo del valor de retorno de la función concreta. Variable de Nombre de la variable que se utiliza para realizar el retorno. Retorno Clase Nombre de la clase a la que pertenece la función concreta. Patrón MVC Nombre de la parte del patrón a la que pertenece la función (Modelo, Vista o Control). Tabla 6. Descripción de la tabla Tipos de Variables Campo Identificador Tipo Especificador Clase Variable Firma Función Clase Función Tipos de Variables Descripción Identificador de la variable detectada durante el análisis de código. Tipo de la variable. Especificador de acceso de la variable. Nombre de la clase en donde fue declarada la variable. Firma de la función de donde se accede a la variable. Nombre de la clase a la que pertenece la función que accede a la variable. Las figuras que van de la Figura 9 a la Figura 15 muestran el Diagrama de Actividad que representa el proceso que se sigue en el Método de Reestructura R1: “Analizar Código Legado” 43 Capítulo 4 Figura 9. Diagrama de Actividad del Método R1: “Analizar Código Legado” 44 Modelo Conceptual del Sistema Figura 10. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 2) 45 Capítulo 4 Figura 11. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 3) 46 Modelo Conceptual del Sistema Figura 12. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 4) 47 Capítulo 4 Figura 13. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 5) 48 Modelo Conceptual del Sistema Figura 14. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 6) 49 Capítulo 4 Figura 15. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 7) Los pasos del Método de reestructura R1: “Analizar código legado” se encuentran en el Anexo A. 50 Modelo Conceptual del Sistema 4.4 A2. Reestructurar el código legado. A continuación se describe la actividad A2. “Reestructurar el código legado”. Dicha descripción se realiza mediante su intención, procedimiento, suposiciones, poscondiciones e interacción de los métodos. Intención: Separar y reubicar los elementos de código del marco orientado a objetos original, de acuerdo a la parte del patrón que les corresponde. Precondiciones: Los estatutos de código, las funciones y las clases del marco orientado a objetos original deben estar etiquetados de acuerdo a la parte del patrón MVA a la que pertenecen. Las tablas “Tipos de clases”, “Funciones abstractas” y “Funciones concretas” deben estar creadas. Procedimiento: Paso A2.1: Crear las tablas “Clases Modelo”, “Clases Vista”, “Clases Adaptador”, “Funciones abstractas MVA”, y “Funciones concretas MVA”. Paso A2.2: Obtener la jerarquía de clases del marco orientado a objetos original, con la finalidad de conservarla en la parte del Modelo. Paso A2.3: Siguiendo el orden de la jerarquía de clases del marco orientado a objetos original, crear las clases del nuevo marco orientado a objetos con arquitectura MVA. Este paso implica: a) Crear las clases del Modelo, la Vista y el Adaptador que se requieren (Paso A2.3.a). Paso A2.4: Si la clase en estudio es especializada en alguna parte del patrón MVA, reubicar a los miembros de la clase en la parte del patrón a la que pertenecen. Este paso implica: a) Reubicar los constructores de la clase (Paso A2.4.a). b) Reubicar las funciones de la clase (Paso A2.4.b). c) Reubicar los atributos de la clase (Paso A2.4.c). d) Redefinir las llamadas a las funciones ya reubicadas que se encuentren en el código (Paso A2.4.d). Paso A2.5: Si la clase en estudio es No-especializada, fragmentar la clase para reubicar a sus elementos de código en la parte del patrón a la que pertenecen. Este paso implica: a) Crear los constructores de las clases MVA (Paso A2.5.a). b) Crear nuevas funciones para reubicar los estatutos de código que pertenezcan a la Vista y/o al Adaptador (Paso A2.5.b). c) Reubicar los atributos a los que acceden las funciones reubicadas (Paso A2.5.c). d) Redefinir las llamadas a las nuevas funciones (Paso A2.5.d). Suposiciones: La parte del modelo mantiene la arquitectura del marco original y no tiene ningún elemento de la Vista. La Vista contiene solamente los elementos de código que pertenezcan a esta parte del patrón. El Adaptador gestiona las interacciones entre el Modelo y la Vista. 51 Capítulo 4 Poscondiciones: Se obtiene un marco orientado a objetos con arquitectura MVA. Interacción de los métodos de reestructura: Después de analizar y etiquetar el código fuente del marco orientado a objetos original, se inicia la reestructuración de la arquitectura del marco, aplicando el método R6. Este método coordina el proceso de reestructuración llamando a los métodos R7, R8, R9 y R10. La Figura 2 muestra gráficamente este proceso, el cual termina cuando todas las clases del marco orientado a objetos original han sido reubicadas en la arquitectura MVA. Es importante señalar que aunque esta actividad consta de 10 métodos (R2-R11), debido a limitaciones de tiempo, actualmente se encuentran en una etapa de refinamiento los métodos R6: “Reestructurar clases”, R8: “Coordinador de la creación de clases”, R9: "Reubicar funciones especializadas", R10: "Fragmentar funciones no especializadas" y R11: "Redefinir llamadas a funciones". Debido a lo anterior, a continuación son presentados únicamente los métodos: R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases” 4.4.1 Método de reestructura R7: “Estructura jerárquica de clases” En el método “R7: Estructura jerárquica de clases” se realiza un recorrido sobre la tabla “Tipos de Clase” la cual fue llenada durante la ejecución del método R1 y que contiene las diferentes clases que conforman el MOO; tal recorrido tiene como objetivo obtener la jerarquía de clases del MOO original, esto con la finalidad de conservarla en la parte del Modelo. Durante la ejecución de este método se utiliza la tabla “Jerarquía de Clases” que es descrita en la Tabla 7. Y el proceso seguido para la ejecución de este método se describe en el diagrama de actividad que se muestra en la Figura 16. Tabla 7. Descripción de la tabla Jerarquía de Clases Campo Clase Padre Clase Hija 52 Jerarquía de Clases Descripción Nombre de la clase que se está analizando, todas las clases del MOO aparecen al menos una vez en este campo. Nombre de la clase que extiende o implemente a la clase padre, puede ser ninguna. Modelo Conceptual del Sistema Figura 16. Diagrama de Actividad del Método R7: “Estructura jerárquica de clases” Los pasos seguidos durante este método se encuentran definidos en el Anexo A. 53 Capítulo 4 4.4.2 Método de reestructura R2: “Crear clases” Este método es utilizado por el método R8 para crear las clases del Modelo, Vista y Adaptador que se necesiten durante el proceso de reestructura. Los pasos del método R2 se pueden encontrar en el Anexo A. El proceso seguido durante la ejecución de este método se muestra en el diagrama de actividad de la Figura 17. 54 Modelo Conceptual del Sistema Figura 17. Diagrama de Actividad del Método R2: “Crear clases” 55 Capítulo 4 4.4.3 Método de reestructura R3: “Crear constructor” El método “R3: Crear Constructor” es utilizado por los métodos R9: "Reubicar funciones especializadas" y R10: "Fragmentar funciones no especializadas" para generar constructores de clase, lo cual es realizado al crearlos o al reubicarlos (copiarlos) desde otras clases. El proceso del método se describe en el diagrama de actividad que va de la Figura 18 a la Figura 19. Y Los pasos que sigue este algoritmo se encuentran definidos en el Anexo A. 56 Modelo Conceptual del Sistema Figura 18. Diagrama de Actividad del Método R3: “Crear constructor” 57 Capítulo 4 Figura 19. Diagrama de Actividad del Método R3: “Crear constructor” (parte 2) 4.4.4 Método de reestructura R5: “Reubicar atributos” El método R5 es utilizado por los métodos R9: "Reubicar funciones especializadas" y R10: "Fragmentar funciones no especializadas" para hacer la reubicación de atributos de una clase a otra o para reubicar los atributos a los que acceden las funciones reubicadas. Este método utiliza la tabla “Variables MVA” la cual se describe a continuación: Campo Identificador Tipo Especificador Valor Función Tabla 8. Descripción de la tabla Variables MVA Variables MVA Descripción Identificador de la variable a reubicar. Tipo de la variable. Especificador de acceso de la variable. Valor contenido en la variable. Firma de la función de donde se accede a la variable. El proceso seguido para ejecutar este método se muestra en la Figura 20. 58 Modelo Conceptual del Sistema Figura 20. Diagrama de Actividad del Método R5: “Reubicar atributos” Los pasos que se siguen durante este método se encuentran definidos en el Anexo A. 59 Capítulo 4 4.4.5 Método de reestructura R4: “Crear funciones” El método R4 es utilizado por el método R10: "Fragmentar funciones no especializadas" con el objetivo de crear nuevas funciones en las que se reubican los estatutos de código que pertenecen a la Vista y/o al Adaptador. Este método inserta información en la tabla “Funciones concretas MVA”. Los pasos de este método se encuentran en el Anexo A. Y el proceso de este método se muestra en el diagrama de actividad representado en la Figura 21 y Figura 22. 60 Modelo Conceptual del Sistema Figura 21. Diagrama de Actividad del Método R4: “Crear funciones” 61 Capítulo 4 Figura 22. Diagrama de Actividad del Método R4: “Crear funciones” (parte 2) 62 Implementación del Sistema Capítulo 5. Implementación del Sistema Una vez definido el proceso de refactorización, el siguiente paso fue el diseño e implementación del sistema. En este capítulo se describe la implementación de seis de los once métodos que conforman el proceso de refactorización. Se presentan los diagramas de clases y paquetes utilizados. Se especifican los criterios utilizados para realizar la etiquetación de código y las herramientas externas utilizadas para la implementación del sistema. 5.1 Implementación del proceso de refactorización en la herramienta MOO2MVA La herramienta elaborada para la implementación del proceso de refactorización de MOO hacia una arquitectura MVA fue denominada MOO2MVA y a continuación, en la Figura 23 se describe su arquitectura general. 63 Capítulo 5 Figura 23. Diagrama general de la herramienta MOO2MVA Como se puede observar la arquitectura general de la herramienta se diseñó siguiendo la arquitectura del patrón MVA, en la cual el paquete llamado InterfazGrafica contiene los elementos relacionados con la vista de la aplicación. El paquete Adaptador contiene la clase que funciona como intermediaria entre la vista y el modelo. El modelo de la aplicación se encuentra contenido en el paquete MOO2MVA el cual contiene la lógica del negocio, que en este caso son los métodos y el proceso de refactorización. 5.1.1 Paquete InterfazGrafica En la Figura 24 se muestran las clases que conforman al paquete InterfazGrafica, dicho paquete consta únicamente de 4 clases. La clase IGUMOO2MVA es la encargada de crear la ventana que se presenta para interactuar con el usuario de la aplicación. Las clases JavaFilter y Utils son utilizadas para validar que los archivos introducidos por el usuario sean archivos con extensión *.java. Y la clase ControladorEventos que implementa a la interfaz ActionListener es la encargada de indicar las actividades a ejecutarse por parte de la aplicación ante la interacción del usuario, por ejemplo, cuando éste da clic en algún botón qué método del adaptador debe ser invocado. 64 Implementación del Sistema class InterfazGrafica JFrame ActionListener IGUMOO2MVA + + + + + + + + + + + + + + + + + + + + ControladorEv entos bAbrir: JButton bAgregarClase: JButton bEstablecer: JButton bIniciar: JButton ~ventana bSeleccionar: JButton jfcSeleccionarEntrada: JFileChooser jfcSeleccionarSalida: JFileChooser jLabel1: JLabel jLabel2: JLabel jPanel1: JPanel jPanel2: JPanel jPanel3: JPanel jPanel4: JPanel jPanel5: JPanel jRutaEntrada: JTextField jRutaSalida: JTextField jTextArea1: JTextArea jTextArea2: JTextArea jTextArea3: JTextArea jTextArea4: JTextArea ~ ~ ~ ~ ~ ~ ~ ~ ~ carpetaSalida: String directorioEntrada: File directorioSalida: File listaArchivosJ: LinkedList<File> = null listaArchivosJava: LinkedList<File> = new LinkedList<... listaDirectorios: LinkedList<File> = new LinkedList<... listaDirectoriosVisitados: LinkedList<File> = new LinkedList<... ma: OrquestadorAplicacion = new Orquestador... ventana: IGUMOO2MVA + + # actionPerformed(ActionEvent) : void ControladorEventos(IGUMOO2MVA) verificarArchivos(File, JTextArea) : LinkedList<File> + + IGUMOO2MVA() initComponents() : void main(String[]) : void + + Utils FileFilter Jav aFilter accept(File) : boolean getDescription() : String + java: String = "java" {readOnly} # + createImageIcon(String) : ImageIcon getExtension(File) : String Figura 24. Diagrama de clases del paquete InterfazGrafica 5.1.2 Paquete Adaptador Este paquete consta de una única clase la cual contiene el método que orquesta a la aplicación en general; en él se establece el orden en que son ejecutadas las actividades del proceso de refactorización. La Figura 25 muestra este paquete. class Adaptador OrquestadorAplicacion + orquestarAplicacion(LinkedList<File>, File) : String Figura 25. Diagrama de clases del paquete Adaptador 5.1.3 Paquete MOO2MVA El paquete MOO2MVA contiene la lógica del negocio de la aplicación, en él se encuentran contenidas las clases que hacen posible la implementación de los métodos que conforman el proceso de refactorización. Dentro de este paquete se crearon tres subpaquetes: A1Analizar, A2Refactorizar y baseDatos. El subpaquete A1Analizar contiene a las clases necesarias para la implementación del método R1: “Analizar código legado”. El subpaquete A2Refactorizar contiene las clases que 65 Capítulo 5 implementan a los métodos R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”. Y el subpaquete baseDatos contiene las clases utilizadas para realizar las conexiones a la base de datos y para leer y escribir en ella. En la Figura 26 que se muestra a continuación se representa la arquitectura del paquete MOO2MVA. Figura 26. Diagrama de clases del paquete MOO2MVA 5.1.3.1 Subpaquete baseDatos El paquete baseDatos es un subpaquete del paquete MOO2MVA. En este subpaquete se encuentran contenidas las clases que permiten realizar la conexión con la base de datos llamada “BD_MOO2MVA” la cual fue implementada en el motor de base de datos MySql en su versión 5.5. Para realizar las conexiones a la base de datos se utiliza la clase llamada ConectorBD, además, cada tabla contenida en la base de datos tiene una clase que la representa dentro de este paquete, esto con el objetivo de facilitar las búsquedas de elementos y evitar tener abierta la conexión a la base de datos todo el tiempo. La estructura del subpaquete baseDatos se muestra a continuación en la Figura 27. 66 Implementación del Sistema class baseDatos ClaseAdaptador - TipoClase bd: ConectorBD Clase_Base1: String Clase_Base2: String id: String Nombre: String Tipo: String Tipo_Relacion1: String Tipo_Relacion2: String Runnable ConnectionPool ClaseModelo - bd: ConectorBD Clase_Base1: String Clase_Base2: String id: String Nombre: String Tipo: String Tipo_Relacion1: String Tipo_Relacion2: String - bd: ConectorBD Clase_Base1: String Clase_Base2: String id: String Nombre: String Tipo: String Tipo_Relacion1: String Tipo_Relacion2: String ClaseVista - m_AvailableConnections: Vector = new Vector() m_CleanupThread: Thread = null m_InitialConnectionCount: int = 5 m_Password: String = null m_URLString: String = null m_UsedConnections: Vector = new Vector() m_UserName: String = null + + + + + + availableCount() : int cerrarConexiones() : void checkin(Connection) : void checkout() : Connection ConnectionPool(String, String, String) getConnection() : Connection run() : void - bd: ConectorBD Clase_Base1: String Clase_Base2: String id: String Nombre: String Paquete: String Patron_MVC: String Tipo: String Tipo_Relacion1: String Tipo_Relacion2: String VariableMVA - bd: ConectorBD Clase: String Especificador: String Funcion: String id: String Identificador: String Tipo: String Valor: String - bd: ConectorBD Clase_Funcion: String Clase_Variable: String Especificador: String FirmaFuncion: String id: String Identificador: String Tipo: String - bd: ConectorBD Clase: String Especificador: String Firma: String id: String Patron_MVC: String Tipo_Retorno: String Variable_Retorno: String -cp EstatutoBloque - bd: ConectorBD clase: String firmaFuncion: String id: String noLineaFin: String noLineaInicio: String patronMVC: String tipoEstatutoBloque: String EstatutoLinea - bd: ConectorBD clase: String Estatuto: String firmaFuncion: String id: String noLinea: String patronMVC: String ConectorBD + -bd + + + + + + + + + + + + + cp: ConnectionPool = null driver: String nombreBD: String password: String url: String usuario: String close() : void ConectorBD(String, String, String, String, String) -bd execute(String) : ResultSet getDriver() : String getNombreBD() : String getPassword() : String getUrl() : String getUsuario() : String setDriver(String) : void setNombreBD(String) : void setPassword(String) : void setUrl(String) : void setUsuario(String) : void update(String) : int -bd TipoVariable FuncionConcreta FuncionConcretaMVA - bd: ConectorBD Clase: String Especificador: String Firma: String id: String Patron_MVC: String Tipo_Retorno: String ClasesVistaUI - bd: ConectorBD clase: String id: String paquete: String JerarquiaClase - FuncionAbstracta FuncionAbstractaMVA - bd: ConectorBD Clase: String Especificador: String Firma: String id: String Patron_MVC: String Tipo_Retorno: String - bd: ConectorBD Clase: String Especificador: String Firma: String id: String Patron_MVC: String Tipo_Retorno: String bd: ConectorBD ClaseHija: String ClasePadre: String id: String Figura 27. Diagrama de clases del paquete MOO2MVA.baseDatos 67 Capítulo 5 5.2 Implementación de la actividad A1. Analizar el código del MOO Para la implementación de la actividad A1 en la que se analiza el código del MOO original y se etiquetan los estatutos, funciones y clases de acuerdo a las partes del patrón MVA a las que pertenecen, se diseñó la arquitectura mostrada en la Figura 28 la cual corresponde al paquete MOO2MVA.A1Analizar. Figura 28. Diagrama de clases del paquete MOO2MVA.A1.Analizar Esta actividad está conformada únicamente por el método R1: “Analizar código legado” y de manera general se puede describir el funcionamiento de éste de la siguiente manera: su entrada son las clases de Java del MOO a refactorizar; el método recibe dichas clases, las analiza y realiza la etiquetación de sus estatutos de acuerdo a la parte del patrón MVA a la que pertenecen; se almacena la información de sus variables de clase, métodos y de la clase; su salida, además de la información almacenada en la base de datos, son clases de Java etiquetadas, las cuales conservan el mismo código que las clases de entrada. Este método podría considerarse como la base para la refactorización del código legado, su importancia radica en que los métodos posteriores basan su funcionamiento en la etiquetación 68 Implementación del Sistema de código y en la información almacenada en la base de datos resultante de la ejecución de este método. 5.2.1 Implementación del método R1: “Analizar código legado” Debido a que para conseguir el objetivo del método R1 fue necesario elaborar un traductor de código Java a código Java, en la implementación de esta parte de la herramienta se utilizó el generador de analizadores sintácticos ANTLR (ANother Tool for Language Recognition) [ANTL,10] en su versión 3, el cual es un sofisticado generador de analizadores sintácticos que puede utilizarse para implementar interpretadores, compiladores y otros traductores [PARR,07]. Cuando se construyen traductores en ANTLR generalmente se envía un Árbol de Sintaxis Abstracta (AST) entre las fases del traductor. Las fases posteriores a la construcción del AST, son recorredores de árboles. Las fases subsecuentes pueden alterar o extraer información del AST. Por ejemplo, la primera fase puede agregar la información sobre la definición de variables y métodos en una tabla de símbolos. La siguiente fase puede alterar el AST para que los nodos creados para una variable o método referencien a su símbolo en la tabla de símbolos. La fase final normalmente emite salidas usando la información recolectada durante las fases anteriores [PARR,07]. Un enfoque parecido al descrito anteriormente se utilizó para la implementación del método R1. En una primera iteración se genera la tabla de símbolos de todos los archivos java que conforman el MOO y en una segunda iteración se utiliza la tabla de símbolos para que los nodos hagan referencia a su símbolo en la tabla de símbolos, y en base a la información contenida en la tabla se etiqueta el código del MOO. A continuación se describe dicho proceso. 1. Generación de la tabla de símbolos Las gramáticas del lenguaje java utilizadas para esta implementación se encuentran en la Lista de Gramáticas para ANTLR en [ANTL,09]. Se utilizaron dos gramáticas elaboradas por Dieter Habelitz, las cuales están disponibles en http://www.antlr.org/grammar/1207932239307/Java1_5Grammars. La primera gramática Java.g es una gramática cuya salida es un AST y la gramática JavaTreeParser.g es un “tree walker” recorredor de árbol de ese AST. Con el objetivo de adaptarlas a esta implementación se renombraron dichas gramáticas. La gramática Java.g se convirtió en la gramática LenguajeJava.g y la gramática JavaTreeParser.g en ReconocedorSimbolos.g, la interacción de estos archivos se muestra en la Figura 29. Figura 29. Proceso de obtención de la tabla de símbolos 69 Capítulo 5 Como se puede observar, el primer paso es la introducción del código java en LenguajeJavaLexer cuya salida son tokens, los cuales son analizados por LenguajeJavaParser, si no se presentan errores de sintaxis, la salida obtenida de LenguajeJavaParser es un AST que es analizado por ReconocedorSimbolos que contiene las acciones semánticas para generar la tabla de símbolos. Es importante señalar que para generar la tabla de símbolos fue necesario extender la clase CommonTree del ANTLR y crear la clase SLAST, esto debido a que la clase CommonTree permite almacenar cierta información básica para los nodos del AST y para esta implementación era necesario que almacenara información adicional para cada nodo, dicha información es el ámbito de cada símbolo, el símbolo y la parte del patrón MVA a la que pertenece. Al registrar cada variable en la tabla de símbolos se guarda también la parte del patrón MVA a la que pertenece. Para determinar esto se utilizan los siguientes criterios: Elementos de la vista: Debido a que en java los paquetes de clases AWT y SWING permiten la creación y manipulación de las interfaces gráficas de usuario, y que el paquete java.io permite la interacción a través de la línea de comandos; si la variable analizada es de algún tipo que pertenece a las librerías java.awt, java.swing o java.io dicha variable es asignada a la Vista. Elementos del modelo: Si la variable analizada es de tipo primitivo o de algún paquete de clases que no sea awt, swing o io, tal variable es asignada al Modelo. Elementos del control o adaptador: Debido a que en el presente trabajo se está utilizando el patrón MVC en su variante MVA, no se considera que existan variables pertenecientes al Adaptador, sino que esta capa será construida utilizando los métodos posteriores para conseguir la interacción entre la Vista y el Modelo La arquitectura de clases utilizada para la Tabla de Símbolos se muestra más adelante en la Figura 31. 2. Utilización de la tabla de símbolos para la etiquetación de código Una vez obtenida la tabla de símbolos se vuelve a analizar el código de las clases del MOO para, basándose en la información almacenada en la tabla, etiquetar los estatutos, funciones y clases. Son utilizados nuevamente los Lexer y Parser de la gramática LenguajeJava y se crea un nuevo recorredor de árbol llamado Etiquetador, el cual contiene las acciones semánticas necesarias para obtener la información de la tabla de símbolos, etiquetar el código y almacenar la información de variables, funciones y clases en la base de datos. El proceso se muestra en la Figura 30 a continuación. 70 Implementación del Sistema Figura 30. Proceso de etiquetación utilizando la tabla de símbolos Para la etiquetación de los estatutos de código se utilizan los siguientes criterios: Estatutos de la vista: Si el estatuto analizado contiene alguna variable perteneciente a la vista o presenta alguna interacción con el usuario utilizando System.out, System.err o System.in, dicho estatuto es etiquetado como de la Vista. Estatutos del modelo: Si el estatuto analizado sólo contiene variables pertenecientes al modelo el estatuto es etiquetado como parte del Modelo. Estatutos del control o adaptador: Como no se considera que existan variables pertenecientes al Control o Adaptador, tampoco se etiquetan estatutos del Control o del Adaptador. Para la etiquetación de funciones y clases se sigue el proceso descrito en el método R1 presentado en el capítulo anterior. 71 Capítulo 5 class TablaSimbolos CommonTree SLAST +scope Simbolo + + + patronMVC: String scope: Ambito symbol: Simbolo + + + + + dupNode() : Tree SLAST() SLAST(Token) SLAST(SLAST) SLAST(Token, Ambito, Simbolo) #definicion # # +symbol # # # SLASTCommonErrorNode + + + + input: IntStream start: Token stop: Token trappedException: RecognitionException + + + + + getText() : String getType() : int isNil() : boolean SLASTCommonErrorNode(TokenStream, Token, Token, RecognitionException) toString() : String #tipo «interface» Tipo SimboloVariable + getNombreTipo() : String SimboloUDT ~ nombreClaseExterna: String + + + + + + getNombreSimbolo() : String setAmbitoContenedor(Ambito) : void setNombreSimbolo(String) : void SimboloVariable(String) SimboloVariable(String, Tipo) SimboloVariable(String, Tipo, String) + + + + + getNombreTipo() : String setAmbitoContenedor(Ambito) : void setNombreSimbolo(String) : void SimboloUDT() SimboloUDT(String) + + + + + + + + + + + + + + getNombreTipo() : String SimboloPrimitivo() SimboloPrimitivo(String) CommonTreeAdaptor SLASTCommonTreeAdaptor + + + #ambitoEnvolvente getAmbitoContenedor() : Ambito getAmbitoEnvolvente() : Ambito getDefinicion() : SLAST getEspecificador() : String getNombreSimbolo() : String getTipo() : Tipo setAmbitoEnvolvente(Ambito) : void setDefinicion(SLAST) : void setEspecificador(String) : void setTipo(Tipo) : void Simbolo() Simbolo(String) Simbolo(String, Tipo) Simbolo(String, Tipo, String) SimboloPrimitiv o + + + «interface» Ambito ambitoEnvolvente: Ambito definicion: SLAST especificador: String nombreSimbolo: String tipo: Tipo ~ + + + + + + + + + + + + + + + + + + + + + + agregarSimbolo(String, Simbolo) : Simbolo buscarSimbolo(String) : Object getAmbitoEnvolvente() : Ambito getAmbitosPadre() : LinkedList <AmbitoBase> getMiembros() : Map getNombreAmbito() : String removerSimbolo(String) : String setNombreAmbito(String) : void AmbitoBase # # # # + + + + ~ambitoActual + + + + + + SimboloConAmbito + ambitoActual: AmbitoBase + + agregarSimbolo(String, Simbolo) : Simbolo + buscarSimbolo(String) : Object + getAmbitoActual() : AmbitoBase + getAmbitoEnvolvente() : Ambito + getAmbitosPadre() : LinkedList<AmbitoBase> + getMiembros() : Map getNombreAmbito() : String removerSimbolo(String) : String setAmbitoActual(AmbitoBase) : void setAmbitoContenedor(Ambito) : void setNombreAmbito(String) : void setNombreSimbolo(String) : void SimboloConAmbito() SimboloConAmbito(AmbitoBase) create(Token) : Object dupNode(Object) : Object errorNode(TokenStream, Token, Token, RecognitionException) : Object ambitoEnvolvente: AmbitoBase = null ambitoPadre: LinkedList<AmbitoBase> = new LinkedList<... nombreAmbito: String = "" simbolos: Map = new HashMap() agregarAmbitoBloque(String, Ambito) : Ambito agregarSimbolo(String, Simbolo) : Simbolo AmbitoBase() AmbitoBase(String, AmbitoBase) buscarEnPadre(String) : Object buscarEnTodo(AmbitoBase, String) : Object buscarSimbolo(String) : Object getAmbitoActual() : Ambito getAmbitoEnvolvente() : AmbitoBase getAmbitosPadre() : LinkedList<AmbitoBase> getMiembros() : Map getNombreAmbito() : String getSimbolos() : Map removerSimbolo(String) : String setAmbitoEnvolvente(AmbitoBase) : void setAmbitoPadre(AmbitoBase) : void setNombreAmbito(String) : void setSimbolos(Map) : void + SimboloClase + + getNombreTipo() : String SimboloClase(String, AmbitoBase, String) AmbitoGlobal AmbitoGlobal(String) SimboloMetodo + SimboloMetodo(String, AmbitoBase, Tipo, String) Figura 31. Diagrama de clases del paquete MOO2MVA.A1.Analizar.TablaSímbolos 72 AmbitoLocal + AmbitoLocal(String, AmbitoBase) Implementación del Sistema 5.3 Implementación de la actividad A2. Reestructurar el código legado. Para la implementación de la actividad A2. “Reestructurar el código legado”, se creó un paquete llamado MOO2MVA.A2Refactorizar en el cual se encuentra contenida una clase para cada método que participa en la actividad A2. Estos métodos son: R2: “Crear clases” R3: “Crear constructor” R4: “Crear funciones” R5: “Reubicar atributos” R6: “Reestructurar clases” R7: “Estructura jerárquica de clases” R8: “Coordinador de la creación de clases” R9: "Reubicar funciones especializadas" R10: "Fragmentar funciones no especializadas" R11: "Redefinir llamadas a funciones" Debido a limitaciones de tiempo y a que algunos de los métodos se encuentran en etapa de refinamiento, no fue posible implementar todos los métodos que conforman esta actividad, los métodos que sí fueron implementados son los siguientes: El método R2: “Crear clases” fue implementado en la clase R2CrearClases. El método R3: “Crear constructor” se implementó en la clase R3CrearConstructor. El método R4: “Crear funciones” se implementó en la clase R4CrearFunciones. El método R5: “Reubicar atributos” fue implementado en la clase R5ReubicarAtributos El método R7: “Estructura jerárquica de clases” se implementó en la R7EstructurarJerarquiaClases clase El diagrama de este paquete se presenta a continuación en la Figura 32. 73 Capítulo 5 Figura 32. Diagrama de clases del paquete MOO2MVA.A2.Refactorizar 74 Pruebas del Sistema Capítulo 6. Pruebas del Sistema En este capítulo se describe el plan de pruebas utilizado para probar los métodos implementados en la herramienta MOO2MVA. El plan de pruebas está basado en el estándar para pruebas de software 829-1998 del Instituto de Ingenieros Electricos y Electrónicos (IEEE por sus siglas en inglés) [SOFT,98]. Las pruebas se realizaron probando cada uno de los métodos implementados; y sólo las pruebas del método R7: “Estructura jerárquica de clases” dependen de las salidas obtenidas al probar el método R1: “Analizar código legado”, los demás métodos fueron probados cada uno por separado. El objetivo de las pruebas fue demostrar que los métodos implementados R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases” funcionan correctamente. 6.1 Identificador del Plan de Pruebas El código de identificación para la ejecución del plan de pruebas se presenta a continuación y se establece para todo el proceso de evaluación de la herramienta de refactorización MOO2MVA. 75 Capítulo 6 6.2 Documentación de Prueba La documentación utilizada en el plan de pruebas se resume en la siguiente tabla. Tabla 9. Documentos del plan de pruebas Documentos del plan de pruebas Tipo Descripción MOO2MVA-PP-XX Plan de pruebas. MOO2MVA-DP-XX Especificación de diseño de las pruebas. MOO2MVA-CP-XX Especificación de los casos de pruebas. 6.3 Descripción del Plan de Pruebas 6.3.1 Plan de pruebas para MOO2MVA 6.3.1.1 Elementos de prueba El conjunto de casos de prueba que se describe tiene como objetivo verificar y validar el correcto funcionamiento de los métodos de reestructura R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”; los cuales colaboran en la refactorización de MOO a una arquitectura MVA. Los elementos para realizar las pruebas son: a) Archivos con clases Java que pertenecen a un MOO. Las clases utilizadas se describen en la Tabla 10. 76 Pruebas del Sistema Tabla 10. Clases de Java a usarse como elementos de prueba Clases Java ID CJ01 CJ02 CJ03 CJ04 CJ05 CJ06 CJ07 CJ08 CJ09 CJ10 CJ11 CJ12 CJ13 CJ14 CJ15 CJ16 CJ17 CJ18 CJ19 CJ20 CJ21 CJ22 CJ23 CJ24 CJ25 CJ26 CJ27 CJ28 CJ29 CJ30 CJ31 CJ32 CJ33 CJ34 CJ35 CJ36 CJ37 CJ38 CJ39 CJ40 CJ41 CJ42 CJ43 CJ44 Nombre de la clase aConicas.java aCuadrilateros.java aCuerpo.java aCurvos.java aElemGeometrico.java aFigura.java aParalelogramos.java aPiramides.java aPoliedros.java aPoliedrosIrregulares.java aPoliedrosRegulares.java aPoligonos.java aPrismas.java aTrapecios.java aTriangulos.java cCilindro.java cCirculo.java cCono.java cCuadrado.java cCubo.java cDecagono.java cDodecaedro.java cElipse.java cEneagono.java cEsfera.java cHeptagono.java cHexagono.java cIcosaedro.java cOctaedro.java cOctagono.java cPentagono.java cPiramides.java cPrismas.java cRectangulo.java cRombo.java cRomboide.java cTetraedro.java cTrapecio.java cTrapecioIsosceles.java cTrapecioRectangulo.java cTrapezoide.java cTrianguloEquilatero.java cTrianguloEscaleno.java cTrianguloIsosceles.java Descripción Clase abstracta referente a las figuras cónicas. Clase abstracta referente a los cuadriláteros. Clase abstracta referente a los cuerpos. Clase abstracta referente a los cuerpos curvos. Clase abstracta referente a los elementos geométricos. Clase abstracta referente a las figuras. Clase abstracta referente a los paralelogramos. Clase abstracta referente a las pirámides. Clase abstracta referente a los poliedros. Clase abstracta referente a los poliedros irregulares. Clase abstracta referente a los poliedros regulares. Clase abstracta referente a los polígonos. Clase abstracta referente a los prismas. Clase abstracta referente a los trapecios. Clase abstracta referente a los triángulos. Clase concreta referente a los cilindros. Clase concreta referente a los círculos. Clase concreta referente a los conos. Clase concreta referente a los cuadrados. Clase concreta referente a los cubos. Clase concreta referente a los decágonos. Clase concreta referente a los dodecaedros. Clase concreta referente a los eclipses. Clase concreta referente a los eneágonos. Clase concreta referente a las esferas. Clase concreta referente a los heptágonos. Clase concreta referente a los hexágonos. Clase concreta referente a los icosaedros. Clase concreta referente a los octaedros. Clase concreta referente a los octágonos. Clase concreta referente a los pentágonos. Clase concreta referente a las pirámides. Clase concreta referente a los prismas. Clase concreta referente a los rectángulos. Clase concreta referente a los rombos. Clase concreta referente a los romboides. Clase concreta referente a los cilindros. Clase concreta referente a los trapecios. Clase concreta referente a los trapecios isósceles. Clase concreta referente a los trapecios rectángulos. Clase concreta referente a los trapezoides. Clase concreta referente a los triángulos equiláteros. Clase concreta referente a los triángulos escalenos. Clase concreta referente a los triángulos isósceles. 77 Capítulo 6 Las clases presentadas anteriormente constituyen el MOO de Figuras Geométricas y su diagrama de clases se muestra a continuación en la Figura 33. Figura 33. Diagrama de clases del MOO Figuras Geométricas 6.3.1.2 Características a ser probadas Las características a ser probadas son: 1. Funcionamiento del método R1: “Analizar código legado” al etiquetar código de acuerdo al patrón MVA y al almacenar información sobre las funciones y clases en las tablas “Tipos de Clases”, “Tipos de variable”, “Funciones abstractas” y “Funciones concretas”. 78 Pruebas del Sistema 2. Obtención de la estructura jerárquica de clases utilizando el método R7: “Estructura jerárquica de clases”, almacenando correctamente la información en la tabla “Jerarquía de Clases”. 3. Creación de clases utilizando el método R2: “Crear clases”. 4. Creación de constructores utilizando el método R3: “Crear constructor”. 5. Reubicación de atributos utilizando el método R5: “Reubicar atributos”. 6. Creación de funciones y almacenamiento correcto de la información en la tabla “Funciones concretas MVA” al utilizar el método R4: “Crear funciones”. 6.3.1.3 Características que no se probarán A continuación se describen las actividades que no serán probadas: 1. La completa refactorización del MOO hacia una arquitectura MVA. 2. El tiempo de duración de la prueba. 6.3.1.4 Enfoque El enfoque utilizado en este plan de pruebas se centra en los resultados de cada método (R1, R2, R3, R4, R5 y R7). Se utiliza un enfoque de prueba de caja negra, el cual se centra en lo que se espera de cada método, y se intentan encontrar casos en los que el método no cumpla con su especificación. Las pruebas con un enfoque de caja negra también son denominadas pruebas funcionales, en las que se introducen datos de entrada y se estudia la salida. 6.3.1.5 Criterio aceptado no aceptado Se considera que un caso de prueba tiene éxito cuando los resultados esperados coinciden con los descritos en el caso de prueba. De lo contrario se determinará si se debe continuar con los casos de prueba o finalizar la validación. 6.3.1.6 Criterios de suspensión y criterios de reanudación Las pruebas se suspenderán temporalmente cuando al menos una de ellas no sea aceptada, inmediatamente se evaluará y corregirá el error. Una vez corregido el error se reanudarán las pruebas y el caso de prueba pasará el criterio de aceptación. 6.3.1.7 Liberación de pruebas Para aceptar y finalizar las pruebas se debe tener que todas las salidas de la ejecución de los métodos (R1, R2, R3, R4, R5, y R7) coincidan con las salidas esperadas para cada caso de prueba. 6.3.1.8 Requisitos ambientales Las características físicas y lógicas necesarias para el entorno de pruebas son las siguientes: Hardware Procesador Core i7 o superior. 2 GB de memoria RAM o superior. 79 Capítulo 6 Mouse Teclado Sistema Operativo Windows 7 Service pack 1 Herramientas MySql Server 5.5.16 Máquina Virtual de Java: jdk1.6.0_07 o superior Entorno de Desarrollo para Java, Netbeans 7.0.1 u otro. Programas de prueba Clases de Java del MOO a probar. 6.3.1.9 Responsabilidades La persona responsable de administrar, diseñar, preparar y ejecutar las pruebas es la Ing. Luz Christina Gaitán Torres, quien se encargará de ingresar el código java del MOO y comparar los resultados obtenidos con los esperados en cada caso de prueba. 6.3.1.10 Riesgos A continuación se presentan los posibles riesgos para la ejecución del presente plan de pruebas: La no disponibilidad del ambiente para la ejecución de pruebas. Pérdida de tiempo en la generación de los casos de prueba. No contemplar algunos aspectos de importancia durante el diseño de los casos de prueba. Pérdida de tiempo al ejecutar un caso de prueba incorrecto. Pérdida de tiempo al corregir errores. 6.3.1.11 Aprobación El plan de pruebas debe ser aprobado por el Dr. René Santaolaya Salgado y la M.C. Olivia Graciela Fragoso Díaz. 6.4 Especificación del Diseño de Pruebas Propósito En esta sección se describe el diseño de pruebas para probar los métodos, R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”. 6.4.1 80 MOO2MVA-DP-01 Pruebas del Sistema Diseño de prueba para el método R1: “Analizar código legado” al etiquetar código de acuerdo al patrón MVA y al almacenar información sobre las variables, funciones y clases en las tablas correspondientes a) Características a ser probadas Esta prueba tiene como característica la siguiente: 1. Funcionamiento del método R1: “Analizar código legado” al etiquetar código de acuerdo al patrón MVA y al almacenar información sobre las funciones y clases en las tablas “Tipos de Clases”, “Tipos de variable”, “Funciones abstractas” y “Funciones concretas”. b) Refinamiento del enfoque El objetivo es probar que el código del MOO es etiquetado correctamente generando nuevos archivos java con el mismo código y con la etiquetación como comentario; que la información sobre de las clases es extraída y almacenada correctamente en la tabla “Tipos de clases”; que la información sobre las funciones abstractas es extraída y almacenada correctamente en la tabla “Funciones abstractas”; que la información sobre las funciones concretas es extraída y almacenada correctamente en la tabla “Funciones concretas”; y que la información sobre las variables de clase es extraída y almacenada correctamente en la tabla “Tipos de variable”. c) Identificación de las pruebas MOO2MVA-CP-01 d) Características de criterio de aceptación/rechazo Para el criterio de aceptación o rechazo, se debe realizar la evaluación visual del código generado a partir de la etiquetación para comprobar que fue etiquetado correctamente. Además, se deben revisar las tablas “Tipos de Clases”, “Tipos de variable”, “Funciones abstractas” y “Funciones concretas” y comparar su contenido con el contenido de los archivos analizados. Si la etiquetación se realizó correctamente y las tablas contienen la información correcta, entonces se considerará que la prueba es aceptada. En caso contrario, la prueba será rechazada. 6.4.2 MOO2MVA-DP-02 Diseño de prueba para la obtención de la estructura jerárquica de clases utilizando el método R7: “Estructura jerárquica de clases”, almacenando correctamente la información en la tabla correspondiente a) Características a ser probadas Esta prueba tiene como característica la siguiente: 81 Capítulo 6 2. Obtención de la estructura jerárquica de clases utilizando el método R7: “Estructura jerárquica de clases”, almacenando correctamente la información en la tabla “Jerarquía de Clases”. b) Refinamiento del enfoque El objetivo es probar que, a partir de la información almacenada en la tabla “Tipos de Clases”, se obtiene la jerarquía de clases y se almacena dicha arquitectura en la tabla “Jerarquía de clases” correctamente. c) Identificación de las pruebas MOO2MVA-CP-02 d) Características de criterio de aceptación/rechazo Para el criterio de aceptación o rechazo, se debe realizar la comparación visual de la información contenida en la tabla “Jerarquía de clases” con las relaciones de herencia o implementación que mantienen las clases analizadas. Si la información contenida en la tabla “Jerarquía de Clases” es correcta, entonces se considera que la prueba es aceptada. En caso contrario, la prueba será rechazada. 6.4.3 MOO2MVA-DP-03 Diseño de prueba para la creación de clases utilizando el método R2: “Crear clases” a) Características a ser probadas Esta prueba tiene como característica la siguiente: 3. Creación de clases utilizando el método R2: “Crear clases”. b) Refinamiento del enfoque El objetivo es probar que las clases se crean correctamente de acuerdo a lo que establece el método “R2: Crear clases”, que los archivos generados no contengan errores de sintaxis y que, cuando son solicitadas, presentan las relaciones de herencia o implementación correctamente establecidas. c) Identificación de las pruebas MOO2MVA-CP-03 d) Características de criterio de aceptación/rechazo Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual para comprobar que las clases son creadas correctamente y se debe utilizar un editor de código Java con detección de errores de sintaxis para comprobar que ninguno está presente. Si el código y el archivo fueron creados correctamente, entonces se considera que la prueba ha sido aceptada. De lo contrario, la prueba será rechazada. 82 Pruebas del Sistema 6.4.4 MOO2MVA-DP-04 Diseño de prueba para la creación de constructores utilizando el método R3: “Crear constructor” a) Características a ser probadas Esta prueba tiene como característica la siguiente: 4. Creación de constructores utilizando el método R3: “Crear constructor”. b) Refinamiento del enfoque El objetivo es probar que los constructores son creados correctamente de acuerdo a lo que establece el método “R3: Crear constructor” y que no presentan errores de sintaxis. c) Identificación de las pruebas MOO2MVA-CP-04 d) Características de criterio de aceptación/rechazo Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual para comprobar que los constructores son creados correctamente, se debe utilizar un editor de código Java con detección de errores de sintaxis para comprobar que ninguno está presente en el código generado. Si el código fue creado correctamente en el archivo especificado, entonces se considera que la prueba es aceptada. De lo contrario, la prueba será rechazada. 6.4.5 MOO2MVA-DP-05 Diseño de prueba para la reubicación de atributos utilizando el método R5: “Reubicar atributos” a) Características a ser probadas Esta prueba tiene como característica la siguiente: 5. Reubicación de atributos utilizando el método R5: “Reubicar atributos”. b) Refinamiento del enfoque El objetivo es probar que los atributos son reubicados correctamente, en la clase establecida, de acuerdo a lo que establece el método “R5: Reubicar atributos”; y que no se presentan errores de sintaxis. c) Identificación de las pruebas MOO2MVA-CP-05 d) Características de criterio de aceptación/rechazo Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual para comprobar que los atributos son reubicados correctamente. Si el atributo fue reubicado 83 Capítulo 6 correctamente, en la clase establecida, entonces se considera que la prueba ha sido exitosa. De lo contrario, la prueba será rechazada. 6.4.6 MOO2MVA-DP-06 Diseño de prueba para la creación de funciones y almacenamiento correcto de la información en la tabla correspondiente al utilizar el método R4: “Crear funciones” a) Características a ser probadas Esta prueba tiene como característica la siguiente: 6. Creación de funciones y almacenamiento correcto de la información en la tabla “Funciones concretas MVA” al utilizar el método R4: “Crear funciones”. b) Refinamiento del enfoque El objetivo es probar que las funciones son creadas correctamente de acuerdo a lo establecido en el método “R4: Crear funciones”, que no se presentan errores de sintaxis; y que se almacena de manera correcta la información sobre la nueva función en la tabla “Funciones concretas MVA”. c) Identificación de las pruebas MOO2MVA-CP-06 d) Características de criterio de aceptación/rechazo Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual para comprobar que las funciones fueron correctamente; se debe utilizar un editor de código Java con detección de errores de sintaxis para comprobar que ninguno está presente; y comprobar que la información almacenada en la tabla “Funciones concretas MVA” es la correcta. Si la función fue creada correctamente y la información almacenada en la tabla es correcta, entonces se considera que la prueba ha sido exitosa. De lo contrario, la prueba será rechazada. 6.5 Especificación de Casos de Prueba Propósito En esta sección se definen las características y los elementos de prueba requeridos para realizar cada uno de los casos de prueba diseñados para probar el correcto funcionamiento de los métodos R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”. 84 Pruebas del Sistema 6.5.1 MOO2MVA-CP-01 Número/Nombre Prueba: Autor Tipo de prueba Objetivo Condiciones de Ambiente Entrada Resultados Esperados Procedimiento de la Prueba MOO2MVA-CP-01 Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011 Prueba de aceptación. Comprobar que se realiza correctamente la identificación y etiquetación de los estatutos del código legado de acuerdo a su tipo y a la parte del patrón MVA al que pertenecen. Además, comprobar el correcto almacenamiento de la información sobre variables, funciones y clases en las tablas correspondientes. Ninguna. El código del marco orientado a objetos Figuras Geométricas escrito en lenguaje Java (elementos de prueba CJ01- CJ44) Copia del código de un MOO escrito en lenguaje Java etiquetado correctamente de acuerdo a la parte del patrón MVA y a los tipos de estatutos que contiene. 1. Inicio. 2. Se solicita la etiquetación del MOO. 3. Se realiza la copia de los archivos del código del MOO. 4. Se realiza la etiquetación del código del MOO. 5. Se realiza el almacenamiento de la información del MOO en las tablas correspondientes. 6. Fin. Cursos Alternos 3. Ocurre algún error durante la copia de los archivos de código del MOO. 4. La herramienta notifica del error. 5. Fin. 4. Ocurre algún error durante la etiquetación del código del MOO. 5. La herramienta notifica del error. 6. Fin. 5. Ocurre algún error durante el almacenamiento de información en las tablas. 6. La herramienta notifica del error. 7. Fin. Curso alterno 1 Curso alterno 2 Curso alterno 3 Excepciones Si se presenta algún error durante la generación de la copia de los archivos de código del MOO, o la etiquetación, o del almacenamiento de información es las tablas se notifica del error, entonces el caso de prueba termina. Ninguna. Post-condiciones Observaciones 6.5.2 MOO2MVA-CP-02 Número/Nombre Prueba: Autor Tipo de prueba Objetivo MOO2MVA-CP-02 Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011 Prueba de aceptación. Comprobar que se obtiene y almacena correctamente la estructura 85 Capítulo 6 Condiciones de Ambiente Entrada Resultados Esperados Procedimiento de la Prueba jerárquica de las clases del MOO. El caso de prueba MOO2MVA-CP-01 se ha ejecutado con éxito anteriormente. Tabla “Tipos de Clases” con los datos almacenados del MOO Figuras Geométricas. En la tabla “Jerarquía de Clases” se tiene almacenada la información sobre la jerarquía de clases del MOO Figuras Geométricas. 1. Inicio. 2. Se solicita la obtención de la jerarquía de clases del MOO. 3. Se obtiene la jerarquía de clases. 4. Se almacena la información en la tabla. 5. Fin. Cursos Alternos 3. Ocurre algún error durante la obtención de la jerarquía de clases. 4. La herramienta notifica del error. 5. Fin. 4. Ocurre algún error durante el almacenamiento de información en la tabla. 5. La herramienta notifica del error. 6. Fin. Curso alterno 1 Curso alterno 2 Excepciones Si se presenta algún error durante la obtención de la jerarquía de clases o el almacenamiento en la tabla, entonces el caso de prueba termina. Ninguna. Post-condiciones Observaciones 6.5.3 MOO2MVA-CP-03 Número/Nombre Prueba: Autor Tipo de prueba Objetivo Condiciones de Ambiente Entrada Resultados Esperados Procedimiento de la Prueba Curso alterno 1 86 MOO2MVA-CP-03 Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011 Prueba de aceptación. Comprobar que se generaran correctamente clases concretas, abstractas e interfaces de Java. Ninguna. Nombre del paquete, nombre de la clase, tipo de clase, tipo de relación 1, clase base 1, tipo de relación 2 y clase base2. Una clase de Java de acuerdo al tipo de clase solicitada (concreta, abstracta o interfaz) con las relaciones establecidas de acuerdo a lo solicitado. 1. Inicio. 2. Se solicita la generación de la clase. 3. Se genera la clase. 4. Se almacena el archivo generado para su posterior comprobación. 5. Fin Cursos Alternos 3. Ocurre algún error durante la generación de la clase. 4. La herramienta notifica del error. Pruebas del Sistema 5. Fin Post-condiciones Observaciones No. de Instancia Instancia 1 Instancia 2 Instancia 3 Instancia 4 Instancia 5 Instancia 6 Instancia 7 Instancia 8 Instancia 9 6.5.4 Excepciones Si se presenta algún error durante la generación de la clase se notifica del error entonces el caso de prueba termina. Ninguna Instancias de Prueba Valor Resultado Esperado Se solicita la creación de una Clase de Java concreta generada clase concreta. correctamente. Se solicita la creación de una Clase de Java concreta derivada clase concreta derivada de de otra generada correctamente. otra clase. Se solicita la creación de una Clase de Java concreta que clase concreta que implementa una interfaz implementa una interfaz generada correctamente. Se solicita la creación de una Clase de Java concreta derivada clase concreta derivada de de otra e implementa una otra clase y que implementa interfaz generada correctamente. una interfaz. Se solicita la creación de una Clase abstracta de Java generada clase abstracta. correctamente. Se solicita la creación de una Clase abstracta de Java derivada clase abstracta derivada de de una clase generada una clase. correctamente. Se solicita la creación de una Clase abstracta de Java que clase abstracta que implementa una interfaz implementa una interfaz. generada correctamente. Se solicita la creación de una Interfaz de Java generada interfaz. correctamente. Se solicita la creación de una Interfaz de Java que extiende interfaz que extiende a otra otra interfaz generada interfaz. correctamente. MOO2MVA-CP-04 Número/Nombre Prueba: Autor Tipo de prueba Objetivo Condiciones de Ambiente Entrada Resultados Esperados MOO2MVA-CP-04 Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011 Prueba de aceptación. Comprobar que se crean correctamente los constructores con parámetros y sin parámetros. Y que es posible copiar el constructor de una clase en otra. Ninguna Clase de Java en la cual se desea crear el constructor. Si se desea copiar un constructor también es necesario indicar la clase Java desde la cual se copiará. La clase de Java que contendrá el constructor que ha solicitado (con o 87 Capítulo 6 sin parámetros, o copia de otro). 1. Inicio. 2. Se solicita la generación del constructor. 3. Se genera el constructor en la clase especificada. 4. Fin. Procedimiento de la Prueba Cursos Alternos Curso alterno 1 3. Ocurre algún error durante la generación del constructor. 4. La herramienta notifica del error. 5. Fin Post-condiciones Si se presenta algún error durante la generación del constructor el caso de prueba termina. Ninguna Excepciones Observaciones No. de Instancia Instancias de Prueba Valor Instancia 1 Se solicita la creación de un constructor sin parámetros. Instancia 2 Se solicita la creación de un constructor con parámetros. Instancia 2 Se solicita la copia de un constructor. 6.5.5 Resultado Esperado La clase de Java contiene un constructor correcto y sin parámetros. La clase de Java contiene un constructor correcto y con parámetros. La clase de Java contiene una copia del constructor de la clase especificada. MOO2MVA-CP-05 Número/Nombre Prueba: Autor Tipo de prueba Objetivo Condiciones de Ambiente Entrada Resultados Esperados Procedimiento de la Prueba MOO2MVA-CP-05 Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011 Prueba de aceptación. Comprobar que se realiza correctamente la reubicación de atributos. Ninguna. Clase de Java en la cual se desean copiar los atributos y la tabla “Variables MVA” con registros que en la columna “Clase” coincidan con el nombre del archivo java. Código Java con la reubicación de atributos realizada correctamente. 1. Inicio. 2. Se solicita la reubicación de atributos. 3. Se realiza la reubicación de atributos. 4. Fin. Cursos Alternos Curso alterno 1 3. Ocurre algún error durante la reubicación de atributos. 4. La herramienta notifica del error. 5. Fin. Excepciones Post-condiciones 88 Si se presenta algún error durante la reubicación de atributos se notifica del error entonces el caso de prueba termina. Pruebas del Sistema 6.5.6 MOO2MVA-CP-06 Número/Nombre Prueba: Autor Tipo de prueba Objetivo Condiciones de Ambiente Entrada Resultados Esperados Procedimiento de la Prueba MOO2MVA-CP-06 Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011 Prueba de aceptación. Comprobar que se crean correctamente funciones con y sin parámetros. Ninguna. Clase de Java en la cual se desea crear la función firma de la función, especificador de acceso de la función, parte del patrón MVA a la que pertenece la función, el tipo de retorno y en caso de que sea necesario la variable o valor de retorno y un vector con los estatutos de la función. La clase de Java contiene la función que ha solicitado. 1. Inicio. 2. Se solicita la creación de una función. 3. Se crea la función. 4. Se copian los estatutos en la función. 5. Fin. Cursos Alternos Curso alterno 1 Curso alterno 1 3. Ocurre algún error durante la creación de la función. 4. La herramienta notifica del error. 5. Fin. 4. Ocurre algún error al copiar los estatutos a la función. 5. La herramienta notifica del error. 6. Fin. Excepciones Post-condiciones Observaciones No. de Instancia Si se presenta algún error durante la creación de la función o al copiar los estatutos en la misma, entonces se notifica del error y el caso de prueba termina. Ninguna Instancias de Prueba Valor Instancia 1 Se solicita la creación de una función sin parámetros. Instancia 2 Se solicita la creación de una función con parámetros. Resultado Esperado La clase de Java contiene una función sin parámetros generada correctamente. La clase de Java contiene una función con parámetros generada correctamente. 89 Capítulo 6 6.6 Resultados de las Pruebas En la Tabla 11 se muestran los resultados obtenidos de las pruebas al ejecutar cada uno de los casos de prueba especificados en MOO2MVA-CP-01, MOO2MVA-CP-02, MOO2MVA-CP-03, MOO2MVA-CP-04, MOO2MVA-CP-05, MOO2MVA-CP-06. Los diseños de prueba fueron elaborados con el propósito de comprobar que los métodos implementados actualmente en la herramienta MOO2MVA funcionan correctamente. Los casos de prueba MOO2MVA-CP-02, MOO2MVA-CP-03 y MOO2MVA-CP-06 fueron probados con varias instancias, esto con el propósito de verificar que sus salidas fueran correctas con las diferentes entradas y usos que se les pueden dar. Un aspecto importante a probar, además de la ejecución de los métodos, fue el correcto almacenamiento de la información en las tablas de la base de datos correspondientes. Esto fue probado en los casos de prueba MOO2MVA-CP-01, MOO2MVA-CP-02 y MOO2MVA-DP-06. La tabla a continuación resume los resultados obtenidos durante la ejecución de las pruebas. Tabla 11. Resumen de los resultados obtenidos en las pruebas Identificador Ejecución Almacenamiento de información en la Base de Datos MOO2MVA-CP-01 MOO2MVA-CP-02 Instancia 1 No aplica Instancia 2 No aplica Instancia 3 No aplica Instancia 4 No aplica MOO2MVA-CP-03 Instancia 5 No aplica Instancia 6 No aplica Instancia 7 No aplica Instancia 8 No aplica Instancia 9 No aplica Instancia 1 No aplica MOO2MVA-CP-04 Instancia 2 No aplica Instancia 3 No aplica MOO2MVA-CP-05 No aplica Instancia 1 MOO2MVA-CP-06 Instancia 2 90 Pruebas del Sistema 6.7 Análisis de Resultados Al realizar cada uno de los casos de prueba especificados en MOO2MVA-CP-01, MOO2MVA-CP-02, MOO2MVA-CP-03, MOO2MVA-CP-04, MOO2MVA-CP-05, MOO2MVA-CP-06 se probaron los métodos implementados hasta el momento en la herramienta MOO2MVA. Estos métodos son: R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”. Tomando en cuenta los resultados obtenidos al ejecutar las pruebas, mostrados en resumen en la Tabla 11, se puede determinar que los métodos implementados funcionan correctamente, pues las salidas obtenidas coinciden con las salidas esperadas para cada método y las pruebas fueron concluidas satisfactoriamente dentro de los alcances de esta tesis. Es importante señalar que, aunque el tiempo no fue un elemento a probar, durante la ejecución del método R1: “Analizar código legado” se pudo observar que el tiempo tomado para la ejecución del método depende en gran medida de la cantidad de código analizado y etiquetado. Esto es porque además de la etiquetación también se hacen inserciones en la base de datos para cada atributo de clase, para cada método contenido en las clases analizadas, y para cada clase, lo cual puede ser causante de que, cuando se analiza una gran cantidad de clases, el tiempo de ejecución del método llegue a ser considerable. Al finalizar la ejecución de pruebas se afirma que los métodos implementados hasta el momento en la herramienta MOO2MVA funcionan correctamente y que están listos para ser utilizados por los métodos pendientes de desarrollo: R6: “Reestructurar clases”, R8: “Coordinador de la creación de clases”, R9: "Reubicar funciones especializadas", R10: "Fragmentar funciones no especializadas" y el R11: "Redefinir llamadas a funciones". Como se mencionó anteriormente, en la Tabla 11 se muestra sólo el resumen de los resultados obtenidos, en el Anexo B se incluye las entradas utilizadas en cada prueba e instancia de prueba y las salidas obtenidas después de la ejecución de las mismas. 91 Conclusiones y Trabajos Futuros Capítulo 7. Conclusiones y Trabajos Futuros En este capítulo se detallan las conclusiones que son parte de este trabajo de tesis, las aportaciones obtenidas con esta investigación y los que se podrían considerar trabajos futuros. 7.1 Conclusiones El presente trabajo describe una primera aproximación para el desarrollo de una herramienta llamada MOO2MVA, la cual tiene como objetivo automatizar la refactorización de Marcos de Aplicaciones Orientados a Objetos hacia una arquitectura MVC. Esta primera aproximación consistió en la implementación de seis de los once métodos que conforman el proceso de refactorización. Dicho proceso utiliza como base los métodos propuestos en “Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador” [NUÑE,08], tesis de maestría realizada en el laboratorio de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). Se sometió a prueba la herramienta con un MOO que contenía una jerarquía de 44 clases y cuyo dominio se encuentra en la geometría. Tomando en cuenta los resultados obtenidos al 93 Capítulo 7 ejecutar las pruebas, se puede determinar que los métodos implementados funcionan correctamente, pues las salidas obtenidas coinciden con las salidas esperadas para cada método y las pruebas fueron concluidas satisfactoriamente dentro de los alcances de esta tesis. Como producto de este trabajo se obtiene una primera aproximación para la implementación de la herramienta MOO2MVA, la cual puede servir como base para otros trabajos futuros en los que se implementen los métodos restantes para el proceso de refactorización. Una vez que se se tengan implementados todos los métodos, sería posible utilizar la herramienta para transformar MOO hacia una arquitectura MVC, y una vez realizada esta transformación, tomar la capa del Modelo para transformarla a servicios Web. La importancia de transformar los MOO hacia servicios Web radica en que el conocimiento y desarrollo contenido en los MOO no debe ser dejado atrás. Este conocimiento debe ser adaptado a las nuevas tecnologías para conservar su estructura, funcionamiento, reglas de negocio y el esfuerzo invertido en ellos. Dentro de las áreas que podrían verse beneficiadas por el reuso de los MOO se encuentran: la fabricación de computadoras integradas, sistemas distribuidos, redes y telecomunicaciones, o ambientes multimedia de trabajo colaborativo, entre otros, [FAYA,00]. El objetivo del presente trabajo de tesis fue dividir la arquitectura original de los MOO hacia una arquitectura MVC con el propósito de favorecer su reúso como servicios Web, mediante el desarrollo de una herramienta que implemente los métodos propuestos en [NUÑE,08] Aunque el proceso de refactorización no pudo ser implementado en su totalidad, se considera que el objetivo se cumplió parcialmente, pues con base en las pruebas realizadas se afirma que los métodos implementados hasta el momento en la herramienta MOO2MVA funcionan correctamente y representan un primer paso hacia la automatización del proceso de refactorización de MOO hacia una arquitectura MVC. La implementación de seis de los once métodos que conforman el proceso de refactorización representa una implementación de más del 50% de estos. Y debido a que dentro de ellos se encuentra el método R1:”Analizar código legado”, se cree que la implementación actual representa un avance considerable en el desarrollo de la herramienta. Pues durante la investigación, se encontró que la etapa de análisis de código legado es la más importante dentro del proceso de refactorización, y es considerada la base para dicho proceso. Esta etapa demanda la mayor cantidad de análisis debido a que en ella se obtiene la estructura interna del código legado. Entre las aportaciones realizadas con este trabajo, se encuentra la colaboración en el refinamiento de los métodos propuestos en [NUÑE,08] y en el diseño del proceso de refactorización; además de la implementación de seis de los once métodos que conforman dicho proceso. Los métodos implementados son: R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”. 94 Conclusiones y Trabajos Futuros Además, con la implementación del método R1: “Analizar código legado”, fue necesaria la elaboración de una tabla de símbolos, la cual puede ser utilizada para otros proyectos agregándole información de acuerdo a las nuevas necesidades. Esta es una de las ventajas de que el proceso de creación de la tabla de símbolos se encuentre separado del proceso de etiquetación de código dentro del método R1. Por lo anterior, se puede afirmar que la herramienta MOO2MVA lleva a cabo satisfactoriamente una primera aproximación hacia la automatización del proceso de refactorización, y que puede servir como base para trabajos futuros en los que se implementen los métodos restantes para completar este proceso. 7.2 Trabajos futuros Como trabajo futuro se propone continuar con el desarrollo de los métodos pendientes de ser implementados, estos son: R6: “Reestructurar clases”, R8: “Coordinador de la creación de clases”, R9: "Reubicar funciones especializadas", R10: "Fragmentar funciones no especializadas" y el R11: "Redefinir llamadas a funciones". Además, el método R1: “Analizar código legado” debe ser probado ampliamente con código que incluya interfaces gráficas de usuario, con objetos y clases pertenecientes a las librerías java.awt y java.swing para comprobar su correcto funcionamiento, y en caso de ser necesario, realizar las modificaciones que estos nuevos casos necesiten. Una vez implementados todos los métodos y haber probado el método R1: “Analizar código legado” con código que incluya interfaces gráficas de usuario, se deberá realizar una etapa extensiva de pruebas para validar que el resultado de la refactorización conserve la misma funcionalidad que el código original. 95 Bibliografía Bibliografía [ABAD,08] Abadi, A., Ettinger, R., & Feldman, Y. A. (2008). Re-Approaching the Refactoring Rubicon. Recuperado el 15 de Marzo de 2011, de ACM Digital Library: http://dl.acm.org/citation.cfm?id=1636652 [AHO,98] Aho, A. V., Lam, M. S., Sethi, R., & Ullman, J. D. (1998). Compilers: Principles, Techniques, and Tools. Pearson Education, Inc. [ANTL,09] ANTLR v3. (11 de Marzo de 2009). Grammar List. Recuperado el 6 de Julio de 2011, de ANTLR v3: http://www.antlr.org/grammar/list [ANTL,10] ANTLR v3. (22 de Diciembre de 2010). Recuperado el 23 de Junio de 2011, de http://www.antlr.org/: http://www.antlr.org/ [AVER,01] Aversano, L., Canfora, G., Cimitile, A., & De Lucia, A. (15 de Marzo de 2001). Migrating Legacy Systems to the Web: An Experience Report. Recuperado el 14 de Noviembre de 2010, de IEEE Xplore: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=914979 [BODH,02] Bodhuin, T., Guardabascio, E., & Tortorella, M. (2002). Migrating COBOL Systems to the WEB by using MVC Design Pattern. Ninth Working Conference on Reverse Engineering (págs. 329-338). Richmond, VA, USA: IEEE CS Press. [BOOD,06] Boodhoo, J.-P. (Agosto de 2006). Model View Presenter. Recuperado el 2 de Diciembre de 2011, de MSDN Magazine: http://msdn.microsoft.com/enus/magazine/cc188690.aspx [BOSC,97] Bosch, J., Molin, P., Mattsson, M., & Bengtsson, P. (1997). Object-Oriented Frameworks - Problems & Experiences. Sweden: Department of Computer Science and Business Administration, University of Karlskrona/Ronneby. [BUNG,11] Bungee Connect. (2011). Bungee Connect and Model-View-Adapter (MVA). Recuperado el 04 de Diciembre de 2011, de Bungee Connect: http://www.bungeeconnect.com/img/whitepaper-mva_090803.pdf [BUST,03] Bustamante, L. C. (2003). Reestructuración de código legado a partir del comportamiento para la generación de componentes reutilizables. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET. [CUNN,05] Cunningham & Cunningham, Inc. (31 de Mayo de 2005). Model Delegate. Recuperado el 4 de Diciembre de 2011, de Cunningham & Cunningham, Inc.: http://c2.com/cgi/wiki?ModelDelegate [DEIT,08] Deitel, P. J., & Deitel, H. M. (2008). Cómo programar en Java. Naucalpan de Juárez, Estado de México, México: Pearson Educación. 97 Bibliografía [DIRE,11] Dirección General de Educación Superior Tecnológica . (Septiembre de 2011). Traductores y Compiladores. Recuperado el 06 de Diciembre de 2011, de Instituto Tecnológico de Celaya: http://www.iqcelaya.itc.mx/~vicente/Programacion/TradComp.pdf [DIST,06] Distante, D., Tilley, S., & Canfora, G. (2006). Towards a Holistic Approach to Redesigning Legacy Applications for the Web with UWAT+. 10th Conference on Software Maintenance and Reengineering (págs. 295-299). Bari, Italy: IEEE CS Press. [FAYA,97] Fayad, M. E., & Schmidt, D. C. (10 de Octubre de 1997). Object-Oriented Application Frameworks. Special Issue on Object-Oriented. Communications of the ACM. [FAYA,00] Fayad, M. E., & Jhonson, R. E. (2000). Domain-Specific Application Frameworks: Frameworks Experience by Industy. (M. Spencer, Ed.) New York: Jhon Wiley & Sons, Inc. Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refactoring: Improving the Design of Existing Code. Addison Wesley. [FOWL,99] [GOSL,05] Gosling, J., Joy, B., Steele, G., & Bracha, G. (2005). The Java™ Language Specification. Santa Clara, California, U.S.A.: Addison-Wesley. [GULZ,02] Gulzar, N. (4 de Noviembre de 2002). Fast Track to Struts: What id Does and How. Recuperado el 18 de Febrero de 2010, de TheServerSide.com: http://www.theserverside.com/ [HERN,03] Hernandez Moreno, L. A. (2003). Factorización de funciones hacia métodos de plantilla. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET. [MEND,04] Mendez, M. A. (2004). Reestructuración de software escrito por procedimientos conducido por patrones de diseño composicionales. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET. [NUÑE,08] Nuñez Ortega, E. L. (2008). Definición de método heurísticos para reestructura marcos de aplicaciones orientados a objetos hacia el patrón de diseño ModeloVista-Controlador. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET. [PARR,07] Parr, T. (2007). The Definitive ANTLR Reference. Dallas, Texas: The Pragmatic Programmers. [PILL,06] Pillay, A. (Diciembre de 2006). Object Oriented Programming using Java. Notes for the Computer Science Module Object Oriented Programming COMP200. Durban, Sudáfrica: University of KwaZulu-Natal. [PING,04] Ping, Y., Kostas, K., & Lau, T. C. (2004). Transforming Legacy Web Applications to 98 Bibliografía the MVC Architecture. 11th Annual International Workshop on Software Technology and Engineering Practice (págs. 133-142). Chicago, IL, USA: IEEE CS Press. Sicilia, M. Á. (9 de Enero de 2009). ¿Qué es Reestructuración del Software? Recuperado el 23 de Septiembre de 2011, de Connexions: http://cnx.org/content/m17443/latest/ [SIML,09] Simler, K. (20 de Abril de 2009). Model-View-Adapter. Recuperado el 1 de Diciembre de 2011, de Palantir TechBlog: http://blog.palantir.com/2009/04/20/model-view-adapter/ [SMIT,09] Smith, J. (Febrero de 2009). WPF Apps With The Model-View-ViewModel Design Pattern. Recuperado el 3 de Diciembre de 2011, de MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx [SOFT,98] Software & Systems Engineering Standards Committee . (1998). IEEE Standard for Software Test Documentation. IEEE Computer Society . [W3C,10] W3C. (06 de Mayo de 2010). Guía Breve de Servicios Web. Recuperado el 06 de Septiembre de 2010, de W3C World Wide Web Consortium: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb 99 Anexo A: Métodos de Reestructura Anexo A: Métodos de Reestructura En este anexo se presentan los pasos a seguir para los métodos R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”. Método de reestructura R1: “Analizar código legado” 1. Inicio. 2. Inicializar variables: e ” “, paquete ” “, nomclase ” “ 3. Abrir la tabla “Tipos de estatutos”. 4. Crear la tabla “Tipos de clases” con los siguientes campos: Nombre, Paquete, Patrón_MVC 5. Tipo, Tipo_relación1, Clase_base1, Tipo_relación2, Clase_Base2, Crear la tabla “Funciones abstractas” con los siguientes campos: Firma, Tipo_retorno, Clase, Patrón_MVC 6. Crear la tabla “Funciones concretas” con los siguientes campos: Firma, Tipo_retorno, Variable de retorno, Clase, Patrón_MVC 7. Crear la tabla “Tipos de Variables” con los siguientes campos: Identificador, Tipo, Especificador, Clase_variable, FirmaFunción, Clase_Función 8. Abrir la carpeta que contiene todos los archivos del código legado del marco orientado a objetos a analizar. 9. Mientras haya archivos para analizar en la carpeta: mientras(not carpeta vacía)haz 9.1. Inicializar los contadores: cm 0, cv 0, cc 0, cFa 0, cFMZ 0, cFM 0, cFC 0, cFV 0 9.2. Abrir un archivo de la carpeta. 9.3. Mientras no sea fin del archivo: 101 Anexo A: Métodos de Reestructura mientras(not EOF)haz 9.3.1. Leer un estatuto e estatuto 9.3.2. Mientras no sea fin de la clase: mientras(e≠})haz 9.3.2.1. Si el estatuto es una sentencia “import”: si(e==E1)entonces 9.3.2.1.1. archivos): Etiquetar el estatuto con la etiqueta “Im” (importación de estatuto estatuto+”//Im” fin_si //(9.3.2.1) 9.3.2.2. Si el estatuto es una sentencia “package” (definición de paquete): si(e==E2)entonces 9.3.2.2.1. Guardar el nombre del paquete: paquete nombre del paquete al que pertenece la clase fin_si //(9.3.2.2) 9.3.2.3. Si el estatuto es una definición de clase: si(e==E3∨e==E4∨e==E5)entonces 9.3.2.3.1. Si la clase no pertenece a algún paquete: si(paquete==” “)entonces 9.3.2.3.1.1. Definir el nombre del paquete al que pertenece la clase: paquete nombre del paquete fin_si //(9.3.2.3.1) 9.3.2.3.2. clase: Llenar la tabla “Tipos de clases” con los siguientes datos de la nombre de la clase, paquete, tipo de la clase, cláusula de relación1, clase_base1, cláusula de relación2, clase_base2 9.3.2.3.3. Asignar el nombre de la clase a la variable nomclase: nomclase nombre de la clase en estudio fin_si //(9.3.2.3) 9.3.2.4. Si el estatuto es una declaración de atributos (variables de instancia) o un estatuto de declaración de objetos: si(e==E6⋁e==E15)entonces 9.3.2.4.1. Abrir la tabla “Tipos de Variables”. 9.3.2.4.2. Llenar el registro de la tabla con los datos: Identificador de la variable, tipo de la variable, especificador de acceso, nombre de la clase a la que pertenece la variable. 9.3.2.4.3. Cerrar la tabla “Tipos de Variables”. fin_si //(9.3.2.4) 9.3.2.5. Si el estatuto es una declaración de un método abstracto: si(e==E16)entonces 9.3.2.5.1. Llenar los campos “Firma”, “Tipo_retorno” y “Clase”, de la tabla “Funciones abstractas”, con los siguientes datos de la función: firma de la función, tipo de retorno de la función, nomclase 9.3.2.5.2. Escribir “Sin definir” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones abstractas”. 9.3.2.5.3. Incrementar el contador de funciones abstractas: cFa cFa+1 fin_si //(9.3.2.5) 9.3.2.6. Si el estatuto es una definición de constructores: si(e==E7∨e==E8)entonces 9.3.2.6.1. Obtener la firma del constructor: firma firma del constructor 102 Anexo A: Métodos de Reestructura 9.3.2.6.2. Etiquetar el estatuto con la etiqueta “C” (constructor): estatuto estatuto+”//C” 9.3.2.6.3. Recorrer el cuerpo de sentencias del constructor: do{ 9.3.2.6.3.1. Leer el siguiente estatuto del cuerpo del constructor: e sig.estatuto 9.3.2.6.3.2. Si el estatuto es una asignación para inicializar atributos: si(e==E12⋁e==E12+E18)entonces 9.3.2.6.3.2.1. Obtener el identificador del atributo: identificador identificador de la variable 9.3.2.6.3.2.2. Inicializar el valor de la variable i: i 0 9.3.2.6.3.2.3. Abrir la tabla “Tipos de variables”. 9.3.2.6.3.2.4. constructor: Buscar inicializado en mientras(Tipos de variables[i].Identificador≠identificador⋀Tipos variables[i].Clase≠nomclase)haz de 9.3.2.6.3.2.4.1. los datos del atributo Si el atributo ya está registrado en la tabla: si(Tipos de variables[i].Identificador==identificador⋀Tipos variables[i].Clase==nomclase)entonces 9.3.2.6.3.2.4.1.1. de Obtener los datos del atributo: tipo Tipos de Variables[i].Tipo especificador Tipos de Variables[i].Especificador 9.3.2.6.3.2.4.1.2. Si el constructor es la primera función que utiliza el atributo: si(Tipos de variables[i].Firma_función==” “)entonces 9.3.2.6.2.2.5.1.1.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor: Tipos de variables[i].Firma_función firma Tipos de variables[i].Clase_Función nomclase si no 9.3.2.6.2.2.5.1.1.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor con los datos: identificador, tipo, firma, nomclase especificador, clase de la variable, fin_si //(9.3.2.6.3.2.4.1.2) si no 9.3.2.6.3.2.4.1.3. Incrementar el valor de la variable i: i i+1 fin_si //(9.3.2.6.3.2.4.1) fin_mientras //(9.3.2.6.3.2.4) fin_si //(9.3.2.6.3.2) 9.3.2.6.3.3. Si el estatuto es una asignación por medio de una llamada a un método o una llamada al constructor de la clase base: si(e==E12+E18∨e==E18)entonces 9.3.2.6.3.3.1. de invocación): Etiquetar el estatuto con la etiqueta “EI” (estatuto estatuto estatuto+”//EI” fin_si //(9.3.2.6.3.3) }while(e≠}) //(9.3.2.6.3) 103 el Anexo A: Métodos de Reestructura 9.3.2.6.4. Si el estatuto es una llave de fin de método: si(e==})entonces 9.3.2.6.4.1. función): Etiquetar el estatuto con la etiqueta “ff” (fin de estatuto estatuto+”//ff” fin_si //(9.3.2.6.4) fin_si //(9.3.2.6) 9.3.2.7. Si el estatuto es una definición de métodos: si(e==E9∨e==E10)entonces 9.3.2.7.1. función: Llenar la tabla “Funciones concretas” con los siguientes datos de la firma de la función, tipo de retorno, nomclase 9.3.2.7.2. Recorrer el cuerpo de sentencias del método: mientras(e≠})haz 9.3.2.7.2.1. Leer el siguiente estatuto: e siguiente estatuto 9.3.2.7.2.2. Si el estatuto es una declaración de variables locales, o una asignación, o un estatuto de repetición, o un estatuto de impresión, o un estatuto condicional, o un estatuto de invocación, o un estatuto selectivo, o un estatuto de devolución, o un estatuto de bloque: si(e==E11⋁e==E12⋁e==E13⋁e==E14⋁e==E15⋁e==E17∨e==E18∨e==E19∨e==E20∨e==E21) 9.3.2.7.2.2.1. Si el estatuto es una asignación: si(e==E12⋁e==E12+E18)entonces 9.3.2.7.2.2.1.1. Obtener el identificador modificada en el estatuto de asignación: de la identificador identificador asignación del estatuto 9.3.2.7.2.2.1.2. de la variable variable de Obtener la firma de la función: firma firma de la función en estudio 9.3.2.7.2.2.1.3. Inicializar el valor de la variable i: i 0 9.3.2.7.2.2.1.4. Abrir la tabla “Tipos de variables”. 9.3.2.7.2.2.1.5. Buscar los datos de la variable modificada en el estatuto de asignación: mientras(Tipos de variables[i].Identificador≠identificador⋀Tipos de variables[i].Clase≠nomclase)haz 9.3.2.7.2.2.1.5.1. tabla: Si la variable ya está registrado en la si(Tipos de variables[i].Identificador==identificador⋀Tipos variables[i].Clase==nomclase)entonces 9.3.2.7.2.2.1.5.1.1 de Obtener los datos de la variable: tipo Tipos de Variables[i].Tipo especificador Tipos de Variables[i].Especificador 9.3.2.7.2.2.1.5.1.2 a la variable: Si la función es la primera que accede si(Tipos de variables[i].FirmaFunción==” “)entonces 9.3.2.7.2.2.1.5.1.2.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor: Tipos de variables[i] firma si no 104 Anexo A: Métodos de Reestructura 9.3.2.7.2.2.1.5.1.2.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde a la variable modificada en el estatuto de asignación con los datos: identificador, tipo, especificador, nomclase, firma fin_si //(9.3.2.7.2.2.1.5.1.2) si no 9.3.2.7.2.2.1.5.1.3 Incrementar el valor de la variable i: i i+1 fin_si //(9.3.2.7.2.2.1.5.1) fin_mientras //(9.3.2.7.2.2.1.5) fin_si //(9.3.2.7.2.2.1) 9.3.2.7.2.2.2. Si el estatuto pertenece al Modelo: si(e pertenece al modelo)entonces 9.3.2.7.2.2.2.1. Etiquetar (estatuto del modelo): el estatuto con la etiqueta “//EM” estatuto estatuto+”//EM” 9.3.2.7.2.2.2.2. Incrementar el contador de estatutos del modelo: cm cm+1 fin_si //(9.3.2.7.2.2.2) 9.3.2.7.2.2.3. Si el estatuto pertenece al Control: si(e pertenece al control)entonces 9.3.2.7.2.2.3.1. Etiquetar (estatuto del control): el estatuto con la etiqueta “//EC” estatuto estatuto+”//EC” 9.3.2.7.2.2.3.2. Incrementar el contador de estatutos del control: cc cc+1 fin_si //(9.3.2.7.2.2.3) 9.3.2.7.2.2.4. Si el estatuto pertenece a la Vista: si(e pertenece a la vista)entonces 9.3.2.7.2.2.4.1. Etiquetar (estatuto de la vista): el estatuto con la etiqueta “//EV” estatuto estatuto+”//EV” 9.3.2.7.2.2.4.2. Incrementar el contador de estatutos de la vista: cv cv+1 fin_si //(9.3.2.7.2.2.4) 9.3.2.7.2.2.5. Si el estatuto es una asignación por medio de una llamada a un método, o si es una llamada a un método: si(e==E18∨e==E12+E18)entonces 9.3.2.7.2.2.5.1. Etiquetar (estatuto de invocación): el estatuto con la etiqueta “//EI” estatuto estatuto+”//EI” fin_si //(9.3.2.7.2.2.5) 9.3.2.7.2.2.6. Si el estatuto es un bloque de repetición condicional, o es un estatuto selectivo, o es un estatuto de bloque: o si(e==E13+”{“∨e==E17+”{“∨e==E19∨e==E21)entonces 9.3.2.7.2.2.6.1. Recorrer el cuerpo de sentencias del bloque: mientras(e≠})haz 9.3.2.7.2.2.6.1.1. Si el estatuto es una asignación: si(e==E12⋁e==E12+E18)entonces 9.3.2.7.2.2.6.1.1.1 Obtener el identificador de la variable modificada en el estatuto de asignación: 105 Anexo A: Métodos de Reestructura identificador identificador de la variable del estatuto de asignación 9.3.2.7.2.2.6.1.1.2 Obtener la firma de la función: firma firma de la función en estudio 9.3.2.7.2.2.6.1.1.3 Inicializar el valor de la variable i: i 0 9.3.2.7.2.2.6.1.1.4 Abrir la tabla “Tipos de variables”. 9.3.2.7.2.2.6.1.1.5 Buscar los datos modificada en el estatuto de asignación: de la variable mientras(Tipos de variables[i].Identificador≠identificador ⋀Tipos de variables[i].Clase≠nomclase)haz 9.3.2.7.2.2.6.1.1.5.1 en la tabla: Si la variable ya está registrado si(Tipos de variables[i].Identificador==identificador ⋀Tipos de variables[i].Clase==nomclase)entonces 9.3.2.7.2.2.6.1.1.5.1.1 variable: Obtener los datos de la tipo Tipos de Variables[i].Tipo especificador Tipos de Variables[i].Especificador 9.3.2.7.2.2.6.1.1.5.1.2 que accede a la variable: Si la función es la primera si(Tipos de variables[i].FirmaFunción==” “)entonces 9.3.2.7.2.2.6.1.1.5.1.2.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor: Tipos de variables[i] firma si no 9.3.2.7.2.2.6.1.1.5.1.2.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde a la variable modificada en el estatuto de asignación con los datos: identificador, tipo, especificador, nomclase, firma fin_si //(9.3.2.7.2.2.6.1.1.5.1.2) si no 9.3.2.7.2.2.6.1.1.5.1.3 variable i: Incrementar el valor de la i i+1 fin_si //(9.3.2.7.2.2.6.1.1.5.1) fin_mientras //(9.3.2.7.2.2.6.1.1.5) fin_si //(9.3.2.7.2.2.6.1.1) 9.3.2.7.2.2.6.1.2. Si el estatuto pertenece al Modelo: si(e pertenece al modelo)entonces 9.3.2.7.2.2.6.1.2.1 Etiquetar el estatuto con la etiqueta “//EM” (estatuto del modelo): estatuto estatuto+”//EM” 9.3.2.7.2.2.6.1.2.2 modelo: Incrementar el contador de estatutos del cm cm+1 fin_si //(9.3.2.7.2.2.6.1.2) 9.3.2.7.2.2.6.1.3. Si el estatuto pertenece al Control: si(e pertenece al control)entonces 106 Anexo A: Métodos de Reestructura 9.3.2.7.2.2.6.1.3.1 Etiquetar el estatuto con la etiqueta “//EC” (estatuto del control): estatuto estatuto+”//EC” 9.3.2.7.2.2.6.1.3.2 del control: Incrementar el contador de estatutos cc cc+1 fin_si //(9.3.2.7.2.2.6.1.3) 9.3.2.7.2.2.6.1.4. Si el estatuto pertenece a la Vista: si(e pertenece a la vista)entonces 9.3.2.7.2.2.6.1.4.1 Etiquetar el estatuto con la etiqueta “//EV” (estatuto de la Vista): estatuto estatuto+”//EV” 9.3.2.7.2.2.6.1.4.2 la vista: Incrementar el contador de estatutos de cv cv+1 fin_si //(9.3.2.7.2.2.6.1.4) 9.3.2.7.2.2.6.1.5. Si el estatuto es una asignación por medio de una llamada a un método, o es una llamada a un método: si(e==E18∨e==E12+E18)entonces 9.3.2.7.2.2.6.1.5.1 Etiquetar el estatuto con la etiqueta “//EI” (estatuto de invocación): estatuto estatuto+”//EI” fin_si //(9.3.2.7.2.2.6.1.5) 9.3.2.7.2.2.6.1.6. e siguiente estatuto Leer el siguiente estatuto: fin_mientras //(9.3.2.7.2.2.6.1) 9.3.2.7.2.2.6.2. Si el estatuto es una llave de fin de bloque: si(e==})entonces 9.3.2.7.2.2.6.2.1. Etiquetar el “//fe” (fin de estatuto de bloque): estatuto con la etiqueta estatuto estatuto+”//fe” fin_si //(9.3.2.7.2.2.6.2) fin_si //(9.3.2.7.2.2.6) fin_si //(9.3.2.7.2.2) fin_mientras //(9.3.2.7.2) 9.3.2.7.3. Si el estatuto es una llave de fin de método: si(e==})entonces 9.3.2.7.3.1. función): Etiquetar el estatuto con la etiqueta “//ff” (fin de estatuto estatuto+”//ff” 9.3.2.7.3.2. Si la función es no-especializada: si(cm≠0⋀cc≠0⋀cv≠0||cm==0⋀cc≠0⋀cv≠0||cm≠0⋀cc==0⋀cv≠0||cm≠0⋀cc≠0 ⋀cv==0)entonces 9.3.2.7.3.2.1. Etiquetar la función con la etiqueta “//FMZ” (función no-especializada) 9.3.2.7.3.2.2. Escribir “No especializada” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”. 9.3.2.7.3.2.3. especializadas: Incrementar el contador de funciones no cFMZ cFMZ+1 9.3.2.7.3.2.4. Inicializar los contadores: cm 0, cv 0, cc 0 107 Anexo A: Métodos de Reestructura 9.3.2.7.3.3. Si la función es especializada: si no 9.3.2.7.3.3.1. Si la función es del Modelo: si(cm≠0⋀cc==0⋀cv==0)entonces 9.3.2.7.3.3.1.1. del modelo). Etiquetar función con la etiqueta “//FM” (función 9.3.2.7.3.3.1.2. Escribir “Modelo” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”. 9.3.2.7.3.3.1.3. Incrementar el contador de funciones del modelo: cFM cFM+1 9.3.2.7.3.3.1.4. Inicializar el contador de estatutos del modelo: cm 0 9.3.2.7.3.3.2. Si la función no es del modelo: si no 9.3.2.7.3.3.2.1. Si la función es del control: si(cm==0⋀cc≠0⋀cv==0)entonces 9.3.2.7.3.3.2.1.1. Etiquetar la función con “//FC”. 9.3.2.7.3.3.2.1.2. Escribir “Control” “Patrón_MVC” del registro correspondiente estudio, de la tabla “Funciones concretas”. 9.3.2.7.3.3.2.1.3. control: en a la el campo función en Incrementar el contador de funciones del cFC cFC+1 9.3.2.7.3.3.2.1.4. control: Inicializar el contador de estatutos del cc 0 9.3.2.7.3.3.2.2. Si la función no es del control: si no 9.3.2.7.3.3.2.2.1. Si la función es de la vista: si(cm==0⋀cc==0⋀cv≠0)entonces 7.3.2.5.3.3.2.2.1.1. Etiquetar la función con “//FV” 7.3.2.5.3.3.2.2.1.2. Escribir “Vista” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”. 7.3.2.5.3.3.2.2.1.3. de la vista: Incrementar el contador de funciones cFV cFV+1 7.3.2.5.3.3.2.2.1.4. de la vista: Inicializar el contador de estatutos ce 0, cv 0 fin_si //(9.3.2.7.3.3.2.2.1) fin_si //(9.3.2.7.3.3.2.1) fin_si //(9.3.2.7.3.3.1) fin_si //(9.3.2.7.3.2) fin_si //(9.3.2.7.3) fin_si //(9.3.2.7) 9.3.2.8. Leer el siguiente estatuto: e sig.estatuto fin_mientras //(9.3.2) 9.3.3. Si el estatuto es una llave de fin de clase: si(e==})entonces 108 Anexo A: Métodos de Reestructura 9.3.3.1. Etiquetar el estatuto con la etiqueta “fc” (fin de clase): estatuto estatuto+”//fc” 9.3.3.2. Si la clase en estudio es abstracta: si(cFa≠0)entonces 9.3.3.2.1. Escribir “Sin definir” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”. fin_si //(9.3.3.2) 9.3.3.3. Si la clase en estudio es no-especializada: si((cFMZ≠0)⋁(cFM≠0⋀(cFC≠0∨cFV≠0)))entonces 9.3.3.3.1. Etiquetar especializada). la clase con la etiqueta “//CMZ” (clase no- 9.3.3.3.2. Escribir “No especializada” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”. 9.3.3.4. Si la clase en estudio es especializada: si no 9.3.3.4.1. Si la clase en estudio es del Modelo: si(cFMZ==0⋀cFM≠0⋀cFC==0⋀cFV==0)entonces 9.3.3.4.1.1. modelo). Etiquetar la clase con la etiqueta “//CM” (clase del 9.3.3.4.1.2. Escribir “Modelo” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”. si no 9.3.3.4.1.3. Si la clase en estudio es del Control: si(cFMZ==0⋀cFM==0⋀cFC≠0⋀cFV==0)entonces 9.3.3.4.1.3.1. control). Etiquetar la clase con la etiqueta “//CC” (clase del 9.3.3.4.1.3.2. Escribir “Control” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”. si no 9.3.3.4.1.3.3. Si la clase en estudio es de la Vista: si(cFMZ==0⋀cFM==0⋀cFC==0⋀cFV≠0)entonces 9.3.3.4.1.3.3.1. de la vista). Etiquetar la clase con la etiqueta “//CV” (clase 9.3.3.4.1.3.3.2. Escribir “Vista” en el campo “Patrón _MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”. fin_si //(9.3.3.4.1.3.3) fin_si //(9.3.3.4.1.3) fin_si //(9.3.3.4.1) fin_si //(9.3.3.3) fin_si //(9.3.3) fin_mientras //(9.3) fin_mientras //(9) 10.Inicializar las variables: i 0, j 0, Clases[] ” “, nomclase ” “, patron ” “, firma ” “, numreg 0, band ”“ 11.Abrir la tabla “Funciones concretas”. 12.Recorrer la tabla: mientras(not EOF(Funciones concretas))haz 12.1. Obtener los datos de una función concreta: firma Funciones concretas[i].Firma nomclase Funciones concretas[i].Clase 109 Anexo A: Métodos de Reestructura patron Funciones concretas[i].Patrón_MVC 12.2. Inicializar la variable k: k 0 12.3. Abrir la tabla “Tipos de clases”. 12.4. Recorrer la tabla “Tipos de clases”: mientras(nomclase≠” “)haz 12.4.1. Buscar la jerarquía de clases a la que pertenece la función concreta en estudio: si(Tipos de clases[j].Nombre==nomclase)entonces 12.4.1.1. Verificar si la clase extiende o implementa a una clase base: si(Tipos de clases[j].Clase_base1≠” “)entonces 12.4.1.1.1. Almacenar en un arreglo la jerarquía de clases a la que pertenece la función concreta en estudio: Clases[k] Tipos de clases[j].Clase_base1 12.4.1.1.2. Obtener la siguiente clase base de la jerarquía de clases: nomclase Tipos de clases[j].Clase_base1 12.4.1.1.3. Actualizar las variable k y j: k k+1 j 0 12.4.1.2. Si la clase no extiende o implementa a una clase base: si no 12.4.1.2.1. Inicializar la variable nomclase: nomclase ” “ fin_si //(12.4.1.1) 12.4.2. Si la clase registrada en la tabla no pertenece a la jerarquía de clases de la función concreta en estudio: si no 12.4.2.1. Incrementar el valor de la variable j: j j+1 fin_si //(12.4.1) fin_mientras //(12.4) 12.5. Inicializar variables: numreg sizeof(Clases), j 0, k 0 12.6. Recorrer la jerarquía de clases a la que pertenece la función concreta en estudio: mientras(k<numreg)haz 12.6.1. Obtener una clase del arreglo que almacena la jerarquía de clases: nomclase Clases[k] 12.6.2. Limpiar la casilla del arreglo: Clases[k] ” “ 12.6.3. Actualizar las variables k y band: k k+1, band false 12.6.4. Abrir la tabla “Funciones abstractas”. 12.6.5. Recorrer la tabla: mientras(band==false)entonces 12.6.5.1. estudio: Buscar la función abstracta que implementa la función concreta en si(Funciones abstractas[j].Firma==firma⋀Funciones abstractas[j].Clase==nomclase)entonces 12.6.5.1.1. Verificar si la función abstracta no ha sido etiquetada previamente: si(Funciones abstractas[j].Patron_MVC==”Sin definir“)entonces 12.6.5.1.1.1. Etiquetar la función abstracta, de acuerdo a la parte del patrón MVC a la que pertenece la función concreta que la implementa: 110 Anexo A: Métodos de Reestructura Funciones abstractas[j].Patrón_MVC patron 12.6.5.1.1.2. Abrir el archivo <nomclase>.java y etiquetar el código de la declaración de la función abstracta, con la etiqueta correspondiente a la parte del patrón MVC al que pertenece. fin_si //(12.6.5.1.1) 12.6.5.1.2. Modificar el valor de las variables band y j: band true, j 0 12.6.5.2. Si la firma y la clase de pertenencia de la función registrada en la tabla no corresponden con la firma y la clase buscadas: si no 12.6.5.2.1. Incrementar el valor de la variable j para continuar la búsqueda: j j+1 fin_si //(12.6.5.1) fin_mientras //(12.6.5) fin_mientras //(12.6) 12.7. Incrementar el valor de la variable i: i i+1 fin_mientras //(12) 13. Inicializar variables: i 0, j 0, cFMZ 0, cFM 0, cFV 0, cFC 0, nomclase ” “ 14. Abrir la tabla “Funciones abstractas”. 15. Recorrer la tabla: mientras(not EOF(Funciones abstractas))haz 15.1. Obtener la clase a la que pertenece la función abstracta registrada en la tabla: nomclase Funciones abstractas[i].Clase 15.2. Modificar el valor de la variable j: j i 15.3. Analizar las funciones abstractas que pertenecen a la clase en estudio: mientras(Funciones abstractas[j].Clase==nomclase)haz 15.3.1. Si la función abstracta en estudio pertenece al modelo: si(Funciones abstractas[j].Patrón_MVC==”Modelo”)entonces 15.3.1.1. Incrementar el contador de funciones del modelo: cFM cFm+1 si no 15.3.1.2. Si la función pertenece a la vista: si(Funciones abstractas[j].Patrón_MVC==”Vista”)entonces 15.3.1.2.1. Incrementar el contador de funciones de la vista: cFV cFV+1 si no 15.3.1.2.2. Si la función pertenece al control: si(Funciones abstractas[j].Patrón_MVC==”Control”)entonces 15.3.1.2.2.1. Incrementar el contador de funciones del control: cFC cFC+1 si no 15.3.1.2.2.2. Incrementar el contador de funciones no especializadas: cFMZ cFMZ+1 fin_si //(15.3.1.2.2) fin_si //(15.3.1.2) fin_si //(15.3.1) 15.3.2. Incrementar el valor de la variable j: 111 Anexo A: Métodos de Reestructura j j+1 fin_mientras //(15.3) 15.4. Si la función abstracta registrada en la tabla pertenece a una clase diferente: si(Funciones abstractas[j].Clase≠nomclase)entonces 15.4.1. Si la clase en estudio es no especializada: si((cFMZ≠0)⋁(cFM≠0⋀(cFV≠0⋁cFC≠0))entonces 15.4.1.1. Modificar la variable patron: patron ”No especializada” 15.4.1.2. Inicializar los contadores de funciones: cFMZ 0, cFM 0, cFV 0, cFc 0 si no 15.4.1.3. Si la clase en estudio es del modelo: si(cFMZ==0⋀cFM≠0⋀cFv==0⋀cFc==0)entonces 15.4.1.3.1. Modificar la variable patrón: patron ”Modelo” 15.4.1.3.2. Inicializar el contador de funciones del modelo: cFM 0 si no 15.4.1.3.3. Si la clase en estudio es de la vista: si(cFM==0⋀cFv≠0⋀cFc==0⋀cFMZ==0)entonces 15.4.1.3.3.1. Modifica la variable patrón: patron ”Vista” 15.4.1.3.3.2. Inicializar el contador de funciones de la vista: cFv 0 si no 15.4.1.3.3.3. Si la clase en estudio es del control: si(cFM==0⋀cFv==0⋀cFc≠0⋀cFMZ==0)entonces 15.4.1.3.3.3.1. Modificar la variable patrón: patron ”Control” 15.4.1.3.3.3.2. Inicializar el contador de funciones del control: cFc 0 fin si //(15.4.1.3.3.3) fin_si //(15.4.1.3.3) fin_si //(15.4.1.3) fin_si //(15.4.1) 15.4.2. Abrir la tabla “Tipos de clases”. 15.4.3. Inicializar variables: k 0, band false 15.4.4. Recorrer la tabla: mientras(band==false)haz 15.4.4.1. Buscar el registro de la clase en estudio: si(Tipos de clases[k].Nombre==nomclase)entonces 15.4.4.1.1. Verificar que la clase no haya sido etiquetada previamente: si(Tipos de clases[k].Patrón_MVC==”Sin definir”)entonces 15.4.4.1.1.1. Etiquetar la clase: Tipos de clases[k].Patrón_MVC patron 15.4.4.1.1.2. Abrir el archivo <nomclase>.java que contiene el código de la clase, del marco orientado a objetos original, y etiquetar la declaración de la clase con la etiqueta que corresponda (“//CM” si la clase pertenece al modelo, “//CV” si la clase pertenece a la vista, “//Cc” si la clase pertenece al control o “//CMZ” si la clase es No especializada). 112 Anexo A: Métodos de Reestructura fin_si //(15.4.4.1.1) 15.4.4.1.2. Modificar el valor de la variable band: band true si no 15.4.4.1.3. Incrementar el valor de la variable k: k k+1 fin_si //(15.4.4.1) fin_mientras //(15.4.4) 15.4.5. Modificar el valor de la variable i: i j fin_si //(15.4) fin_mientras //(15) 16. Termina el método de reestructura R1. Método de reestructura R7: “Estructura jerárquica de clases” Parámetros de entrada: ninguno 1. Inicio. 2. Crear la tabla “Jerarquía de clases” con los siguientes campos: 3. Inicializar variables: Clase_padre, Clase_hija i 0, clasepadre ” “, band false, h 0, k 0, j 0, numreg sizeof(Tipos de clases) 4. Abrir la tabla “Tipos de clases”. 5. Recorrer la tabla “Tipos de clases” para obtener la arquitectura de clases del marco orientado a objetos original: mientras(k<=numreg)haz 5.1. Buscar una clase padre: mientras(clasepadre==” “)haz 5.1.1. Verificar que la clase padre sea una clase raíz: si((Tipos de clases[i].Clase_base1==” “) ⋀ (Tipos de clases[i].Clase_base2==” “))entonces 5.1.1.1. Obtener la clase raíz: clasepadre Tipos de clases[i].Nomb_clase si no 5.1.1.2. Incrementar la variable i: i i+1 fin_si //(5.1.1) fin_mientras //(5.1) 5.2. Inicializar las variables i y band: i 0, band false 5.3. Recorrer desde el inicio la tabla “Tipos de clases” para obtener todas las subclases de la clase padre: mientras(not EOF(Tipos de clases)haz 5.3.1. Verificar si la clase es subclase de la clase padre: si((Tipos de clases[i].Clase_base1==clasepadre) ⋁(Tipos de clases[i].Clase_base2==clasepadre))entonces 5.3.1.1. Modificar el valor de la variable band: band true 5.3.1.2. Registrar los datos en la tabla “Jerarquía de clases”: 113 Anexo A: Métodos de Reestructura Jerarquía de clases[k].Clase_padre clasepadre Jerarquía de clases[k].Clase_hija Tipos de clases[i].Nomb_clase 5.3.1.3. Incrementar la variable k: k k+1 fin_si //(5.3.1) 5.3.2. Incrementar el valor de la variable i: i i+1 fin_mientras //(5.3) 5.4. Si la clase padre no tiene subclases: si((EOF(Tipos de clases)⋀(band==false))entonces 5.4.1. Registrar los datos de la clase en la tabla “Jerarquía de clases”: Jerarquía de clases[k].Clase_padre clasepadre Jerarquía de clases[k].Clase_hija ”Sin subclases” 5.4.2. Incrementar la variable k: k k+1 fin_si //(5.4) 5.5. Obtener la siguiente clase padre: haz 5.5.1. Verificar que la clase candidata sea una subclase: si(Jerarquía de clases[h].Clase_hija≠”Sin subclases”) 5.5.1.1. Asignar a la subclase como siguiente clase padre: clasepadre Jerarquía de clases[h].Clase_hija 5.5.1.2. Inicializar las variables j y band: j 0, band false 5.5.1.3. Verificar que la nueva clase padre no se encuentre en la tabla “Jerarquía de clases” como clase padre: mientras((j<k)⋁(band==false))haz 5.5.1.3.1. Si la nueva clase padre se encuentra en la tabla “Jerarquía de clases” como clase base: si(Jerarquía de clases[j].Clase_padre==clasepadre)entonces 5.5.1.3.1.1. Cambiar el valor de la variable band: band true 5.5.1.3.1.2. Incrementar el valor de la variable h: h h+1 si no 5.5.1.3.1.3. Incrementar el valor de la variable j: j j+1 fin_si //(5.5.1.3.1) fin_mientras //(5.5.1.3) 5.5.1.4. Si la nueva clase padre no se encuentra en la tabla “Jerarquía de clases” como clase base(padre?): si((j==k)⋀(band==false))entonces 5.5.1.4.1. Incrementar la variable h: h h+1 5.5.1.4.2. i 0 114 Inicializar el valor de la variable i: Anexo A: Métodos de Reestructura fin_si //(5.5.1.4) fin_si //(5.5.1) mientras(band==true) //(5.5) fin_mientras //(5) 6. Termina el método de reestructura R7. Método de reestructura R2: “Crear clases” Parámetros de entrada: paquete, nomclase, tipo, tiporel, clasebase1, tiporel2, clasebase2 1. Inicio. 2. Si no hay clases MVC creadas: si(Clases Modelo==” “∧Clases Vista==” “∧Clases Control==” “)entonces 2.1. Crear una carpeta que almacene los archivos del marco orientado a objetos con arquitectura MVC. 2.2. Abrir la carpeta que almacena los archivos del marco orientado a objetos con arquitectura MVC. 2.3. Crear una nueva carpeta con el nombre del paquete que almacene los archivos del marco orientado a objetos con arquitectura MVC. fin_si //(2) 3. Abrir la carpeta con el nombre del paquete que almacena los archivos del marco orientado a objetos con arquitectura MVC. 4. Crear un archivo de definición con extensión “.java” para la declaración de la clase, en la carpeta que almacena los archivos del marco orientado a objetos con arquitectura MVC. 5. Escribir en este archivo el texto que declara el paquete al que pertenece el archivo: package <paquete>; 6. Escribir en este archivo el texto que declara la clase: 6.1. Si es una clase concreta: si(tipo==”concreta”)entonces 6.1.1. Si es una clase simple: si(tiporel==” “)entonces 6.1.1.1. Generar el siguiente código: public class <nomclase>{ fin_si //(6.1.1) 6.1.2. Si es una clase derivada de otra: si(tiporel==”extends”)entonces 6.1.2.1. Generar el siguiente código: public class <nomclase> extends <clasebase1>{ fin_si //(6.1.2) 6.1.3. Si la clase implementa una interfaz: si(tiporel==”implements”)entonces 6.1.3.1. Generar el siguiente código: public class <nomclase> implements <clasebase1>{ fin_si //(6.1.3) 6.1.4. Si es una clase derivada de otra y además implementa una interfaz: si(tiporel==”extends”⋀tiporel2==”implements”)entonces 6.1.4.1. Generar el siguiente código: public class <nomclase> extends <clasebase1> implements <clasebase2>{ fin_si //(6.1.4) fin_si //(6.1) 6.2. Si es una clase abstracta: 115 Anexo A: Métodos de Reestructura si(tipo==”abstracta”)entonces 6.2.1. Si es una clase simple: si(tiporel==” “)entonces 6.2.1.1. Generar el siguiente código: public abstract class <nomclase>{ fin_si //(6.2.1) 6.2.2. Si la clase es derivada de otra: si(tiporel==”extends”)entonces 6.2.2.1. Generar el siguiente código: public abstract class <nomclase> extends <clasebase1>{ fin_si //(6.2.2) 6.2.3. Si esta clase implementa una interfaz: si(tiporel==”implements”)entonces 6.2.3.1. Generar el siguiente código: public abstract class <nomclase> implements <clasebase1>{ fin_si //(6.2.3) fin_si //(6.2) 6.3. Si es una interfaz: si(tipo==”interface”)entonces 6.3.1. Si es una interfaz simple: si(tiporel==” “)entonces 6.3.1.1. Generar el siguiente código: public interface <nomclase>{ fin_si //(6.3.1) 6.3.2. Si es una interfaz derivada de otra: si(tiporel==”extends”)entonces 6.3.2.1. Generar el siguiente código: public interface <nomclase> extends <clasebase1>{ fin_si //(6.3.2) fin_si //(6.3) 6.4. Cerrar la definición de la clase de manera apropiada, generando el siguiente código: } //Termina <nomclase> 7. Termina método de reestructura R2. Método de reestructura R3: “Crear constructor” Parámetros de entrada: nomclase, claseMVA, parametros[n][3] 1. Inicio. 2. Si el constructor es un constructor simple (sin parámetros), generar el código de inicialización con valores por omisión: public <claseMVA>(){ 2.1. Para cada atributo de la clase: 2.1.1. Si el dato a inicializar en el constructor es de tipo boolean entonces generar el siguiente código: dato=literal; 2.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=dígito; 2.1.3. Si el dato a inicializar en el constructor es de tipo float o double, entonces generar el siguiente código: 116 Anexo A: Métodos de Reestructura dato=dígito.dígito; 2.1.4. Si el dato a inicializar en el constructor es de tipo char, entonces generar el siguiente código: dato=’caracter’; 2.1.5. Si el dato a inicializar en el constructor es de tipo String, entonces generar el siguiente código: dato=”cadena de caracteres”; 2.1.6. Si el dato a inicializar en el constructor es un objeto, entonces generar el siguiente código: Clase obj=referencia; 2.2. Si el constructor crea objetos, generar el siguiente código: this.obj=new <objparm[n]+”()”>; 2.3. Cerrar la definición del constructor de manera apropiada, generando el siguiente código: } //Termina el constructor <claseMVA> 2.4. 3. Si se desea crear otro constructor entonces ir al paso 1, si no, ir al paso 4. Si el constructor es un constructor con parámetros, generar el siguiente código: public claseMVA(<parametros[0][0] parametros[0][1]>, …, <parametros[n][0] parametros[n][1]>){ 3.1. Para cada atributo declarado en la definición de la clase: 3.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=<parametros[0][1]>; … this.datoN=<parametros[n][1]>; 3.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=<parametros[0][1]>; … datoAtributoN=<parametros[n][1]>; 3.2. Si el constructor crea objetos, generar el siguiente código: this.obj=new <parametros[0][0]>(<parametros[0][1] parámetros[0][2]>, …, <parametros[n][1] parametros[n][2]>); o this.obj=new tipo[param1]; o this.vec=new tipo[param1][param2]; 3.2.1. Si el constructor de una subclase invoca explícitamente al constructor de la superclase, entonces generar el siguiente código: public <parametros[0][0]>(<parametros[0][1] parámetros[0][2]>, …, <parametros[n][1] parametros[n][2]>){ 3.2.1.1. Agregar la invocación al constructor de la superclase: super(<parametros[0][2]>, …, <parametros[n][2]>); 3.2.1.2. Si el constructor de la subclase tiene más operaciones, añadir las líneas de asignaciones: dato=datoN+1; o asignarDato(datoN+1); 3.3. Cerrar la definición del constructor de manera apropiada, generando el siguiente código: } //Termina el constructor <claseMVA> 3.4. Si se desea crear otro constructor, ir al paso 1, si no ir al paso 5. 117 Anexo A: Métodos de Reestructura 4. Si el constructor es una copia del constructor de la clase original (constructores de clases especializadas) entonces: 4.1. Abrir el archivo con extensión <nomclase>.java que contiene el código de la clase del marco orientado a objetos original. 4.2. Leer el primer estatuto y su etiqueta: e←estatuto etiqueta←etiqueta del estatuto 4.3. Recorrer el archivo para identificar el código del constructor: mientras(e≠”}“∧etiqueta≠”//fc”) 4.3.1. Si el estatuto define a un constructor: si(e==E7∨e==E8)entonces 4.3.1.1. Abrir el archivo que contiene el código de la clase MVC a la que se agrega el constructor. 4.3.1.2. Copiar el código del constructor: mientras(e≠”}”∧etiqueta≠”ff)haz 4.3.1.2.1. Escribir el estatuto del constructor en el archivo de la clase MVC. 4.3.1.2.2. Leer el siguiente estatuto: e←siguiente estatuto etiqueta←etiqueta del siguiente estatuto fin_mientras //(4.3.1.2) 4.3.1.3. Cerrar la definición del constructor de manera apropiada, generando el siguiente código: } //Termina el constructor nomclase fin_si //(4.3.1) 4.3.2. Leer el siguiente estatuto: e←siguiente estatuto etiqueta←etiqueta del siguiente estatuto fin_mientras //(4.3) 4.4. Si se desea crear otro constructor, ir al paso 1, si no ir al paso 5. 5. Termina el método de reestructura R3. Método de reestructura R5: “Reubicar atributos” Parámetros de entrada: nomclaseMVA 1. Inicio. 2. Inicializar las variables: i←0, band←false, e←” “, especificador←” “, tipo←” “, identificador←” “ 3. Abrir la tabla “Variables MVA”. 4. Recorrer la tabla: mientras(not EOF(Variables MVA)∧band==false)haz 4.1. Buscar los registros de los atributos de la clase MVA: si(Varibales MVA[i].Clase==nomclaseMVA)entonces 4.1.1. Modificar el valor de la variable band: band←true 4.1.2. Abrir el archivo <nomclaseMVA>.java. 4.1.3. Obtener los datos de los atributos a reubicar: mientras(Variables MVA[i].Clase==nomclaseMVA)haz 4.1.3.1. Obtener el especificador de acceso del atributo: especificador←Variables MVA[i].Especificador 4.1.3.2. Obtener el tipo del atributo: tipo←Variables MVA[i].Tipo 4.1.3.3. Obtener el identificador del atributo: 118 Anexo A: Métodos de Reestructura identificador←Variables MVA[i].Identificador 4.1.3.4. Formar el estatuto de declaración de atributos: e←especificador+tipo+identificador+”;” 4.1.3.5. Escribir el estatuto de declaración de atributos <nomclaseMVA>.java 4.1.3.6. Incrementar el valor de la variable i: i←i+1 fin_mientras //(4.1.3) si no 4.1.4. Incrementar el valor de la variable i: i←i+1 fin_si //(4.1) fin_mientras //(4) 5. Termina el método de reestructura R5. e en el archivo Método de reestructura R4: “Crear funciones” Parámetros de entrada: firma, especificador, tiporet, valret, nomclaseMVA, patron 1. Inicio 2. Inicializar variables: parm ”()”, parametros false, n 0, i 0, identificador ” “, lista ” “, listaparm ” “ 3. Abrir el archivo que contiene el código de la clase MVA: Abrir <nomclaseMVA>.java 4. Verificar si la función recibe parámetros: parametros firma.contains(parm) 5. Si la función no recibe parámetros: si(parametros==true)entonces 5.1. Generar el estatuto de definición de la función: e especificador+tiporet+firma+”{“ 5.2. Escribir el estatuto de definición de la función e en <nomclaseMVA>.java 5.3. Si la función pertenece a la Vista: si(patron==”Vista”)entonces 5.3.1. Abrir el vector vVista. 5.3.2. Obtener el número total de elementos en el vector vVista: n length(vVista) 5.3.3. Leer el vector vVista: mientras(i<n)haz 5.3.3.1. Obtener el elemento i del vector vVista: e vVista[i] 5.3.3.2. Escribir el estatuto e en el archivo <nomclaseMVA>.java 5.3.3.3. Incrementar el valor de la variable i: i i+1 fin_mientras //(5.3.3) fin_si //(5.3) 5.4. Si la función pertenece al Modelo: si(patron==”Modelo”)entonces 5.4.1. Abrir el vector vModelo. 5.4.2. Obtener el número total de elementos en el vector vModelo: n length(vModelo) 5.4.3. Leer el vector vModelo: mientras(i<n)haz 5.4.3.1. Obtener el elemento i del vector vModelo: e vModelo[i] el archivo 119 Anexo A: Métodos de Reestructura 5.4.3.2. Escribir el estatuto e en el archivo <nomclaseMVA>.java 5.4.3.3. Incrementar el valor de la variable i: i i+1 fin_mientras //(5.4.3) fin_si //(5.4) 5.5. Si la función pertenece al Control: si(patron==”Control”)entonces 5.5.1. Abrir el vector vControl. 5.5.2. Obtener el número total de elementos en el vector vControl: n length(vControl) 5.5.3. Leer el vector vControl: mientras(i<n)haz 5.5.3.1. Obtener el elemento i del vector vControl: e vControl[i] 5.5.3.2. Escribir el estatuto e en el archivo <nomclaseMVA>.java 5.5.3.3. Incrementar el valor de la variable i: i i+1 fin_mientras //(5.5.3) fin_si //(5.5) Si la función recibe parámetros: si no 5.6. Obtener el identificador de la función: identificador identificador de la firma de la función 5.7. Obtener la lista de parámetros de la firma de la función: lista lista de parámetros de la firma 5.8. Añadir a la lista de parámetros de la función, un identificador por cada tipo de datos que recibe: listaparm ”(“+lista(TipoDato1)+” “Id1+”,”+…+lista(TipoDaton)+”“+Idn+”)” 5.9. Generar el estatuto de definición de la función: e especificador+tiporet+identificador+listaparm+”{“ 5.10. Escribir el estatuto de definición e en el archivo <nomclaseMVA>.java 5.11. Si la función pertenece a la Vista: si(patron==”Vista”)entonces 5.11.1. Abrir el vector vVista. 5.11.2. Obtener el número total de elementos en el vector vVista: n length(vVista) 5.11.3. Leer el vector vVista: mientras(i<n)haz 5.11.3.1. Obtener el elemento i del vector vVista: e vVista[i] 5.11.3.2. Escribir el estatuto e en el archivo <nomclaseMVA>.java 5.11.3.3. Incrementar el valor de la variable i: i i+1 fin_mientras //(5.11.3) fin_si //(5.11) 5.12. Si la función pertenece al Modelo: si(patron==”Modelo”)entonces 5.12.1. Abrir el vector vModelo. 5.12.2. Obtener el número total de elementos en el vector vModelo: n length(vModelo) 5.12.3. Leer el vector vModelo: mientras(i<n)haz 5.12.3.1. Obtener el elemento i del vector vModelo: e vModelo[i] 5.12.3.2. Escribir el estatuto e en el archivo <nomclaseMVA>.java 5.12.3.3. Incrementar el valor de la variable i: 120 Anexo A: Métodos de Reestructura i i+1 fin_mientras //(5.12.3) fin_si //(5.12) 5.13. Si la función pertenece al Control: si(patron==”Control”)entonces 5.13.1. Abrir el vector vControl. 5.13.2. Obtener el número total de elementos en el vector vControl: n length(vControl) 5.13.3. Leer el vector vControl: mientras(i<n)haz 5.13.3.1. Obtener el elemento i del vector vControl: e vControl[i] 5.13.3.2. Escribir el estatuto e en el archivo <nomclaseMVA>.java 5.13.3.3. Incrementar el valor de la variable i: i i+1 fin_mientras //(5.13.3) fin_si //(5.13) fin_si //(5) 6. Añadir el estatuto de retorno: si(valret≠” “)entonces 6.1. Formar el estatuto de retorno: e ”return”+val si no 6.2. Formar el estatuto de retorno: e ”return”+”;” fin_si //(6) 7. Cerrar la función de manera apropiada: e ”} //Termina función” 8. Escribir e en el archivo <nomclaseMVA>.java 9. Abrir la tabla “Funciones concretas MVA”. 10. Llenar el registro de la tabla con los datos: firma, especificador, tiporet, valret, nomclaseMVA, patrón 11. Cerrar la tabla “Funciones concretas MVA”. 12. Termina el método de reestructura R4. 121 Anexo B: Descripción de los Casos de Prueba Anexo B: Descripción de los Casos de Prueba En este anexo se describen los datos de entrada y los resultados esperados para cada uno de los caso de prueba que se ejecutaron para evaluar el correcto funcionamiento de los métodos R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”. Caso de prueba MOO2MVA-CP-01 a) Especificación de entrada Los elementos de entrada para probar la correcta funcionalidad del análisis y etiquetación de código, así como la obtención de información (método R1) son: El código del marco orientado a objetos Figuras Geométricas escrito en lenguaje Java. Es decir, los elementos de prueba CJ01- CJ44 b) Especificación de salida Los resultados de la ejecución del método R1, de acuerdo a la entrada descrita anteriormente son los siguientes: o El código java etiquetado correctamente. Debido a la cantidad de código que se utilizó durante esta prueba, sólo se muestra el código etiquetado de cuatro de las clases analizadas, estas son las clases: aTriangulos.java, cTrianguloEquilatero.java, cTrianguloEscaleno.java y cTrianguloIsoceles.java. 123 Anexo B: Descripción de los Casos de Prueba Figura 34. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 1) 124 Anexo B: Descripción de los Casos de Prueba Figura 35. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 2) Figura 36. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEquilatero.java 125 Anexo B: Descripción de los Casos de Prueba Figura 37. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEscaleno.java Figura 38. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloIsoceles.java o 126 Y las tablas “Tipos de variables”, “Funciones concretas”, “Funciones abstractas” y “Tipos de clase”, dichas tablas se muestra en las siguientes tablas: Anexo B: Descripción de los Casos de Prueba Tabla 12. Resultados del MOO2MVA-CP-01: Tabla Tipos de Variables Especificador Clase_Variable FirmaFuncion Identificador Tipo e radio diametro area perimetro circunferencia semiperimetro excentricidad double double double double double double double double aFigura aConicas aConicas aConicas aConicas aConicas aConicas aConicas puntox double aConicas puntoy double aConicas puntoa double aConicas puntob double aConicas puntoc lado1 lado2 lado3 lado4 altura area apotema diagonal diagonales perimetro semiperimetro radio e radio altura areatot areabase arealat volumen generatriz radio double double double double double double double double double double double double double double double double double double double double double double protected protected protected protected protected protected protected protected aConicas aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuerpo aCurvos aCurvos aCurvos aCurvos aCurvos aCurvos aCurvos aCurvos lado1 double protected aCuadrilateros lado2 double protected aCuadrilateros lado3 double protected aCuadrilateros lado4 double protected aCuadrilateros altura double aElemGeo metrico double double double double double double double double double poligono arealat areatot volumen areabase perimbase apotemalat apotemabase radio aristalat protected protected protected protected protected protected protected protected protected protected protected protected Clase_Funcion aConicas(double) aConicas area() perimetro() circunferencia() semiperimetro() excentricidad() aConicas(double, double, double, double) aConicas(double, double, double, double) aConicas(double, double, double, double) aConicas(double, double, double, double) c() aParalelogramos(double) aParalelogramos(double) aParalelogramos(double) aParalelogramos(double) altura() area() apotema() diagonal() diagonales() perimetro() semiperimetro() circircuns() cCirculo cCirculo cElipse cCirculo cElipse aCurvos(double, double) aCurvos(double, double) area() areabase() areabase() volumen() generatriz() aCurvos(double) aParalelogramos(double, double) aParalelogramos(double, double) aParalelogramos(double, double) aParalelogramos(double, double) aCurvos aCurvos cCilindro cCono cCilindro cCilindro cCono aCurvos arealat() area() volumen() cPiramides cPiramides cPiramides apotema() cPiramides aristalat() cPiramides aConicas aConicas aConicas aConicas cElipse aParalelogramos aParalelogramos aParalelogramos aParalelogramos cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado aParalelogramos aParalelogramos aParalelogramos aParalelogramos aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPiramides aPiramides aPiramides aPiramides 127 Anexo B: Descripción de los Casos de Prueba lado double protected aPoliedrosRegulares areatot arealat volumen apotema perimetro double double double double double protected protected protected protected protected aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares lado1 double protected aCuadrilateros lado2 double protected aCuadrilateros lado3 double protected aCuadrilateros lado4 double protected aCuadrilateros lado1 double protected aTriangulos lado2 double protected aTriangulos lado3 double protected aTriangulos altura area semiperimetro perimetro circircuns cirinsc double double double double double double protected protected protected protected protected protected aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos lado1 double protected aTriangulos lado2 double protected aTriangulos lado3 double protected aTriangulos lado1 lado2 lado3 areatot arealat volumen radio radio diagonal lado1 altura apotema area diagonal diagonales perimetro semiperimetro radio areatot arealat volumen apotema perimetro area perimetro lado1 altura apotema double double double double double double double double double double double double double double double double double double double double double double double double double double double double protected protected protected protected protected protected protected protected aTriangulos aTriangulos aTriangulos aCurvos aCurvos aCurvos aCuadrilateros aCuadrilateros cCubo cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aConicas aConicas cEneagono cEneagono cEneagono 128 protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected aPoliedrosRegulares(dou ble) area() arealat() volumen() apotema() perimetro() aTrapecios(double, double, double) aTrapecios(double, double, double) aTrapecios(double, double, double) aTrapecios(double, double, double) aTriangulos(double, double, double) aTriangulos(double, double, double) aTriangulos(double, double, double) altura() area() semiperimetro() perimetro() circircuns(double) cirinsc(double) aTriangulos(double, double) aTriangulos(double, double) aTriangulos(double, double) aTriangulos(double) aTriangulos(double) aTriangulos(double) area() arealat() volumen() cirinsc() radio() diagonal() cDecagono(double) altura() apotema() area() diagonal() diagonales() perimetro() semiperimetro() radio() area() arealat() volumen() apotema() perimetro() area() perimetro() cEneagono(double) altura() apotema() aPoliedrosRegulares cCubo cCubo cCubo cCubo cCubo aTrapecios aTrapecios aTrapecios aTrapecios aTriangulos aTriangulos aTriangulos cTrianguloEquilatero aTriangulos aTriangulos cTrianguloEquilatero aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos cCono cCono cCono cCuadrado cCuadrado cCubo cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDodecaedro cDodecaedro cDodecaedro cDodecaedro cDodecaedro cElipse cElipse cEneagono cEneagono cEneagono Anexo B: Descripción de los Casos de Prueba area diagonal diagonales perimetro semiperimetro radio areatot arealat areabase volumen lado1 altura apotema area diagonal diagonales perimetro semiperimetro radio lado1 altura apotema area diagonal diagonales perimetro semiperimetro radio areatot arealat volumen apotema perimetro diagonal areatot arealat volumen apotema perimetro lado1 altura apotema area diagonal diagonales perimetro semiperimetro radio lado1 altura apotema area diagonal diagonales perimetro semiperimetro radio apotemalat areatot arealat double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono aCurvos aCurvos aCurvos aCurvos cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares cOctaedro aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono aPiramides aPoliedrosIrregulares aPoliedrosIrregulares area() diagonal() diagonales() perimetro() semiperimetro() radio() area() arealat() areabase() volumen() cHeptagono(double) altura() apotema() area() diagonal() diagonales() perimetro() semiperimetro() radio() cHexagono(double) altura() apotema() area() diagonal() diagonales() perimetro() semiperimetro() radio() area() arealat() volumen() apotema() perimetro() diagonal() area() arealat() volumen() apotema() perimetro() cOctagono(double) altura() apotema() area() diagonal() diagonales() perimetro() semiperimetro() radio() cPentagono(double) altura() apotema() area() diagonal() diagonales() perimetro() semiperimetro() radio() arealat() area() arealat() cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono cEsfera cEsfera cEsfera cEsfera cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cIcosaedro cIcosaedro cIcosaedro cIcosaedro cIcosaedro cOctaedro cOctaedro cOctaedro cOctaedro cOctaedro cOctaedro cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPiramides cPrismas cPrismas 129 Anexo B: Descripción de los Casos de Prueba volumen area perimetro diagonal diagonales semiperimetro altura apotema apotema diagonalmayor diagonalmenor altura perimetro semiperimetro area diagonales area altura semiperimetro diagonales perimetro areatot arealat volumen apotema perimetro area altura semiperimetro diagonal diagonales perimetro area altura semiperimetro diagonal diagonales perimetro area altura lado4 semiperimetro diagonal diagonales perimetro double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double double protected protected protected protected protected protected protected protected public public protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected protected aPoliedrosIrregulares aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros cRombo cRombo aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros lado1 double protected aCuadrilateros lado2 double protected aCuadrilateros lado3 double protected aCuadrilateros lado4 double protected aCuadrilateros semiperimetro diagonales perimetro apotema altura perimetro perimetro double double double double double double double protected protected protected public protected protected protected aCuadrilateros aCuadrilateros aCuadrilateros cTrianguloEquilatero aTriangulos aTriangulos aTriangulos 130 volumen() area() perimetro() diagonal() diagonales() semiperimetro() altura() apotema() apotema() diagonalmayor() diagonalmenor() altura() perimetro() semiperimetro() area() diagonales() area() altura() semiperimetro() diagonales() perimetro() area() arealat() volumen() apotema() perimetro() area() altura() semiperimetro() diagonal() diagonales() perimetro() area() altura() semiperimetro() diagonal() diagonales() perimetro() area() altura() ladooblicuo() semiperimetro() diagonal() diagonales() perimetro() cTrapezoide(double, double, double, double) cTrapezoide(double, double, double, double) cTrapezoide(double, double, double, double) cTrapezoide(double, double, double, double) semiperimetro() diagonales() perimetro() apotema() altura() perimetro() perimetro() cPrismas cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRombo cRombo cRombo cRombo cRombo cRombo cRombo cRomboide cRomboide cRomboide cRomboide cRomboide cTetraedro cTetraedro cTetraedro cTetraedro cTetraedro cTrapecio cTrapecio cTrapecio cTrapecio cTrapecio cTrapecio cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrianguloEquilatero cTrianguloEscaleno cTrianguloEscaleno cTrianguloIsosceles Anexo B: Descripción de los Casos de Prueba altura double Firma altura() ladooblicuo() apotema() area() radio() cirinsc() cirinsc(double) circircuns() circircuns(double) circunferencia() diagonal() diagonales() diametro() figinscir() perimetro() semiperimetro() c() focos() excentricidad() arealat() volumen() areabase() generatriz() aristalat() altura() apotema() area() cirinsc() cirinsc(double) circircuns() circircuns(double) circunferencia() diagonal() diagonales() diametro() figinscir() ladooblicuo() perimetro() semiperimetro() c() focos() excentricidad() perimetro() semiperimetro() area() diametro() circunferencia() figinscir() circircuns() c() focos() excentricidad() altura() apotema() protected aTriangulos altura() cTrianguloIsosceles Tabla 13. Resultado del MOO2MVA-CP-01: Tabla Funciones abstractas Especificador Tipo_Retorno Clase Patron_MVC public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract void void double double double void void void void void void void void void double void void void void void void void void void void double double void void void void void void void void void void double void void void void double void double void void void void void void void void double aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aElemGeometrico aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aFigura aConicas aConicas aConicas aConicas aConicas aConicas aConicas aConicas aConicas aConicas aPoligonos aPoligonos Vista Vista Modelo No especializada Modelo Vista Vista Vista Vista Vista Vista Vista Vista Vista No especializada Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Modelo No especializada Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista No especializada No especializada Vista Vista Vista No especializada No especializada No especializada Vista No especializada No especializada No especializada Vista Vista Vista No especializada No especializada 131 Anexo B: Descripción de los Casos de Prueba area() cirinsc() circircuns() diagonal() diagonales() figinscir() perimetro() semiperimetro() radio() area() apotema() altura() semiperimetro() diagonal() diagonales() perimetro() figinscir() circircuns() cirinsc() area() arealat() volumen() apotema() diagonal() perimetro() areabase() aristalat() area() arealat() areabase() volumen() area() apotema() altura() semiperimetro() diagonal() diagonales() perimetro() circircuns() cirinsc() figinscir() area() arealat() volumen() apotema() perimetro() diagonal() areabase() aristalat() area() arealat() volumen() apotema() aristalat() apotema() aristalat() arealat() area() volumen() area() 132 public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract double void void void void void double void double double double void void void void double void void void double void void double void double void void double void void void double double void void void void double void void void double void void double double void void void double void void double void double void void double void double aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuadrilateros aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCurvos aCurvos aCurvos aCurvos aParalelogramos aParalelogramos aParalelogramos aParalelogramos aParalelogramos aParalelogramos aParalelogramos aParalelogramos aParalelogramos aParalelogramos aPoliedros aPoliedros aPoliedros aPoliedros aPoliedros aPoliedros aPoliedros aPoliedros aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPiramides aPiramides aPiramides aPiramides aPiramides aPoliedrosRegulares No especializada Vista Vista Vista Vista Vista No especializada No especializada Modelo No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista Vista Vista No especializada No especializada No especializada No especializada Vista No especializada Vista Vista No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Modelo Modelo Vista Vista Vista No especializada No especializada No especializada Modelo Vista No especializada No especializada No especializada No especializada No especializada No especializada Anexo B: Descripción de los Casos de Prueba arealat() volumen() apotema() perimetro() diagonal() area() arealat() volumen() area() altura() semiperimetro() diagonal() diagonales() perimetro() perimetro() apotema() altura() Firma arealat() volumen() areabase() generatriz() aristalat() radio() altura() apotema() cirinsc() cirinsc(double) circircuns(double) diagonal() diagonales() ladooblicuo() circunferencia() cirinsc(double) circircuns(double) diametro() ladooblicuo() c() focos() excentricidad() circircuns(double) cirinsc(double) radio() altura() ladooblicuo() cirinsc() cirinsc(double) circircuns() circircuns(double) circunferencia() diagonales() diametro() figinscir() semiperimetro() c() focos() public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract public abstract void void double double void double void void double void void void void double double double void aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPrismas aPrismas aPrismas aTrapecios aTrapecios aTrapecios aTrapecios aTrapecios aTrapecios aTriangulos aTriangulos aTriangulos No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Tabla 14. Resultado del MOO2MVA-CP-01: Tabla Funciones concretas Especificador Tipo_Retorno Clase Patron_MVC public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public void void void void void double void double void void void void void void void void void void void void void void void void double void void void void void void void void void void void void void aFigura aFigura aFigura aFigura aFigura aFigura aConicas aConicas aConicas aConicas aConicas aConicas aConicas aConicas aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aCuadrilateros aCuadrilateros aCuadrilateros aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo aCuerpo Vista Vista Vista Vista Vista Modelo Vista Modelo Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Modelo Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista Vista 133 Anexo B: Descripción de los Casos de Prueba excentricidad() generatriz() radio() generatriz() diagonal() aristalat() apotema() perimetro() diagonal() areabase() perimetro() areabase() aristalat() apotema() aristalat() apotema() figinscir() circircuns() cirinsc() diagonales() circircuns() cirinsc() figinscir() diagonal() radio() area() semiperimetro() circircuns(double) cirinsc(double) area() arealat() areabase() volumen() area() perimetro() diametro() circunferencia() semiperimetro() figinscir() circircuns() c() focos() excentricidad() area() arealat() areabase() volumen() generatriz() altura() semiperimetro() diagonal() diagonales() apotema() area() perimetro() figinscir() circircuns() cirinsc() radio() area() 134 public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public void void double void void void double double void void double void void double void double void void void void void void void void double double void void void double void void void double double void void void void void void void void double void void void void void void void void double double double void void void double double aCuerpo aCuerpo aCuerpo aCurvos aCurvos aCurvos aCurvos aCurvos aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosRegulares aPoliedrosRegulares aPrismas aPrismas aTrapecios aTrapecios aTrapecios aTrapecios aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos aTriangulos cCilindro cCilindro cCilindro cCilindro cCirculo cCirculo cCirculo cCirculo cCirculo cCirculo cCirculo cCirculo cCirculo cCirculo cCono cCono cCono cCono cCono cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCuadrado cCubo Vista Vista Modelo Vista Vista Vista No especializada No especializada Vista Vista Modelo Vista Vista Modelo Vista No especializada Vista Vista Vista Vista Vista Vista Vista Vista Modelo No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada No especializada No especializada Vista Vista Vista No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Modelo No especializada Anexo B: Descripción de los Casos de Prueba arealat() volumen() diagonal() apotema() perimetro() altura() apotema() area() cirinsc() circircuns() radio() diagonal() diagonales() figinscir() perimetro() semiperimetro() area() arealat() volumen() apotema() perimetro() diagonal() c() focos() area() perimetro() excentricidad() semiperimetro() diametro() circunferencia() figinscir() circircuns() altura() apotema() area() cirinsc() circircuns() radio() diagonal() diagonales() figinscir() perimetro() semiperimetro() area() arealat() areabase() volumen() altura() apotema() area() cirinsc() circircuns() radio() diagonal() diagonales() figinscir() perimetro() semiperimetro() altura() apotema() public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public void void void double double void double double void void double void void void double void double void void double double void void void double double void void void void void void void double double void void double void void void double void double void void void void double double void void double void void void double void void double cCubo cCubo cCubo cCubo cCubo cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDecagono cDodecaedro cDodecaedro cDodecaedro cDodecaedro cDodecaedro cDodecaedro cElipse cElipse cElipse cElipse cElipse cElipse cElipse cElipse cElipse cElipse cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono cEneagono cEsfera cEsfera cEsfera cEsfera cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHeptagono cHexagono cHexagono No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada Vista Modelo No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada 135 Anexo B: Descripción de los Casos de Prueba area() cirinsc() circircuns() radio() diagonal() diagonales() figinscir() perimetro() semiperimetro() area() arealat() volumen() apotema() perimetro() diagonal() area() arealat() volumen() apotema() perimetro() diagonal() altura() apotema() area() cirinsc() circircuns() radio() diagonal() diagonales() figinscir() perimetro() semiperimetro() altura() apotema() area() cirinsc() circircuns() radio() diagonal() diagonales() figinscir() perimetro() semiperimetro() apotema() aristalat() arealat() area() volumen() area() arealat() volumen() area() perimetro() diagonal() circircuns() cirinsc() figinscir() diagonales() semiperimetro() altura() 136 public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public double void void double void void void double void double void void double double void double void void double double void void double double void void double void void void double void void double double void void double void void void double void double void void double void double void void double double void void void void void void void cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cHexagono cIcosaedro cIcosaedro cIcosaedro cIcosaedro cIcosaedro cIcosaedro cOctaedro cOctaedro cOctaedro cOctaedro cOctaedro cOctaedro cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cOctagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPentagono cPiramides cPiramides cPiramides cPiramides cPiramides cPrismas cPrismas cPrismas cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo cRectangulo No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada No especializada Anexo B: Descripción de los Casos de Prueba apotema() altura() perimetro() semiperimetro() diagonalmayor() diagonalmenor() area() figinscir() apotema() cirinsc() circircuns() diagonal() diagonales() area() apotema() altura() semiperimetro() diagonal() diagonales() perimetro() circircuns() cirinsc() figinscir() area() arealat() volumen() apotema() diagonal() perimetro() area() altura() semiperimetro() diagonal() diagonales() perimetro() area() altura() semiperimetro() diagonal() diagonales() perimetro() area() altura() ladooblicuo() semiperimetro() diagonal() diagonales() perimetro() area() apotema() altura() semiperimetro() diagonal() diagonales() perimetro() figinscir() circircuns() cirinsc() perimetro() apotema() public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public public double void double void void void double void double void void void void double double void void void void double void void void double void void double void double double void void void void double double void void void void double double void void void void void double double double void void void void double void void void double double cRectangulo cRombo cRombo cRombo cRombo cRombo cRombo cRombo cRombo cRombo cRombo cRombo cRombo cRomboide cRomboide cRomboide cRomboide cRomboide cRomboide cRomboide cRomboide cRomboide cRomboide cTetraedro cTetraedro cTetraedro cTetraedro cTetraedro cTetraedro cTrapecio cTrapecio cTrapecio cTrapecio cTrapecio cTrapecio cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioIsosceles cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapecioRectangulo cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrapezoide cTrianguloEquilatero cTrianguloEquilatero No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista No especializada Vista Vista Modelo No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada Vista Vista Vista No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada Vista Vista Vista No especializada No especializada 137 Anexo B: Descripción de los Casos de Prueba altura() altura() perimetro() apotema() apotema() perimetro() altura() public public public public public public public void void double double double double void cTrianguloEquilatero cTrianguloEscaleno cTrianguloEscaleno cTrianguloEscaleno cTrianguloIsosceles cTrianguloIsosceles cTrianguloIsosceles No especializada No especializada No especializada No especializada No especializada No especializada No especializada Tabla 15. Resultado del MOO2MVA-CP-01: Tabla Tipos de Clases Nombre aElemGeometrico aFigura aConicas aPoligonos aCuadrilateros aCuerpo aCurvos aParalelogramos aPoliedros aPoliedrosIrregulares aPiramides aPoliedrosRegulares aPrismas aTrapecios aTriangulos cCilindro cCirculo cCono cCuadrado cCubo cDecagono cDodecaedro cElipse cEneagono cEsfera cHeptagono cHexagono cIcosaedro cOctaedro cOctagono cPentagono cPiramides cPrismas cRectangulo cRombo cRomboide cTetraedro cTrapecio cTrapecioIsosceles cTrapecioRectangulo cTrapezoide cTrianguloEquilatero cTrianguloEscaleno cTrianguloIsosceles 138 Paquete FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas FiugrasGeometricas Tipo abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta concreta Tipo_Relacion1 Clase_Base1 extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends extends aElemGeometrico aFigura aFigura aPoligonos aElemGeometrico aCuerpo aCuadrilateros aCuerpo aPoliedros aPoliedrosIrregulares aPoliedros aPoliedrosIrregulares aCuadrilateros aPoligonos aCurvos aConicas aCurvos aParalelogramos aPoliedrosRegulares aPoligonos aPoliedrosRegulares aConicas aPoligonos aCurvos aPoligonos aPoligonos aPoliedrosRegulares aPoliedrosRegulares aPoligonos aPoligonos aPiramides aPrismas aParalelogramos aParalelogramos aParalelogramos aPoliedrosRegulares aTrapecios aTrapecios aTrapecios aCuadrilateros aTriangulos aTriangulos aTriangulos Patron_MVC No especializada No especializada No especializada Vista No especializada No especializada No especializada No especializada No especializada No especializada No especializada Vista No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada No especializada Anexo B: Descripción de los Casos de Prueba Caso de prueba MOO2MVA-CP-02 a) Especificación de entrada Los elementos de entrada para probar la correcta funcionalidad del método R7: “Estructura jerárquica de clases” son: La tabla “Tipos de Clases” resultante de aplicar el método R1 (MOO2MVA-CP-01) con los datos almacenados del MOO Figuras Geométricas. b) Especificación de salida El resultado de la ejecución del método R7, de acuerdo a la entrada descrita anteriormente es: La tabla “Jerarquía de Clases” con la estructura jerárquica del MOO. Dicha tabla se muestra a continuación. Tabla 16. Resultado del MOO2MVA-CP-02: Tabla Jerarquía de Clases ClasePadre ClaseHija ClasePadre ClaseHija aElemGeometrico aElemGeometrico aFigura aFigura aCuerpo aCuerpo aConicas aConicas aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aPoligonos aCurvos aCurvos aCurvos aPoliedros aPoliedros cCirculo cElipse aCuadrilateros aCuadrilateros aCuadrilateros aTriangulos aTriangulos aTriangulos cDecagono cEneagono cHeptagono cHexagono cOctagono cPentagono cCilindro aFigura aCuerpo aConicas aPoligonos aCurvos aPoliedros cCirculo cElipse aCuadrilateros aTriangulos cDecagono cEneagono cHeptagono cHexagono cOctagono cPentagono cCilindro cCono cEsfera aPoliedrosIrregulares aPoliedrosRegulares Sin subclases Sin subclases aParalelogramos aTrapecios cTrapezoide cTrianguloEquilatero cTrianguloEscaleno cTrianguloIsosceles Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases cCono cEsfera aPoliedrosIrregulares aPoliedrosIrregulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aPoliedrosRegulares aParalelogramos aParalelogramos aParalelogramos aParalelogramos aTrapecios aTrapecios aTrapecios cTrapezoide cTrianguloEquilatero cTrianguloEscaleno cTrianguloIsosceles aPiramides aPrismas cCubo cDodecaedro cIcosaedro cOctaedro cTetraedro cCuadrado cRectangulo cRombo cRomboide cTrapecio cTrapecioIsosceles cTrapecioRectangulo cPiramides cPrismas Sin subclases Sin subclases aPiramides aPrismas cCubo cDodecaedro cIcosaedro cOctaedro cTetraedro cCuadrado cRectangulo cRombo cRomboide cTrapecio cTrapecioIsosceles cTrapecioRectangulo Sin subclases Sin subclases Sin subclases Sin subclases cPiramides cPrismas Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases Sin subclases 139 Anexo B: Descripción de los Casos de Prueba Caso de prueba MOO2MVA-CP-03 a) Especificación de entrada Los elementos de entrada para probar la correcta funcionalidad del método R2: “Crear clases” son: Nombre del paquete, nombre de la clase, tipo de clase, tipo de relación 1, clase base 1, tipo de relación 2 y clase base2. Instancia 1 o Nombre del paquete: Prueba o Nombre de la clase: cClasePrueba1 o Tipo de clase: concreta Instancia 2 o Nombre del paquete: Prueba o Nombre de la clase: cClasePrueba2 o Tipo de clase: concreta o Tipo de relación 1: extends o Clase base 1: aAbstracta2 Instancia 3 o Nombre del paquete: Prueba o Nombre de la clase: cClasePrueba3 o Tipo de clase: concreta o Tipo de relación 1: implements o Clase base 1: iInterfaz3 Instancia 4 o Nombre del paquete: Prueba o Nombre de la clase: cClasePrueba4 o Tipo de clase: concreta o Tipo de relación 1: extends o Clase base 1: aAbstracta5 o Tipo de relación 2: implements o Clase base 2: iInterfaz5 Instancia 5 o Nombre del paquete: Prueba o Nombre de la clase: aAbstractaPrueba5 o Tipo de clase: abstract Instancia 6 o Nombre del paquete: Prueba o Nombre de la clase: aAbstractaPrueba6 o Tipo de clase: abstract o Tipo de relación 1: extends o Clase base 1: aAbstracta6 140 Instancia 7 Anexo B: Descripción de los Casos de Prueba o o o o o Nombre del paquete: Prueba Nombre de la clase: aAbstractaPrueba7 Tipo de clase: abstract Tipo de relación 1: implements Clase base 1: iInterfaz7 Instancia 8 o Nombre del paquete: Prueba o Nombre de la clase: iInterfazPrueba8 o Tipo de clase: interface Instancia 9 o Nombre del paquete: Prueba o Nombre de la clase: iInterfazPrueba9 o Tipo de clase: interface o Tipo de relación 1: extends o Clase base 1: iInterfaz9 b) Especificación de salida El resultado de la ejecución del método R2, son las clases creadas de acuerdo a las entradas descritas anteriormente. A continuación se muestran los resultados. Instancia 1 Instancia 2 Instancia 3 Instancia 4 Figura 39. Resultado del MOO2MVA-CP-03: Instancia 1 Figura 40. Resultado del MOO2MVA-CP-03: Instancia 2 Figura 41. Resultado del MOO2MVA-CP-03: Instancia 3 Figura 42. Resultado del MOO2MVA-CP-03: Instancia 4 141 Anexo B: Descripción de los Casos de Prueba Instancia 5 Instancia 6 Instancia 7 Figura 43. Resultado del MOO2MVA-CP-03: Instancia 5 Figura 44. Resultado del MOO2MVA-CP-03: Instancia 6 Figura 45. Resultado del MOO2MVA-CP-03: Instancia 7 Instancia 8 Instancia 9 Figura 46. Resultado del MOO2MVA-CP-03: Instancia 8 Figura 47. Resultado del MOO2MVA-CP-03: Instancia 9 Caso de prueba MOO2MVA-CP-04 a) Especificación de entrada Los elementos de entrada para probar la correcta funcionalidad del método R3: “Crear constructor” son: Nombre de la clase a la que se le desea agregar el constructor; para un constructor con parámetros se tiene que enviar una lista con dichos parámetros y para copiar un constructor, el nombre de la clase de la cual se desea copiar el constructor. 142 Instancia 1 o Nombre de la clase donde se creará el constructor: cCuboM Instancia 2 o Nombre de la clase donde se creará el constructor: cCuboM o Parámetros: Tipo: double Id Parámetro: diagonal Variable a inicializar: diagonal Anexo B: Descripción de los Casos de Prueba Instancia 3 o Nombre de la clase donde se creará el constructor: cCuboM o Nombre de la Clase de donde se copiará: cCubo (CJ20) A continuación se muestra la clase desde la cual se desea copiará el constructor. Figura 48. Constructor en la clase cCubo b) Especificación de salida El resultado de la ejecución del método R3, son clases a las que se les ha agregado un constructor de acuerdo a las entradas descritas anteriormente, las clases se muestran a continuación. Instancia 1 Figura 49. Resultado del MOO2MVA-CP-04: Instancia 1 Instancia 2 Instancia 3 Figura 50. Resultado del MOO2MVA-CP-04: Instancia 2 Figura 51. Resultado del MOO2MVA-CP-04: Instancia 3 143 Anexo B: Descripción de los Casos de Prueba Caso de prueba MOO2MVA-CP-05 a) Especificación de entrada Los elementos de entrada para probar la correcta funcionalidad del método R5: “Reubicar atributos” son: el archivo java al que se le desean copiar atributos y la tabla “Variables MVA” con registros que en la columna “Clase” coincidan con el nombre del archivo java. La clase cCuadradoa la que se le desea reubicar atributos se muestra en la siguiente figura. Figura 52. Clase cCuadradoC en donde se reubicarán atributos Los datos de entrada en la tabla “Variables MVA” se muestran en la siguiente tabla. Tabla 17. Tabla Variables MVA para el caso de prueba MOO2MVA-CP-05 Identificador Tipo Especificador Clase altura area apotema diagonal diagonales perimetro semiperimetro radio double double double double double double double double protected protected protected protected protected protected protected protected cCuadradoC cCuadradoC cCuadradoC cCuadradoC cCuadradoC cCuadradoC cCuadradoC cCuadradoC b) Especificación de salida El resultado de la ejecución del método R5, es la clase cCuadradoC con los atributos reubicados, como se muestra a continuación en la Figura 53. Figura 53. Resultado del MOO2MVA-CP-05: clase cCuadradoC 144 Anexo B: Descripción de los Casos de Prueba Caso de prueba MOO2MVA-CP-06 a) Especificación de entrada Los elementos de entrada para probar la correcta funcionalidad del método R4: “Crear funciones” son: Nombre de la clase a la que se le desea agregar la función, firma de la función, especificador de acceso de la función, parte del patrón MVA a la que pertenece la función, el tipo de retorno, en caso de que sea necesario la variable o valor de retorno, y un vector con los estatutos de la función. Instancia 1 o Nombre de la clase donde se creará la función: cRectanguloM o Firma de la función: diagonalM() o Especificador de acceso de la función: public o Patrón MVA: Modelo o Tipo de retorno: double o Variable de retorno: diagonal o Vector “double par1, par2, par3;” “par1=lado1*lado1;” “par2=lado2*lado2;” “par3=par1+par2;” “diagonal=Math.round(Math.sqrt(par3)*100)/100;” A continuación se muestra la clase en dónde se desea copiar la función anteriormente descrita Figura 54. Clase cRectanguloM donde se copiará una función sin parámetros Instancia 2 o Nombre de la clase donde se creará el constructor: cRectanguloV o Firma de la función: diagonalV(double) o Especificador de acceso de la función: public o Patrón MVA: Vista o Tipo de retorno: void o Vector “System.out.println(\”La diagonal del rectangulo es \”+diagonal);” A continuación se muestra la clase en dónde se desea copiar la función anteriormente descrita 145 Anexo B: Descripción de los Casos de Prueba Figura 55. Clase cRectanguloV donde se copiará una función con parámetros b) Especificación de salida El resultado de la ejecución del método R4 son clases con una función agregada, de acuerdo a las entradas descritas anteriormente. Y la información de la nueva función agregada correctamente en la tabla “Funciones Concretas MVA”. Las salidas de las distintas instancias se muestran a continuación. Instancia 1 Figura 56. Resultado del MOO2MVA-CP-06: Instancia 1 Tabla 18. Resultado del MOO2MVA-CP-06: Instancia 1, tabla Funciones Concretas MVA Firma Especificador Tipo_Retorno Clase Patron_MVA diagonalM() public Modelo double cRectanguloM Instancia 2 Figura 57. Resultado del MOO2MVA-CP-06: Instancia 2 Tabla 19. Resultado del MOO2MVA-CP-06: Instancia 2, tabla Funciones Concretas MVA 146 Firma Especificador Tipo_Retorno Clase Patron_MVA diagonalV(double) public Vista void cRectanguloV