1. 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 UT 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

2. 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.

3. 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...

4. 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)

5. 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.

6. 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
i

7. 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 37
diseño......................
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
ii

8. 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
iii

9. Capitulo 7 COMENTARIOS FINALES........................................................ 100
7.1 Alcances logrados...................................................................................................... 101
7.2 Mejoras y ampliaciones a este trabajo....................................................................... 102
7.3 Trabajos futuros......................................................................................................... 103
Referencias.................................................................................................................. 104
Anexo 1. Cuestionario............................................................................................. 106
Anexo 2. Reglas de producción de la gramática visual............................. 107
Anexo 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........................................................... 110
Anexo 5. Demostración de la ejecución del GenCod.................................... 112
iv

10. 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
v

11. 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
vi

12. 5.25 Pantalla de comparación de las coordenadas entre dos objetos 78
que se encuentran en el mismo nivel
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
vii

13. 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.
1

14. Capítulo 1 Introducción a la ingeniería de software
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.
2

15. Capítulo 1 Introducción a la ingeniería de software
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.
3

16. Capítulo 1 Introducción a la ingeniería de software
♦ 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.
4

17. Capítulo 1 Introducción a la ingeniería de software
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
5

18. Capítulo 1 Introducción a la ingeniería de software
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.
Mantenimiento
Mantenimiento
Prueba
Prueba
Implementación
Implementación
Diseño
Con diseño Sin diseño
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
6

19. Capítulo 1 Introducción a la ingeniería de software
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.
7

20. 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.
8

21. Capítulo 2 Planteamiento del problema
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].
8

22. Capítulo 2 Planteamiento del problema
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.
9

23. Capítulo 2 Planteamiento del problema
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.
10

24. Capítulo 2 Planteamiento del problema
• 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.
11

25. Capítulo 2 Planteamiento del problema
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.
M e to d o lo g ía s d e d is e ñ o m á s c o n o c id a s
25
20
15
10
5
0
Seudocódigo
Bertini
Jackson
Hipo
N-S
Yourdon
D. flujo
Warnier
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.
Frecuencia
Notaciones de Diseño
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.
12

26. Capítulo 2 Planteamiento del problema
M e to d o lo g ía s d e d is e ñ o m á s u tiliz a d a s
1 2
1 0
8
6
4
2
0
N-S
Jackson
Seudocódigo
D. flujo
Warnier
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:
frecuencia
rango percentil = * 100
N
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.
13

27. Capítulo 2 Planteamiento del problema
Uso de las metodologías de diseño entre los
desarrolladores
D. Flujo Jackson
N-S
Seudocódigo
Warnier
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.
14

28. Capítulo 2 Planteamiento del problema
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].
15

29. Capítulo 2 Planteamiento del problema
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:
Condición
Primera tarea
F T
Parte- Parte-
Else then
Siguiente tarea
Secuencia If-then-else
Tarea del bucle
T
F Parte del caso
T T
Casos de
F
condición F Condición
del bucle
F T
Do-while
T Repeat-Until
Repetición
F
Selección
Figura 2.5 Construcciones en diagramas de flujo.
16

30. Capítulo 2 Planteamiento del problema
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 M
*
N P N
S e c u e n c ia l R e p e t it iv a
M
O O O O
N N P P
A lte r n a tiv a
Figura 2.6 Estructuras básicas del método de Jackson.
17

31. Capítulo 2 Planteamiento del problema
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.
18

32. Capítulo 2 Planteamiento del problema
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].
Leyenda 1
.-.-.-.-
.-.-.-.-
.-.-.-.-
2 3 4
5 6 7 8 9 12
Contenido
1-.-.-.-.-.-. 6.-.-.-.-.- 10 11
2.-.-.-.-.-.- 7.-.-.-.-.-
3.-.-.-.-.-.- 8.-.-.-.-.-
4--.--.-.--- 9.---.-.-.-
5.-.-.-.-.-.- 10.-.-.-.-.
Figura 2.8 Tabla visual de contenido para un paquete HIPO.
19

33. Capítulo 2 Planteamiento del problema
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].
X 1
C ondición
Proc. 1
sum a<- sum a+ 1
x = x +1
C ondición
(c) * x >= 5
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.
20

34. Capítulo 2 Planteamiento del problema
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].
Proceso 1,
Condición
Proceso 2, Proc 1
.
.
Condición
Proceso n
Proc 2
(a) Secuenciación
(b) Bifurcación
X <- 1
sum a <- sum a + 1
x = x +1
* x >= 5
(c)
(c) Repetición
Figura 2.10 Construcciones básicas de los diagramas de Warnier.
21

35. Capítulo 2 Planteamiento del problema
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.
22

36. Capítulo 2 Planteamiento del problema
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.
23

37. Capítulo 2 Planteamiento del problema
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].
24

38. 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.
26

39. Capítulo 3 Conceptos de Programación Visual
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.
27

40. Capítulo 3 Conceptos de Programación Visual
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
Representativo Dibujo
Abstracto Símbolo
Arbitrario Signo
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) }.
28

41. Capítulo 3 Conceptos de Programación Visual
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.
29

42. Capítulo 3 Conceptos de Programación Visual
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]
30

43. Capítulo 3 Conceptos de Programación Visual
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].
31