Centro Nacional de Investigación y Desarrollo Tecnológico ... · Los diagramas de secuencias de UML muestran las interacciones de objetos colocados en secuencias de tiempo, en particular,

S.E.P. S.E.S. D.G.E.S.T.

Centro Nacional de Investigación y Desarrollo

Tecnológico

cenidet

Aplicación de un proceso de Ingeniería Inversa a Código en C++ para obtener

Diagramas de Secuencias

TESIS

Que para obtener el grado de: MAESTRO EN CIENCIAS EN

CIENCIAS DE LA COMPUTACIÓN

Presenta:

José Armando Alfonzo García

Director de Tesis:

Dr. Máximo López Sánchez

Cuernavaca, Morelos Enero del 2006

Dedicatorias

A mis padres Armando Alfonzo Vázquez

y María de Lourdes García Ruiz porque cada logro obtenido es para ellos, a quienes

me han dado todo lo mejor en esta vida y quienes

han depositado su confianza en mi,

los respeto y honro.

A mis hermanas Claudia y Jaqueline porque llevo también su sangre en mis venas,

son ustedes quienes me han motivado y apoyado

a levantarme cada día.

A mi familia entera por ser mi mejor ejemplo de responsabilidad,

dedicación y amor al trabajo y a la familia.

A mis amigos por su sinceridad eterna y por

motivarme a ser mejor cada día.

Dedicado a la mujer que complementa la otra parte de mi vida...

que me ha apoyado y tenido paciencia...

que me hace ver de la vida, un regalo de Dios...

que me hace escuchar de la vida, un canto divino...

que me hace sentir de la vida, el Amor sincero...

a la mujer que amo y respeto.

Dedicado a ti, mi vida: Evanely

Agradecimientos

Al Consejo Nacional de Educación Tecnológica COSNET por el apoyo

económico y permitir llevar a cabo el desarrollo de esta tesis de maestría.

Al Centro Nacional de Investigación y Desarrollo Tecnológico CENIDET, así

como a todo el personal que en este labora, por haber creído en mi y

haberme permitido ser parte de sus equipos de trabajo.

A mi director de tesis Dr. Máximo López Sánchez a mis revisores M.C.

Felipe de Jesús Alaniz Quezada, M.C. Reynaldo Alanís Cantú y el Dr. René

Santaolaya Salgado, así como M.C. Olivia Graciela Fragoso Díaz por ser

guías y gran apoyo en el desarrollo y mejora de esta tesis desde sus inicios

hasta el final.

A todos mis profesores, que me brindaron sus mejores conocimientos y

experiencias.

A mis amigos del IIE por su apoyo y paciencia

Dr. Andrés Rodríguez y MC. Isaac Parra

A toda la gente que me apoyo para lograr esta meta, por sus palabras de

aliento para ser mejor cada día.

A todos mis amigos y compañeros del CENIDET que me han conocido por

CHEMANDO++

Gracias por ofrecer y regalar su amistad en esta aventura de la vida:

Ariel, Arturo, Allan, Armando, Adrián, Gabo, Toño, Paco, Chavo, Tito,

Guillermo, Marco, Homero, Pablo, Ismael, Rafael, Carlos, Silvana, Sonia,

Sandra, Rosy, Mariana, Crisantema, Leonor, Mireya, Erika, Vianey, Ana,

Karina y por todos aquellos que han depositado su confianza en mi.

Resumen La ingeniería inversa es utilizada para entender la estructura y comportamiento de un software cuya documentación no se encuentre actualizada a la fecha. El Lenguaje Unificado de Modelado [26] (UML, por sus siglas en inglés) es un estándar para escribir planos de software que puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. Los diagramas de secuencias de UML muestran las interacciones de objetos colocados en secuencias de tiempo, en particular, muestra los objetos que participan en la interacción y en la secuencia de mensajes intercambiados [27]. La ingeniería inversa de los diagramas de secuencias ayuda a los desarrolladores de software entender el comportamiento de un sistema durante el desarrollo iterativo y mantenimiento del software.

El objetivo de ésta tesis es diseñar un algoritmo de recuperación de diagramas de secuencias y construir una herramienta de ingeniería inversa que permita recuperar los diagramas de secuencias a partir de programas escritos en código del lenguaje de programación C++. Para lograr el objetivo se planteó una metodología de solución basado en la transformación de modelos que consistió en la modelación del código fuente, tal como un metamodelo capaz de representar un programa orientado a objetos. La traducción a diagramas de secuencias se basó en la sintaxis del código, de la cual se extrajo información tales como los nombres de las clases, objetos, funciones y llamadas, que fueron almacenados en el metamodelo. Una vez almacenado, se transformó el modelo obtenido del código hacia otro modelo en forma de diagramas de secuencias con ayuda de algoritmos de conversión que tienen la capacidad de reducir los diagramas obtenidos, ya sea por método, clases o niveles de profundidad de llamadas que se realizan entre las clases. Un diagramador desarrollado en anteriores trabajos [3], fue utilizado para la visualización de los diagramas de secuencias y que determinó la información o elementos requeridos para construir un diagrama tales como: las clases y mensajes. El corazón de esta investigación es el metamodelo de código para programas orientados a objetos tales como los escritos en C++ y los algoritmos de conversión a diagramas de secuencias.

Durante la fase experimental se seleccionó como caso de estudio un sistema simulador de cajero automático (ATM, Automated Teller Machine) para evaluar y validar nuestra metodología y cuyo código fue escrito en C++ proporcionando varios casos de uso tales como: iniciar sesión, realizar transacciones, validar usuarios entre otras funciones a los cuales se llevó a cabo ingeniería inversa para obtener diagramas de secuencias como casos de prueba.

Con base a los resultados de la tesis podemos concluir, que cumplió con los objetivos propuestos así como demostrar que es posible recuperar directamente del código los diagramas de secuencias de UML de forma automática. Se ha demostrado que si existe forma de modelar el código fuente a través de la creación y uso de un metamodelo capaz de representar un programa orientado a objetos tal como se realizó en este trabajo para el lenguaje de programación C++. Este metamodelo, más que una tabla de valores, es una estructura que representó realmente cómo están dispuestos cada parte o elemento del programa, que ayudó a un mejor análisis durante la transformación a otros modelos, tal es el caso de los diagramas de secuencias obtenidos. Con esto el metamodelo es útil para modelar lenguajes de programación orientado a objetos como el lenguaje C++, así también para llevar a cabo ingeniería inversa para la obtención de diagramas de UML como los de secuencias. El metamodelo de un programa orientado a objetos, es una representación del software escrito en código fuente en el mundo real cuya utilidad es la medida de su valor.

Abstract Reverse engineering is used to understand the software structure and behavior whose documentation is not updated to the date. Unified Modeling Language UML [26] is a standard to make software planes that can be used to visualize, to specify, to build and to document the system artifacts that it involves a big software quantity. UML sequence diagrams show object interactions in time sequences; it shows the objects that take part in the interaction and in the message sequence exchanged [27]. The sequence diagrams reverse engineering help to the software developers to understand the system behavior during the iterative development and the software maintenance. The objective of this thesis is designing a sequence diagrams recovery algorithm and building reverse engineering tool in order to recover the sequence diagrams from programs written in C++ programming language. In order to reach the objective it was planned a solution methodology based on models transformation by modeling source code, such as a metamodel being able to represent a oriented object program. The sequence diagrams translation was based on code syntax, which information like classes name, objects, functions, and calls to functions were extracted and they were stored in the metamodel. Once the information was stored, the source obtained model was become to model sequence diagrams. It was carried out by using conversion algorithms that can reduce the obtained diagrams. The reduction can be done specifying a method name, classes or setting calls depth levels realized in classes. A viewer developed in previous works [3] was used to visualize the sequences diagrams. The sequence diagrams determined the information or required elements (classes and messages) to build a diagram. This research core is the code metamodel to object oriented programs such as those written in C++ language and the sequence diagrams conversion algorithms. During experimental phase it was selected as study case an ATM (Automated Teller Machine) simulator system to assess and validate our methodology. The ATM code was written in C++ language. The ATM has many use cases, some of them are: System Startup, Session, Transaction, Withdrawal, Deposit, Transfer, and Inquiry. The tests were realized on ATM code in order to get sequence diagrams. According to the obtained results, we can conclude that the proposal objectives were accomplished. It was demonstrated that it is possible to recover directly from source code the UML sequence diagrams automatically. Also it was proved that is able to model the source code by creating and using of metamodel capable to represent an object oriented program as C++ language code. To get better analysis, the metamodel is structured with values to represent the real way in which each part or element of program is disposed. The metamodel is useful to model object oriented programming languages, such as C++. It is also useful to carry out reverse engineering to obtain UML sequence diagrams. The metamodel of object oriented program is a representation of software written in source code in real world. The metamodel value depends of its utility.

i

TABLA DE CONTENIDO Tabla de contenido ............................................................................................................ i Listado de figuras ............................................................................................................ iii Listado de tablas .............................................................................................................. iv 1. Introducción...................................................................................................................1 2. Antecedentes .................................................................................................................3

2.1. Trabajos relacionados.............................................................................................4 2.1.1. Tesis.................................................................................................................4 2.1.2. Artículos ..........................................................................................................5 2.1.3. Herramientas ...................................................................................................7 2.1.4. Análisis de los trabajos relacionados...............................................................9

2.2. Planteamiento del problema .................................................................................10 2.2.1. Objetivo .........................................................................................................10 2.2.2. Pregunta de la investigación..........................................................................10 2.2.3. Justificación...................................................................................................11

2.2.3.1. Criterios y beneficios de la investigación...............................................11 2.2.4. Complejidad técnica en la solución del problema.........................................11

2.3. Hipótesis ...............................................................................................................12 2.4. Alcances y limitaciones........................................................................................12

3. Marco conceptual ........................................................................................................13 3.1. Ingeniería en Software..........................................................................................13

3.1.1. Reingeniería...................................................................................................13 3.1.2. Mantenimiento...............................................................................................13 3.1.3. Reingeniería o modernización.......................................................................14 3.1.4. Ingeniería inversa ..........................................................................................14

3.1.4.1. Objetivos ................................................................................................15 3.1.4.2. Recuperación de diseño..........................................................................15 3.1.4.3. Aspecto económico ................................................................................15

3.1.5. Lenguaje Unificado de modelado..................................................................15 3.1.6. Diagramas de interacción ..............................................................................16 3.1.7. Diagramas de secuencias...............................................................................16

3.1.7.1. Ingeniería inversa de los diagramas de secuencias ................................16 3.2. Análisis estático contra dinámico.........................................................................17 3.3. ¿Qué es un metamodelo?......................................................................................17

4. Método de solución .....................................................................................................19 4.1. Metamodelo del diagrama de secuencias .............................................................20 4.2. Traductor y el metamodelo de un programa orientado a objetos .........................21 4.3. Algoritmos de conversión ....................................................................................29

5. Desarrollo del sistema .................................................................................................32 5.1. Requerimientos básicos ........................................................................................32

5.1.1. Nombre del producto.....................................................................................32 5.1.2. Contexto ........................................................................................................32 5.1.3. Especificaciones de alto nivel .......................................................................32

5.2. Caso de uso...........................................................................................................33 5.2.1. Actores...........................................................................................................33 5.2.2. Casos de uso ..................................................................................................33

5.3. Despliegue del proyecto .......................................................................................34 5.4. Modo de operación ...............................................................................................35

ii

5.5. Estructura del sistema...........................................................................................38 5.5.1. Diagramas de clases y de paquetes................................................................38

5.5.1.1. Traductor ................................................................................................38 5.5.1.2. Interfaz del usuario (SCUML)................................................................41

5.5.2. Diagrama de componentes: Traductor e interfaz de usuario .........................44 6. Evaluación experimental .............................................................................................45

6.1. Caso de estudio PIN no válido .............................................................................47 6.2. Caso de estudio Iniciar sesión ..............................................................................48 6.3. Otros casos de estudio ..........................................................................................50

6.3.1. Caso de uso de realizar una transacción ........................................................50 6.3.2. Ingeniería inversa de la función que elige una transacción...........................51 6.3.3. Ingeniería inversa de la función de reporte de fallos.....................................51

7. Conclusiones ...............................................................................................................52 7.1. Pregunta de investigación resuelta .......................................................................52 7.2. Análisis de los resultados .....................................................................................53 7.3. Comentarios y trabajos futuros.............................................................................53

7.3.1. Alcances y limitaciones de la herramienta ....................................................54 8. Referencias bibliográficas ...........................................................................................55

Anexo A ......................................................................................................................57 Anexo B.......................................................................................................................58 Anexo C.......................................................................................................................59 Anexo D ......................................................................................................................60 Anexo E.......................................................................................................................61 Anexo F .......................................................................................................................62 Anexo G ......................................................................................................................72

iii

LISTADO DE FIGURAS Figura 1 Arquitectura de la Suite cenidet-UML................................................................3 Figura 2 Evolución de la herramienta Suite cenidet-UML ...............................................4 Figura 3 Funcionamiento de la herramienta LogSequencer..............................................7 Figura 4 Funcionamiento de j2u........................................................................................8 Figura 5 Análisis estático contra análisis dinámico según Raitalaakso [13]...................17 Figura 6 Modelo conceptual del método de solución......................................................20 Figura 7 Metamodelo de un diagrama de secuencias según Macías Alonso ..................20 Figura 8 Ejemplar de un diagrama de secuencias de las herramienta Scuml..................21 Figura 9 Metamodelo de un programa orientado a objetos.............................................24 Figura 10 Estructura general del convertidor a diagramas de secuencias .......................29 Figura 11 Algoritmos de conversión a diagramas de secuencias ....................................30 Figura 12 Diagrama de secuencias del programa escrito en C++ ...................................31 Figura 13 Casos de uso de la herramienta .......................................................................33 Figura 14 Diagrama de despliegue del proyecto InverS3C.............................................35 Figura 15 Diagrama de actividad del modo de operación de la herramienta ..................36 Figura 16 Secuencia de operación de la herramienta ......................................................37 Figura 17 Dependencia entre paquetes del traductor ......................................................38 Figura 18 Estructura de clases del analizador .................................................................38 Figura 19 Estructura de clases y relaciones del metamodelo de un programa orientado a objetos .............................................................................................................................39 Figura 20 Herencia en el metamodelo.............................................................................40 Figura 21 Estructura de clases del Traductor ..................................................................40 Figura 22 Relación entre paquetes del la herramienta SCUML......................................41 Figura 23 Estructura de clases de la interfaz de usuario de InverS3C ............................41 Figura 24 Estructura detallada de clases de la interfaz de usuario de InverS3C.............42 Figura 25 Diagrama de clases del convertidor ................................................................43 Figura 26 Componentes del traductor e interfaz de usuario............................................44 Figura 27 Casos de uso del cajero automático ................................................................45 Figura 28 Diagrama de clases del cajero automático ......................................................46 Figura 29 Diagrama de colaboración de PIN no válido ..................................................47 Figura 30 Ingeniería inversa cuando el PIN no es válido................................................48 Figura 31 Diagrama de secuencias de iniciar sesión en un ATM ...................................48 Figura 32 Ingeniería inversa cuando se inicia sesión en un ATM ..................................49 Figura 33 Ingeniería inversa cuando se realiza una transacción .....................................51 Figura 34 Ingeniería inversa cuando se elige una transacción ........................................51 Figura 35 Ingeniería inversa cuando se reporta fallos en una transacción ......................51 Figura 36 Funcionamiento de LogSequencer..................................................................57 Figura 37 Funcionamiento de j2u durante el análisis dinámico......................................58 Figura 38 Funcionamiento de CodeLogic para C# en Visual Studio .NET ....................59 Figura 39 Funcionamiento de CodeLogic para Java .......................................................60 Figura 40 Opciones de la herramienta Borland Together para establece el tamaño de los diagramas.........................................................................................................................61

iv

LISTADO DE TABLAS Tabla 1 Trabajos relacionados.........................................................................................10 Tabla 2 Tabla de equivalencias entre el código C++ y el diagrama de secuencias.........22 Tabla 3 Ejemplar del metamodelo de un programa orientado a objeto escrito en C++ ..25

«Todo debe hacerse lo más sencillo posible, pero no más simple»

Albert Einstein

1. Introducción

in duda, los productos de tecnología como los aparatos electrónicos, televisores, teléfonos móviles, cámaras fotográficas, relojes digitales, aparatos de sonido, computadoras, etc. pasan a ser parte de la vida diaria de las personas en cualquier

lugar. Estos productos en su momento cuando se adquirieron fueron considerados como la última tecnología y, con el transcurso del tiempo estos han dejado de ser útiles, ya sea por su desgaste, su baja velocidad, rendimiento, estética e incluso hasta porque ya pasaron de moda. Este constante cambio de los productos tecnológicos no sólo implica cambios en su estructura física sino también en su estructura no física (intangible).

Mientras el hardware realiza cambios en su estructura a través del tiempo debido a nuevos desarrollos tecnológicos; el software, aunque tiene el mismo enfoque de avance no lo hace necesariamente a la misma velocidad. Por lo que a una empresa o negocio no le es tan sencillo abandonar o cambiar su software y poder mantenerlo a la vanguardia de acuerdo como la competencia y la tecnología hoy lo exige. Para estos casos la solución está en el concepto de reingeniería, la cual nos da la posibilidad de reconstruir al software proporcionándole una nueva funcionalidad y dotarlo de mejores alternativas de mantenimiento. Esto implica la creación de nuevos sistemas basados en computadora, pero en muchos otros, se requiere la modificación y reconstrucción de aplicaciones existentes.

Para aquellos casos en que los programas de la empresa o negocio que cuentan con poca documentación y que es necesario entenderlos para llevar a cabo la reconstrucción del software existe el concepto de ingeniería inversa [1], término que tiene sus orígenes en el mundo del hardware. La ingeniería inversa del software es el proceso de análisis de un programa con el fin de crear una representación de éste con un nivel de abstracción más elevado que el código fuente. En el software la ingeniería inversa es un proceso de recuperación de diseño. Con las herramientas de la ingeniería inversa se extrae información del diseño arquitectónico y del proceso del programa existente e información de los datos.

Actualmente el estándar de representación del diseño de software se hace mediante el uso del Lenguaje de Modelado Unificado (UML Unified Modeling Language), el cual es el lenguaje más utilizado en la actualidad por la industria del software [1]. Este trabajo hará uso de los diagramas de interacción para describir los mensajes que se intercambian y ocurren entre diferentes objetos dentro de un sistema. Debido a que estos diagramas proveen una representación gráfica de la transferencia de control y describen el comportamiento esperado por el sistema. De hecho, durante el mantenimiento la actividad de entender un programa es central, y para sistemas orientados a objetos puede ser notablemente difícil entender el comportamiento de los

Capítulo

1

S

Capítulo 1. Introducción

2

objetos. Aplicar ingeniería inversa al código fuente escrito en lenguaje orientado a objetos para la obtención de los diagramas de interacción puede apoyar a tal tarea [2].

Debido a la importancia que guardan las dos plataformas de desarrollo de software, Sun y Microsoft, el trabajo que se desarrollará en esta tesis será para ser implementado en la plataforma de Microsoft y en especial aplicado al lenguaje C++. Dentro de este trabajo de tesis se definirá un método para llevar a cabo ingeniería inversa sobre código escrito en C++ y así obtener diagramas de secuencias de UML. Se basará en: un metamodelo, algoritmos de conversión y reducción de diagramas. El metamodelo propuesto concentrará información relevante del código como son los objetos y las llamadas a funciones dentro de las clases. Se utilizarán diagramas de secuencias para que revelen las interacciones que existan entre las clases por medio de mensajes. Este trabajo presentará la forma de extraer la información del código escrito a un metamodelo que lo represente, así como un algoritmo para convertirlo a diagrama de secuencias y su reducción.

El producto (prototipo) de la tesis denominado InverS3C permitirá la obtención de diagramas de secuencias de UML tomando como base la información almacenada en el metamodelo del programa escrito. La visualización de los diagramas de secuencias se llevará a cabo en una herramienta denominada S3C [3] desarrollada en anteriores trabajos al nuestro.

Este trabajo presentará la metodología, la cual será ilustrada con ejemplos y validada a través de casos de estudio. Organización de esta tesis

Esta tesis esta estructurada como sigue: En el capitulo 2 se describirán los antecedentes y detalles de los trabajos

relacionados tanto de investigación como comerciales, y al final se presentará una tabla de comparación de estos trabajos. Dentro de esta sección se mostrará una descripción del problema, justificación, hipótesis, objetivos, alcances y limitaciones

En el capítulo 3 se describirá el marco conceptual con términos y principios para el claro entendimiento de este trabajo.

Capitulo 4 contendrá el método de solución, se explicará el método propuesto y los algoritmos, tomando como base un ejemplo.

Capitulo 5 presentará el desarrollo del sistema. Se explicará el ciclo de vida del sistema: el análisis y el diseño.

Capitulo 6 mostrará la evaluación experimental. Se describirá un conjunto de documentos de prueba que se realizaran a la herramienta.

Capítulo 7 contendrá las conclusiones y trabajos futuros. Se describirán las conclusiones a las que se llegó después de analizar, diseñar, instrumentar y probar el sistema. Aquí se realizará un análisis de las implicaciones del estudio y si se cumplieron parcial o totalmente los objetivos planteados en la propuesta de tesis.

Como punto final se dará un resumen de recomendaciones para continuar con esta investigación y otras que puedan ser derivadas de esta.

«La gran finalidad de la vida no es el conocimiento, sino la acción»

Thomas Henry Huxley

2. Antecedentes

l grupo de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) ha elaborado a la fecha, un ambiente de desarrollo de software orientado a objetos denominado Suite Cenidet-UML

(SCUML). Proyecto que tiene como parte central al Lenguaje de Modelado Unificado (UML por sus siglas en inglés). Mediante el uso del UML se pretende auxiliar al desarrollo de software evolutivo orientado a objetos, modelando a través de diagramas de casos de uso, clases y paquetes la parte estática de un sistema de software y por otro lado los diagramas de actividades, interacción y estados para la parte estática. Presentando un valor agregado a la suite a diferencia de lo que los productos comerciales ofrecen; esto es, el modelado de diseño detallado de los métodos de clases más la documentación y pruebas asociadas al sistema. Entre los diagramas que contiene la suite se encuentran los diagramas de: casos de uso, clases, Warnier, estados, paquetes, secuencias así como ingeniería directa e inversa para código de C++ y Java (Ver Figura 1).

Figura 1 Arquitectura de la Suite cenidet-UML

A continuación se muestra la evolución de la Suite Cenidet-UML (ver Figura 2): 1997 LEVISS. Generador de código para leguaje C utilizando diagramas de Warnier

para el diseño detallado de funciones [4].

Capítulo

2

E

Capítulo 2. Antecedentes

4

2000 SOODA y DDVi. Nace la idea de crear un Modelado Visual Orientado a Objetos utilizando diagramas de clases junto los diagramas de Warnier para generar código C++ [5].

Figura 2 Evolución de la herramienta Suite cenidet-UML

2002 InverDDVi. Aplica un modelo de ingeniería inversa para la obtención de diseño detallado en diagramas de Warnier basado en Leviss para código C [6].

2003 InverSOODA. Realiza ingeniería inversa de código fuente en C++ para la obtención de su diseño de diagramas de clases y Warnier [7].

2004 Durante este año se desarrollaron varios proyectos para la creación de diagramas de paquetes [8], estados [9], secuencias [10], casos de uso con soporte de informes [11] e ingeniería inversa de diagramas de clases y Warnier a partir de código Java [12].

2005 InverS3C. Trabajo actual que pretende obtener los diagramas de secuencias a partir de código escrito en C++ y que se detalla en posteriores capítulos. Es conveniente hacer notar que a partir de este trabajo que se incorpora a la

Suite, esta última tomará el nombre de “Mango”, nombre que por decisión de los participantes en el desarrollo de la Suite Cenidet-UML, hará que sea más simple y sencilla de recordar.

2.1. Trabajos relacionados

2.1.1. Tesis Dynamic Visualization of C++ Programs with UML Sequence Diagrams [13] Autor: Timo Raitalaakso; Técnica utilizada: Análisis dinámico Este es un trabajo de maestría en ciencias el cual fue publicado en diciembre de 2000 y desarrollado en los laboratorios de sistemas de software de la Universidad Tecnológica de Tampere, Finlandia. En este trabajo se aplica un proceso de ingeniería inversa dinámica en sistemas orientados a objetos, en especial a código C++. La herramienta denominada DYNO1, recolecta información de la interacción entre objetos en tiempo de ejecución y produce secuencias que posteriormente son visualizados en otra herramienta denominada TED2, la cual es un entorno de visualización de los diagramas de secuencias. Para recolectar dicha información se lleva a cabo un proceso de instrumentación al código fuente, siendo el usuario quien proporciona dicha información. La instrumentación consiste en agregar código adicional al original, para

1 DYNO Dynamic Objects - Objetos dinámicos 2 TED Tool Enviroment Design - Herramienta de entorno de diseño


5

que permita obtener información de los objetos en tiempo de ejecución. La información recolectada incluye lo siguiente:

• Número de orden de la acción. • El tipo de acción.

o Inicialización. o Creación de un objeto. o Destrucción de un objeto. o Inicio de un método. o Finalización de un método.

• Número de identificador que permita saber quien inicio un método. • Número de objeto. • Nombre de la clase.

Una vez instrumentado el código de interés nuevamente se compila y se ejecuta el sistema para que se genere un archivo de trazos que contenga la secuencia exacta de ejecución de los objetos, el código es convertido a formato del archivo de entrada de la herramienta TED y podrá ser visualizado en diagramas de secuencias.

2.1.2. Artículos Towards the Reverse Engineering of UML Sequence Diagrams [14] Autores: L.C. Briand, Y. Labiche, Y. Miao; Técnica utilizada: Análisis dinámico Esta investigación fue realizada en febrero de 2003 en los laboratorios de ingeniería de calidad de software de la Universidad de Carleton, Ottawa, Ontario, Canadá. Los autores definen y proponen un método de ingeniería inversa a partir de trazos de ejecución de un sistema escrito en C++. Básicamente su trabajo consiste en cómo recuperar información relevante que incluya condiciones, mensajes de interacción y las identidades de los objetos específicos y tipos involucrados en las interacciones.

En el artículo se habla de instrumentar el código fuente y ejecutar el sistema para producir diagramas de escenarios, básicamente es introducir código en ciertas partes del programa para poder generar información relevante y necesaria en forma de archivo de trazos de ejecución para los diagramas de secuencias. El principal desafío viene del hecho que los trazos no conducen exactamente a un diagrama de escenarios. Por lo que para tratar esto, se proponen dos metamodelos: trazos y diagrama de escenarios. Definiendo reglas de mapeo entre ambos metamodelos usando el OCL3. Estas reglas son usadas como especificaciones para implementar una herramienta que permita leer los trazos y convertirlos a diagramas de escenarios. Los autores mencionan que UML puede representar varios escenarios correspondientes a las posibles ejecuciones de un caso de uso, cabe mencionar que el diagrama de escenarios es un diagrama instanciado de un diagrama de secuencias. Reverse Engineering of the Interaction Diagrams from C++ Code [15] Autores: Paolo Tonella y Alessandra Potrich; Técnica utilizada: Análisis estático Esta publicación de septiembre de 2003 fue desarrollada en el Centro de Investigación Científico y Tecnológico del Instituto Cultural Trentino en Italia. Este trabajo lleva a cabo el proceso de ingeniería inversa a partir de una técnica para la extracción automática de diagramas de interacción de UML desde código C++. El algoritmo esta basado en análisis estático de flujo que se aproxime al comportamiento del sistema en cualquier ejecución y en cualquier posible entrada. La recuperación estática de las

3 OCL Object Constraint Lenguaje - Lenguaje de restricción de objetos


6

interacciones entre los objetos es realizada en dos pasos: localizar los objetos creados por el programa e inferir el acceso a través de variables en el código. La aproximación de los objetos creados por el programa y su mutuas relaciones puede ser obtenida llevando a cabo un análisis de flujo de propagación dentro de un diagrama de flujo de objetos (OFG Object Flow Graph), dicho diagrama es capaz de mantener información acerca de la manera en cómo los objetos fluyen dentro del programa por medio de las asignaciones, paso por parámetros, los destinos de las llamadas a funciones a otros objetos, a si mismos y los retornos. Una vez que se conoce el flujo de objetos sobre el programa, los autores proponen un algoritmo que resuelva llamadas a partir de este diagrama y que devuelva una tabla de llamadas de los métodos (origen y destino de las llamadas), los datos recolectados ayudan a construir los diagramas de colaboración y de secuencias. Los autores proponen otro algoritmo para el análisis de sistemas incompletos, es decir, con sistemas donde solamente se disponga de partes. Por último, cabe destacar que los autores mencionan ciertas ventajas del análisis estático sobre el dinámico y que son las siguientes:

• En el análisis dinámico se requiere el sistema completo, se necesita rastrear las direcciones físicas de los objetos creados, se necesita guardar en un archivo los métodos despachados y el diagrama resultante solamente describe una única ejecución por lo que sus resultados son parciales.

• El análisis estático puede trabajar con sistemas completos e incompletos, generar diagramas más generales y producir resultados que son válidos para todas las ejecuciones y para todas las entradas.

Control Flow Analysis for Reverse Engineering of Sequence Diagrams [16] Autores: Atanas Rountev, Olga Volgin y Miriam Reddoch; Técnica utilizada: Análisis estático Esta publicación de marzo de 2004 fue desarrollada por el departamento de Ingeniería y Ciencias de la Computación en la Universidad del Estado de Ohio en Estados Unidos. Aplican ingeniería inversa sobre código Java, enfocándose solamente al flujo de control de los métodos y llevan a cabo su traducción a sus correspondientes primitivas de flujo de control de los diagramas de secuencias, introduciendo a la nueva generación de UML 2.x. Los autores presentan un algoritmo que lleva a cabo dicha equivalencia, además, en caso de que estos sean demasiados grandes proponen la transformación de los diagramas de secuencias. Realizan pruebas basadas en una herramienta denominada RED (Reverse Engineering of Sequence Diagrams), y discuten su uso y evaluación sobre una herramienta de código abierto llamado Mauve que es una suite de pruebas para la librería estándar de Java. El uso de código Mauve cubre diferentes aspectos del flujo de control de interacciones entre objetos y proporcionan una visión acerca de posibles debilidades de las pruebas. El estudio contribuye a los siguientes puntos:

• Algoritmo de mapeo entre el flujo de control de un método y las primitivas de flujo de control de los diagramas de secuencias de UML.

• Varias transformaciones de los diagramas de secuencias para mejorar la estructura de los diagramas de secuencias resultantes.

• Una evaluación experimental del flujo de control y los diagramas de transformación.

• Una prueba de alcance de la herramienta sobre los diagramas de secuencias y un estudio preliminar sobre el código de la herramienta Mauve.


7

2.1.3. Herramientas LogSequencer [17] Técnicas utilizadas: Instrumentación de código, generación de archivo de trazos y análisis dinámico. Herramienta desarrollada en Java por Gerhard Engel que lee archivos lógicos o trazos de ejecución para generar diagramas de secuencias (Ver Figura 3). Para generar estos archivos lógicos la herramienta se apoya en el compilador AspectJ de Java, el cual instrumenta el código automáticamente para obtener información necesaria para la graficación de los diagramas de secuencias; el registro de información que obtiene, contiene nombre de la clase, nombre del método, acciones cuando el método inicia o termina. A continuación se muestra el siguiente ejemplo de instrumentación:

protected boolean addOrderItem(OrderItem oi) { if (m_isLogging) log("Order", "addOrderItem()", "Begin"); // method logic if (m_isLogging) log("Order", "addOrderItem()", "End"); return true; }

Teniendo el código escrito, este se compila y se ejecuta para que se genere información de registros en tiempo de ejecución, para que posteriormente la herramienta LogSequencer lea y genere los diagramas de secuencias. El proceso de su funcionamiento se muestra en la ilustración siguiente y para mayor detalle véase Anexo A.

Figura 3 Funcionamiento de la herramienta LogSequencer

Las características y funcionalidades de esta herramienta son: • Genera diagrama de secuencias desde un archivo lógico o de trazos. • Guarda los diagramas de secuencias como archivo XML. • Abre un diagrama de secuencias desde un archivo XML y lo despliega • Guarda el diagrama de secuencias como archivo JPG. • Guarda cada diagramas de secuencias por archivos JPG separados • Imprime el diagrama de secuencias.

j2u [18] Técnicas utilizadas: Instrumentación de bytecode, generación de archivo de trazos y análisis dinámico. Herramienta desarrollada en el año 2002 por Nasra Consulting en París, Francia. Realiza ingeniería inversa dinámica sobre el bytecode de aplicaciones en Java. Su funcionamiento se basa en la generación de archivos de trazos a partir de las clases compiladas y, a partir de los trazos se generan archivos HTML o en su defecto en archivo XMI4 (Ver Figura 4) para poder ser importado por otras herramientas. Los pasos necesarios para su funcionamiento son los siguientes:

1. Prepara la aplicación (applets, aplicaciones Java Web, J2EE…). Acceso a la red si es posible.

2. La aplicación j2u hace uso de un archivo de trazos y es alimentado automáticamente con cada evento.

3. Puede usar archivos XMI (Puede exportarse a Rose o Together) o HTML para ser visualizado en un navegador

4 Es un estándar para el intercambio de modelos UML entre herramientas (XML Interchange)


8

Figura 4 Funcionamiento de j2u

La herramienta j2u puede ser utilizada para: • Documentación que se ignora de las aplicaciones: La herramienta j2u toma el

bytecode de entrada, éste puede crear los diagramas UML de una aplicación que aún no tiene.

• Mejora la calidad de la documentación: Puede crear una fiable y consistente documentación para todas las aplicaciones Java.

• Actualización de las aplicaciones: en los ciclos de desarrollo iterativo, el modelo deber ser actualizado desde el código con J2u.

Para mayor detalle de la aplicación ver Anexo B.

CodeLogic [19] Técnica utilizada: Análisis estático Herramienta desarrollada en el año 2004 por la empresa Logic Explorers Inc. en Philadelphia y Boston en Estados Unidos. Permite generar diagramas de clases, de secuencias y de flujo de ejecución de programas desarrollados en Java y C#. Realiza un análisis estático del código para descubrir y representar gráficamente la profundidad interna lógica del código, realiza un análisis por módulo resolviendo nombres de variables, reconoce tipos de conversión, procesos de funciones virtuales, hasta una completa ruta de ejecución. CodeLogic está diseñado para operar como una aplicación autónoma o un añadido a un programa que funciona en entornos integrados de desarrollo (por ejemplo: JBuilder, JDeveloper, Visual Studio .NET, etc). Sus características son las siguientes:

• Interacción dinámica de modelo y código. • Generación automática de diagramas UML. • Navegador lógico. • Exportación de los diagramas a Microsoft Visio & IBM Rational Rose. • Incluye filtros. • Facilidades de acercamiento y alejamiento de los diagramas. Para más detalles de su funcionamiento ver Anexo C y D.

Together Technologies [20]

Técnica utilizada: Análisis estático Herramienta desarrollada por compañía Borland en el año 2003. Obtiene directamente de los métodos de las clases diagramas de secuencia a partir de código Java y C++. Además la herramienta ofrece búsqueda de métodos y uso de métricas para determinar los métodos más complejos a través de la métrica de complejidad, entre otros.

Los desarrolladores se enfocaron a las necesidades que tienen los usuarios para cuando quieren generar rápidamente diagramas de secuencias y observar cómo trabaja el sistema. Para reducir los diagramas plantean varias soluciones, una de ellas es


9

establecer el límite de profundidad de anidamiento de las llamadas (Ver Anexo E), por ejemplo: si un método A llama a B y este su vez llama a C. El nivel uno del diagrama se limitaría a las llamada que produce A hasta B solamente; si el nivel es a dos, se limitaría el diagrama en mostrar las llamadas de métodos A, B y C y así sucesivamente. Otras de las opciones de la herramienta es que el usuario a través de su experiencia establezca manualmente qué clases son de su importancia de acuerdo al dominio del problema y cuales se requieran ser visualizadas, e incluso, establecer si se requiere el detalle de implementación del método como el flujo de control.

2.1.4. Análisis de los trabajos relacionados Son varias las características de los diagramas de secuencias que ofrecen las herramientas comerciales [17, 18, 19, 20] y trabajos relacionados [13, 14, 15, 16] y pocas las estrategias para llevar a cabo ingeniería inversa. Las diferencias son resumidas en la Tabla 1 y comparadas de acuerdo a siete criterios:

- Formato de los diagramas: es ampliamente utilizado con estructuras propias del visualizador o formato de imagen como JPG, y reducido el número que utiliza para el formato de intercambio del estándar XMI 1.x y casi nulo para XMI 2.x

- Lenguaje de programación: el lenguaje analizado es mayor para Java y menor para C++ y C#.

- Versión del los diagramas de secuencias: son en su mayoría de la versión 1.x de UML y poco de la versión actual 2.x

- Estrategia de recuperación: La recuperación de información desde el código se lleva a cabo mediante instrumentación del código para el análisis dinámico de un sistema completo y mediante técnicas de compiladores para el análisis estático para sistemas completos e incompletos.

- Estrategias de reducción: En la reducción de los diagramas son pocos los que utilizan filtros por clases y nivel de anidamiento en las llamadas para un método en particular. En la herramienta comercial [19] se realiza una reducción especial sobre los mensajes que se repiten.

- Estrategia de traducción: La opción de utilizar los metamodelos en la traducción del código a diagramas de secuencias son escasas. Sólo un trabajo [14] utiliza un metamodelo de trazos de ejecución para realizar el análisis dinámico y el resto de los trabajos no utilizan metamodelos para la traducción o simplemente no lo mencionan.

- Visualización del flujo de control: El flujo de control de un método es posible expresarlo sobre los diagramas de secuencias, los estudios para la versión de UML 2.x son escasos y en algunos casos son propuestos por Together [20] para la versión de UML 1.x.

Esto sugiere que para llevar a cabo ingeniería inversa de los diagramas de

secuencias de un sistema, se deberá llevarlo a cabo cubriendo lo siguiente: (1) Obtener el diagrama tanto de un sistema completo como incompleto, actual o pasado. (2) Deberán obtenerse los diagramas de acuerdo a las necesidades de los usuarios, donde les permita seleccionar las clases y métodos que le interesan y que ayuden a reducir la complejidad de los diagramas.


10

Tesis Artículos Herramientas comerciales Tesis Características

[13] [14] [15] [16] [17] [18] [19] [20]

Tipo análisis Din Din Est Est Din Din Est Est Est

Análisis del flujo de control

X X X

Formato del diagrama

XMI 1.x

XML JPG

XMI 1.x JPG

Su propio formato

Su propio formato y XMI 1.x

Su propio formato

Lenguaje C++ C++ C++ Java Java Java Java/C# Java/C++ C++

Modo de reducción de

los diagramas

Método

Método, Filtro de clases, y

resumen de llamadas

Método, filtro de clases, y nivel de

anidamiento de llamadas

Método, filtro de clases, y nivel de

anidamiento de llamadas

Versión de UML

1.x 1.x 1.x 2.x 1.x 1.x 1.x 1.x 1.x

Metamodelo Trace Código

Mapeo entre metamodelos

OCL Algoritmo

Tabla 1 Trabajos relacionados

2.2. Planteamiento del problema

Los desarrolladores de software invierten mucho tiempo y dedicación en comprender el comportamiento dinámico de un sistema de software elaborado por otras personas. En un intento por entender un sistema ellos invierten muchas horas leyendo código del cual no disponen documentación o diseño alguno. Además las herramientas actuales se enfocaron a la obtención de los diagramas de secuencias a partir del análisis del código produciendo diagramas demasiado extensos tanto en lo vertical como en lo horizontal, lo cual dificulta la legibilidad y compresión, por lo que es necesario contar con una herramienta que facilite o que permita hacer cortes lógicos y razonables en ambas direcciones para que ayude a los ingenieros de software entender el comportamiento dinámico de un sistema.

2.2.1. Objetivo Los objetivos de esta tesis son:

• Diseñar un algoritmo de recuperación de diagramas de secuencias • Diseñar y construir una herramienta de ingeniería inversa que permita recuperar

los diagramas de secuencias a partir del código escrito en C++

2.2.2. Pregunta de la investigación Una de las preguntas fundamentales que se plantea este trabajo de investigación es: ¿Existirá alguna forma de modelar el código fuente que ayude a representar un

programa orientado a objetos, para ser utilizado y llevar a cabo ingeniería inversa

para la obtención de diagramas de UML? La pregunta va mas allá de la utilidad de los diagramas obtenidos o de saber cuáles son las formas de reducción de diagramas o de qué técnicas existen para la recuperación de información del código. La pregunta plantea la posibilidad de representar el código fuente de un programa orientado a objetos como un modelo para el análisis y tratamiento en la obtención de diagramas de UML.


11

2.2.3. Justificación Para la mayoría de los ingenieros de software, analizar, diseñar y desarrollar software constituyen sus principales actividades, pero en ocasiones es necesario reconstruir software existente que no fue desarrollado por ellos, para esto, el ingeniero de software requiere de herramientas de ingeniería inversa que le ayuden a entender el sistema desde el punto de vista estructural (estático) y de comportamiento (dinámico). Actualmente son pocas las herramientas comerciales que llevan a cabo ingeniería inversa para obtener los diagramas de secuencias (vista dinámica) partiendo de código escrito en C++ (Véase Tabla 1 Trabajos relacionados) ya que la mayoría se enfocan en trabajar con el lenguaje Java; además, están muy sujetas al ambiente propio de desarrollo lo que no las hace independientes.

2.2.3.1. Criterios y beneficios de la investigación

• Conveniente: ¿Qué tan conveniente es la investigación?; esto es, ¿para qué sirve? Sirve para documentar sistemas orientados a objetos con o sin documentación existente.

• Relevancia social: o Empresas y desarrolladores de software.

� Reducir costos en el mantenimiento de software. � Reducir el esfuerzo y la inversión de tiempo en el entendimiento

de software realizado por otras personas. � Mantener la documentación del software actualizado. � Documentar el software con casi o nula documentación realizado

en el pasado. o Docentes y estudiantes.

� Entender y explicar un software implementado en cursos o clases de computación.

• Implicaciones prácticas: Ayudaría a resolver otros problemas de traducción entre lenguajes de programación y diagramas de diseño de software.

• Valor teórico: Ayudará a conocer cuáles son las técnicas para la obtención de información y estrategias de traducción entre modelos.

• Utilidad metodológica: Ayudaría a comprender sobre la utilidad de la modelación de código como opción para analizar los datos de un programa orientado a objetos. Este trabajo realiza esfuerzos para fortalecer una de las líneas de investigación de la ingeniería software [22], que esta dedicada a la ingeniería inversa y en este caso una contribución a nuestro país [23].

2.2.4. Complejidad técnica en la solución del problema La dificultad radica en lo siguiente:

• Reconocimiento léxico y sintáctico de las interacciones entre los objetos del código escrito en C++ y cuya gramática es extensa.

• Conversión de las instrucciones sintácticas textuales a instrucciones sintácticas en lenguaje visual, es decir determinar las equivalencias del texto escrito a diagrama.

• Al obtener diagramas de secuencias extensos, encontrar en el código alguna propiedad o característica que permitan obtener un nivel de abstracción más alto que el código, además de la partición de los diagramas.


12

Nota: Puede consultar la sección “Ingeniería inversa de los diagramas de secuencias” dentro del capitulo posterior, donde los autores de UML hacen mención de tal complejidad.

2.3. Hipótesis

Dado un programa completo escrito en lenguaje C++ que estando libre de errores sintácticos, es posible crear un metamodelo que ayude a determinar las interacciones que se dan entre los objetos creados en el programa y ser visualizadas en un diagrama de secuencias.

2.4. Alcances y limitaciones

Alcances • Desarrollo de la interfaz en Visual C++ (ALTA). • Integración de la herramienta con la suite Cenidet-UML (ALTA). • Reconocedor de interacciones (ALTA). • Particionador de diagramas (ALTA). • Elaborar la arquitectura del sistema (ALTA). • Visualización de los diagramas de secuencia en pantalla (ALTA). • Guardar las propiedades o características de los diagramas de secuencias

(BAJA). • Guardar en formato de diagrama de secuencias (MEDIA). • Permitir la impresión del diagrama (BAJA). • Diseño del archivo de ayuda (BAJA).

Limitaciones • No detecta errores de compilación en el código por lo que deberá estar

compilado correctamente el código. • La herramienta no trabajará en red. • No se modificarán los archivos de las demás herramientas que conforman

Mango. • No se utilizará toda la gramática de C++, solamente aquellas características que

nos ayuden a representar los diagramas de secuencias. • No calculará métricas.

«Nuestras dudas son traidoras, y por ellas perdemos el bien que con frecuencia pudimos ganar,

por miedo a intentarlo»

William Shakespeare

3. Marco conceptual

ara mayor claridad sobre esta tesis, es necesario conocer algunos conceptos que están muy ligados al tema y son: reingeniería, mantenimiento, ingeniería inversa, lenguaje unificado de modelado, diagramas de secuencias entre otros.

3.1. Ingeniería en Software

3.1.1. Reingeniería La definición dada por el Reengineering Center del Software Engineering Institute de la Universidad Carnegie Mellon es [24]

“Reingeniería es la transformación sistemática de un sistema existente a una

nueva forma para realizar mejoras de la calidad en operación, capacidad del

sistema, funcionalidad, rendimiento o capacidad de evolución a bajo coste, con

un plan de desarrollo corto y con bajo riesgo para el cliente”.

En esta definición se enfatiza el hecho de que la reingeniería es la mejora de sistemas existentes, de modo que la inversión resulte muy rentable y que, de todas formas, dicha mejora podría ser obtenida a través de un nuevo desarrollo. Si la reingeniería no tiene un costo bajo, no está acabada en poco tiempo, no tiene poco riesgo o no ofrece un valor añadido para el cliente, hay que considerar la posibilidad de un nuevo desarrollo.

3.1.2. Mantenimiento Históricamente el mantenimiento se puede considerar como la primera forma de evolución de los sistemas. La mayoría de las empresas que realizaron sus grandes desarrollos hace 25 años necesitan revisar si la aplicación sigue resultando efectiva. Las definiciones de mantenimiento de estándares internacionales [24] son las siguientes: El ANSI/IEE da la siguiente definición de mantenimiento:

Son las modificaciones de los productos software después de su entrega para

corregir fallos, mejorar rendimiento u otros atributos o adaptar el producto a

un cambio de entorno.

Una definición similar es dada por ISO/IEC5: Un producto software soporta una modificación en el código y su

documentación asociada para la solución de un problema o por la necesidad de

5 ISO Organización Internacional para la Estandarización e IEC Comisión Electrotécnico Internacional

Capítulo

3

P

Capítulo 3. Marco conceptual

14

una mejora. Su objetivo es mejorar el software existente manteniendo su

integridad.

El mantenimiento representa el porcentaje más alto costo de todo el ciclo de vida de un sistema; Lientz y Swanson proponen dividir en cuatro los tipos de mantenimiento:

• Adaptativo para ajustar el software a un cambio de entorno.

• Perfectivo para suplir nuevos requerimientos.

• Correctivo para solucionar errores puntuales de programas.

• Preventivo para prever la aparición de problemas.

Según el estudio de Lientz y Swanson, los dos primeros consumen el 75% de los

recursos y el correctivo el 21%. Otros estudios proporcionan resultados similares. Todos muestran que es la incorporación de nuevos requerimientos de usuario la causa principal de la evolución y el mantenimiento del software.

3.1.3. Reingeniería o modernización Posterior a las técnicas de microevolución del mantenimiento, las cuales tienden a moverse a los niveles de abstracción más bajos del sistema, surge la reingeniería para cubrir la necesidad de una evolución más amplia del sistema. La reingeniería trabaja todos los niveles de abstracción (desde la implementación hasta el diseño), con el propósito de conseguir realizar cambios más drásticos preservando los valores de negocio del sistema.

La reingeniería de sistemas puede clasificarse según los niveles de conocimientos requeridos. La reingeniería que requiere conocimientos a bajos niveles de abstracción (código fuente) se llama ingeniería inversa o modernización de caja blanca. Aquella que sólo requiere el conocimiento de las interfaces del sistema se llama reingeniería propiamente dicha o modernización de caja negra [24].

3.1.4. Ingeniería inversa Chikofski ofrece la siguiente definición [25] de ingeniería inversa: “Ingeniería inversa es el proceso de analizar un sistema sujeto a estudio para:

1. Identificar los componentes del sistema y sus interrelaciones; y,

2. Crear representaciones del sistema con otra forma o con un mayor nivel de

abstracción”

Por su parte, Pressman asienta que la Ingeniería inversa es: “…el proceso que consiste en analizar un programa con uno o varios 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 diseño de procedimientos de un programa ya existente” [1]. Al revisar estas dos definiciones podemos encontrar similitudes; ambas hablan

de: “un proceso que analiza software para identificar o extraer abstracciones de mayor nivel”; aunque la definición de Pressman introduce el elemento herramienta [7].

La ingeniería inversa en sí no involucra cambios en el sistema sujeto. Es un proceso de examinación, no hace ningún cambio o réplica.


15

3.1.4.1. Objetivos

¿Qué estamos nosotros tratando de hacer al llevar a cabo un trabajo con la ingeniería inversa? [5]

El primer propósito de la ingeniería inversa en un sistema de software es incrementar la compresión global del sistema para el mantenimiento y nuevos desarrollos. Más allá de estas definiciones, estos son los seis objetivos clave que guiará su dirección de cómo la tecnología madura:

• Hacer frente a la complejidad. • Generar vistas alternativas. • Recuperar información perdida. • Descubrir efectos colaterales. • Sintetizar abstracciones más altas. • Facilitar el reuso.

3.1.4.2. Recuperación de diseño

La recuperación de diseños de un sistema, es un subconjunto de la ingeniería inversa en donde se agrega información externa, conocimientos del dominio y deducciones o razonamientos difusos al entendimiento de un sistema de software, con el fin de identificar abstracciones de alto nivel más significativas que aquellas obtenidas de examinar directamente el sistema por si solo [25]. La recuperación según Ted Biggerstaff:

"...La recuperación de diseños 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 lo 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"

3.1.4.3. Aspecto económico

Los costos para entender el software son raramente considerados como un costo directo. Es más bien el tiempo requerido para comprender el software, el cual incluye el tiempo perdido por equivocaciones. La ingeniería inversa reduce el tiempo requerido para alcanzar la esencia del software en cada fase de ciclo de vida, pudiendo reducir también el costo promedio del software [25]. Algo importante y que es de gran utilidad en el proceso de ingeniería inversa, es el destino que tendrá el producto obtenido al aplicar el proceso mencionado; una consideración para su representación es el uso de un estándar de modelado, por lo que es adecuado tratar en este marco, el tema del lenguaje estándar de modelado UML (Unified Modeling Language).

3.1.5. Lenguaje Unificado de modelado El Lenguaje Unificado de Modelado es un estándar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software [26].

El lenguaje UML es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones distribuidas basadas en la Web, e incluso para sistemas empotrados de tiempo real muy exigentes. Es un lenguaje muy expresivo, el cual cubre


16

todas las vistas necesarias para desarrollar y luego desplegar tales sistemas. UML no es difícil de aprender ni de utilizar.

3.1.6. Diagramas de interacción Los diagramas de interacción modelan aspectos dinámicos de los sistemas. Esto implica modelar instancias concretas o prototípicas de clases, interfaces componente y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento. Pueden utilizarse para visualizar, especificar, construir y documentar la dinámica de una sociedad particular de objetos, o se pueden utilizar para modelar un flujo de control particular de un caso de uso. Importantes para construir sistemas ejecutables por medio de ingeniería directa e inversa [26].

3.1.7. Diagramas de secuencias Un diagrama que muestra las interacciones de objetos colocados en secuencias de tiempo, en particular, muestra los objetos que participan en la interacción y la secuencia de mensajes intercambiados. Al contrario de un diagrama de colaboración, un diagrama de secuencia incluye secuencia de tiempo pero no incluye relaciones del objeto. Un diagrama de secuencias puede existir de forma genérica (describe todos los posibles escenarios) y en una instancia de un formulario (describe un escenario actual). Los diagramas de secuencia y colaboración expresan información similar, pero lo muestran de diferentes formas [27].

Los autores Martin Fowler y Kendall Scott en su libro dicen: “Los diferentes desarrolladores tienen distintas preferencias cuando se trata de

seleccionar la forma de diagrama de interacción que emplearan. Por lo general,

yo prefiero el diagrama de secuencia, debido a que me gusta el énfasis que pone

en la secuencia; es fácil apreciar el orden en que ocurren las cosas. Otros en

cambio, el diagrama de colaboración, porque pueden usar la distribución para

indicar cómo se conectan estáticamente los objetos”. [28] Hans-Erik Eriksson y Magnus Penker en su libro mencionan sobre el uso de los

diagramas de secuencias: “Los diagramas de secuencias pueden ser usados en dos formas: en una forma

genérica y en forma de instancia de un formulario. La instancia de un

formulario describe un específico escenario en detalle; documenta una posible

interacción. La instancia de un formulario no tiene condiciones, bifurcaciones o

ciclos; muestra la interacción de un escenario escogido. La forma genérica

describe todas las posibles alternativas en un escenario, por lo consiguiente

bifurcaciones, condiciones y ciclos pueden ser incluidos”. [29]

3.1.7.1. Ingeniería inversa de los diagramas de secuencias

La ingeniería inversa es posible aplicarla para obtener los diagramas de secuencias como para los de colaboración, especialmente si el contexto del código es el cuerpo de una operación. La ingeniería directa es inmediata; la ingeniería inversa es difícil. Es fácil obtener un montón de información mediante simple ingeniería inversa, de forma que la parte difícil consiste en ser inteligente para saber qué detalles observar [30].

Sin embargo, más interesante que la ingeniería inversa de un modelo a partir de código, es la animación de un modelo durante la ejecución del sistema desarrollado; una herramienta podría animar los mensajes del diagrama mientras se producen en un sistema en ejecución. Mejor aún, teniendo esta herramienta bajo el control de un depurador, se podría controlar la velocidad de ejecución, introduciendo posiblemente


17

puntos de ruptura para detener la acción en punto de interés, con el fin de examinar los valores de los atributos de objetos individuales.

3.2. Análisis estático contra dinámico

El análisis estático es el proceso de analizar el software sin ejecutarlo. El análisis estático incluye análisis sintáctico, chequeo e inferencia de tipos, análisis de flujo de control, análisis flujo de datos, alcances, medidas de complejidad, llamadas estáticas y análisis estructural [13] (Ver Figura 5). El análisis dinámico es el proceso de analizar el comportamiento de un sistema de software en tiempo de ejecución. Otras diferencias que otros autores mencionan son [2]:

• En el análisis dinámico se requiere el sistema completo, se necesita rastrear las direcciones físicas de los objetos creados, se necesita guardar en un archivo los métodos despachados y el diagrama resultante, solamente describe una única ejecución por lo que sus resultados son parciales.

• El análisis estático puede trabajar con sistemas completos e incompletos, generar diagramas más generales y produce resultados que son válidos para todas las ejecuciones y para todas las entradas.

Figura 5 Análisis estático contra análisis dinámico según Raitalaakso [13]

3.3. ¿Qué es un metamodelo?

El UML es definido dentro de un esquema llamado arquitectura de cuatro capas, las cuales envuelven distintos niveles de abstracción. Cada capa define elementos, conceptos y relaciones entre conceptos, basados en los tipos de elementos de la siguiente capa más general [31]. Las capas se describen a continuación. Un meta-metamodelo es el que define el lenguaje para la siguiente capa, pero: ¿que es el metamodelo? Suena complicado pero la idea es más simple de lo que parece: esta capa consiste de un modelo compacto que sirve de cimentación para el conjunto de la arquitectura. Ver referencia [32]. El metamodelo es una instancia (es decir, una expresión particular) del meta-metamodelo. Esta es la capa donde se define el lenguaje que sirve para especificar los modelos que vamos a crear los usuarios de UML. En otras palabras, el metamodelo sirve para describir los elementos que van a componer nuestros diagramas. Esta capa es


18

propia de UML, y es aquí donde se definen los objetos del lenguaje unificado: Clase, Atributo, TipoDato, etc. De acuerdo a esta arquitectura, cuando los usuarios creamos el objeto Empleado en un diagrama, estamos creando una instancia del metaobjeto Clase; es decir, que estamos usando Clase como si fuera el molde para producir una expresión concreta (con características propias) llamada Empleado. De igual forma, si al objeto Empleado le añadimos el atributo Categoría, en realidad estamos instanciando la metaclase Atributo. El modelo es una instancia del metamodelo, y es lo que los usuarios de UML vamos a crear. Cuando creamos un modelo estamos definiendo un lenguaje para describir el área que estamos analizando o el sistema que estamos diseñando. Cuando creamos los objetos Empleado, Departamento y Categoría estamos creando objetos que pertenecen a esta capa, y que servirán a su vez de moldes para los datos que vamos a introducir, manipular, almacenar y procesar en nuestras aplicaciones. Los objetos del usuario (o, si así queremos llamarlos, los datos del usuario) son los datos y objetos que describen el área o dominio a los que está dedicada la aplicación. Por ejemplo, los nombres y características de personas almacenados en el objeto Empleado son elementos de esta capa.

«Si se les da tarea de describir una interacción entre un gato y un perro, podrá hacer anotaciones como: “el gato escupe… el perro muestra los dientes… el gato arquea su

espalda… el perro ladra… el gato…”. Tan importante como las acciones particulares

descritas en la secuencia en la que ocurren y, en alguna medida, cualquier conducta

del gato se hace comprensible únicamente en el contexto de la conducta del perro.» Programación Neuro-Lingüística: De sapos a príncipes

John Grinder y Richard Bandler, 1980

4. Método de solución

a estrategia de solución para la ingeniería inversa de los diagramas de secuencias consiste en la modelación del código fuente, tal como un metamodelo capaz de representar un programa orientado a objetos. La traducción a diagramas de

secuencias esta basada en la sintaxis del código, de la cual se extrae información tales como los nombres de las clases, objetos, funciones y llamadas, que son almacenados en el metamodelo. Un visualizador [3] desarrollado en anteriores trabajos, es utilizado como modelo de diagrama de secuencias, este determina la información o elementos que se requiere para construir un diagrama tales como: las clases y mensajes. Una vez recuperada la información y colocada sobre el metamodelo, se transforma a un diagrama de secuencias por medio de algoritmos de conversión, los cuales respetan las restricciones impuestas entre el metamodelo del programa y el diagrama de secuencias. Estos algoritmos tienen la capacidad de reducir los diagramas obtenidos, ya sea por método, clases o niveles de profundidad de llamadas que se realizan entre las clases. El modelo conceptual del método de solución es mostrado en la Figura 6. Para este trabajo los archivos de entrada de código fuente están escritos en lenguaje de programación C++, posteriormente un analizador sintáctico extrae la información de esos archivos y la interpreta para luego ser depositada en el metamodelo del programa orientado a objetos, después un algoritmo o programa de conversión realiza un tratamiento del modelo obtenido, que ayuda a construir, visualizar y reducir los diagramas de secuencias correspondientes al programa de entrada.

La implementación del traductor, del metamodelo y los algoritmos de conversión se hicieron en C++. El analizador sintáctico fue hecho con la ayuda de un generador de analizadores llamado Antlr [33] usando la gramática de C++. La construcción y visualización de los diagramas de secuencias hicieron uso de las librerías de las MFC (Microsoft Foundation Classes).

El corazón de esta investigación es el metamodelo de código para programas orientados a objetos tales como los escritos en C++ y los algoritmos de conversión hacia diagramas de secuencias.

Capítulo

4

L

Capítulo 4. Método de solución

20

Figura 6 Modelo conceptual del método de solución

4.1. Metamodelo del diagrama de secuencias

Un diagrama de secuencias es un diagrama de interacción que resalta el orden temporal de los mensajes. Un diagrama de secuencia presenta un conjunto de objetos y los mensajes enviados y recibidos por ellos. Los objetos suelen ser instancias (con nombre o sin nombres) de clases, pero también pueden representar instancias de otros elementos, tales como colaboraciones, componentes y nodos [29].

Según la definición anterior, el diagrama de secuencias hace énfasis sobre la ordenación temporal de los mensajes, por lo que ésta deberá ser tomada en cuenta como una restricción. Ésta regla es importante en el metamodelo de código fuente propuesto aquí, ya que deberá almacenar de forma ordenada las llamadas que se realizan dentro de cada función dentro del código.

Figura 7 Metamodelo de un diagrama de secuencias según Macías Alonso

El metamodelo desarrollado por Macias Alonso [3] es retomado en este trabajo para lograr visualizar los diagramas de secuencias. En la Figura 7 se muestra en


21

estructura de clases que representa un diagrama de secuencias y un ejemplo en la Figura 8. Un diagrama de secuencias (clase CDiagramaDS) es un elemento gráfico que puede estar compuesto por objetos/clases (clase CObjetoDS), mensajes (clase CMensajeDS) o mensajes recursivos o llamadas así mismo (CRecursividadDS). Cabe destacar que la clase mensaje (CMensajeDS) contiene atributos para especificar, el objeto/clase de origen y destino, así como un nombre del mensaje.

Figura 8 Ejemplar de un diagrama de secuencias de las herramienta Scuml

En resumen, el metamodelo para el diagrama de secuencias requiere la siguiente información para construirlo: nombre de las clases que intervienen en una interacción, nombres de los mensajes que se llevan a cabo como llamadas simples o llamadas hacia la misma clase, todas de manera ordenada. Información que deberá ser obtenida del metamodelo del programa orientado a objetos del código fuente en C++.

4.2. Traductor y el metamodelo de un programa orientado a objetos

El traductor extrae, resuelve referencias e interpreta información del código para el diagrama de secuencias, durante el análisis sintáctico; el diagrama de secuencias requiere información de clases y mensajes. El traductor extrae información desde el código referente a: clases y funciones declaradas, creación de objetos y llamadas a funciones que pertenecen a algún tipo de clase. El traductor interpreta la información extraída en base a equivalencias en la Tabla 2 y almacenada en un archivo con lo siguiente:

• Nombres de clases: identificador único o nombre de la clase. Ej. #DefClase ClaseA

• Nombres de objetos: identificador o nombre del objeto, clase al que pertenece y número de secuencia. El número de secuencia es cero cuando el objeto es atributo de la clase, parámetro de una función o fue definido a nivel del archivo y mayor a cero cuando el objeto fue definido dentro de una función de acuerdo al orden de aparición en el código. Ej. #Objeto objeto #DefClase ClaseA #Num 2

• Nombres de funciones: identificador o nombre de la función. Ej. #DefFuncion ClaseA::procesar

• Nombres de llamadas: identificador o nombre de la llamada a una función, clase a la cual pertenece y un número de secuencia que es mayor a cero de acuerdo al orden de aparición en el código. Ej. #Llamada metodo #DefClase ClaseB #Num 1


22

• Nombre del proyecto: Nombre genérico de la traducción. Ej. #Proyecto llamada

• Nombre del archivo: Nombre y ruta del archivo al que se realiza la traducción. Ej. #Archivo C:\AreaTrabajo\llamadaSimple.cpp

Código en C++ Diagrama de secuencias

Creación de objetos ClaseA objeto; ClaseA *objeto = new ClaseA(); //En otro caso, como parámetro void ClaseB::procesar(ClaseA objeto){}

: ClaseA

#Objeto objeto #DefClase ClaseA #Num 1 //En otro caso, como parámetro #DefFuncion ClaseB::procesar #Objeto objeto #DefClase ClaseA #Num 0

Mensajes

void ClaseA::procesar(void) { objetoB->metodo(); } void ClaseA::procesar(void) { objetoB::metodo(); } void ClaseA::procesar(void) { objetoB.metodo(); }

: ClaseA : ClaseB

metodo()

#DefFuncion ClaseA::procesar #Llamada metodo #DefClase ClaseB #Num 1

Mensaje de creación

void ClaseA::procesar(void) { ClaseB objetoB; ClaseC objetoC;

} void ClaseA::procesar(void) { ClaseB *objetoB = new ClaseB(); ClaseC *objetoC = new ClaseC();

}

: ClaseA : ClaseB : ClaseC

<<create>>

<<create>>

#DefFuncion ClaseA::procesar #Objeto objetoB #DefClase ClaseB #Num 1 #Objeto objetoC #DefClase ClaseC #Num 2

Recursividad y llamadas hacia la misma clase

//Se crea en algún lado ClaseA *objetoA = new ClaseA(); void ClaseA::more(void) { if (x < 0) objetoA->more(); } void ClaseA::more(void) { if (x < 0) more(); }

: ClaseA

more( )

#Objeto objetoA #DefClase ClaseA #Num 0 #DefFuncion ClaseA::more #Llamada more #DefClase ClaseA #Num 1

Tabla 2 Tabla de equivalencias entre el código C++ y el diagrama de secuencias

El traductor resuelve referencias de objetos. Como es el caso de las llamadas donde es requerida saber a qué clase pertenece, simplemente con sólo identificar el


23

objeto que le antecede y en casos más difíciles cuya referencia sólo es resuelta al final del análisis. Por ejemplo:

void ClaseA::procesar(void) { ClaseB *objetoB = new ClaseB();

objetoB->metodo(); }

¿A qué clase pertenece la llamada metodo()? Respuesta: la llamada metodo() pertenece a la clase ClaseB, debido a que el

objeto que lo invoca (objetoB) fue definido en una línea anterior cuyo tipo fue ClaseB. En casos más difíciles cuyo nombre de objeto fue declarado fuera de la función,

es decir, definido como miembro de una clase, como en el siguiente ejemplo: class ClaseA { public: void procesar(void);

ClaseB *objetoB;

}; void ClaseA::procesar(void) {

objetoB->metodo();

}

De nuevo la pregunta ¿A qué clase pertenece la llamada metodo()? Respuesta: la llamada metodo() pertenece a la clase claseB, debido a que el

objeto que lo invoca (objetoB) fue definido como miembro de la clase. Otro problema de referencias son aquellas llamadas a funciones a las cuales no

les antecede ningún objeto, como en el siguiente ejemplo: class ClaseA { public:

void procesar(void); void metodo(void);

}; void ClaseA::procesar(void) {

metodo();

} void ClaseA::metodo(void) {

//Realiza algo

}

Para este caso se intenta resolver el problema suponiendo que la llamada metodo() pertenece al mismo tipo que la función ClaseA::procesar(), es decir, de ClaseA. Por lo que ahora se realiza la búsqueda de esa función metodo() como ClaseA::metodo, tomando como punto de referencia el ámbito de la función ClaseA::procesar(void). En caso de no ser resuelta la referencia de la llamada, simplemente se ignora y se pasa a la siguiente llamada; debido a que C++ permite ese tipo de invocaciones a funciones que no necesariamente pertenecen a una clase u objeto.


24

Figura 9 Metamodelo de un programa orientado a objetos

Cuando el análisis del programa ha finalizado, entonces se ha creado una

instancia del metamodelo de la Figura 9 que representa el código fuente del programa que se analiza. El metamodelo se lee de la siguiente manera: Un proyecto (clase Proyecto) contiene cero o más archivos (clase Archivo), en un archivo (clase Archivo) se declaran cero o más funciones (clase DefFunción); en un archivo (clase Archivo) se definen cero o más objetos (clase Objeto) y de igual manera en un archivo (clase Archivo) se declaran cero o más clases (clase DefClase). Ahora bien, dentro de una función (clase DefFunción) se declaran cero o más objetos (clase Objeto) con la restricción de Ordenado, esto significa que cada objeto creado dentro de una función deberá incluir un número de secuencia en correspondencia al orden en que aparece en el código. De igual manera sucede con respecto a las llamadas; dentro de una función (clase DefFunción) se realizan cero o más llamadas ordenadas (clase Llamada), con la misma restricción que los objetos. El corazón de toda interacción son las llamadas a funciones; una o más llamadas (clase Llamada) pertenecen a una clase (clase DefClase). La relación de cardinalidad entre llamadas (clase Llamada) y clases (clase DefClase) es de muchos a uno, lo que significa que varias llamadas pertenecen a una sola clase y no a varias a la vez. Otro componente importante en un programa son los objetos (clase Objeto), el cual uno o más objetos pertenecen a una sola clase (clase DefClase), es decir, la relación de cardinalidad entre objetos y clases es de muchos a uno, lo que significa que varios objetos pertenecen a una sola clase y no a varias a la vez. Las clases (clase DefClase) son también importantes en el modelo debido a que una clase puede componerse de cero o más objetos (clase Objeto), es el caso de objetos miembros de una clase. De igual manera en una clase (clase DefClase) se declaran cero o más funciones dentro de ella (clase DefFuncion).


25

Un ejemplar del metamodelo anterior es mostrado en la figura de la Tabla 3. En él se muestra una instancia del metamodelo de código fuente de programa en C++ escrito en el lado derecho, así como un archivo de traducción equivalente al modelo obtenido.

Tabla 3 Ejemplar del metamodelo de un programa orientado a objeto escrito en C++

En el ejemplar del metamodelo se muestran dos instancias que son: el proyecto (clase Proyecto) cuyo nombre es llamada y un archivo (clase Archivo) cuyo nombre es c:\AreaTrabajo\metaDemo.cpp. Posteriormente, las demás instancias debajo del archivo son agregadas conforme se recorre el programa. A continuación se explica la acción que lleva a cabo el traductor en su recorrido por el programa.

Ejemplar del metamodelo del programa de la derecha Programa en C++

01: class A { 02: public: 03: void procesarA1() { 04: procesarA2(); 05: }; 06: void procesarA2(); 07: }; 08: 09: class B { 10: public: 11: procesarB() { 12: a.procesarA1(); 13: }; 14: A a; 15: }; 16: 17: A a; 18: 19: void otraFuncion() { 20: } 21: 22: void main(){ 23: B b; 24: otraFuncion(); 25: b.procesarB(); 26: } 27: 28: void A::procesarA2(){ 29: }

Archivo de traducción 01: #Proyecto llamada

02: #Archivo C:\AreaTrabajo\metaDemo.cpp 03: #DefClase A

04: #DefFuncion procesarA1 05: #Llamada procesarA2 #DefClase A #Num 1

06: #DefClase B 07: #Objeto a #DefClase A #Num 0 08: #DefFuncion procesarB

09: #Llamada procesarA1 #DefClase A #Num 1 10: #Objeto a #DefClase A #Num 0 11: #DefFuncion otraFuncion

13: #DefFuncion main 14: #Objeto b #DefClase B #Num 1

15: #Llamada procesarB #DefClase B #Num 3 16: #DefFuncion A::procesarA2


26

Línea 1: class A {

Acción: Agregando clase: A al archivo: C:\AreaTrabajo\metaDemo.cpp Explicación: El traductor reconoce que el identificador A es una clase, según su sintaxis definido en C++ (Ver anexo F). Entonces se crea una instancia de clase DefClase cuyo nombre sea A y se agrega al archivo actual. Línea 3: void procesarA1() {

Acción: Inicializando secuencia a 0 Explicación: Cuando el traductor reconoce que el identificador procesarA1( ) es una función según la sintaxis de C++ (Ver anexo F). Entonces se inicializa un contador de secuencias en 0 cuando inicia una función. El contador de secuencias es una variable que es incrementada cada vez que se encuentre la declaración de objeto y llamadas dentro del código. El incremento de esta variable asegura el orden en la cual son encontrados los objetos y llamadas a funciones. Posteriormente es creada una instancia de clase DefFunción cuyo nombre sea procesarA1 que es la función actual. Acción: Agregando función: procesarA1 a la clase: A Explicación: El traductor agrega la función actual procesarA1 a la clase actual A. Línea 4: procesarA2();

Acción: Agregando llamada: procesarA2 a la función: procesarA1 Explicación: El traductor encuentra una sentencia que realiza una llamada a la función procesarA2, creando así una instancia de clase Llamada. La llamada procesarA2 no está definida a que clase pertenece, por lo que el traductor agrega a la función actual procesarA1 sin especificar a que clase pertenece y guarda su referencia para que posteriormente sea resuelta. Acción: Número interacciones: 1 Explicación: Cuando el traductor identifica el fin de la función actual procesarA1, se muestra el número de llamadas o interacciones encontradas, tanto para objetos como llamadas realizadas a otras funciones. Línea 9: class B {

Acción: Agregando clase: B al archivo: C:\AreaTrabajo\metaDemo.cpp Explicación: De igual manera a la línea 1 es creada y agregada la clase B al archivo actual. Entonces ahora la clase actual es B. Línea 11: procesarB() {

Acción: Agregando función: procesarB a la clase: B Explicación: Durante la declaración de la clase B, es encontrado un identificador que representa una función que es llamado procesarB y es agregado a la clase actual B, como en el caso de la línea 3. Ahora la función actual es procesarB.

Línea 12: a.procesarA1();

Acción: Guardando llamada para resolver referencia al terminar la clase o función Explicación: El traductor identifica una llamada a una función basado en el objeto que le antecede antes del punto de nombre “a”, Es entonces que el traductor crea una instancia de clase Llamada con el nombre de procesarA1, pero sin ser resuelto a que clase pertenece y lo almacena en una lista de espera para que posteriormente sea resuelta la referencia a la cual pertenece. Acción: Agregando llamada: procesarA1


27

Explicación: La llamada procesarA1 es agregada a la función actual procesarB. La llamada aún no está definida a la clase que pertenece esta línea de código. Línea 14: A a; { Acción: Tipo actual: A Explicación: El traductor guarda el tipo actual para que busque posteriormente la clase a la cual pertenezca el objeto. Acción: El identificador es un objeto dentro de la clase: B Explicación: El traductor determina que el objeto es un objeto puesto dentro de la clase B por medio de uso de variables lógicas, las que indican si se encuentra o no se encuentre dentro de una clase. Acción: Agregando objeto: “a” a la clase: B Explicación: El traductor agrega el objeto y su tipo dentro de la clase actual B. Línea 15: }; Acción: Resolviendo referencias de la llamada: procesarA1 Explicación: El traductor al finalizar la clase busca aquellas llamadas que no fueron determinadas a que clase pertenece. A esta altura de la clase, ya se puede saber a que clase pertenece, debido a que en la línea 14 fue declarado el objeto “a” de tipo de clase A. Línea 17: A a; Acción: Tipo actual: A Acción: El identificador es un objeto dentro del archivo: C:\AreaTrabajo\metaDemo.cpp

Explicación: El traductor encuentra un objeto a nivel de archivo. Acción: Agregando objeto: a al archivo: C:\AreaTrabajo\metaDemo.cpp Explicación: Una vez encontrada a que clase es a la cual pertenece el objeto “a”, se crea una instancia de clase Objeto con el nombre de “a”. Línea 19: void otraFuncion() {

Acción: Inicializando secuencia a 0 Explicación: Cuando el traductor reconoce el identificador otraFuncion( ) según la sintaxis de C++ (Ver anexo F). Entonces cuando inicia una función se inicializa un contador de secuencias en 0. El contador de secuencias es una variable que es incrementada cada vez que se encuentre la declaración de objeto y llamadas dentro del código. Posteriormente es creada una instancia de clase DefFunción cuyo nombre sea procesarA1 y que es la función actual. Acción: Agregando función: otraFuncion al archivo: C:\AreaTrabajo\metaDemo.cpp Explicación: El traductor agrega la función otraFuncion al archivo actual c:\AreaTrabajo\metaDemo.cpp. Acción: Numero interacciones: 0 Explicación: Al finalizar la función muestra el número de objetos y llamadas que se encuentran dentro de la función. Línea 22: void main() {

Acción: Inicializando secuencia a 0 Explicación: Se inicializa la variable de secuencia, la que ayuda a saber cuantas interacciones existen dentro de una función.


28

Acción: Agregando funcion: main al archivo: C:\AreaTrabajo\metaDemo.cpp Explicación: La función encontrada se agrega al archivo actual. Línea 23: B b;

Acción: Tipo actual: B Explicación: El traductor identifica el tipo o clase para los objetos que se creen mas adelante. Acción: Agregando objeto: b a la función: main al archivo: C:\AreaTrabajo\metaDemo.cpp Explicación: El traductor crea una instancia de “b” de clase Objeto y es agregado a la función actual main. Línea 24: otraFuncion();

Acción: Agregando llamada: otraFuncion a la función: main Explicación: El traductor crea una instancia de clase Llamada pero sin tipo. De cualquier forma se agrega a la función actual. Acción: Llamada sin referencia de clase Explicación: El traductor guarda la referencia de llamadas que no tengan clase. Línea 25: b.procesarB();

Acción: Agregando llamada: procesarB de clase B a la función: main Explicación: El traductor crea una instancia de clase Llamada cuyo nombre es procesarB y es resuelto a que clase pertenece la llamada, gracias a la referencia que existe en ese nivel. Acción: Número interacciones: 3 Explicación: El traductor muestra un reporte de número de objetos y llamadas encontradas dentro de la función actual. Línea 28: void A::procesarA2() {

Acción: Inicializando secuencia a 0 Explicación: El traductor inicializa la variable de secuencia, que ayuda a saber cuantas interacciones existen dentro de una función. Acción: Agregando función: A::procesarA2 al archivo: C:\AreaTrabajo\metaDemo.cpp

Explicación: El traductor encuentra la declaración de una función A::procesarA2 y es agregada al archivo, debido a que se encuentra declarada a nivel del archivo. Acción: Numero interacciones: 0 Explicación: El traductor muestra un reporte de número de objetos y llamadas encontradas dentro de la función actual. Línea 30: FIN DEL ARCHIVO Acción: Resolviendo referencias de la llamada: procesarA2 Explicación: El traductor resuelve la referencia de la función procesarA2 y en cual nivel pertenece en la clase A. Acción: Resolviendo referencias de la llamada: otraFuncion Explicación: El traductor intenta resolver la referencia de la función actual. Acción: No se encontró la clase a la que pertenece el identificador: otra función Explicación: El traductor muestra un reporte del éxito y fracaso al intentar resolver alguna referencia.


29

Acción: Fin del análisis Explicación: Esto sucede cuando finaliza el análisis del archivo. Una vez finalizado el análisis sintáctico del programa, el traductor guarda en un archivo información de todas las clases, funciones, objetos y llamadas extraídas en el proceso, para que la herramienta de diagramación de secuencias pueda recuperar la información. Más detalles del archivo de traducción, ver la Tabla 3). Como puede observarse, el archivo de traducción sólo guarda aquellas llamadas que dispongan de alguna clase. Es el caso de la línea 14 y 15 donde se observa que el número de secuencia no es consecutivo debido a que la llamada otraFuncion no pertenece a ninguna clase, es decir es una llamada a una función estilo de escritura para programas C y no para programas orientados a objetos como C++.

4.3. Algoritmos de conversión

Una vez que se ha recuperado la información de las interacciones del código y depositado en la estructura del metamodelo del programa de C++ (Ver Tabla 3 anterior), es necesario convertirlo al correspondiente diagrama de secuencias propuesto por Macias Alonso [3], para lo cual se utiliza un algoritmo o programa que permita visualizar el diagrama. Tal programa es capaz de buscar interacciones realizadas en un método, las clases que intervienen en la interacción, distinguir llamadas funciones pertenecientes a la misma clase e inclusive, introducir una clase genérica para aquellos métodos que no pertenecen a una clase específica como es el caso del main. Por último, el algoritmo es capaz de reducir los diagramas estableciendo un nivel de profundidad en las llamadas. En la Figura 10 se muestra una estructura general del convertidor de diagramas, donde se concentran los algoritmos de conversión, los cuales hacen uso de la de la estructura del metamodelo de código y del diagramador de secuencias.

Proyecto

inter : Interaccion

obtenerInteraccion()

Convertidor

clasesAnalizar : Conjunto

nivelEstablecido : Entero

traducir()

crearMensaje(metodo : Cadena, clase : Cadena, nivel : Entero)

+pro

CDiagramaDS

dibujarObjetos()

dibujarMensajes()

+g

Figura 10 Estructura general del convertidor a diagramas de secuencias

Los parámetros que el algoritmo necesita son los siguientes: • Nombre del método a analizar • Conjunto de clases que intervienen en la interacción en ese método • Limite en el nivel de profundidad en las llamadas


30

Crea de objetos sobre el diagrama Crea los mensajes sobre el diagrama

Traducir 01: CrearDiagrama 02: for each clase in clasesAnalizar 03: dibujarObjetos 04: end for 05: crearMensaje( metodo, clase, 0 )

crearMensaje(Cadena: metodo, Cadena: clase, nivel) 01: for i = 1 to numInter(metodo) do 02: inter = obtenerInter(metodo, i) 03: if nivel < nivelEstablecido and inter.claseDestino in clasesAnalizar 04: dibujarMensaje(inter) 05: if inter.tipo <> RECURSIVO 06: nivel = nivel + 1 07: crearMensaje(inter.mensaje, inter.claseDestino, nivel) 08: nivel = nivel - 1 09: end if 10: end if 11: end for

Figura 11 Algoritmos de conversión a diagramas de secuencias

Algoritmo traducir Objetivo: Crear objetos en el diagrama. Entrada: Método o función de programa (main, por ejemplo) y un conjunto de clases a analizar, que el usuario selecciona a su conveniencia. Salida: Muestra en el diagrama las clases que intervienen en la interacción. Línea 1: CrearDiagrama, indica la creación del diagrama de secuencias (clase CDiagramaDS) dentro del diagramador. Línea 2: Por cada clase en el conjunto de clases deberá dibujar objetos en el diagrama. Línea 3: Dibujar objetos. Línea 4: Finaliza el ciclo de Por cada (For each). Línea 5: Se manda a llamar la función de la clase a la cual pertenezca para crear los mensajes, basándose en el método a analizar y el nivel de profundidad empezando por cero.

Algoritmo crearMensaje Objetivo: Crear los mensajes sobre el diagrama. Entrada: Recibe el nombre del método o función (main, por ejemplo), clase a la cual pertenezca el método y el nivel de profundidad. Salida: Muestra en el diagrama los mensajes que intervienen en la interacción, basándose en el orden en que se llevaron a cabo las llamadas a las funciones. Línea 1: Inicia el ciclo desde 1 hasta el número de interacciones que tenga el método (de líneas 2 hasta la 11). Línea 2: Obtiene del método la interacción correspondiente de i=1,i=2,…,i=n, es decir, una interacción contiene la clase origen, destino y el mensaje. Línea 3: Si el nivel es menor al establecido y si la clase destino está dentro de las clases a analizar entonces deberá hacer lo siguiente (desde la línea 4 hasta la 10). Línea 4: Dibuja un mensaje de interacción (de antemano se sabe que una interacción contiene la clase origen, destino y el nombre del mensaje). Línea 5: Si el tipo de interacción no es recursivo, deberá hacerse lo siguiente (de la línea 6 hasta la 8). Esto debido a que las llamadas recursivas tienden a ser infinitas. Línea 6. Por cada mensaje se incremente el nivel de profundidad. Línea 7. Se crea un mensaje de la siguiente interacción enviándole como argumento la clase destino y el nivel de profundidad contada en ese momento. Línea 8: Una vez finalizado la creación del mensaje se decrementa el nivel de profundidad.


31

El resultado del programa que se ha estado analizando a su correspondiente diagrama de secuencias se muestra en la Figura 12, y cuyos parámetros fueron los siguientes: Método a analizar: main Conjunto de clases a visualizar: clases = {A, B} Nivel de profundidad en las llamadas: 4 (por defecto)

Figura 12 Diagrama de secuencias del programa escrito en C++

Note que en la Figura 12 se introduce una nueva clase llamada App, la cual es una clase genérica de la aplicación en general, y en la cual se depositan aquellos métodos o funciones que no pertenezcan a una clase específica, es el caso del método main. Nota: Para mayor comprensión de nuestro método de solución puede consultar el material de animación en las presentaciones que vienen adjunto a este trabajo de investigación.

«El hombre que no sabe por qué estaría dispuesto a morir no sirve para vivir»

Martin Luther King

5. Desarrollo del sistema

n este capítulo se muestra el análisis y diseño de la herramienta, aunque el análisis en su mayoría se ha discutido en gran parte en el capítulo 4, por lo que a continuación mostramos los requerimientos básicos de la herramienta, los usos

que se le ofrece el usuario al utilizarla, la forma en que están dispuestos los elementos o artefactos de software sobre el sistema operativo y el modo de operación de la herramienta por medio de la descripción de pasos, diagramas de actividades y secuencias. Así también se describen a grandes rasgos la estructura de la herramienta y sus usos, implementando diagramas de paquetes y clases para lograr mayor entendimiento.

5.1. Requerimientos básicos

5.1.1. Nombre del producto InverS3C que significa traductor de código fuente orientado a objetos a diagramas de secuencias de UML.

5.1.2. Contexto El contexto del desarrollo de este producto, consiste en construir una herramienta de software que permita recuperar diagramas de secuencias a partir del descubrimiento de interacciones entre objetos creados en código escrito en lenguaje de programación C++ de sistemas orientados a objetos. Dicho de otra manera, la herramienta deberá mostrar el funcionamiento interno de un programa en forma de diagramas, útil para desarrolladores de software en etapas de mantenimiento y que necesitan entender código que tenga poca o nula documentación, así como también mantener la documentación de sistemas de software lo más actualizado posible.

5.1.3. Especificaciones de alto nivel Son los objetivos de este trabajo y en su defecto los alcances y limitaciones de la propuesta de tesis.

Capítulo

5

E

Capítulo 5. Desarrollo del sistema

33

5.2. Caso de uso

Figura 13 Casos de uso de la herramienta

5.2.1. Actores Usuario: Persona quien maneja la herramienta.

5.2.2. Casos de uso

1. Seleccionar archivos: Este caso de uso lo inicia el usuario. Provee la capacidad de seleccionar y abrir el archivo de programa de C++ para crear, modificar y/o visualizar. Flujo de eventos para el caso de uso Seleccionar archivos

1.1. Precondiciones Debe el usuario verificar que el archivo de programa de C++ sea válido y que compile correctamente.

1.2. Flujo principal Este caso inicia cuando el usuario abre un archivo con extensión .cpp, .cxx, que contenga un programa de C++ para ser analizado. Puede el usuario realizar cambios al archivo que abrió y guardarlo.

1.3. Subflujos Ninguno.

1.4. Flujos alternos Ninguno.

2. Traducir: Este caso de uso lo inicia el usuario. Permite la traducción del archivo de programa de C++ a sus correspondientes diagramas de secuencias de UML. Flujo de eventos para el caso de uso Traducir

2.1 Precondiciones Deberá de estar comentado las directivas de precompilación como #include o #define.

2.2 Flujo principal

Este caso inicia cuando el usuario ejecuta el comando Traducir dentro del asistente de ingeniería inversa de la herramienta que traduce el archivo de programa C++ a diagramas de secuencias y posteriormente muestra una lista de diagramas por método. Después el usuario selecciona y abre el diagrama. 2.3 Subflujos Ninguno.


34

2.4 Flujos alternos Ninguno.

3. Visualizar: Este caso de uso lo inicia el usuario. Permite seleccionar el diagrama a visualizar un diagrama guardado o generado por el traductor. Flujo de eventos para el caso de uso Visualizar

3.1 Precondiciones Debe existir resultado de la traducción o bien un diagrama que se encuentre almacenado.

3.2 Flujo principal Este caso inicia cuando el usuario abre o selecciona un archivo de diagrama traducido. Opcionalmente puede realizar el caso de uso 4. Personalizar visualización. 3.3 Subflujo Ninguno. 3.4 Flujos alternos Ninguno.

4. Personalizar visualización: Este caso de uso lo inicia el usuario. Permite especificar el nivel de profundidad de las llamadas en un diagrama de secuencias, así como las clases que se están visualizando. Flujo de eventos para el caso de uso Personalizar visualización

4.1 Precondiciones Debe existir resultado de la traducción o bien un diagrama que se encuentre almacenado.

4.2 Flujo principal Este caso inicia cuando el usuario presiona el botón opciones del diagrama actual que le permita especificar el nivel de profundidad de las llamadas del diagrama, así como las clases que van ha ser visualizadas.

4.3 Subflujos Ninguno.

4.4 Flujos alternos Ninguno.

5.3. Despliegue del proyecto

A continuación se describen cómo estarán desplegados los objetos o artefactos de software de esta herramienta (Ver Figura 14): Software ejecutable Son los programas desarrollados e implementados, los cuales están compuestos del ambiente gráfico y el traductor, los que se encuentran dentro de la carpeta de la herramienta. Carpeta de la herramienta

• scuml.exe: Entorno gráfico para la interacción con el usuario y visualización de los diagramas.


35

• traductor.exe: Aplicación de consola que realiza un análisis léxico y sintáctico del código C++, cuya información recuperada es almacenada en un archivo llamado traducción.txt

Carpetas y archivos de origen

• CarpetaProyecto: Carpeta donde se encuentra los archivos de una aplicación de C++.

o clases.h: Conjunto de archivos de cabeceras.

o impClase.cpp: Conjunto de archivos de implementaciones.

o main.cpp: Archivo que concentra la aplicación principal. Nota: Hasta este momento estos archivos deberán estar fusionados en uno solo y verificar que estos puedan ser compilados correctamente.

Carpeta y archivos de destino:

• CarpetaResultados: Carpeta donde se depositan los resultados.

o Traduccion.txt: Archivo que contiene información relevante para la construcción de los diagramas de secuencias que se encontraron en el código, tales como son las clases, objetos, funciones y llamadas a funciones.

o ds1.sec ds2.sec, ds3.sec: Uno o más archivos de representación gráfica de un diagrama de secuencias almacenado por la aplicación scuml.exe.

Figura 14 Diagrama de despliegue del proyecto InverS3C

5.4. Modo de operación

El modo de operar se resume en cinco pasos esenciales, haciendo uso del asistente de ingeniería inversa para la obtención de los diagramas de secuencias (ver Anexo G):


36

Paso 1: Elegir la herramienta de ingeniería inversa para código C++, seleccionar el archivo de traducción y el destino de los diagramas resultantes. Paso 2: Seleccionar el tipo de diagrama (diagrama de secuencias) y formato de los archivos (en formato para navegadores Web o formato propia de la herramienta SCUML). Paso 3: Llevar a cabo la traducción a diagramas de secuencias donde se muestra una bitácora de acciones del traductor y posibles errores encontrados. Paso 4: Generar los diagramas de secuencias seleccionando el método, las clases a mostrar y el limite de nivel de profundidad en las llamadas. Paso 5: Finalizar y mostrar un resumen de las actividades realizadas por la herramienta.

El usuario abre un programa de C++ el cual puede editarlo siempre y cuando compruebe que compila. Hasta el momento recomendamos que el programa se integre en uno solo y que se comenten las directivas de inclusión como #include y cualquier otra directiva del prepocesador. Posteriormente se debe llevar a cabo la traducción del código y se mostrará un listado de métodos del cual se pueden obtener los diagramas de secuencias, así como las que intervienen en las interacciones en el nivel de profundidad de llamadas, esto es, las llamadas sucesivas entre métodos. Para mayor detalle de operación ver Figura 15 y la secuencia en la Figura 16.

Figura 15 Diagrama de actividad del modo de operación de la herramienta


37

Figura 16 Secuencia de operación de la herramienta


38

5.5. Estructura del sistema

5.5.1. Diagramas de clases y de paquetes

5.5.1.1. Traductor

Figura 17 Dependencia entre paquetes del traductor

Descripción de los paquetes (Figura 17): • Antlr: Conjunto de clases pertenecientes que el analizador léxico y sintáctico

requiere, fue diseñado por Terence Parr [33] para facilitar el desarrollo de analizadores.

• Analizador: Conjunto de clases generadas por la herramienta de Antlr [33] usando la gramática para C++.

• CMasMas: Conjunto de clases que representa un metamodelo de un programa orientado a objetos.

• Traductor: Conjunto de clases que incluye clases del analizador y del metamodelo para extraer información de un programa orientado a objetos.

Estructura de clases del analizador

Figura 18 Estructura de clases del analizador


39

Descripción de las clases (Figura 18) Las clases diccionario de entrada (DictEntry, Dictionary, CPPDictionary) y tabla de símbolos (CPPSymbol), son clases de apoyo al analizador léxico (CPPLexer) y sintáctico (CPPParser) y otros (STDCTokenTypes y LineObject) creados por Antlr para reconocer código escrito en C++. Las acciones semánticas fueron escritas dentro de la clase CPPParser. Las limitaciones que actualmente el analizador tiene en el momento de la extracción son: que no reconoce Templates en C++ y no reconoce directivas del prepocesador.

Relaciones entre de clases del metamodelo (CMasMas)

Figura 19 Estructura de clases y relaciones del metamodelo de un programa orientado a objetos

Descripción de las clases (Figura 19): • Proyecto: Representa un proyecto de una aplicación en la solución de un

problema, ej. Cajero automático, Sistema de videos. • Archivo: Representa todos los archivos del cual esta compuesto el proyecto, es

decir son los programas escritos en algún lenguaje de programación. • DefFuncion: Representa una método o función en un programa orientado a

objetos. • Objeto: Representa un objeto creado ya sea dentro de una función o dentro de

una clase. • DefClase: Representa un clase o entidad dentro de un programa orientado

objetos. • Llamada: Representa una llamada a una función o método dentro del cuerpo de

una función.

Para mayor detalle de las relaciones entre las clases del metamodelo consulte el capítulo 4.


40

Herencia entre clases del metamodelo (CMasMas)

Figura 20 Herencia en el metamodelo

Descripción de la herencia entre clases (Figura 20) Las clases Proyecto, Archivo, DefFuncion, Objeto, DefClase y Llamada, tienen en común un nombre que los identifica como artefactos únicos (clase Artefacto) dentro de un sistema de software. Algunas propiedades como numSec son esenciales para almacenar el orden de aparición de los objetos y llamadas en un programa. Funciones como serialize() son importantes para el almacenamiento del modelo obtenido de un programa, por ejemplo: puede hacer uso de la función serialize() de la clase Proyecto para almacenar todo el modelo completo como sigue:

traductor.proyecto->serialize(“traduccion.txt”); Para recuperar un modelo desde un archivo, es decir de forma inversa es:

traductor.proyecto = new Proyecto(“traduccion.txt”); El formato del archivo es el descrito en el capitulo 4 en la sección de “Traductor y el metamodelo de un programa orientado a objetos”.

Estructura de clases del traductor

Figura 21 Estructura de clases del Traductor


41

Descripción de las clases (Figura 21) El traductor (clase Traductor) es el responsable de extraer, resolver referencias e interpretar la información del código para el diagrama de secuencias. Mantiene información a cerca de la clase o función que está analizando y guarda una cola de referencias de llamadas (clase ReferenciaLlamadas) para ser resueltas al final del análisis. Es responsable de inicializar la secuencia de conteo durante la traducción cada vez que se encuentra dentro de una función diferente. Así también el traductor está compuesto por los analizadores léxico y sintáctico (clases CPPLexer y CPPParser), y de clases del metamodelo (clases Proyecto, Archivo, DefClase, DefFuncion) útiles para mantener las referencias durante el análisis.

5.5.1.2. Interfaz del usuario (SCUML)

. Figura 22 Relación entre paquetes del la herramienta SCUML.

Descripción de los paquetes (Figura 22): • MFC 6.0: Contiene clases de Microsoft Foundation Class, es un marco de

trabajo de aplicación para la programación en Windows, proporciona el código necesario para manejar ventanas, menús y cuadros de diálogo..

• Scuml: Conjunto de clases pertenecientes a la herramienta suite Cenidet-UML, que dispone para la construcción de diversos diagramas de UML entre ellos los diagramas de secuencias.

Estructura de clases del Sculm - Interfaz de usuario de InverS3C

Figura 23 Estructura de clases de la interfaz de usuario de InverS3C


42

Figura 24 Estructura detallada de clases de la interfaz de usuario de InverS3C

Descripción de las clases (Figura 23 y Figura 24): • CPropertySheetEx y CPropertyPageEx: Clases que permiten crear ventanas o

cuadros de dialogo como fichas, y con ellas son posibles crear asistentes. La clase CPropertySheetEx y la propiedad m_psh.dwFlags |= PSH_WIZARD97; muestra las fichas en modo asistente.

• IngInvDlg: Estilo de ventana que contiene páginas como las siguientes: o IngInvPaginaInicioDlg: Ficha para la ventana inicial del asistente, en el

se seleccionan los archivos para realizar análisis, corresponde a la primer ventana del asistente (Ver Anexo G, primer paso del asistente).

o IngInvPaginaTipos: Ficha para la ventana de selección de formato de los tipos de diagramas (Ver Anexo G, segundo paso del asistente).

o IngInvPaginaTraduccion: Ficha para la ventana de traducción, la que permite mostrar una bitácora de actividades de la traducción. Esta ventana manda a ejecutar la aplicación traductor.exe

<ruta/nombreArchivo> (Ver Anexo G, tercer paso del asistente). o OpcionesDS: Ficha para la ventana que permite personalizar la

visualización de los diagramas de secuencias, por medio de la selección de los métodos, clases y niveles de profundidad en las llamadas. (Ver Anexo G, cuarto paso del asistente).

o PaginaFinalizacion: Ficha para la ventana de finalización que muestra un resumen de las actividades hechas por el asistente (Ver Anexo G, quinto paso del asistente).


43

Estructura de clases del Sculm - Convertidor

Figura 25 Diagrama de clases del convertidor

Descripción de las clases (Figura 25) La interfaz de usuario para generar diagramas de secuencias (clase OpcionesDS) contiene una clase llamada Convertidor, cuya responsabilidad es convertir un modelo obtenido del programa orientado a objetos (clase Proyecto) hacia un diagrama de secuencias (CSeqDiagDoc). La clase Convertidor contiene el nombre del método, la lista de clases que serán analizados y el nivel de profundidad de llamadas realizadas por cada método. Básicamente el convertidor crea diagramas de secuencias a partir del modelo obtenido por el traductor. La implementación de traducción entre un modelo de un programa orientado a objetos y su diagrama de secuencias se encuentra depositado en el método traducir() y crearMensajes(). El cual implementa el algoritmo de conversión citado en el capítulo 4.


44

5.5.2. Diagrama de componentes: Traductor e interfaz de usuario

Figura 26 Componentes del traductor e interfaz de usuario

El componente scuml (Figura 26) es un archivo ejecutable para Windows que depende de las librerías de MFC 6.0, así mismo, el componente Traductor es un archivo ejecutable de consola que depende de las librerías de Antlr, ambos son totalmente dependientes de sus librerías

«Pensar es la tarea más dura que existe; por eso, probablemente, son tan pocos lo que se dedican a ella»

Henry Ford

6. Evaluación experimental

e ha seleccionado como caso de estudio un sistema simulador de cajero automático (ATM, Automated Teller Machine), sin considerar la parte de hardware. Éste trabajo fue desarrollado en el Colegio Gordon por el

departamento de matemáticas y ciencias de la computación (http://www.math-cs.gordon.edu/courses/cs211/ATMExample/index.html) por el profesor Russell C. Bjork, en su materia de desarrollo de software orientado a objetos. Este sistema proporciona varias funcionalidades (Figura 27) como: iniciar el sistema (System Startup), cerrar sistema (System Shutdown), iniciar sesión (Session), realizar transacciones (Transaction), retirar (Withdrwal), depositar (Deposit), transferir (Transfer) y consultar (Inquiry).

Figura 27 Casos de uso del cajero automático

El sistema esta desarrollado en Java completamente y de manera incompleta para C++ estándar (para sistemas Unix). Este código está documentado junto con los diagrama de UML, como los diagramas de la vista estática (clases) y dinámica (interacción y estados, entre otros).

Capítulo

6

S

Capítulo 6. Evaluación experimental

46

En los diagramas de interacción se encuentran los diagramas de secuencias que especifican el comportamiento de cada caso de uso, definiendo la interacción entre los objetos. Estos diagramas fueron desarrollados durante el análisis y diseño. Este trabajo de maestría realiza ingeniería inversa para los diagramas de secuencia que pueden ser usados para verificar la consistencia entre el código y el diseño. Los diagramas de clases del cajero automático (Ver Figura 28) muestran la estructura básica, las relaciones y responsabilidades descubiertas durante el análisis y diseño. Se han seleccionado dos casos de estudio: el PIN no válido e iniciar sesión.

Figura 28 Diagrama de clases del cajero automático


47

6.1. Caso de estudio PIN no válido

Un PIN no válido inicia dentro de una transacción cuando el banco informa de las transacciones de los clientes que no son aprobados, debido a la ejecución de un PIN no válido o incorrecto. El cliente vuelve a reintroducir el PIN y la petición original es enviada al banco de nuevo. Si el banco aprueba la transacción o lo desaprueba por otra razón, el caso de uso original continúa; de lo contrario el proceso de reintroducción del PIN es repetido. Una vez que el PIN es reintroducido con éxito, este es usado para la actual transacción y para las siguientes transacciones de la sesión. Si el cliente falla tres veces al introducir el PIN, se retiene permanentemente la tarjeta y en la pantalla es desplegada la información de este cliente y las sugerencias para contactar al banco y, por último, la sesión completa del cliente es abortada. Si el cliente presiona Cancelar en lugar de reintroducir un PIN, la transacción original es cancelada. El diagrama de colaboración (que es equivalente al diagrama de secuencias) es mostrado en la Figura 29. Un diagrama de secuencias obtenido por el proceso de ingeniería inversa de este trabajo es mostrado en la Figura 30.

Figura 29 Diagrama de colaboración de PIN no válido


48

El diagrama de secuencias inicia en la clase Session con el mensaje número uno, llamado reintroducir PIN (reEnterPIN) y manda mensaje al banco informando de las transacciones sobre el caso de un PIN no válido (mensaje número dos sendToBank). Posteriormente el diagrama de secuencias nos indica que el mensaje siguiente, número tres, es retener la tarjeta (retainCard) que en primer lugar es enviado al cajero automático y este a su vez al lector de tarjetas (CardReader) en el cuarto mensaje.

Figura 30 Ingeniería inversa cuando el PIN no es válido

6.2. Caso de estudio Iniciar sesión

Una sesión inicia cuando un cliente inserta una tarjeta en el cajero automático en el lector de tarjetas de la máquina. El cajero jala la tarjeta y lo lee (Si el lector no lo puede leer la tarjeta debido a la inserción inapropiada o por un daño, la tarjeta es expulsada, un error es desplegado en la pantalla, y la sesión es abortada). Al cliente se le pide introducir su PIN, y es entonces permitido llevar a cabo una o más transacciones, elige de un menú los posibles tipos de transacciones en cada caso. Después de cada transacción, se le pregunta al cliente si quiere ejecutar otra. Cuando el cliente a terminado de llevar a cabo las transacciones, la tarjeta es expulsada de la máquina y la sesión finaliza. Si las transacciones son abortadas debido a muchas entradas no válidas de PIN, la tarjeta quedará retenida dentro de la máquina.

Figura 31 Diagrama de secuencias de iniciar sesión en un ATM


49

Figura 32 Ingeniería inversa cuando se inicia sesión en un ATM


50

El cliente puede abortar la sesión y presionar Cancelar cuando esta introduciendo un PIN o elegir otro tipo de transacción. En la Figura 32 se muestra un diagrama de secuencias del método doSessionUseCase() dentro del programa del cajero automático que a su vez representa el caso de uso de iniciar sesión. La lista de mensajes descubiertos son las siguientes:

1. Inicia sesión obteniendo la clave de acceso personal PIN getPIN(). 2. Se elige y se obtiene del menú la transacción a realizar chooseTransaction(). 3. A su vez se obtiene la opción elegida por el usuario en el cajero

getMenuChoice() que pueden los siguientes mensajes del 4 al 7. 4. Retiro WithdrawTransaction(). 5. Depositar DepositTransaction(). 6. Transferir TransferTransaction(). 7. Consultar InquiryTransaction(). 8. Posteriormente se realiza la transacción con el método doTransactionUseCase()

que incluye el mensaje 9. 9. Verificar si es inválido el PIN doInvalidPINExtension(), que incluye los

mensajes 10 al 12. 10. El anterior mensaje que involucra reintroducir el PIN reEnterPIN(). 11. Enviar mensaje al banco información de la transacción al banco sendToBank(). 12. En el caso de ser no válido el PIN muchas veces se retiene la tarjeta en el cajero

retainCard(). 13. Y a su vez el cajero a su vez envia un mensaje de retención al lector de tarjetas,

retainCard(). 14. Nuevamente se elige del menú getMenuChoice() en la sesión del usuario. 15. En caso de alguna falla de la transacción se envía el mensaje

doFailedTransactionExtension(), esta función lleva a cabo distintos reportes de fallos dependiendo el estatus del sistema que incluye los mensajes 17 al 18.

16. reportTransactionFailure() por el estatus TOO_LITTLE_CASH. 17. reportTransactionFailure() por el estatus ENVELOPE_DEPOSIT_TIMED_OUT. 18. reportTransactionFailure() por otro caso que incluye una explicación. 19. rejectionExplanation() explicación del rechazo. 20. Al terminar la sesión se expulsa la tarjeta del cajero ejectCard(). 21. A su vez el cajero ejectCard() manda un mensaje la lectora de tarjetas que

expulse la tarjeta del cliente.

6.3. Otros casos de estudio

Otros casos de estudio correspondientes a los casos de uso del simulador ATM, que fueron también llevados a cabo ingeniería inversa, como los siguientes:

6.3.1. Caso de uso de realizar una transacción El caso de uso para llevar a cabo una transacción empieza dentro de una sesión cuando los clientes eligen un tipo de transacción del menú de opciones. Si el banco reporta que el PIN del cliente no es válido se lleva a cabo el caso de uso de PIN no válido. Las transacciones deben verificarse si han sido completadas y ofrece la posibilidad de ser canceladas por los usuarios.


51

Figura 33 Ingeniería inversa cuando se realiza una transacción

6.3.2. Ingeniería inversa de la función que elige una transacción Aunque elegir una transacción no es un caso de uso propiamente, el método chooseTransaction() de la clase Transaction. Al realizarle ingeniería inversa pudimos recuperar información a cerca de cuáles son las acciones que lleva a cabo.

Figura 34 Ingeniería inversa cuando se elige una transacción

6.3.3. Ingeniería inversa de la función de reporte de fallos En esta función de reporte de fallos, podemos decir que realiza diferentes tipos reportes sobre cada mensaje, en el primer mensaje según el código se refiere al estado TOO_LITTLE_CASH, el segundo a ENVELOPE_DEPOSIT_TIMED_OUT y el tercero se refiere a un reporte de fallos el cual incluya una explicación adicional. Por ultimo se hace uso de la función rejectionExplanation() que ofrece una explicación del error.

Figura 35 Ingeniería inversa cuando se reporta fallos en una transacción

«La salud de las personas es el verdadero fundamento en que descansa toda su felicidad y todo su poder»

Benjamín Disraeli

7. Conclusiones

a ingeniería inversa es utilizada para entender la estructura y comportamiento de un software cuya documentación no se encuentre actualizada a la fecha. Este trabajo es el punto de inicio para otras investigaciones sobre ingeniería inversa de código

escrito en C++, en el cual se haga uso de metamodelos. El trabajo de tesis cumplió con los objetivos propuestos, que es el desarrollo de un algoritmo de recuperación a diagramas de secuencias y de la construcción de una herramienta de software que permita recuperar los diagramas de secuencias a partir del código escrito en C++. Así también se puede observar que a partir de código escrito en lenguaje C++, se pueden recuperar directamente del código los diagramas de secuencias de UML (Lenguaje Unificado de Modelado) en la versión 1.x, de forma automática, de acuerdo a la hipótesis planteada en este trabajo. La herramienta desarrollada recupera información relevante para el diagrama de secuencias genérico desde el código.

7.1. Pregunta de investigación resuelta

En base a los resultados obtenidos se da respuesta a la pregunta de esta investigación que se planteó en los inicios de este trabajo: ¿Existirá alguna forma de modelar el código fuente que ayude a representar un programa

orientado a objetos, para ser utilizado y llevar a cabo ingeniería inversa para la obtención

de diagramas de UML?

Lo que conduce a la siguiente respuesta: Si existe, forma de modelar el código fuente a través de la creación y uso de un

metamodelo capaz de representar un programa orientado a objetos tal como se realizó en este trabajo para el lenguaje de programación C++. Este metamodelo, más que una tabla de valores, es una estructura que representó realmente cómo están dispuestos cada parte o elemento del programa, que ayudó a un mejor análisis durante la transformación a otros modelos, tal es el caso de los diagramas de secuencias obtenidos. Con esto el metamodelo es útil para modelar lenguajes de programación orientado a objetos como el lenguaje C++, así también para llevar a cabo ingeniería inversa para la obtención de diagramas de UML, como los diagramas de secuencias. El metamodelo de un programa orientado a objetos, es una representación del software escrito en código fuente en el mundo real cuya utilidad es la medida de su valor.

Capítulo

7

L

Capitulo 7. Conclusiones

53

7.2. Análisis de los resultados

Hemos llevado a cabo ingeniería inversa a varios casos de estudio en forma gradual, desde las formas más primitivas de interacción hasta las más complejas, considerando las limitaciones que hasta ahora hemos encontrado, entre ellos un simulador de cajero automático. El programa del simulador de cajero automático tiene mas de 1000 líneas de código, el cual se logró recuperar información relevante de 53 funciones del cajero entre las principales servicio a clientes (ATM::serviceCustomers), la función de PIN no válido (Session::doInvalidPINExtension), la función de realizar sesión (Session::doSessionUseCase) y 9 clases principales entre ellos los mas importantes como la clase cajero (ATM), banco (clase Bank) y sesión (clase Session). Ahora bien, el número de diagramas de secuencias obtenidos fueron 28 de los cuáles 9 fueron los mas significativos en cuanto la información que arrojaban, debido a que algunos métodos se encuentran incompletos y hacen a referencias a clases que no están disponibles. Los tres casos de estudio llevados a cabo en este trabajo de tesis correspondieron a casos de uso definidos por el sistema, del los cuáles podemos decir que algunos casos de uso corresponden directamente a métodos declarados en el código, por ejemplo el método doInvalidPINExtension() de la clase Session corresponde al caso de uso de PIN no válido en el sistema, así como también la función doSessionUseCase() corresponde al caso de uso de iniciar sesión.

También se realizaron pruebas a otros programas, pero no se tenía documentación alguna, que contenían 800 líneas de código aproximadamente y 58 funciones, de los cuales 11 no estaban orientados a objetos, sino de estilo lenguaje C. El número de diagramas con más información relevante fueron de 14.

Los resultados obtenidos han sido evaluados en cuanto a sus equivalencias entre el código y cada elemento del diagrama, así también la relación directa entre la secuencia real de las llamadas dentro de los métodos y sus correspondientes secuencias de mensajes en los diagramas obtenidos, fueron comprobados con la ayuda de una herramienta de depuración durante tiempo de ejecución paso a paso del programa, lo que han confirmado su confiabilidad para la interpretación de los diagramas obtenidos. Además se evaluó los niveles de anidamiento en las llamadas sucesivas dentro de los métodos, mediante programas codificados especialmente para su efectividad y comprobación.

7.3. Comentarios y trabajos futuros

El conocimiento y uso de una gramática de un lenguaje de programación es primordial para recuperar información de cualquier código; dentro de este proyecto se utilizó la traducción dirigida por sintaxis, aplicando predicados semánticos y así poder construir nuestro metamodelo que representa un programa C++, esto fue hecho sin utilizar árboles de sintaxis abstracta debido al reducido tiempo para dominarlos, más aún, cuando la gramática es extensa. Se podría utilizar para trabajos futuros los árboles de sintaxis abstracta y el análisis semántico a través de árboles. Cabe también destacar que la gramática empleada en esta tesis ha sido muy útil, debido a que acepta sin dificultad el código de C++, en contraste, con los anteriores analizadores en los que era muy difícil su manejo y poco soporte para su entendimiento. En cambio, la actual gramática (Ver referencia [33]) está basada por el creador del lenguaje C++.

Capitulo 7. Conclusiones

54

Sería conveniente empezar a trabajar sobre las nuevas versiones de UML 2.x utilizando las especificaciones establecidas por la OMG (Object Management Group) y su tratamiento mediante las tecnologías XML e intercambio de información entre herramientas mediante XMI.

Por otro lado el metamodelo de un programa orientado a objetos propuesto en este trabajo, se ha ido mejorado durante el desarrollo de esta tesis. En sus inicios el metamodelo representaba las interacciones primitivas y posteriormente se fue añadiendo mas relaciones entre sus clases para analizar interacciones complejas entre los objetos. Es posible con el tiempo el metamodelo incremente sus relaciones para un mejor análisis de los objetos dentro de un programa. El actual metamodelo no analiza a detalle los objetos dentro del programa y tampoco son visualizados en el diagrama de secuencias debido a que estos incrementarían el tamaño del diagrama, por lo que se necesitaría un análisis de flujo de datos tal y como lo realizó Tonella [2].

7.3.1. Alcances y limitaciones de la herramienta A continuación se detallan los alcances de la herramienta realizada en este trabajo y también sus limitaciones que no se consideraron al principio y que serán útiles como punto de referencias para trabajos futuros. Alcances

• Generar diagrama genérico (incluye clase y mensajes). • Utilización de tecnología MFC. • Creación de objetos. • Llamadas a métodos. • Recursividad. • Reducción de diagrama por método. • Reducción de diagrama por clases. • Reducción de diagrama por nivel llamadas. • Resuelve llamadas a funciones de la misma clase, es decir llamadas a this. • Resuelve llamada a funciones constructoras por medio de new.

Limitaciones

• No genera diagrama de instancia (incluye clases, objetos y mensajes). • No soporta varios archivos de programas (debe estar en un sólo archivo y

compilado), es decir no incluye análisis del preprocesador. • No analiza el flujo de control y de datos. • No realiza llamadas por parámetros que soporte polimorfismo. • No reduce diagrama por llamadas comunes. • No incluye la destrucción de objetos. • No analiza funciones por herencia básica (simple y múltiple), avanzada (contención

y delegación) y funciones amigas (friend). Ver referencia 34. • No soporta templates y macros. • No analiza funciones que han sido reemplazadas por otras, debido a la herencia.

8. Referencias bibliográficas 1 PRESSMAN ROGER S. Ingeniería de Software, un enfóque práctico. (5a ed.;

Aravaca, Madrid, España: Mc Graw Hill, 2002). 2 TONELLA PAOLO [and] Potrich Alessandra, “Reverse Engineering of the Interaction

Diagrams from C++ Code”, (EN: International Conference on Software

Maintenance, ICSM. Amsterdam, The Netherlands, 2003). pp. 159-168. 3 M.C. MACIAS J. ALONSO, “Ambiente de modelado y diseño de sistemas de software

utilizando diagramas de secuencias”, (Tesis de maestría en ciencias, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, Morelos, México, Agosto 2004).

4 MARTINEZ REBOLLAR ALICIA. “Generador de código para lenguaje C utilizando una notación de diseño detallado”. (Maestría en Ciencias Computacionales; Cuernavaca, Morelos, Centro Nacional de Investigación y Desarrollo Tecnológico, 1997).

5 PARRA RAMIREZ ISAAC ALBERTO, “Modelado visual orientado a objetos”. (Maestría en Ciencias Computacionales; Cuernavaca, Morelos, México, Centro Nacional de Investigación y Desarrollo Tecnológico, 2000).

6 WENCES DÍAZ MARTHA FABIOLA, “Modelo de ingeniería inversa para la obtención de diseño detallado basado en Leviss”. (Maestría en Ciencias Computacionales, Cuernavaca, Morelos, México, Centro Nacional de Investigación y Desarrollo Tecnológico, 2002).

7 HERNANDEZ VELÁZQUEZ MIGUEL. “Ingeniería Inversa de código fuente en C++ para la obtención de su diseño”. (Maestría en Ciencias Computacionales; Cuernavaca, Morelos, México, Centro Nacional de Investigación y Desarrollo Tecnológico, 2003).

8 VALDEZ BESARES JOSE GUILLERMO. “Ambiente visual para la integración de clases utilizando diagrama de paquetes”. (Maestría en Ciencias Computacionales; Cuernavaca, Morelos, México, Centro Nacional de Investigación y Desarrollo Tecnológico, 2004).

9 GONZALES MIRANDA ALEJANDRO. “Ambiente visual de modelado del estado de objetos de una clase utilizando los diagramas de estados propuestos por UML”. (Maestría en Ciencias Computacionales; Cuernavaca, Morelos, México, Centro Nacional de Investigación y Desarrollo Tecnológico, 2004).

10 MACIAS MONTOYA JOSE ALONSO. “Ambiente de modelado y diseño de sistemas de software utilizando diagramas de secuencias”. (Maestría en Ciencias Computacionales; Cuernavaca, Morelos, México, Centro Nacional de Investigación y Desarrollo Tecnológico, 2004).

11 CABRERA SANTIAGO NUBIA. “Ambiente de modelado y documentación de sistemas de software utilizando diagramas de casos de uso”. (Tesis de Maestría, CENIDET, Cuernavaca, Morelos, México, Mayo del 2004).

12 NUÑEZ URBINA ALICIA ANGELICA. “Ingeniería inversa para la obtención de diagramas de clases y diseño detallado basado en diagramas de Warnier para código escrito en Java”. (Tesis de Maestría, CENIDET, Cuernavaca, Morelos, México, Mayo del 2004).

13 RAITALAAKSO TIMO, “Dynamic Visualization of C++ Programs with UML Sequence Diagrams”, (Tesis de maestría en ciencias, Universidad de Tecnologica de Tampere, Finlandia, 2000). Fuente: http://practise.cs.tut.fi/pub/ Agosto 2004

Referencias

56

14 L.C. BRIAND, [y] Labiche [y] Miao, “Towards the Reverse Engineering of UML Sequence Diagrams”, (EN: Proc. IEEE International Conference on Reverse Engineering, ICRE. Victoria, BC, Canada, 2003).

15 TONELLA PAOLO [y] Potrich Alessandra, “Static and Dynamic C++ Code Analysis for the Recovery of the Object Diagram”, (EN: International Conference on Software Maintenance, ICSM. Montréal, Canada, 2002). Fuente: http://www.cis.ohio-state.edu/~rountev/788/private/papers/tonella_icsm02.pdf Marzo 2004.

16 VOLGIN OLGA “Analysis of flow of control for reverse engineering of sequence diagrams”, (Tesis de maestría, Universidad del Estado de Ohio, Estados Unidos, Abril 2004). Fuente: http://www.cse.ohio-state.edu/~rountev/publications.html Noviembre 2004

17 LOGSEQUENCER. Fuente: http://www.logsequencer.com/ Abril 2004. 18 NASRA CONSULTING: Fuente: http://www.nasra.fr/ Mayo 2004. 19 LOGIC EXPLORERS INC. Fuente : http://www.logicexplorers.com/ Marzo 2004. 20 BORLAND INC. Fuente: http://www.borland.com/together/ Septiembre 2004 21 LIBERTY JESSE, Horvath David B. Aprendiendo C++ para Linux en 21 Días. (1ª

ed.; Prentice Hall, 2001). p501. 22 The Future of Software Engineering http://www.softwaresystems.org/future.html Mayo

2005 23 Plan Nacional de Desarrollo 2001-2006 (PND)

Fuente: http://pnd.presidencia.gob.mx/index.php?idseccion=45 Mayo 2005 24 RODRIGUEZ ALFREDO, Márquez Antonio, Toro Miguel, “Gestión de la Evolución

del Software. El eterno problema de los legacy systems”. Universidad de Sevilla. Fuente: http://aporia.ugr.es/evol/docs/1DEF.pdf Marzo 2004.

25 ELLIT J. CHIKOFSKY, James H.Cross II, “Reverse Engineering and Design Recovery: A Taxonomy”. IEEE Software, January 1990, pp.13-17.

26 GRADY BOOCH, James Rumbaugh, Ivar Jacobson. El Lenguaje Unificado de

Modelado. (1ª ed.; Madrid, España: Addison Wesley Iberoamericana, 1999). 27 OBJECT MANAGEMENT GROUP (OMG). “Unified Modeling Language

Specification 1.5” Fuente: http://www.omg.org/cgi-bin/doc?formal/03-03-01. Marzo 2004

28 MARTIN FOWLER, Kendall Scott. UML Gota a gota. (1ª ed.; Addison Wesley Longman de México, 1999). p123.

29 HANS-ERIK ERIKSSON, Magnus Penker. UML Toolkit. (1ª ed.; Wiley Computer Publishing, 1998). p138.

30 GRADY BOOCH, op. cit. p222 31 SIAN SI ALHIR. Learning UML. (1ª ed.; Estados Unidos: O'Reilly, 2003). 32 UML: Por Fin, un Modelo Unificado para Análisis y Diseño". Computerworld, año 19,

número 564. México, Mayo 11-15, 1998. Págs. F22-F23. "El discreto encanto del Metamodelo de UML", Soluciones Avanzadas, México, Agosto de 1998

33 ANother Tool for Language Recognition. http://www.antlr.org/grammar/cpp. Abril 2005

34 LIBERTY JESSE, Horvath David B. Aprendiendo C++ para Linux en 21 Días. (1ª ed.; Prentice Hall, 2001). p501.

Anexo A

Figura 36 Funcionamiento de LogSequencer

Anexos

Archivo de registro

Anexos

58

Anexo B

Figura 37 Funcionamiento de j2u durante el análisis dinámico

1

2

.class

Bytecode actualizado

Ejecuta

Archivo de trazos

3

5

4 j2u

Lee

Actualiza

Lee

Genera

.class

Bytecode

Anexos

59

Anexo C

Figura 38 Funcionamiento de CodeLogic para C# en Visual Studio .NET

Clases y

métodos

Diagrama de Secuencias

Anexos

60

Anexo D

Figura 39 Funcionamiento de CodeLogic para Java

Paquetes

Clases

Métodos

Por cada método un diagramas de secuencias

Anexos

61

Anexo E

Figura 40 Opciones de la herramienta Borland Together para establece el tamaño de los diagramas

Opciones de la herramienta Together

Profundidad de anidamiento de llamadas

Profundidad de llamadas de nivel 1

Profundidad de llamadas de nivel 2

Anexos

62

Anexo F

Lista de trazos del analizador sintáctico y acciones del traductor sobre un programa en C++. > translation_unit; LA(1)==class, LA(2)==A > external_declaration; LA(1)==class, LA(2)==A > declaration; LA(1)==class, LA(2)==A > declaration_specifiers; LA(1)==class, LA(2)==A > type_specifier; LA(1)==class, LA(2)==A > class_specifier; LA(1)==class, LA(2)==A

> qualified_id; LA(1)==A, LA(2)=={ > scope_override; LA(1)==A, LA(2)=={ < scope_override; LA(1)==A, LA(2)=={

Encontrado identificador: A

< qualified_id; LA(1)=={, LA(2)==public Buscando referencia de clase A en el archivo metaDemo.cpp : No encontrada

Creando clase: A Agregando clase: A al archivo: metaDemo.cpp

> member_declaration; LA(1)==public, LA(2)==: nivelDeClase = true;

> access_specifier; LA(1)==public, LA(2)==: < access_specifier; LA(1)==:, LA(2)==void

nivelDeClase = false;

< member_declaration; LA(1)==void, LA(2)==procesarA1 > member_declaration; LA(1)==void, LA(2)==procesarA1

nivelDeClase = true;

> function_definition; LA(1)==void, LA(2)==procesarA1

nivelDeFuncion = true; Inicia función

Inicializando secuencia a 0

> declaration_specifiers; LA(1)==void, LA(2)==procesarA1 > type_specifier; LA(1)==void, LA(2)==procesarA1 > simple_type_specifier; LA(1)==void, LA(2)==procesarA1 < simple_type_specifier; LA(1)==procesarA1, LA(2)==( < type_specifier; LA(1)==procesarA1, LA(2)==( < declaration_specifiers; LA(1)==procesarA1, LA(2)==( > function_declarator; LA(1)==procesarA1, LA(2)==( > function_direct_declarator; LA(1)==procesarA1, LA(2)==( > qualified_id; LA(1)==procesarA1, LA(2)==( > scope_override; LA(1)==procesarA1, LA(2)==( < scope_override; LA(1)==procesarA1, LA(2)==(

Encontrado identificador: procesarA1

< qualified_id; LA(1)==(, LA(2)==) Función encontrada a nivel de clase

Creando función: procesarA1 Agregando función: procesarA1 a la clase: A

< function_direct_declarator; LA(1)=={, LA(2)==procesarA2 < function_declarator; LA(1)=={, LA(2)==procesarA2

03: void procesarA1() {

01: class A {

Anexos

63

> compound_statement; LA(1)=={, LA(2)==procesarA2 > statement_list; LA(1)==procesarA2, LA(2)==( > statement; LA(1)==procesarA2, LA(2)==( > expression; LA(1)==procesarA2, LA(2)==( > assignment_expression; LA(1)==procesarA2, LA(2)==( > conditional_expression; LA(1)==procesarA2, LA(2)==( > logical_or_expression; LA(1)==procesarA2, LA(2)==( > logical_and_expression; LA(1)==procesarA2, LA(2)==( > inclusive_or_expression; LA(1)==procesarA2, LA(2)==( > exclusive_or_expression; LA(1)==procesarA2, LA(2)==( > and_expression; LA(1)==procesarA2, LA(2)==( > equality_expression; LA(1)==procesarA2, LA(2)==( > relational_expression; LA(1)==procesarA2, LA(2)==( > shift_expression; LA(1)==procesarA2, LA(2)==( > additive_expression; LA(1)==procesarA2, LA(2)==( > multiplicative_expression; LA(1)==procesarA2, LA(2)==( > pm_expression; LA(1)==procesarA2, LA(2)==( > cast_expression; LA(1)==procesarA2, LA(2)==( > unary_expression; LA(1)==procesarA2, LA(2)==( > postfix_expression; LA(1)==procesarA2, LA(2)==( > primary_expression; LA(1)==procesarA2, LA(2)==( > id_expression; LA(1)==procesarA2, LA(2)==( > scope_override; LA(1)==procesarA2, LA(2)==( < scope_override; LA(1)==procesarA2, LA(2)==( < id_expression; LA(1)==(, LA(2)==) < primary_expression; LA(1)==(, LA(2)==)

Expresion actual: procesarA2 Llamada encontrada a nivel de clase

Agregando llamada: procesarA2 a la función: procesarA1 Llamada sin referencia de clase

< postfix_expression; LA(1)==;, LA(2)==} < unary_expression; LA(1)==;, LA(2)==} < cast_expression; LA(1)==;, LA(2)==} < pm_expression; LA(1)==;, LA(2)==} < multiplicative_expression; LA(1)==;, LA(2)==} < additive_expression; LA(1)==;, LA(2)==} < shift_expression; LA(1)==;, LA(2)==} < relational_expression; LA(1)==;, LA(2)==} < equality_expression; LA(1)==;, LA(2)==} < and_expression; LA(1)==;, LA(2)==} < exclusive_or_expression; LA(1)==;, LA(2)==} < inclusive_or_expression; LA(1)==;, LA(2)==} < logical_and_expression; LA(1)==;, LA(2)==} < logical_or_expression; LA(1)==;, LA(2)==} < conditional_expression; LA(1)==;, LA(2)==} < assignment_expression; LA(1)==;, LA(2)==} < expression; LA(1)==;, LA(2)==} < statement; LA(1)==}, LA(2)==; < statement_list; LA(1)==}, LA(2)==; < compound_statement; LA(1)==;, LA(2)==void

nivelDeFuncion = false; Numero interacciones: 1

Fin de la función procesarA1

< function_definition; LA(1)==;, LA(2)==void nivelDeClase = false;

< member_declaration; LA(1)==;, LA(2)==void > member_declaration; LA(1)==;, LA(2)==void

nivelDeClase = true; nivelDeClase = false;

05: };

04: procesarA2();

Anexos

64

< member_declaration; LA(1)==void, LA(2)==procesarA2 > member_declaration; LA(1)==void, LA(2)==procesarA2


> declaration; LA(1)==void, LA(2)==procesarA2 > declaration_specifiers; LA(1)==void, LA(2)==procesarA2 > type_specifier; LA(1)==void, LA(2)==procesarA2 > simple_type_specifier; LA(1)==void, LA(2)==procesarA2 < simple_type_specifier; LA(1)==procesarA2, LA(2)==( < type_specifier; LA(1)==procesarA2, LA(2)==( < declaration_specifiers; LA(1)==procesarA2, LA(2)==( > init_declarator_list; LA(1)==procesarA2, LA(2)==( > init_declarator; LA(1)==procesarA2, LA(2)==( > declarator; LA(1)==procesarA2, LA(2)==( > direct_declarator; LA(1)==procesarA2, LA(2)==( > qualified_id; LA(1)==procesarA2, LA(2)==( > scope_override; LA(1)==procesarA2, LA(2)==( < scope_override; LA(1)==procesarA2, LA(2)==(

Encontrado identificador: procesarA2

< qualified_id; LA(1)==(, LA(2)==) < direct_declarator; LA(1)==;, LA(2)==} < declarator; LA(1)==;, LA(2)==} < init_declarator; LA(1)==;, LA(2)==} < init_declarator_list; LA(1)==;, LA(2)==} < declaration; LA(1)==}, LA(2)==;


< member_declaration; LA(1)==}, LA(2)==;

Resolviendo referencias de la llamada: procesarA2

No se encontró la clase a la que pertenece el indentificador: procesarA2 en 7

< class_specifier; LA(1)==;, LA(2)==class < type_specifier; LA(1)==;, LA(2)==class < declaration_specifiers; LA(1)==;, LA(2)==class < declaration; LA(1)==class, LA(2)==B < external_declaration; LA(1)==class, LA(2)==B

> external_declaration; LA(1)==class, LA(2)==B > declaration; LA(1)==class, LA(2)==B > declaration_specifiers; LA(1)==class, LA(2)==B > type_specifier; LA(1)==class, LA(2)==B > class_specifier; LA(1)==class, LA(2)==B > qualified_id; LA(1)==B, LA(2)=={ > scope_override; LA(1)==B, LA(2)=={ < scope_override; LA(1)==B, LA(2)=={

Encontrado identificador: B

< qualified_id; LA(1)=={, LA(2)==public Buscando referencia de clase B en el archivo metaDemo.cpp : No encontrada

Creando clase: B Agregando clase: B al archivo: metaDemo.cpp

> member_declaration; LA(1)==public, LA(2)==: nivelDeClase = true;

> access_specifier; LA(1)==public, LA(2)==: < access_specifier; LA(1)==:, LA(2)==procesarB


< member_declaration; LA(1)==procesarB, LA(2)==( > member_declaration; LA(1)==procesarB, LA(2)==(


09: class B {

07: };

Anexos

65

> function_direct_declarator; LA(1)==procesarB, LA(2)==( > qualified_id; LA(1)==procesarB, LA(2)==( > scope_override; LA(1)==procesarB, LA(2)==( < scope_override; LA(1)==procesarB, LA(2)==(

Encontrado identificador: procesarB

< qualified_id; LA(1)==(, LA(2)==) Función encontrada a nivel de clase

Creando función: procesarB Agregando función: procesarB a la clase: B

< function_direct_declarator; LA(1)=={, LA(2)==a < function_declarator; LA(1)=={, LA(2)==a

> compound_statement; LA(1)=={, LA(2)==a > statement_list; LA(1)==a, LA(2)==. > statement; LA(1)==a, LA(2)==. > expression; LA(1)==a, LA(2)==. > assignment_expression; LA(1)==a, LA(2)==. > conditional_expression; LA(1)==a, LA(2)==. > logical_or_expression; LA(1)==a, LA(2)==. > logical_and_expression; LA(1)==a, LA(2)==. > inclusive_or_expression; LA(1)==a, LA(2)==. > exclusive_or_expression; LA(1)==a, LA(2)==. > and_expression; LA(1)==a, LA(2)==. > equality_expression; LA(1)==a, LA(2)==. > relational_expression; LA(1)==a, LA(2)==. > shift_expression; LA(1)==a, LA(2)==. > additive_expression; LA(1)==a, LA(2)==. > multiplicative_expression; LA(1)==a, LA(2)==. > pm_expression; LA(1)==a, LA(2)==. > cast_expression; LA(1)==a, LA(2)==. > unary_expression; LA(1)==a, LA(2)==. > postfix_expression; LA(1)==a, LA(2)==. > primary_expression; LA(1)==a, LA(2)==. > id_expression; LA(1)==a, LA(2)==. > scope_override; LA(1)==a, LA(2)==. < scope_override; LA(1)==a, LA(2)==. < id_expression; LA(1)==., LA(2)==procesarA1 < primary_expression; LA(1)==., LA(2)==procesarA1

Expresion actual: a

> id_expression; LA(1)==procesarA1, LA(2)==( > scope_override; LA(1)==procesarA1, LA(2)==( < scope_override; LA(1)==procesarA1, LA(2)==( < id_expression; LA(1)==(, LA(2)==)

Guardando llamada para resolver referencia al terminar la clase o función -- Agrego llamada: procesarA1

< postfix_expression; LA(1)==;, LA(2)==} < unary_expression; LA(1)==;, LA(2)==} < cast_expression; LA(1)==;, LA(2)==} < pm_expression; LA(1)==;, LA(2)==} < multiplicative_expression; LA(1)==;, LA(2)==} < additive_expression; LA(1)==;, LA(2)==} < shift_expression; LA(1)==;, LA(2)==} < relational_expression; LA(1)==;, LA(2)==} < equality_expression; LA(1)==;, LA(2)==} < and_expression; LA(1)==;, LA(2)==} < exclusive_or_expression; LA(1)==;, LA(2)==} < inclusive_or_expression; LA(1)==;, LA(2)==} < logical_and_expression; LA(1)==;, LA(2)==} < logical_or_expression; LA(1)==;, LA(2)==} < conditional_expression; LA(1)==;, LA(2)==}

12: a.procesarA1();

11: procesarB() {

Anexos

66

< assignment_expression; LA(1)==;, LA(2)==} < expression; LA(1)==;, LA(2)==} < statement; LA(1)==}, LA(2)==; < statement_list; LA(1)==}, LA(2)==; < compound_statement; LA(1)==;, LA(2)==A


< member_declaration; LA(1)==;, LA(2)==A > member_declaration; LA(1)==;, LA(2)==A

nivelDeClase = true; nivelDeClase = false;

< member_declaration; LA(1)==A, LA(2)==a

> member_declaration; LA(1)==A, LA(2)==a


> declaration_specifiers; LA(1)==A, LA(2)==a > type_specifier; LA(1)==A, LA(2)==a > simple_type_specifier; LA(1)==A, LA(2)==a

Tipo actual: A

> qualified_type; LA(1)==A, LA(2)==a > scope_override; LA(1)==A, LA(2)==a < scope_override; LA(1)==A, LA(2)==a < qualified_type; LA(1)==a, LA(2)==; < simple_type_specifier; LA(1)==a, LA(2)==; < type_specifier; LA(1)==a, LA(2)==; < declaration_specifiers; LA(1)==a, LA(2)==; > member_declarator_list; LA(1)==a, LA(2)==; > member_declarator; LA(1)==a, LA(2)==; > declarator; LA(1)==a, LA(2)==; > direct_declarator; LA(1)==a, LA(2)==; > qualified_id; LA(1)==a, LA(2)==; > scope_override; LA(1)==a, LA(2)==; < scope_override; LA(1)==a, LA(2)==;

Encontrado identificador: a

< qualified_id; LA(1)==;, LA(2)==} El identificador es un objeto dentro de la clase: B

Creando objeto: a Agregando objeto: a a la clase: B

< direct_declarator; LA(1)==;, LA(2)==} < declarator; LA(1)==;, LA(2)==} < member_declarator; LA(1)==;, LA(2)==} < member_declarator_list; LA(1)==;, LA(2)==}


< member_declaration; LA(1)==}, LA(2)==;


< class_specifier; LA(1)==;, LA(2)==A < type_specifier; LA(1)==;, LA(2)==A < declaration_specifiers; LA(1)==;, LA(2)==A < declaration; LA(1)==A, LA(2)==a < external_declaration; LA(1)==A, LA(2)==a

15: };

14: A a;

Anexos

67

> external_declaration; LA(1)==A, LA(2)==a > declaration; LA(1)==A, LA(2)==a > declaration_specifiers; LA(1)==A, LA(2)==a > type_specifier; LA(1)==A, LA(2)==a > simple_type_specifier; LA(1)==A, LA(2)==a

Tipo actual: A

> qualified_type; LA(1)==A, LA(2)==a > scope_override; LA(1)==A, LA(2)==a < scope_override; LA(1)==A, LA(2)==a < qualified_type; LA(1)==a, LA(2)==; < simple_type_specifier; LA(1)==a, LA(2)==; < type_specifier; LA(1)==a, LA(2)==; < declaration_specifiers; LA(1)==a, LA(2)==; > init_declarator_list; LA(1)==a, LA(2)==; > init_declarator; LA(1)==a, LA(2)==; > declarator; LA(1)==a, LA(2)==; > direct_declarator; LA(1)==a, LA(2)==; > qualified_id; LA(1)==a, LA(2)==; > scope_override; LA(1)==a, LA(2)==; < scope_override; LA(1)==a, LA(2)==;

Encontrado identificador: a

< qualified_id; LA(1)==;, LA(2)==void El identificador es un objeto dentro del archivo: metaDemo.cpp

Creando objeto: a Agregando objeto: a al archivo: metaDemo.cpp

< direct_declarator; LA(1)==;, LA(2)==void < declarator; LA(1)==;, LA(2)==void < init_declarator; LA(1)==;, LA(2)==void < init_declarator_list; LA(1)==;, LA(2)==void < declaration; LA(1)==void, LA(2)==otraFuncion < external_declaration; LA(1)==void, LA(2)==otraFuncion

> external_declaration; LA(1)==void, LA(2)==otraFuncion > function_definition; LA(1)==void, LA(2)==otraFuncion



> declaration_specifiers; LA(1)==void, LA(2)==otraFuncion > type_specifier; LA(1)==void, LA(2)==otraFuncion > simple_type_specifier; LA(1)==void, LA(2)==otraFuncion < simple_type_specifier; LA(1)==otraFuncion, LA(2)==( < type_specifier; LA(1)==otraFuncion, LA(2)==( < declaration_specifiers; LA(1)==otraFuncion, LA(2)==( > function_declarator; LA(1)==otraFuncion, LA(2)==( > function_direct_declarator; LA(1)==otraFuncion, LA(2)==( > qualified_id; LA(1)==otraFuncion, LA(2)==( > scope_override; LA(1)==otraFuncion, LA(2)==( < scope_override; LA(1)==otraFuncion, LA(2)==(

Encontrado identificador: otraFuncion

< qualified_id; LA(1)==(, LA(2)==) Función encontrada a nivel de archivo

Creando función: otraFuncion Agregando función: otraFuncion al archivo: metaDemo.cpp

< function_direct_declarator; LA(1)=={, LA(2)==} < function_declarator; LA(1)=={, LA(2)==} > compound_statement; LA(1)=={, LA(2)==} < compound_statement; LA(1)==void, LA(2)==main

19: void otraFuncion() {

17: A a;

Anexos

68


Fin de la función otraFuncion

< function_definition; LA(1)==void, LA(2)==main < external_declaration; LA(1)==void, LA(2)==main

> external_declaration; LA(1)==void, LA(2)==main > function_definition; LA(1)==void, LA(2)==main



> declaration_specifiers; LA(1)==void, LA(2)==main > type_specifier; LA(1)==void, LA(2)==main > simple_type_specifier; LA(1)==void, LA(2)==main < simple_type_specifier; LA(1)==main, LA(2)==( < type_specifier; LA(1)==main, LA(2)==( < declaration_specifiers; LA(1)==main, LA(2)==( > function_declarator; LA(1)==main, LA(2)==( > function_direct_declarator; LA(1)==main, LA(2)==( > qualified_id; LA(1)==main, LA(2)==( > scope_override; LA(1)==main, LA(2)==( < scope_override; LA(1)==main, LA(2)==(

Encontrado identificador: main


Creando función: main Agregando función: main al archivo: metaDemo.cpp

< function_direct_declarator; LA(1)=={, LA(2)==B < function_declarator; LA(1)=={, LA(2)==B > compound_statement; LA(1)=={, LA(2)==B > statement_list; LA(1)==B, LA(2)==b

> statement; LA(1)==B, LA(2)==b > declaration; LA(1)==B, LA(2)==b > declaration_specifiers; LA(1)==B, LA(2)==b > type_specifier; LA(1)==B, LA(2)==b > simple_type_specifier; LA(1)==B, LA(2)==b

Tipo actual: B

> qualified_type; LA(1)==B, LA(2)==b > scope_override; LA(1)==B, LA(2)==b < scope_override; LA(1)==B, LA(2)==b < qualified_type; LA(1)==b, LA(2)==; < simple_type_specifier; LA(1)==b, LA(2)==; < type_specifier; LA(1)==b, LA(2)==; < declaration_specifiers; LA(1)==b, LA(2)==; > init_declarator_list; LA(1)==b, LA(2)==; > init_declarator; LA(1)==b, LA(2)==; > declarator; LA(1)==b, LA(2)==; > direct_declarator; LA(1)==b, LA(2)==; > qualified_id; LA(1)==b, LA(2)==; > scope_override; LA(1)==b, LA(2)==; < scope_override; LA(1)==b, LA(2)==;

Encontrado identificador: b

< qualified_id; LA(1)==;, LA(2)==otraFuncion El identificador es un objeto dentro una función: main a nivel del archivo:

metaDemo.cpp Creando objeto: b

Agregando objeto: b a la función: main al archivo: metaDemo.cpp

23: B b;

22: void main(){

20: }

Anexos

69

< direct_declarator; LA(1)==;, LA(2)==otraFuncion < declarator; LA(1)==;, LA(2)==otraFuncion < init_declarator; LA(1)==;, LA(2)==otraFuncion < init_declarator_list; LA(1)==;, LA(2)==otraFuncion < declaration; LA(1)==otraFuncion, LA(2)==( < statement; LA(1)==otraFuncion, LA(2)==(

> statement; LA(1)==otraFuncion, LA(2)==( > expression; LA(1)==otraFuncion, LA(2)==( > assignment_expression; LA(1)==otraFuncion, LA(2)==( > conditional_expression; LA(1)==otraFuncion, LA(2)==( > logical_or_expression; LA(1)==otraFuncion, LA(2)==( > logical_and_expression; LA(1)==otraFuncion, LA(2)==( > inclusive_or_expression; LA(1)==otraFuncion, LA(2)==( > exclusive_or_expression; LA(1)==otraFuncion, LA(2)==( > and_expression; LA(1)==otraFuncion, LA(2)==( > equality_expression; LA(1)==otraFuncion, LA(2)==( > relational_expression; LA(1)==otraFuncion, LA(2)==( > shift_expression; LA(1)==otraFuncion, LA(2)==( > additive_expression; LA(1)==otraFuncion, LA(2)==( > multiplicative_expression; LA(1)==otraFuncion, LA(2)==( > pm_expression; LA(1)==otraFuncion, LA(2)==( > cast_expression; LA(1)==otraFuncion, LA(2)==( > unary_expression; LA(1)==otraFuncion, LA(2)==( > primary_expression; LA(1)==otraFuncion, LA(2)==( > id_expression; LA(1)==otraFuncion, LA(2)==( > scope_override; LA(1)==otraFuncion, LA(2)==( < scope_override; LA(1)==otraFuncion, LA(2)==( < id_expression; LA(1)==(, LA(2)==) < primary_expression; LA(1)==(, LA(2)==)

Expresion actual: otraFuncion Llamada encontrada a nivel de archivo

Agregando llamada: otraFuncion a la función: main Llamada sin referencia de clase

< postfix_expression; LA(1)==;, LA(2)==b < unary_expression; LA(1)==;, LA(2)==b < cast_expression; LA(1)==;, LA(2)==b < pm_expression; LA(1)==;, LA(2)==b < multiplicative_expression; LA(1)==;, LA(2)==b < additive_expression; LA(1)==;, LA(2)==b < shift_expression; LA(1)==;, LA(2)==b < relational_expression; LA(1)==;, LA(2)==b < equality_expression; LA(1)==;, LA(2)==b < and_expression; LA(1)==;, LA(2)==b < exclusive_or_expression; LA(1)==;, LA(2)==b < inclusive_or_expression; LA(1)==;, LA(2)==b < logical_and_expression; LA(1)==;, LA(2)==b < logical_or_expression; LA(1)==;, LA(2)==b < conditional_expression; LA(1)==;, LA(2)==b < assignment_expression; LA(1)==;, LA(2)==b < expression; LA(1)==;, LA(2)==b < statement; LA(1)==b, LA(2)==.

24: otraFuncion();

Anexos

70

> statement; LA(1)==b, LA(2)==. > expression; LA(1)==b, LA(2)==. > assignment_expression; LA(1)==b, LA(2)==. > conditional_expression; LA(1)==b, LA(2)==. > logical_or_expression; LA(1)==b, LA(2)==. > logical_and_expression; LA(1)==b, LA(2)==. > inclusive_or_expression; LA(1)==b, LA(2)==. > exclusive_or_expression; LA(1)==b, LA(2)==. > and_expression; LA(1)==b, LA(2)==. > equality_expression; LA(1)==b, LA(2)==. > relational_expression; LA(1)==b, LA(2)==. > shift_expression; LA(1)==b, LA(2)==. > additive_expression; LA(1)==b, LA(2)==. > multiplicative_expression; LA(1)==b, LA(2)==. > pm_expression; LA(1)==b, LA(2)==. > cast_expression; LA(1)==b, LA(2)==. > unary_expression; LA(1)==b, LA(2)==. > postfix_expression; LA(1)==b, LA(2)==. > primary_expression; LA(1)==b, LA(2)==. > id_expression; LA(1)==b, LA(2)==. > scope_override; LA(1)==b, LA(2)==. < scope_override; LA(1)==b, LA(2)==. < id_expression; LA(1)==., LA(2)==procesarB < primary_expression; LA(1)==., LA(2)==procesarB

Expresion actual: b

> id_expression; LA(1)==procesarB, LA(2)==( > scope_override; LA(1)==procesarB, LA(2)==( < scope_override; LA(1)==procesarB, LA(2)==( < id_expression; LA(1)==(, LA(2)==)

-- Agrego llamada: procesarB -- Agrego llamada: procesarB de clase B a la función: main

< postfix_expression; LA(1)==;, LA(2)==} < unary_expression; LA(1)==;, LA(2)==} < cast_expression; LA(1)==;, LA(2)==} < pm_expression; LA(1)==;, LA(2)==} < multiplicative_expression; LA(1)==;, LA(2)==} < additive_expression; LA(1)==;, LA(2)==} < shift_expression; LA(1)==;, LA(2)==} < relational_expression; LA(1)==;, LA(2)==} < equality_expression; LA(1)==;, LA(2)==} < and_expression; LA(1)==;, LA(2)==} < exclusive_or_expression; LA(1)==;, LA(2)==} < inclusive_or_expression; LA(1)==;, LA(2)==} < logical_and_expression; LA(1)==;, LA(2)==} < logical_or_expression; LA(1)==;, LA(2)==} < conditional_expression; LA(1)==;, LA(2)==} < assignment_expression; LA(1)==;, LA(2)==} < expression; LA(1)==;, LA(2)==} < statement; LA(1)==}, LA(2)==void < statement_list; LA(1)==}, LA(2)==void < compound_statement; LA(1)==void, LA(2)==A

nivelDeFuncion = false; Numero interacciones: 3 Fin de la función main

< function_definition; LA(1)==void, LA(2)==A < external_declaration; LA(1)==void, LA(2)==A

25: b.procesarB();

Anexos

71

> external_declaration; LA(1)==void, LA(2)==A > function_definition; LA(1)==void, LA(2)==A



> declaration_specifiers; LA(1)==void, LA(2)==A > type_specifier; LA(1)==void, LA(2)==A > simple_type_specifier; LA(1)==void, LA(2)==A < simple_type_specifier; LA(1)==A, LA(2)==:: < type_specifier; LA(1)==A, LA(2)==:: < declaration_specifiers; LA(1)==A, LA(2)==:: > function_declarator; LA(1)==A, LA(2)==:: > function_direct_declarator; LA(1)==A, LA(2)==:: > qualified_id; LA(1)==A, LA(2)==:: > scope_override; LA(1)==A, LA(2)==:: < scope_override; LA(1)==procesarA2, LA(2)==(

Encontrado identificador: A::procesarA2


Creando función: A::procesarA2 Agregando función: A::procesarA2 al archivo: metaDemo.cpp

< function_direct_declarator; LA(1)=={, LA(2)==} < function_declarator; LA(1)=={, LA(2)==} > compound_statement; LA(1)=={, LA(2)==} < compound_statement; LA(1)==, LA(2)==


Fin de la función A::procesarA2

< function_definition; LA(1)==, LA(2)== < external_declaration; LA(1)==, LA(2)==


Resolviendo referencias de la llamada: otraFuncion No se encontró la clase a la que pertenece el indentificador: otraFuncion en

linea 30

< translation_unit; LA(1)==, LA(2)== Fin del analisis

Fin del archivo

28: void A::procesarA2(){

Anexos

72

Anexo G

Asistente de ingeniería inversa para la obtención de los diagramas de secuencias Paso 1: Elegir la herramienta de ingeniería inversa para código C++, seleccionar el archivo de traducción y el destino de los diagramas resultantes.

Anexos

73

Paso 2: Seleccionar el tipo de diagrama (diagrama de secuencias) y formato de los archivos (en formato para navegadores Web o formato propia de la herramienta SCUML).

Paso 3: Llevar a cabo la traducción a diagramas de secuencias, donde se muestra una bitácora de acciones del traductor y posibles errores encontrados.

Anexos

74

Paso 4: Generar los diagramas de secuencias seleccionando el método, las clases a mostrar y SCUML el límite de nivel de profundidad en las llamadas.

Paso 5: Finalizar y mostrar un resumen de las actividades realizadas por la herramienta

Documents

Centro Nacional de Investigación y Desarrollo Tecnológico ... · Los diagramas de secuencias de UML muestran las interacciones de objetos colocados en secuencias de tiempo, en particular,