CENTRO NACIONAL DE INVESTIGACIÓN Y … Leticia Santa... · grado de Maestro en Ciencias de este...

SEP SEIT DGIT

CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO TECNOL~GTCO

cenidet

DISEÑO E IMPLEMENTACIdN DE UNA HERRAMIENTA DE SOFTWARE PARA LA

DOCUMENTACIÓN AUTOMÁTICA DE PROGRAMAS

TESIS

QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN CIENCIAS COMPUTACIONALES

PRESENTA LETICIA SANTA OLALLA OCAMPO a m 06 INFO^^,^,

C C N l D E I ASESORES M.C. MÁXIMO LÓPEZ SÁNCHEZ

M.C. RENÉ SANTAOLAYA SALGADO

CUERNAVACA, MORELOS

[-CkN:DET

ENERO DE 1998

9 8 - 0 0 7 3

s(#> SISTEMA NACiONAL DE INSTITIJTOS TECNOLOGICOS

I/

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO

FORMA A3 REVISION DE TESIS I/

REV 12Bi Cuernavaca, Morelos a 8 de diciembre de 1997

Dr. Javier Ortir Hernandez

Presente Presidente de la Academia de Ciencias Computacionales i

11

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión academica la tesis denominada: Diseño 8 implementación de una herramienta de software para la documentación automática de programas, realizada por la /,.

C. Letlcla Santa Olalla Ocampo, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos ,no tener objeción para que se le conceda la

iI autorización de impresibn de la tesis.

Sin otro particular, quedamos de usted. 11

i

La comisi6n de revisión /I

./I

I1

il

M.C. Mano Guillén Rodriguez I1

I¡

Asesor de t e s v

D. a. I . E. P, Co-asesor de tesis %!'r3 %%C&WdL a; ;h'yfs~wp~ I)

*Wcll<Ln# n{bnFi*i ' ccp Dr. José Ruiz Ascencio/Jefe del Departamento de Ciencias Cornputaciona@ 'I>.I(OLLrI i¿!!q[lJfjlCp

.'

',

ceniúet interior inimnado Palmira SM C.P. 62490 A. P. 5-162 Cuemnvuca Mor., Mexico Tcls. y fas (73) 18-77-11. 12-7643. 12-24-34

11

//

SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO

FORMA A 4 AUTORlZAClON DE IMPRESIÓN DE TESIS

REV. 12/97

Cuernavaca, Moreloc a 8 de diciembre de 1997

C. Leticia Santa Olalla Ocampo Candidata al grado de Maestro en Ciencias En Ciencias Computacionales Presente

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: Diseño e implementación de una herramienta de software para la documentación automática de programas, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Atentamente

. Dr. José Ruiz i scencio

Jefe del Departamento de Ciencias Computacionales

cenidef Interior lnlernado Palmira SR.I C.P. 62490 A. P. 5.164 Cuemavaca Mor.. Mexico Tels. y fax(73) 18-77-41, 12-76-13, 12-24-i4

a DIOS por haberme permitido llegar al término de esta meta.

li

I1 a mi hijo Roberto Urzúa Santa Olalla

decisión del término de este trabajo y

horas de su tiempo. Te amo hijo.

que fue el principal motivo en la I

que me ha permitido tomar muchas i

L

a mi mejor ejemplo de rectitud y honestidad. .. a mi padre. Gracias por tu amor.

a la mujer que con su amor y palabras de aliento me levanto en los momentos en que la voluntad declina. Gracias mamd

!I

a mi esposo por su apoyo y comprensión. Gracias mi amor.

. -

AGRADECIMIENTOS

Agradezco muy especialmente a mi esposo Roberto Urzúa por su apoyo incondicional en el término de este trabajo. Pero sobre todo por su amor.

Agradezco a mis padres por su amor, sus consejos y palabras de aliento.

Agradezco al Consejo Nacional de Ciencia y Tecnología (conacyt) por su apoyo económico para lograr concluir con mis estudios de maestría.

Agradezco ai Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet) por permitirme lograr concluir mis estudios de maestría.

Agradezco a mis hermanos (Ricardo y Julian) por estar conmigo en los momentos más dificiles. Gracias los Amo.

Agradezco a mis cuñadas (Paula Ayesha e hone) por su apoyo incondicional. Pero por sobre todas las cosas, por su cariño.

Agradezco a mi asesor M.C. Máximo López Sánchez por sus conocimientos y por su tiempo que dedico para la elaboración de este trabajo de tesis.

Quiero agradecer de manera muy especial al Dr. Javier Ortiz Hernandez por haber sido mi guía en la terminación de este trabajo de tesis. Pero por sobre todas las cosas por su amistad. Gracias Javier.

Agradezco al M.C Réne Santaolaya Salgado por sus palabras de aliento que desde siempre he recibido, por que ha sido un ejemplo en mi vida profesional. Gracias primo.

Agradezco a todos mis profesores del Cenidet por sus conocimientos brindados

Agradezco a los profesores al Dr. Javier Ortiz Hernández, M.C Mario Guillén Rodriguez, M.C Felipe Alaniz Quezada, por sus comentarios y correcciones a este trabajo.

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

Agradezco a la M.C. O h i a ,Fragoso por la ayuda y orientación brindada, y sobre todo pox su amistad.

il

II

I. .

Agradezco al grupo de Ingeniería de Software: Teresa, Carlos, Susana, Mirna, Liliana, Marco, Jesús, Martha, gracias por todo el apoyo.

Agradezco a mis amigos Fco. Carpio, Hugo Estrada y Alicia Martinez, Juan Gabriel Sema, Víctor Sosa, por toda la asesoría.

Agradezco a mis amigos y compañeros de generación: Leopoldo Sánchez, Ricardo Amador, Ariel Lira, Jesús Hernández, Elsa, Juan de Dios, Higinio, Víctor Sosa, Juan Gabriel Serna, Claudia, Tacho por los buenos momentos que pasamos juntos.

TABLA CONTENIDO

Lista de Figuras ............................................................................................................................... iv

Capitulo 1. PROBLEMÁTICA DEL MANTENIMIENTO DE ...............................................................................

1 SISTEMAS DE SOFTWARE

1.1. ¿Qué es el Software?. ................................................................................................. 1.2. Crisis del software .....................................................................................................

1.2.1 . La problemática del software en nuestros dfas ................................................ 1.3. Ciclo de vida del software, algunos enfoques ............................................................

1.3.1. Ciclo de vida cleisico ....................................................................................... 1.3.2. Construcción de prototipos .............................................................................. 1.3.3. Técnicas de cuarta generación .........................................................................

1.4. El mantenimiento como una fase del ciclo de vida del software ............................... 1.4.1. Tipos de Mantenimiento de software ..............................................................

1.4.1 . 1 . Mantenimiento de Mejora.. ................................................................ 1.4.1.2. Mantenimiento para adaptación ......................................................... 1.4.1.3. Mantenimiento Correctivo .................................................................

1.4.2. El mantenimiento del software como una función del diseflo ......................... 1.4.2.2. Costos y localizaci6n de esfuerzos ..................................................... 1.4.2.3, Los Costos del mantenimiento ............................................................ 1.4.2.4. Planeación del mantenimiento ........................................................... ;

1.5, Problemas de una mala ingeniería de Software ..........................................................

, .

1.4.2.1. Puntos de vista acerca del ciclo de vida clásico del software .............

2 2 3 3 4 6 I 9 9 9 9 IO 10 10 11 1 1 12 12

Capítulo 2. PROBLEMÁTICA DEL DISENO Y SU RELACIÓN CON 14 EL MANTENIMIENTO ..........................................................................................

2.1. Planteamiento del problema ....................................................................................... 2.2. Objetivo de la tesis ................................................

2.4. Metodologia de Solución ............................................

. . 2.3. Beneficios ............................................... ..........................................

.............. 2.5. La Importancia de la Documentación ............... ............... 2.5.1. Técnicas de Diseño y Documentación ... ................. ................

2.5.1.1 . Pseudocodigo .................................................................................... 2.5.1 2. Diagramas de Warnier-Om ..................................................

1 5 IS 16 16 17 19 20 22

I/

I

251 .3 . Diagramas de Flujo de datos .............................................................

2.5.1.5. Diagramas HIPO ..................... 2.5.1.6. Manuales de procedimientos ........... 2.5.1.7. Método de Folklore ...........................................................................

251 .4 , Diagramas de Nassi-Schneiderman ............................................. , , , . , , , . . , , , . , , , , , , , , , , , . , .......................

.......

2.6. Estado del Arte ............................................................................................................ 2.6.1. Herramientas de Mantenimiento ....................................................................... 2.6.2. Software en el mercado ....................................... ., ...........................................

23 24 26 27 28 30 30 32

Capítulo 3. ARQUITECTURA DEL DOCUMENTADOR AUTOMATICO (GENDOC) 34

3.1. Antecedentes .............................................................................................................. 35 3.2. Arquitectura conceptual del Documentador de Programas (GenDoc) .......................

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

3 7

Capítulo 4. DISENO Y DESARROLLO DEL DOCUMENTADOR 40 AUTOMATICO ........................................................................... : .........

4.1. El Paradigma del Libro 41 4.1.1. Comprensión y Mantenimiento ....................................................................... 42 4.1.2. El modelo del Libro 43

45

45

46

53 4.3.1, Información que contiene el Diccionario de Datos .......................................... 53

54 4.3.2. Uso del Diccionario de datos ............................................................................ 4.3.3. Investigación sobre los elementos que debe contener un Diccionario de

55

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

4.1.3. Formateado del código .................................................................................... 4.2. Diseño del GenDoc 45

4.2.1, Estructura para la definición de la tabla de contenido del libro ...................... 4.2.1.1 Estructura para generar la tabla de contenido del código fuente ......... 47 4.2.1.2 Creación del ínice del libro utilizando hipertexto ..............................

4.2.2. Analisis del parrafo para cada función ............................................................ 52

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

4.3. Módulo del diccionario de Datos (índice) ..................................................................

datos .................................................................................................................. 4.3.4. Estructura utilizada para la generación del Diccionario de Datos .................... 56

4.4. Interfaz del Generador de Documentación ................................................................. 58

60

61 5.1, Muestre0 ..................... ............................. 5.2. Varibles dependientes ................ ......................... ............................ 5.3 . Variables indendientes ......................... ................................................. 5.4. Hipotesis a comprobar ......................... 5 . 5 . Plan de evaluacion

Capítulo 5. EVALUACI~N EXPERIMENTAL .........

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

, . .............................................................. 62 ., 62 ............................................ ...................................................

I/

i

I!

I/

il

I1

!I

I/

ii

5.6. Análisis de resultados ................................................................................................. 64

.............................................. CONCLUSIONES ............................................................... : 67

1. Alcances Logrados ........................................................................................................ 68 2. Mejoras y Trabajos Futuros ........................................................................................... 68

Bibliografia ..................... ....... ................ ........... 10,

Anexo 1. Información sobre los archivos de Hipertexto .................... 72 Anexo 2. Cuestionario ............................ Anexo 3. Cuestionario ............................. ............................

I!

i i i

LISTA DE FIGURAS

Descripción Pág. No. Fig.

1.1. I .2. 1.3. 2.1.

2.2

2.3 2.4 2.5 2.6 2.7

2.8. 3.1. 3.2 4.1 4.2. 4.3.

4.4. 4.5. 4.6. 4.7.

4.8. 4.9. 4.10 4.11

4.13

ciclo de vida clásico del software ......................................................................... 6 Construction de prototipos .................................................................................... 7 Técnicas de cuarta generación 8 Técnica en el diseño del software y la documentación es única en su concepción visual Y en su estructuración 20 El uso de Pseudocódigo para ilustrar un servicio de actualización diaria de

21 suscripciones de periódicos ................................................................................... Elementos que utilizan los diagramas de Warnier-Orr .......................................... 22 Símbolos utilizados en los diagramas de flujo de datos ......................................... 24 Símbolos gráficos utilizados en los diagramas de Nassi- Schneiderman ............... 25 Tabla visual de contenido para un paquete HIPO .................................................. 26 Tabla de contenido para el manual de procedimientos del programa denominado

27 EZSORT ................................................................................................................ 29 Método de documentación FOLKLORE ..............................................................

Arquitectura conceptual del AMASS ..................................................................... 35 Arquitectura del GenDoc ....................................................................................... 31

Autómata para el reconocimiento de funciones del GenDoc ................................. 45 Muestra el código fuente escrito en lenguaje ''C" 46

48 Estructura de datos para generar la tabla del contenido 48 Componentes de una página ............................... 51

52 correspondiente Modelo conceptual de los nodos que almacenan los datos del programa fuente.. 56 Muestra el diccionario de datos. Sus variables y cada uno de sus atributos. ........ 57

Código fuente escrito en lenguaje "C" (a la izquierda) y código en forma de

I .

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

.................................................................................. . . < <

Formato de un código fuente bajo la forma de un libro ......................................... 41

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

Estructura de cada nodo de la lista, para generar la tabla del contenido ................

Muestra un ejemplo de.código fuente escrito en lenguaje "C" y SU párrafo

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

Interfaz del GenDoc .............................................................................................. 58

indice y documentado (a la derecha) ..................................................................... Muestra el diccionario de datos que da como salida el GenDoc ...........................

59 59

iv

Capitulo I Problemática del mantenimiento de sistemas de software.

CAPÍTULO i //

PROBLEMÁTICA DEL MANTENIMIENTO DE SISTEMAS DE SOFTWARE

Este capítulo comprende conceptos generales de ingeniería de software y la descripción del ciclo de vida de desarrollo del software, enfocándose al mantenimiento del software.

1

Capitulo I Problemática del mantenimiento de s is tema de software.

1.1 ¿Qué es el software ?

A menudo se Presenta confusión cuando intentamos definir los términos software y programa, por que en realidad la palabra software implica hoy en día más que lo que implica la palabra programa. El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informaticos. El desarrollo de software ha pasado de ser una resolución de problemas especializada, a ser una industria por sí misma. Sin embargo la reciente cultura e historia de la “programación” presentan todavía algunos problemas. El software se ha convertido en un factor que puede limitar la evolución de los sistemas informáticos[PRE88]. Podríamos definir el software, como el conjunto de programas, procedimientos, reglas y documentación asociados con un sistema de hardware (computador), permitiéndole al usuario realizar alguna función [FA1901 .

Por su parte un programa puede definirse como un conjunto de instrucciones codificadas que interpretan la información que se introduce con el teclado, ratón o cualquier otro dispositivo de interacción y luego hacen que la computadora ejecute una o varias tareas.

En relación a los componentes de un sistema de información computarizado, Puede decirse que el software es el elemento lógico, a diferencia del hardware que es COnsiderado como la parte fisica[BRE88].

1.2 Crisis del Software

Con el descenso en los precios de los componentes electrónicos y el incremento en la complejidad de los sistemas de software, la relación entre el costo del hardware y del software se ha modificado, aumentando el segundo en relación con el pnmero. Pressman en 1988 puntualizó que un 70% del costo de un sistema computarizado estaba en el software[PRE-881, Charette en ese año decía que era más del 80% y pronosticó que para la década de los 90’s el costo del software en relación con el hardware llegaría a alcanzar el 90%[CHA-88].

Las estadísticas señalan que pocos proyectos de software se han terminado dentro de las restricciones originales de costo, calendarización y cumplimiento de especificaciones [JEN-SO], por lo que el desarrollo del software se ha caracterizado por sobrecostos, retrasos en las entregas e inutilidad de los productos.

Básicamente en la mayoría de las organizaciones que desarrollan productos de software, durante el desarrollo de los proyectos se invierten más recursos de los que se presupuestaron originalmente. Invertir más tiempo y más personal implica aumentar los costos y retrasarse en la entrega de los productos. La situación se agrava al constatar que los productos generalmente no satisfacen de manera adecuada las necesidades de los clientes. A

2

Problemática del mantenimiento de sistemas de software. Capitulo I

esta situación de sobrecostos, retrasos e insatisfacción se le conoce como “la crisis del software”.

Estos problemas han motivado que tanto universidades como fabricantes de equipo de cómputo y organizaciones desarrolladoras de software destinen recursos para llevar a cabo investigaciones y desarrollo tecnológico orientados a resolver los problemas del software, teniendo como objetivo el mejoramiento de la calidad del software, el descenso de los costos de producción y el mantenimiento de los sistemas una vez implantados.

1.2-1 La problemática del software en nuestros días

Actualmente, en las Organizaciones de desarrollo de software ]a prioridad más importante es calidad en los productos de software y la productividad del equipo que desarrolla los productos. Los productos de software desarrollados actualmente tienen un alto grado de complejidad y sofisticación que hacen que el proceso de desarrollo en muchos casos sea mal o pobremente implementado. En los casos en que se debe realizar mantenimiento a sistemas de software ya existentes el problema ha sido una inversi6n de tiempo considerable dando como resultado sobrecostos y pérdida de oportunidad en los negocios.

El problema de la crisis del software es grande, afecta a muchas organizaciones de gobierno y compaiIías productoras y usuarios del software. Acorde con estudios realizados en 1993 en Estados Unidos, menos del 1% de los proyectos de software ya terminados se habían entregado a tiempo, dentro del presupuesto estimado y cubriendo todos los requerimientos del usuario[MOL-93], asimismo, la mayor parte de todos los proyectos de software terminaron un año más tarde y el costo se increment6 en dos veces el costo inicial estimado.

En junio de 1993 el grupo consultivo de la IBM public6 los resultados de un estudio que realizó con 24 compañías líderes que han desarrollado grandes sistemas distribuidos. Los resultados fueron sorprendentes: 55% de los proyectos costaron más de lo esperado, 68% sobrepasaron sus fechas calendarizadas y el 88% tuvo que ser rediseñado [WAY-941.

La baja calidad del producto y la baja productividad del equipo que lo desarrolla reduce las ganancias de las organizaciones desarrolladoras de software. Debido a esto, es deseable tener la habilidad para realizar una estimación exacta del tiempo de desarrollo de los productos de software. También es importante decrementar el tiempo transcurrido entre la concepción del producto y la entrega ai cliente[MOL-931. Si no se toman medidas a tiempo, los problemas relacionados con la calidad del software y su ejecución pueden afectar adversamente las relaciones de una compañía con SUS clientes.

La calidad es una preocupación primordial de los ingenieros de s o h a r e , y los criterios y parámetros de la calidad dependerán, obviamente, del producto en particular. En

II

3

Capitulo I Problemitica del mantenimiento de sistemas de software.

Casos, la transportabilidad del producto entre diversas máquinas podrá ser un atributo de impomcia capital, mientras que en otras ocasiones el uso eficiente de la memoria Puede ser 10 fundamental; por Otro lado, existen algunas características de calidad V e son fundamentales en todo producto de programación; entre ellas están la utilidad, la claridad del código, la confiabilidad, la eficiencia y la economía.

Muchos observadores de la industria han caracterizado los problemas asociados con el desarrollo del software como una “crisis”, sin embargo, lo que realmente tenemos puede ser algo bastante diferente.

La palabra “crisis”, se define en el diccionario Webster como “unpunto decisivo en el curso de algo; momento, etapa o evento decisivo o crucial”. Sin embargo para el software no ha habido ningún “punto decisivo”, ningún “momento decisivo”, solamente un lento cambio evolutivo. En realidad en la industria del software hemos tenido una “crisis” que ha estado con nosotros cerca de 30 años y eso es una contradicci61-1 para el término.

Tanto si lo llamamos crisis del software como mal del software, el término alude a un conjunto de problemas que aparecen en el desarrollo del software. Los problemas no se limitan al software que “no funciona correctamente”, el mal abarca los problemas asociados a cómo desarrollar software, c6mo mantener el volumen cada vez mayor de software existente y c6mo poder esperar mantenernos al corriente de la dm~anda creciente de software.

1.3 Ciclo de vida del software, algunos enfoques

A continuación se describirhn algunos enfoques del ciclo de vida del software. El presente trabajo está enfocado al ciclo de vida clásico, ya que es en este enfoque en donde se puede visualizar con claridad en papel tan importante que juega la fase del mantenimiento en el desarrollo de cualquier producto de software.

I/

1.3.1 Ciclo de vida clásico

La figura 1.1 ilustra el paradigma del ciclo de vida clásico para la ingeniería del software. Algunas veces llamado “modelo en cascada”. Este paradigma del ciclo de vida exige un enfoque sistemático y secuencia1 del desarrollo de software que comienza con un estudio sistémico de los requerimientos y progresa a través del análisis, diseño, codificación, prueba y mantenimiento del software.

Modelado a partir del ciclo convencional de una ingeniería, este enfoque considera las siguientes actividades[PRE90]:

4

Capitulo I Problemática dei.man1enimiento de sistemas de software.

Zngenieriu y análisis del sistema Debido a que en general el software forma parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos ai software.

Análisis de los requisitos del software. El proceso de recopilación de 10s requisitos se centra e intensifica especialmente para el software. Para comprender la naturaleza de los programas que hay que ConSrniir, el ingeniero de software o experto analista de sistemas debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas,

Diseño. El diseño del software es un proceso que se orienta a la definición de cuatro aspectos distintos del software: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseíío traduce los requisitos en diversas representaciones del software que deben ser definidas y especificadas de manera que se obtenga la calidad requerida antes de que comience la codificaci6n. AI igual que los requisitos, el diseño se documenta y forma parte de la configuraci6n del software.

Co(1ificncidn. El diseíío debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea.

a Prueba Una vez que se ha generado el cbdigo, comienza la prueba del programa. La pmeba se centra en la lógica interna del software, asegurando que todas las instrucciones se han probado, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento. El software, indudablemente, sufrirá cambios despues de We se entregue al cliente. Los cambios ocurrirán debido a que se hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo, 0 debido a We el cliente requiera ampliaciones funcionales O de rendimiento.

i/

5

Capítulo I Problemática del mantenimiento de sistemas de software.

---- __

. . . .

. .. . . . . __ Figura 1.1 Ciclo de vida clásico del software.

En este trabajo de tesis nos interesamos particularmente en la fase de mantenimiento. Pero para esto debemos entender más a detalle, cómo depende la fase de mantenimiento de la fases anteriores en el ciclo de vida del software y cómo se pueden reducir sus métricas de costo y tiempo cuando las fases anteriores en el ciclo se han desarrollado correctamente.

1.3.2 Construcción de prototipos

La construcción de prototipos es un proceso que facilita al programador la creación de un modelo del software a construir. La figura 1.2. muestra la secuencia de sucesos de este proceso. La construcción de prototipos comienza con la recolección de requisitos y termina con un producto de ingeniería. Algunos de los problemas que debemos tratar de evitar son los siguientes:

El cliente observa y analiza el funcionamiento de la primera versi611 del software sin- imaginar que debido a las prisas no se consideraron aspectos de calidad o de mantenimiento que pueden afectar a largo plazo el software desarrollado.

Puede ser que el ingeniero de software no considere todas las alternativas factibles al desarrollar el prototipo, esto es debido a la prisa que tiene por lograr que éste funcione rápidamente.

6

Capitulo 1 -__ .- . . ~

inicia Termina \

Figura 1.2 Construcci6n de prototipos

1.3.3 Técnicas de cuarta generación

El término “técnicas de cuarta generación”(T4G) comprende un conjunto de herramientas de software que facilitan la especificación de alto nivel de algunas características del software. A partir de estas especificaciones estas herramientas pueden generar automáticamente el código fuente.

Estas técnicas se orientan a la posibilidad de especificar el software a un nivel más próximo al lenguaje natural o en una notación que proporcione información más significativa de las funcionalidades del software por desarrollar. Algunas herramientas incluidas dentro del entorno de este paradigma son: lenguajes no procedurales para consultas a bases de datos, interacción y definición de pantallas, generación de código, facilidades gráficas de alto nivel y facilidades de hoja de cálculo. La figura I .2. muestra las etapas involucradas en el paradigma T4G.

Recoleccih de requisitos .- Idealmente, el cliente describe los requisitos, que son a continuación traducidos directamente a un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de los hechos que le son conocidos y puede no desear o ser incapaz de especificar la información, en la forma que una herramienta T4G puede aceptarla.

I

7

..

Capítulo I Problemática del mantenimiento de sistemas de software.

Esfrafegia de &erío.- Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de requisitos al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G). Sin embargo, para grandes proyectos es necesario un mayor esfuerzo para desarrollar una estrategia de diseño del sistema, incluso si se utiliza un L4G. El uso de T4G sin diseño puede causar las mismas dificultades (poca calidad, mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla software mediante los enfoques convencionales.

Implementación en L4G.- Permite .al que desarrolla el software centrarse en la representación de los resultados deseados. Un L4G genera automáticamente código fuente apartir de los resultados deseados, el desarrollador de software solo piensa en ei “que” necesita y no en el “como” desarrollarlo.

Pruebas.- Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una prueba completa, desarrollar una documentación con sentido y-ejecutar el resto de actividades de “transición” requeridas en los otros paradigmas de ingeniería del software.

Recolección de requisitos

L

1

Estrategia de Dissflo L

A Implementación

Prueba

f I

Figura 1.3 Técnicas de cuarta generaci6n

8

Problemática del mantenimiento de sistemas de software. ~~~ ~.

Capitulo I ,... .

1.4 El mantenimiento como una fase dei ciclo del software

El mantenimiento del software es la e.jecución de las actividades requeridas para mantener un sistema de software en forma operable después de que ha sido liberado y puesto en operación. Es el conjunto de actividades que resulten del cambio del producto original, estos cambios consisten en modificaciones creadas por la corrección, inserción, borrado o ampliación del sistema.

1.4.1 Tipos de mantenimiento de software

Pressman clasifica el software de la siguiente manera [PRE93]:

-Mantenimiento de mejora, -Mantenimiento para adaptacih, -Mantenimiento correctivo.

1.4.1.1 Mantenimiento de mejora

Incluve todos los cambios. inserciones. k rrados, modific iiones y extensiones que se efectúen al sistema para responder a las necesidades de crecimiento del usuario. Generalmente, estos cambios son el resultado de la aparición de nuevos requisitos o de las modificaciones de alguno existente. Las actividades encaminadas a lograr códigos más comprensibles, como la reestructuración o actualización de la documentación son consideradas como mejoras. La optimización de código para una ejecución más rápida, también cae dentro de esta categoría. Las estimaciones indican que el mantenimiento de mejora comprende alrededor del 60% de todos los esfuerzos involucrados en el desarrollo de software[PRE93].

1.4.1.2 Mantenimiento para adaptación

Es cualquier esfuerzo realizado a raíz de cambios en el medio ambiente en el que opera el sistema de software. Abarca un porcentaje aproximado del veinte por ciento de toda la actividad de mantenimiento[PRE93].

Los cambios del medio ambiente pueden ser en:

Las normas, procedimientos y regulaciones que afectan al sistema, La configuración del hardware, terminales nuevas' impresoras, etc, Los usuarios y personal a cargo del sistema, En los formatos y estructuras de datos,

9

11

I¡

I¡

/I

!I

I¡

I

I!

!I

¡I

I1

11

!I

Capltulo 1 Problemática del mantenimiento de sistemas de software.

En las utilerías y sistema operativo.

1.4.1.3 Mantenimiento Correctivo

Los cambios necesarios surgidos por la corrección de errores en un sistema abarcan generalmente un veinte por ciento del mantenimiento global del software. Las causas del mantenimiento correctivo son: errores de diseño, errores de lógica y errores de codificación.

Los errores de diseño son generalmente el resultado de descripciones incorrectas, incompletas o poco claras originadas por cambios o por la aparición de nuevos requerimientos del sistema.

Los errores de lógica, resultan de pruebas y conclusiones inválidas, un deficiente flujo de datos, así como la impiementación incorrecta de las especificaciones del diseño.

Los errores de codificaci6n son causados por el programador, y son el resultado de implementaciones incorrectas del diseflo.

1.4.2 El mantenimiento del software como una función del diseño

Los requerimientos de mantenimiento de los productos de Software son generalmente subevaluados por los diseñadores de software debido a que generalmente no consideran las funciones del mantenimiento como componentes del costo del ciclo de vida del producto de software. I 1.4.2.1 Puntos de vista acerca del ciclo de vida clásico del software

Se ha desarrollado el concepto de “ciclo de vida del software” para el software nuevo. El ciclo de vida generalmente inicia con el reconocimiento de problemas y objetivos. El ciclo continua con el análisis, diseño, codificación, instalación, prueba, y operación. El Último escalón del ciclo es el mantenimiento. Los problemas con este modelo son numerosos. Sin embargo, el modelo es generalmente representado por medio de un concepto lineal no circular. En realidad el modelo actual del ciclo de vida del software es una mezcla del concepto lineal con el concepto cíclico.

ll

Cuando desarrollamos software a menudo empleamos mal el concepto de /I mantenimiento y lo consideramos como un paso simple al final del ciclo. Esto trae cómo consecuencia que cuando deseamos darle mantenimiento de mejora al software, el

10 I/

Capltulo 1 Problemática del mantenimiento de sistemas de software.

programador analista deberá dedicar mas tiempo y esfuerzo al análisis y comprensión de las funciones actuales que a las nuevas funciones que va a incluir.

Por lo anterior el desarrollo de software puede concebirse como un proceso secuencial, siempre y cuando exista una retroalimentación de información entre las fases que permita verificar la correcta ejecución del proyecto.

1.4.2.2 Costos y localización de esfuerzos

En el desarrollo de software, la evaluación económica de un proyecto debe determinarse con el análisis costo-beneficio tradicional. Esta aproximación utiliza un modelo en el cual los costos aumentan y los beneficios disminuyen conforme al ámbito avanza.

El costo total que pretende minimizarse consiste en tres componentes fundamentales: costo de mantenimiento, costo de operación y el costo original de desarrollo. Este esquema incluye todos los costos de arreglo de errores o problemas, todas las elevaciones de precio y todos los cambios requeridos por alteraciones en el medio operativo del producto dentro de la definición de mantenimiento (éstos son los costos de todos los cambios a un producto después de su desarrollo original). Los costos de operación incluyen costos de hardware y cualquier trabajo y costo de dirección asociados directamente con la ejecución del producto. Los costos de desarrollo incluyen todos los relativos al análisis, diseño, codificación y prueba de un nuevo producto. La tendencia histórica de los componentes del costo es el proceso de revisi6n de valores. Los costos de operación, por unidad de trabajo, están decrementando rápidamente debido a que los componentes de hardware asociados a estos costos disminuyen, sin embargo, como los costos por unidad de trabajo han disminuido, la demanda de unidades adicionales aumenta en mayores proporciones. Los costos de mantenimiento y desarrollo se incrementan. El costo de mantenimiento también se ve incrementado debido a que la vida útil de los productos de software también se ha incrementado.

1.4.2.3 Los costos del mantenimiento

La etapa que generalmente involucra más tiempo en su desarrollo es la del mantenimiento, independientemente del tipo de éste; según Pressman el 70% del tiempo total del ciclo de vida de un producto de software se dedica a la fase del mantenimiento. Para consiguiente un desarrollo de software que tiene duración de uno a dos años, involucra un periodo de mantenimiento de cinco a diez años[FA190]. AI igual que el factor tiempo el costo juega un papel importante en la fase del mantenimiento. En el desarrollo del software la fase del mantenimiento representa el 70% de costo en relación con los gastos en hardware y software[BOE76]. Los costos de mantenimiento durante la fase de desarrollo impactan de manera importante el costo de desarrollo de un producto. Pero también es

9 8 - 0 0 7 3

Problemática del mantenimiento de sistemas de software. - __ ~

Capltulo 1 _.

importante considerar los costos de mantenibilidad una vez que el producto de software se encuentre en operación.

De acuerdo a este punto de vista, consideramos de suma importancia todo esfuerzo en reducir los costos relacionados con el mantenimiento.

1.4.2.4 Planeación del mantenimiento

Según Reutter[JEN80], la mayoría de las actividades de mantenimiento son directamente originadas por características o capacidades que no fueron contempladas en el diseño original del producto, y la mayoría de las actividades de mantenimiento restantes se refieren directamente a cambios en el medio ambiente en el cual opera el producto de software. Solo una pequeña parte del mantenimiento se refiere a corrección de errores. Mientras que esto no refleja la experiencia con todo el software, probablemente representa lo que se espera del software bien diseñado y bien escrito. En el software de alta calidad. la probabilidad de error se aproxima a cero.

Los posibles cambios para adaptación o mejoras de un sistema, son identificados en el momento del análisis y diseño del producto. En estas fases, las decisiones son hechas para determinar el alcance del proyecto. Las características que deben ser incluidas en el producto son frecuentemente olvidadas.

Existe la otra cara de la moneda, las Características que no se incluyen en el diseño del producto. Estas son características o soluciones técnicas que fueron rechazadas por no responder a las necesidades del producto.

Un apéndice del documento de especificaciones es necesario para el análisis de características no consideradas dentro de un proyecto. Este complemento puede ser de valor para la construcción de un proyecto que esta siendo especificado; su objetivo es auxiliar al mantenimiento. En este sentido, esta información se incluirá en un documento o archivo, el cual podrá ser accesada por el encargado de mantenimiento para estudiar o verificar algún problema.

1.5 Problemas de una mala ingeniería de software

Los métodos de la ingeniería de software indican “cómo” construir técnicamente el software. Los métodos abarcan un amplio espectro de tareas que incluyen: planificación y estimación, análisis de requisitos del sistema y del software, diseño de estructuras de datos, arquitectura de programas y procedimientos algorítmicos, codificación, prueba y mantenimiento.

Las herramientas de la ingeniería del software suministran un soporte automático o semiautomático para 10s métodos.

12

Capitulo I Problemática del mantenimiento de sistemas de software. . . . -~ __ ~. ~ ~~

Los procedimientos de la ingeniería de software son el soporte que junta los métodos y las herramientas. Los procedimientos definen la secuencia en que se aplican los métodos, las entregas (documentos, informes, formas, etc.) que se requieren, los controles que ayudan a asegurar la calidad y coordinar los cambios, las directrices que ayudan a los gestores del software a evaluar el progreso [PRE88].

Cuando se realiza un sistema de software y no se aplica una adecuada ingeniería del software, se generan una serie de problemas que se hacen evidentes cuando deseamos dar mantenimiento al software. Algunos analistas o programadores intentan entender el programa completo antes de hacer cambios, mientras que otros se enfocan directamente a las áreas que necesitan modificación e ignoran el resto del código, o en su defecto algunas veces prefieren, la opción de volver a realizar el programa, argumentando que el tiempo invertido en el análisis de éste puede ser mucho mayor que la creación de uno nuevo.

13

Capitulo 2 Problemática del diseflo y su relación con el mantenimiento.

CAPÍTULO 2

PROBLEMÁTICA DEL DISENO Y SU RELACIÓN CON EL MANTENIMIENTO

En este capítulo se describe en forma detallada el problema a resolver, los objetivos propuestos, los beneficios esperados y la metodología de solución.

CapiNlO 2 Problemática del diseflo y su relación con el mantenimiento.

2.1 Planteamiento del problema

La comprensión tiene un papel crucial en el mantenimiento de programas. Se estima que los programadores de mantenimiento pasan entre el 17% y 62% de su tiempo intentando comprender el código fuente. Dependiendo de la tarea de que se trate, este esfuerzo puede requerir la comprensión total del programa o de solo una parte de éI[PAU90].

Para un programador resulta relativamente fácil comprender una parte o fragmento del código fuente, lo tedioso y dificil se presenta al tratar de comprender el funcionamiento del programa como un todo. En todo caso, se constata que algunos programadores intentan analizar el programa completo antes de hacer cambios, mientras que otros se enfocan directamente a las áreas que necesitan alguna modificación y el resto lo ignoran.

Los listados de código fuente son todavía los más utilizados por los programadores profesionales para tareas cotidianas o excepcionales de mantenimiento. El problema es que estos listados no ayudan realmente a efectuar estas tareas de manera eficaz. Es decir, los listados de código no presentan de manera explícita los elementos que permitan comprender el funcionamiento del programa:

Arquitectura conceptual, Flujo de datos, Diccionario de datos, etc.

Una manera de alcanzar un mayor porcentaje en la comprensión del funcionamiento de un programa sena contar con un documento que muestre la información descrita

funciones o procedimientos llama, cómo identificar rápidamente los parámetros de una función, cuál es el tiempo de vida de una variable, etc..

anteriormente y su relación con el código fuente. Por ejemplo, una función a qué otras /I

! 2.2 Objetivo de la tesis

Con base en el problema citado en el punto anterior y para efectos de esta tesis, proponemos el desarrollo de una herramienta que permite explotar los listados de código fuente para generar información útil para realizar el trabajo de mantenimiento de manera eficaz. Se pretende asimismo que esta información corresponda a las estrategias de búsqueda y análisis que demandan las actividades de mantenimiento. Así, el principal objetivo de este trabajo es el diseño y desarrollo de una herramienta que de manera automatizada y de acuerdo al paradigma del libro genere a partir del código fuente un documento descriptivo de la estructura del sistema de software, así como de los elementos que lo integran.

Capitulo 2 Problemática del diseno y su relación con el mantenimiento.

El resultado será el desarrollo de un prototipo de herramienta para documentar programas escritos en lenguaje C, bajo ambiente Windows. Se pretende aprovechar las características de este último por sus facilidades de manejo de hipertexto. Esta técnica permite agilizar las actividades de mantenimiento, en particular para menejar la comprensión del código fuente. Suponemos que esta facilidad de comprensión hace más eficaces las tareas de adaptación, modificación, reutilización y exportación de c6digo para actuales o nuevas aplicaciones.

2.3 Beneficios

El generar una documentación automática del código fuente y un diccionario de datos del mismo, ofrece los siguiente beneficios:

Disminuir el tiempo y costo en el mantenimiento de software,

Contar con un esquema de la estructura de datos que permita proporcionar un mantenimiento más eficaz a los programas fuente;

Contar con una herramienta que proporcione al ingeniero de mantenimiento de software o bien a cualquier usuario un documento del código fuente.

La organización del código fuente como libro ofrece los siguientes beneficios:

Un modelo de documentos que es fácilmente reconocible, Un alto nivel en la organización de la claves de los códigos, Bajo nivel en la organización de fragmentos , niveles y guías, Rutas de acceso múltiple por medio de la tabla de contenido e índice.

2.4 Metodología de Solución

Algunos estudios sobre el trabajo de los programadores muestran que los i I '

fragmentos, planes y guías juegan un papel importante en el proceso de lectura y entendimiento del código. El mantenimiento normalmente se divide en tres tipos: corregir, prevenir y perfeccionar. No es claro cómo íos programadores adaptan sus cambios a los requerimientos de mantenimiento, pero hay claros indicios de que muchas de las estrategias y técnicas son usadas en los tres tipos de actividades de mantenimiento[PAU90].

Algunos programadores tratan de entender todo el código, mientras otros sólo la parte de código en donde harán las adaptaciones e ignoran todo lo demás. Un libro es una colección de información que permite, tanto una fácil comprensión, como una variedad de accesos a métodos. La estructura permite el acceso de información de lo más general a lo - 1 más específico y de lo más específico a lo más general.

I II

16

Capitulo 2 Problemática del diseíio y su relacibn con e l mantenimiento.

Para presentar una solución al problema planteado, se propone utilizar el paradigma del libro que se tratará en el próximo capítulo, complementándolo con mecanismos de hipertexto.

Se ha identificado que el paradigma del libro con el formato de los programas, es una organización tipográfica muy apropiada para organizar y presentar la información. El ’

paradigma del libro usa estilos de tipo, sentencias, phrrafos, división de secciones, división de capítulos, prefacios, índices, y paginación, y presenta el contenido de un sistema, de tal forma que ayuda al programador a la comprensión del código fuente y facilita las actividades de mantenimiento.

Todos los componentes de un libro están diseñados para facilitar el acceso y transferencia de la información rápidamente. La organización de la información contenida entre un libro y un programa es semejante.

2.5 La Importancia de la documentación

Algunos argumentan que un programa bien-escrito es lo mismo que un programa que bien documentado. Sin embargo la experiencia en la práctica sugiere que esto es verdadero sólo para programas pequeños. Los programadores no pueden entender fácilmente programas grandes. Cuando tales programas se someten a análisis, en general estudio, nos enfocamos en los pequeños detalles, mientras hacemos uso de descripciones incompletas o inexactas de la estructura en general del código . La combinación de grandes cantidades de detalles con inexactitud o descripciones vagas de fragmentos de código nos hacen caer en errores serios. Y

El mantenimiento de grandes sistemas de software es raramente tarea de una sola persona, pero también los equipos de mantenimiento de software padecen problemas de comunicación y coordinación. Por esto a menudo se piensa en reemplazar antes que dar mantenimiento a este tipo de sistemas.

Cuando se estudia un programa grande, debemos descomponerlo en pequeñas partes y entonces, provisionalmente, asociar a cada fragmento del código una función. Frecuentemente, hallamos que nuestras suposiciones provisionales no eran exactamente lo qué los programadores desarrollaron; después de revisar nuestra división inicial y descripciones de la función, probamos de nuevo. Utilizando este proceso iterativo comprobamos que el programa este correcto. Usualmente en la práctica antes de tener una comprensión completa del programa o el tiempo se termina o se acabo nuestra paciencia.

. .

1 -

!

Un método de diseño o un algoritmo que fue obvio al programador durante el desarrollo del software no es obvio a otro programadores, o aun para el mismo programador un año más tarde. Aun cuando el software se haya desarrollado utilizando un proceso de

17

Capitulo 2 Problemática del diseno y su relación con el mantenimiento.

refinamiento sistemático, quedan pocos rastros de ese proceso al final de la codificación. Aunque el autor del programa hubiera pensado en estructurar el programa en bloques de código claramente definidos para cada función, no es fácil identificar esos bloques e inducir sus funciones con solo mirar la codificación final.

Cuando se determina el costo verdadero del software una consideración importante es la estimación de vida Útil del software. De gran importancia en esta estimación es el mantenimiento del software. La determinación del mantenimiento incluye tres factores:

La suficiencia del software, La suficiencia de la documentación del programador, y La habilidad de los programadores de mantenimiento.

Dependiendo de las habilidades del desarrollador de software, el software se consideraría "bien" codificado o no. Donde la medida de "bien" puede incluir el grado en que la codificación misma se documenta, el esfuerzo del diselio, y las necesidades del software.

La documentación del programador o la documentación interna, es generalmente pobre en cualquier desarrollo de software. &te no implica que los programadores no vean la necesidad de la documentación interna, sino que usualmente se le da a está la última prioridad en el desarrollo de software. Los sistemas del software son comúnmente producidos antes de tener una documentación. La documentación no es vista como una actividad en el diseño del software, pero si como una tarea requerida por regulaciones burocráticas o clientes exigentes. El esfuerzo que sufren los diseñadores al tratar de hacer.la documentación de un paquete antes de que sea obsoleto; o antes de que la competencia les

programadores necesitan moverse a algún otro proyecto. Por consiguiente, pocas documentación

original interna de un sistema de software dado. Asi como el, código se modifica, la documentación original puede o no ser modificada manteniéndola de acuerdo a la codificación. Por consiguiente, después de unas modificaciones, la documentación original seria inexacta.

gane el mercado; o cuando los gerentes descubren que lo planeado termina o cuando los

suposiciones son seguras con respecto a la calidad, o existencia, de la

il 1 !

Con objeto de extender la vida útil de un sistema de software, se desea construir sistemas que sean más fáciles de mantener yío modificar. Las normas de documentación existentes están adaptadas para nuevos desarrollos, pero no atienden el problema de la gran cantidad de software existente sin documentación, o documentación que se suspende o empieza a ser anticuada. ¿Qué se necesita para la generación de documentación útil para proporcionar mantenimiento al software existente, una respuesta a esto es la respuesta del concepto "demanda-fácil", que implica que más de un método de documentación se tenga está disponible y que la documentación puede ponerse al dia con muy poco esfuerzo.

18

Capitulo 2 Problemática del diseRo y su relación con el mantenimiento. ~___

También, se considera el mantenimiento para principiantes. Cuando los programadores ganan experiencia, dejan la programación del mantenimiento atrás como un esfuerzo menos-interesante.

2.5.1 Técnicas de diseño y documentación

Antes de empezar a automatizar el proceso de documentación del software, fue necesario determinar qué métodos de documentación son más útiles al programador del mantenimiento. Se analizaron las ventajas y desventajas de varios de los métodos de documentación que se presentan a continuacicin:

- Pseudocódigo, - Diagrama de Warnier-On, - Diagramas de flujo de datos, - Diagrama de Nassi-Shneiderman, - Diagramas HIPO, - Manuales de procedimientos, - Método de Folklore.

Actualmente no existe una sola técnica sencilla y estandarizada para la documentación y el diseño de sistemas de software. La figura 2.1 muestra cómo aparecería cada técnica si fueran graficadas con base en dos dimensiones : I I

(1) Qué tan estructurada es la técnica (2) Qué tan visual es la técnica.

Comenzando desde el cuadrante superior derecho de la figura (que representa técnicas altamente estructuradas y muy visuales) nos dirigiremos al cuadrante inferior izquierdo (que representa a las técnicas no estructurales y textuales).

A continuación discutiremos algunas de las técnicas que más se utilizan actualmente. Cada una de ellas tiene sus propias ventajas y desventajas y características exclusivas.

ii 19

Problemática del diseño y su relación con el mantenimiento. I!

Capitulo 2

I

Dinsrnmi do Wirnier Dingromns Nnrri-Selmeidormnn

HIPO

VISUAL'

* I , y , Diagramar C6nvene1,onalcr.de

flujos de datos Manus l~s de

procedimientos

. .

Figura 2.1

. .

DISEÑO ESTRUCTURADO

Dinsrnmi do Wirnier Dingromns Nnrri-Selmeidormnn

HIPO

VISUAL'

* I , y , Diagramar C6nvene1,onalcr.de

flujos de datos Manus l~s de

procedimientos

. .

TEXTUAL

. .

DISEÑO NO ESTRUCTURADO I

Rclscioncs de ttcnlcsr de diseno y doeumcnlocibn de sistemas

ica en el diseño del software y la documentación es unica en su concepción \.

'1

ial y en su estructuración.

2.5.1.1 Pseudocódigo

El pseudocódigo[KEN88], es similar al inglés estructurado, en el sentido de que no es un tipo particular de código de programación, pero puede utilizarse como paso intermedio en el desarrollo de tal código de programación. El uso del pseudocódigo es común en la industria; pero el carecer de una calendarización, le confiere en general, poca aceptación. Es tan similar a un código de programación que llega a ser común que lo utilicen los programadores en la figura 2.2 se muestra su uso.

R

Ventajas:

La narración es fácil de leer y comprender, Facilita el seguimiento de los procesos paso a paso, Ayuda a mostrar la estructura y arquitectura total de un programa.

I 20

http://C6nvene1,onalcr.de

http://C6nvene1,onalcr.de

Capitulo 2 Problemática del diseño y su relación con el mantenimiento. ... . .~ ~ ~~ _____

Desven tajas:

Las narraciones pueden ser largas o dificiles, Necesitan constante vigilancia cuando el programa sufre cambios.

total, resumen =O leer ei primer nombre, peribdico DO WHILE haya mas nombres(s) peri6dico

PRINT fecha PRINT nombre, periodico total, periodico=O

. .

Leer primer registro, suscriptor . . DO WHILE haya mas regisiros, suscriptor

IF Accion = Renovacion THEN subs, vigencia= subs. vigencia+num. semanas IF direccion direccion.actua1

THEN PERFORM cambio.direccion ELSE continua

ELSE IF Accion =Nueva THEN PERFORM Cambio.direccion subs.vigencia = num.semanas

ELSEIF Accion = Cancelacion subs.vigencia=O PERFORM Reembolso

ELSEIF Accion= Cambio.direccion ELSE PERFORM Accion.error ENDIF

. . , . total periodico = total.periodico + 1 PERFORM Imprimirlsuscriptor leer otro registrosuscriptor

ENDDO PERFORM Imprimir.periodico Obtener el siguiente nombre.periodico ENDDO Cerrar archivos . . .

Figura 2.2 El uso de pseudocódigo para ilustrar un servicio de actualizaci6n diaria de suscripciones de periódicos.

Capitulo 2 Problemática del diseño y su relaci6n con el mantenimiento. ~~~~~ __

Desventajas

Su mayor uso es en programas pequeños, y en programas grandes s610 se usa en los niveles mas altos ya que cuando se trata de grandes sistemas requieren de espacio considerable, de tal forma que el lector tiene varias páginas (a lo ancho) para asimilar todo el contenido del programa. . Las rutas de acceso de componentes procedurales no se muestran. No se visualiza la relación entre los módulos.

I It

2.5.1.3 Diagramas de flujo de datos

Otra técnica visual, pero más estructurada para el diseño y la documentaci6n de los programas es el diagrama de flujo ordinario. En la figura 2.4 se pueden encontrar ejemplos de símbolos utilizados para documentar tanto los sistemas como los programas.

Ventajas

Simple, elegante, flexible.

Son simples en apariencia. Fáciles de entender.

Facilita el seguimiento de los procesos paso a paso.

Desventajas

Existen numerosas desventajas en el uso de los diagramas ordinarios de flujo:

No se elaboran %on base en los principios de la programación estructurada, de tal forma que ilustran el flujo del programa, pero no su estructura; Cuando los programas son grandes no son fáciles de dibujar; Requieren de espacio considerable, de tal forma que el lector tiene varias páginas para asimilar todo el contenido del programa; Cuenta con demasiadas ramificaciones, cada una de ellas proveniente de cada decisión del diagrama de flujo, las cuales tienen varias formas de dibujarse; Cada autor utiliza un estilo particular y, en consecuencia, un autor tendrá dificultades para leer el diagrama de flujo de otro autor; También se tiene toda una lista extensa de símbolos que comprende y memoriza, io cual hace difícil la difusión de diagramas de flujo.

23

I!

Problemática del diseno y su relación con el mantenimiento. .- __ ___ Capitulo 2

Secuencia

1 Procero

I P a r k del caso(

Partc- Parte. Else ihen

If-then-else

Repeat -Unt i l Do-whi le

Ciclos

Selección

Figura 2.4 Símbolos utilizados en los diagramas de flujo de datos.

2.5.1.4 Diagramas Nassi-Schneiderman

'I

Un enfoque más estructurado, pero tal vez menos visual para el diseño y la documentación es el diagrama Nassi-Schneiderman @-S) [KEN88]. La figura 2.5 muestra los símbolos básicos que se utilizan en un diagrama Nassi-Schneiderman. El primero es el cuadro que sirve para presentar cualquier proceso en el programa.

El segundo símbolo es una columna dividida por un triángulo incorporado, que representa una decisión. El tercero es un cuadro dentro de otro cuadro, que se utiliza para indicar que se lleva a cabo una iteración.

24

. .

Capítulo 2 Problemática del diseno y su relación con el mantenimiento. .......

Ventajas

La principal ventaja de un diagrama N-S es que adopta la filosofia de la programación estructurada;

e Utiliza un número limitado de símbolos, de tal forma que el diagrama de flujo ocupa menos espacio y puede leerse con cierta facilidad por la gente POCO familiarizada con símbolos ajenos a los diagramas de flujo;

Proporciona al analista un instrumento de ayuda para el diseño de programas y de su proceso de desarrollo, pues es compatible con la programación estructurada. Los diagramas Nassi-Schneiderman son fáciles de leer porque no se requiere del conocimiento de símbolos complejos. Tampoco abusan del precioso espacio. En resumen, podemos decir que el diagrama Nassi- Schneiderman es un instrumento valioso para el analista.

Desventajas

Los diagramas Nassi-Schneiderman deben estar completos y ser muy claros, con el fin de que se entiendan;

Si de manera regular se hacen cambios, .los diagramas Nassi-Schneiderman, no serán apropiados, ya que deberán dibujarse nuevamente; y su modificación no es sencilla;

Y Proceso misión Iteración

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

25

iI

Caoítulo 2 Problemática del diselio y su relaci6n con el mantenimiento.

2.5.1.5 Diagramas HIPO (Hierachy/Input/Process/Output)

Este método fue creado por IBM [KENSS], con el propósito de ayudar a quienes

funciones dentro de un sistema grande, ya que este método permite tener una vista

para la documentación de programas, además puede facilitar al autor de un programa el recordar lo que hace el sistema después de cierto tiempo. En la figura 2.6 se muestra un ejemplo de la representación de un sistema utilizando el método HIPO.

programadores y a los que dan mantenimiento a los sistemas a visualizar todas las

panorámica de las entradas, procesos y salidas de datos. Esto lo hace una herramienta útil

i

I 1 i

4 9

Figura 2.6 Tabla visual de contenido para un paquete HIPO Ventajas

Sirve como un elemento recordatorio para el autor del programa, a quien ubica con rapidez, después de un largo periodo de no participar.

Desventajas

Requiere una considerable cantidad de espacio gráfico,

Con el fin de ver todo el programa completo, son necesarias varias páginas, y muchas páginas hacen que el lector se pierda.

Capitulo 2 Problemática del diseño y su relación con el mantenimiento.

Es un instrumento demasiado especializado. Estos diagramas sólo son entendidos por los analistas que están familiarizados con sus símbolos.

2.5.1.6 Manuales de procedimientos

I TABLA DE CONTENIDO

Sección 1 Introducción a EZSORT 1 .- Acerca de EZSORT 2 . - h a n q u e . 3.- Los fundamentos 4.- Un pequeño tutorial

1 2 .3 5 8.

Sección 2 Uso del EZSORT. 12 1.- Captura de dGos 13 2.- Ordenando con EZSORT ,17

. ' ?C 3.- Opciones de ordenamiento , .

4.- Salida 25 5 . - Ordenamiento avanzado mediante el uso de EZSORT 3C

Sección 3 Que pasa si ......... 41

1 .- Algunos problemas comunes 2.- Manteniéndose alejado de los problemas

.4: 4'

Sección 4 Referencia I 5(

1 .- Parámetros de entrada 5 2.- Opciones de ordenamiento 5 3.- Parámetros de salida 5 4.- Lista de mensajes de error 5 5.- Glosario 6 6.- Restricción del hardware 6

Indice 7

Figura 2.7 Tabla de contenido para el manual de procedimientos del programa denominado EZSORT.

Los manuales de procedimientos [KENSS], son documentos de carácter organizacional muy comunes. Estos son componentes de la documentación, aunque también contienen códigos de programación, diagramas de flujo, etc. Los manuales se usan para comunicarse con quienes utilizarán los sistemas y pueden contener comentarios

CaDitulo 2 Problemática del diseño Y su relación con el mantenimiento.

introductorios, pasos para realizar varias transacciones, instrucciones de cómo resolver problemas de operación y qué hacer cuando algo no funciona.

Un buen manual se utiliza continuamente como referencia, y como tal necesita organizarse de una manera lógica. Un ejemplo de la estructura de un manual se muestra en la figura 2.7. En él se encuentran las secciones que son necesarias para un buen manual.

Ventajas

Un alto nivel organizacional que facilita el encontrar la información que se busca.

Desventajas

Sólo son útiles cuando están :

Bien organizados, Cuando tiene claridad en la redacción, Que se actualicen cada vez que el sistema sufra cambios.

2.5.1.7 El método FOLKLORE

El Folklore es una técnica de documentación de sistemas, que ha sido creado para complementar algunas de las técnicas que hemos presentado. Aun con la plétora de técnicas disponibles, muchos sistemas quedan poco documentados e inadecuadamente documentados. La técnica FOLKLORE recopila la información que comparten los usuarios, pero que rara vez queda plasmada en un escrito[PRE88].

El folklore es un una técnica sistemática, basada en métodos tradicionales, que han sido utilizados para recopilar el folklore y costumbres de las personas. Este enfoque de documentación de sistemas requiere que el analista entreviste a los usuarios, realice investigación sobre la documentación existente en los archivos, y observe el procesamiento de la información. El objetivo es recopilar aquella información que se encuentre en cualquiera de las siguientes cuatro categorías: costumbres, cuentos, expresiones y elementos artísticos. La figura 2.8 sugiere cómo cada una de las categorías se relaciona con la documentación del sistema de información.

AI documentar costumbres y hábitos, el analista ( u folklorista) trata de dejar por escrito lo que los usuarios hacen para lograr que los programas funcionen sin problemas.

28

Capitulo 2 Problemática del diseño y su relación con el mantenimiento.

las historias es la manera de ver el sistema por los usuarios. La presión de la historia, por supuesto dependerá de la memoria del usuario; y, en el mejor de los casos, no deja de ser una opinión acerca de como funciona el programa.

Las recomendaciones son expresiones breves que representan generalizaciones. En la documentación de sistemas tenemos diversas expresiones tales como: “protege el original antes de respaldarlo”, “respalda siempre con frecuencia”.

La recopilación de manifestaciones artísticas es otra actividad importante que el analista o folklorista tradicional no debe pasar por alto. Los diagramas de flujo, las figuras y las tablas que desarrollan los usuarios, en ocasiones, llegan a ser mejores o más Útiles que los diagramas dibujados por el autor original del sistema.

F O L K L O R E

Figura 2.8 Ejemplo de como las categorías que se utilizan en el método de documentación FOLKLORE se aplican a los sistemas de información.

Ventajas

El enfoque de FOLKLORE funciona porque puede auxiliar la falta de conocimiento creada cuando el autor se retira. Los contribuyentes del

29

Capitulo 2 Problemática del diseflo y su relaci6n con el mantenimiento.

documento FOLKLORE no tienen por qué documentar todo el sistema, sólo aquellas partes que conozcan. Finalmente, es conveniente que los usuarios contribuyan, complementando las tareas del analista.

Desventajas

El riesgo de confiar en el FOLKLORE es que la información recopilada por los usuarios puede no ser objetiva, parcialmente correcta o peor aun, incorrecta. Sin embargo, a menos que alguien tome la tarea de escribir una documentación más formal del programa, la descripción de costumbres, sugerencias, historias y las formas artísticas, puede ser la única información escrita referente a cómo opera el programa.

II I/

2.6 Estado del Arte en herramientas de comprensión

2.6.1 Herramientas de mantenimiento

Existen herramientas que nos permiten realizar un mantenimiento en un forma más fácil y comprensible, según Fairley[FAI90] estas herramientas están compuestas por:

Editores de texto

Permiten modificar rápida y eficientemente un programa fuente, datos de prueba, así como documentos de apoyo. Los editores de texto se utilizan para insertar y reemplazar segmentos de código fuente, comentarios internos, datos de prueba, y documentos de apoyo. Para cambiar o localizar sistemáticamente todas las ocurrencias de un identificador u otra cadena textual. Para guardar las versiones antiguas y nuevas de una rutina, de un archivo de prueba o de un documento. Un editor puede ser de dos tipos: el editor dirigido a la sintaxis, el cual preserva la estructura del código fuente, y el editor de texto inteligente, el cual asegura que todas las referencias cruzadas en el documento de apoyo se actualicen correctamente.

Ayudas para depuración

Proporcionan trampas, vaciados, seguimiento de pistas, verificación de afirmaciones y archivos de historia que nos permiten localizar las causas de errores conocidos.

30

Capitulo 2 Problemática del diseiio y su relación con el mantenimiento. . . ~ ~ .. . . . .... . . . . . .. . . . . . . ~ ~. ~ ~~ ..-- ~.~

Generadores de referencias cruzadas

Brindan listados de referencias cruzadas para llamadas a procedimientos, uso de proporciones y referencias de datos. Los directorios de referencias cruzadas dan estructura, gráfica de llamadas, de quien llama a quien y en donde, además de los nombres de procedimientos y los números de las proposiciones en donde se definen, asignan y usan los parámetros formales, las variables locales y globales.

Editores de enlace

Liga los módulos objeto del código compilado para producir un programa ejecutable. Un programador de mantenimiento puede emplear los editores de enlace para configurar un sistema de varias maneras, también puede ligar de modo selectivo los módulos recompilados dentro de un sistema de software.

Comparadores

Equipara dos archivos de información e informa de las diferencias. Los comparadores se pueden usar durante el mantenimiento para cotejar dos versiones de un programa fuente, un conjunto de pruebas, un archivo de resultados o dos versiones de documentos de apoyo. Con el empleo de un comparador el programador de mantenimiento puede selialar las diferencias entre versiones, iiidicaiido si alguna modificación Iia logrado, o no, el resultado deseado.

Calculadores métricos de complejidad

Utilizados para medir la complejidad del código fuente. La mayoría de las métricas revisan un código fuente calculando el número de operadores y operandos, la complejidad en el flujo de control de información ( a través de la evaluación de la gráfica de llamadas), el número de parámetros y de variables globales y locales, así como el numero de niveles y formas de interconexión de la gráfica de llamadas. Un calculador métrico de complejidad nos da como resultado un número que nos indica, de acuerdo a los factores evaluados, qué tan complejo es un código fuente determinado. Estos calculadores se pueden utilizar al momento de proporcionar mantenimiento a un código fuente para determinar la complejidad de éste antes de cualquier modificación y la complejidad después de la misma.

31

Capitulo 2 ~ ~

Problemática del diselio y su relaci6n con el mantenimiento. I_-._. ~

Sistemas de control de versión

Pueden formar parte de la base de datos para la administración de la configuración o funcionar como una herramienta independiente. Entre las entidades existentes en una biblioteca para el control de versiones se encuentra el código fuente, el código objeto relocalizable, los comandos para el control de trabajos, los archivos de datos y los documentos de apoyo. Las operaciones que se realizan en esta biblioteca son: creación de ésta, edición, y borrado de componentes, preparación de copias de respaldo, edición de archivos, listado de estadísticas de resumen, compilación y ensamblado de versiones especificas [JOS78].

2.6.2 Software en el mercado

l).- SE Companion

Es un paquete que provee a los ingenieros de software diversos apoyos:

Asistencia en el desarrollo : consejos, ejemplos, generación de diagramas manejo de citas bibliográficas y de glosarios;

UN AMBIENTE INTEGRADO: que incluye gestibn de proyectos, procesador de palabras y otros paquetes CASE específicos;

MANEJO DE ANOTACIONES: Durante las sesiones con los usuarios, las sesiones JAD (Joint Application Development sessions) y de las instrucciones dadas hacia los desarrolladores;

UNA INTERFAZ DE USUARIO que facilita el aprendizaje rápido de este software.

2).- La herramienta CASE para el análisis de sistemas JLC navigator

Creación automática de diagramas de flujo,

Interfaz de diagramas de flujo,

Facilita la documentación estructurada,

Reporte completo,

Utilizado en programas de Cobol,

32

CapItulo 2 Problemática del disefío Y su relación con el mantenimiento.

y algunos otros.

3).- System Architect(SA)

Bajo Precio. Alta ejecución. Desde su introducción en 1988, System Architect (SA) provee de muchas mas características ofrecidas' por otras herramientas CASE que se encuentran disponibles para fracción de costo;

Rápido y Fácil. System Architect trabaja sobre IBM y para PC IBM compatible, bajo Windows o OS/2 PM. Proporciona un diccionario de datos que el usuario puede utilizar para encontrar lo que necesita;

Múltiples Opciones. SA trabaja con múltiples metodologías Yourdon / DeMarco, Gane & Sarson, Ward & Mellor (tiempo real), Shelaer/Mellor(OO), Información de Ingeniería, SSADM, y diagramas RE;

Q Provee de algunas otras características como lo son: documentación automática, diccionario, normalización, reglas y balanceo, importa y exporta reportes de clientes, y matrices CRUD;

Otra herramienta de software que genera código en el que se incluyen comentarios .internas es el WINDOWS MAKER PROFESIONAL, el cual tiene como propósito la creación de ventanas, iconos, cajas de diálogos y botones y se encuentra disponible para aplicaciones bajo Windows de la versión 3 en adelante.

33

Capitulo 3 Arquitectura del Documentador Automático (GenDoc)

CAPÍTULO 3

ARQUITECTURA DEL DOCUMENTADOR AUTOMÁTICO (GenDoc)

En este capítulo se muestra la arquitectura y diseño de los módulos que integran al documentador automático, la gramática utilizada en cada módulo, la estructura de datos y la interfaz con el usuario.

34

Cauitulo 3 Arquitectura del Documentador Automático (GenDoc)

3.1 Antecedentes

El sistema "Diseño e Implementación de una herramienta de Software para la Documentación Automática de programas en lenguaje C" GenDoc, es parte del proyecto AMbiente integrado de soporte para la Administración y desarrollo de Sistemas de Software" AMASS-I, en la figura 3..1 se muestra la ubicación del GenDoc.

El Consejo Nacional de Ciencia y Tecnología (CONACyT) otorgó financiamiento en abril de 1996, al proyecto Ambiente Integrado de Soporte para la Administración y Desarrollo de Sistemas de Software AMASS-I. Este Proyecto desarrollado por el Grupo de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET), surge como una necesidad ante los problemas que se presentan en cada una de la etapas del ciclo de vida del software, análisis, diseño, implementación y mantenimiento del 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.

Figura 3.1 Arquitectura conceptual del AMASS

35

Arquitectura del Documentador Automático (GenDoc) ~ ____ _- - Capítulo 3

~

componentes en el depósito.

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

errores en la etapa del mantenimiento.

Sistema de recuperación de código reutilizable(S1SREC)

Generador de código(GenCod) I

Sistema visual generador de interfa

Este sistema generará una interfaz comunicación entre las herramientas que

visuales (GenVIU)

que posibilite el empleo interactivo y y versiones posteriores a al AMASS-I

través de protocolos perfectamente definidos.

Sistema de documentación automática de programas(GenDoc)

Este sistema permitirá documentar interna y externamente programas de computadora escritos en lenguajes C. En esta parte se generará la estructura y el diccionario de datos utilizados por el programa en cuestión, un diagrama conceptual o índice de contenido del sistema, descripción de funciones y procedimientos, especificando sus

36

Capitulo 3 Arquitectura del Documentador Automático (GenDoc) ~ ~~ .~ ,... ~ . . .~

parámetros de entraddsalida. Esto será de utilidad para el proceso de mantenimiento de sistemas de información que carecen de la documentación asociada. Existirá un canal de comunicación e intercambio de información adecuado entre este sistema y los demás subsistemas del ambiente. Este subproyecto es el objetivo central del presente trabajo por lo que a continuación se presentará la arquitectura que utilizamos para la generación del GenDoc.

3.2 Arquitectura conceptual del documentador de programas (GenDoc)

En la figura 3.2 se muestra la arquitectura conceptual del documentador de programas.

Figura 3.2 Arquitectura del GenDoc

Plataforma Windows

Cuando se presentó el objetivo de la tesis[c.fr.2.2] se explicó que una de las razones por las que el GenDoc utilizaría la plataforma Windows es por sus ventajas en el manejo

37

Capítulo 3 Arquitectura del Documentador Automático (GenDoc) .... .. ~ ~ ........ ~ ~

.~ ~ ~ . . . . . ~ ~ . ~ ~ .. ..

de hipertexto. Esta técnica permite al usuario la organización del programa en forma de índice, así como el anidamiento de las funciones.

Analizador léxico

Antes de explicar en que consiste el módulo del analizador léxico del GenDoc debemos hacer referencia a la entrada del sistema.

Esta herramienta tien? como dato de entrada un programa estructurado escrito en lenguaje de programación C. Este código debe tener las siguientes características:

Debe estar indentado. Debe estar escrito en lenguaje C.

Debe de ser previamente compilado. Como ya se ha venido mencionando esta herramienta es un prototipo por esta razón esta limitado a estructuras tales como sentencias, decisión y repetición . Aunque es posible adaptarle estructuras todas las estructuras que soporta en lenguaje C, como un trabajo a futuro.

El GenDoc analiza dicho código y genera un programa documentado que consta de un pequeño texto descriptivo de la función del programa en sí, un diccionario de datos de la s variables utilizadas, un índice de las funciones que integran al código fuente. A continuación se describen brevemente cada uno de los módulos que integran esta herramienta.

Este módulo sirve para formar unidades Iéxicas de cada elemento para determinar si trata de palabras reservadas, de variables o bien de nombre de funciones, de acuerdo a la gramática del lenguaje C. No fue necesario utilizar un analizador sintáctico por que hay que recordar que como una de las especificaciones de entrada se pidió solo programa compilados previamente, por consiguiente estamos dando por hecho que sintácticamente deben de estar bien escritos.

Índice de las funciones

Una vez que el código fuente ha sido analizado y descompuesto en tokens por el Analizador del GenDoc, utilizamos los nombres de las funciones para formar un índice tipo libro. Se utilizan los nombres de las funciones puesto que son partes, guías o fragmentos de programa que al tenerlas identificadas nos permitan visualizar al sistema como un todo. Además de que es una de las maneras en que se puede organizar el código fuente, de manera que ofrezca mayores beneficios. Estos beneficios serán explicados posteriormente en el módulo del libro. La salida que presenta es un índice de las funciones que forman al programa fuente.

38

Capltulo 3 Arquitectura del Documentador Automático (GenDoc) -__ .

Analizador semántico

Utilizando el analizador sintáctico del lenguaje C, se agregó un texto descriptivo a cada una de las funciones que integran al programa dado de entrada.

Diccionario de Datos

El GenDoc tiene como salida un diccionario de datos en el que se presentan todos los datos utilizados en el código fuente que se analiza, cada uno de los datos se muestra con algunos de sus atributos como son el nombre, tipo, el alcance y el tiempo de vida. En el módulo del diccionario de datos se explicará a detalle la estructura del diccionario de datos en el capítulo 4.

Programa Documentado

La documentación consiste en las descripciones escritas, especificaciones, diseño y el código real de un programa. Existen dos tipos de documentacion, La documentacion externa de un programa es la información escrita que está fuera del cuerpo del código ejecutable. Generalmente esta documentación incluye las especificaciones del programa, el desarrollo del programa y las modificaciones posteriores y el manual de usuario. La documentación interna incluye comentarios, formateado del programa y código auto- documentado. El objetivo de todas estas caracteristicas es hacer al programa comprensible y facilmente modificable. El GenDoc presenta como salida una documenfación interna utilizando la tecnica del paradigma de libro. Esta técnica sera explicada en el capítulo 4. La . documentación interna que mencionanamos esta integrada por un indice de las variables utilizadas en el código fuente(E1 diccionario de datos), una tabla de contenido(1a organización de las funciones en forma de índice), y un parrafo para cada una de las funciones(código fuente para cada una de las funciones), El usuario tebdra la eleccion de anexar un prefacio(Comentarios dados por el usuario en la cabezera del código fuente).

39

Capítulo 4 Diseno y Desarrollo del Documentador Automático (GenDoc)

CAPÍTULO 4

DISENO Y DESARROLLO DEL DOCUMENTADOR AUTOMÁTICO (GenDoc)

En este capítulo se muestra la solución al problema planteado en el capítulo 2. Detallando cada uno de los módulos que integran al tiocumentador automático, la estructura de datos utilizada para cada módulo y la interfaz con el usuario.

40

Capitulo 4 Diseño y Desailollo del Documentador Automático (GenDoc)

4.1 El paradigma del libro

Los documentos del listado de código fuente (aún para grandes sistemas) todavía son usados por los programadores profesionales para tareas cotidianas de mantenimiento. El problema, sin embargo, es que los listados de código fuente no son diseñados realmente para ayudar a leer y entender el código fuente. Sino que son diseñados para tener una buena apariencia, pero no ayudan a tener una mejor comprensión del programa.

Lo que los programadores y los ingenieros en mantenimiento necesitan es un método para dar formato a programas que vaya de acuerdo con las estrategias de comprensión para los programadores y que también esté de acuerdo con las actividades de mantenimiento.

Consideramos que la forma más adecuada de dar formato a los programas, es la utilización de una organización tipográfica de un libro. En la figura 4.1 se muestra el formato.

YJ ddd,v”di,,, I , <lriH c

. .

.- I. --. ~ -. L” - -. -- - - - I .I Y

Contenido de otro capítulo

encabezados del

Prefacio , ’

Figura 4.1 Formato de un código fuente bajo la forma de un libro.

41

Capitulo 4 Diseño y Desarrollo del Documentador Automático (GenDoc)

El modelo del libro usa una organización específica de oraciones, párrafos, divisiones y secciones, divisiones para capítulos prefacios indexados y paginación para presentar código de una manera que ayuda a la comprensión y que mejora las actividades de mantenimiento. El organizar código fuente como un libro ofrece varios beneficios:

Un documento que es por su formato fácilmente reconocible información de alto nivel cerca del código fuente a través del empleo de claves (nombres de funciones) que permiten un acceso rápido y directo. Información de bajo nivel acerca del código fuente a través de una organización de los fragmentos que permite el acceso de manera completa y en detalle, utilizando guías de búsqueda. Rutas de acceso múltiple por medio de la tabla de contenido e índices.

El modelo del libro es un arreglo tipográfico de código fuente que sirve como una ~~

forma eficiente de organización de información y de presentación. No le da al programador una carga adicional por que es un medio familiar de transferencia de información que es compatible con la mayoría de las estrategias de comprensión y con la mayoría de las actividades de mantenimiento [PAU 901.

4.1.1 Comprensión y mantenimiento

Los programadores dividen el código fuente en fragmentos o segmentos significativos, que posteriormente organizan mentalmente en base a propósitos funcionales. Las guías son estructuras (o símbolos) que los programadores usan para localizar o aislar fragmentos significativos de los códigos mientras están formulando o verificando sus ideas.

El mantenimiento normalmente se divide en 3 tipos: correctivo, adaptivo y de mejora. No están claras las estrategias de comprensión que los programadores adoptan al realizar cambios o al dar mantenimiento al código fuente, pero hay indicios claros de que muchas estrategias y técnicas de comprensión se utilizan en los 3 tipos de mantenimiento.

Algunos programadores intentan atender todo un programa antes de realizar cambios, sin embargo otros se enfocan a las áreas que necesitan modificación e ignoran el resto del programa. Las notas que los programadores llevan a cabo pensando en voz alta mientras hacen^ mantenimiento para perfeccionar, nos muestran que frecuentemente hacen y prueban conjeturas sobre el código que están estudiando. También hojean a través del código en diferentes formas mientras formulan y prueban hipótesis.

Cuando trabajan con programas complicados, los programadores emplean múltiples estrategias, guiados por una variedad de planes y suposiciones. Reconociendo esto, buscamos un modelo de “observación de código” que:

42

Capitulo 4 Diseño y Desarrollo del Documentador Automático (GenDoc)

e Identifique rutas de acceso múltiple para búsquedas de arriba hacia abajo y de abajo hacia arriba,

Permite efectuar búsquedas a través de un alto nivel organizacional de claves del código fuente,

Aísle secciones de código y haga resaltar guías para una fácil identificación, y

Sea fácil de usar y compatible con las herramientas y con los estilos de programar existentes en la actualidad.

e

e

e

Lo que encontramos fue el modelo del libro [PAU90] .

4.1.2 El modelo del libro

Una definición de un libro es la siguiente

"Un libro es una colección organizada de información para permitir dos cosas: la coniprensiónfcícil y una variedad de métodos de acceso " [PAU90] .

Su estructura permite búsquedas .de arriba hacia abajo o de abajo hacia arriba y transversalmente, estrategias de comprensión global: y otras estrategias' específicas según se necesiten, así como hojearlos.

Se diseñan todos los componentes de un libro para facilitar su acceso y una transferencia rápida de información. Tradicionalmente los libros han sido impresos, pero la forma de un libro se adecua muy bien a otros mecanismos electrónicos de despliegue, pues no excluimos libros electrónicos de nuestro modelo.

Las similitudes entre un libro y un programa son muchas, la tabla 1 muestra algunas similitudes. La diferencia más grande entre un listado tradicional de código es que el formato libro proporcione claves simples e inmediatas que ayudan a localizar y reconocer la estructura de la información en él. Estas claves simples de organización están frecuentemente ausentes de los listados de código.

\

Para propósito de este trabajo, sólo se consideran algunas de las similitudes que .

consideramos más relevantes para efectos del mantenimiento de sistemas de software.

43

Caoitulo 4 Diseño y Desarrollo del Documentador Automhtico (GenDoc)

Tabla de contenido.

~~

En un libro Estructura En el código fuente

al Ingeniero d mantenimiento proporcionar comentarios introductorios.

Nombres de 12 funciones qc integran al códig fuente.

Prefacio. I El sistema permitir Introducción del autor al lector.

Alto nivel organizacional del contenido.

bajo nivel organizacional del contenido.

Alto nivel de divisiones.

Divisiones de capítulos

Fragmentos de información en grupos o párrafos.

Declaraciones y preguntas delimitadas y definidas por la puntuación.

Mecanismos para delimitar y destacar niveles del párrafo.

indices y paginación.

Capítulos.

Secciones.

Párrafos.

Frases.

Puntuación.

Diccionario de datos de las variables utilizado! por el código fuent con sus atributos. Nombre de cada una de las funcione

Llamadas a otras funciones

Fragmento de código de cada función.

Comentarios introductorios.

Declaración de estructuras y variables.

Referencia cruzada trazando con número de línea.

Unidades de programas, archivos incluidos.

Declaración de variables para cada módulo (Tipos, variables y cabeceras de las funciones).

Anidamiento de sentencias relacionadas. (Como If,case y Ciclos).

Declaraciones y sentencias de programas.

Mecanismos para delimitar y destacar niveles del código.

Tabla I . Analogías entre el modelo del libro, la propuesta de Paul W. Urnan, y el GENDOC.

44

Capitulo 4 DiseAo y Desarrollo del Documeniador Automático (GenDoc)

4.1.3 Formateado del código

El modelo del libro requiere de dos tipos de formato macrotipográfico (intermodular) y el formato microtipografico (intramodular). Esto no cambia el flujo de control del programa o su estructura de información; es un arreglo completamente tipográfico del código fuente.

Las tareas macrotipográficas incluyen la creación de un prefacio, un índice y una tabla de contenidos, hacer división de capítulos y paginar todo el listado.

El prefacio es esencialmente los comentarios de los encabezados del programa; la tabla de contenido es un mapa de alto nivel de la estructura del programa o del sistema; el índice es un mapa de bajo nivel de las entidades del programa (módulos e identificadores). Se pueden crear capítulos para las declaraciones globales, el modulo del programa principal, rutinas de apoyo que acompañan al programa principal y los códigos incluidos.

Las tareas microtipograficas incluyen el identificar y crear secciones del código, párrafos del código, estructuras de oraciones o frases y comentarios[PAU90 1.

4.2 Diseño del GenDoc

A continuación se describen el diseño de cada uno de los componentes que integran la documentación automática generada por el GenDoc. La tabla del contenido de las funciones, el índice y el párrafo para cada una de las funciones.

4.2.1 Estructura para la definición de la tabla de contenido del libro

Puesto que partimos de programas “bien ” escritos y en lenguaje C. La gramática a utilizar es la gramática del compilador de C. En esta etapa del trabajo manejamos la parte de la declaración de funciones.

e .-.-

Figura 4.2 Autómata para el reconocimiento de funciones del GenDoc..

45

Diseflo y Desarrollo del Documentador Automático (GenDoc) ~

Capitulo 4 .. ~ __

La sintaxis para la definición de funciones en el lenguaje C es la que se muestra a continuación :

tipo-funcion nombre-funcion (parámetros (opcional) ) declaración de los parámetros

Declaración de variables locales {

cuerpo de la función 1

En la figura 4.2 se muestra el automhta utilizado para el reconocimiento de funciones.

main() { int type ; char s[MAXTOP]; double op2, atof() , pop (), push(); while ((type = getop(s,MAXOP)) !=

switch(type) { case NUMBER:

push(atof(s)); break;

case ' f' ; push(pop0 + POPO); break;

Push(PoP0 * POPO);

EOF)

case '*':

break; case '-':

oP2=PoPo; break, case '1': op2= POPO; if (op2 != 0.0) push(pop0 12) ; else printff'divisor O") ;

case '=': printf("t%f\n,push (pop () )); break;

case 'c': clear(); break;

case TOOBIG: printfr'es demasiado largo"); break;

default: printff' comando conocido");

break, }

double push (Q double f; { if (sp <,MAXVALJ

else { re t~(va i [sp++l ,= . . ,tj;

printf("error"); clear(); retum(0);

1 }

double pop 0 {

if (sp > O ) retum(vai[--sp]); else{

printff'enor : stack vacio "); clear0; retum (O);

I I

. .

.. .

Figura 4.3 Muestra el código fuente escrito en Lenguaje C.

46

Capltulo 4 Diseflo y Desarrollo del Documentador Automático (GenDoc)

4.2.1.1 Estructura para generar la tabla de contenido del código fuente

Para formar el tabla de contenido del código de la figura 4.3 se utilizará la parte de la gramática de C para la declaración de funciones. Utilizando una lista ligada simple donde cada uno de los nodos de la lista representa una función en el código fuente. Un apuntador a una lista de funciones que son llamadas.por la lista que se esta analizando. Así como una liga a una lista de funciones que se encuentran en el mismo nivel de código que se esta analizando. Además cada uno de los nodos de la lista de funciones cuenta con una liga a una lista simple de estructuras del mismo tipo para sus parámetros.

La definición para los nodos de las listas de la tabla del contenido es la siguiente

struct fun struct par { {

char nombre-f[20]; char nombre[lO]; char tipo[5]; char tipo[lO]; int parámetros; struct par *siguiente struct fun *hijo,*hermano; 1; char texto[ 10001; struct par 'para;

I . I i

donde:

nombre-f tipo parámetros la función. *hijo,*hermano

= es una variable de tipo cadena la cual guarda el nombre de la función. = es una variable de tipo cadena la cual guarda el tipo de la función. = es una variable de tipo entera la cual guarda el número de parámetros de

= son variables de tipo apuntador a los hijos de la lista (funciones a las cuales llama) y los hermanos (funciones en el mismo nivel).

texto

*para

= variable de tipo cadena que sirve para almacenar el código fuente correspondiente a cada una de las funciones. = es una variable de tipo apuntador, que apunta a una lista ligada simple

que almacena los parámetros y sus atributos de cada una de las funciones.

La estructura a utilizar para generar el tabla de contenido es la que se muestra en la figura 4.4

41

Desarrollo del Sistema GenDoc Capítulo 4

struct fun StruCt par

Figura 4.4 Esta figura muestra la estructura de cada nodo de la lista, que se utiliz6 para formar el tabla de contenido del código fuente.

En la figura 4.5 se muestra la estructura de datos utilizada para el código de la figura 4.3. Como se puede apreciar en la figura se muestra el nivel en que se encuentra cada una de la función, que integran al código fuente escrito en C.

Main

Figura 4.5. Estructura de datos que se utilizó para formar el tabla de contenido del código fuente de la figura 4.3.

48

Desarrollo del Sistema GenDoc Capítulo 4

4.2.1.2 Creación de la tabla de contenido del libro utilizando hipertexto

Algunas de las definiciones son:

“Hipertexto es el ligado de piezas de texto u otra información en forma no secuencial” FNIE901.

“Hipertexto es un mecanismo para navegar en forma no secuencia1 a través de una red cuyos nodos son componentes de texto, y las ligas son relaciones definidas previamente por el usuario”.

En el sistema GenDoc utilizamos el mecanismo del hipertexto para navegar a través de las funciones a partir de sus llamadas a otras funciones.

Como resultado de una investigación sobre los diferentes sistemas de hipertexto (ver anexo I), el que presentó las mayores ventajas y por el cual se decidió optar, es un archivo con formato RTF ya que ofrece las siguientes ventajas :

1. Es el formato que utiliza la gran mayoría de las ayudas de los programas que trabajan bajo Windows.

2. Este formato es el más utilizado. Debido a esto existe mas información sobre este formato.

La creación de un archivo de hipertexto con formato RTF en ambiente Windows con formato RTF se puede resumir en los siguientes pasos:

1. Editar un archivo de texto con la extensión de RTF respetando la palabras reservadas de formato las cuales se explican con mayor detalle en el anexo], este archivo contiene la información del código fuente escrito en lenguaje C.

2. .Editar un archivo de texto con extensión HPJ el cual llama al archivo RTF.

3. Compilar el archivo con extensión HPJ, con lo que se obtiene un archivo con extensión HLP.

Un archivo HPJ es compilado con el compilador hc3l.exe. Este compilador identifica los archivos que forman al archivo HPJ y compila cada uno de los archivos en el orden en que aparecen.

El archivo de hipertexto organiza la información en forma de páginas, de hecho, la liga se realiza entre páginas de información.

49

Capitulo 4 Desarrollo del Sistema GenDoc

Utilizando el ejemplo del código fuente de la figura 4.3 el archivo con formato RTF quedaría de la siguiente manera:

\par\page #{\footnote Main} " ${\footnote Main} K{\footnote Main} \par {\b Informacion sobre la funcion Main} \par\par\tab {\uldb Getop} {\ getop} \par\par\tab {\uldb Push} {\ push} \par\par\tab {\uldb Atof? { \ atof? \par\par\tab {\uldb Pop} {\ pop}

\par\page #{\footnote getop} ${\footnote getop} K{\footnote getop}

\par\page #{\footnote Push} ${\footnote Push} K{\footnote Push} \par {\b Informacion sobre la funcion Push} \par\par\tab {\uldb Clear} {\ clear}

\par\page #{\footnote atof} ${\footnote atof) K{\footnote atof)

\par\page #{\footnote Pop} ${\footnote Pop} K{\footnote Pop} \par {\b Informacion sobre la funcion Pop} \par\par\tab {\uldb Clear} {\ clear}

\par\page #{\footnote Clear} ${\footnote Clear} K{\footnote Clear}

Como se muestra en el ejemplo anterior un archivo con formato RTF se organiza en páginas. Se tiene una página inicial, para el ejemplo anterior la página inicial es la función

50


principal que es el main, la segunda página contendrá ligas a las funciones a las que llama la función main. Por cada función se tiene una página. En la figura 4.6 se muestran los componentes que integran una página en formato RTF.

, ' ' 8 . , .. , I

. , . .

#(\footnote Main)

$(\footnote Main)

K(\footnote Main)

\par\b (Informaci6n de la funcion Main )

\pnr\tab (\uldb Cetop ) (\v gefop

\pnr\tab (\uldb Push ) (\vpush

/ í \ p a r i r n b (\uldb Alof ) (\t nfofi

Figura 4.6 Componentes de una página.

Algoritmo que recorre la lista de las funciones y con la .información de cada uno de los nodos crea el archivo rtf. Donde el nombre de la función es el nombre de la página, y cada nodo de la lista de las funciones a las cuales llama representa una liga a otra página con su información respectiva. Esto es una función tendrá tantas ligas como funciones llame.

void forma tabla - de-indices(inicio-lista) char IDENbO]; struct fun *inicio-lista; int cuenta; { if (inicio-lista !=NULL); {

inserta -en el archivoRTF(nombrede1a funcion) if (inicio-liGa->hijo != NULL )

I inserta-en-el-archivo-RTF(nombrede1afuncion) forma-tabla-de-indices(inicio-iista->herrnano) ;

1 if (inicio-lista->hermano !=NULL )

51

Desarrollo del Sistema GenDoc Capitulo 4

{

forma - tabla-de-indices(inici 1

inserta-elemento-en-el

inserta-en-el-archivo-RTF(nombredelafuncion)

if (inicio-lista->hijo==NULL)

1

4.2.2 Análisis del párrafo para cada función

Haciendo analogía entre el GenDoc y el Paradigma del libro. El código fuente ' correspondiente a cada una de las funciones que integran un programa, es lo que analógicamente correspondería a un párrafo de un capitulo que forma parte de un libro.

,aid main()

int numero,i,fact=l ;

printf("Dame el numero"); scanf( "%i",&numero);

if(numero >= 1) {

for(i=numero; i>=l; i--) fact=fact* i; printf("e1 factorial es: %O i",*..:t); getch0;

1 else printf("eror");

ilormacion sobre lafuncion main pode IhIuncion : void lumero de Pametins: O )ommenlo: nl numem. i. lad ;uin('W,6nunero] li (numero es mayoi o igual a l ) enlonces haz :idolor( i numero; ¡)=I:&] nd=lncil mpiime e lva lo idelnd ie Io contiario imonme error

Figura 4.1 muestra un ejemplo de código fuente escrito en Lenguaje "C' y su párrafo correspondiente.

52

Capítulo 4 Desarrollo del Sistema GenDoc

4.3 Módulo del diccionario de Datos(índice)

El diccionario de datos es una referencia de “datos acerca de los datos” recopilados por el analista de sistemas para guiarse durante el análisis y el diseño. Como documento, recopila, coordina y confirma lo que un termino especifico significa para la gente de la organización.

Los analistas de sistemas deben catalogar los diversos términos que se refieren al mismo dato. Esto evitará duplicar esfuerzos, favoreciendo una mejor comunicación entre los funciones o procedimientos del código fuente, y a la vez, facilitan el mantenimiento. El diccionario de datos sirve también como el estándar consistente de los datos elementales[KEN91].

4.3.1 Información que contiene el diccionario de datos

Una manera de saber lo que debe contener el diccionario de datos, es visualizar cómo llegará a utilizarse. El diccionario, es el elemento básico de referencia para localizar los nombres y atributos de los datos utilizados en todo el sistema de la organización. Es por esto que deberá incluir todos los datos sencillos; sin embargo, conviene visualizar cómo evoluciona la documentación. Mientras que un diccionario de datos pueda incluir numerosos elementos, nunca estará terminado. De hecho, deberá actualizarse cada vez que se hagan cambios, como ocurriría con cualquier otro tipo de documentación.

Para ser de utilidad, los registros del diccionario de datos deben contener información referente a las categorías siguientes:

1 .- El nombre y sinónimo del dato, 2.- Las descripciones del dato, 3.- Los datos elementales que se relacionan con el término 4.- El rango permitido del dato 5.- La longitud disponible en caracteres 6.- Una adecuada codificación 7.- Cualquier otra información pertinente de edición

A continuación se describen cada una de las categorías :

Nombres y sinónimos (alias)

El diccionario de datos debe contener el nombre de cada dato; esto es, la manera de denominar al dato en la mayoría de los programas. Diferentes programas pueden utilizar un vocabulario particular para datos sencillos comunes, de tal forma que el diccionario de datos debe contener el nombre mas común del dato, así como su sinónimo. Todo esto debe

53

Capítulo 4 Desarrollo del Sistema GenDoc

quedar registrado en el diccionario, para facilitar la comunicación y la referencia cruzada entre programas.

Descripción

El diccionario de datos debe incluir también una descripción textual del dato elemental, la cual debe ser concisa (aproximadamente 3 frases), pero informativa para cualquiera que la consulte.

Rango Permitido

Debe de incluir los distintos rangos y límites que se aplican al elemento.

Longitud del dato

El diccionario de datos debe incluir la longitud permitida para el acceso a un dato elemental de modo que no exceda a la longitud para la cual fue declarado, ejemplo si el dato es un arreglo de 10 caracteres la longitud máxima para los datos que se declaren de este tipo será de 1 O caracteres como máximo.

Información adicional de edición

La información requerida para asegurar la edición adecuada de los datos debe estar presente en el diccionario de datos, esto incluye cualquier orden pertinente.

Cuando un diccionario se integra de manera correcta, es útil para el desarrollo del sistema, su modificación y mantenimiento. Los diagramas de flujo de datos sirven como punto de partida para el diccionario de datos.

4.3.2 Uso del diccionario de datos

El diccionario de datos ideal se encuentra automatizado, y además es interactivo, en línea y evolutivo. Conforme el analista conoce más de los sistemas de la organización los datos se incorporan en el diccionario. Por otra parte el diccionario no será nunca un producto concluido. Para evitar el agobio para construir por completo un diccionario de datos el analista de sistema debe concebirlo como una actividad paralela al análisis y diseño de sistemas.

54


Aunque la tendencia se dirige hacia los diccionarios de datos automatizados en línea, es relevante apreciar la importancia de integrar (aún de manera manual) un diccionario de datos para un sistema.

Un diccionario de datos actualizado sirve como excelente referencia para el mantenimiento de sistemas poco familiares. Los diccionarios de datos automatizados sirven de referencia, para los desarrolladores de software.

4.3.3 Investigación sobre los elementos que debe contener un diccionario de datos

I 3

Grhfica I Muestra los resultados obtenidos de los cada atributos a considerar para los datos involucrados en el c6digo fuente a utilizar

Como ya se ha mencionado, un diccionario de datos sirve de guía para los programadores o ingenieros de mantenimiento cuando desean conservar sistemas con 10s que se encuentran poco familiarizados. El diccionario de datos es útil en todas la fases del análisis, el diseño y finalmente, en la documentación del sistema ya que es la fuente autorizada de cómo el sistema utiliza o define los datos elementales.

5 5

Capitulo 4 Desarrollo del Sistema GenDoc " ~ ~ ~

Así como cada programador tiene su propio estilo para desarrollar un sistema, de la misma manera tiene su propio concepto de los atributos que considera más importantes de considerar en el diccionario de datos. Por lo anterior se decidió realizar una entrevista (ver anexo 2) a una muestra de una población significativa.

Los resultados obtenidos de esta investigación se utilizaron para tomar la decisión de qué atributos se considerarían para el diccionario de datos que presenta como salida el generador de documentación automático.

4.3.4 Estructura utilizada para la generación del diccionario de datos

Para la generación del diccionario de datos del código fuente fue necesario crear una estructura de datos que sirviera para almacenar los atributos de los datos de un programa escrito en lenguaje C, manipular los tipos de datos y el alcance de los datos así como el tiempo de vida para cada dato. Para implenientar este módulo se utilizó la siguiente estructura de datos:

Una lista simplemente ligada para almacenar todas las variables: nombre, tipo, tiempo de vida y alcance correspondiente a cada tipo de dato y un apuntador hacia el nodo siguiente. En la figura 4.8 se muestra el modelo conceptual de esta estructura.

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

A continuacih se muestra la estructura de datos de la figura 4.8 definida en lenguaje de programación 'C',

struct dic { char nombre[25]; char tipo[ 1 O]; char alcance[] O]; char vida[lO]; struct dic *sig;

56

Desarrollo del Sistema GenDoc ^ _ ~

Capítulo 4 . . .

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)

alcance: Este campo sirve para almacenar el alcance de las variables utilizada por el código fuente. El alcance esta determinado por el lugar dentro de la estructura del programa en la que la variable fue declarada.

vida: Este campo sirve para almacenar el tiempo de vida de cada variable si la variable fue declarada como statica o automática.

El analizador del código fuente el cual fue descrito en la arquitectura del Gendoc en el capitulo 3 descompone en tokens y palabras reservadas el código fuente. Cuando reconoce una variable o dato io almacena en la lista ligada descrita en la figura 4.8, su tipo, en que función fue declarada y si fue declarada como automática o como statica. Y Para formar el diccionario de datos que despliega el Gendoc(véase en la figura 4.9) sólo recorremos la lista y desplegamos cada una de los campos de la lista simplemente ligada.

Olcclonarlo de Daws

TlpD Alcance I", Global I", Global / " I Global I", Global I", Global char Global char Global char Global I", Global I", Global I", LOOKUP void LOOKUP char LOOKUP I", LOOKUP char B N A S I", CAMBIOS

Figura 4.9 Muestra el diccionario de datos, sus variables y cada una de sus atributos

57

Capitulo 4 Desarrollo del Sistema GenDoc ~~~~ ~ ~. .-

4.4 Interfaz del Generador de Documentación

La interfaz del GenDoc (véase en la figura 4.10) cuenta con un menú. Cada opción de este menú tiene a la vez un submenú con diferentes opciones.

El menú principal cuenta con tres opciones Archivo, Editnr y Salir. En el caso de la opción del Archivo cuenta con las opciones de Hipertexto y Diccionario de datos.

La opción de Hiperfexto abre una caja de dialogo amodal para abrir el archivo que se desea desplegar, en forma de tabla de contenido utilizando la técnica del libro mencionada en el módulo del paradigma del libro, la navegación a través de las funciones que presenta el GenDoc es utilizando la técnica del hipertexto también mencionada en el módulo del libro.

La opción de diccionario de duros, abre una caja de dialogo amodal para abrir el archivo del cual se desea desplegar su diccionario de datos ( como se muestra en la figura 4.12).

El submenú Editar nos muestra un submenú, con la opción de Ver, ésta última nos despliega el código fuente. Con esta opción podemos tener dos aplicaciones en la ventana de edición al mismo tiempo, la ventaja de esta opción es que podemos ver nuestro código fuente y al mismo tiempo verlo en forma de tabla de contenido como se muestra en la figura 4.1 1, y podemos navegar a través de las funciones que integran al código fuente.

El submenú Salir nos permite salir de la aplicación y regresar a nuestra aplicación anterior

Figura 4.10 lnterfaz del GenCod

58

CapiNlO 4 Desarrollo del Sistema GenDoc ........ ._ ... .................. ..

Eile Background Editar

Si el resultado do la multiplication lambien y 1 sumado cond restado con5 se cumple entonces haz

convierieliio-numero:

Si el resullado de 1. suma I y O 80 cumple entonces haz

Los parametios son con sus respeclivos 1,pos Las funciones a las cuales llama son

a2IQe.D !yw¿w €Q!NB@

If[todo+ll

printfr' mlllon '1; (

1 trio=3; numcro=numero; Ilpamblcn"1 rd-5)

printfr' mil '1; 1

conviertc0; I trlo=numero; numero=trlo; real=numero; t,iO=,eBI; If[l+Ol I printfo; conviertco; getcho;

t void margen0

1;

igura 4.1 1. Código fuente escrito en lenguaje C (derecha) y código en forma de tabla de contenido (izquierda)

Archivo &ditu Salir

brchivo Editar Salir IPil " ....... .." .".." I I-., ." ..*.. ""I,., , 1"""1 ,*", ="."= "." .......... ........

Figura 4.12 Esta figura muestra el diccionario de datos que da como salida el GenDoc.

59

Capitulo 5 Evaluaci6n experimental

CAPÍTULO 5

EVALUACI~N EXPERIMENTAL

En este capitulo se establece la forma experimental con la cual se evaluó el desempeño del GenDoc definiendo variables dependientes e independientes, y señalando los factores que fueron evaluados.

60

Capitulo 5 Evaluación experimental

5.1 Muestre0

La muestra de la población que se consideró para esta prueba del GenDoc fueron 15 desarrolladores de software (de diferentes niveles expertos, y sin experiencia). El estudio O

prueba consistió en medir el tiempo requerido para dar mantenimiento a un programa de software tanto con la herramienta como sin ella, de tal forma que cada persona pudiese experimentar la dos formas de desarrollo. Se decidió no hacer una comparación midiendo en forma paralela el tiempo de dos desarrolladores con la utilización de la herramienta o sin ella, debido a que ésta forma de evaluación ocasionaría que el experimento estuviera afectado por demasiados factores externos, por ejemplo, la experiencia de los programadores en el lenguaje C, la capacidad de abstracción, razonamiento lógico, y otros factores de los sujetos a estudio, etc. La alternativa elegida fue permitir que un sujeto desarrollara un programa sin la herramienta, para posteriormente desarrollar un sistema de igual complejidad utilizando el GenCod, se pensó en no utilizar el mismo programa para ambas pruebas porque se daría el caso de que al utilizar la herramienta el sujeto ya estaría condicionado por el experimento previo.

El primer paso para evaluar el desempeño del GenDoc fue determinar tanto las variables dependientes como independientes que afectan el desempeño del sistema.

a) VARIABLE DEPENDIENTE: La variable a medir en el GenDoc es el tiempo de comprensión de un sistema en relación al tamaño del mismo.

VARIABLES INDEPENDIENTES: Las variables independientes son los dos métodos de desarrollo de sistemas a medir, el tradicional (sin utilizar un documentador automático) y el uso del GenDoc.

b)

5.2 Variables dependientes b

A continuación se describe cada y o de los factores que se utilizaron para medir el desempeño del sistema.

Tiempo de comprensión: Para este caso de estudio se consideró el tiempo que requiere un ingeniero de mantenimiento o cualquier persona que da mantenimiento a un sistema, para comprenderlo y por consiguiente la facilidad que ofrece el sistema GenDoc para seguir el flujo de datos par producir el diccionario de los datos del sistema .

5.3 Variables independientes

Como ya se mencionó anteriormente las variables independientes consideradas para este plan experimental es el método tradicional de comprensión de un código fuente que consiste en

61

Capitulo 5 Evaluaci6n experimental

utilizar el listado tradicional del código fuente o bien ir a revisar directamente el código fuente y el uso de la herramienta de documentación automática.

5.4 Hipótesis a comprobar:

El diseño del plan experimental tuvo como objetivo comprobar o refutar la hipótesis que se planteó al iniciar este trabajo de tesis:

El uso del GenDoc permite reducir el tiempo que se gastan los programadores en entender el código fuente, pues la comprensión es un papel crucial en la etapa del mantenimiento del software.

5.5 Pian de evaluación

Una vez diseñado el plan experimental, se trabajó con la muestra seleccic da ara obtener datos relevantes, los cuales fueron relacionados estadísticamente para observar el comportamiento entre las dos formas de comprender un código fuente: El método tradicional la utilización de un lista fuente y la utilización del GenDoc.

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. 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,, - Mmi,,.

Con la finalidad de obtener datos más exactos acerca de la dispersión de los datos entre sí, es necesario utilizar valores como la desviación media, la varianza y la desviación estándar. Estas medidas de dispersión fueron elegidas debido a que muestran que tan dispersos están los datos recuperados contra la media, lo cual da una idea del grado de error presente en cada sistema de recuperación.

A continuación se describe el significado de cada uno de estos valores y las fórmulas que las calculan:

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

62


Desviación media: Es el promedio del valor absoluto de las desviaciones.

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

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

-63


5.6 Análisis de resultados

Primeramente se calcularon los valores de dispersión para el (tiempo de desarrollo) con programas de 121 líneas de código (ver anexo 3). La tabla 5.1 muestra los datos relativos al desarrollo de un sistema de código sin utilizar la Iierramienta.

Tabla 5.1 Información para calcular la medida de dispersión para el tiempo dedicado a comprender un c6digo fuente sin utilizar el GenDoc.

- 192,6 2889 x=-- -

15

677.6 15

DM=- = 45.17

63701.6 15

s = = 4246.77

S = kJ637016 = 65.16

64

Capitulo 5 Evaluaci6n experimental . - . -- .. - . - . . . ~. . ~

.. .

Posteriormente se calculan los valores relativos al entendimiento de un sistema de código utilizando la herramienta. (tabla 5.2).

Tabla 5.2 Información para calcular la medida de dispersión para el tiempo dedicado a comprender un código fuente utilizando la herramienta GenDoc.

= 142.06 2131 X=--

15

= 3 2 . 3 8 485.82 15

DM =

32133.92 15

S = = 2142.26

S = fJ2142.26 = k46.28

En resumen, de las dos gráficas tenemos la siguiente comparación:

65

Evaluaci6n experimental Capitulo 5

concepto

Tiempo promedio invertido en las pruebas. Desviaci6n media de los datos. Varianza de los datos Desviaci6n estándar de

comprensi6n de un código fuente de 121 lineas sin fuente de 12 1 lineas utilizar la herramienta

GenDoc GenDoc. 192.6 142.06

45.17 32.38

4246.11 2142.26 65.16 46.28

Comprensi6n de un c6digo

utilizando la herramienta

Tabla 5.3 Resumen comparativo de tiempo de comprensi6n de un código fuente sin utilizar la herramienta GenDoc y utilizando la herramienta GenDoc.

La tabla 5.3 comprueba la hipótesis que afirma que e l sistema de documentación automática de código fuente escrito en C (GenDoc) es verdadera, ya que se puede concluir que si el uso de la herramienta GenDoc reduce el tiempo que gastan los programadores al tratar de comprender los sistemas, el porcentaje de reducción de tiempo al utilizar el GenDoc es 26.24% en la comprensión de programas de 121 líneas de código, lo cual representa una disminución considerable.

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

66

Conclusiones

CONCLUSIONES

En esta sección se describen los alcances logrados en este trabajo. Se proponen algunas recomendaciones a éste, se da un panorama de los trabajos futuros relacionados con el GenDoc.

67

Conclusiones

1 Alcances Logrados

Los resultados arrojados en la evaluación experimental, que se aplicó al presente trabajo y el cual fue descrito en el capítulo 5 permite llegar a las siguientes conclusiones:

- El organizar el código fuente utilizando el paradigma del libro. Además de un sistema de navegación como lo es el hipertexto nos permitió seguir el programa fuente a través de guías, palabras claves o planes. Lo anterior nos ayuda a la comprensión del código fuente en el fase del mantenimiento de los sistemas.

- Contar con un diccionario de datos de las variables utilizadas en el código fuente nos ofrece un documento que ayuda en la comprensión o seguimiento en la fase del mantenimiento de sistemas.

- El GenDoc nos ofrece la documentación de cada una de las funciones que componen al código fuente escrito en lenguaje C. La documentación consiste en mostrar el número de parámetros de la función, cada uno de los parámetros, el tipo de la función y el tipo de cada uno de los parámetros, el nombre, las variables locales a cada función y un pequeño texto descriptivo de las sentencias condicionales, de iteración, y de decisión múltiple. Todo lo anterior con la finalidad de ayudar a los Ingenieros de mantenimiento o a los mismos desarrolladores del software a la comprensión del código fuente que se dio como entrada.

2 Mejoras y trabajos futuros

Este trabajo de tesis es el resultado del primer intento de la generación de una herramienta que apoye a los desarrolladores de software o a los ingenieros de mantenimiento en la comprensión del código fuente al dar mantenimiento a los sistemas. Pero como se especificó en los alcances, está limitado. En esta sección presentaremos las tendencias más importantes en la documentación de los sistemas que ayuden al mantenimiento de los sistemas.

La primer limitación es que el GenDoc solo documenta programas escritos en lenguaje C, con esto se logra que este trabajo cumpliera con el objetivo general. Se propone que la herramienta acepte como entrada código escrito en otros lenguajes pero que cumpla con la misma filosofia del lenguaje C.

El presente trabajo toma como guías para navegar a través del código fuente a las funciones con sus respectivas llamadas. Un trabajo futuro sería que se le permitiera al usuario escoger a través de que palabra clave o que guía desea navegar en el sistema pudiera ser a través de los parámetros, de variables o bien a través de módulos.

68

Conclusiones

Que le permita al usuario agregar texto a la documentación o bien modificar la documentación que da como resultado el GenDoc.

69

Bibliografia -

Bibliografía

[CHA88] R. Charette. “Software Engineering Environments”. Addison-Wesley, 1988.

[CHI901 Chikofsky Elliot J. and James H. Cross 11. “Reverse Engineering and Design Recovery: A Taxonomy” .IEEE Software, 1990.

[FA1901 Richar E. Fairley “ Ingenieria de Software”, Editorial McGraw-Hill, Enero 1990.

[JEN80] R. Jensen, C. Tonics. “Software engineering. New York, N.Y. Politechnic Press, 1980.

[JOS78] Josephs, W., “A Mini-Computer Based Library Control System “, Proceedings of the software Quality and Assurance Workshop, ACM Software engineering Notes, vol 3, no. 5 , November 1978.

[KEN881 Kenneth E. Kendall, Julie E. Kendall ‘‘ Analisis y Diseño de Sistemas”, Editorial Prentice- Hall 1988

[LAN881 L.D. Landis / P.M. Hyland / A.L. Gilbert / A.J. Fine “ Documentation in a software maintenance enviroment” . IEEE , The Institute of electrical nad Electronics Engineers, 1988.

[LOR941 Lorge Pamas David, “precise Documentation of Well- Structured Programas” IEEE Transactions on software engineering, Diciembre 1994.

[MOL931 K.H. Moller. D. J. Paulish. “Software Métrics: A practitioner’s Guide to Improved Product Development”. IEEE PRESS, Chapman & Hall, IEEE Computer Society Press. 1993.

pIE90] Jakob Nielsen, “Hipertext and Hipermedia”, Academic Press, Inc. 1990

[PAU90] Paul W. Oman / Curtis R. Cook “ The book Paradigm for Improved Maintenance” IEEE Software, January 1990.

[PRE88] Pressman, R., “Software Engineering. A practitioner’s Approch”. Second Edicion, McGraw-Hill Book Company, 1988.

[PRE93] Pressman, R., Ingeniería del software, un enfoque práctico, 3a. edición, Mc Graw Hill, España 1988.

70

Bibliografia

[WAY941 Wayt Gibbs. “Software’s Chronic Crisis”. Scientific American, September 1994, pp. 72-81,

[WON951 Wong Kenny, Scott R. Tilley, Hausi A. Muller, and Margaret- a m e D. “ Structural Redocumentation : A Case Study”, IEEE software, January 1995.

71

Anexo 1 Información sobre los archivos de Hipertexto

El ambiente de programación Windows nos ofrece muchas ventajas para la creación y manejo de hipertexto, por medio de compiladores que trasladan un archivo de texto escrito en un archivo con extensión .HLP, el cual puede ser leído por el usuario que se encuentra en al ambiente Windows. Dichos compiladores de ayudas (hcc3l.exe 0 helpmake.exe ambos proporcionados por los ambientes de programación Windows) trasladan los comandos del archivo de texto en información para el lector de ayudas. La unidad básica de un archivo Help es la base de datos, Una base de datos es un archivo individual creado por un compilador de ayudas (hc31 .exe o helpmake.exe).

El uso de un mecanismo de este estilo permite insertar gráficos en el archivo de ayuda, estos pueden ser colocados y desplegados en cualquier sitio de la pagina, incluso pueden aparecer a continuación de un gráfico.

Existen tres principales formatos para codificar archivos fuentes para las compiladores de ayudas : RTF (Rich Text Format), Quick Help y Minimally formatted ASCII.

Rich Text Format (RTF): Rich Text format es un formato de Microsoft utilizado pos los procesadores de palabras, el cual es soportado por varios procesadores, incluidos Microsoft Word versión 5.0 y posteriores, Microsoft Word para Windows, Word Perfect, etc. RFT es un formato intermedio que permite que los documentos puedan ser transferidos entre aplicaciones sin necesidad de perder su formato. Los archivos RTF contienen atributos y ligas formateados con una sintaxis especial. El formato de los archivos RTF esta formado por un conjunto de sentencias, las cuales aparecen a continuación con una breve descripción de cada una de ellas:

\ami \b \bin \bmc \bml \bmr \box \brdrb \brdrbar \brdrdb

\brdrl \brdrr \brdrs \brdrt \cell \cf

Especifica que de utilizara el conjunto de caracteres ANSI Utiliza el tipo de texto Bold. Especifica el uso de datos binarios asociados a un dibujo. Despliega un Bitmap Despliega un Bitmap o metafile en el margen derecho Despliega unBitmap o metafile en el margen izquierdo Dibuja un cuadro Dibuja los bordes de un botón Dibuja una barra vertical Dibuja bordes utilizando líneas dobles

Dibuja un borde izquierdo Dibuja un borde derecho Coloca los bordes estándares. Dibuja un borde superior Marca el final de una celda Coloca el color del fondo.

\colortbl Crea una tabla de colores

12


\deff \f \fldrslt \fonnbl \footnote \fs \Y \li \line \mac \page \par \PC \pich \picscalec \picscaley

\sect \SI

\strike \tab

\tqr \trgaph

\tqc

\tx \u1 \uldb \V

\wbitmap

\wbmbitspixel \wbmwidhbytes \metafile

Coloca los tipos de letras establecidas. Coloca un tipo de texto Resultado de un campo Crea el tipo de letra para una tabla Define un tópico especifico de información Coloca el tamaño de texto Inicializa el texto itálico Coloca un identador a la izquierda Rompe la linea actual Activa el conjunto de caracteres Apple Macintosh Termina un tópico Marca el final de un párrafo Activa el conjunto de caracteres PC Especifica el alto de una Imagen Especifica el valor de escalación horizontal Especifica el valor de escalación vertical

Crea una imagen Especifica el tamaño de una imagen Centra texto Justifica el texto a la izquierda Justifica el texto a la derecha coloca un identador a la derecha Marca el final de una línea en una tabla Especifica la versión del RTF

Marca el final de una sección o párrafo Coloca espacios entre líneas Crea un hotspot Inserta un carácter tab Coloca un tab y centro el texto Coloca un tab y justifica el texto a la derecha Coloca espacios entre texto y columnas en una tabla

Coloca tab stop en el texto Crea una liga hacia un tópico Crea un hot spot Crea una liga hacia un tópico Especifica un bitmap de Windows

Especifica el numero de bits por pixel Especifica el tamaño de un bitmap en bytes Especifica un metafile en Windows

73


Una de las sentencias mas utilizadas en el Generador de Documentación automática fue el footnote, por lo anterior se presenta una breve descripción:

La sentencia \footnote sirve para definir tópicos específicos de información, tales como las cadenas de contexto, los títulos, palabras clave, y macros de ejecución. Cada tópico debe tener una cadena de contexto para dar acceso al usuario para accesar el tópico a través de ligas.

La sintaxis de esta sentencia en la siguiente:

{n} {\footnote {n} text}

Parámetro Descripción

' n Especifica el carácter del footnote. Este campo puede tomar los siguientes valores:

Valor Significado

# Especifica una cadena de contexto. El texto puede ser la combinación de letras y dígitos, pero sin contener espacios en blanco. No existe distinción entre mayúsculas y munisculas ya que son tratradas como equivalentes. La cadena de contexto puede ser usada con la sentencia \v en otros tópicos para crear una liga hacia este tópico.

$ Especifica el titulo o nombre del tópico. Windows Help usa el titulo del tópico para identificar el tópico en las cajas de dialogo de Search e History. El texto que se incluye en esta sección puede ser una combinación de caracteres, incluido el espacio en blanco.

K Especifica una palabra clave. Windows Help despliega todas las palabras clave contenidas en el archivo de hipertexto por medio de la caja de dialogo de Search y permite al usuario elegir un tópico para observar por medio de la elección de una palabra clave. El texto contenido en esta sección puede ser una combinación de caracteres, incluido el espacio en blanco. Si el primer carácter es la letra K, a esta le debe de seguir un espacio extra o un apóstrofe.

! desplegado.

text Especifica la cadena de contexto, el titulo del tópico, palabras clave, o macros asociadas con el footnote. Este parámetro depende del tipo de footnote especificado en el parámetro n.

Especifica una macro. Windows Help ejecuta las macros cuando el tópico es

74

Cuestionario Anexo 2

Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET)

CUESTIONARIO

Dado el listado del código fuente X.c escrito en lenguaje C.que se anexa a este cuestionario. Contesta las siguientes preguntas.

De manera breve describe en funcionamiento de código fuente X.C.

Consideras que contar con un diccionario de datos de las variables utilizadas así como de sus atributos, te hubiera auxiliado en la comprensión del código fuente.

si: - no:- ¿por qué?

Si la respuesta fue afirmativa contesta las siguientes preguntas:

¿Consideras importante incluir en un diccionario de datos el nombre de la variable?

no o si 0 ¿Consideras importante incluir una breve descripción de la vaiiable?

si

¿El rango de lavariable?

si 0 no o

75

Anexo 2 ~ ~ ~ -

¿La longitud de la variable?

si u ¿El alcance de la variable?

si 0 ¿El tipo de la variable?

si u

no u

¿El tiempo de vida de la variable?

si o ¿Otro atributo ?

si u

Cuestionario -

Si la respuesta fue afirmativa anexa el atributo. Explica los motivos

/* código fuente X.c */ #include <stdio.h> #include <string.h>

void digitos(int); void decenas(int);

char resultado[lO]; void main() t int numero; char resp[2]; strcpy(resp,"si"); while((strcmp(resp,"si")==O) 11 (strcmp(resp,"SI")==O))

t 76

Cuestionario Anexo 2 ... . . ~ ~~ ~ ~

{ strcpy (resultado,'"'); printf("%s","Dame el numero de entrada"); scanf ("%i",&numero); if(numero>O && numero4 O) { digitos(numer0); I

else if (numero>=lO) i decenas(numer0); }

else {

I printf("%s","Dato fuera de rango");

printf("%s",resultado); printf("%s":"Deseas continuar"); scanf("%s",resp);

1 }

void digitos(numer0) int numero; { switch(numero) { case 1 :

strcat(resultado,"I");

break;

strcat(resultado,"II"); break;

strcat(resultado,"III"); break;

strcat(resu1 tado,"IV"); break;

strcat(resultado,"V"); break;

case 2:

case 3:

case 4:

case 5:

1

Cuestionario ~ ~~ ~ ~

Anexo 2 . ..

case 6: strcat(resultado,"VI"); break;

strcat(resultado,"Vil"); break;

strcat(resultado,"VIIi"); break;

strcat(resultado,"IX"); break;

case 7:

case 8:

case 9:

1 1

void decenas(numer0) int numero;

int res,dec;

dec=numero/l O; res=numero % 1 O; cwitch(dec)

c

{

case 1: strcat(resu1 tado,"X"); break;

strcat(resultado,"XX"); break;

strcat(resultado,"XXX"); break;

strcat(resultado,"XL"); break;

strcat(resultado,"L"); break;

strcat(resu1 tado,"LX"); break;

strcat(resultado,"LXX"); break;

case 2:

case 3:

case 4:

case 5:

case 6:

case 7:

78

Anexo 2 Cuestionario . . . .... ~ . . ~ ~

case 8: strcat(resultado,"LXXX"); break;

case 9: . strcat(resui tado, "XC ");

break; 1 f if (res>O) digitos(res);

1

79

Anexo 3 Cuestionario

CUESTIONARIO

Dado el listado del código fuente X.c escrito en lenguaje C que se anexa a este cuestionario. Contesta las siguientes preguntas.

De manera breve describe en funcionamiento de código fuente X.c

Cuanto tiempo te tomo comprender el funcionamiento del código fuente (en minutos).

tiempo de inicio: tiempo final:

Tuviste que auxiliarte de alguna otra técnica (diagrama de flujo, Nassi-Schneiderman. diagrama de Warnier, pseudocódigo, pruebas de escritorio, etc)

si U no u

Cuantos intentos tuviste que realizar para comprenderlo, de tal manera que pudieras realizar alguna modificación.

uno-tres intentos cuatro-seis intentos 0 mas de sies intentos 0

80

Cuestionario .___

Anexo 3 .. . .. ...

#include <stdio.h> #include <string.h>

void digitos(int); void decenas(int);

char resultado[lO]; void main() { int numero; char resp[2]; strcpy(resp,"si"); whiIe((strcmp(resp,"si")==O) 11 (strcmp(resp,"SI")==O)) { strcpy (resultado," "); priiitf("%s","Dame el numero de entrada"); scanf ("%¡",&numero); if(numero>O && numero<l O) { digitos(numero); }

else if (numero>=lO) { decenas(numer0); 1

else t

printf("%s","Dato fuera de rango"); 1

printf("%s".resultado); printf("%s","Deseas continuar"); scanf("%s",resp);

I

void digitos(numer0) int numero; { switch(numer0) 1 case 1:

strcat(resultado,"I");

81

Anexo 3 Cuestionario . . . . . . ~. . .. .- .

break;

strcat(resultado,"II"); break;

strcat(resultado,"III"); break,

strcat(resultado,"IV"); break,

strcat(resultado,"V"); break;

strcat(resultado,"VI"); break;

strcat(resultado,"VII"); break;

strcat(resultado,"VIII"); break;

strcat(resultado."IX); break;

case 2:

case 3:

case 4:

case 5 :

case 6:

case 7:

case 8:

case 9:

1

void decenas(numer0) int numero; { int res,dec;

dec=numero/lO; res=nurnero Yo 1 O; switch(dec) t case 1:

strcat(resultado,"X"); break;

strcat(resultado,"X")~ break;

case 2:

case 3:

82

Anexo 3 ... ~

.. -. ~ ~.~ .._.. ..

strcat(resultado,"XXX"); break;

strcat(resultad0,"XL"); break;

strcat(resultado,"L"); break;

s trcat(resultado,"LX"); break;

strcat(resultado,"LXX"); break;

strcat(resultado,"LXXX"); break;

strcat(resultado,"XC"); break;

case 4:

case 5 :

case 6 :

case 7:

case 8:

case 9:

1 if (res>O) digitos(res);

}

83

CENTRO NACIONAL DE INVESTIGACIÓN Y … Leticia Santa... · grado de Maestro en Ciencias de este...

Documents

Transcript of CENTRO NACIONAL DE INVESTIGACIÓN Y … Leticia Santa... · grado de Maestro en Ciencias de este...