Y DESARROLLO TECNOLOGICO cenidet. Claudia... · s.e.p. s.e.i.t. d.g.i.t. centro nacional de investigacion y desarrollo tecnologico cenidet. “generador automatic0 de codigo para

S.E.P. S.E.I.T. D.G.I.T.

CENTRO NACIONAL DE INVESTIGACION

Y DESARROLLO TECNOLOGICO

cenidet. “GENERADOR AUTOMATIC0 DE CODIGO PARA UN SISTEMA DE INFORMACION A PARTIR DEL

ESQUEMA DE LA BASE DE DATOS”

T E S I S

OUE COMO REOUlSlTO PARA OBTENER EL GRADO DE:

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

P R E S E N T A : CLAUDIA HORTENCIA IBARRA PADILLA

CENTRO DE INFORMAClON

C E N I D E T

CUERNAVACA, MOR. OCTUBRE DE 1996

\

8 B $pP SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

Centro Nacional de Investigación y Desarrollo Tecnológico

ACADEMIA DE LA MAESTRIA EN CIENCIAS DE LA COMPUTACION

Cuemavaca Mor., a 9 de octubre de 1996

Dr. Juan Manuel Tpicaño Castillo Director del CENIDET P r e s e n t e

At'n: . Dr. José Ruiz Ascencio Jefe del Depto. de Computación

Nos es grato comunicarle, que conforme a los lineamientos'establecidos para la obtención del grado de maestría de este centro, y después de haber sometido a revisión académica el trabajo de tesis denominado:

"Generador Automático de Codigo para un Sistema de Información a partir del Esquema de la Base de Datos"

que presentó la 1.S.C. Claudia Hortencia Ibarra Padilla, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis, así como de fijar la fecha del examen correspondiente.

~

Sin más por el momento, quedamos de usted.

A t e n t a m e n t e r. E. P. D. Q. I. _'' C M wiCk##L bit INYKTIGflC@~

/ , Comisión de revisión de la tesis Y R ( S A . R ~ O L L O r.~(noio61(0 ~~

/-- ^M&!RECCWN A C M I l h ' i i ~

. . . ... - M.C. Ohia G. Frágoso L%z '

M.C. Mario Guillén Rodríguez Director de tesis

M.C. Mario Guillén Rodríguez Director de tesis

Interior Internado Palmira S/N C.P. 62490 Apartado Postal 5-164, C.P. 62050, Cuernavacs Mar., México

Tels. (73) 18-77-41 y 12-76-13, Fax. 12-24-34 cenídet.

Centro Nacional de Investigación y Desarrollo Tecnológico

Subdirección Académica Of. NO. DCC- 102/96

Cuemavaca Mor., a 14 de octubre de 1996

I.S.C. Claudia Hortencia Ibarra Padilla Candidata al grado de Maestro en Ciencias de la Computación PRESENTE

Después de haber sometido a revisión académica, y de haber confvmado las sugerencias indicadas por el jurado de su trabajo de tesis denominado:

"Generador Automático de Código para un Sistema de Información a partir del Esquema de la Base de Datos ''

me es grato comunicarle, que conforme a los heamientos establecidos para la obtención del grado de maestría de este centro, se le concede la autorización respectiva para que proceda con la impresión de dicha tesis.

A t e n t a m e n t e

I. E. P. n. o. I. T . Dr. José Ruíz Ascencio Jefe del Depto. de Ciencias

Computacionales. :wvs W W l Df I M l i r s r ~ ~ '

V BeSCtñOLLO KCROl06ItO %3ERECCl&i ACMEMICL

C.C.P. M.C. Wilberth Alcocer Rosado C.C.P. Ing. David Chávez Aguilar

Subdirección Académica Depto. de Servicios Escolares

interior Internado Palmira S/N C.P. 62490 Apartado Postal 5-164, C.P. 62050, Cnernavaca Mor., México

Teis. (73) 18-77-41 y 12-76-13. Fax. 12-24-34 cenidet/

I

\ \

TABLA DE CONTENIDO

CAPITULO 1 Pág .

INTRODUCCION ........................................................................................ i

1.1 MOTIVACION .............................................................................................. 2

1.2 OBJETIVO DE LA TESIS .............................................................................. 2 1.3 BENEFICIOS .................................................................................................. 3

1.4 ESTADO DEL ARTE EN HERRAMIENTAS CASE ..................... ~ ............. 4

I . 4.1 Comentarios generales ...................................................................... 4

1.4.2 Algunas herramientas CASE comerciales ........................................ 5

1.4.2.1 BACHMAN ....................................................................... 6

1.4.2.2 PREDICT CASE ................................................................ 6

1.4.2.3 PRO IV Workbench ........................................................... 7

1.4.2.4 VISIBLE ANALYST WORKBENCH ............................. 7

1.4.2.5 WESTMOUNT I-CASE .................................................... 8

1.4.2.6CARDLE ........................................................................... 8

9

1.4.2.8 SALSA ................................................................................ 9

1.4.2.7 ADAGEN de Mark V System ............................................

1.4.3 Estado del arte de las herramientas CASE y su relación con

esta tesis ............................................................................................. 1 0

1.5 TENDENCIAS FUTURAS DE EA TECNOLOGIA CASE ........................... 12

1.6 ORGANIZACION DEL DOCUMENTO ...................... ; ................................. 13

CAPITULO 2

CONCEPTOS SOBRE PROTOTIPOS RAPIDOS Y HERRAMIENTAS CASE ........................................................ ; .......... 15

2.1 PROTOTIPOS RAPIDOS ................................................................................ 16

i i i

2.1.1 Enfoques para el desarrollo de prototipos ......................................... 17

2.1.1.1 Tipos de prototipos ............................................................. 17

2.1.1.1 . 1 Prototipos de remiendo ........................................ 17

2.1.1.1.2 Prototipos a escala no funcional ........................... 18

2.1 . 1 . 1.3 Primer modelo a escala completa ......................... 18

2.1.1.1.4 Un modelo que cuenta con ciertas

características esenciales .................................................. 19

2.1 . 1 . 2 Ventajas del uso de prototipos ............................................ 20

2.1.1.3 Problemas con el uso inadecuado de los prototipos ............ 21

2.1.2 El papel del usuario en el prototipo ................................................... 21

. 2.1.2.1 La interacción con el prototipo ........................................... 22

2.2. HEaMIENTAS CASE .............................................................................. 23

2.2.1 Clasificación de las herramientas CASE ........................................... 23

2.2.1.1 Clasificación atendiendo a la fase del ciclo de vida que

soportan ........................................................................................ 23

2.2.1.2 Clasificación según McCLURE .......................................... 23

2.2.1.3 Clasificación según SOMMERVILLE .............................. 24

2.2.1.4 Clasificación según FUGGETTA ..................................... 24

.................................................... 2.2.2 Evolucibn de la tecnología CASE 25 . .

2.2.3 Adopción de la tecnología CASE ..................................................... 26

2.2.4 Beneficios de las herramientas CASE .............................................. 28

CAPITULO 3

PLANTEAMIENTO GENERAL DEL PROBLEMA Y PROPUESTA DE SOLUCION ...................................................... 30

3.1 EL CICLO DE VIDA TRADICIONAL DE LOS SISTEMAS ...................... 31 3.2 LIMITACIONES DEL CICLO DE VIDA TRADICIONAL ......................... 32 3.3 OTROS MODELOS DEL CICLO DE VIDA ................. ~ ............................... 33

3.3.1 El modelo en espiral para el desarrollo de software .......................... 33

iv

c

3.3.2 Modelo del ciclo de vida incremental basado en prototipos ............ 35

3.4 DETERMINAR LAS NECESIDADES DEL CLIENTE ............................... 37

3.5 ETAPAS PARA EL USO DE PROTOTIPOS DE SISTEMAS .................... 39

3.6 PLANTEAMIENTO GENERAL DEL PROBLEMA .................................. 40 3.7 ALCANCE DE LA TESIS ............................................................................ 47

CAPITULO 4

ARQUITECTURA Y CONSIDERACIONES DE DISENO DEL GENERADOR AUTOMATICO DE CODIGO ................................................................................................... 49

4.1 ARQUITECTURA CONCEPTUAL DEL GENERADOR

AUTOMATICO DE CODIGO ........................... : ......................................... 50

4.2 MODULO ANALIZADOR ........................................................................... 50 . 51

52

53

4.2.3.1 Gramática para la definición del esquema de la BD .......... 53

4.2.3.2 Análisis léxico ................................................................... 54

4.2.3.3 Análisis sintáctico ............................................................. 54

4.2.3.4 Acciones semánticas ......................................................... 58

60

60

4.2.4.2 Análisis léxico ................................................................... 61 4.2.4.3 Análisis sintáctico ......................................... ; ................... 61

4.2.4.4 Acciones semánticas ......................................................... 63

. 4.3 MODULO DE PERSONALIZACION ......................................................... 63

4.4 MODULO GENERADOR DE CODIGO ..................................................... 65 66

4.2.1 Especificación para la definición de la BD ..................................... :

4.2.3 Análisis de esquemas de BDs en SQL ............................................... 4.2.2 Especificación para las consultas de informes .................................

. .

. . .

4.2.4 Análisis para la especificación de consultas de informes ................ 4.2.4.1 Gramática para la definición de comultas a la BD ...........

. .

4.4.1 Generación de la unidad de constantes del sistema ......................... 4.4.2 Generación de la unidad de control de opciones e interacción

V

con el usuario ................................................................................... 66

4.4.3. Generación de La unidad de clases para diálogos, botones, etc ...... 67

4.4.4 Generación de las rutinas de manipulación de los datos de cada

tabla de la BD .................................................................................. 67

4.4.4.1. Generación de código para la verificación de la . . . restnccion referenci al ...................................................... 72

4.5 MODULO PRECOMPILADOR ................................................................... 74

4.6 MODULO GENERADOR DE ARCHIVOS EJECUTABLES .................... 75

4.7 REPRESENTACION ESQUEMATiCA AL NIVEL MAS ABSTRACTO .. 75

4.7.1 Sistema de directorios ...................................................................... 76

4.7.2 Sistema de proteccion ...................................................................... 77

4.7.2.1 Verificación de datos de seguridad ................................... 77

4.7.2.1.1 Apertura de una BD existente ............................ 77

4.7.2.1.2 Creación de una nueva BD ................................. 78

4.7.3 Convenciones de nombres de archivos ............................................ 79

..

CAPITULO 5

PATRON DE DISENO DE LOS SISTEMAS PROTOTIPO .................................................................................................. 80

5.1 ARQUITECTURA FUNCIONAL DEL PROTOTIPO ................................. 81

5.1.1'Mantenimiento ................................................................................. 81 . .

5.1.2 Informes ........................................................................................... 82

83 83

5.2 MODULOS COMPONENTES DEL SISTEMA Y SUS OBJETOS ............ 85

5.2.1 Objetos del sistema .......................................................................... 86

86

5.1.2.1 Salida por pantalla ............................................................ 5.1.2.2 Salida por impresora .........................................................

5.2.1.1 Ventana para captura de datos (formas de captura) .......... 5.2.1.2 Ventana de petición de los campos clave (para bajas

o consultas) ....................................................................... 86

vi

5.2.1.3 Ventana para muestra de datos ......................................... 87

5.2.1.4 Objetos para distintos tipos de cajas de diálogo ............... 87

5.2.1.5 Objetos de control ............................................................. 88

5.2.2 Módulos del sistema ........................................................................ 88

5.2,2.1 Programa pnncip al ............................................................ 88

5.2.2.2 Unidad de constantes ........................................................ 89

5.2.2.3 Unidad de objetos ............................................................... 89

5.2.2.4 Control de opciones e interacción con el usuario ............. 89

5.2.2.5 Conjunto de unidades por cada una de las tablas que

. .

. .

participan en la base de datos ............................................. 5.2.2.5.1 Unidad para rutinas de altas, bajas, cambios

89

y consultas ......................................................... 89

93

93

5.2.2.7 Unidad del SMBDD .......................................................... 94

5.2.2.5.2 Unidad para informes .......................................... 5.2.2.6 Unidad de tipos de datos ...................................................

CAPITULO 6

PRUEBAS .......................................................................................................... 95

6.1 OBJETIVO Y DESCRIPCION DE LAS PRUEBAS .................................... 6.2 CASOS DE PRUEBA ....................................................................................

96

96

CAPITULO 7

COMENTARIOS FINALES .................................................................. 129

7.1 CONTRIBUCION DE LA INVESTIGACION ............................................. 130

7.2 LIMITACIONES DEL TRABAJO ................................................................ 131

7.3 TRABAJOS FUTUROS ................................................................................. 131

7.4 OTRAS OBSERVACIONES ......................................................................... 132

ANEXOS ANEXO A

GRAMATICA PARA LA DEFINICION DE TABLAS .................................... 134

ANEXO B

BLOQUES DE RUTINAS GENERADORAS Y GENERADAS ...................... 137

ANEXO C

CONCEPTOS BASICOS DE PROGRAMACION ORIENTADA A

OBJETOS Y TECNICAS DE ANALISIS Y DISENO ESTRUCTURADO ..... 151

viii

LISTA DE FIGURAS

Fimira Nombre

2.1 2.2 2.3 2.4

3.1 3.2 3.3 3.4 3.5 3.6

3.7

3.8

.4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

4.9 4.10 4.11 4.12 4.13

Prototipo de remiendo Prototipo no funcional Modelo a escala completa Un modelo que cuenta con ciertas características esenciales

El enfoque tradicional del ciclo de vida El modelo en espiral del proceso de software Prototipo de desecho Prototipo incorporado Prototipo incremental Nuevo enfoque del ciclo de vida en espiral con prototipos incrementales e incorporados Fases del desarrollo de BDs con enfoque a los modelo de creación de prototipos incremental Fases del desarrollo de BDs con enfoque a los modelo de creación de prototipos incremental e incorporado

Esquema conceptual del generador de código Esquema para la fase de análisis Ejemplo de una especificación para la definición de una BD. Ejemplo de una especificación para las consultas de informes Esquema que muestra la interacción de los distintos módulos Bloques que conforman el archivo ejecutable (.Em) Esquema de dependencia entre las tablas tesis, alumnos y cubics Parte de la estructura interna del diccionario de formas para la tabla alumnos Generación del archivo ejecutable Ejemplo del sistema de directorios Estructura para el esquema de protección Esquema de verificación de los datos de usuario Almacenamiento de los datos de usuario

Pág.

18 18 19 19

31 33 36 36 37 42

44

46

50 51 52 53 65 65 73 74

75 77 77 78 78

5.1 Arquitectura genérica de los prototipos generados 81 5.2 Ventana inicial del prototipo generado 82 5.3 83 5.4 83 5.5 Ventana para captura 86 5.6 Ventana para petición de campos clave 87 5.7 Ventana para muestra de datos 87

Ventana para el mantenimiento de la base se datos Ventana para la selección de informes por pantalla o impresora

ix

Figura Nombre Pág.

5.8 5.9

6.1

6.2

Diagrama jerárquico de los módulos componentes del sistema prototipo 88 91

107

114

Jerarquía de tipos de objetos utilizados en el sistema prototipo

Diagrama de dependencia referencial entre las tablas “ARTICULO” y “DEPAS” . Diagrama de dependencia referencial entre las tablas “FACTURA” y “CLIENTE”

“TRABAJAS” y “DEPTO

“TRAB” y “DEPARTAM”

6.3 Diagrama de dependencia referencial entre las tablas “BONOS”, 120

6.4 Diagrama de dependencia referencial entre las tablas “PUESTOS”, 125

X

LISTA DE TABLAS

Tabla Nombre Pág . 1.1 Tabla ilustrativa para diversas herramientas CASE ........................................... 11

3.1

7.1

Fuentes de errores y su respectivo porcentaje de contribución .......................... 41

Resultados de las pruebas del generador de prototipos ...................................... 132

XI

C APÍTULO 1 INTRODUCCION

En este capítulo se abordan los puntos principales para poder situar el trabajo dentro de un contexto. Como primer punto se plantean los motivos que impulsaron al desarrollo de este trabajo, posteriormente se describe el objetivo del proyecto de tesis, así como los beneficios que se obtienen al contar con un trabajo como este. Como puntos finales del capítulo se da un panorama acerca del estado del arte de las herramientas CASE y finalmente se presenta la organización del contenido de la tesis.

1

INTRODUCCION CAPlTULO I

1.1 MOTIVACION

A continuación se presentan algunas deficiencias que se han observado en el proceso de desarrollo de sistemas de información y que fueron las principales motivaciones para la realización de esta tesis.

- Se ha observado que en los sistemas de información en donde hay ambigüedad en la especificación de sus requerimientos, los tiempos y costos tienden a incrementarse notablemente [MIR87].

- Los prototipos rápidos ayudan a reducir la ambigüedad en la especificación de los requerimientos debido a que propicia la comunicación entre el usuario y el desarrollador del sistema, sin embargo, estos tienden a ser caros [KEN91].

- Existen herramientas de software que generan prototipos rápidos, sin embargo, estos son diseñados para ser desechados, esto es, que su código no está orientado a su reutilización, ya que no está documentado, las variables que en éi aparecen no tienen nombres descriptivos, y que en general, no cumple con las características para que pueda ser modificado.

- Existen muchas herramientas de software que no dan mucha facilidad en SUS

especificaciones de entrada, es decir, se tiene que pasar por un previo proceso de edición gráfica para entonces poder generar código.

1.2 OBJETIVO DE LA TESIS

El objetivo general de esta tesis es diseñar y desarrollar una herramienta CASE que a partir del esquema de una Base de Datos (BD) genere de manera automática el código de los programas necesarios para realizar las operaciones de altas, bajas, cambios y consultas a una BD, manteniendo la regla de integridad referencia1 del modelo relacional.

De manera particular, se tienen los siguientes objetivos:

a) Se pretende que dicha herramienta genere de forma automatizada prototipos rápidos, la cual es una técnica muy valiosa empleada para identificar con rapidez y claridad las necesidades particulares de información de los usuarios.

b) Que los prototipos generados sirvan como un medio de comunicación entre el desarrollador y el usuario del sistema,

2

INTRODUCCION CAPITULO 1

c) Que el código generado de manera automatizada pueda ser reutilizado para generar el sistema real (sistema que finalmente será entregado al usuario y que debe cumplir con los requerimientos definidos), disminuyendo de esta manera tiempos y costos de desarrollo.

d) Por otro lado, en los casos en los que los sistemas que se requieren no sean muy complejos, los prototipos generados bien podrían ser excelentes representantes del sistema final.

e) Que los prototipos generados por el Generador de Prototipos Rápidos (GPR) esté bajo el paradigma de Programación Orientada a Objetos y además que su código aparezca comentado.

1.3 BENEFICIOS

A continuación se muestran los principales beneficios que se pueden obtener con el desarrollo de un generador automático de código diseñado para la creación de sistemas de información:

a) Reducción en tiempos y costos en el desarrollo de sistemas de información

b) Mejora en las especificaciones de los sistemas de información por medio del desarrollo de prototipos.

c) Facilita la comunicación entre el usuario y el desarrollador del sistema, ya que los usuarios pueden ver rápidamente un prototipo de lo que será su sistema.

d) Parte o la totalidad del código del prototipo generado puede ser reutilizado para construir el sistema real.

e) Con el desarrollo de la herramienta, se muestra la factibilidad de desarrollar productos de software de alta calidad como subproducto de una investigación.

f ) Aunque no es una herramienta para diseño, nos puede ayudar en esta fase, ya que permite probar diferentes alternativas de diseño de BDs.

g) Se facilitan en gran medida las refinaciones sucesivas del esquema de la BD.

h) Un beneficio adicional de aspecto académico, es que al contar con el diseño, arquitectura y código fuente de la herramienta CASE, esta puede servir como

3

IN JRODUCC~ON OIPITULO 1

apoyo didáctico para la enseñanza de ingeniería de software, y adicionalmente por considerar qÜe dicha herramienta constituye un compilador, puede ser de gran ayuda en la enseñanza de compiladores.

1.4 ESTADO DEL ARTE EN HERRAMIENTAS CASE

A continuación se da un breve panorama del estado del arte en las herramientas CASE en un sentido general, así como las características de algunos productos comerciales. Es importante señalar que algunas de las técnicas de análisis y diseño estructurado que se mencionan en esta sección, aparecen descritas más ámpliamente en el Anexo C.

1.4.1 Comentarios generales

Las herramientas CASE son una de las aplicaciones que han motivado la aparición de la tecnología de objetos, junto con otras como CAD/CM, CIM, sistemas de oficinas, sistemas expertos, etc.

En particular, los SMBD (Sistemas Manejadores de Bases de Datos) orientados a objetos constituyen una de las bases adecuadas sobre las que se implementan los repositorios de las herramientas CASE.

Por otro lado, recientemente han aparecido nuevas herramientas CASE que soportan las notaciones y las metodologías de análisis y desarrollo orientados a objetos más conocidas: OONOOD de Coad y Yourdon, Shlaer y Melior; OMT de Raumbaugh, Martin y Odell, Booch, etc. [PIA95].

Un gran número de estas herramientas han surgido expresamente para sopork estas nuevas metodologias; por ejemplo, ObjectMaker de Mark V Systems, Objecteering de Softeam, Iconix Powertools de Iconix Software Eng, etc., y en su participación han intervenido los principales metodólogos [PIA95].

La mayor parte de estas herramientas funcionan bajo Windows en computadoras personales o en máquinas con sistema operativo UNIX, hay que tener en cuenta que suelen requerir bastantes recursos para funcionar de manera aceptable (generalmente entre 16 y 32 M de memoria), debido al importante componente gráfico.

4

lNTRODUCClON CAPlTULO I

Por otra parte, algunas herramientas CASE tradicionales, es decir, que soportan métodos y técnicas de análisis y diseño estructurado, han sido extendidas con el fin de abarcar el desarrollo orientado a objetos.

En definitiva, existen numerosas aproximaciones para construir herramientas CASE que soporten el desarrollo orientado a objetos, puesto que es un mercado que está experimentando un gran crecimiento y que ningún fabricante quiere dejar escapar.

A pesar de este gran movimiento en el mercado, en general el soporte CASE para la orientación ai objeto’no es tan maduro como el de los métodos tradicionales. Conocidos expertos en esta área, opinan en este sentido que el estado de la práctica de las herramientas CASE orientadas al objeto refleja una efectividad mucho menor que en caso de las herramientas CASE para métodos estructurados, aunque señala que en un futuro no muy lejano esta situación va a invertirse en favor de las que soportan objetos [PIA95].

“En general, puede afirmarse que aquellas herramientas que soportan muchas notaciones no consiguen realmente ayudar en la aplicación de una metodología con todo su proceso y validaciones correspondientes, sino que se suelen quedar más bien a un nivel exclusivamente gráfico. Por el contrario, las que se centran en una sola metodología, consiguen recoger prácticamente toda su semántica y ayudar al diseñador en la validación de los sistemas, además de generar un código de mayor calidad” [PIA95].

La mayor parte de las herramientas CASE suelen generar código C++; algunas simplemente la definición esquemática de las clases, y otras pueden llegar a generar hasta un 60% del código del sistema. Una limitación importante en este sentido, es que muy pocas generan código en otro lenguaje que no sea C++, como, por ejemplo, Smalltalk, Eiffel u otros lenguajes para programar bajo el paradigma orientado a objetos.

Un aspecto muy importante a tener en cuenta es la escasa capacidad que presentan de momento muchas herramientas a la hora de verificar la congruencia de los diseños.

1.4.2 Algunas herramientas CASE comerciales

Debido a que el principal objetivo de esta tesis es el desarrollo de una herramienta CASE, en esta sección trataremos las principales herramientas de este a

5

CAPITULO 1 lNTRODUCClON

tipo más difundidas en el mercado, con la finalidad de ubicar esta tesis dentro del contexto que se ha estado desarrollando dicha herramienta.

1.4.2.1 BACHMAN

Bachman Information systems fue fundada en 1983 por Charles Bachman, inventor del primer sistema de gestión de bases de datos.

El objetivo de BACHh4AN Information Systems es desarrollar y comercializar un conjunto integrado de productos software orientados a la creación y mantenimiento de sistemas de información.

Las soluciones abiertas que hoy ofrece están basadas en la reingeniería, reutilización e integración de información, y su implementación en distintas bases de datos y plataformas, incluyendo el entorno cliente/servidor.

Actualmente, las soluciones ofrecidas por BACHMAN incluyen el diseño, mantenimiento y optimización de bases de datos críticas, el modelado de procesos, metodologías de trabajo y herramientas para la construcción de aplicaciones en tecnologías tradicionales y en cliente/servidor. La arquitectura abierta con las que están diseñados sus productos permite crear aplicaciones que integran diversas fuentes de información, modificarlas en función de los cambios tecnológicos y de la actividad de la empresa, y ejecutarlas en una gran variedad de plataformas. [PIA951

1.4.2.2 PREDICT CASE

PREDICT CASE es una herramienta que ayuda al análisis, diseño y construcción de sistemas de información dentro del entorno de cuarta generación NATURAL. Ofrece una solución integrada al desarrollo de aplicaciones comerciales y de gestión que utilicen esta tecnología.

El centro neurálgico de PREDICT CASE es la base de datos de desarrollo integrada o repositorio, multiusuario y multiproyecto, que recoge la información manejada durante el desarrollo de los sistemas. El repositorio almacena todos los datos relativos a los objetos definidos en las distintas fases del proyecto (entidades, funciones, flujos de datos, etc.), los datos necesarios para la correcta administración del sistema (perfiles de usuario, uso de librerías, seguridad, etc.), y los datos asociados a la gestión del proyecto (estándares de documentación, estándares de diseño, ciclos de vida, etc.). El repositorio tiene una metaestructura pública y es controlado por un gestor de base de datos entidad relación (ER-

6

INTRODUCCION CAPITULO 1

DBMS), que permite una mayor riqueza semántica que los gestores convencionales.

En torno a este repositorio se articulan una serie de subsistemas para mantener y explotar el contenido del mismo. Entre los principales, podemos citar los siguientes: mantenimiento de objetos, generación de aplicaciones NATURAL (incluyendo soporte de prototipado), generación de documentación y control de calidad [PIA95).

1.4.2.3 PRO IV Workbench

PRO-IV es un paquete de herramientas avanzadas e integradas de desarrollo para las fases de análisis, diseño y desarrollo del ciclo de vida de sistemas de información. La aplicación en este CASE proporciona un marco efectivo y eficiente para traducir los objetivos estratégicos de la compañía en un software que satisfaga los requerimientos establecidos.

PRO IV Workbench utiliza directamente las técnicas fundamentales del desarrollo de software. El módulo de Analyzer soporta la fase de análisis, desde la creación de DFD (diagramas de flujo de datos) hasta la generación de la documentación asociada. El Prototyper permite la generación de prototipos del sistema. El módulo de Data Modeler soporta la definición de la estructura de datos. El Designer provee del entorna necesario para el diseño de diagramas de estructuras. Un repositorio integrado, un sistema de generación de reportes, y el mantenimiento de diferentes proyectos y versiones, completan el ciclo de la herramienta. Además, cuenta con herramientas adicionales para funciones auxiliares, tales como importación y exportación, backup, etc. [PIA95].

1.4.2.4 VISIBLE ANALYST WORKBENCH

VAW es un conjunto de herramientas CASE diseñadas para soportar proyectos en equipo para el desarrollo de sistemas de información utilizando técnicas estructuradas sobre una metodología de desarrollo. Algunas de las metodologías soportadas por VAW son: Information Engineering, Yourdon Structured Method, SDM, DFD, Diagramas de descomposición funcional, mapas de estructuras, etc.

El VAW tiene una excelente relación prestaciones/costo. Los requerimientos de hardware son los mínimos de la actual tecnología PC, trabajando con MS DOS y Windows. En su implementación multiusuario el VAW opera con Novel1 Netware y otras LANs proporcionando a múltiples

7

INTRODUCCION

usuarios de CASE conectados a la red: acceso concurrente, gestión de bloqueo de archivos y registros, distintos niveles de seguridad de proyectos, etc.

CAPlJULO 7

La arquitectura del VAW ha sido realizada s e g h la filosofia OPEN CASE, permitiendo la importaciódexportación con numerosos entornos de desarrollo, generadores de aplicaciones y otras herramientas CASE.

El VAW ofrece importantes ayudas de desarrollo, generando programas fuente en ANSI COBOL y C, además de SQL DDL para los principales SGBDR @B2, Oracle, Informix, Gupta, SQL Server, etc.).

VAW es un producto de constante evolución que se adapta continuamente a las nuevas tecnologías. Las próximas versiones incorporarán técnicas de análisis y diseño orientado a objetos, soporte para UNIX, OSí2, IS0 9000, Total Quality Management, etc. [PIA95].

1.4.2.5 WESTMOUNT I-CASE

WESTMOUNT I-CASE es una herramienta que trabaja en entornos gráficos X y OSFMotif. Posee versiones que soportan Yourdon, Wardhíeilor, SSADM y OMT. Cubre el ciclo completo de vida del desarrollo de un sistema de información (análisis, diseño, generación de código y mantenimiento). Toda la información se almacena en un diccionario o Repository integrado en INGRES, INFORMIX, ORACLE o SYBASE. Westmount I-CASE genera aplicaciones clientehervidor para los entornos de desarrollo 4GL de INGRES, Windows 4GL de INGRES, 4GL de INFORMIX, RDS de INFORMIX, ORACLE, UNIFACE, C y C++. WESTMOUNT I-CASE incluye un módulo para la generación automática de la documentación " completa del sistema desarrollado. WESTMOUNT I-CASE trabaja en entorno UNIX y VMS [PIA95].

1.4.2.6 CARDLE

CARDLE es una herramienta CASE que soporta todas las fases del ciclo de vida. Estas incluyen características para la planeación estratégica, análisis y diseño estructurado, generación de código, y administración de proyectos. CARDLE soporta el método estructurado de Yourdon para el desarrollo de sistemas de información y hace uso de un diccionario de datos, el cual representa las especificaciones, y de esta forma da una entrada al generador de código el cual proporciona generación de tipos desde el diccionario de datos y código procedimental a partir de gráficas y módulos de especificación [OMA90].

8 I!

lNTRODUCClON CAPlTUlO 7

1.4.2.7 ADAGEN de Mark V System

Es una herramienta CASE basada en gráficos, soporta el desarrollo en Ada tradicional y orientado a objetos. Es posible seleccionar entre diversos métodos y notaciones así como sus propias técnicas para modelar los sistemas de información.

Durante el análisis, se pueden crear diagramas de flujo de datos, diagramas de flujo de control, así como diagramas de entidad relación y diagramas de transición de estados. Durante el diseño se pueden seguir métodos de diseño estructurado o usar notaciones Buhr o Booch. Una vez que se ha completado el diseño del sistema de Ada, Adagen puede generar código de diagramas Buhr. La generación de código incluye declaraciones de generación anidada de unidades de programas con sus entradas asociadas y parámetros formales, diversos tipos de estatutos de interfaces, objetos de datos, y tipos [OMA90].

1.4.2.8 SALSA

SALSA es una herramienta bajo Windows orientada a crear aplicaciones de bases de datos. SALSA proporciona ayuda para crear sistemas de inventarios, clientes, empleados, y cualquier otro tipo que se desee.

A diferencia de Microsoft Access, Lotus, y Borland Paradox los cuales requieren de cierta programación para construir aplicaciones del mundo real, SALSA incluye un sofisticado diseñador para el modelado de datos con un generador que crea la aplicación completa. Aunque pudiera pensarse que el diseño del modelo involucra cierta técnica, SALSA hace esta tarea fácil para los usuarios, ya que proporciona una lista predefinida de plantillas para las necesidades más comunes de negocios. Desde este modelo, SALSA crea la base de datos, así como la aplicación completa, incluyendo menús, formas, y reportes. Una vez que la aplicación es generada, el usuario puede introducir o importar datos y buscar y generar reportes inmediatamente.

El modelo es el corazón de las aplicaciones de bases de datos en SALSA, éste se diseña para representar los datos que se desean crear. SALSA usa este modelo para crear la base de datos y la aplicación. Es posible regresar y cambiar el modelo, y SALSA modificará la base de datos y la aplicación de acuerdo a estos cambios [RAJ96]. I

9

amuLo I INJRODUCCION

1.4.3 Estado del arte de las herramientas CASE y su relación con esta tesis

Una vez que se han listado sólo algunas de las herramientas CASE de mayor difusión en el mercado, a continuación se pretende ubicar el trabajo que se expone en esta tesis, dentro del mismo contexto en el que se encuentran todos estas herramientas.

Se presenta una Tabla (Tabla l.l), en donde se muestran algunas de las herramientas CASE mencionadas anteriormente, y por supuesto el “GENERADOR DE PROTOTIPOS RÁPIDOS”, que para fines prácticos dentro de esta sección llamaremos GPR.

Como puede verse en la Tabla 1.1, el GPR abarca las fases del ciclo de vida correspondientes al análisis, diseño y codificación. Las primeras dos son consideradas genéricas, ya que los prototipos generados presentan la misma arquitectura (Ver capítulo 5). Por otro lado, es importante mencionar que el GPR utiliza la metodología de programación orientada a objetos (POO) y la técnica de generación de prototipos. Si comparamos este último punto, se puede ver que la mayoría de las herramientas comerciales que se presentan no son capaces de soportar la PO0 y solo el GPR y el PREDICT CASE consideran la generación de prototipos.

El GPR es una herramienta que comparte la plataforma Windows con la mayoría de las herramientas comerciales que se presentan, lo cual nos hace pensar que en este sentido se encuentra ubicada casi a la par que el resto de las comerciales presentadas. Una ventaja que adicionalmente se puede obtener al trabajar en esta plataforma es que es posible contar con todas las ventajas que nos proporciona el ambiente en Windows.

Por otra parte, se ve cómo el GPR el la única herramienta que presenta la facilidad de recibir como entrada el esquema de una BD en forma de texto, IO Cual representa una gran ventaja sobre las demás. En general, la mayoria de las herramientas que se presentan aquí permiten entradas a través de diseños gráficos.

10

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

I!

lNJRODUCClON cmruLo I

enamient; L Fases del

Ciclo de Vid

Técnicas y Metodología

Plataformas

Parte del Esquema textual de la BD

Legibilidad para el reus( de los componente!

Lenguajes en los cuales se genera el código

Código generado O 0

3ACHMAN PREDICT CASE PRO IV Workbench WESTMOUNT GENERADOR DE PROTS.

RAPWOS(GPR)

Todas Estudio Previo ,; Análisis cohcepiual Análisis, An6lisis y Diseno. implania&ón. Diseao Fisica Diseao. Diseiio Genérico, Adlisis de reqs. Gen. de Cod. Codilicari6n Constnicción y Milo M m .

Rcingenicria. EIR. DFD. Diseño EIR. DFD. DFD. E/R.DSD. P O 0 Análisis 00, lógico de BDs. Relacional Yourdon.Es. Prototipos EIR, DFD. etc Prololips. !. Balchman. Chen.

Yatrd.3"

osli. IBM o compatibles MS-DOS. Windows. UNIX. Windows NOVELL UNIX. MVS ver. para Win.

NO NO NO

SI NO

COBOL. NATURAL Pra4GL. Telón CSP. APS. Transform TELON I/

NO NO NO

UNIX Windows y VMS

NO. SI

I SI

SQL embcbido SQL embebido en C para lngres en Pascal para e Informix, 4GL Windows de lngrcs c Informix SQL de lngrcsd Informix/Oracic/ Sybasc

NO SI

* No aparece en la literatura consultada

Nota: Esta informacion ha sido facilitada por los propios distribuidores, por lo que les compete a ellos la responsabilidad en cuanto a la veracidad de las afirmaciones expuestas @'IA95].

~

Tabla 1.1 Tabla comparativa de las herramientas,CASE y el GPR

96025';' CENTRO DE INFORMACION

CENIDET b.

- -- 7 - - -. . . -- - -.

\ INTRODUCCION

cAPiruo I

Puede verse también, que el GPR es capaz de generar código con caractensticas idóneas para su reutilización, como lo es que el código se encuentre documentado, con nombres de variables representativos, y totalmente orientado a objetos. Mientras que de las herramientas comerciales, solo la de BACHMAN nos da la capacidad de reuso de código, sin embargo en la literatura especializada no aparece el dato de qué tan legible, y qué características tenga el código generado por ésta y otras de las herramientas.

I/

Otro aspecto que es importante comentar, es que el GPR es capaz de generar código en Pascal para Windows logrando así que el código resultante sí sea Orientado a Objetos, y adicionalmente este código presenta instrucciones de SQL intercaladas, mientras que de las herramientas comerciales que se muestran, WESTMOUNT es la única que genera código SQL embebido en un lenguaje de tercera generación y que a diferencia del GPR, ésta lo hace usando como lenguaje . anfitrión “C”, que no es un lenguaje Orientado a Objetos.

H

1.5. TENDENCIAS FUTURAS DE EA TECNOLOGIA CASE I1

El objetivo de esta sección es presentar las tendencias más importantes que se vislumbran dentro de la tecnología CASE, tendencias que nos ofrecen la posibilidad de adoptar una actitud innovadora en el desarrollo de sistemas de información.

‘I

Es importante mencionar en primer lugar el soporte que ofrecen y ofrecerán las herramientas CASE para el diseño de bases de datos, aspecto que cada día cobra mayor importancia en todos los ámbitos.

En segundo término podemosimencionar el desafio que tienen tanto los fabricantes como los organismos de estandarización es conseguir una mejor integración entre las diferentes herramientas, las cuales deberán ser más abiertas, soportando una mayor variedad de técnicas y metodologías, entre las que se destacan las orientadas al objeto.

I Por otro lado, se necesita una mayor investigaci6n para el soporte de

sistemas que sean distintos de los clásicos de información, como por ejemplo los sistemas en tiempo real.

Otra de las tendencias es la adaptación de las herramientas CASE, que surgieron en estaciones de trabajo (sobre todo en entorno UNIX), a sistemas operativos distintos de UNIX.

-_ - - . - -- - ~

-- - - - \

I! INTRODUCCION CAPITULO 1

Un nueva línea de investigación que empieza ya a aparecer en el mercado es la integración de sistemas expertos en las herramientas CASE, los cuales se encargan de guiar al usuario a lo largo de todo el ciclo de vida, aconsejando en la utilización de la metodología y verificando la congruencia del desarrollo.

Otro reto que se debe afrontar en el desarrollo de sistemas de información es comprender el propio proceso de desarrollo, para ser capaz de modelarlo y adaptarlo a las distintas empresas. ES quizá esta palabra, adupución, una de las características clave que ha de poseer el CASE del futuro.

Todas estas características llevarán a herramientas CASE más dinámicas que se completarán con: ejecución de especificaciones del sistema, analizadores de código dinámicos, entornos de prototipado rápido, simuladores, etc., lo que producirá una nueva generación de herramientas, que contribuirá a la mejora de la calidad y productividad de los sistemas de información.

1.6 ORGANIZACION DEL DOCUMENTO II

El contenido de la tesis está organizado de la siguiente manera:

En el Capítulo 2 se da una introducción a los conceptos de prototipos rápidos y herramientas CASE, esto es con la finalidad de introducimos un poco al área en que se trabaja y damos una idea del enfoque que presenta este trabajo.

I/

En el Capítulo 3 se realiza un análisis y planteamiento del problema que se está tratando en este trabajo, además se especifica también el alcance del mismo con la finalidad de definir claramente las limitantes; y finalmente se plantean algunos puntos relevantes que se consideran de importancia para lograr abrir un panorama completo del trabajo. 11

En el Capítulo 4 se define la arquitectura y consideraciones de diseño del generador automático de código. Se describen algunos algoritmos y esquemas que permitirán entender la implementación intema de los programas que se desarrollaron.

En el Capítulo 5 se describe la arquitectura y diseño de los sistemas prototipo, además de su descripción funcional.

13

1 INTRODUCClON CAPITULO 1

En el Capítulo 6 se definen los criterios de evaluación para las pruebas que se realizaron, y que demuestran la correcta funcionalidad del trabajo.

En el Capítulo 7 se dan una serie de conclusiones y comentarios finales, que reflejan los resultados y experiencias obtenidas durante el desarrollo de la tesis, así como posibles extensiones a la misma.

Finalmente, se presentan tres anexos que fueron incluidos por considerar que podrían ser de interés para el lector. El anexo A incluye la gramática para la definición de tablas, el anexo B contiene algunas rutinas generadoras de código y algunas otras que son generadas, mientras que el anexo C contiene conceptos básicos de la programación orientada a objetos, así como algunas técnicas de análisis y diseño estructurado.

'!

I!

'I

I'

14

- . -

Ij

!I

Ii

2 , I1

C APÍTULO

II CONCEPTOS SOBRE PROTOTIPOS

RAPIDOS Y HERRAMIENTAS CASE

-- r

En este capítulo se dan algunos conceptos sobre la creación de prototipos rápidos así como de herramientas CASE, esto es con la finalidad de introducirnos en el contexto dentro del cual se sitúa este trabajo.

15

CONCEPTOS SOBRE PROTS. RAPIDOS Y HERRAMIENTAS CAS€ iI

CAPITULO 2

2.1 PROTOTIPOS W I D O S I/

El desarrollo de prototipos es una metodología muy valiosa para poder lograr tener una visión muy clara de las necesidades de información de los usuarios, y sobre todo de una manera muy rápida.

I1 En general se considera que el desarrollo de prototipos debería realizarse en

las primeras etapas del ciclo de vida del software, es decir en la etapa de especificación de requerimientos, sin embargo, para poder lograr que un prototipo nos sea lo más útil posible, es necesario que se conozcan la mayoría de las características del sistema. II

Considerando que la creación de prototipos es una técnica muy importante para la obtención de información, podemos mencionar que durante la ,fase donde el usuario esté interactuando con el prhtotipo, el desarrollador del sistema debe estar muy atento para que sea capaz de observar las reacciones del usuario así como la de los jefes, esto es en el caso de que tales roles sean desempeñados por personas diferentes; de esta manera el desarrollador podrá captar las sugerencias de los usuarios sobre modificaciones al sistema bajo desarrollo o depuración si éste ya fue presentado con anterioridad, así como las posibles innovaciones hacia él.

Los tipos de información que el desarrollador debe buscar durante el uso de prototipos por parte del usuario son [KEN91]:

- Reacciones Iniciales del usuario

Durante la presentación del i,prototipo al usuario, el desarrollador debe observar todas las reacciones que el cliente o los jefes tengan ante este prototipo, es decir cómo son sus reacciones al trabajar con él, y sobre todo qué tan conveniente es el acoplamiento de las necesidades planteadas, y las características que han sido modeladas en el sistema. De esta manera el desarrollador se dará cuenta si los usuario se encuentran satisfechos conk1 o si habrá dificultades para poder vender o implantar el sistema.

- Sugerencias del usuario I1

El desarrollador debe estar pendiente de las sugerencias de los usuarios y de la gerencia en relación a posibles modificaciones o mejoras. Todo esto será el resultado de la relación que el usuario tenga con el prototipo, de tal manera que si existen sugerencias, éstas deben dar la guía o pauta al desarrollador para refinar el

a p l r u o 2 CONCEPTOS SOBRE PROTS. RAPIDOS Y HERRAMIENTAS CASE

prototipo, modificarlo o depurarlo, de tal forma de que logren satisfacer mejor las necesidades de los usuarios.

- Innovaciones It

Las innovaciones son aquellas características que no fueron contempladas desde antes de la interacción con el prototipo.

- Planes de revisión !

Los planes de revisión nos permitirán identificar las prioridades que deben considerase próximamente para el desarrollo del prototipo.

2.1.1 Enfoques para el desarrollo de prototipos

'/

En esta sección se da un panorama general de los prototipos, en donde se puede apreciar la diferencia entre sus distintos tipos , así como ventajas y desventajas en el uso de los mismos.

I1

2.1.1.1 Tipos de prototipos II

A continuación se presentan las cuatro definiciones más comunes para el desarrollo de prototipos.

2.1.1.1.1 Prototipos de remiendo II

Este tipo de prototipos se refieren a aquellos sistemas que aunque funciona bien, se encuentran parchados o remendados [KEN91].

II

Un ejemplo en los sistemas de información es la creación de un sistema que funciona correctamente, pero que es ineficiente, tal vez debido a que los programas se escribieron de una manera muy apresurada, y no se dio el tiempo suficiente para optimizar los procesos.

I'

il

1 7.

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

- -. . .. -~_ ;I

CAPITULO 2 CONCEPTOS SOBRE PROJS. RAPID05 Y HERRAMIENTAS CASE

Fig. 2.1 Prototipo de remiendo

il 2.1.1.1.2 Prototipos a escala no funcional

Son aquellos prototipos que no funcionan y que fueron construidos a escala, con el único objetivo de poder evaluar aspectos de diseño [KEN91]. Por ejemplo cuando se construye un automóvili a escala para realizar ciertas pruebas o evaluaciones; aunque el tamaño y la forma del automóvil es preciso, el vehículo no funciona. En este caso sólo se incluyen las características esenciales del automóvil para la realización de las pruebas necesarias.

1 Un ejemplo de modelo no funcional en un sistema de información a escala,

podría ser aquel en donde la codificación es muy extensa y se adopta la posición de poner en función únicamente los procesos de entrada y salida, con los cuales podría llevarse a cabo la evaluación sobre la utilidad del sistema.

I/

Fig. 2.2 Prototipo no funcional

2.1.1.1.3 Primer modelo a escala completa 1

Este tipo de prototipos consiste en crear .un sistema a escala completa o “piloto”. Esto es muy útil cuando se tiene pensado implantar el mismo sistema de información en varios lugares. Un modelo de este tipo permite una interacción realista con el sistema, reduciendo de esta manera, los costos de solución de cualquier problema que surja con el nuevo sistema [KEN91].

18 ‘I

-- __ -- - .. . -. _ _ -. - .

/I \ !I

CAPITULO 2 CONCEPTOS SOBRE PROTS. RAPID05 Y HERRAMIENTAS CASE

Un ejemplo podrían ser los sistemas de punto de venta que se encuentran en las cadenas de tiendas de autoservicib, en donde la idea es que el sistema se instale primero en una' sola tienda con el fin de detectar posibles problemas. En el caso de que no se presenten problemas o que ya se les haya dado solución, entonces se procede a realizar las instalación del sistema en toda la cadena de tiendas.

!I '.

Fig. 2.3 Modelo a escala completa

2.1.1.1.4 Un modelo que cuenta con ciertas características esenciales

Este tipo de prototipos incluyeialgunas, pero no todas las características que tendrá el modelo funcional [KEN91]. Por ejemplo, podría ser en un centro comercial que abre provisionalmente sus puertas.

Un sistema de información de este I) tipo, podrá contar únicamente con ciertas características esenciales, pero no todas. Por ejemplo, se podrían contemplar únicamente ciertas opciones básicas de un menú, de tal forma que si se aprueban estas funciones, serán incorporadas al sistema final sin ningún problema.

Fig. 2.4 Un modelo que cuente con ciertas características esenciales

CAPITULO 2 11

CONCEPTOS I/ SOBRE PROTS. RAPIDOS Y HERRAMIENTAS CASE

2.1.1.2 Ventajas del uso de prototipos il

Existen básicamente tres ventajas importantes en el uso de prototipos, las cuales son [KEN91]:

6

ModiJicación del sistema en etapas tempranas de su desarrollo I)

Un factor muy importante que determina el éxito de los prototipos, es con qué frecuencia se recibe la retroalimentación del usuario para hacer cambios y adecuarlos a las necesidades actuales. Como lo implica cualquier esfuerzo de sistemas, los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se realizan en las etapas posteriores.

I/

Debido a que con el uso de prototipos puede haber una gran retroalimentación con el usuario, esto nos permitirá conocer la opinión de éste sobre cambios a la entrada, al proceso o a la salida, lo cual traerá como consecuencia mejoras al sistema Definitivo. Aunque el desarrollo de prototipos implica inversión de tiempo y dinero, siempre será considerablemente menor a la de un sistema completo. De la misma manera, los problemas son más fáciles de detectarse en el prototipo con características limitadas que en un sistema complejo.

11

Eliminación de sistemas indeseables II

Otra de las ventajas, es la posibilidad de poder eliminar sistemas que posiblemente no llegarán a ser lo que el usuario esperaba. Por medio del prototipo es muy factible que el usuario se de un idea de si en realidad el sistema final le será útil o no satisfacerá las necesidades de información que se establecieron. Aunque esto podría en un momento dado considerake una decisión muy difícil, debido al tiempo y dinero invertidos, es mucho mejor que seguir trabajando en un proyecto que al final será inservible.

Diseño de un sistema acorde a las necekidades y expectativas de los usuarios

La tercer ventaja es que en la mayoría de los casos el uso de prototipos determina que los sistemas en desarrollo se ajustarán mejor a las necesidades de los usuarios. !

Una excelente práctica es interactuar con los usuarios a todo lo largo del ciclo de vida de desarrollo del software (SDLC), para lo cual deberá utilizar el prototipo como un instrumento de relación que se amolde lo mejor posible al sistema final.

20 i/

- - . _ - -- - - - - -

I/ CAPITULO 2 CONCEPTOS SOBRE PROTS RAPIDOS Y HERRAMIENTAS CASE

Si los usuarios desde el primer momento están interesados en el sistema de información, ellos serán los principales causantes del éxito.

II Cuando la evaluación de prototipo indica que todo va bien, es decir, dentro de

los lineamientos que se establecieron, debe mantenerse con la operación del prototipo y continuar su expansión.

2.1.1.3 Problemas con el uso inadecuado de los prototipos II

Algunos de los posibles problemas son :

La administración del proyecto 11

Puede ser factible que varias interacciones con el prototipo sean necesarias, sin embargo esto también puede acarrear problemas, debido a la extensión indefinida de su uso, por lo que es importante que el desarrollador del sistema planee muy bien la manera de como se registrará, analizará e interpretará la retroalimentación de uso del prototipo.

Deben buscarse retroalimentaciones periódicas de los usuarios, no todas a la vez, y se debe consultar si las soluciones o los cambios planteados han sido satisfactorios.

Adopción de un sistema incompleto como completo

:I En muchos casos en donde el sistema se requiere de manera urgente, el prototipo puede llegar a aceptarse a pesar de encontrarse incompleto y ponerse en servicio sin el refinamiento necesario, lo cual en cualquier momento traerá problemas a la empresa y a los desarrolladores.

1 Por otro lado, los usuarios pueden llegar a crear patrones de relación con el

sistema prototipo que no son compatibles con lo que ocurrirá con un sistema completo. Además si el prototipo no realiza todas las funciones requeridas, cuando salgan a flote sus deficiencias, éste se menospreciara, en el caso de que haya sido adoptado equivocadamente en la empresa como un sistema completo.

2.1.2 El papel del usuario en el prototipo

11

El papel del usuario en el prototipo consiste básicamente en honestidad y I/ compromiso. Si se carece de compromiso por parte del usuario, pocos son los

motivos para desarrollar un prototipo.

I¡ CAPITULO 2 CONCEPTOS SOBRE PROTS RAPID05 Y HERRAMIENTAS CASE

2.1.2.1 La interacción con el prototipo

I1 Hay tres formas principales según las cuales el usuario puede apoyar la evaluación del prototipo:

- Experimentar con el prototipo. - Plantear sin restricción, reacciones hacia el prototipo, - Sugerir mejoras o recortes al prototipo. 1

Experimentación con el prototipo

Los usuarios deben sentirse 11 en una completa y absoluta libertad de experimentar con el prototipo, ya que en los prototipos a diferencia del sistema real, no se restringirá la experimentación, claro a excepción de un mínimo de instrucciones.

¡I Es preferible que los analistas estén presentes cuando el usuario experimente

con el prototipo, de esta manera, podrá captar cualquier reacción que el usuario tenga ante el prototipo, así como las sugerencias e innovaciones que se presenten durante este proceso.

Plantear sin restricción las reacciones hacia el prototipo [I

Un papel muy importante del usuario hacia el prototipo, es el planteamiento sin restricción de sus reacciones hacia éste. Desafortunadamente, esto no sucede si no se crea un ambiente de confianza'entre él y los desarrolladores; ya que si el usuario percibe cierto enfrentamiento ai exponer sus opiniones acerca del sistema, es muy probable que opte por omitir ciertas sugerencias. Para tratar de que esto no suceda, es preferible que las sesiones sean privadas, con el mínimo de supervisión, donde el usuario pueda interactuar con el prototipo con toda libertad.

I

Cambios sugeridos en elprototipo

Otro de los papeles de los usuarios hacia los prototipos es sugerir ampliaciones o recortes de las caracteristicas que lleve hasta el momento, para lo cual el desarrollador debe determinar e identificar tales sugerencias, y finalmente decidir si se convierten en cambios funcionales.

1, .

li 22

. .i .. .. . - . ~ ___ - - . - ~- - . .

jl CAPITULO 2 CONCEPTOS SOBRE PROTS. RAPID05 Y HERRAMIENTAS CASE

2.2. HERRAMIENTAS CASE

I1 Desde a finales de los años sesenta que fue cuando surgió el término crisis del software, muchos investigadores han tratado de ocuparse de este problema describiendo sus síntomas y causas, así como también han propuesto distintas técnicas, metodologías y herramientas para disminuir sus efectos.

Entre todas ellas, destacan las conocidas bajo el nombre de CASE (Computer AidedAssisted SoftwarelSystem Engineering) que, en su acepción más amplia, se puede definir como las herramientas y metodologías que soportan un enfoque de

'I ingeniería en el desarrollo de software para todas las fases de este proceso.

2.2.1 Clasificación de las herramientas CASE

A continuación se muestran algunas clasificaciones de las herramientas CASE.

2.2.1.1 Clasificación atendiendo a la fase del ciclo de vida que soportan /I

CASE frontales (front-end) o superiores (Upper CASE), abarcan las primeras fases de análisis y diseño.

CASE dorsales (back-end) o inferiores (Lower CASE), cuyo objetivo suele ser el diseño detalladoy la generación de código.

Se denomina ICASE (Integrated CASE) a las herramientas que engloban ambos aspectos, e IPSE (Integrated Programming I) Support Environment) a aquellas que, además, incluyen componentes para la gestión de proyectos y la gestión de configuración.

2.2.1.2 Clasificación según McCLURE" 1

Juegos de herramientas (toolkit), son el tipo más simple, y están formados por un conjunto de herramientas que automatizan un tipo de tarea del ciclo de vida, como el análisis. Dentro de éstas, se incluyen los armazones (frameworks), que sirven para proporcionar una infraestructura en la cual acoplar y adaptar herramientas individuales.

'1

Bancos de trabajo (workbench), conjuntos de herramientas integradas que abarcan las fases básicas del ciclo de vida: análisis, diseño e

¡I

23

I1

CAPITULO 2 CONCEPTOS SOBRE PROTS. RAPIDOS Y HERRAMIENTAS CASE 11

'I implementación.

Compañeros de metodologías (methodology companions), que pueden ser cualquiera de los anteriores, siempre que soporten todas las fases y reglas de una metodología en particular.

2.2.1.3 Clasificación según SOMMERVILLEk

I1 Entornos de programación, pensados para soportar la programación, prueba y depuración de sistemas.

Bancos de herramientas CASE, orientados principalmente al análisis y 11 diseño.

Entornos de ingeniería de software, cuyo objetivo principal es la producción de grandes sistemas de software, y que soportan todas las actividades de desarrollo y mantenimiento.

I)

2.2.1.4 Clasificación según FUGGETTA*

o, Herramientas, que sopodan una tarea específica del proceso de producción de software, como la edición, programación, verificación y validación, gestión de configuración, métricas o gestión de proyectos.

I o Bancos de herramientas, que integran varias herramientas y que soportan: planificación y modelado estratégico, desarrollo de la interfaz de usuario, programación, verificación y validación, mantenimiento e ingeniería inversa, gestión de configuración o gestión de proyectos.

I o Entornos, que se caracterizan por soportar los procesos software, y que

este autor subdivide en:

- Juegos de herramientas, conjunto de productos débilmente integrados 11

- Entornos integrados, que utilizan mecanismos estándar para integrar sus componentes

ii

* McCLURE, SOMMERVILLE y FUGGETTA por [PIA951 en "Elementos y Herramientas en el desarrollo de Sistemas de Iníormación".

II

24

CAPITULO 2 CONCEPTOS SOBRE PROTS RAPID05 Y HERRAMIENTAS CASE

I/ - Entornos de cuarta generación, que soportan una clase específica de programas, como el procesamiento de datos

Entornos centrados en el’ proceso, basados en la definición formal del proceso de software y quewse componen de dos partes: la destinada a la ejecución del modelo de proceso y la utilizada para producir el modelo del proceso. Dentro de esta categoría se incluirían los generadores de entorno y las metaherramientas CASE, capaces de generar entomos de desarrollo siguiendo los procedimientos y políticas descritos por el usuario en el modelo de proceso. I)

2.2.2 Evolución de la tecnología CASE

La tecnología CASE surge a mediados de los años setenta, cuando empiezan a aparecer las primeras metodologías estructuradas y se inician las investigaciones sobre entomos de desarrollo.

I)

A mediados de los &os ochenta, el CASE se populariza y surgen las primeras herramientas de documentación y diadamación automática. Posteriormente surge el concepto de repositorio/diccionario como núcleo de las herramientas CASE, así como los generadores de programas y aplicaciones que automatizan gran parte de las últimas fases del ciclo de vida.

1 A finales de los años ochenta se produce un considerable aumento en la venta

de estos productos y empieza la etapa de asimilación de la tecnología, que fracasa debido, fundamentalmente, a tres factores:

- Limitaciones de la primera genéración de productos - Falsas expectativas sobre sus posibilidades - Implantación incorrecta

En definitiva, la tecnología CASE ha experimentado la clásica evolución que sufren aquellos paradigmas que aparecen como aquellos capaces de resolver todos los problemas del desarrollo de sistemas de información: técnicas estnicturadas, inteligencia artificial, lenguajes de cuarta generación y, en estos momentos, la orientación al objeto.

I/

ii Afortunadamente a mediados d l los años noventa, estamos entrando en una

fase de madurez, en la que empieza a surgir una “segunda generación” de herramientas (algunas de las cuales ya no aparecen bajo el término CASE) que soportan gran parte de las limitaciones existentes.

II

25

¡I CAPlTULO 2 CONCEPTOS SOBRE PROTS. RAPlDOS Y HERRAMIENTAS CASE

Esta nueva generación de herramientas CASE suele aparecer bajo la clasificación de herramientas de desarrollo de aplicaciones, como término más general al que pueden abrirse tanto herramientas sencillas como complejas; las que se dedican a ayudar a crear aplicaciones con un aspecto gráfico (constructores GUI); herramientas de programación orientada a eventos; de programación orientada a objetos; para el desarrollo en arquitecturas cliente/servidor; etc.

I/

AI final del siglo, se espera que el futuro de esta tecnología se caracterizará por una mejor integración entre herramientas (más abiertas), adecuadas a estándares, con una mayor inteligencia y adaptabilidad, incorporando nuevas formas de

código, sino también de análisis y diseño, con el afán de mejorar la calidad y productividad de los sistemas de información.

desarrollo de software que permitan 'I una reutilización efectiva no sólo a nivel de

2.2.3 Adopción de la tecnología CASE -

La tecnología CASE está experimentando considerables avances en distintas áreas, solventando muchos de los defectos que presentaba la primera generación de productos. Sin embargo, el principal1 desafio de esta tecnología sigue siendo su adopción por parte de los profesionales y las empresas.

Se calcula que en la práctica se abandona la tecnología CASE en un alto porcentaje: el 70% de las herramientas y técnicas se deja de utilizar un año después de su introducción, el 25% lo emplea sólo un grupo o una persona dentro de la empresa, mientras que el 5% restante si se emplea ampliamente, pero no al 100% de su capacidad [PIA95].

I1 Muchos consultores han abordado las causas del fracaso de la adopción de la

tecnología CASE, las cuales se pueden agrupar en tres grandes apartados:

Deficiencias en la propia tecnología '

II Una gran cantidad de empresas que empezaron a utilizar herramientas CASE

en los años ochenta, posteriormente las abandonaron debido a sus inconvenientes, entre los cuales se destacan:

* Soporte parcial del ciclo de vida, lo que permite automatizar sólo parte de las actividades de desarrollo, mientras que otras se siguen realizando de forma tradicional.

I1

I1

CAPITULO 2 ' CONCEPTO5 SOBRE PROTS. RAPIDOS Y HERRAMIENTAS CASE

I)

* Incompatibilidad entre herramientas, incluso entre distintas versiones de la misma herramienta que no siempre se encuentran sincronizuu'm en todas las plataformas hardwareísoftware sobre las que actúan.

I! * Escasa integración entre herramientas y el resto del entorno: SMBD, lenguajes de cuarta generación, generadores de informes, etc.

* Poca fiabilidad en el vendedorídistribuidor, que algunas empresas CASE son relativamente pequeñas y corren peligro de desaparecer o ser absorbidas.

* Escasa documentación generada por la herramienta.

'1 I

* Gran abundancia de herramientas, señalada muchas veces como inconveniente, ya que produce una especie de bloqueo a la hora de adquirir una herramienta.

I/

* Funcionamiento deficiente en entornos multiusuario, ya que muchas herramientas nacieron para computadoras personales y no han tenido una versión disponible para entomos Unix o redes de área local haha bastante tiempo después.

* Poca capacidad de adaptación (customización)

* Un alto costo, no sólo en la herramienta sino en la plataforma que esta conlleva.

Deficiencias en la aplicación de la tecnología a los problemas

I1

Otra causa de fracaso se debe a la utilización de herramientas CASE en problemas para los que no están preparhadas, debido a que:

* Soportan una sola metodología; por ejemplo, especializada en el desarrollo de aplicaciones de gestión y que se emplea para construir sistemas en tiempo real.

* No soportan la técnica más adecuada; por ejemplo, en el diseño de bases de datos muy grandes puede ser conveniente emplear la integración de vistas, que muchas herramientas CASE no soportan.

* Metodologías y herramientas que funcionan relativamente bien en proyectos pequeños o medianos, pueden fracasar en proyectos grandes.

* La selección se centra sólo en factores técnicos, por lo que la herramienta resulta insuficiente para los aspectos relativos a la gestión que todo desarrollo lleva consigo.

I

P

21

/j

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

i CAPITULO 2 CONCEPTOS SOBRE PROTS. RAPIDOS Y HERRAMIENTAS CASE

Las medidas más eficientes; para afrontar estos problemas pueden ser: comprender y analizar los distintos tipos de metodologías y herramientas existentes, utilizando las herramientas adecuadas' a cada problema, lo que supone un esfuerzo en formación e inversión en consultoría.

Deficiencias de la propia organizacibn 11

A pesar de las deficiencias que se mencionaron anteriormente, la mayor parte de los fracasos en la adopción de herramientas CASE son debidos a deficiencias de la propia organización. En definitiva,:la adopción de la filosofia CASE es, como la transferencia de cualquier otra tecnología, un problema más cultural que tecnológico. I\

Algunas de las causas de fracaso más importantes en esta área son:

* Actitud por parte de los directivos, [que pretenden introducir la tecnología CASE como la salvación de todos los males del desarrollo, sin contar con una base metodológica.

* Sobrevalorar el esfuerzo requerido, no sólo el económico, sino también el de formación y aceptación por parte del pkrsonal.

* Incapacidad para encontrar las metodologías y herramientas adecuadas al nivel de madurez de la organización.

1 * No medir la produccividad ni rentabilidad de la tecnología.

Estas deficiencias se pueden 'superar con una gestión adecuada de las expectativas, siendo realista y con una buena gestión.

2.2.4 Beneficios de las herramientas CASE I1

Para finalizar esta sección que nos ofrece un panorama del entorno de la tecnología CASE, a continuación se mencionan algunos de los beneficios que deberíamos esperar de las herramientas CASE [TEC]:

Se obtienen resultados de análisis y diseño más completos y precisos dentro del

I1

mismo intinerario del proyecto. li

Se produce una documentación de mayor calidad y uniformidad.

CAPITULO 2 CONCEPTOS SOBRE PROT5 RAPID05 Y HERRAMIENTAS CASE

1,

11 o La disponibilidad de las herramientas CASE está animando a los ingenieros a usar

métodos mejorados de análisis y diseño.

0 Los beneficios no justifican los costos de equipo y de software sin un buen entrenamiento en los métodos resphdados por las herramientas CASE.

II

il d

29

C' APÍTULO

PLANTEAMIENTO GENER L DEL PROBLEMA Y PRORUESTA DE SOLUCION

1

En este capítulo se describen los principales problemas que se tratan en la tesis y que motivaron a su desarrollo! Por otro lado se especifica el alcance del trabajo y algunos puntos necesarios para describir más ampliamente los problemas que se plantean.

11

30 I!

-- - ~~. -. . .

/ j CAPITULO 3 P l A N T E A M I E N T O YANALlSlS DEL PROBLEMA

3.1 EL CICLO DE VIDA TRADICIONAL DE LOS SISTEMAS II

El ciclo de vida de los sistemas en la metodología tradicional para el desarrollo de un sistema de información divide el proceso de desarrollo del sistema en varias etapas, las cuales deben ser realizadas secuencialmente con una interacción entre los usuarios finales y los especialistas en sistemas de información [LAUSS].

El ciclo de vida tradicional de los sistemas como se ilustra en la Figura 3.1, es $1 método más antiguo para la construcción de sistemas de información y todavía es usado actualmente para proyeclos de mediana y gran complejidad. Esta metodología asume que un sistema de información tiene un ciclo de vida igual al de cualquier organismo vivo, es decir, el inicio, la etapa media, y el final. El ciclo de vida para un sistema de información está formado por etapas, las cuales consisten de actividades básicas que deben ser desarrolladas antes de que la siguiente etapa pueda comenzar.

II

11

U Fig. 3.1 El enfoque tradicional del ciclo de vida

'\

( CAPITULO 3 PLANTEAMIENTO YANALISIS DEL PROBLEMA

La metodología del ciclo de vida tradicional es un enfoque muy formal para construir sistemas de información, ya que divide el proceso en diferentes etapas y desarrolla los sistemas secuencialmente, '1 es decir, etapa por etapa.

3.2 LIMITACIONES DEL CICLO DE VIDA TRADICIONAL

El ciclo de vida tradicional de sistemas es usado todavía para la constmcción de grandes sistemas que tienen la caphidad de procesar transacciones y sistemas de información administrativos donde los requerimientos son&tamente estmcturados y bien definidos. También es apropiado para sistemas técnicamente complejos como por ejemplo, control de trafico aéreo, naves espaciales, operaciones en refinerías, etc. Estas aplicaciones requieren de un análisis de requerimientos formal y riguroso. Sin embargo, la metodología del.cicld\de vida de sistemas tiene serias limitaciones y no es muy adecuada para muchos de los pequeños sistemas que predominan durante los 90's y que continuarán predominando por lo menos en los primeros años del próximo siglo [KEN91].

a) La propuesta del ciclo de vida es muy costosa y consume mucho tiempo.

Ii

Se debe invertir una cantidad tremenda de tiempo para obtener la información necesaria y preparar voluminosas especificaciones y documentos. Además esto puede tomar años antes de que un sistema esté finalmente instalado. Si el tiempo de desarrollo es tan prolongado, los requerimientos de información pueden cambiar antes de que el sistema esté en condiciones de operar.

b) La propuesta del ciclo de vida tradicional es inflexible y no propicia a cambios.

11

11 La propuesta del ciclo de vida sí permite revisiones al sistema para asegurar

que los requerimientos sean conocidos. En cualquier caso en que los requerimientos sean incorrectos o se encuentre un error, la secuencia de las actividades del ciclo de vida pueden ser repetidas. Pero se deben generar nuevos volúmenes de documentos, lo cual incrementa substancialmente $1 tiempo de desarrollo y costos. Debido al tiempo y costo de repetir las actividades de ciclo de vida, la metodología tiende a congelar las especificaciones en el proceso de desarrollo, lo cual significa que no se pueden realizar cambios. Una vez que los usuarios han aprobado los documentos de especificación, las especificaciones son congeladas. Sin embargo, los usuarios tradicionales pueden necesitar ver o usar un sistema para asegurarse que realmente se conoce 10 que eiios quieren o necesifkn.

CAPITULO 3 1 PLANTEAMIENTO Y ANALlSlS DEL PROBLEMA

3.3 OTROS MODELOS DEL CICLO DE VIDA

A continuación se presentan algunos otros modelos del ciclo de vida de desarrollo de software. 6 3.3.1 El modelo en espiral para el desarrollo de software

El modelo en espiral constituye el modelo con mayores fundamentos para el medio ambiente del desarrollo de sofhare; éste incluye otros modelos como casos especiales, y además proporciona una dirección hacia la combinación de estos modelos que se adaptan mejor a un software en una situación dada [BOE86].

Fig. 3.2 El Modelo en ekpiral del proceso de Software

Cada ciclo del espiral inicia con la identificación de:

Los objetivos de la parte del producto que está siendo elaborada (desempeño,

Los medios alternativos para la implementación de esta parte del producto (diseño

Las restricciones impuestas en la aplicación de las alternativas (costos, horarios,

11 funcionalidad, capacidad para incorporarle cambios, etc.).

A, diseño B, reuso, etc.).

interface, etc.). )I ,I

El siguiente paso es evaluar las alternativas con respecto a los objetivos y restricciones. Con frecuencia, este proceso identificará áreas de incertidumbre las cuales son fuentes significativas de riesgos del proyecto. Si esto sucede, el siguiente paso sería introducir la formulación de estrategias de costo-efectivo para resolver las fuentes de riesgo. Esto podría involucrdr la creación de prototipos, simulación, o la combinación de estas y otras técnicas pais la resolución de riesgos.

CAPITULO3 PLANTEAMIENTO YANALlSIS DEL PROBLEMA

Una característica muy importante del modelo en espiral (ver Figura 3.2), es que cada ciclo es completado por una revisión que involucra a la gente u organizaciones tienen que ver con el producto. Esta revisión cubre todo el desarrollo del producto durante el ciclo anterior, incluyendo los planes para el siguiente ciclo y los recursos requeridos para llevarlos a cabo. El principal objetivo de esta revisión es asegurarse de que todos los gnipos involucrados estén mutuamente comprometidos y convencidos de pasar a la siguiente fase.

Ventajas del modelo en espiral

I!

1

La principal ventaja del modelo en espiral es que su rango de opciones y propuestas para el manejo de riesgos le permiten adaptarse a las mejores características de los modelo de so&are existentes, mientras que evita muchas de sus dificultades. En situaciones apropiadas, el modelo en espiral llega a ser equivalente a uno de los modelos de proceso existentes. En otras situaciones, éste proporciona una guía para mezclar algunas de las propuestas existentes y que sean aplicadas a un proyecto deteminado.1 Por ejemplo para las siguientes condiciones tenemos que:

Si un proyecto tiene un bajo riesgo en ciertas áreas como una equivocación en la interface de usuario, o bien que no se conocen los requerimientos de desempeño, pero además tiene un alto riesgo en pérdidas de presupuesto, horarios y control del producto; entonces estos riesgos pueden ser manejados siguiendo el modelo en espiral como una equivalencia al modelo en cascada.

I1

Si el proyecto presenta un bzjo riesgo en áreas como pérdidas en el presupuesto y horarios, y tiene un alto riesgo en áreas como la equivocación en la interface de usuario o en requerimientos para el Soporte de las decisiones del usuario, entonces estos riesgos se manejan con el modelo en espiral en su equivalencia al modelo de desarrollo evolucionario.

I

Si se tiene la capacidad de poder desarrollar software automatizado, entonces el modelo en espiral puede tomar la toorma del modelo de creación de prototipos rápidos.

Algunas ventajas adicionales del modelo en espiral son [BOE86]:

I1 . . - Provee mecanismos para incorporar objetivos de calidad de software dentro del desarrollo del producto.

- Se enfoca a eliminar errores y alternativas poco atractivas en forma temprana.

II

34

-_ _- _ - - - - - _ _ -

CAPITULO 3 I PLANTEAMIENTO YANALISlS DEL PROBLEMA

- Puede soportar, y puede ser sopodado por medios ambientes para el desarrollo de software avanzado.

- No maneja propuestas separadas para el desarrollo y mantenimiento de software. il

3.3.2 Modelo del ciclo de vida incremental basado en prototipos

/j La diferencia esencial entre el desarrollo en cascada y el incremental es que el enfoque en cascada realiza todos los detalles de cada fase antes de iniciar la siguiente, de manera que no es posible tener un sistema trabajando, sino hasta el final del desarrollo. La propuesta incremental pospone los detalles de algunas o todas la fases para producir lo más pronto posible software que pueda estar funcionando [GRA89].

‘1

El modelo para el desarrollo incremental basado en prototipos consiste en la creación de uno o más pequeños ‘mini-sistemas’ antes de desarrollar el sistema ‘real’. El objetivo de la prototificación, y de hecho de todos los modelos incrementales, es reducir los riesgos que aparecen en el desarrollo en cascada del ciclo de vida tradicional.

11

Las áreas investigadas por / / los prototipos incluyen nuevos diseños, requerimientos que no son claros o ambiguos, alto desempeño, poca experiencia de los desarrolladores en el dominio de la aplicación y la interface humano- computadora (llamada interface hombre-máquina). A continuación se ilustran tres tipos de desarrollo de prototipos. I1

a) Prototipos de desecho

Un prototipo de desecho como ,se muestra en la Figura 3.3 nunca se propone para uso permanente; el beneficio es dl aprendizaje ganado en producir el prototipo. El prototipo puede ser desechado tan pronto como este se haya completado, o se le puede dar al usuario para que juegue con él hasta que el sistema final este completo.

! I 35

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

CAPITULO 3 PLANTEAMIENTO Y ANALISIS DEL PROBLEMA

"&'-. &$.$, .. PROTOTIPO ,(

I1

.. ' ._ j

APLICACION

il

Fig. 3.3 Prototipo de desecho

b) Prototipo Incorporado I

I1

%n prototipo incorporada como se ve en la Figura 3.4 es propuesto para que pueda llegar a formar parte del sistema final.

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

II CAPITULO 3 PLANTEAMIENTO YANALISIS DEL PROBLEMA

c) Prototipo Incremental

El prototipo Figura 3.5.

11 incremental o evolucionario es como el que se muestra en la

" .

Prototipo 3

' . I I Prototipo2

Prototipo 1 ' I

I/

Fig. 3.5 Prptotipo Incremental

1 Los desarrolladores construyen una implementación parcial del sistema del

cual se conocen los requerimientos. El prototipo es usado entonces por los usuarios para que haya una retroalimentación entre estos y los desarrolladores. Posteriormente, la mejoia se integra a ia siguiente versión de prototipo, adicionalmente, entre una versión y 8tra se van incorporando otros requerimientos. [DAVSS].

Cada prototipo sucesivo explora una nueva área.de las necesidades de los usuarios, mientras se van refinando las funciones previas. Como resultado, la solución se va acercando cada vez más a las necesidades de los usuarios. '1

3.4 DETERMINAR LAS NECESIDADES DEL CLIENTE I

Aunque las necesidades del cliente son declaradas en la fase de definición de requerimientos, muchas veces este esiá incierto de los detalles u opciones deseadas. Para que logremos involucrar al ciiente en el diseño, se recomienda mostrarle varios requerimientos o situaciones, y así poder elegir entre ellos. Por esta razón, se piensa

CAPlTUlO 3 PLANTEAMIENTO YANALlSlS DEL PROBLEMA

que los prototipos rápidos son una herramienta para especificar requerimientos, más que una técnica de diseño. En este c&o, los prototipos rápidos nos ayudan a trabajar con los clientes para determinar qué es lo que realmente quieren o necesitan.

A continuación veremos un ejemplo en donde se puede apreciar de qué forma se involucra al cliente.

Supongamos que la cOmpañía.de Milly (un usuario) contrata el servicio de otra compañía para que le desarrolle un sistema que lleve el control de sus clientes y sus necesidades. El sistema es p&a automatizar io que Milly ahora realiza manualmente:

I

1. Mantenimiento de información acetca del estado de las cuentas de cada cliente.

2. Mantenimiento de información acerca del estado de cada vehículo de los clientes: cuándo fue hecha la última reparación, cuándo fue realizada la última rutina de mantenimiento, cuándo serán necesarias las diferentes clases de rutinas de mantenimiento.

I¡

3. Generar las cuentas para cada cliente según sea necesario.

4. Generar notificaciones para los clientes cuando sea necesaria su rutina de mantenimiento.

1

Ya que Milly no tiene mucha experiencia con las computadoras, ella no está segura de qué es io que hace su nueba computadora. Para ayudarle, la compañía trabaja con ella en frente de la pantahpara generar un sistema ejemplo o subsistema llamado prototipo. Un prototipo es todo o parte de un sistema, que aunque parezca, no tiene la completa funcionalidad del sistema real. Así, un prototipo puede tener pantallas, informes, y menús de un sistema real; pero no desarrolla todas las funciones. Por ejemplo, Miily puede ver el menú principai del sistema que le permite elegir entre el subsistema de cuentas y!el subsistema de mantenimiento. Si ella elige el subsistema de cuentas, le aparecelun menú, que entre otras cosas le permite imprimir las cuentas del mes, la información actual de la cuenta no es almacenada en una base de datos, de tal forma que Milly no puede imprimir realmente sus cuentas, sin embargo sí puede ver cual será su apariencia, cómo serán formateados los informes resultantes, y en que orden serán desmolladas las funciones. Este prototipo le da la oportunidad de cambiar su mentalidad, probar varias opciones, y determinar sus preferencias.

I! I/

http://cOmpaa.de

CAPITULO 3 PLANTEAMIENTO YANALISIS DEL P R O ~ L E M A

Alternativamente, el desarrollo de prototipos puede ayudar a validar las

nuestros clientes quieren. En general un prototipo nos muestra una versión preliminar de cómo una parte o la totalidad del sistema resultante puede parecer.

especificaciones de los requerimientos, I) ya que nos da la oportunidad de afinar lo que

I1 3.5 ETAPAS PARA EL uso DE PROTOTIPOS DE SISTEMAS

El proceso para el USO de un prototipo puede darse básicamente en 4 pasos

1 PAU881.

Paso 1. Identificar los requerimientos básicos del usuario. E1 diseñador del sistema trabaja con el usuario sus ideas básicas y necesidades de información el tiempo suficiente.

I1

Paso 2. Desarrollar un prototipo inicial. El diseñador del sistema desarrolla rápidamente un prototipo de trabajo, usando tal vez alguna herramienta de apoyo como lo podrían ser algunas herramientas CASE. El prototipo puede desarrollar algunas de las funciones del sistema real, o puede consistir del sistema completo. 11

Paso 3. Usar el prototipo. El usuario es alentado a que trabaje con el prototipo para que sepa que tan bien satisface sus necesidades, además puede hacer sugerencias para mejorarlo. 'I

Paso 4. Revisar y agrandar el prototipo. El desarrollador del sistema toma nota de todos los cambios sugeridos por el usuario y en consecuencia hace un refinamiento del prototipo; después df que éste ha sido revisado, el ciclo regresa al paso 3. El paso 3 y 4 son repetidos hasta que el usuario esté satisfecho.

Cuando no se requieren más iteraciones, el prototipo aprobado llega a ser un prototipo operacional que facilita las especificaciones finales para la aplicación. Algunas veces el prototipo por sí mismo es adoptado como la versión final del sistema.

!!

39 li

- - - -- /I

PLANTEAMIENTO Y ANALlSlS DEL PROBLEMA CAPlTULO 3

3.6 PLANTEAMIENTO GENERAL DEL PROBLEMA II

Hoy en día se busca que el desarrollo de sistemas cornputarizados pueda hacerse en forma efectiva con el menor esfuerzo y tiempo posible. Para que esto se logre pueden influir muchos factoies, de los cuales, en esta tesis se tratarán solamente cuatro de ellos, y se mencionan a continuación: 11

a) Reducir la ambigüedad en las especificaciones.

b) En el desarrollo de aplicaciones que difieren de las de BDs tradicionales, como por ejemplo, BDs con aplicación a problemas científicos, se requiere tener el poderío de un lenguaje de tercera generación y toda la capacidad de un lenguaje para el manejo y definición de datos como el SQL.

c) Que el código utilizado para desarrollar prototipos pueda ser reutilizado en ia aplicación real u otras aplicaciones.

d) Que la definición de la BD pueda ser dada fácilmente como entrada a una herramienta automatizada para la generación de código.

I)

I!

En general toda la tesis se centrará en estos cuatro aspectos que representan requerimientos ideales para todo sistema de información, y a los que finalmente se proponen soluciones.

a) Reducir la ambiguedad en las especificaciones.

I1

r

I1

Existen básicamente dos preocupaciones generales que se plantean respecto al ciclo de vida tradicional de los sistemas [KEN91]. La primera se debe al extenso tiempo que se lleva entre la especificación de requerimientos y la obtención del sistema final, es decir a todo io largo del ciclo de vida del desarrollo de los sistemas. Conforme el analista invierte más tiempo, el costo del sistema desarrollado se incrementa proporcionalmente.

'I

II Las segunda preocupación respecto al ciclo de desarrollo de sistemas, es que

los requerimientos del usuario se van modificando a lo largo del tiempo. Los requerimientos del usuario evolucionan desde el momento en que se realiza el análisis de las necesidades del usuario hasta el momento en que se concluye y se entrega el sistema. Debido a tal duración del ciclo, el sistema que resulte puede no llegar a satisfacer adecuadamente las n'ecesidades de información del usuario, lo cual

I

- provoca que se eleven los costos y se invierta más tiempo del que se planteó inicialmente.

40

CAPITULO 3 PLANTEAMIENTO YANALISIS DEL PROBLEMA

Estas dos preocupaciones se encuentran relacionadas ya que las dos se basan en el tiempo que se requiere para concluir la fase de definición de requerimientos y el problema que implica alejarse de las necesidades del usuario, durante el resto de las etapas del desarrollo. 1:

Por otro lado, sabemos que ia historia del Software ha mostrado que la gran mayoria de los errores detectados en la etapa de pruebas se originaron en el momento de definir requerimiento; y especificaciones (errores conceptuales). También se ha comprobado que este tipo de errores cuestan hasta 100 veces más que los errores de implementación, lo cual muestra la importancia que tienen las primeras etapas del ciclo de vida de desarrollo del Software MIR871.

La Tabla 3.1 muestra las principales Rientes de error en el ciclo de vida.

T:

! 0% 10% 20% 30% 40%

I! 3.1 Fuentes de errores y su respectivo porcentaje de contribución

Los errores que se crean durante el proceso de formulación de requerimientos ai escribir las especificaciones, al diseñar el software y al codificar los programas, pueden eliminarse mediante la interacción con el usuario, haciendo inspecciones, revisiones del diseño, pruebas modulares y rastreo de código.

Y

41

cAPIruLo 3 PLANTíAMIENTO YANALISIS DEL PROBLEMA'

I1 Solución propuesta :

Con la finalidad de poder resolver estos inconvenientes, en esta tesis se propone un nuevo enfoque a la metodología de desarrollo de sistemas en espiral, que consiste en unir la idea del desarrollo de prototipos incrementales en cada fase del espiral e incorporarlos al final de éste (Ver fig. 3.6), es decir, que los prototipos que se generen en cada fase se vayan refinando e incrementando hasta lograr un prototipo que constituya el resultado de la última fase del espiral y que éste pueda ser incorporado al sistema final; reduciendo de esta forma el periodo de tiempo que transcurre entre la indagación de los requerimientos de información y la entrega de un sistema funcional.

Fig. 3.6 Nuevo enfoque del ciclo de vida en espiral con prototipos incrementales e incorporados

Por otra parte, con el objetivo de mostrar dentro del contexto del desarrollo de sistemas de información cómo puede ser ubicada la herramienta para el desarrollo de prototipos, se desarrolló el modelo de la Figura 3.7, en donde básicamente la propuesta de solución que se plantea está dada precisamente aqui. Puede verse claramente cómo a partir de la especificación de los requerimientos, pasando por el

42

il

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

1-

PLANTEAMliNO YANALiSiS DEL PROBLEMA ‘I CAPITULO 3

r!

modelo conceptual y de ahí al diseño lógico, podemos obtener el esquema de la BD, la cual se recibe como entrada el GPR para obtener de inmediato un prototipo funcional. ¡I

La principal característica de este prototipo, es que está orientado a que pueda ser fácilmente modificable y legible en su código fuente, lo cual facilita en gran medida que pueda ser usado el enfoque del “prototipo incremental”, que como puede verse en la Figura 3.7, pueden existir varias iteraciones entre el prototipo y el esquema de la BD o bien desde la especificación de requerimientos si se desea.

i‘

. I!

I¡

En forma general se explican las principales fases del modelo propuesto en la I) Figura 3.7:

La fase de requerimientos coniiste en describir todas las partes del sistema, incluyendo los límites. Es necesario saber qué objetos o entidades son incluidas, cómo son (definir sus atributos), cómo se relacionan unos con otros. Es decir describir al sistema en términos de estos elementos.

I1

La fase del modelo conceptual tiene como objetivo obtener una buena representación de los recursos de información de la empresa, con independencia de los usuarios o aplicaciones en particular, y sin tener en cuenta consideraciones sobre eficiencia de la computadora. Mientras que la fase del diseño lógico tiene como objetivo transformar el esquema conceptual obtenido en la fase anterior, adaptándolo al modelo de datos que soporta el SMBD que se va a utilizar Cjerárquico, Codasyl, relacional, orientado a objetos, etc.).

La fase del diseño físico tiene como objetivo instrumentar el esquema lógico de la forma más eficiente posible, teniendo en cuenta no sólo las características propias del SMBD, sino también del Sistema operativo (SO) y del soporte fisico (hardware) empleados. De aquí en adelante se continúa con el ciclo normal de desarrollo. ¡I

Es importante señalar que estas I tres fases estarían comprendidas en todo lo que sería el análisis y diseño del sistema dentro del ciclo de vida del desarrollo de un sistema de información.

Por otro lado, partiendo del esquema de la BD resultante de la fase del disefio lógico, es posible incorporar el GPR, el cual recibe como entrada precisamente este esquema, pudiendo obtener de inmediato un prototipo ejecutable, el cual puede sufiir refmaciones sucdivas hasta lograr un prototipo final, que posteriormente pudiera ser incorporado al sistema real.

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

CAPITULO 3 PLANTEAMIENTO Y ANALISIS DEL PROBLEMA

.................................................. Análisis Y Diser% del si~tema

....

- -

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

Fig. 3.7 Fases del Desarrollo de BDs con enfoque a los modelo de creación de prototipos incremental e incorporado

b) En el desarrollo de aplicaciones que difieren de las de BDs tradicionales, como por ejemplo, BDs con aplicación a ,problemas científicos, se requiere tener el poderío de un lenguaje de tercera generación y toda la capacidad de un lenguaje para el manejo y definición de datos como el SQL.

I/

)I

En algunas aplicaciones es necesario llevar a cabo cálculos muy sofisticados sobre la BD, para lo cual se busca que dicha aplicación se desarrolle con el software adecuado para facilitar estas operaciones.

La gran mayoiia de las herramientas CASE comerciales generan código en 4GLs o distintas adaptaciones de SQL' por separado y no en lenguajes de tercera generación que sean usados como lenguajes anfitriones con código de SQL embebido.

Solución propuesta: 1,

La herramienta que aquí se propone, presenta su código generado en el lenguaje Turbo Pascal para Windows (lenguaje anfitrión), el cual es un lenguaje de tercera generación que facilita las operaciones de cálculos complejos. Además se I/

CAPlTULO 3 PlANTfAMlENJO YANAllSlS DEL PROEL€MA

hace uso de SQL a través de instrucciones embebidas en el lenguaje anfitrión, que para fines de prueba, son interpretadas por el SMBDD experimental llamado SiMBaD para el manejo de la base de datos.

c) Que el código utilizado para desarrollar prototipos pueda ser reutilizado en la aplicación real u otras aplicaciones.

Muchas de las herramientas CASE generan código encriptado o bien código fuente que puede ser accesado, sin embargo es prácticamente ilegible, ya que éste no está orientado a dar al desarrollador la oportunidad de que pueda modificarlo.

Solución propuesta:

El GPR es una herramienta CASE capaz de generar código fuente fácilmente accesible y legible, ya que está comentado y además los programas prototipo resultantes están impiementados bajo el paradigma de programación orientada a objetos, lo cual nos da algunas ventajas como [TEC]:

- Si se desea llevar a cabo un cambio en típicamente en uno o pocos objetos del mundo real.

- Los componentes de los modelos orientados a objetos son más fáciles de volver a usar que los componentes de los modelos funcionales.

los requisitos, éstos se localizan

- Los resultados del desarrollo orientado a objeto se pueden convertir fácilmente a otros lenguajes de prcgramación orientados a objetos.

Esto hace posible que el desarrollador pueda reutilizar parte o la totalidad del código generado por el GPR para que éste pueda ser incorporado en el sistema final. Como se muestra en la figura 3.8, es posible reutilizar algunos módulos e incluso sería posible reusar clases de objetos y métodos en otras 'aplicaciones. Por poner un ejemplo, podría reutilizarse muy fácilmente el prototipo generado para las altas, bajas, cambios y consultas de una tabla, el cual estaría constituido por los modulos Ml,M2,Ml.l,M1.2yM2.1(Verfig.3.8).

45

. CAPITULO 3 PLANTEAMIENTO Y ANALISIS DEL PROBLEMA

, ........................................,

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

, ' Componentes

' ............................... ."

Fig. 3.8 Fases del Desarrollo de BDs con enfoque a los modelos de creación de prototipos incremental e incorporado

d ) Que la de3nición de la BD pueda ser dada fácilmente como entrada a una herramienta automatizada para la generación de código.

En general, las herramientas CASE ofkecen un buen soporte gráfico para esquemas conceptuales de tamaño medio que facilita en gran medida la labor del diseñador; sin embargo, es difícil imaginar el mantenimiento de una gran cantidad de entidades en un entorno gráfico. Por lo que para bases de'datos muy grandes, es más conveniente ir a soluciones más cooperativas, en las que se utilizan, por un lado, estaciones de trabajo o computadoras personales para soportar la visualización de los esquemas y realizar ciertos procesos, y por otro, una computadora de más capacidad (incluso mainfiame) para otros tipos de procesos [PIA95].

A pesar de esto, podemos decir que muchas de las herramientas CASE de hoy son sólo "procesadores de texto gráficos" [TEC], lo cual significa que tal vez presentan mucho poderío para la creación de diagramas gráficos, lo que trae como consecuencia que muchas de ellas requieran de considerables recursos de hardware para poder soportar el desplegado gráfico, como se mencionó anteriormente.

46

CAPlTUlO 3 PLANTEAMIENTO Y ANALISIS DEL PROBLEMA

Solución propuesta:

La herramienta que aquí se propone presenta una entrada relativamente sencilla de construir, ya que consiste solamente de un archivo de texto, el cual puede ser editado en cualquier procesador de textos, no obligándonos a hacerlo desde el ambiente interno de la propia herramienta.

Esta forma de proporcionar la definición de la BD nos permite llevar a cabo modificaciones a la misma de la forma más sencilla posible, evitándonos desplegados gráficos que para ciertas circunstancias nos resultarían menos convenientes.

Por otra parte, si como en el caso que se mencionó anteriormente, se tuvieran que manejar una gran cantidad de tablas, los recursos de hardware no sufrirían de considerables incrementos, ya que el proceso del análisis del texto de entrada no se vería afectado en gran medida..

3.7 ALCANCE DE LA TESIS

El alcance de la tesis comprende el desarrollo de un generador de Ijrototipos rápidos (GPR) con las siguientes características:

1. Recibe como entrada el esquema de la base de datos expresada con estatutos del lenguaje SQL y obtiene como salida instrucciones en lenguaje Turbo Pascal para Windows (versión 1.5) intercaladas con instrucciones del lenguaje SQL de un SMBDDs Experimental denominado SiMBaDD.

2. Es una herramienta de propósito general, con la cual se puede generar para cualquier base de datos definida en SQL los programas prototipo para realizar altas, bajas, cambios y consultas de cada una de las tablas de la BD, manteniendo la regla de integridad referencial.

3. El lenguaje SQL que se tomó como referencia en este trabajo está basado en el Estándar Internacional ISO/IEC 1989 [INT89].

4. La interfaz con el usuario proporcionada por los programas prototipo está basada en el manejo de ventanas que proporciona WINDOWS y es de un mismo tipo, sin embargo es susceptible de ser modificada para adecuarla a una aplicación específica.

47

CAPITULO 3 PLANTEAMIENTO YANALISIS DEL PROBLEMA c

5. El código generado está autodocumentado y orientado a una fácil comprensión por parte de los desarrolladores de aplicaciones; esto es con la finalidad de que puedan reutilizar el software del prototipo en el desarrollo del sistema final. ,

6. Permite desarrollar el código de rutinas de informes que puedan ser expresadas en una cláusula SELECT del lenguaje SQL.

7 . Los informes que pueden generarse sobre la BD pueden involucrar solamente una tabla.

8. Los tipos de datos que se consideraron para los atributos de las tablas son: , CHAR - Tipo Cadena SMALLINT - Entero pequeño I

INTEGER - Entero I

SMALLFLOAT - Flotante pequeño FLOAT - Flotante I

NUMERIC - Numérico I

DATE - Fecha

9. No realiza optimización de código. I

10. No realiza optimización de consultas.

1 1. No incluye el manejo de transacciones.

12. La implementación de su código es totalmente Orientado a Objetos.

13. El código de los prototipos que genera es Orientado a Objetos.

14. En esta tesis se prueba la correcta generación del código de los prototipos y queda fuera de su alcance el cuantificar el ahorro de tiempo y costos del desarrollo de aplicaciones empleando esta herramienta. Así también, aunque el código generado se ha diseñado para que sea fácil de modificar y que sea legible, la evaluación de la legibilidad de éste para su reutilización como un componente de software del sistema real, de igual manera no se considera dentro del alcance de este trabajo.

48

C APÍTULO ' \ 4 ARQUITECTURA Y

CONSIDERACIONES DE DISEÑO DEL GENERADOR AUTOMATIC0 DE CODIG,O

Este capítulo representa la parte central de la tesis, ya que es aquí donde se especifica todo el diseño del generador de código.

Se pretende dar una vista clara pero sin llegar a detalles muy particulares de cada uno de los módulos que conforman el sistema, así como algunas otras consideraciones que tienen que ser descritas para lograr un mejor entendimiento, para lo cual se presentarb esquemas, definiciones de estructuras utilizadas, archivos, etc.

I

49

CAPITULO 4 ARQUITECTURA Y CONSID DE DISENO DEL GEN AUT. DE COb/CO

4.1 ARQUITECTURA CONCEPTUAL DEL GENERADOR AUTOMATIC0 DE CODXGO (GAC)

Básicamente la arquitectura consta de cinco módulos (ver Figura 4.1) que llevan a cabo tareas muy específicas, y dentro de los cuales se realizan cada uno de los pasos para lograr un sistema de información con las características definidas en cada una de las especificaciones que el generador de código recibe como entrada,

A) Analizador de especificaciones B) Personalizador C) Generador de código D) Precompilador E) Generador de archivos ejecutables

. GENER~DORA~UTOMATICO,DE.CODIG.O < < . . . . ~I . . . . . .

c . I

I I

Fig- 4.1 Esquema conceptual del generador de código

Es importante mencionar que el proceso de ejecución de los módulos FS estrictamente secuencial, salvo algunas excepciones que se mencionarán más adelante.

4.2 MODULO ANALIZADOR DE ESPECIFICACIONES I

La realización del análisis de las especificaciones es una de los puntos importantes de este trabajo. Ya que es aquí donde se extrae y almacena toda la información que el módulo generador necesita para poder llevar a cabo su tarea.

Específicamente este módulo está dividido en tres submódulos cuya tarea es realizar diferentes verificaciones y validaciones al archivo de entrada o de especificación (Ver Figura 4.2).

50

CAPITULO 4 ARQUITECTURA Y CONSID. DE DlSENO DEL GEN. AUT. DE CODlCO

Fig. 4.2 Esquema para la fase de análisis

En general, se cuenta con dos tipos de especificaciones:

a) Especificación para la definición de la BD b) Especificación para las consultas de informes .

4.2.1 Especificación para la definición de la BD

El primer tipo de especificación que se maneja es la que contiene el esqukma de la BD en SQL, en donde se definen las tablas que se desean crear por medio del estatuto “CREATE TABLE”, íos atributos de cada tabla con sus tipos, los valores por omisión de los atributos, permiso de valores nulos, sus llaves primarias, así como las llaves forheas para el manejo de la integridad referencial.

Un ejemplo de un archivo de entrada con la especificación del esquema de la BD podría ser el que se muestra en la Figura 4.3, en donde se define una parte db la especificación del esquema de la BD de un sistema de control escolar, en donde se puede ver que desde la tabla “ALUMNOS” a través del estatuto Foreign Key se tiene una relación con la tabla de “CUBICULO”:

51

--- - - - . .-. .- -. ~-.+. ~

I CAPITULO 4 ARQUITECTURA Y CONSID. DE Dl5EfiO DEL GEN. AUT. DE CODlCO

Í

I

I

I

Fig. 4.3 Ejemplo de una especificación para’la definición de una BD ~

4.2.2 Especificación para las consultas de informes

El segundo tipo de especificación que se procesa es el utilizado para las consultas que desean hacer en los informes, cabe señalar que esta opción está limitada a 20 solicitudes como máximo, y pueden hacerse en el orden que se desee. Otra de las restricciones que se impusieron fue que las consultas solo pueden realizarse sobre una sola tabla.

Un ejemplo de un archivo de entrada para especificación de consultas a la BD podría ser el que se muestra en la Figura 4.4, en donde se especifican cuatro consultas a la BD para un sistema de control escolar por medio del estatuto “SELECT”. La primera consulta consiste en desplegar la Clave y el Nombre de todos los alumnos que tengan promedio de 100, la segunda en desplegar Clave y Dirección de todos los alumnos mayores de 23 años; la tercera en desplegar Cldve y Descripción de todos los cubículos para alumnos y la cuarta en desplegar Clave y Cubículo del alumno con Clave ‘0001’.

I

52

CAPITULO 4 ARQUITECTURA YCONSID. DE DISEÑO DEL GEN. AUT. DE CODICO

Fig. 4.4 Ejemplo de una especificación para las consultas de infbrnes '

4.2.3 Análisis de esquemas de BDs en SQL I

El análisis consiste mas que nada en verificar que las especificaciones fueron dadas correctamente siguiendo las reglas del Estándar Internacional de SQL ISO/IEC [PIT891 para la creación de tablas.

Cuando se está ante la posibilidad de iniciar con el analisis de un archivo de definición del esquema de una BD, podemos contar con una ayuda muy significativa. Esta consiste en que se le da al usuario la capacidad de poder editar en ese momento el archivo que se desea procesar, esto es particularmente útil sobre todo cuando surge la necesidad de realizar cambios al archivo de entrada, lo cual es muy frecuente, ya que si surge un error durante la fase de análisis, éste puede ser corregido de inmediato sin tener que recurrir a un editor de texto. Todo esto se logra creando una ventana de edición adicional para que el usuario revise, modifique o renombre el archivo deseado.

4.2.3.1 Gramática para la definición del esquema de la BD I I

Como se mencionó anteriormente, el esquema de la BD es definida en SQL siguiendo las reglas del Estándar Internacional de SQL ISOlIEC 1989 [INT89], con excepción del estatuto CHECK para especificar una condición para una tabla. La gramática para la definición de tablas, y en la cual se basa todo el análisis, se encuentra en el Anexo A.

53 I

CAPITULO 4 ARQUITECTURA Y CONSID. DE D~SEÑO DEL GEN. AUT. DE CODlCO

4.2.3.2 Análisis léxico

El primer paso es llevar a cabo el análisis léxico de las definiciones que se encuentran en el archivo de entrada, éste consiste en agrupar los caracteres leídos del archivo de entrada en “tokens”, en donde cada “token” representa una secuencia lógicamente cohesiva de caracteres, como podrían ser las palabras reservadas, un identificador o un caracter de puntuación.

Las palabras reservadas en el GAC para la definicibn de las BDs son las siguientes:

CREATE, TABLE, CHARACTER, CHAR, SMALLMT, INTEGER, INT, SMALLFLOAT, FLOAT, NUMERIC, DATE, PRIMARY, KEY, FOREIGN, NOT, NULL, REFERENCES, DEFAULT, UNIQUE.

y se tienen como caracteres delimitadores “,” y “;” ; además de “(” y . “y’,

4.2.3.3 Análisis sintáctico

El análisis sintáctico se encarga de verificar que la secuencia de los “tokens” sean legales de acuerdo a las reglas sintácticas especificadas por la gramática independiente del contexto del lenguaje SQL.

Para todo el desarrollo del análisis sintáctico se construyó un autómata de estados finitos, el cual está basado en la gramática de SQE para la definición de tablas base.

En el desarrollo del generador, en toda la fase de análisis sintáctico se encuentran intercaladas todas las acciones semánticas que se realizaron y que serán comentadas más adelante. Sin embargo, lo que sí es importante señalar en este momento, son otros tipos de acciones que se fueron desarrollando en esta etapa y que son de vital importancia para poder realizar la generación de código.

Para que un proceso de generación de código pudiera ser posible, fue necesaria la creación de un diccionario de datos o por llamarle de alguna manera “diccionario de formas”, en el cual se almacena toda la información que se extrae durante la fase de análisis, y que es absolutamente necesaria para el módulo que se encarga de la generación de código.

A continuación se muestra el diccionario de formas, como la estructura de un registro en lenguaje Pascal:

54

-<. - -- -- - -

CAPITULO 4 ARQUITECTURA Y CONSID. DE Df5ENO DEL GEN. AUT. DE CODlCO

PTregTabla = "TRegTabla;

TRegTabla =record NombreT : array [0..12] ofchar; ( Nombre de la tabla NombreT-en-Sistema: araY[O.. 151 of char; ( Nombre de la tabla en e] sistema ) TitWin : array[0..100] of char; ( Título de la Ventana principal TitForma : array[O..l2] ofchar; ( Titulo de la forma EncabForma : array[O..MAXENCABEZADO] of char; ( Encabezado de la forma ) SizeRenglonT : Integer; (Bytes que se reservan para almacenar cada

rengl6n de la Tabla TotalColsT : O..MaxCols; Número de columnas en la tabla TotalIndsT : O..MaxIndices; ( No. de Indices definidos sobre la tabla PrimKeyT : Boolean; ( Si tiene llaves primarias ColsT : TRegColumnas; Estructura para las columnas ) ColsPrimKeyT : TRegColsPrimKey;

) Duplicados : O..l; Si la llave acepta duplicados ) Borradosen-Cascada : Boolean; Si se desean hacer borrados en cascada o no son

permitidos, esto con la finalidad de mantener la integeridad de la BD NumReportes : Byte; ( No. de reportes que se tiene registrados para la tabla ) Reportes : Array [O..MAXREPORTES] Of TRegReportes;

Quereferencia : array [ 1 ..MAXTAB-QUE-REFERENCIA] of array[O..l2] of char;

Que-la-Referencian : array [I ..MAXTAB-QUE-LA-REFERENCIAN] of array[O..l2] of char;

(Arreglo que contiene los nos. de la columnas que participan en la llave primaria

( Estructura en donde se almacena información de los reportes

Tablas que referencia )

Tablas que la referenclan ) End;

TRegColumnas = ARRAY [I ..MaxCols] of TColumna;

( Registro para cada una de las columnas que componen a une tabla de la BDD 1

TColumna = record NombreC, ( Nombre del campo en la forma ) NombreCR: array[O..lS] of char; TipoC : Byte; Tipo del campo I: Integer, 2 char ... Tam : Integer; ( Tamaiio de las cadenas

Limite Inferior en subrangos ) Limite superior en subrangos )

LI, LS : Real; DefaultC : Boolean; ( Tiene valor defult ? )

Valor Default ) ValDefaultC : Array[O..Maxdefault] of char; DeflsNull : Boolean; True = El valor default es NULL, False de otra manera ) EnterosC : Byte; Total de digitos que forman en número ) DecimalesC : Byte; Decimales despues del punto NiiloC Es un campo que acepta nulos ? )

Nombre del Campo en la tabla

NomTabBase : array [0..12] of char; Nombre de la tabla a la cual referencia para esta columna )

ColBase : array [ 1..20] of array[O..l8! of char; Nombre de la columna de la tabla a la cual referencia y con la que se iguala )

END;

55

CAPITULO 4 ARQUITECTURA YCONSID. DE DlSEfiO DEL GEN. AUT. DE C o D l ~ o

A continuach se presenta el algoritmo para el análisis sintáctico, el cual es la representación del autómata de estados finitos para la definición de tablas. A este algoritmo se llega después de haber reconocido la secuencia “CREATE TABLE”.

1 Q=q2; 2 repite 3 Obtener-Token 4 Con W 5 Caso Q de 6 7 8 9 DE OTRO MODO Q=q3 IO DE OTRO MODO ERROR I1 q3 : SI “(“ ENTONCES Q=q4 12 DE OTRO MODO ERROR 13 q4 : SI Identificador ENTONCES 14 15 DE OTRO MODO 16 17 DE OTRO MODO 18 Incrementa(Num. de col.) 19 NornbreC=Token 20 NombreCR=Token

22 DE OTRO MODO 23 Si “UNIQUE” ENTONCES Q=q14 24 DE OTRO MODO 25 SI “PRIMARY” ENTONCES Q=q22 26 DE OTRO MODO 27 SI “FOREIGN ENTONCES 28 FOREIGN=TRUE 29 Q=q23 30 . DEOTROMODOERROR 3 1 q5 : Obten el tipo(TipoC,EnterosC,DechalesC) 32 33 34 35 SI “)” ENTONCES Q=qlO 36 37 38 39 DE OTRO MODO ERROR 40 DE OTRO MODO Q=q6 41 42 43 44 45 DE OTRO MODO ERROR 46 47 48

q2 : SI Identificador ENTONCES NombreT- Token TitForma = Token SI la tabla ya ha sido definida anteriormente ENTONCES ERROR

\

SI el num. de col. =Máximo de Cols. ENTONCES ERROR

SI la columna ya ha sido definida anteriormente ENTONCES ERROR

21 Q=s5

Asigna el tamaño a la columna Asigna Límites inferior y superior SI TipoC in [1,4,7] ENTONCES

DE OTRO MODO SI “NOT’ ENTONCES Q=q8 DE OTRO MODO SI “DEFAULT‘ ENTONCES Q=q7 DE OTRO MODO SI “,” ENTONCES,Q=q4

q6 : SI “)” ENTONCES Q=qlO DE OTRO MODO SI “NOT’ ENTONCES Q=q8 DE OTRO MODO SI “DEFAULT’ ENTONCES Q=q7 DE OTRO MODO SI “,” ENTONCES Q=q4

q7 : Verifica el valor default

q8 : SI “NULL” ENTONCES SI no hubo error ENTONCES Q=Q12

56

49 ColsTiNum. de Col.].NuloC=False 50 Q=qi 1 5 I DE OTRO MODO ERROR 52 q10: SI ‘‘Y ENTONCES Q=@O 53 54 DE OTRO MODO ERROR 55 56 57 58 59 60 FOREIGN=TRUE 61 Q=q23 62 DE OTRO MODO ERROR 63 q12: SI “>I> ENTONCES Q=q4 64 . DE OTRO MODO SI “)” ENTONCES Q=q4. 65 DE OTRO MODO ERROR 66 q14: SI “(“ ENTONCES Q=q15 67 DE OTR9 MODO ERROR 68 q15: SI IDENTIFICADOR ENTONCES 69 Columna=TOKEN 70 71 Q=q 16 72 DE OTRO MODO ERROR 73 DE OTRO MODO ERROR 74 q16: Si “)” ENTONCES Q=qlZ 75 76 DE OTRO MODO ERROR 77 78 DE OTRO MODO ERROR 79 q19: SI “;>> ENTONCES Q+O 80 DE OTRO MODO ERROR 81 82 . DE OTRO MODO Si I‘>>> ENTONCES Q=q4 83 84 DE OTRO MODO ERROR 85 q22: SI “KEY” ENTONCES Q=q14 86 DE OTRO MODO ERROR 87 q23: SI “KEY” ENTONCES Q=q24 88 DE OTRO MODO ERROR 89 q24: Si “(“ ENTONCES Q+5 90 DE OTRO MODO ERROR 91 q25: SI IDENTiFiCADOR ENTONCES 92 93 94 Q=q26 95 DE OTRO MODO ERROR 96 DE OTRO MODO ERROR 97 98 99 DE OTRO MODO ERROR IO0 1 O I 102 q28: SI IDENTIFICADOR ENTONCES

DE OTRO MODO SI “IN” ENTONCES Q=ql8

q l l : s1 “UNIQUE” ENTONCES Q=q12 DE OTRO MODO SI “PRIMARY” ENTONCES Q=qZ 1 DE OTRO MODO SI “>>> ENTONCES Q=q4 DE OTRO MODO SI “)” ENTONCES Q=qlO DE OTRO MODO SI “FOREIGN ENTONCES

SI es correcta la Columna ENTONCES

DE OTRO MODO SI “>>> ENTONCES Q=q15

q18: SI CADENA ENTONCES Q=Ql9

q21: SI “KEY” ENTONCES Q=q12

DE OTRO MODO SI I‘)” ENTONCES Q=qIO

SI La columna no esta repetida en el Foreign ENTONCES inserta columna en la lista

q26: SI “><> ENTONCES Q=q25 DE OTRO MODO SI “)” ENTONCES Q=q27

q27: SI “REFERENCES” ENTONCES Q+8 DE OTRO MODO ERROR

CAPITULO 4 ARQUITECTURA Y CONSID. DE DISENO DEL GEN. AUT. DE CODICO

103 104 Inserta tabla en lista

SI la tabla no existe en la lista de tablas referenciadas ENTONCES

I o5 Q=q29 106 DE OTRO MODO ERROR 107 DE OTRO MODO 108 q29: SI 'I(" ENTONCES ~ = q 3 0 109 I10

DE OTRO MODO SI ">>> ENTONCES Inserta en la lista los mismos nombres

1 1 1 Q=q4

113 DE OTRO MODO ERROR 114 q30: SI IDENTIFICADOR ENTONCES 115 I I6 1 I7 Q=q3 1 118 DE OTRO MODO ERROR 119 DE OTRO MODO ERROR 120 q3 1: SI "," ENTONCES Q=q30 121 I22 DE OTRO MODO ERROR 123 124 125 DE OTRO MODO ERROR 126 FIN 127 HASTA Q=20 o ha ocurrido un error 128 Verifica que las columnas del referencing existan en la tabla que referencia 129 SI no hubo error ENTONCES 130 Verifica que la cantidad de columnas del referencing sea la misma que la del referenced 13 1 SI no hubo error ENTONCES 132

112 DE OTRO MODO SI "(" ENTONCES Q=qO

SI la Columna no esta repetida en el references ENTONCES Inserta columna en la lista

DE OTRO MODO SI ")" ENTONCES Q=q32

q32: SI "," ENTONCES Q=q4 DE OTRO MODO SI "(" ENTONCES Q=qlO

Construye la estructura de tablas y columnas

Durante todo el análisis sintáctico se van llenando estructuras que son empleadas posteriormente para llevar a cabo las acciones semánticas, como se puede apreciar en las líneas 128, 130 y 132 del algoritmo. Sin embargo es importarite mencionar que conforme se realiza el análisis, se va llenando un contenedor del tipo Ptregtabla el cual representa el diccionario de formas en memoria.

Para cada tabla que participa en la BD, se crea un archivo que contiene la información que se fue recolectando durante toda la fase del análisis.

4.2.3.4 Acciones sernántkas

Como se mencionó en el punto anterior, las acciones semánticas se encuentran inmersas en el algoritmo que se implementó para el análisis sintáctico. A continuación se mencionan las principales acciones semánticas que se definieron:

1. El nombre de cada tabla debe ser diferente de cualquier otro nombre de tabla que se haya definido dentro de la base de datos. (Línea 8)

58

CAPITULO 4 ARQUITECTURA Y CONSID. DE DISEÑO DEL GEN. AUT. DE CODlCO

2. La definición de cada tabla debe contener al menos una columna. (Línea 13)

3. Los nombres de las columnas de cada tabla deben ser diferentes entre sí. (Línea 16)

4. Si para una columna no se especifican un NOT NULL ni una cláusula para su valor por defecto, entonces la cláusula DEFAULT NULL es implícita. (Considerado en el estado 45)

5. Cada columna de la lista de columnas de la cláusula UNIQUE debe ser una columna de la tabla que se analiza, y la misma columna no debe aparecer más de una vez. (Línea 70)

6. (Considerado en el estado q l 1)

7. En cada definición de tabla se debe especificar a lo más una cláusula PRIMARY

Cada columna de la cláusula UNIQUE debe especificar un NOT NULL

KEY. (Considerado en q l l )

Para los casos en que se haya definido una cláusula FOREIGN KEY:

8 . Las columnas de la tabla que es referenciada y que aparecen en ésta cláusula deben ser llaves primarias de esa tabla. (Línea 128)

9. Cada columna que participa después de la cláusula FOREIGN KEY debe ser una columna de la tabla que referencia, y no deben aparecer más de una vez. (Línea 92)

10. Cada columna que participa después de la cláusula REFERENCES debe ser una columna de la tabla que es referenciada, y no deben aparecer más de una vez. (Línea 115)

11. El número de columnas que aparecen después de la cláusula FOREIGN KEY deben ser el mismo para las columnas que aparecen después de la cláusula REFERENCES. (Línea 130)

12. La i-ésima columna identificada después de la cláusula FOREIGN KEY corresponde a la i-ésima columna identificada después de la cláusula REFERENCES. (Considerado en la función de la línea 130)

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

CAPITULO 4 ARQUITECTURA Y CONSID. DE DlSEt?O DEL GEN. AUT. DE CODICO

13. El tipo de dato de cada columna después de la cláusula FOREIGN KEY debe ser el mismo que el de su columna correspondiente y que aparece después de la cláusula REFERENCES. (Considerado en la función de la línea 130)

14. Si no existen columnas definidas después de la cláusula REFERENCES, se asume que éstas presentan el mismo nombre que las columnas que aparecen después de la cláusula FOREIGN KEY. (Línea 110)

15. No debe haber referencias cíclicas entre las tablas pertenecientes a la base de datos. (Verificación realizada fuera de este algoritmo)

4.2.4 Análisis para la especificación de consultas de informes

De la misma manera que para el análisis del archivo que contiene la definición de la base de datos, el archivo de consultas para informes, puede ser editado por medio de una ventana de edición, lo cual puede llegar a representar grandes ventajas, ya que resulta muy sencillo modificar las consultas que se desean definir para los informes.

Un punto importante que es necesario resaltar, es que las consultas que el analizador puede procesar, son aquellas que se realizan sobre una sola tabla, es decir, que solo es posible llevar a cabo una cláusula SELECT en donde aparezca a lo más una tabla.

4.2.4.1 Gramática para la definición de consultas a la BD

Debido a que las consultas que se pueden realizar son sobre una sola tabla, se modificó la gramática de SQL para poder llevar a cabo un correcto análisis de las especificaciones para consultas de informes, quedando de la siguiente manera:

<query specification> :: = SELECT [ ALL I DISTINCT ] <select lisp <table expression>

<select l i s p :: = <column name> [ ,<column n a m e ...I

<table expression> :: = <from clause> [<where ciause>]

<from clause> :: = FROM <table name>

60

CAPITULO 4 ARQUiTECTURA Y CONSID. DE D ~ S E Ñ S DEL GEN. AUT. DE CODICO

<where clause> :: = WHERE <search condition>

<search condition, :: = <boolean term> I <search condition> OR <boolean term>

<boolean term> :: = <boolean factor> 1 <boolean term> AND <boolean factor>

<boolean factor> :: = [NOT] <boolean primary>

<boolean primary> :: = <predicate> I (<search condition>)

Entre las diferencias con la gramática del estándar se puede mencionar que no se consideraron:

- El estatuto GROUP BY - El estatuto HAVING - Estatutos SELECTS anidados

4.2.4.2 Análisis léxico

De la misma manera que el proceso de análisis que se realizó para la especificación de la base de datos, aquí se pueden obtener cualquiera de los siguientes tokens válidos:

SELECT, FROM, WHERE, *, NOT, AND, DISTINCT, BETWEEN, IN, LIKE, NüLLycaracteres como , , ( , ) , , .

4.2.4.3 Análisis sintáctico

,

a,,, >% 'L i, 3, 3% $ 3

El análisis sintáctico de la especificación de consultas para inform& se realiza utilizando el diccionario de formas que se ha construido del análisis previo de la especificación de la base de datos. Lo que significa que no es posible realizar el análisis de consultas a una base de datos que no se ha analizado previamente, ya que es precisamente aquí cuando se crea el diccionario de formas que es en donde se encuentran registradas todas las tablas y atributos que forman parte de la base de datos.

61

CAPITULO 4 ARQUITECTURA Y CONSID. DE DISENO DEL GEN. AUT. D€ CODJCO

Durante el análisis sintáctico de la especificación de consultas se van registrando los reportes en una parte del diccionario de formas y cuya estructura aparece a continuación:

Reportes : Array [O..MAXREPORTES] Of TRegReportes;

TRegReportes = Record Nombre,Cornpania,Siglas,pieqag : Array[O..MAXREP - SEL] of char; Columnas : TRegColumnasReportes; Condicion : Array[O..iOO]of char;

End;

TRegColurnnasReportes = Array [ 1 ..MAXCOLS] of Byte;

por cada uno de las consultas que se detecta se registra un nuevo informe, en donde los campos nombre y columna son inicializados por defecto con la condición de búsqueda, mientras que la compañía, siglas y pie de página son inicializadas a nulo. En el campo columnas se inicializan con “1” las posiciones (según la definición) de las columnas que participan en la consulta.

A continuación se muestra un algoritmo del análisis para la especificación de consultas de informes, partiendo del hecho que se ha procesado ya el primer token “SELECT”:

REPITE ql : SI “*” ENTONCES

Q=q2 DE OTRO MODO

Procesa las columnas

DE OTRO MODO ERROR q2 : Si “FROM ENTONCES Q=q3

DE OTRO MODO ERROR q3 : Si (IDENTIFICADOR) ENTONCES

SI no hubo error ENTONCES

DE OTRO MODO ERROR

Q:=qZ

Verifica si la definición de la tabla ya ha sido previamente analizada

Q=q4

DE OTRO, MODO ERROR q4 : SI (WHERE) ENTONCES

q5 : EVALUA LA EXPRESION Q=q5

SI no hubo error ENTONCES Q=q6

q6 : Si “y ENTONCES Q=q7 HASTA que no ocurra un error o Q=q7

62

ARQUITECTURA YCONSlD DE DISEK!O DEL GEN AUT DE C o D l c o

Finalmente cuando termina el análisis del archivo de consultas se tienen registrados todos los informes que se desean obtener. En el caso que se quiera insertar una nueva consulta, ésta puede incluirse en un archivo separado si se desea, y automáticamente se sumará a la lista de consultas, lo cual tendría el mismo efecto que si se incluyera en el archivo inicial. En el caso en que se haya excedido el número máximo de consultas que se pueden procesar (20) simplemente no se registran aquellas que sobrepasen el límite permitido.

CAPITULO 4

Cuando se desea eliminar o modificar alguna(s) o todas las consultas registradas, es conveniente analizar nuevamente el archivo que contiene el esquema de la base de datos, esto para eliminar dichas consultas, y retornar al estado inicial; de esta manera se puede analizar un nuevo archivo de consultas y registrar las modificaciones.

4.2.4.4 Acciones semanticas

Básicamente las principales acciones semánticas que se llevan a cabo en este proceso son las siguientes:

1. Se verifica que exista registrada la tabla sobre la cual se lleva a cabo la consulta; lo que significa que el archivo donde se encuentra la definición de la tabla ya ha sido analizado.

2. Se verifica que las columnas que se especifican en la consulta pertenecen a la tabla que participa en ella.

3. En el caso en que haya condición de búsqueda, se verifica que ésta sea correcta.

4.3 MODULO PERSONALIZADOR

El módulo personalizador se encarga de proporcionar al usuario una interface para que éste pueda modificar algunos de los valores tomados por defecto y sin tener que accesar al código fuente. Entre las opciones que el usuario puede modificar en forma visual están las siguientes:

a) Borrados. Cuando se desea realizar la eliminación de algún o algunos registros de una tabla, es importante que se verifique que dicha eliminación no afecta a la consistencia de la base de datos, lo cual se aplica cuando algún campo de una tabla es llave foránea de otra tabla.

63

- - . - - - _ _ -

CAPITULO 4 ARQUITECTURA Y CONSID DE DISEÑO DEL GEN. AUT. DE C O D l t O

El usuario está habilitado para elegir entre generar código que permita o no dicha eliminación, para lo cual se presentan las siguientes dos únicas alternativas:

Eliminaciones en cascada Verificación a primer nivel

En la primera opción las eliminaciones se realizan en cascada, es decir, cuando se presenta el caso en que se desea eliminar una tupla de una tabla que es referenciada por otra. En estos casos se verifican todos los posibles anidamientos que puedan existir entre las tablas, y se eliminan todas las tuplas que se vean involucradas en el proceso; logrando de esta forma mantener la consistencia de la base de datos.

Por otra parte, en el segundo caso, de igual manera se realiza la verificación, pero esto es solo al nivel inmediato, es decir, sin averiguar si existen o no anidamientos entre las tablas, ya que si se encuentra que al primer nivel aparece una dependencia, simplemente se envía un mensaje en donde se especifica que no se permite llevar a cabo la eliminación de la tupla.

b) Informes. Las opciones que el módulo personalizador presenta al usuario son para poder especificar el encabezado, pie de página, compañía y siglas de la compañía que se desea que aparezcan en el informe. Además de estas opciones, se permite modificar la leyenda correspondiente a la consulta, por ejemplo, si inicialmente la consulta estaba dada en términos de:

“ Promedio =’ 90 “

ésta podría ser sustituida por :

“Todos los alumnos con promedio mayor a 90”

lo cual permitirá que al ejecutar el sistema generado, cada una de las opciones de la lista de posibles consultas tendrán un significado más representativo.

c) Columnas. En esta opción es posible asignar nuevos nombres a las columnas, los cuales aparecerán reflejados en la interface del prototipo, aunque internamente se sigan manejando los nombres iniciales. También es posible especificar límites superiores e inferiores, solo en el caso de columnas que sean de tipo diferente a “caracter” y “fecha”.

64

-- - ----- - -. -- - - -- ._


4.4 MODULO GENERADOR DE CODIGO

Este módulo se encarga de toda la parte de generación de código una vez que la especificación pasó por las pruebas de análisis (Ver Figura 4.5).

ANALIZADOR-: '

Fig. 4.5 Esquema que muestra la interacción de los distintos módulos

El código generado por el GAC se basa en el uso de seis módulos o bloques de librerías de funciones como se muestra en la Figura 4.6.

3

4

5

6

Fig. 4.6 Bloques que conforman el archivo ejecutable (.Em)

65

- - - .. - ~. -. . .

CAPITULO 4 ARQUITECTURA VCONSID. DE DISENO DEL GEN. AUT. DE CODICO

Los bloques I y 2 son los mismos para todos los programas generados, mientras que el resto de los bloques son generados para cada aplicación específica.

Básicamente existen dos módulos .que llevan a cabo la generación de código, los cuales son:

Gen-rut: Genera los bloques 3,4 y 5 Rutigen: Genera el bloque 6

A continuación se da una breve explicación del proceso de generación por cada uno de 10s bloques.

4.4.1 Generación de la unidad de constantes del sistema

En esta unidad se lleva a cabo la generación del código de las constantes que son utilizadas en el sistema, como podrían ser: coordenadas de las ventanas, tamaños de letra, identificadores de los objetos, etc.

Es importante señalar que hasta la última versión del generador de código, esta unidad es común para cualquier prototipo que se genere, por lo que podría pensarse en dejarlo como un archivo estático, que bien podría ser creado previamente y evitamos el proceso de su generación; sin embargo, se pensó que sería conveniente realizar el proceso de generación ya que se consideró que en futuras extensiones al trabajo, muchas de estas constantes podrían ser modificadas desde el módulo de personalización.

4.4.2 Generación de la unidad de control de opciones e interacción con el usuario

Este módulo tiene como finalidad crear los meniis para la selección de tablas y acciones sobre ellas. Una parte del código se muestra en el Anexo B.l

Un ejemplo del código generado sería como el que aparece a continuación:

Unidad Movimientos; Procedimiento Altas; Inicio

Si tabla-seleccionada =‘ALUMNOS ’ entonces

De otro modo Alta - alumnos

Si tabla - seleccionada=‘MAESTROS’ entonces

66

. . ~. -- - . .

CAPITULO 4 ARQUITECTURA Y CONSID. DE DISEÑO DEL GEN. AUT. DE CoDlGO

Alta-maestros ..... ..... Fin.

Procedimiento Bajas; ..... .....

4.4.3. Generación de la unidad de clases para diálogos, botones, etc.

En este módulo se genera el código de todos los elementos y objetos generales del sistema, como son (Ver Anexo B.2.1) :

1. Encabezado del programa principal 2. Archivos de recursos 3. Clase de la aplicación 4. Clases para las cajas de diálogo 5. Clase para la barra de menú 6. Clases para las ventanas auxiliares 7. Clase para la ventana principal 8. Variables locales 9. Métodos de la ventana principal 10. Control de cuadros de lista 1 1. Métodos de las ventanas auxiliares

4.4.4 Generación de las rutinas de manipulación de los datos de cada tabla de la BD

En este módulo se generan las rutinas de altas, bajas, cambios, consultas e informes. A continuación se muestra cómo se lleva a cab’o la generación de algunos de los siguientes módulos:

1. Generación del encabezado de la unidad.

2. Generación de las variables globales a la unidad, entre las que se encuentran las variables anfitrionas.

El encabezado de la rutina generadora es el siguiente:

PROCEDURE GenCod-VarHost.s(Fon:PTregTabla; con-x:Boolean; Normal,Doble-x,llaves,triple-x,guion:Boolean)

67

ARQUITECTURA Y CONS/D. DE DlSEÑO DEL GEN. AUT. DE COD/CO CAPITULO 4

Como puede observarse en el encabezado del algoritmo, el procedimiento generador recibe varios parametros; estos parámetros son ‘‘Form” el cual representa el diccionario de la forma y es el contenedor que guarda toda la información. Por otro lado, este mismo procedimiento puede generar únicamente variables anfitrionas para aquellas columnas que son llaves primarias, esto es por medio del parámetro “llave”. El resto de los parámetros son para dar diferente formato de salida a las variables, como por ejemplo con una, doble o triple “x”.

Básicamente, se tiene un arreglo por cada tipo de dato que se maneja. Estos arreglos contienen los nombres de las columnas que pertenecen al tipo de dato que éste representa. Una vez que se llenaron los arreglos, se realiza un recorrido por cada uno de ellos para generar las variables en grupos.

En realidad, la idea de tener almacenadas las columnas en base a sus tipos de datos, es para poder generar -pos de variables para un mismo tipo, y de esta forma tener una declaración como la siguiente:

edad, número, promedio : integer;

3. Generación de código para la creación de las clases de las ventanas de captura y desplegado de los datos.

4. Generación de código para los métodos de la ventanas de altas, bajas, cambios y consultas.

a) Constructor b) Para refrescamiento de la ventana c) Para el método donde se realiza la actualización

A continuación se presenta una parte del código que lleva a cabo la generación del método (procedimiento) que realiza la inserción de un nuevo registro en una tabla, donde la variable “Forma”” representa el diccionario de formas en memoria.

68

- - -~ __ _ _

ARQU'JECJURA Y CONSID. DE DISENO DEL &J. AUT. DE C O D , ~ ~ CAPlTUlO 4

PROCEDURE GenCod-ActualizaVAltas(Nombre:ch~l3); BEGIN 1. GenCod-Separador 2. GenCod-comen@J'ios(' Objetivo: Este mktodo tiene como objetivo la inserción de la mpla en la tabla coi-wmdiente as[ como la limpieza de los controles de edición') 3. Linea-enBlanco 4. Genera('PR0CEDUR.E TVentanaAltasAc~ali',Tnie)

Genera(' Var' ,True) Generaycad : StrSO',Tnie) Genera('BEGIN',True);

5 . Genera('$ Select',True) Genera(' Into',False)

6. Desde ¡=I hasta Forma".total de columnas Genera(':',False) CadenaAux=Forma".ColsT[i].nombre de la columna Genera(CadenaAux,False) Genera('x',False) SI i< Forma".total de columnas ENTONCES 7.

Genera(',',False) SI i mod 5 = O ENTONCES

Genera(' ',False) Genera(' ',True)

FIN FIN DE OTRO MODO

Genera(",True) FIN

8. Genera('Frorn',False) Genera(Nombre,True)

9. Genera('Where',False) ... I.. ......

Como puede observarse en el código, (por ejemplo, en la primer línea del bloque 4) el procedimiento que lleva a cabo la generación de código recibe el nombre de "GENERA". Este procedimiento tiene dos parámetros; el primero consiste de la cadena que se desea escribir, mientras que el segundo es una bandera, que si es falsa indica continuación en la misma línea y si es verdadera indica un salto a la siguiente línea. Ahora se analizará el código del generador por cada uno de los puntos que se Señalan:

Bloque 1. En esta instrucción se lleva a cabo la generación del código correspondiente a

un separador, el cual consta únicamente de un serie de caracteres como ''=''; esto es para dividir el procedimiento generado del anterior.

Bloque 2.

correspondientes a los métodos, en donde se explica la funci6n que estos tienen. El objetivo de esta serie de instrucciones es generar los comentarios

69

y CONSID DE DISENO DEL GEN AUT DE COD/GO CAPITULO 4

Bloque 3. Esta instrucción tiene como objetivo realizar un salto de línea.

Bloque 4.

procedimiento, así como una variable local que debe declararse dentro del mismo.

Bloque 5 .

que corresponden a instrucciones en SQL.

Bloque 6. Por cada una de las columnas de la tabla se genera el código correspondiente

a las variables anfitrionas, cuyo nombre es obtenido a partir de los nombres de las columnas adicionando una “x”, es decir, que si el nombre de la columna es “clave”, el nombre de la variable anfitriona será “clavex”.

En esta serie de instrucciones se genera el código del encabezado del

En este bloque de instrucciones se generan las palabras “SELECT” e “INTO”,

Bloque 7. En este bloque se verifica si la variable anfitriona que se genera es la última,

en el caso que no lo sea, se genera una “,”, de lo contrario significa que debe darse un salto de línea para continuar con el resto del estatuto. Se toma la convención de escribir en cadenas de 5 variables anfitrionas, esto es para evitar que las líneas resulten muy largas y produzcan errores de compilación.

Bloque 8. En estas dos iistrucciones se genera el código de la palabra “From” junto con

el nombre de la tabla, el cual se obtiene de la variable nombre, que recibe como parámetro el procedimiento generador.

Bloque 9.

generación posterior de la condición de búsqueda. En esta instrucción se genera el código de la palabra “WHERE” que indica la

El código resultante completo sería como el que aparece a continuación:

70

CAPITULO 4 ARQUITECTURA Y CONSID. DE DISENO DEL GEN. AUT. DE CODlCO

1 i . ( - - - - - - - - - - - - - - - - - - - -~ - - -~ - - 2. Objetivo : Este método tiene como objetivo llevar a cabo la inserción de la tupla en la tabla correspondiente, así como la limpieza de los controles de edición 3. 4. PROCEDURE TVentanaAltas.Actualiza;

Var

BEGIN Cad : Str8O;

5. 6. 7.

8. 9.

$ Select *

:SEXOX, :TELEFONOx, :DIRECCIONx, :PROMEDlOx, :NIVELx, :ESPECIALIDADx, :FECHAx, :GRUPOx

From ALUM Where CLAVE - :CLAVEx ; If SQLCODE - O Then

Into :CLAVEx, :NOMBREx, :MAESTROx,:MATERIAx, :EDADx,

MessageBox(HWindow, ' CLAVE YA EXISTENTE ','**** MENSAJE ****',mb - OK or mb - IconExclamation)

Veriíica-Rest(cad); i f cad-' 'then begin

$ Insert into ALUM

Else begin

Values(:CLAVEx, :NOMBREx, :MAESTROx, :MATERIAx:IndMATERIAx, :EDADx, :SEXOx:lndSEXOx, TELEFONOx:lndTELEFONOx, :DIRECCIONx:lndDIRECCIONx, :PROMEDlOx:lndPROMEDIOx, :NIVELx, :ESPECIALIDADx:lndESPECIALIDADx,:FECHAx:lndFECHAx, :GRUPOx:lndGRUPOx);

IF SQLCODE - O THEN Begin MessageBox(HWindow, 'LOS DATOS FUERON

INSERTADOS CON EXITO', t * * * * MENSAJE ****',mb OK or mb-IconExclamation);

Edicion[l]".Clear; ~dicion[Z]..Clear; Edicion[3]" .Clear; Edicion[4]" .Clear; Edicion[5]-.Clear; Edicion[ó]".Clear; Edicion[fl".Clear; Edicion[81^.Clear; Edicion[9lA.Clear; Edicion[lOl^.Clear; Edicion[l l]^.Clear; Edicion[lZl^.Clear; Edicion[l3]^.Clear;

End Else MessageBox(HWindow, 'ERROR EN LA INSERCION DE

,mb-OK or LOS DATOS','***' MENSAJE * * * * ' mb - IconExclamation);

End; End;

END;

En el código resultante que se muestra, se puede ver claramente la correspondencia de cada uno de los puntos entre el código del generador y el código generado.

5 . Generación de código para la verificación de rangos.

6. Generación de código para la verificación de nulos.

71

--.L. I - - ._ - .

, CAPITULO 4 ARQUITECTURA Y CONSID. D E DISEfiO DEL GEN. AUT. DE CODICO

7. Generación de código de los métodos de las ventanas, etc.

4.4.4.1. Generación de código para la verificación de la restricción referencia1 I

Este código es utilizado por el sistema prototipo para que se pueda mantener la integridad de la base de datos.

En el Anexo B.1.3 se presenta el código de la rutina generadora del método que se encarga de llevar a cabo la eliminación de tuplas en alguna tabla.

Supongamos que tenemos el siguiente esquema de una base de datos:

Create Table Cubics Clave Char (5) NOT NULL, Descrip Char (30),

PRIMARY KEY (Clave)); ....

Create table Alumnos Clave Char (5) NOT NULL, Nombre Char (40), Cubiculo Char (§),

FOREIGN KEY (Cibiculo) REFERENCES CUBICS (Clave), PRIMARY KEY (Clave));

....

Create Table Tesis Clave Char (5) NOT NULL, Descrip Char (40),

Alumno Char (9, FOREIGN KEY (Alumno) REFERENCES Alumnos (Clave), PRIMARY KEY (Clave));

....

Puede observarse que existe entre las tablas una dependencia como la que se muestra en la Figura 4.7.

12

CAPITULO 4 ARQUITECJURA Y CONSID. DE DISEÑO DEL GEN. A,UJ. DE CODICO

T! Columna cubículo

Columna alumno

Fig 4.7 Esquema de dependencia entre las tablas tesis, alumnos y cubics

por lo que en consecuencia, cuando se desea realizar una alta, baja o cambio a una tabla, se deben tener en cuenta los casos en los que como éste, es muy posible que la base de datos quede inconsistente.

Basándonos en el esquema mostrado anteriormente, supongamos que deseamos realizar la eliminación de una tupla de la tabla de “CUBICS”; en este caso, es necesario verificar que no exista alguna tabla que haya hecho referencia a ella en su definición.

Como puede observarse en el ejemplo, la tabla “ALUMVOS” referencia a la tabla “CUBICS”. En este caso existen dos caminos:

1. No permitir la eliminación o 2. Eliminar todas las tuplas que se vean afectadas en cada una

de las tablas anidadas (borrados en cascada).

Como se mencionó en puntos anteriores, el sistema prototipo puede ser generado tomando en cuenta cualquiera de las dos opciones que se mencionaron.

Básicamente, el algoritmo @e se mostró anteriormente genera código para poder realizar borrados en cascada. Este algoritmo trabaja con una estructura específica del diccionario de la forma, y es aquella en donde se encuentra toda la información de las columnas.

13

CAPITULO 4 ARQUITECTURA Y CONSID. DE DISENO DEL GEN. AUT. DE CODlCO

Tabla Alumnos

1

2

Fig. 4.8 Parte de la estructura interna del diccionario de formas para la tabla alumnos

En la Figura 4.8 se puede ver cómo se especifica que la columna “cubículo” de la tabla “ALUMNOS” es una llave foránea de la tabla “CUBICS”, y que se corresponde con la columna clave de ésta.

El algoritmo consiste en hacer llamadas recursivas en función del grado de anidamiento que se tenga de dependencia entre las tablas. Es decir, se procesa inicialmente la tabla “CUBICS”, posteriormente la de “ALUMNOS” y finalmente la de “TESIS”.

En el Anexo B.2.2 se muestra el código que el algoritmo generaría para el ’

ejemplo anterior.

4.5 MODULO PRECOMPILADOR

Este modulo se encarga de hacer una llamada al precompilador de SQL del Sistema Manejador de Bases de Datos Distribuidas (SMBDD), el cual se encarga de llevar a cabo la traducción de las instrucciones en SQL a llamadas a procedimientos en Pascal, generando como salida un archivo precompilado, listo para que sea pasado por el compilador de Turbo Pascal para Windows v. 1.5.

74


4.6 MODULO GENERADOR DE ARCHIVOS EJECUTABLES

Su función es la de hacer una llamada al compilador de Turbo Pascal para Windows, con el fin de poder compilar el archivo resultante de la fase anterior (Ver Figura 4.9) y generar de esta manera la aplicación ejecutable.

Fig. 4.9 Generación del archivo ejecutable

4.7 REPRESENTACION ESQUEMATICA AL NIVEL MAS ABSTRACTO

Cuando se desea crear una nueva aplicación o llamémosle prototipo, se presenta una secuencia de módulos de selección, de lo cuales dependerán finalmente el camino o destino que tendrán los programas generados, la manera en que se llevará a cabo la generación del código, así como otros atributos que se describirán a continuaci6n.

El sistema nos permite elegir entre dos opciones:

1. Abrir una base de datos. 2. Crear una nueva base de datos

Hay ocasiones en que es necesario accesar a una base de datos existente, por lo que el sistema permite el acceso a todos los archivos que estén dentro de ella, siempre y cuando se hayan cumplido los atributos de segundad implementados, y que se tratarán en puntos posteriores. Por otro lado en los casos en que sea necesario

75

apiruio 4 ARQUITECTURA Y CONSID. DE D~SEÑO DEL GEN. AUT. DE CODlCO

o se desee crear una nueva base de datos, el sistema permite crear un sistema de directorios propios con atributos de nombre de usuario y password, que dan al sistema un grado de seguridad, evitando que cualquier usuario pueda realizar modificaciones a los diccionarios de datos, creados específicamente para una aplicación.

El sistema nos da la opción de especificar si el proceso de generación de código se llevará a cabo en forma manual o automática.

La forma manual consiste en dejar que el usuario vaya realizando paso a paso cada uno de los procesos necesarios para la obtención del sistema final; mientras que el proceso automático evita al máximo tener que interactuar con el usuario, y lograr un sistema final con solo oprimir un botón.

Finalmente, de una otra forma, se realizan los procesos necesarios para lograr tener una aplicación ejecutable, y poder probarla en el momento que se disponga.

4.7.1 Sistema de directorios

Cuando se realiza la creación de una nueva base de datos, lo que internamente sucede es que se crea un nuevo directorio de trabajo, en donde estarán situados todos los archivos concernientes a la base de datos con que se trabajará. Obviamente, es posible copiar desde fuera del sistema, la especificación de una nueva base de datos, y tener más de una definición y archivos que estén relacionados con dos o más bases de datos distintas; sin embargo el objetivo de tratar con una estructura de directorios, es precisamente poder tener una administración de todos los archivos, de tal forma que en cada subdirectorio aparezcan únicamente aquellos que estén relacionados a una sola base de datos.

En el caso inicial, que es cuando no se ha creado a6n ninguna base de datos, se crea un nuevo subdirectorio (C:\BD) cuyo padre es la raíz, y es de aquí donde partimos para la creación de cada uno de los subdirectorios de trabajo para las bases de datos que se deseen dar de alta (Ver Figura 4.10).

También es importante señalar que se lleva un registro interno de las bases de datos que se han dado de alta, esto es con la finalidad de dar al usuario la facilidad de poder mostrar solo las ya existentes, evitando de esta forma que se trate de accesar a una base de datos que no existe.

16

- . ~ - ~ .-

CAPITULO 4 ARQUITECTURA Y CONSID. DE Dl5Eb?O DEL GEN. AUT DE CODICO

Fig. 4.10 Ejemplo del sistema de directorios

4.7.2 Sistema de protección

Todas las bases de datos creadas son almacenadas en un archivo llamado “bds.bd1” , el cual presenta la estructura que se muestra en la Figura 4.11.

Fig. 4.11 Estructura para el esquema de protección

Cada vez que el usuario quiera accesar la base de datos, debe introducir su nombre de usuario y password; de esta forma, una vez que se ha capturado esta información, se verifica si los datos son correctos.

4.7.2.1 Verificación de datos de seguridad

Una vez que el usuario ha introducido los datos de nombre de usuario y password ( en los casos que sea necesario), el siguiente paso es llevar a cabo la verificación de los mismos con los ya codificados, y determinar si el acceso es permitido o no.

4.7.2.1.1 Apertura de una BD existente

Cuando se ha seleccionado la apertura de una base de datos existente, de inmediato se cargan en memoria todos los datos correspondientes a cada una de las bases de datos, estas son almacenadas en una lista ligada la cual contiene los atributos de nombre de usuario y password ya codificados.

CAPITULO 4 ARQUlJECJURA y CONSID. DE DlSEfiO DEL GEN. AUT. DE CODlco

Una vez que el nombre de usuario y password han sido introducidos por la persona que desea accesar, se realiza una búsqueda a través de toda la lista y se detecta el nodo correspondiente, se llena un primer contenedor en donde se almacenan los datos ya codificados, posteriormente, los datos capturados son pasados por la función de cálculo que se utilizó para encriptar o transformar los datos y en un segundo contenedor son almacenados los datos codificados, finalmente se realiza una comparación entre el primer y el segundo contenedor; si son iguales se permite el acceso, de lo contrario se envía un mensaje para informar que el acceso no ha sido permitido (Ver Figura 4.12).

Fig. 4.12 Esquema de verificación de los datos de usuario

4.7.2.1.2 Creación de una nueva BD

Para el caso en que se seleccione crear una nueva BD, el mantenimiento del esquema de protección es muy sencillo, ya que solo se capturan los datos que el usuario desee que sean su nombre de usuario y password, y éstos son codificados y encriptados para que sean almacenados en un archivo.de seguridad (Ver Figura 4.13).

CONTENEDOR

Fig. 4.13 Almacenamiento de los datos de usuario

78

http://archivo.de

- ~ ~. _- .__. - -


4.7.3 Convenciones de nombres de archivos

Los archivos de especificación para la definición de la BD presentan la extensión “.El”‘.

Los archivos para reportes pueden ser identificados por tener extensión “.REP”.

’ El archivo que representa el diccionario de formas lleva el mismo nombre de la tabla a la que pertenece, con extensión “.FRM”.

Los archivos fuentes generados se identifican por tener extensión “.ORG’

Los archivos de respaldo de versión aparecen con la extensión “.BAK”.

Todo el proceso de análisis se lleva a cabo en el módulo dllex.dl1, el cual es una librería de ligado dinámico.

19

-_ - - - ' - - .

C APÍTULO 3 PATRON BE DISEÑO DE

LOS SISTEMAS PROTOTIPO

En el capítulo anterior se describió la arquitectura del generador de código; en este capítulo se describe la arquitectura del sistema computacional que genera de manera automática esta herramienta.

La descripción de este capítulo presenta dos enfoques, el primero es desde el punto de vista funcional en donde el usuario puede ver una interfaz que muestra las funciones que éste puede realizar; y por otro lado se hace una descripción en términos del desarrollo de un sjstema implementado bajo el paradigma de programación orientada a objetos (POO), esto es, se describen sus módulos y los tipos de objetos que maneja.

80

CAPITULO 5 PATRON DE DISEQO DE LOS SlSJEMAS PROJOTlPO

5.1 ARQUITECTURA FUNCIONAL DEL PROTOTIPO

La arquitectura de los prototipos generados está representada en el esquema funcional de la Figura 5.1, en donde se pueden observar las funciones que el sistema puede realizar.

I I I I

Fig. 5.1 Arquitectura genérica de los prototipos generados

Como se ve en la Figura 5.2, básicamente el sistema de información resultante presenta inicialmente las opciones de Mantenimiento, Informes y Salir:

5.1.1 Mantenimiento

En esta opción el usuario del sistema puede llevar a cabo las operaciones de altas, bajas, cambios y consultas a la base de datos, seleccionando previamente la tabla con la que desea trabajar. Una vez que se selecciona la tabla sobre la cual se desean realizan movimientos, aparece la barra de opciones, en donde es posible seleccionar una alta, baja, cambio, consulta o selección de otra tabla, todo esto a través de la selección del icono correspondiente como se muestra en la Figura 5.3.

Una gran ventaja de trabajar bajo Windows, es el poder de tener varias ventanas abiertas de distintas tablas, es decir, que es posible durante una alta a una

81

- - -- I_-.. - - -.

CAPITULO 5 PATRON DE DISENO DE LOS SISTEMAS PROTOTIPO

tabla, desplegar datos de otra por medio de una consulta, facilitando al usuario ciertas operaciones.

Fig. 5.2 Ventana inisial del prototipo generado

Fig. 5.3 Ventana para el mantenimiento de la base se datos

5.1.2 Informes

En esta opción el usuaria podrá realizar los informes cuyas consultas fueron definidas en el archivo de especificación para infarmes.

82

CAPITULO 5 PATRON DE DlSEÑO DE LO5 SISTEMAS PROTOTIPO

Cuando el usuario selecciona la opción de informes desde la ventana principal, aparece un cuadro de diálogo como el que aparece en la Figura 5.4, en donde se elige la salida del informe, es decir, por pantalla o por impresora.

5.1.2.1 Salida por pantalla

Los informes por pantalla son de un solo formato, y se diferencian de las consultas, en que éstos responden a una condición de búsqueda específica, mientras que éstas últimas no obedecen a una condición de selección.

Inmediatamente después de que se selecciona el informe por pantalla, se pide elegir el informe deseado de entre los especificados en el archivo de entrada de consultas para informes.

Fig. 5.4 Ventana para la selección de informes por pantalaa o impresora

5.1.2.2 Salida por impresora 0

Cuando se selecciona la salida del informe por impresora, aparece una lista de posibles consultas a elegir. Posteriormente, se debe seleccionar el formato de salida que se desea.

En los casos en los que los informes seleccionados sobrepasen los límites de los formatos elegidos, se envía un mensaje especificando que el informe no puede ser obtenido bajo ese formato.

83

CAPITULO 5 PATRON DE DISENO DE LOS SISTEMAS PROTOTIPO

El generador tiene la capacidad de generar código que sea capaz de realizar los informes en cuatro formatos diferentes:

a) Verticales

98 59 PJ 98 PI ?I w 91 97 ?5

b) Horizontales

84

i

CAPITULO 5 PATRON DE DISENO DE 105 SISTEMAS PROTOTIPO

c) A renglón seguido

d) Atributo por renglón

5.2 MODULOS COMPONENTES DEL SISTEMA Y SUS OBJETOS

En esta sección se describen los módulos que componen el sistema prototipo, así como los objetos que se manejan en él.

85

CAPITULO 5 PA JRON DE DISEÑO DE LOS SISTEMAS PROJOT/PO

5.2.1 Objetos del sistema

Como se mencionó anteriormente, el prototipo resultante está implenientado bajo el paradigma de POO, aquí se mencionan los principales tipos de objetos que se crean durante su ejecución.

5.2.1.1 Ventana para captura de datos (formas de captura)

Esta ventana es como la que se muestra en la Figura 5.5 y es empleada para la captura de los datos en el momento que se desea realizar una alta o una modificación. Como se puede apreciar en la misma figura, aparece una barra de Scroll para poder tener una visión de todos los campos de la tabla, así como también, se aprecian valores por omisión para los campos ‘sexo’ y teléfono’.

Fig 5.5 Ventana para captura

5.2.1.2 Ventana de petición de los campos clave (para bajas o consultas)

Esta ventana, como la que se muestra en la Figura 5.6, es empleada para la captura de los campos clave, como en los casos en los que se desea llevar a cabo una consulta o se desea realizar una baja.

86

-- -. ~ - . - ~ . - - - - .

CAPIJULO 5 PATRON DE DISENO DE LOS SISTEMAS PROTOJIPO

Fig. 5.6 Ventana para petición de campos clave

5.2.1.3 Ventana para muestra de datos

Este tipo de ventana se emplea para mostrar los datos que resultan de alguna consulta o informe por pantalla. Un ejemplo de este tipo de ventana se muestra en la Figura 5.7, en donde aparecen algunos campos de una tabla.

Fig. 5.7 Ventana para muestra de datos

5.2.1.4 Objetos para distintos tipos de cajas de diálogo

Estos objetos se emplean generalmente para que el usuario pueda tomar decisiones entre distintas opciones que se presentan.

87

CAPITULO 5 PATRON DE DISENO DE LO5 5ISTEMA5 PROTOT/PO

5.2.1.5 Objetos de control

Botones Barras de.scrol1 Controles estáticos Controles de edición, etc.

5.2.2 Módulos del sistema

En términos generales, el sistema de información tiene la arquitectura que se muestra en la Figura 5.8, en donde cada uno de los módulos, con excepción del programa principal, representan unidades, que finalmente son ligadas para constituir el sistema ejecutable.

Fig. 5.8 Diagrama jerárquico de los módulos componentes del sistema prototipo

5.2.2.1 Programa principal

El programa principal se encarga de invocar a los métodos Init, Run y Done de la aplicación. El método Init que es básicamente el constructor de la aplicación. El método Run da inicio al lazo de mensaje de la aplicación como una tarea de Windows. El método Done descarta el objeto ventana principal de la aplicación y después da por terminada ésta.

88

CAPlTULO 5 PATRON DE DlSEt?O DE LOS SISTEMAS PROTOTIPO

Este es el encabezado del programa principal ) $M 10000,500 Program SISTEMA; USES OBJETOS; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PROGRAMA PRINCIPAL ) BEGIN

Aplicacionl .Init('SISTEMA GENERADO); Aplicacionl .Run; Aplicacion I .Done;

END.

5.2.2.2 Unidad de constantes

En esta unidad sé encuentran todas las constantes que se utilizan en el sistema. Un ejemplo del código de esta unidad se muestra en el Anexo B.2.3.

5.2.2.3 Unidad de objetos

Aquí se encuentran todos las definiciones de las clases de objetos que se utilizan para la interfaz del sistema prototipo. Esta unidad representa una biblioteca de objetos de uso general, es decir, son comunes en todos los sistemas generados.

5.2.2.4 Control de opciones e interacción con el usuario

Esta unidad se encarga de llevar el control de las opciones del usuario, y de esta forma ejecutar las acciones correspondientes. Un ejemplo del código de esta unidad se muestra en el Anexo B.2.4.

5.2.2.5 Conjunto de unidades por cada una de las tablas que participan en la base de datos

Por cada tabla que participa en la BD se crea la unidad correspondiente a sus . movimientos, así como también, en el caso que se especifiquen reportes, se crea un módulo en forma de librería el cual se encargará de llevar el control de éstos.

5.2.2.5.1 Unidad para rutinas de altas, bajas, cambios y consultas

Estas unidades representan la parte medula del sistema, ya que es aquí donde se encuentran las rutinas de altas, bajas, cambios, consultas a la base de datos. Básicamente, estas unidades están formadas por las siguientes secciones:

n

I

i

I 89

CAPITULO 5 PATRON DE Dl5EÑO DE LO5 SISTEMA5 PROTOTIPO

1. Encabezado de la unidad Se define el nombre de la unidad y la sección de la interface

UNIT CUBIC, INTERFACE

2. Unidades que utiliza Se definen las unidades que utiliza la unidad especificada

USES WINPROCS,WINTY PES,WOBJECTS,TIPOSGL1,STRINGS,CONSTANT,WINDOS,SQL,

3. Rutinas que son compartidas con la unidad de movimientos (Mow) Encabezados de las rutinas que son llamadas desde la unidad de movimientos

PROCEDURE Altas-CUBIC(Tabla-Se1:NomTabla; Padre:PwindowsObject); PROCEDURE BajasCUBlC(Tabla-Sel:NomTabla; Padre:PwindowsObject); PROCEDURE Cambios-CUBIC(Tabla-Se1:NomTabla; Padre:PwindowsObject); PROCEDURE Consultas-CUBIC(Tabla-Se1:NomTabla; Padre:PwindowsObject); PROCEDURE ReportesCUBIC(Tabla-Se1:NomTabla; Padre:PwindowsObject; Pantal1a:Boolean);

IMPLEMENTATION

CONST ( Identificadores de los Botones 1 id,Pushl = 114; id-Push2 = 115; id-Scrollx = 116;

4. Sección para la definición de las clases En esta sección se definen todas las clases de los objetos particulares

TYPE TventanaGeneral = OBJECT(Twindow)

END; Clase Ventana para las Altas ) PVentanaAltas = "TVentanaAltas; TVentanaAltas = OBJECT(TVentanaGenera1)

END; ( Clase ventana que muestra los datos de las bajas PVentanaBajasHija = "TVentanaBajasHija; TVentanaBajasHija = OBJECT(TVentanaCenera1)

END; ( Clase Ventana principal para las Bajas ] PVentanaBajas = "TVentanaBajas; TVentanaBajas = OBJECT(TVentanaGenera1)

END;

.....

.....

.....

.....

1

I

.. . . .

' 1 1 . .

. . 4

I

90

PATRON DE DISEÑO DE LO5 SISTEMAS p R O T o ~ / p o c A P i r u o 5

Clase ventana que muestra los datos de los cambios ) PVentanaCambiosHija = "TVentanaCambiosHija; TVentanaCambiosHija = OBECT(TVentanaA1tas)

END; ( Clase Ventana para los Cambios ) PVentanaCambios = "TVentanaCambios; TVentanaCambios = OBJECT(TVentanaBajas)

END; ( Clase que representa una coleccion PColeccion = "TColeccion; TColeccion = object(T0bject)

END; Clase Ventana para las Consultas ) PVentanaConsultas = "TVentanaConsultas; TVentanaConsultas = OBJECT(TVentanaGenera1)

END;

... < .

.... <

.....

.....

Como puede observarse en la definición de las clases, existen clases de objetos que heredan características de otras. En la Figura 5.9 se muestra el diagrama de herencias entre las distintas clases de objetos.

I

Fig. 5.9 Jerarquía de tipos de objetos utilizados en el sistema prototipo

Twindow TVentanaGeneral

: Objeto definido en la biblioteca de objetos de Windows : En esta ventana se definen características generales para

todas las ventanas, como por ejemplo el color del fondo y el tamaño inicial.

91

JRON DE DISENO DE LOS SISTEMAS PROTOTlpO CAPITULO 5

TVentanaAitas

TVentanaBajas TVentanaBajasHiJa TVentanaConsultas

TVentanaCambiosHija : Esta ventana cuenta con controles de edición para capturar

: Esta ventana cuenta con controles de edición para capturar

: Esta Ventana captura solo los campos claves de la tabla. : Esta ventana muestra los datos que se desean dar de baja. : Esta ventana muestra en forma tabular los datos que

10s datos que se desean dar de alta.

resultan de una consulta.

los datos que se desean modificar, con excepción de los campos que constituyen las llaves primarias.

TVentanaCambios

5. Sección de variables anfitrionas y globales en la unidad En esta sección se definen todas las variables globales a la unidad, incluyendo la

declaración de las variables anfitrionas que se utilizan en los estatutos de SQL que se encuentran intercalados en todo el código fuente.

: Esta ventana captura los campos ciave de la tabla.

$ BEGIN DECLARE SECTION CLAVE-CUBICX : STRING [ 5 1 ; ALUMNOX : STRING [ 5 I ;

END DECLARE SECTION ;

Ventanditas : PVentandltas, VentanaBajas : PVentanaBajas; Ventanacambios : PVentanaCambios; Ventanaconsultas : PVentanaConsultas; Ventanaeportes : PVentanaConsultas; Rep-Sel,TipoRep-Sel: Array [O..MAXREP-SEL] Of char; IdxlJdx2 : Integer; Abort : Boolean; hAbortDialog : hWnd;

6. Sección de rutinas que controlan la creación de la ventana correspondiente En esta sección se da la definición de las rutinas que son compartidas con la

unidad de movimientos. El objetivo de cada una de estas rutinas es llevar a cabo la creación de la ventana correspondiente al movimiento que se desea realizar sobre la tabla. El código de estas rutinas puede encontrarse en el Anexo B.2.5.

7. Sección de implementación de los métodos de las Clases

clases definidas. La explicación de cada método aparece en el Anexo B.2.6. En esta sección aparece la implementación de cada uno de los métodos de las

a) Métodos de la ventana principal b) Métodos para la ventana de altas c) Métodos para la ventana de bajas que realiza la petici6n de los campos clave d) Métodos para la ventana de bajas que muestra los datos que se desean eliminar

!

i

'I

92

a p m o 5 PATRON DE DISENO DE LOS SISTEMAS PROTOTIPO

e) Métodos para la ventana de cambios en donde se muestran y editan los campos que se desean modificar

' J Método para el objeto Colección que almacena los datos que resultan de una consulta g) Métodos para la ventana de consultas en donde se muestran los datos en pantalla

Cuando no hay informes que procesar, la sección de consultas se localiza en la misma unidad que el resto de las rutinas, como en este caso. Sin embargo, cuando es el caso contrario, se crea una librería adicional en donde se localizan las rutinas para las consultas y los informes que se especificaron.

5.2.2.5.2 Unidad para informes

Esta unidad se encarga de generar los informes del sistema; es creada únicamente si el generador detecta que existen reportes registrados en el diccionario de la forma.

Cuenta con un procedimiento ilamado Reps-00, cuyo objetivo es imprimir los datos vía impresora. En los casos en los que los informes se desean por pantalla, éstos son controlados por los métodos correspondientes a la ventana de consultas.

Esta unidad cuenta con procedimientos para el control de las impresiones. Algunos tienen las siguientes funciones:

a) Imprimir el pie de página b) Verificar el término de pagina c) Verificar el término de rengión d) Verificar que el informe pueda ser impreso en formato horizontal o vertical e) imprimir los datos f) Obtener el manejador de impresiones g) Verificar si se aborta la impresión h) Imprimir fecha y hora i) Imprimir encabezado

5.2.2.6 Unidad de tipos de datos

En esta unidad se encuentran todos los tipos de datos que se utilizan en el sistema prototipo.

i

I

93

CAPITULO 5 PATRON DE DlSEfiO DE LOS SISTEMAS PROTOTIPO

5.2.2.7 Unidad del SMBDD .

Unidad requerida para la manipulation interna de los datos.

Cada uno de estos módulos son generados automáticamente por el generador, con excepción de la unidad de tipos de datos la cual es UPI archivo que no presenta cambios para diferentes sistemas, y la unidad del SMBDD la cual es necesaria para la ejecución de las llamadas a procedimientos en Pascal que llevan a cabo la manipulación de los datos; estos procedimientos son el resultado de la precompilación previa del prototipo generado, cuyas instrucciones eran en Pascal con algunas otras de SQL inmerso.

94 i

i

C APÍTULO 6 PRUEBAS

En este capítulo se especifican las pruebas que se realizaron al generador de código. Cabe mencionar que cada uno de los casos considerados en este capítulo son solo los más representativos.

95

- - - - - - - -------

PRUEBA5 CAPITULO 6

6.1 OBJETIVO Y DESCRIPCPQN DE LAS PRUEBAS

El principal objetivo de estas pruebas es verificar que el “generador de código” realiza correctamente sus funciones, es decir, determinar si finalmente se generan sistemas que puedan funcionar en forma satisfactoria para la definición del esquema de una base de datos .

La lista de casos de prueba que se describen en este capítulo consisten en la definición de diferentes esquemas de bases de datos. Para cada una de ellas se genera el sistema correspondiente por medio del “generador de código” que se presenta en esta tesis.

Una vez que el código se genera, se realizan algunas inserciones a cada una de las tablas que participan en la base de datos; posteriormente se llevan a cabo algunos borrados y modificaciones para después hacer consultas sobre ellas, y mostrar que el sistema efectivamente realiza correctamente todos los movimientos sobre las tablas.

6.2 CASOS DE PRUEBA

A continuación se presentan los casos de pruebas para distintas definiciones de esquemas de bases de datos. Dentro de cada caso aparecen las pruebas que van ligadas al código que se genera para dicho esquema.

96

PRUEBAS CAPITULO 6

PRUEBA No.1

OBJETIVO:

El objetivo de esta prueba es verificar que todos los tipos de datos pueden ser considerados por el generador de código. Se prueba también el uso de los campos que no aceptan nulos.

Paso 1. , Se realiza la inserción de algunos registros a la tabla “TIPOSDAT”

Resultados: Como puede verse en el Reporte No. 1, los datos se insertaron con éxito.

Paso 2. Se intenta insertar un nuevo registro a la tabla “TIPOSDAT”, en donde el

valor del campo ‘numerico-72’ , excede la longitud máxima de dígitos permitida (7).

91

CAPITULO 6 PRUEBAS

FECHA: Lunes 19/8/1996 HORA: 11:01:54

REPORTE No. I

C E N I D E T

TODOS LOS REGISTROS

CLAVE : 0001 NOMBRE : Los accesorios del escritorio que vienen con Windows pueden

ayudarle a realizar tareas especiales, relacionadas con aigri n proyecto en curso, sin salir de la aplicaci6n. Usted pued e estar trabajando con Excel, por ejemplo, y necesitar hacer una ....

ENTERO PEQUEN0 : 400 ENTERO : 190000 REAL-O-SMALLFLOAT : 2.0000000000E+0I FLOTANTE : 2.0000000000E+03 NUMERKO-7-2 : 00078.00 FECHA : 12/12/1996

CLAVE : 0001 NOMBRE : Estos accesorios del escritorio tienen la ventaja de una de

las herramientas más poderosas ae Windows: la capacidad de c orrer en varias aplicaciones de manera simulthea. Mientras trabaja en !a aplicación principal, usted puede mantener las aplica ...

ENTERO PEQUEN0 : 15000 ENTERO : 9999 REAL-O-SMALLFLOAT : 8.9000000000E+01 FLOTANTE : 6.7045500000E+03 NUMERICO-7-2 : 12345.99 FECHA : 10/01/1990

REPORTEDELAPRUEBANo.1 I

98

PRUEBAS CAPITULO 6

Resultados: El nuevo registro no pudo ser insertado debido a que el valor introducido en el campo ‘numeric-72’ sobrepasó la longitud máxima de dígitos permitida.

Paso

valor el

99

CAPITULO 6 PRUEBAS

Resultados: El nuevo regfstro no pudo ser insertado debido a que se intentó introducir un valor nulo al campo ‘enteroqequeno’ , en el cual se especificó que no se aceptaban valores nulos.

Paso 4. Se intenta insertar un nuevo registro a la tabla “TIPOSDAT”, en donde el

valor del campo ‘entero’ sobrepasa el límite del máximo valor permitido para los enteros (2147483647).

Resultados: El nuevo registro no pudo ser insertado debido a que se intentó introducir un valor superior al máximo permitido para el campo ‘entero’.

1 O0

CAPITULO 6 PRUEBAS

PRUEBA No.2

OBJETIVO:

El objetivo de esta prueba es verificar que puedan ser creados campos de la máxima longitud permitida y adicionalmente verificar el formate0 de un informe sobre la tabla de ejemplo.

Paso 1. Se realiza la inserción de algunos registros a la tabla “TIPODAT2”.

Resultados: Como puede verse en el Reporte No. 2, los datos se insertaron con éxito.

Paso 2. Se lleva a cabo la modificación del registro ‘0001’ en su campo

‘Nombrel’. De Nombrel = ‘El Block de notas es un editor de texto en miniatura. Aunque con funciones limitadas, cuando las compara con otras aplicaciones como Write de Windows o un procesador de palabras profesional como Word para Windows o Ami Pro, el Block de Notas es una h’

a Nombrel = ‘Cambio para el paso 2’.

Resultados: Como puede verse en el Reporte No. 3, la actualización se realizó con kxito.

101

CAPITULO 6 PRUEBAS

FECHA. Lunes 19l.911996

REPORTE No. 2

C E N I D E T

TODOS LOS REGISTROS

CLAVE : 0001 NOMBRE1 : El Block de notas es un editor de texto en miniatura Aunque

con 'funciones limitadas, cuando las compara con otras aplic aciones como Write de Windows o un procesador de palabras pr ofesional como Word para Windows o Ami Pro, el Block de Nota s es una h

NOMBRE2 : igual que se usa un block de nom sobre el escritorio, uste d puede usar el Block de Notas para hacer anotaciones sobre la pantalla mientras trabaja en otra.' aplicaciones de Window s. El Block de Notas usa poca memoria y es útil para editar texto que

NOMBRE3 : El Block de notas encuentra y guarda los archivos en formato de texto. Esta posibilidad hace del Block de Notasun edito r conveniente para crear y modificar los archivos WIN.IN1 de Windows, los archivos de procesamiento por lotes de MS-DOS, los de de

CLAVE : O002 NOMBRE1 : Otro uso práctico para el Block de Notas. es guardar textoq

ue quiera mover a otra aplicaci6n. El portapapeles puede gua rdar s61o una selecci6n a la vez, pero el Block de Notas pue de servir como un album de recortes cuando usted esta movien do varios

NOMBRE2 : Tenga cuidado cuando edite con el Block de Notas, Debido a q ue el Block deNotas crea archivos de texto, usted puedeabr ir y editar archivos importantes del sistema, de las aplicac iones o de datos. Para evitar la perdida de datos o deaplic aciones, a

NOMBRE3 : Para editar o aRadir texto en el Block de Notas, usted debe aprender c6mo recorrer la pagina y mover el punto de inserci r conveniente para crear y modificar los archivos WIN.INI de 6n. Aunque las páginas del Block de Notas se recorren a'trav 6s de la ventana, la mejor manera de concebir bsta acci6n es como una

HORA: 11:01:54

REPORTEDELAPRUEBANo.2 1

102

CAPITULO 6 PRUEBAS

FECHA: Lunes 19/8/1996 HORA: 11:01:54

REPORTE No. 3

C E N I D E T

TODOS LOS REGISTROS

CLAVE : 0001 NOMBRE1 : Cambio para el paso 2 NOMBRE2 : Igual que se usa un block de notas sobre el escritorio, uste

d puede usar el Block de Notas para hacer anotaciones sobre la pantalla mientras trabaja en otras aplicaciones de Window s. El Block de Notas usa poca memoria y es útil para editar texto que

NOMBRE3 : El Block de notas encuentra y guarda los archivos en formato de texto. Esta posibilidad hace,del Block de Notasun edito

r conveniente para crear y modifiuir los archivos WiN.iNI de Windows, los archivos de procesamiento por lotes de MS-DOS, los de de

CLAVE:0002 NOMBRE1 : Otro uso prúctico para el Block de Notas, es guardar texioq

ue quiera mover a oira aplicaci6n. El portapapeles puede gua rdar s610 una selección a la vez, pero el Block de Notas pue de servir como un álbum de recortes cuando usted esta movien do varios

NOMBRE2 : Tenga cuidado cuando edite con el Block de Notas, Debido a q ue el Block de Notas crea archivos de texto, usted puede abr ir y editar archivos importantes del sistema, de las aplicac iones o de datos. Para evitar la ptrdida de datos o deaplic aciones, a

NOMBRE3 : Para editar o añadir texto en el Block de Notas, usted debe aprender c6mo recorrer la página y mover el punto de inserci r conveniente para crear y modificar los archivos WiN.iNI de 6n. Aunque las páginas del Block de Notas se recorren a trav 6s de la ventana, la mejor manera de concebir esta accidn es como una

REPORTEDELAPRUEBANo.2 1

103

CAPITULO 6 PRUEBAS

PRUEBA No.3

OBJETIVO:

El objetivo de esta prueba es verificar que puedan ser creados campos de la mínima longitud permitida y que es posible crear tablas de hasta 20 campos.

Paso 1. Se realiza la inserción de algunos registros a la tabía “TABLAS”.

104

CAPITULO 6 PRUEBAS

I

Resultados: Como puede verse en la figura ¡os datos se insertaron con éxito.

Paso 2.

campo3=3 a campo3 = 5. Se realiza un cambio en el campo3 del registro con clave ‘0002’, de

io5

CAPITULO 6 PRUEBAS

Resultados: La actualización del registro con clave ‘0002’ se realizó exitosamente.

Paso 3. Se lleva a cabo la eliminación del registro ‘0003’ de la tabla “TABLAS”.

Resultados: Después del movimiento anterior los datos de la tabla “TABLAS” quedan de la siguiente manera:

106

CAPITULO 6 PRUEBAS

OBJETIVO: b PRUEBA No.4

El objetivo de esta prueba es verificar que se cumpla la regla de integridad referencia1 para dos tablas, en donde la llave primaria Cformaúa por una sola columna) de una tabla, representa una llave foránea para la otra. Se prueba además la opción de realizar eliminaciones en cascada.

En la Figura 6.1 se muestra un diagrama que ejemplifica la dependencia referencial entre las tablas “ARTICULO” y “DEPAS”.

departam

Fig. 6.1 Diagrama de dependencia referencia1 entre las tablas “ARTICULO” y “DEPAS”

107

CAPITULO 6 PRUEBAS

Paso 1; Se realiza la inserción de los siguientes registros a la tabla “DEPAS”

Resultados: Los datos se insertaron con éxito.

Paso 2. Se realiza la inserción de los siguientes registros a la tabla “ARTICULO.

108

PRUEBAS

Resultados: Los datos se insertaron con éxito.

Paso 3.

para el campo “Departam” igual a ‘05’. Se intenta imertar un nuevo registro a la tabla “ARTICULO’ con un valor

109

CAPiTULO 6 PR UEBA5

Resultados: Como puede verse, por restricción referencia1 el registro no puede ser insertado, ya que no existe en la tabla “DEPAS’ un registro con clave ‘05’.

Paso 4.

registro ‘03’, de Nombre = ‘Ropa para bebé’ a Nombre = ‘Ropa para niño’. Se realiza una modificación a la tabla “DEPAS” en el campo ‘nombre’ del

Resultados: La modificación se realizó exitosamente.

Paso 5 (No se permiten borrados en cascada). Se intenta llevar a cabo la eliminación del registro ‘01’ de la tabla “DEPAS’

,

I IO

CAPITULO 6 PRUEBAS

Resultados: Como puede observarse en la figura, no se permite en este caso realizar eliminaciones sobre registros de los cuales dependen registros de otras tablas; como en este ejemplo, en donde el renglón ‘01’ de Ia tabla “DEPAS” es referenciado por el renglón ‘00001 ’ en la tabla de “ARTICULO.

Paso 6 (Se permiten borrados en cascada). Sin embargo, es posible construir el sistema de tal forma que se permitan

hacer borrados en cascada. A continuación se mostrará cómo se realiza ¡a baja del mismo registro ‘01’ con un nuevo sistema generado, pero con la opción de permitir los borrados cuando se presentan casos como el del ejemplo anterior.

1 1 1

CAPITULO 6 PRUEBAS

@ LOS O b l O S FUERON ELIMINADOS CON m10

Resultados: Después de que la eliminación se Ilevb a cabo, las tablas “ARTICULO” y “DEPAS” quedan como se ve en las figuras que se muestran a continuación. El registro ‘O 1 ’ de la tabla “DEPAS” fue eliminado de la tabla, y como consecuencia se eliminaron todos los registros de la tabla “ARTICULO” que referenciaban al registro ‘O 1 ’ de la tabla “DEPAS”.

112

CAPlTUlO 6 PRUEBAS

Tabla “DEPAS”

Tabla “ARTICULO”

I 1 3

CAPITULO 6 PRUEBAS

PRUEBA No.5

OBJETIVO:

El objetivo de esta prueba es verificar que se cumpla la regla de integridad referencial para dos tablas, en donde la llave primaria Cformadu por dos columnas) de una tabla, representa una llave foránea para la otra.

En la Figura 6.2 se muestra un diagrama que ejemplífica la dependencia referencia1 entre las tablas ‘“FACTURA” y “CLIENTE”.

Columnas cliente y zona - cíien

Fig. 6.2 Diagrama de dependencia referencia1 entre las úablas “FACTURA” y “CLIENTE”

I14

CAPITULO 6 PRUEBAS

Paso 1. Se realiza la inserción de los siguientes registros a la tabla “CLIENTE’.

Resultados: Los datos fueron insertados exitosamente.

Paso 2. Se realiza la inserción de los simientes registros a la tabla “FACTURA”.

I15

.. .. ~~ . ~~

-- -_ - - _-._ ~ , /

P R M E A I I CAPITULO 6

Resultados: Los datos se insertaron exitosamente.

.Paso 3. Se intenta insertar un registro en la tabla “FACTURA” con los siguientes

valores:

Resultados: La nueva factura no pudo insertarse debido a que no existe el cliente ‘001’ con zona de cliente ‘003’.

Paso 4. Se realiza una modificación al registro ‘001’ ‘001’ en su campo ‘nombre’ de

la tabla de “CLIENTE”. De Nombre = ‘Juan Antonio González Garcia’ a Nombre = ‘J. Antonio Glz. Garcia’.

116

PRUEBAS

Resultados: La modificación se realizó con éxito.

Paso 5. Se lleva a cabo la eliminación del registro ‘00002’ de la tabla “FACTURA”.

Resultados: La eliminación se realizó exitosamente.

117

CAPITULO 6 PRUEBAS

Paso 6. Se intenta inserta un nuevo registro con clave ‘00001’ en la tabla

, ‘FACTURA’.

CLAVE YA DDSTENTE

Resultados: El registra no pudo insertarse debido a que ‘la clave ‘00001 ’ ya existía en la tabla ‘FACTURA’.

I I8

CAPITULO 6 PRUEBAS

PRUEBA No.6

OBJETIVO:

El objetivo de esta prueba es verificar que se cumpla la regla de integridad referencial para tres tablas, en donde la llave primaria Cformada por una columna) de una primera tabla, representa una llave foránea para la segunda tabla, y ésta a su vez tiene una llave primaria (formada por una columna) que es una llave foránea de la tercera tabla. Se prueban también las eliminaciones en cascada para las tres tablas.

En la Figura 6.3 se muestra un diagrama que ejemplifica la dependencia referencial entre las tablas “BONOS”, “TRABAJAS” y “DEPTO”.

I19

PRUEBAS CAPITULO 6

departam

Tt Columna trabajador

Fig. 6.3 Diagrama de dependencia referencia1 entre las tablas “BONOS”, “TRABAJAS” y ‘‘DEPTO’’

Paso 1. Se realiza Ia inserción de los siguientes registros a la tabla ‘DEPTO’.


120

IZI

PRUEBAS CAPITULO 6


Paso 4.

cuenta que el sistema permite los borrados en cascada. Se elimina el registro con clave ‘001’ de la tabla “DEPTO”, tomado en

Resultados: A continuación se muestran los datos de cada una de las tablas después de la eliminación.

TABLA “DEPTO”

122

-- - - - -_ -- . .

PRUEBAS CAPITULO 6

TABLA “TRABAJAS”

TABLA “BONOS”

123 .

CAPlTULO 6 PRUEBAS

PRUEBA No.7

OBJETIVO:

El objetivo de esta prueba es verificar que se cumpla la regia de integridad referencial para tres tablas, en donde una de las tres tablas contiene dos llaves foráneas, las cuales corresponden a las llaves primarias (formada por una columna) de las otras dos. * I

En la Figura 6.4 se muestra un diagrama que ejemplifica la dependencia referencial entre las tablas “PUESTOS”, “TRAB” y “DEPARTAM’.

124

~. - . ~- ~~ _.

CAPiJULO 6 PRUEBAS

Fig. 6.4 Diagrama de dependencia referencia1 entre las tablas “PUESTOS”, “TRAB” y “DEPARTAM”

Pasoí. Se realiza la inserción de 10s siguientes datos a la tabla de “PUESTOS”


125 c

CAPITULO 6 PRUEBAS

Paso 2. Se realiza la inserción de los siguientes datos a la tabla ‘DEPARTAM”.


Paso 3. Se realiza la inserción de los simientes datos a la tabla de “TRAB”

I26

PRUEBAS CAPITULO 6


Paso 4.

de Puesto = ‘003’ a Puesto = ‘005’. Se intenta modificar el campo ‘puesto’ del registro ‘002’ de la tabla “TRAB”,

Resultados: Como puede verse en la figura, el sistema no permite la modificación en el campo ‘puesto’ del registro ‘OOZ’, ya que no existe en la tabla “PUESTOS” un registro con clave ‘005’.

Paso 5.

“TRAB”. Departam = ‘002’ a Departam = ‘004’. Se intenta modificar el campo ‘departam’ del registro ‘002’ de la tabla

127

--- - - - .. . . . . - -

CAPITULO 6 PRUEBA5

Resultados: Como puede verse en la figura, el sistema no permite la modificación en el campo ‘departam’ del registro ‘002’, ya que no existe en la tabla “DEPARTAM” un registro con clave ‘004’.

128

.

C APÍTULO 7 COMENTARIOS FINALES

En este capítulo se dan los comentarios finales que describen las contribuciones de este trabajo y sus limitaciones, así como las futuras investigaciones en el área.

129

COMENTARIOS FINALES CAPITULO 7

7.1 CONTFUBUCION DE LA INVESTIGACION

La mayor contribución de este trabajo se centra en enfocar el problema del deskollo de la generación de prototipos rápidos para que su código pueda ser reutilizado. Trabajos previos en esta área, se han dirigido al desarrollo de prototipos como una herramienta de ayuda para recabar los requerimientos del usuario de una manera rápida. Sin embargo, no se ha considerado que el código de los prototipos generados pueda ser reutilizado o adecuado a una aplicación real, así como también que este código sea en un lenguaje de tercera generación y con un lenguaje de consultas embebido como lo es SQL.

Otra contribución de este trabajo está en proponer un cambio a las metodologías del modelo del ciclo de vida en espiral basado en prototipos incrementales y prototipos incorporados, en donde se integran para crear un nuevo concepto de desarrollo de sistemas de información, específicamente ' en aquellos donde la ambigüedad en las especificaciones sea muy evidente.

Finalmente, se desarrolló una herramienta CASE (GPR) que pudiera cumplir con los objetivos planteados. El GPR incluye la generación de prototipos de sistemas de información en tiempos muy cortos y costos muy bajos, y es capaz de generar código bastante legible posibilitando de esta manera su uso posterior.

La siguiente lista sumariza las contribuciones de este trabajo descrito anteriormente.

(i) Posibilita la reutilización del código de prototipos generados a través del GPR.

(ii) Permite utilizar como entrada para el GPR la especificación del esquema de una BD.

(iii) Se muestra la factibilidad de desarrollar una herramienta capaz de generar el código en forma automática de prototipos de sistemas de información que pueden realizar las funciones del mantenimiento y generación de informes de una BD manteniendo la regla de integridad referencial.

(iv) Propone una mejora a Las metodologías de desarrollo de sistemas de información que utilizan prototipos, en donde se fusiona el concepto de desarrollo de prototipos incrementales con el desarrollo de prototipos incorporados, dentro del desarrollo en espiral.

130

COMENTARIOS FINALES a m u o 7

Las implicaciones de este trabajo tienen dos aspectos. El primero es que le facilita ai usuario la tarea de definir y aclarar sus necesidades de información o requerimientos. Y segundo, al desarrollador se le facilita la tarea de comprender las necesidades del usuario y posibilita por otra parte, el ahorro en tiempos de desarrollo a través del reuso de componentes de código. Todo esto puede resultar en el desarrollo de sistemas de información que satisfagan mejor los requerimientos de los usuarios reduciendo tiempos y costos de desarrollo.

!

7.2 LIMITACIONES DEL TRABAJO

Hay algunas !imitaciones en la herramienta presentada en este trabajo. Estas son:

(i) El diseño de las formas de captura es el mismo para todos los prototipo generados.

(ii) Los informes que se generan están limitados a reportes originados de consultas en SQL que involucren solamente una tabla.

(iii) El GPR puede generar prototipos para cualquier número de tablas de una BD, sin embargo, se debe tener especial cuidado en las restricciones que impongan el sistema operativo y el cornpilador del lenguaje utilizado.

Otras limitaciones :

(iv) Quedó fuera del alcance de este trabajo el realizar un análisis profundo para cuantificar el costolbeneficio de reutilizar componentes de código de los prototipos generados en el desarrollo de sistemas.

7.3 TRABAJOS FUTUROS

Los trabajos futuros que se proponen para dar continuidad de este trabajo son:

(i) Realizar un análisis costolbeneficio para cuantificar el impacto en los costos del desarrollo de sistemas de información con el enfoque propuesto.

(ii) Realizar un análisis para cuantificar la legibilidad del código generado como una medida de su facilidad de comprensión por los desarrolladores.

131

CAPITULO 7 COMENTARIOS FINALES

Extensiones al GPR :

(iii) Diseñar e implementar un módulo de personalización más elaborado para la edición de formas de captura (Editor de formas).

(iv) Diseñar e implementar un módulo de personalización para el formate0 de informes que considere consultas sobre más de una tabla.

(v) Diseñar e implementar un módulo adicional al GPR que permita la generación de aplicaciones portables entre varios SMBD por medio de instrucciónes de ODBC.

7.4 OTRAS OBSERVACIONES

Para darnos una idea de la eficiencia de la herramienta desarrollada, se realizaron pruebas para diferentes especificaciones de bases de datos, se obtuvieron tiempos de respuesta del generador de código, así como también se obtuvieron tiempos calculados por el Costar v. 2.02 el cual es un paquete cornputacional para estimaciones de tiempos y costos de sistemas.

' Tabla 7.1 Resultados de las pruebas deltgenerador de prototipos

Como puede apreciarse en la tabla 7.1, se ve el contraste de los tiempos que resultaron en las pruebas, en donde es importante notar que los tiempos obtenidos para la generación de prototipos son bastante cortos, y esto hace que el usuario' pueda obtener más rápido una primera versión de lo que sería el sistema real, logrando de esta manera facilitar la comunicación entre éste y el desarrollador del sistema. Incluso es muy factible que se puedan realizar refinaciones sucesivas del esquema de la BD en unos cuantos minutos posibilitando la mejora en las especificaciones de los sistemas deseados.

132

COMENTARIOS FJNALfS CAPITULO 7

Por otro lado, se pudo analizar el código generado por el generador de prototipos, y se comprobó que es un código comentado, y que es relativamente sencillo de entender. En general, se puede afirmar que el código generado presenta características muy definidas y adecuadas para que pueda ser fácilmente modificado y reutilizado.

Como se mencionó al inicio de la tesis, aunque ésta no es una herramienta para diseño, definitivamente nos da una gran ayuda para poder comparar el desempeño de distintos diseños y poder realizar una selección del mejor de ellos.

Como una observación adicional, podemos mencionar que al contar con el diseño, arquitectura y código fuente de esta herramienta CASE, nos da una gran ventaja, ya que esto serviría de apoyo didáctico para la enseñanza de Ingeniería de Software, así como tambien, por considerar que dicha herramienta puede verse computacionalmente como un compilador, sería de gran ayuda en la enseñanza de compiladores.

133

ANEXO A

ANEXO A

GRAMATICA PARA LA DEFINICION DE TABLAS

ctable definition> Función : Define una tabla base

Formato: <table definition> :: =

CREATE TABLE <table name> (<table elemenv [,<table element> ...I)

<table name> :: = <table identifier>

<table identifier> ::= <identifier>

<table elementz :: = ~ o l u m definition>

I <table constrain definition>

<colum definition> :: = <colum name> <data type>

1 <default clause>( I <column constrain> ...I

<co!um name> :: = <identifier>

<data type> :: = <character string type> < date type>

I <exact numeric t y p e I <approximate numeric type>

<character string t y p e :: = CHARACTER [(<length>)]

I CHAF¿[(<length>)]

<date type’ :: =DATE

. 134

ANEXO A

<exact numeric t y p e :: = NUMERIC [(<precision> [,<scde>l)l

I DECIMAL [(<precision> [,<scale>l)l I DEC [(<precision> [,<scd*l)1 1 INTEGER I INT I SMALLINT

<approximate numeric type> :: = SMALLFLOAT

I FLOAT [(<precision>)]

< length> :: = <unsigned integer>

<precision> :: = <unsigned integer>

<scale> :: = <unsigned integer>

<default clause> :: = DEFAULT <literal> I NULL

<colum constrain> :: =

~

NOT NULL [ <unique specification>] I <references specification>)

<unique specification> :: =

<references specification>::= REFERENCES <referenced table and columns>

<referenced table and columns> :: =

UNIQUE I PRIMARY KEY

<table name> [(reference colum list>)]

<reference colum list> :: = <colum name> [,<colun name> ...I

<table constrain definition> :: = < unique constrain definition>

I <referential constrain definition>

<unique constrain definition> :: = <unique specification, (<unique c o l u lisp)

<unique column list> :: = *alum name> [,<colum name ...I

135

ANEXO A

<referenctiai constrain definition> :: = FOREIGN KEY (<referencing coiumns>) <references specification>

<referencing columns> :: = <reference colum lisp

I36

.

ANEXO 8

ANEXO B

BLOQUES DE RUTINAS GENERADORAS Y GENERADAS

En este anexo se incluyen las principales rutinas generadoras de código, así como también, algunos fragmentos de código que se generan.

B.l RUTINAS GENERADORAS DE CODIGO

A continuación se presentan las principales rutinas generadoras de código.

B.1.1 Rutina generadora del archivo para el control de menús

PROCEDURE GenCod-ArchMovs; BEGIN

Generación del archivo 'MOVS.PAS' Generación del encabezado del archivo Genera('USES'); MIENTRAS que el nombre de la tabla sea O de " y contador < maxtablas ENTONCES

FIN Genera('WINPROCS,WiNTYPES,WOBECTS,STRíNGS,TIPOSGLl;) Linea-enB1anco Genera('C0NST) Genera(' MAXTABLA-SEL = 1 5 3 Linea-en-Blanco Genera('PR0CEDURE ALTAS(Tabla-SekNomTabla; Padre:PWindowsObject);) Genera('PR0CEDURE BAJAS(Tab1a Se1:NomTabla: Padre:PWmdowsObiect):')

Generawombre de la tabla)

Genera('PR0CEDURE Genera('PR0CEDURE Genera('PR0CEDURE Linea-enBlanco

- 111

CAMBIOS(Tabla-SeINomTabla; Padre:PWindowsObject);') CONSULTAS(Tab1a-SekNomTabla; Padre:PWmdowsObject);') REPORTES(Tabla-SekNomTabla; Padre:PWUidowsObject; Pantalla: boolean))

Genera('IMPLEMENTAT1ON') Linea en Blanco _ - GeneraCPROCEDURE ALTAS(Tabla-Se1:NomTabla; Padre:PWindowsObject);',) Generaí'BEGiN' i=O MIENTRAS que el nombre de la tabla sea 0 de '' y contador < maxtablas ENTONCES

Si i o O ENTONCES Genera('e1se') Genera('1F (STRCOMP(Tab1a-Seleccionada,"') Generawombre de la tabla) Genera("')=O) THEN); Genera(' Altas-') Generawombre de la tabla) Genera('(Tab1a-Sel,Padre)') ¡nc(iA)

FIN Genera('END;'); Linea-en-Blanco; Genera c6digo para bajas, cambios, consultas y reportes GenCod-Separador;

FIN

137

--

ANEXO B

B.1.2 Rutina generadora de las variables globales a la unidad, entre las que se encuentran las variables anfitrionas

PROCEDURE GenCod-VarHosts(Form:PTregTabla;

INICIO conx:Boolean; Normal,Doble-x,llaves,triple-x,guion:Boofe~)

Sumar=Verdadero DESDE i=l hasta total de columnas

SI llaves ENTONCES

Sumai=Falso SI la columna no es llave primaria ENTONCES

SI sumar then begin CadenaAux=FormA.Columnas[i].Nombre de la columna SI Form".Columnas[i].Tipo de la columna= 2 ENTONCES (Smallint

Enteros[ContEnterosx+l ].Campo=CadenaAux Inc(ContEnterosx)

Fin DE OTRO MODO

SI Form".Columnas[i].Tipo de la columna = 3 ENTONCES (integer EnterosLargos[ContEnterosLargosx+ l].Campo=CadenaAux Inc(ContEnterosLargosx)

Fin SI Form".Columnas[i].Tipo de la columna = 1 ENTONCES Char

FIN DE OTRO MODO

.....

SI Form".Columnas[i].Tipo de la columna = [4,5,6,7] ENTONCES (Decimal,Smallfloat,Float,Numeric) .I...

FIN DE OTRO MODO SI Form".Columnas[i].Tipo de columna = 9 ENTONCES (Date

FIN .....

t FIN if sumar ] FIN; For) DESDE ¡=I hasta ContadorEnterosx

Cadena=Enteros[i].Campo Genera(Cadena) SI guion ENTONCES Genera(-) SI c o n x ENTONCES Genera('x') DE OTRO MODO

SI doble-x ENTONCES Genera('xx') DE OTRO MODO ~~.

SI Triple-x ENTONCES Genera('xxx') SI i<ContEnterosx ENTONCES Generar,') DE OTRO MODO

Genera(' : Integer;) FIN DESDE ¡=I hasta ContCadenasx

FIN DESDE 1=1 hasta ContRealesx

.....

138

ANEXO B

<<... FIN ..... .....

FIN

~ . 1 . 3 . R u t i n a generadora del método que se encarga de llevar a cabo la eliminación de tuplas en alguna tabla.

PROCEDURE Genera-Borrados-en-Cascada(Fom : PTregTabla) VW

Buf : PTregTabla; BEGIN

i:=l; MIENTRAS Form".que~la~referencian[¡]O ' ' y ¡<=Máxima cantidad de tablas que la referencian

Cadenaaux=Form".que-la-Referencian[i]) + '.frm' Abre(cadenaaux) Si no hubo error ENTONCES

Read(Archivo,Buf);

SI Buf".que-la-Referencian[ 1 1 0 ' ' ENTONCES Genera('$ Declare Cursor ')

Genera(Cadenaaux)

Cierra(cadenaaux)

Inserta-en-Cunores(Cadenaaux3);

CadenaAux3=CadenaAux Genera('xx')

Genera(' For Select ') DESDE j:=i HASTA BuP.total de columnas en la tabla

SI es llave primaria ENTONCES CadenaAux=bufA.ColsT[].Nombre de la columna

Genera(CadenaAux) ' . FIN

FIN Genera(' From ') Cadenaaux=Buf".Nombre de [a tabla

Genera(' Where ') DESDEj:=I HASTA Buf".Total de columnas do begin

Genera(CadenaAux)

SI BufA.Colstlj].NomTabBase=FormA,nombre de la tabla ENTONCES

CadenaAux=BuP.Colst~].NombreC Genera(Cadenaaux)

Genera('=') SI Form".nombre de la tabla=Forma".Nombre de ia tabla

ENTONCES Cadenaaux=':' + Form".Nombre de la tabla + '-* +

Buf".ColsT~].colbase Genera('xx')

FIN DE OTRO MODO

Cadenaaux=':' + CadenaAux+bufA.ColsT[].colbase Genera(Cadenaaux)

139

ANEXO B

Generacx') FIN

FIN FIN Genera(' $Open ') Genera(Cadenaaux3) Genera('xx;') Genera(' Repeat') Genera(' $ Fetch ') Genera(cadenaAux3) Genera('xx Into ') DESDE j:=l HASTA Buf".total de co~umnas

SI @uf".ColsprimKeyTlj]=l) ENTONCES CadenaAux='::' + Buf6,Nombre de la tabla + '_' +

Genera(CadenaAux) Genera('xx') FIN

FIN Genera(' Genera-Borrados-en_Cascada(Buf)

BufA.ColsTlj].Nombre de la columna

If SQLCODE = O ENTONCES')

FIN SI Strcomp(BuP.que-la-Referenc¡~[ I]: ' ) O 0 ENTONCES

Genera(' End;) Genera(' Until SQLCODE O O;) Genera(' $ Close ') Genera(Cadenaaux3) Genera('xx;')

FIN Genera(' $Delete From ') cadenaaux=Buf".Nombre de la tabla

Genera(Cadenaaux) Genera(' Where ')

SI Buf".Colst~].NomTabBase=Form".nombre de la tabla ENTONCES DESDE j:=l HASTA BuP.Totalcolst

CadenaAux=BuP.Colst~].Nombre de la columna

Genera('=') SI Form".nombre de la tabla = Forma".Nombre de la tabla ENTONCES

Genera(Cadenaaux)

Cadenaaux=':' + Form".nombre de la tabla + ' * + BufA.ColsTlj].colbase Genera(CadenaAux)

-

Genera('xx') SI Continua la condicion ENTONCES Genera(' and ')

FIN DE OTRO MODO

Cadenaaux=':' + Buf".ColsT~].colbase Genera(Cadenaaux) Genera('x')

SI Continua la condicion ENTONCES Geneni(' and ') FIN

FIN SI) FIN DESDE)

FIN (Si no hubo error )

I40

ANEXO B

incrementa(¡); FIN; While)

END;

B.2 RUTINAS O BLOQUES GENERADOS

En esta sección se presentan fragmentos del código que se genera. . B.2.1 Elementos y objetos generales del sistema

1. Encabezado del programa prhcipal

’ UNIT OBJETOS; INTERFACE USES WOBJECTS,WINTYPES,WPROCS,TIPOSGLI, STRINGS,MOVS, CONSTANT

2. Archivos de recursos

$R BAR.RES $R BAR2.RES)

3. Clase de Isr aplicación

Aplicacion = OBJECT(TApp1ication)

END; PROCEDURE InitMainWmdow; VIRTUAL;

4. Clases para las cajas de diálogo

Dialogo que muestra los nombre de las tablas que participan en la BD ) PTablas = “lTablas: lTablas = OBJECT’(TDia1og)

Lista : PListBox; CONSTRUCTOR In¡t(AParent: PWindowsObject; AName: PChar); PROCEDURE LCBI(Var Msg : TMessage); VIRTUAL id-First + id-LB 1 ; PROCEDURE SetupWindow; VIRTUAL;

END;

( Dialogo para eleccion de matto del sist., informes o salir ] PDialogoEleccion = “TDialogoEleccion; TDialogoeleccion = OBJECT (TDialog)

BOTOMl ,BOTON2,BOTON3 : PBunon; PROCEDURE HANDLEBOTONI(VAR Msg : TMessage); VIRTUAL id-First + BtnMantto; PROCEDURE HANDLEBOTON2(VAR Msg : TMessage); VIRTUAL

141

ANEXOB

idFirst + BtnInfo; PROCEDURE HANDLEBOTON3(VAR Msg : TMessage); VIRTUAL id-First + BtnSalir;

END;

5 . Clase para la barra de menu

I Definicion del cuadro de dialoao para la barra de botones ) . - PDialogoBarra = "TDialogoBG; TDialogoBarra = OBJECT (TDiaiog)

BOTONl ,BOTON2,BOTON3,B0TON4,BOTON5,BOTON6 : PBunon; PROCEDURE HANDLEBOTONl(VAR Msg : TMessage); VIRTUAL id-First + Boton-1; ..... . < < < .

PROCEDURE HANDLEBOTOWó(VAR Msg : TMessage); VIRTUAL id-First + Boton-6;

END:

6. Clases para las ventanas auxiliares

Objeto para la segunda ventana principal PVentanaDatos2 = TVentanaDatos2; TVentanaDatos2 = OBJECT(TWindow)

Brocha : HBrush; CONSTRUCTOR Init(AParent:PWindowsObject; Atitle : PChar); PROCEDURE SetUpWmdow; VIRTUAL; Function GetClassName: PChar; VIRTUAL; PROCEDURE GetWindowClass(VAR AWndClass : TWndClass); VIRTUAL;

End:

7. Clase para la ventana principal

( Clase Ventana Principal PVentanaDatos = TVentanaDatos; TVentanaDatos = OBJECT(TWindow)

Brocha : HBrusb; HImage : HBitmap; CONSTRUCTOR Init(AParent:PWindowsObject; Atitle : PChar); PROCEDURE SetUpWindow; VIRTUAL; PROCEDURE GetWindowClass(VAR AWndClass : TWndClass); VIRTUAL; DESTRUCTOR Done; VIRTUAL;

End;

142

ANEXO B

8. Variables locales

VAR Aplicacionl : Aplicacion; DialogBar : PDialogoBarra; DiagEleccion: PDialogoEleccion; Ventana2 : PVentanaDatos2;

( Variable estatica que representa la aplicación ]

9. Métodos de la ventana principal

- Constructor: CONSTRUCTOR TVentanaDatos.Init(Aparent : PWmdowsObject; ATitle : Pchar);

~ Inicializador: PROCEDURE TVentanaDatos.SetUpWúidow;

- DestNCtOr: DESTRUCTOR TVentanaDatos.Done;

~ Metodos para el manejo de los botones: PROCEDURE TDialogoBana.HANDLEBOTONl(VAR Msg :

Tmessage); .... ...

PROCEDURE TDialogoBana.HANDLEBOTON6(VAR Msg : TMessage);

10. Control de cuadros de lista

CONSTRUCTOR lTablas.Init(AParent: PWindowsObject; AName: Pchar); PROCEDURE TTabPas.LCBl(Var Msg : Tmessage); PROCEDURE TLiblas.SetupWmdow;

1 1. Métodos de las ventanas auxiliares

CONSTRUCTOR TVentanaDatos2.Init(Aparent : PWindowsObject; ATitle : Pchar); PROCEDURE TVentanaDatos2.SetUpWindow; Function TVentanaDatos2.GetCIassName: PChar; PROCEDURE TVentanaDatos2.GetWindowCla~s(VAR A WndCiass:TWndClass);

143

ANEXO B

~ ~ 2 . 2 Rutina generada para realizar eliminaciones en la tabla de cubiculos

___

__ _-_-_-_== ___ ==== x --------- ( Objetivo: Este mktodo responde a la pulsación del botón eliminar (

PROCEDURE TVentanaBajasHija.lDBotonl(Var MsgTMessage); $ Begin Declare Section ALUM-CLAVExx : String[S]; End Declare Section; BEGIN

y llevar a cabo la eliminación de la tupla

CLAVEx:=CLAVE; $ Declare Cursor ALUMxx For Select CLAVE From ALUM Where CUBICULO=:CLAVEx; $ Open ALUMxx; Repeat $ Fetch ALUMxx Into :ALUM-CLAVExx; If SQLCODE = O Then begin

$ Delete From TESIS Where ALUMNO=:ALUM-CLAVExx;

End; Until SQLCODE O O;

$ Close ALUMxx; $ Delete From ALUM Where CUBICULO=:CLAVEx;

Where CLAVE=:CLAVEx ;

MessageBoxíHWindow, 'LOS DATOS FUERON ELIMINADOS CON EXITO', 'I*** MENSAJE ****',mb-OK or mb-IconExclamation)

$ Delete From CUBIC

if SQLCODE=O then

Else MessageBox(HWindow, 'LOS DATOS NO FUERON ELIMINADOS

CON EXITO','**** MENSAJE ****',mb-OK 01 mb-IconExclamation);

END;

€3.2.3 Código de ejemplo de la unidad de constantes

UNIT CONSTANT; INTERFACE CONST

Coordenadas de la ventana Principal XIP=O; Y IP=O; XZP=SOO; Y2P=600;

TamaAo de letra para las columnas TAMCOLSLETRA = 15;

Coordenadas de la Ventana Hija XICHILD= 150; YlCHILD= 18O;XZCHILD=550;

144

ANEXO 6

Espacio-Tuplas = 90;

Identificadores de los botones de la barra 1 Boton-l = 301; Boton-3 = 303; Boton-5 = 305; Boton-2 = 302; Boton-4 = 304; Boton-6 = 306; i d L b l =307;

Identificadores de los botones de eleccion BmMantto = 127; Bmlnfo = !28; BmSalir = 129;

Constantes de los reportes ) LIMITE-PAGHORiZ = 4700; LIMITE_PAGVERT = 5900;

IMPLEMENTATION END.

B.2.4 Código de ejemplo de la unidad de control de opciones e interacción con el usuario

UNIT MOVS; INTERFACE USES

CONST CUBICALUM,TESIS,WINPROCS,WINTYPES,WOBJECNGS,TIPOSGLI ;

MAXTABL.4-SEL = 15;

PROCEDURE ALTAS(Tabla-Sel:NomTabla; Padre:PWindowsObject); PROCEDURE BAJAS(Tabla-Se1:NomTabla; Padre:PWindowsObject); PROCEDURE CAMBIOS(Tab1a-SekNomTabla; PadrcPWindowsObjeet); PROCEDURE CONSULTAS(Tab1a-Se1:NomTabla; Padre:PWmdowsObject); PROCEDURE REPORTES(Tab1a-Sel:NomTabla; Padre:PWindowsObject; Pantalla: Boolean);

IMPLEMENTATION

PROCEDURE ALTAS(Tabla-Se1:NomTabla; Padre:PWindowsObject); BEGIN IF (STRCOMP(Tab1a-Sel,’CUBIC’)=O) THEN

else Altas-CUBICfTabla-Sel,Padre)

IF (STRCOMP(Tab1a-Sel.’ALUM)=O) THEN

else AltasALUM(Tab1a-Sel,Padre)

IF (STRCOMP(Tab1a-Sel,’TESIS’)=O) THEN Altas-TESIS(Tabla-Sel,Padre)

END;

I ( - = ~ - = ~ - = ~ ~ = = _ - = = = = = = ~ - -_ PROCEDURE BAJAS(Tab1a-SekNomTabla; Padre:PWindowsObject); BEGIN IF (STRCOMP(Tabia-Sel,’CUBIC‘)=o) THEN Bajas-CUBIC(Tab1a-Sel,Padre)

145

ANEXO B

else IF (STRCOMP(Taoia-Sei,’ALUM‘)=O) THEN

else BajasALUM(Tabla-Sel,Padre)

IF (STRCOMP(Tabia-Sel,’TESIS’)=O) THEN BajasTESIS(Tabla-Sel,Padre)

END;

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 PROCEDURE CAMBIOS(Tabla-Se1:NomTabla; Padre:PWindowsObject); BEGIN IF (STRCOMP(Tab1a-Sel.’CUBlC’)=O) THEN

else Cambios-CUBIC(Tabla-Sei,Padre)

IF (STRCOMP(Tab1a-Sei,’ALUM)=O) THEN

else Cambios-ALUM(Tabla-Sel,Padre)

IF (STRCOMP(Tabia-Sei,’TESISs)=O) TIPEN

END; Cambios-TESIS(Tabla-Sel,Padre)

(a=---- __ _ _ _ _ - - _ - - ~ PROCEDURE CONSULTAS(Tab1a-SekNomTabla; Padre:PWindowsObject); . BEGIN IF (STRCOMP(Tab1a-SeI’CUBlC‘)=O) THEN

else ConsultasCUBIC(Tab1a-Sel,Padre)

IF (STRCOMP(Tab1a-Sel,’ALUM)=O) THEN

else Consultas-ALUM(Tabla-Sel,Padre)

IF (STRCOMP(Tab1a-Sel,’TESIS)=O) THEN

END; Consultas_TESIS(Tabla-Sel,Padre)

1 PROCEDURE REPORTES(Tab1a-SekNomTabla; Padre:PWindowsObject; Pmta1la:Boolean); BEGIN IF (STRCOMP(Tab1a-Sel,’CUBIC’)=O) THEN Reportes-CUBIC(Tabla-Sel,Padre,Pantalla) Else IF (STRCOMP(Tab1a-Sel,’ALUM)=O) THEN Reportes-ALUM(Tab1a-SeI,Padre,Pantaila)

Else IF (STRCOMP(Tab1a-Sel,’TESIS)=O) THEN Reportes-TESIS(Tabla-SeI,Padre,Pmtalla) END;

END. (De la unidad

146

ANEXO B

B.2.5 Rutinas que controlan la creación de las ventanas de movimientos ( __________-=====_=====__=______=_===_= 1 PROCEDURE ALTASCUBIC(Tabla-Sel:NomTabla; Padre:Pw~dowsObject); BEGIN

v e n t a n ~ l m := New(PVentanaAltaj,Init(Padre,'ALTAS: CUBIC I));

Application".MakeWmdow(Ventan~ltas);

1 -_____l_----.--=l_l=il========- END;

PROCEDURE ~AJ~s-CUBIC(Tabla-Sel:NomTabla; Padre:PwimdowsObject); BEGIN

VentmaBajas := New(PVentanaBajas,lnit(Padre,'BAJAS: CUBIC '9); Application".MakeWindow(VentanaBaJaS);

END;

PROCEDURE CAMBIOS-CUBlC(Tabla-Se1:NomTabla; Padre:PwindowsObject); BEGIN

Ventanacambios := New(PVentanaCambios,Init(Padre,'CAMBIOS: CUBIC I));

Application".MakeWmdow(VentanaCambios);

) (-__-I ----===_=_ ====

END;

PROCEDURE CONSULTAS-CUBIC(Tabla-Se1:NomTabla; Padre:PwindowsObject); BEGIN

1 (-==---===-===--"---==-------------------- -

Ventanaconsultas := New(PVentanaConsultas,Init(Padre,'CONSULTAS: CUBlC ',False)); Application".MakeWindow(VentanaConsultas);

END;

PROCEDURE REPORTESCUBIC(Tab1a-Se1:NomTabla; Padre:PwindowsObject; Pantal1a:Boolean); BEGIN END;

--I ............................................

(=-==-~__=====_=__=_

B.2.6. Objetivos de cada uno de los métodos definidos para las clases

1. Métodos de la ventana principal

(=-===----- ~

. Objetivo : Este método se llama cuando se desea cenar la ventana hija o.foma, ) I FUNCTION TVentanaGeneral.CmClose : BOOLEAN; p - -- Objetivo : Este método responde a la pulsación del botón de CANCELAR ] PROCEDURE TVentanaGeneraI,IDBoton2(Var MsgTMessage); (======--=-=====_ ==== ======= ~

( Objetivo ; Este mktodo define el nombre de la Clase Function TVentanaGeneral.GetClassName: PChar; (=- ( Objetivo : Este método inicializa los atributos de la ventana PROCEDURE TVentanaGeneral.GetWindowClass(VAR A WndClass:TWndClass); (-==----- _-----___

1

1 en caso de que así sea, se envía el foco a la ventana principal

1

-

---I

)

____ ___- -_

147

ANEXO B i

2. Métodos para la ventana de altas

( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objetivo: Constnxtor e inicializador de la ventana de altas, que además incluye la especificación del estilo de la ventana y sus dimensiones, así Como 1 la creación de los controles de edición y de los botones )

( ( CONSTRUCTOR TVentanaAltas.Init(Aparent : PWindowsObject; ATitle: PChar);

( Objetivo : Este método se llama cada vez que la ventana de altas (foma) necesita )

PROCEDURE TVentanaAltas.Paint(PaintDC : HDC; var PaintInfo : TPaintSbuct);

Objetivo : Este mttodo tiene como objetivo llevar a cabo la inserción de la ] la tupla en la tabla correspondiente, así como la limpieza de los controles de edición )

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

ser redibujada /

( - - - - -=~===-~--- . - - - . - - - ) ____

( ( PROCEDURE TVentanaAPtas.Actualim; ( - - -~=~=~---p=======.====---=---

( Objetivo : Este método se encarga de la verificación de los rangos permitidos por cada campo 1 PROCEDURE TVentanaAkasVerifica-Rangos(Var Cad-aux:Str80);

I (=----- ---_______- -----..-;--==-==---

( Objetivo : Este método se encarga de verificar que la base de datos no quede inconsistente ) PROCEDURE TVentanaAltas.Verifica-Rest(Var Cad-aux:Sh.XO); !

(=----===-======-~==-==-------

( ( PROCEDURE TVentanaAllas.IDBoton 1 (Var Msg:TMessage); (==-=-=I===-==---=-=--==-------------------------------

3. Métodos para la ventana de bajas que realiza la petici6n de los campos clave

Objetivo : Este método responde a la pulsación del botón de ACEPTAR, y tiene ), como objetivo llevar a cabo la extracción del texto de cada control ) de edición así como llamar al método qie realiza la inserción del registro en la tabla

t

1 ==== =___===__==__===_=___=_______

( Objetivo: Constructor e inicializador de la ventana de bajas, que además incluye ) la especificación del estilo de la ventana y sus dimensiones, así como ]

( la creación de los controles de edición y de los botones ) CONSTRUCTOR TVentanaBajas.Init(AParent: PWindowsObject; ATitle: Pchar);

-1 (====- - _ _ = _ _ _ _ ~ ~ - - - Objetivo : Este método se llama cada vez que la ventana principal de bajas necesita ) ser redibujada PROCEDURE TVentanaBajas.Paint(PaintDC : HDC; var Painthfo : TPaintSbuct); (==-==_==_ =========__ ( Objetivo : Este método se llama cada vez que oprime el botón de Aceptar ) PROCEDURE TVentanaBajas.CreaVenmahija;

) (======_-=_===_=_==____= ___ ( Objetivo : Este método responde a la pulsación del botón de ACEPTAR, y tiene ) ( ( PROCEDURE TVentanaBajas.IDBotonl(Var Msg:TMessage); _=_===___====__=_===_-____-

___ ~ ----I en la ventana principal de bajas )

como objetivo llevar a cabo la extracción del texto de cada control ] de edición as1 como desplegar la ventana que muestra los datos que se desean eliminar

I

148

ANEXO B

d

4. Métodos para la ventana de bajas que muestra los datos que se desean eliminar

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

=- ==_____ __ ____ ______-_ --___-=-?& 1

-=--------------- __-__--== )

Objetivo: Constructor e inicializador de la ventana de bajas hija, que ademhs incluye )

la especificación del estilo de la ventana y sus dimensiones, as1 como ) la creación de los botones

CONSTRUCTOR TVentanaBajasHija.In¡~(AParent: PWindowsObject; ATitle: Pchar);

( Objctivo : Este mfiodo se llama cada vez que la ventana de bajas hija (forma) necesita ser redibujada ) PROCEDURE TVentanaBajasHija.Paint(PaintDC : HDC; v a PaintInfo : TPaintStmct);

Objetivo: Este método responde a la pulsación del botón de eliminar ] y lleva a cabo la eliminación de la tupla ) PROCEDURE TVentanaBajasHija.IDBoton1 (Var Msg:TMessage); =========== -_--=2=-

5 . Métodos para ia ventana de cambios en donde se muestran y editan los campos que se desean modificar

-===I

Objetivo: Este método es llamado desde la ventana principal de cambios y tiene PROCEDURE TVentanaCambios.CreaVentanaHija; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objetivo: Este método es llamado desde la ventana principal de cambios y tiene ) PROCEDURE TVentanaCambiosHija.Actualiza; 1 Objetivo: Constructor e inicializadar de la ventana hija de cambios, que además incluye ) la especificación del estilo de la ventana y sus dimensiones, así como I CONSTRUCTOR TVentanaCambiosHija.Init(Aparent : PWindowsObject; ATitle: PChar); -==--------------------- ~ = = Objetivo : Este método se llama cada vez que la ventana de cambios hija (forma) necesita f ser redibujada ) PROCEDURE TVentanaCambiosHija.Paint(PaintDC : HDC; var PaintInfo : TPaintStruct); ==-===-==-======--==----- --____5__

-3 Objetivo : Este método responde a la pulsación del boton de ACEPTAR: y tiene ) PROCEDURE TVentanaCambiosHija.IDBoton I (Var Msg:TMessage);

la fmalidad de crear la ventana hija de cambios en donde se muestran los datos .

) .~

la finalidad de actualizar los cambios realizados a los datos )

~

la creación de los controles de edición y de los botones 1

-----

como objetivo llevar a cabo la extracción del texto de cada control ) de edición as1 como la llamada al método que actualiza el registro en la tabla )

6. Método para el objeto Colección que almacena los datos que resultan de una consulta

I

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

Método de inicialización de la colección que:guarda las tuplas CONSTRUCTOR TColeccion.lnit;

149

. - - .-

ANEXO B

7. Métodos para la ventana de consultas en donde se muestran los datos en pantalla

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

==== __==-_==__=___======_==__=__=_ -================)

Objetivo : Este método es el conshuctor de la ventana de consultas ) CONSTRUCTOR TVentanaConsultas.Init(Aparent : PWindowsObject; ATitle: PChar; Repor:Boolean);

( Objetivo : Este método se llama cada vez qiie la ventana de consultas necesita ( ser redibujada PROCEDURE TVentanaConsultas.Paint(PaintDC : HDC; var Paintlnfo : TPaintShuct); I ~~I ( Objetivo : Este método se encarga de escribir en pantalla los datos que resultan de una consulta ]

.PROCEDURE Escribe(Co1ec : PColeccion); Far; END. ( De la unidad )

I

ANEXO c

ANEXO C

CONCEPTOS BASICOS DE LA PROGRAMACION ORIENTADA A OBJETOS Y TECNICAS DE ANALISIS Y DISENO ESTRUCTURADO

C.l INTRODUCCION

La programación con Turbo Pascal para Windows requiere una firme comprensión de los conceptos y técnicas básicos de la programación orientada a objetos (POO). La PO0 es un nuevo enfoque de programación que se basa en las ideas de la programación estructurada tradicional, para cuya enseñanza se desarrolló Pascal. Dado que muchas personas no están familiarizadas con la POO, en esta sección se dan algunos conceptos básicos que serían importantes conocer para tener una idea más precisa de algunos detalles de programación que se muestran en algunos capítulos de la tesis.

En los modelos de programación procedimental, estructurado y modular, se identifican dos partes importantes del programa: el código fuente y los datos del programa. Ambos se han considerado siempre entidades separadas que se tratan de manera diferente. Se escribe el código y luego se definen las variables de datos en forma separada.

En la programación orientada a objetos, los datos se declaran como parte del código. El código lleva a cabo entonces operaciones sobre estos datos. Con los programas orientados a objetos, íos datos y el código se convierten en una sola cosa: Objeto = Código + Datos.

La clave decisiva de la programación orientada a objetos es la capacidad de simplificar los tareas de programación. Entre los beneficios principales se incluyen los siguientes:

Simplificación. Diseñar un programa resulta más fácil, dado que los objetos corresponden más estrechamente con las entidades del mundo real. Con la estrecha asociación de códigos y datos, la tecnología orientada a objetos facilita la programación.

Reutilización. Dado que los objetos están tan estrechamente relacionados con los datos sobre los que operan, es posible reutilizar antiguos objetos en programas nuevos. El resultado es un ahorro tanto de tiempo como de dinero.

151

ANEXO C

e Reparabilidad. Al poner al día los programas basados en tecnología orientada a objetos, los objetos aislan las funciones del programa unas de otras; de esta forma, la modificación de una de las funciones no supondrá el cambio del programa en ningún otro sitio. Los objetos enteros pueden ser modificados sin reescribir el resto del programa.

La PO0 introduce varios conceptos nuevos [PAL94]:

e Objetos : Los objetos son similares a los registros, pero contienen sus propios procedimientos y funciones que (en un objeto) se denominan métodos.

Tipos de objetos : Definen un tipo de objeto en particular, junto con sus características.

Encapsulución : Fusiona en una estructura de datos los procedimientos y funciones junto con los datos que procesa. La encapsulación permite incluir todos los procedimientos y funciones necesarios para manipular los datos dentro del propio objeto; esto es debido a que crea una “cápsula’’ para el objeto herméticamente sellada, que incluye todos los campos de datos y métodos que éste necesita.

e

Para declarar un tipo objeto, simplemente se utiliza la palabra reservada de Turbo Pascal object y se proporciona la lista de campos y métodos del mismo modo que en la declaración de un registro estándar:

SPe registroestudiante = OBJECT

Nombre, apellido : string[ 1 SI; promedio : real; PROCEDURE Inicialización; PROCEDURE Llenarregistro; PROCEDURE EnviarDiploma; PROCEDURE MostrarNombreypromedio;

END;

En la definición del tipo todos los campos de datos deben aparecer antes que los mitodos, como es el ejemplo anterior.

Claro está que este tipo de declaración no crea un objeto, del mismo modo que la declaración de un registro no crea ningún registro. Para crear un objeto,

152

ANEXO C

debe declararse una variable con el tip0 del objeto; Por ejemplo, Var

estudiante : registroestudiante;

Mensajes : Son instrucciones que se envían a 10s objetos Y que les indican We lleven a cabo los métodos que forman parte de ellos.

Herencia : Significa que las características de un objeto pueden trasladarse a 10 largo de sus objetos descendientes.

Cuando se definen objetos, se emplean términos similares a aquellos que se utilizan para describir la herencia en los animales. Cualquier objeto que hereda los rasgos de un ancestro tiene rasgos similares a ese ancestro. En general, se utiliza un árbol de jerarquía de objetos para mostrar la relación entre objetos. ,El árbol se recorre de arriba a abajo y va de lo general a :o específico.

Polimorfismo : La capacidad de dar a una acción un nombre que es compartido por varios objetos diferentes relacionados se conoce como polimorfismo. La palabra polimorfismo viene de una palabra griega que quiere decir “muchas formas”. Cuando se programa es Pascal, este concepto adquiere muchas y variadas ventajas. Por ejemplo, la función Writeln(Argument0); no se preocupa de cómo se declara el tipo de variable Argumento. El tipo puede ser un entero, un real Ó una cadena, y la función Writeln responde automáticamente de forma apropiada.

Extensibilidad de cbdigo : Esta propiedad permite utilizar las unidades ya compiladas para crear y emplear nuevos objetos, los cuales eran desconocidos en el momento en que éstas fueron compiladas.

.

Métodos estáticos y virtuales : Los métodos pueden ser de dos tipos: estáticos y virtuales. Son estáticos aquellos a los que el cornpilador les asigna memoria y resuelve todas las referencias a ellos en el tiempo de compilación. Las llamadas estáticas se denominan vinculación anterior. Todos los métodos son estáticos por defecto.

Cuando se llama a un método virtual, la llamada real se hace en tiempo de ejecución. Una llamada de esta forma se denomina vinculación posterior. Y1 compilador construye una llamada indirecta a la dirección almacenada en una posición de memoria dada. La dirección real a la que se llama no se conoce hasta el tiempo de ejecución.

153

, ANEXO C

La razón de la utilización de métodos virtuales eS que cuando un objeto hereda rasgos de un objeto previo, el compilador no siempre sabe a que métodos llamar en tiempo de compilación. Por consiguiente, esta decisión debe tomarse en tiempo de ejecución.

Los métodos pueden ser redefinidos en cualquier nivel de la jerarquía de objeto. Un método se hace virtual siguiendo la declaración con la palabra reservada virtual. Todos los métodos con el mismo nombre deben también ser declarados virtuales para evitar un error del compilador.

I

C.2 UTILIZACION DE OBJECTWINDOWS

La libreria Objectwindows es como un marco de aplicaciones, que proporciona una interface de usuario completa para un programa. No obstante, ObjectWindows no es sólo una librería de rutinas a la que puede llamar el programa. El programa puede construirse en tomo a ella PER931.

Se accede a la libreria Objectwindows definiendo la unidad Wobjects en la \

cláusula uses del programa.

Dado que los programas Objectwindows son en realidad híbridos ( es decir, contienen programación orientada a objetos, asi como llamadas al AB1 de Windows), en la mayoría de los casos los programas Objectwindows deben utilizar también las unidades WinProcs y WinTypes. El resultado es una cláusula que tiene esta apariencia: uses Wobject, WinProcs, WinTypes.

Cuando se utiliza la librería Objectwindows, se deben crear dos objetos. La ventana principal que se crea para una aplicación de ventana se llama objeto ventana. Este objeto pertenece al objeto de aplicación. El objeto de aplicación sirve

' para crear y mostrar la ventana principal, procesar los mensajes de ventana y terminar la aplicación.

Un programa mínimo de librería Objectwindows utiliza el objeto ventana tal y como se define en la unidad Wobjects, esto da como resultado la típica ventana básica en cascada de un programa Windows. A continuación se muestra un programa mínimo que crea la ventana.

Program MinOwl; uses Wobjects;

154

ANEXO C -

V X Window : Tapplication;

Begin Window.Init(‘MinOw1’); Window.Run; Window.Done;

End.

Siempre se utilizan tres métodos en el cuerpo principal de WI programa construido mediante la librería ObjectWindows; Inif, Run y Done. Init se conoce como un constructor, y crea el nuevo objeto de aplicación, abre la ventana principal y especifica el nombre del objeto ‘MinOwB’. Run ejecuta el programa Windows y procesa los mensajes Windows. Done es el destructor que cierra el programa.

Se mencionaron dos nuevos términos. Un constructor es el procedimiento que efectúa el trabajo necesario para la operación de otros métodos. Los métodos virtuales siempre deben tener un constructor. EI constructor ayuda a inicializar la memoria e instala ciertas variables.

Un destructor desasigna la memoria y termina cualquier tarea propia de un objeto. Generalmente el destructor es también responsable de cerrar una aplicación y de libererse de cualquier otro proceso. I

c . 3 TECNICAS DE ANALISIS Y DISENO ESTRUCTURADO

En esta sección se describen alanas de las técnicas de análisis y diseño estructurado que soportan las herramientas CASE tradicionales, y varias de ellas aparecen entre las técnicas y metodologías soportadas por algunas de las herramientas comerciales que se describieron en el Capítulo 1, dentro de lo que corresponde al estado del arte.

Diagramas de flujo de datos @FD)

Con la aparición de las técnicas estructuradas de análisis, llegó una revolución en el desarrollo de sistemas. Los diagramas de flujo de datos se encuentran entre estas técnicas, y es el método más extendido en modelado conceptual de procesos. esta técnica, que también es conocida por sus siglas, DFD, o por diagramas de burbujas (Bubble Diagrams), fue propuesta por Yourdon a finales de los años setenta.

IS5

ANEXO C

El objetivo fundamental de esta r6cnica es la descomposición de un problema complejo en otros más sencillos y manejables, facilitando la modularidad del sistema, ,así como aprovechar la comunicabilidad a través de modelos gráficos. Pretende, además, separar la estructura física del sistema de la lógica, aumentando la facilidad de mantenimiento de los análisis. Los DFD constan de muy POCOS elementos, y además son fáciles de aprender [PIA95].

Modelo EntidadRelaci6n

El modelo entidadrelación (MER) es una de las técnicas m h populares y utilizadas dentro del mundo del diseño de aplicaciones, concretamente, en las bases de datos. Puede incluso ser una técnica utilizada por personas poco involucradas en el mundo de la informática, y según algunos critico's, hasta bastante exitosa, debido a que es una técnica gráfica.

El MER tiene uno de sus componentes en el diagrama de entidadírelación (DFYR), que se atribuye básicamente a Peter Chen, en los comienzos de los años setenta. Pero desde entonces han aparecido muchas variantes y extensiones. Hoy día, y en las metodologías más modernas, los diagramas de entidadírelación se utilizan como una base para el desarrollo de modelos de datos; estas variantes (como MER) Extendido) destacan en muchas metodologías. No por ello, el MER deja de ser una de las técnicas más difundidas y populares entre los analistas e ingenieros de sofware.

En un MER se pueden identificar los siguientes conceptos: entidad relación (asociación), cardinalidad, atributos, ocurrencia, identificador, tipos de datos y, dependiendo del nivel de desarrollo de los modelos, se utilizarán otros conceptos que enlazarán directamente con la técnica de diseño de bases de datos (con elementos como subtipos, supertipos, opcionalidad, dominios, etc.) [PIA95].

Modelo Niam

El método de andisis de la información NIAM (Nijssen Information Analysis Methodology) fue desarrollado por el doctor G . M. Nijssen y reconocido por IS0 (International Standard Organisation) en 1982.

NIAM permite obtener, a partir de un conjunto de conceptos simples, un diagrama conceptual basado en relaciones binarias y en un conjunto de restricciones definidas sobre éstas. En dicho diagrama se representan todas las frases elementales que permiten la descripción del universo del discurso dado [PIA95].

156

ANEXO C

Diagrama de Jackson

La metodología Jackson desciende directamente de la programación estructurada que surgió a finales de la década de 1960 y principio de los años setenta. En 1975 fue publicada en el libro Principles of Program Design, y SU utilización se difundió ampliamente, favorecida principalmente por la elegancia, eficiencia y corrección de la técnica.

El método de Jackson se basa en el principio de que el punto inicial del diseño del programa son los datos del problema y no los requisitos funcionales exigidos.

Esta forma de enfocar el desarrollo de software está basada en los datos, ya que los datos del problema son los únicos elementos de las especificaciones que tienen una estructura objetiva y que pueden ser usados como una base lógica y racional para la estructura del programa, evitando utilizar una descomposición funcional que tiene un alto grado de juicios subjetivos o bien un desarrollo mediante organigramas que aportan una visión un poco clara de la estructura completa [PIA95].

Diagramas de Estructura (Structure Charts)

La programación estructurada fue la primera técnica que contempló la complejidad de los sistemas modernos. La técnica sugerida por la programación estructurada para ser una progresión desde la visión general hasta el detalle, se conoce como diseño top-down. Desafortunadamente, a la hora de realizar esta partición únicamente presenta unas cuantas guías. El diseño estructurado expone las guías de las que carece el diseño top-down. A medida que la programación estructurada ganaba en aceptación, se iban cristalizando las ideas del diseño estructurado. Todos los conceptos del diseño top-down permanecen en el diseño estructurado pero se afiadieron otros principios para que se pudiera obtener una mayor visión de los sistemas.

La principal herramienta usada en diseño estructurado para representar la estructura de un sistema es el diagrama de estructura [PIA95].

Matrices

Gracias a los sistemas de información y a la utilización de metodologías a la hora de desarrollar software, especialmente la metodologia estándar inglesa SSADM (Structured Systems Analysis and Design Method), han surgido una serie de técnicas, denominadas generalmente matrices, que ayudan principalmente a realizar

157

ANEXO C

la verificación y validación entre el mundo de los datos y el de los procesos (matriz evento/entidad); así mismo, estas técnicas sirven para que se realicen con éxito otras (matriz entidadlentidad en la realización del modelo de datos entidad-realación), y para comprender mucho mejor el sistema en estudio (matriz papel del usuariolfunción). Un punto de interés es que este tipo de técnicas puede realizarse y aplicarse sobre cualquier clase de actividad que se realice a lo largo del ciclo de vida del software [PIA95].

Diagramas de Warnier-Orr

La metodología de Wamier-Orr se desarrolló en Francia, y se materializó en un libro publicado en dos tomos bajo el título de Programación lógica. Plantea la programación lógica, más que como un método, como una forma de razonar, tratando de evitar los problemas que surgieron durante la fase de introducción de la programación estructurada en los años setenta, cuando todavía no existía una forma organizada para diseñar o piantear la estructura global de los programas.

La premisa básica de la metodología de Warnier-Orr es que la forma o estructura de los datos a procesar determinará la forma o estructura del programa. Uno de los principios en los que se basa es que todo conjunto de información debe subdfvidirse en conjuntos.

El diagrama de Warnier-Orr realiza esta función de subdivisión con la especificación adicional del numero de ocurrencias de los elementos de datos. El diagrama de Warnier-Orr es una representación gráfica que permite mostrar la estructura lógica de los archivos entrada y salida, así como la del programa [PIA9S].

Diagrama de Transición de Estados

El diagrama de transición de estados (DT) es una técnica de modelado que se basa en el comportamiento dependiente del tiempo de uti sistema. Normalmente se utiliza para representar el comportamiento de sistemas del tiempo real, donde el software debe responder a sucesos del mundo real en un tiempo muy limitado. El estándar IEEEíSTD 610 (1990) lo define como un diagrama que representa los estados que puede tomar un componente o un sistemas y muestra los eventos o circunstancias que implican el cambio de un estado a otro [PIA95].

Teoria de la Normalización

La teoría de la normalización es una técnica bastante difundida en las metodologías de desarrollo de sistemas de información que suele emplearse tanto en

158

ANEXO C

el aspecto conceptual (por ejemplo, analizando esquemas ER) como en el lógico (en el diseño de bases de datos relacionales, o incluso de registros (registro, entidad, relación, etc.) de algún lenguaje de programación, como COBOL).

Esta técnica ayuda a los diseñadores a prevenir problemas de redundancia y anomalías de modificación, inserción o borrado en los esquemas de datos, aunque a costa de penalizar su recuperación. De hecho, esta técnica consiste en ir descomponiendo los registros en otros de menor tamaño (con un menor número de campos), de forma que satisfagan una serie de restricciones específicas, que definen lo que se conoce porforma normal [PIA95].

159

[BOE86]

[DAV88]

[GRA89]

[INT89]

[KEN911

[LAU88]

[LIV90]

[MIR87]

[MIS901

[OMA90]

BIBLIOGRAFIA

BOEHM, BARRY W. [et. al]. “Understanding and Controlling Software Costs”. En: IEEE Transactions on Software Engineering, 14:10, Octubre 1988, pp. 1462 - 1477.

DAVIS, ALAN M. [et. al]. “A Strategy for Comparing Alternative Software Development Life Cycle Models”. En: IEEE Transactions on Software Engineering, 14:10, Octubre 1988, pp. 1453 - 1460.

GRAHAM, D. R. “Incremental development: review of nonmonolithic life-cycle development models”. En: Information and Software Technology, 31:1, EneroíFebrero 1989, pp. 7 - 20.

ISO/IEC. “International Standard. Information processing systems - Database Language SQL with integrity enhancement”, c1989.

KENDALE, KENNETH E. [Y] JULIE E. KENDALL. “Análisis y Diseño de Sistemas”. México: Prentice-Hall, ~1991 . pp. 251 - 279.

LAUDON, KENNETH C. [Y] JANE P. LAUDON, “Managment Information Systems, Organization and Technology”, Editorial Awad, 3a Edición, c1988, pp. 388 - 395.

LIVAFü, J. “ Hierarchical spiral model for information system and software development. Part 2: design process”. En: Information and Software Technology, 32:7, Septiembre 1990, pp. 450 - 458.

MIRANDA SILVA, STELLA. “Perspectivas de la Automatización de proceso de desarrollo de Software” Cuernavaca, Mor.: Instituto Tecnológico de Estudios Superiores de Monterrey, 1987. pp. 9 - 46. (Tesis de Maestría).

MISRA S.K. “Analysing CASE sysem characteristics: evaluative fiamework”. En: Information and Software Technology, 32:6, Julio/Agosto 1990, pp. 415 - 422.

OMAN, PAUL W. “CASE Analysis and Design Tools”. En: IEEE Software, Mayo 1990, pp. 37 - 43.

160

[PAL941 PALMER, SCOTT D. “Introducción a TURBO PASCAL para Windows”, México: Megabyte, c1994, pp. 55 - 87.

[PER931 PERRY, PAUL. “La Biblia de Turbo Pascal para Windows”. Guía completa de programación en Pascal para el entorno Windows”, México: Anaya Multimedia America, c1993, pp. 199 - 226.

PIATTINI, MARIO G. [Y] SUNIL N. DARYANANI. “Elementos y Herramientas en e1 desarrollo de Sistemas de Información. Una visión actual de la tecnología CASE”, Madrid, España: Addison-Wesley Iberoamericana, c1995.

[PIA951

[RAJ96] RAJAN, SUNDAR. “Create Small Workgroup Apps - Without Programming”. En: DATABASED ADVISOR, Julio 1996, pp. 15 - 17.

mc1 TECHNOLOGY TRAINING S.A. “ Introducción a las herramientas CASE”.

161

CiÚudia 3L I6arra Pad?& nació e l 30 de enero dé 1971, en Cd Mdero, lamaufipas, es hqa del ing. PascuaC í6ana Fíbres (t) y dé [a sr. Xortencia Papadiná Oam'os. @a&Ó sw es tdws deprimaria en [a Escueh FedéracL<zzaro Cárdenas de 197'6 a 1982, en ese mimo año ingresó a [a Escueh Sec. Fed Nata L?@dondz, dondé red% sw estdios dé secundaria de 1982 a 1985. Posteriormente cursó sus es tdws de preparatoria de 1985 a 1988 en [a Escueh Preparatoria Fed Fco. Medrna C e d h en Tanpico, lamaukpas. Lhó a ca6o sus estdios de Licenciatura en elinstituto lecnoúígico dé @d Madero de 1988 a 1993 donde o h v o ectítuíb dé Ingenkero en Sistemas Computaciomh, y de 1993 a 1996 cursó sus estudios de Maestná en C'iencias & [a Computación en e[ Centro Facional dé ínvestgación y Desarronó TecnolOgico. Tanto en sus es tdws de Licenciatura como de maestná o6tuvo ano de hs nmqores pnomedws a5 su generación, gctualmente reside en [a Cd de Cuernavaca, Mor. y su domicilio permanente es ve. Lázaro Cárdenas No. 116, Co l Linda V i t a , Mata @&daj Veracruz, ~ p h . postal #243, lampico, lamaufipas.

162

CENTRO DE INFORMACION

CE N I Li E T

m

Documents

Y DESARROLLO TECNOLOGICO cenidet. Claudia... · s.e.p. s.e.i.t. d.g.i.t. centro nacional de investigacion y desarrollo tecnologico cenidet. “generador automatic0 de codigo para