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
170
Embed
TESIS DE MAESTRÍA EN CIENCIAS - CENIDET - … Luz Christina... · 3.6 Compilador ... ANTLR Siglas en inglés de ANother Tool for Language Recognition cuya traducción al español
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Anexo A: Métodos de Reestructura ................................................................................................ 101
Anexo B: Descripción de los Casos de Prueba ................................................................................. 123
iii
Lista de Tablas
Pag.
Tabla 1. Comparación de trabajos relacionados. .............................................................................. 17
Tabla 2. Descripción del patrón MVC y sus variaciones. ................................................................... 26
Tabla 3. Descripción de la tabla Tipos de clases ............................................................................... 42
Tabla 4. Descripción de la tabla Funciones Abstractas ..................................................................... 43
Tabla 5. Descripción de la tabla Funciones Concretas ...................................................................... 43
Tabla 6. Descripción de la tabla Tipos de Variables .......................................................................... 43
Tabla 7. Descripción de la tabla Jerarquía de Clases ......................................................................... 52
Tabla 8. Descripción de la tabla Variables MVA ................................................................................ 58
Tabla 9. Documentos del plan de pruebas ........................................................................................ 76
Tabla 10. Clases de Java a usarse como elementos de prueba ......................................................... 77
Tabla 11. Resumen de los resultados obtenidos en las pruebas ...................................................... 90
Tabla 12. Resultados del MOO2MVA-CP-01: Tabla Tipos de Variables .......................................... 127
Tabla 13. Resultado del MOO2MVA-CP-01: Tabla Funciones abstractas ....................................... 131
Tabla 14. Resultado del MOO2MVA-CP-01: Tabla Funciones concretas ........................................ 133
Tabla 15. Resultado del MOO2MVA-CP-01: Tabla Tipos de Clases ................................................. 138
Tabla 16. Resultado del MOO2MVA-CP-02: Tabla Jerarquía de Clases .......................................... 139
Tabla 17. Tabla Variables MVA para el caso de prueba MOO2MVA-CP-05 .................................... 144
Tabla 18. Resultado del MOO2MVA-CP-06: Instancia 1, tabla Funciones Concretas MVA ............ 146
Tabla 19. Resultado del MOO2MVA-CP-06: Instancia 2, tabla Funciones Concretas MVA ............ 146
v
Lista de Figuras
Pag.
Figura 1. Arquitectura del patrón MVC ............................................................................................. 23
Figura 2. Arquitectura del patrón MVA ............................................................................................. 25
Figura 3. Fases de un Compilador ..................................................................................................... 31
Figura 4. Ejemplo de función especializada. ..................................................................................... 34
Figura 5. Ejemplo de función no-especializada ................................................................................. 35
Figura 6. Ejemplo de clase especializada .......................................................................................... 35
Figura 7. Ejemplo de clase no-especializada ..................................................................................... 36
Figura 8. Proceso de refactorización de MOO a arquitectura MVA .................................................. 41
Figura 9. Diagrama de Actividad del Método R1: “Analizar Código Legado” ................................... 44
Figura 10. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 2)................... 45
Figura 11. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 3)................... 46
Figura 12. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 4)................... 47
Figura 13. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 5)................... 48
Figura 14. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 6)................... 49
Figura 15. Diagrama de Actividad del Método R1: “Analizar Código Legado” (parte 7)................... 50
Figura 16. Diagrama de Actividad del Método R7: “Estructura jerárquica de clases” ...................... 53
Figura 17. Diagrama de Actividad del Método R2: “Crear clases” .................................................... 55
Figura 18. Diagrama de Actividad del Método R3: “Crear constructor” ........................................... 57
Figura 19. Diagrama de Actividad del Método R3: “Crear constructor” (parte 2) ............................ 58
Figura 20. Diagrama de Actividad del Método R5: “Reubicar atributos” ......................................... 59
Figura 21. Diagrama de Actividad del Método R4: “Crear funciones” .............................................. 61
Figura 22. Diagrama de Actividad del Método R4: “Crear funciones” (parte 2) ............................... 62
Figura 23. Diagrama general de la herramienta MOO2MVA ............................................................ 64
Figura 24. Diagrama de clases del paquete InterfazGrafica ............................................................. 65
Figura 25. Diagrama de clases del paquete Adaptador .................................................................... 65
Figura 26. Diagrama de clases del paquete MOO2MVA ................................................................... 66
Figura 27. Diagrama de clases del paquete MOO2MVA.baseDatos ................................................. 67
Figura 28. Diagrama de clases del paquete MOO2MVA.A1.Analizar ............................................... 68
Figura 29. Proceso de obtención de la tabla de símbolos ................................................................. 69
Figura 30. Proceso de etiquetación utilizando la tabla de símbolos ................................................. 71
Figura 31. Diagrama de clases del paquete MOO2MVA.A1.Analizar.TablaSímbolos ....................... 72
Figura 32. Diagrama de clases del paquete MOO2MVA.A2.Refactorizar ......................................... 74
Figura 33. Diagrama de clases del MOO Figuras Geométricas ......................................................... 78
Figura 34. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 1) .. 124
Figura 35. Resultado del MOO2MVA-CP-01: Código etiquetado clase aTriangulo.java (parte 2) .. 125
Figura 36. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEquilatero.java . 125
Figura 37. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloEscaleno.java ... 126
Lista de Figuras
vi
Figura 38. Resultado del MOO2MVA-CP-01: Código etiquetado clase cTrianguloIsoceles.java .... 126
Figura 39. Resultado del MOO2MVA-CP-03: Instancia 1 ................................................................ 141
Figura 40. Resultado del MOO2MVA-CP-03: Instancia 2 ................................................................ 141
Figura 41. Resultado del MOO2MVA-CP-03: Instancia 3 ................................................................ 141
Figura 42. Resultado del MOO2MVA-CP-03: Instancia 4 ................................................................ 141
Figura 43. Resultado del MOO2MVA-CP-03: Instancia 5 ................................................................ 142
Figura 44. Resultado del MOO2MVA-CP-03: Instancia 6 ................................................................ 142
Figura 45. Resultado del MOO2MVA-CP-03: Instancia 7 ................................................................ 142
Figura 46. Resultado del MOO2MVA-CP-03: Instancia 8 ................................................................ 142
Figura 47. Resultado del MOO2MVA-CP-03: Instancia 9 ................................................................ 142
Figura 48. Constructor en la clase cCubo ........................................................................................ 143
Figura 49. Resultado del MOO2MVA-CP-04: Instancia 1 ................................................................ 143
Figura 50. Resultado del MOO2MVA-CP-04: Instancia 2 ................................................................ 143
Figura 51. Resultado del MOO2MVA-CP-04: Instancia 3 ................................................................ 143
Figura 52. Clase cCuadradoC en donde se reubicarán atributos .................................................... 144
Figura 53. Resultado del MOO2MVA-CP-05: clase cCuadradoC ..................................................... 144
Figura 54. Clase cRectanguloM donde se copiará una función sin parámetros ............................. 145
Figura 55. Clase cRectanguloV donde se copiará una función con parámetros ............................. 146
Figura 56. Resultado del MOO2MVA-CP-06: Instancia 1 ................................................................ 146
Figura 57. Resultado del MOO2MVA-CP-06: Instancia 2 ................................................................ 146
vii
Glosario de Términos
Acoplamiento Nivel de dependencia entre las unidades de software de un sistema informático, es decir, el grado en que una unidad puede funcionar sin recurrir a otras. Se recomienda que exista bajo acoplamiento.
ANTLR Siglas en inglés de ANother Tool for Language Recognition cuya traducción al español es Otra Herramienta para Reconocimiento de Lenguajes. Es una herramienta de software que opera sobre lenguajes, proporcionando un marco para construir reconocedores, intérpretes, compiladores y traductores de lenguajes a partir de las descripciones gramaticales de los mismos.
ASP Siglas en inglés de Active Server Pages cuya traducción al español es Páginas Activas en el Servidor. Es una tecnología de Microsoft que se ejecuta de lado del servidor, se utiliza para páginas web generadas dinámicamente, que ha sido comercializada como un anexo a Internet Information Services (IIS).
AST Siglas en inglés de Abstract Syntax Tree cuya traducción al español es Árbol de Sintaxis Abstracta. Es una representación del árbol de la estructura sintáctica abstracta de código fuente escrito en un lenguaje de programación.
Capa Estructura lógica de los diferentes elementos que componen el software.
COBOL Siglas en inglés de COmmon Business-Oriented Language cuya traducción al español es Lenguaje Común Orientado a Negocios. Es un lenguaje de programación creado con la intención de que fuera un lenguaje universal que pudiera ser usado en cualquier ordenador, y que estuviera orientado principalmente a los negocios.
Código legado Se refiere a sistemas de software desarrollados o diseñados tiempo atrás del proyecto actual de diseño. Por lo general son sistemas que los clientes desean que sean reusados o actualizados
Cohesividad Hace referencia a la forma en que agrupamos unidades de software en una unidad mayor. El consenso general para una buena programación o un buen diseño es que la cohesión debe ser alta.
Componente Unidad de composición con interfaces especificadas en forma de contrato y con dependencias de contexto explícitas. Un componente puede ser desplegado o instalado independientemente y es sujeto a ser composición por terceras entidades.
Composición Tipo de relación que se establece entre dos objetos que tienen comunicación persistente. Se utiliza para expresar que un par de objetos
tienen una relación de dependencia para llevar a cabo su función, de modo que uno de los objetos involucrados está compuesto por el otro.
Enfoque holístico Tendencia o corriente que analiza los eventos desde el punto de vista de las múltiples interacciones que los caracterizan
IDE Siglas en inglés de Integrated Development Environment cuya traducción al español es Entorno de Desarrollo Integrado. Es un programa informático compuesto por un conjunto de herramientas de programación. Puede dedicarse en exclusiva a un solo lenguaje de programación o bien poder utilizarse para varios.
IIS Siglas en inglés de Internet Information Services cuya traducción al español es Servicios de Información de Internet. Es un servidor web y un conjunto de servicios para el sistema operativo Microsoft Windows
JavaBeans Son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones en Java. Se usan para encapsular varios objetos en un único objeto (la vaina o Bean en inglés), para hacer uso de un solo objeto en lugar de varios más simples.
Java Servlets Son objetos que han sido programados en Java y se ejecutan dentro del contexto de un contenedor de servlets y extienden su funcionalidad. El uso más común de los servlets es generar páginas web de forma dinámica a partir de los parámetros de la petición que envíe el navegador web.
JSP Siglas en inglés de JavaServer Pages cuya traducción al español es Páginas de Servidor de Java. Es una tecnología Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo.
Lexer Analizador léxico o analizador lexicográfico, es la primera fase de un compilador consistente en un programa que recibe como entrada el código fuente de otro programa (secuencia de caracteres) y produce una salida compuesta de tokens (componentes léxicos) o símbolos.
Microsoft SQL Server
Sistema para la gestión de bases de datos producido por Microsoft basado en el modelo relacional. Sus lenguajes para consultas son T-SQL y ANSI SQL.
Paradigma de programación
Propuesta tecnológica que es adoptada por una comunidad de programadores cuyo núcleo central es incuestionable en cuanto a que unívocamente trata de resolver uno o varios problemas claramente delimitados. Un paradigma de programación está delimitado en el tiempo en cuanto a aceptación y uso ya que nuevos paradigmas aportan nuevas o mejores soluciones que la sustituyen parcial o totalmente.
Glosario de Términos
ix
Parser Es una de las partes de un compilador que convierte el texto de entrada en otras estructuras (comúnmente árboles), que son más útiles para el posterior análisis y capturan la jerarquía implícita de la entrada.
Patrón arquitectural
Expresa un esquema de estructura de organización fundamental para el sistema software. Este provee un conjunto de subsistemas predefinidos, especifica responsabilidades e incluye reglas y guías para organizar las relaciones entre ellas.
Patrón de diseño Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Plataforma de desarrollo
Es el entorno de software común en el cual se desenvuelve la programación de un grupo definido de aplicaciones.
Reuso El reuso de código, o también llamado reuso de software, se refiere al uso de software existente, o a la lógica de algún software, para construir nuevo software.
SQL Siglas en inglés de Structured Query Language cuya traducción al español es Lenguaje de consulta estructurado. Es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en estas.
XML Siglas en inglés de eXtensible Markup Language cuya traducción al español es Lenguaje de Marcado Extensible. es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos, permite definir lenguajes para diferentes necesidades, de ahí que se le denomine metalenguaje.
VBScript Siglas en inglés de Visual Basic Script Edition cuya traducción al español es Visual Basic Edición para Script. Es un lenguaje interpretado por el Windows Scripting Host de Microsoft. Su sintaxis refleja su origen como variación del lenguaje de programación Visual Basic.
xi
Resumen
Un Marco de Aplicación Orientado a Objetos es una colección semicompleta de clases que
se ha transformado en una aplicación reusable, la cual puede ser utilizada para dar soluciones a un
grupo de problemas relacionados. Una manera en la que se podrían aprovechar mejor estos
marcos de aplicación, es colocándolos a disposición de una mayor cantidad de personas, utilizando
Internet para compartirlos como servicios Web.
Lo anterior provoca la necesidad de transformar los MOO a servicios Web, pero antes de
realizar esta transformación es necesario adaptar la arquitectura del código según el patrón
Modelo-Vista-Controlador (MVC por sus siglas), ya que se debe separar la parte de la Vista y el
Control de la parte del Modelo, la cual contiene la lógica del negocio.
La complejidad que se presenta al refactorizar los MOO bajo una arquitectura MVC, radica
en que las diferentes capas (Modelo, Vista y Controlador) pueden estar estrechamente acopladas
dentro de las diferentes aplicaciones, lo que provoca que se dificulte su separación.
El presente trabajo describe un primer acercamiento para el desarrollo de una
herramienta llamada MOO2MVA, la cual tiene como objetivo automatizar la refactorización de
MOO hacia una arquitectura según el patrón MVC.
En este primer acercamiento se implementaron seis de los once métodos que conforman
el proceso de refactorización. Dicho proceso utiliza como base los métodos propuestos en
“Métodos Heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia el
patrón de diseño Modelo-Vista-Controlador”, tesis de maestría realizada en el laboratorio de
Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET).
Aunque se sabe que existen trabajos relacionados con el tema de la refactorización hacia
el patrón MVC, también se sabe que no todos están orientados hacia la total refactorización del
código; ni se enfocan en mantener la separación total de las capas de la Vista y el Modelo. Entre
las herramientas que se conocen están: M&S SW, PerCobol, UWAT+, HEDGEHOG, entre otros.
La diferencia entre las herramientas anteriores y el presente trabajo es que MOO2MVA es
una herramienta que apuesta por la total separación de la lógica del negocio (Modelo) y de la
presentación de los datos (Vista), así como un análisis profundo del código original que permita la
preservación de la lógica de negocio.
Los métodos implementados actualmente en la herramienta MOO2MVA fueron probados
con un MOO que consistía en 44 clases cuyo dominio estaba basado en el área de la geometría. De
las pruebas realizadas a estos métodos, se obtuvo el cien por ciento de resultados positivos.
Con base en los resultados obtenidos de las pruebas, se concluyó que la refactorización
automática hacia el patrón MVC, realizada por una herramienta, es posible. También se propone
como trabajo futuro la implementación de los cinco métodos restantes.
xiii
Abstract
A Framework for Object-Oriented Application is a semi-complete collection of classes that have
been transformed into a reusable application, which can be used to provide solutions to a group of
related problems. One way in which these application frameworks could be better used, is by
placing them at the disposal of a greater number of people by using the Internet to share them as
Web services.
This causes the need to transform the MOOs into Web services, but before achieving this,
it is necessary to adapt the architecture of code according to the Model-View-Controller
architectural pattern (MVC for short), since the View and Control layer must be separated from
the Model layer, which contains the business logic.
The complexity presented when refactoring the MOOs into a MVC architecture, is that the
different layers (Model, View and Controller) can be tightly coupled in different applications,
leading to a difficult separation.
This paper describes a first approach for developing a tool called MOO2MVA, which aims
to automate refactoring MOO towards an architecture according to the MVC pattern.
In this first approach, were implemented six of the eleven methods that make the process
of refactoring. This process uses the proposed methods based on "Heuristic Methods for
restructuring application frameworks towards the object-oriented Model-View-Controller design
pattern", a Master degree thesis conducted at the Software Engineering Laboratory of the
National Center for Research and Development of Technology (CENIDET).
Although it is known that there are papers related to the topic of refactoring towards the
MVC pattern, it is also known that not all are aimed towards complete refactoring of the code, nor
focus on maintaining the complete separation of the View and Model layers. Among the tools that
are known are: M&S SW, PerCobol, UWAT + HEDGEHOG, among others.
The difference between the previous tools and the present work is that MOO2MVA is a
tool that is committed to total separation of business logic (Model) and data presentation (View),
and a thorough analysis of the original code that allows the preservation of the business logic.
The first stage in the development of the MOO2MVA tool was tested with a framework for
object-oriented applications consisting of 44 classes whose domain was based on the field of
geometry. From the tested implemented methods, we obtained one hundred percent positive
results.
Based on the results of the tests it was concluded that the automatic refactoring towards the MVC
pattern by a tool is possible. Also, the implementation of the five remaining methods was also
proposed as future work.
Introducción
1
Capítulo 1. Introducción
En este capítulo se presenta una introducción al tema de tesis, la descripción del problema,
objetivo, alcances, limitaciones, justificación, beneficios y la organización general de este
documento.
1.1 Introducción
Un Marco de Aplicación Orientado a Objetos (MOO por sus siglas) es una colección semicompleta
de clases que se ha transformado en una aplicación reusable, la cual puede ser utilizada para dar
soluciones a un grupo de problemas relacionados, de esta manera dicho MOO puede ser utilizado
para generar nuevas aplicaciones hechas a la medida [FAYA,97].
Sin embargo, los MOO, generalmente son explotados de manera centralizada y propietaria
dentro de cada una de las empresas que los posee.
Una manera en la que se podrían aprovechar mejor estos marcos de aplicación, es
poniéndolos a disposición de una mayor cantidad de personas utilizando Internet para
compartirlos como servicios Web, estos servicios tendrían la misma funcionalidad que los MOO
pero podrían ser explotados por una mayor cantidad de personas.
Capítulo 1
2
Lo anterior provoca una nueva necesidad, que es la de transformar los MOO a servicios
Web. Una solución a esta nueva necesidad es la refactorización de los MOO para obtener servicios
Web, pero antes es necesario adecuar la arquitectura del código según el patrón MVC ya que se
debe separar la parte de la Vista y el Control de la parte del Modelo, la cual contiene la lógica del
negocio.
Es decir, para poder realizar la refactorización de un MOO hacia servicios Web es
necesario hacer una transformación intermedia, en la cual se reestructura la arquitectura del MOO
y sus componentes se hacen menos dependientes entre sí, para esto se utiliza el patrón
arquitectural MVC el cual separará el código de las aplicaciones en tres capas (Modelo, Vista y
Controlador) generando así la estructura adecuada para eliminar las capas de la Vista y el Control y
transformar la capa del Modelo a servicios Web.
En el laboratorio de Ingeniería de Software del CENIDET, se han realizado varios trabajos
relacionados a la refactorización de código legado, y el principal antecedente para la
refactorización de MOO hacia el patrón MVC, es la tesis de maestría titulada “Métodos Heurísticos
para reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-
Vista-Controlador” [NUÑE,08]. Con la implementación de los métodos propuestos en dicha tesis se
da continuidad a esta línea de investigación.
Por lo que en este trabajo de tesis se propuso la generación de una herramienta que
ayude a realizar esta refactorización de los MOO hacia una arquitectura MVC, utilizando los
métodos propuestos en [NUÑE,08]. Para que así, después de realizar la refactorización se pueda
tomar la parte correspondiente al Modelo y transformarlo a servicios Web.
1.2 Descripción del problema
Los MOO representan una buena opción para el reuso tanto del diseño como de código de manera
centralizada y propietaria, pero si se quiere poner a disposición de un mayor número de usuarios a
través de Internet para el desarrollo de nuevas aplicaciones, es casi imposible lograrlo debido a
que los MOO no están escritos en un lenguaje estandarizado para ser utilizados por diferentes
plataformas de desarrollo.
Una de las estrategias para reusar los MOO a través de Internet, es transformarlos a
servicios Web, los cuales proporcionan mecanismos de comunicación estándar entre diferentes
aplicaciones.
El problema radica en que no se pueden transformar los MOO a servicios Web
directamente sin antes separar las clases y funciones que son altamente interactivas con el usuario
(capa de la Vista) y la parte que controlan la lógica de la aplicación (capa del Controlador); de la
parte que contiene la lógica del negocio (capa del Modelo); y muchas veces en la arquitectura de
los MOO estas tres capas se encuentran mezcladas, por lo que primero se debe realizar la
transformación a una arquitectura que permite separar estas tres capas, es decir, a la arquitectura
del patrón MVC.
Introducción
3
La complejidad que se presenta al refactorizar los MOO bajo una arquitectura MVC, radica
en que estas capas (Modelo, Vista y Controlador) pueden estar estrechamente acopladas dentro
de las diferentes aplicaciones, lo que provoca que se dificulte su separación.
1.3 Objetivo
Dividir la arquitectura original de los MOO hacia una arquitectura MVC con el propósito de
favorecer su reúso como servicios Web, mediante el desarrollo de una herramienta que
implemente los métodos desarrollados en “Métodos Heurísticos para reestructurar marcos de
aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador” [NUÑE,08].
1.4 Justificación
El desarrollo de una herramienta que separe la arquitectura de los MOO en las diferentes capas
que conforman el patrón MVC, es de utilidad para satisfacer la necesidad de refactorizar los MOO
para obtener servicios Web.
La necesidad de llevar los MOO hacia servicios Web existe debido a que, aunque existen
procesos y herramientas para refactorizar o transformar código legado, ya sea al patrón
arquitectural MVC o a la Web, relativamente poco esfuerzo se ha invertido en trabajos de
investigación enfocados en buscar formas para extender el aprovechamiento y reuso de MOO en
mayor escala.
De acuerdo a [BOSC,97] existe una gran cantidad de investigación y desarrollo de software
tanto en compañías como en universidades e incluso a nivel gubernamental, lo que ha provocado
la creación de un gran número de MOO.
Por otro lado, actualmente es común colocar en Internet, a disposición de otros
desarrolladores, componentes de software como recursos de la Web, los cuales proporcionan las
mismas ventajas que los MOO, pero ahora lo hacen en internet y de manera independiente a la
plataforma de desarrollo, y además pueden ser accedidos por una mayor cantidad de clientes. Lo
que provoca la necesidad de transformar MOO a servicios Web, ya que el tiempo y conocimiento
invertido en el desarrollo de los MOO no debería ser desperdiciado, sino adaptado a las nuevas
tecnologías.
1.5 Beneficios
El desarrollo de una herramienta que ayuda a realizar la refactorización de MOO hacia una
arquitectura MVC favorece la productividad de los desarrolladores de software, pues al separar la
lógica de negocios de la presentación al usuario, se simplifican las tareas de mantenimiento y
reuso, lo que aumentaría la productividad de los desarrolladores y se obtendrían aplicaciones de
Capítulo 1
4
mayor calidad y confiabilidad, ya que dichos componentes provendrían de aplicaciones maduras,
probadas y confiables.
Además, una vez realizada la separación del MOO en las diferentes capas que conforman
el patrón MVC, la parte del Modelo puede ser aprovechada como servicios Web posibilitando el
aprovechamiento de toda la experiencia implícita en estos MOO, por ejemplo, en las aplicaciones
de negocios, de ingeniería, en la educación, el comercio electrónico, etc.
1.6 Alcances y Limitaciones
1.6.1 Alcances
A continuación se presentan los alcances bajo los cuales se llevó a cabo la presente investigación:
Probar y refinar los métodos propuestos en la tesis de maestría titulada “Definición de
métodos heurísticos para reestructurar marcos de aplicaciones orientados a objetos hacia
el patrón de diseño Modelo-Vista-Controlador” [NUÑE,08].
Diseño de un proceso de refactorización utilizando los métodos propuestos en [NUÑE,08]
una vez que estos han sido refinados.
La cantidad de métodos implementados está limitado por el tiempo y las dificultades
encontradas durante el desarrollo de la investigación.
1.6.2 Limitaciones
Las limitaciones bajo los cuales se llevó a cabo el desarrollo de la investigación son las siguientes:
Se implementaron seis de los once métodos necesarios para realizar la refactorización, por
lo que el proceso de refactorización no se realiza completamente.
El proceso de refactorización no fue diseñado para refactorizar MOO cuyo dominio sean
las interfaces de usuario.
La herramienta funciona para MOO escritos en Java.
La herramienta funciona para MOO que contengan código libre de defectos de
compilación y ejecución.
Las interacciones del usuario consideradas son: entrada y salida de datos a través la línea
de comandos, es decir, con elementos de la librería java.io.
No se realizan transformaciones hacia servicios Web.
Introducción
5
1.7 Organización de esta tesis
La estructura restante de este documento se compone de seis capítulos más, los cuales se
describen a continuación.
Capítulo 2
En este capítulo se presentan los trabajos relacionados a esta investigación que fueron
desarrollados anteriormente en el CENIDET, el estado del arte y el análisis comparativo de algunas
investigaciones y herramientas de refactorización.
Capítulo 3
En este capítulo se presentan algunos conceptos teóricos relevantes y tecnologías
estudiadas para realizar la refactorización de los Marcos Orientados a Objetos hacia una
arquitectura MVC.
Capítulo 4
En este capítulo se describe el modelo conceptual en el que se basa el desarrollo de la
herramienta. Se describe el proceso de refactorización, las actividades y los métodos que lo
conforman.
Capítulo 5
En este capítulo se describe la implementación de los métodos de refactorización en la
herramienta. Se presentan los diagramas de clases y paquetes utilizados, los criterios de
etiquetación de código de acuerdo a la parte del patrón MVC a la que pertenecen y las tecnologías
utilizadas para el desarrollo de la herramienta.
Capítulo 6
En este capítulo se presentan el plan de pruebas para los métodos implementados en la
herramienta, la descripción del plan de pruebas y la especificación del diseño de pruebas.
Capítulo 7
En este capítulo se detallan las conclusiones alcanzadas, las aportaciones obtenidas con
esta investigación y los que se podrían considerar trabajos futuros.
Finalmente se presentan las referencias bibliográficas y dos anexos, el primero contiene
los métodos de refactorización y el segundo los resultados de las pruebas realizadas.
Antecedentes
7
Capítulo 2. Antecedentes
En este capítulo se presentan los trabajos relacionados a esta investigación que fueron
desarrollados anteriormente en el CENIDET, el estado del arte y el análisis comparativo de algunas
investigaciones y herramientas de refactorización.
2.1 Antecedentes
En el laboratorio de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo
Tecnológico (CENIDET), se han realizado varios trabajos relacionados a la refactorización de código
legado, pero el principal antecedente para la refactorización de Marcos de Aplicación Orientados a
Objetos hacia el patrón MVC, es la tesis de maestría titulada “Métodos Heurísticos para
reestructurar marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-
Controlador” [NUÑE,08]. A continuación se hace una breve descripción de las diferentes
investigaciones.
Capítulo 2
8
2.1.1 Factorización de Funciones hacia Métodos de Plantilla
[HERN,03]
El objetivo de este trabajo fue desarrollar una herramienta de software que realiza
automáticamente la refactorización de código legado escrito en el lenguaje C bajo el paradigma de
programación por procedimientos y obtiene como resultado arquitecturas de clases reusables
orientadas a objetos escritos en el lenguaje C++.
El proceso de refactorización parte de un conjunto de tablas, generadas al analizar el
código fuente, las cuales contienen la información importante para la refactorización (variables
locales, globales, nombres de funciones, etc.). Para el proceso de refactorización se incorporan
siete métodos que en conjunto cumplen con la función de generar marcos de componentes
reusables orientados a objetos. Los métodos de la refactorización son:
Método de creación de clases: Se construyen plantillas o clases que con la integración de
otros métodos se van convirtiendo en clases de objetos.
Método de declaración de constructores: Consiste en declarar dentro de cada clase de
objetos dos constructores, el primero contiene la inicialización de la estructura de datos
de las instancias de la clase y el segundo recibe un parámetro por cada variable de la clase.
Método de composición de clases: Se definen los elementos de composición que puedan
ser empleados por una clase y los cuales definen la forma en que la clase se familiariza con
otra.
Método de reubicación de funciones: Reubica las funciones en su correspondiente clase
de objetos con sus respectivos parámetros y tipo de la función.
Método de fragmentación de funciones: Fragmenta una misma función que es
redundante en varias clases de objetos, para evitar la duplicidad de código.
Método de superjerarquizar: Se declaran clases abstractas para evitar la duplicidad de
funciones, en este método se identifican clases candidatas a superjerarquizar pero se
necesita la intervención de un experto el dominio para determinar cómo actuar en estos
casos.
Método de fábrica de objetos: Consiste en definir una interfaz para crear objetos dejando
a las subclases la decisión de cual clase instanciar, éste método es influenciado por el
patrón de diseño “Abstract Factory”.
2.1.2 Reestructuración de Código Legado a partir del
Comportamiento para la Generación de Componentes
Reutilizables [BUST,03]
El objetivo de este trabajo fue el desarrollo de una herramienta que permite restructurar de forma
automatizada y en base a patrones de diseño, la arquitectura de los fragmentos de código legado
escritos en lenguaje C, que presenten las características de tener estatutos condicionales con más
de tres alternativas o que puedan presentar varios niveles de anidamiento, debido al alto grado de
Antecedentes
9
complejidad que exhiben; lo anterior tiene el objetivo de hacer una descomposición de segmentos
genéricos de código reutilizable, para que puedan ser probados e incorporados en marcos de
componentes reutilizables orientados a objetos para su reutilización.
Para la restructuración, se toma como entrada código fuente basado en procedimientos
escrito en lenguaje C, al cual se le aplica un proceso de análisis y extracción de información, la cual
se almacena en un conjunto de tablas. Estas tablas son la fuente de información que se utilizará
para llevar a cabo el proceso de restructura y la generación de clases que presentará la estructura
de los patrones de diseño “State” y “Strategy”. Para de esta manera automatizar el proceso de
refactorización de software legado, de una organización basada en procedimientos hacia una
arquitectura de clases en colaboración o marco de trabajo de componentes reusables.
2.1.3 Reestructuración de Software Escrito por Procedimientos
Conducido por Patrones de Diseño Composicionales [MEND,04]
Este trabajo tuvo como objetivo la restructuración de código escrito en C, el cual exhibe muchas
líneas de código, un bajo nivel de cohesividad, altos costos de mantenimiento, alto nivel de
dependencia, alto nivel de complejidad, ausencia de mecanismos de herencia, composición y
delegación; y carencia de interfaces.
La restructuración se hace hacia marcos de aplicaciones orientados a objetos que
incorporen la arquitectura de patrones de diseño que permiten la composición de objetos, con el
fin de obtener segmentos genéricos de código reusables, que pueden ser ejercitados e
incorporados en depósitos de componentes para su reúso en aplicaciones posteriores, mejorando
los aspectos mencionados, además de repercutir en la mejor calidad del sistema y en la
simplificación de las tareas de mantenimiento y reúso.
2.1.4 Métodos Heurísticos para Reestructurar Marcos de
Aplicaciones Orientados a Objetos hacia el Patrón de Diseño
Modelo-Vista-Controlador [NUÑE,08]
El objetivo de esta investigación fue identificar los posibles escenarios que se pueden presentar en
arquitecturas de marcos de aplicaciones orientados a objetos o sistemas legados desarrollados en
el lenguaje de programación Java y a partir de los escenarios identificados desarrollar un conjunto
de métodos heurísticos para la restructura de los Marcos de Aplicación Orientados a Objetos
conforme al patrón MVC.
En esta investigación se generó conocimiento sobre los principales escenarios que se
presentan cuando se requieren restructurar sistemas legados. Se muestra la cantidad de
escenarios que pueden suceder cuando se lleva a cabo la restructura de código legado, la
complejidad y factibilidad de este tipo de trabajos.
Capítulo 2
10
Además, los escenarios identificados documentan la manera en que se puede llegar a
presentar el código de los Marcos de Aplicación Orientados a Objetos legados y una solución para
llevar a cabo la restructura utilizando los métodos heurísticos.
Fueron 8 los métodos generados en esta investigación, los cuales establecen los pasos
para manipular los componentes presentes en los sistemas legados; dichos métodos se describen
a continuación:
Definir plantilla genérica MVC: Utilizando el patrón de diseño “Command” genera una
arquitectura de clases conforme al patrón MVC.
Análisis del Código Legado: Identifica con qué parte del patrón MVC se relaciona cada
uno de los estatutos de código incluido en las clases.
Crear Clases: Define la declaración de clases simples, abstractas e interfaces, colabora
con los métodos de “Cohesionar clases”, “Super-Jerarquizar” y “Sub-Jeraquizar”.
Crear Constructor: Define dos tipos de constructores con parámetros y sin ellos.
Incluye la inicialización de las estructuras de datos de las instancias de las clases.
Crear función: Crea funciones especializadas con parámetros y sin parámetros, al
crearse se especializan y están listas para reubicarse en las clases correspondientes.
Reubicar Atributos: Reubica los atributos y su inicialización desde las clases legadas a
las clases concretas correspondientes de la plantilla MVC.
Fragmentar funciones: Fragmenta las funciones no especializadas y utiliza el método
de Crear Funciones para generar funciones especializadas las cuales serán reubicadas
en la plantilla MVC.
Redefinir llamadas a funciones: Sustituye la actual llamada a una función que después
de ser fragmentada queda ubicada en alguna de las clases de la plantilla MVC.
2.2 Estado del arte
Aunque existen varios procesos y herramientas para refactorizar o transformar código legado, ya
sea al patrón arquitectural MVC o a la Web, durante esta investigación no se encontraron
herramientas que tengan como entrada código Java y su salida sea código Java refactorizado hacia
una arquitectura MVC. A continuación se presentan algunas de estas investigaciones y
herramientas.
2.2.1 Tranforming Legacy Web Applications to the MVC
Architecture (Transformando Aplicaciones Web Legadas hacia la
Arquitectura MVC) [PING,04]
Este artículo relacionado presenta un marco de reingeniería cuyo objetivo es crear un sistema con
arquitectura basada en el patrón MVC y que sea compatible con la plataforma Java. Este marco
está enfocado principalmente en la fragmentación de aplicaciones web legadas mediante la
identificación de los componentes de software que serán transformados en objetos java.
Antecedentes
11
Se desarrollaron herramientas programadas en Java que son capaces de restructurar la
arquitectura de sitios Web basados en JSP a una arquitectura enfocada en el controlador, todo
esto mediante la extracción de la información obtenido del análisis de la aplicación JSP. Los
autores dicen que como se obtiene información de un sistema web, las mismas páginas pueden
ser reutilizadas. También afirman que el proceso de migración de un sistema, además de traducir
de un lenguaje origen a otro, también debería de mejorar la calidad de las características del
sistema migrado.
Las herramientas presentadas en este trabajo relacionado adoptan la arquitectura MVC en
el ambiente Enterprise de Java, y como resultado de esto la aplicación fuente es restructurada en
JavaBeans (Modelo), Java Server Pages (Vista) y Java Servlets (Control).
Para la parte del modelo, se utilizaron tres tipos de JavaBeans:
Bean de consulta: Se encarga de ejecutar las consultas SQL extraídas desde el
programa fuente.
Bean de acceso de datos: Este es un objeto java serializable, el cual consiste casi
exclusivamente de métodos “setters” y “getters”. Lleva un conjunto de información
desde los Bean de consulta a los Bean de datos.
Bean de datos: Es un contenedor de objetos que encapsula la invocación de un Bean
de consultas en una página JSP. Lleva a cabo cierto conjunto de acciones, tales como
establecer los parámetros del Bean de consulta y llenar de información al Bean de
acceso de datos.
Los autores utilizan el mismo término y significado de “contenedores” que se utilizó en el
artículo pasado, y afirman que utilizándolos para JavaBeans, se reduce significativamente la
cantidad de código Java utilizado en las páginas JSP, debido a que la implementación en Java del
acceso a datos está encapsulada dentro de Beans de datos.
En el enfoque mostrado en este artículo, se construyó un componente controlador central
sobre el sistema Web para llevar a cabo la administración de las peticiones de procesamiento del
cliente y los resultados de las páginas Web. En otras palabras, ninguna página Web está enlazada
directamente a ninguna otra. En vez de eso, las páginas se conectan a un controlador asociado, el
cual renvía la petición de una página origen a la página destino.
La metodología que siguieron se divide en tres pasos:
Separar el acceso de base de datos de la presentación lógica, mediante la extracción
de sentencias SQL del programa legado.
Hacer la transición a páginas JSP al separar los elementos desplegables del programa
legado, que necesiten ser remplazados por páginas JSP, con una cierta combinación
JavaBeans generados de la primera etapa.
Adoptar una arquitectura centrada en el controlador. En esta etapa se adapta la
arquitectura original al patrón MVC mediante el análisis del flujo de control (que
puede ser extraído de las primeras dos etapas), el cual es representado por una
colección de archivos HTML, páginas JSP generadas y objetos JavaBeans.
Capítulo 2
12
Para llevar a cabo estas tres etapas, se utilizaron cinco procesos que contienen actividades
basados en la restructuración de código. Los procesos son:
Sistema fuente: Representa a la aplicación de software que será restructurada.
Análisis de software: Aquí se trabaja con un analizador de lenguaje que lee el código
fuente y reconoce la estructura del programa de acuerdo a la gramática del lenguaje
original. Aquí se utiliza un Lexer y un Parser y se obtiene un AST (Árbol Abstracto de
Sintaxis).
Extracción de información: Aquí se extrae la información generada en el AST y se
transforma a objetos reconocibles por Java.
Generación de código nuevo: Este proceso apoya a la generación automática de
nuevas aplicaciones.
Sistema Destino: Etapa final del proceso de restructuración. Esta etapa representa la
plataforma recién creada basada en el proceso de restructura.
2.2.2 Migrating Legacy Systems to the Web: An Experience
Report (Migrando Sistemas Legados a la Web: Un Reporte de las
Experiencias) [AVER,01]
En este trabajo relacionado se presenta un proyecto de migración cuya intención es integrar un
sistema existente escrito en COBOL a una infraestructura Web. El sistema original ha sido dividido
en componentes de interfaz de usuario (páginas ASP) y servidor (lógica de la aplicación y el acceso
a base de datos). Los autores aseveran que “Normalmente los componentes del sistema que son
parte de la interfaz de usuario son restructurados en forma de página Web, y utilizan al navegador
Web como un contenedor y los componentes que implementan las funciones de negocio pueden
ser contenidos o remplazados por componentes estándar o nuevos”.
En este artículo se menciona que la interfaz de usuario (Vista) fue restructurada con
tecnología ASP (Páginas Activas en el Servidor) y VBScript, mientras que la parte de la lógica
(Modelo) fue implementada utilizando Microfocus Object COBOL. Los autores utilizaron una
solución de corto plazo que consiste en agregar una estructura contenedora al código legado, para
permitir la comunicación de éste con código nuevo mediante mensajes, en lugar de la restructura
de código total. Pero los autores reconocen que una solución a largo plazo podría ser la
restructura del código legado hacia la orientación a objetos en la parte del servidor, y migrar
incrementalmente los objetos obtenidos de dicha restructura, hacia una arquitectura de
componentes distribuida.
Los autores indican que basados en trabajos anteriores se considera que los sistemas de
software pueden tener tres tipos de componentes: componentes de interfaz, componentes de la
lógica de aplicación y componentes de base de datos. Basados en esta clasificación, los autores de
[AVER, 2001] agruparon a los componentes de interfaz como parte del cliente, mientras los
últimos dos en la parte del servidor. También hablan que dependiendo de qué tan separados y
Antecedentes
13
definidos estén estos componentes mencionados, se puede clasificar a los sistemas en
Desfragmentable, semi-desfragmentable e indesfragmentable.
Los pasos de restructuración y desfragmentación requieren de un análisis estático para la
extracción de información relevante desde el código fuente para guardarlos en un repositorio.
Como resultado de esta actividad, los programas legados son restructurados en un estilo cliente-
servidor.
La manera en la que los autores capturaron la estructura del programa legado fue
mediante Grafos de Llamadas, los cuales capturan la interacción que se tiene entre las páginas o
módulos del sistema legado. Para capturar estos grafos de llamadas, se utilizó una herramienta
comercial. Después de haber capturado al grafo, se utilizó una herramienta desarrollada por ellos
que transformó este grafo en árbol de jerarquía. Para confirmar que capturaron bien el sistema, se
entrevistaron con el equipo de programadores del sistema original.
Los autores mencionan que uno de sus objetivos fue encontrar el balance entre el
esfuerzo necesario entre restructurar o volver a desarrollar programas legados, y el esfuerzo
requerido para envolverlos. Debido a esto, mencionan que los programas que mantienen la
comunicación con la nueva interfaz gráfica fueron restructurados y envueltos, mientras que las
interacciones con los programas que mantienen comunicaciones con la base de datos, aún son
implementados a través de archivos en COBOL sin restructurar. Los archivos COBOL tienen forma
de librerías dinámicas escritas en Microfocus Object COBOL, son cargadas en el servidor Web IIS
(Internet Information Services) de Microsoft y la interfaz de usuario accede a ellas mediante las
funciones VBScript embebidas en las páginas ASP.
Los autores concluyen el artículo diciendo que están en vías de un nuevo proyecto que se
dedicará a restructurar la parte del servidor hacia una arquitectura orientada a objetos.
2.2.3 Towards a Holistic Approach to Redisigning Legacy
Applications for the Web with UWAT+ (Hacia un Enfoque Holístico
para el Rediseño de Aplicaciones Legadas para la Web con
UWAT+) [DIST,06]
En este artículo se propone un enfoque holístico utilizando UWA (Marco Ubicuo de Diseño de
Aplicaciones Web) y UWAT+(la versión extendida de UWA) que combina tecnologías de
recuperación de diseño para capturar las reglas del dominio embebidas dentro de las aplicaciones
legadas, y métodos de diseño específicos para aplicaciones Web.
El artículo explica que los marcos de diseño UWA y UWAT+ ofrecen al diseñador un
conjunto de metodologías, meta modelos, y herramientas para el diseño centrado en el usuario de
aplicaciones ubicuas de datos y sensible a operaciones. También explican la manera en la que se
conforma el marco UWA y UWAT+. Los procesos por los que se conforman UWAT+ son:
Elicitación de requisitos: Está orientada a la formalización de las metas del proceso de
rediseño y a los requisitos para la versión Web del código legado. En este proceso se
Capítulo 2
14
trabaja en conjunto con los usuarios del sistema para ponerse de acuerdo con los
diseñadores en qué opciones del sistema legado se mantendrán.
Ingeniería inversa: Está orientado la extracción y formalización de la información
desde el código legado. Como resultado se obtiene un boceto de la nueva aplicación.
Aquí también se identifica a los componentes que pueden o tienen que ser
reutilizados en la nueva versión del software. De esta etapa se extraen productos tales
como documentación, tipos de usuario de la aplicación, modelos de proceso etc. Pero
los productos más importantes son la obtención de la lógica del negocio y sus
componentes.
Diseño directo: Aquí se utilizan los requisitos definidos en la primera etapa y se
utilizan para refinar el boceto obtenido de la segunda etapa, produciendo así el diseño
final de la nueva versión Web de la aplicación.
El enfoque presentado en este trabajo relacionado se probó en una aplicación llamada
GPA, la cual estaba programada en Visual Basic 5 y utilizaba la base de datos Microsoft SQL, la cual
fue restructurada con éxito.
2.2.4 Re-Approaching the Refactoring Rubicon (Re-Abordando
el Rubicon de la Refactorización) [ABAD,08]
En este artículo relacionado, los autores llevaron a cabo un caso de estudio en el que convirtieron
un Java Servlet hacia el patrón Modelo-Vista-Controlador utilizando la mayor cantidad soporte
automatizado posible. Basado en los descubrimientos de este trabajo relacionado, los autores
definieron los requisitos para un marco de restructurar, el cual hará posible la fragmentación de
una transformación compleja mediante pasos de restructura bien definidos.
Los autores exponen que los métodos de restructura modernos soportados por las IDEs,
no son capaces de restructurar el Método de Extracción de Fowler. Las transformaciones que se
utilizaron en este trabajo relacionado fueron expresadas como una serie de 36 pasos de
restructura, los cuales consistían en 14 tipos de restructuraciones. Se menciona que todos ellos,
menos cuatro, se encuentran documentados en el catálogo de Fowler. El Método de Extracción se
encuentra dentro del catálogo de Restructuras de Martin Fowler.
Basados en una serie de pruebas, los autores concluyen que los ambientes de desarrollo
modernos no tienen mucha capacidad de restructuración de código, y que muchas de esas
capacidades de restructura de alto nivel, requieren de métodos más pequeños de restructuración.
Además de que en ciertos casos existe más de una forma de implementar la misma
restructuración. Se menciona que el Método de Extracción debería de dar a elegir al usuario entre
varias formas de restructuración. También se menciona que las implementaciones actuales
contienen precondiciones demasiado fuertes para la restructuración, y todo debido al análisis
insuficiente acerca de la restructuración.
Según dicen los autores, un marco de restructuración que sea capaz de invocar varios
métodos pequeños para llevar a cabo una restructuración mayor, sería de gran ayuda para los
Antecedentes
15
desarrolladores y les facilitaría el trabajo. Y para que un marco de restructura sea realmente
efectivo es necesario que posea capacidades profundas de análisis.
2.2.5 Migrating COBOL Systems to the Web by Using the MVC
Design Pattern (Migrando Sistemas COBOL a la Web Utilizando el
Patrón de Diseño MVC) [BODH,02]
Este trabajo relacionado presenta una estrategia de migración cuyo objetivo es un sistema con
arquitectura web basado en el patrón MVC, además de un conjunto de herramientas con
propósitos definidos dentro de la estrategia. Al extraer toda la información necesaria desde el
código fuente en COBOL, las herramientas presentadas en este artículo pueden generar
contenedores para la lógica de negocio y el modelo de datos, y generar una interfaz de usuario
web en forma de JSP (Java Server Pages).
Los autores del artículo afirman que “A menudo, el código legado es la única fuente del
conocimiento del dominio así como también es la única descripción real de las reglas del dominio
actual”. Por lo tanto, mantienen la reestructura de código legado al mínimo, mientras toman el
enfoque de los contenedores de código. Los autores definen a los contenedores de código como
clases de código nuevo que “envuelve” al código legado, sin traducir de un lenguaje a otro, o sin
tener que cambiar la estructura del código original. Siguiendo la definición de “contenedor”,
también afirman que éstos representan una interfaz que le da acceso a las nuevas aplicaciones por
parte los componentes de código legado mediante el intercambio de mensajes. Las llamadas
recibidas por el contenedor, son convertidas en llamadas a los componentes del sistema que
realizan el servicio requerido. Para comunicar al objeto contenedor con el código COBOL, se utilizó
PERCobol, el cual es un compilador comercial desarrollado por la empresa LegacyJ, que es capaz
de compilar más de 15 dialectos de Cobol, puede traducir código COBOL a Java y puede
encontrarse en su sitio web www.legacyj.com. De esta manera, al mantener la parte del dominio
en el modelo, se enfocan en restructurar la parte de la vista para convertirlo en páginas Web JSP.
La metodología propuesta por los autores se llama M&S SW (Métodos y Herramientas
para la Producción de Software, Formación y Aplicaciones). Está compuesta por 8 etapas en las
cuales se utilizan siete herramientas programadas en Java para las diferentes etapas. Las
herramientas son:
Analizador: Ejecuta un análisis estático del código legado y utiliza ANTLR para realizar
el análisis.
Controlador: Produce reportes gráficos y textuales al procesar la información
almacenada en el repositorio. Genera los servlets pertenecientes a la capa del
controlador.
Cortadora: Descompone los programas al aplicar algoritmos de cortes basados en el
análisis de control de dependencias.
Capítulo 2
16
Extractor: Identifica los objetos asociados con el almacenamiento de datos dentro del
código legado. Cada objeto corresponde a un almacén de datos que contiene atributos
que son asociados a la estructura de datos.
Reingeniería: Crea la división de datos en el nuevo programa COBOL que contenga los
métodos extraídos del código original.
Re-Implementador: Genera una nueva interfaz de usuario para los componentes del
sistema mediante JSP.
Generador de contenedor: Genera un objeto en Java para envolver y acceder al
código legado restructurado.
Repositorio: Sirve para guardar la información que se obtiene de cada etapa. No es
una herramienta, pero interactúa con todas las anteriores. La información que se
almacena aquí está en formato XML.
Mediante el patrón MVC se puede mantener la lógica del programa en la parte del
modelo, y la interfaz de usuario en la vista. Las correspondencia entre la interfaz HTML y los
componentes son determinados mediante el análisis estático.
2.2.6 Análisis comparativo
La Tabla 1 muestra un resumen de las características encontradas entre los trabajos relacionados y
[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
funciones”, R5: “Reubicar atributos” y R7: “Estructura jerárquica de clases”.
Pruebas del Sistema
85
6.5.1 MOO2MVA-CP-01
Número/Nombre Prueba: MOO2MVA-CP-01
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se realiza correctamente la identificación y etiquetación de los estatutos del código legado de acuerdo a su tipo y a la parte del patrón MVA al que pertenecen. Además, comprobar el correcto almacenamiento de la información sobre variables, funciones y clases en las tablas correspondientes.
Condiciones de Ambiente Ninguna.
Entrada El código del marco orientado a objetos Figuras Geométricas escrito en lenguaje Java (elementos de prueba CJ01- CJ44)
Resultados Esperados Copia del código de un MOO escrito en lenguaje Java etiquetado correctamente de acuerdo a la parte del patrón MVA y a los tipos de estatutos que contiene.
Procedimiento de la Prueba
1. Inicio. 2. Se solicita la etiquetación del MOO. 3. Se realiza la copia de los archivos del código del MOO. 4. Se realiza la etiquetación del código del MOO. 5. Se realiza el almacenamiento de la información del MOO en las tablas
correspondientes. 6. Fin.
Cursos Alternos
Curso alterno 1 3. Ocurre algún error durante la copia de los archivos de código del MOO.
4. La herramienta notifica del error. 5. Fin.
Curso alterno 2 4. Ocurre algún error durante la etiquetación del código del MOO. 5. La herramienta notifica del error. 6. Fin.
Curso alterno 3 5. Ocurre algún error durante el almacenamiento de información en las tablas.
6. La herramienta notifica del error. 7. Fin.
Excepciones
Post-condiciones Si se presenta algún error durante la generación de la copia de los archivos de código del MOO, o la etiquetación, o del almacenamiento de información es las tablas se notifica del error, entonces el caso de prueba termina.
Observaciones Ninguna.
6.5.2 MOO2MVA-CP-02
Número/Nombre Prueba: MOO2MVA-CP-02
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se obtiene y almacena correctamente la estructura
Capítulo 6
86
jerárquica de las clases del MOO.
Condiciones de Ambiente El caso de prueba MOO2MVA-CP-01 se ha ejecutado con éxito anteriormente.
Entrada Tabla “Tipos de Clases” con los datos almacenados del MOO Figuras Geométricas.
Resultados Esperados En la tabla “Jerarquía de Clases” se tiene almacenada la información sobre la jerarquía de clases del MOO Figuras Geométricas.
Procedimiento de la Prueba
1. Inicio. 2. Se solicita la obtención de la jerarquía de clases del MOO. 3. Se obtiene la jerarquía de clases. 4. Se almacena la información en la tabla. 5. Fin.
Cursos Alternos
Curso alterno 1 3. Ocurre algún error durante la obtención de la jerarquía de clases. 4. La herramienta notifica del error. 5. Fin.
Curso alterno 2 4. Ocurre algún error durante el almacenamiento de información en la tabla.
5. La herramienta notifica del error. 6. Fin.
Excepciones
Post-condiciones Si se presenta algún error durante la obtención de la jerarquía de clases o el almacenamiento en la tabla, entonces el caso de prueba termina.
Observaciones Ninguna.
6.5.3 MOO2MVA-CP-03
Número/Nombre Prueba: MOO2MVA-CP-03
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se generaran correctamente clases concretas, abstractas e interfaces de Java.
Condiciones de Ambiente Ninguna.
Entrada Nombre del paquete, nombre de la clase, tipo de clase, tipo de relación 1, clase base 1, tipo de relación 2 y clase base2.
Resultados Esperados Una clase de Java de acuerdo al tipo de clase solicitada (concreta, abstracta o interfaz) con las relaciones establecidas de acuerdo a lo solicitado.
Procedimiento de la Prueba
1. Inicio. 2. Se solicita la generación de la clase. 3. Se genera la clase. 4. Se almacena el archivo generado para su posterior
comprobación. 5. Fin
Cursos Alternos
Curso alterno 1 3. Ocurre algún error durante la generación de la clase. 4. La herramienta notifica del error.
Pruebas del Sistema
87
5. Fin
Excepciones
Post-condiciones Si se presenta algún error durante la generación de la clase se notifica del error entonces el caso de prueba termina.
Observaciones Ninguna
Instancias de Prueba
No. de Instancia Valor Resultado Esperado
Instancia 1 Se solicita la creación de una clase concreta.
Clase de Java concreta generada correctamente.
Instancia 2 Se solicita la creación de una clase concreta derivada de otra clase.
Clase de Java concreta derivada de otra generada correctamente.
Instancia 3 Se solicita la creación de una clase concreta que implementa una interfaz
Clase de Java concreta que implementa una interfaz generada correctamente.
Instancia 4
Se solicita la creación de una clase concreta derivada de otra clase y que implementa una interfaz.
Clase de Java concreta derivada de otra e implementa una interfaz generada correctamente.
Instancia 5 Se solicita la creación de una clase abstracta.
Clase abstracta de Java generada correctamente.
Instancia 6 Se solicita la creación de una clase abstracta derivada de una clase.
Clase abstracta de Java derivada de una clase generada correctamente.
Instancia 7 Se solicita la creación de una clase abstracta que implementa una interfaz.
Clase abstracta de Java que implementa una interfaz generada correctamente.
Instancia 8 Se solicita la creación de una interfaz.
Interfaz de Java generada correctamente.
Instancia 9 Se solicita la creación de una interfaz que extiende a otra interfaz.
Interfaz de Java que extiende otra interfaz generada correctamente.
6.5.4 MOO2MVA-CP-04
Número/Nombre Prueba: MOO2MVA-CP-04
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se crean correctamente los constructores con parámetros y sin parámetros. Y que es posible copiar el constructor de una clase en otra.
Condiciones de Ambiente Ninguna
Entrada Clase de Java en la cual se desea crear el constructor. Si se desea copiar un constructor también es necesario indicar la clase Java desde la cual se copiará.
Resultados Esperados La clase de Java que contendrá el constructor que ha solicitado (con o
Capítulo 6
88
sin parámetros, o copia de otro).
Procedimiento de la Prueba
1. Inicio. 2. Se solicita la generación del constructor. 3. Se genera el constructor en la clase especificada. 4. Fin.
Cursos Alternos
Curso alterno 1 3. Ocurre algún error durante la generación del constructor. 4. La herramienta notifica del error. 5. Fin
Excepciones
Post-condiciones Si se presenta algún error durante la generación del constructor el caso de prueba termina.
Observaciones Ninguna
Instancias de Prueba
No. de Instancia Valor Resultado Esperado
Instancia 1 Se solicita la creación de un constructor sin parámetros.
La clase de Java contiene un constructor correcto y sin parámetros.
Instancia 2 Se solicita la creación de un constructor con parámetros.
La clase de Java contiene un constructor correcto y con parámetros.
Instancia 2 Se solicita la copia de un constructor.
La clase de Java contiene una copia del constructor de la clase especificada.
6.5.5 MOO2MVA-CP-05
Número/Nombre Prueba: MOO2MVA-CP-05
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se realiza correctamente la reubicación de atributos.
Condiciones de Ambiente Ninguna.
Entrada Clase de Java en la cual se desean copiar los atributos y la tabla “Variables MVA” con registros que en la columna “Clase” coincidan con el nombre del archivo java.
Resultados Esperados Código Java con la reubicación de atributos realizada correctamente.
Procedimiento de la Prueba
1. Inicio. 2. Se solicita la reubicación de atributos. 3. Se realiza la reubicación de atributos. 4. Fin.
Cursos Alternos
Curso alterno 1 3. Ocurre algún error durante la reubicación de atributos. 4. La herramienta notifica del error. 5. Fin.
Excepciones
Post-condiciones Si se presenta algún error durante la reubicación de atributos se notifica del error entonces el caso de prueba termina.
Pruebas del Sistema
89
6.5.6 MOO2MVA-CP-06
Número/Nombre Prueba: MOO2MVA-CP-06
Autor Luz Christina Gaitán Torres Fecha 28 de septiembre de 2011
Tipo de prueba Prueba de aceptación.
Objetivo Comprobar que se crean correctamente funciones con y sin parámetros.
Condiciones de Ambiente Ninguna.
Entrada Clase de Java en la cual se desea crear la función firma de la función, especificador de acceso de la función, parte del patrón MVA a la que pertenece la función, el tipo de retorno y en caso de que sea necesario la variable o valor de retorno y un vector con los estatutos de la función.
Resultados Esperados La clase de Java contiene la función que ha solicitado.
Procedimiento de la Prueba
1. Inicio. 2. Se solicita la creación de una función. 3. Se crea la función. 4. Se copian los estatutos en la función. 5. Fin.
Cursos Alternos
Curso alterno 1 3. Ocurre algún error durante la creación de la función. 4. La herramienta notifica del error. 5. Fin.
Curso alterno 1 4. Ocurre algún error al copiar los estatutos a la función. 5. La herramienta notifica del error. 6. Fin.
Excepciones
Post-condiciones Si se presenta algún error durante la creación de la función o al copiar los estatutos en la misma, entonces se notifica del error y el caso de prueba termina.
Observaciones Ninguna
Instancias de Prueba
No. de Instancia Valor Resultado Esperado
Instancia 1 Se solicita la creación de una función sin parámetros.
La clase de Java contiene una función sin parámetros generada correctamente.
Instancia 2 Se solicita la creación de una función con parámetros.
La clase de Java contiene una función con parámetros generada correctamente.
Capítulo 6
90
6.6 Resultados de las Pruebas
En la Tabla 11 se muestran los resultados obtenidos de las pruebas al ejecutar cada uno de los
casos de prueba especificados en MOO2MVA-CP-01, MOO2MVA-CP-02, MOO2MVA-CP-03,
MOO2MVA-CP-04, MOO2MVA-CP-05, MOO2MVA-CP-06. Los diseños de prueba fueron
elaborados con el propósito de comprobar que los métodos implementados actualmente en la
herramienta MOO2MVA funcionan correctamente.
Los casos de prueba MOO2MVA-CP-02, MOO2MVA-CP-03 y MOO2MVA-CP-06 fueron
probados con varias instancias, esto con el propósito de verificar que sus salidas fueran correctas
con las diferentes entradas y usos que se les pueden dar.
Un aspecto importante a probar, además de la ejecución de los métodos, fue el correcto
almacenamiento de la información en las tablas de la base de datos correspondientes. Esto fue
probado en los casos de prueba MOO2MVA-CP-01, MOO2MVA-CP-02 y MOO2MVA-DP-06.
La tabla a continuación resume los resultados obtenidos durante la ejecución de las
pruebas.
Tabla 11. Resumen de los resultados obtenidos en las pruebas
Identificador Ejecución Almacenamiento de información en la Base de Datos
MOO2MVA-CP-01 -
MOO2MVA-CP-02 -
MOO2MVA-CP-03
Instancia 1 No aplica
Instancia 2 No aplica
Instancia 3 No aplica
Instancia 4 No aplica
Instancia 5 No aplica
Instancia 6 No aplica
Instancia 7 No aplica
Instancia 8 No aplica
Instancia 9 No aplica
MOO2MVA-CP-04
Instancia 1 No aplica
Instancia 2 No aplica
Instancia 3 No aplica
MOO2MVA-CP-05 - No aplica
MOO2MVA-CP-06 Instancia 1
Instancia 2
Pruebas del Sistema
91
6.7 Análisis de Resultados
Al realizar cada uno de los casos de prueba especificados en MOO2MVA-CP-01, MOO2MVA-CP-02,
MOO2MVA-CP-03, MOO2MVA-CP-04, MOO2MVA-CP-05, MOO2MVA-CP-06 se probaron los
métodos implementados hasta el momento en la herramienta MOO2MVA. Estos métodos son: R1:
Además, con la implementación del método R1: “Analizar código legado”, fue necesaria la
elaboración de una tabla de símbolos, la cual puede ser utilizada para otros proyectos agregándole
información de acuerdo a las nuevas necesidades. Esta es una de las ventajas de que el proceso de
creación de la tabla de símbolos se encuentre separado del proceso de etiquetación de código
dentro del método R1.
Por lo anterior, se puede afirmar que la herramienta MOO2MVA lleva a cabo
satisfactoriamente una primera aproximación hacia la automatización del proceso de
refactorización, y que puede servir como base para trabajos futuros en los que se implementen los
métodos restantes para completar este proceso.
7.2 Trabajos futuros
Como trabajo futuro se propone continuar con el desarrollo de los métodos pendientes de ser
implementados, estos son: R6: “Reestructurar clases”, R8: “Coordinador de la creación de clases”,
R9: "Reubicar funciones especializadas", R10: "Fragmentar funciones no especializadas" y el R11:
"Redefinir llamadas a funciones".
Además, el método R1: “Analizar código legado” debe ser probado ampliamente con
código que incluya interfaces gráficas de usuario, con objetos y clases pertenecientes a las librerías
java.awt y java.swing para comprobar su correcto funcionamiento, y en caso de ser necesario,
realizar las modificaciones que estos nuevos casos necesiten.
Una vez implementados todos los métodos y haber probado el método R1: “Analizar
código legado” con código que incluya interfaces gráficas de usuario, se deberá realizar una etapa
extensiva de pruebas para validar que el resultado de la refactorización conserve la misma
funcionalidad que el código original.
Bibliografía
97
Bibliografía
[ABAD,08] Abadi, A., Ettinger, R., & Feldman, Y. A. (2008). Re-Approaching the Refactoring Rubicon. Recuperado el 15 de Marzo de 2011, de ACM Digital Library: http://dl.acm.org/citation.cfm?id=1636652
[AHO,98] Aho, A. V., Lam, M. S., Sethi, R., & Ullman, J. D. (1998). Compilers: Principles, Techniques, and Tools. Pearson Education, Inc.
[ANTL,09] ANTLR v3. (11 de Marzo de 2009). Grammar List. Recuperado el 6 de Julio de 2011, de ANTLR v3: http://www.antlr.org/grammar/list
[ANTL,10] ANTLR v3. (22 de Diciembre de 2010). Recuperado el 23 de Junio de 2011, de http://www.antlr.org/: http://www.antlr.org/
[AVER,01] Aversano, L., Canfora, G., Cimitile, A., & De Lucia, A. (15 de Marzo de 2001). Migrating Legacy Systems to the Web: An Experience Report. Recuperado el 14 de Noviembre de 2010, de IEEE Xplore: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=914979
[BODH,02] Bodhuin, T., Guardabascio, E., & Tortorella, M. (2002). Migrating COBOL Systems to the WEB by using MVC Design Pattern. Ninth Working Conference on Reverse Engineering (págs. 329-338). Richmond, VA, USA: IEEE CS Press.
[BOOD,06] Boodhoo, J.-P. (Agosto de 2006). Model View Presenter. Recuperado el 2 de Diciembre de 2011, de MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
[BOSC,97] Bosch, J., Molin, P., Mattsson, M., & Bengtsson, P. (1997). Object-Oriented Frameworks - Problems & Experiences. Sweden: Department of Computer Science and Business Administration, University of Karlskrona/Ronneby.
[BUNG,11] Bungee Connect. (2011). Bungee Connect and Model-View-Adapter (MVA). Recuperado el 04 de Diciembre de 2011, de Bungee Connect: http://www.bungeeconnect.com/img/whitepaper-mva_090803.pdf
[BUST,03] Bustamante, L. C. (2003). Reestructuración de código legado a partir del comportamiento para la generación de componentes reutilizables. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.
[CUNN,05] Cunningham & Cunningham, Inc. (31 de Mayo de 2005). Model Delegate. Recuperado el 4 de Diciembre de 2011, de Cunningham & Cunningham, Inc.: http://c2.com/cgi/wiki?ModelDelegate
[DEIT,08] Deitel, P. J., & Deitel, H. M. (2008). Cómo programar en Java. Naucalpan de Juárez, Estado de México, México: Pearson Educación.
Bibliografía
98
[DIRE,11] Dirección General de Educación Superior Tecnológica . (Septiembre de 2011). Traductores y Compiladores. Recuperado el 06 de Diciembre de 2011, de Instituto Tecnológico de Celaya: http://www.iqcelaya.itc.mx/~vicente/Programacion/TradComp.pdf
[DIST,06] Distante, D., Tilley, S., & Canfora, G. (2006). Towards a Holistic Approach to Redesigning Legacy Applications for the Web with UWAT+. 10th Conference on Software Maintenance and Reengineering (págs. 295-299). Bari, Italy: IEEE CS Press.
[FAYA,97] Fayad, M. E., & Schmidt, D. C. (10 de Octubre de 1997). Object-Oriented Application Frameworks. Special Issue on Object-Oriented. Communications of the ACM.
[FAYA,00] Fayad, M. E., & Jhonson, R. E. (2000). Domain-Specific Application Frameworks: Frameworks Experience by Industy. (M. Spencer, Ed.) New York: Jhon Wiley & Sons, Inc.
[FOWL,99] Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refactoring: Improving the Design of Existing Code. Addison Wesley.
[GOSL,05] Gosling, J., Joy, B., Steele, G., & Bracha, G. (2005). The Java™ Language Specification. Santa Clara, California, U.S.A.: Addison-Wesley.
[GULZ,02] Gulzar, N. (4 de Noviembre de 2002). Fast Track to Struts: What id Does and How. Recuperado el 18 de Febrero de 2010, de TheServerSide.com: http://www.theserverside.com/
[HERN,03] Hernandez Moreno, L. A. (2003). Factorización de funciones hacia métodos de plantilla. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.
[MEND,04] Mendez, M. A. (2004). Reestructuración de software escrito por procedimientos conducido por patrones de diseño composicionales. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.
[NUÑE,08] Nuñez Ortega, E. L. (2008). Definición de método heurísticos para reestructura marcos de aplicaciones orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador. Cuernavaca, Morelos: Departamento de Ciencias Computacionales, Laboratorio de Ingeniería de Software, CENIDET.
[PARR,07] Parr, T. (2007). The Definitive ANTLR Reference. Dallas, Texas: The Pragmatic Programmers.
[PILL,06] Pillay, A. (Diciembre de 2006). Object Oriented Programming using Java. Notes for the Computer Science Module Object Oriented Programming COMP200. Durban, Sudáfrica: University of KwaZulu-Natal.
[PING,04] Ping, Y., Kostas, K., & Lau, T. C. (2004). Transforming Legacy Web Applications to
Bibliografía
99
the MVC Architecture. 11th Annual International Workshop on Software Technology and Engineering Practice (págs. 133-142). Chicago, IL, USA: IEEE CS Press. Sicilia, M. Á. (9 de Enero de 2009). ¿Qué es Reestructuración del Software? Recuperado el 23 de Septiembre de 2011, de Connexions: http://cnx.org/content/m17443/latest/
[SIML,09] Simler, K. (20 de Abril de 2009). Model-View-Adapter. Recuperado el 1 de Diciembre de 2011, de Palantir TechBlog: http://blog.palantir.com/2009/04/20/model-view-adapter/
[SMIT,09] Smith, J. (Febrero de 2009). WPF Apps With The Model-View-ViewModel Design Pattern. Recuperado el 3 de Diciembre de 2011, de MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
[SOFT,98] Software & Systems Engineering Standards Committee . (1998). IEEE Standard for Software Test Documentation. IEEE Computer Society .
[W3C,10] W3C. (06 de Mayo de 2010). Guía Breve de Servicios Web. Recuperado el 06 de Septiembre de 2010, de W3C World Wide Web Consortium: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Anexo A: Métodos de Reestructura
101
Anexo A: Métodos de Reestructura
En este anexo se presentan los pasos a seguir para los métodos R1: “Analizar código legado”, R2:
8. Abrir la carpeta que contiene todos los archivos del código legado del marco orientado a objetos a analizar.
9. Mientras haya archivos para analizar en la carpeta:
mientras(not carpeta vacía)haz
9.1. Inicializar los contadores:
cm 0, cv 0, cc 0, cFa 0, cFMZ 0, cFM 0, cFC 0, cFV 0
9.2. Abrir un archivo de la carpeta.
9.3. Mientras no sea fin del archivo:
Anexo A: Métodos de Reestructura
102
mientras(not EOF)haz
9.3.1. Leer un estatuto
e estatuto
9.3.2. Mientras no sea fin de la clase:
mientras(e≠})haz
9.3.2.1. Si el estatuto es una sentencia “import”:
si(e==E1)entonces
9.3.2.1.1. Etiquetar el estatuto con la etiqueta “Im” (importación de archivos):
estatuto estatuto+”//Im”
fin_si //(9.3.2.1)
9.3.2.2. Si el estatuto es una sentencia “package” (definición de paquete): si(e==E2)entonces
9.3.2.2.1. Guardar el nombre del paquete: paquete nombre del paquete al que pertenece la clase
fin_si //(9.3.2.2) 9.3.2.3. Si el estatuto es una definición de clase:
si(e==E3∨e==E4∨e==E5)entonces
9.3.2.3.1. Si la clase no pertenece a algún paquete:
si(paquete==” “)entonces
9.3.2.3.1.1. Definir el nombre del paquete al que pertenece la clase:
paquete nombre del paquete
fin_si //(9.3.2.3.1)
9.3.2.3.2. Llenar la tabla “Tipos de clases” con los siguientes datos de la clase:
nombre de la clase, paquete, tipo de la clase, cláusula de relación1, clase_base1, cláusula de relación2, clase_base2
9.3.2.3.3. Asignar el nombre de la clase a la variable nomclase:
nomclase nombre de la clase en estudio
fin_si //(9.3.2.3)
9.3.2.4. Si el estatuto es una declaración de atributos (variables de instancia) o un estatuto de declaración de objetos:
si(e==E6⋁e==E15)entonces
9.3.2.4.1. Abrir la tabla “Tipos de Variables”.
9.3.2.4.2. Llenar el registro de la tabla con los datos:
Identificador de la variable, tipo de la variable, especificador de acceso, nombre de la clase a la que pertenece la variable.
9.3.2.4.3. Cerrar la tabla “Tipos de Variables”.
fin_si //(9.3.2.4)
9.3.2.5. Si el estatuto es una declaración de un método abstracto:
si(e==E16)entonces
9.3.2.5.1. Llenar los campos “Firma”, “Tipo_retorno” y “Clase”, de la tabla “Funciones abstractas”, con los siguientes datos de la función:
firma de la función, tipo de retorno de la función, nomclase
9.3.2.5.2. Escribir “Sin definir” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones abstractas”.
9.3.2.5.3. Incrementar el contador de funciones abstractas:
cFa cFa+1
fin_si //(9.3.2.5)
9.3.2.6. Si el estatuto es una definición de constructores:
si(e==E7∨e==E8)entonces
9.3.2.6.1. Obtener la firma del constructor:
firma firma del constructor
Anexo A: Métodos de Reestructura
103
9.3.2.6.2. Etiquetar el estatuto con la etiqueta “C” (constructor):
estatuto estatuto+”//C”
9.3.2.6.3. Recorrer el cuerpo de sentencias del constructor:
do{
9.3.2.6.3.1. Leer el siguiente estatuto del cuerpo del constructor:
e sig.estatuto
9.3.2.6.3.2. Si el estatuto es una asignación para inicializar atributos:
si(e==E12⋁e==E12+E18)entonces
9.3.2.6.3.2.1. Obtener el identificador del atributo:
identificador identificador de la variable
9.3.2.6.3.2.2. Inicializar el valor de la variable i:
i 0
9.3.2.6.3.2.3. Abrir la tabla “Tipos de variables”.
9.3.2.6.3.2.4. Buscar los datos del atributo inicializado en el constructor:
mientras(Tipos de variables[i].Identificador≠identificador⋀Tipos de variables[i].Clase≠nomclase)haz
9.3.2.6.3.2.4.1. Si el atributo ya está registrado en la tabla:
si(Tipos de variables[i].Identificador==identificador⋀Tipos de variables[i].Clase==nomclase)entonces
9.3.2.6.3.2.4.1.1. Obtener los datos del atributo:
tipo Tipos de Variables[i].Tipo
especificador Tipos de Variables[i].Especificador
9.3.2.6.3.2.4.1.2. Si el constructor es la primera función que utiliza el atributo:
si(Tipos de variables[i].Firma_función==” “)entonces
9.3.2.6.2.2.5.1.1.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor:
Tipos de variables[i].Firma_función firma
Tipos de variables[i].Clase_Función nomclase
si no
9.3.2.6.2.2.5.1.1.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor con los datos:
identificador, tipo, especificador, clase de la variable, firma, nomclase
fin_si //(9.3.2.6.3.2.4.1.2)
si no
9.3.2.6.3.2.4.1.3. Incrementar el valor de la variable i:
i i+1
fin_si //(9.3.2.6.3.2.4.1)
fin_mientras //(9.3.2.6.3.2.4)
fin_si //(9.3.2.6.3.2)
9.3.2.6.3.3. Si el estatuto es una asignación por medio de una llamada a un método o una llamada al constructor de la clase base:
si(e==E12+E18∨e==E18)entonces
9.3.2.6.3.3.1. Etiquetar el estatuto con la etiqueta “EI” (estatuto de invocación):
estatuto estatuto+”//EI”
fin_si //(9.3.2.6.3.3)
}while(e≠}) //(9.3.2.6.3)
Anexo A: Métodos de Reestructura
104
9.3.2.6.4. Si el estatuto es una llave de fin de método:
si(e==})entonces
9.3.2.6.4.1. Etiquetar el estatuto con la etiqueta “ff” (fin de función):
estatuto estatuto+”//ff”
fin_si //(9.3.2.6.4)
fin_si //(9.3.2.6)
9.3.2.7. Si el estatuto es una definición de métodos:
si(e==E9∨e==E10)entonces
9.3.2.7.1. Llenar la tabla “Funciones concretas” con los siguientes datos de la función:
firma de la función, tipo de retorno, nomclase
9.3.2.7.2. Recorrer el cuerpo de sentencias del método:
mientras(e≠})haz
9.3.2.7.2.1. Leer el siguiente estatuto:
e siguiente estatuto
9.3.2.7.2.2. Si el estatuto es una declaración de variables locales, o una asignación, o un estatuto de repetición, o un estatuto de impresión, o un estatuto condicional, o un estatuto de invocación, o un estatuto selectivo, o un estatuto de devolución, o un estatuto de bloque:
9.3.2.7.2.2.1.1. Obtener el identificador de la variable modificada en el estatuto de asignación:
identificador identificador de la variable del estatuto de asignación
9.3.2.7.2.2.1.2. Obtener la firma de la función:
firma firma de la función en estudio
9.3.2.7.2.2.1.3. Inicializar el valor de la variable i:
i 0
9.3.2.7.2.2.1.4. Abrir la tabla “Tipos de variables”.
9.3.2.7.2.2.1.5. Buscar los datos de la variable modificada en el estatuto de asignación:
mientras(Tipos de variables[i].Identificador≠identificador⋀Tipos de variables[i].Clase≠nomclase)haz
9.3.2.7.2.2.1.5.1. Si la variable ya está registrado en la tabla:
si(Tipos de variables[i].Identificador==identificador⋀Tipos de variables[i].Clase==nomclase)entonces
9.3.2.7.2.2.1.5.1.1 Obtener los datos de la variable:
tipo Tipos de Variables[i].Tipo
especificador Tipos de Variables[i].Especificador
9.3.2.7.2.2.1.5.1.2 Si la función es la primera que accede a la variable:
si(Tipos de variables[i].FirmaFunción==” “)entonces
9.3.2.7.2.2.1.5.1.2.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor:
Tipos de variables[i] firma
si no
Anexo A: Métodos de Reestructura
105
9.3.2.7.2.2.1.5.1.2.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde a la variable modificada en el estatuto de asignación con los datos:
identificador, tipo, especificador, nomclase, firma
fin_si //(9.3.2.7.2.2.1.5.1.2)
si no
9.3.2.7.2.2.1.5.1.3 Incrementar el valor de la variable i:
i i+1
fin_si //(9.3.2.7.2.2.1.5.1)
fin_mientras //(9.3.2.7.2.2.1.5)
fin_si //(9.3.2.7.2.2.1)
9.3.2.7.2.2.2. Si el estatuto pertenece al Modelo:
si(e pertenece al modelo)entonces
9.3.2.7.2.2.2.1. Etiquetar el estatuto con la etiqueta “//EM” (estatuto del modelo):
estatuto estatuto+”//EM”
9.3.2.7.2.2.2.2. Incrementar el contador de estatutos del modelo:
cm cm+1
fin_si //(9.3.2.7.2.2.2)
9.3.2.7.2.2.3. Si el estatuto pertenece al Control:
si(e pertenece al control)entonces
9.3.2.7.2.2.3.1. Etiquetar el estatuto con la etiqueta “//EC” (estatuto del control):
estatuto estatuto+”//EC”
9.3.2.7.2.2.3.2. Incrementar el contador de estatutos del control:
cc cc+1
fin_si //(9.3.2.7.2.2.3)
9.3.2.7.2.2.4. Si el estatuto pertenece a la Vista:
si(e pertenece a la vista)entonces
9.3.2.7.2.2.4.1. Etiquetar el estatuto con la etiqueta “//EV” (estatuto de la vista):
estatuto estatuto+”//EV”
9.3.2.7.2.2.4.2. Incrementar el contador de estatutos de la vista:
cv cv+1
fin_si //(9.3.2.7.2.2.4)
9.3.2.7.2.2.5. Si el estatuto es una asignación por medio de una llamada a un método, o si es una llamada a un método:
si(e==E18∨e==E12+E18)entonces
9.3.2.7.2.2.5.1. Etiquetar el estatuto con la etiqueta “//EI” (estatuto de invocación):
estatuto estatuto+”//EI”
fin_si //(9.3.2.7.2.2.5)
9.3.2.7.2.2.6. Si el estatuto es un bloque de repetición o condicional, o es un estatuto selectivo, o es un estatuto de bloque:
si(e==E13+”{“∨e==E17+”{“∨e==E19∨e==E21)entonces
9.3.2.7.2.2.6.1. Recorrer el cuerpo de sentencias del bloque:
mientras(e≠})haz
9.3.2.7.2.2.6.1.1. Si el estatuto es una asignación:
si(e==E12⋁e==E12+E18)entonces
9.3.2.7.2.2.6.1.1.1 Obtener el identificador de la variable modificada en el estatuto de asignación:
Anexo A: Métodos de Reestructura
106
identificador identificador de la variable del estatuto de asignación
9.3.2.7.2.2.6.1.1.2 Obtener la firma de la función:
firma firma de la función en estudio
9.3.2.7.2.2.6.1.1.3 Inicializar el valor de la variable i:
i 0
9.3.2.7.2.2.6.1.1.4 Abrir la tabla “Tipos de variables”.
9.3.2.7.2.2.6.1.1.5 Buscar los datos de la variable modificada en el estatuto de asignación:
mientras(Tipos de variables[i].Identificador≠identificador
⋀Tipos de variables[i].Clase≠nomclase)haz
9.3.2.7.2.2.6.1.1.5.1 Si la variable ya está registrado en la tabla:
si(Tipos de variables[i].Identificador==identificador
⋀Tipos de variables[i].Clase==nomclase)entonces
9.3.2.7.2.2.6.1.1.5.1.1 Obtener los datos de la variable:
tipo Tipos de Variables[i].Tipo
especificador Tipos de Variables[i].Especificador
9.3.2.7.2.2.6.1.1.5.1.2 Si la función es la primera que accede a la variable:
si(Tipos de variables[i].FirmaFunción==” “)entonces
9.3.2.7.2.2.6.1.1.5.1.2.1 Llenar el campo “FirmaFunción” de la tabla “Tipos de variables” que corresponde al atributo inicializado en el constructor:
Tipos de variables[i] firma
si no
9.3.2.7.2.2.6.1.1.5.1.2.2 Llenar un nuevo registro de la tabla “Tipos de variables” que corresponde a la variable modificada en el estatuto de asignación con los datos:
identificador, tipo, especificador, nomclase, firma
fin_si //(9.3.2.7.2.2.6.1.1.5.1.2)
si no
9.3.2.7.2.2.6.1.1.5.1.3 Incrementar el valor de la variable i:
i i+1
fin_si //(9.3.2.7.2.2.6.1.1.5.1)
fin_mientras //(9.3.2.7.2.2.6.1.1.5)
fin_si //(9.3.2.7.2.2.6.1.1)
9.3.2.7.2.2.6.1.2. Si el estatuto pertenece al Modelo:
si(e pertenece al modelo)entonces
9.3.2.7.2.2.6.1.2.1 Etiquetar el estatuto con la etiqueta “//EM” (estatuto del modelo):
estatuto estatuto+”//EM”
9.3.2.7.2.2.6.1.2.2 Incrementar el contador de estatutos del modelo:
cm cm+1
fin_si //(9.3.2.7.2.2.6.1.2)
9.3.2.7.2.2.6.1.3. Si el estatuto pertenece al Control: si(e pertenece al control)entonces
Anexo A: Métodos de Reestructura
107
9.3.2.7.2.2.6.1.3.1 Etiquetar el estatuto con la etiqueta “//EC” (estatuto del control):
estatuto estatuto+”//EC”
9.3.2.7.2.2.6.1.3.2 Incrementar el contador de estatutos del control:
cc cc+1
fin_si //(9.3.2.7.2.2.6.1.3)
9.3.2.7.2.2.6.1.4. Si el estatuto pertenece a la Vista:
si(e pertenece a la vista)entonces
9.3.2.7.2.2.6.1.4.1 Etiquetar el estatuto con la etiqueta “//EV” (estatuto de la Vista):
estatuto estatuto+”//EV”
9.3.2.7.2.2.6.1.4.2 Incrementar el contador de estatutos de la vista:
cv cv+1
fin_si //(9.3.2.7.2.2.6.1.4)
9.3.2.7.2.2.6.1.5. Si el estatuto es una asignación por medio de una llamada a un método, o es una llamada a un método:
si(e==E18∨e==E12+E18)entonces
9.3.2.7.2.2.6.1.5.1 Etiquetar el estatuto con la etiqueta “//EI” (estatuto de invocación):
estatuto estatuto+”//EI”
fin_si //(9.3.2.7.2.2.6.1.5)
9.3.2.7.2.2.6.1.6. Leer el siguiente estatuto: e siguiente estatuto
fin_mientras //(9.3.2.7.2.2.6.1)
9.3.2.7.2.2.6.2. Si el estatuto es una llave de fin de bloque:
si(e==})entonces
9.3.2.7.2.2.6.2.1. Etiquetar el estatuto con la etiqueta “//fe” (fin de estatuto de bloque):
estatuto estatuto+”//fe”
fin_si //(9.3.2.7.2.2.6.2)
fin_si //(9.3.2.7.2.2.6)
fin_si //(9.3.2.7.2.2)
fin_mientras //(9.3.2.7.2)
9.3.2.7.3. Si el estatuto es una llave de fin de método:
si(e==})entonces
9.3.2.7.3.1. Etiquetar el estatuto con la etiqueta “//ff” (fin de función):
9.3.2.7.3.2.1. Etiquetar la función con la etiqueta “//FMZ” (función no-especializada)
9.3.2.7.3.2.2. Escribir “No especializada” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.
9.3.2.7.3.2.3. Incrementar el contador de funciones no especializadas:
cFMZ cFMZ+1
9.3.2.7.3.2.4. Inicializar los contadores:
cm 0, cv 0, cc 0
Anexo A: Métodos de Reestructura
108
9.3.2.7.3.3. Si la función es especializada:
si no
9.3.2.7.3.3.1. Si la función es del Modelo:
si(cm≠0⋀cc==0⋀cv==0)entonces
9.3.2.7.3.3.1.1. Etiquetar función con la etiqueta “//FM” (función del modelo).
9.3.2.7.3.3.1.2. Escribir “Modelo” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.
9.3.2.7.3.3.1.3. Incrementar el contador de funciones del modelo:
cFM cFM+1
9.3.2.7.3.3.1.4. Inicializar el contador de estatutos del modelo:
cm 0
9.3.2.7.3.3.2. Si la función no es del modelo:
si no
9.3.2.7.3.3.2.1. Si la función es del control:
si(cm==0⋀cc≠0⋀cv==0)entonces
9.3.2.7.3.3.2.1.1. Etiquetar la función con “//FC”.
9.3.2.7.3.3.2.1.2. Escribir “Control” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.
9.3.2.7.3.3.2.1.3. Incrementar el contador de funciones del control:
cFC cFC+1
9.3.2.7.3.3.2.1.4. Inicializar el contador de estatutos del control:
cc 0
9.3.2.7.3.3.2.2. Si la función no es del control:
si no
9.3.2.7.3.3.2.2.1. Si la función es de la vista:
si(cm==0⋀cc==0⋀cv≠0)entonces
7.3.2.5.3.3.2.2.1.1. Etiquetar la función con “//FV”
7.3.2.5.3.3.2.2.1.2. Escribir “Vista” en el campo “Patrón_MVC” del registro correspondiente a la función en estudio, de la tabla “Funciones concretas”.
7.3.2.5.3.3.2.2.1.3. Incrementar el contador de funciones de la vista:
cFV cFV+1
7.3.2.5.3.3.2.2.1.4. Inicializar el contador de estatutos de la vista:
ce 0, cv 0
fin_si //(9.3.2.7.3.3.2.2.1)
fin_si //(9.3.2.7.3.3.2.1)
fin_si //(9.3.2.7.3.3.1)
fin_si //(9.3.2.7.3.2)
fin_si //(9.3.2.7.3)
fin_si //(9.3.2.7)
9.3.2.8. Leer el siguiente estatuto:
e sig.estatuto
fin_mientras //(9.3.2)
9.3.3. Si el estatuto es una llave de fin de clase:
si(e==})entonces
Anexo A: Métodos de Reestructura
109
9.3.3.1. Etiquetar el estatuto con la etiqueta “fc” (fin de clase):
estatuto estatuto+”//fc”
9.3.3.2. Si la clase en estudio es abstracta: si(cFa≠0)entonces
9.3.3.2.1. Escribir “Sin definir” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.
fin_si //(9.3.3.2) 9.3.3.3. Si la clase en estudio es no-especializada:
si((cFMZ≠0)⋁(cFM≠0⋀(cFC≠0∨cFV≠0)))entonces
9.3.3.3.1. Etiquetar la clase con la etiqueta “//CMZ” (clase no-especializada).
9.3.3.3.2. Escribir “No especializada” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.
9.3.3.4. Si la clase en estudio es especializada:
si no
9.3.3.4.1. Si la clase en estudio es del Modelo:
si(cFMZ==0⋀cFM≠0⋀cFC==0⋀cFV==0)entonces
9.3.3.4.1.1. Etiquetar la clase con la etiqueta “//CM” (clase del modelo).
9.3.3.4.1.2. Escribir “Modelo” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.
si no
9.3.3.4.1.3. Si la clase en estudio es del Control:
si(cFMZ==0⋀cFM==0⋀cFC≠0⋀cFV==0)entonces
9.3.3.4.1.3.1. Etiquetar la clase con la etiqueta “//CC” (clase del control).
9.3.3.4.1.3.2. Escribir “Control” en el campo “Patrón_MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.
si no
9.3.3.4.1.3.3. Si la clase en estudio es de la Vista:
si(cFMZ==0⋀cFM==0⋀cFC==0⋀cFV≠0)entonces
9.3.3.4.1.3.3.1. Etiquetar la clase con la etiqueta “//CV” (clase de la vista).
9.3.3.4.1.3.3.2. Escribir “Vista” en el campo “Patrón _MVC” del registro correspondiente a la clase en estudio, de la tabla “Tipos de clases”.
fin_si //(9.3.3.4.1.3.3)
fin_si //(9.3.3.4.1.3)
fin_si //(9.3.3.4.1)
fin_si //(9.3.3.3)
fin_si //(9.3.3)
fin_mientras //(9.3)
fin_mientras //(9)
10. Inicializar las variables:
i 0, j 0, Clases[] ” “, nomclase ” “, patron ” “, firma ” “, numreg 0, band ”“
11. Abrir la tabla “Funciones concretas”.
12. Recorrer la tabla:
mientras(not EOF(Funciones concretas))haz
12.1. Obtener los datos de una función concreta:
firma Funciones concretas[i].Firma
nomclase Funciones concretas[i].Clase
Anexo A: Métodos de Reestructura
110
patron Funciones concretas[i].Patrón_MVC
12.2. Inicializar la variable k:
k 0
12.3. Abrir la tabla “Tipos de clases”.
12.4. Recorrer la tabla “Tipos de clases”:
mientras(nomclase≠” “)haz
12.4.1. Buscar la jerarquía de clases a la que pertenece la función concreta en estudio:
si(Tipos de clases[j].Nombre==nomclase)entonces
12.4.1.1. Verificar si la clase extiende o implementa a una clase base:
si(Tipos de clases[j].Clase_base1≠” “)entonces
12.4.1.1.1. Almacenar en un arreglo la jerarquía de clases a la que pertenece la función concreta en estudio:
Clases[k] Tipos de clases[j].Clase_base1
12.4.1.1.2. Obtener la siguiente clase base de la jerarquía de clases:
nomclase Tipos de clases[j].Clase_base1
12.4.1.1.3. Actualizar las variable k y j:
k k+1
j 0
12.4.1.2. Si la clase no extiende o implementa a una clase base: si no
12.4.1.2.1. Inicializar la variable nomclase: nomclase ” “
fin_si //(12.4.1.1)
12.4.2. Si la clase registrada en la tabla no pertenece a la jerarquía de clases de la función concreta en estudio:
si no
12.4.2.1. Incrementar el valor de la variable j:
j j+1
fin_si //(12.4.1)
fin_mientras //(12.4)
12.5. Inicializar variables:
numreg sizeof(Clases), j 0, k 0
12.6. Recorrer la jerarquía de clases a la que pertenece la función concreta en estudio:
mientras(k<numreg)haz
12.6.1. Obtener una clase del arreglo que almacena la jerarquía de clases:
nomclase Clases[k]
12.6.2. Limpiar la casilla del arreglo:
Clases[k] ” “
12.6.3. Actualizar las variables k y band:
k k+1, band false
12.6.4. Abrir la tabla “Funciones abstractas”.
12.6.5. Recorrer la tabla:
mientras(band==false)entonces
12.6.5.1. Buscar la función abstracta que implementa la función concreta en estudio:
12.6.5.1.1.1. Etiquetar la función abstracta, de acuerdo a la parte del patrón MVC a la que pertenece la función concreta que la implementa:
Anexo A: Métodos de Reestructura
111
Funciones abstractas[j].Patrón_MVC patron
12.6.5.1.1.2. Abrir el archivo <nomclase>.java y etiquetar el código de la declaración de la función abstracta, con la etiqueta correspondiente a la parte del patrón MVC al que pertenece.
fin_si //(12.6.5.1.1)
12.6.5.1.2. Modificar el valor de las variables band y j:
band true, j 0
12.6.5.2. Si la firma y la clase de pertenencia de la función registrada en la tabla no corresponden con la firma y la clase buscadas:
si no
12.6.5.2.1. Incrementar el valor de la variable j para continuar la búsqueda:
15.4.1. Si la clase en estudio es no especializada:
si((cFMZ≠0)⋁(cFM≠0⋀(cFV≠0⋁cFC≠0))entonces
15.4.1.1. Modificar la variable patron:
patron ”No especializada”
15.4.1.2. Inicializar los contadores de funciones:
cFMZ 0, cFM 0, cFV 0, cFc 0
si no
15.4.1.3. Si la clase en estudio es del modelo:
si(cFMZ==0⋀cFM≠0⋀cFv==0⋀cFc==0)entonces
15.4.1.3.1. Modificar la variable patrón:
patron ”Modelo”
15.4.1.3.2. Inicializar el contador de funciones del modelo:
cFM 0
si no
15.4.1.3.3. Si la clase en estudio es de la vista: si(cFM==0⋀cFv≠0⋀cFc==0⋀cFMZ==0)entonces
15.4.1.3.3.1. Modifica la variable patrón:
patron ”Vista”
15.4.1.3.3.2. Inicializar el contador de funciones de la vista:
cFv 0
si no
15.4.1.3.3.3. Si la clase en estudio es del control:
si(cFM==0⋀cFv==0⋀cFc≠0⋀cFMZ==0)entonces
15.4.1.3.3.3.1. Modificar la variable patrón:
patron ”Control”
15.4.1.3.3.3.2. Inicializar el contador de funciones del control:
cFc 0
fin si //(15.4.1.3.3.3)
fin_si //(15.4.1.3.3)
fin_si //(15.4.1.3)
fin_si //(15.4.1)
15.4.2. Abrir la tabla “Tipos de clases”.
15.4.3. Inicializar variables:
k 0, band false
15.4.4. Recorrer la tabla:
mientras(band==false)haz
15.4.4.1. Buscar el registro de la clase en estudio:
si(Tipos de clases[k].Nombre==nomclase)entonces
15.4.4.1.1. Verificar que la clase no haya sido etiquetada previamente:
si(Tipos de clases[k].Patrón_MVC==”Sin definir”)entonces
15.4.4.1.1.1. Etiquetar la clase:
Tipos de clases[k].Patrón_MVC patron
15.4.4.1.1.2. Abrir el archivo <nomclase>.java que contiene el código de la clase, del marco orientado a objetos original, y etiquetar la declaración de la clase con la etiqueta que corresponda (“//CM” si la clase pertenece al modelo, “//CV” si la clase pertenece a la vista, “//Cc” si la clase pertenece al control o “//CMZ” si la clase es No especializada).
Anexo A: Métodos de Reestructura
113
fin_si //(15.4.4.1.1)
15.4.4.1.2. Modificar el valor de la variable band:
band true
si no
15.4.4.1.3. Incrementar el valor de la variable k:
k k+1
fin_si //(15.4.4.1)
fin_mientras //(15.4.4)
15.4.5. Modificar el valor de la variable i:
i j
fin_si //(15.4)
fin_mientras //(15)
16. Termina el método de reestructura R1.
Método de reestructura R7: “Estructura jerárquica de clases”
Parámetros de entrada: ninguno
1. Inicio.
2. Crear la tabla “Jerarquía de clases” con los siguientes campos:
Clase_padre, Clase_hija
3. Inicializar variables:
i 0, clasepadre ” “, band false, h 0, k 0, j 0, numreg sizeof(Tipos de clases)
4. Abrir la tabla “Tipos de clases”.
5. Recorrer la tabla “Tipos de clases” para obtener la arquitectura de clases del marco orientado a objetos original:
mientras(k<=numreg)haz
5.1. Buscar una clase padre:
mientras(clasepadre==” “)haz
5.1.1. Verificar que la clase padre sea una clase raíz:
si((Tipos de clases[i].Clase_base1==” “) ⋀ (Tipos de clases[i].Clase_base2==” “))entonces
5.1.1.1. Obtener la clase raíz:
clasepadre Tipos de clases[i].Nomb_clase
si no
5.1.1.2. Incrementar la variable i:
i i+1
fin_si //(5.1.1)
fin_mientras //(5.1)
5.2. Inicializar las variables i y band:
i 0, band false
5.3. Recorrer desde el inicio la tabla “Tipos de clases” para obtener todas las subclases de la clase padre:
mientras(not EOF(Tipos de clases)haz
5.3.1. Verificar si la clase es subclase de la clase padre:
si((Tipos de clases[i].Clase_base1==clasepadre)
⋁(Tipos de clases[i].Clase_base2==clasepadre))entonces
5.3.1.1. Modificar el valor de la variable band:
band true
5.3.1.2. Registrar los datos en la tabla “Jerarquía de clases”:
Anexo A: Métodos de Reestructura
114
Jerarquía de clases[k].Clase_padre clasepadre
Jerarquía de clases[k].Clase_hija Tipos de clases[i].Nomb_clase
5.3.1.3. Incrementar la variable k:
k k+1
fin_si //(5.3.1)
5.3.2. Incrementar el valor de la variable i:
i i+1
fin_mientras //(5.3)
5.4. Si la clase padre no tiene subclases:
si((EOF(Tipos de clases)⋀(band==false))entonces
5.4.1. Registrar los datos de la clase en la tabla “Jerarquía de clases”:
Jerarquía de clases[k].Clase_padre clasepadre
Jerarquía de clases[k].Clase_hija ”Sin subclases”
5.4.2. Incrementar la variable k:
k k+1
fin_si //(5.4)
5.5. Obtener la siguiente clase padre:
haz
5.5.1. Verificar que la clase candidata sea una subclase:
si(Jerarquía de clases[h].Clase_hija≠”Sin subclases”)
5.5.1.1. Asignar a la subclase como siguiente clase padre:
clasepadre Jerarquía de clases[h].Clase_hija
5.5.1.2. Inicializar las variables j y band:
j 0, band false
5.5.1.3. Verificar que la nueva clase padre no se encuentre en la tabla
“Jerarquía de clases” como clase padre:
mientras((j<k)⋁(band==false))haz
5.5.1.3.1. Si la nueva clase padre se encuentra en la tabla “Jerarquía de
clases” como clase base:
si(Jerarquía de clases[j].Clase_padre==clasepadre)entonces
5.5.1.3.1.1. Cambiar el valor de la variable band:
band true
5.5.1.3.1.2. Incrementar el valor de la variable h:
h h+1
si no
5.5.1.3.1.3. Incrementar el valor de la variable j:
j j+1
fin_si //(5.5.1.3.1)
fin_mientras //(5.5.1.3)
5.5.1.4. Si la nueva clase padre no se encuentra en la tabla “Jerarquía de
clases” como clase base(padre?):
si((j==k)⋀(band==false))entonces
5.5.1.4.1. Incrementar la variable h:
h h+1
5.5.1.4.2. Inicializar el valor de la variable i:
i 0
Anexo A: Métodos de Reestructura
115
fin_si //(5.5.1.4)
fin_si //(5.5.1)
mientras(band==true) //(5.5)
fin_mientras //(5)
6. Termina el método de reestructura R7.
Método de reestructura R2: “Crear clases”
Parámetros de entrada: paquete, nomclase, tipo, tiporel, clasebase1, tiporel2, clasebase2
2.1. Crear una carpeta que almacene los archivos del marco orientado a objetos con
arquitectura MVC.
2.2. Abrir la carpeta que almacena los archivos del marco orientado a objetos con
arquitectura MVC.
2.3. Crear una nueva carpeta con el nombre del paquete que almacene los archivos del
marco orientado a objetos con arquitectura MVC.
fin_si //(2)
3. Abrir la carpeta con el nombre del paquete que almacena los archivos del marco orientado a
objetos con arquitectura MVC.
4. Crear un archivo de definición con extensión “.java” para la declaración de la clase, en la carpeta que almacena los archivos del marco orientado a objetos con arquitectura MVC.
5. Escribir en este archivo el texto que declara el paquete al que pertenece el archivo:
package <paquete>;
6. Escribir en este archivo el texto que declara la clase:
6.1. Si es una clase concreta:
si(tipo==”concreta”)entonces
6.1.1. Si es una clase simple:
si(tiporel==” “)entonces
6.1.1.1. Generar el siguiente código:
public class <nomclase>{
fin_si //(6.1.1)
6.1.2. Si es una clase derivada de otra:
si(tiporel==”extends”)entonces
6.1.2.1. Generar el siguiente código:
public class <nomclase> extends <clasebase1>{
fin_si //(6.1.2)
6.1.3. Si la clase implementa una interfaz: si(tiporel==”implements”)entonces
6.1.3.1. Generar el siguiente código:
public class <nomclase> implements <clasebase1>{
fin_si //(6.1.3)
6.1.4. Si es una clase derivada de otra y además implementa una interfaz: si(tiporel==”extends”⋀tiporel2==”implements”)entonces
6.1.4.1. Generar el siguiente código:
public class <nomclase> extends <clasebase1> implements <clasebase2>{
fin_si //(6.1.4)
fin_si //(6.1)
6.2. Si es una clase abstracta:
Anexo A: Métodos de Reestructura
116
si(tipo==”abstracta”)entonces
6.2.1. Si es una clase simple:
si(tiporel==” “)entonces
6.2.1.1. Generar el siguiente código:
public abstract class <nomclase>{
fin_si //(6.2.1)
6.2.2. Si la clase es derivada de otra: si(tiporel==”extends”)entonces
6.2.2.1. Generar el siguiente código:
public abstract class <nomclase> extends <clasebase1>{
fin_si //(6.2.2)
6.2.3. Si esta clase implementa una interfaz: si(tiporel==”implements”)entonces
6.2.3.1. Generar el siguiente código:
public abstract class <nomclase> implements <clasebase1>{
fin_si //(6.2.3)
fin_si //(6.2)
6.3. Si es una interfaz: si(tipo==”interface”)entonces
6.3.1. Si es una interfaz simple: si(tiporel==” “)entonces
6.3.1.1. Generar el siguiente código:
public interface <nomclase>{
fin_si //(6.3.1)
6.3.2. Si es una interfaz derivada de otra: si(tiporel==”extends”)entonces
6.3.2.1. Generar el siguiente código:
public interface <nomclase> extends <clasebase1>{
fin_si //(6.3.2)
fin_si //(6.3)
6.4. Cerrar la definición de la clase de manera apropiada, generando el siguiente código:
} //Termina <nomclase>
7. Termina método de reestructura R2.
Método de reestructura R3: “Crear constructor”
Parámetros de entrada: nomclase, claseMVA, parametros[n][3]
1. Inicio.
2. Si el constructor es un constructor simple (sin parámetros), generar el código de inicialización con valores por omisión:
public <claseMVA>(){
2.1. Para cada atributo de la clase:
2.1.1. Si el dato a inicializar en el constructor es de tipo boolean entonces generar el siguiente código:
dato=literal;
2.1.2. Si el dato a inicializar en el constructor es de tipo byte, o short, o int, o long, entonces generar el siguiente código:
dato=dígito;
2.1.3. Si el dato a inicializar en el constructor es de tipo float o double, entonces generar el siguiente código:
Anexo A: Métodos de Reestructura
117
dato=dígito.dígito;
2.1.4. Si el dato a inicializar en el constructor es de tipo char, entonces generar el siguiente código:
dato=’caracter’;
2.1.5. Si el dato a inicializar en el constructor es de tipo String, entonces generar el siguiente código:
dato=”cadena de caracteres”;
2.1.6. Si el dato a inicializar en el constructor es un objeto, entonces generar el siguiente código:
Clase obj=referencia;
2.2. Si el constructor crea objetos, generar el siguiente código:
this.obj=new <objparm[n]+”()”>;
2.3. Cerrar la definición del constructor de manera apropiada, generando el siguiente código:
} //Termina el constructor <claseMVA>
2.4. Si se desea crear otro constructor entonces ir al paso 1, si no, ir al paso 4.
3. Si el constructor es un constructor con parámetros, generar el siguiente código:
public claseMVA(<parametros[0][0] parametros[0][1]>, …, <parametros[n][0] parametros[n][1]>){
3.1. Para cada atributo declarado en la definición de la clase:
3.1.1. Si el nombre de los datos definidos en la firma del constructor son iguales a los nombres de los datos correspondientes a los atributos declarados en la definición de la clase, entonces generar el siguiente código:
this.dato1=<parametros[0][1]>;
…
this.datoN=<parametros[n][1]>;
3.1.2. Si el nombre de los datos definidos en la firma del constructor son diferentes a los nombres de los datos correspondientes a los atributos declarados en la definición de la clase, entonces generar el siguiente código:
datoAtributo1=<parametros[0][1]>;
…
datoAtributoN=<parametros[n][1]>;
3.2. Si el constructor crea objetos, generar el siguiente código: