Embed Size (px)
Citation preview
S.E.P. S.E.I.T. D.G.I.T.
Centro Nacional de Investigación y Desarrollo Tecnológico
CENIDET
Ingeniería Inversa de Código Fuente en C++ para la Obtención
de su Diseño
TESIS Que para obtener el grado de
. Maestro en Ciencias en Ciencias Computacionales
presenta: MIGUEL HERNÁNDEZ VELÁZQUEZ
Director de Tesis: M.C. MÁXIMO LÓPEZ SÁNCHEZ
Codirector de Tesis: M.C. ISAAC ALBERTO PARRA RAMÍREZ
Cuernavaca, Morelos
CENTRO DE iNFORMAClON DG'Tl s ~ p CENlDET
0 3 - 0 3 3 4 Agosto del 2003
Cuemavaca, Mor., a 18 de Agosto de 2003
Dr. Gerard0 Reyes Salgado Presidente de la' Academia de Ciencias Computacionales Presente
Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: Ingeniería Inversa de Código Fuente en C++ para la Obtención de su Disetio, realizada por ei(ia) C. Miguel Hemández Velázquez, y habiendo realizado las mrrecciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.
Sin otro particular, quedamos de usted
Atentamente
La comisión de revisión de tesis
- Dr. René Sadtaolaya Salgado (M.c. Olivia FI *a@$ Diaz
\ f
\
Luis Liñán Garcia
i /-
Codirector de tesis
C.C.P. Dr. Rodolfo A Pazos Rangel, Jefe del Depto. de Ciencias Computacionales Lic. Olivia Maquinay Díaz, Jefe del Depto. de Servicios Escolares. C. Miguel Hemández Velázquez, alumno del programa de maestría.
INTERIOR INTERNADO PALMIRA SIN, COL, PALMIRA, A.P. 5-164. CP. 62490, CUERNAVACA, MOR. - MÉXICO TELS. (777) 312 23 14,318 77 41. FAX (777) 312 24 34 FMAll nnio?Qrdrenidnt rnm my
~ ~ ~ L í E m c x . 3 N t
FORMULARIO C4 AUTORIZACIÓN DE IMPRESION DE TESIS
I u & % m 3 m % m m w
Cuernavaca, Mor., a 19 de Agosto de 2003.
C. Miguel Hemández Velázquez Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente
Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: Ingeniería Inversa de Código Fuente en C++ para la Obtención de su Diseño, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.
Jefe del Depto. de Ciencias Computacionales
C.C.P. Lic. Ohia Maquinay Diaz, Jefe Depto. de Servicios Escolares
INTERIOR INTERNADO PALMIRA S / N . COL. PALMIRA , A.P. 5-164. CP. 62490, CUERNAVACA. MOR. ~ MÉXICO TELS.(777I312 2314 .318 7741 .FAXí777 i 312 2 4 3 4
Para mís padres, para Ise, y
. parachei
Agradecimientos
Quiero expresar mi mas sincero agradecimiento a todas las personas que de alguna manera contribuyeron para finalizar este proyecto de tesis (en la lista de abajo quizá no estén todas y cada una de ellas dado que mi memoria no es precisamente de elefante y ha pasado bastante tiempo); cada quién puso una roca o un granito de arena en la conversación, en el espaldarazo, en la crítica, en lo económico, en el saludo, en el enojo, tristeza o alegría justo en el momento indicado (el orden de aparición no indica el importancia necesariamente):
A mi asesor Máximo López por toda la ayuda moral e incluso económica, consejo académico y disculpas aceptadas. Por ser un guía que no desdeña el trato humano. Por aprender a escuchar las ideas este inusual tesista. Vivan los vivos.
A Javier Ortiz pues al inicio de la maestría su apoyo fue imprescindible para emprender el reto con ánimo y esperanza. Por las concienzudas y profundas pláticas de cómo mejorar varios aspectos de este condenado país.
A René Santaolaya porque detrás de toda su bien ganada sapiencia existe un ser humano que finalmente también es capaz de escuchar. Gracias por ser un ejemplo para mi carrera profesional. La programación con objetos ya tienen sentido para mi al fin.
A Olivia Fragoso, gracias por ser una parte decisiva en mi aspiración de entrar al centro. Gracias por ser una guía en muchos aspectos extra-académicos, pero principalmente por todo el consejo durante mi transición hacia la vida como padre. La Ingeniería de Software sípuede ser divertida e int&esante, siempre y cuando se tope uno con gente como Olivia y se platique al respecto.
Al Dr. Pazos, por compartir largas conversaciones que permitieron abrir mi original ingenuo panorama sobre el conocimiento y uno que otro sabio consejo más. Por las verdaderas cátedras en el aula acerca de la Bases de Datos. Por el apoyo en general que me otorgó durante mi estancia.
A mis compañeros de-generación: Isabel - por su confianza para platicar y su apoyo inicial Gustavo - por su transparencia y calidez humana Alberto - por recordarme que la vida no debe ser tan complicada y por tener tan buenos gustos musicales Karina - por su sinceridad, femineidad y los Buffy. Laura - por mostrarme que una mujer puede representar un verdadero reto en el ámbito profesional, pero principalmente por Compartir con Michelle tantos momentos Abril - porque a pesar de tantos roces, logramos pintar una raya de respeto Javier - por ser un ejemplo de madurez y coraje deportivo, por mostrar un espíritu ganador todo el tiempo Carlos - por mostrar una respetable amistad y por ser un ejemplo de dedicación al estudio Osslan - por no irle al América, por tocar tan bien la guitarra y ser un ejemplo de pasión por algo musical, por su espíritu tan alegre Chícharo - por su nobleza desmedida, por apoyarme cuando se prestó la oportunidad Omar - por su franqueza a hablar y por su admirable capacidad para programar René - por llegar a ser un amigo al fin Juan - por brindar su sincera amistad y cuidar de Michelle incondicionalmente
Desde luego a la SEP y en especial al COSNET por prestar la ayuda económica sin la cuál este proyecto simplemente no se hubiera logrado.
Gracias.
INGEN~ER~A INVERSA DE CÓDIGO FUENTE EN c++ PARA LA OBTENCIÓN DE SU DISENO
Introducción El tema central del presente trabajo se enfoca hacia la aplicación de ingeniería inversa para recuperar diseños de software. Lo anterior, debido en gran parte a que el ingeniero de software frecuentemente echa mano de herramientas automatizadas que recuperan diseños para mantener y documentar sistemas de software, reduciendo la complejidad del entendimiento de código fuente.
Las herramientas en el mercado que realizan ingeniería inversa de sistemas orientados a objetos generalmente son costosas y presentan una peculiar limitación: a últimas fechas se ha dejado de lado la recuperación del diseño detallado de los métodos de clases. Se pretende que SOODA', una herramienta que ayuda a modelar sistemas orientados a objetos, sea capaz de recuperar el diseño de clases y el diseño detallado de métodos desde software implementado en C++, a partir de la creación e integración de un mecanismo de ingeniería inversa.
Es necesario estudiar varios temas para la realización de este proyecto: las tecnologías de objetos que involucran a los atrones de diseño y el desarrollo de software con la MFC2;
lenguajes libres de contexto y el lenguaje de programación C++. diagramas de clases del UML r: y ' . diagramas del método de Warnier; la traducción de
El uso de tecnologías de objetos es fundamental para poder incorporar a SOODA la capacidad de recuperar diagramas. El núcleo de SOODA seguirá bajo la arquitectura MFC pero el uso de patrones de diseño facilitará el diseño e implementación de clases reusables que permitan construir diagramas a partir del análisis de código fuente.
El diagrama de clases del UML y los diagramas de Warnier, serán la notación base para representar respectivamente los diagramas con las perspectivas estática y dinámica del diseño recuperado desde código fuente en C++.
La teoría de traducción de lenguajes permitirá identificar un formalismo para traducir de manera eficaz el código fuente en C++ hacia el conjunto de diagramas mencionados anteriormente. Aunado a esta base formal se usará la herramienta ANTLR4 para constxuir el núcleo traductor de la herramienta.
i SOODA es producto dc la I& "Modelado Oricniado a Objeior". dcl grupa dc ingenieria de Solbarc. dcl Centro Nacional de lnvesligacibn y Desanollo Tecnológico, en Cuemavaca, Morelos. Mexico. 2
1
4
Bibliolcca de Clases Base dc Microsafl Lcnguajc Unificado de Modelado Anoiher Tool for Language Recognition
INGENlERiA INVERSA DE CÓOIGO FUENTE EN c++ PARA LA OBTENCIÓN DE SU DISENO
En el presente trabajo de tesis se construye una herramienta que permite realizar ingeniería inversa de código fuente en C++ para obtener las vistas estática y dinámica de su diseño en forma de diagramas de clases del UML y en diagramas de Wamier respectivamente.
En el Capítulo 1 se mencionan, analizan y comparan los trabajos relacionados, se comentan la problemática resuelta, la hipótesis de investigación, los beneficios esperados, los alcances y las limitaciones de la herramienta. El Capítulo 2 revisa el marco teórico que envuelve al trabajo. En el Capítulo 3 trata sobre el modelo conceptual del sistema. El Capítulo 4 describe la construcción de la herramienta y las pruebas realizadas. Finalmente, el Capítulo 5 discute los resultados y conclusiones obtenidas, los beneficios directos y los trabajos futuros.
Los tipos de letra varían deliberadamente en el contenido del documento. El tipo de letra base es Tintes New Roman, el tipo de letra para las ilustraciones y tablas es Arid y el tipo de letra para porciones de código es Courier New.
< .
11
-
,<' .'.I<.,
I N G E N I E R ~ A INVERSA DE Cooico FUENTE EN c++ PARA LA O Q T E N C I ~ N DE SU DISECO
CONTENIDO GENERAL
....................................... I ...
...................................... VI1
Capítulo I . Conceptos Generales
1.1 1.2 1.3 1.4 1.5 1.6 1 .i 1.8
Objetivo de la Tesis .................................................................................. I . Hipotesis ......................
Beneficios Esperados ....................................... 8
Referencias.. ..... ........................ ...................................... IO
Capítulo 2. Marco Teórico
2.1 Antecedentes .................... 1 ................. 2.2 Definiciones de Conceptos Centrales 2.3 El Lenguaje Unificado de Modelado. 2.4 Diseño Detallado en InverDDVi ....... 2.5 Base Teórica del Análisis de Código ................. ........................... 2.6 Construcción Automática de Analizadores Sint 2.7 Patrones de Diseño Orientados a Objetos ....................................... 32 2.8 Referencias ................................................................................................................... 35
Capítulo 3. El Modelo Conceptual del Sistema
3.1 Introducción ................. ................ 3.2 Arquitectura de InveS 3.3 Diagrama de Clases d 3.4 Aspectos de Diseño Orientado a Objetos .......... 3.5 Los Analizadores de Código Fuente ....................................... 57 3.6 Interaccion con InverDDVi ............................................................................................................ 75 3.7 Referencias ................... ................................ ............. 76
. I
Capítulo 4. Desarrollo y Pruebas de la Herramienta
4.1 Iniroducción 79 4.2 Manejo de la lnterfaz Gráfica de Usuario ........ 79 4.3 Implementación de los Analizadores de Códig ................................................................. 86 4.4 Pruebas ....................... ....................................... 95 4.5 Referencias ........................... ............................................................................ 1 I8
Capítulo 5 . Conclusiones
5.1 Análisis de los Resultados Obtenidos ................ ........................... ..................... 121 5.2 Conclusiones ...................... ............................................................................ 122 5.3 Trabajos Futuros...'. ...... ................ 123 5.4 Refcrencias ........... ~ ......................................................................................................................... 123
... 111
INGENlERiA INVERSA DE CODIGO FUENTE EN c* PARA LA OBTENCION DE SU DISENO
ÍNDICE DE FIGURAS
Figura
Figura 1.1 Proceso básico de ingeniería inversa de Byrne
Figura 1.2 Proceso básico de recuperación de diseños de Biggerstaff
Figura 1.3 Diagrama de actividades UML de la metodología de solución empleada
Figura 2.1 Áreas de aplicación actuales de la Ingeniería Inversa de Software
Figura 2.2 Proceso conceptual de una traducción dirigida por la sintaxis
Figura 2.3 Ejemplo de una estructura Composite: la jerarquía de figuras geométricas
Figura 2.4 Estructura general del patrón de diseño Composite
Figura 2.5 Estructura general del patrón de diseño Builder
Figura 3.1 Arquitectura de InverSOODA vista por capas de servicios
Figura 3.2 Diagrama de clases de InverSOODA
Figura 3.3 Relación entre el documento y la vista de una aplicación MFC
Figura 3.4 Diagrama de clases con los patrones de diseño Composite, Iterator y Visitor embebidos en la arquitectura de InverSOODA
Figura 3.5 Construcción asíncrona del diagrama de clases
Figura 3.6 Construcción sincrona del diagrama de clases
Figura 3.7 Diagrama de clases del UML del patrón del diseño Builder embebido en la arquitectura de InverSOODA
Figura 3.8 Diagrama de secuencias del UML de los objetos en el patrón Builder
Figura 3.9 Patrón de diseño Command embebido en la arquitectura de InverSOODA
Figura 3.10 Ejemplo de archivo de especificación gramatical para ANTLR
Figura 3.1 1 Autómata reconocedor de palabras reservadas
Figura 3.12 Autómata reconocedor de caracteres en blanco
Figura 3.13 Autómata reconocedor de comentarios del tipo doble - diagonal
Figura 3.14 Autómata reconocedor de comentarios del tipo diagonal - estrella
Figura 3.15 Autómata reconocedor de diversos caracteres simples
Figura 3.16 Autómata reconocedor de caracteres literales
Figura 3.17 Autómata reconocedor de cadenas literales
Página
3
4
I I
16
27
33
34
35
40
41
43
46
51
52
53
54
57
59
62
63
63
64
64
65
65
iv
, , :. .". 4 ,..I. ..'U, ,1
INGENlERiA INVERSA DE CÓDIGO FUENTE EN c* PARA LA OBTENCION DE SU DISENO
Figura
Figura 3.18 Autómata que reconoce caracteres de escape
Figura 3.19 Autómata reconocedor de dígitos decimales
Figura 3.20 Autómata reconocedor de números enteros
Figura 3.21 Autómata reconocedor de identificadores
Figura 3.22 Traducción entre una clase en código fuente hacia una figura
Figura 3.23 Ejemplo de árbol sintáctico de derivación con acciones semanticas
Figura 3.24 Orden de ejecucióii acciones semánticas y sus correspondientes efectos en la traducción
Figura 3.25 Interacción de la herramienta InverDDVi en el proceso de recuperación de diseño detallado de métodos de c!ases
-?
Figura 4.1 Cambios en 1% barras de modelado y de herramientas de SOODA
Figura 4.2 Interfaz gráfica de usuario de InverSOODA
I
Figura 4.3Cuadro de diálogo que pregunta si se inicia otro proceso de ingenieria inversa
Figura 4.4 Cuadro de diálogo para seleccionar el archivo que contiene el código fuente en C++ sobre el cual se aplicará la recuperación de diseño
Figura 4.5 Cuadro de diálogo que indica al usuario la recuperación con éxito de un diseño desde código fuente
Figura 4.6 E'em I 1 &un d\&rama de Wamier que corresponde al diseño detallado de un
metodo de clase
Figura 4.7 Instantánea de la interfaz utilizada cuando de acciona la recuperación del diseño detallado de un midodo en particular
Figura 4.8 Métodos y atributos de la clase InverSoodaDiagramaBuilder usados en 10s mecanismos de ingenieria inversa
Figura 4.9 Diagrama de clases generado de manera asÍncrona por niedio de la barra de modelado de InVerSOODA
QUI 4.10 blamama generado para ia función Context0::interaciua
Figura 4.11 Diseño detallado del método Suina::Calcula
Figura 4.12 Diseña detallado del método Media::Calcula
Figura 4.13 Diserio detallada del rnátodo Desviación::Calcula
Figura 4.14 Pantalla de salida en la ejecución del código gcnerado con los mecanismos de ingenieria directa de InverSOODA
I
Página
66
66
67
67
73
73
74
75
79
80
81
82
81
84
85
90
96
97
98
98
99
I04
1 1
INGENlERiA INVERSA DECODIGOFLJENTE EN c* PARA LA OBTENCION DE SU DISENO
Figura Página
Figura 4.15 Diagrama de clases recuperado con InverSOODA: despliegue de las clases BDSys y de BDMenu
Figura 4.16 Diseño detallado recuperado del método aStratl ::getnum()
1 o9
110
Figura 4.17 Diseño detallado recuperado del método aSfratl::pidevar() I10
Figura 4.18 Diseño detallado recuperado del método aStrat1;:pidevaK)
Figura 4.19 Diseño detallado recuperado del método aStratl::pidegrupo()
Figura 4.20 Diseño detallado recuperado del método cStrl I::Algor¡tmoDeInterFaz()
Figura 4.21 Diseño detallado recuperado del método cStrlZ::AlgoritmoDeInterfaz()
Figura 4.22 Diseño detallado recuperado del método cStrl3::AlgoritmoDeInterfaz()
1 1 1
111
112
112
113
113 Figura 4.23 Diseño detallado recuperado del método cStrl4::AlgoritmoDeInterfaz()
Figura 4.24 Diseño detallado recuperado del método cStrlS::AlgoritmoDeInterfaz()
Figura 4.25 Diseño detallado recuperado del método cStrl6::AlgoritmoDeInterfaz()
114
114
Figura 4.26 Diseño detallado recuperado del método SC-BASE:Produce() 115
dos CCC-VA::Crea(), CCC-VB::Crea() 115 Figura 4.27 Diseño detallado recuperah dP 10s Nbf, J
Figura 4.28 Diseño detallado recuperado de los métodos de la clase BASE
Figura 4.30 Diseño detallado recuperado del método VAl::bdleea(unsigned int VAR)
1 I 6
Figura 4.29 Diseño detallado recuperado del método VAl::bdInicia() 117
117
118 Figura 4.31 Diseño detallado recuperado del método VAl::bdsca(unsigned int VAR)
vi
INGENlERiA INVERSA DE CÓDiGO F U E ~ T E EN C+t PARA LA OBTENCION DE SU DISERO
ÍNDICE DE TABLAS
Tabla
Tabla 1.1 Herramientas que realizan ingenieria inversa de software para recuperar diseños
Tabla 2.1 Definición dirigida por la &axis para traducir expresiones de suma y resta en notación infija a notación posfija
Tabla 2.2 Esquema de traducción dirigido por la sintaxis que traduce expresiones aritméticas de suma y multiplicación, de notación en infijo a posfijo
Tabla 3.1 Muestras reconocidas por el analizador léxico de InverSOODA
Tabla 3.2 Esquema de traducción entre el lenzuaje C++ y diagramas de clases del UML
Tabla 4.1 Papel de los atributos y métodos del objeto Builder en el análisis semántico
Tabla 5.1 Deficiencias encontradas durante las pruebas a InverSOODA
vii
Página( s)
5.6
21
30
61
69-12
9 1-94
121-122
\
-
i 1.1
i I 1.7
1.2 1.3 1.4 1.5 1.6
1.8
I
Capítulo 1
Conceptos Generales
“EL RETO Siempre establece el camino,
nimca sigas el sendero ‘I
Anvli(nif
Trabajos Relacionados Definición del Problema Objetivo de la Tesis
Bcneficios Esperados Límites y Alcances del Trabajo Metodología de Solución Referencias
Ilipótesis
CAPiTULO I : CONCEPTOS GENERALES TRABAJOS RELACIONADOS
En el ámbito actual de la Ingeniería de Software existen dos conceptos con íntima relación: la documentación de software existente y la recuperación de diseños 'de software. La importancia de la relación entre estos dos conceptos existe porque al recuperar el diseño de un software que ya existe, se cuenta con los planos con que se construyó. El diseño es una parte niedular de la documentación de un software, que se complenienta con otros elementos tales como los requisitos y las pruebas.
La recuperación de diseños de software involucra la aplicación de ingeniería inversa. La ingeniería inversa de software es.un proceso que consiste en analizar código fuente para obtener uno o varios niveles de abstracción más elevados que'el propio código fuente. El diseño de un software, por ejemplo, es una abstracción más alta que el código fuente [preo21. La ingeniería inversa nomialmente se aplica desde herramientas especializadas que extraen información acerca de la arquitectura de un programa ya existente.
Los tenias tratados en este capítulo tienen la intención de presentar los antecedentes y conceptos generales que preceden el presente trabajo. Todo gira en tomo a la recuperación de diseño por medio de ingeniería inversa; se mencionan los trabajos relacionados y la relación
respecto a InverSOODA, la especial de las herramientas SOODA herramienta propuesta; se presenta el objetivo de este proyecto; se formula la hipótesis general
. que sostiene la tesis; se exponen los beneficios, alcances y limitaciones; finalmente, se enumeran las actividades que comprende la metodología de solución propuesta.
e InverDDVi [PnrOO]
1.1 Trabajos Relacionados
Son varios los estudios que revisan métodos y técnicas de ingeniería inversa y también son varias las herramientas computacionales que aplican 'técnicas de ingeniería inversa con diversos fines. En esta sección se presentan algunos métodos y trabajos relacionados con la aplicación de la ingeniería inversa para recuperar diseños de programas.
1.1.1 Modelo de ingeniería inversa de Byrne'
En el trabajo Eric J. Byrne se presenta un iiiodelo de ingenieria inversa que consiste en extraer información de diserio deiailado con abstracciones de alto nivel, desde código fiiente y documentos de diseño.
I r I r I
Inlormacibn del diseno delaliado
Figura 1.1 Proceso básico de ingeniería inversa de Byme.
' Ciiado en [ WeiiOZ]
3
CAPiTULO 1: CONCEPTOS GENERALES
Dicho modelo fue utilizado para recuperar el diseño de un sistema implementado en lenguaje Fortran, para implementar una nueva versión en el lenguaje Ada. El proceso básico que propone Byrne se resume en la Figura I . 1.
Programa Identificación de Recuperación de fuentcen c d agrupaciones de i ) abstracciones de
módulos y datos diseño
1.1.2
propone un modelo de recuperación de diseños aplicado al Ted J. Biggerstaff mantenimiento de programas y al enriquecimiento de bibliotecas para reuso. El modelo consta de tres etapas. Cada etapa provee los siguientes elementos respectivamente:
Modelo de recuperación de diseños de Biggerstaff
[Big891
1) El entendimiento del programa para su mantenimiento. 2) El enriquecimiento de bibliotecas de reuso y recuperación. 3) La aplicación de los resultados de la recuperación de diseño.
La Figura 1.2 ilustra el proceso básico de recuperación de diseños para programas escritos en C. Según Biggerstaff, este proceso se puede aplicar a lenguajes orientados a objetos con sólo una modesta variación'. El proceso básico comienza con un análisis que identifica estructuras . organizacionales a gran escala, tales como módulos, subsistemas y datos importantes. Enseguida se recuperan otras estructuras abstractas de diseño: diagramas informales, conceptos y relaciones informales, diseño racional, estructura de módulos y finalmente flujo de datos y de control. Durante este proceso se debe mantener el mapeo entre las abstracciones y los segmentos de código que las implementan.
Mapeo de las i ) abstracciones
con el código E l
I I1
Figura 1.2 Proceso básico de recuperación de diseños de Biggerstaff.
abstractos
Deigraciidumente no especifica que variación. El modelo no enloca su aplicación a sis l~n ias orientados a objetos, pero sienta las bases de la recuperación de infamación de entidades con alta abstmcción - algo muy parecido u una clsse - y luego u la recupcración de los deialles de dichas entidades.
4
CAP~TULO 1: CONCEPTOS GENERALES TRABAJOS RELACIONADOS
1.1.3 Herramientas de ingeniería inversa
Son numerosas las herramientas computacionales que realizan ingeniería inversa para recuperar diseños embebidos en código fuente. La diversidad de dominios, lenguajes y metas que comprenden estas herramientas hace imposible listarias todas. La Tabla 1.1 tiene la intención de mostrar al lector una síntesis de aquellas herramientas que tienen mayor relevancia para el presente trabajo. En cualquier caso, la columna denominada Contraste menciona los desventajas de las herramientas analizadas que no son tales en InverSOODA, la herramienta propuesta en este trabajo de tesis para recuperar diseños.
Herramientas que realizan ingeniería inversa de software para recuperar
Nombre IPADIC++ [ZavO2]
SOODA [ParOO]
LS/2000 [DeaOl]
disi Dominio
Com.ponentes de Software.
Modelado orientado a objetos.
Software de tecnologías de informaci6n a gran escala con YK2, el problema de sistemas que no previeron el uso de fechas posteriores ai ano 2000.
Descripción Una herramienta que utiliza un modelo can6nico de representaci6n de patrones de diseño. para rewnocer patrones de diseño en cddigo en C++.
Permite diseñar diagramas de clases de UML y el disefio detallado de métodos de clases, apoyándosede DDVi. Es capaz de generar código en C++ a partir de los diagramas creados.
Es un software altamente automatizado oue
os Relación
La identificaci6n automática de patrones de disefio es un ejemplo de la recuperaci6n de una alta abstracci6n de disefio orientado a objetos.
Especial relación tiene esta herramienta en el presente trabajo: sobre la base de SOODA se propone InverSOODA, una nueva herramienta bldireccional.
El Y2K - es un ejemplo tlpico en donde es común la aplicación de ingenieria inversa para la recuperación automatizada de disefios.
Contraste IPADIC++ no recupera los diagramas de clases que corresponden a los patrones de diseño. Tampoco recupera el diseno detallado de métodos de c I a s e s.
SOODA no recupera ni diagramas de clases ni diagramas de diseño detallado de métodos desde código fuente legado.
Aunque LS/~OOO trata directamente w n la recuperaci6n de abstracciones equivalentes al diseflo detallado, nc recupera precisamente el diserio detallado de funciones con algún tipo de diagramas.
Tabla 1.1 Herramientas que realizan ingeniería inversa de software para recuperar diseños.
i
5
CAP~ULO 1: CONCEPTOS GENERALES
Herramientas que realizan ingeniería inversa de software para recuperar 1 (continuación ...)
Nombre nverDDVi Wen021
IRT [DrtOZ]
lational lose Jrofessional idition for :++ [Rat031
Dominio MBtodos automatizadc de ingenieria inversa.
Aplicaciones gráficas interactivas.
Desarrollo Model-Driven con UML.
- diseños
Descripción Es una herramienta de ingenieria inversa que permite visualizar el diseño detallado de un programa, utilizando la notación Wamier.
Oesign Recovery Tool es una herramienta de exploración gráfica de apiicaciones en C/C++ muy peculiar; identifica explosiones de ejecución - la totalidad de los métodos llamados - que corresponden a las acciones ejecutadas por un usuario. Obtiene un mapeo explicito de las acciones de alto nivel -similares a iragmentos de escenarios de casosdeuso-wnsu. implementación de bajo nivel. Esta herramienta es una parte de Rational Suite, que es lider en el campo del desarrollo de software orientado a objetos y de componentes. Esta versión se puede integrar con Microsofl Visual C++ para desarrollar software.
, -~ . .
Rqlación De especial relevancia es este trabajo, pues representa el módulo que recupera el diseño detallado de funciones de InverSOODA.
El mapeo de ejecuciones de métodos con escenarios de casosdeusose puede usar para recuperar diseños j documentar las funciones más usadas de manera gráfica.
Rational Rose es Ií herramienta propuesta por el Object Management Group para promover y usar el UML. Realiza ingenieria inversa directa de código para Visual C++ entre otros lenguajes de programación.
,Contras fe La principal desventaja frente a InverSOODA es que. por sí sola, sólo funciona para sistemas escritos en lenguaje C. Su enfoque no contempla la recuperación de abstracciones equivalentes a c I a s e s. DRT es una herramienta experimental que deja de lado la recuperación de la vista estática envestida en los diagrama de clases. Tampoco se puede decir que es exactamente la recuperación del diseño detallado de métodos su finalidad. En cuanto a ingenieria inversa, Rational Rose enfoca sus esfuerzos a la recuperaci6n de diversas abstracciones de diseño, entre otras, el diagrama de clases, pero no hace recuperación explicita del diseño detallado de los mbtodos de clases que aparecen en dicho diagrama de clases.
Tabla 1.1 Herramientas que realizan ingeniería inversa de software para recuperar diseños. (continuación ...)
6
CAPiTULO 1 : CONCEPTOS GENERALES DEFINICIÓN DEL PROBLEMA
1.2 Definición del Problema
De acuerdo con Chikofsb 'ch'wl, "Las fases de ciclos de vida evolutivos involucran la transición de altos niveles de abstracción en etapas tempranas, a bajos niveles de abstracción en etapas posteriores". Además, comenta que en dichas etapas: "...la ingenieria inversa cubre un amplio rango de etapas que comienza con la implementación existente, la recuperación o recreación del diseño y el descifrado de los requerimientos que de hecho se implementan en el sistema...". De aquí se desprende que en los modelos de ciclos de vida3, la aplicación de ingeniería inversa se da en varias etapas y puede considerar tanto las abstracciones de alto nivel como las abstracciones de bajo nivel.
,,
En el contexto de desarrollo de sistemas orientados a objetos, independientemente del modelo de ciclo de vida, el diagrama de clases se encuentra .en un nivel de abstracción mayor que cualquier diagrama de diseño detallado. Ninguno es más importante, mas bien son complementarios. Existe 'en la actualidad una diversidad de herramientas que recuperan diagramas de clases y, sin embargo, dichas herramientas parecen haber dejado .en el olvido la recuperación del diseño detallado de los métodos de clases. Esto impide realizar ingeniería inversa de una importante abstracción de bajo nivel, como lo es el.diseño detallado.
# El problema se extiende de alguna manera a la herramienta SOODA, pues, por principio de cuentas, no es una herramienta bidireccional; no puede hacer ingeniería inversa a partir de código fuente en C++.
El problema que res$elve este proyecto de tesis es precisamente el de construir una herramienta basada en SOODA, que sea bidireccional al permitir la recuperación del diagrama de clases del UML y el diseño detallado de métodos de clases con diagramas de Wamier.:Al final, se tendrá como producto el software denominado InverSOODA, la herramienta bidireccional.
1.3 Objetivo de la Tesis 1
El objetivo de esta tesis es generar un mecanismo de ingeniería inversa para recuperar el diseño de clases y el diseño detallado de métodos de clases desde código que ya existe escrito en C++.
I 1.4 Hipótesis
En este trabajo se plantea como hipótesis que es posible generar el diagrama de clases basado en el estándar UML y los diagramas de Warnier para representar el diseño detallado de métodos de clases, a partir de código fuente existente en C++.
' Llhesc el tradioional modela en cascada. el cvol~t ivo modelo en espiral. etc.
7
CAPhULO 1: CONCEFTOS GENERALES
1.5 Beneficios Esperados
Se contará con InverSOODA, una herramienta de ingeniería de software que realiza ingeniería directa e ingeniena inversa de programas en C++. La ingeniería directa provee los mismos beneficios que la herramienta SOODA. A su vez, la ingeniería inversa obtiene diagramas con el diseño de clases y el diseño detallado de los métodos de clases, desde código fuente existente. Los diagramas recuperados representan un modelo estático y dinámico que son parte de la documentación del diseño del código fuente.
La recuperación del diseño detallado de métodos representará un valor agregado respecto a las herramientas para análisis y diseño orientado a objetos en el mercado, pues a la fecha del inicio de este trabajo ninguna ataca el problema.
El diseño arquitectónico de InverSOODA se reorganizó con patrones de diseño orientados a objetos a partir del diseño original de SOODA. Esto facilitará las extensiones y modificaciones a posteriori a la arquitectura de la herramienta.
1.6 Límites y Alcances del Trabajo
El analizador sintáctico de C++ construido .para la herramienta InverSOODA reconoce un subconjunto de la gramática de CH4, lo que repercute en que no se identifican directivas de preprocesamiento ni se recuperan templates de Ctt.
InverSOODA no verifica errores en el código fuente sujeto a análisis. Por lo tanto, éste no debe tener errores de compilación ni de ejecución. De lo contrario, se obtendrán mensajes de error. Además, el código fuente debe estar organizado con su definición de clases dentro de un solo archivo con extensión h ó hpp y la implementación de los métodos de clases dentro de archivos independientes con extensión c Ó cpp.
Si bien existe la posibilidad de usar notaciones de diseño detallado más divulgadas que la de Warnie?, InverSOODA echa mano del conocimiento adquirido con InverDDVi para resolver la diagramación del diseño detallado de los métodos de clases.
InverSOODA utiliza todo elemento gráfico de SOODA para la ingeniería directa. Sin embargo, el mecanismo de ingeniería inversa sólo recupera relaciones de herencia y de agregación entre clases, pues el analizador sintáctico no reconoce apuntadores y por ende relaciones simples o de dependencia entre clases.
1.7 Metodología de Solución
La metodología empleada en la construcción de InverSOODA involucra las siguientes actividades:
' El Anexo A de este documento contiene dicha gramática. ' Los tradicionales diagramas de flujo por ejemplo.
8
,,"U. :C%L$?"SrA.+l.." . . . i . ' I , t ~. * ' I
e < . . . !
CAPITULO 1: CONCEPTOS GENE~ALES METODOLOG~A DE SOLUCIÓN
1. Revisión de la arquitectura de clases y funcionamiento de SOODA.
Para efectos de agregar a la arquitectura de SOODA la capacidad de realizar ingeniería inversa, se realizó una revisión exhaustiva de su diseño de clases y una modificación de aspectos de diseño puntuales para lograrlo.
I . . r las siguientes preguntas encontraron respuesta: ¿qué estructura de datos se,usan y cómo se manipulan?, ¿Cómo se manejan los eventos de interfaz e usuario?, ¿Cómo están organizadas sus clases?, ¿Qué clases se pueden extender o agregar para poder hacer ingeniería inversa?
2. Reorganización de aspectos de diseño orientado a objetos puntuales con patrones de diseño.
para proveer un diseño La idea original fue utilizar el patrón de diseño Builder reusable que permitiera construir un objeto'diagrama a partir de la información que arrojase el analizador sintáctico. Pero, conforme se fue detectando la posibilidad y conveniencia de aplicar otros patrones de diseño que colaboraran con el Builder, entonces se reorganizó gran parte del diseño de clases de la arquitectura original de SOODA.
Se estudiaron la d a or parte de'los patrones de diseño que tienen relación con el patrón Composite 'l. En SOODA, ya se utilizaban algunas bondades de la programación orientada a objetos con el uso de una clase abstracta denominada Figura; objetos concretos Figura se guardaban genéricamente en una lista de punteros a.objetos del mismo tipo: Figura. Sin embargo, no se podía hablar del patrón Composite inmerso en su arquitectura. Dos objetos Builder concretos,'uno para la ingeniería directa y otro para la ingeniería inversa, construirían una estructura Composite para cada diagrama de clases generado por InverSOODA.
3. Estudio de formalismos que sustenten el análisis sintáctico.
La recuperación de cualquier tipo de información desde código fuente tiene dos principales alternativas: la constnicción de analizadores manuale's o.el uso de formalismos como la teoría de autómatas y be compiladores. La finalidad de esta actividad fue encontrar un esquema de traducción formal entre lenguajes basándose en acciones semánticas. La definición dirigida por la sintuxis fue el objeto de estudio que se acoplaba más para el propósito de InverSOODA.
revision, A partir de esta
[Gam951
., J
4. Estudio y selección de diferentes herramientas que generan analizadores sinthcticos de manera automática.
La herramienta ANTLR-2.7.1 fue la elegida entre varios productos, para generar automáticamente el analizador léxico y sintáctico que analizaría el código fuente legado. Además de manejar notación gramatical EBNF, la gran ventaja que guió esta decisión, es que ANTLR es un marco.de trabajo orientado a objetos que permite crear objetos h e r y parser en el lenguaje C t t . Entonces se creó una librería estática que provee la
. ,
9
CAPiTULO 1: CONCEFTOS GENERALES
funcionalidad de análisis léxico, sintáctico y semántico necesarias (además de poder agregar objetos Builder) para recuperar los diseños en cuestión.
Las acciones semánticas del analizador sintáctico generado con ANTLR son las que propiamente realizan la ingeniería inversa. Consiruyen con un objeto Builder el diagrama de clases a partir de la información que arroja el análisis sintáctico.
5. Identificación del subconjunto de la gramática de C++.
Se identificó una subgramática para C++ escrita en notación EBNF que alimenta al ANTLR. Este subconjunto gramatical de C++ es el suficiente para reconocer y descubrir nombres, atributos, métodos de clases y relaciones entre clases. Se revisaron la literatura especializada y algunos los archivos con definiciones de gramáticas para C ya existentes.
6. Implementación del rediseño para InverSOODA e implementación de las acciones semánticas del analizador sin fáctico.
La codificación e integración del analizador sintáctico a la nueva arquitectura fue el paso lógico a seguir, habiendo analizado y diseñado los aspectos mencionados en los pasos anteriores de este subtema.
7. Realización de pruebas y reflexión sobre resultados obtenidos.
Si bien se realizaron pruebas y ensayos empíricos no documentados durante las diferentes etapas del desarrollo de InverSOODA, también se definieron dos casos de prueba específicos que verificarían y demostrarían la eficacia de la herramienta6.
8. Escritura de la memoria de tesis
A partir de los resultados obtenidos durante el desarrollo de la herramienta y aplicación de casos de prueba, se escribió el presente documento que sustenta la tesis.
La Figura 1.3 en la página siguiente, resume las actividades que corresponden a la metodología descritas en la enumeración anterior.
1.8 Referencias
[Big891 Biggenlaff. Ted J. Design Recovery for Mainienance end Reuse Computer. (E.U.: IEEE Computer, Julio de 1989) pp. 36-49.
[Chi901 Chikofsky, Elliot J. [y] Cross 11, James H. Reverse Engineedng and Design Recovery: A Taxonomy. (E.U.: IEEE Somare. Enem de 1990) pp. 13-17.
Revise el Capitulo 5.
10
CAP~TULO I: CONCEPT~S G E N ~ M L E ~ REFERENCIAS
Figura 1.3 Diagrama de actividades de UML de la metodología de solución empleada.
[DeaOl] Dean, Thomas R. Et al. Using Design Recovery Techniques to Transform Legacy Systems. (Canada: ICSM 2001 IEEE International Conference on Software Maintenance. Florence, Noviembre de 2001).
[Ort02] DRT. Design Recovery Tool. httD:llwww.cse.unsw.edu.aul-driíindex.hlml 14 de Enero de 2003.
[Gam951 Gamma Erich et al. Design Pafferns-Elemenls of Reusable Object-Oriented Sohare. (E.U.: Addison- Wesley-Longrnan.1995) pp. 97-106. 163-173.
[ParOO] Parta Ramirez. Isaac A. Modelado Visual Orientado a Objetos. (Tesis de Maestria. CENIDET, Cuernavaca. Morelos, México. Diciembre del 2000).
[PreO2] Pressman, Roger S. Ingeniería del Soflwara. Un enfoque pdctico. Quinta Ed. (Madrid, Espaíia: McGrawhillllnteramencana de España. 2002) p. 546.
[Rat031 Rational Software Corp. httD:llwww.rational.comlDroduclslroselclcc.isD 14 de Enero de 2003.
[Wen021 Wences Diaz. Martha F. Modelo de ingeniería inversa para la obienci6n de diseno detallado basado en LEVISS. (Tesis de Maestria, CENIDET. Cuernavaca, Morelos, México. Febrero de 2002) pp. 15. 28-39.
[ZavOZ] ,,Zavalela Carrillo. Patricia. Reconocimiento de Patrones de Diseño de Gamma a partir de ia fonna candnica definida en el IPADIC++. (Tesis de Maestria. CENIDET. Cuernavaca. Morelos..MBxico, Enero de 2002).
I 11
03- O 3 3 4
2.1 2.2 2.3 2.4 2.5 2.6 2.1 2.8
Capítulo 2
“Elcamino sigueysigue ...” B. Baggins
Antecedentes Definiciones de El Lenguaje Unificado be Modelado Diseño Detallado en InjerDDVi Base Teórica del Análisis de Código Construcción Automátiya de Analizadores Sintácticos Patrones de Diseño Orientados a Objetos Referencias I
CAPÍNLO 2: MARCO TEóRiCO
IMOIOO] 2.1.1 Ingeniería inversa e ingeniería inversa de código
Hoy día, existen dos al entendimiento de software: la ingeniería inversa Para el entendimiento de software industrial o resuelve la incógnita sobre qué información se
en contextos diferentes. El famoso problema del año dos mil y la migración de sistemas de información hacia aplicaciones Web o hacia elcomercio electrónico, entre odos, han propiciado el interés por crear conceptos y técnicas para la ingeniería'inversa de datis. El incremento del uso de bodegas de datos y técnicas de minería de datos también han ido motivo de interés, concretamente para la ingeniería inversa de bases de datos.
No ohstante, el esfuerzo de investigación para la ingeniería inversa dd datos no ha tenido una significativa representación en la Ingeniería' de Software. Aparentemente, la ingeniería inversa de código representa un reto más desafiante, además de que ha existido una tradicional división entre ingenieros de software y desarrolladores de sistemas .de bases de datos.
I
e' I
"En sistemas con pobre
es la única fuente confiable de .
información acerca del sistema. "
HausiA. Mü"er
Müller et al comentan: "Durante la evolución del software, se aplican C 'mbios al código fuente para añadirle funcionalidad, corregir sus defectos y mejorar su calidad. En sistemas con pobre documentdpión, el código es la única fuente confiable de información acerca del sistema. Como resultado, el proceso de
7
ingeniería inversa se ha concentrado en entender el código".
ANTECEDENTES .
' Mejor conocidos como Sirlemas de Infamación.
2.1 Antecedentes
15
. .
CAPiTULO 2: MARCO TE6RICO
Estos comentarios dejan ver, de alguna manera, por qué es relevante el entendimiento de código fuente. Sin embargo, falta precisar algunos de los frutos o beneficios concretos que proveen las capacidades de ingeniería inversa de código. Dichos beneficios incluyen la descomposición en subsistemas; análisis de conceptos; identificación de diseños, programas y patrones de cambio; slicing de programas; análisis de dependencias estáticas y dinámicas; métricas orientadas a objetos; exploración y visualización de software. Se habla entonces de artefactos de sofwure al referimos a una abstracción de determinado nivel que se encuentra embebida dentro del código fuente, y que puede ser recuperada por mecanismos de ingeniería inversa.
Müller et al también nos indican que existe una importancia en la continuidad en el entendimiento de programas: “Para evitar una crisis, es importante tratar las necesidades de información más efectiva durante el ciclo de vida un software. Se necesita dar soporte al seguimiento de los artefactos de software’’. Por ejemplo, en la ingeniería directa es importante obtener los elementos de código que lo implementan. En la ingeniería inversa, dado un archivo u objeto fuente, se debe tener la capacidad de obtener la política o responsabilidad que implementa. De igual forma, es importante determinar cuando es más apropiado enfocar el análisis en diferentes niveles de abstracción. La Figura 2.1 ilustra las tendencias actuales de la ingeniería inversa además de resumir los elementos analizados y los beneficios obtenidos.
Ingeniería I””T)C%?
Se aplica a (en): Bodegas de datos; Mineria de dalos; y, Bases de dalos relacionales
Ingeniería Inversa
rla nntm
r ingenieria I Se aplica a:
CddiQo fuente 1 Inversa de Ceidigo
Se obtiene(n): Objetos centrales de negocios para migrar sislemas a plataformas onentadas a obJetos:
Map- entre e ~ t ~ c h l r a s de datos legadas y un modelo de objetos mmún para negocios o infraestmclums moperalivas Web: y.
Aseguramiento de wlidad integral de sistemas de samate que usan eslnicluras de datos persistenles o esquemas mn sistemas maneladores de bases dedalos.
Se obtiene(n): Descamposici6n en subsistemas; Sintesis de conceptos: Identificaci6n de diseno y patrones de cambio; Rebanado de programas: AnBlisis de dependencias estdticas y dinhmicas; MBtrica~ orientadas a objetos: y. Explaraci6n y.visualiraci6n de somare.
I1
Figura 2.1 Áreas de aplicación actuales de la Ingeniería Inversa de Software.
16
CAPITULO 2: MARCO TEÓNCO
El grupo de Ingeniería de S o h a r e del CENIDET ha estado desarrollando a la fecha, un ambiente de desarrollo de s o d a r e orientado a objetos denominado Suite CENIDET-UML. El proyecto involucra como pahe medular al Lenguaje de Unificado de Modelado (UML). Mediante el uso del UML se p!etende auxiliar el desarrollo de software evolutivo orientado a objetos, modelando las siguikntes vistas: vistas .estáticas de clases y paquetes, casos de uso y vistas dinámicas de estadbs, secuencias y actividades. Además, se tiene planeado dar un valor agregado a la suite que normalmente las herramientas comerciales no presentan: el
asociadas al sistema.
I modelado del diseño detallado I de los métodos de clases más la documentación y pruebas
Entre los módulos que contendrá la suite se tienen los siguientes*:
a) SOODA*, modela diagr a , mas de clases del UML y diagramas de Wamier para el diseño detallado de métodos, apoyándose de DDVi para los segundos. Genera código fuente en C+ a p h i r del modelado de diagramas de clases.
b) InverDDVi*, modela dibeño detallado con diagramas de Wamier. Auxilia a - SOODA para generar el c)ódigo fuente de métodos de clases en lenguaje C++.
c) SIDDO*, detallado de métodos de clases I utilizando Tiene embebido un analizador
diagramas sea válida en función de
medio de diagramas de casos de uso los documentos de requerimientos y
sintáctico' que una gramática visual para
d) Un módulo que modelará del UML. Con esta
e) Un módulo que permitirá P btener de forma automática los diagramas de secuencia pruebas del sistema.
del UML, tomando infodación de 1os.diagramas de clases y de diseño detallado generados con SOODA. ddemh, permitirá el cálculo.automático de la métrica de acoplamiento para sistemad, orientados a objetos:
f) Un módulo que mode ará el comportamiento ,dinámico de los objetos correspondientes a las clases modeladas con SOODA, por medio de los diagramas
g) Un módulo que presentará la vista de paquetes correspondientes a grupos de clases con responsabilidad común) gmpos que serán modelados previamente con SOODA.
de actividades.
\ de estado del UML. I
I
r
ANTECEDENTES
Durante el desarrollo de la Suite CENIDET-UML ya se han obtenido resultados concretos y satisfactorios en cierta no está completo. El estado
Sin embargo, el prototipo original de SOODA apoya la fase de diseño de clases y la
generación del código en C + + que las implementa, en complicidad con InverDDVi. En otras palabras, hace ingeniería dir&a. No obstante, hace falta dar soporte al seguimiento de código generado. La suite presudone el apoyo al desarrollo de sofhvare evolutivo y esto
producto de la ingeniena directa. implica que en algún momento se recuperar y entender algún artefacto de software
I ' Los módulos señalados con asterisco uten terminados y los dcmb sc ~n~ucnlran cn desarrollo a la fecha I
CAPfTULQ 2: MARCO TEÓRICO
Concretamente, se pretende que SOBDA sea un módulo bidireccional que sea capaz de recuperar diseños desde código fuente3. Con InverSOODA, el nuevo prototipo de SOODA propuesto en este trabajo, se cuenta ahora con la capacidad de recuperación a partir del código fuente escrito en C++ de al menos dos niveles de abstracción de diseño: el diagrama de clases y el diseño detallado de métodos. Con dicha capacidad es factible el entendimiento y la reestructuración potencial de las tempranas decisiones de diseño arquitectura].
Es importante notar que InverSOODA se puede catalogar como un software que realiza ingeniería inversa de código para identificar diseño, de acuerdo con la Figura 2.1 de la sección 2.1.1.
2.2 Definiciones de Conceptos Centrales
En esta sección se definen los conceptos que tienen que ver directamente con el tópico central del presente trabajo: la ingeniería inversa de software para recuperar diseños. La definición puede o no venir acompañada de un comentario o nota crítica que vincula el concepto definido con el menester del proyecto o con alguna otra sección del documento en específico.
2.2.1 Ingeniería inversa
Chikofski [Chigo] nos da la siguiente definición en su Útil taxonomía:
“La lngenieria Inversa es el proceso d e analizar un sistema sujeto a estudio para: a) identificar los componentes del sistema y sus interrelaciones; y, b) crear representaciones del sistema con otra forma o con un mayor nivel de
abstracción.”
Por su parte, Pressman [preo21 asienta que ia ingeniería inversa es:
”... el proceso que consiste en analizar un programa con uno o vanos niveles de abstracción más elevados que el código fuente. Generalmente se aplica desde herramientas de reingeniería que extraen información acerca de los datos, arquitectura y disefio de procedimientos de un programa ya existente.”
AI revisar estas dos definiciones se encuentran similitudes: ambas hablan de un “proceso que analiza s o h a r e para identificar o extraer abstracciones de mayor nivel”; aunque la definición de Pressman sí introduce el elemento herramienta, ¿quizá por ser un texto más actualizado?. De cualquier manera, esta cuestión no interesa a la hipótesis planteada en la tesis y se invita al lector a repasar la sección 2.1 para que deduzca sus propias conjeturas4.
’ Explicitamente cn [ParOO] se menciona la necesidad a postcnori de agrcgar la Capacidad de ingenieria inversa a SOODA.
1.1.2 deestedocumento. Además. para ver ejemplos concretos de procesos a los que se refiere la definici6n de ingenicna invcna repasc las secciones 1:l . i y
18
CAP~NLO 2: MARCO TEÓRICO
. -
DEFINICIONES DE CONCEPTOS CENTRALES
2.2.3 Reestructuración 1
2.2.2 Ingeniería directa
[Chi901 semántica)"
2.2.4 Redocumentación
Chikofsky nos dice que la rkdocumentación es la más antigua y simple forma de la ingeniería inversa, y que se .codsidera también una forma de reestructura de código no intrusiva. El prefijo re que existió o que debió sistema pan' mejorarlo.
es recuperar <la documentación del sistema también indica volver a hacer la ingeniería del
algunos ejemplos de herramientas que realizan
- Pretty-printers. El es un anglicismo para denominar el despliegue
redocumentación:
de listados de código de una manera mejorada. - Generadores de diagrama?. Herramientas que crean diagramas directamente del
código para reflejar el control o la estructura del mismo. - Generadores de cruzada. La meta de estas herramientas es
proveer maneras más para visualizar relaciones entre los elementos que componen programas.
2.2.5 Recuperación de diseños 1 "La recuperación de disenos es un hbconjunto de la ingenieria inversa en donde se agrega información externa, conocimientos I de dominio, y deducciones o razonamiento difuso al entendimiento de u n sistema de software, para identificar abstracciones de alto nivel más significativas que aquellas obtenidas dk examinar directamente el sistema por si solo"
[Chi901 . I
CAPITULO 2: MARCO TE~RICO
~
Chikofsky cita a BiggerstaffS parañmblib las ideas expresadas en su definición:
’...La recuperación de diseilos recrea abstracciones de diseño desde una combinación de código. documentación existente (si existe), experiencia personal y conocimiento en general acerca de un problema y dominios de aplicación ... La recuperación.de diseños debe reproducir toda la información requerida por una persona para entender plenamente lo que hace un programa, cómo ío hace, porqué lo hace, etc. Por lo tanto, lidia con un rango mucho mayor de información que el que se obtiene en las representaciones o código convencionales de la ingeniería de software”
Byrne6 nos proporciona otra definición:
“El proceso de reconstruir el diseño de u n programa es llamado recuperación del disefio y es u n elemento del proceso de ingeniería inversa”.
Sin profundizar por el momento en las diferencias entre la definición de Chikofsky y Byrne, cabe hacer notar la diferencia entre recuperación de diseños y redocumentación en cuanto a alcance de enfendimiento de soffware, según las definiciones de esta sección y de la sección 2.3.3 respectivamente. De acuerdo a las ideas de Biggerstaff, la recuperación de diseños se antoja como un proceso mucho más completo y ambicioso que la redocumentación, quizá porque dan énfasis al mantenimiento y reuso de sof iare En cualquier caso, a la hipótesis que sostiene el presente trabajo no compete comprobar que la recuperación de diseños debe obtener altos niveles de entendimiento de software, al estilo Biggerstaff, mas sí lo es obtener dos niveles de abstracción de disefio diferentes para software en C++.
2.2.6 Mantenimiento de software
“La definición ANSI de mantenimiento de software es la modificación de un producto de software después de su entrega para corregir fallas, para mejorar el desempeño de otros atributos o ara adaptar el producto en un ambiente modificado, de acuerdo al ANSlllEEE Std 729-1983.” [ChiOfi
El mantenimiento de software es un contexto en donde la ingenieria ihversa tiene cabida. De hecho, los términos ingeniería inversa y reestructura de so f ia re caen dentro la definición global del mantenimiento de software. Se habla de quien aplica mantenimiento a un sistema como alguien que potencialmente se apoya de herramientas de ingeniería inversa, cuando examina y entiende cierto sistema de software. Ciertamente, no es utópico pensar que el módulo InverSOODA se vea, en potencia, involucrado a futuro en cuestiones de mantenimiento de software, si en ese momento se encuentra apoyando el desarrollo de software evolutivo.
’ La sección 1.1.2 de este documento presenta un resumen de los elementos básicos del modelo de recuperación de disefios pmpucslo por Biggerstaff. . . 6 La iección I . I .I de este documento presenta un resumen de los elementos básicos del modelo de’ingenieda invens de Byme.
20
CAPITULO 2: M k C O TE~RICO
2.2.7 Reingeniería
"La reingenieria, también conocid( de un sistema ara reconstituirlo nueva forma" [CiP,Ol
2.2.8 Software legado
~ . , .
DEFINICIONES DE CONCEPTOS CENTRALES
como renovación y reclamación, es la examinación y alteración en una nueva forma y la subsiguiente implementación de la
El Lenguaje Unificado de Modelado (UML por sus siglas en inglés) es en esencia un conjunto de diagramas que compkndian los métodos de modelado de Booch, Rumbaugh, y Jacobson. Originalmente, el UMd representó un lenguaje visual que nació de la necesidad de generar diseños sólidos que tanto clientes, analistas y desarrolladores aceptaran como pauta para modelar sistemas de sdftware de negocios. Hoy día, se enfoca a ser un lenguaje de modelado estándar para desdollar las fases de análisis y diseño de aplicaciones de sistemas orientados a objetos [RumOi]
1 .
legado:
1) "Son programas que son
El UML provee básicamente odos los esquemas, vistas o perspectivas que permiten entender el diseño de un sistema a de sus diagramas. Los diagramas más importantes son: el diagrama de clases, el de secuencias, el diagrama de casos de uso, el diagrama de actividades, entre otkos, Todos ,estos se elaboran según las necesidades del sistema y la etapa de desarrollo ed que se encuentre el mismo. Este lenguaje se distribuye de manera pública y gratuita en vakos documentos ue resentan los conceptos básicos del modelado: su significado y su representación gráfica %*&I .
I Hoy día, el Lenguaje Unificado de Modelado está siendo incorporado en la mayoría de las herramientas de software comerciales que modelan sistemas orientados a objetos, además de ser constante objeto de estudio. por parte de las instituciones de investigación [LOP021
criticos' para la operaci6n de las compañías, pero que fueron,
CENTRO DE, INFORMACION SEP CENIDET
21 I
C A P ~ L O 2: MARCO TEÓRICO
. . . . . . . .
2.3.1 El modelo estático de clases - . El diagrama de clases del UML provee la vista estática de un software orientado a objetos: "... en un principio llamados modelos de objetos, muestran las clases del sistema y sus interrelaciones (incluidas la herencia, agregación y asociaciones)" [Amb981. Además, de manera opcional pueden mostrar los atributos y/o .los métodos de las clases: "... los métodos se documentan con una descripción de su lógica y los atributos se documentan con una descripción sobre qué contienen. su tipo y una indicación de rango de valores. Las relaciones entre clases se documentan con una descripción de su propósito y una indicación de su cardinalidad ..." [Amb98]
La siguiente cita de Scott W. Ambler [Amb981, enriquece las descripciones del párrafo anterior: "La información contenida en un diagrama de clases se mapea directamente con el código fuente que será escrito para implementar la aplicación y por ende un diagrama de clases siempre debe ser dibujado para una aplicación orientada a objetos." Con InverSOODA se puede realizar ingeniería directa para crear un diagrama de clases y generar el código en C++ asociado al diagrama. En el renglón de recuperación de diseños hace propiamente lo inverso: es capaz de recuperar el diagrama de clases a partir del código que generó.
2.3.2 EL modelado dinámico con el UML
Tradicionaltmente el modelado dinámico de software con el UML.se entiende como el modelado de estado y comportamiento de objetos. Los diagramas de estados del UML se usan para modelar precisamente el estado y comportamiento de objetos, puesto que en dichos diagramas se pueden representar las transiciones o cambios de estado durante la vida de un objeto. En otras ralabras, "Los diagramas de estados muestran los detalles dinámicos de las operaciones"
Por otro lado, tanto los diagramas de distribución como los diagramas de actividades del UML normalmente también se consideran como diagramas con enfoque dinámico. Los diagramas de distribución presentan la configuración en tiem o de ejecución
los diagramas de actividad se usan "... para documentar la lógica de un solo método.de operación o el flujo de la lógica d e un proceso de negocio"[Amb981 "El diagrama de actividades es una extensión del diagrama de estado. Los diagramas de eitados destacan los estados y
Actualmente, InverSOODA no basa el modelado dinámico de sistemas por medio de los diagramas del UML descritos en esta sección. La idea es aprovechar el conocimiento adquirido con InverDDVi para representar detalles dinámicos o flujo de la lógica procedimental de los métodos de clases. Como se indica en la sección 2.1.2, los módulos c) y f) de la Suite CENIDET-UML representan la parte que se planeó para cubrir apropiadamente el modelado dinámico de sistemas con diagramas del UML.
[Sch O]
de componentes de hardware y el software que se ejecuta sobre éstos Ihb9 8p l. Por su parte;
representan actividades como flechas. Los d e actividad se enfocan en las actividades." [School
: I
' < ' . - . ' 22
CAPhULO 2: MARCO TEÓRICO
de diseño detallado proporcionan una del paradigma por procedimientos, pero no se
secuenciales,
decir entonces que, para fines prácticos como vehículo para inspeccionar
en C++. Se recomienda la representación de
perspectiva de diseño propia de debe olvidar que para
DISEÑO DETALLAW EN INVERDDVI
control [loy90].
23
CAPINLO 2: MARCO TE6RICO
¿Queda explicita en el UML la representaci6n de diseño detallado orientado a objetos?
Una anécdoia
Durante el curso intitulado Tecnologia software para ambientes Web", impariido en Enero del año 2000 dentro de las instalaciones del CENIDET. al Dr. Oscar Pastor López (Jefe del Depto. de Sistemas Informátiws y Computación de la Universidad Poiitécnica de Valencia), se le hicieron. entre otras, preguntas con alusión a la siguiente idea: ¿Queda explicita en el UML la representaci6n de diseño detallado?. El wntexto en ese momento era la exposición de la intención de los diferentes diagramas del es6ndar UML.
Recreando s610 la esencia de las preguntas. sin tomar las palabras corno se dijeron literalmente:
Asistente al curso: Doctor, ~ c 6 m o se puede utilizar una notacidn detallada w n UML?
'En verdad os digo que has puesto el dedo en la llaga. Recuerde que el UML es una especificación lodavia incompleta"
¿Ud. cree que el estado actual del UML permite modelar disefio detallado de métodos de dases. con alguno de sus diagramas?.
Tomándose algunos segundos, volteando hacia arriba y finalmente apresurándose a contestar: 'El uso de diagramas del UML para eso mmhh. es cuestionable ..." La anterior anh io ta no tiene otro fin más que el de recalcar que hasta ahora no existe en el estándar una convenclón acerca de qué diagrama es el más apropiado para modelar ei disefio detallado. La validez del uso de un diagrama u otro es válida en términos del wntexto de desarrollo y is utilidad que al desarrollador le provea. ¿Alguna vez habr6 escuchado el lector la frase Estoy programando C++ estnicturado?. O bien la persona que dedar6 eso ignora la evoluci6n de los.paradigmas de programaci6n. o bien [intenta decir que le es práctiw.mezclar código en C wn objetos o viceversa!. Lo anterior no es tan .descabellado si se hace. por ejemplo, un reuso de funciones de la biblioteca estándar de C dentro de objetos. lo cual finalmente puede ser una estrategia útil para usar.funciones estándar probadas a manera de un wrapper0 un adapter:
Dr::
... Asistente al curso:
#include isldio.h,
class BufferedCutputScream : public OulpuLStr~ani I public:
I I
virtual inr YriLelFlLE 'ptr. char 'buffer1
retvm furite,b"ffer. 1. buffelre. PtTii //.rapper
i f e l d e d s c66igo ... 1
Lo cierio es que la lecnologia de'modelado del UML presupone una orientación a objetos pura y no contempla la inclusión de elementos. procedurales. En el wntexto del desarrollo de InverSOODA se identific6 un nicho de oportunidad al enwntrar que la ingeniería inversa del disefio detallado de métodos es, para fines prácticos. un mecanismo iitil vara recrear el disefio detallado de un lenouaie concebido híbndo desde su diseño. como lo es C++.
2.5.1
J. Howard Johnson el análisis de código para obtener entendimiento de código:
Niveles en los que se puede aplicar el análisis de código
sugiere un listado general de los niveles en que se puede aplicar
I . Texto simple: El cuerpo del código se considera como una colección de archivos cada uno de los cuales es una secuencia de caracteres agrupados en líneas.
24
2.
3.
4.
5 .
6.
CAPhuLO 2: MARCO TEÓRICO
*> _I
BASE TEÓNCA DEL ANÁLISIS DE CÓDIGO
Texto preprocesado: En lenguajes con preprocesadores de nivel textual como C O PLfI, el efecto de aplicar el preprocesador a . la colección de archivos es la expansión de macros e inclusiones. El resultado de dicha expansión es que el contenido de archivds individuales será entonces compilable, pero entonces se habrá perdido una sbpificativa 'cantidad de estructuras tales como constantes, funciones en línea, reflejará entonces cÓ
Secuencia de Lexem
aplicación.
aplicado a los archivbs individuales y reemplazado el contenido de éstos con una secuencia de elerdentos léxicos llamados lexemas.
entre otros. ~a estructura. organizacional y el cargador analizarán y constxuirán la
léxico de un compilador se habrá
Árbol Sintáctico: secuencia de elementos sintácticos se analiza con un parser que interpreta dentro de cada archivo un módulo analizador
sintáctico válido y prohuce un árbol sintáctico.
Arbol Sintáctico con anotaciones y Tabla de Símbolos: El árbol sintáctico se ha transformado para quitar la información sintáctica que no afecta .el significado. Las declaraciones de variables en el código ahora son entradas en una tabla de símbolos qua identificb propiedades de entidades semánticas. Las ocurrencias de las entidades en el ákbol sintáctico se correlacionan con la tabla de símbolos.
I .
Ejecución Abstracta: lógica del programa,
estudian flujos de control y datos particulares de la llegar a un entendimiento de lo que hace el código.
[San981 tomados de
Los niveles sugeridos por Jobson son muy parecidos a las fases de análisis de un. compilador. La explicac.ión es qud existen formalismos comunes a los formalismos en los ,que se basa un compilador, como be muestra en la siguiente sección. La diferencia entre ambos formalismos es de intenciód. Un compilador no se enfocan hacia la traducción entre lenguajes, más bien'a la
2.5.2 Traducción libres .de contexto
De manera análoga de contexto (LLC), se puede traducción de un lenguaje
código ejecutable.
de contexto (GLC) genera un lenguaje libre un mecanismo basado en GLC que genere la
'B'. Estos mecanismos son conocidos
I comúnmente como traductores.
25
CAP~TULO 2: MARCO TE~RICO
El esquema de traducción dirigida por la sintaxis es el tema sobre traducción de lenguajes que se trata en ambas partes con cierta similitud y que se aborda con mayor profundidad en esta sección.
ISan981 2.5.2.1 Traductores
Un traductor es un dispositivo tal que, dada una cadena de entrada x , calcula una cadena de salida y, de manera que el par ordenado (x, y) está en una traducción T dada. La traducción debe tener las siguientes características:
a) Debe ser legible. Esto es, debe ser fácil determinar cuáles pares (x, y) existen en la traducción.
b) Debe ser posible construir mecánicamente un traductor eficiente, para que la traducción se efectúe de manera directa desde la definición de ésta.
Características deseables en traductores:
u Operación eficiente. Para una cadena de entrada w de longitud n, la cantidad de tiempo requerido para hacer un análisis sintáctico de w debe estar en proporción directa con n.
o Correcto. Es deseable demostrar que el traductor funciona correctamente sobre todas sus entradas, a partir de un conjunto pequeño de pruebas.
[Aha981 2.5.2.2 Traducción dirigida por la sintaxis
La traducción de lenguajes libres de contexto puede ser guiada por una GLC. Esto se logra proporcionando información semántica a las construcciones del lenguaje a traducir. Es decir, se asocian reglas semánticas a las producciones gramaticales y opcionalmente atributos a los símbolos no terminales.
Hay dos notaciones para asociar reglas semánticas con producciones gramaticales: las definiciones dirigidas por la sintaxis (DDS) y los esquemas de traducción (STDS). En el proceso conceptual de traducción, tanto para las definiciones dirigidas por la sintaxis como para los esquemas de traducción, se hace un análisis sintáctico de la cadena de componentes léxicos de entrada, se construye el árbol de análisis sintáctico y después se recorre el árbol para evaluar las reglas semanticas en sus nodos, como se aprecia la Figura 2.2. La traducción de las cadenas de componentes léxicos es el resultado obtenido al evaluar las reglas semánticas.
Una implementación no tiene que seguir al pie de la letra el esquema de la Figura 2.2. Hay casos especiales de definiciones dirigidas por la sintaxis en las que se pueden implementar las evaluaciones sintácticas en una sola pasada, sin construir explícitamente un árbol de análisis sintáctico o un grafo de dependencias entre atributos.
26
Cadena de + Árbol de entrada sintákico
análisis + Grafo de dependencias + Orden de' evaluación de las reglas semántica
Regla Semántica
gramática libre del contexto para símbolo de la gramática ie asocia de reglas semánticas, para calcular que aparecen en esa producción.
expr.a := expr1.a digit0.a + expr.a := expr1.a digit0.a - expr.a := digit0.a digit0.a := O
digit0.a := 9 ...
especificar la estructura sintáctica de la entrada. A cada un conjunto de atributos y a'cada producción un conjunto 'los valores de los atributos asociados con los símbolos
Tabla 2.1 Definición dirigida por expresiones de suma y resta de posfija.
Las dependencias entre los atributos serán representadas mediante un grafo de
CAPhum 2: MARCO TEÓRICO
- , 2.5.2.4 Asociación de atributos en una definición dirigida por la sintaxis
En una definición dirigida por la sintaxis, cada producción gramatical A -+ a tiene asociado un conjunto de reglas semánticas de la forma b = f (ci, CZ, ..., ck), donde f es una función; y,
1. b es un atributo sintetizado de A y CI, c2, ..., ck son atributos que pertenecen a los símbolos gramaticales de la producción, o bien
2. b es un atributo heredado de uno de los símbolos gramaticales del lado derecho de la producción, y C I c2, ..., ck son atributos que pertenecen a los símbolos gramaticales de la producción.
En cualquier caso, se dice que el atributo b depende de los atributos c1 CZ, ..., ck.
[San981 2.5.2.5 Esquemas de traducción dirigidos por la sintaxis (STDS)
Existe otra manera para traducir dos lenguajes entre sí: el esquema de traducción dirigida por la sintaxis. Este esquema es una gramática que asocia ciertos elementos de traducción con cada una de sus reglas gramaticales, intercalados en los lados derechos de dichas reglas. La traducción se realiza de un lenguaje descrito por la gramática a otro lenguaje definido por los elementos de traducción.
[Ah0981 Los elementos de traducción son también conocidos como acciones semánticas que definen la equivalencia entre las oraciones de los lenguajes, al generar cadenas de salida a partir de cadenas de entrada. Las cadenas de entrada son porciones de oraciones que se derivan de la gramática. Las cadenas de salida son las cadenas de entrada traducidas.
Un esquema de traducción dirigido por la sintaxis (STDS) es una 5-tupla T = ( N, E, A, R, S ) donde:
N es un conjunto finito de símbolos no terminales C es un alfabeto finito de entrada A es un alfabeto finito de salida R e s un conjunto finito de reglas de la forma A-+a,P. Donde a E (N u I)*, p E (N u A)*, y los símbolos no terminales en p son una permutación en a de los no terminales. S es un símbolo no terminal distinguido en N, llamado símbolo de inicio.
2.5.2.6 Asociaciones entre símbolos no terminales dentro de reglas de producción
Sea A+ a$ una regla de producción. A cada no terminal de a hay asociado un equivalente en p no terminal. Si un no terminal B aparece en a y p sólo una vez, entonces es obvia la asociación.
28
CAPÍTULO 2: MARCO TEÓRICO
Si B aparece más de una ve se utilizan superíndices enteros para indicar la asociación. Esta asociación es parte íntima la regla. Por ejemplo, en la regla A+ B1CB2, B2B1C, las tres posiciones en B‘CB~ se aSocian con las posiciones Y, 3” y l a respectivamente en B’B’C. I
. 1 .
BASE TEÓRICA DEL ANÁLISIS DE CÓDIGO
2.5.2.7 Formas de traducción
Una forma de traducción T se
1. (S, S) es una forma de 2. Si (aAP, a’AP’) es una
están asociadas, y si, A-+ 2.5.1.5), entonces (ayP,a’y’P’)
Tanto, los no terminales y y exactamente como están asociados (ver sección 2.5.1.6).
Si las formas de traducción son relacionadas como se describe
(aA,P,
define de dos formas:
traducción, y se dice que las dos S están asociadas forma de traducción, en la cual las dos ocurrencias de A
y,y’es una regla contenida en el conjunto R (ver sección es a su vez, también una forma de traducción.
I’ como a P y a’ P’ se asocian en la forina de traducción en la regla, o bien, se utilizaran superíndices enteros
(aAP, a’AP’) y (ayP,a’y’P’) junto con sus asociaciones, en el párrafo anterior, entonces se escribe:
a’AP’) a (ayp, a’y’P’)
La traducción definida por T,
(%Y) I
2.5.2.8 Derivaciones de formas
Dada una cadena de entrada x se S utilizando las producciones de aZ, ..., a. = x, es una de tales traducción:
(ao, PO) 5
denotada por T(T) es el conjunto de pares:
* (S, S ) (y, Y), =E* Y YEA*)
de traducción
encuentra alguna derivación de x desde un símbolo inicial esquema de traducción. Suponiendo que S = a,~,“ ai,+=
dehaciones. Entonces, se crea una derivación de formas de
(ai, PI) = (az, P2) =-... -(an, Pn)
CAPITULO 2: MARCO TE~RICO
Producción
,. . ~ . tal que, (w,p 0 ) = (S, S), (a,,$ ") = (x, y), y -cada pi se obtiene-aplicando a pi., el elemento de traducción o la acción semántica correspondiente al ir de a i.1 a a i. La cadena y es una salida para x.
Elemento de traducción
2.5.2.9 Ejemplo del uso de un STDS
Considérese el siguiente esquema de traducción mostrado en la Tabla 2.2:
1) E = > E + T 2) E = > T 3) T = > T * F 4) T = > F 5) F = > ( E ) 6) F=>digito 7) digito=>O
16) digito => 9 ...
1) E = E T + 2) E = T 3) T = T F * 4) T = F 5) F E E 6) F=digito 7) digito=O
16) digito = 9 ...
Tabla 2.2 Esquema de traducción dirigido por la sintaxis que traduce expresiones aritméticas de suma y multiplicación, de notación en infijo a posfijo.
El primer elemento de traducción indica que la traducción asociada con el símbolo no terminal E de la primera producción es ET+; el segundo elemento de traducción muestra que la traducción asociada con el símbolo no terminal E de la segunda producción es T, y así sucesivamente.
¿Cuál será la salida para la entrada w = 2+3*5?. Primero se encuentra una derivación por la izquierda de w desde E, utilizando las producciones del esquema de traducción. Entonces, se calculan las derivaciones correspondientes a las formas de traducción como sigue:
( % E ) 3 ( E + T, E T + ) ( T + T, T T +) ( F + T , F T + ) 3 ( digito + T, digito T + ) ( digito + T * F, digito T F * + ) ( digito + F * F, digito F F * + ) ( digito + digito * F, digito digito F * + )
3 * 3 3
3
==? ( digito + digito * digito, digito digito digito * + ) 3 ( 2 + 3 * 5 ,2 3 5 * + )
30
CAPÍTUL.0 2: MARCO TEÓRICO
* .!l.
BASE TE6RICA DEL ANALISIS DE CÓDIGO
,sin un análisis profundo.
investigar formas de facilitar la ingeniería inversa.
integración de pursers ad hoc con herramientas de
CAP~TULO 2: MARCO TE~RICO
La integración de ingeniería inversa en SOODA representa un caso ejemplo de las ideas en la cita de Müller et al. Por un lado, se eligió un STDS (revisar la sección 2.5.2) como fundamento teórico para traducir código en C++ ai lenguaje del diagrama de clases del UML'O. Por otra parte, se seleccionó ei h t i r como ia tecnología que permitió construir el analizador sintáctico del InverSOODA. Sin embargo, se necesitó idear una manera para facilitar la integración del analizador con el resto de la aplicación. En el capítulo 3 se aborda cómo se realizó dicha integración. Sólo se mencionará por ahora que se echó mano de algunos patrones de diseño.
2.7 Patrones de Diseño Orientados a Objetos
El diseño y la instrumentación de un software orientado a objetos es sin duda una tarea complicada, siempre y cuando se recurra a la tradicional forma de construir software: el continuo redescubrimiento y reinvención de conceptos centrales que dan solución a problemas recurrentes.
Una solución que mitiga la complejidad de la implementación de aplicaciones orientadas a objetos es recurrir a la reutilización de componentes de software o de clases desde las bibliotecas de clases.
AI reutilizar ciertas clases y objetos se pueden construir complejas aplicaciones eficazmente. No obstante, el diseño embebido dentro del software con las características anteriores, se traduce en un sistema que refleja las necesidades actuales pero no necesariamente las necesidades futuras.
Afortunadamente, los patrones de diseño orientados a objetos ayudan a identificar las abstracciones menos obvias que pueden ser representadas en objetos. Por ejemplo, los objetos que representan un proceso o algoritmo que no ocurre en la naturaleza y, sin embargo, son parte crucial de un diseño flexible. Los objetos de este tipo rara vez se encuentran durante la fase de análisis o aún en las primeras etapas de la fase de diseño; son descubiertos después durante la tarea de hacer un diseño más flexible y reusable.
Pero, (,qué es un patrón de diseño? El concepto de patrón común de diseño fue introducido en 1988, con el Model-View-Controller (MVC) para Smalltalk. Sin embargo, un reconocimiento más completo del concepto de patrones de diseño orientados a objetos, fue madurado durante la primera mitad de la década de los años noventa principalmente por Erich Gamma:
"Los patrones de diseño orientados a objetos describen soluciones simples y elegantes hacia problemas específicos en el diseño orientado a objetos". "Son soluciones recurrentes a problemas de diseño que se presentan una y otra vez" [Gam951
'O Pana [Par001 propone una gramática que genera el lenguaje visual del diagarna de clses del UML.
32
CAPiTULO 2: MARCO TE6RiCO
2.7.1 Un nivel de abstracción
Por su parte, InverSOODA cue h ta con un diseño arquitectural de clases que ya incluye algunos patrones de diseño que bromueven el reuso de funcionalidades básicas y la integración de otros módulos de la
ri , . j .
PATRONES DE DISENO ORIENTALXX A OüETOS
más alto que el concepto de clase [Gam951
Tnángvlo Escslcno Triángulo Equilálcm Tningulo Ishecles
33
CAPhTJLO 2: MARCO TE6RlCO
-
2.7.3 Representación de estructuras todo-parte con el patrón de diseño Composite IGam95j
Composite Operation0 Add(Componente) Remove(Com ponente) GetChild(Componente)
La intención de dicho patrón es la de componer objetos dentro de estructuras de árbol para representar jerarquías de tipo todo-parte. Su uso se extiende principalmente a aplicaciones de gráficos como editores de dibujos y procesadores de texto, donde el usuario puede agrupar elementos gráficos para formar otros más complejos. Utiliza la composición recursiva en términos orientados a objetos. La clave en el patrón de diseño Composite es una clase abstracta que representa ambas clases primitivas y sus clases contenedoras. En la Figura 2.3 de la pá ina anterior se ejemplifica una estructura Composite: la jerarquía de figuras geométricas , que contiene a la superclase abstracta Triángulo y sus subclases Triángulo Escaleno, Triángulo Equilátero y Triángulo Isósceles.
La aplicabilidad de este patrón se da cuando:
5
Se quieren representar jerarquías todo parte de objetos. Se quiere que los programas cliente ignoren la diferencia entre composiciones de objetos y objetos individuales. Los programas cliente tratarán todos los objetos en la estructura Composite de manera uniforme.
La estructura general del Composite identificada por Gamma, se muestra en la Figura 2.4.
Figura 2.4 Estructura general del patrón de diseño Composite.
" Una variación del clásico ejemplo de la pmgramaci6n oricnrada aobjelos: la clase figura y sus subripas cuadrado, recfangulo, rombo. circulo, etc.
34
CAPITULO 2: MARCO TEÓNCO
IGam9SI 2.7.4 El patrón de diseño Bui der para creación de objetos compuestos . i PATRONES DE DISEÑO ORIENTADOS A OBJETOS
El patrón de diseño Builder tkne la siguiente intención: Separar la construcción de un objeto complejo de su representahn, tal que el mismo proceso de construcción pueda crear diferentes representaciones.
Su aplicabilidad se establece cua
El algoritmo que crea un complejo debe ser in$ependiente de las partes que forman el objeto y cómo sk ensamblan. El proceso de construccióh debe permitir diferentes representaciones para el objeto que se está construyendo. 1
2.8 Referencias
La Figura 2.5
patrones fueron diagramas de clase en uso práctico de los
de diseño Builder. Un objeto Builder Composite (ver sección 2.5.3); ambos
de representación y construcción interna de los En el siguiente capítulo, ,se aborda con más detalle el
Composite y Builder, además de algunos otros
comúnmente es
patrones también utilizados.
ConstiuirParteO ---m builder->ConctruiiPaite()
Figura 2.5 Estructu a general del patrón de diseño Builder. I
CAPhWu, 2: MARCO TE6RICO
[Big891
(Chi901
[Gam951
[ltC03]
[Joh93]
~JOY901
[LOP021
[MüiOO]
[ParOO]
[PreOZ]
[Pia951
[RurnOl]
[San961
[SchOO]
Wen021
[ZarnOl]
Biggersiaff, Ted J. Design Recovery for M&tenance and Reuse Computer. (E.U.: IEEE Computer, Julio de 1989) pp. 36-49.
Chikofsky. Elliot J. [y] Cross (I; James H. Reverse Engineering and Design Recovery: A Taxonomy. (E.U.: IEEE Sollware. Enero de 1990) pp. 13-17.
Gamma Ench et al. Design Patterns-Eiements of Reusable Object Oriented Software. (E.U.: Addison- Wesley-Longman.1995) pp. 3-31.97 163.
Instituto Tecnológiw de Ciudad Guzmán. Diserío detallado httl)~ilWWW.itw.edu.mx/inQsofUdetalla.hlm 19 Febrero de 2003.
Jonson. J . Howard. .identifyng Redundancy in Source Code using Fingerprints. (Canadá: Proceedings of CASCON '93. Toronto, Ontario. Octubre de 1993) pp. 171-183.
Joyanes Aguilar. Luis Fundamentos de Programación. Aigoritmos y Estructuras de Datos. (México: McGrawhilüinteramencana de México S.A. de C.V.) pp 511, 519.
Lbpez Sanchez. Maximo. Protocolo de proyecto a CONACYT. (Propuesta de proyecto sometida al CONACYT (con formato en documento electrónico). Cuernavaca. Morelos. México, CENIDET. G ~ p o de lngenieria de Software, Octubre de 2002).
Müller. Hausi A. et al. Reverse Engineering: A RoadMap. (Canadá: htto:iiwww.cs.ucl.ac.uMstaffA.Finkelstein~ose~nalmuller.~f, Mayo 2000) 12 páginas.
Parra Ramlrez, Isaac A. Modelado Wsual Orientado a Objetos. (Tesis de Maestrla. CENIDET. Cuemavaca. Morelos, Méuw. Diciembre del 2000) pp. 6.2, 1.6. A3.
Pressman, Roger S. lngenieria del Sofiware. Un enfoque práctico. Quinta Ed. (Madrid. España: McGrawhillilnteramericana de España, 2002) p. 546.
Plaitini. Mano [y] D&yanani Sunil. Elementos y Herremientas en el Desarmiio de Sistemas de Informacibn. Una visión acfual de la tecnolcgia CASE. (Madrid. EspaRa: McGrawhillilnteramencana de España - Rama, Serie Paradigma. 1995) p. 42-45
Rumbaugh James e l al The Unifiod Modeling Language Reference Manual (Indianápolis. IN E U Addison- Wesley Pearson Education. Agosto de 2001)
Santaolaya Salgado. Diciembre de 1998).
René Apuntes sobre compiladores (Cuernavaca. Morelos, México: CENIDET Junio.
Schmuller Joseph. Aprendiendo UML en 24 horas. (México: Pearson Educaci6n de México. S.A. de C.V., la Edicibn, 2000) pp. 99, 134.
Wences Dlaz. Martha F. Modelo de ingenieria inversa para la obtención de 'diserío detallado basado en LEVISS. (Tesis de Maeslria. CENIDET. Cuernavaca. Morelos. México, Febrero de 2002).
Zamudio Lbpez. Sheidy A. Ideniificacibn de Funciones Recurrentes en Sohare Legado. (Tesis de Maestrla. CENIDET. Cuemavaca. Morelos. México, Diciembre del 2001) p. 26.
36
Capítulo 3
3.1 Introducción 3.2 Arquitectura de InverSOODA 3.3 3.4 3.5 3.6 Interacción con InverDDVi 3.7 Referencias
Diagrama de clases de In\;erSOODA I Aspectos de diseño orientados a objetos Los analizadores de código fuente
1
“¡No hagas todo por mí, Emacs” K. Rodarmer
3.1 Introducción
Un modelo conceptual es una representación 1 de aito nivel de cómo se organiza y opera un determinado sistema. Involucra las más importantes metáforas y analogías empleadas en el diseño, los conceptos que el siskema expone a los usuarios, las relaciones entre dichos conceptos, los mapeos entre esaos conceptos y dominio de tareas que el sistema está diseñado a soportar [Dan02]. El lect r encontrará en este capitulo cuestiones sobre el diseño y arquitectura de InverSOODA, las estrategias de ingenieria inversa, la interacción con InverDDVi y el rediseño de la arbuitectura original de SOODA, y se describen con cierto detalle algunos aspectos que comF/lementan la comprensión del sistema.
P
I 3.2 Arquitectura de InverSOODb
La Figura 3.1 muestra la arquitec&a general de InverSOODA vista por capas de servicios'. He aquí su descripción: I
I a) Un usuario utiliza los siguientes servicios en la primera capa a través de la interfaz gráfica de usuario de inver OODA LT J Creadiagramas de claseS y diagramas de diseño detallado. J Genera archivos en medios persistentes que contienen el código fuente en C t t
correspondiente a los di gramas de clases. J Almacena la lógica de los diagramas en, medios persistentes.
fuente en C++ existente para obtener los
los objetos del ANTLR y los objetos de soporte a, los servicios de la primera
conjunto de mensajes que procesan información generada por pos eventos de usuario. En esta capa se determina el comportamiento dinámico d$ los objetos del sistema.
escalafón del conjunto de capas de software de InverSOODA. El sistema operativo
Windows XP Home.
c) Finalmente, la tercera capa u b ica los servicios del sistema operativo como el Último
puede ser Windows 9x, Windows Me O
1s palabra scrvicio con algún otra significado compuiacianal que arbitrano pan ejemplificar de mancra no convencional 18
39
CAPfTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA
lnteriaz
1. Capa
2' Capa
Código fuente en C++ Usuario
. . i
., . ... . - . . I
Figura 3.1 Arquitectura de InverSOODA vista por capas de servicios.
3.3 Diagrama de clases de InverSOODA
Recordando las ideas del segundo capítulo en la Sección 2.3.1 de este documento: *...un diagrama de clases provee la vista estatica de un software orientado a objetos y siempre debe ser dibujado para una aplicación orientada a objetos". La Figura 3.2 muestra las principales clases de InverSOODA.
40
- +
CAPhULO 3: EL MODELO CONCEPTUA, I DEL SISTEMA DIAGRAMA DE CLASES DE XNnRSOODA
41
1 1 1 j ' 1 :, .
~
I I ............ ...........
I
,177 I
. . CAPÍTULO 3: ELMODELO CONCEPWAL DEL SISTEMA
3.4 Aspectos de diseño orientado a'objetos
La siguiente sección describe los aspectos de diseño orientado a objetos tomados en cuenta para el rediseño de SOODA. Esto es, los aspectos de diseño que hicieron posible la. incorporación de la nueva funcionalidad provista por InverSOODA. Se hace énfasis en las partes de la arquitectura de InverSOODA en donde se aplican patrones de diseño orientados a objetos, aunque también se menciona la aportación de las clases de la Biblioteca de Clases Base de Microsoft, la MFC.
3.4.1 El Diseño de Aplicaciones MFC
Relevante es hablar de la biblioteca de clases llamada MFC (Microsoft Foundation Classes), debido a que originalmente SOODA e InverDDVi se basaron en ésta y a que InverSOODA continúa utilizándola.
La MFC es una biblioteca propia del entorno de desarrollo Visual C++ de Microsoft. El uso de la MFC estnba en ayudar a desarrollar aplicaciones de C++ para Windows 32 bits tratando de lograr los siguientes objetivos [parno]:
Reducción de la cantidad de código escrito para una aplicación en Windows. Habilidad para llamar a cualquier función de C directamente. Conversión de aplicaciones en C a Cti-. Facilitar el uso de la interfaz de programas de aplicación ( M I ) de Windows al utilizar caractensticas de C+t.
- 3.4.2 Arquitectura documento-vista
Cuando se utiliza el asistente de generación de aplicaciones de Visual C t t (AppWizard) se puede escoger la generación de una aplicación tipo MFC entre otros tipos de aplicaciones para Windows. Una aplicación generada como aplicación MFC tendrá necesariamente la arquitectura documento-vista.
Dicha arquitectura incorpora dos clases principales:
a) La clase documento. Corresponde a la clase que manipula la información que el usuario puede guardar desde la aplicación.
b) La clase vista. Se encarga de manipular la manera en que se presenta la información al usuario y de procesar los eventos de entrada.
42
C A P ~ U L O 3: EL MODELO CONCEPTUAL
Figura 3.3 Relación entre una aplicación MFC
_ . ._ -. j 1 ,
DEL SISTEMA ASPECTOS DE DISENO ORIENTAW A OBJETOS
I) La conformación de entidades mantenimiento.
No obstante existe un problema Potencial con el uso de la MFC: se pueden agregar a una aplicación MFC clases
En las siguientes objetos, como una que se tiene de
el usuario sin un esquema de reusabilidad.
el uso de patrones de diseño orientados a posibilidad de perder la escalabilidad y reuso
de código organizadas más entendibles y de fácil
CAP~IJLO 3: EL MODELO CONCEP~UAL DEL SISTEMA
3.4.3 Uso de los patrones de diseño Composite, Iterator y Visitor
3.4.3.1 Motivación
La aplicación del patrón de diseño Composite no difiere mucho del ejemplo clásico que aparece en el capítulo dos del libro de Eric Gamma [ G ~ ~ ~ S I , que trata del diseño de un editor de documentos, mejor conocido como procesador de texto. De hecho, los criterios de diseño tomados de dicho capitulo son casi idénticos. La diferencia está en la funcionalidad de SOODA, que mucho dista de ser un procesador de textos para enfocarse al modelado visual de sistemas orientados a objetos. Lo mismo ocurre para InverSOODA, pues su interfaz gráfica de usuario y su estructura interna de documento están basados en SOODA.
A partir de que en SOODA se identifica un caso típico de diseño que involucra una estructura de documento, se aplica el patrón de diseño Composite. Aunado al aspecto anterior, está el recorrido de dicha estructura por medio de objetos Iterator. Es decir, los datos de los diagramas están almacenados en una estructura de datos que puede ser recorrida de vanas formas. Además, se utilizó experimentalmente el patrón de diseño Visitor para efectuar acciones específicas durante el recorrido en cada nodo de la estructura Composite.
InverSOODA utiliza diferentes objetos visuales para desplegar los diagramas de clases: rectángulos, líneas, flechas, texto. El usuario de la aplicación utiliza estos elementos visuales para conformar sus diagramas, o bien realiza ingeniería inversa, lo cual trae como resultado los diagramas de clases con los objetos visuales correspondientes al diseño del código. ¿Cómo se tratan internamente estos objetos visuales?, ¿Cómo hacer para que un objeto visual llamado Flecha tenga su correspondiente objeto en el diseño de la aplicación?. Estas dos respuestas aforíunadamente ya tenían resultados desde SOODA IPdo1. Pero, ¿cómo hacer que un objeto parser generado con ANTLR pueda manejar transparentemente un objeto Flecha a manera de un objeto más abstracto denominado Grafico?, o, ¿cómo hacer que un objeto Diagrama derivado de Grafico se trate igual que los objetos tipo Grafico que contiene?. La repuesta a estas preguntas es utilizar algún tipo de estructura de datos para representar jerarquías de objetos todo - parte. El patrón de diseño Composite permite tratar los objetos dentro de este tipo de jerarquías uniformemente y casi siempre vienen asociados los patrones de diseño Iterator y Visitor para hacer recorridos y acciones variantes cuando se visita cada nodo de la jerarquía de objetos compuestos.
3.4.3.2 Aplicabilidad
Gamma [carn95] recomienda utilizar los patrones Composite, Iterator y Visitor en las siguientes circunstancias:
A) Composite
1) Cuando se quiere representar jerarquías de objetos todo -parte
CAr'hULo 3: ELMODELO C O N C E m A 1. DEL S l S E M A ASPECTOS DE DISENO ORLENTADO A OBJETOS
2) Se quiere ignorar la diferencia.entre composiciones de objetos y objetos individuales y trat d r ambos tipos uniformemente.
I ) Acceder el conten'do de un objeto agregado en estructuras Composite (o simplemente en li tas o vectores de objetos) sin exponer la representación interna de dicho objeto.
2) Se quiere objetos..
polimórfica).
7. 1 B) Iterator
múltiples formas de recorrido de listas o vectores de
uniforme para realizar los recomdos (iteración
C) Visitor
InverSOODA sólo se explica de esa intención del proyecto justificar o simplemente es una cuestión de obstante, se encontraron resultados 3..4.3.4.
Una estructura de interfaces dependen de su imp ementación concreta. Se necesita efectua, muchas operaciones o acciones sin relación alguna de objetos contenidos 'k n una esmictura de datos,' y no se quiere modificar o extender la impiemehtación de dichos objetos con las operaciones o acciones directamente. El p h n de diseño Visitor mantiene estas operaciones encapsuladas en ud objeto aparte y sabe llevarles la acción de dichas operaciones a los odjetos agregados en la estructura de datos, por medio de un mecanismo
cuando.
Composite contiene muchas clases de objetos con quiere efectuar operaciones en dichos objetos que
t
o double-dispatch p r n 9 5 ] . 18
la estructura de objetos cambian muy de vez en
manera. Recuerde el lector que no es propiamente la demostrar ,el uso de determinado patrón para algo,
conyeniencia y buen gusto por la tecnología de objetos. NO interesantes, mismos que se comentan en la Sección
CAph'WO 3: ELMODELO CONCEPTUAL DEL SISTEMA
3.4.3.3 Colaboraciones
La Figura 3.4 muestra al patrón de diseño Composite junto con los otros dos patrones descritos en esta sección2.
I'
Figura 3.4 Diagrama de clases con los patrones de diseño Composite, Iterator y Visitor embebidos en la arquitectura de InverSOODA.
Enseguida se describen las colaboraciones de las clases involucradas en los tres patrones en cuestión:
Composite:
o CGrujco: Es la clase abstracta en el tope de la jerarquía del Composite. Es la clase padre de toda clase que represente una entidad grafica en InverSOODA. Su interfaz permite que las clases hijas redefinan operaciones como Dibujar: un objeto rectangular evidentemente se dibujará en pantalla de manera diferente que una línea por ejemplo; pero también incluye métodos que le permiten establecer relaciones con objetos tipo Iterator y Visitor. Concretamente, CreurIterudor permite que cada clase hija cree o no su propio objeto Iterato? y Aceptar, cuya intención es que las clases hijas compuestas o simples puedan apegarse al patrón de diseño Visitor.
Algunas c l a s s del código fuente sc omiten por cumtiones de Sspacio, pero aparecen las más importantes. ' Tomando cn cuenta que los objetos del patrón Composite pueden ser simplcs o compuestos. para lor primems se crea por dcfceto u? objeto ltirator que itera en el vacio, caso contrario para los objetos compuestos, que pueden crear un objeto ltcrator a la medida de sus ePtNeNmS de datos.
46
CAPITIJLQ 3: ELMODELO CONCEPTUAL
I . 47
- - . - . - . - .- ~
..) * ' + . - PEL SISTEMA , ASPECTOS DE DEERo A osmos
CAF’fTULO 3: E L M O D E M CONCEPTUAL DEL SISTEMA
objetos Visitor. No redefine la creación de objetos Iterator pues es un objeto simple dentro del patrón de diseño Composite.
Iterator:
o Crierator CCGraJco*>: Es una clase abstracta parametnzada con apuntadores a objetos de tipo CGrafico. Define en su interfaz los métodos necesarios para recorrer estructuras Composite de tipo CGrafico. El recomdo de objetos simples se realiza iterando en el vacío. El recomdo de objetos compuestos se realiza dependiendo del objeto Iterator concreto que definan dichos objetos compuestos. El uso de templates de C t t en el patrón de diseño Iterator obedece a que la estructura de datos utilizada para definir el patrón Composite también debe ser parametrizada. Cada objeto compuesto es capaz de crear objetos Iterator concretos específicos a sus necesidades de recorrido.
o CListIterator <CGraJco *>: Es una implementación concreta de la clase Citerator. En InverSOODA es el Iterator por defecto para objetos compuestos tipo CDiagrama. Realiza un recorrido lineal de la .estructura de datos del objeto diagrama.
Visitor:
O CKiitor: Es una clase abstracta de la cual se pueden extender clases concretas CVisitor especificas al patrón de diseño Composite utilizado en InverSOODA. Su existencia obedece a definir una serie de métodos virtuales que corresponden cada uno a las clases concretas del Composite mencionado. Si durante el recorrido de la estructura Composite se ve involucrada una acción específica hacia un objeto, digamos de tipo CClase, entonces la implementación concreta del método VisitCClaseO sabe exactamente que sólo objetos de tipo CClase pueden recibirlo en su método Aceptar 0. No hay manera de confundir al compilador pues la firma que define CVisitor es Única para cada objeto Composite. Normalmente, los objetos Visitor comienzan su visita al Composite apoyándose del Iterator que crea CDiagrama. El primer objeto que visita depende de qué posición se encuentre en la lista de objetos simples del objeto diagrama.
o CApunfador: Esta clase es una implementación concreta de CVisitor y sirve para ejecutar la acción específica que corresponda a un objeto componente del Composite. Cuando el usuario de la aplicación ha pulsado un botón del ratón, estando la aplicación en modo apuntador, una acción específica será llevada a cualquier objeto simple del patrón Composite que pueda responder a ella. Así, la colaboración se da en el escenario dinámico entre objetos Composite cuyo estado podrá o no ser modificado y el objeto apuntador que lleva la acción modificadora a dichos objetos Composite.
O CDblClick: Esta clase también es una implementación concreta de CVisitor. Cada implementación de los métodos de CDblClick encapsula la semántica de ejecución específica para’ cada objeto Composite, a partir de un evento de doble pulso de
, .
48
puntero asociado con cierto
3.4.3.4 Consecuencias
objeto en la estructura de datos.
CAPhULO 3: EL MODELO CONCEPIUAL DEL SISTEMA
2. El uso de templates de C++ para parametrizar objetos Iterator permite mantener una relación con la clase CGrafico y todos sus descendientes: Un objeto Iterator siempre devolverá un puntero a CGrafico cuando se encuentre recomendo un objeto compuesto y esto supone una ventaja cuando se llaman solamente los métodos de la interfaz de CGrafico. Sin embargo, cuando se necesita saber con exactitud qué clase se está obteniendo desde la estructura de datos, entonces es necesario recurrir al RTT?, o a las macros de la MFC (RUNTIME-CLASS), o bien al uso de objetos Visitor.
Las consecuencias de usar el patrón de diseño Visitor son:
1. Permite añadir nuevas operaciones que dependen de los componentes de objetos complejos Composite. Por ejemplo, se puede definir una nueva operación obtener nombres de clases definiendo un nuevo objeto Visitor concreto que obtenga los nombre de todas clases que conforman un diagrama en InverSOODA. Lo interesante de esta cuestión es que no se necesita cambiar ni añadir nuevo estado ni implementación en las clases Composite para que la nueva operación funcione. El nuevo objeto simplemente va obteniendo los nombres de cada clase cuando visita objetos de tipo CClase.
2. Los objetos Visitor pueden ir acumulando valores estado, que de otra manera tendrían que estar pasándose como argumentos en los métodos que efectiian el recorrido de estructuras Composite.
3 . El uso de objetos Visitor de alguna manera rompe con el encapsulamiento de los objetos que visitan, pues para acceder al estado privado de estos Últimos necesita ser declarado comofn’end.
4. No es fácil añadir una nueva clase concreta Composite que responda a los objetos Visitor pues se tendría que añadir un método virtual para cada uno de dichos objetos Visitor. Esto podría implicar un gran esfuerzo si ya existen numerosas clases concretas derivadas de CVisitor.
3.4.4 Usa del patrón de diseña Builder cama base para construir el diagrama de clases
3.4.4.1 Motivación
El proceso de construcción de un diagrama de clases en SOODA es asíncrono. El usuario usa una barra de modelado con la cual se pueden escoger pequeños símbolos gráficos que representan las diferentes figuras que conformarán el diagrama de clases. Todo esto sucede en intervalos asíncronos de tiempo como se observa en la Figura 3.5.
‘Run Time Type Infamation
50
-
CAPhlJLO 3: EL MODELO CONCEPTUAL ASPECTOS DE DISEÑO OMENTAD0 A OBJETOS
La principal consecuencia de I a construcción asíncrona de un diagrama, es que impacta de manera directa en el diseño ¿e los mecanismos que responden a eventos asíncronos. Hablando en términos generales, la solución más común a la construcción asíncrona de
de ratón o de teclado. diagramas inicia con el procesamiento I de información tomada directamente desde eventos
Barra de modelado de SOODA
Evenlol: ... Eventon-I: ~ w n b , : crear Clase Crear clase Crear herehcia
Eventos aslncronos
Construcción del diagrama de clases
Representación Visual
.I
Figura 3.5 Construdción
Por otra parte, la construcción 1 del diagrama de clases visto desde un proceso de ingeniería inversa es síncrono. La Figura 3.6 ilustra dicho proceso: se puede visualizar la creación inversa como una máquida constructora, que asciende a través de un árbol sintáctico de derivación sincronizaddo la toma de información obtenida en cada hoja o nodo intermedio del árbol, desde sintácticos o de acciones semánticas. La información necesaria para realiza inversa viene entonces desde un flujo síncrono de tokens, que termina con un carácter EOF en el nodo raíz del árbol
De lo anterior se deduce que
sintáctico.
manera síncrona o asíncrona.
En InverSOODA el
dos formas de construir un diagrama: de
sí mismo, que se representa lógicamente y cada objeto contenido encapsula a su con un objeto
vez las características de cada gráficd del diagrama. El diagrama intrínsicamente mantiene I
asíncrona del diagrama de clases.
CAPITULO 3: EL MODELO CONCEPTUAL DEL SISTEMA
una composición de objetos, es decir, es un Composite (ver sección 3.4.3). Se puede hablar de que el diagrama es en sí un objeto complejo compuesto por muchos otros.
Código fuente
Obieto Parser
8 8 8 8 8 Infomacdn sincrona desde acciones semanticar O"
O - Area de Aplicaclón de SOODA
Construcción del Representación Visual diagrama de clases
Figura 3.6 Construcción síncrona del diagrama de clases.
¿Cómo construir un diagrama Composite de manera síncrona o asíncrona manteniendo una interfaz abstracta común para la construcción de diferentes diagramas?. Una forma adecuada es aplicando el patrón de diseño denominado Builder.
3.4.4.2 Aplicabilidad
Se recomienda usar el patrón de diseño Builder cuando [cam9S1:
I ) El algoritmo para crear un objeto complejo debe ser independiente de las partes que
2) El proceso de construcción debe permitir diferentes representaciones para el objeto conforman el objeto y de cómo se ensamblan.
que se construye.
El algoritmo síncrono para construir los diagramas de clases en InverSOODA es independiente del algoritmo asíncrono. El primero resuelve la obtención de información desde las acciones semánticas del objeto parser generado con ANTLR, y el segundo toma información desde eventos de ratón y teclado. Además, el proceso de construcción permite construir, ' potencialmente, diferentes representaciones para un objeto diagrama en particular, por medio de diferentes objetos Builder concretos. La Figura 3.7 muestra un
52
CAP~TULO 3: EL MODELO ASPECTOS DE DISERO ORIENTADO A OBJETOS
diagrama de clases de UML co h las actuales clases involucradas en el patrón de diseño Builder embebido en la arquitecdra de InverSOODA.
clases de manera asíncrona; proceso de construcción.
9 CInverSoodaDiagramaBuild de clases de manera síncrona,
Figura 3.7 Diagrama de clase UML del patrón de diseño Builder embebido en la arquktectura de InverSOODA.
I
es guiado por el objeto CSoodaLButtonUp durante el
r. Es el objeto cuyos métodos construyen el diagrama el objeto TinyCPPParser guía el proceso de 7 .
53
3.4.4.3 Colaboraciones I
C A P ~ J L O 3: EL MODELO CONCEFTJAL DEL SISTEMA
construcción por medio del preprocesamiento y envío de información semántica hacia dichos métodos.
TinyCPPParser. Es el objeto que realiza el análisis sintáctico de código fuente y que por medio de acciones semánticas controla el protocolo síncrono de construcción del diagrama de clases, apoyado por el objeto CInverSoodaDiagramaBuilder.
.
r n a a i r c n d l a g a m a I I I I
~ OnBvllonlnplnv ,:i CrearMaIodo _ _ _ _ _ Crsadlr lbulo
___- - J< Y
CraarCLiSs
Amadir en d l a g r s m i
I I
Figura 3.8 Diagrama de secuencias UML de los objetos en el patrón Builder.
3.4.4.4 Consecuencias
La interfaz.de la clase abstracta Builder permite ocultar la representación y estructura interna del objeto diagrama que construye, encapsulando también el proceso de construcción. En otras palabras, el código fuente de construcción y representación queda aislado de las demás clases de la aplicación. Sólo el objeto concreto Command (ver Sección 3.4.5) que responde al evento de levantar el ratón y el objeto purser (ver Sección 3.5) conocen el proceso y protocolos asíncrono ,y síncrono de construcción respectivamente. Dichos objetos representan los objetos directores mencionados por Gamma [ G ~ ~ S J . Por su parte, los objetos Builder concretos contienen la implementación apropiada para crear y ensamblar un diagrama de clases según el protocolo de construcción.
Otra consecuencia del uso del patrón de diseño Builder radica en que se obtiene un control más granular del proceso de construcción del diagrama de clases, respecto a la construcción de golpe que proveen otros patrones de diseño de creación como el Factory Method [Gam951 o el Prototype [ G ~ ~ ~ s I . El patrón de diseño Builder permite controlar paso a paso el ensamble de las diferentes partes que conforman un objeto diagrama y por consecuencia de la esmictura interna de este último.
54
.* , I CAPhWLO 3: ELMODELO CONCEPTUAL DEL SISTEMA ASPECTOS DE DISENO ORIENTADO A OBIETOS ! 3.4.5 Uso del patrón de diseño Command para eliminar dependencias entre la clase documento y la clase vista
3.4.5.1 Motivación I capacidad de
El esquema de de evento con algún
que se le dé al método implícita del identificador de
gráfica de usuario, se entra en el se selecciona un método específico
intrinzado mapeo de mensajes de MFC, lo común es que los objetos vista respondan a
barras de scroll y barras de herramientas,
evento. Por ciclo clásico de de un objeto manejador de Microsoft Windows. En eventos generados desde mientras que el los elementos Lie la barra de menú.
El problema se presenta la interacción a nivel mensaje de objetos entre el MFC es altamente acoplada. Es fácil caer en
dependencias entre objetos vista y objetos anterior no es probl'ema si la aplicación realiza
fácil codificar una aplicación para Windows mensajes y el manejo de cuadros de diálogo,
estatutos case y handlers con los que Sin embargo, cuando hay que
es bastante dificil moaificar la intención original los objetos vista o documento.
al método del objeto Vista que responde a
este método tenga el mismo que tiene definida la clase Vista.
con esta'situación, sin embargo, el más voluminoso y necesariamente
u objetos de la aplicación. Se corre el riesgo funcionalidad métodos como OnBuffonUp.
como Vista, manejador de eventos por orden específica para cierta semántica encapsulación de varias líneas código
problema es el patrón de
documento y la vista de implementaciones que
operaciones triviales bajo MFC, una vez para entonces
extender la funcionalidad de la con que se implementaron los
documentos e incluso
Supóngase, que I ' I eventos de soltar un botón del ratón. Dicho método originalmente ocasionaba que ciertas
variables se modificaran en el objeto documento, a partir de la coordenada en la que se
código que modifiquemos y generará más dependencias de que no sea tan trivial
¿ Que esquema defecto, pueda
55
CAF'hVLO 3: EL MODELO CONCEPTUAL DEL SISTEMA
. .
3.4.5.2 Aplicabilidad
Se puede hacer uso del patrón de diseño Command cuando [ G ~ ~ ~ s I :
1) Se parametrizan objetos que llevan implícita la acción a ejecutar.
2) Especificar, almacenar y ejecutar peticiones en momentos diferentes. Un objeto Command puede tener un tiempo de vida independiente de la petición original.
3) Permitir operaciones de deshacedrehacer. Un objeto Command puede almacenar el estado de ciertas variables para revertir el efecto de las operaciones del objeto realizadas.
En la versión actual de SOODA sólo se aplica parcialmente el punto número 1; se dejó el mapeo de mensajes al estilo de la MFC, lo que implica que automáticamente se generen métodos con una firma preestablecida. Lo anterior no permite cabalmente aplicar la estructura de clases propuesta por E. Gamma respecto al patrón Command. Sin embargo, todos estos puntos fueron considerados originalmente antes de aplicar el patrón.
3.4.5.3 Colaboraciones ,
La gran diferencia entre la estructura original del patrón Command propuesta por Gamma y la adaptación que se realizó en InverSOODA consiste en que no necesariamente existe un objeto receptor ni otro emisor. CVista hace las veces de receptor e invocante pues no existe el concepto puro de objeto invocante en el mapeo de mensajes MFC, mas bien se manejan los identificadores constantes al estilo IDBUTTONl, ID MENU ITEM. Puesto en otras palabras, no se pueden mandar como parámetros objetos command en métodos dentro del mapeo de mensajes MFC, para ajustar a la medida del patrón Command en la arquitectura documento-vista, al menos no de manera trivial. No obstante, sí se logró implementar parcialmente el patrón Command al diseñar objetos que colaboran con el objeto Vista para tomar la responsabilidad de atender a los eventos de usuario.
Concretamente, existe una jerarquía de objetos Command; una clase abstracta más una clase concreta por cada tipo de evento de ratón que maneje la clase vista. En la Figura 3.9 se aprecia cual es la vista estática de las clases involucradas con el patrón de diseño Command.
56
CAPhlJLO 3: EL MODELO CONCEPTUAL DEL SISTEMA ASPECTOS DE DISENO ORIENTADO A OüJETOS
CCommmd
E@mla,()
- - - - - - - - - - <-----.-.-------
OnBunonDom () ((depends >>
~ ~. . .
CSoodaLBvflOnüblClk CSoodaLBu«onDown i CSoodaLBultonUp
C A f h J L O 3: EL MODELO CONCEPTUAL DEL SISTEMA
3.5.1 Creación de analizadores de código con ANTLR
No es la intención de esta tesis proveer un tutorial sobre el manejo del ANTLR Sin embargo, se considera prudente y puntual mostrar al lector la manera básica con la que se especifica la creación de un analizador con la herramienta ANTLR. De tal suerte, se ayudará en la c.omprensión global de las siguientes secciones y particularmente al uso de acciones semánticas como mecanismo clave de la ingeniería inversa.
Es bastante natural la creación de analizadores con ANTLR. Sólo se necesita conocer la notación Backus-Naur o BNF, las expresiones regulares y tener nociones de programación en los lenguajes C++ o Java. ANTLR permite especificar un analizador para un lenguaje determinado (libre de contexto) a partir de la gramática que genera dicho lenguaje. Los siguientes pasos describen un poco más a detalle el proceso de creación del analizador:
1. Identificar la gramática BNF que genere el lenguaje que se quiera analizar. La gramática debe ser de tipo regular o libre de contexto.
Escritura de la gramática de acuerdo a la sintaxis de especificación del ANTLR, en un archivo de texto:
2.
a) Producción gramatical. Cada símbolo no terminal que derive en otros símbolos se escribe a la izquierda, seguido de dos puntos (e l caracter ‘:’ ), seguido de los símbolos terminales en los que deriva dicho símbolo no terminal. Se marca el fin de la producción gramatical con un carácter punto y coma ‘;’. Si existen más de dos derivaciones, se puede utilizar el caracter pipe ‘I>, para separar dichas derivaciones.
b) Acción semúntica. Si las producciones tienen asociadas una acción semántica, entonces deberá especificarse inmediatamente antes del caracter de término ( ‘;’ ) un bloque especial encerrado entre llaves.
3. Procesar el archivo de texto con la especificación gramatical con la utilena Tool de ANTLR, esto generará uno o varios archivos con el código fuente correspondiente al analizador que reconoce oraciones de la gramática especificada.
Ejemplo de gramática especificada para ANTLR:
1. Identificación de gramática
G = ( N, T, So, P ) , donde :
N = ( A, B , C ) T = ( a , b, c ) so = s
= ( s + ABC, A + aA. A + a , B -+ b B , B + b, c -f ac, c -fC )
58
2. Escritura de la gramática bajo
/ * Archivo gram * / header
las reglas de ANTLR, dentro de un archivo de texto:
' #include <stckio. h>
options 1
con el nombre grarnarica-ejemplo.g y
/ / aquí van opciones exclusivas para el
1 I
se tenga instalado el intérprete de java en el sistema. I,,
59
/ / una seccióh opcional para incluir código
class Lexer exte options
1
'
1 / / más opciones exclusivas para ei ANTLR
s : ABC
A : aA i
I a printf 'a" ) 1 B : bB
I b printf (I "b" 1 i
c : cc I c printf ( i
/ * fin de archivo
CAPiTULO 3: EL MOOELO CONCEPTUAL DEL SISTEMA
La Figura 3.10 de la página anterior muestra un sencillo ejemplo de archivo de especificación de gramática para ANTLR. Las producciones gramaticales se encuentran en negritas. Estas producciones gramaticales corresponden a las producciones P definidas anteriormente en el paso 1 del mismo ejemplo. Son bastante similares a una especificación en notación BNF. Por ejemplo:
S : ABC; equivale en BNF a: < S > ::= < A B 0
El lector notará que también existen otros elementos dentro del archivo ejemplo como comentarios estilo C / C++, algunos bloques encerrados entre llaves, entre otras cosas. Los bloques encerrados entre llaves que preceden el caracter de cierre de producción gramatical ‘;’ son las acciones semánticas. Por ejemplo:
B : bB I b printf ( “b” ) 1 ;
la llamada a la función de biblioteca estándarprintfcorresponde a la acción semántica de la regla de producción B => b, que en este caso significa:
Cuando el símbolo no-terminal ‘B’ derive en el símbolo terminal ‘b ’, imprimir en salida estándar el carácter ‘b ’.
3.5.2 Analizador Léxico
El analizador léxico o lexicográfico que realiza InverSOODA se concibe como un módulo de software que realiza ordenadamente los siguientes pasos:
1. Lee de manera secuencia1 como un flujo de caracteres de texto el programa fuente en lenguaje C++.
2. Analiza caracter por caracter la cadena de entrada y construye subcadenas con significado llamadas muestras o tokens.
3. Alimenta a otro módulo de software denominado analizador sintáctico con dichas muestras.
Las muestras se obtienen de acuerdo a reglas que definen el contenido de las muestras.
AI contenido de las muestras se le conoce como lexema. Entonces, ¿qué se requiere para conshuir el analizador léxico?. Se debe definir el conjunto finito de muestras y describir qué cadenas forman las muestras. Además, la implementación debe cumplir los siguientes puntos:
. 9
9
1
El reconocimiento de las cadenas correspondientes a las muestras La entrega de las muestras reconocidas. El regreso del valor o lexema de las muestras. Proveer una forma de resolver ambigüedades. La asignación de atributos de la muestra.
60
CAPÍTULO 3: EL MODELO CONCEPTUAd DEL SISTEMA LOS ANALIZADORES DE CODGO FUENTE
Con la herramienta ANTLR los requisitos anteriores cabalmente al automáticas de generación de analizadores.
con ANTLR es que produce clases en utiliza un objeto denominado lexer
de código en C++. Cabe
igual que con muchas otras Respecto a dichas lenguaje C++ o generado con mencionar que el analizador Béxico de InverSOODA reconoce muestras para un vocabulario parcial del lenguaje Cb+.
En la Tabla 3.1 se enlistan las muestras y los correspondientes lexemas que permiten reconocer las muestras léxicas d I interés para un proceso de ingeniería inversa con la herramienta InverSOODA: I
Muestra o token Palabras reservadas
Lexema int, char, bool, float, double, void, long, signed, unsigned, short, if, else, while, class, StruCt, union, private, protected,
Enseguida se muestran una serie de permiten al analizador léxico reconocer
ilustraciones con' la representación de las reglas que las muestras listadas en la Tabla 3.1,
CAPITULO 3: EL MODELO CONCEPTUAL DEL SISTEMA
La Figura 3.1 I muestra el autómata que define la regla para reconocer las palabras reservadas de C++ de interés. Se reconocen las palabras reservadas que definen tipos enteros, de punto flotante, booleanos y sin tipo; cláusulas de selección del tipo i f / else; repetición del tipo while; y, palabras reservadas clave para definir tipos de datos abstractos: class, struct y union, con las palabras reservadas que definen alcance: public, private, y protected.
ini
Figura 3.1 1 Autómata reconocedor de palabras reservadas
62
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA LOS ANALIZADORES DE CODIGO FUENTE
Los caracteres en blanco se reconocen con el autómata desplegado en la Figura 3.12. El interés en reconocer caracteres en blanco tiene la misma finalidad que la de un compilador de C++, discriminarlos.
Caracteres en blanco \t
I '
\n
\r
Figura 3.12 Autómata reconocedor de caracteres en blanco.
Por su parte, tanto la Figura 3.13 como la Figura 3.14, ilustran los autómatas que reconocen los comentarios clásicos de C++. La finalidad de reconocer comentarios es la de discriminarlos. Sin embargo, en el trabajo de Biggerstaff (ver Sección 1.1.2 del capítulo 1), el tratamiento sofisticado de comentarios en procesos de recuperación de diseños puede jugar un papel interesante. Desgraciadamente, no está dentro del alcance de este trabajo, investigar más a fondo la importancia de los comentarios en la recuperación de diseños que tengan que ver con el diagrama de clases o del diseño detallado.
E
Comentarios de
cualquier otro carácter menos \n
cualquier otro caracter menos \n
Figura 3.13 Autómata reconocedor de comentarios del tipo doble - diagonal
63
' CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA 'I ,I
Figura 3.14 Autómata reconocedor de comentarios del tipo diagbnal - estrella. I1
La Figura 3.15 muestra un conjunto de caracteres simples reconocidos con los autómatas de la misma figura.
Dichos caracteres simples se utilizan cotidianamente en la codificación de programas en C++, aunque distan de ser la totalidad de caracteres simples que pueden considerarse como muestras. Para el objetivo de este proyecto sólo fueron los necesarios.
( Paréntesis izquierdo
)
(
)
Parbniesis derecho
*
- -
Figura 3.15 Autómata reconocedor de diversos caracteres simples.
64
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA ' LOS ANALIZADORES DE CODIGO FUENTE
I Caracteres de escape
cualquier otro carácter menos \
Caracteres literales
Figura 3.16 Autómata reconocedor de caracteres literales.
Tanto caracteres literales como cadenas literales son englobados como muestras en el análisis léxico, ilustrados en las Figuras 3.16 y 3.17. Este tipo de muestras son un tanto más complicadas para el análisis léxico debido a que pueden contener caracteres que a su vez se consideran como caracteres simples.
Caracteres de
Caracteres de
I \ cualouierotro carácter l. / /
Figura 3.17 Autómata reconocedor de cadenas literales.
La Figura 3.18 tiene ilustrado el autómata que reconoce las secuencias de escape. Estos caracteres especiales también se consideraron puesto que pueden verse como un subautómata de los autómatas de las Figuras 3.16 y 3.17 anteriores.
65
~~~ ~~ ~
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA
de escape It
'I Figura 3.1 8 Autómata que reconoce caracteres de escape.
I/
Para poder reconocer tanto identificadores como números enteros; es crucial identificar digitos. Entonces, se puede ver como un subautomata el dibujo de la Figura 3.19 al enfocarse tanto hacia el autómata de la Figura 3.20 como al autómata de la Figura 3.21.
I/
8
6
4
2
I1
I
O 11 1
3
5 I1
7
9
Figura 3.19 Autómata reconocedor de dígitos decimales.
66
I
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA LOS ANALIZADORES DE CODIUO FUENTE
Letra
Digito
Identificador I
Digito II
Los autómatas de las Figuras 3.20 y 3.21 reconocen números enteros e identificadores respectivamente. El reconocimiento de identificadores es de especial relevancia para el proceso de ingeniería inversa, debido que normalmente un identificador representa el nombre de clases, de variables y de métodos o funciones.
En la sección posterior se explica porque es especialmente importante el reconocimiento de identificadores durante un proceso de recuperación de diseiios.
Numero entero
Digito
+----?t Digito
Figura 3.20. Autómata reconocedor de números enteros.
~
Figura 3.21 Autómata reconocedor de identificadores.
3.5.3 Analizador sintáctico y semántico
Una vez que las muestras son aceptadas o reconocidas por el analizador léxico (ver Sección 3.5.2) el segundo paso en la recuperación del diseño desde código fuente es entender la estmctura de las oraciones del lenguaje C++. El analizador sintáctico de InverSOODA verifica que las muestras obtenidas ppr el analizador se encuentren dentro de la estructura sintáctica del lenguaje C++ pero, además, realiza a la vez el análisis semántico que a la postre es la clave de la ingeniería inversa propuesta en este proyecto.
61
CAP¡TULO 3: E L MODELO CONCEPTUAL DEL SISTEMA I!
3.5.3.1 Análisis sintáctico del lenguaje de programación C++
El lenguaje C++ ha sido reconocido por la comunidad de desarrolladores como un lenguaje cuya gramática es extremadamente ambigua. Esto se traduce enlque el análisis sintáctico de la totalidad de este lenguaje sea una labor bastante compleja. Se necesitan aplicar métodos y estrategias de desambiguación para poder interpretar o compilar toda la expresividad del lenguaje. Constantemente están siendo mejorados los compiladores de C++ para poder analizar eficazmente el código y crear imágenes 'kjecutables o bibliotecas de clases. Aún a la fecha, los compiladores comerciales o libres como Microsoft Visual C++ o Borland C++ para sistemas operativos Windows, Metrowerks de Macintosh o GCC para sistemas Linux varían en el resultado directo que emiten después de un proceso de
I I1
1
it
I1
I/ análisis de código fuente en C++. I1
El hecho de construir un analizador sintáctico para todo el espectro de producciones gramaticales es de una complejidad inalcanzable para un proyecto de las dimensiones de este trabajo. Sin embargo, se pudo identificar un subconjunto de la gramática lo suficientemente completo para traducir oraciones de C++ a diagramas de clases en C++.
I/
j
I)
3.5.3.2 Uso del ANTLR en la construcción del analizador sintácfico de C++
La herramienta ANTLR juega un papel primordial en la construcción del analizador sintáctico de InverSOODA, pero también en el análisis semántico. El ANTLR tiene entre otras muchas curiosidades, mecanismos de desambiguación I) llamados predicados sintácticos con los que fue posible evitar la creación de árboles de derivación no deseados. Además, la simpleza y naturalidad con la que se puede definir enjun archivo de texto la especificación gramatical del lenguaje (ver Sección 3.5.1), permite ajustar casi a la perfección los esquemas de traducción STDS. ANTLR permite utilizar acciones semánticas intercaladas en las producciones gramaticales que en InverSOODA sirven para controlar la traducción. t
I/
I
.I
<
111
(I
3.5.3.3 Esquema de traducción aplicado en la recuperación de diseños
En esta sección se incluye la Tabla 3.2. que lista en la primera columna las producciones gramaticales apegadas ai esquema de traducción. En la segunda ,tcolumna aparecen las acciones seinánticas correspondientes a cada producción gramatical.
/I Las producciones gramaticales están ordenadas de acuerdo a la clasificación en el Apéndice A en se trata de varias secciones que engloban las reglas gramaticales de C++ conforme al tipo de oración que generan. Para algunas producliones gramaticales no fue necesario asociarles acción semántica alguna, pero existen :lpara poder seguir la secuencia de derivación. Cabe mencionar que es de especial importancia el previo reconocimiento léxico de identificadores puesto que durante el analisis semántico éstos normalmente son candidatos a representarse como la figura clase dentro del diagrama de clases recuperado.
68
- .- .......
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA LOS ANALIZADORES DE CÓDIGO FUENTE
. . . . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esquema de traducción entre el lenguaje C++ y diagramas de clases del UML i
1 sección 1. Programa
~ c Z i & n T ~ a Z i E i i - rAc,;ones semánticas l ~ -_ 1
i -- i i
1 agregaciones encontradas, crear las figuras ~
1 correspondientes.
.__.___-, 1.1 UnidadDeTraduccion => declaracion EOF 1.la. Recorrer un vector con las
agregacion y asociarlas con las clases
1 j 1.1 b. Recorrer un vector con las herencias 1 encontradas, crear las figuras herencia, y asociarlas con las clases correspondientes.
I i ' Sección II. Expresiones
-..-~--~-..__._I-I I___
---[Acciones semánticas _l_________-_-___l ~ ~.
Producción gramatical 11.1 exprld => idNoCualificado 11.2 idNoCualificado => ldentificador
- -.__ __._.-.-_I_. ~ -__I---_-.._
2.2 Almacenar el nombre del ldentificador r como nombre temporal
1 Sección IV. Declaraciones
Froáucción gramatical l.lV:l declaracion => declSimple
----.---.--___I__ bcciones semánticas
........ __ ................ __ . - - declSimple => secDeclEsp IistalnicDecla ; f-
-. -
- r'-declSimple => IistalnicDecla ; r-- [ .''' deciSimple =7 ;
r--- I If3'secDeclEsp => especDecl I
...................... ............... .... ..... ....... ..... . . - declSimple => secDeclEsp ; I-- - ~-
.................................................... .. - . ... - - - - -
I IV.4 especDecl => especTipo I -
rN.5 especTipo => especClFe ___ -r--- [ especTipo => especSimpleTipo r-- , I" especTipo => especElabTipo -
.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .............. ............... . .......... ... - ........................................................ ......... ........... ................. ....................... ..... ........... ..,4_..- I I IV.6 especSimpleTipo => nombreTipo . a Verificar si el nombre del tipo
1 corresponde a una agregación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .i .... . . . . . . . . . . . . . . . . . . . . . .~. ....................................... I
I "' especSimpleTipo => tipoFlotante - .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ......... ................ .. .,. ................................ . :
- i.-. - ¡ "' , ,
esDecSimDleTiDo => tipoEntero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ ............. -. .............. ............... 1 ' "'especSimpleTipo => boo1 /'4:6b'Almacenar boo1 como tipo temporal
~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - .......... .- ....... .-~ ........................ . ~- .~ ...................... ~1
Tabla 3.2 Esquema de traducción entre e l lenguaje C++ y diagramas de clases del UML
69
/I ! -
I1 CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA
I/
....... 7- Esquema de traducción entre el lenguaje C++ y diagramas de clases del UML (continuación ...)
................. . . . . . . . . . . . . . . . . . . . . . . . . . . L. . . . . . . . ., . . . . . . . . . . . Producción gramatical "'['Acciones semánticas
.................................................................... . . . . . . . . . . . . . . . . . . . . . . - ... . . . . . . . . . . . . . . . . . . . . . . . . . . I-'-- .... .... :
i"IV.7 especElabTipo => claveclase 1 iV.8 nombreTipo => Identificador
. . . . . ,'4BAimac.e .... nar el nom'bre del ldentificador j I como el tipo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...........I. ............................ .-~...> I IV.9 especFunc => inline
i especFunc => virtual ' 1 i
i V.¡ IistalnicDecla => IistalnicDecla, decllnic /'''''''.' - V.2 decllnic => declarador " j -
r--
- ................................................................ . . . . . . , . , . . -
.~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... ....... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - . ~ ~ . . . . . .
~... ; Secci6n V. Declaradores
. ...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-. . -, ._ . _II.._._.__..._____._ - - I -
.-____I__ ; V.3 declarador => exprld ( ) I declarador => exorld
--
.....
..................
. . . . . . .
............ ......
. . . . . . . . . . . . . . .
.. :
...................................... ... -
", . . . . . . . . i'.' metodoVirtual => secDeclMetodoVirtual ,
i:..'.' . ~ . ~ .......... ._ . .~
~~8cecDeclEspMetodoVirtual => virtual r -11
........................................................................................................... ~- - - especTipoRetFunc inline I V.9 secDeclEspMetodoSimple => especTipoRetFunc inline V.10 secDeclEspFunc => especTipoRetFunc especfunc
esDecTiooRetFunc
I/ --- r- - " r- - ._..________.._-._____---....I_.__-____.- - secDeclEspFunc => especFunc
--..........I. ........ L ...... -
..,.. I v.1 I especTipoRetFunc => especSimpleTipo r
I--'- I---- especTipoRetFunc => void . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ............. ........................................... . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
I/
- __
.. . . . . . . . . . . . . , ................. ...,. .................. .... .... ...................................
Tabla 3.2 Esquema de traducción entre e l lenguaje C++ y diagramas de clases del UML (continuación.. .)
4
70
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA LOS ANALIZADORES DE CODIGO FUENTE
-__ . .- . - ....... ~ - -. - - -. .. - -. - . .- - .............
Esquema de traducción entre el lenguaje C++ y diagramas de clases del UML (continuación ...)
j sección V ia Clases
.- .- , __ I ... ........... ... .. r----- ~ Producción gramatical 1 especMiembro ]
1 Acciones semánticas i 6a.la Crear la figura clase en base a la 1 clase temporal y los valores de esta ultima I 1 6a.l b Limpiar todo almacenamiento de I atributos temporales
_______.I" .
Vla.1 especclase => cabeceraclase t
I
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................................................... ~- ... ~
6a.2a Almacenar el nombre del ldentificador como el nombre de la clase 6a.2b Almacenar el nombre del ldentificador como el nombre de la clase
i !
!
........... ...............................
i
rVra2-cabeceraClase => claveClase ! ldentificador
cabeceraclase => claveClase 1 ldentificador clausulaüase
.- __
j 1 6 a . 2 ~ Verificar si el nombre del tipo I corresponde con una herencia 1 k.a:3EFeZuna figura clase temporal
... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i l 'Via32aveciase => class [ c l a v e c l a s e => struct I--- -
- . ......................................... ................................. I claveclase ____ => union , I
I Vla.4 especMiembro => declaracionMiembro ~ ____ -
especMiembro => declaracionMiembro - esDecMiembro
I esDecMiembro => esoecAcceso : I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ _ _ _ ....................... i i'.' especMiembro =>.especAcceso : i... . - ~
~-
I especMiembro j
temporal en base a los demás datos ~
temporales !
-- ................... ., .. ., ........ ................................... . ~ , . . . . . i : 6a.5a Establecer los métodos de la clase ¡
I
1 ....................... ............ ______.___ ..,...... .............. j
6a.5b Establecer los métodos de la clase temporal en base a los demás datos temporales 6 a . k Establecer los atributos de la clase temporal en base a los demás datos temporales
j I i
Vla.5 declaracionMiembro => defFuncMiembro ;
~
__ declaracionMiembro => I defFuncMiembro
~
i i "- :
-
declaracionMiembro => especSimpleTipo
1 IistaDeclMiembro ; r declaracionMiembro => ; r- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... ,... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . / ~ ¡ ~ ~ s t a D e c l M i e m b r o => declaradorMiembro - . . . . . . . . . . . . . . . . . . . . . . ................. ... . 1 ListaDeclMiembro => IistaDeclMiernbro , -
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .......... . . . . . . . . . . . . . . . . . . . . . . . . ..,. ......... 1 1 declaradorMiembro I lVla.7 . . . . . . . . . . . . declaradorMiembro .-
. . . . . . . . . . . => declarador , . . . . . . . . . . I - -.' -. - , .......................... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabla 3.2 Esquema de traducción entre el lenguaje C++ y diagramas de clases del UML (continuación ...)
71
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA I/
t tipo temporal
Almacenar combinación de entero signo como el tipo temporal ~ - - ~ -
tipoEnteroConSigno => (todas las combinaciones del lado derecho anterior) - VIL4 tipoEnteroSinSigno => unsigned short int unsigned short int como
j I ! Esquema d e traducción entre el lenguaje:C++ y diagramas de clases del UML (continuac'ión ...)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . _ .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ ~ . , ~
Sección Vlb. Clases Derivadas ._"____..__I_ .. Producción gramatical - .__.I" __._- Vlb.1 clausuiaBase => : especAcceso nombreTipo Vlb.2 especAcceso => private _ ....................... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
especAcceso => public
especAcceso => protected ..._......__._._I ___-.I-.-.
_--.I_-_ ____.--
.______I .I__--___ ~ ... Acciones semánticas "' .~ . . - ... . . . . . . . . . . . . . . . ,. ................. 6b.2a Almacenar private como el acceso :
temporal 6b.2b Almacenar public p r n o el acceso ~
temporal 6 b . 2 ~ Almacenar protected como el a c c e s o :
I
........................ ................... . . . . . . . . .
. _-
i temporal ........ ') ~ ._l__ll_-_ 1 Sección VII. Reglas de producción para tipos de datos i
..... ........ -~..I..-...-.- _ .- -~ ............. ... r - ~ - tipoEnteroSinSigno unsigned long int como el I tipo temporal ! .. L . . ........................................... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 . 4 ~ Almacenar combinacióp de entero j i I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5a Almacenar unsigned char como el !
I1 ~
1 V11.5 tipocaracter => unsigned char 1
7.5b Almacenar signed char'como el tipo ~
temporal i 1 7 . 5 ~ Almacenar char como ei,tipo temporal I
r s a r a c t e r => signed char i < _ ~ _.____._____.__r.l-_____.. - t
j tipoCaracter.=> char
Tabla 3.2 Esquema de traducción entre el lenguaje C++ y diagramas de clases del UML (continuación ...)
sin signo como el tipo temporal
1 tipo temporal
i ' r
tipoEnteroSinSigno => (todas las combinaciones del lado derecho anterior)
--I
i _I___ _---_I
-. ......................... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
:,
72
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA LOS ANALIZADOES DE CODICO FUENTE
De manera conceptual un ejemplo sencillo de traducción bajo el esquema de la Tabla 3.2 se realizaría así:
Código fuente Diagrama de clases UML
Figura 3.22 Traducción entre una clase en código fuente hacia una figura.
UoidadDeTraduccion 6a.la 6a.lb 1 1 c cabeceraclase [ espechniembro j 1
1 1 1 1 1
Dedaraci6o
dedSimple
secDedE~pec
e~pecDecl
eSpeCTipo
especc1ase-
6b.2b w I I
1 6a.5b 1 defFUnCMiembiO
1 rnetcdoSimple
IipoEnIer~ declaradorMiernbr
1 1 Iip~EnIeroC~nSign~ declarad
1 7.3n in,
1 exprld
1 2.2
secDelEspMelcdoSirnple declarado
rfi 1 1 1 1
BspecTipoRetFunc
exprld ( ,J
1 tipoEnIero
idNoCualificado
especSimpleTipo 2.2 1 Idenüficador - char tipocaracter 2
Figura 3.23 Ejemplo de árbol sintáctico de derivación con acciones semánticas
73
_-
CAPiTULO 3: E L MODELO CONCEPTUAL DEL SISTEMA
En la Figura 3.23 de la página anterior, las acciones semánticas se aprecian con la numeración descrita en la Tabla 3.2, en letra negrita, y al lado de la’producción gramatical que las produjo. De esta manera, si se graficara el orden de aparición de las acciones semánticas y la traducción que realizan se apreciase algo como lo ‘mostrado en la Figura 3.24.
6a.3
I I I I I 1 I I I
6b.2b
7.311
2.2
6 a . 5 ~
7 . 5 ~
2.2
6aSb
6a.la
6a.la
Se traduce a O01
Se traduce a
o n e
u n o
,on>
Se traduce a
Se traduce a
Se traduce a
Se traduce a
Se traduce a
Se traduce a
10-
Se traduce a
10-
Crear una clase temporal
Almacenar public temporalmente
Almacenar int temporalmente
Almacenar “x” temporalmente
Establecer un nuevo atributo en clase e temporal
Almacenar char temporalmente
Almacenar “f’ temporalmente
Establecer u n nuevo o método en clase temporal
Crear la figura Clase con el identificador que sigue a la palabra class y con los valores de la clase temporal
e I + x : ’ T I + f(): char
, Figura 3.24 Orden de ejecución de acciones semánticas y sus correspondientes efectos en la traducción.
74
I
I i
~
I
I
t
I
~. . . . . . . . - -. . . .. . . . - _. ~~
y’*‘ 1..
CAP~TULO 3: EL MODELO CONCEPTUAL DEL SISTEMA INTERACCiON CON INVEFdlDVi
3.6 Interacción con InverDDVi
El presente proyecto plantea que es factible la recuperación del diseño detallado de métodos de clases. Retomando algunas ideas de la Secciones 2.3.2 y 2.4 del segundo capítulo, se tiene que InverDDVi es la herramienta con la que se auxilia InverSOODA para recuperar el diseño detallado. ¿Cuándo se presenta la interacción entre InverSOODA e InverDDVi?. Una vez que se realiza el proceso de ingenieria inversa para obtener el diagrama de clases, se puede proceder a llamar InverDDVi individualmente para cada método de cada clase (ver Figura 3.25)
Proceso de ingenieria inversa para obtener el diagrama de clases del
<< produce >>
Sintáctico Semántico
.y*. -..-..,.
e-, i:::: 1 - - :”.-
Despliegue independiente del diseno detallado del método de’clase al que se le aplique ingenieria inversa con DOVi.
. ....... ...., ..... Diagrama de clases
hlormac¡un sobre
especifico+ la clase que los
El usuario de la aplicación tiene la responsabilidad de llamar a InverDDVi desde la interíaz de InverSooda para obtener el diagrama de Warnier de cada método.
~~
Figura 3.25 Interacción de la herramienta InverDDVi en el proceso de recuperación de diseño detallado de métodos de clases.
InverDDVi toma el nombre del método del que se requiere obtener el diseño detallado para iniciar su propio proceso de ingeniería inversa. Los nombres de los métodos específicos a una clase están almacenados en un vector de cadenas o strings en dicha clase. La interfaz gráfica de usuario de InverSOODA permite realizar la llamada al módulo InverDDVi. Los detalles del cómo se realiza esta llamada y muchos otros aspectos de implementación de InverSOODA se encuentran en el siguiente capítulo de este documento.
75
CAPiTULO 3: EL MODELO CONCEPTUAL DEL SISTEMA
3.7 Referencias
[Ant031 ANTLR. ANother Tool for Language Recognition. htto:l/antlr.orql I 9 Febrero de 2003.
Daniels John. Modeling with a Sense ofpurpose. (EU.: IEEE Sohare, EnerilFebrero de 2002) pp. 8-10
Gamma Erich et al. Design Patterns-Elements of Reusable Object Orie+ed Software, (E.U.: Addison- Wesley-Longrnan.1995).
Parra Rarnirez. Isaac A. Modelado Visual Orientado a Objetos. (Tesis de Mabstria, CENIDET. Cuernavaca. Morelos. Mexico. Diciembre del 2000) pp. 5.8, 5.4.
Company, Segunda Edición, 1991) pp. 614-616.
[Dan021
[Gam951
I/
[ParüO]
ll
[Ctl91] Slroustrup Eijarne. The C++ programming language. (New Jersey, EU!: Addison-Wesley Publishing
'!
76
Capítulo 4
.
"Si no saben programar, ZEnionces qué saben?" R. A. Pazos
4.1 Introducción 4.2 4.3 4.4 Pruebas 4.5 Referencias
Manejo de la interfaz gráfica de usuario Implementación de los analizadores de código fuente
INTRODUCC~ON CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
4.1 Introducción
El presente capítulo da a conocer al lector un resumen del desarrollo de la herramienta denominada InverSOODA y algunas de las pruebas aplicadas a ésta. La descripción del desarrollo de la herramienta retoma algunas ideas expuestas en el capitulo anterior, principalmente cuestiones sobre la construcción de diagramas a partir del análisis de código fuente. También presenta de manera breve cómo es la interacción de la interfaz gráfica de la herramienta con el usuario. Además, se presentan dos casos de estudio a manera de pruebas. De estas pruebas se desprende un análisis de los resultados obtenidos para constatar la validez de la hipótesls que sostiene el presente trabajo; análisis que se incluye en el siguiente capítulo.
4.2 Manejo de la interfaz gráfica de usuario
La interfaz gráfica de usuario (GUI por sus siglas en inglés) de InverSOODA es parecida de su antecesor SOODA, excepto por algunos cambios en las barras de herramientas y de modelado: un nuevo botón para la primera, como se muestra en la Figura 4.1:
II Barra de'modelado de SOODA Barra de herramientas de SOODA
I'
Figura 4.1 Cambios en las barras de modelado y de herramientas de SOODA
El Nótese que, de acuerdo a.la figura anterior, aparece un nuevo icono en la barra de herramientas de InverSOODA: el icono en forma de flecha que parece girar apuntando hacia la izquierda. Este es el icono a través del cual se llaman los mecanismos de ingeniería inversa.
I/ Los demás elementos de la GUI tienen la misma apariencia y funcionamiento que en
SOODA, es decir, la interfaz que dirige el proceso de ingeniería directa aparece idéntica para el usuario final. En la Figura 4.2 de la página siguiente se ilustra la interfaz gráfica de usuario de InverSOODA. .
79
11
CAPhULO 4: DESARROLLO Y PRUEBAS DE L A HERRAMIENTA
Figura 4.2 Interfaz gráfica de usuario de InverSOODA. I1
Como se puede apreciar en la figura anterior, las barras de iconos aparecen justo abajo del menú clásico de toda aplicación para Windows de Microsof?, sinqque esto signifique que siempre estarán ahí; ambas son del tipo Jotante y pueden moverse de posición y aparecer en cualquier lugar de la pantalla, a manera de ventanas hijas.
I
4.2.1 Activacih de la ingeniería inversa para recuperar diagramas de clases desde la GUI
Recordando ideas de !a sección 3.4.4.1, se tiene que la construcción de giagramas de clases durante procesos de ingeniería directa se dirige por medio de la barra de modelado en intervalos asíncronos de tiempo, mientras que la ingeniería inversa es un proceso síncrono.
¿En que parte de la GUI de inicia el proceso de ingeniería inversa?. En el II nuevo icono que aparece en la barra de herramientas. N
¿Cuándo es posible disparar los procesos de ingeniería inversa?. En cualquier momento que el usuario lo desee, sólo debe tener cuidabo de guardar !os diagramas con los que estuviera trabajando previo a! llamado de la recuperación de diseños.
,PU,same,
CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA MANEJO DE CUI
Una vez que se pulsó el botón de la barra de herramientas para iniciar un proceso de ingeniería inversa aparecerá un cuadro de diálogo preguntando si se quiere iniciar un nuevo proceso de ingenieria inversa, como se muestra en la Figura 4.3.
Figura 4.3 Cuadro de diálogo que pregunta si se inicia otro proceso de ingeniería inversa.
11 La intención de este diálogo es la de prevenir al usuario final de que está por comenzar
un proceso de ingeniería inversa y es probable perder los datos de diagramas en uso. Si el usuario pulsa el botón del diálogo etiquetado con un Sí, entonces InverSOODA procederá con un proceso de ingeniería cuyo resultado borrará el estado volátil de cualquier diagrama que haya estado activo justo antes. Caso contrario, InverSOODA continúa con el proceso de recuperación de diseños sin destruir el diagrama anterior'.
Seguido al cuadro de diálogo que aparece en la Figura 4.3, la herramienta presenta al usuario otra ventana especial, un cuadro de dialogo especializado para seleccionar archivos, mejor conocido como un File Dialog, como se indica en la Figura 4.4 de la siguiente página.
' En versiones posteriores de la herramicnia se propone mejorar esla interacción con algún mecanismo que permla cancelar l a accibn misma de iniciar procesos de ingenieria invcrsa.
81
CAPITULO 4 DESARROLLO Y PRUEBAS DE LA HERRAMIENTA I1
,I
!
Figura 4.4 Cuadro de diálogo para seleccionar el archivo que contiene e1 código fuente en C++ sobre el cual se aplicará la recuperación de diseño.
Una vez que se selecciona el archivo (uno sólo), entonces comienza el proceso de análisis del código fuente contenido en dicho archivo.
Si el código fuente se apega a las restricciones mencionadas en la Sección 1.6 del primer capítulo de este documento, entonces aparecerá el mensaje ilustrado en la Figura 4.5 de la siguiente página y posteriormente el diagrama de clases del UML que corresponde al diseño del código fuente recién analizado. Como se puede obse&ar en las últimas figuras, la interacción del usuario con la GUI para resolver la recuperación de diseños es bastante simple. La post-interpretación de aspectos semánticos de los diagramas de clases del UML recuperados queda fuera del alcance de InverSOODA. I/
,I
Cuando se obtiene con éxito el diagrama de clases del UML, entonces termina el proceso de ingeniería inversa, y el usuario está facultado para manipular a su libre albedrío el diagrama. Por ejemplo, puede manipularlo gráficamente para acomodar las figuras, acceder a los datos de'las clases y modificarlos, agregar nuevas c'lases y relaciones. En suma, puede iniciar un proceso de ingeniería directa como con cualqdier otro diagrama de la herramienta. ¿Qué hay del diseño detallado de las clases recuperadas?. El proceso de ingeniería inversa para recuperar el diseño detallado de métodos se expliba en la siguiente sección.
'
..
, ,I
CAPiTULO4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA MANEJO DE GUI
Figura 4.5 Cuadro de diálogo: que indica al usuario la recuperación con éxito de un diseño desde código fuente.
4.2.2 Activación de la ingeniería inversa para recuperar el diseño detallado de métodos desde la GUI
Actualmente, InverSOODA trabaja de manera separada respecto a InverDDVi, aunque se propone unir la funcionalidad de estas herramientas a futuro. InverDDVi obtiene el diseño detallado de métodos analizando un archivo a la vez. La limitación es que, para que ambas herramientas recuperen en bolaboración el diseño detallado de métodos pertinente, se necesita tener en archivos separados la implementación de los métodos, archivos almacenados preferentemente con extensión c o cpp. De tal suerte, sólo es posible recuperar el diseño detallado de métodos, de manera apropiada, en los casos que se apeguen a la limitación recién mencionada.
Afortunadamente, InverDDVi no presenta problemas para analizar implementaciones de funciones miembro al estilo C++, tomando en cuenta que InverDDVi fue diseñada para analizar código en lengua$ C. Esto se debe a que el esquema de análisis de código de InverDDVi busca instrucciones secuenciales, repetitivas o de selección adentro de
CAP~TULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
funciones. Lo anterior implica que los procesos de análisis de InverDDVi busquen ávidamente nombres de funciones seguidas de paréntesis. i
Construcciones del tipo:
void Ciertaclase :: funcionl O
/ / lo que sea . . . i I
no afectan al análisis posterior que se realiza adentro del bloque 'hefinido dentro de la función identificada como tal. InverDDVi se ejecutará como una aplicación aparte y desplegará su clásica interfaz con el diagrama de Wamier correspondiente al diseño detallado del método que corresponda al llamado. La Figura 4.6 muestra un ejemplo de diseño detallado obtenido para un método de clase cuyo diseño 'fue recuperado, por supuesto, previamente desde InverSOODA.
"! . . .! - . '. -x :*r, . . dBI . , ; . n r r m F p . . . . . . . . -., s w u l Ed>* yer 'enana "8 A >IS181 &lQlCAl 51 PlY?lOl <I1
~ 1 @ 1 @ 1 @ ( 1 gI e I ,I * 1 2 s d l ~ ~ @ & ~ ' & ~ ~ li 1 =O-
4" =*-
,# Figura 4.6 Ejemplo de un diagrama de Wamier que corresponde al diseñc$detallado de un método de clase.
De acuerdo con la figura anterior, se observan los siguientes elementos dentro del diagrama de Wamier obtenido por InverDDVi: el segundo triángulo 1 representa una llamada a procedimiento de nombre fl, acotando otros elementos con la primera llave; enseguida, se encuentra un ciclo controlado por la variable i; después, se representa un
84
CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA MANEJO DE GUI
estatuto condicional que a su vez se encuentra dentro del acotamiento de la llave del ciclo, la condición evalúa la expresión f < 100; y, finalmente, una condición negada. El código correspondiente al diagrama desplegado en la figura anterior se encuentra almacenado en un archivo de nombre A.cpp y es el siguiente:
#include "a. h"
int A :: El O
int i; while ( i )
( I1
i if ( i < io0 )
else break; printf ( "Actual valor %d", i ) ;
1 I
Si se observa el trozo de código anterior, se puede notar que la función no es de tipo global (al estilo C), sino más bien una implementación de un método llamadofl, que es miembro de la clase denominada A . Queda en el aire la pregunta obligada para esta sección: ¿Cómo accionar desde InverSOODA la recuperación del diseño detallado de un método de una clase en particular?. La Figura 4.7 ilustra gráficamente esta cuestión seguida de una breve explicación en la página siguiente.
J
I' Figura 4.7 Instantánea de la'interfaz utilizada cuando se acciona la recuperación del diseño
detallado de un método en particular.
85
I1
8) CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
Una vez que se recuperó un diagrama de clases es factible la fecuperación del diseño detallado de métodos de clases siempre y cuando alguna de las clases del diagrama recién recuperado contenga métodos. Se selecciona el primer icono de la barra de modelado (ver figura 4.l), la cual corresponde a la figura apuntador. Enseguida selselecciona la clase que contiene el método de interés pulsando el botón derecho del ratón.'hEntonces aparecerá un cuadro de diálogo con varias pestañas. Se selecciona enseguida la pestaña etiquetada como métodos. En, la pestaña denominada métodos aparece una región que despliega un listado con los nombres de los métodos miembro.de la clase seleccionada! Se pulsa de nuevo el botón derecho del ratón posicionando antes el cursor sobre el método de interés. Acto seguido aparece un pequeño menú con las siguientes opciones:
9 Insertar 1 Borrar . Modificar 1 Diseño
Es de especial interés la opción del menú anterior llamada Diseño; puesto que al pulsar el botón derecho del ratón se activa la llamada a InverDDVi. Entoncds el usuario estará en posibilidad de usar el InverDDVi para recuperar el diseño detallado del método que seleccionó desde InverSOODA. I1
,I ,.
,I
4.3 Implementación de los analizadores de código fuente
Para entender más a fondo la descripción de la implementación deilos analizadores se recomienda que el lector haya repasado las secciones 3.4.4, 3.5.1, 3.5.28~ 3.5.3 en donde se desarrollan los siguientes temas:
II
o 3.4.4 Uso del patrón de diseño Builder como base para construir el diagrama de clases
o 3.5.1 Creación de analizadores de código con ANTLR I1
o 3.5.2 Analizador léxico I
o 3.5.3 Analizador sintáctico y semántico
4.3.1 Implementación del analizador léxico
El analizador léxico se apega a la definición de muestras listadas en la Tabla 3.1 y conceptualmente a los autómatas ilustrados en las figuras numeradas del 3.11 al 3.21. Además, se implementa en un archivo de especificación gramatical de acuerdo a las reglas mencionadas en la Sección 3.5.1. Los detalles de implementación que no, se trataron en ese capítulo se enuncian en los siguientes párrafos.
En el archivo de especificación gramatical del analizador léxico se especificaron varias opciones especiales que indican al ANTLR como generar dicho analizador. Entre estas opciones se tiene:
86
I M ~ L E M E N T A C I ~ N DE ANALIZADORES CAPITULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
o La sección options general:,'
options mangleLiteralPrefix = "TK-" ; language= "Cpp" ;
1 10
LO anterior indica al ANTLR que concatene el prefijo TK- a cada muestra, Y que el Lenguaje en el que se genere e\ analizador léxico sea C++.
o La definición de la clase ,TinyCLexer y sus inmediatas opciones:
class TinyCLexer extends Lexer; options
k=2; exportVocab=TinyC; charvocabularx = '\3'..'\377';
1 4
TinyCLexer es el nombre de la clase generada por ANTLR a partir de la clase Lexer. Es la clase que define en su implementación el analizador léxico2. La linea k=2 significa que se utiliza un;lookahead de dos caracteres. export Vocab=TinyC significa que el analizador léxico exporta un vocabulario o conjunto de tokens denominado TilryC hacia cualquier analizador sintáctico generado también con ANTLR. Finalmente, charVocabulary= 'I3 '.. '1377' define el rango de caracteres que TinyCLexer puede identificar, para este caso,,'se definió el rango de los caracteres ASCII.
o La sección tokens: ,
tokens I "int"; "char"; "bool"; '"float't; lldoublev; "voidt!; t!longu; nwsignedrr "unsigned"; ushoS-t!. !)if!#. , "else"; "while"; "class"; "struct"; "union"; "private!; "protected"; "public"; "inline"; "virtual"; 1
El ANTLR permite, definir en una sección especial denominada tokens aquellas muestras que explícitamente se definen sin utilizar derivaciones.
o Regias protegidas y no protegidas:
a) Protegidas. Reglas que no interesan al analizador sintáctico. I
protected DIGIT : * ' 0 ' . . ' 9 '
' El lipa de analizadores que genera el ANTLR son LL ( k ).
87
CAPfTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAM~ENTA
b) No protegidas. Reglas que se entregan al analizador sintáctico una vez reconocidas.
ID : ('~'..'Z'~'A'..'Z'~'-~) ( ' a ' , . ~ z ~ ~ ' ~ ~ . . ~ z ~ ~ ~ - ' ~ ' o ' . , ~ g ~ ) * ;
Nótese que la regla ID se define en un forma parecida a las expresiones regulares; ésta es una opción alternativa que provee ANTLR para definir derivaciones. Cabe mencionar que toda especificación de muestras debe iniciar con uda letra mayúscula.
ii
I1 4.3.2 Implementación del analizador sintáctico
La Tabla 3.2 del capítulo anterior define las reglas gramaticales que se especificaron en un archivo para ANTLR de acuerdo a las reglas mencionadas en la Seccion 3.5.1. A partir de dicha especificación se generó el analizador sintáctico. Los detalles de la implementación dentro del archivo de especificación gramatical se enlistan a continuación:
'I
O
O
O
La sección header, que sirve para agregar código fuente de preprocesador y variables o funciones globales ,
(
I/
header
.I #include <iostream.h> #include "StdAfx. h" #include "Clase. h" #include "1nverSoodaDiagrarnaBuilder.h" ,I
1
Concretamente en el código anterior se añadieron los archivos i0stream.h para manejo de salida estándar, 3dAfx.h para manejo de objetos básicos MFC, C1ase.h que contiene la definición para objetos con la figura clase. Finalmente, InverSoodaDiagramaBuilder.h, que es la definición del objeto /I que dirige la construcción síncrona de un diagrama de clases.
La sección options general:
options rnangleLiteralPrefix = "TK-" ; language="Cpp" ;
)
Lo anterior indica al ANTLR que concatene el prefijo TK- a +da muestra, y que el lenguaje en el que se genere el analizador léxico sea Ctt-.
La definición de la clase TinyCPPParser y sus inmediatas opciones:
88
. ... . . I .,*“~.t?p> :.. .I(
CAPÍTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA IMPLEMENTACIÓN DE ANALIZADORES
class T i n y C P P P a r s e r extends Parser ;
opt ions
importVocab=TinyC; I I I)
El analizador sintactico está definido dentro de una clase llamada TinyCPPParser. A su ,hez, dicha clase hereda funcionalidad de un clase más genérica llamada Purse;. La oración itnportVocub=TinyC indica al ANTLR que el analizador sintáctico utiiliza un conjunto de muestras definidos en el vocabulario TinyC. Dicho vocabulario se define previamente en el analizador léxico TinyCLexer (ver Sección 4.3.1). ‘1
o Sección de código:
/ / Seccion de codigo
pub l i c :
p r iva te :
I CInverSoodaDiagramaBuilder* g e t B u i l d e r O ( r e t u r n b u i l d e r ; )
CInverSoodaDiagramaBuilder *bui lder ; 1
Justo después de la sección options de la definiciGn de TinyCPPParser se agrega una sección especial delimitada solamente por un par de llaves que abren y cierran. Es la sección que indica al ANTLR que el código ahí encerrado es particular a la implementación del analizador. Específicamente, en la porción de código anterior se declara como privado dh apuntador a objetos Builder (ver Sección 3.4.4), que son los encargados de construir los diagramas de clases. También se define un método miembro de la clase TinyCPPParser que sirve para recuperar el objeto Builder.
o El resto de las secciones del archivo de especificación gramatical se apega al ejemplo mostrado en:[ el capítulo anterior en la Figura 3.10. Contiene la especificación de tod& las producciones gramaticales que permiten realizar la ingeniería inversa, de acuerdo al esquema de traducción conceptual mostrado en la Tabla 3.2. Por ejemploJla regla 11.2 se implementa así:
idhiocualificado : i d : I D
il
builder->setCurrentNombre(id->getTextO.c-strO); I ) ;
En donde, idNoCtialificudo es el símbolo no terminal a la derecha de la producción; id es una &ueia específica de ANTLR, que hace las veces de variable temporal para contener el texto de la muestra; ID es el token en que deriva el símbolo terminal a la $emha y cuyo lexemu se almacena en la etiqueta anterior; encerrada entre llaves está la acción semántica implementada por el .método setCurreniNombre, propio del objeto builder agregado previamente en la clase TinyCPPParser en la sección de código; setCurrentNombre se parametriza con el lexema de ID. ‘t
89
CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
4.3.3 Imp lemen tac ión del anal izador semántico 1
L a irnplementación del analizador semántico se basas en las acciones sernánticas descritas de manera abstracta en l a Tabla 3.2 del capítulo 3. El objeto builder agregado en el objeto analizador sintáctico TinyCPPParser es el encargado de concretar dichas acciones semánticas. L a Figura 4.8 expone los métodos y atributos del objeto builder al que corresponden las acciones semánticas para recuperar diagramas de clases UML.
1
ClnverSoodaDiagramaBuilder
- mPrototipoClase : CClase' - mCurrrentAcceso : CString - mCurrrentTipo : CString - mCurrrentNombre : CString - mCurrentValor : CString - rnCurrentParam : CString - mCurrentNumAtributos : int - mAtribAcceso : CStringArray - mAtribTipo : CStringArray - mAtribNombre : CStringArray - mAtribValor : CStringArray - mCyrrentNumMetodos : int - mMetodAcceso : CStringArray - mMetodTipo : CStringArray - mMetodNombre : CStringArray - mMetodParam : CStringArray - mMetodValor : CStringArray - mAgregaciones : CStringArray - mHerencias : CStringArray
+ getDiagrama ( ) : CGrafico' + crearLinea ( ) : CGrafico' + crearRectangulo ( ) : CGrafico' + setHerencias ( ) : void + checkHerencia ( ) : void + setAgregaciones ( ) : void + checkAgregacion ( ) : void + getClase ( ) : CClase' + crearclase ( ) : CClase* + setMetodosClase ( ) : void + SetAtributosClase ( ) : void + resetMiembrosClase ( ) : void
+ setCurrentAcceso ( ) : void + cetCurrentNombre ( ) : void + setcurrentvalor ( ) : void + setcurrentparam ( ) : void - ,resetMetodosClase ( ) : void - resetAtributosClase ( ) : void
I1
1
I1
+ setCurrentTipo ( ) : void I
i!
II Figura 4.8 Métodos y atributos de la clase InverSoodaDiagramaBuilder usados en los
mecanismos de ingeniería inversa.
90
... , , ,*r- ':'.T. ?'R. , .., <
CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA IMPLEMENTACIÓN DE ANALIZADORES
Papel de atributos y métodos en el análisis semántico IJi Atributo mPrototipoClase
mCurrrentAcceso
mCurrrentT/po
mCurrrentNo'mbre
I . . _ . - mcurrentvaior
mcurrent Param
mCurrentNumAtributos
mAtri bAcceso
rnAtribTipo
Papel en e/ análisis semántico Es un objeto dentro del cual se almacenan t&nporalmente los valores resultantes del análisis. Cuando se concreta la identificación de una entidad grafica clase entonces se toman 10s valores almacenados en este objeto para guardarlos en vectores de objetos CString. Almacenamiento temporal para tipos de acceso,, por d:efecto private. Cuando se concreta la identificación de una clase se almacena en mAtribAcceso o en mMetodAcceso.
métodos u objetos. Cuando se concreta la identificación de una clase se almacena en
1 ~ 4lmacenarniento temporal para tipos de variables, ~. I '
i
I
~
mAtribTipo o mMetodTipo. También es usado para !
I ibentificar ,, . - relaciones . . . . . . . . . . . . . . . . . . . . . . . de agregación y herencia. Almacenamiento temporal para nombre de varia-bies, ~ - ; objetos o métodos. Cuando se concreta la ilentificación de una clase se almacena en mAtribNombre o mMetodNombre. I)lmacenamiento temporal para e¡ 'valor de variables u objetos. Cuando se concreta la identificación de una dase se almacena en mAtribValor o mMetodValor. Para métodos aplica como el especificador virtual huro. Almacenamiento temporal para 10s paiámetrosde métodos. Cuando se concreta la identificación de una clase se almacena en mMetodParam. Almacenamiento temporal que lleva cuenta del número de atributos que se han identificado para una entidad clase. Almacenamiento temporal en forma de vector que almacena objetos tipo CString. Contiene la totalidad de los accesos que califican a los atributos kecuperados para una entidad clase. Almacenamiento temporal en forma de vector que almacena objetos tipo CString. Contiene la totalidad de los tipos de los atributos recuperados para una entidad clase.
~ .... . . . . . . .
i !
. . . . . . . . . . . . .
- . ~i il . . . , ... -. . .
............... . . . . . . . . . . . . . l.
1
Tabla 4.1 Papel de los atributos y métodos del objeto builder en el análisis semántico.
I1 CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
.
1 -. -- Papel de atributos y métodos en el análisis'semántico---
I (continuación ...)
almacena objetos tipo CString. Contiene la totalidad de los tipos de los métodos recuperados para una entidad clase. t
.. - .................. - - - ~ -! i 1 A tributo j Papel en el análisis semántico
mMetodParam
mAtribNom bre
de los nombres de los métodos recuderados para una entidad clase. Almacenamiento temporal en forma de vector que
mAtribValor
. . . . mCurrentNumMetodos
mMetodAcceso
Almacenamiento temporal en forma de vector que almacena objetos tipo CString. Contiene la totalidad de los nombres de los atributos recuberados para una entidad clase. Almacenamiento temporal en forma de vector que almacena objetos tipo CString. Contiene la totalidad de los valores de los atributos recuperados para una entidad clase. Almacenamiento temporal que lleva cuenta del número de métodos que se han identificado para una entidad clase. Almacenamiento temporal en forma de vector que almacena objetos tipo CString. Contiene la totalidad de los accesos que califican a los métodos
......... .- .. . . . . . . . . . ... .....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
! recuoerados oara una entidad clase. 1 . . . . . ............ - - , ,~ .I .................... .- ...... ... ___ ........... mMetodTipo iAiimacenamiento temporal en forma de vector que
mAgregaciones j Almacenamiento temporal en forma de vector que ~ almacena objetos tipo CString. Contiene la totalidad ~ de las agregaciones encontradas durante el análisis ~ semántico. I)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....... -. . .............................................
Tabla 4.1 Papel de los atributos y métodos del objeto builder en el análisis semántico. (continuación ...) /I
92
11: v"*r)+-.*." 'si.cl
CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA IMPLEMENTACldN DE ANALIZAOORES 4
Papel de atributosiiy métodos en el análisis sernántico (con tin uació n.. .)
Atributo mHerencias
Método getDiagrama ( ) crearLinea ( )
-. . ___ crearRectangulo ( )
- .. . . . .. . . - . . . - setHerencias ( )
checkHeren2a ( )
seagregaciones ( )
checkAgregacion ( )
. ..
Papel en el análisis sernántico Almacenamiento temporal en forma de vector que almacena objetos tipo CString. Contiene la totalidad de las herencias encontradas durante el análisis smántico.
Papel en el análisis sernántico r Retorna el objeto diagrama que se construye j r e a una figura del tipo Ciinea. Usado en la creación de entidades gráficas del tipo agregación o herencia. Resuelve las restricciones de despliegue de la figura dreada respecto a las clases que asocia y la agrega en el objeto diagrama Crea una figura del tipo CRectangulo. Este método se y
tasa en los valores del objeto temporal clase para la creación de la figura rectangular. Resuelve las pstricciones de despliegue de la figura creada y la agrega en el objeto diagrama. Se encarga de asociar las herencias encontradas Clurante el análisis semántico con las respectivas clases. Recorre el atributo mHerencias para tal efecto. 1 Ratifica en determinado momento del análisis semántico si el tipo y nombre temporales generará una asociación del tipo herencia. Si esto es afirmativo, agrega una agregación a manera de objeto Cstring dentro del vector mHerencias. Se encarga de asociar las agregaciones encontradas
clases. Recorre el atributo mAgregaciones para tal !efecto.
~ Ratifjca'en determinado momento del análisis semántica si el tipo y nombre temporales generará una asociación del tipo agregación. Si esto es
1,afirmativo. agrega una agregación a manera de obieto
. ~ . ~ _.
.~ . .. ... . ~ ~ .~ ~.~~ .
r ~ ~ ~~~ ~ -~.~. . ~ . .
I1
. - . ~~ . . - - ~ .~ ~
i'lburante el análisis semántico con las respectivas I '
I' [Cstrin !. dentro ~~ del vector-migregaciones. ~ ~
Tabla 4.1 Papel de los atributos y métodos del objeto builder en el análisis semántico .( continuación ...)
I! CAF'hlJLO 4: DESARROLLO Y PRUEBAS DE LA HERRAMENTA
getClase ( ) crearclase ( )
Retorna el objeto temporal de tipo CClase Instancia el objeto temporal de tipo CClase con estado inicial vacío. I/
resetMiembrosClase ( ) setCurrentTipo ( ) setCurrentAcceso ( ) setCurrentNombre ( ) setcurrentvalor ( ) setcurrentparam í
1 Llama a resetMetodosClase y a resehtributosClase. .I Asigna un nuevo valor a la variable mCurrentTipo. i l Asigna un nuevo valor a la variable mCurrentAcceso. /Asigna un nuevo valor a la variable-mCurrentNombre. 'r isigna un nuevo valor a la variable m,CurrentValor.
siana un nuevo valor a la variable mCurrentParam.
__ --
.-I-_..-.._-..- ______I-
. . __I_.~._I.__ ..
resetMetodosClase ( ) Limpia los valores temporales de los vectores que ' guardan información de los métodos de entidades 1 clase. 1 Limpia los valores temporales de los vectores que guardan información de los métodos de entidades
: .I.. clase.
__ recetAtributocClace ( )
. . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ . -.___-___ ~~
¡I
Tabla 4.1 Papel de los atributos y métodos del objeto builder en el análisis semántico. (continuación. ..) !t
La tabla anterior corresponde a la descripción funcional de cada uno de los atributos y métodos mostrados previamente en la Figura 4.8, es decir, muestrailel papel de estas entidades en la irnplementación de los mecanismos de ingeniería inversa del objeto builder denominado InverSoodaDiagramaBuilder.
,I
94
,~ ??,‘rutt”.‘* g . >*.
CAPÍTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA PRUEBAS
4.4 Pruebas
En esta sección se presentan dos casos de estudio a manera de pruebas. La intención primordial de estos casos de es&dio es constatar la validez de la hipótesis enunciada en el primer capítulo de este documento la cual sustenta que: ‘‘...es posible generar el diagrama de clases basado en el estándhr UML y los diagramas de Warnier para representar el diseño detallado de métodos de clases, apariir de código fuente existente en C++. ”.
I)
Es esencial mencionar que las pruebas realizadas son limitadas en ciertos aspectos puesto que no se realizaron bajo una evaluación exhaustiva ni bajo un estándar de pruebas de software. Por ejemplo, no se realiza un estudio de precondiciones ni poscondiciones que permitan validar la totalidad ?e los valores iniciales del código sujeto a prueba ni los valores de salida esperados.
No obstante, los valores objetivos que se manejan en estos casos de.estudio son la correspondencia directa de las clases en el código fuente con las figuras tipo clase obtenidas en el diagrama de Clases; la validez en la cardinalidad de relaciones de tipo agregación y herencia; y, la validez en la cardinalidad, tipo, ámbito y nombre de los atributos y métodos de cada clase recuperada. Con las observaciones antes mencionadas se. presenta en las siguientes secciones los dos casos de estudio.
11’
4.4.1 Caso de estudio 1 ,, El primer caso de estudio consiste en aplicar la ingeniería directa para modelar un conjunto de cinco clases, generar su iódigo y posteriormente obtener con ingeniería inversa el modelo correspondiente a partir del código generado.
El conjunto de clases modelado corresponde a una porción de un prototipo de un framework estadístico, que fue desarrollado a manera de proyecto final para la materia de Ingeniería de Software Orientada a Objetos en el CENIDET’.
El propósito general del framework es realizar cálculos de medidas de tendencia central, medidas de dispersión, ajuste de curvas, cálculo de distribuciones y ordenación de listas doblemente ligadas. Especídamente, la intención del conjunto de cinco clases elegidas para este caso de estudio es calcular la media aritmética, que es una medida de tendencia central; y la desviación estándar, que es una medida de dispersión.
Enseguida se presenta la descripción de las cinco clases modeladas en cuanto a atributos y métodos:
Clase Strategy
. Atributos: 11
Ninguno
’ Esta prueba se realizó en colaborkión con el 1.S.C Manuel Alejandro Valdés Marrero, a quien quiero expresar un sincero agradecimiento por su ayuda en este caso de estudio.
CAPfTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
Métodos: public: void Calcula (Contexto *ctW ) = O public: double GetResult ( ) = O
Clase Contexto I . Atributos: I1 private: double valor
public: double Arreglo [ 10 ] public: Strategy str
.I
/I
li
. Métodos: I public: void lnteractua ( )
public: void SetValor ( double dato ) public: double GetValor ( )
1
Clases Suma, Media y Desviación ( heredan de Strategy ) 11 - Atributos:
. Métodos: private: double Resultado
public: void Calcula ( Contexto 'ctx ) public: double GetResult ( )
La Figura 4.9 muestra el diagrama de clases producto de lalingeniería directa utilizandoÍnverSOODA:
r- -----
Figura 4.9 Diagrama de clases generado de manera asincrona por medio de la barra de
J mi*
I1
modelado de InverSOODA. 1
96
CAPITULO 4: DESARROLLO Y PRUE6AS DE LA HERRAMIENTA PRUEBAS
11
A su vez, el diseño detallado de cada uno de los métodos de las clases de la figura anterior se creó con InverDDVi. Las siguientes figuras Y oárrafos describen más a detalle el
int ¡=O; i<l O; i++
---
b
str=new Suman II 1 PSC
str->Calcula[this] PSC
SetValor[str->GetResultOJ I1
py."La Sumatoria es: "<<GetValor0 .' -.. I
str=new Median PSC
str->Calcula[this] PSC
ii SetValor[ctr->GetResult~]
Pfl"La Media Aritmética e!: "<<GetValorO \' , str-new Desviaciono Jj
PSC
str->Calcula[this] PSC
SetValor[str->GetResupO) )I PSC
la Desviación Estándar es: "<<GetValor[ .' Figura 4.10 Diagrama generado para la función
Contexto :: Interachia 0.
41 ..
11
.. diseño e intención de los métodos de cada clase.
La Figura 4.10 de la presente página muestra en específico el diseño detallado del método Interactua de la clase Contexto.
El propósito de este método es utilizar en primera instancia, un ciclo para tomar valores desde la entrada estándar y almacenarlos en un arreglo. A partir de estos valores almacenados se calculan secuencial- mente las siguientes medidas:
1) Sumatona 2) Media aritmética 3) Desviación estándar
El proceso de cálculo para cada una de estas medidas estadísticas implica hacer la llamada a los métodos de un objeto Strategv en el siguiente orden:
1) Calcula 2 ) GetResult
El valor de regreso de la función GetResult se parametriza en la función SetVaior del objeto Cuntextu.
Finalmente, se llama al método GetValor del mismo objeto Contexto, para imprimir el resultado del cálculo en salida estándar. Aunque también se generó el diseño detallado de los métodos SetValor y GetValor de la clase Contexto no se muestran en alguna ilustración debido a la simpleza de los mismos: sólo ejecutan una instrucción.
97 1
CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA I1
La Figura 4.1 1 muestra el diseño detallado creado para el método Calcula de la clase concreta Suma. El propósito de este método es realizar la sumatoria de todos los elementos almacenados en el arreglo del objeto Contexto. El resultado se almacena en la variable Resultado, que es un atributo de las clases tipo Strategy.
1 . s v m
11 double Surnatoria-O PSC
11
Surnatoria~=~->Arreglo[ i ]
ResultadoSumatoria
Para los métodos GetResult de cada una de las clases concretas de tipo Strategy también se realizó el diseño detallado, pero debido a la
operación que regresa el valor contenido en la variable Resultado) no se incluyen las figuras correspondientes. método Suma::Calcula.
simpleza del método (realiza sólo una
Figura 4.1 1 Diseño ,;detallado del
int N=l O PSC
double Surnatoria, rnedia=O PSC
Surnatoria=cb->GetValor0 PSC
rnedia=Sumatoria/N PSC
Recultado=media PSC
Figura 4.12 Diseño detallado del método Media::Calcula.
1 En el caso de objetos tipo Media, el método
Calcula tiene la intención de calcular la media aritmética de los datos almacenados en el arreglo del objeto Contexto, pero utilizando la sumatoria de dichos datos previamente calculada por un objeto tipo Suma (recordar las instrucciones del método Interactua de la Figura 4.10), r h l t a d o que a su vez se almacena en la variable Valor del objeto Contexto (ver Figura 4.12). II '
La media aritmética calculada se almacena en la variable Resultado, que es un atributo de las clases tipo Strategy (hablando en términos solamente del método Media::CalculaO ).
I
:I En la página siguiente, la Figura 4.13 muestra el diseño detallado del método Calcula de objetos tipo Desviación. El proceso de cálculo de la desviación estándar se apoya en los cálculos previos por objetos Media (recordar las instrucciones del método Interacpa de la Figura 4.10). Se utiliza la media almacenada en el obieto
I/
Contexto para calcular la diferencia de cuadrados con respecto a cada uno .de los elementos del arreglo.
De lo anterior, se calcula la sumatoria de las diferencias al cuadrado para dividirla entre el número de datos. Finalmente, se obtiene la desviación estándar calculando la raiz cuadrada de la operación anterior. I1
98
, .- , ~ ".: e,.* ' ,t " !I
CAPfTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA PRUEBAS
inl N=10 PSC
double Sumaioria=O, desv. media, aux PSI:
medio=cb<->GelValorO PSC
aux=m->Arreglo[i] - media PSC
" Sumatoria+=aux*aux PSC
dcsv=Sumaloria/[N-11 PSC I/
desv=sqrl[decv] PSC
Resultado=desv PSC
!! Figura 4.13 Diseño detallado del método Desviacion::Calcula.
El código generado por InverSOODA correspondiente al diagrama de clases diagramas de las Figuras 4.94 es el sipiede: / ' - ---- . . --------------------------------------------- .-~-----------------------------------
caso1.h * /
/ * Declaración de la clase. Cbdigo generado por InverSOODA * / //#if idefined(Contexto~compilada1 //#define Contexto-Compilada /* Descripción : * / class strategy; class Contexto (
/ / Atributos public:
double ~rregioiiol i strategy *st=;
private: double Valor;
protected:
I CAF'hLO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
/ / Métodos public:
Contexto0 ; -Contexto ( 1 ; void InteractuaO ; void CetValor(doub1e dato); double GetvalorO;
private : protected:
1; //#endif
/ * Declaración de la clase. Código generado por InverSOODA * / //#if idefined(Strategy_Compilada) //#define Strategy-Compilada
Descripción :
11 / *
* / I/
class strategy (
/ / Atributos public: private: protected:
/ / Métodos public:
strategy ( ) ; -Strategy ( ) ;
virtual void Calcula(Contexto* ctX)=O; virtual double GetRecultO=O;
private : protected:
1; //#endif
/* Declaración de la clase. Código generado por InverSOODA * / //#if idefined(SumaCompi1ada) //#define Suma-Compilada /* Descripción : * / class Suma : public Strategy (
/ / Atributos public: private:
protected:
// Métodos public :
double Resultado;
Suma I ) ; -suma 1) ; void Calcula(Contexto* ctx); double GetResultO ;
private : protected:
/ * Declaración de la clase. C6digo generado por InverSOODA */ //#if Idefíned(Media-Compilada) //#define Media-Compilada
Descripción : /*
* /
100
I/
'!
CAPiTULO 4: DESARROLLO Y PRUEBAS b E L A HERRAMIENTA PRUEBAS
class Media : public Strategy (
/ / Atributos public: private:
protected:
/ / Métodos public:
double Resultado;
Media I ) ; -Media ( ) ; void CalculaIContexto' ctx); double GetReSult O i
private : protected:
1. Declaración de l a clase. Código generado por InverSoODA * / //#if Idefined(Desviacion-Compilada) //#define Desviacion-Compilada
Descripción :
class Decviacion : public Strategy (
/ / Atributos public: private :
ptotected:
/ / Métodos public :
/ *
* /
double Resultado;
DesviacionO ; -üesviacionO ; void CalculalContexto+ ctx); double GetReaultO ; ;
private: protected:
1; //#endif
A su vez el código generado por InverDDVi correspondiente a los diagramas de la Figura 4.1 O a la Figura 4.1 35 ed el siguiente: / * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . - -~- . . - - - - - - - - - - - - - - - - - - . - - - . - - - - . - - - - - - - .~- - - -~- - - - - - . f caeo1.cpp */ #include "caso1.h" #include "math.h* #include "ioetream.h"
/ * Métodos de la clase. Código generada por InversOODA * / //#include I' S trategy . h" \ I Metodos de la clase Strategy
Strategy::StrategyO I
//Código I
' El c6digo fucnic en negritas fue sgrcgado o dercameniado de manera manual para qnc &te pudiera cornpilame y cjecularse. Posteriomcnic, las implementaciones .fueron 'agrupadas cn un solo archivo ( caso1 s p p )julo con CI código clienlc para quc pudiera realizarse la ingcnicna iwcma.
CAP¡TULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
11
Strategy: :-Strategy0
//C6digo (
1 /I
/ * Métodos de la clase. Código generado por InverSOODA * / // #include "Contexto.h'' / / Metodos de la clase Contexto Contexto::ContextoO
h ValorFO ; ArreglollOl =ArregloliOI ;
//Código ) I/
Contexto::-Contexto0 í 1 //Código
void Contexto::InteractuaO I
/ / Código for (int i=o; icio: i++)
cout c< ',Valor "cci<c": 'I;
cin >> Arreglo[il ; 1
I
str=new S u m a O ; str->Calcula(this) ; SetValor(str-sGetRecult01; =out << "La Sumatoria es: "<<GetValorO; Str=new Media0 ; str->Calcula(this) ; setvalor(str-~GetResultO): =out << "La Media Aritmética es: 'ccGetValor0; str=new DeeviacionO; str->Calcula (this1 ; CetValor(str-)GetResultO); =out << "La Desviación Estándar es: "CsGetValorO;
I/
!! 1 void Contexto::SetValor(double dato)
//Cbdigo Valorxdato;
1 double Contexto::GetValorO
//Cbdigo return Valor:
(
1 / * Métodos de la clase. C6digo generado por InverSOODA * / // #include -5uma.h" / / Metodos de la clase Suma
Suma ; :Suma ( 1
ReCultado=O :
1
//Código 1
(
//Código
Suma : ! -Suma ( )
void Suma::Calcula(Contexto* ctxl
102
CAPiTULO 4: DESARROLLO Y PRUEBAS DE L A HERRAMIENTA PRUEBAS
'11
//Código double Sumatoria=O; for (int i=ü; i<lo; it+) (
Sumatoriat-ctx->Arregloíil: /I 1
ReSultado=SUmatOria; 1
(
I
double Suma::GetResultO
//Código return Resultado;
// Media.cpp
/ * Métodos de la clase. Código generado por InverSOODA * / / / #include "Media.h* I / Metodos de la clase Media
Media: :Media0
Resultado=O ;
//Código I I Media::-Media0 l ;/Código I void Media::Calcula(Contexto* ctxl
IICódiaa . . - int N=10; double Sumatoria. media=O; Sumatoria=ctx->GetValorO; media=Sumatoria/N; Resultado=media;
I
,(
)
// Des"i*Eion.Cpp
11 double Media::GetResultO
//Código return Resultado;
8,
I* Metodos de la clase. C6digo generado por SOODA * I // #include 'desviacion.h" / I Metodoc de la clase Desviacitin
Desviacion::OecviacionO 1.
Resultado=O : (
I
(
I
(
//CSdigo
Desviacion::-Desviacion() !I //Cbdigo
void Desviacion: :Calcula(Contexto* C t x )
//Cbdigo int N=iO; double Cumatoria=O. desv. media. aux; media=ctx-,GetValoT(I i for (int i.0; i<iü; i++) (
103
I)
CAPITULO 4: DESARROLLO Y PRUEBAS DE L A HERRAMIENTA
il
aux-ctx->Arregioiil - media; Sumatoria+=aux*aux;
1 desv.suma toria/ (N- 11 ; dew-sqrt idecvl ; Resultado-desv:
)
contexto ctx; c t x . 1nteractuao ; ret"rn o;
!!
I Una vez compilado el código mostrado con anterioridad se puede correr la imagen
ejecutable creada. La Figura 4.14 muestra la pantalla de salida de dicha corrida con datos arbitrarios. I1
Figura I/
4.14 Pantalla de salida en la ejecución del código generado con los mecanismos de I/ ingeniería directa de InverSOODA. I1
El proceso de ingeniería inversa con InverSOODA e InverDDVi se aplicó sobre el código generado con el proceso de ingeniería directa aplicado previamente en este caso de estudio. El resultado de este proceso de ingenieria inversa fue satisfactorio en cuanto a recuperación de los diagramas de clases y el diseño detallado de los métodos de estas clases, bajo las restricciones siguientes:
1 - Se comentó el código que fue insertado manualmente'.
Remitirse al código ejemplo mostrado con anterioridad. Éste tiene señalada cn negritas el código que se comentó para que funcionaran los mecanismos de ingenieria inversa.
104
CAPiTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA PRUEBAS !I.
- AI arreglo declarado en la clase Contexto también se le comentaron los corchetes para quedar como variable simple. Se creó un Ünico archivo en el que integró la totalidad del código disperso en a’kchivos individuales, esto es, para los archivos de cabecera con las definiciones de clases. Los diagramas recuperados concuerdan con los creados originalmente en la ingeniería directa, aunque se tuvieron que reacomodar espacialmente para una mejor visualización.
-
-
4.4.2 Caso de estudio 2
En el segundo caso de estudio se aplicó ingeniería inversa a dos conjuntos diferentes de clases relacionadas. Los conjuntos se denominaron arbitrariamente BDSys y EDMenu. Los conjuntos constan es su totalidad de catorce clases. El código fuente legado en C++ que contiene las catorce clases, es el resultado de un proceso de reingeniería descrito en los trabajos Brevemente se citan enseguida algunas de las intenciones y características del código fuente tomado para este segundo caso de estudio, extraídas de panoil:
BDSys:
“BDSystem es un programa .;escrito en lenguaje ‘ C , hecho para el sistema de control de procesos distribuidos para los módulos del sistema SAC del departamento de instrumentación y control del Instituto de Investigaciones EIBctricas. La función del sistema es la de manejar dos tablas de datos, una de las señales analógicas y la otra de señales digitales para un sistema de control de procesos distribuidos.”
BDMenu: It
“BDMenu es un programa escrito en lenguaje ‘C’ que funciona como cliente de las operaciones que realiza BDSystem. La función’[de este sistema es proporcionar al usuario un menu de opciones para las operaciones que puede realizar el BDSystem”
El lector notará que se habla del lenguaje ‘C’ en las descripciones anteriores; afortunadamente, el código fuente tomado para esta prueba no es precisamente el programa en lenguaje C, sino el código! fuente producto del proceso de reingeniería descrito por pnnozl; dicha reestructuración permitió contar con un conjunto de clases que tienen la misma funcionalidad que el código original en C.
:I
Enseguida, se lista el código utilizado en esta pmeba’, seguido de una figura que corresponde a su diseño recuperado:
Código fuente’ de las definiciones de clases de BDSys y de BDMenu: :I
’ Aparecen en negritas las porciones de código que se alteraron para poder aplicarles eficazmente la ingeniería inversa. Esto significa que algunas lineas están comentadas, o bien tiene partes modificadas, incluso el código mostrado adolece de algunas líneas de preprocesamiento originales y presenta nuevos comentarios.
No es posible generar una imagen ejecutable a partir de este código fuente debido a todas las modificaciones anteriores
1 CAPiNLO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
/. ll! ............................................................................. using namespace BDMenu;
* class aStratl
class aStratl .............................................................................. */
:I
( protected:
unsigned VAR; unsigned VALOR;
virtual void AlgOritmODeInterfazO = O; public:
unsigned int getnum0 int pidevar ( 1 int pideval O int pidegrupo 0
) ;
/' ......................................... * using,name?pace BDMenu; f class Contexl
class Contexl
private :
public:
...........................................
(
astratl Strategy; // *strategy;
/* contexio
>; */
Strategy - NULL;
..
..
'11
I/
I1 * / .................................
void SetTipoO;// char)> void InteractuaO;
1; /. ....................................................................... 1- - - - - - - * using namespace BDMenu; ........................................................................ ,.. ..... */ . class CStT11
class CStrli: public astratl I public
void AlgoritmoDeInterfaz(), ) ; /' ............................................................................. * Using namespace BDMenu; * class CStrlZ .............................................................................. * I class CStrlZ: public aStratl !I (
1; /. .............................................................................
public: void AlgoritmoDeInterfazO;
, .
* using namespace BDMenu; f class cStr13
class cStrl3: public astratl
public :
.............................................................................. */
(
) ; void AlgoritmoDeInterfazO;
106
........ -
CAPhWLO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA PRUEBAS
107
CAF'h'WLO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
/I
( orivate : protected: public:
ned int CK; ,-BASE O
CK P O; (
I ; */
virtual void bdinicia0; virtual int bdescb0; //unsigned int, unsigned intl; virtual int bdescbw0; //unsigned int, unsigned int); virtual int bdesca0; //unsigned int. unsigned int);
.I virtual int bdleeb0; //unsigned int); virtual int bdleebw0; //unsigned inti; virtual int bdleea0; //unsigned i n t i ;
11
1; /' .............................................................................
* class VA1
class VA1: public BASE
I * using namespace B u s y ~ ;
It * /
( private : I/
protected: unsigned int VA; / / [30001 ;
public: /*VA10
V A 1 0 (unsigned int v-VA130001) o r t
VA130001 D v~VA[30001; I* / void bdinicia0; int bdleea();//unsigned int VAR); int bdesca()://unsigned int VAR. unsigned int VALOR);
) ;
void bdinicia0; int bdleea();//unsigned int VAR); int bdesca()://unsigned int VAR. unsigned int VALOR);
) ;
private:
protected: public:
I unsigned int VE; // 12001 ;
I /*VE10 (1; (
I
VBlluneigned int v-VBi2001 I
VB[2001 E V ~ V E ~ Z O O I ,
" I void bdinicia0; int bdleebO;//unsigned i n t VAR); int bdleebwO;//unsigned int GRUPO); int bdescb(l;//unsigned int VAR. unsigned int valor); int bdescbw();/./unsigned int GRUPO, unsigned int VALOR); 1; II
CAPiTULO4: DESARROLLO Y PRUEBAS D E L A HERRAMIENTA PRUEBAS ,
La Figura 4.1'5 es el diagrama de clases correspondiente al listado de código anterior, recuperado con InverSOODA:
11
I
u - Reviredl ~~~ ~. ~~~ ~ ~.~ L..L1
__. -
I1
Figura 4.15 Diagrama de clases recuperado con InverSOODA: despliegue las clases de " BDSys y de BDMenu.
La recuperación del diagrama de clases de BDSys y de BDMenu implicó realizar previamente los siguientes pasos:
I1 - Unir en un solo archivo con extensión hpp la totalidad del código de los
archivos de cabecera dispersos, es decir, todo archivo con ' solamente definiciones de clases. Comentar toda directiva de preprocesamiento. Reescribir toda línea de código que tuviera que ver con apuntadores, de manera que se prescindiera de éstos.
- -
'i)
- Comentar toda implementación inline. - Comentar todo constructor. - Reescribir toda Cunción con parámetros, de manera que se tuviera una versión
de la misma función sin parámetros. Ii
109
CAP¡TULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
81
De este párrafo en adelante, la exposición los resultados de la fbtención del diseño detallado de cada uno de los métodos de las clases de B D S p y BDMenu, es de la siguiente manera: la porción de código del método adyacente a la ilustración $desde la Figura 4.16 hasta la F i b r a 4.3 1) con el diieño detallado correspondiente.
/' .............................................................................
unsigned int astratl i : getnumii (
'i
I1
I1
I .. I¡
* / / / from aCtratl.hpp: ex inline function
char s [ S O I : gets is1 i return iatoi i s ) ) ;.
I1
Figura 4.16 Diseño detallado recuperado del método aStratl :: getnum(). I1
* / / * ............................................................................. I / from aStratl.hpp: ex inline function t int aStratl i: pidevar i l
printf (Itdame el NUMERO de la variable : " i ; VAR = getnum i l i
// added return 01
) '11
Figura 4.17 Diseño detallado recuperado del método aStratl :: pidevar ().
1 IO
CAPh'ULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA PRUEBAS . .
* I / ^ ............................................................................. I / from aStratl.hpp: ex inline fuktion int astratl i : pidevalo I
printf("dame el VALOR de'la variable : ',I; VALOR = getnum O ;
/ / added '! return O;
.,I )
- 1 U - 1
U*J
k!rx "dame el VALOR de la variable : '' 5
VALOR= getnum 0 PSC
4 Fi&ra 4.18 Diseño detallado recuperado del método aStratl :: pideval 0.
* I /' ............................................................................. / from aStratl.hpp: ex inline function int astratl i : pidegrupo0 I . * I ) . printf ("dame el NUMERO del grupo . ,
VAR = getnum ii ;
// added return O;
I
Figura 4.19 Diseño detallado recuperado del método aStratl :: pidegrupo 0.
111
. .. 11
I!
1 AlgoritmoDelnteríaz
d a d
ipidevar
I/
Figura 4.20 Diseño detallado recuperado del método cStrl1 ::AlgoritmoDeInterfaz().
;/ cstr12 .cpp void cStrl2 : : AlgoritmoDeInterfaz I 1 I
printf ('LEE ANALüGICO\ntO ; pidevar ( ) ;
1
d a 2
A AlgoritmoDelnteríaz 2 D a lb
1 pidevar I
$/ "LEE ANALOGiCO\n" .< ,
I/
I1 Figura 4.2 1 Diseño detallado recuperado del método cStrl2::AlgoritmoDeInterfaz().
,I
112
CAP~TULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA PRUEBAS
* / /' ............................................................................. // cstr13.cpp
I
void cStrl3 : : A l g O r i t m O D ~ I n t ~ ~ f ~ ~ O
printf ("LEE BINAR10 POR GRUPO\n"l ; pidegrupo 0 ;
d a d 1 AlgoritmoDelnterfaz
d a d
&<*/ "LEE BINAR10 POR GRUPO\n" ,I .s l P i d e g r u P 0
I)
Figura 4.22 Diseño detallado recuperado del método cStr !3::AlgoritmoDeInterfaz(),
iJ
Figura 4.23 Diseño detallado recuperado del método cStr14::AlgoritmoDeInterfaz().
113
CAPfTULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA
printf ("ECC ANALOGICO\n"I : pidevar 1 ) : pideval I) ;
-1 D - 1 I 1
Figura 4.24 Diseño detallado recuperado del método cStrl5::AlgoritmoDeInterfaz().
/ * * I
(
/ I cStrl6.cpp void cStrl6 : : AlgoritmoDeInterfazO
printf ["ECC BINAR10 POR GRUPO\n") i pidegrupo í ) ; pideval O i
I
1 AlgoritmoDelnterfaz
- I n 2
py- "ESC BINAR10 POR GRUPO\n" 4
.lpidegrupo
.lpideval
Figura 4.25 Diseño detallado recuperado del método cStrl6::AlgoritmqDeInterfaz().
114
CAPITULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA PRUEBAS
I, I1 * / / * .............................................................................
t
/ / SC-BASE.Cpp BASE 'SC-BASE::ProduceO
return CreaO;
-Yrea
115
CAPITULO 4: DESARROLLO Y PRUEBAS DE LA HERRAMIENTA !I
/ J. ...............................................................................
1 int VA1 : : bdescalunsigned int VAR. unsigned int VALOR)
if W A R 5 3000) I printfí" ERROR . . . EL NUMERO DE LA VARIABLE ES > QUE EL TOTAL\n"); printf 1'' DE VARIABLES DE LA BASE DE DATOS \n'O ;
I, 1 else
I* deshabilita interrupciones * / / * suma e l nuevo valor y resta el valor anterior*/
(
CK += (VALOR - VA[VARII; VA [VARI = VALOR; / * habilita interrupciones */
., ' )
return (VALOR) ; t
I
II 2 0 2 1
bdesca unsigned int VAR unsigned int VALOR A( 2 0 2
o VAR ' 3000 2 0 2
"ERROR,.. EL NUMERO DE LAVARIABLE ES > QUE ELTOTAL\n" .4
y/. 8 1 DE VARIABLES DE LA BASE DE DATOS \no' .<, I)
-..
Areturn VALOR
Figura 4.3 1 Diseño detallado recuperado del método VA1::bdsca (unsigned int VAR).
Respecto a la recuperación del diseño detallado sólo se encontraron los siguientes
Se necesitó guardar en un archivo aparte las definiciones de métodos inline, para poder realizar la recuperación de su diseño.
detalles: -
4.5 Referencias [San021 Santaolaya Salgado. Re"& Modelo de Represeniaci6n de Palrones de C6digo para la ConstniccMn de
Componentes Reusables. (Tesis de Doctorado. Instituto Poltecnico Nacional. Centro de Investigación en wmputaci6n. Laboratorio de ingeniería de Conware. México D.F. Noviembre de 2002).
Capítulo 5
5.1 5.2 5.3 5.4
“What else could I write?, I don’t have the right..:”
K. Cobain
Análisis de los resultados obtenidos Conclusiones Trabajos Futuros Referencias
CApiTuLo 5 : CONCLUSIONES ANALISIS DE LOS RESULTADOS OBTENIOOS
En el presente capítulo se presenta en primera instancia un análisis de los resultados obtenidos en las pruebas descritas en el capítulo anterior. Así mismo, a partir de l a experiencia obtenida durante el desarrollo en general del proyecto y primordialmente del análisis de los resultados se enuncian las conclusiones a las que se llegaron. Además, en la
't ' ú l t ima sección se menciona una serie de recomendaciones a manera de trabajos futuros.
Deficiencias encontradas durante las pruebas I . . . . . . . . . . . . . . . . . .
1: Deficiencia . ~ .............. ................ - .............. A:..:...:.: Motivo .... L.1 ................... :.I ..:.::I ... 1::- El área de aplicación no tiyne habilitado el . El control del área de desplazamiento o área crecimiento 'del área de visualización ;de scroll como mejor se le conoce, está
~ controlada por las barras de dksplazamiento: supeditado a.la función SetScrollSizes propia j de los objetos tipo CView de la MFC. Se necesita asignar un valor más ,grande al área
I
~ : de desplazamiento si ai comparar este último contra el valor del área de la ultima figura clase recuperada es menor.
)I 11 --- ^ _ L.-- ._--...__--I- 1 . . . . .
11 5.1 Análisis de los resultados obtenidos
Como se indicó en los casos de estudio del capítulo anterior, los resultados obtenidos respecto a la eficacia de la herramienta para recuperar diseños son satisfactorios, apegándose a las limitaciones y alcances mencionados en l a Sección 1.6 de este documento. Una serie de deficiencias de InverSOODA e InverDDVi no descritas con anterioridad fueron detectadas durante las phebas. Se resumen a continuación las más importantes:
I,
k
1
No se admiten parámetros en las funciones. 11
121
El analizador sintáctico no tiene definida una regla gramatical que los produzca i~ ~~
~~ ~. . . ............ .......... . . . . . . .
No puede recuperarse el . El analizador sintáctico no las define, pero por ~ sin un tipo de dato de i otro lado incluirlas puede producir una
ambigüedad con los constructores. !
CAPhULO 5 : CONCLUSIONES
I/ ............... . .. ..... ...... ..... . . . .... ... .... ,. . ..,.. .... . .. . . . .- ...... -. . . ... . . ~ .. . ~
~~ __ ~
Se tuvo que deshabilitar una serie de reglas herencia de manera bidireccional. que evitaban recuperar diseños que tuvieran
legitimamente una relacibn de herencia y otra de agregación a la vez, entre dos clases.
- 11
I1
I
Tabla 5.1 Deficiencias encontradas durante las pruebas a InverSOODA
5.2 Conclusiones
A pesar de la existencia de las limitaciones y alcances sugeridos en el primer capítulo y la detección los errores de ejecución o bugs introducidos durante las phebas, la hipótesis que sostiene la tesis de este trabajo está comprobada: fue posible recuperar los diagramas de clases UML y el diseño detallado de los métodos de clases en diagramas de Warnier.
I1
Siempre será más fácil comprender el todo de un sistema de software a través de un diagrama que infiltrándose en las peculiaridades del código fuente. Particularmente para los sistemas escritos en C++, el diagrama de clases provee una vista estátiza del sistema en la que salta a las vista cuantas clases existen, cuantas herencias, agregaciones y demás relaciones existen. I .
En un proceso de desarrollo de software más o menos ordenado el diagrama de clases puede comunicar eficazmente las ideas generales del diseñador hacia alblprogramador. Más aún, cuando ya existe el software,. las personas encargadas del mantenimiento del software verán con gratitud una herramienta que les permita desentrañar dicho código existente. Mejor aún, tanto en etapas de diseño como de mantenimiento de sistemas escritos en C++ la posibilidad de crear o recuperar diseños' detallados de métodos, permitirá que las personas involucradas en el desarrollo se comuniquen con un nivel de abstracción mayor que el código fuente. I/
Considerando las acotadas dimensiones del proyecto (InverSOODA es un módulo de un proyecto más grande y ambicioso) y que no se tiene precisamente un &~po de trabajo al estilo industrial, se tiene que el aporte de este proyecto es potencialmente útil para la comunidad nacional de investigación en el área de Ingeniería de Software La necesidad de contar con una herramienta que maneje ambos aspectos, el diseño estático de clases y el diseño detallado encuentra una solución con InverSOODA. Además, la reestructuración de la arquitectura original de SOODA con algunos patrones de diseñy, presupone una escalabilidad más fácil a posteriori de la herramienta.
La herramienta plantea un esquema simple de recuperación de diseños en términos del archivo de especificación gramatical y de los objetos involucrados en el proceso.'El USO de un objeto constructor que obedece al patrón de diseño Builder permite encapsular todo el proceso de análisis semántico en un solo objeto, conservando las responsabilidades de los objetos lexer y parser generados con ANTLR de realizar el análisis lkxico y sintáctico respectiva y Únicamente. Esto significa que, a la postre, se puede intercambiar la funcionalidad del análisis semántico con otro parser más completo para analizar código
122
CONCLUSIONES CAPfTLiLO 5 : CONCLUSIONES ;
fuente en C++' y por ende, reLonocer más construcciones gramaticales del lenguaje, sin alterar la recuperación o uso de información semántica ya implementada.
InverSOODA puede ser empleada en ambientes académicos para promover la enseñanza de sistemas orientados a objetos aportando el aspecto de diseño orientado a objetos. En conjunto con los demás módulos descritos en la Sección 1.
5.3 Trabajos Futuros
Los resultados obtenidos en este proyecto permiten pensar en una cantidad importante de mejoras al software para abrir más perspectivas de uso práctico. Enseguida se enlista a manera de trabajos futuros, alghnas de las mejoras, quizá las más evidentes:
Q Quizá la deficiencia más importante de InverSOODA radica en su parser. El hecho de incluir un analizador sintáctico completo supone la apertura de un análisis semántico más concienzudo, que a la postre permita recuperar más entidades gráficas del diagrama de clases del UML.
o Idear una estrategia para poder analizar código con directivas de preprocesamiento, excepciones, y namespbces; elementos que no necesariamente se usan en la teoría de la programación orientada a objetos y sin embargo promueven la construcción de software'robusto y porthble.
o Atender las deficiencias que marca la tabla 5.1 de este capítulo para enmendarlas,
o Integrar InverSOODAl e InverDDVi con las demás herramientas de la Suite CENIDET (ver la Seciión 2.1.2, del capítulo 2), para que pueda convivir con éstas en un Ambiente de Mokielado.
o Integrar capacidad de zoornrning en los diagramas.
o Proveer un vínculo con herramientas de reingeniería, como en [sanozl, para poder visualizar el diseño del código resultado de procesos de reingeniería. En otras palabras, permitir el uso de la funcionalidad de InverSOODA a manera deplug-in.
o Aumentar la capacidad del software para realizar ingeniería round-trip para otros lenguajes de programación orientados a objetos.
5.4 Referencias
[San021 Cantaolaya Salgado, Renb. Modelo de Represeniacidn de Paimnes de Cddigo pare la Consi~lccidn de Componentes Reusables. (Tesis de Doctorado, instituto Poitbcnico Nacimai. Centro de Invesügacibn en computación, Laboratorio de Ingenieria de Software. México D.F. Noviembre de 2002).
1
C++ para ANTLR. De hecho, el 16 de febrero de 2003 apareció la versión graluita dc archivo de espccifieaci6n gramatical para nnaiiais léxico y sintaciico
123
Subconjunto de la Gramática de C t t utilizada en InverSOODA 81
El lector encontrará que existen reglas triviales en esta subgramatica. Por ejemplo, sean A,B,C E del conjunto de los simbolos no terminales de G .
<A> ::= <B>; <B> ::= <C>, entonceskAz ::=<O y <A> ::= <B> es una produción trivial.
La razón para incluir producciónes triviales se debe a que se deja abierta la posibilidad de expander más producciones alternas, que complementen la gramática sin perder el orden del estándar.
Seccion I. Programa. I/
1.1 cUnidadTrad> : : = <dec'laracion> EOF I E
II
Seccion 11. Expresiones. 11.1 cexprId> : : = cidNoCualificado>
11.2 cidiioCualificado> ::;= <id:ID>
Seccion 111. Oraciones. 111.1 E
1
Seccion IV. Declaraciones. IV.l cdeclaracions : := cdeclSirnple>
IV.2 cdeclsimples : : = csecDeclESp> clistaInicDecla> > ; '
i
I1 clistaInicDecla>';' 1 csecDeclEsp> I ; '
Il ' i ' IV.3 csecDeclEsp> : : = cespecDecl>
IV.4 cespecDecl> : : = cespecTipo>
IV.5 cespecTipos ::= <especClase> I)
I cespecSlrnpleTipo> I <esp&cElabTipo>
IV.6 <especSimpleTipo> : : = cnombreTipo> I <tipoflotante> I ctipoEntero>
11 I 'bool'
1
,I ANEXO A I/
It
I
IV.7 cespecElabTipo> : := <claveclase>
IV.8 <nombreTipo> ::= 'identificador'
IV.9 cespecFunc> : : = 'inline'[ 'virtual'
Ceccion V. Declaradores. 1)
V.l <iistaInicDecla> : : = <listaInicDecla> ' , ' <declInic> i I cdeclInic>
V.2 cdeclInic> : : = <declarador> I
v.3 <declarador> : : = cexprIdz ' í ' ' ) ' I exprrd II
V.4 cdefFunc> : : = E /I
V.5 cdefFuncMiembro> : := <metodovirtual> I <metodoCimple> I/
V. 6 <metodosimple> : : = <secDeclEspMetodoCirnple> <declarado:>
V.7 <metodovirtual> : := csecDeclEspMetodoVirtual> <declarador> I = ' 'O' 1 <secDeclEspMetodoVirtual> <declarador>
I/ v.8 <secDeciEspMetodoVirtual> : : = <especTipoRetFunc> 'virtual' 'inline'
I <especTipoRetFunc> 'inline' 'virtual' I 'inline' 'virtual' <ecpecTipoRetFunc> I 'inline' cespecTipoRetFunc> 'virtual' I 'virtual' <especTipoRetFunc: 'inline' I 'virtual' 'inline' <especTipoRetFunc> 1 cespecTipoRetFunc> 'virtual' I 'virtual' <especTipoRetFunc> I 'virtual' 'inline' 1 'virtual'
I 'inline' 'virtual' I/
I/
V.9 csecDeclEspMetodoCimple> : : = <especTipoRetFunc> 'inline: 1 'inline' <especTipoRetFunc> I <especTipoRetFunc> 1 'inline' 11:
V.10 <secDeclEcpFunc> : : = <ecpecTipoRetFunc> <especFunc> t I <especFunc> <especTipoRetFunc> 1 <especTipoRetFunc> I <especFunc> 1
V.11 <especTipoRetFunc> : : = <especSimpleTipo>
Sección V i a . Clases. VIa.1 <especClase> : : = <cabeceraclase> I ' <especMiembro> ' ) '
VIa.2 <cabeceraclase> : : = <claveclase> 'identificador'
I! I 'void'
126
".' f
ANEXO A
I '<claveclase> 'identificador' cclausulaBases via.3 <claveclase> : : = 'class' I 'struct' I 'union'
VIa.4 cespecMiembro> : : = '<declaracionMiembro> I <declaracionMiembro> <especMiembro> 1 , cespecAcceso> % : '
I cespecAcceso> I : ' <especMiembro>
VIa.5 <declaracionMiembro> : : = <defFuncMiembro> ' ; ' 1 cdefFuncMiembro> I <especSimpleTipo> <listaDeclMiembro> l;' I S . !
VIa.6 clistaDeclMiembro>.i : : = <declaradorMiembro>
VIa. 7 <declaradorMiembro& : : = <declarador>
I clistaDeclMiembro> ' , ' cdeclaradorMiembro>
Sección VI(bis). Clases Derivadas. V I b . 1 <clausulaBase> : : ' : ' cespecAcceso> <nombreTipo>
VIb.2 <especAcceso> : : = 'private' I 'protected' I 'public'
Sección VII. Reglas de producción para tipos de datos. VII.l <tipoFlotante> : :L 'float' I 'double' I 'long' 'double'
VII.2 ctipoEntero> : : = ¿tipoCaracter> I <tipoEnteroConSigno> I ctipoEnteroSinSigno>
VII.3 ctipoEnteroConSigno> : : = 'signed' 'short' 'int' I 'signed' 'long' 'int' I 'signed' 'short' I 'signed' 'long' I 'signed' 'int' I 'short' 'int' I 'long' 'int' 1 'signed' I 'short' I 'long' I 'int'
VII.4 <tipoEnteroSinSigno> : : = 'unsigned' 'short' 'int' I 'unsigned' 'long' 'int' I 'unsigned' 'short' I 'unsigned' 'long' 1 'unsigned' 'int' 1 'unsigned'
VII.5 <tipoCaracter> : : = 'unsigned' 'char' 1 'signed' 'char' I 'char' 0 5 - 0 3 3 6 '
127
![u p s s Ill n u c O -1-6 -K -1—6 p o o 41 J -K p .14 @ ióJ s p p ......O p p 10 -1-6 n.n p -K 00 p p < s p p O o O o O s C] s +6 s s -K -K s O s o IBþ -K p s < O p IJ >](https://img.pdfslide.tips/doc/110x75/6021ca24cac6294893021302/u-p-s-s-ill-n-u-c-o-1-6-k-1a6-p-o-o-41-j-k-p-14-ij-s-p-p-o-p.jpg)
