TESIS DE MAESTRÍA EN CIENCIAS - CENIDET - … Luz Christina... · 3.6 Compilador ... ANTLR Siglas...

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Refactorización de Marcos Orientados a Objetos hacia Arquitecturas MVC

presentada por

Luz Christina Gaitán Torres Ing. en Telemática por la Universidad de Colima

como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación

Director de tesis: Dr. René Santaolaya Salgado

Co-Directora de tesis: Dra. Olivia Graciela Fragoso Díaz

Cuernavaca, Morelos, México. 16 de febrero de 2012

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Refactorización de Marcos Orientados a Objetos hacia Arquitecturas MVC

presentada por

Luz Christina Gaitán Torres Ing. en Telemática por la Universidad de Colima

como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias de la Computación

Director de tesis: Dr. René Santaolaya Salgado

Co-Directora de tesis:

Dra. Olivia Graciela Fragoso Díaz

Jurado:

Dr. Joaquín Pérez Ortega– Presidente M.C. Mario Guillén Rodríguez – Secretario M.C. Humberto Hernández García – Vocal

Dr. René Santaolaya Salgado – Vocal Suplente

Cuernavaca, Morelos, México. 16 de febrero de 2012

Dedicatorias

A mi familia

Mis padres Efrén Gaitán y Rita Ycela Torres; y a mis hermanas Martha y Mary, cuyo amor y

apoyo incondicional me han motivado siempre a superarme. A pesar de la distancia siempre han

estado presentes en mi corazón. Los amo.

A la familia Salazar Robles

Al Sr. José y la Sra. Alicia, por su gran cariño e invaluable apoyo durante todo este tiempo,

por acogerme como un miembro más de su familia, muchas gracias.

A Pepe

Por ser un gran pilar en mi vida, por apoyarme siempre en todos los ámbitos, por

escucharme y motivarme en los momentos difíciles y por su paciencia en los momentos de estrés;

pero sobre todo por su gran amor, muchas gracias. Te amo.

A mis amigos

Quienes a pesar de la distancia siempre estuvieron conmigo y aunque sólo los veía unas

cuantas veces al año siempre me recibían con gran cariño y me recargaban de energía, gracias

Chuy, Lupita y Manuel.

A Fideo

Por alegrarnos la vida con su existencia durante el tiempo que estuvo con nosotros. Te

extrañamos.

Agradecimientos

Agradezco al Consejo Nacional de Ciencia y Tecnología CONACYT por el apoyo económico

que me brindó durante todo este tiempo.

Al Centro Nacional de Investigación y Desarrollo Tecnológico CENIDET que me abrió las

puertas y me permitió superarme tanto en el ámbito profesional como en el personal, a todos los

que labora en el Centro mi más grande agradecimiento.

A mi director de tesis el Dr. René Santaolaya Salgado y mi codirectora la Dra. Olivia

Graciela Fragoso Díaz, por guiarme y brindarme sus conocimientos ayudándome a llevar a cabo

esta investigación. Les agradezco su invaluable apoyo, su paciencia, sus buenos consejos y la

confianza que depositaron en mí.

A mis revisores Dr. Joaquín Pérez Ortega, M.C. Mario Guillén Rodríguez y M.C. Humberto

Hernández García, quienes me guiaron y aconsejaron durante la realización de esta tesis, gracias

por su compromiso con este trabajo y por el tiempo que le brindaron.

A la M.C. Sheydi Anel Zamudio López con quien tuve la fortuna de trabajar estrechamente,

por ayudarme, aconsejarme, por compartir su conocimiento conmigo y por convertirse en una

buena amiga.

A los distintos maestros que participaron en mi formación profesional durante mi estancia

en el CENIDET muchísimas gracias.

A mi familia, abuelita, tías, tíos y primos; a Pepe y a las familias Salazar Aviña y Robles

López; quienes con su confianza y apoyo colaboraron en la realización de esta tesis.

A mis compañeros y nuevos grandes amigos: Adrián, Lucy, Blanca, Liz, Ricardo E. y Ricardo

G. por todos los buenos momentos que vivimos, por su gran cariño y apoyo. Siempre ocuparán un

lugar muy importante en mi corazón.

A mis amigos de toda la vida por estar siempre a mi lado brindándome su apoyo y su

amistad. Y a mis excompañeros de trabajo quienes me apoyaron siempre. Muchas gracias.

A todos ustedes mil gracias por todo lo que han hecho en mi vida desde que los conocí.

i

Contenido

Pag.

Contenido ............................................................................................................................................. i

Lista de Tablas .....................................................................................................................................iii

Lista de Figuras .................................................................................................................................... v

Glosario de Términos ......................................................................................................................... vii

Resumen .............................................................................................................................................. xi

Abstract ............................................................................................................................................. xiii

Capítulo 1. Introducción ................................................................................................................ 1

1.1 Introducción ........................................................................................................................ 1

1.2 Descripción del problema ................................................................................................... 2

1.3 Objetivo ............................................................................................................................... 3

1.4 Justificación ......................................................................................................................... 3

1.5 Beneficios ............................................................................................................................ 3

1.6 Alcances y Limitaciones ....................................................................................................... 4

1.7 Organización de esta tesis ................................................................................................... 5

Capítulo 2. Antecedentes .............................................................................................................. 7

2.1 Antecedentes ...................................................................................................................... 7

2.2 Estado del arte .................................................................................................................. 10

Capítulo 3. Marco Teórico ........................................................................................................... 19

3.1 Refactorización .................................................................................................................. 19

3.2 Programación Orientada a Objetos ................................................................................... 20

3.3 Marcos de aplicaciones orientadas a objetos ................................................................... 21

3.4 Patrón Modelo Vista Controlador (MVC) .......................................................................... 22

3.5 Lenguaje de programación Java ........................................................................................ 26

3.6 Compilador ........................................................................................................................ 30

3.7 Servicio Web ...................................................................................................................... 34

3.8 Otros conceptos. ............................................................................................................... 34

Capítulo 4. Modelo Conceptual del Sistema ............................................................................... 37

4.1 Diseño del Proceso de Refactorización ............................................................................. 37

Contenido

ii

4.2 MOO2MVA: Marco de Aplicaciones Orientadas a Objetos hacia una arquitectura MVA 40

4.3 A1. Analizar el código del MOO original y etiquetar los estatutos, funciones y clases de

acuerdo a las partes del patrón MVA a las que pertenecen. ........................................................ 41

4.4 A2. Reestructurar el código legado. .................................................................................. 51

Capítulo 5. Implementación del Sistema ..................................................................................... 63

5.1 Implementación del proceso de refactorización en la herramienta MOO2MVA ............. 63

5.2 Implementación de la actividad A1. Analizar el código del MOO ..................................... 68

5.3 Implementación de la actividad A2. Reestructurar el código legado. .............................. 73

Capítulo 6. Pruebas del Sistema .................................................................................................. 75

6.1 Identificador del Plan de Pruebas ..................................................................................... 75

6.2 Documentación de Prueba ................................................................................................ 76

6.3 Descripción del Plan de Pruebas ....................................................................................... 76

6.4 Especificación del Diseño de Pruebas ............................................................................... 80

6.5 Especificación de Casos de Prueba ................................................................................... 84

6.6 Resultados de las Pruebas ................................................................................................. 90

6.7 Análisis de Resultados ....................................................................................................... 91

Capítulo 7. Conclusiones y Trabajos Futuros ............................................................................... 93

7.1 Conclusiones...................................................................................................................... 93

7.2 Trabajos futuros ................................................................................................................ 95

Bibliografía ........................................................................................................................................ 97

Anexo A: Métodos de Reestructura ................................................................................................ 101

Anexo B: Descripción de los Casos de Prueba ................................................................................. 123

iii

Lista de Tablas

Pag.

Tabla 1. Comparación de trabajos relacionados. .............................................................................. 17

Tabla 2. Descripción del patrón MVC y sus variaciones. ................................................................... 26

Tabla 3. Descripción de la tabla Tipos de clases ............................................................................... 42

Tabla 4. Descripción de la tabla Funciones Abstractas ..................................................................... 43

Tabla 5. Descripción de la tabla Funciones Concretas ...................................................................... 43

Tabla 6. Descripción de la tabla Tipos de Variables .......................................................................... 43

Tabla 7. Descripción de la tabla Jerarquía de Clases ......................................................................... 52

Tabla 8. Descripción de la tabla Variables MVA ................................................................................ 58

Tabla 9. Documentos del plan de pruebas ........................................................................................ 76

Tabla 10. Clases de Java a usarse como elementos de prueba ......................................................... 77

Tabla 11. Resumen de los resultados obtenidos en las pruebas ...................................................... 90

Tabla 12. Resultados del MOO2MVA-CP-01: Tabla Tipos de Variables .......................................... 127

Tabla 13. Resultado del MOO2MVA-CP-01: Tabla Funciones abstractas ....................................... 131

Tabla 14. Resultado del MOO2MVA-CP-01: Tabla Funciones concretas ........................................ 133

Tabla 15. Resultado del MOO2MVA-CP-01: Tabla Tipos de Clases ................................................. 138

Tabla 16. Resultado del MOO2MVA-CP-02: Tabla Jerarquía de Clases .......................................... 139

Tabla 17. Tabla Variables MVA para el caso de prueba MOO2MVA-CP-05 .................................... 144

Tabla 18. Resultado del MOO2MVA-CP-06: Instancia 1, tabla Funciones Concretas MVA ............ 146

Tabla 19. Resultado del MOO2MVA-CP-06: Instancia 2, tabla Funciones Concretas MVA ............ 146

v

Lista de Figuras

Pag.

Figura 1. Arquitectura del patrón MVC ............................................................................................. 23

Figura 2. Arquitectura del patrón MVA ............................................................................................. 25

Figura 3. Fases de un Compilador ..................................................................................................... 31

Figura 4. Ejemplo de función especializada. ..................................................................................... 34

Figura 5. Ejemplo de función no-especializada ................................................................................. 35

Figura 6. Ejemplo de clase especializada .......................................................................................... 35

Figura 7. Ejemplo de clase no-especializada ..................................................................................... 36

Figura 8. Proceso de refactorización de MOO a arquitectura MVA .................................................. 41

Figura 9. Diagrama de Actividad del Método R1: “Analizar Código Legado” ................................... 44

Figura 10. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 2)................... 45






Figura 16. Diagrama de Actividad del Método R7: “Estructura jerárquica de clases” ...................... 53

Figura 17. Diagrama de Actividad del Método R2: “Crear clases” .................................................... 55

Figura 18. Diagrama de Actividad del Método R3: “Crear constructor” ........................................... 57

Figura 19. Diagrama de Actividad del Método R3: “Crear constructor” (parte 2) ............................ 58

Figura 20. Diagrama de Actividad del Método R5: “Reubicar atributos” ......................................... 59

Figura 21. Diagrama de Actividad del Método R4: “Crear funciones” .............................................. 61

Figura 22. Diagrama de Actividad del Método R4: “Crear funciones” (parte 2) ............................... 62

Figura 23. Diagrama general de la herramienta MOO2MVA ............................................................ 64

Figura 24. Diagrama de clases del paquete InterfazGrafica ............................................................. 65

Figura 25. Diagrama de clases del paquete Adaptador .................................................................... 65

Figura 26. Diagrama de clases del paquete MOO2MVA ................................................................... 66

Figura 27. Diagrama de clases del paquete MOO2MVA.baseDatos ................................................. 67

Figura 28. Diagrama de clases del paquete MOO2MVA.A1.Analizar ............................................... 68

Figura 29. Proceso de obtención de la tabla de símbolos ................................................................. 69

Figura 30. Proceso de etiquetación utilizando la tabla de símbolos ................................................. 71

Figura 31. Diagrama de clases del paquete MOO2MVA.A1.Analizar.TablaSímbolos ....................... 72

Figura 32. Diagrama de clases del paquete MOO2MVA.A2.Refactorizar ......................................... 74

Figura 33. Diagrama de clases del MOO Figuras Geométricas ......................................................... 78

Figura 34. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 1) .. 124

Figura 35. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 2) .. 125

Figura 36. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEquilatero.java . 125

Figura 37. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEscaleno.java ... 126

Lista de Figuras

vi

Figura 38. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloIsoceles.java .... 126

Figura 39. Resultado del MOO2MVA-CP-03: Instancia 1 ................................................................ 141









Figura 48. Constructor en la clase cCubo ........................................................................................ 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



vii

Glosario de Términos

Acoplamiento Nivel de dependencia entre las unidades de software de un sistema informático, es decir, el grado en que una unidad puede funcionar sin recurrir a otras. Se recomienda que exista bajo acoplamiento.

ANTLR Siglas en inglés de ANother Tool for Language Recognition cuya traducción al español es Otra Herramienta para Reconocimiento de Lenguajes. Es una herramienta de software que opera sobre lenguajes, proporcionando un marco para construir reconocedores, intérpretes, compiladores y traductores de lenguajes a partir de las descripciones gramaticales de los mismos.

ASP Siglas en inglés de Active Server Pages cuya traducción al español es Páginas Activas en el Servidor. Es una tecnología de Microsoft que se ejecuta de lado del servidor, se utiliza para páginas web generadas dinámicamente, que ha sido comercializada como un anexo a Internet Information Services (IIS).

AST Siglas en inglés de Abstract Syntax Tree cuya traducción al español es Árbol de Sintaxis Abstracta. Es una representación del árbol de la estructura sintáctica abstracta de código fuente escrito en un lenguaje de programación.

Capa Estructura lógica de los diferentes elementos que componen el software.

COBOL Siglas en inglés de COmmon Business-Oriented Language cuya traducción al español es Lenguaje Común Orientado a Negocios. Es un lenguaje de programación creado con la intención de que fuera un lenguaje universal que pudiera ser usado en cualquier ordenador, y que estuviera orientado principalmente a los negocios.

Código legado Se refiere a sistemas de software desarrollados o diseñados tiempo atrás del proyecto actual de diseño. Por lo general son sistemas que los clientes desean que sean reusados o actualizados

Cohesividad Hace referencia a la forma en que agrupamos unidades de software en una unidad mayor. El consenso general para una buena programación o un buen diseño es que la cohesión debe ser alta.

Componente Unidad de composición con interfaces especificadas en forma de contrato y con dependencias de contexto explícitas. Un componente puede ser desplegado o instalado independientemente y es sujeto a ser composición por terceras entidades.

Composición Tipo de relación que se establece entre dos objetos que tienen comunicación persistente. Se utiliza para expresar que un par de objetos

http://es.wikipedia.org/wiki/Internet_Information_Services

http://es.wikipedia.org/wiki/Internet_Information_Services


viii

tienen una relación de dependencia para llevar a cabo su función, de modo que uno de los objetos involucrados está compuesto por el otro.

Enfoque holístico Tendencia o corriente que analiza los eventos desde el punto de vista de las múltiples interacciones que los caracterizan

IDE Siglas en inglés de Integrated Development Environment cuya traducción al español es Entorno de Desarrollo Integrado. Es un programa informático compuesto por un conjunto de herramientas de programación. Puede dedicarse en exclusiva a un solo lenguaje de programación o bien poder utilizarse para varios.

IIS Siglas en inglés de Internet Information Services cuya traducción al español es Servicios de Información de Internet. Es un servidor web y un conjunto de servicios para el sistema operativo Microsoft Windows

JavaBeans Son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones en Java. Se usan para encapsular varios objetos en un único objeto (la vaina o Bean en inglés), para hacer uso de un solo objeto en lugar de varios más simples.

Java Servlets Son objetos que han sido programados en Java y se ejecutan dentro del contexto de un contenedor de servlets y extienden su funcionalidad. El uso más común de los servlets es generar páginas web de forma dinámica a partir de los parámetros de la petición que envíe el navegador web.

JSP Siglas en inglés de JavaServer Pages cuya traducción al español es Páginas de Servidor de Java. Es una tecnología Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo.

Lexer Analizador léxico o analizador lexicográfico, es la primera fase de un compilador consistente en un programa que recibe como entrada el código fuente de otro programa (secuencia de caracteres) y produce una salida compuesta de tokens (componentes léxicos) o símbolos.

Microsoft SQL Server

Sistema para la gestión de bases de datos producido por Microsoft basado en el modelo relacional. Sus lenguajes para consultas son T-SQL y ANSI SQL.

Paradigma de programación

Propuesta tecnológica que es adoptada por una comunidad de programadores cuyo núcleo central es incuestionable en cuanto a que unívocamente trata de resolver uno o varios problemas claramente delimitados. Un paradigma de programación está delimitado en el tiempo en cuanto a aceptación y uso ya que nuevos paradigmas aportan nuevas o mejores soluciones que la sustituyen parcial o totalmente.


ix

Parser Es una de las partes de un compilador que convierte el texto de entrada en otras estructuras (comúnmente árboles), que son más útiles para el posterior análisis y capturan la jerarquía implícita de la entrada.

Patrón arquitectural

Expresa un esquema de estructura de organización fundamental para el sistema software. Este provee un conjunto de subsistemas predefinidos, especifica responsabilidades e incluye reglas y guías para organizar las relaciones entre ellas.

Patrón de diseño Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Plataforma de desarrollo

Es el entorno de software común en el cual se desenvuelve la programación de un grupo definido de aplicaciones.

Reuso El reuso de código, o también llamado reuso de software, se refiere al uso de software existente, o a la lógica de algún software, para construir nuevo software.

SQL Siglas en inglés de Structured Query Language cuya traducción al español es Lenguaje de consulta estructurado. Es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en estas.

XML Siglas en inglés de eXtensible Markup Language cuya traducción al español es Lenguaje de Marcado Extensible. es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos, permite definir lenguajes para diferentes necesidades, de ahí que se le denomine metalenguaje.

VBScript Siglas en inglés de Visual Basic Script Edition cuya traducción al español es Visual Basic Edición para Script. Es un lenguaje interpretado por el Windows Scripting Host de Microsoft. Su sintaxis refleja su origen como variación del lenguaje de programación Visual Basic.

xi

Resumen

Un Marco de Aplicación Orientado a Objetos es una colección semicompleta de clases que

se ha transformado en una aplicación reusable, la cual puede ser utilizada para dar soluciones a un

grupo de problemas relacionados. Una manera en la que se podrían aprovechar mejor estos

marcos de aplicación, es colocándolos a disposición de una mayor cantidad de personas, utilizando

Internet para compartirlos como servicios Web.

Lo anterior provoca la necesidad de transformar los MOO a servicios Web, pero antes de

realizar esta transformación es necesario adaptar la arquitectura del código según el patrón

Modelo-Vista-Controlador (MVC por sus siglas), ya que se debe separar la parte de la Vista y el

Control de la parte del Modelo, la cual contiene la lógica del negocio.

La complejidad que se presenta al refactorizar los MOO bajo una arquitectura MVC, radica

en que las diferentes capas (Modelo, Vista y Controlador) pueden estar estrechamente acopladas

dentro de las diferentes aplicaciones, lo que provoca que se dificulte su separación.

El presente trabajo describe un primer acercamiento para el desarrollo de una

herramienta llamada MOO2MVA, la cual tiene como objetivo automatizar la refactorización de

MOO hacia una arquitectura según el patrón MVC.

En este primer acercamiento se implementaron seis de los once métodos que conforman

el proceso de refactorización. Dicho proceso utiliza como base los métodos propuestos en

“Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el

patrón de diseño Modelo-Vista-Controlador”, tesis de maestría realizada en el laboratorio de

Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET).

Aunque se sabe que existen trabajos relacionados con el tema de la refactorización hacia

el patrón MVC, también se sabe que no todos están orientados hacia la total refactorización del

código; ni se enfocan en mantener la separación total de las capas de la Vista y el Modelo. Entre

las herramientas que se conocen están: M&S SW, PerCobol, UWAT+, HEDGEHOG, entre otros.

La diferencia entre las herramientas anteriores y el presente trabajo es que MOO2MVA es

una herramienta que apuesta por la total separación de la lógica del negocio (Modelo) y de la

presentación de los datos (Vista), así como un análisis profundo del código original que permita la

preservación de la lógica de negocio.

Los métodos implementados actualmente en la herramienta MOO2MVA fueron probados

con un MOO que consistía en 44 clases cuyo dominio estaba basado en el área de la geometría. De

las pruebas realizadas a estos métodos, se obtuvo el cien por ciento de resultados positivos.

Con base en los resultados obtenidos de las pruebas, se concluyó que la refactorización

automática hacia el patrón MVC, realizada por una herramienta, es posible. También se propone

como trabajo futuro la implementación de los cinco métodos restantes.

xiii

Abstract

A Framework for Object-Oriented Application is a semi-complete collection of classes that have

been transformed into a reusable application, which can be used to provide solutions to a group of

related problems. One way in which these application frameworks could be better used, is by

placing them at the disposal of a greater number of people by using the Internet to share them as

Web services.

This causes the need to transform the MOOs into Web services, but before achieving this,

it is necessary to adapt the architecture of code according to the Model-View-Controller

architectural pattern (MVC for short), since the View and Control layer must be separated from

the Model layer, which contains the business logic.

The complexity presented when refactoring the MOOs into a MVC architecture, is that the

different layers (Model, View and Controller) can be tightly coupled in different applications,

leading to a difficult separation.

This paper describes a first approach for developing a tool called MOO2MVA, which aims

to automate refactoring MOO towards an architecture according to the MVC pattern.

In this first approach, were implemented six of the eleven methods that make the process

of refactoring. This process uses the proposed methods based on "Heuristic Methods for

restructuring application frameworks towards the object-oriented Model-View-Controller design

pattern", a Master degree thesis conducted at the Software Engineering Laboratory of the

National Center for Research and Development of Technology (CENIDET).

Although it is known that there are papers related to the topic of refactoring towards the

MVC pattern, it is also known that not all are aimed towards complete refactoring of the code, nor

focus on maintaining the complete separation of the View and Model layers. Among the tools that

are known are: M&S SW, PerCobol, UWAT + HEDGEHOG, among others.

The difference between the previous tools and the present work is that MOO2MVA is a

tool that is committed to total separation of business logic (Model) and data presentation (View),

and a thorough analysis of the original code that allows the preservation of the business logic.

The first stage in the development of the MOO2MVA tool was tested with a framework for

object-oriented applications consisting of 44 classes whose domain was based on the field of

geometry. From the tested implemented methods, we obtained one hundred percent positive

results.

Based on the results of the tests it was concluded that the automatic refactoring towards the MVC

pattern by a tool is possible. Also, the implementation of the five remaining methods was also

proposed as future work.

Introducción

1

Capítulo 1. Introducción

En este capítulo se presenta una introducción al tema de tesis, la descripción del problema,

objetivo, alcances, limitaciones, justificación, beneficios y la organización general de este

documento.

1.1 Introducción

Un Marco de Aplicación Orientado a Objetos (MOO por sus siglas) es una colección semicompleta

de clases que se ha transformado en una aplicación reusable, la cual puede ser utilizada para dar

soluciones a un grupo de problemas relacionados, de esta manera dicho MOO puede ser utilizado

para generar nuevas aplicaciones hechas a la medida [FAYA,97].

Sin embargo, los MOO, generalmente son explotados de manera centralizada y propietaria

dentro de cada una de las empresas que los posee.

Una manera en la que se podrían aprovechar mejor estos marcos de aplicación, es

poniéndolos a disposición de una mayor cantidad de personas utilizando Internet para

compartirlos como servicios Web, estos servicios tendrían la misma funcionalidad que los MOO

pero podrían ser explotados por una mayor cantidad de personas.

Capítulo 1

2

Lo anterior provoca una nueva necesidad, que es la de transformar los MOO a servicios

Web. Una solución a esta nueva necesidad es la refactorización de los MOO para obtener servicios

Web, pero antes es necesario adecuar la arquitectura del código según el patrón MVC ya que se

debe separar la parte de la Vista y el Control de la parte del Modelo, la cual contiene la lógica del

negocio.

Es decir, para poder realizar la refactorización de un MOO hacia servicios Web es

necesario hacer una transformación intermedia, en la cual se reestructura la arquitectura del MOO

y sus componentes se hacen menos dependientes entre sí, para esto se utiliza el patrón

arquitectural MVC el cual separará el código de las aplicaciones en tres capas (Modelo, Vista y

Controlador) generando así la estructura adecuada para eliminar las capas de la Vista y el Control y

transformar la capa del Modelo a servicios Web.

En el laboratorio de Ingeniería de Software del CENIDET, se han realizado varios trabajos

relacionados a la refactorización de código legado, y el principal antecedente para la

refactorización de MOO hacia el patrón MVC, es la tesis de maestría titulada “Métodos Heurísticos

para reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-

Vista-Controlador” [NUÑE,08]. Con la implementación de los métodos propuestos en dicha tesis se

da continuidad a esta línea de investigación.

Por lo que en este trabajo de tesis se propuso la generación de una herramienta que

ayude a realizar esta refactorización de los MOO hacia una arquitectura MVC, utilizando los

métodos propuestos en [NUÑE,08]. Para que así, después de realizar la refactorización se pueda

tomar la parte correspondiente al Modelo y transformarlo a servicios Web.

1.2 Descripción del problema

Los MOO representan una buena opción para el reuso tanto del diseño como de código de manera

centralizada y propietaria, pero si se quiere poner a disposición de un mayor número de usuarios a

través de Internet para el desarrollo de nuevas aplicaciones, es casi imposible lograrlo debido a

que los MOO no están escritos en un lenguaje estandarizado para ser utilizados por diferentes

plataformas de desarrollo.

Una de las estrategias para reusar los MOO a través de Internet, es transformarlos a

servicios Web, los cuales proporcionan mecanismos de comunicación estándar entre diferentes

aplicaciones.

El problema radica en que no se pueden transformar los MOO a servicios Web

directamente sin antes separar las clases y funciones que son altamente interactivas con el usuario

(capa de la Vista) y la parte que controlan la lógica de la aplicación (capa del Controlador); de la

parte que contiene la lógica del negocio (capa del Modelo); y muchas veces en la arquitectura de

los MOO estas tres capas se encuentran mezcladas, por lo que primero se debe realizar la

transformación a una arquitectura que permite separar estas tres capas, es decir, a la arquitectura

del patrón MVC.

Introducción

3

La complejidad que se presenta al refactorizar los MOO bajo una arquitectura MVC, radica

en que estas capas (Modelo, Vista y Controlador) pueden estar estrechamente acopladas dentro

de las diferentes aplicaciones, lo que provoca que se dificulte su separación.

1.3 Objetivo

Dividir la arquitectura original de los MOO hacia una arquitectura MVC con el propósito de

favorecer su reúso como servicios Web, mediante el desarrollo de una herramienta que

implemente los métodos desarrollados en “Métodos Heurísticos para reestructurar marcos de

aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador” [NUÑE,08].

1.4 Justificación

El desarrollo de una herramienta que separe la arquitectura de los MOO en las diferentes capas

que conforman el patrón MVC, es de utilidad para satisfacer la necesidad de refactorizar los MOO

para obtener servicios Web.

La necesidad de llevar los MOO hacia servicios Web existe debido a que, aunque existen

procesos y herramientas para refactorizar o transformar código legado, ya sea al patrón

arquitectural MVC o a la Web, relativamente poco esfuerzo se ha invertido en trabajos de

investigación enfocados en buscar formas para extender el aprovechamiento y reuso de MOO en

mayor escala.

De acuerdo a [BOSC,97] existe una gran cantidad de investigación y desarrollo de software

tanto en compañías como en universidades e incluso a nivel gubernamental, lo que ha provocado

la creación de un gran número de MOO.

Por otro lado, actualmente es común colocar en Internet, a disposición de otros

desarrolladores, componentes de software como recursos de la Web, los cuales proporcionan las

mismas ventajas que los MOO, pero ahora lo hacen en internet y de manera independiente a la

plataforma de desarrollo, y además pueden ser accedidos por una mayor cantidad de clientes. Lo

que provoca la necesidad de transformar MOO a servicios Web, ya que el tiempo y conocimiento

invertido en el desarrollo de los MOO no debería ser desperdiciado, sino adaptado a las nuevas

tecnologías.

1.5 Beneficios

El desarrollo de una herramienta que ayuda a realizar la refactorización de MOO hacia una

arquitectura MVC favorece la productividad de los desarrolladores de software, pues al separar la

lógica de negocios de la presentación al usuario, se simplifican las tareas de mantenimiento y

reuso, lo que aumentaría la productividad de los desarrolladores y se obtendrían aplicaciones de

Capítulo 1

4

mayor calidad y confiabilidad, ya que dichos componentes provendrían de aplicaciones maduras,

probadas y confiables.

Además, una vez realizada la separación del MOO en las diferentes capas que conforman

el patrón MVC, la parte del Modelo puede ser aprovechada como servicios Web posibilitando el

aprovechamiento de toda la experiencia implícita en estos MOO, por ejemplo, en las aplicaciones

de negocios, de ingeniería, en la educación, el comercio electrónico, etc.

1.6 Alcances y Limitaciones

1.6.1 Alcances

A continuación se presentan los alcances bajo los cuales se llevó a cabo la presente investigación:

Probar y refinar los métodos propuestos en la tesis de maestría titulada “Definición de

métodos heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia

el patrón de diseño Modelo-Vista-Controlador” [NUÑE,08].

Diseño de un proceso de refactorización utilizando los métodos propuestos en [NUÑE,08]

una vez que estos han sido refinados.

La cantidad de métodos implementados está limitado por el tiempo y las dificultades

encontradas durante el desarrollo de la investigación.

1.6.2 Limitaciones

Las limitaciones bajo los cuales se llevó a cabo el desarrollo de la investigación son las siguientes:

Se implementaron seis de los once métodos necesarios para realizar la refactorización, por

lo que el proceso de refactorización no se realiza completamente.

El proceso de refactorización no fue diseñado para refactorizar MOO cuyo dominio sean

las interfaces de usuario.

La herramienta funciona para MOO escritos en Java.

La herramienta funciona para MOO que contengan código libre de defectos de

compilación y ejecución.

Las interacciones del usuario consideradas son: entrada y salida de datos a través la línea

de comandos, es decir, con elementos de la librería java.io.

No se realizan transformaciones hacia servicios Web.

Introducción

5

1.7 Organización de esta tesis

La estructura restante de este documento se compone de seis capítulos más, los cuales se

describen a continuación.

Capítulo 2

En este capítulo se presentan los trabajos relacionados a esta investigación que fueron

desarrollados anteriormente en el CENIDET, el estado del arte y el análisis comparativo de algunas

investigaciones y herramientas de refactorización.

Capítulo 3

En este capítulo se presentan algunos conceptos teóricos relevantes y tecnologías

estudiadas para realizar la refactorización de los Marcos Orientados a Objetos hacia una

arquitectura MVC.

Capítulo 4

En este capítulo se describe el modelo conceptual en el que se basa el desarrollo de la

herramienta. Se describe el proceso de refactorización, las actividades y los métodos que lo

conforman.

Capítulo 5

En este capítulo se describe la implementación de los métodos de refactorización en la

herramienta. Se presentan los diagramas de clases y paquetes utilizados, los criterios de

etiquetación de código de acuerdo a la parte del patrón MVC a la que pertenecen y las tecnologías

utilizadas para el desarrollo de la herramienta.

Capítulo 6

En este capítulo se presentan el plan de pruebas para los métodos implementados en la

herramienta, la descripción del plan de pruebas y la especificación del diseño de pruebas.

Capítulo 7

En este capítulo se detallan las conclusiones alcanzadas, las aportaciones obtenidas con

esta investigación y los que se podrían considerar trabajos futuros.

Finalmente se presentan las referencias bibliográficas y dos anexos, el primero contiene

los métodos de refactorización y el segundo los resultados de las pruebas realizadas.

Antecedentes

7

Capítulo 2. Antecedentes

En este capítulo se presentan los trabajos relacionados a esta investigación que fueron

desarrollados anteriormente en el CENIDET, el estado del arte y el análisis comparativo de algunas

investigaciones y herramientas de refactorización.

2.1 Antecedentes

En el laboratorio de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo

Tecnológico (CENIDET), se han realizado varios trabajos relacionados a la refactorización de código

legado, pero el principal antecedente para la refactorización de Marcos de Aplicación Orientados a

Objetos hacia el patrón MVC, es la tesis de maestría titulada “Métodos Heurísticos para

reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-

Controlador” [NUÑE,08]. A continuación se hace una breve descripción de las diferentes

investigaciones.

Capítulo 2

8

2.1.1 Factorización de Funciones hacia Métodos de Plantilla

[HERN,03]

El objetivo de este trabajo fue desarrollar una herramienta de software que realiza

automáticamente la refactorización de código legado escrito en el lenguaje C bajo el paradigma de

programación por procedimientos y obtiene como resultado arquitecturas de clases reusables

orientadas a objetos escritos en el lenguaje C++.

El proceso de refactorización parte de un conjunto de tablas, generadas al analizar el

código fuente, las cuales contienen la información importante para la refactorización (variables

locales, globales, nombres de funciones, etc.). Para el proceso de refactorización se incorporan

siete métodos que en conjunto cumplen con la función de generar marcos de componentes

reusables orientados a objetos. Los métodos de la refactorización son:

Método de creación de clases: Se construyen plantillas o clases que con la integración de

otros métodos se van convirtiendo en clases de objetos.

Método de declaración de constructores: Consiste en declarar dentro de cada clase de

objetos dos constructores, el primero contiene la inicialización de la estructura de datos

de las instancias de la clase y el segundo recibe un parámetro por cada variable de la clase.

Método de composición de clases: Se definen los elementos de composición que puedan

ser empleados por una clase y los cuales definen la forma en que la clase se familiariza con

otra.

Método de reubicación de funciones: Reubica las funciones en su correspondiente clase

de objetos con sus respectivos parámetros y tipo de la función.

Método de fragmentación de funciones: Fragmenta una misma función que es

redundante en varias clases de objetos, para evitar la duplicidad de código.

Método de superjerarquizar: Se declaran clases abstractas para evitar la duplicidad de

funciones, en este método se identifican clases candidatas a superjerarquizar pero se

necesita la intervención de un experto el dominio para determinar cómo actuar en estos

casos.

Método de fábrica de objetos: Consiste en definir una interfaz para crear objetos dejando

a las subclases la decisión de cual clase instanciar, éste método es influenciado por el

patrón de diseño “Abstract Factory”.

2.1.2 Reestructuración de Código Legado a partir del

Comportamiento para la Generación de Componentes

Reutilizables [BUST,03]

El objetivo de este trabajo fue el desarrollo de una herramienta que permite restructurar de forma

automatizada y en base a patrones de diseño, la arquitectura de los fragmentos de código legado

escritos en lenguaje C, que presenten las características de tener estatutos condicionales con más

de tres alternativas o que puedan presentar varios niveles de anidamiento, debido al alto grado de

Antecedentes

9

complejidad que exhiben; lo anterior tiene el objetivo de hacer una descomposición de segmentos

genéricos de código reutilizable, para que puedan ser probados e incorporados en marcos de

componentes reutilizables orientados a objetos para su reutilización.

Para la restructuración, se toma como entrada código fuente basado en procedimientos

escrito en lenguaje C, al cual se le aplica un proceso de análisis y extracción de información, la cual

se almacena en un conjunto de tablas. Estas tablas son la fuente de información que se utilizará

para llevar a cabo el proceso de restructura y la generación de clases que presentará la estructura

de los patrones de diseño “State” y “Strategy”. Para de esta manera automatizar el proceso de

refactorización de software legado, de una organización basada en procedimientos hacia una

arquitectura de clases en colaboración o marco de trabajo de componentes reusables.

2.1.3 Reestructuración de Software Escrito por Procedimientos

Conducido por Patrones de Diseño Composicionales [MEND,04]

Este trabajo tuvo como objetivo la restructuración de código escrito en C, el cual exhibe muchas

líneas de código, un bajo nivel de cohesividad, altos costos de mantenimiento, alto nivel de

dependencia, alto nivel de complejidad, ausencia de mecanismos de herencia, composición y

delegación; y carencia de interfaces.

La restructuración se hace hacia marcos de aplicaciones orientados a objetos que

incorporen la arquitectura de patrones de diseño que permiten la composición de objetos, con el

fin de obtener segmentos genéricos de código reusables, que pueden ser ejercitados e

incorporados en depósitos de componentes para su reúso en aplicaciones posteriores, mejorando

los aspectos mencionados, además de repercutir en la mejor calidad del sistema y en la

simplificación de las tareas de mantenimiento y reúso.

2.1.4 Métodos Heurísticos para Reestructurar Marcos de

Aplicaciones Orientados a Objetos hacia el Patrón de Diseño

Modelo-Vista-Controlador [NUÑE,08]

El objetivo de esta investigación fue identificar los posibles escenarios que se pueden presentar en

arquitecturas de marcos de aplicaciones orientados a objetos o sistemas legados desarrollados en

el lenguaje de programación Java y a partir de los escenarios identificados desarrollar un conjunto

de métodos heurísticos para la restructura de los Marcos de Aplicación Orientados a Objetos

conforme al patrón MVC.

En esta investigación se generó conocimiento sobre los principales escenarios que se

presentan cuando se requieren restructurar sistemas legados. Se muestra la cantidad de

escenarios que pueden suceder cuando se lleva a cabo la restructura de código legado, la

complejidad y factibilidad de este tipo de trabajos.

Capítulo 2

10

Además, los escenarios identificados documentan la manera en que se puede llegar a

presentar el código de los Marcos de Aplicación Orientados a Objetos legados y una solución para

llevar a cabo la restructura utilizando los métodos heurísticos.

Fueron 8 los métodos generados en esta investigación, los cuales establecen los pasos

para manipular los componentes presentes en los sistemas legados; dichos métodos se describen

a continuación:

Definir plantilla genérica MVC: Utilizando el patrón de diseño “Command” genera una

arquitectura de clases conforme al patrón MVC.

Análisis del Código Legado: Identifica con qué parte del patrón MVC se relaciona cada

uno de los estatutos de código incluido en las clases.

Crear Clases: Define la declaración de clases simples, abstractas e interfaces, colabora

con los métodos de “Cohesionar clases”, “Super-Jerarquizar” y “Sub-Jeraquizar”.

Crear Constructor: Define dos tipos de constructores con parámetros y sin ellos.

Incluye la inicialización de las estructuras de datos de las instancias de las clases.

Crear función: Crea funciones especializadas con parámetros y sin parámetros, al

crearse se especializan y están listas para reubicarse en las clases correspondientes.

Reubicar Atributos: Reubica los atributos y su inicialización desde las clases legadas a

las clases concretas correspondientes de la plantilla MVC.

Fragmentar funciones: Fragmenta las funciones no especializadas y utiliza el método

de Crear Funciones para generar funciones especializadas las cuales serán reubicadas

en la plantilla MVC.

Redefinir llamadas a funciones: Sustituye la actual llamada a una función que después

de ser fragmentada queda ubicada en alguna de las clases de la plantilla MVC.

2.2 Estado del arte

Aunque existen varios procesos y herramientas para refactorizar o transformar código legado, ya

sea al patrón arquitectural MVC o a la Web, durante esta investigación no se encontraron

herramientas que tengan como entrada código Java y su salida sea código Java refactorizado hacia

una arquitectura MVC. A continuación se presentan algunas de estas investigaciones y

herramientas.

2.2.1 Tranforming Legacy Web Applications to the MVC

Architecture (Transformando Aplicaciones Web Legadas hacia la

Arquitectura MVC) [PING,04]

Este artículo relacionado presenta un marco de reingeniería cuyo objetivo es crear un sistema con

arquitectura basada en el patrón MVC y que sea compatible con la plataforma Java. Este marco

está enfocado principalmente en la fragmentación de aplicaciones web legadas mediante la

identificación de los componentes de software que serán transformados en objetos java.

Antecedentes

11

Se desarrollaron herramientas programadas en Java que son capaces de restructurar la

arquitectura de sitios Web basados en JSP a una arquitectura enfocada en el controlador, todo

esto mediante la extracción de la información obtenido del análisis de la aplicación JSP. Los

autores dicen que como se obtiene información de un sistema web, las mismas páginas pueden

ser reutilizadas. También afirman que el proceso de migración de un sistema, además de traducir

de un lenguaje origen a otro, también debería de mejorar la calidad de las características del

sistema migrado.

Las herramientas presentadas en este trabajo relacionado adoptan la arquitectura MVC en

el ambiente Enterprise de Java, y como resultado de esto la aplicación fuente es restructurada en

JavaBeans (Modelo), Java Server Pages (Vista) y Java Servlets (Control).

Para la parte del modelo, se utilizaron tres tipos de JavaBeans:

Bean de consulta: Se encarga de ejecutar las consultas SQL extraídas desde el

programa fuente.

Bean de acceso de datos: Este es un objeto java serializable, el cual consiste casi

exclusivamente de métodos “setters” y “getters”. Lleva un conjunto de información

desde los Bean de consulta a los Bean de datos.

Bean de datos: Es un contenedor de objetos que encapsula la invocación de un Bean

de consultas en una página JSP. Lleva a cabo cierto conjunto de acciones, tales como

establecer los parámetros del Bean de consulta y llenar de información al Bean de

acceso de datos.

Los autores utilizan el mismo término y significado de “contenedores” que se utilizó en el

artículo pasado, y afirman que utilizándolos para JavaBeans, se reduce significativamente la

cantidad de código Java utilizado en las páginas JSP, debido a que la implementación en Java del

acceso a datos está encapsulada dentro de Beans de datos.

En el enfoque mostrado en este artículo, se construyó un componente controlador central

sobre el sistema Web para llevar a cabo la administración de las peticiones de procesamiento del

cliente y los resultados de las páginas Web. En otras palabras, ninguna página Web está enlazada

directamente a ninguna otra. En vez de eso, las páginas se conectan a un controlador asociado, el

cual renvía la petición de una página origen a la página destino.

La metodología que siguieron se divide en tres pasos:

Separar el acceso de base de datos de la presentación lógica, mediante la extracción

de sentencias SQL del programa legado.

Hacer la transición a páginas JSP al separar los elementos desplegables del programa

legado, que necesiten ser remplazados por páginas JSP, con una cierta combinación

JavaBeans generados de la primera etapa.

Adoptar una arquitectura centrada en el controlador. En esta etapa se adapta la

arquitectura original al patrón MVC mediante el análisis del flujo de control (que

puede ser extraído de las primeras dos etapas), el cual es representado por una

colección de archivos HTML, páginas JSP generadas y objetos JavaBeans.

Capítulo 2

12

Para llevar a cabo estas tres etapas, se utilizaron cinco procesos que contienen actividades

basados en la restructuración de código. Los procesos son:

Sistema fuente: Representa a la aplicación de software que será restructurada.

Análisis de software: Aquí se trabaja con un analizador de lenguaje que lee el código

fuente y reconoce la estructura del programa de acuerdo a la gramática del lenguaje

original. Aquí se utiliza un Lexer y un Parser y se obtiene un AST (Árbol Abstracto de

Sintaxis).

Extracción de información: Aquí se extrae la información generada en el AST y se

transforma a objetos reconocibles por Java.

Generación de código nuevo: Este proceso apoya a la generación automática de

nuevas aplicaciones.

Sistema Destino: Etapa final del proceso de restructuración. Esta etapa representa la

plataforma recién creada basada en el proceso de restructura.

2.2.2 Migrating Legacy Systems to the Web: An Experience

Report (Migrando Sistemas Legados a la Web: Un Reporte de las

Experiencias) [AVER,01]

En este trabajo relacionado se presenta un proyecto de migración cuya intención es integrar un

sistema existente escrito en COBOL a una infraestructura Web. El sistema original ha sido dividido

en componentes de interfaz de usuario (páginas ASP) y servidor (lógica de la aplicación y el acceso

a base de datos). Los autores aseveran que “Normalmente los componentes del sistema que son

parte de la interfaz de usuario son restructurados en forma de página Web, y utilizan al navegador

Web como un contenedor y los componentes que implementan las funciones de negocio pueden

ser contenidos o remplazados por componentes estándar o nuevos”.

En este artículo se menciona que la interfaz de usuario (Vista) fue restructurada con

tecnología ASP (Páginas Activas en el Servidor) y VBScript, mientras que la parte de la lógica

(Modelo) fue implementada utilizando Microfocus Object COBOL. Los autores utilizaron una

solución de corto plazo que consiste en agregar una estructura contenedora al código legado, para

permitir la comunicación de éste con código nuevo mediante mensajes, en lugar de la restructura

de código total. Pero los autores reconocen que una solución a largo plazo podría ser la

restructura del código legado hacia la orientación a objetos en la parte del servidor, y migrar

incrementalmente los objetos obtenidos de dicha restructura, hacia una arquitectura de

componentes distribuida.

Los autores indican que basados en trabajos anteriores se considera que los sistemas de

software pueden tener tres tipos de componentes: componentes de interfaz, componentes de la

lógica de aplicación y componentes de base de datos. Basados en esta clasificación, los autores de

[AVER, 2001] agruparon a los componentes de interfaz como parte del cliente, mientras los

últimos dos en la parte del servidor. También hablan que dependiendo de qué tan separados y

Antecedentes

13

definidos estén estos componentes mencionados, se puede clasificar a los sistemas en

Desfragmentable, semi-desfragmentable e indesfragmentable.

Los pasos de restructuración y desfragmentación requieren de un análisis estático para la

extracción de información relevante desde el código fuente para guardarlos en un repositorio.

Como resultado de esta actividad, los programas legados son restructurados en un estilo cliente-

servidor.

La manera en la que los autores capturaron la estructura del programa legado fue

mediante Grafos de Llamadas, los cuales capturan la interacción que se tiene entre las páginas o

módulos del sistema legado. Para capturar estos grafos de llamadas, se utilizó una herramienta

comercial. Después de haber capturado al grafo, se utilizó una herramienta desarrollada por ellos

que transformó este grafo en árbol de jerarquía. Para confirmar que capturaron bien el sistema, se

entrevistaron con el equipo de programadores del sistema original.

Los autores mencionan que uno de sus objetivos fue encontrar el balance entre el

esfuerzo necesario entre restructurar o volver a desarrollar programas legados, y el esfuerzo

requerido para envolverlos. Debido a esto, mencionan que los programas que mantienen la

comunicación con la nueva interfaz gráfica fueron restructurados y envueltos, mientras que las

interacciones con los programas que mantienen comunicaciones con la base de datos, aún son

implementados a través de archivos en COBOL sin restructurar. Los archivos COBOL tienen forma

de librerías dinámicas escritas en Microfocus Object COBOL, son cargadas en el servidor Web IIS

(Internet Information Services) de Microsoft y la interfaz de usuario accede a ellas mediante las

funciones VBScript embebidas en las páginas ASP.

Los autores concluyen el artículo diciendo que están en vías de un nuevo proyecto que se

dedicará a restructurar la parte del servidor hacia una arquitectura orientada a objetos.

2.2.3 Towards a Holistic Approach to Redisigning Legacy

Applications for the Web with UWAT+ (Hacia un Enfoque Holístico

para el Rediseño de Aplicaciones Legadas para la Web con

UWAT+) [DIST,06]

En este artículo se propone un enfoque holístico utilizando UWA (Marco Ubicuo de Diseño de

Aplicaciones Web) y UWAT+(la versión extendida de UWA) que combina tecnologías de

recuperación de diseño para capturar las reglas del dominio embebidas dentro de las aplicaciones

legadas, y métodos de diseño específicos para aplicaciones Web.

El artículo explica que los marcos de diseño UWA y UWAT+ ofrecen al diseñador un

conjunto de metodologías, meta modelos, y herramientas para el diseño centrado en el usuario de

aplicaciones ubicuas de datos y sensible a operaciones. También explican la manera en la que se

conforma el marco UWA y UWAT+. Los procesos por los que se conforman UWAT+ son:

Elicitación de requisitos: Está orientada a la formalización de las metas del proceso de

rediseño y a los requisitos para la versión Web del código legado. En este proceso se

Capítulo 2

14

trabaja en conjunto con los usuarios del sistema para ponerse de acuerdo con los

diseñadores en qué opciones del sistema legado se mantendrán.

Ingeniería inversa: Está orientado la extracción y formalización de la información

desde el código legado. Como resultado se obtiene un boceto de la nueva aplicación.

Aquí también se identifica a los componentes que pueden o tienen que ser

reutilizados en la nueva versión del software. De esta etapa se extraen productos tales

como documentación, tipos de usuario de la aplicación, modelos de proceso etc. Pero

los productos más importantes son la obtención de la lógica del negocio y sus

componentes.

Diseño directo: Aquí se utilizan los requisitos definidos en la primera etapa y se

utilizan para refinar el boceto obtenido de la segunda etapa, produciendo así el diseño

final de la nueva versión Web de la aplicación.

El enfoque presentado en este trabajo relacionado se probó en una aplicación llamada

GPA, la cual estaba programada en Visual Basic 5 y utilizaba la base de datos Microsoft SQL, la cual

fue restructurada con éxito.

2.2.4 Re-Approaching the Refactoring Rubicon (Re-Abordando

el Rubicon de la Refactorización) [ABAD,08]

En este artículo relacionado, los autores llevaron a cabo un caso de estudio en el que convirtieron

un Java Servlet hacia el patrón Modelo-Vista-Controlador utilizando la mayor cantidad soporte

automatizado posible. Basado en los descubrimientos de este trabajo relacionado, los autores

definieron los requisitos para un marco de restructurar, el cual hará posible la fragmentación de

una transformación compleja mediante pasos de restructura bien definidos.

Los autores exponen que los métodos de restructura modernos soportados por las IDEs,

no son capaces de restructurar el Método de Extracción de Fowler. Las transformaciones que se

utilizaron en este trabajo relacionado fueron expresadas como una serie de 36 pasos de

restructura, los cuales consistían en 14 tipos de restructuraciones. Se menciona que todos ellos,

menos cuatro, se encuentran documentados en el catálogo de Fowler. El Método de Extracción se

encuentra dentro del catálogo de Restructuras de Martin Fowler.

Basados en una serie de pruebas, los autores concluyen que los ambientes de desarrollo

modernos no tienen mucha capacidad de restructuración de código, y que muchas de esas

capacidades de restructura de alto nivel, requieren de métodos más pequeños de restructuración.

Además de que en ciertos casos existe más de una forma de implementar la misma

restructuración. Se menciona que el Método de Extracción debería de dar a elegir al usuario entre

varias formas de restructuración. También se menciona que las implementaciones actuales

contienen precondiciones demasiado fuertes para la restructuración, y todo debido al análisis

insuficiente acerca de la restructuración.

Según dicen los autores, un marco de restructuración que sea capaz de invocar varios

métodos pequeños para llevar a cabo una restructuración mayor, sería de gran ayuda para los

Antecedentes

15

desarrolladores y les facilitaría el trabajo. Y para que un marco de restructura sea realmente

efectivo es necesario que posea capacidades profundas de análisis.

2.2.5 Migrating COBOL Systems to the Web by Using the MVC

Design Pattern (Migrando Sistemas COBOL a la Web Utilizando el

Patrón de Diseño MVC) [BODH,02]

Este trabajo relacionado presenta una estrategia de migración cuyo objetivo es un sistema con

arquitectura web basado en el patrón MVC, además de un conjunto de herramientas con

propósitos definidos dentro de la estrategia. Al extraer toda la información necesaria desde el

código fuente en COBOL, las herramientas presentadas en este artículo pueden generar

contenedores para la lógica de negocio y el modelo de datos, y generar una interfaz de usuario

web en forma de JSP (Java Server Pages).

Los autores del artículo afirman que “A menudo, el código legado es la única fuente del

conocimiento del dominio así como también es la única descripción real de las reglas del dominio

actual”. Por lo tanto, mantienen la reestructura de código legado al mínimo, mientras toman el

enfoque de los contenedores de código. Los autores definen a los contenedores de código como

clases de código nuevo que “envuelve” al código legado, sin traducir de un lenguaje a otro, o sin

tener que cambiar la estructura del código original. Siguiendo la definición de “contenedor”,

también afirman que éstos representan una interfaz que le da acceso a las nuevas aplicaciones por

parte los componentes de código legado mediante el intercambio de mensajes. Las llamadas

recibidas por el contenedor, son convertidas en llamadas a los componentes del sistema que

realizan el servicio requerido. Para comunicar al objeto contenedor con el código COBOL, se utilizó

PERCobol, el cual es un compilador comercial desarrollado por la empresa LegacyJ, que es capaz

de compilar más de 15 dialectos de Cobol, puede traducir código COBOL a Java y puede

encontrarse en su sitio web www.legacyj.com. De esta manera, al mantener la parte del dominio

en el modelo, se enfocan en restructurar la parte de la vista para convertirlo en páginas Web JSP.

La metodología propuesta por los autores se llama M&S SW (Métodos y Herramientas

para la Producción de Software, Formación y Aplicaciones). Está compuesta por 8 etapas en las

cuales se utilizan siete herramientas programadas en Java para las diferentes etapas. Las

herramientas son:

Analizador: Ejecuta un análisis estático del código legado y utiliza ANTLR para realizar

el análisis.

Controlador: Produce reportes gráficos y textuales al procesar la información

almacenada en el repositorio. Genera los servlets pertenecientes a la capa del

controlador.

Cortadora: Descompone los programas al aplicar algoritmos de cortes basados en el

análisis de control de dependencias.

Capítulo 2

16

Extractor: Identifica los objetos asociados con el almacenamiento de datos dentro del

código legado. Cada objeto corresponde a un almacén de datos que contiene atributos

que son asociados a la estructura de datos.

Reingeniería: Crea la división de datos en el nuevo programa COBOL que contenga los

métodos extraídos del código original.

Re-Implementador: Genera una nueva interfaz de usuario para los componentes del

sistema mediante JSP.

Generador de contenedor: Genera un objeto en Java para envolver y acceder al

código legado restructurado.

Repositorio: Sirve para guardar la información que se obtiene de cada etapa. No es

una herramienta, pero interactúa con todas las anteriores. La información que se

almacena aquí está en formato XML.

Mediante el patrón MVC se puede mantener la lógica del programa en la parte del

modelo, y la interfaz de usuario en la vista. Las correspondencia entre la interfaz HTML y los

componentes son determinados mediante el análisis estático.

2.2.6 Análisis comparativo

La Tabla 1 muestra un resumen de las características encontradas entre los trabajos relacionados y

el trabajo de esta tesis.

Antecedentes

17

Tabla 1. Comparación de trabajos relacionados.

Proyecto/Atributo

Tipo de proyecto Arquitectura resultante

Entradas Salidas Es Automática Lenguaje

[PING,04] Marco de reingeniería

MVC centrado en el controlador

Páginas JSP JavaBeans, JSP y Java Servlets

Sí, el usuario no interviene directamente.

Java

[AVER,01] Metodología Cliente-Servidor (Vista-Modelo)

Código COBOL, Grafos de llamada

ASP, VBScript y Librerías Dinámicas de ASP

No, es manual. Se sigue la metodología MORPH para la separación de código.

Metodología MORPH

[DIST,06] Metodología Cliente servidor (Vista-Modelo)

Visual Basic 5 Código Visual Basic y HTML

No, es manual. Metodología UWAT+

[ABAD,08] Caso de estudio MVC Java Servlets Código Java No, es semiautomática, pues utilizaron el soporte de reestructuración de la IDE Eclipse

Soporte de la IDE Eclipse

[BODH,02] Estrategia y herramientas

MVC Código COBOL JSP, XML Sí, el usuario no interviene directamente.

Java

Tesis (MOO2MVA)

Herramienta MVA (Variante de MVC)

Código Java Código Java refactorizado

Sí, el usuario elige el proyecto a refactorizar y el sistema lo hace automáticamente.

Java

Capítulo 2

18

Como se puede observar en la Tabla 1 los proyectos no utilizan el mismo tipo de

metodología o herramienta, y algunos manejan una arquitectura diferente al proyecto de esta

tesis.

Algunos proyectos usan sólo metodologías mientras que otros ya han adaptado dichas

metodologías y han creado herramientas que automatizan el trabajo. A diferencia de las

metodologías manuales, la herramienta presentada en este trabajo sería automática, lo que evita

que el usuario pueda cometer algún tipo de error.

Los proyectos que manejan la refactorización de código, se pueden dividir en dos

filosofías: Los que envuelven el código legado con un contenedor que sirve de adaptador, y los que

refactorizan totalmente el código legado. Al ser una herramienta que refactoriza todo el código de

entrada, se podría decir que el proyecto de esta tesis presenta una solución a largo plazo, en lugar

de corto plazo como indican los proyectos con filosofías de contenedores de código legado.

La mayoría de los proyectos utilizan la arquitectura MVC o algún derivado de ella, mientras

que los restantes son considerados por sus autores como una arquitectura de dos niveles (Cliente-

Servidor) con vías a expandirse al patrón MVC. En este proyecto de tesis se propone una

herramienta que refactorice código Java hacia código Java, bajo la arquitectura MVC en su

variante MVA, la cual se considera que podría adaptarse al medio Web sin perder la flexibilidad del

patrón MVC.

Las entradas son variadas, pero siempre es código que en algún momento del proyecto se

analiza automáticamente o manualmente, y se refactoriza teniendo como salidas código Java u

otros lenguajes orientados a objetos. La herramienta desarrollada en este proyecto de tesis está

programada en Java y ofrece como entradas y salidas código Java.

Si bien no todos los proyectos utilizan una herramienta automática, queda asentado por

los autores de los respectivos trabajos, que se encuentran en vías de desarrollar soporte

automático para la implementación de sus marcos y metodologías.

Si tomamos el trabajo relacionado [BODH, 02] y lo comparamos con el el trabajo realizado

en esta tesis, se puede observar que los dos utilizan una metodología como base del proceso para

la refactorización, y basado en cada metodología, se produce una herramienta que implementa

dicho proceso de refactorización.

Ambas herramientas están basadas en el patrón MVC, y están construidas en el lenguaje

Java. Las entradas y salidas varían, puesto que el trabajo [BODH, 02] necesita código COBOL como

entrada y produce páginas JSP y datos en formato XML, mientras que la herramienta actual toma

como entrada código Java y produce código Java. Las dos herramientas son consideradas como

automáticas, pues no se requiere la intervención del usuario más que para seleccionar algunos

aspectos que no involucran a la parte del análisis de código.

Marco Teórico

19

Capítulo 3. Marco Teórico

En este capítulo se presentan algunos conceptos teóricos relevantes y tecnologías estudiadas para

realizar la refactorización de los Marcos Orientados a Objetos hacia una arquitectura MVC.

3.1 Refactorización

Fowler define la refactorización como:

“Proceso de cambiar un sistema de software de tal manera que no se altere el

comportamiento externo del código pero se mejora su estructura interna.” [FOWL,99]

Se dice que al refactorizar se mejora el diseño del código después de que éste fue escrito,

ya que el proceso permite “limpiarlo” y reduce las posibilidades de errores [FOWL,99]. Con la

refactorización se puede tomar un mal diseño y restructurarlo como código bien diseñado, con

pasos simples se puede mejorar el diseño radicalmente o adaptarlo a nuestras nuevas

necesidades.

Durante la refactorización se considera que a partir cómo está construido un sistema se

puede aprender cómo mejorarlo. El resultado de esto nos permite mantener un sistema con un

buen diseño conforme su desarrollo continúa.

Capítulo 3

20

3.2 Programación Orientada a Objetos

La Programación Orientada a Objetos (POO) es uno de los muchos paradigmas (o modelos) de

programación que existen. En este paradigma, el sistema de software es visto como un conjunto

de objetos que colaboran entre sí, mediante el envío de mensajes para resolver un problema

[PILL,06].

La Programación Orientada a Objetos tiene 5 componentes clave: Clase, Objeto, Instancia,

Mensaje y Método.

Clase: Una clase es una plantilla que define las variables y métodos comunes a todos los

objetos de un cierto tipo. Una vez que se creó una clase se pueden crear cualquier número de

objetos de esa clase.

Objeto: Un objeto es un paquete de software que contiene variables y métodos relacionados.

Las variables son elementos de datos identificados por un nombre y los métodos son

funciones asociadas al objeto.

Instancia: Todos los objetos son instancias de una clase. El método invocado por un objeto en

respuesta a un mensaje es determinado por su clase. Todas las instancias de una clase usan el

mismo método para responder a un mismo mensaje.

Mensaje: Un mensaje es una petición para realizar una acción. El mensaje codifica la petición

de una acción y, en algunos casos, es acompañado por información adicional (en forma de

parámetros) necesaria para realizar la acción. El receptor es el objeto al que se le envía el

mensaje. Si el receptor acepta el mensaje deberá llevar a cabo la acción indicada (un método)

para satisfacer la solicitud.

Método: Un método es una función asociada al objeto de una clase. Es cómo un objeto

responde a un mensaje.

3.2.1 Propiedades de la POO

La POO se basa en 4 propiedades que todos los lenguajes de programación orientados a objetos

deben ser capaces de soportar: Abstracción de datos, Encapsulamiento de datos, Herencia y

Polimorfismo.

3.2.1.1 Abstracción

Según Timothy Budd:

“La abstracción es la supresión deliberada, con el fin de ocultar algunos detalles de un

proceso o artefacto, para poner de manifiesto más claramente otros aspectos, detalles o

estructuras.” [PILL,06].

En la programación orientada a objetos se manejan diferentes niveles de abstracción. Los

objetos y mensajes se pueden ver como ejemplos de la aplicación de la abstracción.

Marco Teórico

21

3.2.1.2 Encapsulamiento:

Se le llama encapsulamiento a empaquetar las variables de los objetos dentro de la custodia

protectora de sus métodos. El encapsulamiento se usa para esconder detalles internos de la

implementación, los cuales no son importantes para otros objetos.

Con el encapsulamiento se permite la modularidad, es decir, que el código fuente de un

objeto puede escribirse y mantenerse sin afectar al código fuente de otros objetos. Y el

ocultamiento de información; un objeto tiene una interfaz que los otros objetos pueden usar para

comunicarse con él.

3.2.1.3 Herencia

El término de herencia se refiere al hecho que una clase puede heredar parte o toda la estructura

o comportamiento de otras clases. A la clase que hereda se le llama subclase o clase derivada. Si la

clase B es una subclase de la clase A, entonces decimos que A es la superclase de B o clase base.

Una subclase puede agregar variables o métodos de la clase que hereda. Puede remplazar o

modificar el comportamiento heredado pero sin modificar las interfaces de los métodos

heredados.

3.2.1.4 Polimorfismo

El polimorfismo permite “programar de forma general”, en vez de “programar en forma

específica”. Permite escribir programas que procesen objetos que compartan una misma

estructura base dentro de una jerarquía de clases, como si todos los objetos fueran del mismo

tipo; esto puede simplificar la programación.

El polimorfismo se implementa mediante la invalidación y reemplazo de los métodos

dentro de las subclases, y la asociación de tipo durante el tiempo de ejecución. Permite a los

programadores tratar con las generalidades mientras se deja que el entorno se encargue de los

detalles específicos durante el tiempo de ejecución.

Con el polimorfismo se promueve la extensibilidad: el software que invoque el

comportamiento polimórfico será independiente de los tipos de objetos a los cuales se envían los

mensajes. En un sistema se pueden incorporar nuevos tipos de objetos que puedan responder a

llamadas de métodos de objetos previos, sin necesidad de modificar el sistema base. Para agregar

nuevos objetos, sólo se tendría que modificar el código cliente para adaptar las llamadas hacia

estosa nuevos objetos [DEIT,08].

3.3 Marcos de aplicaciones orientadas a objetos

Un Marco de Aplicación Orientado a Objetos (Object-Oriented Application Framework) es un

grupo de clases “semicompleto” que se ha transformado en una aplicación reusable, que puede

ser utilizada para dar soluciones a una familia de problemas relacionados. A diferencia del reuso

de aplicaciones Orientadas a Objetos que se basa en las librerías de clases, los Marcos de

Capítulo 3

22

aplicación Orientados a Objetos (MOO) tienen como objetivo sectores de negocios particulares y

aplicaciones de dominio específicos. Algunos de los marcos de aplicaciones más importantes para

el desarrollo de software son: MacApp, ET++, Interviews, ACE, Microsoft's MFC and DCOM,

JavaSoft's RMI, e implementaciones de OMG's CORBA [FAYA,97].

Los principales beneficios que proporcionan los MOO son la modularidad, el reuso,

extensibilidad y la inversión de control que se proporciona a los desarrolladores.

Además de por su ámbito de aplicación, los marcos también se pueden clasificar por las

técnicas utilizadas para extenderlo; existen los marcos de caja blanca y los marcos de caja negra.

En los marcos de caja blanca la funcionalidad es reusada y extendida utilizando la herencia

y sobreescritura de los métodos contenidos en las clases del marco; además, se pueden utilizar

métodos gancho usando patrones de diseño como el Template Method.

Por otro lado, en los marcos de caja negra, la extensión se realiza por la definición de

interfaces de los componentes que se pueden conectar en el marco a través de la composición de

objetos. La funcionalidad es reusada por la definición de componentes que se ajustan a una

interfaz en particular y por la integración de dichos componentes en el marco utilizando patrones

de diseño como el Strategy y Functor.

Los MOO han demostrado ser una poderosa herramienta para el reuso, así como para

capturar la esencia de los patrones, arquitecturas, componentes, políticas, servicios y mecanismos

de programación exitosos [FAYA,97].

3.4 Patrón Modelo Vista Controlador (MVC)

La arquitectura del patrón MVC (Modelo-Vista-Controlador) originalmente fue aplicada en el

modelo de interacción gráfica de usuarios, para entradas, procesamientos y salidas. Esta

arquitectura descompone una aplicación en tres capas, donde cada capa es una estructura lógica

de los diferentes elementos que componen el software. Las capas en que se divide el patrón MVC

son el Modelo, la Vista y el Controlador [GULZ,02]. A continuación se describen brevemente:

Modelo

El modelo representa los datos de una aplicación y contiene la lógica para acceder a ellos y

manipularlos. Los servicios que maneja el modelo deben ser lo suficientemente genéricos como

para soportar varios tipos de clientes y debe ser fácil entender cómo controlar la conducta del

modelo con tan solo revisar brevemente la lista de sus métodos.

El modelo notifica a las vistas cuando cambia su estado y proporciona facilidades para que

las vistas consulten el modelo acerca de su estado. También proporciona facilidades para que el

controlador acceda a la funcionalidad de la aplicación encapsulada por el modelo.

Vista

Marco Teórico

23

La vista se encarga de acceder a los datos del modelo, especifica cómo se deben presentar

esos datos y actualiza la presentación de los mismos cuando ocurren cambios en el modelo. La

semántica de presentación está dentro de la vista, por lo tanto, la información contenida en el

modelo se puede adaptar a diferentes tipos de vistas. La vista se modifica cuando el modelo se

comunica con ella y a su vez, la vista envía información introducida por el usuario al controlador.

Controlador

El controlador define el comportamiento de la aplicación. Despacha las peticiones del

usuario y selecciona las vistas de presentación siguiente basándose en la información introducida

por el usuario y en el resultado de las operaciones realizadas por el modelo. Es decir, interpreta las

entradas del usuario y las mapea en acciones a ser efectuadas por el modelo.

Figura 1. Arquitectura del patrón MVC

3.4.1 Variaciones del patrón MVC

Algunos autores consideran al patrón MVC no como a un solo patrón, sino como a una

familia de patrones [SIML,09], esto es debido a que a partir del patrón MVC han surgido diferentes

variaciones del mismo, algunas de las cuales se describen brevemente a continuación:

Patrón Modelo Vista Presentador (MVP)

Es un patrón derivado del patrón MVC, que mayoritariamente es utilizado para construir

interfaces de usuario. En este patrón el Presentador asume el equivalente al Control en MVC. Y la

Vista es el responsable de manejar los eventos de Interfaces de Usuario Gráficas (clics con el ratón

o teclas presionadas) [BOOD,06].

Modelo: es una interfaz que define los datos a ser desplegados o no en la interfaz de

usuario.

Vista: es una interfaz que despliega los datos (el Modelo) y dirige los comandos del

usuario (eventos) al Presentador para que actúe sobre los datos.

Capítulo 3

24

Presentador: actúa sobre el Modelo y la Vista. Recupera datos del Modelo y les da

formato para mostrarlos en la Vista.

Patrón Presentación-Abstracción-Control (PAC)

El patrón PAC es usado como una estructura jerárquica de agentes, cada una constituida

de una triada de Presentación, Abstracción y Control. Los agentes (o triadas) se comunican entre sí

sólo a través de la parte del Control de cada triada. Y en cada triada se aísla por completo la

presentación y la abstracción [SIML,09].

Presentación: juega el mismo papel que la Vista en el patrón MVC. Muestra la información

desde la abstracción.

Abstracción: contiene los datos, y a diferencia del MVC original, estos datos pueden ser

sólo una parte de la estructura

Control: actúa sobre el Modelo y la Vista. Recupera datos del Modelo y les da formato

para mostrarlos en la Vista.

Patrón Modelo Vista Vista-Modelo (MVVM)

El patrón MVVM se basa en gran parte en el patrón MVC y está dirigido a las plataformas

modernas de desarrollo de interfaz de usuario (Windows Presentation Foundation o WPF y

Silverlight) en las que está involucrada la interfaz de usuario [SMIT,09].

Modelo: se refiere la capa que contiene los datos que representan el contenido de la

aplicación, al igual que en el patrón MVC.

Vista: son los elementos que se muestran en la interfaz de usuario (botones, ventanas,

gráficos, etc.)

VistaModelo: es un Modelo de la Vista, esto significa que es una abstracción de la Vista

que también sirve de enlace de los datos entre la Vista y el Modelo, podría ser visto como

el equivalente al Controlador del patrón MVC

Patrón Modelo Delegado (MD)

Es una variación del patrón MVC. Dos de las tres responsabilidades del MVC, en este caso

se unen la capa de la Vista y la capa del Control en una sola que representa a la interfaz de usuario

llamada Delegado [CUNN,05].

Modelo: contienen los datos específicos de la aplicación.

Vista/Controlador: presentan la información e interactúan con el usuario.

Patrón Modelo Vista Adaptador (MVA)

El patrón MVA también es conocido como Mediador-Controlador MVC. Y al igual que el patrón

MVC, el patrón MVA separa la lógica de negocios (el Modelo) de la capa de presentación (la Vista).

Pero, en el patrón MVA la separación entre la Vista y el Modelo es absoluta, evitando la mezcla de

elementos de la lógica del negocio con la presentación, lo cual es común con el patrón MVC

[BUNG,11].

Las capas del patrón MVA son los siguientes:

Marco Teórico

25

Modelo: al igual que en el patrón MVC esta capa contiene la lógica de negocios de la

aplicación.

Vista: al igual que en el patrón MVC esta capa contiene las interfaces de usuarios y es con

la que el usuario interactúa.

Adaptador: maneja todas las interacciones, actualización y flujo de control de la aplicación

y permite la separación estricta entre el Modelo y la Vista. Es responsable de la

sincronización y los aspectos dinámicos de la interfaz de usuario

Como se puede observar en la Figura 1, mostrada anteriormente, tradicionalmente el MVC

maneja las tres capas (Vista, Modelo y Control) interconectadas, de tal manera que hay cierto flujo

de información entre la Vista y el Modelo sin pasar por la capa del Control. El patrón MVA resuelve

este problema evitando que el Modelo y la Vista tengan comunicación directa, como se observa

en la Figura 2 a continuación.

Figura 2. Arquitectura del patrón MVA

El Adaptador mantiene un apuntador al Modelo y a la Vista de tal manera que

directamente llama a los métodos de ambos y es el responsable de mantenerlos en sincronía, cada

uno de ellos no sabe nada sobre el otro [SIML,09].

La Vista se encuentra completamente desacoplada del Modelo, de tal manera que el

Modelo sólo puede interactuar con la Vista a través del Adaptador. Con este arreglo, sólo el

Adaptador tiene conocimiento del Modelo y la Vista, porque es responsabilidad solamente de él

realizar esta comunicación.

Esta completa separación permite a una gran variedad de diferentes Vistas acceder

indirectamente al mismo Modelo con exactamente el mismo Adaptador o la misma clase de

adaptadores. El adaptador o clases de adaptadores mantienen al Modelo completamente

desinformado de que está siendo utilizado por múltiples interfaces de usuario aunque tal vez lo

esté haciendo concurrentemente. Para el Modelo, estos múltiples tipos de interfaces de usuario

lucen como instancias múltiples de un usuario genérico.

De la misma manera, ninguna interfaz de usuario sabe sobre la variedad de diferentes

Modelos que puede manejar el Adaptador. Porque la Vista sólo interactúa con un Adaptador y

Capítulo 3

26

nunca directamente con el Modelo. Además, varios Adaptadores pueden ser creados para cambiar

la manera en que una Vista presenta datos para un Modelo dado.

Algunas de las ventajas del patrón MVA sobre el patrón MVC son; todas las partes

“movibles” se concentran en el Adaptador; la separación de interfaces entre la Vista y el

Adaptador. La Vista es responsable de la distribución y la presentación visual, mientras que el

Adaptador es responsable de la sincronización y los aspectos dinámicos de la interfaz de usuario;

con esto se logra un mejor desacoplamiento entre Modelos y Vistas ya que la Vista no necesita

saber nada sobre el Modelo y viceversa.

La siguiente tabla presenta una descripción del patrón MVC y sus diferentes variaciones.

Tabla 2. Descripción del patrón MVC y sus variaciones.

Patrón Descripción

Modelo Vista Controlador (MVC)

La arquitectura de este patrón originalmente fue aplicada en el modelo de interacción gráfica de usuarios, para entradas, procesamientos y salidas. Esta arquitectura descompone una aplicación en tres capas, donde cada capa es una estructura lógica de los diferentes elementos que componen el software. Las capas en que se divide el patrón MVC son el Modelo, la Vista y el Controlador [GULZ,02].

Modelo Vista Presentador (MVP)

Es un patrón derivado del patrón MVC, que mayoritariamente es utilizado para construir interfaces de usuario. En este patrón el Presentador asume el equivalente al Control en MVC. Y la Vista es el responsable de manejar los eventos de Interfaces de Usuario Gráficas (clics con el ratón o teclas presionadas) [BOOD,06].

Presentación-Abstracción-Control (PAC)

Es usado como una estructura jerárquica de agentes, cada una constituida de una triada de Presentación, Abstracción y Control. Los agentes (o triadas) se comunican entre sí sólo a través de la parte del Control de cada triada. Y en cada triada se aísla por completo la presentación y la abstracción [SIML,09].

Modelo Vista Vista-Modelo (MVVM)

Se basa en gran parte en el patrón MVC y está dirigido a las plataformas modernas de desarrollo de interfaz de usuario (Windows Presentation Foundation o WPF y Silverlight) en las que está involucrada la interfaz de usuario [SMIT,09].

Modelo Delegado (MD)

Es una variación del patrón MVC. Dos de las tres responsabilidades del MVC, en este caso se unen la capa de la Vista y la capa del Control en una sola que representa a la interfaz de usuario llamada Delegado [CUNN,05].

Modelo Vista Adaptador (MVA)

También es conocido como Mediador-Controlador MVC. Y al igual que el patrón MVC, el patrón MVA separa la lógica de negocios (el Modelo) de la capa de presentación (la Vista). Pero, en el patrón MVA la separación entre la Vista y el Modelo es absoluta, evitando la mezcla de elementos de la lógica del negocio con la presentación, lo cual es común con el patrón MVC [BUNG,11].

3.5 Lenguaje de programación Java

El lenguaje de programación Java es un lenguaje de propósito general, concurrente, basado en

clases y orientado a objetos [GOSL,05]. Está muy relacionado a los lenguajes C y C++ pero se

organiza de manera un poco diferente.

Marco Teórico

27

Java omite algunos aspectos de C y C++ como el soporte a la expresión goto; la utilización

de estructuras y uniones; y elimina herramientas de bajo nivel como la manipulación directa de

punteros o memoria. E incluye algunas ideas de otros lenguajes como la administración

automática de memoria de Eiffel y la utilización de una máquina virtual de Smalltalk.

Este lenguaje es de tipo estático fijo, es decir, sus variables no cambian de tipo una vez

declaradas, y es considerado relativamente de alto nivel, incluye manejo de almacenamiento

automático para el que se usa un colector de basura.

3.5.1 Paquetes

En java, los programas se organizan en conjuntos de paquetes. La estructura de los nombres para

los paquetes es jerárquica. Los miembros de un paquete son tipos clase, tipos interfaz y

subpaquetes, estos subpaquetes contienen unidades de compilación y subpaquetes a la vez.

Un paquete consta de unidades de compilación. Una unidad de compilación

automáticamente tiene acceso a todos los tipos declarados dentro del paquete y

automáticamente importa los tipos public declarados en el paquete predefinido java.lang.

Para programas pequeños y desarrollos casuales, un paquete puede no tener nombre o

tiene un nombre simple, pero si el código va a ser distribuido, deben de escogerse nombres únicos

para prevenir conflictos, en [GOSL,05] se menciona cómo realizar esta construcción de nombres.

3.5.2 Clases

En Java, una declaración de clase define un nuevo tipo de referencia y describe como es

implementado.

Una clase anidada es una clase cuya declaración ocurre dentro del cuerpo de otra clase o

dentro de una interfaz. Una clase de nivel superior es una clase que no es anidada.

Una clase puede ser declarada abstract, y debe serlo, cuando no está implementada

completamente, tal clase no puede ser instanciada pero puede ser extendida por subclases. Las

clases que son declaradas final no pueden tener subclases. Si es declarada public, entonces

puede ser accedida desde otros paquetes.

El cuerpo de una clase declara miembros (campos, métodos, clases e interfaces anidadas),

instancias e inicializadores estáticos, y constructores. El ámbito de un miembro es el cuerpo

entero de la declaración de la clase a la cual el miembro pertenece, las declaraciones de campos,

métodos de clase, clases miembro, interfaces miembro y constructores pueden incluir

modificadores de acceso public, protected o private.

3.5.3 Interfaces

Una interfaz especifica un nuevo tipo de referencia cuyos miembros son clases, constantes y

métodos abstractos. Estos tipos no tienen implementación, pero otras clases pueden

implementarlos proveyendo implementación para sus métodos abstractos.

Capítulo 3

28

Una interfaz anidada es una interfaz cuya declaración aparece dentro del cuerpo de otra

clase o interfaz. Una interfaz de nivel superior, es una interfaz que no es anidada.

Hay dos tipos de interfaces, interfaces normales y tipos anotación.

Las interfaces son usadas con el propósito de evitar que clases relacionadas, compartan

una superclase abstracta común.

Una interfaz puede ser declarada para ser una extensión directa de uno o más interfaces,

esto significa que implícitamente especifica todos los tipos miembros, métodos abstractos y

constantes de las interfaces que extiende, excepto por cualquier tipo miembro y constantes que

se oculten.

Una clase puede declarar que directamente implementa una o más interfaces, esto

significa que cualquier instancia de la clase implementa todos los métodos abstractos

especificados por la interfaz o interfaces. Esta múltiple herencia de interfaces permite a los

objetos soportar múltiples comportamientos comunes sin compartir ninguna implementación.

Una variable cuyo tipo es una interfaz puede tener como sus valores, una referencia a

cualquier instancia de una clase la cual implementa la interfaz especificada.

3.5.4 Constructores

Un constructor es usado en la declaración de un objeto, el cual es una instancia de una clase. Su

nombre debe ser el mismo que el de la clase que lo contiene. En todos lo demás, la declaración del

constructor luce sólo como una declaración de método que no tiene tipo de retorno.

Los constructores son invocados por expresiones de creación de instancia de clase y nunca

son invocados por expresiones de invocación de métodos. El acceso a constructores es

determinado por modificadores de acceso; nunca son heredados y por lo tanto no son sujetos al

ocultamiento o sobreescritura.

3.5.5 Métodos

Un método declara código ejecutable que puede ser invocado, pasando un número de

argumentos.

El cuerpo del método es un bloque de código que contiene un conjunto de instrucciones y

que implementa el comportamiento del método. Sí se tuviese simplemente un punto y coma, esto

indicaría que falta la implementación, es decir, que se trata de un método abstracto.

Si una implementación va a ser provista para una declaración de método void, pero la

implementación no requiere código ejecutable, el cuerpo del método debería ser escrito como un

bloque con no contiene sentencias “{}”.

Si un método es declarado void, entonces su cuerpo no debe contener la sentencia

return que retorna un valor. Si un método es declarado para tener un tipo de retorno, entonces

cada sentencia return en su cuerpo tiene un valor de retorno. Nótese que para un método es

posible tener declarado un tipo de retorno y no contener sentencia return.

Marco Teórico

29

3.5.6 Variables

Una variable es una ubicación de almacenamiento y tiene un tipo asociado, ya sea un tipo

primitivo o un tipo de referencia. El valor de una variable es cambiado con una asignación o por un

operador prefijo o postfijo ++ (incremento) o -- (decremento).

El lenguaje de programación Java, garantiza la compatibilidad del valor de una variable con

su tipo, siempre y cuando, no se presenten advertencias en tiempo de compilación del programa.

3.5.6.1 Variables de tipo primitivo

Una variable de tipo primitivo siempre mantiene un valor de ese mismo tipo exactamente. Los

tipos primitivos son: boolean, byte, short, int, long, char, float o double.

3.5.6.2 Variables de tipo de referencia

Una variable de tipo de referencia es una variable de tipo complejo que hace referencia a objetos

basados en alguna clase. Una variable de tipo clase T puede almacenar una referencia a null o

una referencia a una instancia de la clase T o a cualquier clase que sea una subclase de T. Una

variable de tipo interfaz puede almacenar una referencia a null o una referencia a cualquier

instancia de cualquier clase que implementa la interfaz.

3.5.6.3 Tipos de variables.

En Java existen siete tipos de variables:

1. Una variable de clase es un campo declarado usando la palabra reservada static dentro

de la declaración de clase, podríaestar o no contener la palabra reservada static dentro

de una declaración de interfaz.

2. Una variable de instancia es un campo declarado dentro de una clase sin usar la palabra

reservada static.

3. Componentes array son variables sin nombre, que son creados e inicializados a valores

por defaul en donde se cree un nuevo objeto que es de tipo array.

4. Parámetros de método, llamados valores de argumento, los cuales son enviados a un

método. Para cada parámetro declarado en una declaración de método, una nueva

variable de parámetro es creada cada vez que el método es invocado.

5. Parámetros de constructor llamados valores de argumento enviados a un constructor. Por

cada parámetro declarado en una declaración de constructor, una nueva variable de

parámetro es creada cada vez que se invoca ese constructor.

6. Un parámetro de manejador de excepciones es creado cada vez que una excepción es

capturada por una cláusula catch o una sentencia try. La nueva variable es inicializada

con el objeto actual asociado con la excepción.

7. Variables locales, son declaradas por un estatuto de declaración de variables locales.

Puede estar declaradas en cualquier lugar del flujo de control, dentro de un bloque o en

un estatuto for. Una declaración de variable local puede contener una expresión en la

Capítulo 3

30

cual se inicialice la variable, sin embargo, no se inicializa hasta que el estatuto de

declaración de variable local es ejecutado.

3.5.7 Modificadores de acceso

En Java, existen 4 modificadores de acceso:

Public: un miembro con este modificador puede ser accedido por los elementos de la clase

en que se declara; por los elementos de una subclase; los elementos de otra clase dentro

del mismo paquete y elementos de una clase en diferente paquete.

Protected: un miembro con este modificador puede ser accedido por los elementos de la

clase en que se declara; y por los elementos de una subclase.

Private: Los miembros private sólo pueden ser accedidos por los elementos de la clase en

que se declara.

Default: también conocido como package friendly. Cuando no se especifica alguno de los

modificadores de acceso anteriormente mencionados, se establece este modificador de

acceso por default, con el cual el miembro puede ser accedido por los elementos de la

clase en que se declara; por los elementos de una subclase; y los elementos de otra clase

dentro del mismo paquete.

3.6 Compilador

Un compilador es un programa que lee un programa escrito en un lenguaje, conocido como

lenguaje fuente, y lo traduce a un programa equivalente, en otro lenguaje, conocido como

lenguaje objeto. Los lenguajes objeto son variados; pueden ser otro lenguaje de programación o

lenguaje máquina [AHO,98].

Los compiladores pueden clasificarse como de una pasada, múltiples pasadas, de carga y

ejecución, de depuración o de optimización, dependiendo de cómo se construyan o de la función

que realicen. Sea como sea, las tareas básicas que debe realizar un compilador son esencialmente

las mismas.

3.6.1 Fases de un compilador

Se considera que en la compilación hay dos tareas principales; el Análisis y la Síntesis. El Análisis

consta de las fases de Análisis Léxico, Análisis Sintáctico y Análisis Semántico. Y la Síntesis de las

fases de Generación de Código Intermedio, Optimización de Código y Generación de Código. Otras

actividades que se realizan simultáneamente a las seis fases anteriormente mencionadas son la

Administración de la Tabla de Símbolos y el Manejo de Errores. A continuación, se muestra estas

fases.

Marco Teórico

31

Figura 3. Fases de un Compilador

3.6.1.1 Fases del Análisis

Durante el Análisis se divide al programa fuente en elementos y se crea una representación

intermedia del mismo. En esta fase se determinan las operaciones que implica el programa fuente

y se registra en una estructura jerárquica llamada árbol. Frecuentemente se utiliza un árbol

sintáctico, en el cual, cada nodo representa una operación y los hijos del nodo son los argumentos

de la operación.

Análisis Léxico

También conocido como exploración. En esta fase, la cadena de caracteres que constituye

el programa fuente se lee de izquierda a derecha y se agrupa en componentes léxicos, que son

secuencias de caracteres con un significado colectivo.

Análisis Sintáctico

Se agrupan los componentes léxicos del programa fuente en frases gramaticales que el

compilador utiliza para sintetizar la salida. Generalmente, las frases gramaticales se representan

mediante un árbol de análisis sintáctico.

Capítulo 3

32

Análisis Semántico

En esta fase se revisa el programa fuente para encontrar errores semánticos y se reúne la

información sobre los tipos para la fase posterior de generación de código. Se utiliza la estructura

jerárquica resultante de la fase de análisis sintáctico para identificar los operadores y operandos

de expresiones y proposiciones. En esta fase se realiza la verificación de tipos, lo cual es una parte

importante en la que el compilador verifica si los operadores tienen operandos permitidos por la

especificación del lenguaje fuente.

3.6.1.2 Fases de Síntesis

Durante estas fases se construye el programa objeto deseado a partir de la representación

intermedia. Esta parte es la que requiere más técnicas especializadas.

Generación de Código Intermedio

Después del análisis sintáctico y semántico, algunos compiladores generan una

representación intermedia explícita del programa fuente. Esta representación intermedia puede

ser considerada como un programa para un a máquina abstracta y debe tener dos propiedades

importantes; debe ser fácil de producir y fácil de traducir al programa objeto.

La representación intermedia puede tener diversas formas. Una de ellas es el código de

tres direcciones, que podría considerarse como el lenguaje ensamblador para una máquina en la

que cada posición de memoria puede actuar como un registro.

Optimización de Código

En esta fase se trata de mejorar el código intermedio, para obtener un código máquina

más rápido de ejecutar. Varía mucho la cantidad de optimización de código que ejecutan los

diferentes compiladores. En los llamados “compiladores optimizadores” una gran parte del tiempo

se ocupa en esta fase. Pero también, hay optimizaciones sencillas que mejoran sensiblemente el

tiempo de ejecución del programa objeto y sin tomar mucho tiempo de compilación.

Generación de Código

La fase final de un compilador es la generación de código objeto, que por lo general

consiste en código de máquina relocalizable o código ensamblador. En esta fase se seleccionan las

posiciones de memoria para cada variable usada por el programa. Después, cada instrucción

intermedia se traduce a una secuencia de instrucciones de máquina que ejecutan la misma tarea.

En esta fase, un aspecto decisivo es la asignación de variables a registros.

3.6.1.3 Otras Actividades

Otras dos actividades; la Administración de la Tabla de Símbolos y el Manejo de Errores, son

actividades que interactúan con las seis fases del compilador.

Administración de la tabla de símbolos

Marco Teórico

33

Una función esencial de un compilador es registrar los identificadores utilizados en el

programa fuente y reunir información de los distintos atributos de cada identificador, para lo cual

es utilizada una tabla de símbolos.

La tabla de símbolos es una estructura de datos que contiene un registro por cada

identificador, y puede almacenar sus diferentes características. La estructura de datos permite

encontrar rápidamente cada identificador y almacenar o consultar sus datos.

Los atributos almacenados pueden proporcionar información sobre la memoria asignada a

un identificador, su tipo, su ámbito (la parte del programa donde tiene validez) y, en caso de las

funciones, el número y tipos de sus argumentos, el tipo que devuelve, etc.

Detección de errores

Durante todas las fases del compilador se pueden encontrar errores. Sin embargo, al

detectar un error, cada fase debe tratar de alguna forma ese error, para poder continuar con la

compilación, permitiendo la detección de más errores en el programa fuente.

Las fases en las que se presenta la mayor cantidad de errores son las fases del análisis

sintáctico y semántico. En la fase de análisis léxico se puede detectar errores cuando los caracteres

de entrada no forman ningún componente léxico del lenguaje. Un compilador que se detiene

cuando encuentra el primer error, no resulta tan útil como debería.

3.6.2 Programas similares a un Compilador

Otros programas similares a un compilador son los Intérpretes y los Traductores los cuales se

definen a continuación:

Intérprete

Es un programa que en lugar de producir un programa objeto, realiza las operaciones que

se indican en el programa fuente. Algunos lenguajes de programación, Java entre ellos, utilizan un

intérprete para traducir al instante el código que se va leyendo a lenguaje máquina para que

pueda ser ejecutado.

La principal ventaja de un Intérprete sobre un Compilador es que dado cualquier

programa, si éste fue interpretado, entonces se podrá interpretar en cualquier sistema operativo.

Pero por otro lado, el archivo generado por el compilador solo funciona en el sistema operativo

para el que fue creado [DIRE,11].

Traductor

Programa que recibe una entrada en un lenguaje y produce una salida en otro lenguaje.

Como se puede notar, la definición de un Traductor incluye a los Compiladores y los Intérpretes,

pues los dos programas reciben una entrada en un lenguaje y obtienen una salida en otro

lenguaje.

Capítulo 3

34

3.7 Servicio Web

Los servicios Web son un conjunto de aplicaciones o de tecnologías con capacidad para

interoperar en la Web, dichas aplicaciones intercambian datos entre sí, de esta manera ofrecen

nuevos servicios.

A través de la Web los proveedores ofrecen sus servicios como procedimientos remotos y

los clientes los solicitan llamando a estos procedimientos.

Estos servicios proporcionan mecanismos de comunicación estandar entre diferentes

aplicaciones, que interactúan entre sí para presentar información dinámica [W3C,10].

3.8 Otros conceptos.

Otros conceptos utilizados en el contexto de esta tesis, son los términos que se definen a

continuación [NUÑE,08].

3.8.1 Función especializada

Son las funciones en las que la totalidad del código que la conforman, pertenece a una sola parte

del patrón MVC, es decir pertenecen exclusivamente a la parte del Modelo, de la Vista o del

Control. Es importante señalar que en el contexto de la presente tesis, el papel que desempeña la

parte del Control en la arquitectura MVC es tomado por el Adaptador.

En la Figura 4 se muestra un ejemplo de función especializada de la Vista.

Figura 4. Ejemplo de función especializada.

3.8.2 Función no-especializada.

Se denominan funciones no-especializadas a las funciones que tienen estatutos de código

que pertenecen a más de dos partes diferentes del patrón MVC. La Figura 5 muestra un ejemplo

de una función no especializada pues contiene tanto estatutos de la Vista como del Modelo.

Marco Teórico

35

Figura 5. Ejemplo de función no-especializada

3.8.3 Clase especializada

Una clase especializadas es una clase compuestas por una o más funciones especializadas

de la misma parte del patrón MVC. Como se mencionó anteriormente, en el contexto de la

presente tesis, el papel que desempeña la parte del Control en la arquitectura MVC es tomado por

el Adaptador. En la Figura 6 se presenta un ejemplo de una clase especializada.

Figura 6. Ejemplo de clase especializada

3.8.4 Clase no-especializada

Una clase no-especializada es una clase que incluye funciones no-especializadas o una

mezcla de funciones especializadas de diferente parte del patrón MVC y no-especializadas. La

Figura 7 muestra un ejemplo de una clase no-especializada pues contiene funciones especializadas

tanto de la Vista como del Modelo.

Capítulo 3

36

Figura 7. Ejemplo de clase no-especializada

Modelo Conceptual del Sistema

37

Capítulo 4. Modelo Conceptual del Sistema

El proceso de refactorización de marcos de aplicaciones orientado a objetos hacia una

arquitectura MVC se basa en el análisis del código del MOO para obtener información sobre su

arquitectura inicial; y en seguida se utiliza dicha información para realizar la separación de los

elementos pertenecientes a las diferentes partes del patrón.

En este capítulo se describe la manera en que fue diseñado el proceso de refactorización.

Y además se describen a detalle el proceso, las actividades y los métodos utilizados para realizar la

refactorización de MOO hacia una arquitectura MVC.

4.1 Diseño del Proceso de Refactorización

Para cumplir con el objetivo del presente trabajo de tesis se realizaron distintas pruebas de

escritorio a los métodos presentados en [NUÑE,08].

A continuación se muestra una lista de los métodos probados junto con una pequeña

descripción de cada uno de ellos.

Capítulo 4

38

Método heurístico H0, “Definir plantilla genérica MVC”: genera una arquitectura de

clases conforme al patrón MVC.

Método heurístico H1, “Análisis del código legado”: identifica los estatutos, las funciones

y clases del código legado de acuerdo a la parte del patrón MVC a la que pertenecen.

Método heurístico H2, “Crear clases”: define la declaración de clases simples, clases

abstractas e interfaces en un archivo.

Método heurístico H3, “Crear constructor”: crea constructores simples y constructores

con parámetros.

Método heurístico H4, “Crear función”: crea una función sin parámetros o con

parámetros.

Método heurístico H5, “Reubicar atributos”: reubica los atributos y su inicialización desde

las clases legadas a las clases concretas correspondientes de la plantilla MVC.

Método heurístico H10, “Fragmentar funciones”: fragmenta las funciones no-

especializadas y utiliza el método de crear funciones para generar funciones

especializadas.

Método heurístico H11, “Redefinir llamadas funciones”: sustituye la actual llamada a una

función, que después de ser fragmentada queda ubicada en alguna de las clases de la

plantilla MVC.

Durante la ejecución de las pruebas de escritorio se determinó que era necesario realizar

modificaciones, tanto para hacer algunas correcciones como para adaptarlos al patrón MVA, el

cual, como se mencionó en el Capítulo 3, es un patrón derivado del patrón MVC que se apega más

al objetivo y la intención de desacoplar completamente la parte de presentación de los MOO (la

Vista), de la parte de la lógica de negocios (el Modelo).

Debido a que en el trabajo [NUÑE,08] no se establece un proceso de reestructura que

integre los métodos que fueron desarrollados, además del refinamiento de los métodos, también

fue necesario definir el proceso de refactorización.

Las modificaciones a los métodos y la definición del proceso de refactorización se realizó

en colaboración con la estudiante de doctorado del CENIDET M.C. Sheydi Anel Zamudio López,

quien está desarrollando un proyecto titulado “Migración de marcos de aplicaciones orientados a

objetos hacia servicios web”, en el cual realiza la especificación formal de los métodos; y con quien

se trabajó estrechamente.

La terminología utilizada para la identificación de las actividades y los métodos es la

siguiente:

An: N-esima actividad del proceso de refactorización.

Rn: N-esimo método de reestructura.

En donde n representa un número consecutivo o identificador.

Una actividad (A) se conforma de métodos (R). La actividad A1 está conformada por el

método R1 y la actividad A2 por los métodos del R2 al R11.


39

El resultado del refinamiento de los métodos propuestos en [NUÑE,08], y nuevos métodos

creados ante la necesidad de diseñar el proceso de refactorización, son los 11 métodos descritos a

continuación:

Método de reestructura R1: “Analizar código legado”: método equivalente al método H1

“Análisis del código legado”. En este método se conservó la intención de identificar los

estatutos, las funciones y clases del código legado de acuerdo a la parte del patrón MVC a

la que pertenecen. Las modificaciones realizadas fueron en el sentido de no sólo etiquetar

el código sino también almacenar información del código del MOO en tablas.

Método de reestructura R2: “Crear clases”: se conservó la intención del método H2

“Crear clases”, de definir la declaración de clases simples, clases abstractas e interfaces en

un archivo. Las modificaciones realizadas tuvieron que ver con las diferentes opciones de

clases que se pueden crear.

Método de reestructura R3: “Crear constructor”: se conserva la intención del método H3

“Crear constructor”, de crear constructores simples y constructores con parámetros, y se

agregó la opción de copiar constructores desde otra clase.

Método de reestructura R4: “Crear funciones”: se mantiene la intención de crear una

función con parámetros o sin parámetros y además se considera la inserción de estatutos

de código en el cuerpo de la función.

Método de reestructura R5: “Reubicar atributos”: al igual que el método H5 “Reubicar

atributos”, reubica los atributos, pero en lugar de copiarlos desde otra clase, ahora se

obtienen los atributos a reubicar desde una tabla especialmente diseñada con ese

objetivo.

Método de reestructura R6: “Reestructurar clases”: este método es el orquestador de

todo el proceso de refactorización.

Método de reestructura R7: “Estructura jerárquica de clases”: con este método se

obtiene la arquitectura original de los MOO con el objetivo de conservarla en la parte del

modelo durante el proceso de reestructura.

Método de reestructura R8: “Coordinador de la creación de clases”: se puede considerar

este método como el equivalente al método H0 “Definir plantilla genérica MVC”, las

modificaciones están relacionadas con la manera en que se crea la nueva arquitectura de

acuerdo al patrón MVA.

Método de reestructura R9: "Reubicar funciones especializadas": se reubican las

funciones especializadas, actividad realizada anteriormente por el método H10

“Fragmentar funciones”.

Método de reestructura R10: "Fragmentar funciones no especializadas": se fragmentan

las funciones no-especializadas, actividad realizada anteriormente por el método H10

“Fragmentar funciones”.

Método de reestructura R11: "Redefinir llamadas a funciones": al igual que con el

método H11 “Redefinir llamadas funciones”, en este método se sustituye la actual llamada

a una función que ha sido reubicada.

Capítulo 4

40

En las siguientes secciones se presenta una descripción más amplia del proceso de

refactorización y de las actividades y métodos utilizados durante el mismo.

4.2 MOO2MVA: Marco de Aplicaciones Orientadas a Objetos

hacia una arquitectura MVA

El proceso de refactorización de Marcos de Aplicaciones Orientados a Objetos hacia una

arquitectura MVA está constituido de 11 métodos (R1-R11) los cuales están divididos en dos

actividades principales:

A1. Analizar el código del MOO original y etiquetar los estatutos, funciones y clases de

acuerdo a las partes del patrón MVA a las que pertenecen.

A2. Reestructurar el código legado.

Dichas actividades son descritas por su intención, procedimiento, suposiciones,

poscondiciones e interacción de los métodos.

Durante la actividad A1 se obtiene una descripción inicial del MOO. Las salidas obtenidas

son: el código del MOO etiquetado; y un diccionario de datos compuesto de un conjunto de tablas,

las cuales contienen información sobre las clases, métodos y atributos de clase que conforman el

MOO.

En la actividad A2, se utiliza la información obtenida en la primera actividad para realizar la

refactorización; como salida se obtiene el código del MOO con una arquitectura MVA.

En la Figura 8 se muestra el proceso de refactorización.


41

Figura 8. Proceso de refactorización de MOO a arquitectura MVA

4.3 A1. Analizar el código del MOO original y etiquetar los

estatutos, funciones y clases de acuerdo a las partes del

patrón MVA a las que pertenecen.

A continuación se describe la actividad A1. “Analizar el código del MOO original y etiquetar los

estatutos, funciones y clases de acuerdo a las partes del patrón MVA a las que pertenecen”. Dicha

descripción se realiza mediante su intención, procedimiento, suposiciones, poscondiciones e

interacción de los métodos.

Intención:

Identificar a qué parte del patrón MVA corresponde cada uno de los estatutos de código,

las funciones y las clases del MOO.

Precondiciones:

Tener acceso al código del conjunto de clases del MOO original y haber realizado la

clasificación de los estatutos del lenguaje en que está escrito el MOO.

Procedimiento:

Paso A1.1: Analizar los estatutos, las funciones y las clases del MOO en estudio, con la

finalidad de:

Capítulo 4

42

a) Identificar cada estatuto de código del MOO.

b) Etiquetar los elementos de código de acuerdo a la parte del patrón a la que

pertenecen.

c) Generar información sobre las clases y las funciones del MOO en estudio, que

apoyarán las siguientes actividades del proceso de reestructura.

Suposiciones:

A partir de identificar y etiquetar los elementos de código, es posible llevar a cabo la

reestructura del MOO en estudio.

Poscondiciones:

Los elementos del código del MOO en estudio quedan etiquetados de acuerdo a la parte

del patrón MVA a la que pertenecen. Se obtiene información de tipos de clases, funciones

abstractas, funciones concretas y tipos de variables.

Interacción de los métodos de reestructura:

Los pasos de esta actividad se llevan a cabo aplicando el método de reestructura R1 y no

interacciona con otros métodos.

4.3.1 Método de reestructura R1: “Analizar código legado”

La intención del método R1 es analizar el código legado de tal manera que se etiquete cada

estatuto dependiendo de la parte del patrón MVA a la que pertenece, en seguida, etiquetar y

almacenar funciones, ya sean especializadas o no especializadas y finalmente las clases, también

especializadas y no especializadas.

Por otro lado, mientras se realiza la etiquetación, se va almacenando información sobre las

variables, funciones y clases en las tablas: “Tipos de clases”, “Funciones abstractas”, “Funciones

concretas”, “Tipos de Variables”. Dichas tablas se describen a continuación.

Tabla 3. Descripción de la tabla Tipos de clases

Tipos de clases

Campo Descripción

Nombre Nombre de la clase identificada durante el análisis de código.

Paquete Nombre del paquete al que pertenece la clase identificada.

Tipo Tipo de la clase, puede ser “concreta”, “abstract” o “interface”.

Tipo Relación 1 Primer tipo de relación que mantiene la clase, puede ser ninguna, “extends” (herencia) o “implements” (implementación).

Clase Base 1 Nombre de la clase con la cual se tiene la relación establecida en el campo Tipo Relación 1.

Tipo Relación 2 Segundo tipo de relación que mantiene la clase, puede ser ninguna, “extends” (herencia) o “implements” (implementación).


43

Clase Base 2 Nombre de la clase con la cual se tiene la relación establecida en el campo Tipo Relación 2.

Patrón MVC Parte del patrón MVA a la que pertenece la clase identificada, puede ser “Modelo”, “Vista”, “Control”, “Sin definir” o “No especializada”

Tabla 4. Descripción de la tabla Funciones Abstractas

Funciones abstractas

Campo Descripción

Firma Firma de la función abstracta que ha sido detectada durante el análisis de código.

Especificador Especificador de acceso de la función abstracta.

Tipo de retorno Tipo del valor de retorno de la función abstracta.

Clase Nombre de la clase a la que pertenece la función abstracta.

Patrón MVC Nombre de la parte del patrón a la que pertenece la función (Modelo, Vista o Control).

Tabla 5. Descripción de la tabla Funciones Concretas

Funciones concretas

Campo Descripción

Firma Firma de la función concreta que ha sido detectada durante el análisis de código.

Especificador Especificador de acceso de la función concreta.

Tipo de retorno Tipo del valor de retorno de la función concreta.

Variable de Retorno

Nombre de la variable que se utiliza para realizar el retorno.

Clase Nombre de la clase a la que pertenece la función concreta.

Patrón MVC Nombre de la parte del patrón a la que pertenece la función (Modelo, Vista o Control).

Tabla 6. Descripción de la tabla Tipos de Variables

Tipos de Variables

Campo Descripción

Identificador Identificador de la variable detectada durante el análisis de código.

Tipo Tipo de la variable.

Especificador Especificador de acceso de la variable.

Clase Variable Nombre de la clase en donde fue declarada la variable.

Firma Función Firma de la función de donde se accede a la variable.

Clase Función Nombre de la clase a la que pertenece la función que accede a la variable.

Las figuras que van de la Figura 9 a la Figura 15 muestran el Diagrama de Actividad que

representa el proceso que se sigue en el Método de Reestructura R1: “Analizar Código Legado”

Capítulo 4

44

Figura 9. Diagrama de Actividad del Método R1: “Analizar Código Legado”


45

Figura 10. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 2)

Capítulo 4

46



47


Capítulo 4

48



49


Capítulo 4

50


Los pasos del Método de reestructura R1: “Analizar código legado” se encuentran en el Anexo A.


51

4.4 A2. Reestructurar el código legado.

A continuación se describe la actividad A2. “Reestructurar el código legado”. Dicha descripción se

realiza mediante su intención, procedimiento, suposiciones, poscondiciones e interacción de los

métodos.

Intención:

Separar y reubicar los elementos de código del marco orientado a objetos original, de

acuerdo a la parte del patrón que les corresponde.

Precondiciones:

Los estatutos de código, las funciones y las clases del marco orientado a objetos original

deben estar etiquetados de acuerdo a la parte del patrón MVA a la que pertenecen. Las tablas

“Tipos de clases”, “Funciones abstractas” y “Funciones concretas” deben estar creadas.

Procedimiento:

Paso A2.1: Crear las tablas “Clases Modelo”, “Clases Vista”, “Clases Adaptador”, “Funciones

abstractas MVA”, y “Funciones concretas MVA”.

Paso A2.2: Obtener la jerarquía de clases del marco orientado a objetos original, con la

finalidad de conservarla en la parte del Modelo.

Paso A2.3: Siguiendo el orden de la jerarquía de clases del marco orientado a objetos original,

crear las clases del nuevo marco orientado a objetos con arquitectura MVA. Este paso implica:

a) Crear las clases del Modelo, la Vista y el Adaptador que se requieren (Paso A2.3.a).

Paso A2.4: Si la clase en estudio es especializada en alguna parte del patrón MVA, reubicar a

los miembros de la clase en la parte del patrón a la que pertenecen. Este paso implica:

a) Reubicar los constructores de la clase (Paso A2.4.a).

b) Reubicar las funciones de la clase (Paso A2.4.b).

c) Reubicar los atributos de la clase (Paso A2.4.c).

d) Redefinir las llamadas a las funciones ya reubicadas que se encuentren en el código

(Paso A2.4.d).

Paso A2.5: Si la clase en estudio es No-especializada, fragmentar la clase para reubicar a sus

elementos de código en la parte del patrón a la que pertenecen. Este paso implica:

a) Crear los constructores de las clases MVA (Paso A2.5.a).

b) Crear nuevas funciones para reubicar los estatutos de código que pertenezcan a la

Vista y/o al Adaptador (Paso A2.5.b).

c) Reubicar los atributos a los que acceden las funciones reubicadas (Paso A2.5.c).

d) Redefinir las llamadas a las nuevas funciones (Paso A2.5.d).

Suposiciones:

La parte del modelo mantiene la arquitectura del marco original y no tiene ningún

elemento de la Vista. La Vista contiene solamente los elementos de código que pertenezcan a esta

parte del patrón. El Adaptador gestiona las interacciones entre el Modelo y la Vista.

Capítulo 4

52

Poscondiciones:

Se obtiene un marco orientado a objetos con arquitectura MVA.

Interacción de los métodos de reestructura:

Después de analizar y etiquetar el código fuente del marco orientado a objetos original, se

inicia la reestructuración de la arquitectura del marco, aplicando el método R6. Este método

coordina el proceso de reestructuración llamando a los métodos R7, R8, R9 y R10. La Figura 2

muestra gráficamente este proceso, el cual termina cuando todas las clases del marco orientado a

objetos original han sido reubicadas en la arquitectura MVA.

Es importante señalar que aunque esta actividad consta de 10 métodos (R2-R11), debido a

limitaciones de tiempo, actualmente se encuentran en una etapa de refinamiento los métodos R6:

“Reestructurar clases”, R8: “Coordinador de la creación de clases”, R9: "Reubicar funciones

especializadas", R10: "Fragmentar funciones no especializadas" y R11: "Redefinir llamadas a

funciones". Debido a lo anterior, a continuación son presentados únicamente los métodos: R1:

“Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5:

“Reubicar atributos” y R7: “Estructura jerárquica de clases”

4.4.1 Método de reestructura R7: “Estructura jerárquica de

clases”

En el método “R7: Estructura jerárquica de clases” se realiza un recorrido sobre la tabla “Tipos de

Clase” la cual fue llenada durante la ejecución del método R1 y que contiene las diferentes clases

que conforman el MOO; tal recorrido tiene como objetivo obtener la jerarquía de clases del MOO

original, esto con la finalidad de conservarla en la parte del Modelo.

Durante la ejecución de este método se utiliza la tabla “Jerarquía de Clases” que es

descrita en la Tabla 7. Y el proceso seguido para la ejecución de este método se describe en el

diagrama de actividad que se muestra en la Figura 16.

Tabla 7. Descripción de la tabla Jerarquía de Clases

Jerarquía de Clases

Campo Descripción

Clase Padre Nombre de la clase que se está analizando, todas las clases del MOO aparecen al menos una vez en este campo.

Clase Hija Nombre de la clase que extiende o implemente a la clase padre, puede ser ninguna.


53

Figura 16. Diagrama de Actividad del Método R7: “Estructura jerárquica de clases”

Los pasos seguidos durante este método se encuentran definidos en el Anexo A.

Capítulo 4

54

4.4.2 Método de reestructura R2: “Crear clases”

Este método es utilizado por el método R8 para crear las clases del Modelo, Vista y Adaptador que

se necesiten durante el proceso de reestructura. Los pasos del método R2 se pueden encontrar en

el Anexo A.

El proceso seguido durante la ejecución de este método se muestra en el diagrama de

actividad de la Figura 17.


55

Figura 17. Diagrama de Actividad del Método R2: “Crear clases”

Capítulo 4

56

4.4.3 Método de reestructura R3: “Crear constructor”

El método “R3: Crear Constructor” es utilizado por los métodos R9: "Reubicar funciones

especializadas" y R10: "Fragmentar funciones no especializadas" para generar constructores de

clase, lo cual es realizado al crearlos o al reubicarlos (copiarlos) desde otras clases.

El proceso del método se describe en el diagrama de actividad que va de la Figura 18 a la

Figura 19. Y Los pasos que sigue este algoritmo se encuentran definidos en el Anexo A.


57

Figura 18. Diagrama de Actividad del Método R3: “Crear constructor”

Capítulo 4

58

Figura 19. Diagrama de Actividad del Método R3: “Crear constructor” (parte 2)

4.4.4 Método de reestructura R5: “Reubicar atributos”

El método R5 es utilizado por los métodos R9: "Reubicar funciones especializadas" y R10:

"Fragmentar funciones no especializadas" para hacer la reubicación de atributos de una clase a

otra o para reubicar los atributos a los que acceden las funciones reubicadas.

Este método utiliza la tabla “Variables MVA” la cual se describe a continuación:

Tabla 8. Descripción de la tabla Variables MVA

Variables MVA

Campo Descripción

Identificador Identificador de la variable a reubicar.

Tipo Tipo de la variable.

Especificador Especificador de acceso de la variable.

Valor Valor contenido en la variable.

Función Firma de la función de donde se accede a la variable.

El proceso seguido para ejecutar este método se muestra en la Figura 20.


59

Figura 20. Diagrama de Actividad del Método R5: “Reubicar atributos”

Los pasos que se siguen durante este método se encuentran definidos en el Anexo A.

Capítulo 4

60

4.4.5 Método de reestructura R4: “Crear funciones”

El método R4 es utilizado por el método R10: "Fragmentar funciones no especializadas" con el

objetivo de crear nuevas funciones en las que se reubican los estatutos de código que pertenecen

a la Vista y/o al Adaptador.

Este método inserta información en la tabla “Funciones concretas MVA”. Los pasos de este

método se encuentran en el Anexo A. Y el proceso de este método se muestra en el diagrama de

actividad representado en la Figura 21 y Figura 22.


61

Figura 21. Diagrama de Actividad del Método R4: “Crear funciones”

Capítulo 4

62

Figura 22. Diagrama de Actividad del Método R4: “Crear funciones” (parte 2)

Implementación del Sistema

63

Capítulo 5. Implementación del Sistema

Una vez definido el proceso de refactorización, el siguiente paso fue el diseño e implementación

del sistema. En este capítulo se describe la implementación de seis de los once métodos que

conforman el proceso de refactorización. Se presentan los diagramas de clases y paquetes

utilizados. Se especifican los criterios utilizados para realizar la etiquetación de código y las

herramientas externas utilizadas para la implementación del sistema.

5.1 Implementación del proceso de refactorización en la

herramienta MOO2MVA

La herramienta elaborada para la implementación del proceso de refactorización de MOO hacia

una arquitectura MVA fue denominada MOO2MVA y a continuación, en la Figura 23 se describe su

arquitectura general.

Capítulo 5

64

Figura 23. Diagrama general de la herramienta MOO2MVA

Como se puede observar la arquitectura general de la herramienta se diseñó siguiendo la

arquitectura del patrón MVA, en la cual el paquete llamado InterfazGrafica contiene los elementos

relacionados con la vista de la aplicación. El paquete Adaptador contiene la clase que funciona

como intermediaria entre la vista y el modelo. El modelo de la aplicación se encuentra contenido

en el paquete MOO2MVA el cual contiene la lógica del negocio, que en este caso son los métodos

y el proceso de refactorización.

5.1.1 Paquete InterfazGrafica

En la Figura 24 se muestran las clases que conforman al paquete InterfazGrafica, dicho paquete

consta únicamente de 4 clases.

La clase IGUMOO2MVA es la encargada de crear la ventana que se presenta para

interactuar con el usuario de la aplicación. Las clases JavaFilter y Utils son utilizadas para validar

que los archivos introducidos por el usuario sean archivos con extensión *.java. Y la clase

ControladorEventos que implementa a la interfaz ActionListener es la encargada de indicar las

actividades a ejecutarse por parte de la aplicación ante la interacción del usuario, por ejemplo,

cuando éste da clic en algún botón qué método del adaptador debe ser invocado.


65

Figura 24. Diagrama de clases del paquete InterfazGrafica

5.1.2 Paquete Adaptador

Este paquete consta de una única clase la cual contiene el método que orquesta a la aplicación en

general; en él se establece el orden en que son ejecutadas las actividades del proceso de

refactorización. La Figura 25 muestra este paquete.

Figura 25. Diagrama de clases del paquete Adaptador

5.1.3 Paquete MOO2MVA

El paquete MOO2MVA contiene la lógica del negocio de la aplicación, en él se encuentran

contenidas las clases que hacen posible la implementación de los métodos que conforman el

proceso de refactorización. Dentro de este paquete se crearon tres subpaquetes: A1Analizar,

A2Refactorizar y baseDatos.

El subpaquete A1Analizar contiene a las clases necesarias para la implementación del

método R1: “Analizar código legado”. El subpaquete A2Refactorizar contiene las clases que

class InterfazGrafica

ActionListener

ControladorEv entos

~ carpetaSalida: String

~ directorioEntrada: File

~ directorioSalida: File

~ listaArchivosJ: LinkedList<File> = null

~ listaArchivosJava: LinkedList<File> = new LinkedList<...

~ listaDirectorios: LinkedList<File> = new LinkedList<...

~ listaDirectoriosVisitados: LinkedList<File> = new LinkedList<...

~ ma: OrquestadorAplicacion = new Orquestador...

~ ventana: IGUMOO2MVA

+ actionPerformed(ActionEvent) : void

+ ControladorEventos(IGUMOO2MVA)

# verificarArchivos(File, JTextArea) : LinkedList<File>

JFrame

IGUMOO2MVA

+ bAbrir: JButton

+ bAgregarClase: JButton

+ bEstablecer: JButton

+ bIniciar: JButton

+ bSeleccionar: JButton

+ jfcSeleccionarEntrada: JFileChooser

+ jfcSeleccionarSalida: JFileChooser

+ jLabel1: JLabel

+ jLabel2: JLabel

+ jPanel1: JPanel

+ jPanel2: JPanel

+ jPanel3: JPanel

+ jPanel4: JPanel

+ jPanel5: JPanel

+ jRutaEntrada: JTextField

+ jRutaSalida: JTextField

+ jTextArea1: JTextArea




+ IGUMOO2MVA()

- initComponents() : void

+ main(String[]) : void

FileFilter

Jav aFilter

+ accept(File) : boolean

+ getDescription() : String

Utils

+ java: String = "java" {readOnly}

# createImageIcon(String) : ImageIcon

+ getExtension(File) : String

~ventana

class Adaptador

OrquestadorAplicacion

+ orquestarAplicacion(LinkedList<File>, File) : String

Capítulo 5

66

implementan a los métodos R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5:

“Reubicar atributos” y R7: “Estructura jerárquica de clases”. Y el subpaquete baseDatos contiene

las clases utilizadas para realizar las conexiones a la base de datos y para leer y escribir en ella.

En la Figura 26 que se muestra a continuación se representa la arquitectura del paquete

MOO2MVA.

Figura 26. Diagrama de clases del paquete MOO2MVA

5.1.3.1 Subpaquete baseDatos

El paquete baseDatos es un subpaquete del paquete MOO2MVA. En este subpaquete se

encuentran contenidas las clases que permiten realizar la conexión con la base de datos llamada

“BD_MOO2MVA” la cual fue implementada en el motor de base de datos MySql en su versión 5.5.

Para realizar las conexiones a la base de datos se utiliza la clase llamada ConectorBD,

además, cada tabla contenida en la base de datos tiene una clase que la representa dentro de este

paquete, esto con el objetivo de facilitar las búsquedas de elementos y evitar tener abierta la

conexión a la base de datos todo el tiempo.

La estructura del subpaquete baseDatos se muestra a continuación en la Figura 27.


67

Figura 27. Diagrama de clases del paquete MOO2MVA.baseDatos

class baseDatos

ClaseAdaptador

- bd: ConectorBD

- Clase_Base1: String


- id: String

- Nombre: String

- Tipo: String

- Tipo_Relacion1: String


ClaseModelo

- bd: ConectorBD



- id: String

- Nombre: String

- Tipo: String



ClasesVistaUI

- bd: ConectorBD

- clase: String

- id: String

- paquete: String

ClaseVista

- bd: ConectorBD



- id: String

- Nombre: String

- Tipo: String



ConectorBD

- cp: ConnectionPool = null

- driver: String

- nombreBD: String

- password: String

- url: String

- usuario: String

+ close() : void

+ ConectorBD(String, String, String, String, String)

+ execute(String) : ResultSet

+ getDriver() : String

+ getNombreBD() : String

+ getPassword() : String

+ getUrl() : String

+ getUsuario() : String

+ setDriver(String) : void

+ setNombreBD(String) : void

+ setPassword(String) : void

+ setUrl(String) : void

+ setUsuario(String) : void

+ update(String) : int

Runnable

ConnectionPool

- m_AvailableConnections: Vector = new Vector()

- m_CleanupThread: Thread = null

- m_InitialConnectionCount: int = 5

- m_Password: String = null

- m_URLString: String = null

- m_UsedConnections: Vector = new Vector()

- m_UserName: String = null

+ availableCount() : int

+ cerrarConexiones() : void

+ checkin(Connection) : void

+ checkout() : Connection

+ ConnectionPool(String, String, String)

- getConnection() : Connection

+ run() : void

EstatutoBloque

- bd: ConectorBD

- clase: String

- firmaFuncion: String

- id: String

- noLineaFin: String

- noLineaInicio: String

- patronMVC: String

- tipoEstatutoBloque: String

EstatutoLinea

- bd: ConectorBD

- clase: String

- Estatuto: String

- firmaFuncion: String

- id: String

- noLinea: String

- patronMVC: String

FuncionAbstracta

- bd: ConectorBD

- Clase: String

- Especificador: String

- Firma: String

- id: String

- Patron_MVC: String

- Tipo_Retorno: String

FuncionAbstractaMVA

- bd: ConectorBD

- Clase: String


- Firma: String

- id: String



FuncionConcreta

- bd: ConectorBD

- Clase: String


- Firma: String

- id: String



- Variable_Retorno: String

FuncionConcretaMVA

- bd: ConectorBD

- Clase: String


- Firma: String

- id: String



JerarquiaClase

- bd: ConectorBD

- ClaseHija: String

- ClasePadre: String

- id: String

TipoClase

- bd: ConectorBD



- id: String

- Nombre: String

- Paquete: String


- Tipo: String



TipoVariable

- bd: ConectorBD

- Clase_Funcion: String

- Clase_Variable: String


- FirmaFuncion: String

- id: String

- Identificador: String

- Tipo: String

VariableMVA

- bd: ConectorBD

- Clase: String


- Funcion: String

- id: String

- Identificador: String

- Tipo: String

- Valor: String

-bd-bd-bd-bd -bd-bd-bd

-bd

-bd-bd

-cp

-bd-bd-bd-bd

Capítulo 5

68

5.2 Implementación de la actividad A1. Analizar el código del

MOO

Para la implementación de la actividad A1 en la que se analiza el código del MOO original y se

etiquetan los estatutos, funciones y clases de acuerdo a las partes del patrón MVA a las que

pertenecen, se diseñó la arquitectura mostrada en la Figura 28 la cual corresponde al paquete

MOO2MVA.A1Analizar.

Figura 28. Diagrama de clases del paquete MOO2MVA.A1.Analizar

Esta actividad está conformada únicamente por el método R1: “Analizar código legado” y

de manera general se puede describir el funcionamiento de éste de la siguiente manera: su

entrada son las clases de Java del MOO a refactorizar; el método recibe dichas clases, las analiza y

realiza la etiquetación de sus estatutos de acuerdo a la parte del patrón MVA a la que pertenecen;

se almacena la información de sus variables de clase, métodos y de la clase; su salida, además de

la información almacenada en la base de datos, son clases de Java etiquetadas, las cuales

conservan el mismo código que las clases de entrada.

Este método podría considerarse como la base para la refactorización del código legado,

su importancia radica en que los métodos posteriores basan su funcionamiento en la etiquetación


69

de código y en la información almacenada en la base de datos resultante de la ejecución de este

método.

5.2.1 Implementación del método R1: “Analizar código legado”

Debido a que para conseguir el objetivo del método R1 fue necesario elaborar un traductor de

código Java a código Java, en la implementación de esta parte de la herramienta se utilizó el

generador de analizadores sintácticos ANTLR (ANother Tool for Language Recognition) [ANTL,10]

en su versión 3, el cual es un sofisticado generador de analizadores sintácticos que puede utilizarse

para implementar interpretadores, compiladores y otros traductores [PARR,07].

Cuando se construyen traductores en ANTLR generalmente se envía un Árbol de Sintaxis

Abstracta (AST) entre las fases del traductor. Las fases posteriores a la construcción del AST, son

recorredores de árboles. Las fases subsecuentes pueden alterar o extraer información del AST. Por

ejemplo, la primera fase puede agregar la información sobre la definición de variables y métodos

en una tabla de símbolos. La siguiente fase puede alterar el AST para que los nodos creados para

una variable o método referencien a su símbolo en la tabla de símbolos. La fase final normalmente

emite salidas usando la información recolectada durante las fases anteriores [PARR,07].

Un enfoque parecido al descrito anteriormente se utilizó para la implementación del

método R1. En una primera iteración se genera la tabla de símbolos de todos los archivos java que

conforman el MOO y en una segunda iteración se utiliza la tabla de símbolos para que los nodos

hagan referencia a su símbolo en la tabla de símbolos, y en base a la información contenida en la

tabla se etiqueta el código del MOO. A continuación se describe dicho proceso.

1. Generación de la tabla de símbolos

Las gramáticas del lenguaje java utilizadas para esta implementación se encuentran en la

Lista de Gramáticas para ANTLR en [ANTL,09]. Se utilizaron dos gramáticas elaboradas por Dieter

Habelitz, las cuales están disponibles en

http://www.antlr.org/grammar/1207932239307/Java1_5Grammars. La primera gramática Java.g

es una gramática cuya salida es un AST y la gramática JavaTreeParser.g es un “tree walker”

recorredor de árbol de ese AST. Con el objetivo de adaptarlas a esta implementación se

renombraron dichas gramáticas. La gramática Java.g se convirtió en la gramática LenguajeJava.g y

la gramática JavaTreeParser.g en ReconocedorSimbolos.g, la interacción de estos archivos se

muestra en la Figura 29.

Figura 29. Proceso de obtención de la tabla de símbolos

http://www.antlr.org/grammar/list

http://www.antlr.org/grammar/1207932239307/Java1_5Grammars

Capítulo 5

70

Como se puede observar, el primer paso es la introducción del código java en

LenguajeJavaLexer cuya salida son tokens, los cuales son analizados por LenguajeJavaParser, si no

se presentan errores de sintaxis, la salida obtenida de LenguajeJavaParser es un AST que es

analizado por ReconocedorSimbolos que contiene las acciones semánticas para generar la tabla de

símbolos.

Es importante señalar que para generar la tabla de símbolos fue necesario extender la

clase CommonTree del ANTLR y crear la clase SLAST, esto debido a que la clase CommonTree

permite almacenar cierta información básica para los nodos del AST y para esta implementación

era necesario que almacenara información adicional para cada nodo, dicha información es el

ámbito de cada símbolo, el símbolo y la parte del patrón MVA a la que pertenece.

Al registrar cada variable en la tabla de símbolos se guarda también la parte del patrón

MVA a la que pertenece. Para determinar esto se utilizan los siguientes criterios:

Elementos de la vista: Debido a que en java los paquetes de clases AWT y SWING permiten la

creación y manipulación de las interfaces gráficas de usuario, y que el paquete java.io permite

la interacción a través de la línea de comandos; si la variable analizada es de algún tipo que

pertenece a las librerías java.awt, java.swing o java.io dicha variable es asignada a la Vista.

Elementos del modelo: Si la variable analizada es de tipo primitivo o de algún paquete de

clases que no sea awt, swing o io, tal variable es asignada al Modelo.

Elementos del control o adaptador: Debido a que en el presente trabajo se está utilizando el

patrón MVC en su variante MVA, no se considera que existan variables pertenecientes al

Adaptador, sino que esta capa será construida utilizando los métodos posteriores para

conseguir la interacción entre la Vista y el Modelo

La arquitectura de clases utilizada para la Tabla de Símbolos se muestra más adelante en la

Figura 31.

2. Utilización de la tabla de símbolos para la etiquetación de código

Una vez obtenida la tabla de símbolos se vuelve a analizar el código de las clases del MOO

para, basándose en la información almacenada en la tabla, etiquetar los estatutos, funciones y

clases.

Son utilizados nuevamente los Lexer y Parser de la gramática LenguajeJava y se crea un

nuevo recorredor de árbol llamado Etiquetador, el cual contiene las acciones semánticas

necesarias para obtener la información de la tabla de símbolos, etiquetar el código y almacenar la

información de variables, funciones y clases en la base de datos. El proceso se muestra en la Figura

30 a continuación.


71

Figura 30. Proceso de etiquetación utilizando la tabla de símbolos

Para la etiquetación de los estatutos de código se utilizan los siguientes criterios:

Estatutos de la vista: Si el estatuto analizado contiene alguna variable perteneciente a la vista

o presenta alguna interacción con el usuario utilizando System.out, System.err o System.in,

dicho estatuto es etiquetado como de la Vista.

Estatutos del modelo: Si el estatuto analizado sólo contiene variables pertenecientes al

modelo el estatuto es etiquetado como parte del Modelo.

Estatutos del control o adaptador: Como no se considera que existan variables pertenecientes

al Control o Adaptador, tampoco se etiquetan estatutos del Control o del Adaptador.

Para la etiquetación de funciones y clases se sigue el proceso descrito en el método R1

presentado en el capítulo anterior.

Capítulo 5

72

Figura 31. Diagrama de clases del paquete MOO2MVA.A1.Analizar.TablaSímbolos

class TablaSimbolos

«interface»

Ambito

+ agregarSimbolo(String, Simbolo) : Simbolo

+ buscarSimbolo(String) : Object

+ getAmbitoEnvolvente() : Ambito

+ getAmbitosPadre() : LinkedList <AmbitoBase>

+ getMiembros() : Map

+ getNombreAmbito() : String

+ removerSimbolo(String) : String

+ setNombreAmbito(String) : void

AmbitoBase

# ambitoEnvolvente: AmbitoBase = null

# ambitoPadre: LinkedList<AmbitoBase> = new LinkedList<...

# nombreAmbito: String = ""

# simbolos: Map = new HashMap()

+ agregarAmbitoBloque(String, Ambito) : Ambito


+ AmbitoBase()

+ AmbitoBase(String, AmbitoBase)

+ buscarEnPadre(String) : Object

+ buscarEnTodo(AmbitoBase, String) : Object


+ getAmbitoActual() : Ambito

+ getAmbitoEnvolvente() : AmbitoBase

+ getAmbitosPadre() : LinkedList<AmbitoBase>



+ getSimbolos() : Map


+ setAmbitoEnvolvente(AmbitoBase) : void

+ setAmbitoPadre(AmbitoBase) : void


+ setSimbolos(Map) : void

AmbitoGlobal

+ AmbitoGlobal(String)

AmbitoLocal

+ AmbitoLocal(String, AmbitoBase)

Simbolo

# ambitoEnvolvente: Ambito

# definicion: SLAST

# especificador: String

# nombreSimbolo: String

# tipo: Tipo

+ getAmbitoContenedor() : Ambito


+ getDefinicion() : SLAST

+ getEspecificador() : String

+ getNombreSimbolo() : String

+ getTipo() : Tipo

+ setAmbitoEnvolvente(Ambito) : void

+ setDefinicion(SLAST) : void

+ setEspecificador(String) : void

+ setTipo(Tipo) : void

+ Simbolo()

+ Simbolo(String)

+ Simbolo(String, Tipo)

+ Simbolo(String, Tipo, String)

SimboloClase

+ getNombreTipo() : String

+ SimboloClase(String, AmbitoBase, String)

SimboloConAmbito

~ ambitoActual: AmbitoBase



+ getAmbitoActual() : AmbitoBase


+ getAmbitosPadre() : LinkedList<AmbitoBase>




+ setAmbitoActual(AmbitoBase) : void

+ setAmbitoContenedor(Ambito) : void


+ setNombreSimbolo(String) : void

+ SimboloConAmbito()

+ SimboloConAmbito(AmbitoBase)

SimboloMetodo

+ SimboloMetodo(String, AmbitoBase, Tipo, String)

SimboloPrimitiv o


+ SimboloPrimitivo()

+ SimboloPrimitivo(String)

SimboloUDT




+ SimboloUDT()

+ SimboloUDT(String)

SimboloVariable

~ nombreClaseExterna: String

+ getNombreSimbolo() : String



+ SimboloVariable(String)

+ SimboloVariable(String, Tipo)

+ SimboloVariable(String, Tipo, String)

CommonTree

SLAST

+ patronMVC: String

+ scope: Ambito

+ symbol: Simbolo

+ dupNode() : Tree

+ SLAST()

+ SLAST(Token)

+ SLAST(SLAST)

+ SLAST(Token, Ambito, Simbolo)

SLASTCommonErrorNode

+ input: IntStream

+ start: Token

+ stop: Token

+ trappedException: RecognitionException

+ getText() : String

+ getType() : int

+ isNil() : boolean

+ SLASTCommonErrorNode(TokenStream, Token, Token, RecognitionException)

+ toString() : String

CommonTreeAdaptor

SLASTCommonTreeAdaptor

+ create(Token) : Object

+ dupNode(Object) : Object

+ errorNode(TokenStream, Token, Token, RecognitionException) : Object

«interface»

Tipo


#ambitoEnvolvente

#definicion

#tipo

+scope

+symbol

~ambitoActual


73

5.3 Implementación de la actividad A2. Reestructurar el código

legado.

Para la implementación de la actividad A2. “Reestructurar el código legado”, se creó un paquete

llamado MOO2MVA.A2Refactorizar en el cual se encuentra contenida una clase para cada método

que participa en la actividad A2. Estos métodos son:

R2: “Crear clases”

R3: “Crear constructor”

R4: “Crear funciones”

R5: “Reubicar atributos”

R6: “Reestructurar clases”

R7: “Estructura jerárquica de clases”

R8: “Coordinador de la creación de clases”

R9: "Reubicar funciones especializadas"

R10: "Fragmentar funciones no especializadas"

R11: "Redefinir llamadas a funciones"

Debido a limitaciones de tiempo y a que algunos de los métodos se encuentran en etapa

de refinamiento, no fue posible implementar todos los métodos que conforman esta actividad, los

métodos que sí fueron implementados son los siguientes:

El método R2: “Crear clases” fue implementado en la clase R2CrearClases.

El método R3: “Crear constructor” se implementó en la clase R3CrearConstructor.

El método R4: “Crear funciones” se implementó en la clase R4CrearFunciones.

El método R5: “Reubicar atributos” fue implementado en la clase R5ReubicarAtributos

El método R7: “Estructura jerárquica de clases” se implementó en la clase

R7EstructurarJerarquiaClases

El diagrama de este paquete se presenta a continuación en la Figura 32.

Capítulo 5

74

Figura 32. Diagrama de clases del paquete MOO2MVA.A2.Refactorizar

Pruebas del Sistema

75

Capítulo 6. Pruebas del Sistema

En este capítulo se describe el plan de pruebas utilizado para probar los métodos implementados

en la herramienta MOO2MVA. El plan de pruebas está basado en el estándar para pruebas de

software 829-1998 del Instituto de Ingenieros Electricos y Electrónicos (IEEE por sus siglas en

inglés) [SOFT,98].

Las pruebas se realizaron probando cada uno de los métodos implementados; y sólo las

pruebas del método R7: “Estructura jerárquica de clases” dependen de las salidas obtenidas al

probar el método R1: “Analizar código legado”, los demás métodos fueron probados cada uno por

separado.

El objetivo de las pruebas fue demostrar que los métodos implementados R1: “Analizar

código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar

atributos” y R7: “Estructura jerárquica de clases” funcionan correctamente.

6.1 Identificador del Plan de Pruebas

El código de identificación para la ejecución del plan de pruebas se presenta a continuación y se

establece para todo el proceso de evaluación de la herramienta de refactorización MOO2MVA.

Capítulo 6

76

6.2 Documentación de Prueba

La documentación utilizada en el plan de pruebas se resume en la siguiente tabla.

Tabla 9. Documentos del plan de pruebas

Documentos del plan de pruebas

Tipo Descripción

MOO2MVA-PP-XX Plan de pruebas.

MOO2MVA-DP-XX Especificación de diseño de las pruebas.

MOO2MVA-CP-XX Especificación de los casos de pruebas.

6.3 Descripción del Plan de Pruebas

6.3.1 Plan de pruebas para MOO2MVA

6.3.1.1 Elementos de prueba

El conjunto de casos de prueba que se describe tiene como objetivo verificar y validar el correcto

funcionamiento de los métodos de reestructura R1: “Analizar código legado”, R2: “Crear clases”,

R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura

jerárquica de clases”; los cuales colaboran en la refactorización de MOO a una arquitectura MVA.

Los elementos para realizar las pruebas son:

a) Archivos con clases Java que pertenecen a un MOO. Las clases utilizadas se describen en la

Tabla 10.

Pruebas del Sistema

77

Tabla 10. Clases de Java a usarse como elementos de prueba

Clases Java

ID Nombre de la clase Descripción

CJ01 aConicas.java Clase abstracta referente a las figuras cónicas.

CJ02 aCuadrilateros.java Clase abstracta referente a los cuadriláteros.

CJ03 aCuerpo.java Clase abstracta referente a los cuerpos.

CJ04 aCurvos.java Clase abstracta referente a los cuerpos curvos.

CJ05 aElemGeometrico.java Clase abstracta referente a los elementos geométricos.

CJ06 aFigura.java Clase abstracta referente a las figuras.

CJ07 aParalelogramos.java Clase abstracta referente a los paralelogramos.

CJ08 aPiramides.java Clase abstracta referente a las pirámides.

CJ09 aPoliedros.java Clase abstracta referente a los poliedros.

CJ10 aPoliedrosIrregulares.java Clase abstracta referente a los poliedros irregulares.

CJ11 aPoliedrosRegulares.java Clase abstracta referente a los poliedros regulares.

CJ12 aPoligonos.java Clase abstracta referente a los polígonos.

CJ13 aPrismas.java Clase abstracta referente a los prismas.

CJ14 aTrapecios.java Clase abstracta referente a los trapecios.

CJ15 aTriangulos.java Clase abstracta referente a los triángulos.

CJ16 cCilindro.java Clase concreta referente a los cilindros.

CJ17 cCirculo.java Clase concreta referente a los círculos.

CJ18 cCono.java Clase concreta referente a los conos.

CJ19 cCuadrado.java Clase concreta referente a los cuadrados.

CJ20 cCubo.java Clase concreta referente a los cubos.

CJ21 cDecagono.java Clase concreta referente a los decágonos.

CJ22 cDodecaedro.java Clase concreta referente a los dodecaedros.

CJ23 cElipse.java Clase concreta referente a los eclipses.

CJ24 cEneagono.java Clase concreta referente a los eneágonos.

CJ25 cEsfera.java Clase concreta referente a las esferas.

CJ26 cHeptagono.java Clase concreta referente a los heptágonos.

CJ27 cHexagono.java Clase concreta referente a los hexágonos.

CJ28 cIcosaedro.java Clase concreta referente a los icosaedros.

CJ29 cOctaedro.java Clase concreta referente a los octaedros.

CJ30 cOctagono.java Clase concreta referente a los octágonos.

CJ31 cPentagono.java Clase concreta referente a los pentágonos.

CJ32 cPiramides.java Clase concreta referente a las pirámides.

CJ33 cPrismas.java Clase concreta referente a los prismas.

CJ34 cRectangulo.java Clase concreta referente a los rectángulos.

CJ35 cRombo.java Clase concreta referente a los rombos.

CJ36 cRomboide.java Clase concreta referente a los romboides.

CJ37 cTetraedro.java Clase concreta referente a los cilindros.

CJ38 cTrapecio.java Clase concreta referente a los trapecios.

CJ39 cTrapecioIsosceles.java Clase concreta referente a los trapecios isósceles.

CJ40 cTrapecioRectangulo.java Clase concreta referente a los trapecios rectángulos.

CJ41 cTrapezoide.java Clase concreta referente a los trapezoides.

CJ42 cTrianguloEquilatero.java Clase concreta referente a los triángulos equiláteros.

CJ43 cTrianguloEscaleno.java Clase concreta referente a los triángulos escalenos.

CJ44 cTrianguloIsosceles.java Clase concreta referente a los triángulos isósceles.

Capítulo 6

78

Las clases presentadas anteriormente constituyen el MOO de Figuras Geométricas y su

diagrama de clases se muestra a continuación en la Figura 33.

Figura 33. Diagrama de clases del MOO Figuras Geométricas

6.3.1.2 Características a ser probadas

Las características a ser probadas son:

1. Funcionamiento del método R1: “Analizar código legado” al etiquetar código de acuerdo al

patrón MVA y al almacenar información sobre las funciones y clases en las tablas “Tipos de

Clases”, “Tipos de variable”, “Funciones abstractas” y “Funciones concretas”.

Pruebas del Sistema

79

2. Obtención de la estructura jerárquica de clases utilizando el método R7: “Estructura jerárquica

de clases”, almacenando correctamente la información en la tabla “Jerarquía de Clases”.

3. Creación de clases utilizando el método R2: “Crear clases”.

4. Creación de constructores utilizando el método R3: “Crear constructor”.

5. Reubicación de atributos utilizando el método R5: “Reubicar atributos”.

6. Creación de funciones y almacenamiento correcto de la información en la tabla “Funciones

concretas MVA” al utilizar el método R4: “Crear funciones”.

6.3.1.3 Características que no se probarán

A continuación se describen las actividades que no serán probadas:

1. La completa refactorización del MOO hacia una arquitectura MVA.

2. El tiempo de duración de la prueba.

6.3.1.4 Enfoque

El enfoque utilizado en este plan de pruebas se centra en los resultados de cada método (R1, R2,

R3, R4, R5 y R7). Se utiliza un enfoque de prueba de caja negra, el cual se centra en lo que se

espera de cada método, y se intentan encontrar casos en los que el método no cumpla con su

especificación. Las pruebas con un enfoque de caja negra también son denominadas pruebas

funcionales, en las que se introducen datos de entrada y se estudia la salida.

6.3.1.5 Criterio aceptado no aceptado

Se considera que un caso de prueba tiene éxito cuando los resultados esperados coinciden con los

descritos en el caso de prueba. De lo contrario se determinará si se debe continuar con los casos

de prueba o finalizar la validación.

6.3.1.6 Criterios de suspensión y criterios de reanudación

Las pruebas se suspenderán temporalmente cuando al menos una de ellas no sea aceptada,

inmediatamente se evaluará y corregirá el error. Una vez corregido el error se reanudarán las

pruebas y el caso de prueba pasará el criterio de aceptación.

6.3.1.7 Liberación de pruebas

Para aceptar y finalizar las pruebas se debe tener que todas las salidas de la ejecución de los

métodos (R1, R2, R3, R4, R5, y R7) coincidan con las salidas esperadas para cada caso de prueba.

6.3.1.8 Requisitos ambientales

Las características físicas y lógicas necesarias para el entorno de pruebas son las siguientes:

Hardware

Procesador Core i7 o superior.

2 GB de memoria RAM o superior.

Capítulo 6

80

Mouse

Teclado

Sistema Operativo

Windows 7 Service pack 1

Herramientas

MySql Server 5.5.16

Máquina Virtual de Java: jdk1.6.0_07 o superior

Entorno de Desarrollo para Java, Netbeans 7.0.1 u otro.

Programas de prueba

Clases de Java del MOO a probar.

6.3.1.9 Responsabilidades

La persona responsable de administrar, diseñar, preparar y ejecutar las pruebas es la Ing. Luz

Christina Gaitán Torres, quien se encargará de ingresar el código java del MOO y comparar los

resultados obtenidos con los esperados en cada caso de prueba.

6.3.1.10 Riesgos

A continuación se presentan los posibles riesgos para la ejecución del presente plan de pruebas:

La no disponibilidad del ambiente para la ejecución de pruebas.

Pérdida de tiempo en la generación de los casos de prueba.

No contemplar algunos aspectos de importancia durante el diseño de los casos de prueba.

Pérdida de tiempo al ejecutar un caso de prueba incorrecto.

Pérdida de tiempo al corregir errores.

6.3.1.11 Aprobación

El plan de pruebas debe ser aprobado por el Dr. René Santaolaya Salgado y la M.C. Olivia Graciela

Fragoso Díaz.

6.4 Especificación del Diseño de Pruebas

Propósito

En esta sección se describe el diseño de pruebas para probar los métodos, R1: “Analizar

código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar

atributos” y R7: “Estructura jerárquica de clases”.

6.4.1 MOO2MVA-DP-01

Pruebas del Sistema

81

Diseño de prueba para el método R1: “Analizar código legado” al etiquetar código de

acuerdo al patrón MVA y al almacenar información sobre las variables, funciones y

clases en las tablas correspondientes

a) Características a ser probadas

Esta prueba tiene como característica la siguiente:

1. Funcionamiento del método R1: “Analizar código legado” al etiquetar código de

acuerdo al patrón MVA y al almacenar información sobre las funciones y clases en las

tablas “Tipos de Clases”, “Tipos de variable”, “Funciones abstractas” y “Funciones

concretas”.

b) Refinamiento del enfoque

El objetivo es probar que el código del MOO es etiquetado correctamente generando

nuevos archivos java con el mismo código y con la etiquetación como comentario; que la

información sobre de las clases es extraída y almacenada correctamente en la tabla “Tipos de

clases”; que la información sobre las funciones abstractas es extraída y almacenada correctamente

en la tabla “Funciones abstractas”; que la información sobre las funciones concretas es extraída y

almacenada correctamente en la tabla “Funciones concretas”; y que la información sobre las

variables de clase es extraída y almacenada correctamente en la tabla “Tipos de variable”.

c) Identificación de las pruebas

MOO2MVA-CP-01

d) Características de criterio de aceptación/rechazo

Para el criterio de aceptación o rechazo, se debe realizar la evaluación visual del código

generado a partir de la etiquetación para comprobar que fue etiquetado correctamente. Además,

se deben revisar las tablas “Tipos de Clases”, “Tipos de variable”, “Funciones abstractas” y

“Funciones concretas” y comparar su contenido con el contenido de los archivos analizados. Si la

etiquetación se realizó correctamente y las tablas contienen la información correcta, entonces se

considerará que la prueba es aceptada. En caso contrario, la prueba será rechazada.

6.4.2 MOO2MVA-DP-02

Diseño de prueba para la obtención de la estructura jerárquica de clases utilizando el

método R7: “Estructura jerárquica de clases”, almacenando correctamente la

información en la tabla correspondiente



Capítulo 6

82

2. Obtención de la estructura jerárquica de clases utilizando el método R7: “Estructura

jerárquica de clases”, almacenando correctamente la información en la tabla

“Jerarquía de Clases”.


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.


MOO2MVA-CP-02


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”



3. Creación de clases utilizando el método R2: “Crear clases”.


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.


MOO2MVA-CP-03


Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual

para comprobar que las clases son creadas correctamente y se debe utilizar un editor de código

Java con detección de errores de sintaxis para comprobar que ninguno está presente. Si el código

y el archivo fueron creados correctamente, entonces se considera que la prueba ha sido aceptada.

De lo contrario, la prueba será rechazada.

Pruebas del Sistema

83

6.4.4 MOO2MVA-DP-04

Diseño de prueba para la creación de constructores utilizando el método R3: “Crear

constructor”



4. Creación de constructores utilizando el método R3: “Crear constructor”.


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.


MOO2MVA-CP-04



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”



5. Reubicación de atributos utilizando el método R5: “Reubicar atributos”.


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.


MOO2MVA-CP-05



para comprobar que los atributos son reubicados correctamente. Si el atributo fue reubicado

Capítulo 6

84

correctamente, en la clase establecida, entonces se considera que la prueba ha sido exitosa. De lo

contrario, la prueba será rechazada.

6.4.6 MOO2MVA-DP-06

Diseño de prueba para la creación de funciones y almacenamiento correcto de la

información en la tabla correspondiente al utilizar el método R4: “Crear funciones”



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”.


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”.


MOO2MVA-CP-06



para comprobar que las funciones fueron correctamente; se debe utilizar un editor de código Java

con detección de errores de sintaxis para comprobar que ninguno está presente; y comprobar que

la información almacenada en la tabla “Funciones concretas MVA” es la correcta. Si la función fue

creada correctamente y la información almacenada en la tabla es correcta, entonces se considera

que la prueba ha sido exitosa. De lo contrario, la prueba será rechazada.

6.5 Especificación de Casos de Prueba

Propósito

En esta sección se definen las características y los elementos de prueba requeridos para

realizar cada uno de los casos de prueba diseñados para probar el correcto funcionamiento de los

métodos R1: “Analizar código legado”, R2: “Crear clases”, R3: “Crear constructor”, R4: “Crear

funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”.

Pruebas del Sistema

85

6.5.1 MOO2MVA-CP-01

Número/Nombre Prueba: MOO2MVA-CP-01

Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011

Tipo de prueba Prueba de aceptación.

Objetivo Comprobar que se realiza correctamente la identificación y etiquetación de los estatutos del código legado de acuerdo a su tipo y a la parte del patrón MVA al que pertenecen. Además, comprobar el correcto almacenamiento de la información sobre variables, funciones y clases en las tablas correspondientes.

Condiciones de Ambiente Ninguna.

Entrada El código del marco orientado a objetos Figuras Geométricas escrito en lenguaje Java (elementos de prueba CJ01- CJ44)

Resultados Esperados Copia del código de un MOO escrito en lenguaje Java etiquetado correctamente de acuerdo a la parte del patrón MVA y a los tipos de estatutos que contiene.

Procedimiento de la Prueba

1. Inicio. 2. Se solicita la etiquetación del MOO. 3. Se realiza la copia de los archivos del código del MOO. 4. Se realiza la etiquetación del código del MOO. 5. Se realiza el almacenamiento de la información del MOO en las tablas

correspondientes. 6. Fin.

Cursos Alternos

Curso alterno 1 3. Ocurre algún error durante la copia de los archivos de código del MOO.

4. La herramienta notifica del error. 5. Fin.

Curso alterno 2 4. Ocurre algún error durante la etiquetación del código del MOO. 5. La herramienta notifica del error. 6. Fin.

Curso alterno 3 5. Ocurre algún error durante el almacenamiento de información en las tablas.


Excepciones

Post-condiciones Si se presenta algún error durante la generación de la copia de los archivos de código del MOO, o la etiquetación, o del almacenamiento de información es las tablas se notifica del error, entonces el caso de prueba termina.

Observaciones Ninguna.

6.5.2 MOO2MVA-CP-02




Objetivo Comprobar que se obtiene y almacena correctamente la estructura

Capítulo 6

86

jerárquica de las clases del MOO.

Condiciones de Ambiente El caso de prueba MOO2MVA-CP-01 se ha ejecutado con éxito anteriormente.

Entrada Tabla “Tipos de Clases” con los datos almacenados del MOO Figuras Geométricas.

Resultados Esperados En la tabla “Jerarquía de Clases” se tiene almacenada la información sobre la jerarquía de clases del MOO Figuras Geométricas.


1. Inicio. 2. Se solicita la obtención de la jerarquía de clases del MOO. 3. Se obtiene la jerarquía de clases. 4. Se almacena la información en la tabla. 5. Fin.

Cursos Alternos

Curso alterno 1 3. Ocurre algún error durante la obtención de la jerarquía de clases. 4. La herramienta notifica del error. 5. Fin.

Curso alterno 2 4. Ocurre algún error durante el almacenamiento de información en la tabla.


Excepciones

Post-condiciones Si se presenta algún error durante la obtención de la jerarquía de clases o el almacenamiento en la tabla, entonces el caso de prueba termina.

Observaciones Ninguna.

6.5.3 MOO2MVA-CP-03




Objetivo Comprobar que se generaran correctamente clases concretas, abstractas e interfaces de Java.


Entrada Nombre del paquete, nombre de la clase, tipo de clase, tipo de relación 1, clase base 1, tipo de relación 2 y clase base2.

Resultados Esperados Una clase de Java de acuerdo al tipo de clase solicitada (concreta, abstracta o interfaz) con las relaciones establecidas de acuerdo a lo solicitado.


1. Inicio. 2. Se solicita la generación de la clase. 3. Se genera la clase. 4. Se almacena el archivo generado para su posterior

comprobación. 5. Fin

Cursos Alternos

Curso alterno 1 3. Ocurre algún error durante la generación de la clase. 4. La herramienta notifica del error.

Pruebas del Sistema

87

5. Fin

Excepciones

Post-condiciones Si se presenta algún error durante la generación de la clase se notifica del error entonces el caso de prueba termina.

Observaciones Ninguna

Instancias de Prueba

No. de Instancia Valor Resultado Esperado

Instancia 1 Se solicita la creación de una clase concreta.

Clase de Java concreta generada correctamente.

Instancia 2 Se solicita la creación de una clase concreta derivada de otra clase.

Clase de Java concreta derivada de otra generada correctamente.

Instancia 3 Se solicita la creación de una clase concreta que implementa una interfaz

Clase de Java concreta que implementa una interfaz generada correctamente.

Instancia 4

Se solicita la creación de una clase concreta derivada de otra clase y que implementa una interfaz.

Clase de Java concreta derivada de otra e implementa una interfaz generada correctamente.

Instancia 5 Se solicita la creación de una clase abstracta.

Clase abstracta de Java generada correctamente.

Instancia 6 Se solicita la creación de una clase abstracta derivada de una clase.

Clase abstracta de Java derivada de una clase generada correctamente.

Instancia 7 Se solicita la creación de una clase abstracta que implementa una interfaz.

Clase abstracta de Java que implementa una interfaz generada correctamente.

Instancia 8 Se solicita la creación de una interfaz.

Interfaz de Java generada correctamente.

Instancia 9 Se solicita la creación de una interfaz que extiende a otra interfaz.

Interfaz de Java que extiende otra interfaz generada correctamente.

6.5.4 MOO2MVA-CP-04




Objetivo Comprobar que se crean correctamente los constructores con parámetros y sin parámetros. Y que es posible copiar el constructor de una clase en otra.

Condiciones de Ambiente Ninguna

Entrada Clase de Java en la cual se desea crear el constructor. Si se desea copiar un constructor también es necesario indicar la clase Java desde la cual se copiará.

Resultados Esperados La clase de Java que contendrá el constructor que ha solicitado (con o

Capítulo 6

88

sin parámetros, o copia de otro).


1. Inicio. 2. Se solicita la generación del constructor. 3. Se genera el constructor en la clase especificada. 4. Fin.

Cursos Alternos

Curso alterno 1 3. Ocurre algún error durante la generación del constructor. 4. La herramienta notifica del error. 5. Fin

Excepciones

Post-condiciones Si se presenta algún error durante la generación del constructor el caso de prueba termina.




Instancia 1 Se solicita la creación de un constructor sin parámetros.

La clase de Java contiene un constructor correcto y sin parámetros.

Instancia 2 Se solicita la creación de un constructor con parámetros.

La clase de Java contiene un constructor correcto y con parámetros.

Instancia 2 Se solicita la copia de un constructor.

La clase de Java contiene una copia del constructor de la clase especificada.

6.5.5 MOO2MVA-CP-05




Objetivo Comprobar que se realiza correctamente la reubicación de atributos.


Entrada Clase de Java en la cual se desean copiar los atributos y la tabla “Variables MVA” con registros que en la columna “Clase” coincidan con el nombre del archivo java.

Resultados Esperados Código Java con la reubicación de atributos realizada correctamente.


1. Inicio. 2. Se solicita la reubicación de atributos. 3. Se realiza la reubicación de atributos. 4. Fin.

Cursos Alternos

Curso alterno 1 3. Ocurre algún error durante la reubicación de atributos. 4. La herramienta notifica del error. 5. Fin.

Excepciones

Post-condiciones Si se presenta algún error durante la reubicación de atributos se notifica del error entonces el caso de prueba termina.

Pruebas del Sistema

89

6.5.6 MOO2MVA-CP-06




Objetivo Comprobar que se crean correctamente funciones con y sin parámetros.


Entrada Clase de Java en la cual se desea crear la función firma de la función, especificador de acceso de la función, parte del patrón MVA a la que pertenece la función, el tipo de retorno y en caso de que sea necesario la variable o valor de retorno y un vector con los estatutos de la función.

Resultados Esperados La clase de Java contiene la función que ha solicitado.


1. Inicio. 2. Se solicita la creación de una función. 3. Se crea la función. 4. Se copian los estatutos en la función. 5. Fin.

Cursos Alternos

Curso alterno 1 3. Ocurre algún error durante la creación de la función. 4. La herramienta notifica del error. 5. Fin.

Curso alterno 1 4. Ocurre algún error al copiar los estatutos a la función. 5. La herramienta notifica del error. 6. Fin.

Excepciones

Post-condiciones Si se presenta algún error durante la creación de la función o al copiar los estatutos en la misma, entonces se notifica del error y el caso de prueba termina.




Instancia 1 Se solicita la creación de una función sin parámetros.

La clase de Java contiene una función sin parámetros generada correctamente.

Instancia 2 Se solicita la creación de una función con parámetros.

La clase de Java contiene una función con parámetros generada correctamente.

Capítulo 6

90

6.6 Resultados de las Pruebas

En la Tabla 11 se muestran los resultados obtenidos de las pruebas al ejecutar cada uno de los

casos de prueba especificados en MOO2MVA-CP-01, MOO2MVA-CP-02, MOO2MVA-CP-03,

MOO2MVA-CP-04, MOO2MVA-CP-05, MOO2MVA-CP-06. Los diseños de prueba fueron

elaborados con el propósito de comprobar que los métodos implementados actualmente en la

herramienta MOO2MVA funcionan correctamente.

Los casos de prueba MOO2MVA-CP-02, MOO2MVA-CP-03 y MOO2MVA-CP-06 fueron

probados con varias instancias, esto con el propósito de verificar que sus salidas fueran correctas

con las diferentes entradas y usos que se les pueden dar.

Un aspecto importante a probar, además de la ejecución de los métodos, fue el correcto

almacenamiento de la información en las tablas de la base de datos correspondientes. Esto fue

probado en los casos de prueba MOO2MVA-CP-01, MOO2MVA-CP-02 y MOO2MVA-DP-06.

La tabla a continuación resume los resultados obtenidos durante la ejecución de las

pruebas.

Tabla 11. Resumen de los resultados obtenidos en las pruebas

Identificador Ejecución Almacenamiento de información en la Base de Datos

MOO2MVA-CP-01 -

MOO2MVA-CP-02 -

MOO2MVA-CP-03

Instancia 1 No aplica









MOO2MVA-CP-04




MOO2MVA-CP-05 - No aplica

MOO2MVA-CP-06 Instancia 1

Instancia 2

Pruebas del Sistema

91

6.7 Análisis de Resultados

Al realizar cada uno de los casos de prueba especificados en MOO2MVA-CP-01, MOO2MVA-CP-02,

MOO2MVA-CP-03, MOO2MVA-CP-04, MOO2MVA-CP-05, MOO2MVA-CP-06 se probaron los

métodos implementados hasta el momento en la herramienta MOO2MVA. Estos métodos son: R1:


“Reubicar atributos” y R7: “Estructura jerárquica de clases”.

Tomando en cuenta los resultados obtenidos al ejecutar las pruebas, mostrados en

resumen en la Tabla 11, se puede determinar que los métodos implementados funcionan

correctamente, pues las salidas obtenidas coinciden con las salidas esperadas para cada método y

las pruebas fueron concluidas satisfactoriamente dentro de los alcances de esta tesis.

Es importante señalar que, aunque el tiempo no fue un elemento a probar, durante la

ejecución del método R1: “Analizar código legado” se pudo observar que el tiempo tomado para la

ejecución del método depende en gran medida de la cantidad de código analizado y etiquetado.

Esto es porque además de la etiquetación también se hacen inserciones en la base de datos para

cada atributo de clase, para cada método contenido en las clases analizadas, y para cada clase, lo

cual puede ser causante de que, cuando se analiza una gran cantidad de clases, el tiempo de

ejecución del método llegue a ser considerable.

Al finalizar la ejecución de pruebas se afirma que los métodos implementados hasta el

momento en la herramienta MOO2MVA funcionan correctamente y que están listos para ser

utilizados por los métodos pendientes de desarrollo: R6: “Reestructurar clases”, R8: “Coordinador

de la creación de clases”, R9: "Reubicar funciones especializadas", R10: "Fragmentar funciones no

especializadas" y el R11: "Redefinir llamadas a funciones".

Como se mencionó anteriormente, en la Tabla 11 se muestra sólo el resumen de los

resultados obtenidos, en el Anexo B se incluye las entradas utilizadas en cada prueba e instancia

de prueba y las salidas obtenidas después de la ejecución de las mismas.

Conclusiones y Trabajos Futuros

93

Capítulo 7. Conclusiones y Trabajos Futuros

En este capítulo se detallan las conclusiones que son parte de este trabajo de tesis, las

aportaciones obtenidas con esta investigación y los que se podrían considerar trabajos futuros.

7.1 Conclusiones

El presente trabajo describe una primera aproximación para el desarrollo de una

herramienta llamada MOO2MVA, la cual tiene como objetivo automatizar la refactorización de

Marcos de Aplicaciones Orientados a Objetos hacia una arquitectura MVC.

Esta primera aproximación consistió en la implementación de seis de los once métodos

que conforman el proceso de refactorización. Dicho proceso utiliza como base los métodos

propuestos en “Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a

objetos hacia el patrón de diseño Modelo-Vista-Controlador” [NUÑE,08], tesis de maestría

realizada en el laboratorio de Ingeniería de Software del Centro Nacional de Investigación y

Desarrollo Tecnológico (CENIDET).

Se sometió a prueba la herramienta con un MOO que contenía una jerarquía de 44 clases y

cuyo dominio se encuentra en la geometría. Tomando en cuenta los resultados obtenidos al

Capítulo 7

94

ejecutar las pruebas, se puede determinar que los métodos implementados funcionan

correctamente, pues las salidas obtenidas coinciden con las salidas esperadas para cada método y

las pruebas fueron concluidas satisfactoriamente dentro de los alcances de esta tesis.

Como producto de este trabajo se obtiene una primera aproximación para la

implementación de la herramienta MOO2MVA, la cual puede servir como base para otros trabajos

futuros en los que se implementen los métodos restantes para el proceso de refactorización. Una

vez que se se tengan implementados todos los métodos, sería posible utilizar la herramienta para

transformar MOO hacia una arquitectura MVC, y una vez realizada esta transformación, tomar la

capa del Modelo para transformarla a servicios Web.

La importancia de transformar los MOO hacia servicios Web radica en que el conocimiento

y desarrollo contenido en los MOO no debe ser dejado atrás. Este conocimiento debe ser

adaptado a las nuevas tecnologías para conservar su estructura, funcionamiento, reglas de

negocio y el esfuerzo invertido en ellos. Dentro de las áreas que podrían verse beneficiadas por el

reuso de los MOO se encuentran: la fabricación de computadoras integradas, sistemas

distribuidos, redes y telecomunicaciones, o ambientes multimedia de trabajo colaborativo, entre

otros, [FAYA,00].

El objetivo del presente trabajo de tesis fue dividir la arquitectura original de los MOO

hacia una arquitectura MVC con el propósito de favorecer su reúso como servicios Web, mediante

el desarrollo de una herramienta que implemente los métodos propuestos en [NUÑE,08]

Aunque el proceso de refactorización no pudo ser implementado en su totalidad, se

considera que el objetivo se cumplió parcialmente, pues con base en las pruebas realizadas se

afirma que los métodos implementados hasta el momento en la herramienta MOO2MVA

funcionan correctamente y representan un primer paso hacia la automatización del proceso de

refactorización de MOO hacia una arquitectura MVC.

La implementación de seis de los once métodos que conforman el proceso de

refactorización representa una implementación de más del 50% de estos. Y debido a que dentro

de ellos se encuentra el método R1:”Analizar código legado”, se cree que la implementación actual

representa un avance considerable en el desarrollo de la herramienta. Pues durante la

investigación, se encontró que la etapa de análisis de código legado es la más importante dentro

del proceso de refactorización, y es considerada la base para dicho proceso. Esta etapa demanda

la mayor cantidad de análisis debido a que en ella se obtiene la estructura interna del código

legado.

Entre las aportaciones realizadas con este trabajo, se encuentra la colaboración en el

refinamiento de los métodos propuestos en [NUÑE,08] y en el diseño del proceso de

refactorización; además de la implementación de seis de los once métodos que conforman dicho

proceso. Los métodos implementados son: R1: “Analizar código legado”, R2: “Crear clases”, R3:

“Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica

de clases”.

Conclusiones y Trabajos Futuros

95

Además, con la implementación del método R1: “Analizar código legado”, fue necesaria la

elaboración de una tabla de símbolos, la cual puede ser utilizada para otros proyectos agregándole

información de acuerdo a las nuevas necesidades. Esta es una de las ventajas de que el proceso de

creación de la tabla de símbolos se encuentre separado del proceso de etiquetación de código

dentro del método R1.

Por lo anterior, se puede afirmar que la herramienta MOO2MVA lleva a cabo

satisfactoriamente una primera aproximación hacia la automatización del proceso de

refactorización, y que puede servir como base para trabajos futuros en los que se implementen los

métodos restantes para completar este proceso.

7.2 Trabajos futuros

Como trabajo futuro se propone continuar con el desarrollo de los métodos pendientes de ser

implementados, estos son: R6: “Reestructurar clases”, R8: “Coordinador de la creación de clases”,

R9: "Reubicar funciones especializadas", R10: "Fragmentar funciones no especializadas" y el R11:

"Redefinir llamadas a funciones".

Además, el método R1: “Analizar código legado” debe ser probado ampliamente con

código que incluya interfaces gráficas de usuario, con objetos y clases pertenecientes a las librerías

java.awt y java.swing para comprobar su correcto funcionamiento, y en caso de ser necesario,

realizar las modificaciones que estos nuevos casos necesiten.

Una vez implementados todos los métodos y haber probado el método R1: “Analizar

código legado” con código que incluya interfaces gráficas de usuario, se deberá realizar una etapa

extensiva de pruebas para validar que el resultado de la refactorización conserve la misma

funcionalidad que el código original.

Bibliografía

97

Bibliografía

[ABAD,08] Abadi, A., Ettinger, R., & Feldman, Y. A. (2008). Re-Approaching the Refactoring Rubicon. Recuperado el 15 de Marzo de 2011, de ACM Digital Library: http://dl.acm.org/citation.cfm?id=1636652

[AHO,98] Aho, A. V., Lam, M. S., Sethi, R., & Ullman, J. D. (1998). Compilers: Principles, Techniques, and Tools. Pearson Education, Inc.

[ANTL,09] ANTLR v3. (11 de Marzo de 2009). Grammar List. Recuperado el 6 de Julio de 2011, de ANTLR v3: http://www.antlr.org/grammar/list

[ANTL,10] ANTLR v3. (22 de Diciembre de 2010). Recuperado el 23 de Junio de 2011, de http://www.antlr.org/: http://www.antlr.org/

[AVER,01] Aversano, L., Canfora, G., Cimitile, A., & De Lucia, A. (15 de Marzo de 2001). Migrating Legacy Systems to the Web: An Experience Report. Recuperado el 14 de Noviembre de 2010, de IEEE Xplore: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=914979

[BODH,02] Bodhuin, T., Guardabascio, E., & Tortorella, M. (2002). Migrating COBOL Systems to the WEB by using MVC Design Pattern. Ninth Working Conference on Reverse Engineering (págs. 329-338). Richmond, VA, USA: IEEE CS Press.

[BOOD,06] Boodhoo, J.-P. (Agosto de 2006). Model View Presenter. Recuperado el 2 de Diciembre de 2011, de MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

[BOSC,97] Bosch, J., Molin, P., Mattsson, M., & Bengtsson, P. (1997). Object-Oriented Frameworks - Problems & Experiences. Sweden: Department of Computer Science and Business Administration, University of Karlskrona/Ronneby.

[BUNG,11] Bungee Connect. (2011). Bungee Connect and Model-View-Adapter (MVA). Recuperado el 04 de Diciembre de 2011, de Bungee Connect: http://www.bungeeconnect.com/img/whitepaper-mva_090803.pdf

[BUST,03] Bustamante, L. C. (2003). Reestructuración de código legado a partir del comportamiento para la generación de componentes reutilizables. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.

[CUNN,05] Cunningham & Cunningham, Inc. (31 de Mayo de 2005). Model Delegate. Recuperado el 4 de Diciembre de 2011, de Cunningham & Cunningham, Inc.: http://c2.com/cgi/wiki?ModelDelegate

[DEIT,08] Deitel, P. J., & Deitel, H. M. (2008). Cómo programar en Java. Naucalpan de Juárez, Estado de México, México: Pearson Educación.

Bibliografía

98

[DIRE,11] Dirección General de Educación Superior Tecnológica . (Septiembre de 2011). Traductores y Compiladores. Recuperado el 06 de Diciembre de 2011, de Instituto Tecnológico de Celaya: http://www.iqcelaya.itc.mx/~vicente/Programacion/TradComp.pdf

[DIST,06] Distante, D., Tilley, S., & Canfora, G. (2006). Towards a Holistic Approach to Redesigning Legacy Applications for the Web with UWAT+. 10th Conference on Software Maintenance and Reengineering (págs. 295-299). Bari, Italy: IEEE CS Press.

[FAYA,97] Fayad, M. E., & Schmidt, D. C. (10 de Octubre de 1997). Object-Oriented Application Frameworks. Special Issue on Object-Oriented. Communications of the ACM.

[FAYA,00] Fayad, M. E., & Jhonson, R. E. (2000). Domain-Specific Application Frameworks: Frameworks Experience by Industy. (M. Spencer, Ed.) New York: Jhon Wiley & Sons, Inc.

[FOWL,99] Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refactoring: Improving the Design of Existing Code. Addison Wesley.

[GOSL,05] Gosling, J., Joy, B., Steele, G., & Bracha, G. (2005). The Java™ Language Specification. Santa Clara, California, U.S.A.: Addison-Wesley.

[GULZ,02] Gulzar, N. (4 de Noviembre de 2002). Fast Track to Struts: What id Does and How. Recuperado el 18 de Febrero de 2010, de TheServerSide.com: http://www.theserverside.com/

[HERN,03] Hernandez Moreno, L. A. (2003). Factorización de funciones hacia métodos de plantilla. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.

[MEND,04] Mendez, M. A. (2004). Reestructuración de software escrito por procedimientos conducido por patrones de diseño composicionales. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.

[NUÑE,08] Nuñez Ortega, E. L. (2008). Definición de método heurísticos para reestructura marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.

[PARR,07] Parr, T. (2007). The Definitive ANTLR Reference. Dallas, Texas: The Pragmatic Programmers.

[PILL,06] Pillay, A. (Diciembre de 2006). Object Oriented Programming using Java. Notes for the Computer Science Module Object Oriented Programming COMP200. Durban, Sudáfrica: University of KwaZulu-Natal.

[PING,04] Ping, Y., Kostas, K., & Lau, T. C. (2004). Transforming Legacy Web Applications to

Bibliografía

99

the MVC Architecture. 11th Annual International Workshop on Software Technology and Engineering Practice (págs. 133-142). Chicago, IL, USA: IEEE CS Press. Sicilia, M. Á. (9 de Enero de 2009). ¿Qué es Reestructuración del Software? Recuperado el 23 de Septiembre de 2011, de Connexions: http://cnx.org/content/m17443/latest/

[SIML,09] Simler, K. (20 de Abril de 2009). Model-View-Adapter. Recuperado el 1 de Diciembre de 2011, de Palantir TechBlog: http://blog.palantir.com/2009/04/20/model-view-adapter/

[SMIT,09] Smith, J. (Febrero de 2009). WPF Apps With The Model-View-ViewModel Design Pattern. Recuperado el 3 de Diciembre de 2011, de MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

[SOFT,98] Software & Systems Engineering Standards Committee . (1998). IEEE Standard for Software Test Documentation. IEEE Computer Society .

[W3C,10] W3C. (06 de Mayo de 2010). Guía Breve de Servicios Web. Recuperado el 06 de Septiembre de 2010, de W3C World Wide Web Consortium: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb

Anexo A: Métodos de Reestructura

101


En este anexo se presentan los pasos a seguir para los métodos R1: “Analizar código legado”, R2:

“Crear clases”, R3: “Crear constructor”, R4: “Crear funciones”, R5: “Reubicar atributos” y R7:

“Estructura jerárquica de clases”.

Método de reestructura R1: “Analizar código legado”

1. Inicio.

2. Inicializar variables:

e ” “, paquete ” “, nomclase ” “

3. Abrir la tabla “Tipos de estatutos”.

4. Crear la tabla “Tipos de clases” con los siguientes campos:

Nombre, Paquete, Tipo, Tipo_relación1, Clase_base1, Tipo_relación2, Clase_Base2, Patrón_MVC

5. Crear la tabla “Funciones abstractas” con los siguientes campos:

Firma, Tipo_retorno, Clase, Patrón_MVC

6. Crear la tabla “Funciones concretas” con los siguientes campos:

Firma, Tipo_retorno, Variable de retorno, Clase, Patrón_MVC

7. Crear la tabla “Tipos de Variables” con los siguientes campos:

Identificador, Tipo, Especificador, Clase_variable, FirmaFunción, Clase_Función

8. Abrir la carpeta que contiene todos los archivos del código legado del marco orientado a objetos a analizar.

9. Mientras haya archivos para analizar en la carpeta:

mientras(not carpeta vacía)haz

9.1. Inicializar los contadores:

cm 0, cv 0, cc 0, cFa 0, cFMZ 0, cFM 0, cFC 0, cFV 0

9.2. Abrir un archivo de la carpeta.

9.3. Mientras no sea fin del archivo:


102

mientras(not EOF)haz

9.3.1. Leer un estatuto

e estatuto

9.3.2. Mientras no sea fin de la clase:

mientras(e≠})haz

9.3.2.1. Si el estatuto es una sentencia “import”:

si(e==E1)entonces

9.3.2.1.1. Etiquetar el estatuto con la etiqueta “Im” (importación de archivos):

estatuto estatuto+”//Im”

fin_si //(9.3.2.1)

9.3.2.2. Si el estatuto es una sentencia “package” (definición de paquete): si(e==E2)entonces

9.3.2.2.1. Guardar el nombre del paquete: paquete nombre del paquete al que pertenece la clase

fin_si //(9.3.2.2) 9.3.2.3. Si el estatuto es una definición de clase:

si(e==E3∨e==E4∨e==E5)entonces

9.3.2.3.1. Si la clase no pertenece a algún paquete:

si(paquete==” “)entonces

9.3.2.3.1.1. Definir el nombre del paquete al que pertenece la clase:

paquete nombre del paquete

fin_si //(9.3.2.3.1)

9.3.2.3.2. Llenar la tabla “Tipos de clases” con los siguientes datos de la clase:

nombre de la clase, paquete, tipo de la clase, cláusula de relación1, clase_base1, cláusula de relación2, clase_base2

9.3.2.3.3. Asignar el nombre de la clase a la variable nomclase:

nomclase nombre de la clase en estudio

fin_si //(9.3.2.3)

9.3.2.4. Si el estatuto es una declaración de atributos (variables de instancia) o un estatuto de declaración de objetos:

si(e==E6⋁e==E15)entonces

9.3.2.4.1. Abrir la tabla “Tipos de Variables”.

9.3.2.4.2. Llenar el registro de la tabla con los datos:

Identificador de la variable, tipo de la variable, especificador de acceso, nombre de la clase a la que pertenece la variable.

9.3.2.4.3. Cerrar la tabla “Tipos de Variables”.

fin_si //(9.3.2.4)

9.3.2.5. Si el estatuto es una declaración de un método abstracto:

si(e==E16)entonces

9.3.2.5.1. Llenar los campos “Firma”, “Tipo_retorno” y “Clase”, de la tabla “Funciones abstractas”, con los siguientes datos de la función:

firma de la función, tipo de retorno de la función, nomclase

9.3.2.5.2. Escribir “Sin definir” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones abstractas”.

9.3.2.5.3. Incrementar el contador de funciones abstractas:

cFa cFa+1

fin_si //(9.3.2.5)

9.3.2.6. Si el estatuto es una definición de constructores:

si(e==E7∨e==E8)entonces

9.3.2.6.1. Obtener la firma del constructor:

firma firma del constructor


103

9.3.2.6.2. Etiquetar el estatuto con la etiqueta “C” (constructor):

estatuto estatuto+”//C”

9.3.2.6.3. Recorrer el cuerpo de sentencias del constructor:

do{

9.3.2.6.3.1. Leer el siguiente estatuto del cuerpo del constructor:

e sig.estatuto

9.3.2.6.3.2. Si el estatuto es una asignación para inicializar atributos:

si(e==E12⋁e==E12+E18)entonces

9.3.2.6.3.2.1. Obtener el identificador del atributo:

identificador identificador de la variable

9.3.2.6.3.2.2. Inicializar el valor de la variable i:

i 0

9.3.2.6.3.2.3. Abrir la tabla “Tipos de variables”.

9.3.2.6.3.2.4. Buscar los datos del atributo inicializado en el constructor:

mientras(Tipos de variables[i].Identificador≠identificador⋀Tipos de variables[i].Clase≠nomclase)haz

9.3.2.6.3.2.4.1. Si el atributo ya está registrado en la tabla:

si(Tipos de variables[i].Identificador==identificador⋀Tipos de variables[i].Clase==nomclase)entonces

9.3.2.6.3.2.4.1.1. Obtener los datos del atributo:

tipo Tipos de Variables[i].Tipo

especificador Tipos de Variables[i].Especificador

9.3.2.6.3.2.4.1.2. Si el constructor es la primera función que utiliza el atributo:

si(Tipos de variables[i].Firma_función==” “)entonces

9.3.2.6.2.2.5.1.1.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor:

Tipos de variables[i].Firma_función firma

Tipos de variables[i].Clase_Función nomclase

si no

9.3.2.6.2.2.5.1.1.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor con los datos:

identificador, tipo, especificador, clase de la variable, firma, nomclase

fin_si //(9.3.2.6.3.2.4.1.2)

si no

9.3.2.6.3.2.4.1.3. Incrementar el valor de la variable i:

i i+1

fin_si //(9.3.2.6.3.2.4.1)

fin_mientras //(9.3.2.6.3.2.4)

fin_si //(9.3.2.6.3.2)

9.3.2.6.3.3. Si el estatuto es una asignación por medio de una llamada a un método o una llamada al constructor de la clase base:

si(e==E12+E18∨e==E18)entonces

9.3.2.6.3.3.1. Etiquetar el estatuto con la etiqueta “EI” (estatuto de invocación):

estatuto estatuto+”//EI”

fin_si //(9.3.2.6.3.3)

}while(e≠}) //(9.3.2.6.3)


104

9.3.2.6.4. Si el estatuto es una llave de fin de método:

si(e==})entonces

9.3.2.6.4.1. Etiquetar el estatuto con la etiqueta “ff” (fin de función):

estatuto estatuto+”//ff”

fin_si //(9.3.2.6.4)

fin_si //(9.3.2.6)

9.3.2.7. Si el estatuto es una definición de métodos:


9.3.2.7.1. Llenar la tabla “Funciones concretas” con los siguientes datos de la función:

firma de la función, tipo de retorno, nomclase

9.3.2.7.2. Recorrer el cuerpo de sentencias del método:

mientras(e≠})haz

9.3.2.7.2.1. Leer el siguiente estatuto:

e siguiente estatuto

9.3.2.7.2.2. Si el estatuto es una declaración de variables locales, o una asignación, o un estatuto de repetición, o un estatuto de impresión, o un estatuto condicional, o un estatuto de invocación, o un estatuto selectivo, o un estatuto de devolución, o un estatuto de bloque:

si(e==E11⋁e==E12⋁e==E13⋁e==E14⋁e==E15⋁e==E17∨e==E18∨e==E19∨e==E20∨e==E21)

9.3.2.7.2.2.1. Si el estatuto es una asignación:


9.3.2.7.2.2.1.1. Obtener el identificador de la variable modificada en el estatuto de asignación:

identificador identificador de la variable del estatuto de asignación

9.3.2.7.2.2.1.2. Obtener la firma de la función:

firma firma de la función en estudio

9.3.2.7.2.2.1.3. Inicializar el valor de la variable i:

i 0

9.3.2.7.2.2.1.4. Abrir la tabla “Tipos de variables”.

9.3.2.7.2.2.1.5. Buscar los datos de la variable modificada en el estatuto de asignación:

mientras(Tipos de variables[i].Identificador≠identificador⋀Tipos de variables[i].Clase≠nomclase)haz

9.3.2.7.2.2.1.5.1. Si la variable ya está registrado en la tabla:

si(Tipos de variables[i].Identificador==identificador⋀Tipos de variables[i].Clase==nomclase)entonces

9.3.2.7.2.2.1.5.1.1 Obtener los datos de la variable:



9.3.2.7.2.2.1.5.1.2 Si la función es la primera que accede a la variable:

si(Tipos de variables[i].FirmaFunción==” “)entonces

9.3.2.7.2.2.1.5.1.2.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor:

Tipos de variables[i] firma

si no


105

9.3.2.7.2.2.1.5.1.2.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde a la variable modificada en el estatuto de asignación con los datos:

identificador, tipo, especificador, nomclase, firma

fin_si //(9.3.2.7.2.2.1.5.1.2)

si no

9.3.2.7.2.2.1.5.1.3 Incrementar el valor de la variable i:

i i+1

fin_si //(9.3.2.7.2.2.1.5.1)

fin_mientras //(9.3.2.7.2.2.1.5)

fin_si //(9.3.2.7.2.2.1)

9.3.2.7.2.2.2. Si el estatuto pertenece al Modelo:

si(e pertenece al modelo)entonces

9.3.2.7.2.2.2.1. Etiquetar el estatuto con la etiqueta “//EM” (estatuto del modelo):

estatuto estatuto+”//EM”

9.3.2.7.2.2.2.2. Incrementar el contador de estatutos del modelo:

cm cm+1

fin_si //(9.3.2.7.2.2.2)

9.3.2.7.2.2.3. Si el estatuto pertenece al Control:

si(e pertenece al control)entonces

9.3.2.7.2.2.3.1. Etiquetar el estatuto con la etiqueta “//EC” (estatuto del control):

estatuto estatuto+”//EC”

9.3.2.7.2.2.3.2. Incrementar el contador de estatutos del control:

cc cc+1

fin_si //(9.3.2.7.2.2.3)

9.3.2.7.2.2.4. Si el estatuto pertenece a la Vista:

si(e pertenece a la vista)entonces

9.3.2.7.2.2.4.1. Etiquetar el estatuto con la etiqueta “//EV” (estatuto de la vista):

estatuto estatuto+”//EV”

9.3.2.7.2.2.4.2. Incrementar el contador de estatutos de la vista:

cv cv+1

fin_si //(9.3.2.7.2.2.4)

9.3.2.7.2.2.5. Si el estatuto es una asignación por medio de una llamada a un método, o si es una llamada a un método:

si(e==E18∨e==E12+E18)entonces

9.3.2.7.2.2.5.1. Etiquetar el estatuto con la etiqueta “//EI” (estatuto de invocación):


fin_si //(9.3.2.7.2.2.5)

9.3.2.7.2.2.6. Si el estatuto es un bloque de repetición o condicional, o es un estatuto selectivo, o es un estatuto de bloque:

si(e==E13+”{“∨e==E17+”{“∨e==E19∨e==E21)entonces

9.3.2.7.2.2.6.1. Recorrer el cuerpo de sentencias del bloque:

mientras(e≠})haz

9.3.2.7.2.2.6.1.1. Si el estatuto es una asignación:


9.3.2.7.2.2.6.1.1.1 Obtener el identificador de la variable modificada en el estatuto de asignación:


106

identificador identificador de la variable del estatuto de asignación

9.3.2.7.2.2.6.1.1.2 Obtener la firma de la función:

firma firma de la función en estudio

9.3.2.7.2.2.6.1.1.3 Inicializar el valor de la variable i:

i 0

9.3.2.7.2.2.6.1.1.4 Abrir la tabla “Tipos de variables”.

9.3.2.7.2.2.6.1.1.5 Buscar los datos de la variable modificada en el estatuto de asignación:

mientras(Tipos de variables[i].Identificador≠identificador

⋀Tipos de variables[i].Clase≠nomclase)haz

9.3.2.7.2.2.6.1.1.5.1 Si la variable ya está registrado en la tabla:

si(Tipos de variables[i].Identificador==identificador

⋀Tipos de variables[i].Clase==nomclase)entonces

9.3.2.7.2.2.6.1.1.5.1.1 Obtener los datos de la variable:



9.3.2.7.2.2.6.1.1.5.1.2 Si la función es la primera que accede a la variable:

si(Tipos de variables[i].FirmaFunción==” “)entonces

9.3.2.7.2.2.6.1.1.5.1.2.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor:

Tipos de variables[i] firma

si no

9.3.2.7.2.2.6.1.1.5.1.2.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde a la variable modificada en el estatuto de asignación con los datos:

identificador, tipo, especificador, nomclase, firma

fin_si //(9.3.2.7.2.2.6.1.1.5.1.2)

si no

9.3.2.7.2.2.6.1.1.5.1.3 Incrementar el valor de la variable i:

i i+1

fin_si //(9.3.2.7.2.2.6.1.1.5.1)

fin_mientras //(9.3.2.7.2.2.6.1.1.5)

fin_si //(9.3.2.7.2.2.6.1.1)

9.3.2.7.2.2.6.1.2. Si el estatuto pertenece al Modelo:

si(e pertenece al modelo)entonces

9.3.2.7.2.2.6.1.2.1 Etiquetar el estatuto con la etiqueta “//EM” (estatuto del modelo):

estatuto estatuto+”//EM”

9.3.2.7.2.2.6.1.2.2 Incrementar el contador de estatutos del modelo:

cm cm+1

fin_si //(9.3.2.7.2.2.6.1.2)

9.3.2.7.2.2.6.1.3. Si el estatuto pertenece al Control: si(e pertenece al control)entonces


107

9.3.2.7.2.2.6.1.3.1 Etiquetar el estatuto con la etiqueta “//EC” (estatuto del control):

estatuto estatuto+”//EC”

9.3.2.7.2.2.6.1.3.2 Incrementar el contador de estatutos del control:

cc cc+1

fin_si //(9.3.2.7.2.2.6.1.3)

9.3.2.7.2.2.6.1.4. Si el estatuto pertenece a la Vista:

si(e pertenece a la vista)entonces

9.3.2.7.2.2.6.1.4.1 Etiquetar el estatuto con la etiqueta “//EV” (estatuto de la Vista):

estatuto estatuto+”//EV”

9.3.2.7.2.2.6.1.4.2 Incrementar el contador de estatutos de la vista:

cv cv+1

fin_si //(9.3.2.7.2.2.6.1.4)

9.3.2.7.2.2.6.1.5. Si el estatuto es una asignación por medio de una llamada a un método, o es una llamada a un método:

si(e==E18∨e==E12+E18)entonces

9.3.2.7.2.2.6.1.5.1 Etiquetar el estatuto con la etiqueta “//EI” (estatuto de invocación):


fin_si //(9.3.2.7.2.2.6.1.5)

9.3.2.7.2.2.6.1.6. Leer el siguiente estatuto: e siguiente estatuto

fin_mientras //(9.3.2.7.2.2.6.1)

9.3.2.7.2.2.6.2. Si el estatuto es una llave de fin de bloque:

si(e==})entonces

9.3.2.7.2.2.6.2.1. Etiquetar el estatuto con la etiqueta “//fe” (fin de estatuto de bloque):

estatuto estatuto+”//fe”

fin_si //(9.3.2.7.2.2.6.2)

fin_si //(9.3.2.7.2.2.6)

fin_si //(9.3.2.7.2.2)

fin_mientras //(9.3.2.7.2)

9.3.2.7.3. Si el estatuto es una llave de fin de método:

si(e==})entonces

9.3.2.7.3.1. Etiquetar el estatuto con la etiqueta “//ff” (fin de función):

estatuto estatuto+”//ff”

9.3.2.7.3.2. Si la función es no-especializada:

si(cm≠0⋀cc≠0⋀cv≠0||cm==0⋀cc≠0⋀cv≠0||cm≠0⋀cc==0⋀cv≠0||cm≠0⋀cc≠0

⋀cv==0)entonces

9.3.2.7.3.2.1. Etiquetar la función con la etiqueta “//FMZ” (función no-especializada)

9.3.2.7.3.2.2. Escribir “No especializada” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.

9.3.2.7.3.2.3. Incrementar el contador de funciones no especializadas:

cFMZ cFMZ+1

9.3.2.7.3.2.4. Inicializar los contadores:

cm 0, cv 0, cc 0


108

9.3.2.7.3.3. Si la función es especializada:

si no

9.3.2.7.3.3.1. Si la función es del Modelo:

si(cm≠0⋀cc==0⋀cv==0)entonces

9.3.2.7.3.3.1.1. Etiquetar función con la etiqueta “//FM” (función del modelo).

9.3.2.7.3.3.1.2. Escribir “Modelo” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.

9.3.2.7.3.3.1.3. Incrementar el contador de funciones del modelo:

cFM cFM+1

9.3.2.7.3.3.1.4. Inicializar el contador de estatutos del modelo:

cm 0

9.3.2.7.3.3.2. Si la función no es del modelo:

si no

9.3.2.7.3.3.2.1. Si la función es del control:

si(cm==0⋀cc≠0⋀cv==0)entonces

9.3.2.7.3.3.2.1.1. Etiquetar la función con “//FC”.

9.3.2.7.3.3.2.1.2. Escribir “Control” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.

9.3.2.7.3.3.2.1.3. Incrementar el contador de funciones del control:

cFC cFC+1

9.3.2.7.3.3.2.1.4. Inicializar el contador de estatutos del control:

cc 0

9.3.2.7.3.3.2.2. Si la función no es del control:

si no

9.3.2.7.3.3.2.2.1. Si la función es de la vista:

si(cm==0⋀cc==0⋀cv≠0)entonces

7.3.2.5.3.3.2.2.1.1. Etiquetar la función con “//FV”

7.3.2.5.3.3.2.2.1.2. Escribir “Vista” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.

7.3.2.5.3.3.2.2.1.3. Incrementar el contador de funciones de la vista:

cFV cFV+1

7.3.2.5.3.3.2.2.1.4. Inicializar el contador de estatutos de la vista:

ce 0, cv 0

fin_si //(9.3.2.7.3.3.2.2.1)

fin_si //(9.3.2.7.3.3.2.1)

fin_si //(9.3.2.7.3.3.1)

fin_si //(9.3.2.7.3.2)

fin_si //(9.3.2.7.3)

fin_si //(9.3.2.7)

9.3.2.8. Leer el siguiente estatuto:

e sig.estatuto

fin_mientras //(9.3.2)

9.3.3. Si el estatuto es una llave de fin de clase:

si(e==})entonces


109

9.3.3.1. Etiquetar el estatuto con la etiqueta “fc” (fin de clase):

estatuto estatuto+”//fc”

9.3.3.2. Si la clase en estudio es abstracta: si(cFa≠0)entonces

9.3.3.2.1. Escribir “Sin definir” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.

fin_si //(9.3.3.2) 9.3.3.3. Si la clase en estudio es no-especializada:

si((cFMZ≠0)⋁(cFM≠0⋀(cFC≠0∨cFV≠0)))entonces

9.3.3.3.1. Etiquetar la clase con la etiqueta “//CMZ” (clase no-especializada).

9.3.3.3.2. Escribir “No especializada” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.

9.3.3.4. Si la clase en estudio es especializada:

si no

9.3.3.4.1. Si la clase en estudio es del Modelo:

si(cFMZ==0⋀cFM≠0⋀cFC==0⋀cFV==0)entonces

9.3.3.4.1.1. Etiquetar la clase con la etiqueta “//CM” (clase del modelo).

9.3.3.4.1.2. Escribir “Modelo” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.

si no

9.3.3.4.1.3. Si la clase en estudio es del Control:

si(cFMZ==0⋀cFM==0⋀cFC≠0⋀cFV==0)entonces

9.3.3.4.1.3.1. Etiquetar la clase con la etiqueta “//CC” (clase del control).

9.3.3.4.1.3.2. Escribir “Control” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.

si no

9.3.3.4.1.3.3. Si la clase en estudio es de la Vista:

si(cFMZ==0⋀cFM==0⋀cFC==0⋀cFV≠0)entonces

9.3.3.4.1.3.3.1. Etiquetar la clase con la etiqueta “//CV” (clase de la vista).

9.3.3.4.1.3.3.2. Escribir “Vista” en el campo “Patrón _MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.

fin_si //(9.3.3.4.1.3.3)

fin_si //(9.3.3.4.1.3)

fin_si //(9.3.3.4.1)

fin_si //(9.3.3.3)

fin_si //(9.3.3)

fin_mientras //(9.3)

fin_mientras //(9)

10. Inicializar las variables:

i 0, j 0, Clases[] ” “, nomclase ” “, patron ” “, firma ” “, numreg 0, band ”“

11. Abrir la tabla “Funciones concretas”.

12. Recorrer la tabla:

mientras(not EOF(Funciones concretas))haz

12.1. Obtener los datos de una función concreta:

firma Funciones concretas[i].Firma

nomclase Funciones concretas[i].Clase


110

patron Funciones concretas[i].Patrón_MVC

12.2. Inicializar la variable k:

k 0

12.3. Abrir la tabla “Tipos de clases”.

12.4. Recorrer la tabla “Tipos de clases”:

mientras(nomclase≠” “)haz

12.4.1. Buscar la jerarquía de clases a la que pertenece la función concreta en estudio:

si(Tipos de clases[j].Nombre==nomclase)entonces

12.4.1.1. Verificar si la clase extiende o implementa a una clase base:

si(Tipos de clases[j].Clase_base1≠” “)entonces

12.4.1.1.1. Almacenar en un arreglo la jerarquía de clases a la que pertenece la función concreta en estudio:

Clases[k] Tipos de clases[j].Clase_base1

12.4.1.1.2. Obtener la siguiente clase base de la jerarquía de clases:

nomclase Tipos de clases[j].Clase_base1

12.4.1.1.3. Actualizar las variable k y j:

k k+1

j 0

12.4.1.2. Si la clase no extiende o implementa a una clase base: si no

12.4.1.2.1. Inicializar la variable nomclase: nomclase ” “

fin_si //(12.4.1.1)

12.4.2. Si la clase registrada en la tabla no pertenece a la jerarquía de clases de la función concreta en estudio:

si no

12.4.2.1. Incrementar el valor de la variable j:

j j+1

fin_si //(12.4.1)


12.5. Inicializar variables:

numreg sizeof(Clases), j 0, k 0

12.6. Recorrer la jerarquía de clases a la que pertenece la función concreta en estudio:

mientras(k<numreg)haz

12.6.1. Obtener una clase del arreglo que almacena la jerarquía de clases:

nomclase Clases[k]

12.6.2. Limpiar la casilla del arreglo:

Clases[k] ” “

12.6.3. Actualizar las variables k y band:

k k+1, band false

12.6.4. Abrir la tabla “Funciones abstractas”.

12.6.5. Recorrer la tabla:

mientras(band==false)entonces

12.6.5.1. Buscar la función abstracta que implementa la función concreta en estudio:

si(Funciones abstractas[j].Firma==firma⋀Funciones abstractas[j].Clase==nomclase)entonces

12.6.5.1.1. Verificar si la función abstracta no ha sido etiquetada previamente:

si(Funciones abstractas[j].Patron_MVC==”Sin definir“)entonces

12.6.5.1.1.1. Etiquetar la función abstracta, de acuerdo a la parte del patrón MVC a la que pertenece la función concreta que la implementa:


111

Funciones abstractas[j].Patrón_MVC patron

12.6.5.1.1.2. Abrir el archivo <nomclase>.java y etiquetar el código de la declaración de la función abstracta, con la etiqueta correspondiente a la parte del patrón MVC al que pertenece.

fin_si //(12.6.5.1.1)

12.6.5.1.2. Modificar el valor de las variables band y j:

band true, j 0

12.6.5.2. Si la firma y la clase de pertenencia de la función registrada en la tabla no corresponden con la firma y la clase buscadas:

si no

12.6.5.2.1. Incrementar el valor de la variable j para continuar la búsqueda:

j j+1

fin_si //(12.6.5.1)



12.7. Incrementar el valor de la variable i:

i i+1

fin_mientras //(12)


i 0, j 0, cFMZ 0, cFM 0, cFV 0, cFC 0, nomclase ” “

14. Abrir la tabla “Funciones abstractas”.


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:


112

j j+1


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).


113

fin_si //(15.4.4.1.1)

15.4.4.1.2. Modificar el valor de la variable band:

band true

si no

15.4.4.1.3. Incrementar el valor de la variable k:

k k+1

fin_si //(15.4.4.1)


15.4.5. Modificar el valor de la variable i:

i j

fin_si //(15.4)

fin_mientras //(15)

16. Termina el método de reestructura R1.

Método de reestructura R7: “Estructura jerárquica de clases”

Parámetros de entrada: ninguno

1. Inicio.

2. Crear la tabla “Jerarquía de clases” con los siguientes campos:

Clase_padre, Clase_hija


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)


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”:


114

Jerarquía de clases[k].Clase_padre clasepadre

Jerarquía de clases[k].Clase_hija Tipos de clases[i].Nomb_clase

5.3.1.3. Incrementar la variable k:

k k+1

fin_si //(5.3.1)

5.3.2. Incrementar el valor de la variable i:

i i+1


5.4. Si la clase padre no tiene subclases:

si((EOF(Tipos de clases)⋀(band==false))entonces

5.4.1. Registrar los datos de la clase en la tabla “Jerarquía de clases”:

Jerarquía de clases[k].Clase_padre clasepadre

Jerarquía de clases[k].Clase_hija ”Sin subclases”

5.4.2. Incrementar la variable k:

k k+1

fin_si //(5.4)

5.5. Obtener la siguiente clase padre:

haz

5.5.1. Verificar que la clase candidata sea una subclase:

si(Jerarquía de clases[h].Clase_hija≠”Sin subclases”)

5.5.1.1. Asignar a la subclase como siguiente clase padre:

clasepadre Jerarquía de clases[h].Clase_hija

5.5.1.2. Inicializar las variables j y band:

j 0, band false

5.5.1.3. Verificar que la nueva clase padre no se encuentre en la tabla

“Jerarquía de clases” como clase padre:

mientras((j<k)⋁(band==false))haz

5.5.1.3.1. Si la nueva clase padre se encuentra en la tabla “Jerarquía de

clases” como clase base:

si(Jerarquía de clases[j].Clase_padre==clasepadre)entonces

5.5.1.3.1.1. Cambiar el valor de la variable band:

band true

5.5.1.3.1.2. Incrementar el valor de la variable h:

h h+1

si no

5.5.1.3.1.3. Incrementar el valor de la variable j:

j j+1

fin_si //(5.5.1.3.1)

fin_mientras //(5.5.1.3)

5.5.1.4. Si la nueva clase padre no se encuentra en la tabla “Jerarquía de

clases” como clase base(padre?):

si((j==k)⋀(band==false))entonces

5.5.1.4.1. Incrementar la variable h:

h h+1

5.5.1.4.2. Inicializar el valor de la variable i:

i 0


115

fin_si //(5.5.1.4)

fin_si //(5.5.1)

mientras(band==true) //(5.5)

fin_mientras //(5)


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


public class <nomclase> extends <clasebase1>{

fin_si //(6.1.2)

6.1.3. Si la clase implementa una interfaz: si(tiporel==”implements”)entonces


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


public class <nomclase> extends <clasebase1> implements <clasebase2>{

fin_si //(6.1.4)

fin_si //(6.1)

6.2. Si es una clase abstracta:


116

si(tipo==”abstracta”)entonces

6.2.1. Si es una clase simple:

si(tiporel==” “)entonces


public abstract class <nomclase>{

fin_si //(6.2.1)

6.2.2. Si la clase es derivada de otra: si(tiporel==”extends”)entonces


public abstract class <nomclase> extends <clasebase1>{

fin_si //(6.2.2)

6.2.3. Si esta clase implementa una interfaz: si(tiporel==”implements”)entonces


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


public interface <nomclase>{

fin_si //(6.3.1)

6.3.2. Si es una interfaz derivada de otra: si(tiporel==”extends”)entonces


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:


117

dato=dígito.dígito;

2.1.4. Si el dato a inicializar en el constructor es de tipo char, entonces generar el siguiente código:

dato=’caracter’;

2.1.5. Si el dato a inicializar en el constructor es de tipo String, entonces generar el siguiente código:

dato=”cadena de caracteres”;

2.1.6. Si el dato a inicializar en el constructor es un objeto, entonces generar el siguiente código:

Clase obj=referencia;

2.2. Si el constructor crea objetos, generar el siguiente código:

this.obj=new <objparm[n]+”()”>;

2.3. Cerrar la definición del constructor de manera apropiada, generando el siguiente código:

} //Termina el constructor <claseMVA>

2.4. Si se desea crear otro constructor entonces ir al paso 1, si no, ir al paso 4.

3. Si el constructor es un constructor con parámetros, generar el siguiente código:

public claseMVA(<parametros[0][0] parametros[0][1]>, …, <parametros[n][0] parametros[n][1]>){

3.1. Para cada atributo declarado en la definición de la clase:

3.1.1. Si el nombre de los datos definidos en la firma del constructor son iguales a los nombres de los datos correspondientes a los atributos declarados en la definición de la clase, entonces generar el siguiente código:

this.dato1=<parametros[0][1]>;

…

this.datoN=<parametros[n][1]>;

3.1.2. Si el nombre de los datos definidos en la firma del constructor son diferentes a los nombres de los datos correspondientes a los atributos declarados en la definición de la clase, entonces generar el siguiente código:

datoAtributo1=<parametros[0][1]>;

…

datoAtributoN=<parametros[n][1]>;

3.2. Si el constructor crea objetos, generar el siguiente código:

this.obj=new <parametros[0][0]>(<parametros[0][1] parámetros[0][2]>, …, <parametros[n][1] parametros[n][2]>);

o this.obj=new tipo[param1];

o this.vec=new tipo[param1][param2];

3.2.1. Si el constructor de una subclase invoca explícitamente al constructor de la superclase, entonces generar el siguiente código:

public <parametros[0][0]>(<parametros[0][1] parámetros[0][2]>, …, <parametros[n][1]

parametros[n][2]>){

3.2.1.1. Agregar la invocación al constructor de la superclase:

super(<parametros[0][2]>, …, <parametros[n][2]>);

3.2.1.2. Si el constructor de la subclase tiene más operaciones, añadir las líneas de asignaciones:

dato=datoN+1; o

asignarDato(datoN+1); 3.3. Cerrar la definición del constructor de manera apropiada, generando el siguiente código:

} //Termina el constructor <claseMVA>

3.4. Si se desea crear otro constructor, ir al paso 1, si no ir al paso 5.


118

4. Si el constructor es una copia del constructor de la clase original (constructores de clases especializadas) entonces:

4.1. Abrir el archivo con extensión <nomclase>.java que contiene el código de la clase del marco orientado a objetos original.

4.2. Leer el primer estatuto y su etiqueta:

e←estatuto

etiqueta←etiqueta del estatuto

4.3. Recorrer el archivo para identificar el código del constructor:

mientras(e≠”}“∧etiqueta≠”//fc”)

4.3.1. Si el estatuto define a un constructor:


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


4.4. Si se desea crear otro constructor, ir al paso 1, si no ir al paso 5.


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”.


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:


119

identificador←Variables MVA[i].Identificador

4.1.3.4. Formar el estatuto de declaración de atributos:

e←especificador+tipo+identificador+”;”

4.1.3.5. Escribir el estatuto de declaración de atributos e en el archivo

<nomclaseMVA>.java

4.1.3.6. Incrementar el valor de la variable i:

i←i+1


si no

4.1.4. Incrementar el valor de la variable i:

i←i+1

fin_si //(4.1)

fin_mientras //(4)


Método de reestructura R4: “Crear funciones”

Parámetros de entrada: firma, especificador, tiporet, valret, nomclaseMVA, patron

1. Inicio


parm ”()”, parametros false, n 0, i 0, identificador ” “, lista ” “, listaparm ” “

3. Abrir el archivo que contiene el código de la clase MVA:

Abrir <nomclaseMVA>.java

4. Verificar si la función recibe parámetros:

parametros firma.contains(parm)

5. Si la función no recibe parámetros:

si(parametros==true)entonces

5.1. Generar el estatuto de definición de la función:

e especificador+tiporet+firma+”{“

5.2. Escribir el estatuto de definición de la función e en el archivo

<nomclaseMVA>.java

5.3. Si la función pertenece a la Vista:

si(patron==”Vista”)entonces

5.3.1. Abrir el vector vVista.

5.3.2. Obtener el número total de elementos en el vector vVista:

n length(vVista)

5.3.3. Leer el vector vVista:

mientras(i<n)haz

5.3.3.1. Obtener el elemento i del vector vVista:

e vVista[i]

5.3.3.2. Escribir el estatuto e en el archivo <nomclaseMVA>.java


i i+1


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]


120



i i+1


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]



i i+1


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]



i i+1


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]




121

i i+1


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]



i i+1


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”.


Anexo B: Descripción de los Casos de Prueba

123

Anexo B: Descripción de los

Casos de Prueba

En este anexo se describen los datos de entrada y los resultados esperados para cada uno de los

caso de prueba que se ejecutaron para evaluar el correcto funcionamiento de los métodos R1:


“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.


124

Figura 34. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 1)


125

Figura 35. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 2)

Figura 36. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEquilatero.java


126

Figura 37. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEscaleno.java

Figura 38. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloIsoceles.java

o Y las tablas “Tipos de variables”, “Funciones concretas”, “Funciones abstractas” y “Tipos de clase”,

dichas tablas se muestra en las siguientes tablas:


127

Tabla 12. Resultados del MOO2MVA-CP-01: Tabla Tipos de Variables

Identificador Tipo Especificador Clase_Variable FirmaFuncion Clase_Funcion

e double

aFigura

radio double

aConicas aConicas(double) aConicas

diametro double

aConicas

area double

aConicas area() cCirculo

perimetro double

aConicas perimetro() cCirculo

circunferencia double

aConicas circunferencia() cElipse

semiperimetro double

aConicas semiperimetro() cCirculo

excentricidad double

aConicas excentricidad() cElipse

puntox double

aConicas aConicas(double, double, double, double)

aConicas

puntoy double


aConicas

puntoa double


aConicas

puntob double


aConicas

puntoc double

aConicas c() cElipse

lado1 double protected aCuadrilateros aParalelogramos(double) aParalelogramos




altura double protected aCuadrilateros altura() cCuadrado

area double protected aCuadrilateros area() cCuadrado

apotema double protected aCuadrilateros apotema() cCuadrado

diagonal double protected aCuadrilateros diagonal() cCuadrado

diagonales double protected aCuadrilateros diagonales() cCuadrado

perimetro double protected aCuadrilateros perimetro() cCuadrado

semiperimetro double protected aCuadrilateros semiperimetro() cCuadrado

radio double protected aCuadrilateros circircuns() cCuadrado

e double

aCuerpo

radio double protected aCurvos aCurvos(double, double) aCurvos

altura double protected aCurvos aCurvos(double, double) aCurvos

areatot double protected aCurvos area() cCilindro

areabase double protected aCurvos areabase() cCono

arealat double protected aCurvos areabase() cCilindro

volumen double protected aCurvos volumen() cCilindro

generatriz double protected aCurvos generatriz() cCono

radio double protected aCurvos aCurvos(double) aCurvos

lado1 double protected aCuadrilateros aParalelogramos(double, double)

aParalelogramos


aParalelogramos


aParalelogramos


aParalelogramos

altura double

aPoliedrosIrregulares

poligono aElemGeometrico


arealat double

aPoliedrosIrregulares arealat() cPiramides

areatot double

aPoliedrosIrregulares area() cPiramides

volumen double

aPoliedrosIrregulares volumen() cPiramides

areabase double


perimbase double


apotemalat double

aPiramides apotema() cPiramides

apotemabase double

aPiramides

radio double

aPiramides

aristalat double

aPiramides aristalat() cPiramides


128

lado double protected aPoliedrosRegulares aPoliedrosRegulares(double)

aPoliedrosRegulares

areatot double protected aPoliedrosRegulares area() cCubo

arealat double protected aPoliedrosRegulares arealat() cCubo

volumen double protected aPoliedrosRegulares volumen() cCubo

apotema double protected aPoliedrosRegulares apotema() cCubo

perimetro double protected aPoliedrosRegulares perimetro() cCubo

lado1 double protected aCuadrilateros aTrapecios(double, double, double)

aTrapecios


aTrapecios


aTrapecios


aTrapecios

lado1 double protected aTriangulos aTriangulos(double, double, double)

aTriangulos


aTriangulos


aTriangulos

altura double protected aTriangulos altura() cTrianguloEquilatero

area double protected aTriangulos area() aTriangulos

semiperimetro double protected aTriangulos semiperimetro() aTriangulos

perimetro double protected aTriangulos perimetro() cTrianguloEquilatero

circircuns double protected aTriangulos circircuns(double) aTriangulos

cirinsc double protected aTriangulos cirinsc(double) aTriangulos

lado1 double protected aTriangulos aTriangulos(double, double)

aTriangulos


aTriangulos


aTriangulos

lado1 double protected aTriangulos aTriangulos(double) aTriangulos



areatot double protected aCurvos area() cCono

arealat double protected aCurvos arealat() cCono

volumen double protected aCurvos volumen() cCono

radio double protected aCuadrilateros cirinsc() cCuadrado

radio double protected aCuadrilateros radio() cCuadrado

diagonal double

cCubo diagonal() cCubo

lado1 double protected cDecagono cDecagono(double) cDecagono

altura double protected cDecagono altura() cDecagono

apotema double protected cDecagono apotema() cDecagono

area double protected cDecagono area() cDecagono

diagonal double protected cDecagono diagonal() cDecagono

diagonales double protected cDecagono diagonales() cDecagono

perimetro double protected cDecagono perimetro() cDecagono

semiperimetro double protected cDecagono semiperimetro() cDecagono

radio double protected cDecagono radio() cDecagono

areatot double protected aPoliedrosRegulares area() cDodecaedro

arealat double protected aPoliedrosRegulares arealat() cDodecaedro

volumen double protected aPoliedrosRegulares volumen() cDodecaedro

apotema double protected aPoliedrosRegulares apotema() cDodecaedro

perimetro double protected aPoliedrosRegulares perimetro() cDodecaedro

area double

aConicas area() cElipse

perimetro double

aConicas perimetro() cElipse

lado1 double protected cEneagono cEneagono(double) cEneagono

altura double protected cEneagono altura() cEneagono

apotema double protected cEneagono apotema() cEneagono


129

area double protected cEneagono area() cEneagono

diagonal double protected cEneagono diagonal() cEneagono

diagonales double protected cEneagono diagonales() cEneagono

perimetro double protected cEneagono perimetro() cEneagono

semiperimetro double protected cEneagono semiperimetro() cEneagono

radio double protected cEneagono radio() cEneagono

areatot double protected aCurvos area() cEsfera

arealat double protected aCurvos arealat() cEsfera

areabase double protected aCurvos areabase() cEsfera

volumen double protected aCurvos volumen() cEsfera

lado1 double protected cHeptagono cHeptagono(double) cHeptagono

altura double protected cHeptagono altura() cHeptagono

apotema double protected cHeptagono apotema() cHeptagono

area double protected cHeptagono area() cHeptagono

diagonal double protected cHeptagono diagonal() cHeptagono

diagonales double protected cHeptagono diagonales() cHeptagono

perimetro double protected cHeptagono perimetro() cHeptagono

semiperimetro double protected cHeptagono semiperimetro() cHeptagono

radio double protected cHeptagono radio() cHeptagono

lado1 double

cHexagono cHexagono(double) cHexagono

altura double

cHexagono altura() cHexagono

apotema double

cHexagono apotema() cHexagono

area double

cHexagono area() cHexagono

diagonal double

cHexagono diagonal() cHexagono

diagonales double

cHexagono diagonales() cHexagono

perimetro double

cHexagono perimetro() cHexagono

semiperimetro double

cHexagono semiperimetro() cHexagono

radio double

cHexagono radio() cHexagono

areatot double protected aPoliedrosRegulares area() cIcosaedro

arealat double protected aPoliedrosRegulares arealat() cIcosaedro

volumen double protected aPoliedrosRegulares volumen() cIcosaedro

apotema double protected aPoliedrosRegulares apotema() cIcosaedro

perimetro double protected aPoliedrosRegulares perimetro() cIcosaedro

diagonal double

cOctaedro diagonal() cOctaedro

areatot double protected aPoliedrosRegulares area() cOctaedro

arealat double protected aPoliedrosRegulares arealat() cOctaedro

volumen double protected aPoliedrosRegulares volumen() cOctaedro

apotema double protected aPoliedrosRegulares apotema() cOctaedro

perimetro double protected aPoliedrosRegulares perimetro() cOctaedro

lado1 double protected cOctagono cOctagono(double) cOctagono

altura double protected cOctagono altura() cOctagono

apotema double protected cOctagono apotema() cOctagono

area double protected cOctagono area() cOctagono

diagonal double protected cOctagono diagonal() cOctagono

diagonales double protected cOctagono diagonales() cOctagono

perimetro double protected cOctagono perimetro() cOctagono

semiperimetro double protected cOctagono semiperimetro() cOctagono

radio double protected cOctagono radio() cOctagono

lado1 double protected cPentagono cPentagono(double) cPentagono

altura double protected cPentagono altura() cPentagono

apotema double protected cPentagono apotema() cPentagono

area double protected cPentagono area() cPentagono

diagonal double protected cPentagono diagonal() cPentagono

diagonales double protected cPentagono diagonales() cPentagono

perimetro double protected cPentagono perimetro() cPentagono

semiperimetro double protected cPentagono semiperimetro() cPentagono

radio double protected cPentagono radio() cPentagono

apotemalat double

aPiramides arealat() cPiramides

areatot double

aPoliedrosIrregulares area() cPrismas

arealat double

aPoliedrosIrregulares arealat() cPrismas


130

volumen double

aPoliedrosIrregulares volumen() cPrismas

area double protected aCuadrilateros area() cRectangulo

perimetro double protected aCuadrilateros perimetro() cRectangulo

diagonal double protected aCuadrilateros diagonal() cRectangulo

diagonales double protected aCuadrilateros diagonales() cRectangulo

semiperimetro double protected aCuadrilateros semiperimetro() cRectangulo

altura double protected aCuadrilateros altura() cRectangulo

apotema double protected aCuadrilateros apotema() cRectangulo

apotema double protected aCuadrilateros apotema() cRectangulo

diagonalmayor double public cRombo diagonalmayor() cRombo

diagonalmenor double public cRombo diagonalmenor() cRombo

altura double protected aCuadrilateros altura() cRombo

perimetro double protected aCuadrilateros perimetro() cRombo

semiperimetro double protected aCuadrilateros semiperimetro() cRombo

area double protected aCuadrilateros area() cRombo

diagonales double protected aCuadrilateros diagonales() cRombo

area double protected aCuadrilateros area() cRomboide

altura double protected aCuadrilateros altura() cRomboide

semiperimetro double protected aCuadrilateros semiperimetro() cRomboide

diagonales double protected aCuadrilateros diagonales() cRomboide

perimetro double protected aCuadrilateros perimetro() cRomboide

areatot double protected aPoliedrosRegulares area() cTetraedro

arealat double protected aPoliedrosRegulares arealat() cTetraedro

volumen double protected aPoliedrosRegulares volumen() cTetraedro

apotema double protected aPoliedrosRegulares apotema() cTetraedro

perimetro double protected aPoliedrosRegulares perimetro() cTetraedro

area double protected aCuadrilateros area() cTrapecio

altura double protected aCuadrilateros altura() cTrapecio

semiperimetro double protected aCuadrilateros semiperimetro() cTrapecio

diagonal double protected aCuadrilateros diagonal() cTrapecio

diagonales double protected aCuadrilateros diagonales() cTrapecio

perimetro double protected aCuadrilateros perimetro() cTrapecio

area double protected aCuadrilateros area() cTrapecioIsosceles

altura double protected aCuadrilateros altura() cTrapecioIsosceles

semiperimetro double protected aCuadrilateros semiperimetro() cTrapecioIsosceles

diagonal double protected aCuadrilateros diagonal() cTrapecioIsosceles

diagonales double protected aCuadrilateros diagonales() cTrapecioIsosceles

perimetro double protected aCuadrilateros perimetro() cTrapecioIsosceles

area double protected aCuadrilateros area() cTrapecioRectangulo

altura double protected aCuadrilateros altura() cTrapecioRectangulo

lado4 double protected aCuadrilateros ladooblicuo() cTrapecioRectangulo

semiperimetro double protected aCuadrilateros semiperimetro() cTrapecioRectangulo

diagonal double protected aCuadrilateros diagonal() cTrapecioRectangulo

diagonales double protected aCuadrilateros diagonales() cTrapecioRectangulo

perimetro double protected aCuadrilateros perimetro() cTrapecioRectangulo

lado1 double protected aCuadrilateros cTrapezoide(double, double, double, double)

cTrapezoide


cTrapezoide


cTrapezoide


cTrapezoide

semiperimetro double protected aCuadrilateros semiperimetro() cTrapezoide

diagonales double protected aCuadrilateros diagonales() cTrapezoide

perimetro double protected aCuadrilateros perimetro() cTrapezoide

apotema double public cTrianguloEquilatero apotema() cTrianguloEquilatero

altura double protected aTriangulos altura() cTrianguloEscaleno

perimetro double protected aTriangulos perimetro() cTrianguloEscaleno

perimetro double protected aTriangulos perimetro() cTrianguloIsosceles


131

altura double protected aTriangulos altura() cTrianguloIsosceles

Tabla 13. Resultado del MOO2MVA-CP-01: Tabla Funciones abstractas

Firma Especificador Tipo_Retorno Clase Patron_MVC

altura() public abstract void aElemGeometrico Vista

ladooblicuo() public abstract void aElemGeometrico Vista

apotema() public abstract double aElemGeometrico Modelo

area() public abstract double aElemGeometrico No especializada

radio() public abstract double aElemGeometrico Modelo

cirinsc() public abstract void aElemGeometrico Vista

cirinsc(double) public abstract void aElemGeometrico Vista

circircuns() public abstract void aElemGeometrico Vista

circircuns(double) public abstract void aElemGeometrico Vista

circunferencia() public abstract void aElemGeometrico Vista

diagonal() public abstract void aElemGeometrico Vista

diagonales() public abstract void aElemGeometrico Vista

diametro() public abstract void aElemGeometrico Vista

figinscir() public abstract void aElemGeometrico Vista

perimetro() public abstract double aElemGeometrico No especializada

semiperimetro() public abstract void aElemGeometrico Vista

c() public abstract void aElemGeometrico Vista

focos() public abstract void aElemGeometrico Vista

excentricidad() public abstract void aElemGeometrico Vista

arealat() public abstract void aElemGeometrico Vista

volumen() public abstract void aElemGeometrico Vista

areabase() public abstract void aElemGeometrico Vista

generatriz() public abstract void aElemGeometrico Vista

aristalat() public abstract void aElemGeometrico Vista

altura() public abstract void aFigura Vista

apotema() public abstract double aFigura Modelo

area() public abstract double aFigura No especializada

cirinsc() public abstract void aFigura Vista

cirinsc(double) public abstract void aFigura Vista

circircuns() public abstract void aFigura Vista

circircuns(double) public abstract void aFigura Vista

circunferencia() public abstract void aFigura Vista

diagonal() public abstract void aFigura Vista

diagonales() public abstract void aFigura Vista

diametro() public abstract void aFigura Vista

figinscir() public abstract void aFigura Vista

ladooblicuo() public abstract void aFigura Vista

perimetro() public abstract double aFigura No especializada

semiperimetro() public abstract void aFigura No especializada

c() public abstract void aFigura Vista

focos() public abstract void aFigura Vista

excentricidad() public abstract void aFigura Vista

perimetro() public abstract double aConicas No especializada

semiperimetro() public abstract void aConicas No especializada

area() public abstract double aConicas No especializada

diametro() public abstract void aConicas Vista

circunferencia() public abstract void aConicas No especializada

figinscir() public abstract void aConicas No especializada

circircuns() public abstract void aConicas No especializada

c() public abstract void aConicas Vista

focos() public abstract void aConicas Vista

excentricidad() public abstract void aConicas Vista

altura() public abstract void aPoligonos No especializada

apotema() public abstract double aPoligonos No especializada


132

area() public abstract double aPoligonos No especializada

cirinsc() public abstract void aPoligonos Vista

circircuns() public abstract void aPoligonos Vista

diagonal() public abstract void aPoligonos Vista

diagonales() public abstract void aPoligonos Vista

figinscir() public abstract void aPoligonos Vista

perimetro() public abstract double aPoligonos No especializada

semiperimetro() public abstract void aPoligonos No especializada

radio() public abstract double aPoligonos Modelo

area() public abstract double aCuadrilateros No especializada

apotema() public abstract double aCuadrilateros No especializada

altura() public abstract void aCuadrilateros No especializada

semiperimetro() public abstract void aCuadrilateros No especializada

diagonal() public abstract void aCuadrilateros No especializada

diagonales() public abstract void aCuadrilateros No especializada

perimetro() public abstract double aCuadrilateros No especializada

figinscir() public abstract void aCuadrilateros Vista

circircuns() public abstract void aCuadrilateros Vista

cirinsc() public abstract void aCuadrilateros Vista

area() public abstract double aCuerpo No especializada

arealat() public abstract void aCuerpo No especializada

volumen() public abstract void aCuerpo No especializada

apotema() public abstract double aCuerpo No especializada

diagonal() public abstract void aCuerpo Vista

perimetro() public abstract double aCuerpo No especializada

areabase() public abstract void aCuerpo Vista

aristalat() public abstract void aCuerpo Vista

area() public abstract double aCurvos No especializada

arealat() public abstract void aCurvos No especializada

areabase() public abstract void aCurvos No especializada

volumen() public abstract void aCurvos No especializada

area() public abstract double aParalelogramos No especializada

apotema() public abstract double aParalelogramos No especializada

altura() public abstract void aParalelogramos No especializada

semiperimetro() public abstract void aParalelogramos No especializada

diagonal() public abstract void aParalelogramos No especializada

diagonales() public abstract void aParalelogramos No especializada

perimetro() public abstract double aParalelogramos No especializada

circircuns() public abstract void aParalelogramos No especializada

cirinsc() public abstract void aParalelogramos No especializada

figinscir() public abstract void aParalelogramos No especializada

area() public abstract double aPoliedros No especializada

arealat() public abstract void aPoliedros No especializada

volumen() public abstract void aPoliedros No especializada

apotema() public abstract double aPoliedros Modelo

perimetro() public abstract double aPoliedros Modelo

diagonal() public abstract void aPoliedros Vista

areabase() public abstract void aPoliedros Vista

aristalat() public abstract void aPoliedros Vista

area() public abstract double aPoliedrosIrregulares No especializada

arealat() public abstract void aPoliedrosIrregulares No especializada

volumen() public abstract void aPoliedrosIrregulares No especializada

apotema() public abstract double aPoliedrosIrregulares Modelo

aristalat() public abstract void aPoliedrosIrregulares Vista

apotema() public abstract double aPiramides No especializada

aristalat() public abstract void aPiramides No especializada

arealat() public abstract void aPiramides No especializada

area() public abstract double aPiramides No especializada

volumen() public abstract void aPiramides No especializada

area() public abstract double aPoliedrosRegulares No especializada


133

arealat() public abstract void aPoliedrosRegulares No especializada

volumen() public abstract void aPoliedrosRegulares No especializada

apotema() public abstract double aPoliedrosRegulares No especializada

perimetro() public abstract double aPoliedrosRegulares No especializada

diagonal() public abstract void aPoliedrosRegulares No especializada

area() public abstract double aPrismas No especializada

arealat() public abstract void aPrismas No especializada

volumen() public abstract void aPrismas No especializada

area() public abstract double aTrapecios No especializada

altura() public abstract void aTrapecios No especializada

semiperimetro() public abstract void aTrapecios No especializada

diagonal() public abstract void aTrapecios No especializada

diagonales() public abstract void aTrapecios No especializada

perimetro() public abstract double aTrapecios No especializada

perimetro() public abstract double aTriangulos No especializada

apotema() public abstract double aTriangulos No especializada

altura() public abstract void aTriangulos No especializada

Tabla 14. Resultado del MOO2MVA-CP-01: Tabla Funciones concretas

Firma Especificador Tipo_Retorno Clase Patron_MVC

arealat() public void aFigura Vista

volumen() public void aFigura Vista

areabase() public void aFigura Vista

generatriz() public void aFigura Vista

aristalat() public void aFigura Vista

radio() public double aFigura Modelo

altura() public void aConicas Vista

apotema() public double aConicas Modelo

cirinsc() public void aConicas Vista

cirinsc(double) public void aConicas Vista

circircuns(double) public void aConicas Vista

diagonal() public void aConicas Vista

diagonales() public void aConicas Vista

ladooblicuo() public void aConicas Vista

circunferencia() public void aPoligonos Vista

cirinsc(double) public void aPoligonos Vista

circircuns(double) public void aPoligonos Vista

diametro() public void aPoligonos Vista

ladooblicuo() public void aPoligonos Vista

c() public void aPoligonos Vista

focos() public void aPoligonos Vista

excentricidad() public void aPoligonos Vista

circircuns(double) public void aCuadrilateros Vista

cirinsc(double) public void aCuadrilateros Vista

radio() public double aCuadrilateros Modelo

altura() public void aCuerpo Vista

ladooblicuo() public void aCuerpo Vista

cirinsc() public void aCuerpo Vista

cirinsc(double) public void aCuerpo Vista

circircuns() public void aCuerpo Vista

circircuns(double) public void aCuerpo Vista

circunferencia() public void aCuerpo Vista

diagonales() public void aCuerpo Vista

diametro() public void aCuerpo Vista

figinscir() public void aCuerpo Vista

semiperimetro() public void aCuerpo Vista

c() public void aCuerpo Vista

focos() public void aCuerpo Vista


134

excentricidad() public void aCuerpo Vista

generatriz() public void aCuerpo Vista

radio() public double aCuerpo Modelo

generatriz() public void aCurvos Vista

diagonal() public void aCurvos Vista

aristalat() public void aCurvos Vista

apotema() public double aCurvos No especializada

perimetro() public double aCurvos No especializada

diagonal() public void aPoliedrosIrregulares Vista

areabase() public void aPoliedrosIrregulares Vista

perimetro() public double aPoliedrosIrregulares Modelo

areabase() public void aPoliedrosRegulares Vista

aristalat() public void aPoliedrosRegulares Vista

apotema() public double aPrismas Modelo

aristalat() public void aPrismas Vista

apotema() public double aTrapecios No especializada

figinscir() public void aTrapecios Vista

circircuns() public void aTrapecios Vista

cirinsc() public void aTrapecios Vista

diagonales() public void aTriangulos Vista

circircuns() public void aTriangulos Vista

cirinsc() public void aTriangulos Vista

figinscir() public void aTriangulos Vista

diagonal() public void aTriangulos Vista

radio() public double aTriangulos Modelo

area() public double aTriangulos No especializada

semiperimetro() public void aTriangulos No especializada

circircuns(double) public void aTriangulos No especializada

cirinsc(double) public void aTriangulos No especializada

area() public double cCilindro No especializada

arealat() public void cCilindro No especializada

areabase() public void cCilindro No especializada

volumen() public void cCilindro No especializada

area() public double cCirculo No especializada

perimetro() public double cCirculo No especializada

diametro() public void cCirculo Vista

circunferencia() public void cCirculo No especializada

semiperimetro() public void cCirculo No especializada

figinscir() public void cCirculo No especializada

circircuns() public void cCirculo No especializada

c() public void cCirculo Vista

focos() public void cCirculo Vista

excentricidad() public void cCirculo Vista

area() public double cCono No especializada

arealat() public void cCono No especializada

areabase() public void cCono No especializada

volumen() public void cCono No especializada

generatriz() public void cCono No especializada

altura() public void cCuadrado No especializada

semiperimetro() public void cCuadrado No especializada

diagonal() public void cCuadrado No especializada

diagonales() public void cCuadrado No especializada

apotema() public double cCuadrado No especializada

area() public double cCuadrado No especializada

perimetro() public double cCuadrado No especializada

figinscir() public void cCuadrado No especializada

circircuns() public void cCuadrado No especializada

cirinsc() public void cCuadrado No especializada

radio() public double cCuadrado Modelo

area() public double cCubo No especializada


135

arealat() public void cCubo No especializada

volumen() public void cCubo No especializada

diagonal() public void cCubo No especializada

apotema() public double cCubo No especializada

perimetro() public double cCubo No especializada

altura() public void cDecagono No especializada

apotema() public double cDecagono No especializada

area() public double cDecagono No especializada

cirinsc() public void cDecagono No especializada

circircuns() public void cDecagono No especializada

radio() public double cDecagono No especializada

diagonal() public void cDecagono No especializada

diagonales() public void cDecagono No especializada

figinscir() public void cDecagono No especializada

perimetro() public double cDecagono No especializada

semiperimetro() public void cDecagono No especializada

area() public double cDodecaedro No especializada

arealat() public void cDodecaedro No especializada

volumen() public void cDodecaedro No especializada

apotema() public double cDodecaedro No especializada

perimetro() public double cDodecaedro No especializada

diagonal() public void cDodecaedro Vista

c() public void cElipse No especializada

focos() public void cElipse No especializada

area() public double cElipse No especializada

perimetro() public double cElipse No especializada

excentricidad() public void cElipse No especializada

semiperimetro() public void cElipse Vista

diametro() public void cElipse No especializada

circunferencia() public void cElipse No especializada

figinscir() public void cElipse Vista

circircuns() public void cElipse Modelo

altura() public void cEneagono No especializada

apotema() public double cEneagono No especializada

area() public double cEneagono No especializada

cirinsc() public void cEneagono No especializada

circircuns() public void cEneagono No especializada

radio() public double cEneagono No especializada

diagonal() public void cEneagono No especializada

diagonales() public void cEneagono No especializada

figinscir() public void cEneagono No especializada

perimetro() public double cEneagono No especializada

semiperimetro() public void cEneagono No especializada

area() public double cEsfera No especializada

arealat() public void cEsfera No especializada

areabase() public void cEsfera No especializada

volumen() public void cEsfera No especializada

altura() public void cHeptagono No especializada

apotema() public double cHeptagono No especializada

area() public double cHeptagono No especializada

cirinsc() public void cHeptagono No especializada

circircuns() public void cHeptagono No especializada

radio() public double cHeptagono No especializada

diagonal() public void cHeptagono No especializada

diagonales() public void cHeptagono No especializada

figinscir() public void cHeptagono No especializada

perimetro() public double cHeptagono No especializada

semiperimetro() public void cHeptagono No especializada

altura() public void cHexagono No especializada

apotema() public double cHexagono No especializada


136

area() public double cHexagono No especializada

cirinsc() public void cHexagono No especializada

circircuns() public void cHexagono No especializada

radio() public double cHexagono No especializada

diagonal() public void cHexagono No especializada

diagonales() public void cHexagono No especializada

figinscir() public void cHexagono No especializada

perimetro() public double cHexagono No especializada

semiperimetro() public void cHexagono No especializada

area() public double cIcosaedro No especializada

arealat() public void cIcosaedro No especializada

volumen() public void cIcosaedro No especializada

apotema() public double cIcosaedro No especializada

perimetro() public double cIcosaedro No especializada

diagonal() public void cIcosaedro Vista

area() public double cOctaedro No especializada

arealat() public void cOctaedro No especializada

volumen() public void cOctaedro No especializada

apotema() public double cOctaedro No especializada

perimetro() public double cOctaedro No especializada

diagonal() public void cOctaedro No especializada

altura() public void cOctagono No especializada

apotema() public double cOctagono No especializada

area() public double cOctagono No especializada

cirinsc() public void cOctagono No especializada

circircuns() public void cOctagono No especializada

radio() public double cOctagono No especializada

diagonal() public void cOctagono No especializada

diagonales() public void cOctagono No especializada

figinscir() public void cOctagono No especializada

perimetro() public double cOctagono No especializada

semiperimetro() public void cOctagono No especializada

altura() public void cPentagono No especializada

apotema() public double cPentagono No especializada

area() public double cPentagono No especializada

cirinsc() public void cPentagono No especializada

circircuns() public void cPentagono No especializada

radio() public double cPentagono No especializada

diagonal() public void cPentagono No especializada

diagonales() public void cPentagono No especializada

figinscir() public void cPentagono No especializada

perimetro() public double cPentagono No especializada

semiperimetro() public void cPentagono No especializada

apotema() public double cPiramides No especializada

aristalat() public void cPiramides No especializada

arealat() public void cPiramides No especializada

area() public double cPiramides No especializada

volumen() public void cPiramides No especializada

area() public double cPrismas No especializada

arealat() public void cPrismas No especializada

volumen() public void cPrismas No especializada

area() public double cRectangulo No especializada

perimetro() public double cRectangulo No especializada

diagonal() public void cRectangulo No especializada

circircuns() public void cRectangulo No especializada

cirinsc() public void cRectangulo No especializada

figinscir() public void cRectangulo Vista

diagonales() public void cRectangulo No especializada

semiperimetro() public void cRectangulo No especializada

altura() public void cRectangulo No especializada


137

apotema() public double cRectangulo No especializada

altura() public void cRombo No especializada

perimetro() public double cRombo No especializada

semiperimetro() public void cRombo No especializada

diagonalmayor() public void cRombo No especializada

diagonalmenor() public void cRombo No especializada

area() public double cRombo No especializada

figinscir() public void cRombo Vista

apotema() public double cRombo No especializada

cirinsc() public void cRombo Vista

circircuns() public void cRombo Vista

diagonal() public void cRombo Modelo

diagonales() public void cRombo No especializada

area() public double cRomboide No especializada

apotema() public double cRomboide No especializada

altura() public void cRomboide No especializada

semiperimetro() public void cRomboide No especializada

diagonal() public void cRomboide Vista

diagonales() public void cRomboide No especializada

perimetro() public double cRomboide No especializada

circircuns() public void cRomboide Vista

cirinsc() public void cRomboide Vista

figinscir() public void cRomboide Vista

area() public double cTetraedro No especializada

arealat() public void cTetraedro No especializada

volumen() public void cTetraedro No especializada

apotema() public double cTetraedro No especializada

diagonal() public void cTetraedro

perimetro() public double cTetraedro No especializada

area() public double cTrapecio No especializada

altura() public void cTrapecio No especializada

semiperimetro() public void cTrapecio No especializada

diagonal() public void cTrapecio No especializada

diagonales() public void cTrapecio No especializada

perimetro() public double cTrapecio No especializada

area() public double cTrapecioIsosceles No especializada

altura() public void cTrapecioIsosceles No especializada

semiperimetro() public void cTrapecioIsosceles No especializada

diagonal() public void cTrapecioIsosceles No especializada

diagonales() public void cTrapecioIsosceles No especializada

perimetro() public double cTrapecioIsosceles No especializada

area() public double cTrapecioRectangulo No especializada

altura() public void cTrapecioRectangulo No especializada

ladooblicuo() public void cTrapecioRectangulo No especializada

semiperimetro() public void cTrapecioRectangulo No especializada

diagonal() public void cTrapecioRectangulo No especializada

diagonales() public void cTrapecioRectangulo No especializada

perimetro() public double cTrapecioRectangulo No especializada

area() public double cTrapezoide No especializada

apotema() public double cTrapezoide No especializada

altura() public void cTrapezoide No especializada

semiperimetro() public void cTrapezoide No especializada

diagonal() public void cTrapezoide Vista

diagonales() public void cTrapezoide No especializada

perimetro() public double cTrapezoide No especializada

figinscir() public void cTrapezoide Vista

circircuns() public void cTrapezoide Vista

cirinsc() public void cTrapezoide Vista

perimetro() public double cTrianguloEquilatero No especializada

apotema() public double cTrianguloEquilatero No especializada


138

altura() public void cTrianguloEquilatero No especializada

altura() public void cTrianguloEscaleno No especializada

perimetro() public double cTrianguloEscaleno No especializada

apotema() public double cTrianguloEscaleno No especializada

apotema() public double cTrianguloIsosceles No especializada

perimetro() public double cTrianguloIsosceles No especializada

altura() public void cTrianguloIsosceles No especializada

Tabla 15. Resultado del MOO2MVA-CP-01: Tabla Tipos de Clases Nombre Paquete Tipo Tipo_Relacion1 Clase_Base1 Patron_MVC

aElemGeometrico FiugrasGeometricas abstract

No especializada

aFigura FiugrasGeometricas abstract extends aElemGeometrico No especializada

aConicas FiugrasGeometricas abstract extends aFigura No especializada

aPoligonos FiugrasGeometricas abstract extends aFigura Vista

aCuadrilateros FiugrasGeometricas abstract extends aPoligonos No especializada

aCuerpo FiugrasGeometricas abstract extends aElemGeometrico No especializada

aCurvos FiugrasGeometricas abstract extends aCuerpo No especializada

aParalelogramos FiugrasGeometricas abstract extends aCuadrilateros No especializada

aPoliedros FiugrasGeometricas abstract extends aCuerpo No especializada

aPoliedrosIrregulares FiugrasGeometricas abstract extends aPoliedros No especializada

aPiramides FiugrasGeometricas abstract extends aPoliedrosIrregulares No especializada

aPoliedrosRegulares FiugrasGeometricas abstract extends aPoliedros Vista

aPrismas FiugrasGeometricas abstract extends aPoliedrosIrregulares No especializada

aTrapecios FiugrasGeometricas abstract extends aCuadrilateros No especializada

aTriangulos FiugrasGeometricas abstract extends aPoligonos No especializada

cCilindro FiugrasGeometricas concreta extends aCurvos No especializada

cCirculo FiugrasGeometricas concreta extends aConicas No especializada

cCono FiugrasGeometricas concreta extends aCurvos No especializada

cCuadrado FiugrasGeometricas concreta extends aParalelogramos No especializada

cCubo FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada

cDecagono FiugrasGeometricas concreta extends aPoligonos No especializada

cDodecaedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada

cElipse FiugrasGeometricas concreta extends aConicas No especializada

cEneagono FiugrasGeometricas concreta extends aPoligonos No especializada

cEsfera FiugrasGeometricas concreta extends aCurvos No especializada

cHeptagono FiugrasGeometricas concreta extends aPoligonos No especializada

cHexagono FiugrasGeometricas concreta extends aPoligonos No especializada

cIcosaedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada

cOctaedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada

cOctagono FiugrasGeometricas concreta extends aPoligonos No especializada

cPentagono FiugrasGeometricas concreta extends aPoligonos No especializada

cPiramides FiugrasGeometricas concreta extends aPiramides No especializada

cPrismas FiugrasGeometricas concreta extends aPrismas No especializada

cRectangulo FiugrasGeometricas concreta extends aParalelogramos No especializada

cRombo FiugrasGeometricas concreta extends aParalelogramos No especializada

cRomboide FiugrasGeometricas concreta extends aParalelogramos No especializada

cTetraedro FiugrasGeometricas concreta extends aPoliedrosRegulares No especializada

cTrapecio FiugrasGeometricas concreta extends aTrapecios No especializada

cTrapecioIsosceles FiugrasGeometricas concreta extends aTrapecios No especializada

cTrapecioRectangulo FiugrasGeometricas concreta extends aTrapecios No especializada

cTrapezoide FiugrasGeometricas concreta extends aCuadrilateros No especializada

cTrianguloEquilatero FiugrasGeometricas concreta extends aTriangulos No especializada

cTrianguloEscaleno FiugrasGeometricas concreta extends aTriangulos No especializada

cTrianguloIsosceles FiugrasGeometricas concreta extends aTriangulos No especializada


139



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.


El resultado de la ejecución del método R7, de acuerdo a la entrada descrita anteriormente es:

La tabla “Jerarquía de Clases” con la estructura jerárquica del MOO. Dicha tabla se muestra a

continuación.

Tabla 16. Resultado del MOO2MVA-CP-02: Tabla Jerarquía de Clases

ClasePadre ClaseHija

aElemGeometrico aFigura

aElemGeometrico aCuerpo

aFigura aConicas

aFigura aPoligonos

aCuerpo aCurvos

aCuerpo aPoliedros

aConicas cCirculo

aConicas cElipse

aPoligonos aCuadrilateros

aPoligonos aTriangulos

aPoligonos cDecagono

aPoligonos cEneagono

aPoligonos cHeptagono

aPoligonos cHexagono

aPoligonos cOctagono

aPoligonos cPentagono

aCurvos cCilindro

aCurvos cCono

aCurvos cEsfera

aPoliedros aPoliedrosIrregulares

aPoliedros aPoliedrosRegulares

cCirculo Sin subclases

cElipse Sin subclases

aCuadrilateros aParalelogramos

aCuadrilateros aTrapecios

aCuadrilateros cTrapezoide

aTriangulos cTrianguloEquilatero

aTriangulos cTrianguloEscaleno

aTriangulos cTrianguloIsosceles

cDecagono Sin subclases

cEneagono Sin subclases

cHeptagono Sin subclases

cHexagono Sin subclases

cOctagono Sin subclases

cPentagono Sin subclases

cCilindro Sin subclases

ClasePadre ClaseHija

cCono Sin subclases

cEsfera Sin subclases

aPoliedrosIrregulares aPiramides

aPoliedrosIrregulares aPrismas

aPoliedrosRegulares cCubo

aPoliedrosRegulares cDodecaedro

aPoliedrosRegulares cIcosaedro

aPoliedrosRegulares cOctaedro

aPoliedrosRegulares cTetraedro

aParalelogramos cCuadrado

aParalelogramos cRectangulo

aParalelogramos cRombo

aParalelogramos cRomboide

aTrapecios cTrapecio

aTrapecios cTrapecioIsosceles

aTrapecios cTrapecioRectangulo

cTrapezoide Sin subclases

cTrianguloEquilatero Sin subclases

cTrianguloEscaleno Sin subclases

cTrianguloIsosceles Sin subclases

aPiramides cPiramides

aPrismas cPrismas

cCubo Sin subclases

cDodecaedro Sin subclases

cIcosaedro Sin subclases

cOctaedro Sin subclases

cTetraedro Sin subclases

cCuadrado Sin subclases

cRectangulo Sin subclases

cRombo Sin subclases

cRomboide Sin subclases

cTrapecio Sin subclases

cTrapecioIsosceles Sin subclases

cTrapecioRectangulo Sin subclases

cPiramides Sin subclases

cPrismas Sin subclases


140



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 Tipo de relación 1: extends

o Clase base 1: aAbstracta2

Instancia 3




o Tipo de relación 1: implements

o Clase base 1: iInterfaz3

Instancia 4








Instancia 5


o Nombre de la clase: aAbstractaPrueba5

o Tipo de clase: abstract

Instancia 6






Instancia 7


141






Instancia 8


o Nombre de la clase: iInterfazPrueba8

o Tipo de clase: interface

Instancia 9


o Nombre de la clase: iInterfazPrueba9

o Tipo de clase: interface




El resultado de la ejecución del método R2, son las clases creadas de acuerdo a las entradas

descritas anteriormente. A continuación se muestran los resultados.

Instancia 1

Figura 39. Resultado del MOO2MVA-CP-03: Instancia 1

Instancia 2


Instancia 3


Instancia 4



142

Instancia 5


Instancia 6


Instancia 7


Instancia 8


Instancia 9




Los elementos de entrada para probar la correcta funcionalidad del método R3: “Crear constructor”

son: Nombre de la clase a la que se le desea agregar el constructor; para un constructor con parámetros se

tiene que enviar una lista con dichos parámetros y para copiar un constructor, el nombre de la clase de la

cual se desea copiar el constructor.

Instancia 1

o Nombre de la clase donde se creará el constructor: cCuboM

Instancia 2


o Parámetros:

Tipo: double

Id Parámetro: diagonal

Variable a inicializar: diagonal


143

Instancia 3


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


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


Instancia 2


Instancia 3



144



Los elementos de entrada para probar la correcta funcionalidad del método R5: “Reubicar

atributos” son: el archivo java al que se le desean copiar atributos y la tabla “Variables MVA” con registros

que en la columna “Clase” coincidan con el nombre del archivo java.

La clase cCuadradoa la que se le desea reubicar atributos se muestra en la siguiente figura.

Figura 52. Clase cCuadradoC en donde se reubicarán atributos

Los datos de entrada en la tabla “Variables MVA” se muestran en la siguiente tabla.

Tabla 17. Tabla Variables MVA para el caso de prueba MOO2MVA-CP-05

Identificador Tipo Especificador Clase

altura double protected cCuadradoC

area double protected cCuadradoC

apotema double protected cCuadradoC

diagonal double protected cCuadradoC

diagonales double protected cCuadradoC

perimetro double protected cCuadradoC

semiperimetro double protected cCuadradoC

radio double protected cCuadradoC


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


145



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


146

Figura 55. Clase cRectanguloV donde se copiará una función con parámetros


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


Tabla 18. Resultado del MOO2MVA-CP-06: Instancia 1, tabla Funciones Concretas MVA

Firma Especificador Tipo_Retorno Clase Patron_MVA

diagonalM() public double cRectanguloM Modelo

Instancia 2


Tabla 19. Resultado del MOO2MVA-CP-06: Instancia 2, tabla Funciones Concretas MVA

Firma Especificador Tipo_Retorno Clase Patron_MVA

diagonalV(double) public void cRectanguloV Vista

TESIS DE MAESTRÍA EN CIENCIAS - CENIDET - … Luz Christina... · 3.6 Compilador ... ANTLR Siglas...

Documents

Transcript of TESIS DE MAESTRÍA EN CIENCIAS - CENIDET - … Luz Christina... · 3.6 Compilador ... ANTLR Siglas...