MC Carlos De La Cruz Sosa 2000

Transcripción

S.E.I.T.
S.E.P
DGIT
CENTRO NACIONAL DE INVESTIGACI~NY
DESARROLLO TECNOL~GICO
cenidef
DESARROLLO DE UN LENGUAJE VISUAL PARA CONSTRUIR
INTERFACES AL USUARIO DE AMBIENTES INTEGRADOS DE
ADMINISTRACIÓN DE SOFTWARE
T ES1 S
\
QUE PARA OBTENER EL GRADO DE MAESTRO EN
CIENCIAS EN CIENCIAS COMPUTACIONALES.
PRESENTA
CARLOS DE LA CRUZ SOSA
ASESOR
M.C. MAXIM0 L6PEZ SANCHEZ
Cuernavaca, Morelos
30 de agosto del 2000
Centro Nacional de Investigación y Desarrollo Tecnológico
FORMA C3
REVISION DE TESIS
Cuernavaca, Morelos a 21 de agosto del 2000
M.C. Raúl Pinto Elias
Presidente de la Academia de Ciencias Computacionales
Presente
Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de
Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis
denominada: DESARROLLO DE UN LENGUAJE VISUAL PARA CONSTRUIR INTERFACES
AL USUARIO" DE AMBIENTES INTEGRADOS DE ADMINISTRACI~N DE SOFTWARE
realizada por la C. Carlos De La Cruz Sosa, 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.
..
.
Sin otro particular, quedamos de usted.
Atentamente
M
-.
~
-
-
La comisión de revisión de tesis
kj-j/
r u,.
- .
erto Hemández García
I,
I,,
M.C. Hugo Estrada Esquive1
C.C.P.
Dr. Javier Oríiz HernándezlJefe del Departamento de Ciencias Computacionales
INTERIOR INTERNADO PALMlRA SIN. CUERNAVACA. M O R . MEXICO
APARTADO POSTAL 5-164 C P 62050. CUERNAVACA.
TELS. 173112 2314.12 7613.18 7741. FAX (73) 12 2434
cenidef
Centro Nacional de Investigación y Desarrollo Tecnológico
FORMA C4
AUTORIZACION DE IMPRESIÓN DE TESIS
Cuernavaca, Morelos a 24 de agosto del 2000
C. Carlos de la Cruz Sosa
Candidato al grado de Maestro en Ciencias
en Ciencias Computacionales
Presente
Después de haber atendido las indicaciones sugeridas por la Comisión ,Revisora de la
Academia de Ciencias Computacionales en relación a su trabajo de tesis: DESARROLLO DE
UN LENGUAJE VISUAL PARA CONSTRUIR INTERFACES AL USUARIO .DE AMBIENTES
INTEGRADOS DE ADMINISTRACIÓN DE SOFTWARE, me es grato comunicarle, que
conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias
en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.
Jefe del D e p t @ e Ciencias Computacionales
/
INTERIOR INTERNADO PALMIRA SIN, CUERNAVACA. M O R . MCXICO
APARTADO POSTAL 5-164 C P 62050. CUERNAVACA.
iELS. (73112 2314.12 7613 .18 7741. FAX 173) 12 2434
cenidef
Tesis:
-
“Desarrollo de un lenguaje visual para construir interfaces al usuario de
ambientes integrados de administración de software"
Director de tesis:
M.C. Máximo López Sánchez.
Profesor-Investigador del programa de maestría en ciencias computacionales del
Centro Nacional de Investigación y Desarrollo tecnológico.
(CEN I D E T )
interior internado Palmira s/n
Apdo. Postal 475
Cuemavaca, Morelos; México
Tesista:
L.1. Carlos De La Cruz Sosa
Centro Nacional de investigación y Desarrollo Tecnológico
(C E N I D E T)
e-mail: [email protected]
Tel: (01-5)590-2746
Agradecimientos
Especialmente agradezco a mi asesor Máximo López Sánchez, por tenerme paciencia y animarme
a culminar este trabajo de tesis, pero principalmente por sus consejos, asesorías, conocimientos
transmitidos y por su amistad.
A Humberto Hemández Garcia, Mario Guillén Rodriguez y Hugo Estrada Esquive1 por el apoyo,
tiempo y consejos brindados en la revisión de la tesis.
A Olivia Fragoso Dim y René Santaolaya Salgado por sus consejos, comprensión y apoyo en el
desarrollo y culminación de la tesis. Gracias por su amistad.
A mi familia porque sin su apoyo y cariño no hubiera sido posible realizar mis estudios de
maestría.
AI Centro Nacional de Investigación y Desarrollo Tecnológico como casa formadora de mis
estudios y por haberme permitido lograr un objetivo más en mi vida profesional.
Al Consejo Nacional de Ciencia Y Tecnología (CONACYT) y a la Secretaría de Educación
Pública (SEP) por las becas académicas otorgadas a través de la Dirección General de Institutos
Tecnológicos (DGIT).
Al grupo de Ingenieria de Software por todos los momentos que compartimos juntos.
A todos m i s maestros por todo sus conocimientos y experiencias que compartieron conmigo.
A todos mis compañeros de generación por haber compartido sus experiencias conmigo.
A todos ustedes Gracias
A Xochitl y Carlos
Mis padres, con mucho cariño por darme amor, apoyo y
sobretodo por enseñarme a ser persistente hasta lograr lo
que uno quiere.
Los quiero mucho
A Verónica, Juan, Xochitl y Oscar
Mis hermanos, por todo su amor y por los momentos que
compartimos juntos.
A Susy
Mi amor, a ti por todo tu amor y comprensión. Gracias por
estar a mi lado en todo momento y por compartir tu vida
conmigo.
Te Amo.
CONTENIDO
Lista de figuras........................................................ ;...................................................................
Lista de tablas.. ............................................................................................................................
INTRODUCCI~N
...........................................
.
..........:.........................................................
;
...
111
iv
Capitulo 1 PLA"llM&lIENTO DEL PROBLEMA..............................................
1
....
2
1.1. Descnpcion del problema.....................................................................................................
.
.
1.2. objetivo general....................................................................................................... 1............ 4
. .
1.2.1. Objetivos específicos..................................................................................................
4
1.3. Beneficios.............................................................................................................................
..
1.4. Solucion propuesta...............................................................................................................
1.4.1. Hipótesis de trabajo....................................................................................................
1.5. Alcances................................................................................................................................
5
6
6
Capitulo 2 MARCO TEOFUCO.....................................................................................
7
2.1. Interfaces al Usuario (IU) .....................................................................................................
2.1.1. Ciclo de vida ...............................................................................................................
2.1.2. Elementos...................................................................................................................
..
2.1.3. .Principiosde diseño....................................................................................................
.. ..............................................................................................................
2.1.4. Clasificacion
2.2. Ambientes integrados..........................................................................................................
. . ...........................................................................................................................
2.3. Gramaticas
2.3.1. Jerarquía de Chomsky................................................................................................
. . al..................................................................................................
. . posicion
2.3.2. Gramatica
. .Visual
. (LPV).................................................................................................
2.4. Programacion
2.4.1. Importancia del uso de iconos....................................................................................
2.42. ¿Qué es Programación Visual?...................................................................................
2.5. Estado del arte.......................................................................................................................
2.6. Análisis del estado del arte...................................................................................................
8
9
10
.
.
5
11
11
12
14
14
14
17
17
18
20
23
Capitulo 3 DESCRIPCION DE LA GRAMATICA DEL GENVIU................. 25
3.1. Notación usada en la definición de la gramática..................................................................
3.2. Análisis de la gramática........................................................................................................
3.2.1. Elementos que definen la forma de las interfaces al usuario.....................................
3.2.2: Elementos que definen la secuencia de eventos de las interfaces al usuario ............
. . ....................................................................................................
3.3. Definición de la gramatica
3.3.1. Símbolos gramaticales................................................................................................
3.3.1.1. Símbolos No Terminales................................................................................
3.3.1.2. Símbolos Terminales.....................................................................................
...
3.3.1.3. Símbolo inicial..............................................................................................
3.3.1.4. Relaciones cuádruples de los símbolos terminales.................. .....................
!I
It
26
26
27
28
28
29
29
29
30
30
..
3.3.2. Reglas de produccion..................................................................................................
3.3.3. Atributos de los símbolos terminales gráficos............................................................
3.3.3.1. Atributos de los símbolos que definen la forma de las interfaces al usuario .
3.3.3.1.1. Atributos del simbolo menú..........................................................
3.3.3.2. Atributos de los simbolos que definen la secuencia de eventos de las
interfaces al u s d o.......................................................................................
.
31
33
34
35
35
Capitulo 4 AMBIENTE DE DESARROLLO DEL GENVIU.............................
37
4.1. Arquitectura del GenVIU ......................................................................................................
4.1.1. GUI: Interfaz Gráfica de Usuario...............................................................................
4.1.2. Editor IU:Editor de la forma de una IU .....................................................................
4.1.3. Editor SE: Editor de la secuencia de eventos de una IU.............................................
4.1.4. Precompilador del GenVIU ........................................................................................
4.1.5. Generador de código del GenVIU ..............................................................................
4.2. Estructuras de datos que maneja el GenVIU ..................................
.....................................
4.2.1. Estructuras de datos que maneja el editor de la forma de una'IU...............................
4.2.2. Estructuras de datos que maneja el editor de la secuencia de eventos de una IU .......
4.3. Jerarquía de clases utilizadas en el GenVIU .........................................................................
4.3.1. Clase TGenVIUApp: Crea y controla el ambiente GenVIU ......................................
4.3.2. Clase Micontrol: Crea y maneja un control (recurso grafico)...................................
4.3.3. Clase EditorIU: Crea y'controla el editor.de interfaces al usuario.............................
4.3.4. Clase EditorSE: Crea y controla el editor de secuencias de eventos de la IU
disefiada.......................................................................................................................
4.3.5. Clase VentanaMsg: Crea una ventba para visualizar los mensajes de error.............
38
39
40
41
42
43
43
44
51
53
55
59
61
~
.
64
67
Capitulo 5 PLAN DE PRUEBAS EXPERIMENTALES................... :.................. 69
. .
5.1. Objetivo................................................................................................................................
5.2. Resultado esperado...............................................................................................................
5.3. Resultado real ........................................................................................................................
5.4. Casos de prueba.......................................................................................
............................
5.4.1. Caso de prueba 1: IU del Ambiente Integrado de Soporte para la Administración y
desarrollo de Sistemas de Software (AMASS)...........................................................
. .
5.4.1.1 Objetivo..........................................................................................................
5.4.1.2. Resultados esperados....................................................................................
5.4.1.3. Resultados obtenidos......................................................................................
5.4.1.4 Elementos que definen la forma de la interfaz del ambiente.........................
5.4.1.5. Transiciones que definen la secuencia de eventos de la interfaz...................
..
5.4.1.6. Proceso de construccion................................................................................
5.4.1.7. Código del diseño especificado e IU producida por el código......................
5.4.2. Caso de prueba 2: IU que agrupa a cinco herramientas con el mismo formato de
datos............................................................................................................................
5.4.2.1 Objetivo....................................................... :..................................................
5.4.2.2. Resultados esperados....................................................................................
. .
5.4.2.3. Resultados obtenidos.....................................................................................
70
70
70
70
71
71
71
71
71
72
72
77
80
81
81
81
5.4.2.4 Elementos que definen la forma de la interfaz del caso 2 .............................
.. ................................................................................
5.4.2.6. Proceso de cynstruccion
S.4.2.7. Código del diseño especificado e IU producida por el código......................
5.4.3. Caso de prueba 3: IU que agrupe las herramientas de Microsoft Office...................
. .
5.4.3.1 objetivo ..........................................................................................................
5.4.3.2. Resultados esperados..................;.................................................................
5.4.3.3. Resultados obtenidos.......... .........................................................................
5.4.3.4. Elementos que definen la forma de la interfaz..............................................
..
5.4.3.6. Proceso de construccion................................................................................
5.5. Validación de la hipótesis de trabajo....................................................................................
5.5.1. Atributos medidos.......................................................................................................
5.5.2. Resultados obtenidos..................................................................................................
i
!I
CONCLUSIONES.........................................
i
81
82
82
84
88
88
88
89
89
89
89
91
92
92
;......:...............................................................
93
Beneficios proporcionados...........................................................................................................
Alcances logrados .......................................................................................................................
:I
. .
Mejoras y ampliaciones ..............................................................................................................
Trabajos futuros ..........................................................................................................................
95
95
96
96
. .
'I
. .
Bibliografía General ............................................................................................................
97
IILISTA DE FIGURAS
Descripción
Figura
1.1.
2.1.
2.2.
2.3.
3.1.
3.2.
3.3.
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.
4.14.
4.15.
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.1.
5.8.
5.9.
5.10.
5.11.
Ejemplo de una IU ..............................................................................................
Ciclo de vida de una interfaz al usuario..............................................................
Ejemplo de una oración gráfica utilizando una gramática posicional ...............
1)
Formas en las que se puede
presentar la VP en el proceso de programación ....
Elementos gráficos seleccionados para definir la gramática del GenVIU .........
Conjunto de símbolos No Terminales (NT) .......................................................
Conjunto de símbolos Terminales (T) ................................................................
Arquitectura del GenVIU ...................................................................................
GUI del editor de la forma de una IU .......................................
........................
GUI del editor de la secuencia de eventos de una IU ........................................
Lista enlazada Dlgs ...?........................................................................................
!I
Lista enlazada Recursos .....................................................................................
Lista enlazada Menú ..........................................................................................
Lista enlazada Iconos .........................................................................................
Lista enlazada ElemenDT ..................................................................................
Lista enlazada Relaciones ..................................................................................
Jerarquíade clases utilizadas en el GenVIU .................... :............ i .....................
Modelo conceptual d e la clase TGenVIUApp ..................................................
Modelo conceptual de::'1 la clase Micontrol .........................................................
Modelo conceptual de'la clase EditorIU ............................................................
Modelo conceptual de la clase EditorSE ............................................................
Modelo conceptual de la clase VentanaMsg ......................................................
Diseño del menú de opciones del AMASS ........................................................
Diseño de la barra de botones del AMASS ........................................................
Vinculación de un BMP con un botón de la barra de botones ...........................
Diagrama de transición de estados que especifica la secuencia de eventos de
esta IU ................................................................................................................
1
Atributos asociados al nodo doble circulo: bloque principal de la IU del
AMASS .................... I .........................................................................................
Comandos de opciones disponibles para accionar la ejecución de una
herramienta..........................................................................................................
Especificación del nombre de la herramienta asociado a un nodo sencillo del
diagrama .............................................................................................................
Acción asociada a un Inodo sencillo del diagrama .............................................
3. .
Indicación de que el código de la IU diseñada se ha creado con éxito ..............
Ventana principal de la Iu del AMASS .............................................................
Diseño del menú de opciones del caso 2 ............................................................
Página
2
10
16
19
21
29
30
38
39
40
46
47
50
51
52
53
54.
56
60
62
65
68
73
73
74
14
75
75
76
76
16
80
82
!
I
Figura
5.12.
5.13.
5.14.
5.15.
5.16.
5.17.
5.18.
5.19.
-.
Descripción
Diseño de la barra de rotones del caso 2 ...........................................................
Secuencia de eventos de la IU del caso 2 ...........................................................
Valores asignados a los atributos del bloque principal de la IU del caso 2 .......
Ventana principal de la 1U del caso 2 ................................................................
' . del caso 3 ................................. I.................. ;.......
Diseño del menú de opciones
Diseño de la barra de dotones del caso 3 ...........................................................
Secuencia de eventos especificada con errores ..................................................
Errores detectados en 1.aevaluación del diseño de la IU ....................................
Phgina
83
83
84
88
90
90
91
91
I!
II
Y
LISTA DE TABLAS
Descnpci Ón
Tabla
2.1.
2.2.
2.3.
3.1.
Atributos de usabilidap que constituyen en conjunto uno de los atxibutos para
determinar la calidad de los sistemas .................................................................
'1
Una clasificación de 1 interfaces de usuario...................... ;..............................
Clasificación de gramáticas según Chomsky......................................................
Modificación del significado de los símbolos de los diagramas de transición
de estados ..............................................................
............................................
Página
8
13
15
28
I!
ij
...
111
Introducción
Introducción
Actualmente las Integaces al Usuario .(IU) han evolucionado conforme al auge
tecnológico en el hardware y software, de tal suerte que representan en la mayoría de los'casos el
éxito o el h c a s o de la aplicaciones.
Lo anterior origina la necesidad de creai interfaces Gráficas al Usuario (GUI, por SUS
siglas en ingles Graphics User Interfaces) flexibles, de tal. forma que permitan una mayor
interacción entre el usuario y los sistemas. Cabe mencionar que las GUI's estimulan la
exploración de una determinada aplicación, debido a que las funciones del sistema son fáciles de
probar por estar r e p r e s e n d ' por ICONOS que tienen la ventaja de poseer una semántica
asociada y de permitir una may& retención de las funciones.
La importancia de las W se sustenta en el hecho de que proveen un lenguaje a través del
cual es posible que los usuarios se comuniquen con los sistemas de software. Hoy día existen
diversas herramientas visuales que facilitan el desarrollo de KJ, pero únicamente en lo que
respecta a su forma (front end). Sin embargo, la semántica asociada a las interfaces se especifica
por medio de un lenguaje 'de programación con una sintaxis textual, lo que se traduce en un
proceso teüioso y lento para eiljusuario. Por consiguiente, en la presente tesis se propone utilizar
la tecnología visual para defin$ la secuencia de eventos asociada a una IU,con lo cual se espera
disminuir el tiempo de desarrollo de las interfaces.
La solución propuesta consiste en utilizar la teoría de autómatas y de lenguajes visuales,
para obtener una herramienta que soporte la construcción de IU en el dominio de ambientes
integrados de administración de software. La solución trata de probar que el empleo de estas
tecnologías mejora el proceso de desarrollo de las interfaces, además el dominio seleccionado
permitirá '' obtener la iU del! proyecto A M A S S (AMbiente integrado de soporte para la
Administraci6n y desarrollo de Sistemas de Software) desarrollado por el grupo de ingeniería de
software del cenidet. Cabe +lam que posteriormente se puede extender el alcance de la
herramienta a desarrollar con el fm de no limitar su uso.
,
El presente documento se encuentra organizado como sigue:
Capítulo 1. Planteamiento del problema. Se especifica el planteamiento del problema, se
muestran !las partes de una IU,así como las características que deben tener en el dominio de
ambientes' integrados de admibistración de software. Posteriormente se ilustran los objetivos y
beneficios de este proyecto de fesis.
Capítulo 2. Marco teórico. Se presentan algunos conceptos fundamentales de la
programación visual y de la teoría de autómatas, se describen algunos trabajos que tratan de
solucionar el problema descrito en el capítulo 1,
iV
1
Introducción
i
Capítulo 3. Descripcioh de la gramática del GenViU. Se describe la gramática visual
(relacional) utilizada en el GenVIU, incluyendo su análisis y definición. Así mismo, se describen
las modificaciones realizadas a la notación de los diagramas de transición de estados que
describen autómatas de estados h i t o s .
Capítulo 4. Desarrollo del sistema. Se describe la metodología de solución que da como
resultado ai sistema GenVIU, así como a las estructuras de datos utilizadas en la implementación
y 10saigoritmos que manipulan tales estructuras.
L
Capítulo 5. Plan de prukbas. Se establecen tres casos de prueba con los que se evalúa la
íüncionalidad del GenViU.
Conclusiones. Se describen los beneficios y alcances logrados en la presente tesis. Se
proponen algunas recomendacidbes, se da un panorama de los trabajos relacionados con el tema
de la programación visual, y porpíltimo se presentan algunos comentarios finales.
Bibliografia general. Se listan todas las referencias nombradas en el contenido de la tesis.
I
V
Capítulo 1 I
I
Planteamiento del Problema
Capítulo 1
PLANTEAMIENTO DEL PROBLEMA
1
En' el presente capítulo se especifica el planteamiento del problema tratado en la tesis.
Haciendo uso de un ejemplo deI una IU, se muestran las caractensticas que la IU debe tener en el
dominio de ambientes integrados de administración de software. Posteriormente se ilustran los
objetivos, los beneficios, la solución propuesta y los alcances de este proyecto de tesis.
Capitulo 1
I
1.1. Descripción del problema
En los sistemas computarizados, la interfaz hombre-máquina, por convención denominada
Interj¿az de Usuario (Iv) repreienta el medio de comunicación entre el sistema y los
usuarios[WASSERh4AN85]. En otras palabras las IU proveen, un lenguaje a través del cual es
posible que los usuarios se comuniquen con los sistemas de software.
Frecuentemente la IU es considerada como uno de los factores principales que influyen en
el éxito que puedan tener los 'Listemas. Las IU pueden tomar diversos mecanismos de
interacción[SHNEIDERMAN87], por ejemplo: un menú de selección múltiple, un lenguaje de
comandos, manipulación directa, un lenguaje de consulta a bases de datos, o bien permitir
entradas al sistema en ¡enguaje n a y a l . Así, la acción que debe efectuar un sistema de software
es determinada por la entrada de los usuarios, y en respuesta a esas entradas el sistema puede
0
responder mediante: solicitud de entradas adicionales, mensajes de error, ejecución de acciones o
I/
eventos o ayuda en el uso del sistema.
En la figura 1.1. se ilustra un ejemplo de una IU en la cual se pueden distinguir las dos
partes que la constituyen: su forma;y los eventos que se ejecutan al seleccionar una opción de la
forma, generalmente a esta parte se le conoce como semántica de la IU.
!,
I
Figura 1.1. Ejemplo de una IU.
I1
La forma (componente sin@ctico) de la interfaz constituye la apariencia (front end) del
sistema. Esta parte de la IU contiene reglas que permiten construir la secuencia de entradas
apropiadas al sistema, aunque no se? semánticamente significativas.
I
El significado (componente semántico) de la IU esta constituida por las funciones que va a
ejecutar el sistema en respuesta a una secuencia de entradas. En otras palabras, la semántica de
U esta formada por la secuencia de eventos a los cuales debe responder.
una i
2
Capítulo 1
Una de las tecnologías que se usa para construir IU consiste en la programación
tradicional (textual) y en un diseño iterativo (prototipo-pruebas-refinamiento). El uso de esta
tecnología ocasiona que el proceso de diseño y construcción de una IU llegue a consumir
aproximadamente el 50% del costo total del ciclo de vida del software[BASS91]. Este gasto
de desarrollo se puede ver como una pérdida, lo cual ha originado el desarrollo de nuevas
tecnologías para diseñar y construir IU a bajo costo y con el mínimo esfuerzo por parte de los
ingenieros de software.
Debido a la importancia de las IU en una aplicación, las técnicas de interacción humanocomputadora han evolucionado de las textuales a las gráficas, debido a los cambios en los
paradigmas de programación y a las necesidades actuales de las personas que demandan software
de calidad. Una de las tecnologías que actualmente se emplean para construir IU es la
programación visual, con lo cual se logra reducir el costo de desarrollo. Sin embargo, las
herramientas existentes que soportan este paradigma hacen uso de lenguajes textuales
(tradicionales), en los cuales se cAdifica parte de la semántica correspondiente a una iü. Algunas
de las razones del porque no se emplea el paradigma visual para describir totalmente la forma y la
semántica de una iü de un sistema dado son:
1). La semántica de una iü depende de la funcionalidad que deba tener el sistema, que se accede
por medio de la forma de la interfy.
2). Una herramienta visual que permita describir de manera visual la forma y la semántica de una
iü, debe tener un lenguaje de programación visual cuyo dominio debe ser genérico, con la
finalidad de soportar el desarrollo de diversos tipos de sistemas. Desarrollar una herramienta con
estas características no es trivial ya que tendría que incluir símbolos gráficos que representen a
cada elemento de la forma de la iü y elementos que representen cada función que se pueda
realizar en el dominio del sistema'que se desee modelar con dicha herramienta.
En la actualidad existen diversas herramientas computacionales de tipo visual que facilitan
desarrollar aplicaciones, incluyendo la iü de éstas. Por ejemplo, Visual Basic, Visual C++, Visual
Café, Delphi, entre otras. Sin embargo, estas herramientas se relacionan estrechamente con algún
lenguaje de programación textual, que sirve de anftrión al ambiente visual de dichas
herramientas, tal lenguaje anfitrión se utiliza para definir detalles de la semántica (significado) de
una iü.
La problemática planteada: "El proceso de diseño y construcción de IU llega a consumir
aproximadamente el 50% del cbsto total del ciclo de vida del sofhvare", esta solucionada
parcialmente para ciertos dominios, debido al empleo de herramientas visuales que permiten la
construcción de iü (su forma en su totalidad y parte de su semántica) para sistemas de software
de dichos dominios. Sin embargo, en la actualidad existe la carencia de una herramienta visual
que permita construir de manera visual en su totalidad la IU (forma y semántica) para un
ambiente que integre diversas herramientas en el dominio de desarrollo y administración de
sistemas de software.
3
I1
Capítulo 1
!I
para estos ambientes son:
Las Características de las
1. Permitir que los cambios en un elemento de información sean comunicados a otros
elementos relacionados a él.
I.
2.
Permitir el acceso directo, no secuencial, a cualquier herramienta contenida en el entorno.
I
3. Permitir que los usuarios de cada herramienta tengan una visión consistente de la IU
En este dominio de aplicafión, el pasar de una herramienta a otra debe de ser transparente
para el usuario, tal transparencia la debe de proporcionar la iü.Un sistema de este dominio esta
constituido por un conjunto de herramientas entre las cuales se establece una determinada
comunicación o secuencia de eventos.
Las herramientas visuales comerciales que existen en la actualidad, permiten construir la
forma de una IU para estos ambientes, pero la semántica asociada a esta IU se define mediante
código textual en el lenguaje anfitrión de dichas herramientas visuales. Lo anterior origina que el
construir Iü para este dominio ,siga consumiendo mucho tiempo del ciclo de vida de desarrollo
de sistemas de software. por tal motivo, se hace necesario una herramienta visual en la cual la
forma de la IU del ambiente y la comunicación entre las herramientas que se integran en ésta se
incorporen visualmente, sin escribir código textual en algún lenguaje de alto nivel.
1.2. Objetivo General
1)
Desarrollar una herramienta visual que permita de manera visual construir en su
totalidad Interfaces de usuario lforma y secuencia de eventos) para ambientes integrados en el
dominio de administración y desarrollo de sistemas de sofiare De aquí en adelante a esta
herramienta se le denominará GenVIU
II
1.2.1. Objetivos particulares
a) Realizar un estudio a varik aplicaciones en el dominio de administración y desarrollo de
sistemas de sofíware, con la finalidad de determinar los elementos gráficos que formarán
parte del alfabeto de la grdática relacional a definir.
b) Definir una gramática relacional para construir IU para ambientes integrados en el dominio de
administración y desarrollo de sistemas de software.
11
c) Modelar como caso de prueba la construcción de la Iü del AMbiente integrado de soporte
para la Administración y desarrollo de Sistemas de Software (AMASS I), el cual está en
proceso de desarrollo por parte del grupo de ingenieria de Software del cenidet).
I1
I
4
Capítulo 1
li
1.3. Beneficios
Se realizará una modificación en la notación de los diagramas de transición de estados que
describen autómatas de estados finitos determinísticos, con la finalidad de obtener una nueva
notación de diagramas de transición de estados para describir los eventos a los que debe
responder una iü.
I
Se definirá, diseñará e implementará una gramática relacionai para construir iü de sistemas de
software en el dominio de ambientes integrados para la administración y desarrollo de
software.
1 '
Se contará con un analizaddr sintáctico de la gramática relacional que permite validar las
construcciones hechas por el u s k o .
El usuario contará con una'herramienta para construir KJ para ambientes integrados de
administración y desarrollo he sistemas de software, en la cual podrán definir de manera
visual tanto la forma como dsecuencia de eventos de una iü.
I
Se generará código automáticamente a partir del diseño de la forma y la secuencia de eventos
especificada por medio del GenViü, propiciando una reducción en el tiempo de desarrollo, el
cual puede ser empleado en otra fase del ciclo de vida del s o h a r e .
El GenViü proporcionará al usuario código fuente de la KJ construida. El código se
proporcionará por medio de hn archivo de textos, dicho código estará escrito en el lenguaje de
programación C++ para la piataforma de Windows siguiendo el paradigma de programación
orientado a objetos.
I
Con el desarrollo de esta tesis la investigación se incursionará en el área de los lenguajes de
programación visual que permitan generar iU mediante una gramática relacional, asimilando
!
esta tecnología.
Se tendrá la iü del AMASS I,la cual será construida como un caso de prueba del GenViü.
1.4. Solución propuesta
Con la finalidad de reducir el costo y tiempo de desarrollo de IU se propone hacer uso de
la programación visual para definir de manera visual la forma y la secuencia de eventos
(comunicación entre las herramientas) a los que debe responder la iü de un sistema de software
de ambientes integrados para la administración y desarrollo de sistemas de software. Lo anterior
requiere de la especificación de una gramática relaciona1 que dirija la definición de la secuencia
de eventos de la Tu. Dicha gramatica contiene:
il
1. Elementos gráficos propios de la plataforma de desarrollo seleccionada, con la finalidad de
5
Capitulo 1
I
i
poder construir la forma de la IU.
2. Los símbolos de los diagrdas de transición de estados (doble círculo, círculo sencillo, y
I
arco), los cuales permitirán definir
la secuencia de eventos a los que debe responder una iU.
1)
Los eventos representan acciones a ejecutar desde la forma de la interfaz.
Esta solución emplea la teoria de diagramas de transición de estados para definir que
acción se debe ejecutar cuando se seleccione cierto comando de la IU diseñada. La finalidad de
usar esta teoria es debido a que, se puede especificar de manera gráfica una IU (forma y secuencia
de eventos). En otras palabras, la notación que proporciona permite una apreciación clara del
orden de precedencia y consecución de los eventos, permitiendo manejar de manera más óptima
las relaciones de producción de los elementos del ambiente integrado.
I
La gramática relaciona1 constituye la solución al problema planteado en este capítulo. La
gramática para fines experimehes se probará en el dominio de ambientes integrados de
adminisb;ición y desarrollo de @temas de software, debido a que la forma de la IU se puede
construir de manera visual, pero \a secuencia de interacción entre las herramientas en su totalidad
o parcialmente se tiene que definir mediante un lenguaje textual (C, C t t , Java, Visual Basic, etc)
ocasionando que los beneficios que se obtienen al emplear la programación visual para construir
la forma de las IU resulten insuficientes en cuanto a tiempo y costo de desarrollo.
1.4.1. Hipótesis de trabajo
El empleo de una herramienta visual para construir visualmente en su totalidad IU (forma y
semántica) de sistemas de software reduce el tiempo y costo de desarrollo de estos sistemas.
Los diagramas de transición de estados finitos facilitan la descripción de la secuencia de
eventos a los que debe responder una determinada iiJ.
1.5. Alcances
I. El tipo de interfaces de usuario que se podrán construir con el GenVIü será de tipo gráfico.
2. La gramática permitirá construir de manera visual la interfaz de u s d o del AMASS I. Así
mismo. se generará el código fuente de dicha interfaz durante el proceso de interpretación de
las expresiones visuales.
3. La gramática podrá ser extendida en trabajos futuros con la finalidad de no limitar el dominio
de los tipos de interfaz que s e pueda construir con dicha gramática.
1
4. El GenViiJ únicamente contempla la construcción de interfaces de usuario en el dominio de
ambientes integrados de administración y desarrollo de sistemas de software. No permitiendo
11
la construcción de interfaces de usuario para el control y monitoreo de procesos, y otros
tipos de interfaces que se encuentren fuera del alcance del dominio especificado.
6
i
Capítulo 2
MARCO TEÓRICO
En este capítulo se presentan los conceptos básicos en los que se sustenta el proyecto de
tesis. Los conceptos tratados son: Interfaz de usuario (IU),Ambiente Integrado, Gramática y
paradigma de los Lenguajes de Programación Visual (LPV). Además se incluye un reporte del
estado del arte relacionado con el tema de tesis.
Capitulo 2
Marco Teórico
2.1. Interfaces de usuario
Una interfaz de usuario representa el medio de comunicación entre los sistemas de
software y los usuarios [WASSERMAN85]. Las IU hacen uso de tipografía, símbolos, colores y
otros gráikos estáticos y dinámicos para transmitir hechos, conceptos o emociones [MATT97].
La tabla 2.1. muestra los atributos que determinan el nivel de usabilidad de una IU.
1
I
1
1
Atributos de Usabilidad de las IU.
1. Agradable.
2. Fácil de aprender
3. Eficiente
I
1I
Descripción
Satisfacción subjetiva de las necesidades de
los usuarios.
Se refiere al hecho de que los usuarios sin que
conozcan toda la funcionalidad del sistema
puedan efectuar alguna aplicación en él.
Significa que permita al usuario experta
obtener un alto nivel de productividad en el
sistema.
I
4. Fácil de recordar
I
5. Relativamente libre de errores o
errores no severos.
Se refiere al hecho de que algunos usuarios
puedan utilizar el sistema después de cierta
tiempo de no interactuar con él y que esta
nueva interacción no provoque que tengan que
aprender de nuevo el funcionamiento del
sistema.
Significa que los errores que se originen
mediante la interacción humano-computadora
sean fáciles de recuperar o bien no sean
catastróficos.
1
a
Capitulo 2
Marco Teórico
I1
I
1
Por'tal motivo el desarrollo de IU se lleva a cabo.considerando el hardware y software de
. ..
computadora disponibles, y analizando cómo emplear 'las herramientas disponibles para una
mejor satisfacción de las necesidades de los clientes, sin descuidar las características de los
usuarios que operarán el sistema, con la finalidad de reflejar estas características en el diseño y
construcción de la interfaz.
i!
1;
2.1.1. Ciclo de vida
I
11
El ciclo de vida de desarrollo de las interfaces de usuario es un proceso que involucra un
número de fases independientes ai '&3o de vida de la ingeniería de Software (IS). Sin embargo, el
ciclo de vida de desarrollo de las hJ se basa en las etapas de la IS como se muestra en la figura
2.1. [BASS91]. O
I
Dentro del ciclo de vida de desarrollo de iü,es importante observar los siguientes dos aspectos:
I1
i.
El diseño y desarrollo de iü es un proceso iterativo de refinamiento que persiste hasta que
ya sean suficientes las modificaciones realizadas ai sistema, con la finalidad de satisfacer
las necesidades de los usuarios
I1
.
ii. En cada Uno de los componer& de la interfaz se realizan representaciones abstractas. Así,
en la parte relacionada con !ps factores humanos esas abstraccione6 son estudiadas por
psicólogos, con la finalidad de obtener mejores criterios de diseño de la interfaz. En los
factores relacionados con la cgmputadora, las abstracciones son desciitas por una jerarquía
de máquinas de abstracción que proveen varios niveles de servicio y eso difiere en el costo
de implementación y mantenimiento.
'I1
Cualquier iü debe estar b a s p a en el conocimiento de estas dos observaciones y seguir las'
siguientes fases del ciclo de desarrollo de las IU [BASS91]:
I/
1. Definición de requerimienios:;Involucrala definición del problema, el modelo del usuario,
y el anáiisis de las tareas que debe efectuar la interfaz. En el análisis de las tareas se realiza
un diseño de alto nivel de la IU en el que el diseñador primero debe entender la
funcionalidad deseada del sistema, así como las capacidades de los usuarios que usarh.el
I1
sistema.
I
2.
Especificnción ; Consiste en especificar la IU con la cual interactuarán los usuarios del
sistema, también se definen 110s objetos de interacción a utilizar, tal como, ventanas,
comandos, o menús. Por o&o lado, se pueden efectuar las pruebas de usabilidad y
aprendizaje de la interfaz, así Lomo el refinamiento de la funcionalidad de los modelos del
usuario y el sistema.
3. Implemeniación : En esta fax, se desarrollan las estructuras de software necesarias para
construir la IU, esto ocasiona que las interfaces de usuario presenten una máquina
abstracta con el cual los usuarios interactúan.
9
Es importante aclarar que kl proceso de refinamiento de la interfaz se lleva a cabo durante
1
todas las fases del ciclo de vida de, la IU,como se muestra en la figura 2.1.
1
Tam= diferentes
Intencción
adiciona de los
Definición de
requerimientos
Especificación
Implementación
mtersción de lor
diferente de loí
‘ b
I1
implementación
I
11
Especificación
Figura 2.11. Ciclo de vida de una Interfaz de Usuario.
2.1.2. Elementos
1
‘I
La interfaz de usUano de un sistema, se compone básicamente de dos elementos, los
cuales se describen a continuación
I/ .
[WASSERMAN85], piiELSEN931, [BASS91J,
[HOWLETT96], y [COSTAGOGLiA95]:
1
a). Forma de la IU (componente sintáctico).
1 ’
La forma de la interfaz ,constituye la apariencia (front end) del sistema. En este elemento
se describen las reglas que pekniten construir la secuencia de entradas apropiadas al sistema,
I!
aunque no sean semánticamente significativas. Las entradas se forman mediante operaciones
10
'i
Capitulo 2
Marco Teórico
I
'i(
. .
primitivas del hardware disponible. Además, se describe la salida y las operaciones semánticas
que tiene el sistema por medio de ia interfaz, pero no sus detalles internos.
11
b). Significado de la IU (Componente semhtico).
I/
El significado de la interf' consiste en las funciones ejecutadas por el sistema, por lo
tanto, se debe de tener la información necesaria de cada función que opera sobre los datos
internos del sistema, incluyendo el resultado que genera.
I/
2.1.3. Principios de Diseño
I/
Los principios de diseño de una iü están relacionados con tres factores del diseño de una
interfaz: factores de desarrollo, factores de visibilidad y factores de aceptación [MATT97]. A
continuación se listan los tres pnnFipios de diseño de una iü descritos en [HOWLETT96].
I/
1. Armonía:
Probablemente es el principio más importante, y se alcanza: primero, cuando
los elementos de una interfaz se adaptan en conjunto sin modificaciones;
segundo, cuand: la navegación (ir de una parte de la interfaz a otra) se hace
con facilidad; y lpwxxo, cuando la configuración de todo el ambiente de la iü
(aspectos visuales y funcionales, entre otros) permite la satisfacción de todas
las necesidades '!de los usuarios. Este principio se refleja en la interfaz por
medio de la secuencia de eventos a la cual responde, así como en el estilo y
tamaño de los elementos de despliegue (letras, gráficos, aspectos de
retroalimentación) que emplea.
2. Equilibrio:
Este principio $ igual que el anterior se relaciona con la integridad de
elementos de la IU, con la diferencia de que se refiere de manera más directa a
los aspectos de 'simetría que debe contemplar toda interfaz, es decir, a los
aspectos relacidnados con la colocación, tipo de letra, color, gráficos
empleados en el hiseño. En otras palabras, incluye aspectos de estética visual.
3. Simplicidad, La simplicidad en las iü no es lo inverso a complejidad, sino que se refiere a
la claridad, sofishcación, elegancia de toda interfaz, sin dejar de considerar el
costo que ocasiona.
I/
2.1.4. Clasificación
I1 .
El auge tecnológico ha ocpionado que las necesidades a satisfacer por la ingenieria de
software aumenten considerablemehe, afectando a todas las fases del ciclo de vida del software y
en consecuencia al ciclo de vida de desarrollo de iü,de tal suerte que las iü de los sistemas de
software evolucionan con relación auge del software y hardware, y aún más por las necesidades
de los usuarios. La tabla 2.2 ilustra ima clasificación de las IU, obtenida mediante la recopilación
Marco Teórico
'I
Capitulo 2
de información [ W A S S E d N 8 5 ] ,
[COSTAGOGLIA95].
[NIELSEN93],
[BASS91],
[HOWLETT96],
y
1
2.2. Ambientes Integrados
'I
Los ambientes integrados constituyen un enfoque de la ingeniena de software para el
desarrollo de software. La intbgración de herramientas en ambientes de desarrollo genera
beneficios que incluyen [PRESSI)L4N93]:
i.
1
La transferencia fluida de ;información
herramientas y etapas de la IS.
(modelos, programas, documentos, datos) entre
ii. La reducción del esfuerzo requerido para realizar actividades de soporte como la gestión de
la configuración del softwa?e, el control de calidad, y la generación de documentación.
I/
iii. Un aumento en el control de los proyectos que se consigue mediante una mejor
planificación, la monitorización y la comunicación.
'I
iv. Mejora de la coordinación entre los miembros del equipo que trabajan en un proyecto de
software.
I'
Por otro lado, la intebación exige representaciones consistentes de información,
interfaces estandarizadas entre las herramientas, un mecanismo homogéneo para la comunicación
entre el ingeniero de software y cada herramienta y un enfoque efectivo que permita al ambiente
1
ejecutarse sobre distintas plataformas
de hardware y sistemas operativos [PRESSMAN93]. Así
los requisitos de integración son:
1
1.
Suministrar un mecanismo para que todas las herramientas contenidas en el entorno
compartan la información.1
2.
11 en un elemento de información sean comunicados a otros
Permitir que los cambios
elementos relacionados.
'I
3. Permitir el acceso directo, no secuencial, a cualquier herramienta contenida en el entorno.
4.
'I
Permitir que los usuarios de cada herramienta tengan una visión consistente de la interfaz
hombre-máquina.
11
12
1
Marco Teórico
Capitulo 2
1
Tipo de lnterfaz
.Textual
- Lenguaje de comandos. 11
- Menús de selección tipo popup.
I/
Características
1. No se pueden acceder con facilidad a
todas las funciones que efectúa el sistema.
2. Dificil de recordar.
3. Poco agradable de usar.
4. interacción tediosa entre el usuario y
sistema.
!. Gráficos.
'I
11
t
1. Empleo de imágenes (iconos, gráficas,
entre otras).
1. Debido al uso de aspectos visuales
(tipogr&ia, color, percepción, entre
otros)
2. son fáciles de aprender y recordar.
3. Interacción agradable y eficiente entre el
usuario y el sistema.
4. Mayor impacto en los usuarios, ya que es
1
.Multimedios.
iI
poco tedioso de usar a diferencia de las IU
textuales.
Además de incluir las características de las n
gráficas, incluyen:
1. Uso de múltiples medios
entraddsaiida (Audio, vídeo,
entre otros).
de
VOZ,
Z. El desarrollo de este
tipo de
interfaces resulta
muy
costoso,
debido a los requerimientos que
se exige para surealización.
Tabla 2.2. Una clasificación de las interfaces de usuario.
13
11
Capiiulo 2
Marco Te6nco
11
2.3. Gramáticas
11
Una gramática G que describe a un lengÚaje L se define como un cuarteto [RÉVÉSZ83]:
1
1
Donde :
NT
G=(NT,T,S,P)
Que representan a los símbolos no terminales de G, los cuales son un conjunto de
símbolos que representan las clases o estructuras sintácticas.
11
T
Representa al conjunto de símbolos terminales de G. Así, los símbolos en T representan al
alfabeto de L y T* designa todas las combinaciones del alfabeto de L.
S
Es el símbolo inicial de 1~ producciones en G. Generalmente S E NT
P
Representa al conjunto de reglas de producción en G, Una regla de producción es una
oración que indica una &gla de transformación que tiene del lado izquierdo un patrón
para probar una subcadena que será transformada, y del lado derecho se indica el
reemplazamiento que p e h i t e probar el patrón de la subcadena. Las oraciones en P tienen
la forma: a +/3
Donde: a /3 E (NT yT)*
a es diferente de NULO.
NT n T no es vacío.
I/
2.3.1. Jerarquía de Chombky
Las gramáticas generalmente se clasifican considerando el tipo de producciones que
t
generan. En la tabla 2.3. se muestra la jerarquía de las gramáticas según Chomsky.
I1
Las gramáticas son usadas para definir lenguajes de programación, tal como: los lenguajes
C, Pascal, Basic, Fortran, A& Modula, entre otros. El tipo de gramática a emplear en la
definición de un lenguaje en pdticuiar depende del propósito que persiga dicho lenguaje.
‘I
2.3.2. Gramática Posicionai
11
La definición de gramática posicional que se muestra a continuación fue adoptada de
[COSTAGOGLiA95]. Una giamática posicional se define mediante una extensión de la
defdción de gramática dada en 2.3., quedando de la siguiente manera:
G = (S, T, NT,P, POS, PE).
14
11
Marco Teórico
Capitulo 2
I/
Tipo
Características
I1
n este tipo de gramáticas se permiten producciones
ue eliminan símbolos, así mismo permiten la
mtracción y dispersión de símbolos intermedios.
No permite contracción de las reglas:
a + P o I P I 5 la1
Permite producciones como: bB + Bb
'I
11
o10 permite un símbolo del lado izquierdo de k
roducción, además que las producciones tienen k
xma:
a + P o I P I >.
la1 y la1 = I
A -+ B donde: B E (NT u T)* - 1
AENT
a = NULO.
Lineal Derecha, sus producciones son del tipo:
A+aB
A-+a
Lineal Izquierda, sus producciones son del tipo:
A+Ba
A j a
Donde : a
E
T y A, B
E
NT.
Tabla 2.3. Clasificación de gramáticas según Chomsky [RÉVÉSzS3]
1
Donde :
'I
G :Es una gramática posicionai.
S, 7: NTy P :Tienen el mismo significado que en la definición de gramática dada en 2.3.
POS : Es el conjunto dd relaciones de los símbolos gramaticales.
P E : Es el evaiuador pictográfico que convierte formas de sentencias en sus
representaciones b a l e s .
El elemento PUS de una gramática posicional describe en que sentido un objeto tiene
t
relación con otro objeto (símbolo
gramatical). Por su parte el elemento PE es un evaluador
pictográfico en donde se encuentran las reglas semánticas que se utilizarán dentro del intérprete o
15
It
Marco Teórico
11
Capitulo 2
I1
compilador del lenguaje a desarrollar. En este evaluador se define la posición que deberá adquirir
cada objeto de acuerdo a la relacion que tenga con otros objetos.
Por lo general, en las gramáticas posicionales las producciones en P, tienen la forma:
'I
'I
Donde :
.. Rm-lXrn, A
A + XIRIXZ
I/
A : Es un símbolo No Terminal (NT).
Xj : Es cualquier simbolo gramatical que E (NT U T)* -NULO.
'I
A : Reglas semánticas dentro del intérprete o compilador visual.
Rj : Es una relacion compuesta de la forma:
iI
..,REL?, ...,REL,~")con n 2 1.
(REL,~',.
I/
Cada REL;' denota un 'par (REL,, hi) donde: RELi es una relación en POS denotando
relaciones posicionales que tiene un objeto con respecto a otro; hi muestra cual es el objeto con el
que se tiene relación, el valor de hi se obtiene de XJ-k
en donde: j corresponde al valor secuencid
que tiene el símbolo gramatical.actual y k corresponde al valor secuencial que tiene el simbolo
gramatical con el cual se relaciona.
El rango de valores permitido para hi es: O Ihi <j .
'I
Se puede observar que la forma de las producciones de las grbáticas relacionales
.I
corresponde al tipo de producciones de una gramática libre del contexto. La figura 2.2., ilustra un
ejemplo utilizando este tipo de producciones.
n
mloim
B'HOR'
2
HOR'
3
VER'
4
VER3
5
VER'
6
1
(a)
11
(b)
Figura 2.2. Ejemplo de una oración gráfica utilizando una gramática posicionai.
11
El inciso (a) muestra la producción de una oración de manera visual, mientras que el
inciso (b) ilustra la misma producción pero haciendo uso del formalismo descrito en líneas
anteriores, el superíndice u t i b d o en cada uno de los símbolos gramaticales indica la
posición(número secuencial) que ocupa dicho símbolo en la oración.
11
ejemplo fue adaptado considerando el ejemplo ilustrado en
[COSTAGOGLIA95]. La adappción consiste en la modificación del rango de valores que puede
adoptar hi (supenndice de la relación), sin afectar la notación y la manera de calcular h, (h,=j - k,
donde: 1 Ij 5 n y 1 5 k <j). El rango de valores de hi es, 1 5 h ,<j.
Nota
: Este
I
16
,
11
Capitulo 2
Marco Te6nco
11
En el caso del inciso (b) 113 HOR' 7 indica que el objeto etiquetado con el número 7 se
relaciona horizontalmente con el objeto cuya etiqueta es el número 3, es decir, j = 2, k = 1,
h, = 2-1 = 1. Por SU parte, 7 VER3 O indica que verticalmente se relaciona el objeto etiquetado
I
con el número O, con el objeto cuya etiqueta es el número 7, es decir, j = 5, k = 2, h, = 5-2 = 3.
11
2.4. Programación Visual
1
El auge tecnológico ha originado el aumento en el interés por los sistemas.que emplean
gráficas en la comunicación seres humanos-computadoras, en la programación de aplicaciones y
en la visualización de datos. Debido a lo anterior, las tendencias actuales en el desarrollo de
herramientas computacionales se basan en el empleo del paradigma conocido como:
iI
programación visual en el proceso de programación y manipulación de datos.
En las siguientes secciones se definen y describen aspectos que esth relacionados con la
programación visual.
I1
2.4.1. Importancia del uso de iconos
11
El uso de elementos grficos (tal como iconos), como un medio de comunicación tiene su
origen desde hace mucho tiempb [LESTER95]. Las ideas representadas mediante estos elementos
reflejan asuntos cotidianos y se usan de manera exhaustiva. En la actualidad se incorpora este tipo
de elementos en el área de la computación como un medio para definir procesos y datos. Esta
t
aplicación ha originado un nuevo paradigma de programación, io que hoy se conoce como
programación visual.
'1
Un icono, según el diccionario Webster, es una imagen, representación, ilustración,
grabado o esquema utilizado p&a representar un concepto, idea, dato u operación.
La principal razón del por qué el empleo de iconos en la representación de información ha
tenido un gran auge, es debido"a que estos facilitan captar los mensajes, ya que la mente cuando
procesa una imagen, infiere relaciones sin necesidad de incluir texto en ésta [LESTER95],
además de que:
1
1. Son más didácticas que las palabras. como medio de comunicación.
2. Ayudan a entender y recordar.
'1
Lo anterior no significa que el propósito de emplear estos elementos sea representar todo
tipo de ideas y acciones sin incluir texto en ellas.
17
81
/i
Capitulo 2
Marco Teónco
I/
11
Lenguajes
de Programación
I/
Ambiente Visual
Lenguaje
Visual
11
It
Programas que
producen gr9ficos
Programas que
producen aplicaciones sin
Figura 2.3 Formas en las que se puede presentar la VP en el proceso de
programación [BüRNER95].
‘t
Por programación visual se entiende como el uso de expresiones visuales (tales como:
gráficas, dibujos, iconos) en el proceso de programación de aplicaciones [BURNER95].
Un Lenguaje de Programación Visual (WL) se puede definir adquiriendo cualquiera de
las siguientes definiciones:
1. Es una representación griifka de entidades conceptuales y operaciones, y es esencialmente una
herramienta por medio de la cual los usuarios componen iconos, o “expresiones visuales”
[CHANG95].
II
2. Es un lenguaje que permite el uso sistemático de las expresiones de tipo visual, las cuales se
convierten en código que a11 su vez la computadora puede ejecutar para realizar una tarea
particular. Así, un lenguaje de programación visual es un lenguaje visual [LÓPEZ95].
11
La Visualización tiene la función de ilustrar ciertos tipos de datos, la estructura de datos,
la estructura de un sistema cpmplejo, o incluso, el comportamiento de un sistema dinámico
[LÓPEZ95].
Los compiladores de los lenguajes visuales deben interpretar expresiones visuales y
trasladar éstas dentro de una forma que al menos intente la ejecución de las tareas descritas por
tales expresiones. Este procesolno es directo. El compilador no puede determinar e1 significado de
una expresión simplemente por reconocer los elementos que la constituyen, sino que debe de
considerar su contexto, es decir como cada elemento de ésta se relaciona con los demás.
t
‘I
19
11
Capitulo 2
Marco Teórico
11
2.5. Estado del arte
I
Actualmente en el mercado existen diversas herramientas Visuales Para el drsarro1lo de
aplicaciones, que han tratado de solucionar la problemática planteada en el ca~ímlo1. A
continuación se describen algunas de ellas:
I1
Aplication Builder [LÓPEZ95]
Esta herramienta permite construir aplicaciones de sistemas de base de datos. En
Aplication Builder 1.2 todo se realiza graáfkamente, uniendo mediante líneas objetos, señales, y
funciones. Esta característica puede ser atractiva, hasta que se presenta el hecho de tener un gram
numero de objetos y relacione? lo cual ocasiona que la legibilidad del sistema diseñado se
dificulte debido a las múltiples líneas que sirven de enlaces entre los objetos.
Las pantallas de la aplicación se diseñan propiamente de acuerdo con la metodología
común a casi todas las herramientas de desarrollo rápido: se toma el objeto de una paleta y se
arrastran a la posición que se desea en la pantalla (técnica drag and drop). Finalmente la pantalla
es compilada, generando un archivo ejecutable, el cual no es independiente ya que requiere de un
run rzme en forma de librenas dinámicas(DLL) para ejecutar la aplicación generada. En cuanto a
la programación que emplea es& herramienta es importante resaltar que es muy semejante a la de
la programación orientada a objetos, ya que primero se define la funcionalidad del elemento
visual a dibujar (métodos) y d&spuésse pinta el elemento visual en la pantalla, a diferencia de
otras herramientas que emplean otros paradigmas de programación. Por otro lado, el Aplication
Builder permite agregar funcionalidad a las aplicaciones generadas por él mediante el lenguaje
c/c++.
,I
Delphi ILbPEZ95)
Es una herramienta de desarrollo visual que trabaja bajo una versión mejorada de Borland
Pascal. Así mismo Delphi trabaja bajo Windows, una de sus características sobresalientes es que
está enfocado a plataformas cliente-servidor y desarrollo de aplicaciones para base de datos. La
filosofia en la cual se basa esta herramienta visual es la de diseño de pantallas mediante drag and
drop (tómese y tírese en el lugar apropiado), por lo que poner botones, controles, ventanas o
imágenes, significa tomar la opción del menú y colocarla en la ventana en donde el programador
está creando la forma (pantalla) de su aplicación.
Delphi a diferencia dellotras herramientas visuales hace uso del compilador de Borland
Pascal. Por otro lado, los componentes que emplea esta herramienta en la programación visual
son totalmente orientado a objetos.
11
Así mismo, Delphi produce código ejecutable directamente en Windows y soporta todos
los servicios de OLE (Object Linked Embedding), DLL (Dynamic Link Library) y DDE
(Dynamic Data Exchange) que Windows provee. Es posible realizar modificaciones a las
20
'I
Capitulo 2
Marco Teórico
I1
aplicaciones mediante el lenguaje de programación Borland Pascal con la finalidad de ajustar la
aplicación a necesidades específicas.
PowerBuilder [LdPEZ95]
Es una herramienta visual para generar aplicaciones bajo el ambiente gráfico de Windows
3.x. En el PowerBuilder se cuenta con una serie de rutinas, que el usuario ve como iconos que
representan diferentes acciones, que se pueden tomar. En principio esta herramienta p e h t e
generar aplicaciones en Windows que funcionen con bases de datos, es decir, el sistema está
orientado a ser un manejador de base de datos para plataformas cliente-servidor. Así mismo, es
programable y le permite al uhario generar poderosos front end que permiten manipular la
información de diferentes maneras.
81
Al igual que Delphi hace uso de la filosofia drag and drop con la cual se colocan botones o
cajas de dialogo en las ventanas de la aplicación que se está creando. Otra característica del
PowerBuilder es que cuenta con su proprio lenguaje para escribir las acciones que los botones en
las ventanas diseñadas deberán tener. Dicho lenguaje genera código ejecutable para la interfaz
11
que corre bajo Windows.
O
I
Visual Basic [LdPEZ95]
'I
Es una herramienta visual que puede generar programas autoejecutables (siempre
acompañados de un run time: VBRüN300.DLL) con algunas pulsaciones del ratón. Así mismo
permite tener acceso a OLE 2, comunicación DDE, y al API de Windows, pero una de sus
desventajas es la de no poder generar archivos DLL. Visual Basic hace uso de versiones del
lenguaje BASIC para darle funcionalidad a la aplicación cuya interfaz(forma) se genero mediante
la programación visual que soporta esta herramienta. Otra característica importante de Visual
Basic es que no es orientado, a objetos ya que los componentes que emplea carecen de las
propiedades de herencia y polimoríísmo.
Las cuatro herramienth descritas, se clasifican dentro de los medios ambientes de
programación visual que emplean una sintaxis textual, ya que a pesar de que permiten la
programación visual hacen uso de algún lenguaje de alto nivel tradicional (C, Pascal, Basic, entre
otros) que sea compatible con la herramienta en uso. La utilización de estos lenguajes es con la
finalidad de definir parte o en su totalidad la funcionalidad de las aplicaciones, incluyendo el
dialogo a seguir para que los ukmios interactúen con dichas aplicaciones.
A continuación se describe una herramienta visual que hace uso de algunos símbolos
gráfkos en su sintaxis.
21
Marco Teórico
Capitulo 2
LABVIEW (Programación gráfica para la instrumentación) [NATIONAL92].
National Instruments
Es un sistema de programación gráfico para la adquisición, análisis y presentación de
datos. Esta herramienta ofrece una metodología revolucionaria, en la que el desarrollador
ensambla su programa utilizando módulos llamados “instrumentos virtuales” (Vis). Estos Vis
adquieren los’datos de tarjetas de adquisición de datos o instrumentos programables, y luego los
analizan, procesan y presentan en la forma que se especifique. LabVIEW incluye un editor de
expresiones visuales en donde el desarrollador crea sus aplicaciones, así mismo contempla un
compilador para estas expresiones.
En la actualidad se están efectuando investigaciones en instituciones educativas y centros
de investigación con relación a los lenguajes visuales que permitan construir interfaces de
usuario, algunas de estas investigaciones se describen a continuación:
Automatic Construction of User Interface from Constraint Multiset Grammar[CHOK95].
Autor(es): Sitt Sen Chok and Kim Marriott
Departament of Computer Science
Monash University
Este trabajo describe una herramienta que genera automáticamente una sofisticada
interfaz de usuario a partir de la especificación de un lenguaje visual con una gramática que
contiene múltiples limitaciones. La interfaz de usuario permite construir diagramas en el lenguaje
visual a partir de elementos primitivos tales como: texto, líneas, rectángulos, o círculos. Estos
elementos son traducidos incrementalmente dentro de subdiagramas. Durante el análisis
sintáctico, automáticamente se corrigen los errores removiendo los errores geométricos, además
provee una retroalimentación acerca de lo que ha sido reorganizado. Los usuarios pueden añadir o
borrar elementos, además der poder manipular los componentes del diagrama. Durante la
manipulación las relaciones geométricas dictadas por el lenguaje visual se preservan.
AMULET : User Interface Toolkit (MYER96).
Autor(+: Brad A. Myers, Rich McDaniel, Alan Ferrency, Rob Miller, Patrick Doane.
Human Computer Interaction Institute
School of Computer Science
Carnegie Mellon University
Pittsburgh, Enero 1996.
I1
El ambiente de desarrollo de interfaces de usuario AMULET, incluye diversas
innovaciones de diseño e implementación de software, incluyendo nuevas restricciones, objetos,
entradas, salidas y modelos de deshacer (undo). AMULET fue diseñado con una arquitectura
abierta, de tal manera que los desarrolladores de las interfaces de usuarios puedan reemplazar y
agregar partes. Las clases de objetos gráficos están implementados de una manera abierta ai
22
Capitulo 2
Marco Teórico
utilizar el AMULET intlínsecamente de tal forma que los desarrolladores pueden reemplazar O
modificar estas clases de objetos, la finalidad de esto es que SÓIO se tenga que imp1ementar
aquellas partes que les interesen y usar el resto de lo que requiem de las librerías d f i c a s .
Un objetivo importante del AMULET, es el de proveer un soporte para desarrollar
programas de aplicación de alto nivel. Las herramientas convencionales como la caja de
herramientas de Macintosh y el motifde Unix proveen una colección de clases de objetos gráficos
como menús, barras de scroll, botones y campos de entrada de texto. El AMULET provee
adicionalmente un soporte para aplicaciones graficas del tipo de: editores visuales, visualizadores
de programas entre otros ya que soporta una actualización automática de los d f i c o s , así mismo
está constituido por clases de objetos gráficos que soportan comandos de edición built-in, tales
como copiar, cortar, pegar, ir hacia arriba, hacia abajo y deshacer, que pueden ser utilizados
directamente.
Una de las finalidades al desarrollar el AMULET, es el de explorar el uso intensivo de
herramientas interactivas que permitan a la mayoría de las interfaces de usuario ser especificadas
sin la programación convencional. Por último, es permitir al diseñador de interfaces de usuario
simplificar dibujos de las gráficas de la interfaz y entonces demostrar los funcionamientos
interactivos para mostrar como la interfaz debería reaccionar para el usuario.
AMULET contiene un conjunto de herramientas que está constituido por un conjunto de
clases de objetos graaficos y la “capa intrínseca” la cual es la manera en como las clases de objetos
gráficos están implementados. )Esta capa contiene una interfaz abstracta para el manejador de
ventanas. y nuevos modelos para objetos, restricciones, entrada, salida. Así mismo, implementa
una instancia prototipo de sistema de objetos sobre C t t . En una instancia prototipo de objetos,
no existe distinción entre clases, por ejemplo: cada objeto puede ser utilizado por otro objeto
como un prototipo.
2.6. Análisis del estado del arte
Es importante remarcar que las herramientas y las investigaciones revisadas, no resuelven
el problema planteado en la tesis, ya que estos trabajos buscan la solución a otros problemas que
no tienen ninguna relación con el tratado en el dominio del tema de la tesis.
Por otro lado, el lenguaje visual a desarrollar no pretende ser una competencia para las
herramientas comerciales, sino que permitirá mostrar que tan eficiente es construir visualmente
interfaces de usuario en este caso en el dominio de ambientes integrados para el desarrollo y
administración de s o h a r e , mediante un lenguaje de programación visual.
Una pregunta que puede surgir es: ¿Qué diferencia tiene la herramienta a desarrollar con
respecto a las herramientas que ya existen para diseñar y construir aplicaciones mediante
programación visual?. La respuesta a tal cuestionamiento es la siguiente:
23
!
Capitulo 2
Marco Teórico
Una razón del por qué no existe un lenguaje visual para diseñar interfaces de usuario para
diversos dominios es el hecho de que estos lenguajes así como los lenguaje tradicionales hacen
uso de una gramática, pero en el caso de los lenguajes visuales se requiere que su alfabeto incluya
símbolos gráficos. También se sabe que los lenguajes visuales tienen un dominio específico, estos
están limitados por el dominio de la gramática que los soporta, de hecho por esta razón, las
herramientas comerciales dedicadas a construir interfaces de usuario mediante programación
visual hacen uso de ambientes de programación visual basados en una sintaxis textual, ya que
estos ambientes emplean símbolos gráficos en la visualización del diseño y construcción de la
interfaz de usuario de aplicaciones, pero no existe una gramática visual(gráfica) que soporte dicha
programación, sino que todo ese proceso lo realiza un lenguaje basado en una gramática textual o
tradicional. en la mayoria de los casos el lenguaje empleado es uno de los ya conocidos (C,
Pascal, Basic), sin embargo existen algunos otros que incluyen su propio lenguaje.
Considerando las limitantes existentes actuales para constniir IU en el dominio de
ambientes integrados, en esta tesis se define una gramática positional que permita guiar la
construcción de IU, así como la definición de la comunicación entre las herramientas de un
determinado ambiente integrado. Esta gramática se describe en el siguiente capítulo.
24
Descripción de la gramática del GenVIU
Capitulo 3
Capítulo 3
DESCRIPCIÓN DE LA GRAMÁTICA DEL GENVIU
En este capítulo se describe la gramática relaciona1 utilizada en el GenVIU. Se inicia
explicando el esquema conceptmi por capas del GenViU, posteriormente de describe el análisis y
la d e f ~ c i ó nde la gramática utilizada. Así mismo, se describen las modificaciones que se le
hicieron a la notación de los diagramas de transición de estados que denotan autómatas de estados
finitos.
25
Capitulo 3
Descripción de la gramática del GenVlU
3.1. Notación usada en la definición de la gramática
Con la finalidad de estandarizar la formalización de la gramática que se explica en las
siguientes secciones con relación a notaciones de gramáticas, se hace uso de la convención de
notación propuesta por Alfred V. Aho[AH090], la cual esta basada en la notación Backus Naur
Form. Dicha convención se ha ajustado a la formalización de la gramática que se describe en este
capítulo.
1. Son símbolos terminales: ( T )
a) Los símbolos gráficos.
b) Las letras escritas en minúsculas.
2. Son símbolos no terminales: ( NT )
a) Las letras escritas en mayúsculas.
b) La letra S es el símbolo inicial.
c) Los símbolos gráficos que se encuentran encerrados en un cuadro
3. Las letras griegas minúsculas, a,p por ejemplo, representan cadenas de símbolos
gramaticales. Por tanto, una producción genérica podría escribirse A + a,indicando que hay
un solo símbolo NT <' A " a la izquierda de la flecha (el lado izquierdo de la producción), y
una cadena de símbolos gramaticales , formada por símbolos que E (NT U T ) a la derecha de
la flecha (el lado derecho de la producción).
4. Si A -+ al, A -+ az,..., A + ai, son todas las producciones con <' A " a la izquierda, a estas
producciones se les llama producciones de " A ". Tales producciones se pueden escribir
como: A + al I a2 I ... I G.En la cual a al,a2, ..., a, se denominan alternativas de " A ".
En dicha escritura el símbolo " I " indica " O exclusivo", es decir, que el símbolo NT del lado
izquierdo de la producción puede ser reemplazado por cualquiera de las cadenas del lado
derecho separadas por el símbolo " I ".
S. A menos que se diga lo contrario, el lado izquierdo de la primera producción esta formado
por el símbolo S .
3.2. Análisis de la gramática
La gramática del GenVIU tiene como finalidad:
I . Generar la forma (componente sintáctico) de IU para ambientes integrados de
administración y desarrollo de sistemas de software.
2. Definir la secuencia de eventos e la que debe responder la IU generada.
Por tal motivo, para definir dicha gramática se tuvo que realizar una investigación acerca
de los elementos gráficos que se emplean para construir IU de ambientes integrados para la
administración y desarrollo de software. Los elementos básicamente se seleccionaron analizando
26
Descripción de la gramática del GenVlLl
Capitulo 3
herramientas que permiten construir aplicaciones de este dominio, las herramientas analizadas
son: Visual Basic, Visual C++, Visual Café, Borland C++, Delphi entre otras. LOS elementos
seleccionados fueron aquellos que resultaron comunes a todas las herramientas analizadas. Por
otro lado, para poder lograr la segunda finalidad de la gramática se empleo la teoría de autómatas
de estados finitos determinísticos en su representación gráfica mediante diagramas de transición
de estados, debido a que este tipo de notación permite una apreciación clara del orden de
precedencia y consecución de los eventos, permitiendo manejar de manera óptima las relaciones
de producción de los elementos de la IU. La figura 3.1. ilustra el resultado de dicho estudio.
Ventana gráfica.
Menu de opciones
Botón
Caja de chequeo de datos.
@
d
F/
Radio botón de chequeo.
Caja de entrada de datos.
Etiqueta.
Caja de despliegue de datos
01
Icono o imagen de mapa de bits.
@)
0
/
Doble circulo.(nodo inicial)
I
circulo senciiio.(nodo)
Arco.
(b) Elementos que definen la secuencia de
eventos de una IU.
Caja de dialogo.
(a) Elementos que deñnen la forma de una iü.
~
Figura 3.1. Elementos gráficos seleccionados para definir la gramática del GenViU.
3.2.1. Elementos que definen la forma de las Interfaces al Usuario
Los elementos que definen la forma (front end) de una IU para el dominio de ambientes
integrados de administración y desarrollo de sistemas de software se ilustran en la figura 3.1.
inciso (a). Estos elementos son utilizados generalmente, en el desarrollo de IU para el dominio
tratado en esta tesis.
27
Capitulo 3
3.2.2.Elementos que definen la secuencia de eventos de las Interfaces al
Usuario
Los elementos que definen la secuencia de eventos de una IU para el dominio tratado en
esta tesis son ilustrados en la figura 3.1. inciso (b). Estos elementos permiten definir la
comunicación entre las herramientas que constituyen a un ambiente integrado. Se puede observar
que tales elementos son los símbolos gráficos de los diagramas de transición de estados. Aunque
cabe aclarar que debido a los propósitos de la gramática del GenVIU se modificó el significado
de cada uno de estos símbolos, tal modificación se ilustra en la tabla 3.1. El significado original
de los símbolos de los diagramas de transición de estados se pueden consultar en
[WASSERMAhW], [BROOKSHEAR93].
SIGNIFICADO
Representa al nodo inicial, en otras palabras, la i
U principal de un ambiente
integrado, la cual permite iniciar una sesión de trabajo.
O
f
Representa un nodo del diagrama, en este caso cada nodo representa a una
herramienta a integrar en el ambiente.
Representa a un arco del diagrama, en este cas@el arco será una relación
a establecer entre cada uno de los nodos del diagrama, la etiqueta de
cada arco representa la informaci6n que se comunica entre una
herramienta y otra.
Tabla 3.1. Modificación del significado de Los símbolos de los diagramas de transición de
estados.
3.3. Definición de la gramática
Lalgramática relacional que utiliza el GenVIU se define mediante una extensión de las
gramáticas lineales. Quedando como:
G = (NT, T, S, P, POS)
Donde :
G
S
T
P
Es una gramática relacional.
Es el símbolo inicial de G.
es el conjunto de símbolos terminales.
es el conjunto de símbolos no terminales.
es el conjunto de reglas de producción.
28
Capitulo 3
POS es el conjunto de relaciones cuádruples de los identificadores.
La principal característica de G es que en el conjunto de sus símbolos terminales se
encuentran representaciones gráficas, lo que hace que esta gramática sea visual, y que además
nos permite.iniciar un diálogo entre los elementos del ambiente integrado, mediante la relación
que existe en las reglas de reescritura. Se proporciona un conjunto de secuencias que permite la
comprensión de los eventos, su secuencia y la posición que guardan dentro del ambiente. En las
siguientes secciones se presenta la definición de los elementos que constituyen a la gramática del
GenVIU.
3.3.1. Símbolos gramaticales
Los símbolos gramaticales se definen como el conjunto de símbolos que resultan de la
unión del conjunto de símbolos No Terminales (NT) y del conjunto de símbolos Terminales (T),
es decir, los símbolos gramaticales son el conjunto (NT u T).
3.3.1.1. Símbolos No Terminales
El conjunto de símbolos No Terminales (NT) constituye un conjunto de variables
sintácticas que denota conjuntos de cadenas. En la figura 3.2. se muestran los NT utilizados en la
gramática del GenVIU. Estos símbolos definen conjuntos de cadenas que ayudan a definir el
lenguaje generado por la gramática. Además establecen una estructura jerárquica sobre el
lenguaje generado, la cual es útil para el análisis sintáctico como para la traducción[AH090].
NT=
(
<S>, <VENCOMPUESTA>, <CONTENIDO>, <CONTENiDODLG>, <RECGRA!+,
<RECGRAFVENTANA>, <RECGRAFDLG>, <MASRECGRAF>, <RGVENTANA>,
<CAJADIALOGO>, <RGBOTON>, <RGICONO>, <RGCAJADATO>, <RGMENU>,
<RGCAJACHECA>, <RGRADIOCHECA>, <RGCAJALISTA>, <RGETIQUETA>,
<EVENTOS>, < H E W > , <REGRESO>, <NODODO, .iNODO>
1
Figura 3.2. Conjunto de símbolos No Terminales (NT).
3.3.1.2. Símbolos Terminales
El conjunto de símbolos Terminales (T) constituye un conjunto de símbolos básicos con
que se forman las cadenas. “Componente léxico” es un sinónimo de terminal cuando se trata de
gramáticas para lenguajes de programación[AH090].
29
Capitulo 3
Los símbolos terminales utilizados en la gramática del GenVIU se ilustran en la figura
3.3, dichos símbolos representan a los recursos gráficos empleados para definir la forma de una
IU para el dominio especificado en el objetivo de esta tesis. Así mismo, los Últimos dos símbolos
(de izquierda a derecha) ilustrados en la figura antes mencionada se emplean para poder definir la
secuencia de eventos de la interfaz a construir.
Figura 3.3. Conjunto de símbolos Terminales (T).
3.3.1.3. Símbolo inicial
En ‘una gramática un símbolo de NT es considerado como el símbolo inicial y el conjunto
de cadenas que representa es el lenguaje definido por la gramática. Generalmente este símbolo se
denota con la letra “S”.
3.3.1.4. Relaciones cuádruples de los símbolos terminales
POS, es el quinto elemento de G, el cual denota al conjunto de relaciones cuádruples que
pueden tener los símbolos terminales de G. Básicamente un elemento de POS representa la
relación que tiene un objeto con respecto a los demás. Así mismo, estas relaciones ubican al
objeto dentro de un plano cartesiano de dos dimensiones (2-D) con respecto a otros objetos. A
continuación se muestra el conjunto POS:
POS :Rj = { ADENTRO, ARCO ]
Considerando la definición de R, que se dio anteriormente, tenemos:
Para el caso de la relación ADENTRO:
REL = ADENTRO
h, puede adquirir dos posibles valores:
1 : En el caso de que se desee relacionar un objeto con un objeto VENTANA
derivado a partir del símbolo <VEN COMPUESTA>.
2 : En el caso de que se desee relacionar-un objeto con un objeto VENTANA
derivado a partir del símbolo <CAJADIALOGO>.
30
Descripci6n de la gramatica del GenVIU
Capitulo 3
En otras palabras, la relación ADENTRO es un par de coordenadas que indica dentro de
que objeto se encuentra un objeto determinado, además indica la posición en la que se encuentra
un objeto dentro de la pantalla.
Para el caso de la relación ARCO:
REL = ARCO
h,: (k, 1) en donde:
k : Corresponde al número del elemento actual en la secuencia de la producción.
1 : Corresponde al número del elemento con el cual se desea tener relación.
El rango de valores permitidos para k y 1 es: 1 5 k Im y 1 5 1 < k respectivamente,
donde: m representa al último elemento de una secuencia de producción.
Esta relación tiene asociada una representación visual mediante una linea curva con
dirección. Lo anterior es necesario para poder definir de manera visual con la gramática G la
secuencia de eventos a los que debe de responder una IU.
3.3.2. Reglas de producción
Las reglas de producción de una gramática especifican cómo se pueden combinar los
símbolos de T y los símbolos de NT para formar cadenas. Cada producción consta de un símbolo
de NT seguido de una flecha, seguida por una cadena de símbolos gramaticales, es decir:
A+P
donde:AENTyPE(NTuT)'
Las gramáticas relacionales son una extension de las gramáticas lineales, por io tanto, se
puede observar un incremento de nuevas características a las reglas de producción P.
.
A+ Xm'R~Xm2,. ., Rj-iXJ, A
Donde :
A : Símbolo del conjunto NT.
X : Símbolo gramatical que E (NT u T) - NULO.
j : Indica el número total de elementos en la regla de producción.
m : Indica el elemento a relacionar mediante Rj en cada producción que
utilice ADENTRO], ADENTRO~O RELACION.
En el caso de RELACION indica el objeto ai cual estará apuntando la punta
de la flecha. El valor de m debe estar en el rango: 1 _< m c j.
A : Reglas semántica dentro del intérprete o compilador visual.
R, : Es una relación compuesta de la forma :
31
CapiNlO 3
(REL'~',. . ., EL?,
. . ., REL,~")con n 2 1.
Cada
denota un par ( E L i , hi) donde: RELi es una relación en POS denotando relaciones
posicionales que tiene un objeto con respecto a otro; hi muestra cual es el objeto con el que se
tiene relación, el valor de hi se obtiene de XJ-ken donde: j corresponde al valor secuencia] que
tiene el símbolo gramatical actual y k corresponde al valor secuencial que tiene el símbolo
gramatical con el cual se relaciona. El rango de valores permitido para hi es : O 5 hi < j .
P=(
<S> + <VENCOMPUESTA> I <EVENTOS>
<VENCOMPUESTA> -+ <RGVENTANA> ADENTRO' <CONTENIDO>
1 <RGVENTANA> ADENTRO' <RGMENü> ADENTRO' <CONTENIDO>
<CONTENIDO> -+ <RECGRAFVENTANA> ADENTRO' <CONTENIDO>
I <RECGRAFVENTANA>
<RECGRAFVENTANA> + CAJADIALOGO>
1 <RGBOTON>
1 <RGICONO>
ICAJADIALOGO> -+ <RGVENTANA> ADENTRO~<CONTENIDODLG>
<CONTENIDODLG> .+ <RECGRAFDLG> ADENTRO~ICONTENIDODLG>
I <RGBOTON> ADENTRO~<MASRECGRAF>
I <MASRECGRAR
<RECGRAFDLG> -P <RGCAJADATO>
I <RGCAJACHECA>
I <RGRAüIOCHECA>
I <RGCAJALISTA>
I <RGETIQUETA>
<MASRECGRAF> -+ <RECGRAF> ADENTRO2<MASRECGRAF,
I <RECGRAF>
<RECGRAF, -+ <RECGRAFDLG>
I <RGBOTON>
<EVENTOS> 3 <NODODO ARCO(k, I) <HERRAM>
<HERRAM> -b <NODO> ARCO(k, I) <REGRESO>
1 <NODO> ARCO(k, I) <HERRAM>
1 <NODO>
32
Capitulo 3
<RGVENTANA> +
<RGCAJACHECA> +
<RGRADIOCHECA>
+ @
<RGBOTON> +
d
<RGCAJADATO>
-+
<RGCAJALISTA>
+
<RGETIQUETA>
+ T/
1
<NODODO
+
a
@
En la formalización de las producciones de G, a todos los símbolos terminales gráficos se
les asigna un subíndice (m) que indica el número de elemento(en este caso un nodo) a relacionar
o producir.
3.3.3. Atributos de los símbolos terminales gráficos
Las gramáticas relacionales diferencia de las gramáticas lineales tienen asociado un
conjunto de atributos a cada uno de los símbolos terminales gráficos que la constituyen. Estos
atributos proporcionan información adicional de cada símbolo.
1
33
Capitulo 3
'
Descripción de la gamhtica del GenVIU
3.3.3.1. Atributos de los símbolos que definen la forma de las Interfaces al
Usuario
Los símbolos gráficos de la gramática G que permiten definir la forma de las IU tienen los
siguientes atributos:
Atributo
Número de objeto
Descripción
Representa el número secuencial que ocupa el símbolo
gráfico en la secuencia de entrada.
Nombre del identificador Representa una etiqueta con la cual se puede referencia al
símbolo gráfico.
Valor del identifieador
Es un valor de tipo entero sin signo asociado al nombre del
identificador.
Tipo de recurso gráfico
Es un valor de tipo entero sin signo que indica el tipo de
recurso gráfico al que pertenece el símbolo actual en la
secuencia de entrada.
Posición en el eje X
Es un valor entero sin signo que indica la posición del
símbolo en el eje X dentro de un plano cartesiano 2-D.
Posición en el eje Y
Es un valor entero sin signo que indica la posición del
símbolo en el eje Y dentro de un plano cartesiano 2-D.
Altura
Es un valor entero sin signo que indica en el dispositivo de
despliegue la cantidad de pixeles que tiene como altura el
símbolo.
Ancho
Es un valor entero sin signo que indica en el dispositivo de
despliegue la cantidad de pixeles que tiene como ancho el
símbolo.
Leyenda asociada
Es una cadena de caracteres encerrada entre comillas que
representa el nombre del símbolo gráñco.
Estilo asociado
Es un valor entero que representa a uno o a varios estilos
asociados a los símbolos gráficos.
Dentro de los elementos gráficos que constituyen al conjunto T de la gramática G, el
símbolo gráfico menú tiene asociados atributos adicionales, descritos en la siguiente sección.
34
Capitulo 3
3.3.3.1.1. Atributos del símbolo menú
51 simbolo @flc0 menú no requiere de los atributos Leyenda Y Estilo Y tiene Otros
atributos adicionales correspondientes a las opciones que se incluyen en el menú. Tales atributos
se listan a continuación.
Atributo
Descripción
Número de opción
Representa el número secuencial que ocupa la opción en el
menú.
Tipo de opción
Este atributo puede adquirir uno de dos posibles valores de
tipo entero sin signo:
1: indica que 1á opción tiene un identificador con el cual se
puede utilizar.
2: indica que una opción tiene la función de submenú, esto
implica que no tenga identificador, sino que contiene
opciones que pueden clasificarse en cualquiera de los
dos tipos descritos en este punto.
Nombre del identificador Representa una etiqueta con la cual se puede referenciar una
opción del menú.
.-
Valor del identifcador
Leyenda asociada
Es un valor de tipo entero sin signo asociado al nombre del
identificador.
..:-indica el nombre de una opción.
3.3.3.2. Atributos de los símbolos que definen la secuencia de eventos de las
Interfaces al Usuario
Los símbolos doble circulo, circulo sencillo (nodos) y la relación arco comparten los
siguientes atributos en común:
Atributo
Descripción
Número de objeto
Representa el número secuencial que ocupa el elemento en la
secuencia de entrada.
Posición en el eje X (XI)
Es un valor de tipo entero sin signo que indica la posición en
el eje X de la esquina superior izquierda del nodo.
35
Capitulo 3
Posición en el eje Y (Y,)
el eje Y de la esquina superior izquierda del nodo.
Posición en el eje X (Xz)
el eje X de la esquina inferior derecha del nodo.
Posición en el eje Y (Y2)
el eje Y de la esquina inferior derecha del nodo.
Leyenda asociada
indica el nombre de una opción.
~
Los símbolos doble círculo y círculo sencillo tiene dos atributos adicionales asociados:
Atributo
Tipo de nodo
Descripción
Este atributo puede adquirir a la vez uno de los siguientes
valores de tipo entero sin signo:
1. Este valor indica que se trata del nodo inicial (doble
círculo) y representa a la aplicación pnncipal (ambiente
integrado).
2. Este valor indica que se trata de un nodo más en el
y
diagrama de
transiciones (círculo sencillo)
representa a una herramienta a integrar en la IU.
Nombre de la aplicación
Asociada al nodo,
Es una cadena de caracteres que indica el nombre del archivo
(incluyendo trayectoria de acceso) de la aplicación asociada
al nodo.
La relación arco empleada en las reglas de reescritura de la gramática G, además de tener
asociados los atributos en común descritos al inicio de esta sección, tiene el siguiente atributo:
Atributo
Comando que efectúa
la transición.
Descripción
Valor de tipo entero que representa a una opción del menú o un
botón de la barra de botones.
36
Capítulo 4
Desarrollo del Sistema
Capítulo 4
DESARROLLO DEL SISTEMA
En este capítulo se describe el sistema GenViU a nivel conceptual y funcional. Como
punto de partida se explica la arquitectura general del sistema, describiendo cada uno de los
módulos que la constituyen, además se explican las estructuras de datos y la jerarquía de clases
que hacen posible la implementación del GenVIU.
37
Capitulo 4
4.1. Arquitectura del GenVIU
La figura 4.1.muestra la arquitectura del GenVIU, en la que se observa 10s módulos que
la integran, además de las interrelaciones que existentes entre ellos.
La GUI permite al usuario especificar el diseño de una IU, empleando menús de opciones
y botones que accionan operaciones de cada uno de los editores que integran al GenVIU. Por SU
parte el EditorIU integra las funciones que definen la forma de una 1U. La forma se define por
medio de recursos gráficos correspondientes a la plataforma Windows. El otro editor de la
herramienta es el EditorSE, que agrupa las funciones que permiten definir la secuencia de eventos
de una IU. Este editor utiliza los símbolos de los diagramas de transición de estados para
especificar el orden en que se ejecutarán las acciones a las que responde la forma de una IU.
Una vez especificado el diseño de una IU por medio de los dos editores, se procede a su
evaluación a través del módulo del precompilador del GenVIU que está integrado un analizador
léxico, sintáctico y semántico que se encargan de validar el diseño de una IU. En caso de que el
diseño sea correcto se procede a generar el código correspondiente en C t t por medio del módulo
Generador de código en C t t .
El GenVIU está fundamentada en la tecnologia de los Autómatas Finitos Deterministicos
(MD), el paradigma de programación visual y la programación Orientada a objetos. Así mismo,
en el diseño e implementación del GenVIU se emplean estructuras de datos, tales como: listas
enlazadas y arreglos dinámicos, con la finalidad de lograr una representación en memoria del
diseño de una IU. La finalidad de utilizar la tecnologia orientada a objetos es con el fin de lograr
un código extensible y de mantenimiento flexible. En las siguientes secciones se detalla la
funcionalidad de los módulos.
I
Generador de código en C + t
t
Precompilador del GeoVlU
Análisis Sintkttw y Semhtiw
Análisis L.5XiW
Gramática relaciond
Autómatas fmitos
deterministas
Esmcturas de
datos
SE
Programación
orientada a objetos
Figura 4.1. Arquitectura del GenVIU
38
Capítulo 4
4.1.1. GUI: Interfaz Gráfica de Usuario
La GUI proporciona el mecanismo de interacción y de navegación en la herramienta. Esta
interfaz incluye dentro de su forma (front end) elementos gráficos que forman parte de 10s
simbolos de la gramática del GenVIU. El objetivo principal de la GUI es proporcionar niveles de
transparencia en el flujo de datos entre cada uno de los módulos del sistema.
La interfaz facilita al usuario el diseño de una IU tanto en forma como en su secuencia de
eventos, esto se logra mediante dos configuraciones de la GUI, correspondientes a cada uno de
los editores del GenVIU respectivamente. inicialmente la GUI tiene la apariencia que muestra la
figura 4.2. Esta configuración esta asociada al editor de la forma de la interfaz.
Cuando finaliza la edición de la forma de la IU el usuario puede establecer la secuencia de
eventos asociada a la forma diseñada. Esta secuencia de eventos se edita por medio de la GUI que
se muestra en la figura 4.3.
Barra de botones: Cada botón está
asociado a una operación del editor
de la forma de una IU.
Ventana de edición de la
forma de una IU.
Opción que habilita el editor de la
secuencia de eventos de una N.
I
Figura 4.2. CUI del editor de la forma de una IU.
Después de haber contigurado la secuencia de eventos de una IU, se procede a verificar la
construcción del diagrama de transición de estados que especifica dicha secuencia, tal validación
se efectúa por medio del precompilador del GenVIU.
39
.
.
.Desarrollo del Sistema
Capitulo 4
4.1.2. Editor IU: Editor de la forma de una Iu
El editor IU permite construir el diseño de la forma de una IU en el GenVIU, empleando
wmo elementos básicos de construcción los siguientes Recursos Gráficos (RG). ventana, caja de
texto. caja de chequeo, botón circular, botón de comando, caja de diaogo, caja de entrada de
datos, menú de opciones, barra de botones, entre otros. A continuación se explican las
operaciones permitidas en el editor.
Nueva IU: Esta operación habilita una ventana nueva, en la cual se insertan los recursos gráficos
que se desean que formen parte de la IU.
Abrir diseño de I U Carga en las estructuras de datos correspondientes el diseño de una IU que
esta almacenada en un archivo de datos.
Guardar diseño de IU: Almacena en un archivo de datos el contenido de las estructuras de datos
que modelan el diseño de una IU (forma y secuencia de eventos).
Salir: Libera el espacio de memoria que ocupan las estructuras de datos y descarga de memoria
la aplicación.
Barra de botones Cada botón esta
asociado a una operación del editor
de la secuencia de eventos de una IU
I
Opción que habilita al
urecomvilador del GenVN
I
Figura 4.3. GUI del editor de la secuencia de eventos de una IU.
40
Capltulo 4
Insertar RG: Permite agregar un recurso grAko en la forma en diseño. Este proceso de
inserción se realiza mediante la técnica arrastrar y soltar, para esto se utiliza los botones que
aparecen de, bajo del menú de opciones del editor, en el que cada botón representa a un RG
disponible en el GenVIU.
Eliminar RG: Elimina de la forma y de las estructuras de datos correspondientes a un RG
seleccionado por medio del ratón.
Seleccionar RG: Marca con puntos el contorno de un recurso gráfico al pulsar sobre el recurso
deseado el botón derecho del ratón.
Mover RG: Habilita el cambio de posición a un RG seleccionado. Este proceso se efectúa por
medio de la técnica arrastrar y soltar.
Dimensionar RG: Modifica el tamaño de un RG seleccionado. El nuevo tamaño es especificado
por la nueva posición del contorno de la marca del RG, para desplazar el contorno se utiliza el
ratón y la técnica arrastrar y soltar.
Cuando se tiene un RG seleccionado y se pulsa dos veces el botón derecho del ratón se
activa la v'entana de propiedades del RG, en la cual se pueden modificar los valores de los
atributos que se deseen.
El editor IU opera sobre el registro AtrsVentana y las lista enlazadas: Dlgs, Recursos,
Menú e Iconos que se explican en la sección 4.2. del presente capítulo.
4.13. Editor SE: Editor de la secuencia de eventos de una IU
El editor SE permite definir la secuencia de eventos a los que debe responder la forma de
una IU diseñada en el GenVIU. La secuencia se define una vez que la forma de la interfaz ha
sido diseñada, en caso contrario el editor SE no se habilita.
Este editor utiliza como elementos básicos, los símbolos de los diagramas de transición de
estados para definir la secuencia. El proceso de definición emplea como nodo inicial el doble
círculo (bloque principal), ya que este símbolo debe aparecer una sola vez en la secuencia y el
círculo sencillo como cualquier otro nodo del diagrama (herramienta a vincular con la
aplicación). Las herramientas se asocian al bloque principal por medio de eventos especificados
por una transición. Esta transición se indica en el diagrama por medio de un arco que tiene
asociado un comando del menú o botón de acción de la interfaz. Al accionarse un comando de la
interfaz asociado a una transición se ejecuta la herramienta representada por el nodo donde
termina el arco.
Las operaciones que integra el editor SE son: insertar el bloque principal, insertar una
herramienta, insertar una transición, eliminar una herramienta de la secuencia, eliminar una
transición y generar el código de la forma y la secuencia de eventos de la interfaz diseñada.
41
.
Capitulo4
Insertar bloque principal: Agrega al diagrama de transición un nodo doble c k x l o . Este
símbolo representa el bloque principal de un ambiente integrado de software. Este nodo
únicamente se puede insertar una vez en el diagrama. Los atributos asociados al bloque principal
son: nombre de la aplicación y tipo de archivos a manipular por las herramientas a integrar.
Insertar una herramienta: Permite agregar un nodo sencillo al diagrama de transición. Un nodo
de este tipo representa una herramienta a integrar en el ambiente por medio de la IU. La
propiedad asociada a una herramienta es: nombre del archivo ejecutable (incluye ruta de
localización) que representa a dicha herramienta.
Insertar una transición: Agrega un arco al diagrama de transición. El proceso de inserción
consiste en: seleccionar un nodo inicial (nodo invocador) donde inicia el arco, posteriormente se
selecciona un nodo final (nodo invocado) donde finaliza el arco. Cabe aclarar que el invocador y
el invocado deben ser nodos distintos, además que, los nodos del diagrama de transición no deben
de quedar aislados, es decir, todo nodo debe tener asociado al menos una transición. Los atributos
asociados al símbolo arco son: tipo de acción a ejecutar (caja de diáiogo o archivo ejecutable) y
comando que ejecuta la transición.
Eliminar una herramienta: Elimina de la ventana de edición y de las estructuras de datos
correspondientes el nodo sencillo seleccionado.
Eliminar una transición: Elimina de la ventana de edición y de las estructuras de datos
correspondientes el arco seleccionado.
Mover nodo o arco: Habilita el cambio de posición de un elementos del diagrama de transición
de estados. Este proceso se realiza por medio de la técnica arrastrar y soltar.
Seleccionar nodo o arco: Marca con puntos el contorno de un nodo o arco al pulsar sobre el
símbolo deseado el botón derecho del ratón.
El editor SE opera sobre las listas enlazadas: ElemenDT y Relaciones que se explican en
la sección 4.2. del presente capítulo.
4.1.4. Precompilador del G e n W
Este módulo se encarga de validar el diseño de la Iü creada por medio de los editores
descritos anteriormente. Así mismo, se encarga de verificar y validar la sintaxis del diagrama de
transición de estados que define la secuencia de eventos de una IU. Para efectuar la verificación
y validación mencionada se utiliza: un analizador léxico, un analizador sintáctico y un analizador
semántico que operan sobre la gramática definida en el capítulo 3.
Analizador l6xico: Se encarga de agnipar los elementos del alfabeto del GenVIU empleados en
diseño de una IU. Además verifica que los grupos formados constituyan elementos básicos del
lenguaje definido por la gramática del GenVIU. Una vez que se reconocen todos los elementos
básicos se procede a la fase del analizador sintáctico.
42
Capítulo 4
Analizador Sintáctico: Valida que el diagrama de transición definida corresponda a una forma
válida en el lenguaje visual del GenVIU. Esta validación consiste en verificar el orden que ocupa
cada elemento del diagrama, en el cual, de antemano se sabe que no deben existir nodos aislados,
ni arcos que no finalicen en algún nodo. El análisis sintáctico utiliza las reglas de construcción
descritas en'el capítulo 3 y que forman parte de la gramática del GenVIU. En caso de que no
existan errores en el orden que deben de ocupar los elementos básicos del lenguaje se procede a
asociar un significado a la expresión visual reconocida.
Anaiiizador Sernántico: Asocia un significado a cada expresión visual construida por medio de
un diagrama de transición de estados. Esta asociación implica relacionar cada uno de los atributos
asociados a los elementos del diagrama de tal forma que en conjunto representen la integración
de diversas herramientas en un ambiente de desarrollo.
Cada uno de los analizadores e s t h implementados por las clases que se describen en la
sección 4.3 de este capítulo.
4.1.5. Generador de código del GenVIU
Este módulo genera el código fuente en lenguaje C++ del diseño de una IU construida en
el GenVIU. El código es generado cuando no existen errores sintácticos y semánticos en el
diseño y está estructurado en tres archivos: aplic.cpp, aplic.rc y aplic.rh.
El primer archivo contiene el código fuente tanto de la forma como de la secuencia de
eventos de la IU. El segundo archivo contiene la definición de los recursos gráficos que se
utilizan en el diseño de la interfaz. Por su parte, el tercer archivo contiene la definición de los
identifcadores de cada uno de los recursos gráficos, incluyendo opciones del menú y botones de
la barra de botones asociado al menú.
1
El código se genera recomendo las estructuras de datos descritas en la sección 4.2. y
seleccionando objetos OWL (Object Windows Library) según corresponda. Como el código
generado es código fuente y no objeto, la versión ejecutable del diseño de una IU se obtiene
compilando el código generado en la versión 4.5 o superior del Borland C++ para la plataforma
Win32, ya que utiliza tecnología de objetos y OWL proporcionados por esta herramienta. En el
capítulo 5, se muestran ejemplos del código generado por el GenVIU.
4.2. Estructuras de datos que maneja el GenVIU
El GenVIU está basado en diversas estructuras de datos que contienen la información
requerida para definir una IU para ambientes integrados de administración de software. A
continuación se describen las estructuras de datos empleadas por el sistema.
43
Capitulo 4
4.2.1. Estructuras de datos que maneja el editor de la forma de una Iu.
Repistro AtrsVentana
Esta estructura representa la información que define a una ventana gráfica al estilo de
Windows. Una instancia de este registro se utiliza para especificar a la ventana principal de la IU
diseñada en el sistema.
struct AtrsVentana
{
1;
unsigned int Posx;
unsigned int Posy;
unsigned int Altura;
unisgned int Anchura;
char Leyenda[lO];
char Tipo[20];
char CajMin[20];
char CajMax[20];
Posx: Variable de tipo entero sin signo que guarda la posición en X(co1umnas) que ocupa la
ventana principal de una aplicación, este valor está dado en relación al rango de coordenadas de
la pantalla.
Posy: Variable de tipo entero sin signo que guarda la posición en Y(fi1as o renglones) que ocupa
la ventana principal de una aplicación, este valor está dado en relación al rango de coordenadas
de la pantalla.
Altura: Variable de tipo entero sin signo que guarda la altura de la ventana principal de una
aplicación, este valor se emplea para determinar en que coordenada Y se termina de construir la
ventana de una aplicación, esto implica que la suma de Posy y Altura no sobrepase el rango de
coordenadas de la pantalla.
Anchura: Variable de tipo entero sin signo que guarda el ancho (longitud) de la ventana
principal de una aplicación, este valor se utiliza para determinar en que coordenada X se termina
de construir la ventana de una aplicación, esto implica que la suma de Posx y Anchura no
sobrepase el rango de coordenadas de la pantalla.
Leyenda: Cadena de caracteres que describe la etiqueta (título) asociado a la ventana principal
de una aplicación.
Tipo: Cadena de caracteres que describe el estilo correspondiente al tipo de ventana Windows
diseñado, dentro de los tipos disponibles tenemos:
44
Capltulo 4
WS:POPWWiNDOW
Crea una
ventana pop-up con los estilos:
WSBORDER, WSPOPUP Y WS-SYSMENU.
WS-DLGFRAME
Crea una ventana con doble borde y sin título.
WS-THICKFRAME
Crea una ventana con marco ajustable.
CajMin: Cadena de caracteres que describe el estilo de una ventana con botón de minimizar
ventana, este dato representa al estilo de una ventana Windows conocido como:
WS-MINIMIZEBOX.
CajMax: Cadena de caracteres que describe el estilo de una ventana con el botón de maximizar
ventana, este dato representa al estilo de una ventana Windows conocido como:
WS-MAXIMIZEBOX.
Lista enlazada DIES
La estructura de datos Dlgs agrupa la información referente a las cajas de diálogo
asociadas a una IU y a cada uno de los RG de dichas cajas de diálogo. La figura 4.4. muestra el
esquema conceptual de esta lista, en la cual se observa que la lista principal representa a las cajas
de diálogos y cada una de las sublistas a los RG de cada caja de diálogo. A continuación se
describe el registro AtrsDiulogo que constituye la información de cada nodo de la lista principal
de la lista Dlgs.
struct AtrsDialogo
{
f;
unsigned int Valide;
unsigned int Posx;
unsigned int Posy;
unsigned int Altura;
unisgned int Anchura;
char Nomlde[ZO];
char Leyenda[80];
char SysMen[ZO];
char CarLey[ZO];
Vaiide: Variable de tipo entero sin signo que guarda el valor del identificador de una caja de
diálogo, este valor permite referirse a dicha caja de diálogo dentro de una IU.
Posx: Variable de tipo entero sin signo que guarda la posición en X(co1umnas) que ocupa una
caja de diálogo, este valor está dado en relación al rango de coordenadas de la pantalla.
Posy: Variable de tipo entero sin signo que guarda la posición en Y (filas o renglones) que ocupa
una caja de diálogo, este valor tiene relación con el rango de coordenadas de la pantalla.
45
Capitulo4
'
Altura: Variable de tipo entero sin signo que guarda la altura de la ventana que representa a una
caja de diálogo, este valor se emplea para determinar en que coordenada Y se termina de
construir una caja de diálogo. La suma de Posy y Altura no debe sobrepasar el rango de
coordenadas de la pantalla.
Figura 4.4. Lista enlazada Dlgs
Anchura: Variable de tipo entero sin signo que guarda el ancho (longitud) de la ventana que
representa a una caja de diálogo, este valor se utiliza para determinar en que coordenada X se
termina de construir una caja de diálogo. La suma de Posx y Anchura no debe sobrepasar el
rango de coordenadas de la pantalla.
NomIde: Cadena de caracteres que describe el nombre del identificador de una caja de diálogo,
este nombre se utiliza en la generación de código para asociar una caja de diálogo con una
aplicación. NomIde representa el valor de ValIde.
Leyenda: Cadena de caracteres que describe la etiqueta (título) asociado con una caja de
diálogo.
SysMen: Cadena de caracteres que indica si una caja de diálogo tiene el estilo de una ventana
con sistema menú. En otras palabras, este dato representa a 1 estilo de una ventana Windows
conocido como: WS-SYSMENU.
46
Capihilo 4
CarLey: Cadena de caracteres que describe el estilo de una ventana con barra de título, en otras
palabras representa al estilo de ventana Windows conocido como: WSCAPTION.
I,
Lista enlazada Recursos
.
,,,
La estructura de datos Recursos agrupa la información referente a los RG asociados a la
ventana principal de la IU diseñada, La figura 4.5. muestra el esquema conceptual de esta lista, en
la cual se observa que el contenido de cada nodo es una instancia del registro AhsRectrrso,
adem& de que cada nodo representa a un RG diferente. A continuación se describe cada atributo
del regisgo AtrsRecurso; Cabe' aclarar que instancia. de este registro se utilizan como contenido
de los nodoc de las sublistas de la lista Dlgs.
NumRec: Variable de tipo entero sin signo que guarda el número secuencial que ocupa un RG
en la IU diseñada, este valor permite editar dicho RG.
VaUde: Variable de tipo.entero sin signo que guarda el valor del identificador del RG, este valor
permite asociar una acción semántica a dicho.recurso.
. .
Posx: Variable de tipo entero sin signo que guarda la posición en X(co1umnas) que ocupa un
RG, este valor está dado en relación al rango de coordenadas de la ventana en la que se asocia un
RG.
0
1
unsigned in1 NumRec;
mi@ in1 Vailde;
unsi& in! Posx;
unsigned in1 Posy; '
unsigned int Altura,
unirgned in1 Anchya;
unsigned in1 TipRec;
- chsNonilde[2O];
cherleyndaI801;~
char Visible[SO];
char Seltnb[201;
char Entilo[ZO]:
cha. AlinewionpO];
~
.
..
1;
Figura 4.5. Lista enlazada Recursos
Posy: Variable de tipo entero sin signo que guarda la posición en Y(fi1as o renglones) que ocupa
un RG, este valor está dado en relación al rango de coordenadas de la ventana en la que se asocia
un RG.
Capitulo 4
SSLEFT
Crea un rectángulo sencillo con texto
justificado a la izquierda dentro de dicho
rectángulo.
SS-SIMPLE
Crea un rectángulo sencillo con texto
justificado a la izquierda; el texto no se
puede modificar.
Alineación: Cadena de caracteres que indica el tipo de alineación de un RG, Las alineaciones
consideradas son: izquierda, centrada, derecha.
Lista enlazada Menú
Esta lista enlazada contiene en cada uno de sus nodos una instancia del registro
AtrsMenu. Esta estructura de datos permite representar el diseño de un menú de opciones
asociada a la ventana principal de una IU. Cada nodo de esta lista representa a una opción del
menú. La figura 4.6.muestra el esquema conceptual de la lista menú, en el que se observa que
cada nodo contiene una instancia del registro AtrsMenu. Por consiguiente a continuación se
describe cada atributo de este registro.
NumOpc: Variable de tipo entero sin signo que guarda el número secuencia1 que le corresponde
a una opción del menú de la IU en proceso de diseño, este valor permite referirse a una opción
dentro de la lista de opciones del menú para poder editarlo.
Padre: Variable de tipo entero sin signo que guarda el número secuencial de una opción padre
de otras opciones del mismo menú.
Nodo 3
...
Nodo n
Figura 4.6. Lista enlazada Menú
50
Capítulo 4
ValIde: Variable de tipo entero sin signo que guarda el valor del identificador de una opción del
menú, este valor permite asociar una acción semántica a dicha opción.
NomIde: Cadena de caracteres que desctibe el nombre del identificador de una opción del menú,
este dato se utiliza en la generación de código correspondiente al menú de una IU. NomIde
representa el valor de ValIde.
Leyenda: Cadena de caracteres que describe la etiqueta (leyenda) asociado a una opción del
menú de una IU.
Nodo2
I
Nodo 3
...
Nodo n
Figura 4.7. Lista enlazada Iconos
NomIde: Cadena de caracteres que describe el nombre del identificador de un archivo de mapa
de bits, este dato se utiliza en la generación de código correspondiente a la barra de iconos del
menú de una IU. NomIde representa el valor de Valide.
Nombre: Cadena de caracteres que describe el nombre lógico de un archivo de mapa de bits, este
dato permite editar un elemento de la barra de iconos del menú de una IU.
4.2.2. Estructuras de datos que maneja el editor de la secuencia de eventos de
una IU.
Lista enlazada ElemenDT
L a lista ElemenDT describe las propiedades de cada uno de los Elementos de un
Diagrama de Transición de estados (EDT). Esta estructura de datos es manipulada por el módulo
51
Capítulo 4
Nodo 3
...
Nodo n
TF'&tESI;
'
TPoinl EID;
char Levendal401:
Figura 4.8. Lista enlazada ElemenDT
E I D Variable de tipo TPoint que guarda el par de coordenada (x,y) correspondiente a la esquina
inferior derecha del rectángulo que sirve como referencia para dibujar cada EDT, este valor debe
estar dentro del rango de coordenadas de la ventana en la que se edita un EDT.
Leyenda: Cadena de caracteres que describe la etiqueta asociada a un EDT. Este dato permite
referirse a un elemento en la edición de la secuencia de eventos de una IU.
NomArchi: Cadena de caracteres que describe la ruta del archivo en formato ejecutable que
representa a una herramienta a integrar. Esto significa que cada nodo del diagrama de
transiciones representa a una herramienta.
52
Capítulo 4
Clase TDialog. Esta clase permite derivar clases que sirvan como cliente a las cajas de diálogo
que utiliza el GenVIU.
Clase TWindow. Esta clase permite crear y controlar una nueva ventana, ya sea una ventana de
edición o visualización de datos o gráficos.
“Module
I
TAppUwüon
I
I
TFnmewiodow
I
TBirMenoDlg
I
I
I
T A C ~ ~ D TVenIaaiDig
I ~
I
ThuMrDlg
1
I
TBarBmp
TNodonDlg
TAtrAplicsDlg
1
+ Herencia no virtual
.i‘Herencia virtual
Figura 4.10. Jerarquía de clases utilizadas en el GenVIU.
Clase TControl. Esta clase permite derivar una nueva clase que genera y controla un nuevo
recurso gráfico al estilo de Windows.
Clase TListBox. Esta clase permite derivar una nueva clase que crea y controla a una ventana de
visualización de datos. En esta ventana los datos se visualizan en forma de una lista de datos.
54
Capitulo 4
Clase TMiMChiíd. Esta clase permite derivar una nueva clase que crea y controla a una ventana
de tipo MDI (interfaz con múltiples documentos). Este tipo de ventana sirve como un contenedor
de ventanas hijas.
A continuación se describen las clases más importantes que se derivan a partir de las
clases OWL.
4.3.1. Clase TGenVIUApp: Crea y controla el ambiente GenViU
Esta clase se deriva a partir de la clase TApplication, la figura 4.1 1 muestra un esquema
conceptual de esta nueva clase. En dicha figura se puede observar que dicha clase contiene datos
y funciones miembros del tipo público y protegido. A continuación se da una breve explicación
de cada uno de los elementos que integran a la clase TGenVIUApp.
Datos miembro
AcercaDlg: Apuntador al tipo de dato definido por la clase TAcercaDlg, este apuntador permite
crear la caja de diálogo que visualiza la información acerca de ... del GenVIU.
Cliente: Apuntador al tipo de dato definido por la clase Ventanacliente, la cual es una clase
derivada a partir de la clase OWL TMDIClient, este apuntador permite crear y manipular una
ventana del tipo MDI (Interfaz con múltiples documentos).
Frame: Apuntador al tipo de dato definido por la clase OWL TDecoratedFrame. Esta variable
permite crear y manipular una ventana que puede ser decorada, en otras palabras, se le puede
asociar una barra de bitmaps deslizable.
ControlBar: Apuntador al tipo de dato definido por la clase OWL TcontrolBar. Esta variable
permite agregar y quitar bitmaps a una barra de bitmaps de un menú.
ControlBarLoc: Variable de tipo entero que indica la dirección de deslizamiento de la barra de
bitmaps en la ventana principal del GenVIU.
Funciones miembro
TGenVIUApp: Constnictor de la clase, recibe como argumento el texto a colocar en la barra de
título de la ventana que se crea.
-TGenVIUApp: Destructor de la clase. Libera el espacio de memoria que ocupan los datos
dinámicos declarados en la clase.
InitMainWindow: Función heredada de la clase TApplication. Esta función se redefine con la
finalidad de que se genere una nueva ventana de aplicación con los atributos especificados.
55
Capitulo 4
CmAcerca: Ejecuta la caja de diálogo que muestra la información acerca de ... correspondiente
al GenVIU.
CmSalir: Ejecuta ;a opción de salir del ambiente GenVIU
CmAbrir: Permite abrir un archivo de edición de una IU, Esta función se encarga de solicitar el
archivo a abrir y posteriormente carga las estructuras de datos con la información contenida en el
archivo especificado con la finalidad de que una iü se pueda modificar.
CmBorrarRG: Borra un RG previamente seleccionado, este proceso de eliminación consiste en
borrar del contexto de dispositivo de la ventana el RG deseado, además de actualizar las
estructuras de datos correspondientes.
CmGuardar: Permite la permanencia de la iü diseñada, es decir, almacena en un archivo
especificado el contenido de la estructuras de datos que describen a la forma y semántica de una
IU.
CmDlg: Ejecuta la opción de crear una ventana que representa a una caja de diálogo a diseñar
por el programador.
CmIconos: Ejecuta la opción que crea una barra de bitmaps asociados al menú de opciones de la
Tu diseñada.
CmBotones: Ejecuta la opción que crea un RG de tipo botón pushbutton en la ventana que
representa a la ventana principal de la aplicación en diseño, o en su caso en la ventana que
representa a una caja de diálogo asociada a la aplicación en diseño. Esta función manipula la lista
de los recursos gráficos diseñados. Por otro lado, cuando el RG asocia a una caja de diálogo esta
función manipula la lista de lisias que representa el diseño de una caja de diálogo.
CmCajDato: Ejecuta la opción que crea un RG de tipo botón check box en la ventana principal
de la aplicación en diseño, o en su caso en una caja de diálogo asociada a la aplicación en diseño.
Esta función manipula la lista de los recursos gráficos diseñados. Por otro lado, cuando el RG
asocia a una caja de diálogo esta función manipula la lista de listas que representa el diseño de
una caja de diálogo.
CmCirDato: Ejecuta la opción que crea un RG de tipo botón circular en la ventana principal de
la aplicación en diseño, o en su caso en una caja de diálogo asociada a la aplicación en diseño.
Esta función manipla la lista de los recursos gráfkos diseñados. Por otro lado, cuando el RG
asocia a una caja de diálogo esta función manipula la lista de lisias que representa el diseño de
una caja de diálogo.
CmEntDato: Ejecuta la opción que crea un RG de tipo caja de edición (entrada / visualización
de datos) en la ventana principal de la aplicación en diseño, o en su caso en una caja de diálogo
asociada a la aplicación en diseño. Esta función manipula la lista de los recursos gráficos
diseñados. Por otro lado, cuando el RG asocia a una caja de diálogo esta función manipula la lista
de listas que representa el diseño de una caja de diálogo.
57
Capitulo 4
CmDesDato: Ejecuta la opción que crea un RG de tipo caja de visualización de datos (listbox) en
la ventana principal de la aplicación en diseño, o en su caso en una caja de diálogo asociada a la
aplicación en diseño. Esta función manipula la lista de los recursos gráficos diseñados. Por otro
lado, cuando el RG asocia a una caja de diálogo esta función manipula la lista de listas que
representa el diseño de una caja de diálogo.
CmTexto: Ejecuta la opción que crea un RG de tipo caja de visualización de texto (static) en la
ventana principal de la aplicación en diseño, o en su caso en una caja de diálogo asociada a la
aplicación en diseño. Esta función manipula la lista de los recursos gráficos diseñados. Por otro
lado, cuando el RG asocia a una caja de diálogo esta función manipula la lista de listas que
representa el diseño de una caja de diálogo.
CmMenu: Ejecuta la opción que crea una barra de menú de opciones asociada a la ventana
principal de la aplicación en diseño. Esta función manipula la lista de las opciones del menú.
CmVentana: Ejecuta la opción que crea una nueva aplicación (IU para un ambiente integrado).
Esta función guarda las características de la ventana principal de la aplicación en una variable
global de tipo struct AtrsVentana, para que posteriormente se guarde en un archivo.
CmDefDlg: Permite definir la secuencia de eventos asociada a la forma de una IU. Esta función
manipula la lista de elementos de un diagrama de transición de estados y la lista de relaciones
que se establecen por medio de los arcos del diagrama diseñado.
CmNodoDT: Crea un nodo sencillo que forma parte del diseño del diagrama de transición de
estados que representa la secuencia de eventos de una IU. Esta función manipula la lista de
elementos de un diagrama de transición de estados.
CmNodoDcDT: Permite crear únicamente un nodo doble círculo como elemento de un diagrama
de transición de estados. Este nodo representa la aplicación principal, a partir del cual se deriva la
secuencia de eventos a las otras herramientas a integrar en un ambiente. Esta función manipula la
lista de elementos de un diagrama de transición de estados.
CmArcoDT: Permite crear un arco (flecha) como elemento de un diagrama de transición de
estados. Este arco permite establecer el enlace (comunicación) entre las herramientas a integrar.
Esta función manipula la lista de elementos de un diagrama de transición de estados.
CmGenCod: Verifica si el diseño no tiene errores y procede a generar el código en lenguaje C++
para Windows correspondiente a la IU diseñada. Esta generación de código se efectúa mediante
la invocación de las funciones Genera-CodMenu y Genera-CodApl.
CmToggleBar: Permite desplazar la barra de bitmaps asociado al menú del GenVIU en las
siguientes direcciones: Parte superior de la ventana, lado izquierdo de la ventana, así como el
lado derecho de la ventana.
GuardAtr: Guarda en una variable de tipo struct AtrsRecurso los atributos por defecto de un
RG al estilo de Windows.
58
Capítulo 4
. _.
.
GeneraCodMenu: Genera el código en lenguaje C+t para Windows del menú de opciones
asociado a la IU diseñada. Esta función manipula la lista de opciones del menú.
Genera-CodApl: Genera el código en lenguaje C++ para Windows de la forma de la IU, así
como de la secuencia de eventos a los que responderá dicha forma. Esta función manipula las
listas descritas en la sección 4.2. de este capítulo.
Es-Un-Nodo: Verifica si el elemento de un diagrama de transición de estados es un nodo o un
arco. Esta función manipula la lista de EDT.
Verifica-DT: Verifica si el diagrama de transición de estados definido esta bien formado en
cuanto a las relación entre cada una de las herramientas a integrar en una ambiente. Esta función
manipula la lista de elementos de un diagrama de transición de estados.
4.3.2. Clase Micontrol: Crea y maneja un control (recurso gráfico)
La clase Micontrol se deriva a partir de la clase TControl. Esta clase se emplea para crear
y controlar recursos gráficos tales como: botones de tipo pushbutton, radio botones, cajas de
chequeo de datos, cajas de visualización de datos (listbox), entre otros.
En la figura 4.12 se muestra un esquema conceptual de la clase Micontrol. En dicho
esquema se puede observar que esta clase contiene los elementos que a continuación se
describen.
Datos miembro
Padre: Apuntador al tipo de dato definido por la clase TWindow, esta variable guarda una liga a
la ventana en la que se asocia un control que representa a un RG.
AtrsCtrl: Variable de tipo síruct AfrsRecurso. Esta variable guarda los atributos asignados por
el programador al RG en edición.
Control: Vanable de tipo union TipoDeConhol. Esta variable contiene un apuntador al tipo de
RG diseñado.
Funciones miembro
Micontrol: Esta clase tiene tres tipos de consiructor, que se describen a continuación:
a). MiConrrolO. Es un constructor por defecto, con valores por defecto de un control.
b). MiControI(MiControl&). Es un constructor tipo copia que permite crear un nuevo confrol a
partir de uno ya existente.
59
Capitulo 4
4.3.3. Clase EditorIU: Crea y controla el editor de interfaces al usuario
La clase EditorIU se deriva a partir de la clase TMDIChild. Esta clase se emplea para
crear y controlar un editor de formas de IU para el dominio especificado en el capítulo 1. Este
editor no soporta la edición de la semántica asociada a dicha forma.
En la figura 4.13 se muestra un modelo conceptual de la clase EditorIU. En este esquema
se puede observar que esta clase contiene los elementos que a continuación se describen.
Datos miembro
AtrsRG: Variable de tipo struct AtrsRecurso. Esta variable almacena los atributos del RG
seleccionado.
ControlRG: Apuntador al tipo de dato definido por la clase Micontrol. Esta variable crea y
manipula un control (ventana) para un RG.
Dc: Apuntador al tipo de dato definido por la clase OWL TDC. Esta variable permite manipular
el contexto de dispositivo de la ventana del editor de IU, esto permite editar RG asociados a dicha
ventana.
Menu: Apuntador al tipo de dato definido por la clase OWL TMenu. Esta variable permite crear
y manipular un menú para asociarlo a una Iü.
Seleccionado: Variable de tipo lógico (bool). Esta variable indica si un RG está seleccionado, el
valor de seleccionado se utiliza para efectuar diversas operaciones en el editor de la forma de IU.
ActDecora: Variable de tipo lógico (bool). Esta variable indica en que momento en necesario
actualizar la barra de bitmaps del menú del GenVIU.
MoverRG: Variable de tipo lógico (bool). Esta variable indica si el RG seleccionado puede ser
desplazado sobre la ventana en edición.
AmpliarRG: Variable de tipo lógico (bool). Esta variable indica si el RG seleccionado puede ser
ampliado de tamaño.
CursorActual: Variable de tipo entero sin signo que guarda el identificador del cursor actual
utilizado en edición.
61
Capitulo 4
-
TMDlClienI
Char T i l
- EditorlU
1
1
Owncreate
1-(
Clase " EditorlU "
IDisena-Menu
)
ILimpia7AtrsRG
Limpia-Banderas]
1 EvNLBunonDown 1
L EvLBunmDown
1
EvLBunpnDblClkJ
AtrsRecursa
MiControl
TDC
TMenu
Bml
BWl
Ba>l
Bml
Unsigned in1
Unsigned int
Unsigned ¡ni
AtrsRG
*Con~olRG
*dc
'Menu
Seleccionado
ActDecora
MoverRG
AmpliarRG
CursorActuaJ
Despx
bSPY
In1 NumRG
Unsigned u11
Int NinnRG
Char'ldenl
Unrigned in1
Char 'Idem
AmDialaga
Borra-Marca
-r'
Amüialogo
EvLBunonUp
Figura 4.13 Modelo conceptual de la clase EditorIU.
Despx: Variable de tipo entero sin signo que guarda la diferencia en pixeles entre la posición del
cursor en X dentro del control del RG y la posición de origen en X del control del RG. Este valor
se utiliza en la actualización de la posición del RG dentro de la ventana en diseño.
Despy: Variable de tipo entero sin signo que guarda la diferencia en pixeles entre la posición del
cursor en Y dentro del control del RG y la posición de origen en Y del control del RG. Este valor
se utiliza en la actualización de la posición del RG dentro de la ventana en diseño.
Funciones miembro
EditorIU: Constructor de la clase, recibe como argumento un apuntador a la ventana cliente MDI
y el título de la ventana a crear. Esta función inicializa los datos miembros de esta clase.
-EditorIU: Destructor de la clase. Libera el espacio de memoria que ocupan los datos dinámicos
declarados en la clase.
Owncreate: Esta función crear una ventana hija con las caractm'sticas de una ventana MDI.
62
Capíiulo 4
OwnSetupWindow: inicializa los atributos y objetos de la ventana hija creada mediante una
instancia de esta clase.
Crea-DC: Crea una instancia al contexto de dispositivo de la ventana hija M ü I creada. En esta
función se asigna a dc la instancia creada.
Dibuja-Marca: Dibuja la marca correspondiente al RG seleccionado dentro de la ventana de
edición, la marca consiste en un recuadro con borde grueso. La posición del RG se utiliza como
referencia para dibujar la marca.
DibujaContornos: Dibuja los contornos de los RG diseñados en la ventana ile edición, el
contorno consiste en recuadro con borde sencillo. La posición del RG se utiliza como referencia
para dibujar el contorno.
DisenaMenu: Controla la edición del menú asociado a la IU.
BorrarRG: Borra el área del contexto de dispositivo que ocupa el RG seleccionado, además
actualiza la lista de recursos gráficos.
Disena-BarraBmp: Controla la edición de la barra de bitmaps asociado al menú.
Localiza-RG: Localiza en la lista de controles el RG seleccionado, esta localización se efectúa
considerando el número secuencial que ocupa el RG en el diseño de la IU.
Localiza-AtrRG: Localiza en la lista de recursos gráficos los atributos del RG seleccionado,
esta localización se efectúa considerando el número secuencial que ocupa el RG en el diseño de
la IU.
Localiza-CajaDlg: Localiza en la lista de listas la caja de diálogo en edición, esta localización se
efectúa considerando el nombre del identificador de la caja de diálogo.
Regresa-AtrDlg: Regresa al editor los atributos de la caja de diálogo en edición
Localiza-RGDlg: Localiza en la lista de listas el RG seleccionado correspondiente a la caja de
diálogo en edición, esta localización se efectúa considerando el nombre del identificador de la
caja de diálogo y el número secuencia1 que ocupa el RG.
EvNCLButtonDblClk Heredada de la clase TWindow. Esta función responde al evento
WM-NCLBUTTONDBLCLK cuando se pulsa dos veces el botón izquierdo del ratón en el área
no cliente de la ventana en edición. Además de responder al evento ya mencionado, esta función
invoca a la caja de diálogo que permite especificar los atributos de una ventana.
EvNCLButionDown: Heredada de la clase TWindow. Esta función responde al evento
WM-NCLBUTTONDOWN cuando se suelta el botón izquierdo en el área no cliente de la
ventana en edición.
63
Capitulo 4
EvMouseMove: Heredada de la clase TWindow. Esta función responde al evento
WMMOUSEMOVE cuando de mueve el puntero del Mouse. Además de responder al evento ya
mencionado, esta función actualiza tanto el refresco del contexto de dispositivo como la lista de
recursos gráficos y la lista de controles, ya que al mover el Mouse teniendo oprimido el botón
izquierdo sobre un RG, éste se mueve.
EvLButíonDown: Heredada de la clase TWindow. Esta función responde al evento
WM-LBUTTONDOWN cuando se pulsa el botón izquierdo. Además de responder al evento ya
mencionado, esta función guarda las coordenadas que ocupa un RG dentro del contexto de
dispositivo de la ventana en edición.
EvLButtonUp: Heredada de la clase TWindow. Esta función responde al evento
WM-LBUTTONUP cuando se suelta el botón izquierdo. Además de responder al evento ya
mencionado, esta función actualiza los valores en la lista de recursos gráficos y en la lista de
controles, ya que al soltar el botón del Mouse se detiene el diseño de un RG.
EvLButtonDbiCik Heredada de la clase TWindow. Esta función responde al evento
WM-LBUTTONDBLCLK cuando se pulsa dos veces el botón izquierdo del ratón. Además de
responder al evento ya mencionado, esta función invoca a la caja de diálogo en donde se
especifican los atributos de RG.
4.3.4. Clase EditorSE: Crea y controla el editor de secuencias de eventos de la
IU diseñada.
La clase EditorSE se deriva a partir de la clase TMDIChild. Esta clase se emplea para
crear y controlar un editor de secuencias de eventos que se asocia a una forma de IU. En este
editor se emplea la tecnología de la transición de estados por medio de su representación gráfica.
En la figura 4.14 se muestra un esquema conceptual de la clase EditorSE. En dicho esquema se
puede observar que esta clase contiene los elementos que a continuación se describen.
Datos miembro
AtrsEDT: Variable de tipo struct AtrsElemenDT. Esta variable almacena los atributos del EDT
seleccionado.
Dc: Apuntador al tipo de dato definido por la clase OWL TDC. Esta variable permite manipular
el contexto de dispositivo de la ventana del editor de secuencias de eventos de una IU, esto
permite editar los elementos de un diagrama de transición de estados.
Seleccionado: Variable de tipo lógico (bool). Esta variable indica si un EDT está seleccionado,
el valor de seleccionado se utiliza para efectuar diversas operaciones en el editor de la secuencia
de eventos de una Iu.
II
64
Capitulo 4
char 'Tlt
TMDIClienl
dz
Owncreate
COLORREF
AmElmcnDT
IntNumRG
Unsigned int Tipo
Clase " EditorSE "
AIxElemenlDT
TComandoDlg
TNodosDlg
TTipoRepreDlg
TDC
Boo1
Boo1
AusEDT
Tomand
'ADNodoDlg
*TipRepDlg
*dc
Boo1
Roo1
Bo01
Unsigned in1
Unsigned int
AmpliarEDT
ActivaCreaEDT
EsArw
CutsorActual
Despx
&spy
BoOl
EvNLButtonDown
EvLButtonDblClk
Unsigned mi
c IntNurnEDT
Unsigned in1
unsigned int x,Y
Unsigned in1
Seleccionado
AnDewra
MoverEDT
AmElemenDT
EvMouseMove
Figura 4.14 Modelo conceptual de la clase EditorSE.
ActDecora: Variable de tipo lógico (bool). Esta variable indica en que momento en necesario
actualizar la barra de bitmaps del menú del GenVIU.
MoverEDT: Variable de tipo lógico (bool). Esta variable indica si el EDT seleccionado puede
ser desplazado sobre la ventana en edición.
AmpliarEDT: Variable de tipo lógico (bool). Esta variable indica si el EDT seleccionado puede
ser ampliado de tamaño.
ActivaCreaEDT: Variable de tipo lógico (bool). Esta variable indica si es posible crea un nuevo
r
EDT.
EsArco: Variable de tipo lógico (bool). Esta variable posibilita especificar un enlace entre dos
herramientas que forman parte de la integración de una de aplicaciones.
CursorActual: Variable de tipo entero sin signo que guarda el identificador del cursor actual
utilizado en edición.
65
I
Capítulo 4
Despx: Variable de tipo entero sin signo que guarda la diferencia en pixeles entre la posición del
cursor en X dentro del recuadro del EDT y la posición de origen en X del recuadro del EDT. Este
valor se utiliza en la acíuaiización de la posición del EDT dentro de la ventana en edición.
Despy: Variable de tipo entero sin signo que guarda la diferencia en pixeles entre la posición del
cursor en Y dentro del recuadro del EDT y la posición de origen en Y del recuadro del EDT. Este
valor se utiliza en la actualización de la posición del EDT dentro de la ventana en edición.
Funciones miembro
EditorSE: Constructor de la clase, recibe como argumento un apuntador a la ventana cliente
MDI y el título de la ventana a crear. Esta función inicializa los datos miembros de esta clase.
-EditorSE: Destructor de la clase. Libera el espacio de memoria que ocupan los datos
dinámicos declarados en la clase.
Owncreate: Esta función crea una ventana hija con las caractensticas de una ventana MDI.
OwnSetupWindow: inicializa los atributos y objetos de la ventana hija creada mediante una
instancia de esta clase.
Crea-DC: Crea una instancia al contexto de dispositivo de la ventana hija MDI creada. En esta
función se asigna a la variable dc la instancia creada.
DibujaEDT: Dibuja el EDT según los atributos especificados por el argumento del tipo sfruct
AtrsEZemenDT que recibe la función.
ReDibuja-EDT: Actualiza los EDT en el contexto de dispositivo de la ventana de edición, esta
actualización se efectúa cuando la ventana cambia de tamaño o se modifica el contenido de la
ventana.
Crea-EDT: Crea un nuevo EDT y lo inserta en la lista de EDT para poder manipularlo
posteriormente.
BorraEDT: Borra el área del contexto de dispositivo que ocupa el RG seleccionado, además
actualiza la lista de recursos gráficos.
Dibuja-Marca: Dibuja la marca correspondiente al EDT seleccionado dentro de la ventana de
edición, la marca consiste en un recuadro con borde sencillo. La posición del EDT se utiliza
como referencia para dibujar la marca.
Localiza-EDT: Localiza en la lista de EDT el EDT seleccionado, esta localización se efectúa
considerando el número secuencia1 que ocupa el EDT en la definición de la secuencia de eventos
de una iü.
18
66
Capitulo 4
Limpia-AreaEDT: Borra el área del contexto de dispositivo ocupado por el EDT seleccionado.
Esta función utiliza como referencia la posición del EDT.
Asigna-ValoresEDT: Asigna los valores de los atributos de un EDT a la vanable protegida
AtrsEDT para su posterior manipulación.
LimpiaBanderas: Inicializa con los valores por defecto el contenido de la variables protegidas
de tipo bool.
EvMouseMove: Heredada de la clase TWindow. Esta función responde al evento
WM-MOUSEMOVE cuando de mueve el puntero del Mouse. Además de responder al evento ya
mencionado, esta función actualiza tanto el refresco del contexto de dispositivo como la lista de
EDT, ya que al mover el Mouse teniendo oprimido el botón izquierdo sobre un EDT, éste se
mueve.
EvLButtonDown: Heredada de la clase TWindow. Esta función responde al evento
WMLBUTTONDOWN cuando se pulsa el botón izquierdo. Además de responder al evento ya
mencionado, esta función guarda las coordenadas que ocupa un EDT dentro del contexto de
dispositivo de la ventana de edición.
EvLButtonUp: Heredada de la clase TWindow. Esta función responde al evento
WMLBUTTONUP cuando se suelta el botón izquierdo. Además de responder al evento ya
mencionado, esta función actualiza los valores en la lista de EDT, ya que al soltar el botón del
Mouse se detiene el diseño de un EDT.
EvLButtonDblClk: Heredada de la clase TWindow. Esta función responde al evento
WMLBUTTONDBLCLK cuando se pulsa dos veces el botón izquierdo del ratón. Además de
responder al evento ya mencionado, esta función invoca a la caja de diálogo en donde se
especifican los atributos asociados a un EDT.
4.3.5. Clase VentanaMsg: Crea una ventana para visualizar los mensajes de
error
La clase VentanaMsg se deriva a partir de la clase TMDIChild. Esta clase se emplea para
crear una ventana en la que se visualiza los mensajes de error que se presentan en la
interpretación de la IU diseñada. Los errores detectados se almacenan en un archivo del cual se
recuperan para ser visualizados en la ventana creada por esta clase.
La figura 4.15 muestra un modelo conceptual de la clase VentanaMsg. En dicho esquema
se puede observar que esta clase contiene los elementos que a continuación se describen.
61
Capitulo 5
Capítulo 5
Plan de Pruebas
II
'I
I!
I!
PLAN DE PRUEBAS
En este capítulo se describen las pruebas aplicadas al sistema GenViü. Las pruebas se
centran en la funcionalidad del sistema con el fin de probar la hipótesis planteada en este trabajo.
Como casos de prueba se eligieron tres situaciones: la primera consiste en diseñar la interfaz del
AMASS (Ambiente Integrado de Soporte para la Administración y desarrollo de Sistemas de
Software) y de integrar las herramientas que la componen por medio de la IU, el segundo caso
consiste en crear una IU que permita acceder a siete herramientas que manejan el mismo formato
de datos, por último el tercer caso, consiste en diseñar una ILT que agrupe las herramientas del
Microsoft Office.
,
69
Capítulo 5
Plan de Pruebas
5.1. Objetivo
I
Comprobar que el uso del GenViü disminuye el tiempo de desarrollo de IU (tanto en su
forma como en la definición de su secuencia de eventos) para el dominio especificado en esta
tesis.
Otro objetivo consiste en comprobar que los diagramas de transición de estados describen
con claridad la secuencia de evenfk a los que debe responder una ni.
5.2. Resultado esperado
'
Disminución de esfuerzo en el desarrollo de iü para ambientes integrados de
administración de software. El esfuerzo se mide en cuanto al tiempo de construcción y los
conocimientos técnicos requeridos para desarrollar una interfaz en el GenVIU, considerando que
en el diseño no interviene código t&xtualen algún lenguaje de programación.
5.3. Resultado real
Se obtuvieron resultados satisfactorios con lo cual se alcanzaron los objetivos planteados
en la sección 5.1. Cabe aclarar que ,estos resultados se lograron a partir de la suposición de que el
usuario debe conocer el formalismo para construir diagramas de transición de estados finitos
determinísticos, ya que el lenguaje visual del GenVIU utiliza la simbología de estos diagramas
para definir la secuencia de eventos de una KJ.
Con el empleo del G e n W se l o p disminuir el tiempo de desarrollo de IU, tal y como lo
muestran los casos de prueba, ya que al definir de manera visual la secuencia de eventos a los que
debe responder una interfaz para el dominio especificado en esta tesis, no se tiene que dominar el
estilo de programación de un lenguaje textual anfitrión para lograr tal definición. Esto facilita
mucho el desarrollo de aplicaciones!
Cabe mencionar que las iü construidas en el GenVIU no integran herramientas en un
ambiente, ya que no validan la comunicación de datos entre herramientas. Sino que Únicamente
validan los datos que se comunican de la ventana principal a cada una de las herramientas y no
los datos que se comunican entre las propias herramientas.
5.4. Casos de prueba
Los casos de prueba que a cbntinuación se describen permitieron validar que los objetivos
y las hipótesis planteadas en esta tesis se alcanzaran. Cada caso consta de dos partes: la primera
concierne a la forma de la Iü y la segunda a la secuencia de eventos asociada a dicha forma.
Como resultado de cada caso, se tiene el código en C++ con OWL que genera la Tu especificada
en cada una de las tres situaciones probadas en esta sección.
I
70
b
Capítulo 5
Plan de Pruebas
I/
2. SisRec
3. DocProg
I)
I
5.4.1.5. Transiciones que definen la secuencia de eventos de la interfaz
1
I1
Las transiciones en cada uno de los casos se especifican bajo el siguiente formato:
I/
(nodo invocador, evento o comando de transición, nodo invocado)
Las transiciones que definen esta secuencia son.
1. (Ventana principal, Opc'bn Leviss, Ejecución de la herramienta Leviss)
2. (Ventana principal, Opción SisRec, Ejecución de la herramienta SisRec)
3. (Ventana principal, Opción DocProg, Ejecución de la herramienta DocProg)
4. (Herramienta Leviss, Opción SisRec, Ejecución de la herramienta SisRec)
5. (Herramienta SisRec, Opción DocProg, Ejecución de la herramienta DocProg)
I1
5.4.1.6. Proceso de construcción
I/
La figura-5.1. muestra como queda el diseño del menú de opciones de la interfaz de
usuario del AMASS. En esta figura se observa que por medio de una caja de diálogo se insertan
las opciones en el menú sin necesidad de emplear código textual para especificarla.
Por su parte la figura 5.2. muestra como quedan integrado los elementos de la barra de
botones asociado al menú de opciones. Cabe aclarar que los botones contienen imágenes de
mapas de bits que el usuario tiene que especificar por medio de la caja de diálogo que se muestra
en la figura 5.3.
I/
Después de diseñar el menú 'de opciones y la barra de botones se procede a especificar las
transiciones descritas en la sección 5.4.1.2. Estas transiciones se detallan por medio de un
diagrama de transición de estados tal y como se muestra en la figura 5.4.
I1
AI diseñar el diagrama de la ,secuencia de eventos de la interfaz, se debe asignar valores a
cada uno de los atributos asociados a los símbolos del diagrama, esto con el fin de que al verificar
el diseño del diagrama y generar el código de la I
U no se presenten errores por la ausencia de
valores en los atributos.
La figura 5.5. muestra los valores asignados al símbolo doble círculo del diagrama. Este
símbolo en cualquier diseño representa al bloque principal de una Iü.
!I
!I
72
Capitulo 5
Plan de Pruebas
gpcioner del menu
flN SUBMENU Archivo
SUBMENU Hensriientas
OPCiON L a i r s
OPaON C i d l e c
OPClONDocProg
flN SUBMENU Hmamientat
I
'(
Lf
Figura 5.1) Diseño del menú de opciones del AMASS.
1
I
Figura 5.2. Diseño de la barra de botones del AMASS.
L!
Capitulo 5
I1
Plan de Pruebas
1
!I, lsirrec
I
II
Figura 5.7. Especificación del nombre de la herramienta asociado a un nodosencillo del
diagrama.
i
11
Figura 5.8. Acción asociada a un nodo sencillo del diagrama.
I
I1
Figura 5.9. Indicación de que el código de la IU diseñada se ha creado con éxito.
Ir
Cuando finaliza el diseño di'la IU tanto en su forma (ventana, menú y barra de botones) y
en su secuencia de eventos asociado (diagrama de transición de estados), se procede a evaluar el
diseño de tal forma que el códigd generado del diseño sea correcto. Es decir, se evalúa el
diagrama de transición de estados que especifica la secuencia de eventos. La evaluación consiste
en verificar que no existan nodos aihados, arcos que no terminen en algún nodo y atributos que
no tengan valores obligatorios asignados. En caso detectar alguno de estos errores, el código no se
genera quedando a responsabilidad del usuario corregir tales errores. En este caso el diseño es
correcto, por lo tanto se genera el código y se muestra un ventana de mensaje como el de la figura
5.9.
li
I,
76
Capitulo 5
Plan de Pniebas
,I
5.4.1.7. Código del diseño especificado e IU producida
71
En esta sección se muestra el código generado a partir del diseño descrito en este caso, el
cual produce la IU del AMASS.
El código esta agrupado en tres archivos: aplic.cpp, aplic.rc y aplicxh, que en conjunto al
compilarse y ligarse producen laslinterfaz para este caso. El archivo Aplic.rh se omite ya que
únicamente contiene los valores de los identificadores de cada una de las opciones del menú y de
la barra de botones.
II
Archivo: Aplic.cpp
'I
Contiene el código fuente generado a partir del diseño de la IU especificada en la sección
anterior.
1
Ptt* Archivos de cabecera incluidos por el generador del código del GenVlU ***/
#include <owl\window.h>
I\
#include <owl\applicat.h>
#include <owl\buttonga.h>
II
#include awl\controlb.h>
#include <owl\opensave.h>
#include <owl\decúame.h>
II
#include <owl\static.h>
#include <string.h>
!, . .
#include Qtdio.h>
#include "Aplic.rh"
/*** Variables que manipulan la barra de botones
TButtonGadget' Bms[4];
TDecoratedFrame 'Frameglo;
I**/
b**Funci4n que crea la barra de botones de la 1U ***/
static TContro¡Bar*
BuildControlBar(TWindow* parent, TConbolBar::TTileDirection direction) {
TControlBar* cb = new TConbolBarO>arent. direction);
Bms[O] = new TButtonCadget(lDC-OPC~ON5,lDC~OF'ClON5);
Btns[ 11 = new TButtonGadget(IDC-OPCiON6,IDC_OPCION6);
Bmsp] = new TButtonGadget(IDC~OPC1ON7,IDC~OPCiON7);
1
cb->Insert(*Btns[O]);
cb->lnsert(*Bms[ I]);
cb>lnsert(*Bms[2]);
ch->Attr.Style (=WS-CLIPSIBLINGS;
cb->Attr.Id = IDW-TOOLBAR;
r e m cb;
}
f.** Función que pemite cambiar la localiyción de la barra de botones
const TDecoratedFrame :: TLocation Location[] = {
***/
TDecoratedFrame :: Top,
TDecoratedFrame ::Left,
71
Capitulo 5
l8 Opción Dochog *I
Plan de Pruebas
I
void MiVentana::CmOpcionS() (
WinExec("c:\\docprog.exe",SW-SHOW);
f
11
I* Clase que controla a la aplicacion construida
*/
class MiAplicacion : public Tapplication (
protected:
TControlBar* ControlBar;
int ControlBarhc;
public:
il
I' Constructor de esta clase */
MiAplicacion() : TApplication() (}
void lnitMainWindow();
:i
}; /¡Fin de la clase MiAplicacion
I* Funcion que inicializa los elementos deila aplicacion *I
void MiAplicacion::lnitMainWindow() (
TDecoratedFrame 'Frame = new T D e c o ~ t e d F m e ( 0 "Ambiente
,
AMASSS", new Miventana);
Mainwindow = Frame;
I/
Fme->AssignMenu (IDMMENU);
I' se crea la barra de botones *I
ControlBar = BuildControlBar(Fme, TContiolBar::Honmntal);
ControlBarLoc = O;
. .
/* se inserta la barra de botones a la vent&a *I
Frame-~lnsen(*Contro1Bar,location[Contro~ar~c]);
F m e g l o = Frame;
''
]I/Fin de la funcion InitMianWmdow
I* Funcion que se encarga de ejecutar la aplicacion *I
int OwlMain(int I*argc*l, char' I*argv*/ [I) (
return MiAplicacion().RunO;
}I/ Fin de la funcion OwlMain
If
Archivo: Aplicxc
1,
Contiene el código de los recursos gráficos empleados en la forma de la IU.
#include "Aplic.rh"
'I(
I' Archivos de imágenes de mapas de bits asociados a los botones de la barra de botones de la IU *I
IDCOPCIONS BITMAP "D:\USUARIOS\CARLOS\TESISWRUEBAS\CASOI
\LEVISS.BMP"
IDC-OPCIONó BITMAP "D\USUARIOS\CARLOS\TESIS\PRUEBAS\CASO1\SISREC.BMF"'
IDCOPCION7 BITMAP "D:\USUARIOS\CARLOS\TESlSWRmBAS\CASOl\DOCPROG.BMP"
I. Menu de opciones de la aplicacion *I
'I/
IDM MENU MENU LOADONCALL MOYEABLE (
POPUP "Archivo" (
MENUITEM "Abrir", IDC-OPClONZ
MENUITEM "Salir", IDcOPCION3
79
!I
Capliulo 5
Plan de Pniebas
I1
5.4.2.1 Objetivo
Integrar en una aplicación por medio de su Iu seis herramientas interrelacionadas entre si.
Generar el código del diseño de la Tu y la aplicación que integra a las seis herramientas.
Probar el funcionamiento del GenViü al especificar ciclos en la secuencia de eventos de una
1)
Iu.
11
5.4.2.2. Resultados esperados
1)
Una aplicación que a p p e a través de su iü las seis herramientas.
Código que genera a la aplicación que se espera obtener.
Funcionamiento correcto del evaluador de diagramas de transición de estados del GenVrU, al
emplear ciclos en la especificadión de la secuencia de eventos de una iü.
11
5.4.2.3 Resultados obtenidos
Una aplicación que integra por medio de su IU las herramientas del AMASS.
Código que genera a la aplicacign obtenida.
El evaluador de diagramas de transición de estados funciona soporta la definición de ciclos
entre los nodos.
11
o
o
1
5.4.2.4. Elementos que definen
la forma de la interfaz del caso 2
II
a) Ventana principal
b) Menú de opciones
1. Archivo
1.1. Abrir
1.3. Salir
2. Programas
2.1. Prog. Uno
2.2. Prog. Dos
2.3. Prog. Tres II
2.4. Prog. Cuatro
2.5. Prog. Cinco
It
c) Barra de botones
1. Programa Uno
2. Programa Dos
11
3. Programa Tres
4. Programa Cuatro
5. Programa Cinco
I1
81
Capitulo 5
Plan de Pniebas
11
I1
1. (Ventana principal, Opción Prog. Uno, Ejecución del programa Uno)
2. (Ventana principal, Opción Prog. Dos, Ejecución del programa Dos)
3. (Ventana principal, Opcion Prog. Tres, Ejecución del programa Tres)
4. (Ventana principal, Opción Prog. Cuatro, Ejecución del programa Cuatro)
5. (Ventana principal, Opción Prog. Cuatro, Ejecución del programa Cinco)
6 . (Programa Dos, Opción Prog. Tres, Ejecución del programa Tres)
7. (Programa Tres, Opción Prog. Dos, Ejecución del programa Dos)
8. (Programa Tres, Opción Prog. Cuatro, Ejecución del programa Cuatro)
9. (Programa Cuatro, Opción Prog. Tres, Ejecución del programa Tres)
10. (Programa Cinco, Opción Prog. Cuatro, Ejecución del programa Cuatro)
11. (Programa Cuatro, Opcion Prog. Cinco, Ejecución del programa Cinco)
12. (Programa Cinco, Opcidn Prog. Dos, Ejecución del programa Dos)
Cinco, Ejecución del programa Cinco)
13. (Programa Dos, Opción
5.4.2.6. Proceso de construcción
111
En este proceso se utilizan las especificaciones descritas en las dos secciones anteriores.
El objetivo de esta IIJ es agrupar en su ambiente a cuatro herramientas que trabajan con archivos
'I
en formato texto.
I
*I--
I
I
dl
Figura 5.11. Diseño del menú de opciones del caso 2.
En la figura 5.1 1 se muestra como queda el diseño del menú de opciones de esta interfaz,
:j
a2
Capítulo 5
Plan de Pruebas
I1
de la iü.Uno de los valores asignados es el tipo de datos que van a compartir los programas, en
este caso es de tipo texto.
1
Cada uno de los nodos senyillos en el diagrama de transición de estados, tiene asociado un
archivo ejecutable que representa un programa que recibe datos tipo texto.
Figura 5.14. Valores asignados a los atributos del bloque principal de la IU del caso 2.
I/
Después de diseñar complepmente la interfaz, se procede a la evaluación de diseño por
medio del precompilador del GenVIU. En este caso de prueba no existe error en la construcción
de la interfaz, por lo que se muestra al usuario un mensaje como el de la- figura 5.9.
I/
5.4.2.7. Código del diseño especificado e IU producida por el código
.II.
Archivo: Aplic.cpp
II
Contiene el código fuente generado a partir del diseño de la IU especificada en la sección
anterior.
I¡
/*** Archivos de cabecera incluidos por el generador del código del GenVlU ***I
#include <owl\window.h>
I)
#include <owliapplicat.h>
#include <owl\buttonga.h>
#include <owl\controlb.h>
!I
#include <owl\opensave.h>
#include <owl\decframe.h>
#include <owl\static.h>
11
#include <string.h>
#include Qtdio.h>
#include "Aplicxh"
I1
'I variables que manipulan la bana de botones */
TButtonGadget' Btns[ó];
I1
TDecoratedFrame 'Frameglo;
static TControlBar'
I/
1
84
Capitulo 5
Plan de Pniebas
BuildControlBar(TWindow*parent, TCon@olBar::TTileDirectiondirection) {
TControlBar' cb = new TControlBar(parent, direction);
Btns[Ol =new TButtonGadget(lDCOPClON5,lDC-OPCION5);
Btns[ I ] = new TBunonGadget(lDC-OPCION6,lDC~OPCiON6);
Btns[2]= new TButtonGadget(lDC-OPCION7,i~-OPCION7);
Btnsg] = new TButtonGadget(lDC~OPCION8,lDC~OPClON8);
Btns[4] = new TButtonGadget(iDC-OPCiON9,iDC-OPClON9);
cb->lnsert(*Bm[O]);
cb->lnsert(*Btns[ I]);
cb->Insert(*Bms[Z]);
cb->lnsert(*Bm[3]);
cb->Insert(*Btns[4]);
cb->Attr.Síyle I= WS-CLIPSIBLMGS;
cb->Atü.ld = IDW-TOOLBAR,
return cb;
!
it
const TDecoratedFrame :: TLocztion Location[] = {
TDecomtedFrame :: Top,
TDecoratedFme :: Le4
TDecoratedFme :: Right
1;
class Miventana : public TWindow {
protected:
I* Abrir *I
void CniOpcion10;
I* Salir V
void CmOpcion20;
I* uno ' I
void CmOpcion30;
I* dos *I
void CmOpcion4();
'
I* @es ' I
void CmOpcionSO;
I* cuatro *I
void CmOpcionó();
1' cinco *I
void CrnOpcion70;
public:
'1
Miventana(); I/ Consmctor de la clase
DECLARE_RESPONSE-TABL~MiVentana);
); /Fin de la clase Miventana
DEFINE-ESPONSE-TABLEI (MiVen&% TWindow)
EV-COMMAND ODC-OPCION2, CmOpcionl),
EV-COMMAND (lDCOPCION3, CmOpcion2),
EV-COMMAND (IDC-OPCIONS, CmOpcion3),
EV-COMMAND (lDC-OPCION6, CmOpcion4),
EV-COMMAND (I=-OPCION7, CmOpcion5),
EV-COMMAND (IDC-OPCIONS,, CmOpcionó),
EV-COMMAND (IDC-OPCION9, CmOpcion7),
END-rnSPONSE-TABLE
85
Capítulo S
11
Plan de Pniebas
TDecoraiedFrame *Frame = new TDecoratedFrame(0, "Aplicacion generada", new Miventana);
Mainwindow = Frame;
I1
Frame->AssignMenu (IDM-MENU);
I' se crea la barra de botones */
ControlBar = BuildControlBar(Frame, TiControlBar::Honu>ntal);
ControlBarhc = O;
I* se inserta la bana de botones a la ventana */
Frame->~sert(*Con~orolBar,Location[Co'ntLoc]);
Frameglo = Frame;
)//Fin de la funcion initMianWindow
'
i* Funcion que se encarga de ejecutar la a@acion */
int OwlMain(int /*argc*/, char* /*argv*lu) {
return MiAplicacion().Run();
)//Fin de la funcion OwlMain
11
Archivo: Aplic.rc
Contiene el "digo de los recursos gráiicos empleados en la forma de esta Tu.
11
#include "Aplic.rh"'
/* Bmps de la barra del menu de la aplicacipn */
IDC-OPCIONS BITMAP "D\U,SUARlOS\CARLOS\TESIS\CODIGO\BITMAPOT.BMP'~
IDC-OPCION6 BITMAP "D.\USUARIOS\CARLOS\TESIS\CODIGO\BITMAPS\BOTONT.~MP"
IDC-OPCION7 BITMAP "D:\USUARIOS\CARLOS\TESIS\CODIGOBlTMAPS\CAJADATT.BMP
ID(-OPCIONS BITMAP "D\USUARlOS\CARLOS\TESIS\CODlGO\BI~APS\CAJDLGT.BMP'~
IDC-OPCION9 BITMAP "D:\USUARIOS\CARLOS\TESIS\CODIGO\BITMAPS\CAJENTRT.B~"
/* Menu de opciones de la aplicacion */
IDM-MENU MENU LOADONCALL M ~,IV E A B L E{
POPUP "Archivo" {
MENUITEM "Abrir", IDC-OPClON2
MENUITEM "Salir", IDCOPCION3
I
!;
POPUP "Herramientas" {
MENUITEM "uno", IDC_OPCIONS i
MENUITEM "dos", IDC-OPCION6 ,I(
MENUITEM "tres", IDC..OPCION7
MENUITEM "cuatro", IDC-OPCIONB
MENUITEM "cinco", IDC-OPCION/
1
1
La figura 5.1 5. muestra como queda la interfaz que se produce por medio de este código.
'!
I1
87
Plan de Pniebas
Capítulo 5
5.4.3.3 Resultados obtenidos
/I_
Detección de errores en el diseno de una IU.
El diagrama de transición de estados que especifica la secuencia de eventos de una Iü se
válida correctamente.
5.4.3.4. Elementos que definen la forma de la interfaz
.I1
a) Ventana principal
I1
b)’Menú de opciones
1. Archivo
i t 1. Salir
2. Microsoft
2.1. Word
2.2. Excel
I/
2.3. Powerpoint
.c) Barra de botones
1. Microsoft Word 11,
2. Microsoft Powerpoint.
3. Microsoft Excel
,
j/
r
.-
,
.
I
I . (Ventana principal, OpciOn Word. Ejecución de Microsoft Word)
2. (Ventana principal, Opción Powerpoint, Ejecución de Microsoft PowerPoint)
3. (Ventana principal, Opcion Excel, Ejecución de Microsoft Excel)
Ill
En la definición de las transiciones se introducen los siguientes errores:
a) No se establece la primera transición, el nodo ‘ivord” queda aislado.
4
b) No se asigna un comando a la transición 2.
,I/
5.4.3.6. Proceso de construckión
En este proceso se utilizan ‘las especificaciones descritas en las dos secciones anteriores.
En este caso de prueba se introddcen errores en la creación de la interfaz, por lo que en las
siguientes figuras se muestra este diseño erróneo.
La figura 5.16 muestra el diseño
del menu de opciones de esta interfaz, a su vez la figura
1
5.1 7 ilustra la barra de botones de asociada a la 1U.
89
Conclusiones
Conclusiones
II
!!
En esta sección se describen las conclusiones obtenidas en el desarrollo de la tesis. Así
mismo, se detallan los beneficios y alcances logrados con respecto a los objetivos propuestos, y se
plantean problemas no resueltos en 'Ieste trabajo, que pueden ser temas de investigaciones futuras.
93
Bibliografia general
I/
Referencias
I
II
[AH0901
Ah0 Alfred V., et,al, Compiladores: principios, técnicas y
herramientas, USA: Addison-Wesley Iberoamericana, cl990.
[BASS911
Bass Len [Y] Coutaz Joelle, Developing Software for the User
interface., USA: Addison Wesley Publishing Company the SEI
Series idlsoftware Engineering, c1991, p. 1.
[BURNER951
Burnett M. Margaret and Goldberg Adele. Visual Object-Oriented
Programming: concepts and environments; Manning Publications
c1995, pp. 8-12.
[BROOKSHEAR931
Brookshear M. Glenn, Teoría de la computación (lenguajes
formalesf autómatas y complejidad, Addison - Wesley
Iberoamericana c1993, pp 39 y 40.
[C”G95]
Chang Shi-kuo, Costagliola Gennaro, etal, “Visual-Language
System For User Interfaces”, (En: IEEE Software, Mar’95) p. 37.
[CHOK95]
Chok Sitt Sen and Marriott Kim, “Automatic Construction of User
1nterface”fiom Constraint Multiset Grammar’’,Departament of
Computer Science, Monash University,
http://k0&25 .informatik.uni-hambug.del-haarslev/vl95~/~lks.
I1
I/
[COSTAGOGLIA95]
Costagliola Gennaro, Tortora Genoveffa, etal, “Automatic
Generation of Visual Progmnming Environments”.(En: Computer,
Mar.’95)’’pp. 57-58.
[HOWLETT96]
Howlett Virginia, Visual interface design for windows., USA
Wiley Computer Publishing c1996.
FESTER951
Lester Paul Martin., Visual Comunication with messages., USA:
Wadsworfh Publishing Company ~1995.
[LÓPEZ95]
López Manuel, Gerard0 Marín, etal., “Las Nuevas Herramientas
Visuaíes”,(En: Personal ComDutine México, May’95) p.36.
[MATT971
“Effective Visual Communication for Graphical User Interfaces ”,
(En:h~://cs.~i.edu/-matt/courses/cs563/talks~mt
desidint del
4/03/97.) p. 1.
I
97
11
Bibliografia general
I1
Bibliografía
,I
Ah0 Alfred V., et.al., Compiiadores: Pprincipios, técnicas y herramientas., editorial
Addison-Wesley Iberoamericana, c1990.
Bass Len [Yl Coutaz Joelle, Developing Software for the User Interface., (USA: Addison
Wesley Publishing Company the SEI Series in Software Engineering, ~1991).
I/
Bumett M. Margaret and Goldberg Adele. Visual Object-Oriented Programming: Cconcepts
and environments, Manning Publications ~ 1 9 9 5 .
Brookshear M. Glenn. Teoría de la computación (lenguajes formales, autómatas y
complejidad, Addison-Wesley Iberoamericana c1993.
Chang Shi-kuo, Costagliola Gennaro, etal, “Visual-Language System For User interfaces”,
(En: IEEE Software, Mar’95)
1
Chok Sitt Sen and Marriott Kim! “Automatic Construction of User Interface f?om Constraint
Multiset Grammar”, Departament of Computer Science, Monash University.
http://kogs25.informatik.uni-h~burg.del-haarslev/vl95www/~ks.
Costagliola Gennaro, Tortora Genoveffa, etal, “Automatic Generation of Visual
Programming Environments”.(En: Computer, Mar. ’95).
i1
Howled Vupinia, Visual interface design for windows., USA: Wiley Computer Publishing
c1996.
LabVIEW para WINDOWS (programación gráfica para instrumentación), manual de
demostración, National instruments, Septiembre de 1992.
i
Lester Paul Martin., Visual Comunication with ‘messages., USA Wadsworth Publishing
Company ~ 1 9 9 5 .
López Manuel, Gerard0 Marfn, etal., “Las Nuevas Herramientas Visuales”,(En: Personal
Computina México, May’95) .
‘‘Effective Visual Communication for Graphical User interfaces ”,
(En:hM,://cs.w~i.edu/-matt/co~ses/cs563/talks
d e s i d i n t de14/03/97.)
’
I1
Myers Brad A. And M c D h e l Rich. “Overview of the Amulet’ User interface
Toolkit”.Human Computer Interaction Institute, Camegie Mellon University, Pittsburgh
(En: ‘http://www.cs.cmu.edu/-arnulet. 1996).
99
Bibliogratia general
11
Nielsen Jakob, Bellcore, “Iterative User-Interface Design”, (En: Computer, Nov.’93).
Pressman Roger S.. Ingeniería del Software un enfoque práctico, ESPAÑA: McGraw Hill
c1993.
I/
Révész Gyorgy, Introduction to Formal Languages, USA: McGraw Hill, c1983.
I!
Shneiderman Ben, Designing the User Interface: Strategies for Effective HumdComputer
Interaction., USA: Addison Wesley Publishing Company, ~ 1 9 8 7parte
.
It.
Wasserman Anthony I., “Extendtng
l . State Transition Diagrams for the Specification of
Human-Computer Interaction”.(En: IEEE Transactions on Software Engineering, Vol. SE11,No. 8., Aug.’85).
d
:/
1O0

MC Carlos De La Cruz Sosa 2000

Transcripción

Documentos relacionados

Manual de Resultados de Evaluacion

El cuadro y el cuento MUCHACHA EN LA VENTANA (Dalí) Es una

Guía para mensaje “Datos no disponibles por el