CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO … Jose... · Centro Nacional de Investigación y Desarrollo TeciioIOgico ACA1)EMIA DE CIENCIAS COMPUTACIONAI,E.S Cuerriavaca Mor.,

SEP SEIT DGIT

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO

cenídet

PROCESADOR GRAFICO PARA AUTOMATIZAR LA LEGIBILIDAD DE CODIGO FUENTE PARA UN INTEGRADOR DE COMPONENTES REUSABLES

TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS

EN CIENCIAS COMPUTACIONALES

PRESENTA JOSE FRANCISCO CARPI0 TOVILLA

ASESOR M.C. RENE SANTAOLAYA SALGADO

CUERNAVACA, MORELOS NOVIEMBRE DE 1997

Centro Nacional de Investigación y Desarrollo TeciioIOgico

ACA1)EMIA DE CIENCIAS COMPUTACIONAI,E.S

Cuerriavaca Mor., a 20 dc octu.hre de 199’7

I l r . Juan Maiiuel Ricaíío Castillo Dircctor del CENIDET P r c c e 11 t c

Ai‘ii: l l r . José Ruiz Ascencio Jefe del Ilpfo. de Ciencias Coiiipiii:icioiiales

Nos cs grato coiiioiiicarle. qiie conroriiie a los liiicmiiiciiios csi:ildccid»s p m i la obtcncióii del grado de Maestro en Ciencias en Ciencias Coiiiput5cioiialcs de este Centro. y después de Iiriher sometido a rcvisióii académica el irabajo de tcsis dei-toininado:

“Proccs:itlor g:‘áficn para automatizar la Icgil>iliil:itl <IC cGtligo fiicnfc p:tr;i iin inicgtxtlor (IC componcntes reitsal>lcs”

qiic prcscntó el liig. José Francisco Carpio Tovilla, y Iiabieiitlo ciiiiipliclo con 1,~ilas las cnnecciones que le fiicroii indicadas, acordamos no tener objeci6ii para qiie se le conceda iri

aiiioriiiacióii dc iiiipresióii de la tesis, así como de fijar la fecha del evaiiicli correspoi!dietiie. . . . .

Sin nihs por e l nioinetito. quedainos de usted.

A t e i i t a ni e ii t e Comisión de revisióii de la tesis

_ _ _ ~ M.C. Hugo Esira<la Isquivel

Dirccior dc ICSiS

Cuernavaca. Mol a 7 de novienibie de 1097 Oficio CCS-036/97

lng. José Francisco Carpio Tovilla Candidato a l grado de Maestro en Ciencias cn Ciencias Cotnpiitacioiiales Presente I

Después de haber revisado SLI expedieníe escolar y consuier;iiido que ciiiiiple con los liiicaniiciiios esial)lecitlos CII el reglaiiietilo acadéiiiico para In oh[eiii.itiii (le!. g x k i tic Macsíro eri Ciciicins qiie ofrece esie Cciiiro, tile es gi-ato coiiiiiiiicnrle qcic. sc le. ciiiicedc la aiitorizacióti para q i e proceda a la iinpresibii de su tesis. Api-oveclio para iriJ:h:irle qiie dcherá acordar con los mienibi-os del jiirado la fecha y la llora de prcseniacihir del examen dc gi~ado.

Reciba inis felicitaciones por el termino de sii'trabajo de íesis.

4 . ,

AAitatnente w- Ur. Jose Ruiz Ascencio

cenidet

DEDICATORIAS

AGRADECIMIENTOS

Agradezco a mi esposa Ana Linda Pineda Méndez porque creer en mí, por comprenderme y darme su ayuda incondicional, gracias a su apoyo he logrado alcanzar esta meta que tanto esperaba.

Expreso mi más sincero agradecimiento al Centro Nacional de Investigación y Desarrollo Tecnológico por darme la oportunidad de estudiar nuevamente la Maestría en Ciencias Computacionales y continuar el proyecto de tesis.

Agradezco a mi asesor M.C. René Santaolaya Salgado por su apoyo, orientación y tiempo dedicado para lograr terminar el trabajo de tesis, y sobre todo, por su amistad.

Agradezco al Dr. Javier Ortiz Hemández por toda la ayuda y palabras de aliento que siempre me ha brindado, además gracias por tu amistad.

Agradezco al Dr. José Ruiz Ascencio por todo el apoyo brindado.

Agradezco al M.C. Máximo López Sánchez y a la M.C. Oiivia Fragoso por la ayuda y orientación brindada, y sobre todo por su amistad.

Agradezco al grupo de Ingeniería de Software: Teresa, Carlos, Susana, Mima, Liliana, Marco, Jesús, Martha, gracias por todo el apoyo. Muy especialmente agradezco a Hugo, Alicia y Leticia, por toda la asesoría y por su amistad que me brindaron, siempre los recordare como unos grandes amigos.

Agradezco a todos mis profesores del Cenidet por sus conocimientos brindados

Agradezco a los profesores al Dr. Guillermo Rodriguez, al M.C. Hugo Estrada y al M.C. Reynaldo Alaniz porque con SUS comentarios y correcciones hicieron un mejor trabajo.

AGRADECIMIENTOS

Reconozco y agradezco el apoyo económico brindado por (CONACYT) para lograr ia terminación de mis estudios de Maestría en Ciencias Computacionales. . ,

1,. ' , . I

.. . Agradezco sinceramente al Instituto Tecnológico de Zacatepec por darme todo el apoyo '' .. necesario para continuar estudiando y obtener el titulo en Ciencias Computacionales.

Agradezco a una gran persona, al M.C. Gerard0 M. Lara Orozco por todo el apoyo y comprensión que me dio durante el desarrollo de este trabajo. Gracias por confiar en mí.

Agradezco mucho a mis compañeros de trabajo del Departamento de Sistemas y Computación del Instituto Tecnológico de Zacatepec: Alejo, Carlos, Armanda, Enrique, Cartujano, Ofelia, Mario, Noemí, Alejandro, Muñiz, Claudia, Gama, José A, Antonio, Gabriel, Dr. Bustamente, Chagolla, Roberto, Teresa, Madaí, Isabel, Guadalupe, Boris, Norma R. Gracias por darme el apoyo para continuar preparándome y fortalecer con mis estudios a la Academia.

Agradezco profundamente el apoyo del C.P. Raúl Trujillo Escobar y la L.I. Donají Sedano Flores, por todas las facilidades que me dieron para el desarro110 de este trabajo.

TABLA DE CONTENIDO

Lista de Figuras ....................................................................................... iv Lista de Tablas ......................................................................................... vi

Capítulo 1. INTRODUCCION A LA REINGENIERIA 1 DE SOFTWARE ..................................................

. r 1.1 Introduccion ....................................................................................... 2 3 1.2 Tecnologías de la Reingeniería de Software ..................................... 4 1.2.1 Entendimiento del Software .....................................................

1.2.2 Mejoramiento del Software ..................................................... 4

4 Sistemas: Un Caso de Estudio ................................................... : ...... 1.3 La Reingeniería de Software reduce el mantenimiento de

Capítulo 2. PLANTEAMIENTO DEL PROBLEMA Y PROPUESTA DE SOLUCION 8 .............................

9 10 10 10 11 20 20

. . I 2.1 Descripcion del problema ..... : ............................................................ 2.2 Propuesta de solucion ........................................................................

2.2.1 Objetivo de la tesis ...................................................................

2.2.3 Formas de representar código gráficamente ............................

. I

2.2.2 Beneficios de la tesis ................................................................

2.2.4 Notación seleccionada para representar código gráficamente 2.2.5 Reingeniería de datos para mejorar el código .........................

Capítulo 3. CONCEPTOS SOBRE VISUALIZACION DE SOFTWARE ......................................................... 22

. I 3.1 Introduccion ....................................................................................... 23 23

3.2.1 Representacion Textual ............................................................ 23 24 3.2.2 Representacion Gráfica ............................................................

3.3 Estrategias de visualización .............................................................. 24 25

3.5 Estado del arte en herramientas de visualización ............................. 28

3.2 Representación Textual vs. Gráfica .................................................. . r

.,

3.4 Expresión visual como medio de comunicación ...............................

I

3.5.1 Caso de estudio para “mejorar la representación visual de . . 28 .. codigo ................................................................................... 3.5.2 VIASOFT’S VIA/Renaissance ................................................ 37

Capítulo 4 . METODO PARA MEJORAR LA LEGIBILIDAD DEL SOFTWARE ..................... .. 4.1 Introduccion .......................................................................................

4.3 Método de Reingeniería de datos ...................................................... 4.4 Framework para buscar código fuente utilizando patrones de

programas .................................................................. ; .......................

4.2 Expresiones Regulares para mejorar tipos de datos .........................

Capítulo 5 . ARQUITECTURA Y DISEÑO DEL PROCESADOR GRAFICO .....................................

5.1 Antecedentes ...................................................................................... 5.2 Arquitectura conceptual del Procesador Gráfico .............................. 5.3 Módulo analizador del código fuente ................................................

5.3.1 Diagrama de Estructura del analizador .................................... 5.4 Módulo visualizador de código fuente ..............................................

5.4.1 Estructuras de Datospara visualizar código ............................

5.4.3 Tipo de organización jerárquica para visualizar código .......... 5.4.2 Notación modificada para visualizar código ...........................

5.4.4 Organización de los objetos gráficos ....................................... 5.4.5 Mostrar los objetos gráficos en forma de árbol .......................

5.4.5.1 Expandir niveles de mayor abstracción de un objeto .. 5.4.5.2 Contraer niveles de menor abstracción de un objeto ...

5.5 Módulo para mejorar la legibilidad del código fuente ...................... 5.5.1 Estructura de Datos para mejorar el código ............................. 5.5.2 Diagrama de Estructura para mejorar código fuente ...............

5.5.2.1 Analizador del código .............. ..................................

5.5.2.3 Mejorar datos de lectura no inicializados .................... 5.5.2.4 Mejorar datos de escritura no uiilizados ...................... 5.5.2.5 Generador de código mejorado! ...................................

5.6 Módulo para ejecutar un programa ................ ! .................................. 5.7 Interfaz gráfica implantada en el Procesador kráfico .......................

5.5.2.2 Generador de expresiones regulares ............................ I . .

38

39 39 43

45

46

47 49 50 50 52 53 55 56 58 63 64 67 68 68 70 70 70 71 72 72 77 78

5.7.1 Administración de archivos de Windows ................................ 78 5.7.2 Interfaz del Procesador Gráfico ............................................... 79

Capítulo 6. EVALUACION EXPERIMENTAL ..................... 85

I .

6.1 Hipotesis a comprobar ....................................................................... 86 6.2 Variables dependientes ...................................................................... 86 6.3 Variables independientes ................................................................... 86 6.4 Plan de muestra .................................................................................. 87 6.5 Plan de evaluacion ............................................................................. 87 6.6 Análisis de resultados ........................................................................ 88

Capítulo 7. COMENTARIOS FINALES ................................... 92

. r

. .

b

7.1 Contribución de la investigación ....................................................... 93 7.2 Mejoras y trabajos futuros .................................................................. 93

Apéndices

95 A Media aritmetica .................................................................................. 95 B Desviacion media .................................................................................

C Varianza ............................................................................................... 95 96 D Desviacion estándar .............................................................................

. I .

. . I

. .,

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

!

I

... 111

LISTA DE FIGURAS

No. Fig. Descripción Pag.

1.1 1.2

2.1 2.2 2.3

2.4 2.5 2.6 2.7 2.8 2.9

3.1 3.2

3.3

3.4 3.5

3.6

3.7

3.8

3.9 3.10

4.1 4.2 4.3

Demanda de mantenimiento 5

aplicar Reingeniería de Software 7 Número de horas de mantenimiento emergente antes y después de

Construcciones en diagramas de flujo. Estructuras básicas del método de Jackson. Los tres símbolos gráficos utilizados para dibujar los diagramas de Nassi-Schneiderman. Tabla visual de contenido para un paquete HIPO. Simbología utilizada para los diagramas de Wamier. Construcciones básicas de los diagramas de Wamier. Caja estructurada Secuencia Caja estructurada Alternación Caja estructurada Iteración

12 13

14 15 16 17 19 19 20

Espectro cósmico electromagnético global 27 Representación gráfica de las funciones mogost-open-window y

29 XmxSetConstraints.

Representación gráfica del programa gui-dia1ogs.c. 30

Reducción de arcos múltiples. 31 Gráfica después de enumerar y remover los arcos múltiples. 32

Gráfica después de remover las bibliotecas de C, Windows y M o t i f

Gráfica con agrupamiento de nodos y arcos

Gráfica resultante después de aplicar disposiciones heurísticas

33

34

35

36

37

42 44 44

Gráfica aplicando colores y vistas en 3D. Ciclo de vida de la Reingeniería para crear programas de aplicación utilizando de herramienta VIASOFT'S VINRenaissance.

Programa fact0r.c para encontrar los factores de un número primo. Fragmento de programa con datos de lectura no inicializado Código mejorado de datos de lecturas no inicializados.

iv

4.4

4.5

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10

5.11 5.12 5.13 5.14

5.16

5.17 5.18 5.19 5.20 5.21 5.22 5.23

5.24

5.25 5.26

5.27 5.28 5.29 5.30 5.31 5.32 5.33 5.34 5.35

Fragmento de programa con error tipo de dato de escritura no utilizado. Código mejorado de datos de escritura no utilizados

Arquitectura conceptual del AMASS-I1 Arquitectura del SoftGraf Diagrama de Estructura del módulo analizador Modelo conceptual de los nodos de la lista para visualizar código Principio de la organización jerárquica Distribución de objetos del programa prueba.c Programa prueba.c Lista doblemente ligada del programa prueba.c Programa prueba.c representado gráficamente Lista doblemente ligada del programa prueba.c con las coordenadas actualizadas Ejemplo para sensar nn objeto Lista con los nodos modificados en el campo imp Ejemplo de expandir objetos del programa prueba.c Lista doblemente ligada del programa prueba.c con las coordenadas actualizadas después de expandir los objetos Modelo conceptual de los nodos que almacenan los datos del programa fuente. Diagrama de estructura del Módulo para mejorar código Programa ho1a.c Lista doblemente ligada de código del programa ho1a.c Lista simplemente ligada de las variables del programa ho1a.c Lista de variables con el campo expresion actualizado. Lista del código actualizado, después de eliminar un nodo. Programa ho1a.c después de mejorar el dato de escritura no utilizado Lista con las expresiones regulares actualizadas, dato de escritura no utilizado. Lista del código actualizado, después de insertar una variable Programa holyc después de mejorar el dato de lectura no inicializado Lista de iwiables con las expresiones regulares actualizadas Programa mejorado después de las correcciones. Interfaz del SoftGraf. Caja de diálogo para abrir archivos. Programa ejemp1o.c representado en forma textual. Programa ho1a.c mejorado. Resultado de ejecutar el programa may0r.c Equivalencia del símbolo gráfico en lenguaje Ayuda en línea para un objeto gráfico.

45 45

48 49 51 53 57 61 62 62 63

63 65 66 66

67

69 70 73 73 74 74 74

75

75 76

76 76 77 79 80 81 82 83 83 84

V

LISTA DE TABLAS

No. Tab. Descripción Pag.

1.1 1.2

4.1

' 4.2 4.3

5.1 5.2 5.3 5.4 5.5 1

5.6

6.1

6.2

6.3

6.4

6.5

Tecnologías de Reingeniena de Software Modelo para definir los requerimientos del usuario

Equivalencias de categorías de expresiones regulares en lenguaje " L

Reglas para formar la expresiones regulares Expresiones regulares generadas del programa fact0r.c

Tabla de palabras reservadas de lenguaje C Tabla de nombres de archivos bitmaps Notación gráfica para la función main Notación grafica construcciones de Secuencia Notación gráfica construcciones de Alternación Notación gráfica construcciones de Iteración

Información para calcular la medida de dispersión para el tiempo dedicado a entender programas textuales sin utilizar la herramienta Información para calcular la medida de dispersión para el tiempo dedicado a entender programas representados gráficamente utilizando la herramienta Información para calcular la medida de dispersión para el tiempo dedicado a modijicar datos incorrectos sin utilizar la herramienta Información para calcular la medida de dispersión para el tiempo dedicado en modijcur datos incorrectos utilizando la herramienta Resumen comparativo del tiempo utilizado en las cuatro pruebas

3 6

40 41 42

54 54 55 55 56 56

88

89

89

90 90

vi

Capítulo 1 Introducción a la Reingeniería de Software

CAPITULO 1

rn I O CI

Este capítulo describe una reseña de la Reingeniería de Software, la tecnología asociada al entendimiento y mejoramiento de Software, también se analiza brevemente un caso de estudio para demostrar la importancia que tiene la Reingeniería de Software en el mantenimiento de Sistemas.

Capítulo 1 Introducción a la Reingenieria de Software

1.1 Introducción

A través de la historia de la ingeniería, parece surgir un principio: la gran ingeniería es la ingeniería sencilla. Las ideas que se toman muy rebuscadas, inflexibles y problemáticas tienden a ser reemplazadas por otras más nuevas y claras desde el punto de vista conceptual y con sencillez estética. Cuando el diagrama de un programador parece una telaraña, es hora de rediseñar todo el programa. El software corre el riesgo constante de convertirse en rebuscado, inflexible y problemático. Los enlaces entre las diversas partes tienden a multiplicarse si se añaden nuevas características y si cambian las necesidades de los usuarios.

Actualmente en la industria de desarrollo de software existe la necesidad de crear sistemas más rápidamente, más baratos, de mayor calidad y con el menor esfuerzo dedicado.

También se requiere que los usuarios relacionados con información puedan crear y modificar sus propias aplicaciones en forma mucho más rápida. Esto ha necesitado que instituciones educativas y empresas fabricantes de software lleven a cabo investigaciones y desarrollos tecnológicos orientado a satisfacer estas necesidades.

I

Una tendencia de investigación importante es la Reingeniería de Software, por las siguientes razones:

Crea el ambiente necesario para aplicar herramientas CASE para facilitar el

Reduce el riesgo de inversión en la extensión de nuevos cambios en el software. Mejora la construcción de software existente. Ayuda a las organizaciones a recuperar parcialmente su inversión del software.

mantenimiento de software antiguo. Facilita la creación de herramientas para la automatización de software.

Una definición sobre la Reingeniería de Software:

“Es el proceso de modificar los mecanismos internos de un programa o estructura de datos de un sistema para mejorar su aplicación” [GUI89].

Otra definición:

“Examinar y alterar un sistema con el objeto de reconstruir éste en una nueva forma para su implementación más adecuada” [CHI90].

La Reingeniería de Software provee metodologías y técnicas para el mejoramiento y mantenimiento de software. Esta tecnología permite mejorar el entendimiento de un

2


programa, que consiste en examinar programas existentes para extraer información de interés por el encargado de dar mantenimiento al software, esta información puede ser: la estmctura de control, el flujo lógico y el flujo de datos (declaración de datos, ciclos, estructuras lógicas) con el propósito de eliminar el código inútil dejando tan solo, el código de interés, para que otras herramientas de mantenimiento puedan construir mapas gráficos de dependencias que muestran los enlaces entre las diferentes estructuras de datos, componentes de programas y otras características. Las herramientas de mantenimiento que realizan ésto, han sido denominadas herramientas de visualización de código [OMA90]. De hecho, permiten al encargado de dar mantenimiento visualizar el programa, ayudando a controlar la calidad de los cambios y la productividad de la gente que los realiza.

Sin embargo, es necesario la creación de nuevas técnicas y herramientas automáticas para solucionar problemas de entendimiento de programas en la fase de mantenimiento del ciclo de vida en el desarrollo de sistemas.

Entendimiento de Software

Mejoramiento de Software

Recuperar, almacenar y extender conocimientos acerca del software

En este trabajo de tesis se construyó una herramienta visual cuyo objetivo principal es facilitar a los encargados de mantenimiento de software la comprensión y mejoramiento de programas ya existentes a través de técnicas de Reingeniería de Software y Visualización.

Visualización Análisis y Métricas

Reestructuración 0 Redocumentación

Ingeniería para el reuso e Remodularización

Reingeniería de Datos 0 Reingeniería para procesos industriales

Ingeniería Inversa y recuperación de diseños

Análisis de mantenimiento, análisis de portafolio y análisis económico

Ingeniería Inversa para la recuperación de diseños Descomposición

Recuperación de objetos Entendimiento de programas Base de conocimientos y transformación

1.2 Tecnologías de Reingeniería de Software

Las tecnologías asociadas a Reingeniería de Software para mantenimiento se muestran en la tabla 1.1, tales temas sirvieron como referencia para el desarrollo de este trabajo de tesis.

3

Introducción a la Reingenieria de Software Capitulo 1

A continuación se describen únicamente los temas que están relacionados con este trabajo.

1.2.1 Entendimiento del Software

Visualización de Software. Esta técnica sirve para entender y examinar software en editores de texto y más recientemente a través del uso de Hipertexto [CON871 (por ejemplo, HTML- HiperText Markup Language) que 'sirve para hacer conexiones entre partes relacionadas y mostrar múltiples vistas del Software [CLE89], para ser seleccionadas por el usuario con solo oprimir el botón del ratón electrónico (mouse).

Análisis y Métricas. Analizar y medir son también técnicas importantes para entender las propiedades complejas de un programa. La relevancia para esta técnica de Reingeniería es dividir los programas [WEI81], medir el control del flujo del programa [MCC76] y medir el acoplamiento del programa [MYE75].

Ingeniena Inversa y recuperación de diseños. Estas sirven para generar nueva información acerca del Software, usualmente con diferentes formas. Analizando el código fuente se generan estructuras de caracteres o diagramas de flujo de datos u objetos gráficos con el propósito de comprender mejor el programa fuente.

1.2.2. Mejoramiento del Software

Reestructuración de Software. Es la modificación de Software para hacerlo más fácil de entender o más fácil de darle mantenimiento [ARN89]. Hoy en día este término significa el cambio en las estructuras de control del código fuente.

Reingeniería de Datos. Esta técnica sirve para mejorar los datos incorrectos de un sistema. Los datos incorrectos pueden ser reorganizados de varias formas, datos de lectura y/o escritura incorrectos, sobre carga de datos y migración de datos, esto con el objetivo de aumentar la vida útil de los sistemas existentes [RiC89] y.facilitar el mantenimiento de éstos.

1.3 La Reingeniería de Software reduce el mantenimiento de Sistemas: Un caso de estudio.

La historia del desarrollo y mantenimiento del sistema.

Este caso de estudio [MAL911 se realizó en un Sistema de Policía para dar servicio a 42 compañías. El sistema fué desarrollado hace 14 años en Cobol y algunas utilerías en lenguaje de programación Ensamblador. El sistema tiene 1,600 programas dando un total de 2,000,000 líneas de código. Hasta la fecha a sufrido más de 1,000 cambios, muchos de los

4

Capitulo 1

cuales han necesitado un gran esfuerzo. Esto ha ocasionado altos costos para poder satisfacer los requerimientos de los usuarios.

Introducción a la Reingenieria de Software

Esta situación ha motivado a los encargados de mantenimiento a investigar otras opciones para facilitar el mantenimiento del sistema. Una de éstas es la Reingeniería de Software que ofrece una alternativa para obtener mejores beneficios (esfuerzo-costo) en el mantenimiento. En este estudio se describen las técnicas de Reingenieria de Software que fueron usadas junto con otros métodos para reducir el esfuerzo y costos en mantenimiento de Sistemas.

Se utilizó una base de datos para almacenar y controlar la información que se necesitaba en varias partes del sistema para atención de los usuarios. Fueron construidos 2 subsistemas para proveer estadísticas de información histórica de la empresa. También descubrieron que el sistema de Policía no estaba integrado, por que la información que emitía era diferente para un mismo concepto.

Durante los últimos años, un mínimo de información fue colectada sobre los trabajos de mantenimiento realizados. Sin embargo el tipo de información y las definiciones del problema cambiaron. En la figura 1.1 se muestra una gráfica de los tipos de mantenimiento que se realizaron entre 1984 a 1988 y se observa que el mantenimiento correctivo se realizó constantemente durante estos años.

tto. periecilvo

Mto. adaptativo I I

Figura 1.1 Demanda de mantenimiento

Una segunda clase de nocturnos en operación por emisión de los reportes y frecuencia.

información importante que se descubrió para los programas lotes, fué que se requería un mantenimiento emergente en la en aquellas áreas que requerían mantenimiento con más

Análisis del sistema para el mantenimiento.

El estudio y análisis que se realizo, indicó muchos problemas de mantenimiento, los cuales fueron: falta de mantenimiento adaptativo, una gran cantidad de mantenimiento correctivo, un incompleto e inadecuado sistema de información y falta de planeación en las mejoras del sistema, dando como resultado documentación inadecuada e inexistente.

5

Introducción a la Reingeniería de Software Capítulo 1

Estrategia para la rehabilitación del sistema.

Uno de los objetivos fué el de disminuir la cantidad de cambios al sistema, particularmente aquellos que fuesen realizados durante el mantenimiento correctivo. Se seleccionó un sistema escrito en Cobol con el objeto de integrarlo a un sistema de reportes. Otro objetivo de la Reingeniería de este Software fui producir un sistema con arquitectura más modular con el propósito de facilitar el mantenimiento y que pudieran intercambiar información sin que está se duplicara.

También se formó un equipo de planeación técnica para considerar los cambios del sistema que propone la Reingenieria de Software.

Método de desarrollo aplicado.

El método propuesto está basado en el ciclo de vida de desarrollo de un Sistema de Software, considerando las observaciones del usuario como parte de la planeación del diseño del sistema. Se trató de no considerar los cambios en forma deliberada que pudieran afectar la eficiencia del sistema, cada etapa consideraba los objetivos generales del sistema.

Cuando se termino cada etapa, se evaluo para determinar que tan bien se conocían las necesidades del procesamiento de información, después de una favorable evaluación, los diseños del proyecto y los objetivos fueron reevaluados para determinar cualquier cambio en el sistema. Considerando la Reingeniería de Software para cada etapa y área de trabajo. Dentro de cada una de las áreas se generó una lista descriptiva de funciones del sistema, éstas incluían mantenimiento adaptivo, seguridad y funcionalidad, después se identificó una lista de atributos para cada una de las funciones y como éstos estaban asociados. En la tabla 1.2 se muestra las soluciones a estos problemas.

Mantenimiento

Seguridad

Funcionalidad

Implementación de corrección. Implementar más medidas de mantenimiento en el sistema. Establecer un alto nivel de pruebas en el sistema.

Error en la evolución . Actualizar la información en dispositivos de almacenamiento (disco).

Tener métodos formales para examinar diseños, código,

Garantizar calidad en todas las etapas del proyecto. Instalar herramientas automáticas en el análisis del problema.

documentación y planes de prueba. Establecer medidas de calidad para módulos de urogramas. . -

o

Procesamiento en linea v nor lote. Moniiorrar y rrgisirar iodos los cambios cfcctuados en el sistema.

. I

Tabla 1.2 Modelo para definir los requerimientos del usuario

Reducir el número de cintas de respaldo requeridas. Reestructurar los programas sobrecargados de tareas. Reestructurar el software para volver a leerlo y a utilizarlo.

6


Implementación de soluciones

Las soluciones se dividieron en tres categorías:

Procesamiento de transacciones. Este trata de optimizar y estandarizar los procesos en línea y por lotes del sistema.

Administración de datos. En esta categoría se definieron y se integraron los elementos de información necesaria para la base de datos, considerando la revisión de todos los reportes en existencia para eliminar redundancia y proveer reportes integrados.

Modelado de datos. Este fue a través de la implementación de una herramienta CASE y de un diccionario de datos, con la ayuda de éstos, el equipo de modelado de datos analizó anomalías de la información y propuso soluciones a éstas.

Conclusiones del caso de estudio

AI aplicar Reingeniería de Software se lograron tres resultados importantes: incrementar la legibiiidad del código existente, estandarización de los nombres de variables y reestructurar el código en forma modular. Teniendo como consecuencias facilidad de mantenimiento (ver figura 1.2) y mejoras en la interface de usuario del sistema. También se logró que personal encargado de dar mantenimiento no diera respuesta a solicitudes cuando el programa estaba trabajando bien, logrando con esto un ahorro de tiempo y de recursos considerables, reduciendo el mantenimiento de emergencias hasta un 50% (ver figura 1.2). En general, se logró estructurar el sistema para apoyar las necesidades de mantenimiento en forma planeada y al mismo tiempo proveer una estructura de alto nivel para modificar o ampliar el sistema actual.

Oct-Dic MayJul

Figura 1.2 Número de horas de mantenimiento emergente antes y después de aplicar Reingeniería de Software

7

Capitulo 2 Planteamiento del problema y propuesta de solución

CAPITULO 2

PLANTEAMIENTO DEL PROBLEMA Y PROPUESTA DE SOLUCION

En este capítulo se describe el problema a resolver y las diferentes alternativas de solución, considerando las formas de representar código gráficamente y también cómo mejorar el código a través de la Reingeniería de Datos.

Capítulo 2 Planteamiento del problema y propuesta de solución

2.1 Descripción del problema

la actualidad el desarrollo de software se ha caracterizado por sobrecostos, retrasos en las entregas e inutilidad de los productos, como consecuencia de invertir más recursos de 10s que originalmente se presupuestaron, más tiempo Y más Personal. La situación se agrava cuando los productos son muy grandes (miles de líneas de código) y en ocasiones el desarrollo de éstos es artesanal.

Se considera que un factor importante para mejorar la productividad en el desarrollo de software es el número de líneas de código fuente que han sido desarrolladas para dar respuesta a un problema específico, es decir en lugar de buscar la forma de escribir código más rápidamente, tenemos que ver maneras de escribir menos código, reutilizando el software desarrollado con anterioridad, una vez organizado en depósitos o almacenes de componentes.

Un problema que surge cuando una organización específica plantea sus requerimientos, es que los programas anteriores no se adaptan a las necesidades actuales y sobre todo cuando esta aplicación es de otro dominio o clase de problema, por lo tanto es necesario que se modifiquen las estructuras internas del programa para lograr su readaptabilidad, en caso de que el componente haga más o menos de lo requerido.

Cuando se presenta esta situación, entonces el usuario necesitará revisar y analizar la documentación externa e interna del componente o programa reusable, esto se vuelve impráctico si el número de programas es muy grande porque aumenta el tiempo y esfuerzo de desarrollo de los sistemas. Los problemas se multiplican ya que la gran mayoría de personas que ocupan el código tienden a modificarlo y prácticamente es imposible regresar a los requerimientos del código fuente.

Muchas de estas actividades son parte del mantenimiento de programas y/o componentes. En particular este trabajo de tesis pretende atender los problemas de entendimiento y mejoramiento de software.

A continuación se describen los problemas identificados en este rubro:

Las personas que realizan actividades de mantenimiento a sistemas se les dificulta abstraer información cuando tienen que analizar todo un programa completo. Shneideman [SHNSO] cree que la información en partes es mejor para la comprensión de programas completos.

En el análisis, el código textual no muestra el flujo de datos del programa y no proporciona sugerencias visuales de los diferentes caminos de como está organizado el código fuente. Esto dá como resultado que el proceso de comprensión sea más lento y como resultado de esto, de más alto costo.

9


Cuando se requiere dar mantenimiento a un código poco familiar acompañado de documentación inadecuada o en algunas ocasiones inexistentes, entonces se toma como último recurso el código fuente. De aquí, las personas tienen que extraer la información directamente del código fuente, creando modelos abstractos e infiriendo el funcionamiento del programa total. Esta actividad es muy lenta por que el código textual no cuenta con un modelo gráfico que represente el funcionamiento o actividad de las estructuras internas del programa.

En algunos programas existen datos incorrectos como: datos no inicializados, datos no utilizados y mala distribución de los datos, que hacen que un programa sea más difícil de comprender y que se generen un mayor número de errores de lógica.

2.2 Propuesta de solución

Lo que se pretende con este trabajo de tesis es que los encargados de realizar mantenimiento a programas existentes, tengan una mejor visualización de programas escritos en lenguaje C por medio de una representación gráfica de este código y a través de la mejoría de los tipos de datos incorrectos, pretendiendo con esto, ahorrar tiempo y costos en la comprensión y correcciones de dichos programas.

2.2.1 Objetivo de la tesis

Diseñar e implementar una herramienta que perniita representar en forma gráfica segmentos de código fuente con ,mayor legibilidad, con el propósito de apoyar a los desarrolladores de software o al grupo de mantenimiento de componentes reusables a entender, adaptar, modificar y/o extender código reusable para la implementación de nuevas aplicaciones. En esta tesis, se trata de probar que al transformar el código fuente a estructuras gráficas y mejorar los datos incorrectos, el programa será más comprensible.

2.2.2 Beneficios de la tesis

A continuación se muestran los principales beneficios que se pueden obtener con el desarrollo de esta herramienta:

a) Al reestructurar el control del flujo de datos en forma gráfica, se posibilitará una mejoría en el diseño de datos en un programa. Con esto se espera ubicar los datos en el lugar más adecuado para futuras consultas.

i

b) Al tener un programa estructurado representado gráficamente, se tendran las estructuras de control internas más simples (secuencia], selección y repetición) facilitando la documentación de éste.

10

Planteamiento del problema y propuesta de solucih capitulo 2

c) descomponer un programa en estructuras de control en forma de gráfica se Pretende que el mantenimiento de un programa sea más fácil ya que 10s datos estarán en 10s lugares más apropiados, y además, teniendo las estructuras de control en símbolos gráficos se pretende probar que se puede agregar nuevas características al código de una manera más rápida.

d) A través de los símbolos gráficos de cada una de las estructuras de un programa se ayudará a reducir el tiempo de comprensión, teniendo como resultado ahorro de tiempos y costos en el mantenimiento de un sistema.

e) Facilitará al usuario a comprender un programa para usarlo correctamente en la construcción de sus propias aplicaciones a partir de componentes de código reusable.

i ) Ai mejorar los tipos de datos no inicializados se evitaran los errores de lógica.

g) AI retirar los tipos de datos no utilizados se reducirá el número de líneas de código, logrando con ésto una mejoría en el código para su comprensión.

h) Esta herramienta permitirá obtener conocimientos y tecnologías nuevas en México. Se tratará de probar la metodología de jerarquía de símbolos gráficos y el método de Reingeniería de Datos para mejorar datos incorrectos, propuesto por Alan R. Hevner [ALA89].

2.2.3 Formas para representar código gráficamente

La Reingeniería de Software propone representar en forma gráfica el código fuente, para lograr un alto nivel de entendimiento del funcionamiento de un programa. En seguida se muestran algunas metodologías importantes que podrían servir para esta situación, considerando sólo tres estructuras básicas: secuencia, selección y repetición.

a) Diagramas de flujo

Un diagrama de flujo es un gráfico muy sencillo. Para representar un paso de procesamiento se utiliza un cuadro, un rombo para representar una condición lógica y flechas para mostrar el flujo de control, como se muestra en la figura 2.1.


Las construcciones básicas de esta notación son:

Primera tarea

Secuencia If-then-else

Tarea del bucle

del bucle Do-while

Repeat-Until Repetición

+i Selección

Figura 2.1 Construcciones en diagramas de flujo.

b) Jackson

Esta metodología creada por el inglés Michael Jackson se basa en que la estructura de un programa está en función de la estructura de los datos que manipula. Jackson emplea módulos según su orden jerárquico dentro de los diferentes niveles donde se encuentra. Cada módulo es un dato o un conjunto de datos [JOYSS].

12

Capitulo 2 Planteamiento del problema y propuesta de SOlUCion

Construcciones básicas

Las estructuras consideradas básicas en el método Jackson vienen representadas en la figura 2.2 y son las siguientes:

Secuencia: Un número determinado de módulos se ejecutan una sola vez en el orden jerárquico preestablecido.

Alternativa: Se selecciona para la ejecución un módulo de entre varios posibles. El proceso se indica por medio de una letra O.

Repetitiva: Un módulo se ejecuta desde cero hasta n veces. El proceso repetitivo se indica con un asterisco (*).

Con estas estructuras básicas se puede obtener cualquier otra que intervenga en el diseño del programa.

El uso del método de Jackson supone lectura arriba-abajo y de izquierda a derecha.

Figura 2.2 Estructuras básicas del método de Jackson.

c) NassVShneiderman (N-S)

Los diagramas de flujo estructurado también llamados Nassi-Schneiderman, son herramientas gráficas que forzan al diseñador a estructurar código de software de forma que sea modular y descendente. Proporcionan una estructura a la que se pueden ajustar los que desarrollan el software de aplicación [SEN94].

13


Este sistema de representación permite tener una visión mucho más estructurada que los diagramas de flujo y el pseudocódigo, por lo tanto tiene mayor facilidad de ser traducido ai lenguaje de una computadora.

Otra de las ventajas con las que cuenta este método son:

1 . Compatibilidad con la programación estructurada. 2. Reducción del espacio en papel ya que este método omite el uso de flechas, utiliza cajas

o bloques contiguos y los diagramas son de una sola hoja.

Sin embargo este método también tiene algunas desventajas con relación a los otros métodos. Una de ellas es que para que un diagrama pueda ser entendido debe ser completo y comprensivo [KENSS].


Los elementos básicos de los diagramas N-S son [KENSS]:

Proceso Dxisión r teración

Figura 2.3 Los tres símbolos gráficos utilizados para dibujar los diagramas de Nassi-Schneiderman.

PROCESO: Está representado mediante un rectángulo y simboliza la inicialización de variables, actividades de entrada y de salida y las llamadas para ejecutar otros procedimientos.

Un nombre descriptivo breve, escrito dentro del rectángulo, establece el propósito del proceso.

DECISION: El símbolo de decisión representa condiciones alternativas, Son equivalentes a las estructuras if-then-else.

14

Planteamiento del problema y propuesta de solución Capítulo 2

ZTERACZON: Representa los ciclos y repeticiones de operaciones mientras se cumpla una condición [KENSS].

d) HIPO (Hierachy/Input/Process/Output)

Este método fue creado con el propósito de ayudar a los diseñadores a no perder la pista de alguna función dentro de un sistema grande, ésta es su principal ventaja con ia que cuenta con respecto a otras notaciones, ya que este método permite tener una vista panorámica de las entradas, procesos y salidas de datos. Esto lo hace una herramienta útil para la documentación de programas, además de que le puede facilitar al autor de un programa el recordar lo que hace el sistema después de cierto tiempo.

Sin embargo HIPO también cuenta con ciertas desventajas, una de ellas es que utilizan una gran cantidad de espacio para mostrar todo el diagrama de un sistema por io que puede ocasionar que al lector se le dificulte la navegación en el seguimiento del flujo de éste [KEN88]. En la figura 2.4 se muestra un ejemplo del diagrama HiPo [FAI90].

Figura 2.4 Tabla visual de contenido para un paquete HIPO

e) Diagramas de Warnier-Orr

El diseño de estos diagramas fueron desarrollados inicialmente en Francia por Jean- Dominique Wamier, con el fin de representar la jerarquía de la información utilizando las tres construcciones de secuencia, selección y repetición, además Wamier demostró que la estructura del software puede derivarse directamente de las estructuras de los datos.

Por su parte Kenneth Orr en los Estados Unidos amplía el trabajo de Warnier abarcando una visión más amplia del campo de información, evolucionando el desarrollo de sistemas estructurados en datos [PRE90].

-


Simbología

A continuación en la figura 2.5 se muestra un diagrama general de Wamier-On, así como el significado de los diferentes elementos que en él participan [SAN92].

suma<- suma+ I

Figura 2.5 Simbología utilizada para los diagramas de Wamier.

Significado de los elementos

1. Una llave { denota a un bloque de información jerarquizada que pueden ser datos o acciones, las llaves anidadas de derecha a izquierda denotan los niveles de abstracción, las sentencias o bloques de sentencias de arriba abajo, muestran la secuencia y las relaciones lógicas entre las funciones.

2. La información entre los paréntesis (variable simbólica o cantidad numérica ) indica el número de veces que ocurrirá la estructura. Si se coloca una letra C indica que un ciclo se termina cuando una condición se cumple.

3. La barra - indica negación de una condición

4. El símbolo 8 indica la ocurrencia condicional exclusiva de una acción o grupo de acciones.

5 . Un triangulo A indica un bloque de instnicciones descrito en otra parte, puede estar vacío o llevar adentro un número o identificador de procedimiento (subprograma, rutina, función).

16

Oapiíulo 2

6. El asterisco * indica la expresión condicional de fin de ciclo. Es decir cuando se cumple

Planteamiento del problema y propuesta de solución

la expresión que va después del asterisco, se termina de ejecutar el ciclo.

7. Una flecha izquierda t indica la asignación de una variable, de derecha a izquierda.


La notación de Wamier utiliza las construcciones básicas de: secuenciación, bifurcación y repetición figura 2.6. A continuación se explica cada una de ellas [SAN92].

(b) Bifurcación (a) Secuenciación c

suma <- suma + 1

Figura 2.6 Construcciones básicas de los diagramas de Wamier.

Secuenciación. La llave es usada para denotar diferentes niveles de información jerarquizada, de arriba abajo muestra la secuencia de ejecución y las relaciones lógicas entre los procesos, de izquierda a derecha muestra el nivel de abstracción.

Bifurcación. Si se cumple la condición, el proceso se bifurca al proceso 1, de otra manera se sigue con el proceso 2.

Repetición. En la figura 2.6 inciso c, se muestra la estructura de repetición. Todas las instrucciones que se encuentren dentro de la llave se van a ejecutar hasta que se cumpla la condición x >= 5.

17


Esta notación de diseño detallado tiene una característica que la hace diferente respecto a las demás notaciones, ésta es: Para poder desarrollar un diagrama de WarniedOrr, el analista debe trabajar hacia atrás, es decir, se debe empezar con la especificación de la salida del sistema.

En el papel el flujo del diagrama va de izquierda a derecha, definiendo en primer lugar la salida o resultados del procedimiento y en el nivel siguiente, mostrado mediante la inclusión de una llave, se definen los pasos para producir una salida. Las llaves adicionales agrupan los procesos requeridos para producir el resultado en el siguiente nivel.

Estos diagramas ofrecen a los expertos en sistemas algunas ventajas distintivas. Son simples en apariencia, fáciles de entender, fáciles de modificar, más que los diagramas de Nassi-Schneiderman porque como se mencionó anteriormente el analista debe trabajar hacia atrás.

Otra de las ventajas importantes de los diagramas de Wamier es que son compatibles con las técnicas de la programación estructurada, por lo que se convierten en poderosas herramientas de diseño. También tienen la ventaja de mostrar agrupaciones de procesos y los datos que deben transferirse de nivel a nivel. Además la secuencia del trabajo hacia atrás garantiza que el sistema estará orientado hacia el resultado, a menudo es necesario determinar los pasos más internos antes de poder resolver lo relativo a las interacciones y a la modularidad [KENSS].

f ) Jerarquía de cajas estructuradas

Esta metodología [ALA891 sirve para analizar el flujo de datos de un programa estructurado, y se puede describir como una jerarquía de objetos gráficos. Esto es, un programa puede estar descompuesto en estructuras de control secuenciales y anidadas (secuencia, alternación, iteración), de arriba a abajo en estatutos individuales y ser representado en forma de jerarquía de cajas estructuradas. Las cajas estructuradas es una teoría que también sirve para analizar y diseñar sistemas de información [MIL86], [MIL87].

Esta metodología puede describir cualquier sistema o parte de software en tres tipos de datos abstractos:

Caja negra. Define los tipos de datos abstractos completamente en términos de comportamiento externo, en estímulos y respuestas.

Caja de estado. Sirve para guardar datos abstractos para determinar el próximo estado y dar respuesta a un estimulo previo. Cada una de las cajas claras tendrá una de éstas.

Caja clara. Define el procedimiento que accesa el estado interno y posiblemente las llamadas a otras cajas negras al siguiente nivel de descomposición.

18


La representación de las estructuras de control de secuencia, alternación e iteración de un programa pueden ser descritas en cajas claras, como se muestra en las figuras 2.7-2.9.

R e

P

e

t a

,- - - - - - - - - - E

t í m

1

S S

u u

S

O

Figura 2.7 Caja estructurada secuencia

R e

P

e

t a

E S

t í m

1

S

u

S u

O

Figura 2.8 Caja estructurada alternación

19

Planteamiento del problema y propuesta de solution Capitulo 2

R e

P

e S

t a

_ _ _ _ - - - - - E S

t í m

1

S

u

u

O

Figura 2.9 Caja estructurada iteración

2.2.4 Notación seleccionada para representar código gráficamente

Unos de los principales problemas que se requiere atender en esta tesis es representar y comprender un código ya existente a través de objetos gráficos, y se observa que la notación que ofrecía más ventajas sobre ésto, es la notación de jerarquía de cajas estructuradas; por las siguientes razones:

Notación sencilla de utilizar. Independiente del lenguaje sobre el cual se desee visualizar el código. Podría servir para visualizar código, ya que cuenta con símbolos gráficos en sus construcciones básicas. Se puede analizar el flujo de datos de un programa estructurado. Esta notación describe un programa en partes y en niveles de profundidad, lo que hace más fácil su comprensión. Otra razón importante que ofrece esta notación es que la distribución de sus símbolos es de manera jerárquica y se cree que es la forma natural de representar los niveles de abstracción de las partes de un programa estructurado.

2.2.5 Reingeniería de datos para mejorar el código

La propuesta de solución que se eligió para resolver los problemas de datos incorrectos, con el propósito de mejorar el código original, es utilizar la técnica de Reingeniería de datos que fue descrita brevemente en la sección 1.2.2.

Considerando que la Reingeniería de datos amplía la vida útil de un sistema existente, logrando con esto una mejoría en el código fuente.

20


Otro motivo es que a través de la Reingeniería de datos se permite descubrir las propiedades de los datos mediante un análisis del código fuente de sus datos actuales y la comparación de aquellas propiedades necesarias para saber si los datos están incorrectos. En este análisis se ocupan expresiones regulares para poder automatizar el proceso. En capítulos posteriores se hablará más ampliamente de estos temas.

Y

!

21

Capitulo 3 Conceptos sobre Visualización de Software

CAPITULO 3

CONCEPTO 1 LIZACION DE SOFTWARE

En este capítulo se describe la importancia que tiene la Visualización para mejorar la comprensión de Software, se presentan las diferencias que existen entre las representaciones textual y gráfica de Software, los problemas que tiene la Visualización y las estrategias de solución, también se describe brevemente la expresión visual como medio de comunicación de información y por Último se presenta el estado del arte en herramientas de Visualización de Software.

22

Conceptos sobre Visualización de Software Capitulo 3

3.1 Introducción

La técnica de visualización se toma como alternativa para lograr un mantenimiento de sistemas más fácil. En esta tesis se pretende comprobar que al representar el código en forma gráfica se tiene un alto nivel de comprensión en sistemas y es más Útil que la representación textual. Sin embargo la representación gráfica de Software tienen problemas de visualización, ya que presentan demasiada información y el dispositivo de salida de las computadoras es muy pequeño para este fin. Por lo tanto en este trabajo de tesis se pretende mostrar estrategias y heurísticas para la representación de información gráficas para evitar estos problemas. Estrategias que consideran incluir agrupaciones de estructuras, objetos con colores para cada una de las estructuras básicas de un programa escrito en lenguaje de programación C, evitar el cruce de líneas, ocultar comentarios, ocultar librerías internas y mostrar el programa en forma arborecente para facilitar la navegación sobre éste.

3.2. Representación Textual vs. Gráfica

El código fuente textual esta lejos de facilitar el mantenimiento ya que no cuenta con un modelo cognoscitivo (guía para comprender un programa existente) del Sistema [May95, LET861.

El código fuente solo puede ser visto en pequeñas partes y no da facilidades de navegación, a diferencia de la representación gráfica, donde se pueden representar varias vistas del programa, estas vistas comúnmente muestran el control de flujo de los datos, las dependencias de los módulos, la jerarquía de archivos, el control del flujo de los símbolos gráficos y el paso de mensajes, cada una de estas vistas provee información importante para facilitar el mantenimiento.

3.2.1 Representación Textual

El desarrollo de lenguajes de programación de alto nivel como Pascal, C, C++ y otros tienen importantes avances de lectura de código y comprensión. Sin embargo es necesario considerar las siguientes reglas al editar el texto del código fuente.

Uso de nombres naturales. El uso de nombres apropiados para variables y procedimientos ayudarán a las personas de mantenimiento a tratar de comprender e inferir el significado de este nombre y descubrir el dominio del problema [LAI93].

El uso de comentarios. El uso apropiado de comentarios puede ser una invaluable ayuda para el proceso de comprensión del código.

Modularidad. Problemas complejos son usualmente descompuestos en subproblemas más pequeños, hasta que las partes sean reducidas a tamaños manejables [WR7 1 1,

I

,

23

Conceptos sobre Visualización de Software Capítulo 3

Buena impresión del código fuente. Esta sugiere el uso de indentación, espacios Y bloques esmcturados para hacer fácil la lectura del código para 10s programadores.

Aun considerando estas reglas, la representación textual de código aún no es suficiente para resaltar la relación entre las estructuras internas de un programa y especialmente cuando las relaciones son dispersas.

3.2.2 Representación Gráfica

Las representaciones gráficas son útiles para crear modelos cognoscitivos de estructuras de un programa [SHNSO]. Es importante utilizar técnicas de visualización para facilitar a las personas encargadas de dar mantenimiento el proceso de comprensión de programas.

Las vistas en la representación gráfica de código tienen el potencial de proveer estructuras valiosas de información, que puede ser rápidamente ocupada o desechada por el analista, dejando tiempo para aprovecharlo en otra aplicación [BUR96].

La mayoría de herramientas de visualización de software representan gráficas directas de estructuras de un programa, sin representar la profundidad, únicamente el significado de la gráfica del software de aplicación. Utilizando gráficas en 2 dimensiones (2D) se dificulta el entendimiento de sistemas grandes e imposibles de leer [ST095]. Para resolver ésto se sugiere añadir múltiples ventanas para crear símbolos gráficos más legibles, sin embargo sólo una pequeña área es visible a un tiempo y es fácil de perder el contexto con respecto al total del programa. Las representaciones gráficas en 3 dimensiones (3D) resuelven algunos problemas de despliegue de programas grandes y permiten anidar las gráficas en niveles posteriores para mostrar la vista de toda la estructura [BUR96].

3.3 Estrategias de visualización

Generalmente una presentación gráfica de código fuente ofrece una vista funcional superior del sistema comparado a la representación textual. Sin embargo, aunque la representación gráfica ha mejorado la presentación de código, existen algunas deficiencias que dificultan el mantenimiento de sistemas.

A continuación se describen 4 estrategias para facilitar la representación gráfica del código fuente para reducir el tiempo de mantenimiento de sistemas.

1. Simplificación Gráfica. Cuando el código llega a ser muy largo, es más compleja la comprensión de la gráfica, porque existe gran número de caminos de la representación gráfica del código. Para lograr simplicidad en la gráfica se sugiere realizar las siguientes acciones:

24

Capítulo 3 Conceptos sobre Visualización de Software

Enumerar las llamadas, Cuando existen multiples llamadas de funciones, la solución es reemplazar estas llamadas múltiples por una sola, anotando el número de veces que se llama a las funciones.

Ocultar Bibliotecas. Consiste en ocultar al máximo las bibliotecas (C, Windows). 0

Ocultar bibliotecas normales ANSI. Un proceso similar al descrito anteriormente.

Ocultar las llamadas a funciones externas. Es ocultar funciones externas que no son de importancia para interpretar el código o componentes de software.

2. Agrupamiento. Es un proceso mediante el cual los grupos de información son llamados y representados como grupos comunes. Un nuevo grupo reemplaza uno que ha sido removido. Por lo tanto, los nombres dados a los nuevos grupos representan la colección de llamadas que serán reemplazadas.

3. Disposición. La disposición frecuentemente depende de la aplicación del problema. Por esta razón las disposiciones son definidas en forma heurística. Esto incluye:

Usar líneas rectas Agrupar las llamadas que se realizan muchas veces en una estructura de más alto nivel Asegurar que existe suficiente espacio entre los símbolos gráficos Minimizar las líneas cruzadas Reducir la longitud de las líneas tan cortas como sea posible

4. Presentación y Representación en 3D. La presentación incluye color y vistas jerárquicas. A través de colores se puede diferenciar cada estructura de símbolos gráficos para destacar partes del programa. La disposición jerárquica del programa se divide por niveles, las estructuras de cada nivel son puestas en líneas horizontales y los subniveles son apilados en forma vertical. Y una representación tridimensional de un programa ofrece otra vista del sistema mejorando la visualización.

3.4 Expresión visual como medio de comunicación

A lo largo de la historia el hombre ha desarrollado sobremanera el oído y la vista con menoscabo de los demás sentidos [MAR97]. Y esto se produce en relación con la comunicación con el medio ambiente y para todo io creativo, de tal manera que puede observarse un enorme desarrollo de lo audiovisual, mientras el gusto y el olfato han quedado relegados a los placeres de la mesa. Los sentidos son las vías de la información de todo cuanto acontece a nuestro alrededor.

2s


En el proceso de la percepción audiovisual pueden 'establecerse tres pasos importantes. El primero se refiere a la mera sensación que aportan los sentidos, es decir, a las sensaciones visuales, auditivas o audiovisuales, todas estas generan la recepción informativa. El segundo registra la información en la memoria, la almacena para que luego sea recuperada y sometida a nuevos procesos de tratamiento. El tercero se centra en el procesamiento y en las interrelaciones de las informaciones almacenadas.

En este trabajo de tesis se considera la percepción de las imágenes como sistema expresivo que plasma la realidad y la transmite a unos destinatarios mediante la expresión visual de los objetos gráficos.

También se considera la percepción visual de los objetos gráficos como medio para percibir información, para orientar al órgano de la vista a efectuar una selección informativa y procesarlo a través de un sistema de imágenes configurado en la retina que posteriormente, previa conversión en corrientes eléctricas aptas para ser trasladadas por el sistema nervioso, son conducidos al cerebro.

I

I

Los órganos de la vista perciben la información de los objetos mediante la luz. La luz es un fenómeno cósmico electromagnético que sirve como portador de información.

El ojo humano capta sólo la luz visible que ,es una parte muy reducida del espectro global, como puede apreciarse en la figura 3.1.

26


Figura 3.1 Espectro cósmico electromagnético global.

Las imágenes gráficas se traducen en impulsos eléctricos a través de la retina. El sistema biocular humano permite también efectuar una visión tridimensional de la realidad, ocupada por los objetos gráficos con sus tamaños, posiciones, movimiento, dirección y velocidad.

La visión requiere además una cierta agudeza visual. De ella depende la capacidad de reconocer las imágenes. La agudeza visual está condicionada por la iluminación y color, esto da una riqueza de la realidad y su percepción un aumento de la información visual.

La representación de la realidad está íntimamente vinculada con el factor de iconicidad de la información. Lo icónico se caracteriza por el mayor grado de semejanza que guarda un objeto, hasta la representación exacta de todas sus peculiaridades.

En la actualidad la representación por imágenes tiene una novedosa expresividad visual y se ha podido mejorar mediante procesos digitales por computadora. Esto ha dado como resultado una gran gama de iconicidad, varia desde imágenes abstractas como líneas, volúmenes y colores combinados de diversos modos, hasta la imagen figurativa que representa la forma esquemática, con un total realismo, objetos reconocibles en la realidad

I I

21

Capítulo 3 Conceptos sobre Visualizaci6n de Software

pasando por toda multiplicidad de imágenes simbólicas que sirven para representar convencionalmente una realidad como diagramas y esquemas. Estos diagramas y esquemas aportan elementos importantes para la recepción y la rapidez con la que se pueden comprender los símbolos gráficos. Todos estos elementos fueron considerados para desarrollar el presente trabajo.

3.5 Estado del arte en herramientas de visualización

A continuación se da un breve panorama del estado del arte en las herramientas de visualización en un sentido general, así como las características generales de algunos productos.

'3.5.1 Caso de estudio para mejorar la representación visual de código

Este estudio describe el trabajo aportado por la investigación del grupo de visualización de mantenimiento de software de la Universidad de Durham [BUR96]. Este sirve para obtener un alto nivel de comprensión en la representación gráfica para aquellos programas que tenga una sobrecarga de información. Así el trabajo del grupo de visualización ha estado investigando estrategias y heuristicas para la representación de información gráfica. Las estrategias que consideran son simplificación de la gráfica, agrupamiento, disposición, presentación y representaciones en tres dimensiones (3D).

Un gran número de herramientas de s o h a r e están disponibles para ayudar a personas de mantenimiento para entender un sistema, por ejemplo McCabe, Logiscope y SNiFF+l. Estas herramientas proveen una representación gráfica de varios aspectos del software. Las gráficas producidas por estas herramientas desafortunadamente no son bien presentadas, muchas gráficas no representan el dato desplegado y existen problemas de espacio entre nodos. El control del flujo gráfico producido por las herramientas es muy estático.

Para la representación de las gráficas del código se consideran únicamente el nombre de las funciones y las llamadas. El nombre será un rectángulo definido como nodo que representa la función y una flecha que representa la llamada de la función, que se define como arco. Un ejemplo de ésto se muestra en la figura 3.2.

28


nombre de la función (nodo)

4

Figura 3.2 Representación gráfica de las funciones mogost-open - window

y XmSetConstraints.

Los ejemplos usados en este caso de estudio son tomados de Mosaic (NCSA Mosaic para X Windows, Copyright 1993) escrito en lenguaje de programación C. El programa seleccionado para este caso es gui-dia1ogs.c esta compuesto de 80 funciones, de aproximadamente 300 llamadas a funciones y de 50,000 líneas de código. Sin embargo, la representación gráfica de programas puede ser aplicable al más moderno lenguaje de programación. En la figura 3.3 se muestra la representación inicial del programa gui- dia1ogs.c.

. 29

Capítulo 3 Conceptos sobre Visualización de Software

Figura 3.3 Representación gráfica del programa gui-dia1ogs.c.

Como podrá observarse la gráfica tiene muchos arcos cruzados entre nodos, ofreciendo poca información útil para facilitar el mantenimiento.

Para facilitar el mantenimiento y visualización del código en este caso de estudio, se utilizaron 4 estrategias importantes. Estas son:

1. Simplificación de la gráfica 2. Agrupamiento 3. Disposición 4. Presentación y Representaciones en tres dimensiones (3D).

1. Simplificación de la gráfica. Una estrategia importante en el estudio realizado fue la simplificación de la gráfica a través de enumerar los arcos y ocultar bibliotecas ANSI.

Enumerar los arcos. En los estudios del sistema se identifico que existían múltiples llamadas de una función a otra, principalmente dirigida a múltiples arcos entre nodos. Una

30


solución fue reemplazar estos arcos múltiples con un solo arco. Un ejemplo de esto se muestra en la figura 3.4.

Figura 3.4 Reducción de arcos múltiples.

Utilizando el procedimiento de enumerar arcos se reduce aproximadamente el 40% de arcos, la gráfica actualizada se presenta en la figura 3.5 dando una mayor claridad que la gráfica de la figura 3.3, pero todavía la imagen es confusa.

31

_ -


Figura 3.5 Gráfica después de enumerar y remover los arcos múltiples

La segunda acción para la simplificación de la gráfica es ocultar la tercera parte de las bibliotecas. Estas pueden incluir las bibliotecas de C, de Windows o de WMotif. En la figura 3.6 se muestra la gráfica obtenida después de ocultar las bibliotecas.

I

32

El ocultamiento de las bibliotecas de C, Windows y M o t i f reduce 43% de nodos y 68% de arcos de la gráfica. Logrando más visualización de la gráfica.

2. Agrupamiento. Este es un proceso mediante el cual los grupos de información son representados como nodos comunes. Un nuevo nodo reemplaza uno que ha sido removido. Los principios son agrupar funciones que llaman a otros archivos del. código fuente y agrupar funciones que llaman a otras bibliotecas. El resultado de agrupar la gráfica se muestra en la figura 3.7. Se logro ocultar 30 nodos y 84 arcos.

33

.-


I

Figura 3.7 Gráfica con agrupamiento de nodos y arcos.

3. Disposición. Esta estrategia incluye algunas disposiciones heurísticas para mejorar la gráfica como son: usar líneas rectas, minimizar las líneas cruzadas, reducir la longitud de líneas y dar más espacio entre nodos. En la figura 3.8 se muestra el resultado de esta estrategia.

34

SE

I

Capitulo 3 Conceptos sobre Visualizacibn de Software

Figura 3.9 Gráfica aplicando colores y vistas en 3D.

Conclusiones del caso de estudio

Este caso de estudio utilizó la representación gráfica como un medio para facilitar el entendimiento de código fuente, para mejorar el mantenimiento de sistemas, utilizando un programa grande y complejo (gui-dia1ogs.c). También se consideró la complejidad que tiene visualizar código en forma gráfica y la importancia que tiene el aplicar estrategias para mejorar la visualización del código fuente. Se observó que en algunos casos no se podrán aplicar las mismas estrategias porque se pueden ocasionar errores de visualización en la gráfica, para ésto se tendrá que hacer una análisis del problema y de la estrategia a utilizar. Uno de 10s resultados importantes de esta investigación es que se observa que existe la posibilidad de automatizar este proceso.

36


3.5.2 VIASOFT'S WAmenaissance

Esta herramienta fue desarrollada por Viasoft's, Inc en Phoenix para extraer (buscar) funciones de programas escritos en lenguaje Cobol que existen en depósitos y con éstos crear nuevos programas considerando nuevas especificaciones [HAN91]. También Viasoft's toma componentes (piezas) de código para permitir el reuso de este en otros programas. En la figura 3.10 se muestra el ciclo para crear programas de aplicación.

Esta herramienta existe en versión Beta en el sistema operativo VMS. Esta provee habilidades para crear símbolos gráficos indicando lo que hace el código fuente en Cobol para habilitar al programador para ver la representación gráfica de un programa. Permite al usuaiio visualizar más de 20,000 líneas de código fuente en pantalla en una estación de trabajo, donde puede ser analizado y manipulado tanto como se necesite.

Otras características de esta herramienta son las siguientes:

Permite dar fácil mantenimiento al código existente.

Permite quitar funciones redundantes y facilita la creación de funciones nuevas en módulos simples.

Permite mover funciones desde un programa a otro.

Figura 3.10 Ciclo de vida de la Reingeniería para crear programas de aplicación utilizando de herramienta VIASOFT'S VIABenaissance.

Capítulo 4 Metodo para Mejorar la Legibilidad del Software

CAPITULO 4

q E T 0 R L A L E G B IDAD EL SOFTWARE

En este capítulo se explica como funciona el método de Reingeniería de Datos para mejorar los datos incorrectos de un programa estructurado escrito en lenguaje de programación C, para ésto, es necesario descomponer el programa en estructuras secuenciales y de control, con el propósito de identificar las lecturas y escrituras para verificar su correctés, este proceso se realiza a través de un análisis sintáctico automático utilizando expresiones regulares y autómatas de estado finito.

,Z , i I

38

Capitulo 4 Método para Mejorar la Legibilidad del Software

4.1 Introducción.

Una necesidad que tienen quienes se dedican a dar mantenimiento de Software es lograr comprender y mejorar el flujo de datos de un programa estructurado. Esta tesis propone un método de Reingeniería de Datos en combinación con las teorías de abstracción de datos para rediseño de sistemas, para lograr eliminar el flujo de datos incorrectos y mejorar el alcance de datos, en forma automática, a través de expresiones regulares y autómatas de estado finito.

4.2. Expresiones Regulares para mejorar tipos de datos

Para la implementación del “Procesador gráfico para automatizar la legibilidad de código fuente para un integrador de componentes reusables”, se utilizaron expresiones regulares para manipular los tipos de datos de un programa estructurado con el propósito de mejorar su legibilidad y verificar su correctés. A través de las expresiones regulares se pueden referenciar los tipos de datos para verificar si son correctos, en qué línea de código se encuentran, tipo de estatuto y en qué tipo de estructura se están utilizando.

Las expresiones regulares se derivan por un análisis sintáctico del programa fuente, para que después se analicen a través de un autómata de estados finito, para identificar posibles errores en los tipos de datos y generar de nuevo el código del programa fuente, pero mejorado.

La definición de expresiones regulares está basada sobre cómo se usan los datos en los diferentes tipos de datos y estructuras de control en un programa estructurado. Para generar las expresiones regulares se consideran las siguientes condiciones:

En una asignación, la parte izquierda del dato es una escritura y el lado derecho del dato es una lectura (R).

En una prueba condicional, estructura de control de decisión o de iteración , el tipo de dato es solamente de lectura (R).

En estatutos de entrada, los tipos de datos son de escritura (W).

En los estatutos de salida, los tipos de datos son de lectura (R)

Para facilitar el análisis de las expresiones regulares se adoptan tres categorías: ‘‘lecturas’’ (R) y “escrituras” (W), y, por conveniencia una categoría adicional “no usado” (N). En la tabla 4.1 se muestra la equivalencia de estas categorías en lenguaje C:

39

Capítulo 4 Método para Mejorar la Legibilidad del Software

Prueba condicional if(exp1) if( R ) for(;expl ;) for( ;R, ) while(exp1) while( R ) do { do{

I }while( R ); I Jwhile(exp1);

Entrada gets(exp 1); getsíw); scanf(‘“hcodigo”,exp 1); scanf(“?hcodigo”, W);

I printf(“%codigo”,expl); I printf(“%codigo”,R); Tabla 4.1 Equivalencias de categorías de expresiones regulares en lenguaje C.

A cada tipo de estructura de control se le define una expresión regular.

Estructura -secuencial’. El dato utilizado será concatenado.

Estructura de ’decisión compuesta‘. La ramificación binaria de los datos utilizados será separada por la barra I que significa “sino” .

Estructura ’decisión múltiple‘. Los datos utilizados en la prueba serán separados por el símbolo menos - de los casos y íos datos utilizados en los diferentes casos serán encerrados entre paréntesis separados por una coma para cada caso.

Estructura ’mientras’ con la condición al principio. Se ocupa el operador asterisco * antes de los datos usados dentro de la estructura.

Estructura ‘mientras’ con la condición al final. Se ocupa el operador más + antes de los datos usados dentro de la estructura.

Estructura ’para’. Los datos utilizados en la prueba son encerrados entre llave izquierda { y llave derecha }, y entre paréntesis ( ) los datos usados dentro del ciclo.

La tabla 4.2 resume las reglas para construir las expresiones regulares para cada una de las estructuras básicas del lenguaje de programación C.

40


ecuencial

)ecisión

teración

Ta

icpl = exp2; rcpy(exp1 ,exp2); ets(exp1); :anf("%codigo",expl ); uts(exp 1); rintf("%codigo",expl ); 'ompuesta: if (expl) exp2;

else exp3;

4últiple: switch(expl){

case consl: exp2; case cons2: exp3; case cons3: exp4;

1 4ientras con la condición ai inicio: while(exp 1)

exp2;

dientras con la condición al final: do {

exp2; Jwhile(exp1);

'ara: for(exp1; exp2; exp3)

exp4; L 4.2 Reglas para formar la expresion

Erpresiún regular :xpl erp2 :xpl exp2 :xpl :xpl :rpl :xpl

cxpl (exp2 esp3)

expl - (exp2,exp3,exp4)

expl * (exp2)

expl + (exp2)

{ expl ,exp2,exp3}(exp4)

~ regulares.

Para cada tipo de dato se construye una expresión regular analizando el programa de arriba hacia abajo (bottom-up). Aplicando las reglas de la tabla 4.1 se construyen expresiones regulares considerando todos los tipos de datos utilizados jerárquicamente en el programa. Por ejemplo la tabla 4.3 muestra las expresiones regulares del programa fact0r.c de la figura 4.1. Para facilitar la comparación, se incluyen los tipos de estatutos y las estructuras de control. El renglón final de la tabla 4.3 muestra la expresión regular para cada tipo de dato utilizado en todo el programa.

41

Método para Mejorar la Legibilidad del Software Capitulo 4

#include <stdio.h> I* Programa fact0r.c */

I main() { int n,m,COUNT.FACTOR: 2 3 4 5 6 7 8 9 IO 1 1 12 13 14 15 16 17 18 19 20 21 22 23

scanf(""d",&n); m = n; COUNT=O; if ( n e ) printf("%d Valor muy pequeño ",n);

else { printf( "Los valores de %d son: ",n); FACTOR=2; while

(FACTOR <= m) if

( (m %FACTOR) = = O) { COUNT = COUNT + I ; printf(" Factor # %d es *., COUNT,FACTOR); m = m I FACTOR;

I else

FACTOR = FACTOR + I ; 1

24 1 Figura 4.1. Programa fact0r.c para encontrar los factores de un número no primo.

42


4.3 Método de Reingeniería de datos

Una alternativa para mejorar el flujo de datos de un programa estructurado es a través de la Reingenieria de Software. Definiendo Reingeniería de Software como: “El proceso de modificar los mecanismos internos de un programa o estructura de datos de un sistema para mejorar su funcionalidad ‘‘ [ARN93].

Una de las funciones de la Reingeniería de Software es mejorar el código y las tecnologías asociadas a ésta son: Reestructuración de programas, Redocumentación, Ingeniería para el reuso, Remodulación, Análisis para mantenimiento, Reingeniería para procesos industriales y Reingeniería de datos.

En el presente trabajo se utiliza la Reingeniería de datos para lograr recobrar el control del flujo de datos de un programa existente, con el propósito de mejorarlo para facilitar el mantenimiento de éste. Para ésto existen tres métricas importantes a considerar las cuales se describen a continuación:

Datos referenciados: Es identificar todos los mismos tipos de datos referenciados entre un rango de líneas de código. Uso de datos globules: Identificar los tipos de datos que tienen referencias a variables globales. Medir el uso de los datos: Medir cada tipo de datos donde son usados y qué valores tienen en un segmento de código o en un programa completo.

La Reingeniería de datos también combina las teorías de tipos datos abstractos para reestructurar un programa existente. Para el presente trabajo se consideran la primera y la tercera métricas que se definieron anteriormente y únicamente se analizan tipos de datos simples (lecturas y escrituras en estructuras secuenciales, de alternación y repetitivas) y no considera tipos de datos complejos como: estructura de datos, organización de archivos y bases de datos.

Para esta aplicación las expresiones regulares consideran pocos tipos de datos, pero se puede generalizar para tipos de datos complejos y otras operaciones.

El primer paso para la Reingeniería de datos es reconocer y eliminar varios tipos de datos, para mejorar el flujo de datos de un programa que está formulado incorrectamente. Los tipos que considera la Reingenieria son: datos de lectura no inicializados, datos de escritura no utilizados, tipos de datos sobrecargados y reducir el alcance de los datos. Este trabajo únicamente es capas de detectar y corregir los dos primeros. Un análisis de los datos usando expresiones regulares permite una rápida reorganización de datos anómalas.

La detección de datos incorrectos se hace a través de un autómata de estados finitos, analizando cada tipo de dato y su expresión regular equivalente por medio del

43

Capitulo 4 Método para Mejorar la Legibiiidad del Software

reconocimiento de patrones de datos incorrectos [HAUSj]. Las técnicas empleadas en este trabajo se discuten a continuación.

11 if(x -i O) 12 printf(‘%d es negativoh”,x); 13 else

Datos de lectura no inicializados. Cuando un tipo de dato es de lectura y no existe una operación previa de escritura para asignar un valor al tipo de dato, entonces ésto es incorrecto. Para identificar esta situación se genera y se analiza una expresión de cada tipo de dato y si antes de una R no existe una W, entonces esta expresión es incorrecta. En la figura 4.2 se muestra un ejemplo de este tipo de error y la expresión regular..

W R )

Fragmento de código incorrecto 10 int x:

/ Expmión regular para ei tipo x

15 printf(“%d es positivo\n”,x); I

I Fragmento de &digo corregido ] Expresión regular para el tipo x I 1 O int x; 11 x=o; 12 if(x < O) 13 printf(“%d es negativo\n”,x); 14 else

Datos de escritura no uti/izados. Esta anomalía puede ocurrir cuando un tipo de dato de escritura no es utilizado y nuevamente tiene asignado un valor. En este caso el diseño del programa podría contener consecutivamente vanas W’s. En la figura 4.4 se muestra un ejemplo de esta anomalía.

44


3 x=2; 4 printf(“Dar número ”); 5 scanf(“%d”,&n); 6 if(n%2) printf(“%d es impar “,n); 7 x=n;

W

ww

2 int x,n; 3 printf(“Dar número ”); 4 scanf(“%d”,&n); 5 if(nY02) printf(“%d es impar “p); 6 x=n;

I Fragmento de c6diyo corregido I Expresión reguiar para el tipo x I

W

4.4 Framework para buscar código fuente usando patrones de programas

Este Framework sirve para buscar y localizar fragmentos de código fuente que igualen ciertos patrones de programa, este tipo de búsqueda es de gran ayuda para grandes cantidades de fragmentos de código fuente [SAN94].

El Framework utiliza Reingeniería de datos, expresiones regulares y comprensión de programas a través de hipótesis para localizar código. Las especificaciones son escritas usando patrones de programas, estos patrones son una extensión usada de un lenguaje de programación existente. Las extensiones incluyen grupos de símbolos que pueden ser usados como sustitutos de entidades sintácticas en el lenguaje de programación. Para especificar una búsqueda se escribe uno o más de estos símbolos para igualar diferentes fragmentos de código, si estos símbolos son usados, entonces extrae el código fuente que corresponda a esta igualdad.

Existe el prototipo Scruple que sirve para experimentar con este Framework, utilizando dos lenguajes de programación C y PL/AS. Este prototipo automáticamente encuentra las entidades de código fuente que igualen las especificaciones escritas en el modelo del lenguaje Scruple a través de arboles sintácticos y autómatas de estados finito.

45

Capitulo 5 Arquitectura y Diseño del Procesador Gráfico

CAPITULO 5

j R AROUITE GRAFICO íSoftGrafl

En este capítulo se muestra la arquitectura y diseño de los módulos que forman parte del SoftGraf , la notación de jerarquía de cajas estructuradas, las estructuras de datos utilizadas para visualizar y mejorar el código y también se describen las ayudas de la herramienta y la interfaz gráfica del usuario.

46

~ ~ .

Arquitectura y Diseño del Procesador Gráfico Capitulo 5

5.1 Antecedentes

El “Procesador Gráfico para automatizar la legibilidad de código fuente para un integrador de componentes reusables” SoftGraf, forma parte del proyecto AMbiente integrado de soporte para la Administración y desarrollo de Sistemas de Software“ AMASS-11, en la figura 5.1 se muestra la ubicación del SoftGraf, en este ambiente.

En abril de 1996, CONACyT otorgó financiamiento al proyecto Ambiente Integrado de Soporte para la Administración y Desarrollo de Sistemas de Software AMASS-I. El proyecto surgió de un análisis prospectivo realizado por el Grupo de Ingeniería de Software : del CENIDET en donde se establece la necesidad de contar con ambientes que apoyen la construcción y mantenimiento de sistemas de software. El proyecto que se propuso obtener con AMASS-I es un ambiente basado en herramientas y métodos de vanguardia como son la Programación visual, Reingeniería y Reusabilidad de software.

El proyecto AMASS-I está siendo actualmente desarrollado tomando como marco de referencia un modelo de ciclo’ de vida del software orientado a la, construcción, integración, reutilización y mantenimiento de componentes elementales de software. Sus etapas son análisis de requerimientos, diseño incluyendo componentes, composición, recuperación de componentes, adaptación, pruebas del sistema, y mantenimiento. El objetivo de este modelo es apoyar a los desarrolladores de software para obtener productos que garanticen una mayor calidad, plazos de desarrollo más cortos y costos más bajos. La obtención de componentes reusables se obtiene a través de varios procesos, estos son: análisis de dominios, diseño de frameworks, encapsulado de componentes, evaluación de componentes, recuperación de componentes (esta actividad es común al modelo antes mencionado), y mantenimiento de componentes.

El primer modelo se enfoca al desarrollo de nuevas aplicaciones, mientras que el segundo modelo se enfoca al desarrollo de componentes de software y por io tanto no sólo apoya a un desarrollador de una nueva aplicación, sino que también apoya al personal que construye componentes de software reusables independientemente de que vayan a ser empleados en alguna aplicación.

En la primera versión del proyecto (AMASS-I) se propusieron el desarrollo de tres herramientas que apoyaran algunas fases del ciclo de vida de los sistemas y de componentes reusables. Las herramientas que conforman AMASS-I son SISREC, LEVISS y DAPROG. También se propuso un sistema que fuera capaz de integrar a éstas y formar un ambiente, a ese sistema se le identifica como SAMI.

AMASS-I es el primer resultado que cumple parcialmente con el objetivo de este proyecto. La segunda versión de AMASS-I denominada AMASS-I1 pretende cumplir con otra parte de los objetivos planteados a través de la definición de metodologías y la construcción de herramientas para apoyar otras fases de los ciclos de vida mencionados. Se propone para AMASS-I1 la construcción de una herramienta (SoftGraf) que apoye el entendimiento de código para facilitar por un lado la adaptación o modificación de componentes y por otro lado el mantenimiento tanto de los sistemas como

47

.... ~. -- --


de los componentes, adicionalmente se proponen la definición de una metodología para realizar análisis de dominios con el propósito de construir componentes de software, y una metodología que nos permita traducir las necesidades reales del cliente a la especificación del sistema a desarrollar. La tendencia es la cobertura total de los ciclos de vida de software ya sea de sistemas o de componentes de software.

..

Análisis de dominios .. .. ... .. .. ...

Plataforma Metodológica

Definición de los subproyectos que forman parte del AMASS-I1

SoftGraf. Este sistema tiene como objetivo el representar gráficamente un programa escrito en lenguaje C para facilitar la adaptación de componentes yio mantenimiento de sistemas. Este subproyecto es complementario con DAPROG de AMASS-I, ya que ambos apoyan directamente la fase de mantenimiento del ciclo de vida de un producto.

Metodología para análisis de dominios. El objetivo de este subproyecto es el de definir una metodología que nos apoye en la construcción de componentes de software, y

48

Arquitectura y Diseño del Procesador Gráfico Capítulo 5

para la obtención de componentes de software reusables a partir de software existente de un dominio. Se propone esta metodología para apoyar la fase de análisis de dominios del ciclo de vida de un componente de software.

Modelado organizacional de procesos para la especificación de los requerimientos de un sistema de información. El objetivo de este subproyecto es el de desarrollar un modelo que capture la necesidades reales de un cliente y puedan éstas ser traducidas en la especificación del sistema a desarrollar.

Sistema para la especificación de gramáticas visuales. El objetivo de este proyecto es el de proveer una herramienta que apoye al ingeniero de software en la definición iterativa de gramáticas para lenguajes visuales, reduciendo así el tiempo de especificación de éstas. Esta herramienta se propone que sea construida para apoyar cualquier otra herramienta de tipo visual construida dentro del ámbito del AMASS-11. LEVISS y SAM1 constituyen m ejemplo de herramientas que emplean una gramática visual.

5.2 Arquitectura conceptual del Procesador Gráfico (SoftGraf)

Figura 5.2 Arquitectura del SoftGraf.

49

. .

Arquitectura y Diseño del Procesador Gráfico Capítulo 5

Esta herramienta tiene como dato de entrada (El) un programa estructurado escrito en lenguaje de programación C y cuenta con 4 módulos, como se muestra en la figura 5.2. A continuación se describe brevemente a cada uno de éstos.

Analizador del SoftGraf (Ml). Este sirve para clasificar las estructuras internas de un programa estructurado en estatutos secuenciales, de alternación e iteración. También se eliminan líneas en blanco, librerías y se insertan estas estructuras en una lista doblemente ligada.

Generación del Código Gráfico (M2). Este sirve para visualizar el código fuente en forma gráfica, para mejorar su comprensión.

Transformación Automática para mejorar el código (M3). Este módulo sirve para mejorar la legibilidad de los datos incorrectos del código fuente aplicando técnicas de Reingeniería de Datos y expresiones regulares.

Ejecución del Programa (M4). Este sirve para hacer pruebas al código fuente

Esta herramienta tiene como salidas el código representado gráficamente en jerarquía de cajas estructuradas (Sl), otra salida es el código mejorado en tipos de datos incorrectos de lectura y/o escritura (S2) y una última salida es el resultado de ejecutar el código fuente (S3).

En las secciones posteriores se describirán a detalle cada uno de estos módulos y las salidas correspondientes.

5.3 Módulo analizador del código fuente

En este módulo se analiza el código fuente escrito en lenguaje de programación C, para clasificar las estructuras secuenciales, de alternación e iteración, determinando la organización jerárquica de éstas, almacenando datos en una lista secuencia1 doblemente ligada, para que posteriormente en el módulo de visualización se tomen los datos correspondientes para poder representar en forma gráfica el código fuente.

5.3.1 Diagrama de Estructura del analizador

Este análisis tiene como función revisar la secuencia de caracteres que se recibe del código fuente (dato de entrada: un archivo de textos) para determinar si forman palabras o símbolos (tokens) propias del lenguaje de programación C. Mediante las palabras o símbolos se construyen las instrucciones del lenguaje C, para formar las estructuras de secuencia, alternación e iteración. Teniendo ya las instrucciones del lenguaje, se compara con una tabla de palabras reservadas (tabla 5.1) para determinar si es una estructuras activa o pasiva (una estructura activa es aquella que tiene generalmente un conjunto de instrucciones internas y una estructura pasiva no tiene instrucciones internas), para

50

Capitulo 5

determinar el nivel en la organización jerárquica del programa, los parámetros correspondientes de cada una de las estructuras y para clasificar las estructuras que se deben desplegar en pantalla de acuerdo al nivel de organización, considerando que por primera vez se muestren todas aquellas estructuras que pertenezcan al primer nivel, luego dependerá de la selección que haga el usuario que esté utilizando la herramienta.

Arquitectura y Diseño del Procesador Gráfico

A continuación se muestra el diagrama de estructura general de este módulo y todos los submódulos que lo forman.

I I I " . . . . . . ." . . ,I

I... , . . . . . . . . . . . ,. :.,.,, :; ... :,

I I I

A continuación se describen brevemente las tareas que realizan cada uno de estos submódulos:

51


Leer-Archivo. Este sirve para recorrer en forma secuencia1 el archivo de entrada para realizar las siguientes operaciones: quitar espacios en blanco, quitar líneas en blanco, ocultar librerías.

Prueba. Este submódulo sirve para formar los tokens con el objetivo de encontrar los niveles de las estructuras del código fuente, clasificar las estructuras en activas y/o pasivas, encontrar el final de los bloques de las estructuras activas, diferenciar la asignación normal con la del ciclofor, identificar el ciclo do como estructura iterativa mientras con la condición al final.

Scan. Este submódulo sirve para identificar si el token es una palabra reservada correcta, clasificar las palabras reservadas y analizar si son correctos los caracteres que forman los tokens.

ClaseScan. Este submódulo sirve para clasificar el caracter en letra, dígito, blanco o enter.

Token - AddCar. Este submódulo sirve para crear los tokens.

PalReservada. Este submódulo verifica si el token es una palabra reservada, regresando el valor de verdadero si es palabra reservada y también regresa el identificador de la estructura.

,

A u N u m . Este submódulo sirve para clasificar el token en tipo de dato entero o tipo flotante con signo.

Que-Clase. Este submódulo sirve para clasificar que tipo de clase es el caracter: letra, dígito, blanco, coma, punto y coma, paréntesis izquierdo, símbolo más, menos, multiplicación, etc.

Insert - End. Este submódulo sirve para crear la estructura de datos de una lista doblemente ligada. Se insertan los nodos al final de la lista y se inicializan los campos id, niv, x, y, parms, imp,finbk, tipo, los apuntadores izq y der, para que posteriormente sirvan para desplegar las estructuras del código en forma gráfíca.

Recorre - Do. Este sirve para asignar los parametros de la prueba del ciclo do, y es necesario recorrer la lista de derecha a izquierda para localizar dicha estructura, ya que este tipo de estructura tiene la prueba al final del ciclo.

5.4. Módulo visualizador de código fuente

Este módulo sirve para representar gráficamente el código fuente escrito en lenguaje de programación C. La distribución de los objetos es bajo el principio de organización jerárquica (estructura tipo arborescente), considerando algoritmos de navegación, para que

52

* Capitulo 5 Arquitectura y Diseno del Procesador Gráfico

el usuario pueda seleccionar y tratar de comprender las estructuras internas que forman el programa e inferir la función del programa.

5.4.1 Estructura de Datos para visualizar código

Para poder visualizar el código en forma gráfica fue necesario crear estructuras de datos que sirvieran para almacenar y manipular los atributos y el correspondiente objeto gráfico de dicho código. Para implementar este modulo se utilizaron las siguientes estructuras de datos:

Una lista doblemente ligada para almacenar todos los datos de las estructuras que forman parte de un programa, como son: el número de identificador de la estructura, el nivel de anidamiento, coordenadas de posición del objeto, los parámetros de la estructura, una bandera o señal para indicar cuando se debe desplegar el objeto en pantalla, fin de bloque para los objetos activos, una bandera para indicar si el objeto tiene más objetos, un apuntador hacia el nodo anterior y un apuntador hacia el nodo siguiente. En la figura 5.4 se muestra el modelo conceptual de esta estructura.

La estructura de datos de la figura 5.4 definida en lenguaje de programación C, se muestra a continuación:

typedef struct { int id,niv,x,y; char parms[l OO],imp[2],finbk[2]; char tipo; ./*activa o pasiva*/ struct APTR *izq, *der; } APTR

donde:

53

Capitulo 5

Ideiitificador


Palabra reservada

id. Es una variable de tipo entera en la que se va a almacenar el tipo de instrucción (programa principal, lectura, escritura, asignación, alternación, iteración) que representa ese nodo, este valor se toma de la tabla 5.1, esta variable también corresponde al tipo de bitmap que se va a presentar gráficamente de acuerdo a la tabla 5.2.

O main

3 4 5

I 2 StrCDv 1 I

scanf getchar eetch

6 7 8

gets printf

vutchar 9 10 11 12

I 13 I while 1

puts if

else switch

14 do 15 for

1 2

. 3 4 5 6 7 8

54

asignar asignar

leer leer leer leer

escribir escribir

9 10 11 12

escribir si

sino caso'

13 mientras 14 hazmientras 15 Para


niv. En este campo se almacena el nivel que le corresponde a cada una de las estructuras de un programa, para su representación gráfica, de acuerdo al principio de la organización jerárquica que propone Cuevas [CUE93].

x, y. Estos dos campos almacenan las coordenadas para ubicar el objeto gráfico en la pantalla.

parms. Esta campo sirve para almacenar todos los parámetros de las estructuras de un programa.

imp. Esta variable sirve para indicar cuales objetos gráficos deben desplegarse en pantalla. A este campo se le asigna un valor 'S' para indicar que se debe desplegar y un valor 'N' para indicar lo contrario.

finbk. Este campo sirve para indicar el fin de instrucciones para un objeto activo.

tipo. Esta variable sirve para indicar si un objeto es activo o pasivo. Para un objeto activo se le asigna un valor 'A' y para un objeto pasivo un valor 'P'.

5.4.2 Notación modificada para visualizar código

Para poder visualizar mejor el código representado gráficamente hé necesario modificar la notación cajas estructuradas y crear nuevos símbolos, como se muestra en las tablas siguientes:

I Función I Función 1 main() 1 no existe principal

Tabla 5.3 Notación gráfica para la función main. Tabla 5.3 Notación gráfica para

Tabla 5.4 Notación gráfica para construcciones de Secuencia.

55

Capítulo 5 Arquitectura y Diseño del Procesador Gráfico

múltiple

íonstrucción iásica Alternación

azul m switch(el){ no existe case ~ 1 x 2 ; case ~ 2 x 3 ;

mientras condición al final

I

Tabla 5.5 Notación gráfica para construcciones de Alternación.

do{ no existe cafe

} while(e 1); e2;

condición e2; ai inicio

Tabla 5.6 Notación gráfica para construcciones de Iteración.

5.4.3 Tipo de organización jerárquica para visualizar código

Para resolver un problema inforrnático, los conjuntos de información pueden organizarse de diferentes modos. Una de estas formas es la organización jerárquica.

Según el principio de organización jerárquica cualquier conjunto de información (sea el de datos de.entrada, el de datos de salida o el programa) debe subdividirse en subconjuntos, estructurándose en niveles desde el más alto hasta el más bajo.

Desde el punto de vista teórico, el principio de organizucih jerárquica puede interpretarse de la siguiente manera (figura 5.5).

56

Capitulo 5 Arquitectura y Diseño del Rocesador Gráfico

NIVEL O NIVEL 1 NIVEL 2

Figura 5.5 Principio de la organización jerárquica [CUE93].

El conjunto de información C se subdivide en los subconjuntos de primer nivel SI ,..., SI, (el nivel viene señalado por el índice su erior). Estos se subdividen a su vez, en subconjuntos de segundo nivel S2,;, ..., S ..., S ..., S2n,Kn y así sucesivamente hasta agotar la partición.

2 P

Para efectos de esta tesis se determinó dividir cada uno de los conjuntos de informaciones en objetos activos y pasivos, de tal forma que sea posible diferenciarlos entre sí:

los objetos activos son aquellos que generalmente llevan implícitos un conjunto de instrucciones, por ejemplo, si hablamos de un ciclo de repetición, éste es un objeto activo porque dentro de él pueden existir n conjuntos de instrucciones, que se van a estar ejecutando, por io tanto se dice que un objeto activo puede contener n conjuntos de objetos activos, pasivos o ambos, dando paso a la formación de los niveles de abstracción. El siguiente fragmento de programa escrito en lenguaje C, muestra un conjunto de información de este tipo:

for (a=l; a > 3; a++) if ( n ! = m )

printf("Va1or de m"); scanf("%d",&m); I

{

57


y los objetos pasivos son aquellos que no pueden contener a otros objetos, una muestra de éstos son las instrucciones secuenciales (entrada, salida, asignación). Por ejemplo:

printf("Dar datos"); scanf("%f',&datos); datos=234.67;

5.4.4 Organización de los objetos gráficos

Aquí se explica cómo se representa gráficamente el código fuente por primera vez en el área del cliente y cómo se calcula las coordenadas necesarias para mostrar los objetos gráficos. Esto se lleva a cabo recomendo de izquierda a derecha la lista doblemente ligada que almacena la información del código fuente, analizando cada uno de los nodos de la lista, si el campo imp tiene el valor 'S', indica que se debe mostrar el objeto gráfico en la pantalla de la computadora de acuerdo al identificador de la figura 5.2. También es necesario calcular las coordenadas: del objeto gráfico, del parámetro del objeto, de las líneas horizontales y verticales del objeto. Para la distribución de los objetos se aplica el principio organización jerárquica de la figura 5.5. A continuación se describe cómo se calculan estas coordenadas, tomando como entrada el programa de la figura 5.7 y como salida la figura 5.6.

Coordenadas x, y del objeto gráfico. El tamaño de los objetos gráficos (bitmaps) es de 32x32 pixeles, el número de espacios entre objetos gráficos hacia la derecha y abajo es de tres, las coordenadas iniciales es x=O, y=O, como se muestra en la figura 5.6.

El valor de x se multiplica por el nivel del objeto, al valor de y se le suma el tamaño del Bitmap más los espacios entre los objetos. En la figura 5.6 se muestra las coordenadas de 5 objetos y en el algoritmo 5.1 se muestran las fórmulas. Por ejemplo, para el primer objeto, las coordenadas son: x= O * 34 donde x=O; y=O, después al valor de y= O + 31 + 3 donde y=34, para el segundo objeto las coordenadas son: x=34, y=34, así sucesivamente.

Para calcular el valor de las coordenadas del parámetro del último objeto, donde x=68, y=136 entonces xp=x+34, yp=y+I O, xp=68+34, yp=136+10 los valores serian xp=102, yp=146, como se muestra en la figura 5.6 y el algoritmo 5.1.

Coordenadas de líneas horizontales. Estas se calculan a partir del segundo objeto, en la figura 5.6 se muestra un ejemplo y en el algoritmo 5.1 se muestran las fórmulas. El tamaño de la línea es fijo (1 8 pixeles). Por ejemplo para el calculo de las coordenadas del segundo objeto de la figura 5.6, donde x=34, y=34 entonces Ihxl=x, lhyl=y+l5,lhx2=x-l8, lhy2= lhyl los valores serian lhxl=34, lhyl=34+15=49, lhx2= 34 -18=16, Ihy2= 49.

58


Coordenadas de líneas verticales. Estas se calculan a partir del segundo objeto, en la figura 5.6 se muestra un ejemplo y en el algoritmo 5.1 se muestran las fórmulas. El tamaño de la línea es variable, ya que depende de si el objeto es activo o pasivo. El algoritmo 5.2 muestra como se pintan las líneas verticales de diferentes tamaños. Por ejemplo para el calculo de las coordenadas del último objeto de la figura 5.6, donde x=68, y=136 entonces, lw2= x-18, lvy2= y+15 los valores serian lvx2= 68 -1840, lvy2= 136+15=151. A partir de este punto inicia pintando pixeles de abajo hacia arriba y termina hasta que encuentre un punto color negro como se muestra en la figura 5.6

En el algoritmo 5.1 se muestra cómo recorre la lista de izquierda a derecha, calcula coordenadas de los objetos, de los parámetros, pinta el Bitmap, escribe el texto de los parámetros, calcula las coordenadas y pinta las líneas horizontales y verticales en el área del cliente, por Último actualiza las coordenadas en la lista.

Algoritmo Recorre Lista Pixel-Inicial=l ; TamañoBitMap=32-Pixel-Inicial; Espacios=3; y=O; x=O. Recorrer Lista hasta el final

Si Lista->imp=’S’entonces x = Lista->niv * 34; /* coordenada del objeto */ xp= x + 34; Lista->x=x; Lista->y=y; /* Almacena las coordenadas en lista */ Pinta - BitMap(manija, x,y,BitMap[Lista->id]; /* pinta el bitmap*/ Ihxl=x; Ihyl=y+l5; lhx2= x -18; lhy2= Ihyl; /*coordenadas línea horizontal*/ MoveTo(manija,lhxl Jhyl); LineTo(manija,lhx2,lhy2); /* pinta línea horizontal*/ lvx2=x- 18; Ivy2=y + 15; /* coordenadas línea vertical*/ Pinta - LineaV(manija,lhx2,lhy2); /* pinta la línea vertical */ y= y f TamañoBitMap + Espacios; /*coordenada del objeto*/ yp= y + 10; /*coordenada del parámetro*/ TextOut(manija,xp, yp,Lista->parms, tamaño); /* pinta el parámetro */

/* coordenada del parámetro */

Fin-Si Fin-Recorre Lista

Algoritmo 5.1. Recorrido de la lista.

59

.. . .


Algoritmo Pinta-LineaV(manija, lvx2,lvy2) COLORREF color; /* maxx es el valor máximo del área del cliente */ lvy2=lvy2 - 1 ; /* se resta 1 para iniciar a pintar pixeles color= GetPixel(hdc,lvx2,1vy2); /* toma el color del pixel */ /* hasta que encuentre un pixel de color negro valor 1 termina de pintar pixeles */ Mientras (color!=O && (lvy2>0 && lvy2 < maxx)) hacer SetPixel(hdc,lvx2,lvy2,1); /* pinta la línea de abajo hacia arriba */ lvy2=Ivy2-1; /*resta 1 para pintar el pixel de arriba y descubrir si hay un pixel negro*/ color=GetPixel(hdc,lvx2,lvy2); /* toma el color del pixel */

Fin-Mientras Fin-Algoritmo Pinta-LineaV

Algoritmo 5.2. Pinta línea vertical

60

19


clrscro; while(n<3) 1

I intn; I 13 1

< printf("Dar número"); scanf("%d,&n); n=n- 1 ;

1 }

7 2 3 2 1 2 16 1 16 O

Figura 5.7 Programa prueba.c.

- Campos del nodo de la lista

soordenadar del objeto x y. ~wiynnros del objeto, imprimir VN, fin d i bloke S/N,tipo. a n i r d p a i v ~

lista doblemente ligada

' , l .. > , \ , P

n3 l _n l

I I Figura 5.8 Lista doblemente ligada del programa prueba.c.

62

E9


5.4.5.1 Expandir niveles de mayor abstracción de un objeto

Para ver los objetos que se encuentran dentro de un objeto activo, se debe seleccionar con el cursor del mouse y dar un clic con el botón izquierdo al objeto que se desee expandir.

El proceso que se realiza es el siguiente:

1. Si el usuario oprime el botón izquierdo del mouse (generando un mensaje WMLBUTTONUP) entonces se toman las coordenadas del cursor del mouse de la estructura org.x, 0rg.y (tipo MAKEPOINT(1Param)).

2. Recorrer toda la lista doblemente ligada que almacena la información del código fuente @.e. figura 5.8) de izquierda a derecha, analizando cada uno de los nodos de la lista.

2.1 Comparar si el identificador del nodo de la lista es un objeto activo. Es un objeto activo cuando el identificador esta entre el rango del 1 O al 15 de acuerdo a la tabla 5. I . Si ésto es verdadero, entonces después se comparan las coordenadas del org.x, 0rg.y del mouse con las coordenadas x, y del objeto utilizando la siguiente expresión:

(0rg.x >= L->x && 0rg.x <= L->x+31) && (0rg.y >= L->y && 0rg.y <= L->y+3 I )

Esta expresión indica que las coordenadas del mouse pueden estar en cualquier punto del área del objeto seleccionado, entre el rango del extremo superior izquierdo (x,y) y el extremo inferior derecho (x+3 1 ,y+3 1) del objeto, como se muestra en la figura 5.1 1. Si esta prueba es verdadera entonces se recorre la lista a partir del nodo siguiente, asignando el valor de ‘S‘ al campo imp del nodo, ésto se repite hasta encontrar el fin el bloque.

3. Representar gráficamente el código

3.1 Nuevamente recorrer la lista doblemente ligada de izquierda a derecha y en todos los nodos que en su campo imp tengan el valor de ’S’, imprimir el objeto gráfico de acuerdo su identificador y actualizar nuevamente las coordenadas de los objetos que se expandieron.

Ejemplo para expandir objetos

Considerando como ejemplo el programa prueba.c de la figura 5.9, a continuación se describe brevemente los pasos que se realizan para expandir los objetos:

1. El usuario selecciona con el mouse el segundo objeto de la figura 5.9, considerando que fueran las coordenadas del cursor del mouse org.x=49, org.y=38 como se muestra en la figura 5.1 1.

64


Figura 5.1 1 Ejemplo para sensar un objeto

2. Recorrer la lista de izquierda a derecha de la figura 5.10 hasta encontrar las coordenadas del objeto seleccionado o hasta terminar de recorrer toda la lista.

2.1 Comparar si el objeto es activo.

La prueba del primer nodo es falso porque el campo tipo tiene el valor de P. Entonces se prueba el siguiente nodo.

La prueba del segundo nodo es verdadero porque el campo tipo tiene el valor de A, que pertenece a la estructura mientras del programa prueba de la figura 5.7 y el identificador No. 13, indicando que es un objeto activo. Entonces se realiza la prueba si las coordenadas del mouse pertenecen a este objeto. Considerando las coordenadas del mouse de la figura 5.1 1 y las coordenadas del objeto activo x=34, y=34 de la figura 5.10. La expresión sería la siguiente:

(49 >= 34 y 49 <=68) y (38 >= 34 y 38 <= 68)

el resultado de esta expresión es verdadero, por lo tanto indica que el objeto seleccionado por el usuario es éste, entonces a partir del siguiente nodo de la lista (figura 5.10), se asigna el valor de 'S' en el campo imp de los tres nodos siguientes, hasta encontrar el identificador 16 que indica que es el fin de bloque o cuando el campoJinbk tenga el valor de 'S'. En la figura 5.12 se muestran estos tres cambios:

65

. -


Campos del nodo de la lista

coordenadas del objeto X. Y. parametros del objeto, imprimir S N , fin de bloke S¡N,tipa. aitiuolpar~uo

. . Lista doblemenle ligada

I Figura 5.12 Lista con los nodos modificados en el campo imp.

3. Representación gráfica del código.

3.1 Después se recorre de nuevo toda la lista de izquierda a derecha hasta encontrar el final de lista.

3.2 Se analiza el campo imp de cada uno de los nodos de la lista y si tiene una ‘S’ se despliega en pantalla su objeto gráfko correspondiente, para este ejemplo despliega objetos correspondiente a los cinco primeros nodos de la lista de la figura 5.12 y la representación del programa sería como se muestra en la figura 5.13, después se actualizan las coordenadas de los objetos en la lista como se muestra en la figura 5.14.

Figura 5.13 Ejemplo dc expandir objetos del programa pnicba c .

66

Capítulo 5 Arquitectura y Diseno del Procesador Gráfico

Campos del nodo de la lista

coordemdar del objno. ',y, parmetros del objeto, impnmii SIN, 6, de bloke: SNtipo: acl~volpar~uo

Lists doblemente ligada

1268.102. '%J ,pi F.N P

1.2 68.68 D r " L r n d d

S.%P

I Figura 5.14 Lista doblemente ligada del programa prueba.c con las coordenadas

actualizadas después de expandir los objetos.

5.4.5.2 Contraer niveles de menor abstracción de un objeto

Para ocultar 10s objetos que se encuentran dentro de un objeto pasivo, se debe seleccionar con el cursor del mouse y dar un clic con el botón izquierdo al objeto que se desee contraer.

El proceso que se realiza es el siguiente:

1. Si el usuario oprime el botón izquierdo del mouse entonces se toman las coordenadas del cursor del mouse de la estructura org.x, 0rg.y. Por ejemplo al seleccionar el segundo objeto del programa de la figura 5.13.

2. Se recorre toda la lista doblemente ligada que almacena la información del código fuente @.e. figura 5.14) de izquierda a derecha, analizando cada uno de los nodos de la lista.

2.1 Comparar si el identificador del nodo de la lista es un objeto activo. Si ésto es verdadero, entonces se comparan las coordenadas del org.x, 0rg.y del mouse con las coordenadas x, y del objeto seleccionado. Si esta prueba es verdadera entonces se recorre la lista a partir del nodo siguiente, asignando el valor de 'N' al campo imp del nodo, esto se repite hasta encontrar el fin el bloque. Este proceso es el inverso al expandir objetos. Para el ejemplo de la figura 5.1 3 se cumple esta prueba y se cambian los valores del campo imp por el valor 'N' del segundo, tercero y cuarto nodo de la lista de la figura 5.14. La lista actualizada con los nuevos valores queda como la lista de la figura 5.8.

3. Nuevamente se recorre la lista doblemente ligada (figura 5.8) de izquierda a derecha y en todos los nodos que en su campo imp tengan el valor de 'S' desplegar el objeto gráfico de acuerdo a su identificador (sería como se muestra en la figura 5.9 y después se actualizan nuevamente las coordenadas de los objetos que se ocultaron, la lista con sus coordenadas actualizadas quedaría como la figura 5.8.

67

Capitulo 5 Arquitectura y Diseño del Procesador GrAfico

5.5 Módulo para mejorar la legibilidad del código fuente

Este módulo sirve para detectar y corregir el flujo de datos incorrecto (Datos de lectura no inicializados y Datos de escritura no utilizados, ,sección 4.3) y mejorar el alcance de los datos. Para mejorar el código se utiliza el método de Reingeniería de datos, en combinación con expresiones regulares y autómatas de estados finitos. En la figura 5.17 se muestra el diagrama de estructura de este módulo y todos los submódulos que lo forman.

5.5.1 Estructura de Datos para mejorar el código

Para poder mejorar el código fue necesario crear estructura de datos que sirvieran para almacenar las estructuras internas de un programa escrito en lenguaje 'C' , manipular los tipos de datos y las estructuras donde se ocupan estos datos, así también en qué línea de código está el tipo de dato. Para implementar este módulo se utilizaron las siguientes estructuras de datos:

Una lista doblemente ligada para almacenar todos las líneas del código fuente, con un apuntador hacia el nodo anterior y un apuntador hacia el nodo siguiente. En la figura 5.1 5 se muestra el modelo conceptual de esta estructura.

~~~ ~~ ~~~

Figura 5.15. Modelo conceptual del nodo de la lista para almacenar una línea de código.

A continuación se muestra la estructura de datos de.la figura 5.15 definida en lenguaje de programación 'C'.

#define longcod 120 struct linea { char codigo[longcod]; struct linea *sig; struct linea *ant;

1;

donde:

68

Capítulo 5

codigo. Este campo sirve para almacenar una línea del código fuente. Es una variable tipo cadena de longcod caracteres.

Una lista simplemente ligada para almacenar todas las variables: nombre y tipo, la expresión regular correspondiente a cada tipo de dato y un apuntador hacia el nodo siguiente. En la figura 5.16 se muestra el modelo conceptual de esta estructura.

Arquitectura y Disefío del Procesador Gráfico

Figura 5 16 .Modelo conceptual de los nodos que almacenan los datos del programa fuente.

A continuación se muestra la estructura de datos de la figura 5.16 definida en lenguaje de programación 'C'.

struct var { char nombre[25]; char tipo[20]; char expresion[200]; struct var *sig;

1;

donde:

nombre: Este campo sirve para almacenar el nombre.de la variable del código fuente.

tipo: Este campo sirve para almacenar el tipo de la variable (int, char, float).

expresion: Este campo sirve para almacenar el número de línea donde se encuentra la variable a analizar y la expresión regular correspondiente a la variable y a la estructura del código fuente, para generar la expresión regular se aplican las reglas que se encuentran en la tabla 4.2 del capítulo 4.

En el capítulo 4 se explicó el método de Reingeniería de datos para mejorar la legibilidad del Software, las regias para construir las expresiones regulares, las reglas para identificar datos de lectura no inicializados y datos de escritura no utilizados.

69

http://nombre.de


5.5.2 Diagrama de Estructura para mejorar código fuente

A continuación se muestra el diagrama.de estructura de este módulo Y se describen brevemente las tareas que realizan cada uno de 10s submódulos que lo forman.

Figura 5.17 Diagrama de estnictura del Módulo para mejorar código.

5.5.2.1 Analizador de código. El submódulo Analizador-de-código, sirve para recorrer en forma secuencia1 el archivo de entrada para realizar las siguientes operaciones: Inicializar con valores de nulo todos los nodos de la lista (figura 5.15) para almacenar líneas de código, eliminar líneas de código en blanco, contar las líneas del código, insertar la línea del código al final de la lista, también inicializar con valores de nulo la lista de variables (figura 5.16), identificar todas las variables del programa tomando el nombre y tipo, por último almacenar estos dos datos e insertar el nuevo nodo al final de la lista de variables.

5.5.2.2 Generador de expresiones regulares. El submódulo GenExpReg, sirve para crear expresiones regulares para cada una de las variables del programa, considerando cómo y dónde se esta ocupando la variable, ésta puede estar en una estructura tipo secuencia, alternación e iteración, o una combinación de éstas, también es necesario clasificar la variable como dato de lectura y/o escritura. Las reglas utilizadas para formar las expresiones regulares para cada una de las variables, con su estrucma correspondiente, es de acuerdo a la equivalencia de categorías de la tabla 4.1 y las reglas de la tabla 4.2 descritas en el capítulo 4.

70

http://diagrama.de


El proceso para generar las expresiones regulares es el siguiente:

1. Recorrer la lista de variables hasta el final de la lista. 1.1 Para cada tipo de variable recorrer la lista de código

a) Verificar en que tipo de estructura se esta utilizando la variable y en qué número de línea de código, entonces, generar su expresión regular correspondiente: [número línea] dato de lectura o escritura, por ejemplo el fragmento de código siguiente: 12 while( X >l ) 13 scanf (“%d”,&X), considerando que la variable X es de tipo entera, la estructura es mientras y de lectura, están en la línea número 12 y 13 respectivamente, entonces la expresión regular sería: [I21 R* ([13]W).

b)Almacenar la expresión regular en el campo expresion de la lista de variables

fin del paso 1.1 fin del paso 1

5.5.2.3 Mejorar datos de lectura no inicializados. El submódulo Mej - Dato - LecturaNo-hi, sirve para corregir un tipo de dato de lectura no inicializado con algún valor de su tipo, ya sea por una operación previa de una asignación o una instrucción de entrada de datos. Para verificar si la expresión regular está correcta, se aplica la regla ’antes de una R debe existir una W’, en caso contrario indica que existe un error en el tipo de dato analizado, la expresión sería RR.

El proceso para verificar si la expresión regular esta incorrecta es el siguiente:

1. Recorrer de inicio a fin la lista de variables 1.1 Recorrer de izquierda a derecha la expresión regular de cada nodo

a) Si existen dos R’s seguidas entonces la expresión es incorrecta a. I ) Se asigna a la variable NL el número de línea de la primera R a.2) Se asigna un valor inicial a la variable, de acuerdo al tipo

b.1) Continuar con la siguiente variable b.2) Si es fin de la lista ir al paso 2

b) Sino

Sino Iralpaso 1.1

1.2 Se inserta en la lista del código ia variable inicializada, el número de línea

1.3 Generar nuevamente la expresión regular. Se repiten todos los pasos del indica en que nodo se debe insertar.

submódulo GenExp-Reg, ir al paso 1 2. Fin del proceso

71


5.5.2.4 Mejorar datos de escritura no utilizados. El submódulo Mej - Dato-Escritura-No-Usado sirve para corregir un tipo de dato de escritura no utilizado. Esta anomalía existe cuando un tipo de dato de escritura no es utilizado y nuevamente tiene asignado un valor. Para verificar si la expresión regular está correcta, se aplica la regla ’después una W debe existir una R ’, en caso contrario indica que existe un error en el tipo de dato analizado, la expresión sería WW’s.

El proceso para verificar si la expresión regular es incorrecta es el siguiente:

1. Recorrer de inicio a fin la lista de variables 1.1 Recorrer de izquierda a derecha la expresión regular de cada nodo

a) Si existen dos W’s seguidas entonces la expresión es incorrecta

b) Sino a.1) Se asigna a la variable NL el número de línea de la primera W

b.1) Continuar con la siguiente variable b.2) Si es fin de la lista ir al paso 2

Sino Ir al paso 1.1

1.2 Se elimina el nodo correspondiente a la primera W en la lista del código

1.3 Generar nuevamente la expresión regular. Se repiten todos los pasos del submódulo GenExpReg, ir al paso 1

2. Fin del proceso

5.5.2.5 Generador de código mejorado. El submódulo Generar-código sirve para almacenar las líneas de código que se encuentran en la lista a un archivo de texto, obteniendo un nuevo programa, pero mejorado. Esto se realiza cuando todas las expresiones regulares de las variables del programa original están correctas.

Ejemplo de mejoramiento de código.

Para describir este ejemplo se toma como entrada el programa de la figura 5.18, para referenciar el dato de la expresión regular y la estructura donde se encuentra en uso, fué necesario enumerar las líneas de código. Este programa está escrito en lenguaje de programación C estructurado.

72


1: #include <stdio.h> 2: /*hola.c*l 3: 4: main() 5: 6: 7: 8: 9:

1 o: 11: 12: 13: 14: 15: 16: 17: 18:

{ int x; char c; clrscr(); x=29; printf("ho1a W); while(c!='*') {

I

printf("caracter, *=Fin %cui",c); c=getchO;

x=6; printf("%d",x);

I

Figura 5.18 Programa ho1a.c

Paso

A continuación se describen los pasos para mejorar el código de la figura 5.1 8:

1. Recorrer en forma secuencia1 el archivo ho1a.c de la figura 5.1 8, almacenando cada una de las líneas del código en la lista doblemente ligada, como se muestra en la figura 5.19, se elimina la línea de código en blanco (número 3) , también se identifican el nombre y el tipo de las variables x,c, y por último se crea la lista de variables como se muestra en la figura 5.20.

, ' Figura 5.19 Lista doblemente ligada de código del programa ho1a.c.

73


!ni ““,O P I char I nuln

-

Figura 5.20 Lisia simplemente ligada de Iris variables del programa ho1a.c.

Paso 2. Generar las expresiones regulares del programa hola.c, en la figura 5.21 se muestra como se actualiza el campo expresion de la lista de la figura 5.20.

. . * . 1,.

. .

- - . . ..

Figura 5.21 I.ista de variables con el campo expresion actualimdo.

Paso 3. Analizar la expresión regular del primer nodo de la lista de la figura 5.21 observando que existen dos W’s consecutivas, ésto indica que existe un error en un dato de escritura no utilizado en la línea número 8, por lo tanto se elimina el nodo 8 de la lista de la figura 5.19, la lista actualizada quedaría como se muestra en la figura 5.22. El programa mejorado se muestra en la figura 5.23.

14

Arquitectura y Diseño del Procesador Gráfico Capitulo 5

1: #include <stdio.h> 2: /*hola.c*/ 3: main() 4: { 5: intx; 6: charc; 7: clrscr(); 8: printf("ho1a \n"); 9: while(c!='*') 10: { 11: printf("caracter, *=Fin %c\n",c); 12: c=getch(); 13: } 14: x=6; 15: printf("%d",x); 16: }

Figura 5.23 Programa ho1a.c después de mejorar el dato de escritura no utilizado

Paso 4. Nuevamente se recorre la lista de la figura 5.22 y se generan las expresiones regulares, actualizando la lista de variables de la figura 5.21. La lista con las expresiones regulares actualizadas se muestra en la figura 5.24.

Figura 5.24 Lista con las expresiones regulares actualizadas, dato de escritura no utilizado.

Paso 5. Nuevamente se analiza la expresión regular del primer nodo [14]W[lSjR, se observa que está correcta, por lo tanto se continua con la siguiente expresión regular del segundo nodo de la lista de la figura 5.24, que es [9]R*([ll]R[12]W), que corresponde a la variable c. Y se observa que existen dos R's seguidas, esto indica que existe un error en un dato de lectura no inicializado, antes de la linea número 9, por io tanto a la variable c se le asigna el valor de cero, esto es c=O; después se inserta esta variable con su valor inicial en el nodo 9 de la lista de la figura 5.22, la lista actualizada quedaría como se muestra en la figura 5.25. El programa mejorado se muestra en la figura 5.26.

75


. . . Cab linea

. .

..'.-)I \ihilcic ; * ) ~ p i i n i r i ' c i r m r r : F tno i ;n 'c t :tehit pi in lh ' "nJ ' \ l .

. - Figura j . 2 j Lista del código actualizado. después dc insertar una \ariable.

1: #include <stdio.h> 2: /*hola.c*/ 3: main() 4: { 5: intx; 6: charc; 7: clrscr(); 8: printfrhola \n"); 9: c=o; 10: while(c!='*') 11: { 12: printf("caracter, *=Fin %c\n",c); 13: c=getch(); 14: } 15: x=6; 16: printf("%d",x); 17: }

Figura 5.26 Programa ho1a.c después de mejorar el dato de lectura no inicializado

Paso 6. Nuevamente se recorre la lista de la figura 5.25 y se generan las expresiones regulares, actualizando la lista de variables de la figura 5.24. La lista con las expresiones regulares actualizadas se muestra en la figura 5.27.

76

.. .

Capítulo 5

Paso 7. Nuevamente se analiza la expresión regular del segundo nodo de la lista de la figura 5.27, que es [9]W[lO]R*([l2]R(i3]W), observándose que ésta es correcta, por lo tanto se concluye que el programa ho1a.c de la figura 5.26 ya esta correcto.

Paso 8. Por último se genera el código mejorado, que consiste en recorrer secuencialmente la lista de la figura 5.25 y se almacena todas las líneas de código en un archivo de texto, con el nombre que el usuario desee (figura 5.28).


#include <stdio.h> /*mejor.c*/ main() { int x; char c; clrscr(); printfrhola \n"); c=o; while(c!='*') { printf("caracter, *=Fin %c\n",c); c=getch();

1 x=6; printf("%d",x);

1 Figura 5.28 Programa mejorado después de las correcciones.

5.6 Módulo para ejecutar un programa

Este módulo sirve para probar un programa y ver los resultados con el propósito de comprender el funcionamiento de éste. Para poder ejecutar un programa es necesario contar con el programa ejecutable, en caso contrario existe un error, y no se podrá ejecutar el programa. La ejecución del programa se puede ejecutar en ambiente DOS o en ambiente Windows 3.1 1.

Los pasos que se siguen para realizar ésto, son los siguientes.

1. Se da el nombre del archivo del programa fuente 2. Si existe el archivo ejecutable correspondiente entonces

Se ejecuta el archivo, para mostrar el resultado de éste Sino Imprime mensaje error

Fin-si 3. Fingroceso

77


5.7. Interfaz gráfica implantada en el Procesador Gráfico

A continuación se presenta una descripción de los elementos que forman la interfaz del Procesador Gráfico (SoftGraf) y también se describe como funciona el administrador de archivos del sistema operativo Windows, ya que sirvió como referencia para la representación gráfica del código de este trabajo.

5.7.1 Administrador de archivos de Windows

¿Qué es el Administrador de archivos?

El Administrador de archivos ofrece un método gráfico para organizar archivos y directorios, Sirve para copiar y mover archivos, ejecutar aplicaciones, imprimir documentos y realizar operaciones de mantenimiento de discos. También se puede utilizar el Administrador de archivos para compartir archivos y directorios con un grupo de trabajo o se puede conectar a los directorios compartidos de otros usuarios.

Para aprender a realizar una tarea específica, elija el botón "Indice" y, a continuación, el tema de la Ayuda que le interese.

Mostrar los subdirectorios en el árbol de directorios

En el árbol de directorios podrá ver los subdirectorios que se encuentran dentro de un directorio expandiendo el mismo. También puede ocultar los subdirectorios contrayendo el directorio que los contiene.

Para ver los subdirectorios

Haga doble clic en el directorio que desee expandir. O bien, seleccione en el árbol de directorios el directorio que desee expandir y, luego, presione la tecla ENTRAR. O bien, seleccione el directorio que desee expandir y escoja el comando Expandir un nivel, Expandir rama o Expandir todo en el menú Arbol.

Para ocultar los subdirectorios

Haga doble clic en el directorio que desee contraer. O bien, seleccione el directorio que desee contraer del árbol de directorios y, luego, presione la tecla ENTRAR. O bien, seleccione el directorio que desee contraer y escoja a continuacibn el comando Contraer rama en el menú Arbol.

78


¿Qué es un árbol de directorio?

Es la representación gráfica de la estructura de directorios de un disco, utilizando una estructura arborescente. Los directorios aparecen como ramas que se extienden desde el directorio de nivel superior, denominado directorio raíz.

Este tipo de representación gráfica de directonos sirvió como referencia para poder representar código gráficamente en este trabajo de tesis, ya que la metodología de jerarquía de cajas estructuradas proponía una estructura de árbol en forma horizontal, teniendo como desventaja muchos cruces de líneas y mala distribución de los objetos.

Para realizar este tipo de distribución, fué necesario revisar bibliografía y manuales de Programación en Windows 3.1 1 para ver si ya existían controles y poderlos emplear en este trabajo, de acuerdo el análisis que se realizó, no fué posible hacerlo a través del lenguaje de programación C en Windows 3.11, y se decidió diseñar e implementar una distribución tipo árbol de directorios para la distribución de objetos gráficos de un programa fuente, ésto se explicó en las secciones 5.4.4, 5.4.5 de este capítulo.

5.7.2 Interfaz del Procesador Gráfico

La interfaz del Procesador Gráfico (SoftGraf) cuenta con un menú de opciones para poder representar código gráficamente, mejorar y ejecutar el código de un programa (figura 5.29). También cuenta con ayudas para el usuario con el fin de apoyar la funcionalidad de esta herramienta.

Figura 5.29 Interfaz del SofíGraf.

79

Arquitectura y Disefio del Procesador Gráfico Capítulo 5

El menú del SoftGraf cuenta con las siguientes opciones:

Archivo: Esta opción del menú contiene las opciones Cargar código Gráfico, Ver código Textual, Mejorar código y Salir.

Para las tres primeras opciones es necesario abrir el archivo, para su uso, para ésto se ocupa la caja de diálogo de manejo de archivos, como se muestra en la figura 5.30.

Nombre de crchivo: ejemp1o.c

- Directorios:

c:\tcwin\bin

- Mostrai archivos de tipo:

Text Files r.C] Unidades:

IR] I ¡E4 c: ins-dos-6

0 ~ 6 1 0 lectura

Figura 5.30 Caja de diálogo para abrir archivos.

A continuación se muestra como funciona cada una de estas opciones:

Cargar código Gráfico. Después de dar el nombre del archivo, como se muestra en el ejemplo de la figura 5.30, esta herramienta presenta gráficamente el código del programa ejemplo.^, como se muestra en la figura 5.29. Dando la opción al usuario de seleccionar cualquier objeto gráfico que desee, expandir o contraer a niveles de mayor o menor abstraccion del programa. También a través de la barra vertical el usuario puede mover el programa hacia arriba o hacia abajo, oprimiendo los botones correspondientes.

Ver código Textual. El usuario puede ver también el código en forma textual (ventana derecha de la figura 5.31) para analizar y comparar las estructuras del programa con las estructuras representadas en forma gráfica. También es posible imprimir este código. AI igual que el código representado gráficamente, el usuario puede mover el código textual hacia arriba o hacia abajo con los botones de la barra vertical de la ventana. (Para cerrar la ventana se debe seleccionar la opción salir o seleccionar la opción cerrar de la ventanal

80


Figura 5.3 1 Programa ejemp1o.c representado en forma textual.

Mejorar código. Esta opción sirve para mejorar el código como fué explicado en la sección 5.5 de este capítulo. Las operaciones de esta opción son internas, por io tanto la interface únicamente indica el momento en que se terminó de analizar y mejorar el programa de entrada, en la figura 5.32 se muestra un ejemplo de esta opción. Las dos primeras cajas de diálogo sirven para abrir y para dar el nuevo nombre del archivo mejorado, la ventana que tiene un mensaje 'Fin del proceso', es la salida de esta opción, las dos ventanas de abajo únicamente se muestran para dar este ejemplo.

81

Capitulo 5 \ Arquitectura y Diseño del Procesador Gráfico

Dato no utilizad< \

Dato no i " i C i d i .

c

, Programa de enoada con errores

mainn

¡ n i x

clrccrn; priniirhola \n'l; c.0; while[c!='*']

priniir'carader, *=Fin %c\n':c]; c=getchO;

x.6; priniif%d':x];

/f Programa mejorardo sin ermres

Figura 5.32 Programa ho1a.c mejorado.

La segunda opción del menú principal es Correr. Esta sirve para poder ejecutar un programa con el propósito de ver lo que hace. El dato de entrada es un programa fuente y también se utiliza un caja de diálogo para dar el nombre del programa, como se muestra en la figura 5.30. Después de dar el nombre del archivo, se ejecuta el programa, teniendo como salida la figura 5.33.

82


Dar p r i m e r u a l o r : 4 I Dar segundo u a l o r : 8 E l segundo u a l o r es mayor R

Figura 5.33 Resultado de ejecutar el programa may0r.c.

Esta herramienta también tiene una opción Editar que sirve para inicializar la pantalla, cuando se tiene un programa representado gráficamente.

Además de estas opciones, esta herramienta tiene las siguientes ayudas:

Cuando se tiene el código representado gráficamente y se necesita saber que instrucción en lenguaje de programación C significa el símbolo gráfico, entonces se selecciona con el mouse el objeto, después se oprime el botón derecho y aparece una caja de diálogo donde muestra la instrucción completa con sus parámetros, en la figura 5.34 se muestra un ejemplo.

con el mouse

83

-.-

Capítulo 5 Arqui tectura y Diseño del Procesador Gráfico

Otra ayuda importante, es cuando se necesita saber para que sirve un objeto gráfico, se selecciona con el mouse el objeto deseado, después se oprime la tecla F1, entonces muestra una ventana con la explicación para que sirve este objeto y un ejemplo de éste en modo texto. Para ésto se utilizaron las ayudas en línea del lenguaje de programación BorlancVTurbo C en ambiente Windows. En la figura 5.35 se muestra un ejemplo.

Para indicar que objeto seleccionó el usuario, el objeto gráfico tiene un recuadro en color azul.

objeto seleccionado con F1

Conditional

Syntax i f ( <expression> ) <sta tenent l> . i f ( <expression> ) <statenientl>.

else <sta te i entz> .

If <exwessian> is non-zero when evaluated. <statenientl> IS executed

In the secondcase. <rtatementZ> isexecutedifthe expression is0

An optionalelse canfollowanifstotement but no statementscancome beween an if statement and an else

Examples if (count < 50) count++.

if (x < v i z = x.

else e = Y.

Figura 5.35 Ayuda en línea para un objeto gráfico.

84

Capítulo 6 Evaluación experimental

CAPITULO 6

EVALUACION EXPERIMENTAL

Este capítulo describe la forma experimental con la cual se evaluará el desempeño del Procesador Gráfico (SoftGraf) definiendo las variables dependientes e independientes, y estableciendo los factores más importantes que serán evaluados.

85


6.1 Hipótesis a comprobar.

El diseño experimental tiene como objetivo principal comprobar las hipótesis que se plantearon al inicio de este trabajo de tesis.

A través de la representación gráfica del código fuente se espera reducir el tiempo de entendimiento que se lleva una persona encargada de dar mantenimiento a un programa. Al pasar un programa estructurado escrito en lenguaje de programación C por esta herramienta en caso de ser necesario se reducirá los datos de lectura y escritura incorrectos, se espera que estos cambios permitaran reducir el esfuerzo y tiempo para dar mantenimiento a programas. AI ejecutar programas a través de esta herramienta será más fácil verificar su adaptación a una nueva aplicación.

Para evaluar la eficiencia de esta herramienta fué importante determinar las variables dependientes o independientes.

A continuación se describen cada una de éstas

6.2 Variables dependientes.

Para la evaluación de esta herramienta se consideraron los siguientes factores:

VI: Tiempo que se llevaría el usuario en entender un programa fuente representado gráficamente. V2: Tiempo que se lleva el usuario en modificar datos incorrecto de un programa.

6.3 Variables Independientes.

Las variables independientes que se consideraron para resolver este problema son las siguientes:

I I : La representación gráfica del programa fuente sin anomalías. 12: La representación gráfica del programa fuente con anomalías. 13: La representación textual del programa fuente sin anomalías. 14: La representación textual del programa fuente con anomalías.

(utilizando las técnicas de jerarquía de cajas estructuradas, estrategias de visualización y Reingeniería de datos).

86

... -

Capitulo 6 Evaluación experimental

6.4 Plan de muestra.

Para evaluar esta herramienta se consideró una muestra de 10 personas de una población de 100 candidatos, las características necesarias de la muestra fueron las siguientes: se les aplicaron las pruebas a personas con conocimientos medios en programación. Las instituciones que participaron en esta evaluación fueron quienes se dedican al desarrollo o investigación en el área de desarrollo de sistemas computacionales, éstas fueron: Universidad Autónoma del Estado de Morelos y el Instituto Tecnológico de Zacatepec. A cada una de las personas se les dieron programas representados textualmente en lenguaje de programación Turbo C estructurado y también estos programas fueron representados gráficamente con esta herramienta y se observaron los resultados. Para este plan se consideraron las siguientes métricas:

Número de líneas de código del programa fuente. Número de estructuras de secuencia, alternación e iteración. Número de estructuras simples y complejas del programa fuente. Cambios posibles del programa fuente. Número de datos de lectura y escritura corregidos.

6.5 Plan de evaluación

Una vez diseñado el plan experimental, se trabajó con la muestra seleccionada para obtener datos relevantes, los cuales fueron relacionados estadísticamente para observar el comportamiento entre las formas de entender y modificar programas en representación textual y gráfica.

El concepto de dispersión resulta importante porque puede darse el caso de que poblaciones con la misma media aritmética (valor central) puedan tener distinto nivel de dispersión. La fórmula se muestra en el apéndice A. Una de las medidas de dispersión utilizadas es el Rango, que es la diferencia entre el valor máximo y el mínimo de un grupo de datos. La fórmula del Rango es R= M m a x -Mmw

Con la finalidad de obtener datos más exactos acerca de la dispersión de los resultados de la evaluación, es necesario utilizar valores como la desviación media (la fórmula se muestra en el apéndice B), la varianza (la fórmula se muestra en el apéndice C), y la desviación estándar (la fórmula se muestra en el apéndice D). Estas medidas de dispersión fueron elegidas porque muestran qué tanto están dispersos los datos obtenidos contra la media establecida, lo cual da una idea del grado de error presente en cada uno de los cuatro casos para entender y modificar programas en representación textual y gráfica.

87


6.6 Análisis de resultados

Para analizar los resultados de esta evaluación, fue necesario utilizar las ecuaciones descritas anteriormente, a continuación se describen los pasos que se siguieron para lograr ésto. Primeramente se calculan los valores de dispersión para el tiempo de entender programas textuales de 100 líneas de código (LDC). La tabla 6.1 muestra todos los datos que se calcularon para entender programas textuales sin utilizar la herramienta SoftGraf.

dedicado a entender programas textuales sin utilizar la herramienta.

X= 792.8 I 10 = 79.28

DM = 103.68 I 10 = 10.37

Sz = 1439.77 I 10 = 143.98

s =IvmF8=+11.99

Después se calculan los valores correspondientes a entender programas representados gráficamente utilizando SoftGraf, en la tabla 6.2 se muestra estos resultados.

88


Tabla 6.2 Información para calcular la medida de dispersión~para e¡ tiempo~dedicado a entender programas representados gráficamente utilizando la herramienta.

x= 544 I 10 = 54.4 DM = 87.0 I 10 = 8.79

S2 = 978.97 I 10 = 97.9 S =I&%=?9.89

También se calculan los valores de dispersión para el tiempo dedicado en rnoúi$cur datos incorrectos de un programas de 80 LDC. La tabla 6.3 muestra todos los datos que se calcularon para modifcar datos incorrectos de un programa sin utilizar SoftGraf.

dedicado a modijicuv datos incorrectos sin utilizar la herramienta.

89

Evaluación experimental Capitulo 6

X= 198.0 / 10 = 19.8 DM = 32.0 / 10 = 3.2

Concepto

S’= 171.88 / 10 E 17.19

Después se calculan los valores correspondientes en modificar datos incorrectos

S = +J¡% zM.15

utilizando la herramienta SoffGraf, en la tabla 6.4 se muestra estos resultados.

Tabla 6.4 Información para calcular la medida de dispersión para el tiempo dedicado en modiJicar datos incorrectos utilizando la herramienta

Entendimiento de Entendimiento de programas de 100 programas de 100 LDC sin utilizar el LDC utilizando el

X= 133.491 10 = 13.35 DM = 30.83 / 10 = 3.08

SoftGraf

S 2 = 157.69 / 10 = 15.77 s =fJ1577=+3.97

En la tabla 6.5 se muestra un resumen de los resultados obtenidos en este plan

SoftGraf 19.8 13.35

promedioX I Desviación 1 10.37 I 8.79 media DM

Varianza S2 Desviación

143.98 97.9

11.99 9.89 estándar S

Tabla 6.5 Resumen comparativo del tiempo I

el SoftGraf LDC utilizando

-1 17.19 15.77

ilizado en las cuatro pruebas.

90

Capitulo 6 Evaluación experimental

Los resultados de las pruebas permitieron validar en pequeña escala las hipótesis planteadas, al inicio del proyecto de tesis, ya que el porcentaje de reducción de tiempo al utilizar el SoftGraf fue del 31.38% en el entendimiento de programas de 100 líneas de código, y de 32.58% en mejorar datos incorrectos en programas de 80 línea$ de código, lo cual representa una disminución considerable de tiempo.

Estos resultados obtenidos no se pueden tomar como una conclusión definitiva de la relación entre el uso del SoftGraf y el ahorro de tiempo, sino como un indicativo de la manera cómo se comporta el SoftGraf con una pequeña muestra, de tal forma que se sugiere para un trabajo posterior una evaluación experimental más completa y más confiable.

91

. .

Comentarios finales Capitulo I

CAPITULO 7

Este capítulo describe los alcances.logrados en este trabajo de tesis, también se mencionan algunas mejoras tanto en lo que se refiere a Visualización y Reingeniería de datos, por último se proponen trabajos futuros relacionados con esta herramienta.

92

Comentarios finales Capitulo 7

7.1 Contribución de la investigación.

Como resultado final de esta investigación se comprobó que al representar gráficamente código textual utilizando símbolos gráficos, se mejoró el proceso de comprensión de programas en el mantenimiento de sistemas. Uno de los principales logros de la representación gráfica de un programa fué que se crearon símbolos gráficos con significado de lo que hace cada una de las estructuras del programa, con el propósito de mejorar el proceso cognoscitivo que se realiza al tratar de comprender el significado y la función de un programa.

También al reestructurar los datos incorrectos de un programa, se logró un aumento en el entendimiento, lo cual sin duda redundará en una mejoría en el mantenimiento y en la ejecución de un programa. Para lograr ésto se utilizó Reingeniería de datos y la unidad de medida para la calidad del Software en el flujo de datos son los datos incorrectos y el rango del alcance de los datos. Aunque existen otras métricas, en este trabajo únicamente se consideraron éstas. En particular, yo creo que tiene un valor significativo el reconocer y organizar de nuevo los datos en forma automática, para atender necesidades de mantenimiento en el desarrollo de Software.

Otros logros importantes de este trabajo de tesis fueron:

Para la representación visual del código fuente fué necesario modificar y crear algunos símbolos de la notación jerarquía de cajas estructuradas, con la finalidad de mejorar la visualización del código. También fué necesario crear algoritmos para poder representar el código tipo estructura arborescente, con el propósito de poder distribuir de mejor forma los símbolos gráficos (semejante al administrador de archivos).

Para mejorar los datos incorrectos de lectura y escritura de un programa, se crearon nuevas reglas para formar las expresiones regulares para una estructura de decisión múltiple y dos estructuras de iteración correspondientes al lenguaje de programación C.

7.2 Mejoras y trabajos futuros.

El objetivo de esta sección es presentar las tendencias más importantes que se vislumbran dentro de la tecnologías de Visualización y Reingeniería de datos; tendencias que ofrecen la posibilidad de adoptar una actitud innovadora para la Reingeniería de Software.

Como un primer intento se mejoró el entendimiento y el uso de datos en programas estructurados escritos en lenguaje de programación C, con ésto se logró, que se cumpliera el objetivo general de este trabajo de tesis, sin embargo, es necesario hacer ciertas mejoras.

93

Comentarios finales Capitulo 7

Para esta tesis, el grupo de Ingeniería de Software continuará trabajando para lograr desarrollar un Integrador de Componentes Reusables, que formara parte del proyecto AMASS-11.

Esta tesis puede ser el origen del desarrollo de trabajos futuros, a continuación se describen brevemente cada uno de éstos:

Se propone incluir sonido a través de voz en los objetos gráficos, ésto ayudaría a mejorar el entendimiento ya que se completaría el proceso de comunicación a través de la percepción audiovisual [MAR97].

Actualmente se representan gráficamente las estructuras internas de un programa como son las de secuencia, alternación e iteración, se propone también representar funciones internas definidas por el lenguaje de programación C y las función definidas por el usuario, ésto ayudaría a mejorar el alcance de un sistema.

Se propone que al seleccionar un objeto activo del programa representado gráficamente se pueda ejecutar únicamente el fragmento de código correspondiente a este objeto, con el fin de poder comprobar por partes el funcionamiento del programa.

Uno de los objetivos de comprender el código es para que el encargado de dar mantenimiento o el de Ingeniería de Software puedan modificar este código y utilizarlo en nuevas aplicaciones, por eso se propone incluir en esta herramienta las opciones de insertar y borrar objetos gráficos que desee el usuario y que esta herramienta automáticamente corrija las estructuras correspondientes en el código original.

Actualmente la representación de los objetos gráfkos tanto en su forma como en su distribución están en dos dimensiones, se propone que éstas sean representadas en tres dimensiones ya que son estrategias importantes para mejorar los procesos cognoscitivos de entendimiento de código.

El método de Reingeniería de datos puede ser extendido para incluir datos más complejos, como registros, pilas, colas, arreglos, archivos y base de datos. También se puede continuar mejorando los datos incorrectos, como son los tipos de datos sobre cargados y reducir el alcance de los datos.

Se propone trabajar con otro tipo código estructurado diferente a C (por ejemplo Pascal).

También se propone incluir lenguajes de programación orientados a objetos (por ejemplo C++), y simbólicos (por ejemplo Prolog o Lisp).

94

Apéndices

Apéndie A

Media aritmética: Es la suma de los valores dividida por el número de estos.

Apéndice B

Desviación media: Es el promedio del valor absoluto de las desviaciones de los datos respecto a la media.

Apéndice C

Varianza: Es el promedio de los cuadrados de las desviaciones.

95

Apéndices

Apéndice D

Desviación estándar: Es la raíz cuadrada de la varianza.

$(Xi - X)’ S = I i N i=l

96

Bibliografia

Bibliografía

[ALA891 Alan R. Hevner, Information Systems, University of Maryland College Park, MD y Richard C. Linger, Systems Integration Divition IBM Corporation, Bethesda, MD, Reprinted from Proc.22nd Annual Hawii Int‘l, Conference on System Sciencies (HICSS), pp. 1025-1034, año 1989 by IEEE.

[Am891 R.S. Arnold, “Software Restructuring”, Proc. IEEE, Vol. 77, No. 4, Apr. 1989.

[Am931 Robert S. Arnold. Software Reengineenng. IEEE Computer Society.Vol 1. 1993.

[BUR961 E.L. Burd, P.S. Chan, I.M.M. Duncan, M. M w o , P. Young. “Improving Visual Representations of Code”, Visualisation Research Group, Centre ofr Software Maintenance, University of Durham, South Road, Durham, DHI 3LE, UK. 1996.

[CHI901 E. Chikofsky, “Lecture notes on reverse engineering and disign recovery”, Feb. 1991.

[CLE89] L. Cleveland, “A Program Understandign Support Environment”, IBM Systems J., Vo1.28,No.2, 1989, pp.324-344.

[CON871 J. Conklin “A Survey of Hypertext”, IEEE Computer, Vol. 20, No.9, Sept. 1987, pp. 17-41.

[CUE931 Cuevas Agustín Gonzalo, “Ingeniería de Software: Práctica de la Programación“, Editorial Addison-Wesley Iberoamericana, Wilmington, Delaware, E.U.A. 1993.

[FA1901 Richard E. Fairley “Ingeniería de Software”, Editorial McGraw-Hill, Enero 1990.

[GUI89] Guide Pub. pp-208, Guide Int’s Corp., “Application Reengineering”, Chicago 1989.

[HAN911 Hanna Mary, “Getting back to requirements proving to be a difficult task”, Software Magazine, Sentry Publishing Co., Inc., 1900 West Park Drive, Westborough, MA 01581, USA, Octuber 1991.

[HAUS51 P. .Hausler “Data Usage Abstraction in Structured Programs”, Master’s Thesis, Departament of Computer Science, Univ. of Maryland, 1985.

97

Bibliografia

[JOY881 Luis Joyanes Aguilar “Fundamentos ’ de Programación, algoritmos y estructura de datos”, Editorial. McGraw-Hill, España, 1988.

[KEN881 Kenneth E. Kendall, Julie E. Kendall “System Analysis and Design”, Editorial Prentice-Hall 1988.

[LA1931 Laitinen, K. “The Principle of Natural Naming in Software Documentation”, Technical Research Centre of Finland, ESP00 Report Number 1498, 1993.

[LET861 Letovsky, S. “Cognitive Processes in Program Comprehension”, Empirical Studies of Programmers, Albex, Norwood NJ, 1986. Pages 58-79.

[MAL911 Malcolm Slovin and Silas Malik, “Reeingineering to Reduce System Maintenance: A Case Study”, Software Engineering, July 1991.

[MAR971 Mariano Cebrián Herreros, “Información Audiovisual. Conceptos, técnicas, expresión y aplicaciones”, pp. 66-68,90-91, Editorial , Síntesis-Ciencia Información. 1997.

[MAY911 Von Mayrhauser, A. and Vans, A.M. “Program Comprehension During Software Maintenance and Evolution”, IEEE Computer. August, 1995. Vol. 28, pages 44-45.

[MCC76] T. McCabe, “A Complexity Metric”, IEEE Trans. on Software Eng., VolSE-2, No. 2, Dec. 1976.

[MIL861 H. Mills, R. Linger, and A. Hevner “Principles of Information Systems Analysis and Design”, Academic Press, 1986.

[MIL871 H. Mills, R. Linger, and A. Hevner “Box Structured Information,Systems”, IBM System Journal, Vol. 26, No. 4, pp. 395-413, December 1987.

[MYE75] G.J. MYERS, Reliable Software through Composite Design, Van Nostrand Reinhold Co., N.Y., 1975.

[OMA90] Oman, P., “Maintenance Tools”, IEEE Software, pp. 59-65, Mayoi1990.

[PRE90] Pressman, S. Roger “Ingeniería de Software, un enfoque práctico”, Tercera Edición, España, Editorial McGraw-Hill, 1990.

[RIC89] J.A.Ricketts, J.C.DelMonaco, and M. W. Weeks, “Data Reengineering for Aplication Systems”, Proc.conf. on Software Maintenance, IEEE Computer Society Press, Los Alamitos, Calif., 1989, pp. 174-179.

[ROB931 Robert S. Arnold. “A Road Map Guide to Software Reengineering Technology”, Software Reengineering. IEEE Computer Society.Vol 1. pp. 8-22.1 993.

.. . . ... ,

98

Bibliografia

[SAN921 Santaolaya S. R. “Planeación y diseño de programas de Computadora”, Apuntes, Cenidet, 1992.

[SAN941 Santanu Paul, and Atul Prakash, Members IEEE, “A Framework for Source Code Search Using Program Patterns”, IEEE Transactions on Software Engineering, Vol 20, No.6. June 1994.

[SEN941 James A. Senn “Análisis y diseño de Sistemas de Información”, Editorial McGraw-Hill, Segunda edición, 1994.

[SHN80] Shneiderman, B. “Software Psychology”. Cambridge MA: Winthrop Publishers Inc. 1980.

[STO951 Storey R. and Müller, H.A. “Manipulating and Documenting Software Structures Using SHriMP ViewsY, International Conference on Software Engineering. pp. 275-284. Opio (Nice), France, October 1995.

[WE1811 M. Weiser, “Program Slicing”, Proc. Int’l. Conf. on Software Eng., Computer Society Press, Los Alamitos, Calif., Mar. 1981.

IEEE

[WIR71] Wirth, N. “Program development by Stepwise Refinement”, Communications of the ACM. Vol. 14, No. 4, pp. 221-227. April, 1971.

99

Documents

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO … Jose... · Centro Nacional de Investigación y Desarrollo TeciioIOgico ACA1)EMIA DE CIENCIAS COMPUTACIONAI,E.S Cuerriavaca Mor.,