cenidet Martha Fabiola... · obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis. Atentamente

SEiT DGiT SEP

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet Modelo de ingeniería inversa para la obtención

de diseño detallado basado en LEVES*

TESIS Que para obtener el grado de

Maestro en Ciencias en Ciencias Computacionales

p r e s e n t a

MARTHA FABIOLA WENCES DíAZ

Cuernavaca, Morelos Febrero del 2002

Centro Nacional de Investigación y Desarrollo Tecnológico

FORMA C3 REVISION DE TESIS

Cuernavaca, Morelos a 24 de enero del 2002

Dr. Raúl Pinto Elías Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para I obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: MODELO DE INGENIERIA INVERSA PARA LA OBTENCION DE DISEÑO DETALLADO BASADO EN LEVICC, realizada por la C. MARTHA FABIOLA WENCES DIAZ, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted

Atentamente

omisión de revisión de tesis

Z

,.

. . i

M.C. RENÉ SANTAOLAYA SALGADO

C.C.P. Dr. Rodolfo A. Pazos RangeliJefe del Departamento de Ciencias Cornputacionales

INTERIOR INTERNADO PALMIRA S/N. CUERNAVACA. MOR. MEXICO APARlADO POSTAL 5 ~ 1 6 4 CP 62050. CUERNAVACA. IELS.[73)12 2314.12 7613.18 7741.FAX373) 12 2434

EMAIL [email protected] cenidet

q(>I) Centro Nacional de Investigación y Desarrollo Tecnológico U D FORMA C4

AUTORIZACION DE IMPRESION DE TESIS

Cuernavaca, Morelos a O1 de febrero del 2002

C. MARTHA FABIOLA WENCES DlAZ Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: MODELO DE INGENIERIA INVERSA PARA LA OBTENCIÓN DE DISENO DETALLADO BASADO EN LEVISS, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Atentamente

I ,,' Dr. Rodolfo A. Pazos Range1

Jefe del Depto. de Ciencias Computacionales

INTERIOR INTERNADO PALMIRA S/N. CUERNAVACA. MOR. M E X I C O APARTADO POSTAL 5-164 CP 62050, CUERNAVACA. IELS.{73]12 2314.12 7613.18 í741.FAX (73) 12 243L cenidet

A mi hijo Emiliano, a quien le robé parte de mi tiempo, con el inmenso amor que le tengo.

A mi esposo Isaac, el amor de mi vida y a quien le tengo una gran admiración.

A mi madre Martha, por quien siento un profundo amor y un enorme orgullo. Gracias por haber hecho de mí lo que soy.

A mis hermanos Mónica, Gilberto, José y Christian, siempre presentes en mi corazón y por quienes siento un gran cariño.

Agradecimientos

A mi esposo Isaac, por todo su apoyo, respaldo y tiempo que dedicó en la revisión de este trabajo enriqueciéndolo con sus aportaciones. Gracias por estar siempre conmigo, te quiero.

A toda mi familia por apoyarme siempre que los necesito.

A mis suegros Jesús y Rosa, porque con su ayuda nos impulsaron, a Isaac y a mi, siempre a seguir adelante.

A mi director de tesis el M.C. Máximo López Sánchez, en quien siempre encontré apoyo, paciencia y confianza. Gracias por alentarme en la elaboración de este trabajo.

A mis revisores: el M. C René Santaolaya Salgado, la M. C. Olivia G. Fragoso Diaz y el Dr. Javier Ortiz Hemández, por el tiempo que dedicaron a la revisión de este trabajo y por sus aportaciones que lo mejoraron.

A mis compañeros de generación: Isaac, Magda, Pafy, Agustin, Nadira, Rocío, Sofia, Edson, Rogelio, Alfonso, Santiago, Javier, Aurelio y Alberto, por los momentos buenos y malos que como estudiantes vivimos juntos.

Al Centro Nacional de Investigación y Desarrollo Tecnológico, por permitirme alcanzar una meta más. A la SEP y a CONACYT por el apoyo económico que me brindaron.

i . . . . . . . . - -. . . . ~- ..

CONTENIDO

Capítulo 1. INTRODUCCION ................................................................

I . 1 Introducción 1.2 Antecedente 1.3 Diseño Deta

..... ..... ...... .. ...................................... . . . . . . . .

. . . . . . . . . . . . . . . . . 1.3.1 Ventajas de DDVI .............. 1.3.2 Deficiencias de DDVI ....................................................................................... . .

1.4 Planteamiento del problema ......... . . . . . . . , . . . . . . . . , . . . . . . . . . , , , . . . . . . . . . , . ., 1.5 Justificacion .................................... .......................................................................................... ................... de solución .............................................. . . . 1.8 Alcance y limitaciones ....................................................................

1.9 Plan de exposicion ....................................................................................................... . .,

Capítulo 2. ESTADO DEL ARTE ...........................................................

. . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 IMAGIX 4D ............................................................................................................. 2.3 PL/l ANALYZER ................................................ 2.4 Modelos de ingeniería inversa ...............................

2.4.1 Modelo de ingeniería inversa propuesto p 2.4.2 Modelo de ingenieria inversa propuesto por BOHNER ................................ 2.4.3 Modelo de ingeniería inversa propuesto por BYRNE .... 2.4.4 Modelo de ingeniería inversa propuesto por BIGGERSTAFF

Capítulo 3. MARCO TEORlCO .............................................................

3.1 Lenguajes Visuales ..................................... 3.1.1 Definicion .................................. 3.1.2 Aplicaciones ............................................................................

3.2 Notación de diseño detallado de Wamier ...................................... 3.3 Ingenieria inversa .....................................

............................ ......... ..... ............... . ... . ... . . . . . .. . .... ... . . . . . . . . . . . . . . .. . . . . . . . . . .. . . ...... . . . .... . . . . . I

. .

.............................. ........... ........... ........ 3.3.1 Definición de ingeniería inversa .............................................. 3.3.2 Funcionamiento de la ingeniería inversa. 3.3.3 Importancia de la ingenieria inversa ........

3.3.5 Ciclos de vida del software ............................................................

. , .

3.3.4 Areas de aplicación ..................................... . . . . . . . . . , , , . . . . . . . . . , , . . . . . . .

1

3 3 3 6 6 7 7 7 7 8 8

10

11 11 12 13 13 14 15 16

19

15 19 19 20 22 23 23 24 25 25

3.3.6 Mantenimiento del software ............................................................................ 27

Capítulo 4. ARQUITECTURA Y DESARROLLO DE INVER-DDVI.. ...................................................... 28 ...........

4.1 Introducción .... ........................... ......................................... 28 4.2 Modelo concep 4.3 Enfoque del proceso de ingeniería inversa .... 4.4 Elementos de la arquitectura .......................... 4.5 Extension de las capacidades de DDVI ............................................. 4.6 Metodología de INVER-DDVI ...

4.6.1 Estructura de datos ............................. 4.6.2 Almacenamiento de componentes sintácticos ........................ 4.6.3 Formato de almacenamiento ........................................................................... 35 4.6.4 Gramática Visual de DDVI ....... 4.6.5 Extensión de la gramática

....................................... .................

. , . 4.7 Proceso de ingenieria inversa .................................................................... 4.8 Diseño ....................... ......................... ............................................ 39

Capítulo 5. PRUEBAS EXPERIMENTALES ....................................... 41

5.1 Casos de estudio ....................................................................................................... 4 1 5.2 Aplicación de INVER-DDVI ................................................................................... 44 5.3 Resumen y evaluacion de resultados ........................................................................ 5 1 .,

54 Capítulo 6. CONCLUSIONES ................................................................

6.1 Conclusiones ............................................................................................................ 54 6.2 Trabajos futuros ........................................................................................................ 55

51

Anexo A. Gramática Visual de DDVI ......................................................................... 59

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

LISTA DE FIGURAS

No . de Figura Descripción Página

1.1

2.1

2.2

2.3

2.4

3.1

3.2

4.1

4.2

4.3

4.4

4.5

4.6

4.1

5.1

5.2

5.3

5.4

5.5

5.6

5.7

Arquitectura actualizada de AMASS ........................................

Modelo de ingeniería inversa de Breuer ...............................

Modelo de ingeniería inversa de Bohner ..................

Modelo de ingeniería inversa de Byme ....................................

Modelo de ingeniería inversa de Biggerstaff ............................

Diferencias entre términos del desarrollo del software ........

Modelo de cascada del ciclo de vida del software ....................

Modelo conceptual de INVER-DDVI ..................................

Diagrama del modelo de ingeniería inversa de DDVI ..............

Arquitectura de INVER-DDVI .................................................

Ejemplo del análisis que realiza INVER-DDVI .......................

Extensión que se realizó a la gramática de DDVI .....................

Diagrama del proceso de ingeniería inversa de INVER-DDVI

Diagrama de clases de INVER-DDVI ......................................

Diseño detallado visual del caso 1 ........................................

Diseño detallado visual del caso 2 (primera parte) ...................

Diseño detallado visual del caso 2 (segunda parte) ..................

Diseño detallado visual del caso 3 (primera parte) ............

Diseño detallado visual del caso 3 (segunda parte) ..................

Diseño detallado visual del caso 3 (tercera parte) .....................

Diseño detallado visual del caso 3 (cuarta parte)

4

14

15

16

16

22

24

21

28

30

32

35

36

31

45

46

41

48

49

50

51

Introducción Capitulo 1

CAPíTULO 1

Introducción

La complejidad es una propiedad inherente del software, y la tarea de analizar y entender un sistema de software no es fácIl, sobre todo cuando no existe un diseño documentado. Además entender el software para efectos de mantenimiento implica dedicar tiempo que se traduce en costo.

La atención que dedican los ambientes integrados de software dentro del denominado ciclo de vida del software, ha venido a fortalecer partes, quc por su grado de complejidad, no permitía a los programadores inexpertos desarrollar sistemas de software propios de su

Introducción Capitulo 1

aplicación laboral. Un programador no experto puede ahora utilizar un ambiente integrado de software, para diseñar o para desarrollar SUS propios productos de software, sin tener que contar con un amplio conocimiento de herramientas complejas, lenguajes o metodologías que sólo en muchos de los casos, programadores expertos pueden manipular.

Los diseñadores y desarrolladores de software modernos, cuentan con útiles técnicas y metodologías derivadas de años de experiencia y observación, para guiarlos en su trabajo. Herramientas automatizadas han sido conjuntadas en ambientes que soportan el desarrollo de software. Estas herramientas se acoplan a las técnicas de ingeniería que asisten al desarrollo de s o h a r e dando por resultado software bien estructurado, entendible, fácil de mantener, con pocos errores y documentado apropiadamente [BYR9 I].

El grupo de ingeniería de software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) ha desarrollado un proyecto llamado AMASS, el cual consiste en un ambiente integrado de soporte para la administración y desarrollo de sistemas de software. Dentro de este proyecto se incluye una herramienta denominada DDVI, la cual permite que un desarrollador de software pueda crear en forma visual el diseño detallado de un sistema, utilizando la notación de Warnier, y a partir de éste generar su correspondiente código en el lenguaje de programación C. Esta herramienta es la base para el trabajo que se presenta en esta tesis.

La vida de un producto de software abarca ciclos de desarrollo inicial, incremental, de actualización y mantenimiento. Cada ciclo consiste de la especificación de nuevos requerimientos, determinación de nuevos diseños, modificación o reuso del código y probar que el código modificado se comporta como es requerido [PRY96].

La falta de documentación necesaria para emplear modernos métodos de ingeniería de software a lo largo de la vida de un producto de software, ha sido el mayor obstáculo en la reducción del costo de desarrollo y mejora de la fiabilidad del software [PRY96].

El proceso de reconstruir el diseño de un programa es llamado “recuperación del diseño” y es un elemento del proceso de ingeniería inversa [BYR91]. La recuperación del diseño, recrea abstracciones de diseño desde una combinación de: código, documentación del diseño existente (si está disponible), experiencia personal y conocimiento general acerca del problema y el dominio de la aplicación [BIG89].

La ingeniería inversa es un concepto que nació y se deriva de la tecnología del hardware, cuya finalidad es obtener el diseño de los artefactos a partir de un producto terminado [CHI90]. Aplicado al software, la ingeniería inversa es un concepto que se realiza al tratar de analizar el código fuente de un sistema para descubrir como está diseñado, con la finalidad de darle mantenimiento, mejorarlo, o bien adaptarlo a las necesidades cambiantes del medio ambiente [CHI90].

2

Capitulo 1 Introducción

1.1 Objetivo de la tesis

DDVI (Diseño Detallado Xsual) es una herramienta realizada en CENIDET que permite a un desarrollador de software, realizar el diseño detallado de un programa utilizando una gramática visual y la notación de Warnier, para posteriormente generar el correspondiente código en lenguaje C.

Cuando se desea analizar un programa para documentarlo, evaluarlo o para darle mantenimiento correctivo o perfectivo, nos enfrentamos a un gran problema: tratar de entender como funciona y realiza su propósito. El problema se agrava si no existe un diseño documentado. Hacer el análisis de un programa es más sencillo cuando se realiza desde el diseño detallado que le corresponde, ya que el diseño detallado oculta muchos detalles de implementación.

Es importante que todos los programas tengan un diseño detallado para efectos de mantenimiento, documentación o evaluación, sin embargo en la actualidad se desarrolla mucho software sin diseño y para reconstruirlo se necesita un proceso manual que implica tiempo y costo.

Si no existe la especificación de requerimientos para un sistema determinado, aplicando este proceso al código de un sistema, se puede reconstruir su diseño, el cual captura la funcionalidad del sistema. El diseño debe estar representado a tal nivel de abstracción, que elimine las dependencias de implementación del lenguaje [BYRgI].

De acuerdo al problema antes planteado, el objetivo de esta tesis es desarrollar una herramienta que llamaremos INVER-DDVI (INgenieria inVERsa utilizando Diseño Detallado VIsual), que permita tomar el código fuente de un programa escrito en lenguaje C y transformarlo a la notación de Warnier, para poder ilustrar su diseño de manera visual, tomando como base la gramática visual de la herramienta DDVI [PAROO].

1.2 Antecedentes

AMASS: Ambiente Integrado de Soporte para la Administración y Desarrollo de Sistemas de Soflware" está constituido por un conjunto integrado de herramientas visuales e interactivas, que dan soporte a las diferentes etapas de un modelo de desarrollo de software orientado hacia la construcción de sistemas; INVER-DDVI es una de tales herramientas de software que se incorporan a este ambiente de desarrollo.

El objetivo de AMASS es proporcionar apoyo al desarrollador de software en la obtención de productos de mayor calidad, plazos de desarrollo más cortos y menos costosos, mediante la formulación de un marco de trabajo visual e interactivo, con una base metodológica y otra base tecnológica para el desarrollo de aplicaciones.

' Proyecta spoyado por el Consejo Nacional d e Cicncia y Tccnologia (CONACyT) con la clave 32042-A, y pur cl Conseja dcI Sistema Nacional de Educacien Tecnológica (COSNET). con la clave 759.99-P.

3


AMASS integra herramientas de software basadas en métodos y tecnologías de vanguardia como son: programación visual, ingeniería inversa, reingeniería, análisis de dominios, prototipos rápidos, control de versiones, reusabillidad y teoría semiótica[SANOO]. El ambiente de desarrollo que proporciona AMASS, es un ambiente para el desarrollo de sistemas de software cuyo soporte son componentes reusables.

Desde su formulación original hasta su configuración actual ha presentado cambios en su arquitectura, incorporándosele herramientas y/o extensiones a las herramientas ya desarrolladas, tal es el caso del trabajo de tesis que aquí se está presentando .

En la figura 1.1 se muestra la configuración actual de la arquitectura conceptual de AMASS. Está formada por varias herramientas que facilitan el desarrollo de sistemas de software y cada una tiene una función especifica dentro del ciclo de vida de desarrollo de cistemas[SANOO].

Las herramientas para el desarrollo de software que conforman este ambiente son: el Sistema de recuperación de componentes SISREC, Lenguaje visual para el diseño detallado de programas DDVI, Documentador automático de programas DAPROG, un Visualizador de código SOFTGRAF, una herramienta para el modelado visual orientado a objetos llamada SOODA, un analizador de dominios SR2, un analizador de requisitos SRE, y una herramienta para probar la calidad de componentes de software QC. También tiene un Sistema administrador del ambiente SAMI, el cual es encargado de integrar las herramientas y que permite al usuario navegar de manera transparente entre una y otra herramienta. A continuación se hace una breve descripción de cada una de ellas.

Figura I . I Arquitechira actualizada de AMASS

4

Capitulo 1 Introduccion

SISREC, es una herramienta que permite la clasificación y la recuperación indexada y por hipertexto de componentes reusables de software, hacia y desde el depósito o base de los componentes de: casos de uso, escenarios, arquitecturas, diseño, código, casos de prueba, etcétera. Su funcionamiento está basado en un algoritmo de activación por propagación, lo cual facilita el recuperar componentes que se ajusten a los requerimientos del usuario. Esta herramienta recupera el o los componentes que más hayan sido empleados en la construcción de otros sistemas con requerimientos similares.

DDVI, le da al analista de sistemas la facilidad visual e interactiva de realizar el diseño detallado de programas estructurados proceduralmente o de los métodos específicos de una clase de objetos. El diseño de software se realiza usando un lenguaje visual soportado por una gramática visual y utilizando la notación de diseño detallado de Jean D. Warnier. AI utilizar esta herramienta se obtiene el diseño detallado del programa o del método o función implementada y al mismo tiempo el código de dicho diseño en lenguaje C.

DAPROG, es una herramienta que facilita el entendimiento en el proceso de adaptación o modificación de componentes de código existentes y también el mantenimiento de sistemas. Realiza la documentación automática de un sistema de software, que puede tratarse de un programa procedural o de la comunidad de una arquitectura de clases. Como resultado del proceso que realiza DAPROG, se obtiene la documentación interna del código (insertando pequeños párrafos en lenguaje natural), un diccionario de datos, un indice de la estructura del código basado en el paradigma del libro, y un sistema de hipertexto que permite navegar visualmente entre las diferentes entidades del código.

SOFTGRAF, extiende las capacidades que proporciona DAF'ROG y su función consiste en desplegar visualmente el código o segmentos de código, empleando símbolos gráficos que representan a las instrucciones tales como escritura, lectura, etc. También permite corregir anomalias en el flujo de los datos que en la mayona de los compiladores no son detectados, situación que dificulta la legibilidad del código.

El objetivo de SOODA es proporcionar un ambiente visual e interactive para realizar el diseño de la arquitectura conceptual de un sistema de software orientado a objetos, utilizando la notación del Lenguaje Unificado de Modelado (UML). Con esta herramienta se obtiene el diseño de un conjunto de clases relacionadas. SOODA establece una relación estrecha con DDVI para generar el diseño detallado de los métodos de las clases y posteriormente su correspondiente código en. lenguaje C.

SR2, realiza la transformación del código procedural legado de dominio de aplicaciones, en marcos de trabajo conformados por conjuntos de clases en colaboración que contienen la mayoría de las operaciones necesarias para las aplicaciones de dominios. El trabajo de SRE consiste en apoyar el análisis de los requisitos que un sistema debe cubrir para satisfacer las necesidades del usuario.

QC, proporciona los medios para el aseguramiento de la calidad de los componentes de software desarrollados, con la finalidad de probar su funcionalidad, qué tan genéricos son, su dependencia funcional, su cohesividad, su acoplamiento, etcétera. AI utilizar esta

5


herramienta, se obtiene la medida de los atributos de calidad que permiten o no su usabilidad y su reusabilidad

S A M , es una hcrramienta que tiene como función, permitir la integración de todas las herramientas que forman cl ambiente AMASS, de manera que el usuario pueda interactuar con todas las herramientas de manera transparente entre una y otra.

1.3 Diseño Detallado Visual (DDVI)

DDVl es una herramienta que fue elaborada para resolver uno de los problemas que se presenta en el ciclo de vida del software: la falta de interés por parte de los desarrolladores en la fase de diseño, restándole importancia al hecho de realizar un diseño formal de sus sistemas que permita contar con un producto de software robusto y consistente [MAR97].

DDVI es un herramienta que proporciona un lenguaje visual para elaborar diseños detallados utilizando una notación basada en Wamier. Como todos los lenguajes visuales, DDVI tiene su propia gramática visual la cual permite la construcción de diseños de manera gráfica. Además es una herramienta que facilita la eliminación de una de las fases del ciclo de vida como es la generación de código, ya que realiza la generación de código de manera automática, basándose en el diseño elaborado.

1.3.1 Ventajas de DDVl

DDVI emplea un lenguaje visual que permite desarrollar sistemas de software, reduciendo significativamente la escritura de código fuente. A partir de la simple selección de símbolos en el espacio de la pantalla, DDVI genera el diseño detallado en un lenguaje de especificación visual (que incluye su propia gramática) y produce automáticamente el código en el lenguaje de programación C [LOP97].

El propósito de DDVI es apoyar a los desarrolladores de software en la definición de diseño detallado y proporcionar la generación automática del código de los sistemas, a partir del uso de representaciones visuales de fácil comprensión y manejo.

1.3.2 Deficiencias de DDVI

La gramática que se diseñó originalmente para DDVI incluye operaciones tales como la declaración de una función, llamada de una función, escritura en la pantalla, lectura desde el teclado, sentencias de selección simple, selección múltiple, selección simple negada, selección múltiple negada, así como sentencias repetitivas. Todas estas operaciones tienen una relación de correspondencia directa con una instrucción del lenguaje C [LOP97]. Desafortunadamente DDVI no incluye muchas de las instrucciones del lenguaje C en su gramática. Esto es debido a la limitación de los alcances del trabajo de tesis que dio origen a DDVI.

6


Uno de los aspectos básicos de un lenguaje de programación es el manejo de estructuras de datos. DDVI no incluye la definición y el manejo de estructuras de datos tales como arreglos, registros y archivos, ni tampoco el manejo de memoria dinámica.

Una de las deficiencias más marcadas de esta gramática es la falta de símbolos gráficos para utilizar operaciones básicas en el manejo de archivos.

1.4 Planteamiento del problema

La necesidad de entender, analizar y dar mantenimiento a código existente es algo que se encuentra palpable en cualquier actividad que esté relacionada a la ingeniería de software. Un ambiente integrado para la construcción de software debe contar con un método automatizado para la comprensión del código fuente, de la misma forma con que cuenta con métodos para la realización de las etapas del ciclo de vida del software. Sabemos que existen ambientes integrados de ingeniería de software, pero en realidad, ninguno cuenta con un módulo de ingeniería inversa que recupere el diseño detallado de un programa escrito en lenguaje C y lo presente utilizando la notación de diseño detallado de Warnier con una gramática visual como la de DDVI. La integración de una herramienta automatizada de análisis del software al ambiente de desarrollo de software AMASS dará la solución al problema que aquí se está planteando.

1.5 Justificación

El desarrollador de nuevos sistemas de software, gasta una gran cantidad de tiempo tratando de entender la estructura de sistemas similares y los componentes de los sistemas. La persona que se encarga de dar mantenimiento al software, gasta mucho tiempo estudiando la estructura del sistema para comprender la naturaleza y efecto de un cambio requerido en el software. En cada caso, el analista está involucrado en la recuperación del diseño. Por lo tanto, la recuperación del diseño es una parte común, y algunas veces una parte escondida, de muchas actividades que se dispersan a través del ciclo de vida del software [BIG89].

Los procesos de ingeniería inversa son muy útiles en todas las etapas del ciclo de vida de un producto de software. El costo de entender el software se manifiesta en el costo del tiempo requerido para entenderlo. La automatización de un proceso de ingeniería inversa podría reducirlo considerablemente [CHI90].

I .6 Hipótesis

Utilizar una herramienta de ingeniería inversa que permita vicualizar el diseño detallado de un programa, en forma estructurada, utilizando una notación sencilla y comprensible, como lo es la notación de Warnier, reduce el tiempo de análisis y comprensión del software para el mantenimiento de los sistemas.


1.7 Metodología de solución

La metodología de solución se basa en la creación de un modelo de ingeniería inversa que permita la obtención del diseño detallado de un programa fuente escrito en lenguaje C para expresado de manera visual en una notación de diseño detallado, y que además sea compatible con el sistema DDVI en cuanto a la simbología y el formato de sus diseños, para que pueda complementar el sistema. Debido a esto la notación que se utiliza para recuperar y mostrar diseño detallado es la notación Warnier y se utiliza la gramática visual de DDVI. La gramática de DDVI se describe en el anexo A de este trabajo de tesis.

Para lograr que DDVI cuente con la posibilidad de realizar ingenieria inversa fue necesario estudiar y analizar su metodología, sus estructuras de datos y la manera en como permite realizar diseños detallados visuales, todo esto con la finalidad de agregarle a esta herramienta la implementación del modelo de ingeniería inversa. Por lo tanto, la metodología que se utilizó en la creación del modelo de ingeniería inversa es muy apegada a la metodología de DDVI, lo que dio como resultado una sola herramienta llamada INVER-DDVI.

1.8 Alcance y Limitaciones

El presente trabajo pretende complementar al proyecto AMASS, extendiendo sus capacidades al integrarle una herramienta de ingeniería inversa que apoya a la etapa de mantenimiento del ciclo de vida del software.

Para lograr que el modelo de ingeniería inversa sea integrado a este proyecto, es necesario que exista compatibilidad con DDVI y para ello, se utilizó la gramática visual que se implementó en este sistema considerando solamente los elementos de la gramática del lenguaje C que maneja DDVI y la notación de diseño detallado de Warnier que es la notación que se seleccionó en esta herramienta de diseño detallado.

La gramática de DDVI, contempla las operaciones básicas del lenguaje de programación C, tales como: escritura en la pantalla, lectura desde el teclado, declaración de variables globales y locales, declaración y llamado de funciones, sentencias selectivas y sentencias repetitivas. La notación de Wamier tiene una simbología que permite representar gráficamente cada una de las operaciones que están incluidas en la gramática de DDVI.

Como parte de este trabajo se realizó una extensión a la gramática de DDVI, al agregar las operaciones básicas para el manejo de archivos: abrir, cerrar, leer y escribir.

1.9 Plan de exposición

Una parte importante en el desarrollo de cualquier trabajo de tesis es el estado del arte. El capítulo 2 describe las herramientas que realizan ingeniería inversa, junto con una

8


descripción de los modelos de ingeniería inversa propuestos por investigadores reconocidos en el campo de la ingeniería de software.

En el capítulo 3 se presentan el marco teórico sobre el cual está basado INVER- DDVI: los lenguajes visuales, los conceptos básicos de la ingeniería inversa, su definición, funcionalidad, importancia, y las áreas de aplicación.

El modelo de ingeniería inversa diseñado para DDVI está ilustrado en el capítulo 4, la arquitectura de INVER-DDVI es también parte de este capítulo, así como la metodología que se empleó para el desarrollo de esta herramienta de ingeniería inversa. Es aquí donde se analiza la extensión, que como parte de este trabajo de tesis se realizó a la gramática visual de DDVI. Se exponen las estructuras de datos, el formato de almacenamiento, el proceso de ingeniería inversa realizado por INVER-DDVI, y el diagrama de clases de esta herramienta.

Las pruebas experimentales y de evaluación que se le realizaron a INVER-DDVI, así como los casos de estudio que se utilizaron y los resultados de estas pruebas, se muestran en el capítulo 5 .

Y por último, las conclusiones de este trabajo se encuentran en el capítulo 6 , incluyendo las mejoras y los trabajos futuros que se prevén para la herramienta INVER- DDVI.

9

Estado del arte Capitulo 2

CAPíTULO 2

Estado del arte

Actualmente existen muchas herramientas en cl mercado que analizan el código fuente de los sistemas de software, escritos en diversos lenguajes de programación, para ayudar a su comprensión y facilitar así el objetivo de la reingenieria, que es: mejorar la calidad del software.

A continuación, se presentan las herramientas que están relacionadas con el trabajo de tesis que aquí se presenta:

10


2.1 RIG1 [RIG981

Rig¡ es un proyecto de ingeniería de software que ha sido conducido por investigadores del departamento de ciencias computacionales de la universidad de Victoria. El sistema Rigi es un editor gráfico interactivo que proporciona una representación gráfica de sistemas de software escritos en lenguaje C.

Rigi está enfocado a la ingeniería inversa, e incluye las siguientes fases: Extracción de los componentes del sistema y sus relaciones desde el código fuente para crear los recursos en diagramas de flujo. La fase de extracción es inicialmente automática e incluye un reconocimiento léxico del código fuente y el almacenamiento de los componentes extraídos (por ejemplo, tipos de datos, funciones, dependencias) en un depósitos especializados. El resto de la fase es semiautomática en el sentido de que requiere la intervención del usuario. Creación de subsistemas a partir de diagramas de flujo usando el editor gráfico. Las jerarquías de los subsistemas son construidos desde arriba, a partir del gráfico que representa el llamado inicial, para usar la metodología de la composición de los subsistemas y agruparlos en subsistemas compuestos. Estas jerarquías pueden ser documentadas como vistas, las cuales son instantáneas de vanos estados del proceso de ingeniería inversa. Evaluación de subsistemas por cohesión, emparejamiento e interacción, hasta que los subsistemas hayan sido creados satisfactoriamente.

La información obtenida al utilizar Rigi, es útil para identificar tanto partes del sistema a los cuales se les puede aplicar mantenimiento, como los módulos candidatos para reingeniena.

Esta información no le da una perspectiva al usuario de la herramienta de cómo reestructurar los módulos. Así mismo, los aspectos dinámicos de un sistema de software no son modelados en Rigi y además es dudoso en cuanto a como rendiría para lenguajes orientados a objetos.

2.2 IMAGIX 4D [1MA98]

Imagix 4D, ayuda a los desarrolladores de software a entender la complejidad de software escrito en lenguaje C o C++. Permite hacer ingeniería inversa y documentar el código para acelerar el desarrollo, mejoramiento, reuso y pruebas del software.

Imagix 4D permite revisar de manera rápida, o sistemáticamente estudiar un software a cualquier nivel, desde su arquitectura de alto nivel hasta mostrar algunos detalles de implementación para su construcción como clases y dependencias entre funciones. Es posible explorar visualmente un amplio rango de aspectos acerca del software, como estructuras de control, datos usados y herencia. Tiene la capacidad de crear automáticamente la documentación del diseño.

1 1

Capitulo 2 Estado del arte

Las vistas gráficas creadas por Imagix 4D, describen el software cada una desde un aspecto diferente. El usuario tiene la facilidad de eliminar información ajena y ver sólo la información que es relevante para la cuestión actual.

Con el editor de archivos de lmagix 4D, es posible “hojear” el código fuente, usando ligas de hipertexto entre las definiciones y el uso de funciones, clases, variables y tipos. Debido a la integración del editor con el resto de Imagix 4D, se puede controlar lo que se ve en la ventana gráfica desde el código fuente y viceversa.

Proporciona un amplio rango de despliegues complementarios, poniendo a disposición del usuario una serie de despliegues optimizados, que utilizan la visualización para proveer una rápida y exacta comprensión del software. Los despliegues trabajan junto con la navegación ligada y la sincronización.

La documentación automatizada de Imagix 4D también ayuda a generar documentos del diseño total, para todo el software propio o para el código que se ha heredado. Además de generar documentos ASCII, Imagix 4D puede generar archivos de salida en formato HTML y RTF.

Los diagramas que describen el diseño detallado del software analizado por Imagix 4D presentan las partes del software en forma de ramificaciones, lo que hace muy dificil la comprensión del código, ya que no cuenta con una simbología visual que lo facilite. Así mismo no utiliza una notación de diseño detallado para presentar el análisis del código.

2.3 P u l ANALYZER [STO981

Es una herramienta interactiva para dar mantenimiento y aplicar reingeniena a

PL/l Analyzer soporta: sistemas hechos en PL/I.

* Comprensión de la estructura del código * Análisis del impacto de los cambios * Redocumentación de aplicaciones * Evaluación y mejoramiento de la calidad del software

PL/l Analyzer analiza el código y genera árboles de sintaxis detallados. Estos árboles son utilizados para derivar abstracciones del código fuente. Las abstracciones típicas incluyen diagramas de flujo del control, diagramas de flujo de los datos, diagramas de estructuras y más. El punto más importante de estas abstracciones, es que muestran información acerca de los aspectos específicos del código fuente sin saturar al usuario con información irrelevante.

La herramienta proporciona una interfaz de ventanas para presentar diferentes abstracciones del código fuente y navegar del código actual a los árboles de sintaxis y a los diagramas de flujo.


La mayoría de los reportes disponibles en la herramienta, son representados como tablas. Esta forma tiene dos beneficios: primero, la presentación tabular y la navegación de los datos es familiar a la mayona de los usuarios, además de que reduce el tiempo de comprensión asociado a la herramienta; y segundo, los datos tabulares pueden ser fácilmente exportados al formato HTML o bien en ASCII.

Entre las deficiencias que presenta esta herramienta se encuentra el que solamente puede utilizarse en código escrito en PL/l, un lenguaje de programación que no es muy común ni tan popular como el lenguaje C y C++. Otra de las deficiencias es que no utiliza una notación de diseño detallado para ilustrar el diseño del código que analiza, ni tampoco lo hace de manera gráfica para facilitar su comprensión.

2.4 Modelos de ingeniería inversa

En los últimos años se han realizado muchas investigaciones acerca de la ingeniería inversa aplicada al software. Cada autor tiene una propuesta similar para la realización de esta actividad en el desarrollo y mantenimiento de sistemas. A continuación se muestran algunos modelos de ingeniería inversa con el punto de vista de cada autor acerca de este tema.

2.4.1 Modelo de ingeniería inversa propuesto por BREUER.

El nivel de abstracción de un proceso de ingeniería inversa y las herramientas que se utilicen para realizarlo, aluden a la sofisticación de la información de diseño que se puede extraer del código fuente. Idealmente, el nivel de abstracción sería lo más alto posible. A medida que crece el nivel de abstracción, se proporciona al ingeniero de software información que le permitirá una comprensión más sencilla de los programas.

La completez de un proceso de ingeniería inversa alude al nivel de detalle que se proporciona en un determinado nivel de abstracción. En la mayona de los casos, la completez decrece a medida que aumenta el nivel de abstracción, y mejora en proporción directa con la cantidad de análisis realizado por la persona que efectúe la ingeniería inversa [PRE98].

El núcleo de la ingeniería inversa es una actividad denominada extracción de abstracciones. El ingeniero tiene que evaluar el programa a partir del código fuente (que suele no estar documentado), y debe extraer una especificación significativa del procesamiento que se realiza, la interfaz de usuario que se aplica y las estructuras de datos de programa o la base datos que se utiliza.

13


I Código fuente "sucio" I

I

Especifica'o" final

4 Figura 2.1 Modelo de ingeniería inversa de Breuer [BRE91]

2.4.2 Modelo de ingeniería inversa propuesto por BOHNER.

El modelo propuesto por Bohner propone como primera actividad suministrar el código fuente a una herramienta de ingeniería inversa. Esta herramienta a través de un análisis estático, interpreta la estructura y la información del programa. Dicho análisis identifica cuáles son las variables usadas, los módulos llamados, las sentencias de control, el tamaño de los módulos, las llamadas a otros módulos con parámetros, etc. La información recuperada es descrita utilizando información textual y diagramas.

Los estándares de análisis estructurado y los métodos de diseño estructurado sirven como un buen mecanismo de comunicación para articular la información resultante de la ingeniería inversa. El diccionario de datos, los diagramas de flujo de datos, de flujo de control, y los diagramas de atributos-entidad-relación, son resultados típicos del proceso de ingeniería inversa[PFL9 I] .

Este modelo de ingeniería inversa al igual que la mayoría de los modelos, presenta dos problemas importantes: el primero aparece cuando se aplica a sistemas en donde el mapeo entre la implementación y el diseño es escaso, debido a la realización de frecuentes optimizaciones; el segundo problema ocurre, cuando sistemas extremadamente complejos son implementados con nombres de convenciones incomprensibles. Cuando un modelo de ingeniería inversa es aplicado a esta clase de sistemas, la información modelada que resulta es de un valor limitado.

14


Id 1 1 1 I=/ Código - Fuente

Figura 2.2 Modelo de ingeniería inversa de Bohner [BOH90]

2.4.3 Modelo de ingeniería inversa propuesto por Byrne . Este modelo de ingeniería inversa consiste en extraer información del diseño

detallado y sus abstracciones de alto nivel, a, partir del código fuente y de los documentos de diseño existentes. Esta información incluye una representación de la estructura, descripción de los datos y una descripción detallada de los procesos.

El proceso básico que se propone en este modelo es:

1 .- 2.-

3.-

4.-

5.-

6.-

1.-

8.-

Recolectar toda la información posible acerca del programa. Revisar y examinar esa información. Esto permite a las personas que hacen la recuperación del diseño, empezar a familiarizarse con el sistema. Identificar la estructura del programa y usarla para crear un conjunto de diagramas de la estructura, correspondiendo cada nodo de los diagramas de estructuras al llamado de una rutina en el programa. Reconocer la funcionalidad de cada nodo en los diagramas de estructuras, es decir, registrar el procesamiento realizado que corresponde a cada nodo. Reconocer el flujo de los datos. La estructura del programa recuperado puede ser analizada para identificar la transformación de los datos en el software. Reconocer el flujo de control identificando las estructuras de control utilizadas en el programa y construyendo los diagramas de flujo del control correspondientes. Revisar el diseño recuperado para asegurarse de la consistencia de la información y verificar que la representación del programa es correcta. Generar la documentación del diseño, explicando el propósito del programa.

15


Información del Nueva documentación

Nueva documentación

Revisar Información del diseño

Información del diSCao I \ \

Extraer información del flujo de datos y flujo dc control

Información del diseño detallado

Exiracr información de eslmclura v funcionalidad

Información del programa

Figura 2.3 Modelo de ingeniería inversa de Bvme rBYR911

Cabe mencionar que este procedimiento fue utilizado por el autor, para recuperar el diseño de un sistema implementado en lenguaje Fortran, y se realizó para implementar una nueva versión de ese sistema escrito en Ada [BYR91].

2.4.4 Modelo de ingeniería inversa propuesto por Biggerstaff . Las actividades propuestas para la recuperación del diseño de un sistema de

software en este modelo, están orientadas a programas escritos en un lenguaje estructurado como el lenguaje C. Para otro tipo de lenguajes como los lenguajes orientados a objetos, se requiere de una ligera variación de esta propuesta.

Establecer el M a p a de las abstracciones con CI código

Código del Idenlificacibn de Recuperar p,0gLWla módulos y grupos abstracciones

fuente de datos abstractas del diseño

I &BSTKACCIONES RECUPERADAS DE LOS COMPOWNTES IDEL DISESO 1

Figura 2.4 Modelo de ingeniería inversa de Biggerstaff [BIG891

16


El análisis se enfoca primeramente a la identificación de estructuras organizacionales, tales como la estructura de los subsistemas, la estructura de los módulos y las estructuras de datos importantes.

Posteriormente son recuperadas varias estructuras utilizadas en el diseño y son expresadas en formas abstractas tales como diagramas informales, diagramas para expresar conceptos y relaciones, diagramas de diseño racional, diagramas para representar la estructura de los módulos, así como también diagramas para la representación del flujo de los datos y del flujo del control.

Una vez obtenidas las abstracciones del diseño de un programa, el ingeniero de software deberá mantener las conexiones de las relaciones (el mapeo) entre varias abstracciones y los segmentos de código que el mismo implementó.

17

Capitulo 3 Marco teórico

CAPíTULO 3

Marco teórico

El marco teórico en el que está realizado este trabajo, son los lenguajes visuales y la ingeniería inversa. DDVI (Diseño Detallado Usual) proporciona un lenguaje visual que permite realizar un diseño de manera visual. La ingeniería inversa es una práctica que se lleva a cabo frecuentemente en el desarrollo y mantenimiento del software, por lo mismo existen ya varias formas de efectuarla.

A continuación, se hace una descripción del contexto teórico en el que se desarrolla este trabajo.

I8

Marco teórico Capitulo 3

3.1 Lenguajes Visuales

Los lenguajes visuales representan un paradigma diferente para expresar sistemas computacionales, porque a diferencia de los lenguajes convencionales, ofrecen la posibilidad de manipular directamente objetos gráficos en un espacio determinado en lugar de palabras, números y signos.

3.1.1 Definición

Los lenguajes de programación visual, son aquellos lenguajes que usan una representación visual (en adición a, o en lugar de, palabras y números), para llevar a cabo la implementación de un sistema. En un programa, una sentencia escrita en un lenguaje visual dado, consiste de un arreglo espacial de iconos. Los lenguajes visuales manejan iconos generalizados. Un icono generalizado es un objeto con la representación dual de una parte lógica (el significado) y una parte física (la imagen).

Un lenguaje visual modela un sistema de iconos. En un sistema de iconos, un programa consiste de un arreglo espacial de símbolos pictóricos. El arreglo espacial es la contraparte bidimensional de la secuenciación estándar, en la construcción de programas para el caso de los lenguajes de programación tradicional [CHAgI].

La diferencia entre un lenguaje de programación tradicional y un lenguaje de programación visual, radica en las reglas de producción de sus gramáticas. En un lenguaje de programación tradicional un programa es expresado como una cadena de texto, en la cual los símbolos terminales se van concatenando. Como esta operación es la única regla de construcción, no aparece explícitamente en el vocabulario de la gramática del lenguaje. En contraste, en el caso de los lenguajes visuales, se utilizan tres reglas de producción para acomodar espacialmente los iconos. Estas tres reglas de producción corresponden a los siguientes operadores espaciales: concatenación horizontal, concatenación vertical y cobertura espacial [CHA91]. Por esta razón es necesario incluir tanto a los operadores espaciales como a los iconos elementales, en el vocabulario de los símbolos terminales de la gramática de un lenguaje visual.

3.1.2 Aplicaciones

La especificación de lenguajes es uno de los tópicos centrales de la ingeniería de software, y el número de lenguajes que son visuales va incrementándose. Es indiscutible que los lenguajes visuales son un elemento esencial en la comunicación humano-humano y humano-computadora. Las investigaciones sobre los lenguajes visuales se han llevado a cabo desde muchos diferentes enfoques: ciencias computacionales teóricas, inteligencia artificial, psicología cognoscitiva, lingüística y la última, pero no menor, en áreas de aplicación como la arquitectura, el diseño y las artes.

19


Sin embargo, el impacto de la representación formal de los lenguajes visuales en aplicaciones del mundo real es todavía limitado.

Las áreas de aplicación de los lenguajes visuales puede ser agrupadas en dos categorías [MEY98]:

' * Interpretación de medios de bajo nivel: - reconocimiento de manuscritos - reconocimiento del diseño - procesamiento de imágenes

a Interfaces gráficas de usuario: - - soporte del diseño -

interpretación de entradas de usuario

bases de datos visuales y base de datos multimedia

La aplicación de este trabajo de tesis, se encuentra incluido en el área de reconocimiento del diseño. En algunos trabajos de investigación realizados[MEY98], el conjunto de expresiones reconocibles sólo es una pequeña parte del área aceptable en el diseño de esquemas, esto es, no existe una gramática que identifique todos los lenguajes de esquemas interpretables. En su lugar, el objetivo es procesar partes de la entrada para construir objetos compuestos, sin requerir necesariamente una interpretación del esquema completo.

3.2 Notación de diseño detallado de Warnier

La notación de diseño de Warnier fue creada por Jean D. Warnier. Se trata de un método para la representación de programas cuyo resultado final se denomina diagrama de Warnier. Este método se basa en el empleo de llaves de distintos tamaños que relacionan entre si todas las tareas y las operaciones de un programa [ALC92]. En este método un programa se representa por un solo diagrama en el cual se engloban todas las operaciones necesarias para la resolución de un problema. Estas operaciones están colocadas secuencialmente a la derecha de una llave, en cuya parte izquierda figura el nombre del programa. En la parte superior de la llave anterior figurará el comentario INICIO, y en la parte inferior la palabra FIN. La forma de conectar con distintas páginas es a través de la palabra PROCESO seguido de un número o un nombre que tenga relación con las operaciones que se realizan. En los diagramas de Warnier sólo se utilizan las estructuras básicas de la programación:

secuencia selección repetición

Una estructura secuencia1 es una estructura con un inicio y un fin, en la cual aparecen una serie de acciones cuya ejecución es lineal y en el orden en que aparecen. Una acción representa una operación sencilla, por ejemplo un incremento, una suma, una asignación, etc., o un proceso de cualquier tipo. En esta estructura las acciones se sitúan a la derecha de la llave y desde arriba hacia abajo, según el orden de ejecución.

20


La representación para la estructura secuencia1 es la siguiente:

( I a l a v e z ) i A B

( I a la vez) l I C ( I a la vez)

Una estructura de selección es aquella donde se realiza una acción de entre varias. Puede ser alternativa simple, doble o múltiple; y la acción se realiza según el cumplimiento de una condición.

(0-1 vez)

CONDlClON B L o - 1 vez)

Una estructura repetitiva está representada por un conjunto de acciones que se ejecutan varias veces, aquí tenemos tres tipos:

PARA : Se indica el número de repeticiones por una variable de control indicando sus valores inicial y final, así como el incremento cuando este sea distinto de 1.

(N veces) o decremenlo de la vañable de control

Condicib inicial

PROCESO

* CondiciOn de salida

MIENTRAS : La acciones se repiten hasta que se cumple una condición, y la condición se evalúa antes de cada repetición.

CondiciOn inicial

PROCESO


HASTA : Las acciones se repiten hasta que se cumple una condición que se evalúa después de cada repetición.

Modifica la variable de control

* Condición de salida

Condición inicial

PROCESO

Los diagramas de Wamier utilizan llaves y anidamientos que relacionan todas las estructuras básicas, y la representación de un algoritmo es por medio de un sólo diagrama que contiene todas las operaciones, las cuales están colocadas secuencialmente a la derecha de una llave, y además cualquier algoritmo tiene solamente un inicio y un fin.

3.3 Ingeniería Inversa

La ingeniería es el análisis, diseño, construcción, verificación y administración de entidades técnicas. El software es la entidad en la que se centra la ingeniería dei soffware. La ingeniería del software proporciona el proceso para construir y desarrollar el software de manera adecuada. El proceso de desarrollo del software se divide en tres fases genéricas: definición, desarrollo y mantenimiento, y son independientes del área de aplicación, tamaño o complejidad del proyecto.

La fase de definición es aquella en la cual se identifica la información que será procesada, la función y el rendimiento deseados, cuál será el comportamiento del sistema, las interfaces que van a ser establecidas; las restricciones de diseño que existen y los criterios de validación necesarios para definir un sistema correcto.

La fase de desarrollo se realiza cuando el ingeniero del software define el diseño de las estructuras de datos, la implementación de una arquitectura del software y sus detalles procedimentales, la caracterización de las interfaces, la traducción del diseño a un lenguaje de programación y la realización de las pruebas.

La fase de mantenimiento está enfocada ai cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entomo del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente [PRE98].

La ingeniería inversa consiste en llevar a cabo el proceso inverso a la ingeniería del software, que se puede aplicar en cualquier fase del desarrollo de software o en cualquier nivel de abstracción, y puede ser empleado efectivamente en puntos estratégicos durante los

22


procesos de desarrollo del software [CHI90]. Por ejemplo, se puede extraer del código fuente la información suficiente para recuperar el diseño detallado del sistema en un nivel de abstracción mayor, obviamente lo más alto posible.

Un proceso de ingeniería inversa debe ser capaz de obtener las representaciones de diseño de procedimientos y la información de programas de estructuras de datos, modelos de flujos de datos y de control, y modelos de entidades y relaciones. A medida que crece el nivel de abstracción, se proporciona al ingeniero de software información que le permitirá una mejor comprensión de los programas[PRE98].

3.3.1 Definición de ingeniería inversa

El término ingeniería inversa tiene su origen en la tecnología del hardware y denota el proceso de obtener la especificación de un sistema complejo de hardware. Aplicado al software, todavía no se conoce una definición estándar del término ingenieria inversa pero Chikofsky y Cross [CHI901 la definen de la siguiente manera:

"La ingeniería inversa es el proceso de analizar un sistema para identificar sus componentes y sus interrelaciones y crear una representación del sistema en otra forma o en un mayor nivel de abstracción "_

Los procesos que tienen como propósito rediseñar, reestructurar y mejorar la funcionalidad de un sistema, no están incluidos dentro del alcance de la ingeniería inversa [CHI90]; todos estos procesos forman parte de la reingeniería del software .

3.3.2 Funcionamiento de la ingenieria inversa

La ingeniería inversa no es una actividad en la cual se llevan a cabo cambios al sistema, o en la que se realiza un nuevo sistema basado en aquel al que se le aplicó un proceso inverso para su análisis. Es una actividad de "examinación" y entendimiento del software y no de cambios o réplicas.

La figura 3.1 muestra cuáles son las diferencias entre la ingenieria de software tradicional, la ingeniería inversa y la reingeniería. La ingenierÍa de software es un proceso tradicional que parte de la definición de requerimientos, para después realizar una abstracción a alto nivel de la solución del problema como es el diseño y, finalmente llevar a cabo la implementación fisica de un sistema. La ingeniería inversa como ya se mencionó, sólo es un proceso para analizar la implementación de un sistema, identificando sus componentes y creando una representación del sistema a un nivel de abstracción mayor. La reingenieria es el análisis y alteración de un sistema, para reconstruirlo de nueva forma y

23


ingenieria tradicional

ingenieria inversa .................................

rrrWnri6" drl di-0

reingenieria

ingenieria tradicional

................................. .................................

ingenieria

.................................. ............................... -

.................................. ~ C " ~ r i r i 6 " drl diseno

............................ ................................ - ................................ .................................

reingenieria

Figura 3.1 Diferencias entre términos del desarrollo del software

realizar la implementación de esa nueva forma. La reingeniería generalmente incluye algunas formas de ingeniería inversa, seguidas de algunas formas de ingeniería tradicional, de esta manera incluye modificaciones con respecto a los nuevos requerimientos no especificados en el sistema original[CHI90].

3.3.3 Importancia de la ingeniería inversa

Realizar un proceso de ingeniería inversa tiene un costo, en términos de tiempo y esfuerzo, herramientas de software utilizadas, entrenamiento, etc. Sin embargo, los beneficios de utilizarla son muchos.

Durante el proceso de realización del software y posteriormente en su mantenimiento es importante tener una comprensión del sistema, de tal manera que se conozca cuál es su comportamiento, los elementos que lo conforman, qué datos maneja, cuál es el flujo de los datos, etc. Es inevitable aplicar la ingenieria inversa en estas dos actividades.

Cuando se aplica ingeniería inversa es muy útil visualizar el sistema a un nivel de abstracción mayor al que proporciona el código de los programas. La representación de un sistema a niveles altos de abstracción es más compacta que los niveles bajos de abstracción y esto hace que la comprensión se facilite. Representar los objetos que forman parte de los sistemas facilita también el mantenimiento de los mismos.

Una de las ventajas que proporciona la ingeniería inversa es que propicia el reuso del software, al detectar fácilmente las irnplementaciones que no cambiaron después del mantenimiento. Además facilita la documentación del mantenimiento de los sistemas, las modificaciones pueden ser controladas y las abstracciones obtenidas de un sistema proporcionan un vehículo adecuado para diseñar el plan de pruebas [ZUY93].

24


3.3.4 Áreas de aplicación

Una de las actividades más importantes de la ingeniería inversa de software es la extracción de abstracciones. La persona encargada de realizar el mantenimiento de un sistema tiene que evaluar el código existente y a partir de éste (que habitualmente no esta documentado), tiene que extraer una especificación significativa del procesamiento que realiza, las estructuras de datos que contiene, la interfaz de usuario que se aplica y la base de datos que se utiliza. De ahí que podemos definir básicamente tres áreas de aplicación del proceso de ingeniería inversa[PRE98]: Ingenieria inversa para comprender el procesamiento, ingeniería inversa para comprender los datos, e ingeniería inversa de interfaces de usuario. A continuación describiremos cual es cada una de estas áreas.

Ingeniería inversa para comprender el procesamiento. La primera actividad real de la ingenieria inversa comienza con un intento de comprender y extraer abstracciones de procedimientos que representen el código fuente. De esta manera se establece un contexto para su posterior análisis y se proporciona una idea general acerca de los problemas que pudiera presentar un sistema. El análisis del procesamiento se plasma en una abstracción funcional con un elevado nivel de detalle y por medio de diagramas de bloques se representa la interacción entre las diferentes abstracciones funcionales que se analizan. En algunos casos ya existen especificaciones del sistema al que se le aplicará mantenimiento. Cuando esto sucede se revisan las especificaciones para determinar si se ajustan al código existente.

Ingeniería inversa para comprender los daios. La ingeniería inversa de datos suele producirse en distintos niveles de abstracción. A nivel de programa es frecuente que sea necesario realizar una ingeniería inversa de las estructuras de datos de cada programa como parte de un esfuerzo global de reingeniena. A nivel de sistema es frecuente que se efectúe una reingenieria de las estructuras globales de datos (por ejemplo archivos, bases de datos) para ajustarlos a otros paradigmas de programación.

Ingeniería inversa de interfaces de usuario. Antes de que sea posible reconstruir una interfaz de usuario, es necesario que se lleve a cabo un actividad de ingeniería inversa. Para comprender en su totalidad una interfaz de usuario existente, es preciso especificar la estructura y el comportamiento de la interfaz, determinando cuáles son las acciones básicas que debe procesar y cuál es la descripción compacta de la repuesta del sistema a estas acciones.

3.3.5 Ciclo de vida del software

La figura 3.2 ilustra el paradigma del ciclo de vida clásico para la ingeniería del software, algunas veces llamado ”modelo de cascada”. El paradigma del ciclo de vida exige un enfoque sistemático y secuencia1 del desarrollo del software que comienza en el nivel del sistema y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento.

25

Capítulo 3 Marco teórico

Ingeniena del sistema

t l h Análisis

I I

I I

Figura 3.2 Modelo de cascada del ciclo de vida del software.

Creado a partir del ciclo de vida convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades[PRE90]:

Ingeniería del sistema. Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. Análisis. El proceso de recopilación de los requisitos se centra e intensifica especialmente para el software. Para comprender la naturaleza de los programas que hay que construir, el ingeniero de software ("analista") debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas. Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle de procedimientos y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software que puede ser establecida de forma que se obtenga la calidad requerida antes de que comience la codificación. Al igual que los requisitos, el diseño se documenta y forma parte de la configuración del software. Codificación. El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. Pruebas. Una vez que se ha generado el código comienzan las pruebas del programa. Las pruebas se centran en la lógica interna del software, asegurando que todas las instrucciones se han probado, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

o

26


Mantenimiento. El software indudablemente sufrirá cambios después de que se entregue al cliente. Los cambios ocurrirán debido a que se hayan encontrado errores, a que el software deba adaptarse a cambios de entorno externo, o debido a que el cliente requiera ampliaciones funcionales o de rendimiento.

A continuación se analiza la etapa de mantenimiento, debido a que es en esta en donde, mayormente, se aplican los procesos de ingeniería inversa.

3.3.6 Mantenimiento del software

El mantenimiento del software es una tarea que sin duda se llevará a cabo en todos los productos de software diseñados, y es que es innegable que pueden contener errores y además, el entorno que rodea a un sistema está cambiando constantemente y por lo tanto las necesidades y requerimientos del software también. -

Definimos el concepto de mantenimiento del software de acuerdo a la definición ANSI-IEEE [ZUY93] como sigue:

"El mantenimiento del software es la modificación de un producto de software despuis de haber sido entregado para corregir errores, mejorar su rendimiento u otros atributos, o adaptar el producto a los cambios del medio ambiente".

Es importante mencionar que el mantenimiento preventivo está incluido dentro del alcance de esta definición, esto es, modificar el software desde el momento de su realización para mejorar algunos de sus atributos tales como calidad, mantenibiiidad, etc. También hay que hacer notar que el mantenimiento del software está muy relacionado con la evolución del sistema, y con los constantes cambios en los requerimientos de usuario (mantenimiento perfectivo) [ZUY93].

La ingeniería inversa es una actividad que se realiza constantemente en esta etapa del ciclo de vida del software y representa a una parte de las tareas que se llevan a cabo en el mantenimiento de los programas.

2 1

. . Arquitectura de INVER-DDVI Capitulo 4

CAPíTULO 4

Arquitectura v desarrollo d e INVER-DDVI

4.1 Introducción

El punto de referencia para el trabajo que aquí se presenta es la herramienta DDVl (Diseño Detallado Visual), que es una herramienta que nos permite realizar el diseño detallado de un programa utilizando la notación de Wamier y una gramática visual que nos permite construir diseños de software de manera gráfica, para posteriormente generar el código en lenguaje C que corresponde a éstos.

28

Capitulo 4 Arquitectura de INVER-DDVI

En base a DDVI se ha creado INVER-DDVI, por medio de un modelo que se instrunienta en DDVI para efectuar un proceso de ingeniería inversa. Este proceso se realiza utilizando la metodología de DDVI y todo su entorno para lograr la representación de un programa escrito en lenguaje de programación C, en un nivel de abstracción mayor.

4.2 Modelo Conceptual

Cuando se desarrollan sistemas de software, en la mayoría de los casos no se elabora diseño previo, lo cual hace dificil intentar evaluarlo para su posible modificación o actualización, sin que se presenten complicaciones. El presente trabajo, presenta un modelo de ingeniería inversa implementado en un sistema de recuperación de diseño detallado, para la notación de Warnier. INVER-DDVI fue creado a partir de un modelo conceptual, ilustrado en la figura 4.1, que posteriormente originó el modelo de ingeniería inversa sobre el cual está basada esta herramienta. Se utiliza como plataforma de desarrollo la herramienta DDVI, la cual forma parte del ambiente ixtegrado de software AMASS.

.......... .......... .......................

Código en C Modelo de ingenieria inversa Diseño detallado expresado

en notación de Warnier

Figura 4.1 Modelo conceptual d e INVER-DDVI

La intención de este trabajo de tesis, es contar con una herramienta de software que realice el análisis de un código fuente escrito en lenguajc C, aplicando un modelo de ingeniería inversa en donde se reconozcan los tokens que corresponden a las operaciones del lenguaje C que se pueden reconocer con la gramática de DDVI, asociar estos tokens con los elementos gráficos de diseño correspondientes, y finalmente generar el diseño en el formato correcto para que pueda ser desplegado por la herramienta de diseño detallado visual DDVI.

4.3 Enfoque del proceso de ingenieria inversa de esta tesis.

Un proceso de ingeniería inversa cotidianamente es aplicado a un producto de software cuando es evaluado. A partir del código fuente se tiene que extraer una

29


especificación significativa del procesamiento que realiza [BYR91]. Este proceso puede ser automatizado, generando una herramienta de software que realice el análisis de un programa fuente y recupere las abstracciones del diseño, utilizando una simbología para representar los datos, el flujo de los datos, el flujo del control, las relaciones entre los elementos del programa, las operaciones, etc.[PRY961. Esto es precisamente lo que sc logra hacer con el modelo que se presenta a continuación, el cual permite traducir un lenguaje de bajo nivel como el lenguaje C a un lenguaje de mayor nivel como lo es una representación visual, en este caso la notación de Wamier.

La Figura 4.2 ilustra el diagrama que muestra el modelo de ingeniería inversa diseñado para recuperar el diseño detallado de un programa utilizando la notación de Wamier en DDVI.

. . . Código Fuente ~.

.~ o . . . , . . .: .... AL/_ ..

1 .~ .Eitraei ..

inforkaciób del.' ! . . ñujo.de. dit$ y,. .. ' flujo ile:control . . .. :;. _.

I :,..., . ~ .~~-. . . . .

. .,. ,. ....

. . . 1 . . Leer i0rmato.y

desplegar en :. pantalla , ,

DDVl .i, . . .

Figura 4.2 Diagrama del modelo dc ingenieria inversa de DDVI

Trabajando en la herramienta DDVI, es posible abrir un archivo fuente que contenga el código que se analizará. Una vez que es abierto se puede proceder a realizar el proceso

30

http://ujo.de

Arquitectura de INVER-DDVI Capitulo 4

de ingeniería inversa de ese sistema. El sistema de recuperación del diseño basado en el modelo de ingeniería inversa de MVER-DDVI, hace un análisis de la estructura del programa, identificando la función principal (main) y sus componentes(funciones), para después hacer una búsqueda de cada uno de ellos en el resto del programa. Obviamente, una parte implícita y esencial de este modelo es un algoritmo de parseo, que va reconociendo los elementos sintácticos del programa escrito en lenguaje C. Gracias a este algoritmo se pueden recuperar los tokens del programa que forman parte del diseño.

Un aspecto importante de este modelo es que extrae la información de los datos utilizados y del flujo que siguen dentro del sistema, es decir, cuáles son las variables que se utilizan en el programa (globales y locales), reconociendo su tipo y su tiempo de vida; así como las instrucciones que definen el control del programa, estableciendo el camino de ejecución del mismo. Todos estos elementos del programa que se van reconociendo, son depositados en una estructura de datos auxiliar, que se utiliza para ir reuniendo todos los componentes que formarán parte del diseño detallado.

Una vez identificado cada elemento del programa se le asocia el símbolo visual correspondiente de la gramática de DDVI, para iniciar el proceso de recuperación de las abstracciones del diseño, por ejemplo: a cada definición de una llamada, se le asigna el símbolo de definición de llamada, a cada sentencia repetitiva se les asigna el símbolo que le corresponde, y así sucesivamente.

La información obtenida de este proceso es almacenada en la estructura de datos que utiliza DDVI para almacenar el diseño de cada programa. Una vez que se logra ésto, se puede desplegar el diseño obtenido dentro del ambiente de DDVI.

4.4 Elementos de la arquitectura

En la figura 4.3, se representa gráficamente a los elementos de la arquitectura de INVER-DDVI.

El cuadro que encierra a la mayoría de los elementos de la arquitectura representa el programa ejecutable. El cuadro que posee la leyenda Archivo. &fitor ,..., representa el marco principal del programa, este marco contiene la vista relacionada con un documento, los datos de dicho documento están administrados por una lista de datos, el cual a su vez es vigilado por un conjunto de reglas.

El usuario interactúa con la Vista y con el Marco. El generador de código de DDVI toma los datos del diagrama para producir el código fuente del diseño elaborado y el código del diseño detallado. Cada diseño, es decir, cada diagrama, es una entidad lógica y física de datos que se guardan en un archivo. Estos datos constituyen el documento del programa [PAROO].

La adición que se le hace a esta herramienta es: un Reconocedor de tokens que iiiteractúa con el código fuente de un programa escrito en lenguaje C, una estructura de Árbol en donde se insertan todos los elementos del programa analizado para representarlos

31

Arquitectura de INVER-DDVI Capitulo 4

t a

Figura 4.3 Arquitectura de INVER-DDVI

en una forma más abstracta, y un procesador cuya función es la de convertir la estructura de árbol en una lista, de manera que pueda ser utilizada por la herramienta DDVI para desplegar el diseño del programa. Esto último es la base para lograr el proceso de ingeniería inversa en DDVI.

4.5 Extensión de las capacidades de DDVI

Como una parte complementaria de este trabajo se realizó una extensión a la gramática de DDVI, agregando las instrucciones básicas para el manejo de archivos. Esta extensión es presentada y explicada en puntos posteriores de este mismo capítulo.

Las operaciones que se agregaron son las siguientes: abrir archivo, cerrar archivo, escribir sobre el archivo, y leer desde el archivo. AI igual que las demás operaciones de la gramática de DDVI, estas operaciones tienen también una correspondencia con una instrucción del lenguaje C para el manejo de archivos.

32


4.6 Metodología de INVER-DDVI

INVER-DDVI es una herramienta que consiste de un analizador, cuyo trabajo es procesar un archivo que contiene el código de algún programa escrito en lenguaje C. Este sistema reconocedor realiza un análisis de todas las palabras contenidas en el programa fuente, reconociendo aquellas que forman parte de la gramática de DDVI.

Una vez que reconoce una instrucción del lenguaje C que puede ser representada por un símbolo gráfico, esta instrucción es almacenada en una estructura de árbol, la cual permite formar el “esqueleto” del diseño que será presentado en pantalla de manera gráfica.

Cuando se ha analizado todo el código y una vez que se tienen todos los elementos gráficos, son depositados en una estructura de datos en forma de lista ligada que utiliza DDVI. Esta lista ligada es la base de todos los diseños que se realizan en esta herramienta. El diseño detallado extraído del programa analizado se despliega en el marco de DDVI en base a la estructura de datos.

4.6.1 Estructuras de datos

Las estructuras de datos que son utilizadas en esta metodología son dos: un árbol cuya estructura no es binaria y que es utilizado para el reconocimiento de tokens y componentes sintácticos; así como una lista ligada que se encuentra implementada en DDVI para guardar todos los símbolos gráficos de un diseño detallado.

En los puntos sucesivos se describen ampliamente cada una de éstas estructuras de datos.

4.6.2 Almacenamiento de componentes sintácticos

El sistema reconocedor de tokens está implementado en una clase llamada CReconocedor, la cual incluye 2 atributos que son instancias de otras dos clases: CArbol y Token. Cuando se analiza un programa para aplicarle ingeniería inversa se utiliza la clase CArbol, para ir almacenando los elementos sintácticos del código en lenguaje C que pueden ser representados por un símbolo gráfico de la gramática visual de DDVJ.

r----- class Token (

public: string nombre; TIPO tipo;

1;

class CArbol (

public:

struct nodo{ string nombre; int símbolo; stmct nodo *sig; S ~ N C ~ nodo ‘ant; stmct nodo *hijo;

1;

33


Esta clase es una estructura de datos en forma de árbol n-ario que permite definir el esqueleto del programa analizado. Esto se logra mediante los apuntadores *sig, *ani y *hqo. El apuntador *sig contiene la dirección de los elementos sintacticos que se encuentran en el mismo nivel. *hijo contiene la ubicación de los elementos que forman parte de un bloque de instrucciones y se utiliza para el caso de declaración de funciones, instrucciones de selección múltiple y anidamientos. El apuntador *ant define a quien corresponde el conjunto de instrucciones que de ahí se derivan. También contiene el nombre del token que se va a representar y la clave ;ti simbolo de la gramática de DDVI. La figura 4.4 ilustra un ejemplo de esta estructura de datos, tomando como base el segmento de código que se muestra a continuación:

include <stdio.h>

void Prueba() { in1 i..i,nl,n2; char Opcion:

for (i=O; Opcion='s';j++) { BuscaMin(n I ,n2): for(i=l;nl=n2:iH){

if(ni >n2)( printf(Wumero mayor:"); printr("YW'.nl); )

else( printf("desea salir?[sin]"); scanf("%c",Opcion); )

) I

)

Fig. 4.4 Ejemplo del análisis que realiza INVER-DDVI.

34


La clase Token se utiliza para almacenar, durante la ejecución del parser, a todos los elementos de la gramática y el tipo de símbolo gráfico al que corresponde .

El reconocedor de tokens está formado por cuatro procedimientos para llevar a cabo el reconocimiento de todas las instrucciones que pueden ser ilustradas gráficamente en pantalla a través del marco de DDVI. El método Procesa recorre cada una de las lineas del programa fuente en C y va analizando cada una de las palabras contenidas en él.

class CReconocedor { public: CArbol miarbol; Token token;

public: void procesa (CArchivo miarchivo); int compara(Token token); void incluye (Token token, int simbol2); void Imprime-Resultados (CLevissDoc' pDoc);

I

Cada palabra se Compara con la gramática de DDVI, y si se encuentra en ella, entonces se Incluye en la estructura de árbol que contiene el esqueleto del programa analizado. Una vez que finaliza el análisis del archivo que contiene el programa fuente, Imprime - Resuliados traduce la estructura de árbol a una lista ligada de símbolos para poder ilustrarse en pantalla.

4.6.3 Formato de almacenamiento

El almacenamiento de componentes sintácticos en el proceso de ingeniería inversa es el mismo que se utiliza en DDVI, de esta manera se logra la compatibilidad entre el trabajo que aquí se presenta con la herramienta. El formato de almacenamiento está determinado por CSimbolo, la clase que contiene la lista de los elementos del diseño detallado.

El diagrama del diseño recuperado se almacena en un archivo de tipo texto, cuyo nombre es el mismo del programa fuente en C pero con una extensión .dis [PAROO].

A continuación se presenta la definición de esta clase:

35


class CSimbolo : public CObject {

DECLA-SERIAL(CSimbo1o); public:

CString mDescrip; in t mNivel; CRect mRect; int mNurnSimbolo; int mNumPadre; int mEspacio; CPoint mCoord; UR'IT mNumBitmap;

CSimbolo(); -CSimbolo(); void Dibuja(CDC *dc); void EscnbeDescnp(CDC *pDC); void Serialize(CArchive& ar);

1;

4.6.4 Gramática visual de DDVl

Muchos formalismos han sido propuestos para describir el analizador sintáctico de los lenguajes visuales. Pero para la formalización de esta gramática se han utilizado los conceptos básicos que utiliza Chang [CHA95].

DDVI está soportado por una gramática posicional libre de contexto, cuyo diseño está basado en una serie de elementos gráficos que representan las operaciones más básicas del lenguaje C. La descripción de esta gramática no es parte del trabajo que aquí se presenta, por lo tanto se incluye en el apéndice A de este documento.

4.6.5 Extensión de la Gramática visual de DDVl

La gramática de DDVI incluye sólo las operaciones básicas del lenguaje C, una de las carencias de esta gramática es la falta de símbolos gráficos para el manejo de archivos. AI analizar las operaciones que realiza el lenguaje C para manipular los archivos se diseñaron cuatro símbolos gráficos, estos símbolos representan cuatro de las instrucciones que incluye el lenguaje.

Las operaciones que se agregaron son las siguientes: fopen. fclose, @fprin!L Y fscanf

36


Existen vanas operaciones de entrada y salida de datos en el manejo de archivos, la razón por la cual fueron escogidasfprintffl yfscanffl es muy clara si hacemos un análisis de la sintaxis de estas instrucciones: el parámetro que utilizan es sólo una cadena de texto.

FILE * fopen ( char *nombre-archivo, char *modo ) int fclose ( FILE *pa ) int fprintf( FILE *pa, char * cadena formateada ,.....) int fscnnf ( FILE *pa, char * cadena formateada ......)

El sistema de ingeniería inversa realiza el análisis de palabras completas tomadas del código fuente, por lo tanto las instrucciones que pueden ser representadas gráficamente son éstas.

La correspondencia entre instrucciones y símbolos de la gramática es la siguiente: fopen0 es el símbolo de Abrir, fclose0 es representado por el símbolo Cerrar, fprintf() es la simbolización de Escribir y por úItimofscanf0 simboliza a Leer.

La figura 4.5 ilustra los símbolos gráficos que se incluyeron en la gramática de DDVl para el manejo de archivos.

I I n €3

n Escribir

€3 Abrir Cerrar Leer

Figura 4.5 Extensión que se realizó a la gramática de DDVI.

Las reglas de producción para estas instrucciones fueron elaboradas respetando la gramática posicional de DDVI, cuya explicación se da en el anexo A de este documento, y se muestran a continuación:

<FSCANF> ’ ARRIBA’ ABAJO‘ <APUNTADOR>’ DERECHA’

“variable”‘ IZQUIERDA4 <ISNTFUN>’

37

Capítulo 4 Arquitectura de INVER-DDVI

4.7 Proceso de ingeniería inversa

El modelo de ingenieria inversa que se diseñó y que se plantea en el capítulo 3 de esta tesis, describe la parte conceptual del proceso de ingeniería inversa que realiza INVER-DDVI. Con la explicación a detalle de cada uno de los módulos más importantes del sistema se especifica cómo es que se aplica este modelo a la herramienta DDVI. La figura 4.6 muestra cómo es que interactúan las clases que forman el sistema de INVER- DDVI.

Es en la clase CReconocedor en donde se concentra el control del sistema. A través de su método Procesa, se abre el archivo fuente que contiene el código que se va a analizar y con el método ObfieneToken de la clase CArchivo, se obtienen las palabras que contiene el código. El método Compara de la clase CReconocedor realiza una comparación entre los tokens que se encuentran y las instrucciones que contiene la gramática de DDVI. De pertenecer a dicha gramática, el token obtenido se inserta en la estructura de árbol que contiene el sistema, de esto se encarga el método Incluye.

CReconocedor

CArchivo

CReconocedor

CArchivo

Q.. CToken I Diseno detallado I

CSimbolo .... ..................... CArbol

Código en C

Fig. 4.6 Diagrama del proceso de ingenieria inversa de INVER-DDVI

Por último, el método IrnprimeResulfados recorre la estructura de árbol y deposita cada uno de los elementos que se encuentran en ella, en la lista ligada que utiliza la clase CSimboIo, así es posible mostrar el diseño que se recupera en el mismo formato de almacenamiento de los diseños que se hacen en DDVI.

38


4.8 Diseño

En los puntos anteriores de este capítulo se han explicado por partes las clases más importantes de la herramienta INVER-DDVI. En este punto se ilustra el diagrama de clases del sistema y las relaciones correspondientes. La parte del diagrama que se encuentra encerrada con lineas punteadas constituyen las clases principales de INVER-DDVI. El diagrama de la figura 4.7 representa el modelo estático orientado a objetos de la herramienta y está realizado utilizando la notación de diseño orientado a objetos UML [OMG97].

.._ ..

~~

~

CArbOI

Q aux : simct nodo 1 &actual : ~lrucl noda * Qraiz : struci nado * 1 &dallaves : in1 I

l--.~.; ' *Posicianl"icial() ~

*arbolvacio () : Integer *inreria () . void *siibcarbol () : void i

ImpriineResullador () !

-_I LkbtenNodo () 1

. . Q Fin Archivo()

Fig. 4.7 Diagrama de clascs de INVER-DDVI

Las clases de la arquitectura documento-vista están formadas por CLevissApp, CLevissView, CLevissDoc, CMainFrame y CChildFrame, las cuales se utilizan para dividir de una manera lógica las funciones de un programa tipico de Windows. CLevissApp representa la clase que define al programa ejecutable como un objeto, se encarga de iniciar el sistema e integra las demás clases. La clase CLevissView se encarga de visualizar el

39


diagrama y define la interacción con el usuario. La clase CLevissDoc representa el documento que contiene los datos que se visualizan a través de la ventana. La clase CMainFrm se utiliza para contener a las ventanas y es el principal marco de la aplicación, también contiene al menú y la barra de herramientas. CChildFrm es la clase que contiene a las instancias que representan las ventanas de uno o varios diagramas.

Estas clases fueron revisadas y adaptadas para complementar la nueva funcionalidad de la herramienta DDVl que se realizó en esta tesis. Particularmente la clase CLevissDoc que contiene la estructura de datos original del sistema, a partir de la cual se visualiza el diagrama en una ventana. Las modificaciones realizadas fueron con la intención de que la herramienta tuviera la capacidad de llenar la estructura de datos en base a otra estructura de datos tipo árbol que se utilizó para el reconocimiento del código fuente, de tal manera que el árbol se vacía en la estructura de datos original para que se desplegara de acuerdo al mecanismo de la arquitectura documento-vista de la aplicación. Las clases que se adicionaron para tal efecto son CArbol, CReconocedor y CArchivo.

Este diagrama constituye la arquitectura de INVER-DDVI, y muestra como está conformado el sistema. Las clases que no han sido explicadas aquí forman parte de la MFC de Visual C++.

40

Capitulo 5 Pruebas Experimentales

CAPíTULO 5

Pruebas Experimentales

Las pruebas efectuadas a un software son un ejemento importante para garantizar su calidad. No es raro que cuando se desarrollan sisten!¿; se emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en probar el software. El trabajo de tesis que aquí se presenta fue probado con tres casos de prueba que son expuestos a continuación.

5.1 Casos de estudio

Las pruebas que se realizaron con esta herramienta consistieron en utilizar el modelo de ingeniería inversa propuesto y aplicarlo a tres programas escritos en lenguaje C. El código fuente de los programas y los diseños recuperados fueron mostrados a diez personas que

41


tienen conocimientos básicos en programación del lenguaje C y en la notación de diseño detallado Warnier. Las personas seleccionadas para la prueba fueron divididas en dos grupos de 5 personas cada uno, al primer grupo se les presentó el código fuente de los programas seleccionados y ai segundo grupo los diseños recuperados con INVER-DDVI. Cada una de las personas de cada grupo analizó los tres casos de estudio de la prueba realizada. La entrega de los programas y los disefios recuperados se hizo de manera simultánea y a partir de ese momento se tomó el tiempo que les llevo a cada grupo el entender cuál era la función de cada programa.

A continuac.ión se ilustran los programas que fueron analizados en este experimento enumerando el número de caso presentado. En el punto siguiente de este capítulo se presenta el diseño detallado recuperado con INVER-DDVI de cada uno de los casos de estudio.

Caso I : include <stdio.h> void Prueba() ( int i j ,nl ,n2; char Opcion;

for (j=O; Opcion='s'j++) { BuscaMin(n1 ,n2);

for(i=l ;nl=n2;i++){ if(n1 > n2)(

printf("Nurner0 mayor:"); printf("%d",n I ) ; I

else{ printí("desea salir?[sín]"); scanf("%c",Opcion);

I 1

Caso 2 : #include <stdio.h> char cad[20], cad1[20]; int i = O ;

LEER CAD (char *cade, char *cadel){ gets(cade1); for (i=O;cadel[i];i++) (cadel[¡] = toupper(cadeI[i]); ] printf ("cadena 2 : "1; gets (cade);

I main()(

cirscr(); LEER-CAD (cad,cadI); printf("La cadena 2 es %s :n",cad); printf("La cadena I es %s \n",cadl);

42


Caso 3 :

for (i=strlen(cadI)-I; ¡>=O;¡--) { printf ("%c",cadl [i]);

getch(); I

#include <conio.h> #include <stdlib.h> #include <stdio.h> #!include <ciype.h> #include <string.h>

void otro-num(void); busca(void); int menu(void);

main(void) { char opcion;

do { opcion =menu(); switch (opcion) {

break;

break;

case 'a': otronum();

case 'b: buscar();

1 }while (opcion!='t'); return O;

I nienu (void){

char c;

do { printf("(A)ñadir, (B)uscar o (T)enninar: "); c=tolower(getche()); printf("\n");

}while (c!='t'&& c!='a' && c!='b'); return O;

I void otronum(void){

FILE *fp; char nombre[80]; int prefijo, num;

if ((fp=fopen("teIef',"a"))==NULL) { printf ("NO se puede abrir el archivo b"); exit(1);

printf("1ntroduzca un nombre y un número: "1; fscanf(stdin, "%s%d%d%d", nombre, &prefijo, &num); fscaní(stdin, "%*c"); fprintf (fp, "%s %d %d %din", nombre, prefijo, num);

fclose(fp);

43


)

void buscar(void) {

FILE ' f p ; char nombre[80], nombre2[80]; int prefijo, num;

if ((fp=fopen("telef',"r"))==NULL) { printf ("NO se puede abrir el archivo in"); exit( I ) ;

I printf("nombre?"); gets (nombre);

while (!fopen(@)){ fscanf(stdin, "%s%d%d%d", nomhre2, &prefijo, h u m ) ; if (!strcmp(nombre, nombre2)) {

printf ("%s: (%d) %d;%din", nombre, prefijo, num); break;

I I fclose(@);

f

5.2 Aplicación de INVER-DDVI

El caso 1 de esta prueba es un programa de 19 líneas de código y recibe 2 números enteros desde el teclado para determinar cuál de los dos es mayor. El diseño visual recuperado se ilustra en la figura 5.1.

El caso 2 es un programa de 22 líneas de código y realiza la conversión de una cadena a mayúsculas para posteriormente imprimirla de manera invertida. Las figuras 5.2 y 5.3 muestran el diseño detallado visual para el caso 2.

El programa del caso 3 contiene 77 líneas de código, fue realizado para crear y mantener un directorio telefónico en un archivo de disco. En este programa también se pueden hacer búsquedas de números telefónicos. Se seleccionó este programa para el caso 3 debido a que contiene instrucciones para el manejo de archivos. Las figuras 5.4, 5.5, 5.6, y 5.7 muestran el uso de INVER-DDVI para obtener el diseño detallado de este tercer caso.

44


i -

U

- Prueba

* I 1,n1=n2:i*t

{'= '

Fig. ,5.1 Diseño detallado visual del caso I .

45


i= o PSC

-

U

1 L E E R - C A D cad.cad1

f / “La cadena 2 es %s \n”.csd G

’‘La cadena 1 es %s \n”.cadl

id obi- a)uda p”m F1 r m r - , Fig. 5.2 Diseño detallado visual del caso 2 (primera parte).

46


0 I ü,cadel[i];irr {.= ' iI*LI

loupper cadel [il

"cadena 2 : *'

U A= Paia &ma airda pioh F1 r m r I

Fig. 5.3 Diseño detallado visual del caso 2 (segunda parte).

47

Pruebas Experimentales Capitulo 5

....~ ~ _ ~ ~ ~ _ ~ ~ ~ ~

Fig. 5.4 Diseño detallado visual del caso 3 (primera parte).

48


menu void 1 D T ; I

49


I - "NO se pucdc abrir el archivo \n"

\ 2'f 'Introduzca un nombre y un número: '* 5 p stdin, '%s%d%d%d", nombre, 8prelijo. h u m

€3

%tdin"wl'

P lp, '96s %d %d M n " , nombre, prefijo, num

buscar void 2 0 2

gf- "NO sc puede abrir CI archivo \da f I , exit 1 1 .r

Fig. 5.6 Diseño detallado visual del caso 3 (tercera parte).

50


g/ "NO se puede abrir cI archivo \n" ( <

gets nombre

llopcnpp

'%r%d%d%d", nombrc2, 8prefijo. 8num

Fig. 5.7 Diseño detallado visual del caso 3 (cuarta parte).

5.3 Resumen y evaluación de resultados

Esta prueba experimental fue realizada con el objetivo de determinar si la utilización de la herramienta de ingeniería inversa que se presenta en este trabajo de tesis reduce el tiempo de análisis y comprensión del software para el mantenimiento de los sistemas, y de esta manera hacer válida la hipótesis planteada en este trabajo de tesis.

La prueba se aplicó a dos grupos de personas a las cuales se les asignaron los tres casos de estudio planteados en este capítulo. El primer grupo analizó los programas sin la

51


herramienta INVER-DDVI y el segundo grupo analizó los programas utilizando la herramienta.

Es necesario mencionar que la prueba fue limitada en cuanto al número de programas analizados debido a la naturaleza de la prueba misma, el número de personas que intervinieron y también en lo que se refiere a la consideración de otros factores cuyo control y medición podría resultar mucho más complejo. Estos factores son: la experiencia de las personas como programadores, su capacidad de comprensión y su disposición para realizar la prueba.

Una vez que se han hecho las aclaraciones pertinentes se presenta la siguiente tabla de resultados, que muestra el tiempo en minutos que cada persona se tardó en comprender cada programa que se le presentó:

645

CON LA HERRAMIENTA

52


El tiempo promedio con la herramienta resultó menor que el tiempo promedio sin la herramienta, resultando una diferencia de 37.8 minutos. Esto significa que las personas que realizaron la prueba con la herramienta INVER-DDVI utilizaron 37.8 minutos menos que aquellos que no utilizaron la herramienta; lo que deriva en una disminución del tiempo de comprensión de los programas estudiados del 29.30% que equivale a la proporción de la diferencia sobre el tiempo promedio del grupo que no utilizó la herramienta. La desviación resulta de la diferencia entre el tiempo promedio para cada grupo y el tiempo total de comprensión de los tres programas de cada persona. En general, la desviación nos muestra que el nivel de preparación y conocimientos de las personas que participaron en la prueba es muy similar.

53

Conclusiones Capitulo 6

CAPíTULO 6

Conclusiones

6.1 Conclusiones

Utilizar la herramienta MVER-DDVI que permite visualizar el diseño detallado de un programa fuente escrito en lenguaje Co en forma estructurada, utilizando una notación sencilla y comprensible, como la notación de Warnier, reduce el tiempo de análisis y comprensión del software para el mantenimiento de los sistemas.

54

Conclusiones Capitulo 6

El .análisis de un sistema de software presentado en un nivel de abstracción relativamente alto, permite a los desarrolladores de software comprender en un menor tiempo que es lo que realiza un programa, pero mas importante aún, cómo es que lo hace, La aportación que hace este trabajo de tesis al campo de la ingeniería de software es facilitar la comprensión de programas escritos en lenguaje C, al aplicar un modelo de ingeniería inversa.

Esta herramienta aplica un método de la ingeniería de software que apoya a los desarrolladores en lenguaje C, en la obtención de un diseño bien estructurado y entendible, haciendo que los sistemas sean fáciles de mantener. Para los casos en los que no exista un diseño documentado de los sistemas INVER-DDVI proporciona el diseño detallado de manera automática, facilitando así parte de la documentación de los sistemas.

A diferencia de otras herramientas de ingeniería inversa que existen, INVER-DDVI genera diagramas que describen el diseño detallado del software que analiza utilizando una simbología visual y la notación de diseño detallado de Warnier que facilita la comprensión de los programas.

Utilizando "VER-DDVI, el análisis de un programa escrito en lenguaje C se hace más sencillo y por lo tanto se reduce el costo de entender el software.

Aunque INVER-DDVI fue creada para analizar código fuente escrito en lenguaje C cuyo paradigma de programación es procedural, podría utilizarse para analizar y recuperar por separado el diseño detallado de los métodos de un programa escrito en lenguaje C++.

El agregar a la gramática de DDVI las operaciones básicas para el manejo de archivos que se emplean en el lenguaje C hace más completo el trabajo que realiza INVER- DDVI, ya que los diseños que recupera son más completos.

Debemos entender que un ambiente integrado para la construcción de software, debe contar con un método automatizado para la comprensión del código fuente, por otro lado, la necesidad de entender, analizar y dar mantenimiento al código existente, está siempre latente en cualquier actividad que esté relacionada con la ingeniería de software. INVER- DDVI ofrece la posibilidad de realizar ingeniería inversa y se logra un ambiente de desarrollo mucho más completo.

6.2 Trabajos futuros

A continuación se hace una lista de los posibles trabajos a realizar que ampliarían los beneficios de esta herramienta:

Reconocer y visualizar el resto de los elementos de la gramática del lenguaje C, es decir ampliar la gramática de INVER-DDVI. Desde su creación, la gramática de DDVI sólo contempló las operaciones básicas del lenguaje C. En este trabajo se realizó una extensión a dicha gramática agregando las operaciones para el manejo de archivos, pero existen muchas más instrucciones del lenguaje C que podrían ser

55

Capitulo 6 Conclusiones

implementadas en la gramática visual, y por lo tanto también ser reconocidas por INVER-DDVI.

Además de los programas en lenguaje C, podría aplicarse ingeniería inversa a programas escritos en otros lenguajes de tipo procedural. Esto se lograna construyendo un analizador reconocedor de tokens, como el que se utilizó para el lenguaje C, para cada lenguaje.

Agregar a INVER-DDVI la capacidad de analizar código fuente con un enfoque orientado a objetos, es decir, aplicar ingeniería inversa a código escrito en C++.

Completar la herramienta como una herramienta de ingeniería bidireccional (Round trip Engineering).

56

BIBLIOGRAFIA

[ALC92]

[BIG891

[BOH90]

[BE911

[BYR91]

[CHA95]

[CHA91]

[CHI901

[IMA98]

[LOP961

[LOP971

[MAR971

Alcalde Eduardo, Garcia Miguel, Metodología de la programación, 2”. edición, McGraw Hill, 1992.

Biggerstaff Ted J., “Design Recovery for Mantenance and Reuse”, IEEE Computer, July 1989, p. 36-49.

Bohner S.A., Technology Assessment on Software Reengineering, Contel Technology Center Technical Report CTC-TR-90-001P, (Chantilly, Virginia), February 1990.

Breuer, P.T.y K. Lano, “Creating Specification From Code: Reverse- Engineering Techniques ”, Journal of Software Maintance: Research and Practice, Volumen 3, Wiley, 1991, pp. 145-162.

Byme Eric J. , “Software Reverse Engineering: A Case Study“, Software- Practice and Experience, Vol. 21, December 1991, pp. 1340,1349-1364.

S.K. Chang and Gennaro Costaggliola, “Visual Languages System for Users Interfaces ”, IEEE computer society, V01.2 No.2, March 1995.

S.K. Chang, Tortora Genoveffa, VISUAL LANGUAGES AND VISUAL PROGRAMING, “Structure and interpretation of visual languages“, 199 1.

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

Imagix Corporation. htto://www.imaeix.com

López Sánchez Máximo [et AI] . “Desarrollo formal de una gramática visual para un lenguaje de programación ”, Simposium Internacional de Computación, México, Octubre 1996.

López Sánchez Máximo [et AI] , “Especificacion formal de un lenguaje de programacion visual para desarrollo de diseño detallado de Warnier ”, Conferencia Internacional Ciencia y Tecnología para el Desarrollo, La Habana, Cuba, Marzo 1997.

Martinez R. Alicia, Generador de código para lenguaje C utilizando una notación de diseño detallado, Cuernavaca,Mor., Centro Nacional de Investigación y Desarrollo Tecnológico, Agosto de 1997.

10 de diciembre de 1998

57

http://htto://www.imaeix.com

[MEY98] Meyer Bernd, Marriot Kim, Visual Lenguage Theory, 1". Edición, New York, U.S.A., 1998, pp. 57-59.

Objects Management Groups., UML Summary versión 1.1, USA: OMG, 1997.

[OMG97]

[PAROO] Parra Ramirez Isaac A., Modelado Visual orientado a objetos, Cuernavaca, Mor., Centro Nacional de Investigación y Desarrollo Tecnológico, Diciembre del 2000.

Pfleeger Shari Lawrence, Software Engineering, The production of Qualiy Soffware, Second Edition,New Jersey, USA, Prentice Hall, 1991,

Pressman Roger S., Ingeniería de Soffware, Un enfoque práctico. Tercera edición; Madrid España: Mc Graw Hill, 1990.

Pressman Roger S., Ingeniería de Software, Un enfoque práctico. Cuarta edición; Madrid España: Mc Graw Hill, 1998 p.461.

Prywes Noah, "Recovering Design and Specificaiiond from Source Code ", IEEE Software, November 1996, pp.109-111,114.

Departamento de Ciencias computacionales, Universidad de Victoria, CANADA. httr>://www.ri~i.csc.uvic.ca/rigi/riei.html 10 de diciembre de 1998.

López S. Máximo, Santaolaya S. René, Fragoso D. O h i a , "AMASS: Ambiente integrado de Soporte para la Administración y Desarrollo de Sistemas de Software", Centro Nacional de Investigación y Desarrollo Tecnológico, Sección de Ingenieria de Software, Mayo del 2000.

Sanders Mark S. [y] McCormick Ernest J., Human Factors in Engineering and Design. (Seventh Edition; USA: McGraw-Hill, Inc., 1993) p.4.

Software Technology Group of Planet Earth Projects, Inc. htto://www.stout.ievtech.com

Zuylen H.J.van, The REDO Compendium, Reverse Engineering for Soffware Maintenance, Lugar, JOHN WILEY &SONS, 1993.

[PFL91]

[PRE90]

[PñE98]

[PRY961

[RIG981

[SANOO]

[SAN931

[STO981 11 de dicienbre de 1998.

[ZUY93]

5 8

http://htto://www.stout.ievtech.com

ANEXO A

GRAMÁTICA VISUAL DE DDVI

Muchos formalismos han sido propuestos para describir el analizador sintáctico de los lenguajes visuales. Pero para la formalización de esta gramática, se han utilizado los conceptos básicos que utiliza Chang [CHA95].

DDVI esta soportado por la gramática posicional libre de contexto que a continuación se describe.

La gramática se compone de una tupla de seis elementos G = (N, T, S, P, POS, PE )

donde N = símbolos no terminales T = símbolos terminales S = símbolo inicial P = reglas de producción POS = Relaciones binarias de identificadores PE = Es una evaluación pictográfica que convierte formas de instrucciones en sus representaciones visuales.

Los símbolos no terminales definen conjuntos de cadenas que ayudan a generar el lenguaje generado por la gramática. También imponen una estructura jerárquica sobre el lenguaje que es útil tanto para el análisis sintáctico como para la traducción.

N = { <S>. < VAR>, <PARAMETROS>. <DECFUNCION>, <SENTENCIAS>,

<INSTFUN>, <INSTSEC>, <IFCOMP >, <SWICHT>, <FOR>, <WHILE>. <PRINTD, <SCANF>, <LLAMADA>, <TXTC>, < CONDCICLO>,

<DOWHILE>, ]

Los terminales son símbolos básicos con que se forman las cadenas. Algunos de los símbolos terminales no son gráficos, debido a que dentro de la notación de diseño, existe también texto que sirve para complementar al diseño.

“Nombre función”, “Nombre variables”, “cadena”, ‘ }

En la formalización de la gramática G a todos los símbolos terminales gráficos se les ha asignado un subíndice que indica cual es su significado en cada una de las reglas de producción. Existen símbolos terminales con un solo significado, y por ello estos símbolos tienen como subíndice el numero cero. Tales símbolos son los siguientes:

59

En una gramática, un no terminal es considerado como símbolo inicial, y el conjunto de cadenas que representa es el lenguaje definido por la gramática. En la gramática G el símbolo inicial esta representado por la letra S.

Las producciones de una gramática especifican como se pueden combinar los terminales y los no terminales para formar cadenas. Cada producción consta de un no terminal seguido por una flecha, seguida de una cadena de símbolos no terminales ylo terminales.

Las gramáticas posicionales son una extensión de las gramáticas lineales, por lo tanto se agregan nuevas características a las reglas de producción P. La forma general de las regias de producción de una gramática visual es la siguiente:

n . . A x ' ~ ~ R J , x ~ , ~ R J ~ x ' w i . . . ~ J , ~ " w n ,

Donde i = 1,2,3,4, ..., n y A es un símbolo no terminal, cadaX", puede ser un símbolo terminal o no terminal, el superíndice i identifica cada objeto (icono o texto) en las regias de producción. El subíndice w es escrito después de cada símbolo terminal gráfico y es utilizado para identificar su significado.

Rj es una relación compuesta de la forma:

( R E L ~ ~ ' ,..., REL?' ,..., EL)) con n>=l

Cada REL? denota un par (REL,,hi) donde REL; es una relación en POS denotando las relaciones posicionales que tiene un objeto respecto a otro; hi muestra el objeto con el cual se tiene relación, el valor de hi se obtiene de 2-k en donde j corresponde al valor secuencial que tiene el símbolo gramatical actual y k corresponde al valor secuencial que tiene el símbolo gramatical con el cual se relaciona.

Un ejemplo de una regla de producción de DDVl es el siguiente:

DfCfUuN C=, l1 ABNdl 'hombre funriod2 DERECHk2 <i"S7ipUCC7NES>3 ABNdi 40

De esta regla de producción la relación que tiene el símbolo no terminal <INSTRUCCINES>3 se encuentra a la DERECHA con respecto al símbolo terminal

donde el superíndice 1 en el símbolo terminal , representa el valor de posición secuencial con respecto a la regia de producción, por lo tanto la relación con el símbolo <INSTRUCCINES>3 estará de la forma 2 REL A" en dondej=3 y kl porque el valor secuencial del símbolo con el cual se va a relacionar es 1, por lo tanto la relación quedana DERECHA '-I.

.60

El s ímbolon representa a las reglas semánticas dentro del compilador espacial [MAR97].

Relaciones cuádruples de los identificadores (POS).

Cada símbolo tiene relaciones cuádruples con respecto a los demás identificadores, estas relaciones ubican al objeto dentro de un plano cartesiano de 2-D con respecto a otros objetos, estas relacione son ARRIBA, ABAJO, DERECHA e IZQUIERDA. Cada una de estas relaciones son un par de coordenadas que muestran , que es lo que se encuentra alrededor de un objeto, además de identificar la posición en la que se encuentra dentro de la pantalla. El término POS de la gramática posicional en la que está basada DDVI se refiere a estas relaciones. Por ejemplo, las relaciones para la regla de producción descrita anteriormente son:

Este ejemplo muestra los símbolos terminales y los no terminales de la regla de producción junto con las relaciones que existen entre estos.

Evaluador pictográfico (PE).

PE es un evaluador pictográfico donde se encuentran las reglas semánticas que se utilizarán dentro del compilador, aquí se definen las posiciones que deberá tomar cada objeto de acuerdo a la relación que tenga con los demás objetos, a diferencia de un compilador lineal donde se encuentran las direcciones para el generador de código.

Es importante mencionar que la gramática de DDVI no hace uso de este evaluador pictográfico que forma parte de todas las gramáticas posicionales, ya que esta herramienta cuenta con un mecanismo propio que determina las posiciones que deberá tomar cada objeto de acuerdo a la relación que tenga con otros objetos.

REGLAS DE PRODUCCI~N .

E = SIGNIFICA VACIO

<S> i, <VAR> <S> I DECFUNCION <S> I E

<VAR> i, nombre variables <VAR> I E

<PARAMETROS> i, nombre parametros <PARAMETROS> I E

61

I ABAJO’ “nombre funcion” ’ DERECHA2 <SENTENCIAS>’ <DECFUNCION> i, I 4 ABAJO’ mom

<SENTENCIAS> i, <PRINTF>’ABAJO’ <SENTENCIAS> ’ -o= ’ I

<SCANF>’ABAJO’ <SENTENCIAS> -0- ’ I <LLAMADA>’ ABAJO’ <SENTENCIAS> ABAJO’ =o= ’ I

ABAJO’ SENTENCIAS>^ =O= I <CONDCICLO>’ ABAJO’ <SENTENCIAS> ’ I E

TEXTO1

<PRlNTF> 4 .w G I ARRIBA‘ <INSTSEC> ’ DERECHA’ “cadena”’ IZQUIERDA’ <INSTFWD4 I e/ 6 ’ ARRIBA‘ <INSTSEC> DERECHA’ “variable”’ IZQUIERDA’ <INSTFUN>’

<SCANF> @I ARRIBA’ <INSTSEC> ’ DERECHA2 “variable”’ IZQUIERDA’ <INSTFUN>4

‘ 1 ABAJO’ “nombre funcion” ARRIBA’ <INSTSEC>’ IZQUIERDA’ <CONDCICL0>4

DERECHA’ “cadena” ’ <TXTC> - “Y ‘

<CONDCICLO> <IFCOMP>’ ABAJO’ <CONDCICLO> I <SWICHT>’ ABAJO’ ICONDCICLO>’ I <WHILE>’ ABAJO’ <CONDCICLO> * I DO WHILE>^ ABAJO’ <CONDCICLO>~ I <FOR>’ ABAJO’ <CONDCICLO> ’ I E

<INSTFUN> i,

62

<IFCOMP> i, $& ‘ 1 ARRIBA’ <INSTSEC>’ ABAJO’ “Condicion”’ DERECHA’ <SENTENCIAS4

IZQUIERDA4 <INSTFUN>’ mom ‘ I O 0 ,::,; ‘ I ARRIBA’ <INSTSEC>’ ABAJO’ “Condicion”’ DERECHA’ <SENTENCIAS>4

10’1 ‘ ABAJO’ i@$ ’1 ABAJO’ "Condition"* o DERECHA’ <SENTENCIAS9 IZQUIERDA4 <INSTFUN>” ABAJO‘ mom ‘I

<SWICHT> 4 @ ‘I ARRIBA’ <INSTSEC>’ ABAJO’ “Condicion”’ DERECHA’ <SENTENCIAS4

ABAJO’ “Condicion”’o DERECHA’ <SENTENCIAS>“ IZQUIERDA4 <INSTFUN>“ ABAJO’ =o113 I E

IZQUIERDA4 <INSTFUN>‘ mom ’ ABAJO’ <SWICHT>* ;&?-.

<FOR> ’ I ARRIBA’ <INSTSEC>’ ABAJO’ “Condicion”’ DERECHA’ <SENTENCIAS4

ABAJO’ mom ’ IZQUIERDA’ <INSTFUN>6

<WHILE> d # ‘2 ARRIBA’ <INSTSEC>* ABAJO’ “Condicion”’ DERECHA’ <SENTENCIAS>4

ABAJO’ mom IZQUIERDA’ <INSTFUN>‘

I 3 ARRIBA’ <INSTSEC>’ ABAJO’ “Condicion”’ DERECHA’ <SENTENCIAS4 <DOWHILE> i )

ABAJO’ m o i IZQUIERDA’ <INSTFUN>6

63

Documents

cenidet Martha Fabiola... · obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis. Atentamente