SlideShare una empresa de Scribd logo
1 de 128
Descargar para leer sin conexión
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion
Tecnicas de documentacion

Más contenido relacionado

La actualidad más candente

Escribir en internet (Fundéu 2012)
Escribir en internet (Fundéu 2012)Escribir en internet (Fundéu 2012)
Escribir en internet (Fundéu 2012)Silvia Pellacani
 
Libro simulacion mikroc
Libro simulacion mikrocLibro simulacion mikroc
Libro simulacion mikrocpabs_devil
 
Traductor Pseudocógido to C
Traductor Pseudocógido to CTraductor Pseudocógido to C
Traductor Pseudocógido to CJavier Gray B.
 
La hora de la igualdad: brechas por cerrar, caminos por abrir
La hora de la igualdad: brechas por cerrar, caminos por abrirLa hora de la igualdad: brechas por cerrar, caminos por abrir
La hora de la igualdad: brechas por cerrar, caminos por abrirEUROsociAL II
 
Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...
Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...
Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...Irekia - EJGV
 
RUTAS 2015 MINEDU MATEMATICA VI CICLO
RUTAS 2015 MINEDU MATEMATICA VI CICLORUTAS 2015 MINEDU MATEMATICA VI CICLO
RUTAS 2015 MINEDU MATEMATICA VI CICLOJorge Lazo Paredes
 
RUTAS 2015 MINEDU MATEMATICA VII CICLO
RUTAS 2015 MINEDU MATEMATICA VII CICLORUTAS 2015 MINEDU MATEMATICA VII CICLO
RUTAS 2015 MINEDU MATEMATICA VII CICLOJorge Lazo Paredes
 
Taller para el desarrollo de las funciones ejecutivas.
Taller para el desarrollo de las funciones ejecutivas.Taller para el desarrollo de las funciones ejecutivas.
Taller para el desarrollo de las funciones ejecutivas.MaritaQuezada1
 

La actualidad más candente (16)

Escribir en internet (Fundéu 2012)
Escribir en internet (Fundéu 2012)Escribir en internet (Fundéu 2012)
Escribir en internet (Fundéu 2012)
 
base de datos
base de datosbase de datos
base de datos
 
De la periferia al centro
De la periferia al centroDe la periferia al centro
De la periferia al centro
 
Control manual para cnc
Control manual para cncControl manual para cnc
Control manual para cnc
 
trabajo final .
trabajo final .trabajo final .
trabajo final .
 
Libro simulacion mikroc
Libro simulacion mikrocLibro simulacion mikroc
Libro simulacion mikroc
 
Traductor Pseudocógido to C
Traductor Pseudocógido to CTraductor Pseudocógido to C
Traductor Pseudocógido to C
 
La hora de la igualdad: brechas por cerrar, caminos por abrir
La hora de la igualdad: brechas por cerrar, caminos por abrirLa hora de la igualdad: brechas por cerrar, caminos por abrir
La hora de la igualdad: brechas por cerrar, caminos por abrir
 
Cideal
CidealCideal
Cideal
 
Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...
Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...
Comunicación electrónica - Propuestas para mejorar la calidad de los textos e...
 
RUTAS 2015 MINEDU MATEMATICA VI CICLO
RUTAS 2015 MINEDU MATEMATICA VI CICLORUTAS 2015 MINEDU MATEMATICA VI CICLO
RUTAS 2015 MINEDU MATEMATICA VI CICLO
 
Comunicacion visual
Comunicacion visualComunicacion visual
Comunicacion visual
 
Peladora de soya hidratada
Peladora de soya hidratadaPeladora de soya hidratada
Peladora de soya hidratada
 
RUTAS 2015 MINEDU MATEMATICA VII CICLO
RUTAS 2015 MINEDU MATEMATICA VII CICLORUTAS 2015 MINEDU MATEMATICA VII CICLO
RUTAS 2015 MINEDU MATEMATICA VII CICLO
 
Curso de c++
Curso de c++Curso de c++
Curso de c++
 
Taller para el desarrollo de las funciones ejecutivas.
Taller para el desarrollo de las funciones ejecutivas.Taller para el desarrollo de las funciones ejecutivas.
Taller para el desarrollo de las funciones ejecutivas.
 

Destacado

Técnicas y herramientas de documentación
Técnicas y herramientas de documentaciónTécnicas y herramientas de documentación
Técnicas y herramientas de documentaciónFSILSCA
 
Criterios para evaluar la calidad de la investigación
Criterios para evaluar la calidad de la investigaciónCriterios para evaluar la calidad de la investigación
Criterios para evaluar la calidad de la investigaciónyedipsicosocial
 
Procesos, flujogramas y procedimientos
Procesos, flujogramas y procedimientosProcesos, flujogramas y procedimientos
Procesos, flujogramas y procedimientosmariateresarevalo
 
Ensayo de la arquitectura moderna
Ensayo de la arquitectura moderna Ensayo de la arquitectura moderna
Ensayo de la arquitectura moderna Massi Aragon
 

Destacado (6)

Técnicas y herramientas de documentación
Técnicas y herramientas de documentaciónTécnicas y herramientas de documentación
Técnicas y herramientas de documentación
 
Técnicas de Documentación e Información (TDI)
Técnicas de Documentación e Información (TDI) Técnicas de Documentación e Información (TDI)
Técnicas de Documentación e Información (TDI)
 
Cliente-Servidor
Cliente-ServidorCliente-Servidor
Cliente-Servidor
 
Criterios para evaluar la calidad de la investigación
Criterios para evaluar la calidad de la investigaciónCriterios para evaluar la calidad de la investigación
Criterios para evaluar la calidad de la investigación
 
Procesos, flujogramas y procedimientos
Procesos, flujogramas y procedimientosProcesos, flujogramas y procedimientos
Procesos, flujogramas y procedimientos
 
Ensayo de la arquitectura moderna
Ensayo de la arquitectura moderna Ensayo de la arquitectura moderna
Ensayo de la arquitectura moderna
 

Similar a Tecnicas de documentacion

7 8 yahir de jesus mariaca beltran - sergio reyes galindo
7 8 yahir de jesus mariaca beltran - sergio reyes galindo7 8 yahir de jesus mariaca beltran - sergio reyes galindo
7 8 yahir de jesus mariaca beltran - sergio reyes galindoSilvia Acuña
 
Analisis de fuente conmutada
Analisis de fuente conmutadaAnalisis de fuente conmutada
Analisis de fuente conmutadaotman ghazi
 
Sistema de soporte de decisiones para la gestión académica de la ULADECH
Sistema de soporte de decisiones para la gestión académica de la ULADECHSistema de soporte de decisiones para la gestión académica de la ULADECH
Sistema de soporte de decisiones para la gestión académica de la ULADECHJulio César Álvarez Reyes
 
Proyecto investigacion-sitio web bic 23
Proyecto investigacion-sitio web bic 23Proyecto investigacion-sitio web bic 23
Proyecto investigacion-sitio web bic 23Mary Martínez Morales
 
Proyecto integrador de saberes
Proyecto integrador de saberesProyecto integrador de saberes
Proyecto integrador de saberesCarla Chávez
 
Tesis claudiacruzmtz
Tesis claudiacruzmtzTesis claudiacruzmtz
Tesis claudiacruzmtzkeaton22
 
Tesis Prototipo de Sistema de Inteligencia de Negocios
Tesis Prototipo de Sistema de Inteligencia de Negocios Tesis Prototipo de Sistema de Inteligencia de Negocios
Tesis Prototipo de Sistema de Inteligencia de Negocios Nicolás Chavez
 
Diseño red-fo
Diseño red-foDiseño red-fo
Diseño red-fobeymarcito
 
Esquemas iterativos en paralelo con OpenMP
Esquemas iterativos en paralelo con OpenMPEsquemas iterativos en paralelo con OpenMP
Esquemas iterativos en paralelo con OpenMPSotero Ordones
 
Powerpoint
PowerpointPowerpoint
Powerpointleargo
 

Similar a Tecnicas de documentacion (20)

7 8 yahir de jesus mariaca beltran - sergio reyes galindo
7 8 yahir de jesus mariaca beltran - sergio reyes galindo7 8 yahir de jesus mariaca beltran - sergio reyes galindo
7 8 yahir de jesus mariaca beltran - sergio reyes galindo
 
Aspecto caracteristicas
Aspecto caracteristicasAspecto caracteristicas
Aspecto caracteristicas
 
Tesis maestriafinal
Tesis maestriafinalTesis maestriafinal
Tesis maestriafinal
 
55406
5540655406
55406
 
Analisis de fuente conmutada
Analisis de fuente conmutadaAnalisis de fuente conmutada
Analisis de fuente conmutada
 
Sistema de soporte de decisiones para la gestión académica de la ULADECH
Sistema de soporte de decisiones para la gestión académica de la ULADECHSistema de soporte de decisiones para la gestión académica de la ULADECH
Sistema de soporte de decisiones para la gestión académica de la ULADECH
 
Proyecto investigacion-sitio web bic 23
Proyecto investigacion-sitio web bic 23Proyecto investigacion-sitio web bic 23
Proyecto investigacion-sitio web bic 23
 
PLC: Practicas de rslogix 5000
PLC: Practicas de rslogix 5000PLC: Practicas de rslogix 5000
PLC: Practicas de rslogix 5000
 
Proyecto integrador de saberes
Proyecto integrador de saberesProyecto integrador de saberes
Proyecto integrador de saberes
 
Tesis luis iribarne
Tesis luis iribarneTesis luis iribarne
Tesis luis iribarne
 
Digitales
DigitalesDigitales
Digitales
 
0281 williams
0281 williams0281 williams
0281 williams
 
Tesis claudiacruzmtz
Tesis claudiacruzmtzTesis claudiacruzmtz
Tesis claudiacruzmtz
 
Guía de elaboración de un proyecto
Guía de elaboración de un proyectoGuía de elaboración de un proyecto
Guía de elaboración de un proyecto
 
Módulo didáctico
Módulo didácticoMódulo didáctico
Módulo didáctico
 
Tesis Prototipo de Sistema de Inteligencia de Negocios
Tesis Prototipo de Sistema de Inteligencia de Negocios Tesis Prototipo de Sistema de Inteligencia de Negocios
Tesis Prototipo de Sistema de Inteligencia de Negocios
 
Diseño red-fo
Diseño red-foDiseño red-fo
Diseño red-fo
 
Análisis Espacial con R
Análisis Espacial con RAnálisis Espacial con R
Análisis Espacial con R
 
Esquemas iterativos en paralelo con OpenMP
Esquemas iterativos en paralelo con OpenMPEsquemas iterativos en paralelo con OpenMP
Esquemas iterativos en paralelo con OpenMP
 
Powerpoint
PowerpointPowerpoint
Powerpoint
 

Más de FSILSCA

Presentacion de la información
Presentacion de la informaciónPresentacion de la información
Presentacion de la informaciónFSILSCA
 
Clasificacion de los sistemas
Clasificacion de los sistemasClasificacion de los sistemas
Clasificacion de los sistemasFSILSCA
 
Analisis
AnalisisAnalisis
AnalisisFSILSCA
 
Tablas decision
Tablas decisionTablas decision
Tablas decisionFSILSCA
 
Requerimientos 2
Requerimientos 2Requerimientos 2
Requerimientos 2FSILSCA
 
Recursos de los estudios de factibilidad
Recursos de los estudios de factibilidadRecursos de los estudios de factibilidad
Recursos de los estudios de factibilidadFSILSCA
 
Libro Herramientas Case
Libro Herramientas CaseLibro Herramientas Case
Libro Herramientas CaseFSILSCA
 
Herramienta case
Herramienta caseHerramienta case
Herramienta caseFSILSCA
 
Documentación
DocumentaciónDocumentación
DocumentaciónFSILSCA
 
Conceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemasConceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemasFSILSCA
 
Clasificación de los requerimientos
Clasificación de los requerimientosClasificación de los requerimientos
Clasificación de los requerimientosFSILSCA
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vidaFSILSCA
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vidaFSILSCA
 
Caracteisticas de un analista
Caracteisticas de un analistaCaracteisticas de un analista
Caracteisticas de un analistaFSILSCA
 
Antecedentes y Herramientas de Sistemas de Informacion
Antecedentes y Herramientas de Sistemas de InformacionAntecedentes y Herramientas de Sistemas de Informacion
Antecedentes y Herramientas de Sistemas de InformacionFSILSCA
 
Conceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemasConceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemasFSILSCA
 

Más de FSILSCA (19)

Presentacion de la información
Presentacion de la informaciónPresentacion de la información
Presentacion de la información
 
Clasificacion de los sistemas
Clasificacion de los sistemasClasificacion de los sistemas
Clasificacion de los sistemas
 
Analisis
AnalisisAnalisis
Analisis
 
Tablas decision
Tablas decisionTablas decision
Tablas decision
 
Requerimientos 2
Requerimientos 2Requerimientos 2
Requerimientos 2
 
Recursos de los estudios de factibilidad
Recursos de los estudios de factibilidadRecursos de los estudios de factibilidad
Recursos de los estudios de factibilidad
 
Libro Herramientas Case
Libro Herramientas CaseLibro Herramientas Case
Libro Herramientas Case
 
Jackson
JacksonJackson
Jackson
 
Hcase
HcaseHcase
Hcase
 
Herramienta case
Herramienta caseHerramienta case
Herramienta case
 
Documentación
DocumentaciónDocumentación
Documentación
 
Conceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemasConceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemas
 
Clasificación de los requerimientos
Clasificación de los requerimientosClasificación de los requerimientos
Clasificación de los requerimientos
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 
Ciclo2
Ciclo2Ciclo2
Ciclo2
 
Caracteisticas de un analista
Caracteisticas de un analistaCaracteisticas de un analista
Caracteisticas de un analista
 
Antecedentes y Herramientas de Sistemas de Informacion
Antecedentes y Herramientas de Sistemas de InformacionAntecedentes y Herramientas de Sistemas de Informacion
Antecedentes y Herramientas de Sistemas de Informacion
 
Conceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemasConceptos básicos de la teoría general de sistemas
Conceptos básicos de la teoría general de sistemas
 

Último

Nikola Tesla - Biografia - Datos interesantes e inventos
Nikola Tesla - Biografia - Datos interesantes e inventosNikola Tesla - Biografia - Datos interesantes e inventos
Nikola Tesla - Biografia - Datos interesantes e inventosLeonellBrayanRICALDI
 
Estudios Sociales libro 8vo grado Básico
Estudios Sociales libro 8vo grado BásicoEstudios Sociales libro 8vo grado Básico
Estudios Sociales libro 8vo grado Básicomaxgamesofficial15
 
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptxHidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptxNathaly122089
 
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptxComunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptxJunkotantik
 
ciclos biogeoquimicas y flujo de materia ecosistemas
ciclos biogeoquimicas y flujo de materia ecosistemasciclos biogeoquimicas y flujo de materia ecosistemas
ciclos biogeoquimicas y flujo de materia ecosistemasFlor Idalia Espinoza Ortega
 
el poder del estado en el siglo XXI.pptx
el poder del estado en el siglo XXI.pptxel poder del estado en el siglo XXI.pptx
el poder del estado en el siglo XXI.pptxsubfabian
 
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...helmer del pozo cruz
 
3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptx
3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptx3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptx
3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptxnelsontobontrujillo
 
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLAACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLAJAVIER SOLIS NOYOLA
 
Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...
Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...
Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...Pere Miquel Rosselló Espases
 
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLAACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLAJAVIER SOLIS NOYOLA
 
tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...
tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...
tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...Chema R.
 
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docxcuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docxANDREAGRACEDURANSALA
 
Estrategia Nacional de Refuerzo Escolar SJA Ccesa007.pdf
Estrategia Nacional de Refuerzo Escolar  SJA  Ccesa007.pdfEstrategia Nacional de Refuerzo Escolar  SJA  Ccesa007.pdf
Estrategia Nacional de Refuerzo Escolar SJA Ccesa007.pdfDemetrio Ccesa Rayme
 
2. Entornos Virtuales de Aprendizaje.pptx
2. Entornos Virtuales de Aprendizaje.pptx2. Entornos Virtuales de Aprendizaje.pptx
2. Entornos Virtuales de Aprendizaje.pptxJunkotantik
 
Gran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdf
Gran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdfGran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdf
Gran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdfEdgar R Gimenez
 
Seguridad y virus informáticos 12°B 2024
Seguridad y virus informáticos 12°B 2024Seguridad y virus informáticos 12°B 2024
Seguridad y virus informáticos 12°B 2024sergeycrastz06
 
RESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdf
RESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdfRESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdf
RESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdfANEP - DETP
 

Último (20)

Nikola Tesla - Biografia - Datos interesantes e inventos
Nikola Tesla - Biografia - Datos interesantes e inventosNikola Tesla - Biografia - Datos interesantes e inventos
Nikola Tesla - Biografia - Datos interesantes e inventos
 
Estudios Sociales libro 8vo grado Básico
Estudios Sociales libro 8vo grado BásicoEstudios Sociales libro 8vo grado Básico
Estudios Sociales libro 8vo grado Básico
 
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptxHidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
 
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptxComunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
 
ciclos biogeoquimicas y flujo de materia ecosistemas
ciclos biogeoquimicas y flujo de materia ecosistemasciclos biogeoquimicas y flujo de materia ecosistemas
ciclos biogeoquimicas y flujo de materia ecosistemas
 
el poder del estado en el siglo XXI.pptx
el poder del estado en el siglo XXI.pptxel poder del estado en el siglo XXI.pptx
el poder del estado en el siglo XXI.pptx
 
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
 
3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptx
3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptx3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptx
3. ELEMENTOS QUE SE EMPLEAN EN LAS ESTRUCTURAS.pptx
 
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLAACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
 
Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...
Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...
Realitat o fake news? – Què causa el canvi climàtic? - Modificacions dels pat...
 
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLAACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
 
tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...
tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...
tema 6 2eso 2024. Ciencias Sociales. El final de la Edad Media en la Penínsul...
 
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docxcuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
 
Estrategia Nacional de Refuerzo Escolar SJA Ccesa007.pdf
Estrategia Nacional de Refuerzo Escolar  SJA  Ccesa007.pdfEstrategia Nacional de Refuerzo Escolar  SJA  Ccesa007.pdf
Estrategia Nacional de Refuerzo Escolar SJA Ccesa007.pdf
 
2. Entornos Virtuales de Aprendizaje.pptx
2. Entornos Virtuales de Aprendizaje.pptx2. Entornos Virtuales de Aprendizaje.pptx
2. Entornos Virtuales de Aprendizaje.pptx
 
Power Point : Motivados por la esperanza
Power Point : Motivados por la esperanzaPower Point : Motivados por la esperanza
Power Point : Motivados por la esperanza
 
Gran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdf
Gran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdfGran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdf
Gran Final Campeonato Nacional Escolar Liga Las Torres 2017.pdf
 
Seguridad y virus informáticos 12°B 2024
Seguridad y virus informáticos 12°B 2024Seguridad y virus informáticos 12°B 2024
Seguridad y virus informáticos 12°B 2024
 
RESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdf
RESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdfRESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdf
RESPONSABILIDAD SOCIAL EN LAS ORGANIZACIONES (4).pdf
 
Luz desde el santuario. Escuela Sabática
Luz desde el santuario. Escuela SabáticaLuz desde el santuario. Escuela Sabática
Luz desde el santuario. Escuela Sabática
 

Tecnicas de documentacion

  • 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