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í.
i
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. Modelo Conceptual del Sistema ............................................................................... 37
4.1 Diseño del Proceso de Refactorización ............................................................................. 37
Contenido
ii
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
iii
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
v
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
Lista de Figuras
vi
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
vii
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
Glosario de Términos
viii
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.
Glosario de Términos
ix
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
Es el entorno de software común en el cual se desenvuelve la programación de un grupo definido de aplicaciones.
Reuso 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.
xi
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.
xiii
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.
Introducción
1
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.
Capítulo 1
2
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 Modelo-
Vista-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.
Introducción
3
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
Capítulo 1
4
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:
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
5
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.
Antecedentes
7
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-Vista-
Controlador” [NUÑE,08]. A continuación se hace una breve descripción de las diferentes
investigaciones.
Capítulo 2
8
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
Antecedentes
9
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.
Capítulo 2
10
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.
Antecedentes
11
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.
Capítulo 2
12
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
Antecedentes
13
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 cliente-
servidor.
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
Capítulo 2
14
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
Antecedentes
15
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.
Capítulo 2
16
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.
Antecedentes
17
Tabla 1. Comparación de trabajos relacionados.
Proyecto/Atributo
Tipo de proyecto Arquitectura resultante
Entradas Salidas Es Automática Lenguaje
[PING,04] Marco de reingeniería
MVC centrado en el controlador
Páginas JSP JavaBeans, JSP y Java Servlets
Sí, el usuario no interviene directamente.
Java
[AVER,01] Metodología Cliente-Servidor (Vista-Modelo)
Código COBOL, Grafos de llamada
ASP, VBScript y Librerías Dinámicas de ASP
No, es manual. Se sigue la metodología MORPH para la separación de código.
Metodología MORPH
[DIST,06] Metodología Cliente servidor (Vista-Modelo)
Visual Basic 5 Código Visual Basic y HTML
No, es manual. Metodología UWAT+
[ABAD,08] Caso de estudio MVC Java Servlets Código Java No, es semiautomática, pues utilizaron el soporte de reestructuración de la IDE Eclipse
Soporte de la IDE Eclipse
[BODH,02] Estrategia y herramientas
MVC Código COBOL JSP, XML Sí, el usuario no interviene directamente.
Java
Tesis (MOO2MVA)
Herramienta MVA (Variante de MVC)
Código Java Código Java refactorizado
Sí, el usuario elige el proyecto a refactorizar y el sistema lo hace automáticamente.
Java
Capítulo 2
18
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 (Cliente-
Servidor) 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.
Marco Teórico
19
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.
Capítulo 3
20
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.
Marco Teórico
21
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
Capítulo 3
22
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
Marco Teórico
23
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.
Capítulo 3
24
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:
Marco Teórico
25
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
Capítulo 3
26
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.
Tabla 2. Descripción del patrón MVC y sus variaciones.
Patrón 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ón-Abstracción-Control (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.
Marco Teórico
27
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.
Capítulo 3
28
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.
Marco Teórico
29
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
Capítulo 3
30
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.
Marco Teórico
31
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.
Capítulo 3
32
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
Marco Teórico
33
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.
Capítulo 3
34
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.
Marco Teórico
35
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.
Modelo Conceptual del Sistema
37
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.
Capítulo 4
38
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 no-
especializadas 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: N-esima actividad del proceso de refactorización.
Rn: 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.
Modelo Conceptual del Sistema
39
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.
Capítulo 4
40
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.
Modelo Conceptual del Sistema
41
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:
Capítulo 4
42
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
Tipos de clases
Campo Descripción
Nombre Nombre de la clase identificada durante el análisis de código.
Paquete Nombre del paquete al que pertenece la clase identificada.
Tipo Tipo de la clase, puede ser “concreta”, “abstract” o “interface”.
Tipo Relación 1 Primer tipo de relación que mantiene la clase, puede ser ninguna, “extends” (herencia) o “implements” (implementación).
Clase Base 1 Nombre de la clase con la cual se tiene la relación establecida en el campo Tipo Relación 1.
Tipo Relación 2 Segundo tipo de relación que mantiene la clase, puede ser ninguna, “extends” (herencia) o “implements” (implementación).
Modelo Conceptual del Sistema
43
Clase Base 2 Nombre de la clase con la cual se tiene la relación establecida en el campo Tipo Relación 2.
Patrón MVC 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
Funciones abstractas
Campo Descripción
Firma Firma de la función abstracta que ha sido detectada durante el análisis de código.
Especificador Especificador de acceso de la función abstracta.
Tipo de retorno Tipo del valor de retorno de la función abstracta.
Clase Nombre de la clase a la que pertenece la función abstracta.
Patrón MVC 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 Retorno
Nombre de la variable que se utiliza para realizar el 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
Tipos de Variables
Campo Descripción
Identificador Identificador de la variable detectada durante el análisis de código.
Tipo Tipo de la variable.
Especificador Especificador de acceso de la variable.
Clase Variable Nombre de la clase en donde fue declarada la variable.
Firma Función Firma de la función de donde se accede a la variable.
Clase Función 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”
Modelo Conceptual del Sistema
45
Figura 10. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 2)
Modelo Conceptual del Sistema
47
Figura 12. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 4)
Modelo Conceptual del Sistema
49
Figura 14. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 6)
Capítulo 4
50
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.
Modelo Conceptual del Sistema
51
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.
Capítulo 4
52
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
Jerarquía de Clases
Campo Descripción
Clase Padre Nombre de la clase que se está analizando, todas las clases del MOO aparecen al menos una vez en este campo.
Clase Hija Nombre de la clase que extiende o implemente a la clase padre, puede ser ninguna.
Modelo Conceptual del Sistema
53
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.
Capítulo 4
54
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.
Capítulo 4
56
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.
Modelo Conceptual del Sistema
57
Figura 18. Diagrama de Actividad del Método R3: “Crear constructor”
Capítulo 4
58
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:
Tabla 8. Descripción de la tabla Variables MVA
Variables MVA
Campo Descripción
Identificador Identificador de la variable a reubicar.
Tipo Tipo de la variable.
Especificador Especificador de acceso de la variable.
Valor Valor contenido en la variable.
Función 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.
Modelo Conceptual del Sistema
59
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.
Capítulo 4
60
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.
Implementación del Sistema
63
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.
Capítulo 5
64
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.
Implementación del Sistema
65
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.
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
class InterfazGrafica
ActionListener
ControladorEv entos
~ 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>
JFrame
IGUMOO2MVA
+ bAbrir: JButton
+ bAgregarClase: JButton
+ bEstablecer: JButton
+ bIniciar: JButton
+ 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
+ IGUMOO2MVA()
- initComponents() : void
+ main(String[]) : void
FileFilter
Jav aFilter
+ accept(File) : boolean
+ getDescription() : String
Utils
+ java: String = "java" {readOnly}
# createImageIcon(String) : ImageIcon
+ getExtension(File) : String
~ventana
class Adaptador
OrquestadorAplicacion
+ orquestarAplicacion(LinkedList<File>, File) : String
Capítulo 5
66
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.
Implementación del Sistema
67
Figura 27. Diagrama de clases del paquete MOO2MVA.baseDatos
class baseDatos
ClaseAdaptador
- bd: ConectorBD
- Clase_Base1: String
- Clase_Base2: String
- id: String
- Nombre: String
- Tipo: String
- Tipo_Relacion1: String
- Tipo_Relacion2: String
ClaseModelo
- bd: ConectorBD
- Clase_Base1: String
- Clase_Base2: String
- id: String
- Nombre: String
- Tipo: String
- Tipo_Relacion1: String
- Tipo_Relacion2: String
ClasesVistaUI
- bd: ConectorBD
- clase: String
- id: String
- paquete: String
ClaseVista
- bd: ConectorBD
- Clase_Base1: String
- Clase_Base2: String
- id: String
- Nombre: String
- Tipo: String
- Tipo_Relacion1: String
- Tipo_Relacion2: String
ConectorBD
- cp: ConnectionPool = null
- driver: String
- nombreBD: String
- password: String
- url: String
- usuario: String
+ close() : void
+ ConectorBD(String, String, String, String, String)
+ 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
Runnable
ConnectionPool
- 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
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
FuncionAbstracta
- bd: ConectorBD
- Clase: String
- Especificador: String
- Firma: String
- id: String
- Patron_MVC: String
- Tipo_Retorno: String
FuncionAbstractaMVA
- bd: ConectorBD
- Clase: String
- Especificador: String
- Firma: String
- id: String
- Patron_MVC: String
- Tipo_Retorno: String
FuncionConcreta
- bd: ConectorBD
- Clase: String
- Especificador: String
- Firma: String
- id: String
- Patron_MVC: String
- Tipo_Retorno: String
- Variable_Retorno: String
FuncionConcretaMVA
- bd: ConectorBD
- Clase: String
- Especificador: String
- Firma: String
- id: String
- Patron_MVC: String
- Tipo_Retorno: String
JerarquiaClase
- bd: ConectorBD
- ClaseHija: String
- ClasePadre: String
- id: String
TipoClase
- 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
TipoVariable
- bd: ConectorBD
- Clase_Funcion: String
- Clase_Variable: String
- Especificador: String
- FirmaFuncion: String
- id: String
- Identificador: String
- Tipo: String
VariableMVA
- bd: ConectorBD
- Clase: String
- Especificador: String
- Funcion: String
- id: String
- Identificador: String
- Tipo: String
- Valor: String
-bd-bd-bd-bd -bd-bd-bd
-bd
-bd-bd
-cp
-bd-bd-bd-bd
Capítulo 5
68
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
Implementación del Sistema
69
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
Capítulo 5
70
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.
Implementación del Sistema
71
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.
Capítulo 5
72
Figura 31. Diagrama de clases del paquete MOO2MVA.A1.Analizar.TablaSímbolos
class TablaSimbolos
«interface»
Ambito
+ agregarSimbolo(String, Simbolo) : Simbolo
+ buscarSimbolo(String) : Object
+ getAmbitoEnvolvente() : Ambito
+ getAmbitosPadre() : LinkedList <AmbitoBase>
+ getMiembros() : Map
+ getNombreAmbito() : String
+ removerSimbolo(String) : String
+ setNombreAmbito(String) : void
AmbitoBase
# 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
AmbitoGlobal
+ AmbitoGlobal(String)
AmbitoLocal
+ AmbitoLocal(String, AmbitoBase)
Simbolo
# ambitoEnvolvente: Ambito
# definicion: SLAST
# especificador: String
# nombreSimbolo: String
# tipo: Tipo
+ 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)
SimboloClase
+ getNombreTipo() : String
+ SimboloClase(String, AmbitoBase, String)
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)
SimboloMetodo
+ SimboloMetodo(String, AmbitoBase, Tipo, String)
SimboloPrimitiv o
+ getNombreTipo() : String
+ SimboloPrimitivo()
+ SimboloPrimitivo(String)
SimboloUDT
+ getNombreTipo() : String
+ setAmbitoContenedor(Ambito) : void
+ setNombreSimbolo(String) : void
+ SimboloUDT()
+ SimboloUDT(String)
SimboloVariable
~ nombreClaseExterna: String
+ getNombreSimbolo() : String
+ setAmbitoContenedor(Ambito) : void
+ setNombreSimbolo(String) : void
+ SimboloVariable(String)
+ SimboloVariable(String, Tipo)
+ SimboloVariable(String, Tipo, String)
CommonTree
SLAST
+ patronMVC: String
+ scope: Ambito
+ symbol: Simbolo
+ dupNode() : Tree
+ SLAST()
+ SLAST(Token)
+ SLAST(SLAST)
+ SLAST(Token, Ambito, Simbolo)
SLASTCommonErrorNode
+ input: IntStream
+ start: Token
+ stop: Token
+ trappedException: RecognitionException
+ getText() : String
+ getType() : int
+ isNil() : boolean
+ SLASTCommonErrorNode(TokenStream, Token, Token, RecognitionException)
+ toString() : String
CommonTreeAdaptor
SLASTCommonTreeAdaptor
+ create(Token) : Object
+ dupNode(Object) : Object
+ errorNode(TokenStream, Token, Token, RecognitionException) : Object
«interface»
Tipo
+ getNombreTipo() : String
#ambitoEnvolvente
#definicion
#tipo
+scope
+symbol
~ambitoActual
Implementación del Sistema
73
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 clase
R7EstructurarJerarquiaClases
El diagrama de este paquete se presenta a continuación en la Figura 32.
Pruebas del Sistema
75
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.
Capítulo 6
76
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.
Pruebas del Sistema
77
Tabla 10. Clases de Java a usarse como elementos de prueba
Clases Java
ID Nombre de la clase Descripción
CJ01 aConicas.java Clase abstracta referente a las figuras cónicas.
CJ02 aCuadrilateros.java Clase abstracta referente a los cuadriláteros.
CJ03 aCuerpo.java Clase abstracta referente a los cuerpos.
CJ04 aCurvos.java Clase abstracta referente a los cuerpos curvos.
CJ05 aElemGeometrico.java Clase abstracta referente a los elementos geométricos.
CJ06 aFigura.java Clase abstracta referente a las figuras.
CJ07 aParalelogramos.java Clase abstracta referente a los paralelogramos.
CJ08 aPiramides.java Clase abstracta referente a las pirámides.
CJ09 aPoliedros.java Clase abstracta referente a los poliedros.
CJ10 aPoliedrosIrregulares.java Clase abstracta referente a los poliedros irregulares.
CJ11 aPoliedrosRegulares.java Clase abstracta referente a los poliedros regulares.
CJ12 aPoligonos.java Clase abstracta referente a los polígonos.
CJ13 aPrismas.java Clase abstracta referente a los prismas.
CJ14 aTrapecios.java Clase abstracta referente a los trapecios.
CJ15 aTriangulos.java Clase abstracta referente a los triángulos.
CJ16 cCilindro.java Clase concreta referente a los cilindros.
CJ17 cCirculo.java Clase concreta referente a los círculos.
CJ18 cCono.java Clase concreta referente a los conos.
CJ19 cCuadrado.java Clase concreta referente a los cuadrados.
CJ20 cCubo.java Clase concreta referente a los cubos.
CJ21 cDecagono.java Clase concreta referente a los decágonos.
CJ22 cDodecaedro.java Clase concreta referente a los dodecaedros.
CJ23 cElipse.java Clase concreta referente a los eclipses.
CJ24 cEneagono.java Clase concreta referente a los eneágonos.
CJ25 cEsfera.java Clase concreta referente a las esferas.
CJ26 cHeptagono.java Clase concreta referente a los heptágonos.
CJ27 cHexagono.java Clase concreta referente a los hexágonos.
CJ28 cIcosaedro.java Clase concreta referente a los icosaedros.
CJ29 cOctaedro.java Clase concreta referente a los octaedros.
CJ30 cOctagono.java Clase concreta referente a los octágonos.
CJ31 cPentagono.java Clase concreta referente a los pentágonos.
CJ32 cPiramides.java Clase concreta referente a las pirámides.
CJ33 cPrismas.java Clase concreta referente a los prismas.
CJ34 cRectangulo.java Clase concreta referente a los rectángulos.
CJ35 cRombo.java Clase concreta referente a los rombos.
CJ36 cRomboide.java Clase concreta referente a los romboides.
CJ37 cTetraedro.java Clase concreta referente a los cilindros.
CJ38 cTrapecio.java Clase concreta referente a los trapecios.
CJ39 cTrapecioIsosceles.java Clase concreta referente a los trapecios isósceles.
CJ40 cTrapecioRectangulo.java Clase concreta referente a los trapecios rectángulos.
CJ41 cTrapezoide.java Clase concreta referente a los trapezoides.
CJ42 cTrianguloEquilatero.java Clase concreta referente a los triángulos equiláteros.
CJ43 cTrianguloEscaleno.java Clase concreta referente a los triángulos escalenos.
CJ44 cTrianguloIsosceles.java Clase concreta referente a los triángulos isósceles.
Capítulo 6
78
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”.
Pruebas del Sistema
79
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.
Capítulo 6
80
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 MOO2MVA-DP-01
Pruebas del Sistema
81
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:
Capítulo 6
82
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.
Pruebas del Sistema
83
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
Capítulo 6
84
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”.
Pruebas del Sistema
85
6.5.1 MOO2MVA-CP-01
Número/Nombre Prueba: MOO2MVA-CP-01
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo 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.
Condiciones de Ambiente Ninguna.
Entrada El código del marco orientado a objetos Figuras Geométricas escrito en lenguaje Java (elementos de prueba CJ01- CJ44)
Resultados Esperados 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.
Procedimiento de la Prueba
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
Curso alterno 1 3. Ocurre algún error durante la copia de los archivos de código del MOO.
4. La herramienta notifica del error. 5. Fin.
Curso alterno 2 4. Ocurre algún error durante la etiquetación del código del MOO. 5. La herramienta notifica del error. 6. Fin.
Curso alterno 3 5. Ocurre algún error durante el almacenamiento de información en las tablas.
6. La herramienta notifica del error. 7. Fin.
Excepciones
Post-condiciones 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.
Observaciones Ninguna.
6.5.2 MOO2MVA-CP-02
Número/Nombre Prueba: MOO2MVA-CP-02
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se obtiene y almacena correctamente la estructura
Capítulo 6
86
jerárquica de las clases del MOO.
Condiciones de Ambiente El caso de prueba MOO2MVA-CP-01 se ha ejecutado con éxito anteriormente.
Entrada Tabla “Tipos de Clases” con los datos almacenados del MOO Figuras Geométricas.
Resultados Esperados En la tabla “Jerarquía de Clases” se tiene almacenada la información sobre la jerarquía de clases del MOO Figuras Geométricas.
Procedimiento de la Prueba
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
Curso alterno 1 3. Ocurre algún error durante la obtención de la jerarquía de clases. 4. La herramienta notifica del error. 5. Fin.
Curso alterno 2 4. Ocurre algún error durante el almacenamiento de información en la tabla.
5. La herramienta notifica del error. 6. Fin.
Excepciones
Post-condiciones 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.
Observaciones Ninguna.
6.5.3 MOO2MVA-CP-03
Número/Nombre Prueba: MOO2MVA-CP-03
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se generaran correctamente clases concretas, abstractas e interfaces de Java.
Condiciones de Ambiente Ninguna.
Entrada 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.
Resultados Esperados Una clase de Java de acuerdo al tipo de clase solicitada (concreta, abstracta o interfaz) con las relaciones establecidas de acuerdo a lo solicitado.
Procedimiento de la Prueba
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
Curso alterno 1 3. Ocurre algún error durante la generación de la clase. 4. La herramienta notifica del error.
Pruebas del Sistema
87
5. Fin
Excepciones
Post-condiciones Si se presenta algún error durante la generación de la clase se notifica del error entonces el caso de prueba termina.
Observaciones Ninguna
Instancias de Prueba
No. de Instancia Valor Resultado Esperado
Instancia 1 Se solicita la creación de una clase concreta.
Clase de Java concreta generada correctamente.
Instancia 2 Se solicita la creación de una clase concreta derivada de otra clase.
Clase de Java concreta derivada de otra generada correctamente.
Instancia 3 Se solicita la creación de una clase concreta que implementa una interfaz
Clase de Java concreta que implementa una interfaz generada correctamente.
Instancia 4
Se solicita la creación de una clase concreta derivada de otra clase y que implementa una interfaz.
Clase de Java concreta derivada de otra e implementa una interfaz generada correctamente.
Instancia 5 Se solicita la creación de una clase abstracta.
Clase abstracta de Java generada correctamente.
Instancia 6 Se solicita la creación de una clase abstracta derivada de una clase.
Clase abstracta de Java derivada de una clase generada correctamente.
Instancia 7 Se solicita la creación de una clase abstracta que implementa una interfaz.
Clase abstracta de Java que implementa una interfaz generada correctamente.
Instancia 8 Se solicita la creación de una interfaz.
Interfaz de Java generada correctamente.
Instancia 9 Se solicita la creación de una interfaz que extiende a otra interfaz.
Interfaz de Java que extiende otra interfaz generada correctamente.
6.5.4 MOO2MVA-CP-04
Número/Nombre Prueba: MOO2MVA-CP-04
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo 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.
Condiciones de Ambiente Ninguna
Entrada 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á.
Resultados Esperados La clase de Java que contendrá el constructor que ha solicitado (con o
Capítulo 6
88
sin parámetros, o copia de otro).
Procedimiento de la Prueba
1. Inicio. 2. Se solicita la generación del constructor. 3. Se genera el constructor en la clase especificada. 4. Fin.
Cursos Alternos
Curso alterno 1 3. Ocurre algún error durante la generación del constructor. 4. La herramienta notifica del error. 5. Fin
Excepciones
Post-condiciones Si se presenta algún error durante la generación del constructor el caso de prueba termina.
Observaciones Ninguna
Instancias de Prueba
No. de Instancia Valor Resultado Esperado
Instancia 1 Se solicita la creación de un constructor sin parámetros.
La clase de Java contiene un constructor correcto y sin parámetros.
Instancia 2 Se solicita la creación de un constructor con parámetros.
La clase de Java contiene un constructor correcto y con parámetros.
Instancia 2 Se solicita la copia de un constructor.
La clase de Java contiene una copia del constructor de la clase especificada.
6.5.5 MOO2MVA-CP-05
Número/Nombre Prueba: MOO2MVA-CP-05
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se realiza correctamente la reubicación de atributos.
Condiciones de Ambiente Ninguna.
Entrada 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.
Resultados Esperados Código Java con la reubicación de atributos realizada correctamente.
Procedimiento de la Prueba
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 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
89
6.5.6 MOO2MVA-CP-06
Número/Nombre Prueba: MOO2MVA-CP-06
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se crean correctamente funciones con y sin parámetros.
Condiciones de Ambiente Ninguna.
Entrada 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.
Resultados Esperados La clase de Java contiene la función que ha solicitado.
Procedimiento de la Prueba
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 3. Ocurre algún error durante la creación de la función. 4. La herramienta notifica del error. 5. Fin.
Curso alterno 1 4. Ocurre algún error al copiar los estatutos a la función. 5. La herramienta notifica del error. 6. Fin.
Excepciones
Post-condiciones 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.
Observaciones Ninguna
Instancias de Prueba
No. de Instancia Valor Resultado Esperado
Instancia 1 Se solicita la creación de una función sin parámetros.
La clase de Java contiene una función sin parámetros generada correctamente.
Instancia 2 Se solicita la creación de una función con parámetros.
La clase de Java contiene una función con parámetros generada correctamente.
Capítulo 6
90
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 -
MOO2MVA-CP-03
Instancia 1 No aplica
Instancia 2 No aplica
Instancia 3 No aplica
Instancia 4 No aplica
Instancia 5 No aplica
Instancia 6 No aplica
Instancia 7 No aplica
Instancia 8 No aplica
Instancia 9 No aplica
MOO2MVA-CP-04
Instancia 1 No aplica
Instancia 2 No aplica
Instancia 3 No aplica
MOO2MVA-CP-05 - No aplica
MOO2MVA-CP-06 Instancia 1
Instancia 2
Pruebas del Sistema
91
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.
Conclusiones y Trabajos Futuros
93
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
Capítulo 7
94
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”.
Conclusiones y Trabajos Futuros
95
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.
Bibliografía
97
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/en-us/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.
Bibliografía
98
[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.
[FOWL,99] Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refactoring: Improving the Design of Existing Code. Addison Wesley.
[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 Modelo-Vista-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
Bibliografía
99
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
Anexo A: Métodos de Reestructura
101
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, Tipo, Tipo_relación1, Clase_base1, Tipo_relación2, Clase_Base2, Patrón_MVC
5. 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:
Anexo A: Métodos de Reestructura
102
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. Etiquetar el estatuto con la etiqueta “Im” (importación de archivos):
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. Llenar la tabla “Tipos de clases” con los siguientes datos de la clase:
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
Anexo A: Métodos de Reestructura
103
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. Buscar los datos del atributo inicializado en el constructor:
mientras(Tipos de variables[i].Identificador≠identificador⋀Tipos de variables[i].Clase≠nomclase)haz
9.3.2.6.3.2.4.1. Si el atributo ya está registrado en la tabla:
si(Tipos de variables[i].Identificador==identificador⋀Tipos de variables[i].Clase==nomclase)entonces
9.3.2.6.3.2.4.1.1. 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, especificador, clase de la variable, firma, nomclase
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. Etiquetar el estatuto con la etiqueta “EI” (estatuto de invocación):
estatuto estatuto+”//EI”
fin_si //(9.3.2.6.3.3)
}while(e≠}) //(9.3.2.6.3)
Anexo A: Métodos de Reestructura
104
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. Etiquetar el estatuto con la etiqueta “ff” (fin de función):
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. Llenar la tabla “Funciones concretas” con los siguientes datos de la función:
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 de la variable modificada en el estatuto de asignación:
identificador identificador de la variable del estatuto de asignación
9.3.2.7.2.2.1.2. 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. Si la variable ya está registrado en la tabla:
si(Tipos de variables[i].Identificador==identificador⋀Tipos de variables[i].Clase==nomclase)entonces
9.3.2.7.2.2.1.5.1.1 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 Si la función es la primera que accede a la variable:
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
Anexo A: Métodos de Reestructura
105
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 el estatuto con la etiqueta “//EM” (estatuto del modelo):
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 el estatuto con la etiqueta “//EC” (estatuto del control):
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 el estatuto con la etiqueta “//EV” (estatuto de la vista):
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 el estatuto con la etiqueta “//EI” (estatuto de invocación):
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 o condicional, o es un estatuto selectivo, o es un estatuto de bloque:
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:
Anexo A: Métodos de Reestructura
106
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 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.6.1.1.5.1 Si la variable ya está registrado en la tabla:
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 Obtener los datos de la variable:
tipo Tipos de Variables[i].Tipo
especificador Tipos de Variables[i].Especificador
9.3.2.7.2.2.6.1.1.5.1.2 Si la función es la primera que accede a la variable:
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 Incrementar el valor de la variable i:
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 Incrementar el contador de estatutos del modelo:
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
Anexo A: Métodos de Reestructura
107
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 Incrementar el contador de estatutos del control:
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 Incrementar el contador de estatutos de la vista:
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. Leer el siguiente estatuto: e 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 estatuto con la etiqueta “//fe” (fin de estatuto de bloque):
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. Etiquetar el estatuto con la etiqueta “//ff” (fin de función):
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. Incrementar el contador de funciones no especializadas:
cFMZ cFMZ+1
9.3.2.7.3.2.4. Inicializar los contadores:
cm 0, cv 0, cc 0
Anexo A: Métodos de Reestructura
108
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. Etiquetar función con la etiqueta “//FM” (función del modelo).
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” 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.2.1.3. Incrementar el contador de funciones del control:
cFC cFC+1
9.3.2.7.3.3.2.1.4. Inicializar el contador de estatutos del control:
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. Incrementar el contador de funciones de la vista:
cFV cFV+1
7.3.2.5.3.3.2.2.1.4. Inicializar el contador de estatutos de la vista:
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
Anexo A: Métodos de Reestructura
109
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 la clase con la etiqueta “//CMZ” (clase no-especializada).
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. Etiquetar la clase con la etiqueta “//CM” (clase del modelo).
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. Etiquetar la clase con la etiqueta “//CC” (clase del control).
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. Etiquetar la clase con la etiqueta “//CV” (clase de la vista).
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
Anexo A: Métodos de Reestructura
110
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. Buscar la función abstracta que implementa la función concreta en estudio:
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:
Anexo A: Métodos de Reestructura
111
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:
Anexo A: Métodos de Reestructura
112
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).
Anexo A: Métodos de Reestructura
113
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:
Clase_padre, Clase_hija
3. Inicializar variables:
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”:
Anexo A: Métodos de Reestructura
114
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. Inicializar el valor de la variable i:
i 0
Anexo A: Métodos de Reestructura
115
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:
Anexo A: Métodos de Reestructura
116
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:
Anexo A: Métodos de Reestructura
117
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. Si se desea crear otro constructor entonces ir al paso 1, si no, ir al paso 4.
3. 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.
Anexo A: Métodos de Reestructura
118
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:
Anexo A: Métodos de Reestructura
119
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 e en el archivo
<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.
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 el archivo
<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]
Anexo A: Métodos de Reestructura
120
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:
Anexo A: Métodos de Reestructura
121
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.
Anexo B: Descripción de los Casos de Prueba
123
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.
Anexo B: Descripción de los Casos de Prueba
124
Figura 34. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 1)
Anexo B: Descripción de los Casos de Prueba
125
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
Anexo B: Descripción de los Casos de Prueba
126
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 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
127
Tabla 12. Resultados del MOO2MVA-CP-01: Tabla Tipos de Variables
Identificador Tipo Especificador Clase_Variable FirmaFuncion Clase_Funcion
e double
aFigura
radio double
aConicas aConicas(double) aConicas
diametro double
aConicas
area double
aConicas area() cCirculo
perimetro double
aConicas perimetro() cCirculo
circunferencia double
aConicas circunferencia() cElipse
semiperimetro double
aConicas semiperimetro() cCirculo
excentricidad double
aConicas excentricidad() cElipse
puntox double
aConicas aConicas(double, double, double, double)
aConicas
puntoy double
aConicas aConicas(double, double, double, double)
aConicas
puntoa double
aConicas aConicas(double, double, double, double)
aConicas
puntob double
aConicas aConicas(double, double, double, double)
aConicas
puntoc double
aConicas c() cElipse
lado1 double protected aCuadrilateros aParalelogramos(double) aParalelogramos
lado2 double protected aCuadrilateros aParalelogramos(double) aParalelogramos
lado3 double protected aCuadrilateros aParalelogramos(double) aParalelogramos
lado4 double protected aCuadrilateros aParalelogramos(double) aParalelogramos
altura double protected aCuadrilateros altura() cCuadrado
area double protected aCuadrilateros area() cCuadrado
apotema double protected aCuadrilateros apotema() cCuadrado
diagonal double protected aCuadrilateros diagonal() cCuadrado
diagonales double protected aCuadrilateros diagonales() cCuadrado
perimetro double protected aCuadrilateros perimetro() cCuadrado
semiperimetro double protected aCuadrilateros semiperimetro() cCuadrado
radio double protected aCuadrilateros circircuns() cCuadrado
e double
aCuerpo
radio double protected aCurvos aCurvos(double, double) aCurvos
altura double protected aCurvos aCurvos(double, double) aCurvos
areatot double protected aCurvos area() cCilindro
areabase double protected aCurvos areabase() cCono
arealat double protected aCurvos areabase() cCilindro
volumen double protected aCurvos volumen() cCilindro
generatriz double protected aCurvos generatriz() cCono
radio double protected aCurvos aCurvos(double) aCurvos
lado1 double protected aCuadrilateros aParalelogramos(double, double)
aParalelogramos
lado2 double protected aCuadrilateros aParalelogramos(double, double)
aParalelogramos
lado3 double protected aCuadrilateros aParalelogramos(double, double)
aParalelogramos
lado4 double protected aCuadrilateros aParalelogramos(double, double)
aParalelogramos
altura double
aPoliedrosIrregulares
poligono aElemGeometrico
aPoliedrosIrregulares
arealat double
aPoliedrosIrregulares arealat() cPiramides
areatot double
aPoliedrosIrregulares area() cPiramides
volumen double
aPoliedrosIrregulares volumen() cPiramides
areabase double
aPoliedrosIrregulares
perimbase double
aPoliedrosIrregulares
apotemalat double
aPiramides apotema() cPiramides
apotemabase double
aPiramides
radio double
aPiramides
aristalat double
aPiramides aristalat() cPiramides
Anexo B: Descripción de los Casos de Prueba
128
lado double protected aPoliedrosRegulares aPoliedrosRegulares(double)
aPoliedrosRegulares
areatot double protected aPoliedrosRegulares area() cCubo
arealat double protected aPoliedrosRegulares arealat() cCubo
volumen double protected aPoliedrosRegulares volumen() cCubo
apotema double protected aPoliedrosRegulares apotema() cCubo
perimetro double protected aPoliedrosRegulares perimetro() cCubo
lado1 double protected aCuadrilateros aTrapecios(double, double, double)
aTrapecios
lado2 double protected aCuadrilateros aTrapecios(double, double, double)
aTrapecios
lado3 double protected aCuadrilateros aTrapecios(double, double, double)
aTrapecios
lado4 double protected aCuadrilateros aTrapecios(double, double, double)
aTrapecios
lado1 double protected aTriangulos aTriangulos(double, double, double)
aTriangulos
lado2 double protected aTriangulos aTriangulos(double, double, double)
aTriangulos
lado3 double protected aTriangulos aTriangulos(double, double, double)
aTriangulos
altura double protected aTriangulos altura() cTrianguloEquilatero
area double protected aTriangulos area() aTriangulos
semiperimetro double protected aTriangulos semiperimetro() aTriangulos
perimetro double protected aTriangulos perimetro() cTrianguloEquilatero
circircuns double protected aTriangulos circircuns(double) aTriangulos
cirinsc double protected aTriangulos cirinsc(double) aTriangulos
lado1 double protected aTriangulos aTriangulos(double, double)
aTriangulos
lado2 double protected aTriangulos aTriangulos(double, double)
aTriangulos
lado3 double protected aTriangulos aTriangulos(double, double)
aTriangulos
lado1 double protected aTriangulos aTriangulos(double) aTriangulos
lado2 double protected aTriangulos aTriangulos(double) aTriangulos
lado3 double protected aTriangulos aTriangulos(double) aTriangulos
areatot double protected aCurvos area() cCono
arealat double protected aCurvos arealat() cCono
volumen double protected aCurvos volumen() cCono
radio double protected aCuadrilateros cirinsc() cCuadrado
radio double protected aCuadrilateros radio() cCuadrado
diagonal double
cCubo diagonal() cCubo
lado1 double protected cDecagono cDecagono(double) cDecagono
altura double protected cDecagono altura() cDecagono
apotema double protected cDecagono apotema() cDecagono
area double protected cDecagono area() cDecagono
diagonal double protected cDecagono diagonal() cDecagono
diagonales double protected cDecagono diagonales() cDecagono
perimetro double protected cDecagono perimetro() cDecagono
semiperimetro double protected cDecagono semiperimetro() cDecagono
radio double protected cDecagono radio() cDecagono
areatot double protected aPoliedrosRegulares area() cDodecaedro
arealat double protected aPoliedrosRegulares arealat() cDodecaedro
volumen double protected aPoliedrosRegulares volumen() cDodecaedro
apotema double protected aPoliedrosRegulares apotema() cDodecaedro
perimetro double protected aPoliedrosRegulares perimetro() cDodecaedro
area double
aConicas area() cElipse
perimetro double
aConicas perimetro() cElipse
lado1 double protected cEneagono cEneagono(double) cEneagono
altura double protected cEneagono altura() cEneagono
apotema double protected cEneagono apotema() cEneagono
Anexo B: Descripción de los Casos de Prueba
129
area double protected cEneagono area() cEneagono
diagonal double protected cEneagono diagonal() cEneagono
diagonales double protected cEneagono diagonales() cEneagono
perimetro double protected cEneagono perimetro() cEneagono
semiperimetro double protected cEneagono semiperimetro() cEneagono
radio double protected cEneagono radio() cEneagono
areatot double protected aCurvos area() cEsfera
arealat double protected aCurvos arealat() cEsfera
areabase double protected aCurvos areabase() cEsfera
volumen double protected aCurvos volumen() cEsfera
lado1 double protected cHeptagono cHeptagono(double) cHeptagono
altura double protected cHeptagono altura() cHeptagono
apotema double protected cHeptagono apotema() cHeptagono
area double protected cHeptagono area() cHeptagono
diagonal double protected cHeptagono diagonal() cHeptagono
diagonales double protected cHeptagono diagonales() cHeptagono
perimetro double protected cHeptagono perimetro() cHeptagono
semiperimetro double protected cHeptagono semiperimetro() cHeptagono
radio double protected cHeptagono radio() cHeptagono
lado1 double
cHexagono cHexagono(double) cHexagono
altura double
cHexagono altura() cHexagono
apotema double
cHexagono apotema() cHexagono
area double
cHexagono area() cHexagono
diagonal double
cHexagono diagonal() cHexagono
diagonales double
cHexagono diagonales() cHexagono
perimetro double
cHexagono perimetro() cHexagono
semiperimetro double
cHexagono semiperimetro() cHexagono
radio double
cHexagono radio() cHexagono
areatot double protected aPoliedrosRegulares area() cIcosaedro
arealat double protected aPoliedrosRegulares arealat() cIcosaedro
volumen double protected aPoliedrosRegulares volumen() cIcosaedro
apotema double protected aPoliedrosRegulares apotema() cIcosaedro
perimetro double protected aPoliedrosRegulares perimetro() cIcosaedro
diagonal double
cOctaedro diagonal() cOctaedro
areatot double protected aPoliedrosRegulares area() cOctaedro
arealat double protected aPoliedrosRegulares arealat() cOctaedro
volumen double protected aPoliedrosRegulares volumen() cOctaedro
apotema double protected aPoliedrosRegulares apotema() cOctaedro
perimetro double protected aPoliedrosRegulares perimetro() cOctaedro
lado1 double protected cOctagono cOctagono(double) cOctagono
altura double protected cOctagono altura() cOctagono
apotema double protected cOctagono apotema() cOctagono
area double protected cOctagono area() cOctagono
diagonal double protected cOctagono diagonal() cOctagono
diagonales double protected cOctagono diagonales() cOctagono
perimetro double protected cOctagono perimetro() cOctagono
semiperimetro double protected cOctagono semiperimetro() cOctagono
radio double protected cOctagono radio() cOctagono
lado1 double protected cPentagono cPentagono(double) cPentagono
altura double protected cPentagono altura() cPentagono
apotema double protected cPentagono apotema() cPentagono
area double protected cPentagono area() cPentagono
diagonal double protected cPentagono diagonal() cPentagono
diagonales double protected cPentagono diagonales() cPentagono
perimetro double protected cPentagono perimetro() cPentagono
semiperimetro double protected cPentagono semiperimetro() cPentagono
radio double protected cPentagono radio() cPentagono
apotemalat double
aPiramides arealat() cPiramides
areatot double
aPoliedrosIrregulares area() cPrismas
arealat double
aPoliedrosIrregulares arealat() cPrismas
Anexo B: Descripción de los Casos de Prueba
130
volumen double
aPoliedrosIrregulares volumen() cPrismas
area double protected aCuadrilateros area() cRectangulo
perimetro double protected aCuadrilateros perimetro() cRectangulo
diagonal double protected aCuadrilateros diagonal() cRectangulo
diagonales double protected aCuadrilateros diagonales() cRectangulo
semiperimetro double protected aCuadrilateros semiperimetro() cRectangulo
altura double protected aCuadrilateros altura() cRectangulo
apotema double protected aCuadrilateros apotema() cRectangulo
apotema double protected aCuadrilateros apotema() cRectangulo
diagonalmayor double public cRombo diagonalmayor() cRombo
diagonalmenor double public cRombo diagonalmenor() cRombo
altura double protected aCuadrilateros altura() cRombo
perimetro double protected aCuadrilateros perimetro() cRombo
semiperimetro double protected aCuadrilateros semiperimetro() cRombo
area double protected aCuadrilateros area() cRombo
diagonales double protected aCuadrilateros diagonales() cRombo
area double protected aCuadrilateros area() cRomboide
altura double protected aCuadrilateros altura() cRomboide
semiperimetro double protected aCuadrilateros semiperimetro() cRomboide
diagonales double protected aCuadrilateros diagonales() cRomboide
perimetro double protected aCuadrilateros perimetro() cRomboide
areatot double protected aPoliedrosRegulares area() cTetraedro
arealat double protected aPoliedrosRegulares arealat() cTetraedro
volumen double protected aPoliedrosRegulares volumen() cTetraedro
apotema double protected aPoliedrosRegulares apotema() cTetraedro
perimetro double protected aPoliedrosRegulares perimetro() cTetraedro
area double protected aCuadrilateros area() cTrapecio
altura double protected aCuadrilateros altura() cTrapecio
semiperimetro double protected aCuadrilateros semiperimetro() cTrapecio
diagonal double protected aCuadrilateros diagonal() cTrapecio
diagonales double protected aCuadrilateros diagonales() cTrapecio
perimetro double protected aCuadrilateros perimetro() cTrapecio
area double protected aCuadrilateros area() cTrapecioIsosceles
altura double protected aCuadrilateros altura() cTrapecioIsosceles
semiperimetro double protected aCuadrilateros semiperimetro() cTrapecioIsosceles
diagonal double protected aCuadrilateros diagonal() cTrapecioIsosceles
diagonales double protected aCuadrilateros diagonales() cTrapecioIsosceles
perimetro double protected aCuadrilateros perimetro() cTrapecioIsosceles
area double protected aCuadrilateros area() cTrapecioRectangulo
altura double protected aCuadrilateros altura() cTrapecioRectangulo
lado4 double protected aCuadrilateros ladooblicuo() cTrapecioRectangulo
semiperimetro double protected aCuadrilateros semiperimetro() cTrapecioRectangulo
diagonal double protected aCuadrilateros diagonal() cTrapecioRectangulo
diagonales double protected aCuadrilateros diagonales() cTrapecioRectangulo
perimetro double protected aCuadrilateros perimetro() cTrapecioRectangulo
lado1 double protected aCuadrilateros cTrapezoide(double, double, double, double)
cTrapezoide
lado2 double protected aCuadrilateros cTrapezoide(double, double, double, double)
cTrapezoide
lado3 double protected aCuadrilateros cTrapezoide(double, double, double, double)
cTrapezoide
lado4 double protected aCuadrilateros cTrapezoide(double, double, double, double)
cTrapezoide
semiperimetro double protected aCuadrilateros semiperimetro() cTrapezoide
diagonales double protected aCuadrilateros diagonales() cTrapezoide
perimetro double protected aCuadrilateros perimetro() cTrapezoide
apotema double public cTrianguloEquilatero apotema() cTrianguloEquilatero
altura double protected aTriangulos altura() cTrianguloEscaleno
perimetro double protected aTriangulos perimetro() cTrianguloEscaleno
perimetro double protected aTriangulos perimetro() cTrianguloIsosceles
Anexo B: Descripción de los Casos de Prueba
131
altura double protected aTriangulos altura() cTrianguloIsosceles
Tabla 13. Resultado del MOO2MVA-CP-01: Tabla Funciones abstractas
Firma Especificador Tipo_Retorno Clase Patron_MVC
altura() public abstract void aElemGeometrico Vista
ladooblicuo() public abstract void aElemGeometrico Vista
apotema() public abstract double aElemGeometrico Modelo
area() public abstract double aElemGeometrico No especializada
radio() public abstract double aElemGeometrico Modelo
cirinsc() public abstract void aElemGeometrico Vista
cirinsc(double) public abstract void aElemGeometrico Vista
circircuns() public abstract void aElemGeometrico Vista
circircuns(double) public abstract void aElemGeometrico Vista
circunferencia() public abstract void aElemGeometrico Vista
diagonal() public abstract void aElemGeometrico Vista
diagonales() public abstract void aElemGeometrico Vista
diametro() public abstract void aElemGeometrico Vista
figinscir() public abstract void aElemGeometrico Vista
perimetro() public abstract double aElemGeometrico No especializada
semiperimetro() public abstract void aElemGeometrico Vista
c() public abstract void aElemGeometrico Vista
focos() public abstract void aElemGeometrico Vista
excentricidad() public abstract void aElemGeometrico Vista
arealat() public abstract void aElemGeometrico Vista
volumen() public abstract void aElemGeometrico Vista
areabase() public abstract void aElemGeometrico Vista
generatriz() public abstract void aElemGeometrico Vista
aristalat() public abstract void aElemGeometrico Vista
altura() public abstract void aFigura Vista
apotema() public abstract double aFigura Modelo
area() public abstract double aFigura No especializada
cirinsc() public abstract void aFigura Vista
cirinsc(double) public abstract void aFigura Vista
circircuns() public abstract void aFigura Vista
circircuns(double) public abstract void aFigura Vista
circunferencia() public abstract void aFigura Vista
diagonal() public abstract void aFigura Vista
diagonales() public abstract void aFigura Vista
diametro() public abstract void aFigura Vista
figinscir() public abstract void aFigura Vista
ladooblicuo() public abstract void aFigura Vista
perimetro() public abstract double aFigura No especializada
semiperimetro() public abstract void aFigura No especializada
c() public abstract void aFigura Vista
focos() public abstract void aFigura Vista
excentricidad() public abstract void aFigura Vista
perimetro() public abstract double aConicas No especializada
semiperimetro() public abstract void aConicas No especializada
area() public abstract double aConicas No especializada
diametro() public abstract void aConicas Vista
circunferencia() public abstract void aConicas No especializada
figinscir() public abstract void aConicas No especializada
circircuns() public abstract void aConicas No especializada
c() public abstract void aConicas Vista
focos() public abstract void aConicas Vista
excentricidad() public abstract void aConicas Vista
altura() public abstract void aPoligonos No especializada
apotema() public abstract double aPoligonos No especializada
Anexo B: Descripción de los Casos de Prueba
132
area() public abstract double aPoligonos No especializada
cirinsc() public abstract void aPoligonos Vista
circircuns() public abstract void aPoligonos Vista
diagonal() public abstract void aPoligonos Vista
diagonales() public abstract void aPoligonos Vista
figinscir() public abstract void aPoligonos Vista
perimetro() public abstract double aPoligonos No especializada
semiperimetro() public abstract void aPoligonos No especializada
radio() public abstract double aPoligonos Modelo
area() public abstract double aCuadrilateros No especializada
apotema() public abstract double aCuadrilateros No especializada
altura() public abstract void aCuadrilateros No especializada
semiperimetro() public abstract void aCuadrilateros No especializada
diagonal() public abstract void aCuadrilateros No especializada
diagonales() public abstract void aCuadrilateros No especializada
perimetro() public abstract double aCuadrilateros No especializada
figinscir() public abstract void aCuadrilateros Vista
circircuns() public abstract void aCuadrilateros Vista
cirinsc() public abstract void aCuadrilateros Vista
area() public abstract double aCuerpo No especializada
arealat() public abstract void aCuerpo No especializada
volumen() public abstract void aCuerpo No especializada
apotema() public abstract double aCuerpo No especializada
diagonal() public abstract void aCuerpo Vista
perimetro() public abstract double aCuerpo No especializada
areabase() public abstract void aCuerpo Vista
aristalat() public abstract void aCuerpo Vista
area() public abstract double aCurvos No especializada
arealat() public abstract void aCurvos No especializada
areabase() public abstract void aCurvos No especializada
volumen() public abstract void aCurvos No especializada
area() public abstract double aParalelogramos No especializada
apotema() public abstract double aParalelogramos No especializada
altura() public abstract void aParalelogramos No especializada
semiperimetro() public abstract void aParalelogramos No especializada
diagonal() public abstract void aParalelogramos No especializada
diagonales() public abstract void aParalelogramos No especializada
perimetro() public abstract double aParalelogramos No especializada
circircuns() public abstract void aParalelogramos No especializada
cirinsc() public abstract void aParalelogramos No especializada
figinscir() public abstract void aParalelogramos No especializada
area() public abstract double aPoliedros No especializada
arealat() public abstract void aPoliedros No especializada
volumen() public abstract void aPoliedros No especializada
apotema() public abstract double aPoliedros Modelo
perimetro() public abstract double aPoliedros Modelo
diagonal() public abstract void aPoliedros Vista
areabase() public abstract void aPoliedros Vista
aristalat() public abstract void aPoliedros Vista
area() public abstract double aPoliedrosIrregulares No especializada
arealat() public abstract void aPoliedrosIrregulares No especializada
volumen() public abstract void aPoliedrosIrregulares No especializada
apotema() public abstract double aPoliedrosIrregulares Modelo
aristalat() public abstract void aPoliedrosIrregulares Vista
apotema() public abstract double aPiramides No especializada
aristalat() public abstract void aPiramides No especializada
arealat() public abstract void aPiramides No especializada
area() public abstract double aPiramides No especializada
volumen() public abstract void aPiramides No especializada
area() public abstract double aPoliedrosRegulares No especializada
Anexo B: Descripción de los Casos de Prueba
133
arealat() public abstract void aPoliedrosRegulares No especializada
volumen() public abstract void aPoliedrosRegulares No especializada
apotema() public abstract double aPoliedrosRegulares No especializada
perimetro() public abstract double aPoliedrosRegulares No especializada
diagonal() public abstract void aPoliedrosRegulares No especializada
area() public abstract double aPrismas No especializada
arealat() public abstract void aPrismas No especializada
volumen() public abstract void aPrismas No especializada
area() public abstract double aTrapecios No especializada
altura() public abstract void aTrapecios No especializada
semiperimetro() public abstract void aTrapecios No especializada
diagonal() public abstract void aTrapecios No especializada
diagonales() public abstract void aTrapecios No especializada
perimetro() public abstract double aTrapecios No especializada
perimetro() public abstract double aTriangulos No especializada
apotema() public abstract double aTriangulos No especializada
altura() public abstract void aTriangulos No especializada
Tabla 14. Resultado del MOO2MVA-CP-01: Tabla Funciones concretas
Firma Especificador Tipo_Retorno Clase Patron_MVC
arealat() public void aFigura Vista
volumen() public void aFigura Vista
areabase() public void aFigura Vista
generatriz() public void aFigura Vista
aristalat() public void aFigura Vista
radio() public double aFigura Modelo
altura() public void aConicas Vista
apotema() public double aConicas Modelo
cirinsc() public void aConicas Vista
cirinsc(double) public void aConicas Vista
circircuns(double) public void aConicas Vista
diagonal() public void aConicas Vista
diagonales() public void aConicas Vista
ladooblicuo() public void aConicas Vista
circunferencia() public void aPoligonos Vista
cirinsc(double) public void aPoligonos Vista
circircuns(double) public void aPoligonos Vista
diametro() public void aPoligonos Vista
ladooblicuo() public void aPoligonos Vista
c() public void aPoligonos Vista
focos() public void aPoligonos Vista
excentricidad() public void aPoligonos Vista
circircuns(double) public void aCuadrilateros Vista
cirinsc(double) public void aCuadrilateros Vista
radio() public double aCuadrilateros Modelo
altura() public void aCuerpo Vista
ladooblicuo() public void aCuerpo Vista
cirinsc() public void aCuerpo Vista
cirinsc(double) public void aCuerpo Vista
circircuns() public void aCuerpo Vista
circircuns(double) public void aCuerpo Vista
circunferencia() public void aCuerpo Vista
diagonales() public void aCuerpo Vista
diametro() public void aCuerpo Vista
figinscir() public void aCuerpo Vista
semiperimetro() public void aCuerpo Vista
c() public void aCuerpo Vista
focos() public void aCuerpo Vista
Anexo B: Descripción de los Casos de Prueba
134
excentricidad() public void aCuerpo Vista
generatriz() public void aCuerpo Vista
radio() public double aCuerpo Modelo
generatriz() public void aCurvos Vista
diagonal() public void aCurvos Vista
aristalat() public void aCurvos Vista
apotema() public double aCurvos No especializada
perimetro() public double aCurvos No especializada
diagonal() public void aPoliedrosIrregulares Vista
areabase() public void aPoliedrosIrregulares Vista
perimetro() public double aPoliedrosIrregulares Modelo
areabase() public void aPoliedrosRegulares Vista
aristalat() public void aPoliedrosRegulares Vista
apotema() public double aPrismas Modelo
aristalat() public void aPrismas Vista
apotema() public double aTrapecios No especializada
figinscir() public void aTrapecios Vista
circircuns() public void aTrapecios Vista
cirinsc() public void aTrapecios Vista
diagonales() public void aTriangulos Vista
circircuns() public void aTriangulos Vista
cirinsc() public void aTriangulos Vista
figinscir() public void aTriangulos Vista
diagonal() public void aTriangulos Vista
radio() public double aTriangulos Modelo
area() public double aTriangulos No especializada
semiperimetro() public void aTriangulos No especializada
circircuns(double) public void aTriangulos No especializada
cirinsc(double) public void aTriangulos No especializada
area() public double cCilindro No especializada
arealat() public void cCilindro No especializada
areabase() public void cCilindro No especializada
volumen() public void cCilindro No especializada
area() public double cCirculo No especializada
perimetro() public double cCirculo No especializada
diametro() public void cCirculo Vista
circunferencia() public void cCirculo No especializada
semiperimetro() public void cCirculo No especializada
figinscir() public void cCirculo No especializada
circircuns() public void cCirculo No especializada
c() public void cCirculo Vista
focos() public void cCirculo Vista
excentricidad() public void cCirculo Vista
area() public double cCono No especializada
arealat() public void cCono No especializada
areabase() public void cCono No especializada
volumen() public void cCono No especializada
generatriz() public void cCono No especializada
altura() public void cCuadrado No especializada
semiperimetro() public void cCuadrado No especializada
diagonal() public void cCuadrado No especializada
diagonales() public void cCuadrado No especializada
apotema() public double cCuadrado No especializada
area() public double cCuadrado No especializada
perimetro() public double cCuadrado No especializada
figinscir() public void cCuadrado No especializada
circircuns() public void cCuadrado No especializada
cirinsc() public void cCuadrado No especializada
radio() public double cCuadrado Modelo
area() public double cCubo No especializada
Anexo B: Descripción de los Casos de Prueba
135
arealat() public void cCubo No especializada
volumen() public void cCubo No especializada
diagonal() public void cCubo No especializada
apotema() public double cCubo No especializada
perimetro() public double cCubo No especializada
altura() public void cDecagono No especializada
apotema() public double cDecagono No especializada
area() public double cDecagono No especializada
cirinsc() public void cDecagono No especializada
circircuns() public void cDecagono No especializada
radio() public double cDecagono No especializada
diagonal() public void cDecagono No especializada
diagonales() public void cDecagono No especializada
figinscir() public void cDecagono No especializada
perimetro() public double cDecagono No especializada
semiperimetro() public void cDecagono No especializada
area() public double cDodecaedro No especializada
arealat() public void cDodecaedro No especializada
volumen() public void cDodecaedro No especializada
apotema() public double cDodecaedro No especializada
perimetro() public double cDodecaedro No especializada
diagonal() public void cDodecaedro Vista
c() public void cElipse No especializada
focos() public void cElipse No especializada
area() public double cElipse No especializada
perimetro() public double cElipse No especializada
excentricidad() public void cElipse No especializada
semiperimetro() public void cElipse Vista
diametro() public void cElipse No especializada
circunferencia() public void cElipse No especializada
figinscir() public void cElipse Vista
circircuns() public void cElipse Modelo
altura() public void cEneagono No especializada
apotema() public double cEneagono No especializada
area() public double cEneagono No especializada
cirinsc() public void cEneagono No especializada
circircuns() public void cEneagono No especializada
radio() public double cEneagono No especializada
diagonal() public void cEneagono No especializada
diagonales() public void cEneagono No especializada
figinscir() public void cEneagono No especializada
perimetro() public double cEneagono No especializada
semiperimetro() public void cEneagono No especializada
area() public double cEsfera No especializada
arealat() public void cEsfera No especializada
areabase() public void cEsfera No especializada
volumen() public void cEsfera No especializada
altura() public void cHeptagono No especializada
apotema() public double cHeptagono No especializada
area() public double cHeptagono No especializada
cirinsc() public void cHeptagono No especializada
circircuns() public void cHeptagono No especializada
radio() public double cHeptagono No especializada
diagonal() public void cHeptagono No especializada
diagonales() public void cHeptagono No especializada
figinscir() public void cHeptagono No especializada
perimetro() public double cHeptagono No especializada
semiperimetro() public void cHeptagono No especializada
altura() public void cHexagono No especializada
apotema() public double cHexagono No especializada
Anexo B: Descripción de los Casos de Prueba
136
area() public double cHexagono No especializada
cirinsc() public void cHexagono No especializada
circircuns() public void cHexagono No especializada
radio() public double cHexagono No especializada
diagonal() public void cHexagono No especializada
diagonales() public void cHexagono No especializada
figinscir() public void cHexagono No especializada
perimetro() public double cHexagono No especializada
semiperimetro() public void cHexagono No especializada
area() public double cIcosaedro No especializada
arealat() public void cIcosaedro No especializada
volumen() public void cIcosaedro No especializada
apotema() public double cIcosaedro No especializada
perimetro() public double cIcosaedro No especializada
diagonal() public void cIcosaedro Vista
area() public double cOctaedro No especializada
arealat() public void cOctaedro No especializada
volumen() public void cOctaedro No especializada
apotema() public double cOctaedro No especializada
perimetro() public double cOctaedro No especializada
diagonal() public void cOctaedro No especializada
altura() public void cOctagono No especializada
apotema() public double cOctagono No especializada
area() public double cOctagono No especializada
cirinsc() public void cOctagono No especializada
circircuns() public void cOctagono No especializada
radio() public double cOctagono No especializada
diagonal() public void cOctagono No especializada
diagonales() public void cOctagono No especializada
figinscir() public void cOctagono No especializada
perimetro() public double cOctagono No especializada
semiperimetro() public void cOctagono No especializada
altura() public void cPentagono No especializada
apotema() public double cPentagono No especializada
area() public double cPentagono No especializada
cirinsc() public void cPentagono No especializada
circircuns() public void cPentagono No especializada
radio() public double cPentagono No especializada
diagonal() public void cPentagono No especializada
diagonales() public void cPentagono No especializada
figinscir() public void cPentagono No especializada
perimetro() public double cPentagono No especializada
semiperimetro() public void cPentagono No especializada
apotema() public double cPiramides No especializada
aristalat() public void cPiramides No especializada
arealat() public void cPiramides No especializada
area() public double cPiramides No especializada
volumen() public void cPiramides No especializada
area() public double cPrismas No especializada
arealat() public void cPrismas No especializada
volumen() public void cPrismas No especializada
area() public double cRectangulo No especializada
perimetro() public double cRectangulo No especializada
diagonal() public void cRectangulo No especializada
circircuns() public void cRectangulo No especializada
cirinsc() public void cRectangulo No especializada
figinscir() public void cRectangulo Vista
diagonales() public void cRectangulo No especializada
semiperimetro() public void cRectangulo No especializada
altura() public void cRectangulo No especializada
Anexo B: Descripción de los Casos de Prueba
137
apotema() public double cRectangulo No especializada
altura() public void cRombo No especializada
perimetro() public double cRombo No especializada
semiperimetro() public void cRombo No especializada
diagonalmayor() public void cRombo No especializada
diagonalmenor() public void cRombo No especializada
area() public double cRombo No especializada
figinscir() public void cRombo Vista
apotema() public double cRombo No especializada
cirinsc() public void cRombo Vista
circircuns() public void cRombo Vista
diagonal() public void cRombo Modelo
diagonales() public void cRombo No especializada
area() public double cRomboide No especializada
apotema() public double cRomboide No especializada
altura() public void cRomboide No especializada
semiperimetro() public void cRomboide No especializada
diagonal() public void cRomboide Vista
diagonales() public void cRomboide No especializada
perimetro() public double cRomboide No especializada
circircuns() public void cRomboide Vista
cirinsc() public void cRomboide Vista
figinscir() public void cRomboide Vista
area() public double cTetraedro No especializada
arealat() public void cTetraedro No especializada
volumen() public void cTetraedro No especializada
apotema() public double cTetraedro No especializada
diagonal() public void cTetraedro
perimetro() public double cTetraedro No especializada
area() public double cTrapecio No especializada
altura() public void cTrapecio No especializada
semiperimetro() public void cTrapecio No especializada
diagonal() public void cTrapecio No especializada
diagonales() public void cTrapecio No especializada
perimetro() public double cTrapecio No especializada
area() public double cTrapecioIsosceles No especializada
altura() public void cTrapecioIsosceles No especializada
semiperimetro() public void cTrapecioIsosceles No especializada
diagonal() public void cTrapecioIsosceles No especializada
diagonales() public void cTrapecioIsosceles No especializada
perimetro() public double cTrapecioIsosceles No especializada
area() public double cTrapecioRectangulo No especializada
altura() public void cTrapecioRectangulo No especializada
ladooblicuo() public void cTrapecioRectangulo No especializada
semiperimetro() public void cTrapecioRectangulo No especializada
diagonal() public void cTrapecioRectangulo No especializada
diagonales() public void cTrapecioRectangulo No especializada
perimetro() public double cTrapecioRectangulo No especializada
area() public double cTrapezoide No especializada
apotema() public double cTrapezoide No especializada
altura() public void cTrapezoide No especializada
semiperimetro() public void cTrapezoide No especializada
diagonal() public void cTrapezoide Vista
diagonales() public void cTrapezoide No especializada
perimetro() public double cTrapezoide No especializada
figinscir() public void cTrapezoide Vista
circircuns() public void cTrapezoide Vista
cirinsc() public void cTrapezoide Vista
perimetro() public double cTrianguloEquilatero No especializada
apotema() public double cTrianguloEquilatero No especializada
Anexo B: Descripción de los Casos de Prueba
138
altura() public void cTrianguloEquilatero No especializada
altura() public void cTrianguloEscaleno No especializada
perimetro() public double cTrianguloEscaleno No especializada
apotema() public double cTrianguloEscaleno No especializada
apotema() public double cTrianguloIsosceles No especializada
perimetro() public double cTrianguloIsosceles No especializada
altura() public void cTrianguloIsosceles No especializada
Tabla 15. Resultado del MOO2MVA-CP-01: Tabla Tipos de Clases Nombre Paquete Tipo Tipo_Relacion1 Clase_Base1 Patron_MVC
aElemGeometrico FiugrasGeometricas abstract
No especializada
aFigura FiugrasGeometricas abstract extends aElemGeometrico No especializada
aConicas FiugrasGeometricas abstract extends aFigura No especializada
aPoligonos FiugrasGeometricas abstract extends aFigura Vista
aCuadrilateros FiugrasGeometricas abstract extends aPoligonos No especializada
aCuerpo FiugrasGeometricas abstract extends aElemGeometrico No especializada
aCurvos FiugrasGeometricas abstract extends aCuerpo No especializada
aParalelogramos FiugrasGeometricas abstract extends aCuadrilateros No especializada
aPoliedros FiugrasGeometricas abstract extends aCuerpo No especializada
aPoliedrosIrregulares FiugrasGeometricas abstract extends aPoliedros No especializada
aPiramides FiugrasGeometricas abstract extends aPoliedrosIrregulares No especializada
aPoliedrosRegulares FiugrasGeometricas abstract extends aPoliedros Vista
aPrismas FiugrasGeometricas abstract extends aPoliedrosIrregulares No especializada
aTrapecios FiugrasGeometricas abstract extends aCuadrilateros No especializada
aTriangulos FiugrasGeometricas abstract extends aPoligonos No especializada
cCilindro FiugrasGeometricas concreta extends aCurvos No especializada
cCirculo FiugrasGeometricas concreta extends aConicas No especializada
cCono FiugrasGeometricas concreta extends aCurvos No especializada
cCuadrado FiugrasGeometricas concreta extends aParalelogramos No especializada
cCubo FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada
cDecagono FiugrasGeometricas concreta extends aPoligonos No especializada
cDodecaedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada
cElipse FiugrasGeometricas concreta extends aConicas No especializada
cEneagono FiugrasGeometricas concreta extends aPoligonos No especializada
cEsfera FiugrasGeometricas concreta extends aCurvos No especializada
cHeptagono FiugrasGeometricas concreta extends aPoligonos No especializada
cHexagono FiugrasGeometricas concreta extends aPoligonos No especializada
cIcosaedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada
cOctaedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada
cOctagono FiugrasGeometricas concreta extends aPoligonos No especializada
cPentagono FiugrasGeometricas concreta extends aPoligonos No especializada
cPiramides FiugrasGeometricas concreta extends aPiramides No especializada
cPrismas FiugrasGeometricas concreta extends aPrismas No especializada
cRectangulo FiugrasGeometricas concreta extends aParalelogramos No especializada
cRombo FiugrasGeometricas concreta extends aParalelogramos No especializada
cRomboide FiugrasGeometricas concreta extends aParalelogramos No especializada
cTetraedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada
cTrapecio FiugrasGeometricas concreta extends aTrapecios No especializada
cTrapecioIsosceles FiugrasGeometricas concreta extends aTrapecios No especializada
cTrapecioRectangulo FiugrasGeometricas concreta extends aTrapecios No especializada
cTrapezoide FiugrasGeometricas concreta extends aCuadrilateros No especializada
cTrianguloEquilatero FiugrasGeometricas concreta extends aTriangulos No especializada
cTrianguloEscaleno FiugrasGeometricas concreta extends aTriangulos No especializada
cTrianguloIsosceles FiugrasGeometricas concreta extends aTriangulos No especializada
Anexo B: Descripción de los Casos de Prueba
139
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
aElemGeometrico aFigura
aElemGeometrico aCuerpo
aFigura aConicas
aFigura aPoligonos
aCuerpo aCurvos
aCuerpo aPoliedros
aConicas cCirculo
aConicas cElipse
aPoligonos aCuadrilateros
aPoligonos aTriangulos
aPoligonos cDecagono
aPoligonos cEneagono
aPoligonos cHeptagono
aPoligonos cHexagono
aPoligonos cOctagono
aPoligonos cPentagono
aCurvos cCilindro
aCurvos cCono
aCurvos cEsfera
aPoliedros aPoliedrosIrregulares
aPoliedros aPoliedrosRegulares
cCirculo Sin subclases
cElipse Sin subclases
aCuadrilateros aParalelogramos
aCuadrilateros aTrapecios
aCuadrilateros cTrapezoide
aTriangulos cTrianguloEquilatero
aTriangulos cTrianguloEscaleno
aTriangulos cTrianguloIsosceles
cDecagono Sin subclases
cEneagono Sin subclases
cHeptagono Sin subclases
cHexagono Sin subclases
cOctagono Sin subclases
cPentagono Sin subclases
cCilindro Sin subclases
ClasePadre ClaseHija
cCono Sin subclases
cEsfera Sin subclases
aPoliedrosIrregulares aPiramides
aPoliedrosIrregulares aPrismas
aPoliedrosRegulares cCubo
aPoliedrosRegulares cDodecaedro
aPoliedrosRegulares cIcosaedro
aPoliedrosRegulares cOctaedro
aPoliedrosRegulares cTetraedro
aParalelogramos cCuadrado
aParalelogramos cRectangulo
aParalelogramos cRombo
aParalelogramos cRomboide
aTrapecios cTrapecio
aTrapecios cTrapecioIsosceles
aTrapecios cTrapecioRectangulo
cTrapezoide Sin subclases
cTrianguloEquilatero Sin subclases
cTrianguloEscaleno Sin subclases
cTrianguloIsosceles Sin subclases
aPiramides cPiramides
aPrismas cPrismas
cCubo Sin subclases
cDodecaedro Sin subclases
cIcosaedro Sin subclases
cOctaedro Sin subclases
cTetraedro Sin subclases
cCuadrado Sin subclases
cRectangulo Sin subclases
cRombo Sin subclases
cRomboide Sin subclases
cTrapecio Sin subclases
cTrapecioIsosceles Sin subclases
cTrapecioRectangulo Sin subclases
cPiramides Sin subclases
cPrismas Sin subclases
Anexo B: Descripción de los Casos de Prueba
140
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
Instancia 7
Anexo B: Descripción de los Casos de Prueba
141
o Nombre del paquete: Prueba
o Nombre de la clase: aAbstractaPrueba7
o Tipo de clase: abstract
o Tipo de relación 1: implements
o 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
Figura 39. Resultado del MOO2MVA-CP-03: Instancia 1
Instancia 2
Figura 40. Resultado del MOO2MVA-CP-03: Instancia 2
Instancia 3
Figura 41. Resultado del MOO2MVA-CP-03: Instancia 3
Instancia 4
Figura 42. Resultado del MOO2MVA-CP-03: Instancia 4
Anexo B: Descripción de los Casos de Prueba
142
Instancia 5
Figura 43. Resultado del MOO2MVA-CP-03: Instancia 5
Instancia 6
Figura 44. Resultado del MOO2MVA-CP-03: Instancia 6
Instancia 7
Figura 45. Resultado del MOO2MVA-CP-03: Instancia 7
Instancia 8
Figura 46. Resultado del MOO2MVA-CP-03: Instancia 8
Instancia 9
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.
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
143
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
Figura 50. Resultado del MOO2MVA-CP-04: Instancia 2
Instancia 3
Figura 51. Resultado del MOO2MVA-CP-04: Instancia 3
Anexo B: Descripción de los Casos de Prueba
144
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 double protected cCuadradoC
area double protected cCuadradoC
apotema double protected cCuadradoC
diagonal double protected cCuadradoC
diagonales double protected cCuadradoC
perimetro double protected cCuadradoC
semiperimetro double protected cCuadradoC
radio double protected 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
Anexo B: Descripción de los Casos de Prueba
145
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
Anexo B: Descripción de los Casos de Prueba
146
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 double cRectanguloM Modelo
Instancia 2
Figura 57. Resultado del MOO2MVA-CP-06: Instancia 2
Tabla 19. Resultado del MOO2MVA-CP-06: Instancia 2, tabla Funciones Concretas MVA
Firma Especificador Tipo_Retorno Clase Patron_MVA
diagonalV(double) public void cRectanguloV Vista