tecnicas de documentacion

SEP SEIT DGIT

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO

cenidet

“GENERADOR DE CODIGO PARA LENGUAJE C UTILIZANDO UNA NOTACION

DE DISEÑO DETALLADO”

T E S I S QUE PARA OBTENER EL GRADO DE:

MAESTRO EN CIENCIAS EN CIENCIAS

C O M P U T A C I O N A L E S

P R E S E N T A

ALICIA MARTINEZ REBOLLAR

CUERNAVACA, MORELOS AGOSTO DE 1997

GENERADOR DE CÓDIGO PARA LENGUAJE C UTILIZANDO UNA NOTACIÓN DE DISEÑO DETALLADO

Tesista: Alicia Martínez Rebollar Asesor: Máximo López Sánchez

RESUMEN Este tema de tesis trata de resolver uno de los problemas que se presenta en el ciclo de vida del software: la falta de interés por parte de los desarrolladores en la fase de diseño detallado en el ciclo de vida del software[YOU92]. Este problema se intentó resolver con un sistema de software que automatiza la etapa de diseño detallado, generando el código acorde al diseño en el lenguaje de programación C. Pretendiendo con esto, ahorrar tiempo en la etapa de diseño, ya que las revisiones y correcciones de un sistema de software serán mucho más rápidas. La automatización de la fase de diseño detallado se realizó de una manera visual (se empleó el paradigma de la programación visual), formulando una gramática posicional con los elementos de la notación de diseño (se utilizó la metodología Warnier), así como su implantación en el lenguaje de programación C para Windows. Los resultados que se obtuvieron fueron: 1. formulación e implantación de una gramática posicional de la notación de diseño detallado de Warnier. 2. construcción de un analizador sintáctico y semántico de la gramática, 3. el sistema permitir realizar diseños (que sólo utilicen las construcciones básicas de la notación) sin conocer el lenguaje de programación C. Además de almacenar los diseños del usuario en disco. 5. el sistema permite generar código en lenguaje C acorde al diseño detallado elaborado por el usuario. 4. el sistema cuenta con ayudas de hipertexto. [YOU92] Edward Yourdon “Decline & Fall of American Programmer”. 1992 by PTR Prentice Hall, inc.

A DIOS, por darme la vida...

A mi MADRE a quien debo todo lo que soy...

A mis hermanos por todo su apoyo...

A mis cuñados, por ser como son ...

A mi sobrinos por sus risas y alegrías...

A mi esposo Hugo, porque eres todo lo que necesito para ser feliz, Gracias mi amor, TE AMO...

AGRADECIMIENTOS

A mi esposo Hugo Estrada Esquivel porque gracias a su apoyo y ayuda incondicional he logrado alcanzar esta meta. Agradezco a mi Asesor M.C. Máximo López Sánchez por su apoyo, orientación y tiempo dedicado para lograr mucho más de lo que nos propusimos, y sobre todo, por su amistad. Expreso mi más sincero agradecimiento al Centro Nacional de Investigación y Desarrollo Tecnológico por darme la oportunidad de cursar mi maestría en computación. Reconozco y agradezco el apoyo económico brindado por (CONACYT) para lograr la terminación de mis estudios de maestría. Agradezco al Dr. Javier Ortiz Hernández por toda la ayuda y palabras de aliento que siempre me ha brindado, además gracias por tu amistad. Agradezco al M.C. René Santaolaya Salgado y M.C. Olivia Fragoso Por la ayuda y orientación brindada, y sobre todo por su amistad. Agradezco al grupo de Ingeniería de Software (Hugo Estrada, Carpio Tovilla, Leticia Santa Olalla, Eurí Salgado, Teresa Chamú (por tu gran ayuda en esta tesis), Carlos de la Cruz, Susana, Mirna, Liliana y Marco Aurelio) por los buenos y malos momentos, y sobre todas las cosas, gracias por que juntos hemos salido adelante. Agradezco a todos mis profesores del cenidet por sus conocimientos brindados. Agradezco a los profesores el Dr. Guillermo Rodríguez, al M.C. Felipe Alaniz y al Dr. Rodolfo Pazos Rangel y M.C. Máximo López Sánchez porque con sus comentarios y correcciones hicieron un mejor trabajo. Agradezco al M.C Manuel Juárez y al M.C. J. Luis Ramírez y Verónica Sotelo por su poyo, amistad y sobre todo, por ser como son. Agradezco a mis compañeros de generación Hugo Estrada, Mario Flores, Víctor García, Eurí Salgado, Zulma Sánchez y William Zapata; a todos ellos, gracias por su amistad. Agradezco al grupo de bases de datos distribuidas (Anastacio, José Antonio, Miguel Mastache y Claudia Ibarra)

DEDICATORIAS

A DIOS Por darme la vida, permanecer siempre a mi lado y quererme tanto.

Dedico este trabajo con todo mi amor y respeto a una gran mujer que toda la vida ha permanecido a mi lado,

dándome todo lo mejor de ella: MI MADRE.

Al recuerdo de mi padre, que está presente en todo momento.

A MI ESPOSO Hugo Estrada Esquivel por ser todo mi mundo. Y con quien deseo

compartir todos los momentos de mi vida. TE AMO.

A MIS HERMANOS María del Rosario, Miguel Angel, Lucio y Ervin por su apoyo moral y

económico que me han brindado a lo largo de toda mi carrera.

A MIS CUÑADOS Octavio y Celia por hacer tan felices a mis hermanos

además por ser como son.

A MIS SOBRINOS Mayra, Daniela y Erick porque con su cariño y

alegría me han hecho muy feliz.

i

TABLA DE CONTENIDO

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

v

Capitulo 1 INTRODUCCION A LA INGENIERIA DE SOFTWARE.......................................................................................

1

1.1 Introduccion a la Ingenieria de Software................................................................... 2 1.2 Ciclo de vida clásico.................................................................................................. 2 1.3 Diseño de software..................................................................................................... 4 1.3.1 Diseño de datos................................................................................................. 5 1.3.2 Diseño arquitectónico........................................................................................ 5 1.3.3 Diseño procedimental........................................................................................ 5 1.4 Importancia del diseño............................................................................................... 6 Capitulo 2 PLANTEAMIENTO DEL PROBLEMA.................................. 8 2.1 Descripción del problema.......................................................................................... 9 2.2 Alternativas de solución............................................................................................. 10 2.2.1 Objetivo de la tesis............................................................................................ 10 2.2.2 Beneficios de la tesis........................................................................................ 11 2.3 Investigación sobre la utilización de las notaciones de diseño.................................. 12 2.3.1 Gráfica de tendencias de las notaciones de diseño más conocidas................... 12 2.3.2 Gráfica de tendencias de las notaciones de diseño más utilizadas.................... 13 2.3.3 Representación gráfica (porcentajes) de las notaciones de diseño más utilizadas...........................................................................................................

14

2.4 Resultados obtenidos de la investigación................................................................... 15 2.5 Notaciones de diseño.................................................................................................. 16 2.5.1 Pseudocódigo.................................................................................................... 16 2.5.2. Diagramas de flujo........................................................................................... 16 2.5.2.1. Construcciones básicas........................................................................ 17 2.5.3 Jackson............................................................................................................. 18 2.5.3.1 Construcciones básicas......................................................................... 18 2.5.4 Nassi/Shneiderman (N-S)................................................................................. 19 2.5.4.1 Construcciones básicas........................................................................ 19 2.5.5 HIPO (Hierachy/Input/Process/Output).......................................................... 20 2.5.6 Diagramas de Warnier....................................................................................... 21 2.5.6.1 Simbología........................................................................................... 21 2.5.6.2 Construcciones básicas......................................................................... 22 2.6 Comparaciones entre las notaciones de diseño.......................................................... 23 2.7 Notación de diseño detallado elegida......................................................................... 25

ii

Capitulo 3 CONCEPTOS DE PROGRAMACION VISUAL..................

26

3.1 Introducción............................................................................................................... 27 3.2 Conceptos de programación visual............................................................................ 27 3.3 Una taxonomía de iconos........................................................................................... 28 3.4 Programación visual................................................................................................... 30 3.5 Lenguaje visual Vs. textual........................................................................................ 31 3.6 Estado del arte............................................................................................................ 31 3.6.1 Visual Magic..................................................................................................... 31 3.6.2 Generador de ambientes visuales (VLCC)........................................................ 32 3.6.3 Microstep .......................................................................................................... 32 Capitulo 4. DESCRIPCION DE LA GRAMATICA DEL GENCOD..

33

4.1 Antecedentes.............................................................................................................. 34 4.2 Esquema Conceptual del GenCod.............................................................................. 36 4.3 Un lenguaje gráfico para la representación de una notación de diseño......................

37

4.3.1 Notación de diseño detallado modificada........................................................ 39 4.4 Algunas Ventajas que ofrecen las gramáticas............................................................ 41 4.4.1 Convención de la notación de la gramática....................................................... 42 4.5 Descripción de una gramática ................................................................................... 43 4.5.1 Símbolos no terminales..................................................................................... 43 4.5.2 Símbolos terminales.......................................................................................... 43 4.5.3 Símbolo inicial.................................................................................................. 45 4.5.4 Reglas de producción........................................................................................ 45 4.5.4.1 Relaciones Cuádruples de identificadores (POS)................................. 46 4.5.4.1.1 Relaciones Cuádruples de los símbolos terminales de la grámática ......................................................................

47

4.5.4.2 Atributos de los objetos......................................................................... 49 4.5.5 Evaluador pictográfico...................................................................................... 50 4.6 Estructura de Datos que maneja el GenCod............................................................... 50 4.6.1 Estructura de datos de la lista de objetos.......................................................... 51 4.6.2 Estructura de datos de la lista de Argumentos.................................................. 53 4.6.3 Estructura de datos del arreglo de listas............................................................ 54 4.7 Interfaz gráfica implantada en el sistema GenCod.................................................... 56 4.7.1 Interfaz con múltiples documentos (MDI)........................................................ 56 4.7.2 Interfaz del GenCod.......................................................................................... 57

iii

Capitulo 5. DESARROLLO DEL SISTEMA................................................

60

5.1 Desarrollo interno del diseño detallado...................................................................... 61 5.1.1 Definición dirigida por la sintaxis..................................................................... 63 5.1.2 Análisis en el desarrollo de un diseño y ubicación de los objetos en la pantalla..............................................................................................................

64

5.1.2.1 Ubicación del primer objeto en la pantalla........................................... 66 5.1.2.2 Ubicación de un objeto en la pantalla de un objeto activo.................... 67 5.1.2.3 Ubicación de un objeto en la pantalla después de un objeto pasivo..... 69 5.1.2.4 Ubicación de un objeto en la pantalla después del objeto FIN............. 69 5.1.2.5 Ubicación del objeto activo hacer-mientras <condición> y hacer <condición > mientras...........................................................................

71

5.1.3 Inserción de objetos........................................................................................... 73 5.1.3.1 Inserción entre niveles (de mayor a menor abstracción)....................... 75 5.1.3.2 Inserción entre niveles (de menor a mayor abstracción)...................... 77 5.1.3.3 Inserción entre objetos (en el mismo nivel).......................................... 78 5.1.3.4 Inserción entre niveles (de mayor a menor abstracción) cuando se desea hacer la inserción antes del objeto Mientras condición o hacer-Mientras condición......................................................................

79

5.1.3.5 Ubicación de los objetos después de la inserción................................. 80 5.1.4 Ajuste de los objetos en el diseño..................................................................... 81 5.1.4.1 Estructura de datos de la lista temporal (que realiza el ajuste de las coordenadas de los objetos activos)......................................................

83

5.1.5 Eliminación de objetos...................................................................................... 83 5.1.6 Generador automático de código...................................................................... 86 5.1.6.1 Manejo de la estructura de datos para la generación de código........... 86 5.1.7 Arquitectura del archivo de diseño................................................................... 89 5.1.8 Herramientas del GenCod................................................................................. 90 5.1.8.1 Navegación entre funciones.................................................................. 90 5.1.8.2 Ayudas por hipertexto........................................................................... 91 Capitulo 6 DISEÑO DE UN PLAN EXPERIMENTAL.............................

92

6.1 Muestreo..................................................................................................................... 93 6.2 Variables dependientes............................................................................................... 94 6.3 Variables independientes........................................................................................... 94 6.4 Hipótesis a comprobar................................................................................................ 94 6.5 Plan de evaluación...................................................................................................... 94 6.6 Análisis de resultados................................................................................................. 96

iv

Capitulo 7 COMENTARIOS FINALES........................................................ 100 7.1 Alcances logrados...................................................................................................... 1017.2 Mejoras y ampliaciones a este trabajo....................................................................... 1027.3 Trabajos futuros......................................................................................................... 103 Referencias.................................................................................................................. 104Anexo 1. Cuestionario............................................................................................. 106Anexo 2. Reglas de producción de la gramática visual............................. 107Anexo 3. Diagrama de transición de estados para la declaración de una variable o un arreglo....................................................................

109

Anexo 4. Formato del archivo de diseño........................................................... 110Anexo 5. Demostración de la ejecución del GenCod.................................... 112

v

LISTA DE FIGURAS No. Fig. Descripción Pág. 1.1 Modelo de cascada del ciclo de vida del software 3 1.2 Importancia del diseño 6 2.1 Metodologías de diseño detallado más conocidas 13 2.2 Cuadro de frecuencia de las notaciones de diseño 13 2.4 Metodologías de diseño más utilizadas 14 2.4 Uso de las metodologías de diseño entre los desarrolladores 15 2.5 Construcciones en diagramas de flujo 17 2.6 Estructuras básicas del método de Jackson 18 2.7 Los tres símbolos gráficos utilizados para dijar los diagramas de

Nassi-Schneiderman 19

2.8 Tabla visual de contenido para un paquete HIPO 20 2.9 Simbología utilizada para los diagramas de Warnier 21 2.10 Construcciones básicas de los diagramas de Warnier 22 3.1 Una taxonomía de iconos 28 4.1 Esquema conceptual por capas del AMASS-I 35 4.2 Esquema conceptual del GenCod 36 4.3 Principio de la organización jerárquica 38 4.4 Tabla que muestra las modificaciones hechas a la notación de

diseñode Warnier en la secuenciación 39

4.5 Tabla que muestra las modificaciones hechas a la notación de diseño de Warnier en la bifurcación.

40

4.6 Tabla que muestra las modificaciones hechas a la notación de diseño de Warnier en la repetición

41

4.7 Conjunto de símbolos no terminales 43 4.8 Conjunto de símbolos terminales 44 4.9 Tabla de símbolos gráficos con su subíndice asociado dependiendo

del significado 44

4.10 Ejemplo de una regla de producción 46 4.11 Estructura de datos del GenCod 51 4.12 Modelo conceptual de los nodos de la lista de objetos 51 4.13 Tabla de identificadores para el número de instrucciones 52 4.14 Modelo conceptual de los nodos de la lista de variables 54 4.15 Modelo conceptual de los nodos del arreglo de listas 55 4.16 Autómata empleado en el GenCod 56

vi

4.17 Editor de un programa MDI 57 4.18 Interfaz del GenCod 58 5.1 Caja de dialogo que pide la información de una función del sistema

GenCod 61

5.2 Caja de dialogo que impide dar nombres inapropiados a las funciones 61 5.3 Caja de dialogo que forza definir el tipo de una función 62 5.4 Caja de dialogo de la declaración de los parámetros de una función 62 5.5 Cajas de dialogo para controlar el nombre y tipo de cada variable 63 5.6 Ejemplo del análisis en la inserción de un objeto en el diseño 65 5.7 Ejemplo de un error en el análisis con la inserción del objeto else 66 5.8 Ejemplo de una función con tres funciones anidadas 67 5.9 Coordenadas del primer objeto del diseño 68 5.10 (a) Muestra la obtención de las coordenadas de la izquierda de un

objeto insertado después de un objeto activo, (b) Muestra la obtención de las coordenadas de arriba del mismo objeto

68

5.11 Muestra la obtención de las coordenadas abajo y derecha de un objeto insertado

68

5.12 Muestra la inserción de un objeto en el mismo nivel de abstracción 69 5.13 Muestra la obtención de las coordenadas de arriba de un objeto

insertado en un nivel de abstracción mayor 70

5.14 Muestra la obtención de las coordenadas de la izquierda de un objeto insertado en un nivel de abstracción mayor

70

5.15 Muestra la obtención de las coordenadas de arriba del objeto while 71 5.16 Muestra la obtención de las coordenadas de arriba e izquierda del

objeto scanf 72

5.17 (a) Muestra la obtención de las coordenadas de la izquierda del objeto scanf (b) Muestra la obtención de las coordenadas de arriba del objeto

73

5.18 Comparación de las coordenadas obtenidas por el mouse contra los objetos que integran el diseño

74

5.19 Inserción de un objeto después de una función. 75 5.20 Pantalla de comparación de las coordenadas, para la inserción de

un objeto 76

5.21 Pantalla de comparación de las coordenadas, para la inserción de un objeto

76

5.22 Inserción de un objeto, después de el objeto de terminación de una sentencia

77

5.23 Pantalla de comparación de las coordenadas, para la inserción de un objeto

77

5.24 Pantalla de la posición elegida por el mouse para realizar la inserción de un objeto.

78

vii

5.25 Pantalla de comparación de las coordenadas entre dos objetos que se encuentran en el mismo nivel

78

5.26 Pantalla de la inserción entre niveles (de mayor a menor abstración) 79 5.27 Pantalla de comparación de las coordenadas de la inserción entre

niveles 80

5.28 Inserción de un objeto activo dentro de un diseño 80 5.29 Ubicación del objeto activo ya insertado en el diseño 81 5.30 Ejemplo del ajuste de los objetos en el diseño detallado

(externamente) 81

5.31 Ajuste de los objetos en el diseño detallado (internamente) 82 5.32 Modelo conceptual de los nodos de la lista temporal que sirve para

realizar el ajuste de las coordenadas de objetos activos del diseño 83

5.33 Pantalla que muestra la eliminación de objetos en el sistema GenCod 84 5.34 Pantalla que muestra la eliminación del objeto if y la ubicación

de los objetos después de la eliminación 85

5.35 Pantalla que muestra la eliminación del objeto fin de una sentencia y la ubicación de los objetos después de la eliminación

85

5.36 El GenCod como un puente entre la etapa de diseño detallado y pruebas

86

5.37 Orden secuencial en el cual se recorren las estructuras de datos en el GenCod para la generación de código

87

5.38 Interfaz del GenCod que muestra la generación de código de dos funciones

88

5.39 Almacenamiento del archivo de diseño detallado del GenCod 89 5.40 Arquitectura del archivo de diseño 90 5.41 Navegación entre las funciones de diseño 90 6.1 Información para calcular la medida de dispersión para el tiempo

dedicado a desarrollar un sistema sin utilizar la herramienta 96

6.2 Información para calcular la medida de dispersión para el tiempo dedicado a desarrollar un sistema utilizando la herramienta

96

6.3 Información para calcular la medida de dispersión para el tiempo dedicado a desarrollar un sistema sin utilizar la herramienta

97

6.4 Información para calcular la medida de dispersión para el tiempo dedicado a desarrollar un sistema utilizando la herramienta

98

6.5 Resumen comparativo del tiempo utilizado en las cuatro pruebas 98

1

CAPITULO 1

INTRODUCCION A LA INGENIERIA DE SOFTWARE Este capítulo describe un breve panorama del ciclo de vida de un sistema, así como de la importancia que tiene el diseño dentro de él.

Capítulo 1 Introducción a la ingeniería de software

2

1.1 Introducción a la ingeniería de software Los dirigentes de las organizaciones demandan Sistemas de software cada vez más confiables, es decir, que su realización se elabore en forma correcta conforme a los estándares de calidad, y por otra parte que su desarrollo se realice en los tiempos y costos establecidos. La situación real en los Centros de desarrollo de software, dista mucho de los deseos de los ejecutivos, en cuanto a la calidad de los sistemas que producen, así como a los tiempos y costos realmente implicados. Todo ello es debido fundamentalmente a la falta de empleo de metodologías y herramientas adecuadas, además de los posibles casos particulares de relaciones laborales[CUE93]. Para dar solución a esta problemática surge la Ingeniería de Software, que tiene como meta principal, aportar herramientas y técnicas que mejoren la productividad de los actuales ingenieros de programación[FAI90]. Una definición que acerca el concepto de la ingeniería de software es: “La ingeniería de software es la disciplina tecnológica y administrativa dedicada a la producción sistemática de productos de programación, que son desarrollados y modificados a tiempo y dentro de un presupuesto definido” [FAI90].

Las metas de primordiales de esta nueva disciplina tecnológica son mejorar la calidad de estos productos y aumentar la productividad y satisfacción profesional de los ingenieros de esta disciplina . Este trabajo de tesis da como resultado una herramienta cuyo objetivo es ayudar a los programadores en una de las etapas del ciclo de vida del software, de la cual hablaré más ampliamente en el punto 1.3. 1.2 Ciclo de vida clásico En este tema de tesis se trabajó en la fase de diseño detallado y como una consecuencia también en la fase de codificación. Para entender más a detalle, como se relacionan las fases de diseño y codificación, a continuación se muestra un modelo del ciclo de vida del software. 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”, el paradigma del ciclo de vida exige un enfoque sistemático y secuencial del desarrollo software que comienza en el nivel del sistema y progresa a través del análisis, diseño, codificación, prueba y mantenimiento.


3

Ingeniería del sistema

Análisis

Diseño

Codificación

Prueba

Mantenimiento

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

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

♦ Ingeniería del sistema. Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. ♦ Análisis. El proceso de recopilación de los requisitos se centra e intensifica especialmente para el software. Para comprender la naturaleza de los programas que hay que construir, el ingeniero de software (“analista”) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridos. ♦ Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software que puede ser establecida de forma que se obtenga la calidad requerida antes de que comience la codificación. Al igual que los requisitos, el diseño se documenta y forma parte de la configuración del software.


4

♦ Codificación. El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. ♦ Prueba. Una vez que se ha generado el código, comienza la prueba del programa. La prueba 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. ♦ Operación. Algunos autores añaden esta fase en el modelo del ciclo de vida del software. En esta fase se identifican aciertos, en la medida en que los requerimientos de los programas de computadora satisfagan las necesidades del usuario, la arquitectura y los diseños se asocian a las características específicas del sistema de explotación de cómputo, y en general la disciplina que haya sido empleada para la construcción del código[GER85]. ♦ Mantenimiento. El software, indudablemente, sufrirá cambios después de que se entregue al cliente. Los cambios ocurrirán debido a que se hayan encontrado errores, a que el software deba adaptarse a cambios de entorno externo, o debido a que el cliente requiera ampliaciones funcionales o de rendimiento. Una vez que se ha analizado el ciclo de vida del software se hablará más ampliamente de la fase de diseño. 1.3 Diseño de software Este tema de tesis se centra en la fase de diseño, debido a que ésta es una de las menos atacadas por los desarrolladores de sistemas, ya que si bien existen herramientas que nos permiten organizar un sistema en módulos en la fase de análisis, no existen aquellas utilerias que nos permitan desarrollar el diseño de un sistema y que nos de como resultado la implantación de ese diseño. Ahora se mencionarán las partes en las que se divide el diseño de software según Farley y Pressman, cabe aclarar que estas dos ideas respecto al diseño no se presentan como una comparación entre ellas, sino como un medio para llegar a una idea más general de diseño. Fairley divide la fase de diseño en: estructural y detallado, dándoles la siguiente definición: Diseño estructural: comprende la identificación de los componentes de la programación, su desacoplamiento y descomposición en módulos de procesamiento y estructuras de datos conceptuales, y la especificación de las interconexiones entre componentes.


5

Diseño detallado: se refiere a detalles de: cómo empacar módulos de procesamiento, y cómo instrumentar los algoritmos, las estructuras de los datos y sus interconexiones. El diseño detallado está fuertemente influenciado por el lenguaje de implantación, pero no es lo mismo que la instrumentación, el diseño detallado tiene que ver más con aspectos semánticos y menos con detalles sintácticos que es la instrumentación, además permite el diseño de algoritmos y representaciones de datos en un nivel más alto de abstracción y notación que el que proporciona el lenguaje de implantación, es decir el diseño de un algoritmo es susceptible a ser implantado en una amplia variedad de lenguajes de programación. El diseño detallado separa las actividades de diseño a bajo nivel de instrumentación, igual que las actividades de análisis y diseño aíslan las consideraciones de lo que se desea de la estructura que logrará los resultados deseados. Una especificación adecuada de diseño detallado minimiza el número de sorpresas durante la instrumentación del producto. A diferencia de Fairley, Pressman asienta el diseño de un programa en el diseño de datos, el diseño arquitectónico, el diseño procedimental y el diseño de la interfaz de usuario. Diseño de datos: El diseño de datos es la primera (y de alguna forma podríamos decir que la más importante) de las tres actividades de diseño realizadas durante la ingeniería del software. El impacto de la estructura de datos sobre la estructura de programa y la complejidad procedimental, hace que el diseño de datos tenga una gran influencia en la calidad del software[PRE90]. En secciones posteriores se mostrarán algunas de las metodologías enfocadas a este tipo de diseño. Diseño arquitectónico: El objetivo principal del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos. Además el diseño arquitectónico mezcla la estructura de programas y la estructura de datos y define las interfaces que facilitan el flujo de los datos a lo largo del programa [PRE90]. Diseño procedimental: El diseño procedimental se realiza después de que se ha establecido la estructura del programa y de los datos. En un mundo ideal, la especificación procedimental que define los detalles algorítmicos debería explicarse en lenguaje natural. Desafortunadamente el diseño procedimental debe especificar los detalles de los procedimientos sin ambigüedad y la falta de ambigüedad en el lenguaje natural no es habitual. Por estas y muchas otras más razones, se debe de usar una forma más restringida para la representación de los detalles procedimentales, las cuales se mostrarán en las secciones subsecuentes a este capítulo. Este tipo de diseño es semejante o equivalente al diseño detallado del cual se habló anteriormente, sólo que este autor lo denomina procedimental. Diseño de la intefaz de usuario: La interfaz del usuario es el mecanismo a través del cual se establece un diálogo entre el programa y el humano. Tiene tanto que ver con el estudio de la gente como con aspectos de la tecnología. ¿Quién es el usuario? ¿Cómo aprende el usuario a


6

interaccionar con un sistema nuevo basado en computadora? ¿Qué espera el usuario del sistema? Estas son sólo unas pocas de las muchas preguntas que deben ser planteadas y respondidas como parte del diseño de la interfaz de usuario. Teniendo varios enfoques de la fase de diseño mencionaremos cuál es la importancia que tiene éste dentro del ciclo de vida del software. 1.4 Importancia del diseño La importancia del diseño del software se puede sentar con una única palabra CALIDAD. El diseño es el proceso en el que se asienta la calidad del desarrollo del software. El diseño produce las representaciones del software de las que pueden evaluarse su calidad. El diseño es la única forma mediante la cual podemos traducir con precisión los requisitos del cliente en un producto o sistema acabado. El diseño de software sirve como base de todas las posteriores etapas del desarrollo y de la fase de mantenimiento. Sin diseño, nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeños cambios; un sistema que pueda ser difícil de probar; un sistema cuya calidad no pueda ser evaluada hasta más adelante en el proceso de ingeniería del software, cuando quede poco tiempo y se haya gastado ya mucho dinero [PRE90]. A continuación en la figura 1.2 se presenta una gráfica que ilustra los resultados de desarrollo de software con diseño y sin diseño.

Prueba

Implementación

Diseño

Implementación

Prueba

Mantenimiento

Con diseño Sin diseño

Mantenimiento

Figura 1.2 Importancia del diseño. En esta gráfica se puede ver que el diseño es de primordial importancia para el desarrollo de cualquier sistema de software. Al igual que en las demás fases del ciclo de vida del software, en la etapa de diseño detallado se cuenta con un conjunto de herramientas que sirven para


7

facilitar las distintas actividades asociadas con dicha etapa, a estas herramientas se les conoce como notaciones de diseño En este tema de tesis se plantea la construcción de un sistema de software que permita al usuario realizar la etapa de diseño detallado de una manera automatizada. En el capitulo 2 se analiza el por qué a pesar de que el diseño de sistemas tiene beneficios tan palpables, los desarrolladores no lo utilizan cotidianamente en el ciclo de desarrollo de sistemas. El GenCod se ideó como una herramienta capaz de generar código en el lenguaje de programación C basándose en el diseño de un sistema. El reto de construir esta herramienta fue que el GenCod fuese tan fácil de utilizar que para los desarrolladores no lo vieran como un nuevo problema.

8

CAPITULO 2

PLANTEAMIENTO DEL PROBLEMA En este capítulo se realiza un planteamiento del problema, para esto se muestran los resultados obtenidos de dos investigaciones, cuyo objetivo fue elegir la notación de diseño detallado que se emplearía para solucionar una parte del problema que se presenta.

Capítulo 2 Planteamiento del problema

8

2.1 Descripción del problema En el capítulo uno se analizó muy brevemente el ciclo de vida del software. Si se estudiaran más a fondo cada una de las fases, nos percataríamos de que en cada una de ellas existen problemas que impiden que su uso sea extensivo, algunos de estos problemas (los que han podido ser resueltos) no cuentan con soluciones que cumplan con las expectativas de los desarrolladores de software. Este tema de tesis trata de resolver uno de los problemas que se presenta en el ciclo de vida del software: la falta de interés por parte de los desarrolladores en la fase de diseño detallado en el ciclo de vida del software[YOU92]. En muchas ocasiones, la mayoría de los programadores trabajan con un diseño informal del sistema, restando importancia a un diseño formal que permita contar con un producto robusto y consistente. Generalmente se busca "no perder tiempo" y como resultado de esto, no se contará con un respaldo documental de los conceptos de diseño. Esto es el equivalente a construir una casa sin realizar primero un plano arquitectónico de la misma. Pero aun con estas razones es difícil que el desarrollador comprenda que la implantación de una especificación adecuada del diseño detallado minimiza el número de sorpresas durante la instrumentación del producto. A pesar de que actualmente existe una amplia gama de metodologías, a los desarrolladores les resulta una tarea desagradable el usar alguna de ellas, ya que consideran que representa un desperdicio de tiempo y esfuerzo, los cuales pudiesen ser aprovechados en la codificación del sistema, se debe tener en cuenta que aunque el diseño detallado es de mucha utilidad, la construcción de éste es muy tediosa, por lo cual esta fase esta siendo reconocida como un serio problema [YOU92]. Las consecuencias de esta actitud se ven reflejadas mas tarde, cuando se intenta dar mantenimiento al sistema, y no se cuenta con una buena documentación que ayude a comprender de forma más rápida el funcionamiento del sistema. La ausencia de una documentación que refleje el estado actual del sistema ocasiona muchos problemas asociados, uno de estos (aún sin solución) es la imposibilidad práctica para predecir con exactitud el tiempo de desarrollo de un proyecto, ya que generalmente el tiempo real es más elevado que el tiempo estimado, disparándose de esta manera el costo del sistema. Y es que los problemas que se van encontrando durante el ciclo de vida del software y no se les da solución, o se les resta importancia se van acarreando hasta el final del ciclo de vida del software, ocasionando otros problemas como son: 1. Desarrollos lentos. 2. Elevadas cargas de mantenimiento. 3. Elevados costos de corrección en el desarrollo. 4. Baja calidad y confiabilidad del producto [CUE93].


9

Peor aun si no se utiliza formalismo y alguna metodología para la realización del software, se continuará teniendo dependencia de los desarrolladores del software. 2.2 Alternativas de solución Una vez que se ha planteado el problema, se explicará la alternativa de solución que se empleó para la solución de este problema. Lo que se pretende con este trabajo de tesis es que los desarrolladores se auxilien de la computadora para elaborar el diseño detallado de un sistema, pretendiendo con esto, ahorrar tiempo en la etapa de diseño, ya que las revisiones y correcciones serán mucho más rápidas. En la sección 2.3 se muestran los resultados de una investigación que se realizó con el fin de conocer la metodología de diseño que se emplearía para la realización de este trabajo de tesis. El diseño detallado se realizará de una manera gráfica (se empleó el paradigma de la programación visual de la cual se hablará más ampliamente en el siguiente capítulo), pretendiendo con esto, que el empleo de la herramienta no resulte un problema más. Una vez que se haya completado el diseño detallado del sistema, el usuario podrá generar el código en el lenguaje de programación C, correspondiente a dicho diseño, lográndose con esto una reducción en el tiempo empleado para obtener un sistema terminado. Además de que se le brinda al desarrollador una serie de ayudas para hacerle aun más fácil y atractiva la idea de realizar el diseño detallado de un sistema de software (acerca de estas ayudas se hablará más adelante). 2.2.1 Objetivo de la tesis Elaborar e implantar una gramática posicional de la notación de diseño detallado elegida, así como la construcción de un analizador sintáctico de esta gramática, para la construcción de una herramienta visual que permita al usuario realizar de una manera automatizada sus diseños. La construcción de éstos deberán ser de una manera visual lo que facilitará el uso de la herramienta, porque se contarán con símbolos gráficos para representar las instrucciones de la notación, asi tambien se agregarán símbolos a aquellas instrucciones que no sean gráficas, las figuras de estos símbolos serán congruentes con la instrucción a la que representen. Además la herramienta permitirá generar de manera automática código estructurado en el lenguaje de programación C, este código será acorde al diseño construido.


10

La herramienta debe permitir realizar diseños (que sólo utilicen las construciones básicas de la notación) sin conocer el lenguaje de programación C. Además de almacenar los diseños del usuario en disco. 2.2.2 Beneficios de la tesis Con el desarrollo de esta tesis se obtuvieron los siguientes beneficios: • Se realizó una modificación en la notación de diseño detallado elegida (sección 2.?),

teniendo con esto una nueva notación de diseño más gráfica. • Se diseñó e implementó una gramática posicional de la notación de diseño elegida. • Se cuenta con un analizador sintáctico de la gramática posicional que permite validar las

construcciones hechas por el usuario. • Se cuenta con una gramática lineal que valida las entradas por teclado hechas por el usuario. • El usuario cuenta con una herramienta para construir sistemas, a partir del diseño detallado

que asista a los programadores en la elaboración de programas y en la documentación de sistemas.

• Esta herramienta cuenta con un ambiente visual, en donde las instrucciones de la

metodología de diseño detallado están representadas por botones, los cuales pueden ser seleccionados por el usuario para ir formando el diseño detallado, además la herramienta va guiando al usuario en la construcción de su diseño, todo esto permite al usuario construir su diseño de una forma natural e intuitiva entre el hombre y la computadora.

• Se genera código automáticamente a partir del diseño detallado, avanzándose en la fase de

codificación, logrando con esto una reducción de tiempo que puede ser empleado en otra fase del ciclo de vida del software.

• La herramienta de diseño además de utilizar técnicas de diseño estructurado, fomenta a los

desarrolladores buenos hábitos de programación, ya que no permite diseñar sus programas con muchos ciclos anidados, además de poder utilizar solo variables que se hayan declarado con anterioridad.

• Se puede contar con la documentación de los programas (diseño detallado), esto facilita la

comprensión del funcionamiento de dichos programas, lo cual permitirá que las adaptaciones futuras (mantenimiento) sean más simples y rápidas.


11

• Se cuenta con un archivo de texto, donde se encuentra el código generado por el sistema, de tal manera que este pueda ser utilizado posteriormente por el desarrollador si lo desea.

Una vez que se han visto algunos de los beneficios que aporta esta herramienta, se muestra a continuación las investigaciones que se realizaron para saber cual es la notación de diseño que se iba a implantar. 2.3 Investigación sobre la utilización de las notaciones de diseño Las notaciones de diseño surgen casi de manera simultánea con la aparición de los lenguajes de programación, como una herramienta que facilita a los programadores la realización de la fase de diseño. Hoy en día existe una amplia gama de metodologías de diseño, por lo que existen muchas maneras de realizar la fase de diseño. Para unificar un poco esto, se llevó a cabo una investigación a través de un cuestionario, el cual se aplicó a una muestra de 28 personas elegidas al azar y con diferentes niveles de conocimientos en programación: alumnos del curso propedéutico de ciencias computacionales de la generación 95, profesores-investigadores, alumnos a nivel licenciatura tanto del Instituto Tecnológico de Zacatepec como de la Universidad Autónoma de Morelos. Esta investigación se realizó para determinar cuáles notaciones son las más conocidas, así mismo saber cuál de ellas es generalmente la más utilizada (Anexo 1). Los resultados obtenidos de esta investigación sirvieron para decidir qué notación de diseño se implementa en esta tesis, buscando con esto realizar una herramienta CASE (computer aided software engineering) que pueda ser utilizada por un mayor número de programadores. A continuación se muestran los resultados obtenidos de dicha investigación. 2.3.1. Gráfica de tendencias de las notaciones de diseño más conocidas Uno de los propósitos del cuestionario fue: saber cuáles notaciones son las más conocidas, obteniéndose los siguientes resultados de la encuesta a) 22 personas dijeron que conocían la notación de diseño de Warnier/Orr. b) 20 personas conocían la notación de diseño del pseudocódigo. c) 19 personas conocían la notación de diseño de Flujo de datos. d) 7 personas conocían la notación de diseño de Jackson. e) 6 personas conocían la notación de diseño de Nassi-Shneiderman. f) 5 personas conocían la notación de diseño de Yourdon. g) 4 personas conocían la notación de diseño de Hipo.


12

h) 1 persona dijo que conocía la notación de diseño de Bertini. Con estos resultados se puede ver claramente que las notaciones más conocidas entre los programadores son: Warnier, Pseudocódigo y Flujo de datos. Para visualizar mejor esta información se construyó la siguiente gráfica de barras. La figura 2.1 muestra el comportamiento del cuestionario aplicado.

War

nier

Seud

ocód

igo

D. f

lujo

Jack

son

N-S

You

rdon

Hip

o

Ber

tini0

5

1 0

1 5

2 0

2 5

War

nier

Seud

ocód

igo

D. f

lujo

Jack

son

N-S

You

rdon

Hip

o

Ber

tini

M e t o d o l o g í a s d e d i s e ñ o m á s c o n o c i d a s

Figura 2.1 Metodologías de diseño detallado más conocidas. 2.3.2 Gráfica de tendencia de las notaciones de diseño más utilizadas Una vez que han sido analizadas las notaciones de diseño más conocidas entre los programadores, se procedió a determinar cuáles de ellas son las más utilizadas (lo cual es realmente el objetivo principal de esta investigación). Obteniéndose la información de la figura 2.2.

Notaciones de Diseño

Frecuencia

Warnier/Orr 12 Pseudocódigo 8

Diagramas de Flujo 5 Jackson 2

Nassi/Shneiderman 1 Figura 2.2 Cuadro de frecuencia de las notaciones de diseño

Con estos datos la figura 2.3 muestra un diagrama para representar la frecuencia de diseñadores que eligió cierta notación de diseño, en dónde la altura de cada barra representa el número de personas que eligió esa notación, y cada una de las barras representa a la notación.


13

War

nier

Seud

ocód

igo

D. f

lujo

Jack

son

N-S

0

2

4

6

8

1 0

1 2

War

nier

Seud

ocód

igo

D. f

lujo

Jack

son

N-S

M e t o d o l o g í a s d e d i s e ñ o m á s u t i l i z a d a s

Figura 2.3 Metodologías de diseño más utilizadas. 2.3.3 Gráfica de tendencias (porcentajes) de las notaciones de diseño más

utilizadas Otra manera de representar los resultados obtenidos de la investigación llevada a cabo, es a través de los diagramas circulares, llamados también diagramas de pastel, en donde para poder mostrar la información es necesario determinar un rango percentil para cada notación, la cual representa un pedazo del diagrama de pastel. La ecuación para determinar el rango percentil es la siguiente:

rango percentil = frecuenciaN

* 100

donde: N = sumatoria de todas las frecuencias. frecuencia = el número de personas que eligió cierta notación. Aplicando esta ecuación a cada uno de los datos que se encuentran en la figura 2.2 se obtuvo la muestra del índice de utilización de las metodologías de diseño, aunque se debe recalcar que generalmente los desarrolladores no utilizan ninguna metodología de diseño para desarrollar software, la siguiente gráfica de la figura 2.4 muestra el porcentaje de utilización de las metodologías que ocasionalmente llegan a utilizar los desarrolladores.


14

Uso de las metodologías de diseño entre los desarrolladores

Warnier

D. Flujo JacksonN-S

Seudocódigo

Figura 2.4 Uso de las metodologías de diseño entre los desarrolladores 2.4 Resultados obtenidos de la investigación Los resultados que se obtuvieron de la investigación fueron muy similares. Todas las personas entrevistadas contestaron que sí habían utilizado una notación de diseño detallado para la elaboración de un sistema, esto indica que sí se realiza la fase de diseño detallado del ciclo de vida del software, aunque generalmente en muchas ocasiones no se hace. A pesar de que ellos mismos comentan que sí han visto que son de gran ayuda porque reduce el tiempo en el desarrollo de un sistema y como consecuencia esto se ve reflejado en el costo, ya que cuando un proyecto se encuentra desfasado los costos se disparan. La mayoría de las personas contestaron que utilizan una notación de diseño cuando van a llevar a cabo un sistema grande porque esto les permite tener un mejor seguimiento de los programas además de que sirve para la documentación final del proyecto. Una vez analizada la utilidad y la frecuencia con la que se utiliza una notación de diseño las demás preguntas del cuestionario estaban enfocadas para conocer cual de todas las notaciones que conocen y que han utilizado les había gustado más, las respuestas ya han sido mostradas en los puntos anteriores a través de unas gráficas. Aunque la información recabada en la encuesta es importante para este trabajo de tesis, también se requirió hacer otra investigación entre las notaciones de diseño detallado, más conocidas por los diseñadores, para analizar si la notación elegida por los encuestados ayudaba a cumplir con el objetivo de esta tesis. En esta investigación se analizaron las construcciones básicas, ventajas y desventajas de algunas de ellas.


15

2.5 Investigación de las notaciones de diseño Las metodologías para construir el diseño detallado surgen casi de manera simultánea con la aparición de los lenguajes de programación. Estas metodologías junto con la programación estructurada, permiten al diseñador representar los detalles procedimentales, facilitando su traducción al código. En seguida se muestran algunas de estas metodologías o notaciones de diseño, así como sus construcciones básicas (en algunos casos), porque cualquier programa, independiente del área de aplicación y de la complejidad técnica, puede diseñarse e implementarse usando sólo las tres construcciones estructuradas, sin embargo debe tenerse en cuenta que si estas herramientas se usan incorrectamente puede conducir a un software erróneo [PRE90]. 2.5.1 Pseudocódigo Es “un lenguaje chapurreado que utiliza el vocabulario de un lenguaje (p.ej.: inglés) y la sintaxis general de otro (p.ej.: un lenguaje de programación estructurada)” [CAI75]. A primera vista, el pseudocódigo se puede parecer a PASCAL o a Ada. La diferencia entre el pseudocódigo y un lenguaje de programación de alto nivel se encuentra en el uso de texto descriptivo directamente dentro de las instrucciones del pseudocódigo. La desventaja que tiene esta notación de diseño es que describe las instrucciones parecidas al lenguaje natural, y el diseño detallado debe especificar los detalles de los procedimientos sin ambigüedad y la falta de ambigüedad en un lenguaje natural no es habitual [PRE90]. 1.5.2. Diagramas de flujo Un diagrama de flujo es un gráfico muy sencillo. Para representar un paso de procesamiento se utiliza un cuadro, un rombo para representar una condición lógica y flechas para mostrar el flujo de control. Existen numerosas desventajas en el uso de los diagramas ordinarios de flujo, una de ellas es que este tipo de diagramas requieren de un espacio considerable de papel, de tal forma que el lector tiene que navegar entre varias páginas para asimilar todo el contenido del programa. Además cuenta con demasiadas ramificaciones, cada una de ellas provenientes de cada decisión del diagrama de flujo, las cuales tienen varias formas de dibujarse, según el autor. Esto ocasiona el problema de que a un diseñador le resultará muy problemático leer diagramas de flujo realizadas por otro diseñador [KEN88].


16

Tal vez la mejor razón para utilizar diagramas de flujo es que han sido utilizados históricamente. Quienes los han usado y han sido promovidos dentro de una compañía, con el tiempo llegan a entenderlos mejor que cualquier otra técnica más reciente. 2.5.2.1. Construcciones básicas Las construcciones básicas de esta notación son:

Secuencia

Primera tarea

Siguiente tarea

Casos de

condición

T

T

T

F

F

F

Parte del caso

Selección

T

F

T

F

Repeat-Until

Condicióndel bucle

Do-while

Repetición

Tarea del bucle

Condición

F TParte-Else

Parte-then

If-then-else

Figura 2.5 Construcciones en diagramas de flujo.


17

2.5.3 Jackson Esta metodología creada por el inglés Michael Jackson se basa en que la estructura de un programa está en función de la estructura de los datos que manipula. Jackson emplea módulos según su orden jerárquico dentro de los diferentes niveles donde se encuentra. Cada módulo es un dato o un conjunto de datos [JOY88]. 2.5.3.1 Construcciones básicas Las estructuras básicas en este método vienen representadas en la figura 2.6 y son las siguientes: Secuencial: un número determinado de módulos se ejecutan una sola vez en el orden jerárquico preestablecido. Repetitiva: un módulo se ejecuta desde cero hasta n veces. El proceso repetitivo se indica con un asterisco (*). Alternativa: Se selecciona para la ejecución un módulo entre varios posibles. El proceso se indica por medio de una letra O. Con estas estructuras básicas se puede obtener cualquier otra que intervenga en el diseño del programa. El uso del método de Jackson supone lectura arriba-abajo y de izquierda a derecha.

M

PN

S e c u e n c i a l

M

PN

A l t e r n a t i v a

N PO OOO

M

N

R e p e t i t i v a

*

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


18

2.5.4 Nassi/Shneiderman (N-S) Los diagramas de flujo estructurado también llamados Nassi-Schneiderman, son herramientas gráficas que fuerzan al diseñador a estructurar software que sea modular y descendente. Proporcionan una estructura a la que se pueden ajustar los que desarrollan el software de aplicación [SEN94]. Este sistema de representación permite tener una visión mucho más estructurada que los diagramas de flujo y el pseudocódigo, por lo tanto tiene mayor facilidad de ser traducido al lenguaje de una computadora. Otra de las ventajas con las que cuenta este método son: 1. compatibilidad con la programación estructurada. 2. reducción del espacio en papel ya que este método omite el uso de flechas, utiliza cajas o bloques contiguos y los diagramas son de una sola hoja. Sin embargo este método también tiene algunas desventajas con relación a los otros métodos. Una de ellas es que para que un diagrama pueda ser entendido debe ser completo y comprensivo [KEN88]. 2.5.4.1. Construcciones básicas Los elementos básicos de los diagramas N-S son [KEN88]:

Proceso Decisión Iteración

Figura 2.7 Los tres símbolos gráficos utilizados para dibujar

los diagramas de Nassi-Schneiderman.


19

PROCESO: está representado mediante un rectángulo y simboliza la inicialización de variables, actividades de entrada y de salida y las llamadas para ejecutar otros procedimientos. Un nombre descriptivo breve, escrito dentro del rectángulo, establece el propósito del proceso. DECISION: el símbolo de decisión representa condiciones alternativas. Son equivalentes a las estructuras IF-THEN-ELSE. ITERACION: representa los ciclos y repeticiones de operaciones mientras se cumpla una condición [KEN88]. 2.5.5. HIPO (Hierachy/Input/Process/Output) Este método fue creado con el propósito de ayudar a los diseñadores a no perder la pista de alguna función dentro de un sistema grande, ésta es su principal ventaja con la que cuenta con respecto a otras notaciones, ya que este método permite tener una vista panorámica de las entradas, procesos y salidas de datos. Esto lo hace una herramienta útil para la documentación de programas, además de que le puede facilitar al autor de un programa el recordar lo que hace el sistema después de cierto tiempo. Sin embargo HIPO también cuenta con ciertas desventajas, una de ellas es que utilizan una gran cantidad de papel para mostrar todo el diagrama de un sistema por lo que puede ocasionar que el lector navegue entre hojas y se le dificulte el seguimiento del flujo de éste [KEN88]. En la figura 2.8 se muestra un ejemplo del diagrama HIPO [FAI90].

Contenido

Leyenda.-.-.-.-.-.-.-.-.-.-.-.-

1-.-.-.-.-.-. 6.-.-.-.-.-2.-.-.-.-.-.- 7.-.-.-.-.-3.-.-.-.-.-.- 8.-.-.-.-.-4--.--.-.--- 9.---.-.-.-5.-.-.-.-.-.- 10.-.-.-.-.

5 6

2

7 8

3

10 11

9 12

4

1

Figura 2.8 Tabla visual de contenido para un paquete HIPO.


20

2.5.6 Diagramas de warnier El diseño de estos diagramas fueron desarrollados inicialmente en Francia por Jean-Dominique Warnier, con el fin de representar la jerarquía de la información utilizando las tres construcciones de secuencia, selección y repetición, además Warnier demostró que la estructura del software puede derivarse directamente de las estructuras de los datos. Por su parte Kenneth Orr en los Estados Unidos amplía el trabajo de Warnier abarcando una visión más amplia del campo de información, evolucionando el desarrollo de sistemas estructurados en datos [PRE90]. 2.5.6.1 Simbología A continuación en la figura 2.9 se muestra un diagrama general de Warnier-Orr, así como el significado de los diferentes elementos que en él participan [SAN92].

Proc. 1Condición

Condición

(c)

sum a<- sum a+ 1

x = x +1

* x >= 5

X 1

Figura 2.9 Simbología utilizada para los diagramas de Warnier.

Significado de los elementos 1. Denota a un bloque de información jerarquizada que pueden ser datos o acciones, de derecha a izquierda denota los niveles de abstracción, de arriba abajo, muestra la secuencia y las relaciones lógicas entre las funciones.


21

2. La información entre los paréntesis (variable simbólica o cantidad numérica ) indica el número de veces que ocurrirá la estructura. Si se coloca una letra C indica que un ciclo se termina cuando una condición se cumple. 3. Indica la negación de una condición. 4. Indica ocurrencia condicional de una acción o grupo de acciones. 5. Indica un bloque de instrucciones descrito en otra parte, puede estar vacío o llevar adentro un número o identificador de procedimiento (subprograma, rutina, función, etc.). 6. Indica expresión condicional de fin de ciclo. Es decir cuando se cumple la expresión que va después del asterisco, se termina de ejecutar el ciclo. 7. Indica asignación de una variable, de derecha a izquierda. 2.5.6.2 Construcciones básicas La notación de Warnier utiliza las construcciones básicas de: secuenciación, bifurcación y repetición figura 2.10. A continuación se explica cada una de ellas [SAN92].

Proc 1

Proc 2

Condición

Condición

(b) Bifurcación

Proceso 1,Proceso 2,

.

.Proceso n

(a) Secuenciación

X <- 1

(c) Repetición

(c)

suma <- suma + 1x = x +1* x >= 5

Figura 2.10 Construcciones básicas de los diagramas de Warnier.


22

Secuenciación. La llave es usada para denotar diferentes niveles de información jerarquizada, de arriba abajo muestra la secuencia de ejecución y las relaciones lógicas entre los procesos, de izquierda a derecha muestra el nivel de abstracción. bifurcación. Si se cumple la condición, el proceso se bifurca al proceso 1, de otra manera se sigue con el proceso 2. Repetición. En la figura 2.10 inciso c se muestra la estructura de repetición. Todas las instrucciones que se encuentren dentro de la llave se van a ejecutar hasta que se cumpla la condición x >= 5. Esta notación de diseño detallado tiene una característica que la hace diferente respecto a las demás notaciones, ésta es: para poder desarrollar un diagrama de Warnier/Orr, el analista debe trabajar hacia atrás, es decir, se debe empezar con la especificación de la salida del sistema. En el papel el flujo del diagrama va de izquierda a derecha, definiendo en primer lugar la salida o resultados del procedimiento y en el nivel siguiente, mostrado mediante la inclusión de una llave, se definen los pasos para producir una salida. Las llaves adicionales agrupan los procesos requeridos para producir el resultado en el siguiente nivel. Estos diagramas ofrecen a los expertos en sistemas algunas ventajas distintivas. Son simples en apariencia, fáciles de entender, fáciles de modificar, mas que los diagramas de Nassi-Schneiderman porque como se mencionó anteriormente el analista debe trabajar hacia atrás. Otra de sus ventajas importantes es que los diagramas de Warnier son compatibles con las técnicas de la programación estructurada, por lo que se convierten en poderosas herramientas de diseño. También tienen la ventaja de mostrar agrupaciones de procesos y los datos que deben transferirse de nivel a nivel. Además la secuencia del trabajo hacia atrás garantiza que el sistema estará orientado hacia el resultado, a menudo es necesario determinar los pasos más internos antes de poder resolver lo relativo a las interacciones y a la modularidad [KEN88]. 2.6 Comparaciones entre las notaciones de diseño En la sección anterior se mencionaron algunas de las muchas notaciones que existen, pero en la actualidad no hay alguna notación que pueda considerarse como estándar para la documentación del software. Esto conlleva a la libertad que tienen los programadores en elegir la notación que más le pueda servir para su diseño, ya que no podemos decir cual de ellas es mejor o peor porque cada una de ellas cuenta con sus propias características lo que las ponen en ventajas con algunas de ellas y viceversa. Pressman hace algunos comentarios los cuales pueden serle útiles al programador para elegir una notación de diseño.


23

Una notación de diseño debe conducir a una representación que sea fácil de comprender y revisar. Además, la notación debe facilitar la codificación, de forma que el código se obtenga de hecho como un producto natural del diseño. Finalmente la representación del diseño debe ser fácilmente mantenible, de forma que el diseño represente siempre correctamente el programa. Además menciona algunos atributos con los que debe contar una buena notación de diseño, estos son: Modularidad: una notación de diseño debe soportar el desarrollo de software modular. Pfleeger comenta que la modularidad es una de las característica que tiene un buen diseño, ya que la modularidad provee la flexibilidad que los programadores necesitan para entender lo que un sistema está haciendo [PFL91]. Simplicidad global: una notación de diseño debe ser relativamente sencilla de aprender, relativamente fácil de usar y generalmente fácil de leer. Facilidad de edición: el diseño procedimental puede requerir modificaciones durante el paso de diseño, durante la prueba del software y finalmente durante la fase de mantenimiento del proceso de ingeniería de software. Legible por la máquina: los entornos de la ingeniería de software asistida por computadora están siendo adoptados por la industria. Una notación que pueda ser introducida directamente en un sistema de desarrollo basado en computadora ofrece unos enormes beneficios potenciales. Mantenimiento: el mantenimiento de la configuración del software casi siempre significa mantenimiento de la representación del diseño procedimental. Exigencia de Estructura: una notación de diseño que refuerce el uso sólo de construcciones estructuradas promueve la práctica de un buen diseño. Procesamiento Automático: un diseño detallado contiene información que puede ser procesada para dar al diseñador nuevos o mejores conocimientos respecto a la corrección y la calidad de un diseño. Representación de los datos: la habilidad para representar datos locales y globales es un elemento esencial en el diseño detallado. Verificación lógica: una notación que refuerce la posibilidad de verificar la lógica, mejora bastante la idoneidad de la prueba. Disposición para la codificación: una notación que se convierta fácilmente a código fuente reduce el trabajo y los errores.


24

2.7 Notación de diseño detallado elegida Con los resultados obtenidos de la encuesta y el estudio realizado de las notaciones de diseño detallado, se decide implantar la metodología de Warnier porque la mayoría de la gente la calificó como una notación sencilla de utilizar, porque permite manejar niveles de abstracción tanto como el usuario quiera, además de que es independiente del lenguaje sobre el cual se desee realizar la implantación. Otra razón por la elección de esta notación es que cuenta con algunos símbolos gráficos en sus construcciones básicas, lo que permite realizar la automátización visual de la notación. Además esta metodología tiene en el momento actual, un nivel de formalización considerablemente superior a otras metodologías tales como Bertini, Jackson o Yourdon, lo cual permite una forma más eficiente y real de su soporte mediante una herramienta CASE, tanto para la generación de programas como para su validación [CUE93].

26

CAPITULO 3

CONCEPTOS DE PROGRAMACION VISUAL En este capítulo se encuentran algunos conceptos fundamentales de la programación visual, así como el estado del arte de la misma.

Capítulo 3 Conceptos de Programación Visual

27

3.1 Introducción Día a día crece el interés en los sistemas que utilizan gráficas en la comunicación computadora/seres humanos, en programación de aplicaciones y en la llamada visualización de datos. Por lo tanto la tendencia dominante hoy en día es la de las herramientas de desarrollo generadas mediante lo que se ha denominado como programación visual [LOP95]. Se presentan a continuación algunos de los conceptos más importantes en torno a la programación visual. 3.2 Conceptos de programación visual Por programación visual se entiende como el uso de expresiones visuales, tales como gráficas, dibujos e iconos en el proceso de la programación de aplicaciones [BUR95]. Un lenguaje visual es una representación pictográfica de entidades conceptuales y operaciones [CHA90]. Un lenguaje visual significa en realidad el uso sistemático de las expresiones visuales (tales como gráficas, dibujos e iconos), que se convierten en código que a su vez la computadora puede ejecutar para realizar una tarea particular [LOP95]. La Visualización tiene la función de ilustrar ciertos tipos de datos, la estructura de datos, la estructura de un sistema complejo o, incluso, el comportamiento de un sistema dinámico [LOP95]. Un lenguaje visual es esencialmente una herramienta compuesta de iconos, o sentencias visuales. Los compiladores de los lenguajes visuales deben interpretar sentencias visuales y trasladar éstas dentro de una forma que al menos intente la ejecución de las tareas. Este proceso no es directo. El compilador no puede determinar el significado de una sentencia visual simplemente por mirar el icono. Debe considerar el contexto de la sentencia, como el objeto se relaciona con los demás. Los intentos de mantenimiento que hace un usuario, así como la interpretación de los mismos, es una de las tareas más importantes en un lenguaje visual. Una sentencia visual es un acomodo espacial de objetos y/o iconos de procesos que generalmente describen una compleja entidad conceptual de una secuencia de operaciones.


28

3.3 Una taxonomía de iconos Iconos objetos: representan entidades o grupos conceptuales de iconos que son acomodados en un lugar en particular. Iconos de procesos: denotan operaciones y son generalmente dependientes del contexto [CHA95]. En cuanto a los iconos, Shi-Kuo Chang en su artículo “Hacia una teoría formal de iconos” [CHA87], realiza una taxonomía de los iconos y dice: un icono generalizado es un objeto con doble representación, una parte lógica (el significado) y una parte física (la imagen). El diccionario define un icono como: “una imagen; figura; representación; pintura”. La comunicación de un icono concierne con el uso de la imagen para transmitir ideas o acciones (comandos) de una manera no verbal. En la figura 3.1 se da una taxonomía de iconos, que provee una clasificación por su diseño o su función.

Diseño Funcion

Abstracto Símbolo

Arbitrario Signo

Representativo Dibujo

Figura 3.1 Una taxonomía de iconos.

En esta taxonomía Shi-Kuo Chang da un sistema formal de iconos, la cual tiene cinco elementos G = (VL, VP, S, x0, R), donde VL es un conjunto de objetos lógicos. VP es un conjunto de objetos físicos, S es un conjunto finito no vacío de nombres de iconos, x0 es un elemento en S, denotando la cabeza el nombre del icono, y R es el conjunto de reglas de los iconos el cual es mapeado desde X en 2(VL∪S). Un icono es denotado por x, y su identificador formal, o (Xm, Xi), donde Xm es un subconjunto de VL∪S, y Xi es un elemento de VP. Se podría utilizar la notación x intercambiable, (Xm, Xi), x(Xm, Xi), y (x, Xm, Xi), para denotar un icono. Dado que un icono en un sistema G, puede determinar el icono del conjunto RR, el cual es un conjunto de todos los iconos definido por G, o formalmente,

RR = { (x,Xm, Xi): x::=( (Xm, Xi) ∈ R) }.


29

Un icono (x,Xm, Xi) puede ser uno de los siguientes tipos: Icono elemental: Si Xm∩S es vacío. En otras palabras, Xm es un subconjunto de VL, dado que

x es de la forma ({etiquetas}, imagen). La etiqueta puede denotar objetos, procedimientos u operadores, dado que los iconos elementales pueden ser un icono objeto, un icono de proceso o un icono operador.

Existen iconos elementales especiales. Un icono imagen es uno donde Xm está

vacío, así x es de la forma ({}, imagen). Un icono etiqueta es uno donde la parte física es nula, así que x es de la forma ({etiqueta}, e). Finalmente, un icono nulo es de la forma ({}, e).

Icono complejo: Si Xm∩S es no vacío. Un icono complejo apunta a otros iconos y define relaciones de iconos. En este tipo de iconos se pueden distinguir los siguientes tipos:

Icono compuesto: Si Xm∩VL es no vacío. El icono x es de la forma ({OP, y1,...,yn}, imagen). En otras palabras, x está compuesto de subiconos y1,...,yn utilizando el operador OP.

Icono estructural: Si Xm∩VL es vacío. El icono x es de la forma ({y1,...,yn}, imagen), en

otras palabras, x está relacionada con subiconos y1,...,yn , pero el mecanismo para la composición de x de y1,...,yn no está especificado.

Una de las razones por las que el uso de iconos tiene un gran crecimiento, se debe a la facilidad para captar un mensaje visual, ya que la mente, cuando procesa imágenes, infiere relaciones sin necesidad de incluir texto en estas. Además, existen otras razones que nos invitan a iniciar la utilización de elementos visuales dentro de los medios ambientes de trabajo y desarrollo. Enseguida citamos algunas. a) Las figuras son más didácticas que las palabras como un medio de comunicación. Puede trasmitirse más información de una manera más concisa por unidad de expresión. b) Las figuras ayudan a entender y recordar. c) Las figuras pueden ser un incentivo para aprender a programar. d) Las figuras no tienen las barreras del lenguaje. Cuando son adecuadamente diseñadas, son entendidas independientemente del idioma que se hable. Con lo anterior no queremos decir que la meta de los lenguajes visuales sea representar todo tipo de ideas y acciones mediante iconos sin incluir en estas texto; la finalidad es usar de manera armónica los dos tipos de representación para integrar ideas más claras.


30

Debido a estas características el número de áreas en las que se pueden emplear los iconos como objetos de información es mayor. Una de estas áreas y la que nos interesa es la de computación. En ella recientemente se ha investigado acerca de medios ambientes de trabajo basados en iconos, y ambientes fundamentalmente visuales. Esta área es conocida actualmente como lenguajes Visuales (LV) o sistemas basados en iconos (SBI). Estos se encuentran dentro de la programación visual [CHA86]. En este tema de tesis se utilizaron iconos elementales para representar cada una de las instrucciones del diseño detallado, estos iconos tienen con una parte lógica y una parte física, además de los tributos asociados con los que cuentan. En el capítulo siguiente se hablará con más detalle de la gramática utilizada en el GenCod, así como del lenguaje visual que se realizó con este trabajo de investigación. 3.4 Programación visual La programación visual se distingue por lo que describe y como lo describe. Lo que describe son programas, expresados en términos de la sintaxis y semántica del lenguaje de programación. Cuando al menos algunos de los terminales de la gramática del lenguaje son gráficos, tales como pinturas, formas o animaciones, decimos que el lenguaje tiene una sintaxis visual. Una sintaxis visual puede incorporar información espacial tal como contenido o relación , y atributos visuales tales como localización o color. El texto puede además ser una parte de la sintaxis visual. Ejemplos de texto en una sintaxis visual son los comentarios textuales y etiquetas textuales de los nombre de los iconos. Ejemplos de lenguajes con una sintaxis visual incluye muchas clases de lenguajes diagramáticos, tales como lenguajes de flujo de datos o lenguajes de estados de transición, en la cual los nodos y arcos son los terminales. Otros ejemplos incluyen lenguajes iconicos en los cuales la composición espacial de los iconos son los terminales, utilizan la especificación de la composición de los tokens o las precondiciones y poscondiciones de las reglas de acción. Utilizamos el término lenguaje de programación visual (VPL), para significar un lenguaje con una sintaxis visual. La forma en la cual trabajan los programadores para crear, modificar y examinar programas, está definida por el ambiente de programación. El ambiente consiste de un conjunto de herramientas y una interfaz para que el usuario pueda accesar a ellas. Decimos que el sistema tiene un ambiente visual cuando las herramientas son gráficas y utilizan técnicas gráficas para la manipulación de elementos pictográficos y para desplegar la estructura del programa si fue originalmente expresado textual o visualmente[BUR95]


31

3.5 Lenguaje visual Vs. textual Los defectos de los lenguajes basados en texto son variables. Uno de estos se presenta en la forma de representar las variables. Las variables son símbolos para representar objetos desconocidos, estas tienen dos propósitos contradictorios: a)ellas ligan puntos de dónde se producen los datos y dónde se utilizan (nombres cortos preferentemente) y b) sus nombres dan información del modo en que se usan los datos (nombres largos preferentemente). En los lenguajes gráficos las variables pueden ser eliminadas usando un significado gráfico que indique todos los puntos en el programa donde se usa el mismo dato. Los elementos de una figura pueden ser agrupados en un mismo tipo dentro de un conjunto de figuras, lo cual puede ser además combinado con la forma de la figura. En un programa textual esta combinación agrupa símbolos adyacentes dentro de subfrases. Esta composición de dos frases textuales es su concatenación. Para una figura la composición es más complicada que la concatenación. La composición de una figura puede ser hecha con formas adyacentes, donde la adyacencia puede ser sin fundamento o completamente especificado (A arriba de B, A cerca de B, etc.). La composición puede además ser hecha a través de la conexión del elemento tal como dos segmentos de líneas con un punto en común. Tanto los lenguajes textuales, como visuales, están formados sobre un alfabeto básico y pueden ser descompuestos dentro de su estructura bien definida. Pero (a) una cadena de strings es unidimensional y tiene un orden lineal, y (b) para entender la estructura de un programa visual es a menudo un grafo direccionado, más que un árbol[PRO96]. 3.6 Estado del arte A continuación se mencionan algunas de las herramientas que pudiesen tener alguna relación con el tema de tesis que se presenta. 3.6.1 Visual magic Visual Magic es una herramienta que permite desarrollar y mantener software en el nivel de diseño, mediante un modelo ejecutable que valida la funcionalidad de una aplicación requerida. Después que el usuario refina la aplicación, puede generar código automáticamente de estos diagramas. Lo que significa que un usuario puede concentrarse en obtener el diseño, sin tener que preocuparse de escribir el código[VIS97].


32

3.6.2 Generador de ambientes visuales (VLCC) El VLCC (The Visual Language Compiler-compiler), es un prototipo gráfico para la generación automática de ambientes de programación y soporta la implantación de un lenguaje visual mediante la asistencia del diseñador, con la sintaxis del lenguaje, semántica y la definición gráfica de los objetos. La generación de procesos produce un ambiente integrado con un editor y un compilador para el lenguaje visual definido [CHA95]. 3.6.3 Microstep Microstep es un generador de aplicaciones basado en gráficos, que permite ir de especificaciones a programas ejecutables de forma automática. Este genera código en C, compilándolo y ligándolo automáticamente. Microstep esta diseñado para procesamiento de datos y manejo de aplicaciones principalmente por el flujo de datos entre procesos. Microstep está basado en un lenguaje gráfico que a su vez está basado en diagramas de flujo de datos similares a las de Yourdon. En Microstep se pueden crear diagramas de flujo de datos y definir los objetos individuales (estructuras y formatos) y procesos con un editor gráfico. Se puede especificar el flujo de control y un rango completo de lógica. Microstep verifica consistencia y sintaxis. Microstep soporta diagramas de flujo más grandes que una sola pantalla; se pueden utilizar herramientas zoom para moverse a través de tales diagramas. Las especificaciones pueden contener llamados a otras especificaciones hasta cinco niveles de profundidad. Estas características permiten construir sistemas grandes. En Microstep se construyen especificaciones computacionales y lógicas seleccionando operadores y funciones de menús pull-down [LEW90].

33

CAPITULO 4

DESCRIPCION DE LA GRAMATICA DEL GENCOD

En este capítulo se describe la gramática posicional que utiliza el GenCod, así como las modificaciones que se realizaron a la notación de diseño (Warnier), además de mostrar la estructura de datos que se utilizó.

Capítulo 4 Descripción de la gramática del GenCod

34

4.1. Antecedentes El sistema “Generador de código para lenguaje C utilizando una notación de diseño detallado” no es un proyecto aislado, éste forma parte de un proyecto emprendido recientemente en el Cenidet. A continuación se describe en forma general el objetivo de dicho proyecto: AMbiente integrado de soporte para la Administración y desarrollo de Sistemas de Software (AMASS-I) [Santaolaya96]: En fecha reciente, el Consejo Nacional de Ciencia y Tecnología (CONACYT) aprobó el apoyo financiero para este proyecto de investigación, asignándole la clave 0722P-A, a realizarse por el grupo de Ingeniería de Software del Cenidet. El sistema AMASS-I, consiste en un conjunto de herramientas de apoyo a los desarrolladores que estará organizado en forma modular para dar oportunidad de adicionar nuevas herramientas que sean desarrolladas después de contar con la primera versión de éste. Inicialmente, el sistema estará integrado de herramientas de las etapas del ciclo de vida del software menos atendidas como son las fases de diseño y generación automática de código, pruebas, mantenimiento y autodocumentación, en un ambiente visual de desarrollo, que tendrá la arquitectura presentada en la figura 4.1. De esta figura, la capa más baja indica que todas las herramientas que forman parte del sistema AMASS-I, están desarrollándose en una plataforma Windows. Las siguientes capas son los módulos o subsistemas principales que forman las herramientas del AMASS-I, éstas son: • Sistema visual generador de interfaces visuales (GenVIU), este sistema actualmente se

encuentra en desarrollo dentro del AMASS-I. El tipo de interfaces que generará este sistema estará enfocado a los ambientes de desarrollo de sistemas. En particular, el GenVIU permitirá generar una interfaz gráfica SAMI (sistema administrador de sistemas integrados) que posibilite a las herramientas que integran el AMASS-I y versiones posteriores comunicarse a través de protocolos perfectamente definidos.

• Generador de código (GenCod), este sistema parte de la definición gramatical de un

lenguaje visual basado en los símbolos diagramáticos de Jean D. Warnier para el diseño detallado de programas, de tal forma que el usuario pueda ir diseñando interactivamente un programa mediante la identificación visual de los símbolos de la notación de diseño de Warnier. La salida de este sistema genera por un lado un archivo que contiene el diseño detallado del programa de la aplicación particular en diagramas de Warnier, para su posterior uso en actividades de mantenimiento, y por otro lado también genera un archivo que contiene el código fuente en lenguaje ´C´, generado a partir de la aplicación hecha por el usuario.


35

Este sistema podrá accesar al sistema de recuperación de código reusable (este sistema también forma parte del AMASS-I) y regresar desde él, después de haber localizado e incorporado unidades de biblioteca, al proceso de desarrollo del programa de la aplicación. También podrá accesar al sistema documentador de software (este sistema también forma parte del AMASS-I) y regresar desde él, ésto lo podra hacer con la herramienta explicada anteriormente.

Autodocumentador de software (DaProg)

Plataforma windows

Aplicación

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

Generador de interfaces visuales (GenVIU)

Generador de código (GenCod)

Figura 4.1 Esquema conceptual por capas del AMASS-I. • Autodocumentador de software (DaProg), este sistema actualmente se encuentra en

desarrollo dentro del AMASS-I. Permitirá documentar interna y externamente programas de computadora escritos en lenguajes ´C´ (los cuales deben apegarse a un formato impuesto por la herramienta). 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 a detalle de funciones y procedimientos, especificando sus parámetros de entrada/salida, la búsqueda y reemplazo de nombres de variables, eliminación de identificadores o variables no utilizadas, y un archivo de índices del programa fuente. 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.


36

• Sistema de recuperación de código reutilizable (SisRec), este sistema utiliza depósitos de

componentes reutilizables y/o bibliotecas de funciones ya sean definidas por los lenguajes y/o aquellas que son desarrolladas de manera aislada por los programadores, para incorporar automáticamente código reusable; mediante la búsqueda, localización y recuperación, de segmentos de código o unidades de biblioteca, al desarrollo de nuevos programas de aplicaciones diversas, sin que se requiera de la modificación importante de tales bibliotecas y/o funciones. Se podrá accesar desde este sistema a los subsistemas de generación automática de código y autodocumentación, una para la construcción de bibliotecas y la otra para su documentación [SAN96].

4.2 Esquema conceptual del GenCod

Programa de aplicación

Analizador sintáctico Analizador semántico

Interfaz GráficaGramática posicional

Generador de código en C

Ayudas de la herramienta

A. léxicoA. sintáctico

Gramática del Leng. C

Interfaz gráfica

Figura 4.2 Esquema conceptual del GenCod El esquema conceptual del GenCod (Generador de código para lenguaje C utilizando una notación de diseño detallado) es mostrado en la figura 4.2. Este modelo representa gráficamente las capas que sirvieron de base para construir el GenCod. La primera etapa de este proyecto consistió en analizar la gramática del lenguaje de programación C, para posteriormente elaborar un analizador léxico y sintáctico de la gramática (anexo 3), estos dos analizadores son útiles al realizar el análisis de las entradas textuales que realiza el usuario, por ejemplo, las declaraciones de nombres de variables e identificadores.


37

De forma simultánea al desarrollo de estas dos primeras etapas se llevó a cabo una investigación de campo para determinar cuál metodología de diseño era la más conveniente de implantar en este proyecto de tesis (sección 2.3). Las siguientes tres capas que se muestran en el modelo conceptual del GenCod, forman las partes de un compilador visual. La primera es una gramática posicional basada en la metodología de diseño detallado de Warnier, se le denominó posicional porque la gramática toma como referencia un espacio bidimensional en el cual se “distribuyen” los elementos que componen un diseño elaborado con esta metodología. La segunda capa constituye la creación de la interfaz gráfica del sistema, ésta se realizó implícitamente al implantarse la gramática posicional. Aunado a esto se llevó a cabo la tercera capa, formada por el analizador sintáctico y semántico de la gramática posicional. Se debe mencionar que el compilador que se implantó para este proyecto de tesis no cuenta con un analizador léxico debido a que se está hablando de un compilador visual, el cual difiere de los compiladores lineales en que el primero de estos no necesita ir formando unidades léxicas sino que cada elemento que compone a la gramática es una unidad léxica (de esto se hablará más ampliamente a lo largo de este capítulo). La siguiente capa del modelo conceptual la forma el generador de código, en esta parte del sistema se traduce la notación de diseño detallado a código en lenguaje C. La capa siguiente está constituida por una serie de herramientas incluidas en este sistema, tales como: el sistema de navegación, el sistema de impresión del diseño, el sistema de ayudas al usuario (hipertexto) y el sistema de buenos hábitos de programación [PAZOS]. Este último valida lo siguiente: que no sea posible hacer declaraciones de variables de una sola letra, que no se permita declarar una variable si ésta no cuenta con al menos tres letras al inicio y, por último, que no pueda haber más de tres ciclos anidados del mismo tipo. La capa más externa del modelo conceptual es la del programa de aplicación que constituye al GenCod. 4.3 Un lenguaje gráfico para la representación de una notación de

diseño Una vez que se determinó la notación de diseño a utilizar (notación de Warnier) y la forma como se iba a representar (un ambiente gráfico), se hizo necesario diseñar un lenguaje que permitiera unir ambos conceptos sin que perdieran sus atributos principales, lo cual implicó definir una gramática que soportara a este lenguaje. La gramática definida para este tema de tesis será expuesta en las secciones posteriores. El primer paso para construir un lenguaje gráfico para la representación del diseño fue realizar algunas modificaciones a los componentes u objetos gráficos que forman la notación de diseño detallado de Warnier, estas modificaciones consistieron en: a) modificar aquellos


38

símbolos gráficos que determinamos (en reunión con el Grupo de Ingeniería de Software del cenidet) que carecían de la expresividad suficiente como para ser entendidas por un gran número de desarrolladores y b) agregar símbolos gráficos a aquellas instrucciones que no tenían una representación en la metodología de Warnier, pero que se necesitaban para el desarrollo de un sistema, un caso de esto fueron las instrucciones de escritura o lectura, que no tienen una contraparte simbólica en la notación Warnier original. En la siguiente sección se expondrán las modificaciones a la notación. A estas modificaciones que se realizaron no se afectó el principio de organización jerárquica con el que cuenta Warnier, esta organización puede interpretarse de la siguiente manera (figura 4.3). El conjunto de informaciones C se subdivide en subconjuntos de primer nivel S1

1..., S1n (el nivel viene señalado por el índice superior). Estos se subdividen a su vez, en

subconjuntos de segundo nivel S21,1...,S2

1,K1..., S2n,1..., S2

n,Kn y así sucesivamente hasta agotar la partición.

C

S 11

S 1n

S 21,1

S 2n ,1

S 21 ,K 1

S 2n ,K n

N IV E L 1 N IV E L 2

Figura 4.3 Principio de la organización jerárquica Para efectos de esta tesis se determinó dividir cada uno de los conjuntos de informaciones en objetos activos y pasivos, de tal forma que sea posible diferenciarlos entre sí: los objetos activos son aquellos que generalmente llevan implícitos un conjunto de instrucciones, por ejemplo, si hablamos de un ciclo de repetición, éste es un objeto activo porque dentro de él pueden existir n conjuntos de instrucciones, que se van a estar ejecutando, por lo tanto se dice que un objeto activo puede contener n conjuntos de objetos activos, pasivos o ambos, dando paso a la formación de los niveles de abstracción; mientras que un objeto pasivo es aquel que no puede contener a otros objetos, por ejemplo las instrucciones secuenciales: las instrucciones de entrada (scanf), salida (printf), etc.


39

4.3.1 Notación de diseño detallado modificada Como se mencionó anteriormente, se tuvieron que hacer algunas modificaciones a la notación de diseño de Warnier para hacerla más intuitiva al usuario para su manejo. Por lo tanto se obtuvo una notación de diseño más gráfica. En la figura 4.4 se muestra una tabla con las modificaciones que se hicieron a la notación de diseño detallado de Warnier, en esta figura solamente se maneja la construcción básica de la secuenciación que abarca las siguientes instrucciones:

Instrucción1,

Instrucción2,...Instrucción n

Secuencia

Notación deWarnier (ejemplos)

cadena

a) instrucciónde entrada

Escribe Cadena

variableLee variable

b) instrucciónde salida

clrscr();

c) instrucción pararepresentar laterminación delconjunto de instruccinesque integran un objetoactivo.

d) El indicador de laimplantación de unlenguaje dado no existe

Construcciónbásica

tipo deinstrucción

Notación de Warnier

Modificada(ejemplos)

No existe (sólo elindicador del nivel de

abstracción)

No existe surepresentación

Figura 4.4 Tabla que muestra las modificaciones hechas a la notación de diseño

de Warnier en la secuencia.

a) Instrucción de entrada. A esta instrucción solamente se agregó un símbolo gráfico, de un libro abierto, con el cual se pretende que el usuario de la herramienta GenCod asocie este símbolo con una lectura. b) Instrucción de salida. Al igual que la instrucción anterior, solamente se agregó a ésta un símbolo gráfico (un lápiz). c) Fin del ciclo. Esta instrucción fue agregada a la notación de diseño e indica la terminación del conjunto de instrucciones que forman parte de un objeto activo. d) Texto en C. Esta nueva notación de diseño, es independiente de cualquier lenguaje de programación excepto por este icono. Esta instrucción o icono fue diseñado con el propósito de darle más facilidades al desarrollador, que ya conoce el lenguaje C, además de hacer a la notación más extensa, ya que las notaciones de diseño detallado generalmente sólo incluyen las construcciones básicas. Cuando el usuario elija esta instrucción tiene que escribir sintácticamente bien, alguna función del lenguaje de programación C, que desee incluir dentro de su diseño. Esta instrucción tiene asociado el símbolo gráfico mostrado en la figura 4.4 inciso d (ver columna etiquetada con el texto instrucción). Sin embargo el empleo de esta instrucción no es obligatoria para el desarrollo del diseño.


40

Pasando a las modificaciones que se hicieron a la construcción básica de la bifurcación, podemos notar que en ésta hubo varios cambios: 1. Se agregó la instrucción de la bifurcación simple, ya que en la notación de diseño de Warnier, ésta no existe. Esto se hizo con el fin de eliminar el conjunto vacío que se colocaba cuando no existía una condición negada. 2. Se agregó un símbolo gráfico a todas las condiciones. También a las condiciones negadas se les ha agregado un símbolo gráfico, estos símbolos se pueden observar en la tercera columna de la figura 4.5. 3. Se eliminó el símbolo (or exclusivo), de la notación de Warnier que existía entre dos condiciones de una bifurcación compuesta o múltiple (figura 4.5 inciso b y c), ya que lo lleva implícito el símbolo .

Condicional

Notación de Warnier(Ejemplos)

a) Simple no existe

b) Compuesta

Construcción básica Instrucción Notación de Warnier Modificada (ejemplos)

c) Múltiple

Proc 1condición

Proc1condición

condición Proc 2

condición1 Proc1

condición2Proc2

condiciónn Proc n

condición1

condición2

Proc ncondición n

Proc2

Proc1

condición

Proc2

Proc1

condición

Figura 4.5 Tabla que muestra las modificaciones hechas a la notación

de diseño de Warnier en la bifurcación. Pasando a la construcción básica de la repetición, también se hicieron algunos cambios, estos fueron: a) Se eliminó la información entre los paréntesis (r) de la notación de Warnier (figura 4.6 inciso a y b). b) El paréntesis que indica la condición del ciclo en el diagrama de Warnier, fue reemplazado por un símbolo gráfico, el cual tiene la forma de un asterisco y la posición de éste indica la instrucción a ejecutar, por ejemplo si el asterisco se encuentra al principio del conjunto de instrucciones que forman ese nivel de abstracción (figura 4.6 inciso a), entonces la instrucción


41

estará actuando como un while (del lenguaje de programación C), pero si el asterisco se encuentra al final del bloque de instrucciones (figura 4.6 inciso b), entonces estará actuando como un ciclo do while, pero si el asterisco con la condición se encuentra en un nivel de abstracción anterior a un conjunto de instrucciones (figura 4.6 inciso c, columna “notación de Warnier modificada”), entonces se estará comportando como un ciclo for (del lenguaje de programación C).

Repetición

Notación de Warnier(ejemplos)

a) Hacer instrucción 1 instrucción 2mientras (condición)

Construcción básica Instrucción Notación de Warnier

modificada (ejemplos)

sentence 1

sentence 2

condición instrucción 1instrucción 2no existe

b) mientras (condición ) instrucción 1 instrucción 2fin mientras

c) Para (expresión) hasta (condición)

expresión

instrucción 1instrucción 2

condición*condicióninstrucción 1instrucción 2

(r)

expresión

instrucción 1instrucción 2 *condición

(r)

expresión expresión

instrucción 1

condición

instrucción 2

Figura 4.6 Tabla que muestra las modificaciones hechas a la notación

de diseño de Warnier en la repetición. 4.4 Algunas ventajas que ofrecen las gramáticas Antes de hablar de la gramática que se utilizó para la construcción de la herramienta que se muestra en esta tesis, se mostrarán algunas ventajas significativas que ofrecen las gramáticas a los diseñadores de lenguajes y a los escritores de compiladores. • Una gramática da una especificación sintáctica precisa y fácil de entender de un lenguaje de

programación. • A partir de algunas clases de gramáticas se puede construir automáticamente un analizador

sintáctico eficiente que determine si un programa fuente está sintácticamente bien formado. Otra ventaja es que el proceso de construcción del analizador sintáctico puede revelar ambigüedades sintácticas y otras construcciones difíciles de analizar que, de otro modo podrían pasar sin ser detectadas en la fase inicial de diseño de un lenguaje y de su compilador.


42

• Una gramática diseñada adecuadamente imparte una estructura a un lenguaje de programación útil para la traducción de programas fuente a código objeto correcto y para la detección de errores.

• Los lenguajes evolucionan con el tiempo, adquiriendo nuevas construcciones y realizando

tareas adicionales. Estas nuevas construcciones se pueden añadir con más facilidad a un lenguaje cuando existe una aplicación basada en una descripción gramatical del lenguaje[Aho90].

4.4.1 Convención de la notación de la gramática Para evitar confusiones en la formalización de la gramática que se explica en la siguiente sección, se presenta a continuación una convención de notación de las gramáticas propuesta por Alfred V. Aho, [AHO90] la cual se ha ajustado a la formalización de la gramática propuesta. 1. Son símbolos terminales: a) Las letras que se encuentren entre comillas “”. b) Los símbolos gráficos. c) Las letras escritas en minúsculas. 2. Son símbolos no terminales: a) Las letras escritas en mayúsculas. b) La letra S, que cuando aparece suele ser el símbolo inicial. c) Los símbolos gráficos que se encuentran encerrados en un cuadro. 3. Las letras griegas minúsculas, α, β por ejemplo, representan cadenas de símbolos gramaticales. Por tanto, una producción genérica podría escribirse A →α, indicando que hay un solo no terminal A a la izquierda de la flecha (el lado izquierdo de la producción) y una cadena de símbolos gramaticales a la derecha de la flecha (el lado derecho de la producción). 4. Si A →α1, A → α2 ,..., A → α1k son todas las producciones con A a la izquierda (se les llama producciones de A), se puede escribir A → α1 α2 ... αk donde α1, α2,..., αk se denominan alternativas de A. 5. A menos que se diga otra cosa, el lado izquierdo de la primera producción es el símbolo inicial.


43

4.5 Descripción de una gramática Muchos formalismos han sido propuestos para describir el analizador sintáctico de los lenguajes visuales[CHA87]. Pero para la formalización de esta gramática, se han utilizado los conceptos básicos que utiliza Chang, quien comenta que las gramática posicionales constituyen una extensión de las gramáticas lineales [CHA95]. El sistema GenCod está soportado por la gramática posicional independiente de contexto que a continuación se describe. La gramática se compone de una tupla de seis elementos.

G = ( N, T, S, P, POS, PE ) donde: N = Símbolos no terminales. T = Símbolos terminales S = Símbolo inicial. P = Reglas de producción. POS = Relaciones binarias de identificadores. PE = Es un evaluador pictográfico que convierte formas de instrucciones en sus representaciones visuales. 4.5.1 Símbolos no terminales Los símbolos no terminales, son variables sintácticas que denotan conjuntos de cadenas. La lista de símbolos en la figura 4.7 representan símbolos no terminales, éstos definen conjuntos de cadenas que ayudan a generar el lenguaje generado por la gramática. También imponen una estructura jerárquica sobre el lenguaje que es útil tanto para el análisis sintáctico como para la traducción [AHO90].

N={<S>, <VAR>, <TXTC>, <CADVAR>, <PARAMVAR>, <ELSE>,<ELSEOP>, <SECUENCIAS>, <INSTRUCCINES>, <CONDCICLO>, <SWITCH>, <DEFAULT>, <DECFUN>, <PRINTF>,

<SCANF>, <LLAMADA>, <IFCOMP>, <WHILE>, <DOWHILE>, <FOR> }

Figura 4.7 Conjunto de símbolos no terminales. 4.5.2 Símbolos terminales Los terminales son símbolos básicos con que se forman las cadenas. “Componente léxico”, es un sinónimo de “terminal” cuando se trata para gramáticas de lenguajes de programación[AHO90].


44

En la figura 4.8 se muestra la lista de símbolos terminales que conforman la notación de diseño detallado, algunos de los símbolos terminales no son gráficos, debido a que dentro de la notación de diseño, existe también texto que sirve para complementar al diseño. Por ejemplo el nombre de la función, las condiciones, etc.

T = { , , , , , , , , “Nombre función”, ”Nombre variables”, “Cadena”, “Condición”, ∈}

Figura 4.8 Conjunto de símbolos terminales.

Los símbolos terminales T mostrados anteriormente son todos aquellos que componen la notación del diseño detallado. Algunos de estos símbolos varían su significado de acuerdo a la posición en la que se encuentren y, a los atributos que tengan asociados. Por ejemplo, el símbolo

sirve para representar la declaración de una función y también representa la llamada a una función. 1 Este símbolo con el subíndice 1 representa la declaración de una función. 2 Este símbolo con el subíndice 2 representa la llamada de una función. 1 Este símbolo con el subíndice 1 representa una instrucción selección simple. 2 Este símbolo con el subíndice 2 representa una instrucción selección múltiple. 1 Este símbolo con el subíndice 1 representa a la instrucción selección simple negada. 2 Este símbolo con el subíndice 2 representa a la instrucción selección múltiple negada. 1 Este símbolo con el subíndice 1 representa a un ciclo iterativo sin condición. 2 Este símbolo con el subíndice 2 representa a un ciclo iterativo condicional (MIENTRAS condición). 3 Este símbolo con el subíndice 3 representa a un ciclo iterativo condicional (HACER MIENTRAS condición ).

Figura 4.9 Tabla de símbolos gráficos con su subíndice asociado dependiendo del significado.

En la formalización de la gramática G a todos los símbolos terminales gráficos, se les ha asignado un subíndice que indica, cuál es su significado en cada una de las reglas de producción (figura 4.9). Existen símbolos terminales gráficos con un solo significado ( , , , ), estos símbolos tienen como subíndice el número cero.


45

4.5.3 Símbolo inicial En una gramática, un no terminal es considerado como el símbolo inicial, y el conjunto de cadenas que representa es el lenguaje definido por la gramática[Aho90]. En la gramática G el símbolo inicial está representado por la letra S. 4.5.4 Reglas de producción Las producciones de una gramática especifican cómo se pueden combinar los terminales y los no terminales para formar cadenas. Cada producción consta de un no terminal seguido por una flecha, seguida por una cadena de símbolos no terminales y/o terminales[Aho90]. Repasando lo que se había mencionado anteriormente: las gramáticas posicionales son una extensión de las gramáticas lineales, por lo tanto podemos ver un incremento de nuevas características a las reglas de producción P. Enseguida se muestra la forma general de las reglas de producción de una gramática visual.

A X1w1R

j1X

2w2R

j2X

iwi... R

j nX n wn ,

Donde i = 1,2,3,4,....,n y A es un símbolo no terminal, cada Xi

w puede ser un símbolo terminal o no terminal, el superíndice i identifica a cada objeto (icono o texto) en las reglas de producción. El subíndice w es escrito después de cada símbolo terminal gráfico y es utilizado para identificar su significado (ver figura 4.9). Rj es una relación compuesta de la forma:

( REL1h1,..., RELihi ,..., RELnhn ) con n >= 1

Cada RELihi denota un par (RELi,hi) donde RELi, es una relación en POS denotando las relaciones posicionales que tiene un objeto con respecto a otro; hi muestra el objeto con el cuál se tiene relación, el valor de hi se obtiene de xj-k en donde j corresponde al valor secuencial que tiene el símbolo gramatical actual y k corresponde al valor secuencial que tiene el símbolo gramatical con el cual se relaciona[CHA95]. Un ejemplo de una regla de producción del GenCod: DECFUNCION 1

1 ABAJO11 “nombre función”2 DERECHA2

2 <INSTRUCCIONES >3

ABAJO13 40


46

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

1, donde el superíndice 1 en el símbolo terminal, representa el valor de posición secuencial con respecto a la regla de producción, por lo tanto la relación con el símbolo <INSTRUCCIONES >3 estará de la forma Xk RELj-k Xj, en donde j=3 y k=1 porque el valor secuencial del símbolo con el cual se va a relacionar es 1, por lo tanto la relación quedaría DERECHA3-1. El símbolo representa a las reglas semánticas dentro del compilador espacial. También se debe mencionar que en cada regla de producción se encuentra un símbolo no terminal de lado izquierdo y del lado derecho se encuentran las reglas que se derivan de ese símbolo y para que se pueda cumplir esa regla, también se deben cumplir las derivaciones que ésta tenga. Estas derivaciones son el resultado de cada una de las relaciones cuádruples que tiene cada uno de los símbolo terminales gráficos, de las cuales se hablará en la siguiente sección. 4.5.4.1 Relaciones cuádruples de identificadores (POS). Cada símbolo tiene relaciones cuádruples con respecto a los demás identificadores, estas relaciones ubican al objeto dentro de un plano cartesiano de 2-D con respecto a otros objetos, estas relaciones son : ARRIBA, ABAJO, DERECHA e IZQUIERDA , cada una de estas relaciones son un par de coordenadas qué muestran, que es lo que se encuentra alrededor de un objeto, además de indicar la posición en la que se encuentra dentro de la pantalla. Estas relaciones es a lo que se refiere el término POS de la gramática posicional. Por ejemplo: la regla de producción descrita arriba puede verse en la siguiente figura 4.10, donde se muestran los símbolos terminales y no terminales junto con las relaciones que existen entre estos. Se debe aclarar que con esta figura sólo se pretende ilustrar la secuencia de una regla de producción. DERECHA2

2 <INSTRUCCIONES> ABAJO1 1 ABAJO1

3 “nombre”

Figura 4.10 Ejemplo de una regla de producción.


47

4.5.4.1.1 Relaciones cuádruples de los símbolos terminales de la gramática En la sección anterior se describió en qué consisten las relaciones entre los símbolos gramaticales, en esta sección se explicará cuáles son las relaciones que tiene cada símbolo terminal con respecto a los demás. En la sección 4.5.2, se mencionó que en esta gramática existen símbolos terminales con diferente significado y para poder identificarlos se les añadía un subíndice. Para explicar las relaciones de los identificadores se va hacer uso de la tabla que se encuentra en esa sección figura 4.9. a) Declaración de una función

El símbolo terminal asociado a la declaración de una función es el siguiente: En la gramática que se encuentra en el anexo 2 podemos ver que este símbolo es el primer símbolo terminal gráfico con el que se inician las reglas de producción, y es el símbolo del cual se derivan todos los demás símbolos terminales que forman la gramática posicional; es decir este símbolo siempre va a constituir el primer nivel dentro de la notación de diseño, por lo tanto sus relaciones con los demás objetos son: abajo e izquierda. Sus relaciones son: ABAJO : “nombre de la función” IZQUIERDA: 2 | 0 | 0 | 0| (1,2) | (1,2) | (1,2,3)| 0 b) Llamada de una función El símbolo terminal asociado a la llamada de una función es el siguiente: El símbolo terminal que representa la llamada de una función es un símbolo pasivo que como tal no ocasiona un nivel, por lo tanto en su relación a la derecha no tiene ningún símbolo terminal asociado. Sus relaciones son: ARRIBA : 0 | 0 | 0| 0 | 1 ABAJO : “el nombre de la función” IZQUIERDA : 1 | (1,2) | (1,2) | (1,2,3)


48

c) Instrucción de salida

El símbolo terminal asociado a una instrucción de salida de una función es el siguiente:

Este símbolo terminal también es un símbolo pasivo, pero a diferencia del símbolo anterior, éste tiene asociado a su derecha una cadena o una variable la cual forma parte de sus atributos asociados a este objeto (estos atributos serán explicados en la siguiente sección). Sus relaciones son: ARRIBA : 0 | 0 | 0| | 2

ABAJO : 2 | 0 | 0 | 0| 0 | (1,2) | (1,2) | (1,2,3)

DERECHA : “cadena” | variable

IZQUIERDA : 1 | (1,2) | (1,2) | (1,2,3) d) Instrucción de entrada

El símbolo terminal asociado a una instrucción de entrada de una función es el siguiente:

Las relaciones cuádruples de este símbolo son las mismas que el símbolo anterior (instrucción de salida), la única diferencia es que este símbolo sólo tiene asociado a su derecha el nombre de una variable. e) Instrucciones: condicional simple, múltiple y condicional negada

El símbolo terminal asociado a la instrucción condicional simple y múltiple es el siguiente: . El símbolo terminal asociado a la instrucción condicional negada es el siguiente: Estos símbolos terminales tienen diferente representación (ver figura 4.9), pero sus relaciones cuádruples son las mismas, por lo tanto se explicarán sólo una vez para todos ellos. Sus relaciones son: ARRIBA : 0 | 0 | 0| 0 | 2

ABAJO : “condición”

IZQUIERDA : 0 | 0 | 0| 2 | (1,2) | (1,2) | (1,2,3)| 0

DERECHA : los objetos que pueden tener a la derecha son los mismos que tiene en su relación izquierda.

f) Instrucciones: ciclos condicionales


49

El símbolo terminal asociado a los ciclos condicionales (mientras<condicion>, repetir mientras <condición>, para hasta <condición>) es el siguiente: . Estos símbolos terminales tienen diferente representación (ver tabla 4.9), y sus relaciones cuádruples son las mismas, que los símbolos anteriores 4.5.4.2 Atributos de los objetos Otra cosa que hace diferentes a las gramáticas visuales de las gramáticas lineales son los atributos que tienen asociados los símbolos terminales gráficos. Estos atributos proporcionan información adicional a cada símbolo. Los símbolos gráficos que componen la gramática G tienen algunos atributos en común, estos son: * Tipo de instrucción. * Tipo de bitmaps. * Coordenadas arriba del objeto (x,y) * Coordenadas abajo del objeto (x,y) * Coordenadas derecha del objeto (x,y) * Coordenadas izquierda del objeto (x,y) * cadena Los atributos (tipo de instrucción y tipo de bitmaps) representan al nombre lógico de cada bitmap, y el cuarteto de coordenadas (x,y) representan las relaciones que tiene el símbolo con respecto a otros símbolos, además de ubicar a cada símbolo dentro de un plano cartesiano de 2-D. El atributo cadena sirve para almacenar información, la cual depende del tipo de instrucción al que represente, por ejemplo si se trata de la declaración de una función, en esa cadena se va a almacenar el nombre de la función, en caso de que se trate de un ciclo en esa cadena se almacenará la condición, etc. En seguida se muestran los atributos adicionales que tienen cada uno de los símbolos terminales gráficos. • Atributos de la declaración de una función: * Tipo de la función * parámetros {tipo dato, nombre, tipo parámetro} • Atributos de la llamada de una función: * parámetros {Tipo dato, nombre, tipo Parámetro}


50

• Atributos de las instrucciones de entrada y salida: * Variables (este símbolo puede tener asociado varias variables) • Atributo de las instrucciones condicional simple, múltiple, condicional negada y

los ciclos: * Condición 4.5.5 Evaluador pictográfico (PE) PE es un evaluador pictográfico donde se encuentran las reglas semánticas que se utilizarán dentro del compilador, aquí se definen las posiciones que deberá tomar cada objeto de acuerdo a la relación que tenga con los demás objetos, a diferencia de un compilador lineal donde se encuentran las instrucciones para generar el código. 4.6 Estructura de datos que maneja el GenCod Para la implantación de la gramática G fue necesario que ésta estuviera respaldada por una estructura de datos que soportara los atributos y objetos que maneja dicha gramática posicional. En la figura 4.11 se muestra un panorama de la estructura de datos que utiliza el GenCod, éstas son: * un lista doblemente ligada en donde se almacenan los datos de las variables globales, como son: el nombre de las variables, su tipo de dato y el tiempo de vida de la variable. * una lista doblemente ligada la cual está apuntada por un arreglo. En esta lista se almacena la información de las variables locales (la información que se almacena es parecida a la lista de las variables globales). * un arreglo de 50 posiciones en donde se almacena la información de las diferentes funciones que componen todo el diseño detallado, además de la información referente a cada ventana (que representa a cada función).


51

Objetos

Variables globales

Atributos de los objetos

Variables locales

.

.

.

Figura 4.11 Estructura de datos del GenCod.

* una lista doblemente ligada donde se almacena la información de los objetos que forman el diseño detallado, en cada uno de los nodos se almacenan los atributos de los objetos, como son: la posición del objeto dentro de un espacio, el tipo de instrucción, el tipo de bitmap que va a utilizar y los atributos con los que cuente este objeto, además puede contar con una lista doblemente ligada que contiene información asociada al objeto. En la siguiente sección se hablará más ampliamente de esta estructura. * una lista doblemente ligada que almacena la información de los atributos de los objetos esta lista va a estar apuntada por la lista de los objetos. 4.6.1 Estructura de datos de la lista de objetos

Número

de

instrucción

Número

de

Bitmap

Coord.

Dcha X

Coord.

Dcha Y

Coord.

ArribaX

Coord.

Izq X

Coord.

Arriba Y

Coord.

AbajoX

Coord.

AbajoY

Coord.

Izq . Ynormal tipo

función Cadena

Apuntadorhacia el nodoanterior

Apuntador hacia la lista de losatributos de los objetos

Apuntador hacia elnodo siguiente

Figura 4.12 Modelo conceptual de los nodos de la lista de objetos


52

La estructura de los nodos de la lista de objetos (figura 4.12) se muestra a continuación: typedef struct { int nInstruc; int nBmp; int DerechaX; int DerechaY; int IzquierdaX; int IzquierdaY; int ArribaX; int ArribaY ; ; Coordenadas int AbajoX; int AbajoY int ArribaModifX; int ArribaModifY; int NormalBmp; int Tipo; char Cadena[80]; struct OBJECTDATA *AptNext; struct OBJECTDATA *AptAnt; struct LISTAVARS *AptArgs; } donde: nInstruc = Es una variable de tipo entera que almacena el tipo de instrucción que representa ese nodo, el valor que contenga se va a tomar de la siguiente tabla de comparación (Figura 4.13).

Instrucción Identificador numéricoFUNCION 0 DECLARA 1 TXTC 2 LLAMADA 3 PRINTF 4 SCANF 5 IF 6 SWITCH 7 CASE 8 ELSE 9 WHILE 10 DOWHILE 11 FOR 12 FIN 13

Figura 4.13 Tabla de identificadores para el número de instrucciones.


53

nBmp = Al igual que la variable anterior ésta también es de tipo entera, y almacena el tipo del bitmap que representa a la instrucción de la que se trate, es decir, almacena el nombre físico del objeto, que en realidad también lleva el número del identificador de la tabla de la figura 4.13, ese número corresponde al índice de un arreglo, en el cual se encuentran todos los nombres de los bitmaps. DerechaX, DerechaY, IzquierdaX, IzquierdaY, ArribaX, ArribaY, AbajoX, AbajoY, ArribaModifX, ArribaModifY (Coordenadas) = Almacenan las relaciones de cada objeto. ArribaModifX, ArribaModifY = Estos dos campos almacenan las coordenadas modificadas del objeto cuando el objeto tiene que cambiar de posición, esto ocurre cuando se trata de un objeto activo, que necesita volver a calcular sus coordenadas con respecto a los objetos que forman parte de él (Esto será explicado más adelante en la sección de ajuste de objetos). NormalBmp = Este campo sirve como una bandera para realizar el borrado de algún objeto, el campo siempre estará inicializado en 0, de otra manera indica que el objeto tiene que ser eliminado de la lista (la función de este campo se verá más ampliamente en la sección de borrado de objetos). Tipo = En este campo se almacena el tipo de la función. El valor de este campo corresponde a un indicador numérico; el cual es el índice de un arreglo (TposDtos), en donde se encuentran todos los nombres de los tipos de datos. Como se mencionó anteriormente en esta estructura se guarda la información de la declaración de variables y de los argumentos (que se hablará posteriormente), por lo tanto en esta variable de tipo entero, se almacena el tipo de la variable, colocándose un indicador numérico que corresponde al índice de un arreglo en donde se encuentran los nombres de los tipos de datos. Cadena = En este campo se almacena distinta información, ésta va a depender del tipo de instrucción que tenga el nodo. Por ejemplo si el número de la instrucción corresponde a una función, entonces en este campo se almacenará el nombre de la función, pero si la instrucción corresponde a un printf, entonces aquí se almacenará la cadena que se desea imprimir en pantalla. 4.6.2 Estructura de datos de la lista de argumentos La estructura que se presenta en la figura 4.14, es la misma que se utiliza para almacenar la información de las variables locales, globales y los argumentos de los objetos.


54

TipoApuntadorhacia el nodoanterior

Apuntador hacia elnodo siguiente

Variable alcance

Figura 4.14 Modelo conceptual de los nodos de la lista de variables

La estructura de los nodos de la lista de argumentos (figura 4.14) se muestra a continuación: typedef struct{ int Tpo; char Variable[25]; char alcance[8]; struct LISTAVARS *AptNext; struct LISTAVARS *AptLast; } donde: Tpo = En esta estructura se guarda la información de la declaración de variables y de los argumentos, por lo tanto en esta variable de tipo entero, se almacena el tipo de la variable, el cual corresponde al índice del arreglo TposDtos. Variable = En esta cadena se almacena el nombre de la variable, en caso de que se trate de un argumento o parámetro, se guarda el nombre de éste. alcance = En este campo se almacena el alcance que tiene una variable, por ejemplo se almacena la palabra “static”, en caso de que se trate de un parámetro formal, se guarda el caracter del tipo del parámetro, por ejemplo si es por referencia se almacena un *, y si se trata de un parámetro real por referencia, se almacena el símbolo &. 4.6.3 Estructura de datos del arreglo de listas La figura 4.15 muestra la estructura de una posición del arreglo de listas, en el cual se almacena toda la información referente a la interfaz del sistema GenCod, además de la información específica de cada una de las funciones que existan dentro del diseño detallado.


55

Apuntadorhacia lasvariables

Apuntador hacialos objetos

Arr

Bmp

FunX

TopY RightX BottomYLeftX Edo NumWin caduno

[120]

Arr

Bmp

FunY

caddos

[120]

cadtres[120]

Figura 4.15 Modelo conceptual de los nodos del arreglo de listas Enseguida se muestra la declaración de esta estructura. typedef struct{ struct OBJECTDATA *AptObjs; struct LISTAVARS *AptVars; int ArrBmpFunX; int ArrFuncionY; int LeftX; int TopY; Coordenadas del área cliente int RightX; int BottomY; int Edo; int NumWin; char caduno[120]; char caddos[120]; Comentarios de la función char cadtres[120]; } ArrBmpFunX, ArrFuncionY = Estas dos coordenadas almacenan la información de las coordenadas de arriba de la posición en la que se encuentra el bitmap de la función. LeftX, TopY, RightX, BottomY (Coordenadas del área del cliente) = Almacenan las coordenadas del área del cliente, en el momento de crear una nueva función. Edo = Este campo almacena el estado de cada una de las funciones (el autómata que se menciona, se encuentra ilustrado en la figura 4.16). Por ejemplo, en caso de que una función que se está ejecutando tenga que interrumpirse por el llamado de otra función, se debe almacenar el estado en el cual se encuentra, para que cuando vuelva a ser llamada continúe en el estado en el cual se quedó.


56

1 20 Función

secuencial,bifurcación,repetición.

Fin deldiseño

Figura 4.16 Autómata empleado por el GenCod. NumWin = Esta variable guarda el número de la ventana que le corresponde a cada una de las funciones. caduno, caddos, cadtres (Comentarios) = El sistema GenCod permite que el usuario documente cada una de sus funciones, para esto tiene una opción para realizar estos comentarios, los cuales son almacenados en estas tres variables de tipo cadena. 4.7 Interfaz gráfica implantada en el sistema GenCod A continuación se presenta una descripción de los elementos que forman la interfaz del GenCond, explicando en algunos de los casos especiales el porqué de la elección de una técnica en particular. 4.7.1. Interfaz con múltiples documentos (MDI) Las interfaces con múltiples documentos permiten trabajar en una sola aplicación con múltiples ventanas hijas que tendrán todas las mismas funciones pero diferentes atributos asociados. Tanto la ventana principal como las ventanas hijas cuentan con barra de títulos, barras scroll, botones de maximizar, minimizar e iconos. Una de las diferencias entre la ventana principal y las ventanas hijas es que, las ventanas hijas solo pueden moverse dentro de la ventana principal (área cliente), además sólo la ventana principal tiene menú. El administrador de archivos (File Manager) para Windows en Windows 3.1 y el SysEdit de Windows 3.0 son ejemplos de MDIs [Farrell92]. En la figura 4.17 se muestra un ejemplo de un editor de un programa que utiliza los MDI´s como interfaz.


57

<sin título>

Archivo Editar Buscar Ventana

Programa Editor

marco de la ventana

barra de desplazamientode la ventana hija

barra de menú de la ventana padrebarra de título de la ventana padrebarra de título de la ventana hija

una de las muchasposibles ventanas

espacio para otrasventanas hijas

botones de la ventana padre

botones de la ventana hija

Figura 4.17 Editor de un programa MDI En el desarrollo de esta tesis fue necesario utilizar la técnica de los MDI´s con la finalidad de hacer más práctico el GenCod, esto es, se necesitaba que existiera un mecanismo que permitiera crear múltiple ventanas para contener a las múltiples funciones que pueden integrar un programa escrito en lenguaje C. Se requería que cada ventana pudiera representar una función, y que por lo tanto, todas estas ventanas tuvieran la misma finalidad, pero cada una conteniendo una parte del diseño detallado del sistema. 4.7.2. Interfaz del GenCod La interfaz del GenCod (figura 4.18) cuenta con un menú y una paleta de botones, en donde se encuentran representados en forma gráfica los símbolos de la notación de diseño detallado de Warnier (estructuras de decisión, iteración, llamadas a funciones, etc.). También cuenta con una ventana de edición donde se construye el diseño detallado especificado por el usuario. Como se mencionó en la sección anterior, en esta interfaz que emplea la técnica de MDI´s pueden existir tantas pantallas de edición como funciones tenga el programa.


58

Cada una de estas ventanas de edición posee las características básicas de cualquier ventana en windows: minimización, maximización, colocar las ventanas en cascada, dividir las ventanas, etc. Esto da una amplia flexibilidad al sistema, en el sentido que un usuario puede tener siempre visible todas las funciones que integran su sistema.

Archivo Opciones Editar V entana Ayuda

GenCod

main

Pide_datos

Menú

Paleta de botones

Diseño detallado

Opcion=‘s’

SearchMin

num1=num2

num1>num2

num1>num2

num1

hola

Op

num2

Nombre dela función

main

Pide_datos

Figura 4.18 Interfaz del GenCod El menú del GenCod cuenta con las siguientes opciones: Archivo: esta opción de menú contiene las opciones Cargar, Salvar diseño y Salir del sistema. Opciones: contiene las opciones Generar código con base en el diseño desarrollado, Ver Código, Compilar y Ejecutar el archivo fuente creado y por último, colocar Comentarios en cada una de las funciones que formen el diseño creado con la herramienta.


59

Editar: esta opción cuenta con las opciones que es posible realizar sobre el diseño detallado como son: Cortar (borrar una parte del diseño) e Insertar (insertar instrucciones dentro de una sección del diseño). Ventana: esta opción del menú permite colocar las ventanas hijas en cascada, u ordenarlas por título, además permite arreglar los iconos de las ventanas, además de cerrar todas las ventanas que forman el sistema (Cerrar Todo). Ayuda: Esta opción despliega una ventana de hipertexto en la cual se explica el funcionamiento del sistema.

60

CAPITULO 5

DESARROLLO DEL SISTEMA En este capítulo se describe la metodología de solución para el problema descrito en el capítulo 2, detallando los algoritmos utilizados.

Capítulo 5 Desarrollo del sistema

61

5.1 Desarrollo interno del diseño detallado Utilizando el sistema GenCod el usuario tiene la opción realizar un diseño nuevo o de leer un diseño hecho con anterioridad, si la opción elegida es realizar uno nuevo, entonces se le presenta una caja de diálogo para proporcionar el nombre y el tipo de la función (figura 5.1), éste último se elige de una lista de tipos escrita en español, por lo que el usuario sólo deberá elegir alguno de ellos.

G enC od

Arch ivo A yuda

Figura 5.1 Caja de diálogo que pide la información de una función del sistema GenCod.

Si el usuario elige dos o más tipos de datos para una función, el sistema toma la última opción que se haya elegido. Por otra parte, si un usuario escribe el nombre de una función con menos de tres letras al inicio, se le mostrará la figura 5.2. Esto forma parte del sistema de buenos hábitos de programación que utiliza el GenCod, ya que en muchas ocasiones los nombres de las funciones no corresponden a su semántica, y colocar el nombre de un identificador con más de tres letras al inicio fuerza al usuario a describir más precisamente una función.

Figura 5.2 Caja de diálogo que impide dar nombres inapropiados a las funciones.


62

Si el usuario diera un nombre correcto a la función pero no hubiese elegido el tipo de la función se le presentará la caja de diálogo mostrada en la figura 5.3.

Figura 5.3 Caja de diálogo que fuerza a

definir el tipo de una función

Una vez que ha escrito el nombre y elegido el tipo de la función se le presenta otra caja de diálogo (figura 5.4), en la cual se piden los parámetros de la función, si es que los tiene, de otra manera el usuario puede elegir la opción de cancelar e inmediatamente iniciar con el desarrollo de su diseño detallado, del cual se hablará en la siguiente sección.

GenCod

Archivo Ayuda

Figura 5.4 Caja de diálogo de la declaración de los parámetros de una función.

En caso de que la función tenga parámetros, entonces el usuario deberá escribir el nombre de cada uno de estos en la caja de edición correspondiente. Al igual que en la declaración del nombre y tipo de la función, esta sección fuerza al usuario a definir el tipo del parámetro sí es que se ha omitido, así como también para escribir por lo menos tres letras al inicio del nombre de un parámetro (figura 5.5).


63

Figura 5.5 Cajas de diálogo para controlar el nombre y tipo de cada variable

Si el usuario ha determinado el nombre y tipo para una variable entonces deberá definir si el parámetro será pasado por valor o por referencia, en caso de no especificarse esta característica se toma por omisión la opción de paso de parámetro por valor. Una vez que se hayan definido el nombre, tipo y forma de paso de parámetro, el usuario debe presionar el botón de agregar que le dará la opción de seguir declarando más parámetros. Una vez que el usuario haya declarado todos los parámetros que contiene la función deberá de presionar el botón de finalizar. De la misma manera se realizó la declaración de las variables. Si el usuario ha determinado el nombre y tipo para una variable entonces deberá definir si los parámetros serán pasados por valor o por referencia, en caso de no especificarse esta característica se toma por default la opción de paso por valor. Una vez que se haya definido el nombre, tipo y forma de paso de parámetros, entonces el usuario debe presionar el botón de Agregar que le dará la opción de seguir declarando más parámetros. Una vez que el usuario haya declarado los parámetros de la función deberá presionar el botón de finalizar. De la misma manera se realiza la declaración de las variables (en el anexo 5 se muestra brevemente la ejecución del GenCod). Se debe mencionar que la entrada de datos que se realiza por teclado (por ejemplo: el nombre de la función, la declaración de variables, la declaración de parámetros, etc.), se analiza a través de una gramática muy parecida a la gramática utilizada por el lenguaje de programación C, por lo que se tiene un analizador léxico y sintáctico, para este tipo de entradas. Se utilizaron unos autómatas de estados finitos, los cuales se muestran en el anexo 3. 5.1.1. Definición dirigida por la sintaxis En esta sección se hablará de cómo se realiza internamente la inserción de los objetos en el sistema GenCod por medio de un análisis sintáctico, pero antes de eso definiremos el análisis sintáctico como: “El proceso de determinar si una cadena de componentes léxicos puede ser generada por una gramática” [AHO90], en este caso los componentes serán los objetos, de los cuales se ha hablando a lo largo de este capítulo.


64

Para este sistema se utilizó una definición dirigida por sintaxis que es una generalización de una gramática independiente del contexto en la que cada símbolo gramatical tiene un conjunto de atributos asociados, dividido en dos subconjuntos, llamados atributos sintetizados y atributos heredados de dicho símbolo gramatical. Un atributo puede representar cualquier cosa: una cadena, un número, un tipo, una posición de memoria, etc. El valor de un atributo en un nodo de un árbol de análisis sintáctico se define mediante una regla semántica asociada a la producción utilizada en dicho nodo, en este caso se utilizarán los atributos heredados, porque el valor de un atributo heredado se calcula a partir de los valores de los atributos en los hermanos (objetos pasivos) y el padre (objeto activo) [AHO90]. Una vez que se han hecho algunas definiciones, se pasará a explicar el análisis sintáctico, éste se realiza en varias ocasiones durante el funcionamiento del sistema: en el desarrollo de un diseño, en la inserción y eliminación de objetos dentro del diseño. Paralelo a esto, se lleva a cabo la ubicación de los objetos dentro del diseño, así como el ajuste de las coordenadas de los objetos activos. Estos dos últimos aspectos forman parte del análisis semántico de este sistema. 5.1.2 Análisis en el desarrollo de un diseño y ubicación de los objetos en

la pantalla El sistema GenCod está desarrollado de forma tal que no permita que un usuario cometa errores durante el desarrollo de su diseño, guiándolo en todo el desarrollo de su diseño, es por esta razón que se realiza un análisis mínimo de las expresiones gramaticales que el usuario va formando. Cada vez que un usuario realiza un diseño y elige un objeto para formar parte del diseño, se forma un expresión gramatical, y es entonces cuando se realiza el análisis sobre esa expresión. El proceso que se realiza es el siguiente: 1. El objeto elegido por el usuario es insertado al final de la lista que contiene la información de los objetos. 2. Si el objeto insertado representa a las instrucciones else o default, se recorre la lista de nodos que contiene la información de los objetos de atrás hacia adelante, ya que debe haber sido insertada antes la instrucción if (condicional compuesta) o case (condicional múltiple), además el GenCod verifica que la expresión condicional esté finalizada, es decir, debe existir el símbolo fin correspondiente a la instrucción if, como se ilustra en la figura 5.6.


65

“hola“

fin de lainstrucción: if

Figura 5.6 Ejemplo del análisis en la inserción de un objeto en el diseño.

En caso contrario, el sistema GenCod manda un mensaje de error al diseñador indicándole que no puede insertar ese objeto en el diseño, y en forma automática es borrado de la lista de objetos, el nodo que representa a la instrucción else. Este ejemplo se muestra en la figura 5.7.

“hola“

Figura 5.7 Ejemplo de un error en el análisis con la inserción del objeto else.

3. Si el objeto elegido corresponde al símbolo fin de todo el diseño, entonces no es posible insertar otro objeto, a menos que se elimine este objeto o se realice la opción de insertar un objeto en una parte intermedia dentro del diseño.


66

4. Cada vez que se inserta un objeto activo en el diseño, se analiza el anidamiento de las funciones, es decir, se recorrerá la lista de objetos para verificar que no existan más de dos objetos activos anidados del mismo tipo, si esto ocurre entonces se despliega un mensaje de error indicándole al diseñador que no puede insertar ese objeto, en la figura 5.8 se muestra un ejemplo de este tipo.

“hola“

Figura 5.8 Ejemplo de una función con tres condicionales simples anidadas.

5.1.2.1 Ubicación del primer objeto en la pantalla En cuanto a la ubicación de los objetos dentro de la pantalla, para el primer objeto gráfico del diseño que corresponde a la declaración de una función, el sistema lo pone automáticamente cuando el usuario elige la opción de hacer un nuevo diseño, porque de este primer elemento se van a determinar las coordenadas de los demás objetos. Este objeto obtiene sus coordenadas del área del cliente, y es colocado en la posición Arriba (0,0): las demás coordenadas son calculadas de la siguiente manera: • Las coordenadas de abajo se obtienen sumándole a las coordenadas de arriba en y el espacio

del bitmap (SPCBMP), además del espacio que ocupan los datos de la declaración de la función (DATOS), que en este caso es el nombre de la función.

• Las coordenadas de la izquierda son (0,0), ya que este objeto no tiene ninguna relación con

otro objeto a su izquierda.


67

• Las coordenadas de la derecha van a modificarse en su coordenada en x, estas coordenadas se obtienen de las coordenadas de arriba, a estas se les va a sumar en x un espacio horizontal (SPCHOR) este espacio es lo que separa un nivel de otro.

La inserción de este objeto se encuentra ilustrado en la figura 5.9.

ArribaX=0

ArribaY=0

DerechaX=ArribaX+ SPCHOR

DerechaY=0

AbajoX=ArribaX

AbajoY=ArribaY+SPCBMP+DATOS

Figura 5.9 Coordenadas del primer objeto del diseño.

5.1.2.2 Ubicación de un objeto en la pantalla después de un objeto activo Una vez que se ha insertado el primer objeto del diseño, las demás posiciones van a originarse de alguna manera de este primer objeto. Ahora bien cuando se inserta otro objeto, se realiza el análisis, de la siguiente manera: primeramente, se analiza el objeto insertado, para comprobar si esta acción corresponde a las reglas de producción de la gramática, sino existe error, entonces se analiza cuál es el elemento que lo antecede para obtener las coordenadas del objeto que se ha insertado, sí el objeto anterior corresponde a un objeto activo, es decir, que el objeto insertado forme parte de un nuevo nivel, entonces las coordenadas de la izquierda del objeto van a estar dadas por las coordenadas de arriba del objeto anterior, esta representación se ilustra en la figura 5.10 inciso a. Las coordenadas de arriba del objeto insertado serán las mismas que las coordenadas de la derecha del objeto anterior, solamente que a la coordenada en y del objeto insertado se le sumará un espacio (SPCentreBMPS), para que el objeto no quede hasta arriba de la pantalla (figura 5.10 inciso b).


68

X=0Y=0

Izq=Arriba(Obj.Anterior)

DchaX=ArribaX +SPCHORDchaY=0

Izq(X,Y)

ArribaX=DerechaX(Obj.Anterior)ArribaY=DerechaY(Obj.Anterior) + SPCentreBMPS

(a)(b)

X=0Y=0

Figura 5.10 (a) Muestra la obtención de las coordenadas de la izquierda de un objeto insertado después de un objeto activo, (b) Muestra la obtención de las coordenadas de arriba del mismo objeto.

Las coordenadas de abajo y derecha del objeto, se obtienen de las coordenadas (x,y) de arriba del mismo objeto. Las coordenadas de abajo son las mismas que las coordenadas de arriba, solamente que en la coordenada en y se le va a sumar el espacio que ocupa el bitmap. Las coordenadas de la derecha del objeto van a ser (0,0), ya que este objeto (el de la figura 5.11) que se está analizando es un objeto pasivo.

ArribaX=DerechaX(Obj.Anterior)ArribaY=DerechaY(Obj.Anterior) + SPCentreBMPS

Izq(X,Y)

AbajoX=ArribaX

AbajoY=ArribaY+SPCBMP

0

Figura 5.11 Muestra la obtención de las coordenadas abajo y derecha de un objeto insertado.


69

5.1.2.3 Ubicación de un objeto en la pantalla después de un objeto pasivo

Una vez analizado un objeto insertado en un nivel abstracto menor, se analizará la inserción de un objeto cuando éste se encuentre en el mismo nivel de abstracción (figura 5.12), en este caso después de analizar que el objeto elegido para su inserción corresponda a la gramática posicional explicada anteriormente. Las coordenadas de la izquierda del objeto insertado serán las mismas que las coordenadas de la izquierda del objeto anterior y las coordenadas de arriba serán las coordenadas de abajo del objeto anterior, las coordenadas de abajo y derecha del objeto insertado serán calculadas como las coordenadas de los objetos explicados anteriormente.

Izquierda(x,y)

Izquierda(x,y)

Abajo(x,y)

Arriba(x,y)

Abajo(x,y)

Figura 5.12 Muestra la inserción de un objeto

en el mismo nivel de abstracción. 5.1.2.4 Ubicación de un objeto en la pantalla después del objeto FIN Ahora se mostrará cómo se realiza el análisis de la expresión cuando se inserta un objeto el cual es antecedido por el objeto FIN, el objeto que será insertado debe pertenecer a un nivel mayor de abstracción. Se debe recordar que cada vez que un objeto se desea insertar en el diseño primero se realiza un análisis para ver si el objeto se encuentra sintácticamente correcto; para entender mejor esto, en la siguiente sección se mostrará un ejemplo de una expresión incorrecta. Retomando lo referente al análisis, veremos la inserción del objeto de lectura (figura 5.13), que está representado por la figura del libro. La coordenada de arriba en x de este objeto estará dada por las coordenada de la izquierda en x del objeto anterior, y la coordenada de arriba en y está dada por las coordenada de abajo en y del objeto anterior y se le va a adicionar un pequeño espacio para separar a los objetos verticalmente.


70

ArribaX=Izquierda(Obj.anterior)

Izq(X,Y)

Arriba(X,Y)

Abajo(X,Y)

ArribaY=AbajoY+SPCentreBMPS

Figura 5.13 Muestra la obtención de las coordenadas de arriba de un objeto insertado en un nivel de abstracción mayor.

Las coordenadas de la izquierda del objeto insertado están dadas por las coordenadas de la izquierda del objeto que se encuentra arriba del objeto insertado (figura 5.14). Internamente ésto se lleva a cabo recorriendo la lista doblemente ligada que almacena la información de los objetos hasta el final, como el penúltimo objeto se trata de un objeto fin entonces se coloca un apuntador a ese nodo y se recorre la lista ahora de atrás hacia adelante, hasta encontrar el nodo al cual corresponde el nodo fin, para este ejemplo ese nodo representa a un if, se coloca otro apuntador en ese nodo para obtener las coordenadas que interesan. Las coordenadas de abajo y derecha se obtienen de la misma forma que las coordenadas de los objetos explicados anteriormente.

Izq(X,Y)

Izq(X,Y)

Dcha(X,Y)

Figura 5.14 Muestra la obtención de las coordenadas de la izquierda de un objeto insertado en un nivel de abstracción mayor


71

5.1.2.5 Ubicación del objeto activo: hacer-mientras <condición> y hacer

<condición> mientras > El análisis de las instrucciones: hacer mientras <condición> y hacer <instrucciones> mientras <condición> , es diferente a las instrucciones que se han estado analizando y esto se debe a la inserción que tienen estas instrucciones cuando son elegidas por el usuario, cuando esto sucede las coordenadas de arriba del objeto van a ser dadas por las coordenadas de abajo del objeto anterior, además se va a adicionar el espacio que ocupa el bitmap (SPCBMP), y un espacio horizontal (SPCHOR). Aunque este objeto ya sea while o dowhile, pertenece al conjunto de instrucciones de la función (para este ejemplo figura 5.15), se va a encontrar en una posición un poco más adelante que los demás objetos, esto se debe a la manera de cómo maneja la notación de Warnier estas dos instrucciones.

Abajo(X,Y)Arriba(X)= AbajoX (Obj. anterior) + SPCBMP + SPCHOR

SPCBMP SPCHOR

Figura 5.15 Muestra la obtención de las coordenadas de arriba del objeto while Como se analizó anteriormente las coordenadas de arriba de estos dos objetos (while o dowhile), se obtienen de diferente manera que las coordenadas de los demás objetos activos que se han estado analizando, por lo tanto cuando un objeto es insertado después que es finalizado el nivel de abstracción que comprende la instrucción de un while o do while, las coordenadas de este objeto se obtienen de la siguiente manera: se analiza el penúltimo objeto, si éste corresponde al objeto fin (figura 5.16), entonces se coloca un apuntador a este objeto y se recorre la lista de objetos de atrás hacia adelante, para encontrar cuál es el objeto activo al cual corresponde este objeto fin, si se trata de un while o dowhile (apuntador 2), entonces se analiza cuál es el objeto anterior, que puede ser: a) un objeto pasivo diferente al objeto fin, b) el objeto fin, c) un objeto activo


72

A rr ib a X = iz q u ie rd a X

A r r ib a Y = A b a jo Y (o b je to a n te r io r )

Iz q (X ,Y )

Iz q (X ,Y )

A b a jo (X ,Y )

Iz q (X ,Y )

a p u n ta d o r 1

a p u n ta d o r 2

a p u n ta d o r 3

a p u n ta d o r 4

Figura 5.16 Muestra la obtención de las coordenadas de arriba e izquierda del objeto scanf.

a) un objeto pasivo diferente al objeto fin: en este caso las coordenadas del objeto insertado son calculadas de la misma manera que en las figuras 5.12 y 5.15. b) el objeto fin: cuando se trate del objeto fin que anteceda al objeto while o dowhile (apuntador 3, de la figura 5.10), se debe seguir recorriendo la lista que contiene la información de los objetos, para encontrar el objeto al cual corresponde el fin, para este ejemplo se trata del objeto que representa a la instrucción if(apuntador 4), entonces se coloca un apuntador y las coordenadas de la izquierda del objeto insertado, son las mismas que las coordenadas de la izquierda del objeto señalado por el apuntador número 4, del objeto señalado por el apuntador número 3 se toman las coordenadas de arriba en su coordenada en x del objeto insertado, las coordenadas de arriba en y del objeto insertado son las mismas que las coordenadas de abajo en y del objeto anterior a él (apuntador 1). En algunas de las figuras (5.16 y 5.17) se presentan puntos suspensivos entre un símbolo activo y el símbolo fin, éstos indican que pueden existir n instrucciones en este espacio. c) un objeto activo: cuando se trate de un objeto activo, el que anteceda al objeto while o dowhile, (en este ejemplo mostrado en la figura 4.35, el símbolo que antecede al while es el que representa a la instrucción del if, que se encuentra señalado por el apuntador 3, en la figura 5.11, inciso b), las coordenadas de la izquierda del objeto insertado son las mismas que las coordenadas de la izquierda del objeto anterior a él (figura 5.17 inciso a), la coordenada de arriba en x está dada por la coordenada de la derecha del objeto activo que antecede al símbolo while y la coordenada de arriba en y está dada por la coordenada de abajo en y del símbolo anterior al símbolo insertado (figura 5.17 inciso b).


73

Izq(X,Y)

(a)

Izq(X,Y)

ArribaX = derecha X

ArribaY = Abajo Y(obj anterior)

Dcha(X,Y)

Abajo(X,Y)

apuntador 1

apuntador 2apuntador 3

(b)

Figura 5.17 (a) Muestra la obtención de las coordenadas de la izquierda del objeto scanf

(b) Muestra la obtención de las coordenadas de arriba del objeto. 5.1.3 Inserción de objetos En este punto se hablará de la inserción de los objetos, pero desde el punto de vista de las coordenadas que el usuario elija para insertar un objeto. El análisis de las expresiones gramaticales formadas son evaluadas de la misma manera que cuando se lleva a cabo el desarrollo de un diseño (visto en la sección anterior). Se debe hacer notar, que el diseño se va construyendo de arriba hacia abajo y de derecha a izquierda. A diferencia de la opción de insertar que existe en el menú, con la cual se puede hacer insertar un objeto en el lugar que indique el usuario, siempre y cuando sea correcta la expresión. Para poder entender mejor esto se tomará como ejemplo el diseño de la figura 5.17, en donde el conjunto de instrucciones del objeto activo if ( ) es terminado cuando se elige el símbolo fin ( ), por lo tanto cuando el usuario elija otro objeto, éste formará parte del objeto activo . Por lo tanto si el usuario desea insertar un objeto en el conjunto de instrucciones que forman el objeto activo if, deberá elegir la opción de insertar que se presenta en el menú principal del sistema GenCod. Notando que sólo se puede hacer la inserción de un objeto a la vez. La inserción de un objeto, entre dos objetos que ya han sido insertados anteriormente se debe realizar de la siguiente manera:


74

1. El usuario tiene que elegir del menú principal la opción de insertar. 2. Señalar con el mouse y presionar el botón derecho el lugar dónde se desea hacer la inserción. 3. Por último se debe elegir de la paleta de botones la instrucción que desea insertar. Una vez que el usuario realiza los tres pasos que se mencionan arriba, internamente el sistema inserta el nodo de la instrucción seleccionada por el usuario, pero antes de hacer eso, verifica las coordenadas señaladas por el mouse, para realizar una comparación de las coordenadas obtenidas, contra las coordenadas de los demás objetos, ésto se hace analizando las coordenadas de un nodo y del siguiente para verificar si las coordenadas obtenidas por el mouse se encuentran entre estos dos nodos (ver figura 5.18) y poder hacer la inserción del nodo con la instrucción seleccionada. En caso de que la coordenada señalada por el mouse fuera inválida, se manda un mensaje de error al usuario.

Nodo Nodosiguiente

Coordenadas (x,y)

Figura 5.18 Comparación de las coordenadas obtenidas por el mouse contra los objetos que integran el diseño

Una vez que se ha insertado el nodo en la lista, se realiza el análisis para ver si la inserción de este nuevo objeto cumple con las reglas gramaticales, de las cuales se ha estado hablando. La ubicación de este objeto en el diseño sólo se verá reflejado hasta que se realice el ajuste de las coordenadas de todos los demás objetos que componen el diseño, tomando como base el objeto activo que antecede al nuevo objeto insertado (las coordenadas se obtienen de la misma manera que en la sección anterior). La inserción se puede llevar a cabo entre los niveles de abstracción que existan en el diseño, en las siguientes secciones se hablará de cómo analiza el sistema GenCod, si una coordenada es válida para realizar la inserción de un objeto en esa posición.


75

5.1.3.1 Inserción entre niveles (de mayor a menor abstracción) Este tipo de inserción se lleva a cabo cuando se desea insertar después de un objeto activo, ya que el objeto a insertar formará parte del conjunto de objetos que pertenecen a ese objeto activo.

Aunque en la figura 5.19 se ve fácilmente en donde se desea hacer la inserción, no se debe perder de vista que todos los objetos gráficos (y su posición en el espacio) mostrados en el diseño se encuentran almacenados en una lista, por lo tanto se tiene que hacer un recorrido de estos objetos para saber en dónde se debe insertar el objeto.

Figura 5.19 Inserción de un objeto después de una función. Cuando se eligen las coordenadas en el área de desarrollo del diseño para realizar la inserción, se debe analizar si éstas son válidas, es decir se debe verificar que en las coordenadas elegidas por el usuario puede insertarse un objeto de ese tipo, esto se realiza haciendo las siguientes comparaciones. (Cur.x >= XNext && Cur.x <= XNext+SPCBMP)&& (Cur.y >= YNext && Cur.y <= YNext+SPCBMP)|| (Cur.y < YNext && Cur.y > NodoAnt->ArribaY+ SPCBMP)) donde: Cur.x = corresponde a la coordenada en x que el usuario eligió para realizar la inserción. Cur.y = corresponde a la coordenada en y que el usuario eligió para realizar la inserción. XNext= corresponde a la coordenada en x del nodo siguiente. YNext= corresponde a la coordenada en y del nodo siguiente. SPCBMP = corresponde al espacio en pixeles que ocupa un bitmap. En la figura 5.19 se muestra la inserción de un objeto después de la declaración de una función y antes de un objeto pasivo (scanf), en este caso específico la inserción se lleva a cabo con un objeto que se encuentra en un nivel de abstracción más grande que el objeto siguiente. En la figura 5.20 se mustra la comparación de las coordenadas señaladas por el mouse (CurX), las cuales se deben encontrar entre las coordenadas x y x más el espacio que ocupa el

N i v e l 1 N i v e l 2


76

bitmap (SPCBMP) del elemento siguiente al que se encuentra, en el nivel de abstracción más grande.

(Cur.y >= YNext && Cur.y <= YNext+32)

XNext XNext +SPCBMP

CurX

Figura 5.20 Pantalla de comparación de las coordenadas,

para la inserción de un objeto. Además de cumplirse la comparación anterior debe cumplirse la siguiente comparación: las coordenadas señaladas por el mouse en y deben estar entre las coordenadas de y y las coordenadas de y+SPCBMP, pero puede ser que curY esté fuera de las coordenadas de YNext, y también se considera una coordenada correcta. Ver figura 5.21.

(Cur.y >= YNext && Cur.y <= YNext+SPCBMP)

YNext

YNext +SPCBMP

CurY

Figura 5.21 Pantalla de comparación de las coordenadas para la inserción de un objeto.


77

5.1.3.2 Inserción entre niveles (de menor a mayor abstracción) La inserción entre un nivel de abstracción menor a otro de mayor abstracción (figura 5.22) se presenta cuando la inserción de un objeto se desea hacer después del objeto que representa el fin de una instrucción de un objeto activo ( ).

N iv e l2N iv e l1 N iv e l3

Figura 5.22 Inserción de un objeto, después del objeto de terminación de una instrucción.

Para este tipo de inserción (figura 5.23), las coordenadas seleccionadas por el usuario con el mouse(CurX) deben encontrarse en el espacio que ocupa el bitmap en x, es decir entre las coordenadas de x y x+SPCBMP del objeto que se está analizando o en esas mismas coordenadas, pero del objeto siguiente. La coordenada en y debe encontrarse en y+SPCBMP del objeto analizado (fin del nivel) y la coordenada en y del objeto siguiente. Si las coordenadas dadas por el usuario cumplen con estas restricciones, entonces se tienen unas coordenadas válidas y se podrá llevar a cabo la inserción de un objeto, siempre y cuando éste cumpla con las reglas de la notación.

Nivel2Nivel1 Nivel3

X X+SPCBM P

CurX CurY

YNext

XNext XNext+SPCBM P

CurX

Y+SPCBM P

Figura 5.23 Pantalla de comparación de las coordenadas para la inserción de un objeto.


78

Se debe tener en cuenta que cuando se desea hacer la inserción después del objeto fin de un nivel, se analiza que este fin no represente el final de una condicional compuesta, es decir no se podrá llevar a cabo la inserción entre un if y un else, porque representa un error, aunque las coordenadas de inserción estén correctas, lo mismo ocurre cuando se tiene la instrucción que representa un condicional múltiple. 5.1.3.3 Inserción entre objetos (en el mismo nivel)

Este tipo de inserción se lleva a cabo cuando se desea insertar entre dos objetos pasivos, los cuales van a encontrarse en el mismo nivel Figura 5.24 Pantalla de la posición elegida por el mouse para realizar la inserción de un objeto.

En este tipo de inserción el análisis de las coordenadas es más simple (figura 5.25). Solamente se tiene que verificar que el objeto actual (scanf), está representado por un objeto pasivo y el objeto siguiente también.

X X +SPC B M P

C urY

Y +SPC B M P

Y N ext

C urX

Figura 5.25 Pantalla de comparación de las coordenadas entre dos objetos que se encuentran en el mismo nivel.

Nivel2Nivel1


79

Por lo tanto las coordenadas seleccionadas por el usuario en x deben encontrarse entre las coordenadas en x y x+SPCBMP del objeto analizado y las coordenadas en y deben encontrarse entre la coordenada de y+SPCBMP del objeto analizado y la coordenada de y del objeto siguiente.

Una vez que se ha comprobado que las coordenadas dadas por el usuario cumplen con estas restricciones se puede llevar a cabo la inserción de un objeto, siempre y cuando éste sea válido. 5.1.3.4 Inserción entre niveles (de mayor a menor abstracción) cuando se

desea hacer la inserción antes del objeto mientras condición o hacer-mientras condición

Este tipo de inserción se lleva a cabo cuando se desea insertar antes del objeto que representa a la instrucción MIENTRAS condición o HACER MIENTRAS (condición) (figura 5.26), debido a que cuando se inserta cualquiera de estas dos instrucciones se crea un nivel virtual (nivel 3 de la figura 5.26), que en realidad no es posible que vayan objetos en ese nivel, según la notación modificada de Warnier, pero el diseñador pudiera ser que desee hacer una inserción de un objeto en ese espacio, entonces la comparación de las coordenadas, se realiza de la siguiente manera:

N iv e l2N iv e l1 N ive l3 N iv el4

Figura 5.26 Pantalla de la inserción entre niveles (de mayor a menor abstracción). a) como se había mencionado antes, cuando se elige del menú cualquiera de estas dos instrucciones, se crea un nivel intermedio entre la instrucción del tipo mientras condición o hacer mientras condición y la instrucción anterior a ella.


80

b) para analizar si la coordenada elegida por el usuario para realizar la inserción es válida se sigue el mismo procedimiento que la inserción entre niveles. El análisis de las coordenadas se encuentra ilustrado en la figura 5.27.

CurX

CurY

X X+SPCBMP

Y+SPCBMP

CurX

XNext XNext+SPCBMP

Figura 5.27 Pantalla de comparación de las coordenadas de la inserción entre niveles.

5.1.3.5 Ubicación de los objetos después de la inserción

Una vez analizada la manera de cómo se lleva a cabo la inserción internamente, en este punto se verá como afecta la inserción de un objeto activo en el diseño. En la figura 5.28 se ilustra un diseño ya terminado, esto se puede ver porque la función cuenta con el símbolo de terminación en el nivel dos. En este ejemplo se muestra la inserción de un objeto activo (if), dentro del diseño.

N iv e l2N ive l1

Figura 5.28 Inserción de un objeto activo dentro de un diseño.


81

Una vez que se han verificado las coordenadas de la inserción y se ha visto que este objeto puede ir en esa posición, se realiza la actualización de las coordenadas (el GenCod lo realiza automáticamente) con el nuevo objeto ya insertado. En la figura 5.29 se muestra el diseño actualizado después que se ha realizado la inserción del objeto activo (if), en donde se puede notar que se ha aumentado un nuevo nivel y todos los objetos hasta el fin del nivel pertenecen al nuevo objeto activo insertado, dando como resultado un diseño inconcluso porque el objeto que representa la declaración de la función no cuenta con su objeto de terminación.

Nivel3Nivel2Nivel1

Figura 5.29 Ubicación del objeto activo ya insertado en el diseño.

5.1.4 Ajuste de los objetos en el diseño El ajuste de los objetos consiste en ordenar los objetos activos (declaración de una función, if, case, else, for, etc.), que se encuentren dentro del diseño detallado conforme se vaya desarrollando el diseño.

objeto activo 1

objeto activo 2

Figura 5.30 Ejemplo del ajuste de los objetos en el diseño detallado (externamente).


82

Por ejemplo en la figura 5.30 se encuentran señalados por una flecha dos objetos activos. Sus coordenadas en y dependen del número de objetos que formen parte de ellos. Por ejemplo el objeto activo 2 (condicional simple if), se encuentra colocado al centro (en su coordenada en y ) de los cinco objetos que pertenecen a él, El ajuste de las coordenadas en y, de los objetos activos se realiza internamente de la siguiente manera (ver figura 5.31): a) Se recorre la lista de los objetos y cada vez que se encuentre un objeto activo, se crea un nodo temporal, el cual va a estar inicializado con las coordenadas de abajo del objeto activo. b) Se une el nodo temporal y el objeto activo al cual está asociado a través de un apuntador. c) Cada vez que se encuentre un símbolo de terminación de un conjunto de instrucciones de un objeto activo, se posiciona un apuntador al final de la lista de nodos temporales (apuntador 2 de la figura 5.31). d) Se calculan las coordenadas del objeto activo, comparando las coordenadas de abajo del objeto de terminación (apuntador 1 de la figura 5.31), con las coordenadas del nodo temporal (apuntador 2), para determinar las coordenadas del objeto activo, éstas se colocan en el campo del objeto ArribaModifX y ArribaModifY. e) El nodo de la lista temporal se elimina.

Apuntador 1

Apuntador 2

Lista de objetos

Lista temporal

Figura 5.31 Ajuste de los objetos en el diseño detallado (internamente)


83

5.1.4.1 Estructura de datos de la lista temporal (que realiza el ajuste de las coordenadas de los objetos activos)

La estructura de datos que utiliza la lista temporal que sirve para calcular las coordenadas de acomodo de los objetos activos en el diseño, se encuentra ilustrada en la figura 5.32.

A puntadorhacia el nodoanterior A puntador hacia el

nodo siguiente

SpcAllBm ps

A puntador hacia unobjeto activo de la

lista de objetos

Figura 5.32 Modelo conceptual de los nodos de la lista temporal que sirve para realizar el ajuste de las coordenadas de objetos activos del diseño.

La estructura de los nodos de la lista mostrada en la figura anterior es la siguiente: typedef struct{ int SpcAllBmps; struct CUENTABMPS *AptNext; struct CUENTABMPS *AptLast; struct OBJECTDATA *AptObjsBmp; }CUENTABMPS ; donde: SpcAllBmps = es una variable de tipo entera en donde se almacenan las coordenadas de abajo en y del objeto activo que se está analizando. 5.1.5 Eliminación de objetos El sistema GenCod permite al usuario realizar la eliminación de varios objetos dentro del diseño, para esto debe marcar con video inverso los objetos que desea eliminar figura 5.33.


84

Figura 5.33 Pantalla que muestra la eliminación de objetos en el sistema GenCod.

Una vez colocado el video inverso se recorre la lista de los objetos analizando sus coordenadas para saber si éstas se encuentran dentro del bloque marcado, si es así se le pone una marca al nodo del objeto y dependiendo del tipo de instrucción del que se trate va a afectar a los demás objetosl. 1. Objetos pasivos: En caso de que la eliminación se trate de un objeto pasivo, como este tipo de objetos no implican a otros objetos simplemente son eliminados. 2. Objetos activos: for, else, dowhile, while En caso de que se trate de estas instrucciones se tiene que dejar un apuntador en esa posición de la lista y recorrerla hacia adelante para analizar si esa instrucción tiene fin de nivel. En caso de que tenga, se va a eliminar tanto la instrucción como su fin de nivel. 3. Condicional (if ): Si la instrucción que se desea eliminar es un condicional simple, entonces solamente se elimina la instrucción del if y se sigue analizando para ver si ésta cuenta con su fin de nivel para eliminarse también. En caso de ser condicional compuesta, se tiene que eliminar también el objeto de else y su fin de nivel (si lo tiene) todos los demás objetos que se encuentren dentro de estas instrucciones pasarán a formar parte del objeto activo anterior. Un ejemplo de esto se encuentra en la figura 5.34, en donde al eliminar el objeto activo if, se realiza automáticamente la eliminación del objeto fin del if y se elimina el objeto else con su fin respectivo .


85

Nivel2Nivel1 Nivel3 Nivel4

Objeto marcado para la eliminación

Nivel2Nivel1 Nivel3

Objetos después de la eliminación

Figura 5.34 Pantalla que muestra la eliminación del objeto if y la ubicación de los objetos después de la eliminación.

4. Fin de la ejecución de una instrucción: Cuando se desea hacer la eliminación del objeto que representa la terminación de una instrucción (para este ejemplo la terminación de la instrucción if), se analiza que no exista el objeto que representa a la instrucción else enseguida del objeto de terminación, si es así, entonces también debe eliminarse, junto con su terminación de la instrucción. En la figura 5.35 se ilustra este ejemplo, en donde puede verse cómo al eliminar el objeto de terminación, también es eliminado el objeto else y los objetos que pertenecían a él, pasan a formar parte de la instrucción if y el objeto de terminación de la instrucción else va a ser la terminación de la instrucción if.

Nivel2Nivel1 Nivel3 Nivel4

Objeto marcado para la eliminación

Nivel1 Nivel2 Nivel3

Objetos después de la eliminación

Figura 5.35 la eliminación del objeto fin de una instrucción y la ubicación de los objetos


86

después de la eliminación. 5.1.6 Generador automático de código Como se ha estado mencionando a lo largo de esta tesis, el GenCod es una herramienta visual que permite crear diseños detallados. Internamente el sistema (GenCod) almacena estos diseños en una estructura de datos(analizada en la sección 4.6), toda la información almacenada en esta estructura de datos, sirve para generar automáticamente código estructurado en el lenguaje de programación C. El sistema GenCod valida la información que es introducida por el diseñador al sistema, (sección 5.1) a través de autómatas que utilizan la gramática del lenguaje de programación C, eliminando una fuente potencial de error. Esto no sólo asegura que el código producido sea sintácticamente correcto sino que además corresponda al diseño detallado. Aunque éste no es el objetivo principal de esta tesis, sí constituye un gran beneficio para el diseñador ya que la herramienta sirve como un puente entre la fase de diseño detallado y la fase de pruebas (figura 5.36), sin tener que pasar por la etapa de implantación.

implement

ación

DISEÑODETALLADO

PRUEBAS

Figura 5.36 El GenCod como un puente entre la etapa de diseño detallado y pruebas. 5.1.6.1 Manejo de la estructura de datos para la generación de código La generación de código se realiza con la información contenida en las estructuras de datos que utiliza el GenCod, las cuales fueron explicadas en la sección 4.6.


87

El código generado se almacena en un archivo de texto, el cual tiene una extensión .C, este código se forma de la siguiente manera: ♦ Se colocan las bibliotecas básicas que utiliza el lenguaje de programación C. ♦ Se escriben todas las variables globales que existen en el diseño detallado, esto se hace

recorriendo cada uno de los nodos de la lista que almacena la información de las variables globales (figura 5.37 número 1).

♦ Se escriben los prototipos de todas las funciones que existan en el diseño. ♦ Una vez escritas las variables globales, se comienza a recorrer el arreglo en donde se

almacena la información de cada una de las funciones que forman el diseño(figura 5.37 número 2), además de los comentarios de cada una de las funciones.

♦ En cada una de las posiciones del arreglo, se coloca un apuntador al primer nodo de la lista

de objetos(figura 5.37 número 3), para obtener la información de la función, tal como el nombre y tipo de la función, para escribir los prototipos de las funciones.

Variables globales

Objetos

Atributos de los objetos

Variables locales ...

Figura 5.37 Orden secuencial en el cual se recorren las estructuras de datos en el GenCod para la generación de código.

♦ Los parámetros de la función se obtienen recorriendo la lista (figura 5.37, número 4), que se

encuentra apuntada por el nodo que contiene la información de la función y cada uno de los nodos de esta lista, va a contener la información de la declaración de un parámetro.


88

♦ Después de haber escrito los parámetros de una función (si los tiene), se escriben las

variables locales a la función, recorriendo la lista donde se encuentra la información de estas variables (figura 5.37, número 5), aquí al igual que las demás listas, cada uno de los nodos contiene la información de la declaración de una variable.

♦ Al terminar de recorrer la lista de las variables locales a una función, se continúa recorriendo

la lista de los objetos, empezando con el nodo siguiente al nodo que representa la declaración de una función (figura 5.37, número 6). Dependiendo la instrucción que se trate, va a tener una lista asociada de atributos, por ejemplo en el caso de un printf, puede contener la información de una variable y una cadena a desplegar. Cada vez que se encuentre un nodo que represente la instrucción de fin de una instrucción ( ), se escribe en el archivo del código fuente la llave “}”.

De esta manera se sigue generando el código de cada una de las instrucciones que represente cada uno de los nodos, hasta terminar de recorrer la lista de los objetos. Después se continúa con la siguiente posición del arreglo, realizando los mismos pasos para todas las posiciones del arreglo que contengan información. El código generado se almacena en un archivo fuente, que puede ser visualizado mediante la opción del menú ver código, de esta manera se presenta el código en otra ventana, en donde el usuario puede analizarlo y ejecutarlo si lo desea. En la figura 5.38 se muestra la generación de código del diseño detallado de dos funciones.

Figura 5.38 Interfaz del GenCod que muestra la generación de código de dos funciones.


89

5.1.7 Arquitectura del archivo de diseño

El sistema GenCod tiene la opción de salvar el diseño detallado en un disco, esto lo hace almacenando la información contenida en las estructuras de datos a un archivo(figura 4.39). La información de las estructuras de datos manejadas por el GenCod se convierten en cadenas, las cuales son insertadas en un archivo de texto para su almacenamiento, la extensión que tienen los archivos que almacenan el diseño es .dis.

Figura 5.39 Almacenamiento del archivo de diseño detallado del GenCod. El orden en que es almacenada la información del diseño en el archivo de texto es el siguiente (ver figura 5.40, en donde los nombres de los bloques mostrados en esta figura representan las palabras claves que identifican el tipo de información que se está almacenando): a) Se almacenan primero los datos globales en el archivo, tales como el tope del arreglo. b) Después almacena la información de las variables globales, si es que existen en el diseño. c) Una vez almacenada la información de las variables globales, se van a tener n bloques de información, en donde cada uno de los bloques va a contener la información de las funciones declaradas dentro del diseño. Estos bloques contienen la declaración de las variables locales (si existen), la declaración de todos los objetos que pertenecen a la función de la cual se está hablando, así como la declaración de los argumentos o parámetros de los objetos. Un ejemplo de este archivo se encuentra en el anexo 4 al final de esta tesis.


90

DTOSGLOBALES

VARGLOBALES

se almacena el tope del arregloprincipalSe almacena la información de lasvariables globales

DECFUNCION Se almacena la información de lafunción

VARLOCALES Se almacena la información de lasvariables locales

OBJSDTOS Se almacena la información de losobjetos

ARGDTOS Se almacena la información de losargumentos de los objetos

Figura 5.40 Arquitectura del archivo de diseño 5.1.8 Herramientas del GenCod 5.1.8.1 Navegación entre funciones El sistema GenCod incluye un sistema de navegación entre las funciones, que permite a un usuario invocar a una función dando un clic con el mouse en el icono que represente las llamada a esa función, de esta forma, el usuario puede observar el cuerpo de la función invocada (figura 5.41).

G enC od

m ain

m ain

Pide_datos

SearchM in

num 1 < num 2

num 1 > num 2

Pide_datos

O pcion=‘s’

SearchM in

num 1=num 2

num 1>num 2

num 1>num 2

num 1

hola

O p

num 2

Pide_D atos

Search

Archivo O pciones E ditar V entana A yuda

Figura 5.41 Navegación entre las funciones de diseño.


91

Este mecanismo de navegación es una de las ventajas del uso de los MDI´s para la programación de ventanas. 5.1.8.2 Ayudas por hipertexto Esta herramienta cuenta con un mecanismo de ayuda por hipertexto, similar a la utilizada por paquetes comerciales. Una vez que el usuario activa el hipertexto puede navegar entre tópicos que explican el funcionamiento del GenCod. Esta ayuda por hipertexto puede ser comparada con un manual de usuario de la herramienta.

92

CAPITULO 6 DISEÑO DE UN PLAN EXPERIMENTAL En este capítulo se establece la forma experimental con el cual se evaluó el desempeño del GenCod, definiendo variables dependientes e independientes y señalando los factores que fueron evaluados.

Capítulo 6 Diseño de un plan experimental

93

Antes de entrar de lleno a la descripción de las pruebas realizadas se debe de aclarar que estas no tuvieron el rigor suficiente como para ser tomadas como una conclusión definitiva, de tal forma que sera necesario realizar una investigación con muchos casos más de los aquí analizados y con un tiempo de experimentación mayor, sin embargo estas pruebas pueden servir como un indicativo de una posible tendencia al utilizar el GenCod, cabe mencionar que el desarrollo de pruebas exahustivas no fue el objetivo principal de este tema de tesis, sino el uso de una gramática visual para la generación de código. 6.1 Muestreo Los sujetos que se eligieron para este estudio fueron 5 desarrolladores de sistemas de distintas instituciones (C.B.T.i.s 136, Universidad Autónoma de Morelos, cenidet, IIE) y de distinto nivel académico (medio, profesional y maestría). El estudio o prueba consistió en medir el tiempo requerido para realizar un programa de software con la herramienta o sin ella, de tal forma que cada persona pudiese experimentar las 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 esta 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 GenCod fue determinar tanto las variables dependientes como independientes que afectan el desempeño del sistema. a) VARIABLE DEPENDIENTE: la dimensión tecnológica a medir en el GenCod es el tiempo

de desarrollo de un sistema en relación al tamaño del mismo. b) VARIABLES INDEPENDIENTES: las variables independientes son los dos métodos de

desarrollo de sistemas a medir, el tradicional (sin utilizar generadores de código) y el uso del GenCod.


94

6.2 Variables dependientes A continuación se describe cada uno de los factores que se utilizaron para medir el desempeño del sistema. • Tiempo de desarrollo: para este caso de estudio se consideró como el tiempo que requiere

un sujeto para elaborar el diseño conceptual de un problema para posteriormente realizar el diseño detallado del mismo, y por último traducir la especificación de diseño a un lenguaje de programación.

6.3 Variables independientes Como ya se mencionó anteriormente las variables independientes consideradas para este plan experimental son: a)el método tradicional de desarrollo que consiste en elaborar todas las etapas en forma artesanal y b)el uso de herramientas automáticas para generar código. 6.4 Hipótesis a comprobar El diseño del plan experimental tiene como objetivo comprobar o refutar algunas de las hipótesis que se plantearon al iniciar este trabajo de tesis: • El uso del GenCod permite reducir en aproximadamente una tercera parte el tiempo normal

de desarrollo de un sistema de software utilizando el método tradicional de desarrollo. • El tiempo de desarrollo de un sistema utilizando el GenCod se reduce en forma más

significativa a medida que el tamaño de los programas aumenta. 6.5 Plan de evaluación Una vez diseñado el plan de pruebas, se trabajó con la muestra seleccionada para obtener datos relevantes, los cuales fueron relacionados estadísticamente para observar el comportamiento entre las formas de creación de sistemas: el tradicional y el basado en el GenCod. 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 = Mmax - Mmin.


95

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 porque muestran qué tanto están dispersos los datos obtenidos contra la media, lo cual da una idea del grado de error presente en cada una de las formas de creación de sistemas. 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.

XN X

N

ii

N

= =∑

1

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

DMX X

N

ii

N

=−

=∑| |

1

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

SX X

Ni

i

N

2 1

2

=∑ −=

( )

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

SX X

N

ii

N

= ±∑ −=

( )1

2


96

6.6 Análisis de resultados Primeramente se calculan los valores de dispersión para el tiempo de desarrollo con programas de 130 líneas de código. La tabla 6.1 muestra los datos relativos al desarrollo de un sistema de código sin utilizar la herramienta.

Persona

Tiempo (minutos)

Desvío x - X

Valor absoluto |x - X|

Cuadrados de los desvíos (x - X)2

1 210 81.4 81.4 6625.96 2 193 64.4 64.4 4147.36 3 83 -45.6 45.6 2079.36 4 76 -52.6 52.6 2766.76 5 81 -47.6 47.6 2265.76

SUMA 291.6 17885.2 Tabla 6.1 Información para calcular la medida de dispersión para el tiempo dedicado

a desarrollar un sistema sin utilizar la herramienta

X = =6435

6 128.

DM = =291 6

5. 58.32

S2 1788525

357704= =. .

S = ± = ±3577 04 5980. .

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

Persona

Tiempo (minutos)

Desvío x - X



1 145 53.4 53.4 2851.56 2 131 39.4 39.4 1552.36 3 63 -28.6 28.6 817.96 4 58 33.6 33.6 1128.96 5 61 30.6 30.6 936.36


a desarrollar un sistema utilizando la herramienta


97

X = =4585

91 6 .

DM = =185 6

5. 37.12

S2 728725

= =. 1457.44

S = ± = ±145744 3817. .

Posteriormente se calculan los valores de dispersión para el desarrollo de un sistema de 350 líneas de código sin utilizar la herramienta.

Persona

Tiempo (minutos)

Desvío x - X



1 615 232.6 232.6 54102.76 2 597 214.6 214.6 46053.16 3 245 -137.4 137.4 18878.76 4 217 -165.4 165.4 27357.16 5 238 -144.4 144.4 20851.36


a desarrollar un sistema sin utilizar la herramienta

X = =1912

5 382.4

DM = =894 4

5178 88. .

S2 16724325

3344864= =. .

S = ± = ±3344864 18288. .


98

Por último se calculan los valores relativos al desarrollo de un sistema de 350 líneas utilizando el GenCod.

Persona

Tiempo (minutos)

Desvío x - X



1 407 176.6 176.6 31187.56 2 348 117.6 117.6 13829.76 3 137 -93.4 93.4 8723.56 4 118 -112.4 112.4 12633.76 5 142 -88.4 88.4 7814.56


a desarrollar un sistema utilizando la herramienta

X = =1152

5 230.4

DM = =588 4

5117 68. .

S2 7418925

1483784= =. .

S = ± = ±1483784 12181. . En resumen, de las cuatro tablas se obtiene la siguiente comparación:

concepto Desarrollo de un sistema de 130

líneas de código sin utilizar el GenCod

Desarrollo de un sistema de 130 líneas de código utilizando

el GenCod

Desarrollo de un sistema de 350 líneas de código sin utilizar

el GenCod

Desarrollo de un sistema de 350 líneas de código utilizando

el GenCod Tiempo promedio invertido en las pruebas.

128.6 91.6 382.4 230.4

Desviación media de los datos.

58.32 37.12 178.88 117.68

Varianza de los datos 3577.04 1457.44 33448.64 14837.84 Desviación estándar de los datos

59.80 38.17 182.88 121.81

Tabla 6.5 Resumen comparativo del tiempo utilizado en las cuatro pruebas.


99

Los resultados de las pruebas permitieron validar en pequeña escala las hipótesis planteadas al inicio de este tema de tesis ya que el porcentaje de reducción de tiempo al utilizar el GenCod fue del 28.43% en sistemas de 150 líneas de código, y de 39.79% en sistemas de alrededor de 350 líneas de código, lo cual representa una disminución considerable de tiempo. Los resultados obtenidos permitieron comprobar la hipótesis de que mientras más grande sea el sistema a desarrollar, mayor será el tiempo que se ahorre en relación a la forma tradicional de desarrollo de sistemas, ya que el control de sistemas se vuelve más difícil. Se debe recordar que los resultados obtenidos no pueden ser tomados como una conclusión definitiva de la relación entre el uso del GenCod y el ahorro de tiempo, sino como un indicativo de la manera cómo se comporta el GenCod con una pequeña muestra, de tal forma que se hace necesario un plan experimental más completo.

Capítulo 7 Comentarios finales

100

CAPITULO 7

COMENTARIOS FINALES En este capítulo se describen los alcances logrados en este proyecto de tesis. Se proponen algunas recomendaciones a éste, se da un panorama de los trabajos futuros relacionados con el tema de la programación visual, y por último se expresan algunos comentarios finales.


101

Con base en el análisis bibliográfico realizado se llegó a las siguientes conclusiones: • El uso de símbolos de gráficos para representar una idea intenta que una persona pueda lograr

un “salto” entre la visualización de un objeto y su representación mental, omitiendo en lo posible el proceso cognoscitivo que se realiza al tratar de “comprender” el significado de una idea.

• Con base en la hipótesis anterior, se asegura que el uso de la programación visual puede

facilitar el desarrollo del diseño de un sistema, ya que el uso de gráficos facilita la visualización del contenido de un programa al estar organizado (en la notación de Warnier) en niveles de abstracción.

• La utilización de herramientas que eliminen la etapa de codificación de un sistema, auxilian a

los desarrolladores a crear diseños sin que esto represente una perdida de tiempo o esfuerzo, y por lo tanto, no se vea al diseño como una actividad demasiado tediosa.

7.1 Alcances logrados En lo general, el objetivo global de este trabajo de tesis fue alcanzado: El desarrollo de un sistema que permitiera a un usuario realizar en forma visual el diseño detallado de un sistema, y que como resultado de la creación del diseño obtener el código del mismo en el lenguaje de programación C, logrando con esto una reducción en los tiempos de desarrollo de sistemas computacionales. Los resultados específicos alcanzados, fueron los siguientes: Un Analizador de las relaciones espaciales entre los objetos que forman el diseño: • Desarrollo de una gramática que refleje las relaciones permitidas y no permitidas entre

cada objeto. La gramática desarrollada es independiente de contexto y puede ser considerada como visual porque al menos alguno de los símbolo terminales de la gramática son objetos gráficos.

• Desarrollo de un analizador que valida que las construcciones realizadas por un usuario

sean correctas de acuerdo a la gramática definida. • Desarrollo de un gramática y sus correspondientes analizadores (léxico y sintáctico) para

validar las entradas por teclado del usuario.


102

Un ambiente de creación del diseño detallado de un sistema, que incluye las siguientes funciones: • Desarrollo de los algoritmos para insertar un objeto en alguna posición del diseño

detallado, lo cual implicó la construcción de un analizador que garantice la validez semántica de la inserción del objeto.

• Desarrollo de algoritmos para eliminar un objeto en el diseño, lo que implicó realizar un

análisis espacial que confirmara que eliminar uno o varios objetos no traerá como resultado un diseño semánticamente incorrecto.

• Desarrollo de algoritmos para reacomodar los objetos del diseño en la pantalla, ya que al

hacer una inserción o eliminación las coordenadas de los objetos deben modificarse para que puedan reflejar los niveles de abstracción de los diagramas Warnier-orr.

7.2 Mejoras y ampliaciones a este trabajo A través del desarrollo e implantación del generador de código fueron apareciendo nuevos enfoques, extensiones y mejoras al mismo. Este proyecto como un primer intento de solucionar uno de los problemas asociados con el uso de la programación enfocada a la etapa de diseño detallado tiene sus limitaciones y alcances. Para mejorarlo se proponen como trabajos futuros los siguientes: • Desarrollo e implantación de un mecanismo que permita la generación de código no sólo

en lenguaje C, sino en cualquier lenguaje de programación que soporte la programación estructurada.

• Extensión de la gramática visual para que pueda considerar no sólo la programación

estructurada, sino también la modular, además la gramática debe extenderse para que abarque todas las construcciones que permite el lenguaje C y que no fueron incluidas en este primer prototipo (uniones, interrupciones, manejo de apuntadores, etc).

• Crear iconos para agrupar instrucciones semejantes, por ejemplo, incluir iconos que

representen las operaciones de Abrir y Guardar un diseño detallado.


103

7.3 Trabajos futuros Es importante hacer notar que el proyecto desarrollado en esta tesis es el inicio de un ambiente integrado de desarrollo de software que pretende automatizar el mayor número de acciones involucradas en el ciclo de vida del software, por lo que este trabajo puede ser el origen de una serie de proyectos afines: • Desarrollo de un mecanismo que permita tomar el código fuente de un programa escrito

en lenguaje C y lo transforme a la notación de Warnier para poder ser modificado en forma visual. Este mecanismo deberá generar el código intermedio que se produce al crear un diseño detallado con el GenCod, de tal forma que este código intermedio sea interpretado y desplegado en forma gráfica.

• Desarrollo de un generador de lenguajes visuales que cuente con un ambiente que permita

generar la gramática de un lenguaje visual (símbolos iniciales, terminales, no terminales, y reglas de producción), y que posteriormente pueda crear en forma automática el compilador que realice el análisis semántico de las construcciones que realice el usuario.

• Desarrollo de un lenguaje visual para la especificación de requerimientos de una

aplicación y que con base en ésta se genere el diseño detallado del mismo.

Referencias

104

Referencias

[AHO90] Alfred V. Aho, et al, “Compiladores: principios, técnicas y herramientas”, Ed. Addison-Wesley Iberoamericana,Wilmington, Delaware, E.U.A. 1990.

[BUR95] M.M. Burnett, D.W. McIntyre, “Visual Programming”, Computer, vol. 28, No. 3,

marzo 1995. [CAI75] Caine,S., and K. Gordon, “PDL _A Tool for software Desing”, in Proc. National

Computer Conference, AFIPS Press, 1975. [CHA86] S.K. Chang, T. Ichikawa and P.A. Ligomenides, “Visual Languages”, Plenum Press.

New York 1986. [CHA87] S. K. Chang, et al., Icon purity-toward a formal theory of icons, international journal

of pattern recognition and artificial intelligence, World Scientific Publishing Company, Vol 1, No. 3,4. 1987.

[CHA90] S. K. Chang Principles of Visual Programming Systems, Ed. Prentice-Hall,

Englewood Cliffs, N.J., 1990. [CHA95] S. K. Chang and Gennaro Costagliola, Visual-Language System for User Interfaces,

IEEE computer society, Vol 12, No. 2, March 1995.

[CUE93] Gonzalo Cuevas Agustín “INGENIERIA DEL SOFTWARE: Práctica de la programación”, Ed. Addison-Wesley Iberoamericana,Wilmington, Delaware, E.U.A. 1993.

[FAI90] Richard E.Fairley "INGENIERIA DE SOFTWARE", Ed. McGraw-Hill, enero 1990. [FAR92] Tim Farrell Runnoe Connally, “Programming in Windows 3.1” 2nd Edition, QUE,

USA, 1992. [GER85] Gerez Greiser V., Rodriguez Ortiz G., et al., “Desarrollo y administración de

programas de computadora (software)”, De. Continental, México 1985. [JOY88] Luis Joyanes Aguilar "FUNDAMENTOS DE PROGRAMACION algoritmos y

estructura de datos", Ed. McGraw-Hill, España 1988. [KEN88] Kenneth E. Kendall, Julie E. Kendall “SYSTEM ANALYSIS AND DESIGN” De.

Prentice-Hall, 1988.

Referencias

105

[LEW90] Ted Lewis "Code Generators", IEEE Software, mayo 1990. [LOP95] Manuel López, Gerardo Marín, et al. “las nuevas herramientas visuales”, Personal

computing México, mayo 1995. [PAZOS] “Comunicación personal” Dr. Pazos Rangel R. [PET92] Charles Petzold “Programming Windows 3.1”, 3ra. Edición, Microsoft press. USA,

1992. [PFL91] Shari Lawrence Pfleegder, “Software Engineering The Production of Quality

Software” , segunda edición, Macmillan Publishing Company, U.S.A.,1991. [PRE90] Pressman, S. Roger “INGENIERIA DE SOFTWARE, UN ENFOQUE PRACTICO”,

3era. Edición España, Ed. McGraw-Hill, 1990. [PRO96] “Programming Visual”, http: //union.ncsa.uiuc.edu/ hypernews/ get/ computing/

visual.html #wthat_is_VPL. 1996. [SAN92] Santaolaya S.R. “Planeación y diseño de programas de Computadora”, Apuntes

cenidet 1992. [SAN96] Santaolaya S.R. et al. “Análisis prospectivo de investigación sobre la línea de

ingeniería de software, precisando en reusabilidad de componentes”, cenidet, junio 1996.

[SEN94] James A. Senn "Análisis y diseño de SISTEMAS DE INFORMACION" Ed.

McGraw-Hill, Segunda edición 1994. [VIS97] “Visual Magic”, http://www.visual-magic.com/index.html. 1997. [YOU92] Edward Yourdon “Decline & Fall of American Programmer”. 1992 by PTR Prentice

Hall, inc.

Anexo1 Cuestionario

106

ANEXO 1 CUESTIONARIO

1. ¿Haz utilizado alguna vez una notación de diseño detallado para la elaboración de un sistema?_______________________________________________________________________ 2. Si la respuesta anterior fue negativa escribe brevemente ¿por qué? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Si haz utilizado alguna vez una notación de diseño contesta brevemente las siguientes preguntas. 3. ¿Con qué frecuencia utilizas una notación de diseño detallado para la elaboración de tus sistemas y por qué? ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 4. ¿Cuál es el resultado en tiempo, costo, etc. que haz obtenido cuando utilizas una herramienta de diseño y cuándo no la utilizas? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 5. ¿Consideras que las notaciones de diseño realmente ayudan al programador? ¿Por qué? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 6. ¿Cuáles notaciones de diseño detallado conoces? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 7. Si tuvieras que hacer en este momento un sistema. ¿Cuál notación de diseño detallado eligirías y por qué? ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Anexo2 Reglas de producción de la gramática posicional

107

ANEXO 2

REGLAS DE PRODUCCION ∈ = SIGNIFICA VACIO <S> <VAR> <S> | DECFUNCION <S>| ∈

<VAR> nombre variables<VAR> |∈

<PARAMETROS> nombre parametros<PARAMETROS> |∈

<DECFUNCION>

11 ABAJO1 “nombre función”2 DERECHA2 <SENTENCIAS >3

ABAJO1 4

<SENTENCIAS> <PRINTF>1 ABAJO1 <SENTENCIAS>2 ABAJO1 3 |

<SCANF>1 ABAJO1 <SENTENCIAS>2 ABAJO1 3 |

<LLAMADA>1 ABAJO1 <SENTENCIAS>2 ABAJO1 3 | 1

ABAJO1 <SENTENCIAS>2 ABAJO1 3 | <CONDCICLO>1

ABAJO1 <SENTENCIAS>2 | ∈

<PRINTF>

1 ARRIBA1 <INSTSEC>2 DERECHA2 “cadena” 3 IZQUIERDA3

<INSTFUN>4 | 1 ARRIBA1 <INSTSEC>2 DERECHA2 “variable”3

IZQUIERDA3 <INSTFUN>2

<SCANF>

1ARRIBA1 <INSTSEC>2 DERECHA2 “variable”3 IZQUIERDA3

<INSTFUN> 4

<LLAMADA>

11 ABAJO1 “nombre función”2 ARRIBA1 <INSTSEC>3

IZQUIERDA3 <CONDCICLO> 4

<TXTC> 1 DERECHA1 “cadena”2

CONDCICLO <IFCOMP>1 ABAJO1 <CONDCICLO>2 | <SWITCH>1ABAJO1

<CONDCICLO>2 | <WHILE>1 ABAJO1 <CONDCICLO>2 |

<DOWHILE>1 ABAJO1 <CONDCICLO>2 | <FOR>1 ABAJO1

<CONDCICLO>2 | ∈

Anexo2 Reglas de producción de la gramática posicional

108

<INSTFUN> 1| (1,2,3) | (1,2)| (1,2)

<INSTSEC> | | | | 1 | ∈

<IFCOMP>

11 ARRIBA1 <INSTSEC>2 ABAJO2 “Condición”3 DERECHA3

<SENTENCIAS>4 IZQUIERDA4 <INSTFUN>5 ABAJO2 6 | 11

ARRIBA1 <INSTSEC>2 ABAJO2 “Condición”3 DERECHA3

<SENTENCIAS>4 IZQUIERDA4 <INSTFUN>5 ABAJO2 6

ABAJO1 71 ABAJO1 “Condición”8 DERECHA2

<SENTENCIAS>9 IZQUIERDA4 <INSTFUN>10 ABAJO2 11

<SWITCH>

11 ARRIBA1 <INSTSEC>2 ABAJO1 “Condición” 3 DERECHA2

<SENTENCIAS>4 IZQUIERDA4 <INSTFUN> 6 ABAJO2 7

ABAJO1 <SWITCH>8 ABAJO1 92 ABAJO1 “Condición”10

DERECHA2 <SENTENCIAS>11 IZQUIERDA4 <INSTFUN>12

ABAJO2 13 | ∈

<FOR> 1

1 ARRIBA1 <INSTSEC>2 ABAJO2 “Condición” 3 DERECHA3

<SENTENCIAS>4 ABAJO1 5 IZQUIERDA5 <INSTFUN> 6

<WHILE>



<DOWHILE> 1



Anexo3 Diagrama de transición de estados

109

ANEXO 3

Diagrama de transición de estados para la declaración de una variable o un arreglo

eotracosa

1 2

4

3 70

65

9

9

14

9

0

10 11

17

e e ee

8

Letra

[

LetraLetra

0

17

e

1312

16

e ee

140

15

5

5

Blanco , ; =Fincadena

Letradigitoguión

[ , ; id

blanco

blanco; Fincadena

Fincadena

e

otracosa

,

Blanco , ; =Fincadena

Letradigitoguión

[

[[

token =id

==

digito

digito

Letra blanco , ;

otracosa

blanco , ;

[

]

=

blanco

otracosa

]

=blanco

,

; Fincadena

otra cosa otra cosa otra cosaotra cosa otra cosa

otra cosa

otracosa

otra cosa otra cosa

Anexo 4 Formato del archivo de diseño

110

ANEXO 4

FORMATO DEL ARCHIVO DE DISEÑO

- Se almacena la información general del sistema. {DTOSGLOBALES (IndexWnd) * Almacena el tope del arreglo. }FIN

- Se almacena la información de la variables globales. {VARGLOBALES (Variable) (Tipo) (Alcance) * Se almacena la información de las variables globales. }FIN

- Este bloque almacena la información de una función, pueden existir varios bloques de este tipo, dependiendo de las funciones que existan en el desarrollo de un diseño. {DECFUNCION (NumWin)(EdoFun)(Edo) * (NumWin) almacena el número de la ventana que le corresponde a esa función. * (EdoFun) almacena el estado de la función. El número 1 indica que la función está

activa y 0 que esa función ya ha sido borrada. * (Edo) Almacena el estado del autómata. (Caduno) (Caddos) (Cadtres) * En estas tres cadenas se almacenan los comentarios de la función. }FIN - Se va a almacenar la información de las variables locales de la función. {VARLOCALES (Variable) (Tipo) (Alcance) * Se almacena la información de las variables locales. }FIN - En este bloque se almacena la información de todos los objetos que existan en la función y se va a diferenciar la información de un objeto, con respecto a otro con el símbolo (@) {OBJSDATOS @ (nInstruc)(nBmp)(SpcBmp) * (@) Este símbolo identifica la declaración de un objeto. * (nInstruc) almacena el nombre lógico del objeto. * (nBmp) almacena el nombre físico del objeto. * Se va a almacenar el espacio que ocupa el objeto en pixeles.

Anexo 4 Formato del archivo de diseño

111

(ArribaX)(ArribaY)(AbajoX)(AbajoY) (IzquierdaX)(IzquierdaY)(DerechaX)(DerechaY)

* Se almacena el cuádruple de coordenadas que tiene cada objeto. (ArribaModifX)(ArribaModifY)

* Se van a almacenar las coordenadas de arriba en X y Y pero ya modificadas, de cuando se realiza el ajuste de objetos en la pantalla.

(Tipo)(NormalBmp) * (Tipo) Almacena diferentes cosas dependiendo de la instrucción. * (NormalBmp) Este campo sirve para ver si se va a eliminar un objeto. (cadena) * (cadena) Se almacenan varias cosas según sea la instrucción. - Se almacena la información de los argumentos de un objeto {ARGDTOS (Variable) (Tipo) (Alcance) * Se van a almacenar los argumentos de los objetos. }FIN }FIN - Este FIN indica la terminación de la información de una función.

Anexo 5 Demostración de la ejecución del GenCod

112

ANEXO 5

DEMOSTRACION DE LA EJECUCION DEL GENCOD Este anexo pretende mostrar brevemente la ejecución del GenCod. El sistema GenCod cuenta con dos menús, el primero de ellos sólo tiene las opciones de abrir un archivo ya existente de diseño o de comenzar un nuevo diseño, además de la opción de ayuda (que indica cómo se puede manejar el sistema), para esta prueba de corrida se inició con la opción de generar un nuevo archivo de diseño, enseguida aparece una caja de diálogo que pregunta el nombre de la función de diseño, además de mostrar los tipos de datos que existen para que el usuario eliga el tipo de la fución, una vez hecho ésto se oprime el botón de Aceptar (ver figura 1).

GenCod

Archivo Ayuda

figura 1 Pantalla inicial que se presenta al elegir del menú nuevo archivo de diseño

Una vez que se escribe el nombre de la función y se elige el tipo de la función, se presenta otra caja de diálogo preguntando por los parámetros de la función (figura 2). El usuario debe escribir el nombre del parámetro, elegir el tipo de dato y el tipo de paso del parámetro, hecho ésto debe oprimir el botón con la opción de Agregar y continuar con la declaración de los demás parámetros, al terminar debe oprimir el botón con la opción de Finalizar. En caso de que la función no cuente con parámetros el usuario sólo debe oprimir el botón de Finalizar.


113

GenCod

Archivo Ayuda

figura 2 Pantalla que se muestra para realizar la declaración de parámetros

En la siguiente pantalla que se presenta en la figura 3, se puede ver el segundo menú del GenCod, el cual contiene todas las instrucciones de la notación de diseño de Warnier, además aparece el primer objeto del diseño que representa la declaración de una función.

figura 3 Pantalla en donde se va a realizar el diseño


114

Cada vez que se elija una instrucción de la paleta de botones del menú, se presentará una caja de diálogo, que pide la información necesaria para cada instrucción. En la figura 4 se muestran las cajas de diálogo de las instrucciones de salida y condicional (todas las instrucciones tienen la opción de cancelar la acción).

figura 4 Caja de diálogo de las instrucciones de salida y del condicional

Con la utilización de la herramienta el usuario no debe preocuparse dónde colocar cada una de las instrucciones elegidas, porque el GenCod se encarga de realizar ésto. En la figura 5 se muestra cómo despúes de elegir un objeto activo (condicional), se crea un nuevo nivel de abstracción, asi que todos los objetos o instrucciones que se eligan van a pertenecer al objeto activo anterior, en este caso al condicional.

figura 5 Inserción de un objeto después de un objeto activo


115

Además en caso de que se eligiera una instrucción incorrecta, el GenCod presenta un mensaje indicando el error (ver figura 6).

figura 6 Mensaje de error al elegir una instrucción incorrecta

De tal manera que el usuario puede continuar eligiendo instrucciones hasta terminar con su diseño, pudiéndolo guardar en un archivo (ver figura 7).

figura 7 Caja de diálogo que se presenta al elegir la opción de guardar el archivo de diseño


116

Además el GenCod cuenta con un sistema de ayuda que permite al usuario consultar a través de hipertexto el funcionamiento que tiene el sistema (ver figura 8).

figura 8 Pantalla que muestra las ayudas del GenCod

En el capítulo 5 se explica con mayor detalle las opciones que tiene el GenCod, así como también la generación de código y la ejecución de los programas generados a partir del diseño (desde el punto de vista interno del sistema).

tecnicas de documentacion

Education