tesis de maestría en ciencias

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