S.E.P. D.G.I.T. CENTRO NACIONAL DE INVESTIGACION Y ... Juan Gabriel... · s.e.p. s.exf. d.g.i.t. centro nacional de investigacion y desarrollo tecnologico cenidet '' ambiente de desarrollo

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

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO

cenidet ' ' AMBIENTE DE DESARROLLO DE INTERFACES

GRAFICAS HOMBRE. MAQUINA CON APLICACION AL MONITOREO DE PROCESOS "

T E S I S O U E C O M O R E O U I C I T O

P A R A O B T E N E R E L G R A D O D E : MAESTRO EN CIENCIAS DE LA COMPUTACIONCENTRO DE INFORMAWN

P R 0 0 E N f A i CENIDET ING. JUAN GABRIEL GONULEZ SERNA

CUERNAVACA, MOR, ABRIL 1995

9 5 0 7 1 'I

-.-- .- - - --

SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

Centro Nacional de Investigación y Desarrollo Tecnológico ACADEMIA DE LA MAESTRU\ EN CIENCM

DE LA COMPUTAClON ,

Cuemavaca Mor., a 30 de Marzo de 1995

Dr. Juan Manuel Rica* castillo Director del CENIDET P r e s e n t e

At'n: M.C. Luis Garcia Gutiémz Jefe del Dpto. de Computación

Nos es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de maestría de este centro, y después de haber sometido a revisión académica el trabajo de tesis titulado: "AMBIENTE DE DESARROLLO DE INTERFACES GRAFICAS HOMBRE-MAQUINA CON APLICACION AL MONITOREO DE PROCESOS", que presenta el ing. Juan Gabriel GonZalez Serna, y habiendo cumplido con todas las correcciones que le fueron indicadas, estamos de acuerdo con su contenido, por lo que aprobamos que el trabajo sea presentado en examen oral.

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

A t e n t a m e n t e . e .. ... : ; ' ; ' j .i : : : I . . . . . I (UBLiC Comisión de revisión de la tesis

...I .... ,: . ,, .. ',,-:(.','.. "C

SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

Centro Nacional de Investigación y Desarrollo Tecnológico

Cuemavaca Mor., a 3 de Abril de 1995

ing. Juan Gabriel G o d l e E &ma ' Candidato ai grado de Maestro

en Ciencias de la Computación 5 P R E S E N T E

Después de haber revisado su expediente escolar, y considerando que cumple con los lineamientos establecidos en el reglamento académico para la obtención del grado de maestría de este centro, me es grato comunicarle que se le concede la autorizaci6n para que proceda con la impresión de su tesis. AI mismo tiempo, aprovecho para indicarle que, deberá acordar con los miembros del jurado la fecha y hora de presentación del examen respectivo.

Sin más por el momento, reciba mis felicitaciones por el termino de su trabajo de tesis, deseandole éxito en el examen correspondiente.

A t e n t a

A .

Computaciodes.

/I C.C.P. M.C. Wilbenh Alcocer R. Subdirección Académica C.C.P. C.P. Ing. David Chávez A. Dpto. de Servicios Escolares

interior Intermdo Pahim S/N C.P. 62490 ApIíaedo Postal 5-164, C.P. 62050, Cuwnavace Mor., Mexico

Tclp. (73) 18-77-41 y 12-76-13, Fax. 12-24-34 cenidetl I

AGRADECIMIENTOS I

A mi asesor de tesis, el M.C. Luis García Gutiérrez por su apoyo, orientación y tiempo dedicado para la realización de este trabajo de tesis.

A mi tío Enrique, por sus consejos y apoyo que me permitieron orientar el rumbo de mi 8 profesión.

AI CENIDET, por permitirme realizar mis estudios de Maestría y por brindarme su apoyo y confianza.

Doy gracias al Consejo Nacional de Ciencia y Tecnología (CONACyT) por el apoyo brindado para culminar mis estudios de Maestría,

A los profesores de CENIDET, por compartir sus conocimientos y experiencia, en especial a: el M.C. René Santaolaya Salgado, el M.C. Moish González García y el M.C. Joaquín Pérez Ortega.

Agradezco a la Unidad de Resultados de Automatización de Procesos del IiE, por el apoyo brindado para la realización de esta tesis, en especial al M.I. Alfonso Rivas Suárez por su asesoría técnica en el desarrollo de este trabajo.

A mis revisores de tesis, por sus comentarios, criticas y su valiosa cooperación en la revisión de este trabajo.

A mis tíos Pepe y Flora, por brindarme su cariño, apoyo y hogar que me hicieron sentir como en mi propia casa.

A mis primos Jaquelin, Carlos y José Luis por brindarme su cariño y confianza.

A mis tíos Lola y Octavio, por brindarme el cariño, apoyo y confianza que solo se puede encontrar en unos padres.

A mi abuelita Juanita, por el cariño y consejos que toda la vida me ha dado y a quien debo parte de lo que he logrado.

A mi abuelita Luisa por su amor y cariño.

A mis primos Jesica, Ambrica, Octavio y Brenda por el cariño y apoyo que me han brindado.

A mis amigos de CENIDET con quienes compartir una de las etapas mas importantes de mi vida y quo me brindaron su apoyo y amistad: Elsa, Victor, Juan de Dios, Polo, Ricardo, Ariel.

i

DEDICATORIA

A ti Senor, por permitirme formarme como persona y profesionista.

A mi Madre, a quien debo todo lo que soy y a quien dedico todos mis triunfos.

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

A mis hermanos, Oscar, Vero, Horacio, Cris y Claudia, que sin su amor, confianza y apoyo no lo hubiera logrado.

A Oly, por tu Amor, paciencia y confianza que me motiva cada dfa a ser mejor.

ii

......... ... .- I

..... . _. . . ...

li

INDICE I

CAPITULO 1

INTRODUCCION .................................................................................................... 1.1.- Antecedentes .......................................................................................... 1.2.- Objetivo de la tesis ................................................................................ 1.3.- Beneficios ............................................................................................... 1.4.- Organuacion de los capitulas ................................................................

. .

. . . I

CAPITULO 2

MARCO TEORICO .................................................................................................... 2.1.- Interfaz Gráfica al Usuario (GUI) ............................................................ 2.2.- Estado del arte ...........................................................................................

2.4.- Programación Orientada a Objetos (POO) ............................................... 2.5.- Sistemas.de Adquisición de datos (SAD) ................................................

I

2.3.- Programación Visual ..................................................................................

. CAPITULO3

PLANTEAMIENTO Y ANALISIS DEL PROBLEMA .......................................... 3.1.- Planteamiento general del problema ......................................................... 3.2,- Análisis de posibles soluciones .................................................................

3.2.1.- Plataforma de desarrollo ............................................................. 3.3.- Seleccion de herramientas .......................................................................... 3,4.- Planteamiento de Objetivos .......................................................................

3.4.1.- Objetivo general .......................................................................... 3.4.2.- Objetivos específicos ..................................................................

3.5.- Defimcion de requenmientos ....................................................................

.. . 1

. . \ _

. . . . .

' CAPITULO4

! ARQUITECTURA DE LAS HERRAMIENTAS DE SOPORTE ........................... 4.1.- Entorno de trabajo Openwindows .............................................................

4.1.1.- Introducción al Toolkit de Open Look ....................................... 4.1.2.- Principales clase Xt intnnsics ......................................................

4.2.- Descripción del diseño de un widget ......................................................... 4.3- Arquitectura del Widget ...............................................................................

4.3.1.- Archivos que componen un Widget ............................................ 4.4.- Descripción de widgets de aplicacion ........................................................

. .

I

. . . 4.4.1.- Descripción del widget Core Barra ..............................................

4.4.3.- Descripción del widget Core Alarma ........................................... 4.4.2.- Descripción del widget Core Tendencia :I ......................................

5 6 7 10 11 12

16 17 20 24 25 26 26 26 26

32 33 35 36 37 40 40 45 45 48 51

i i i

http://Sistemas.de

4.4.4.- Descripción del widget Composite Report ................................... 4.4.5.- Descripción del widget Composite AreaCtrlBarra

53 55 i .......................

CAPITULO 5

DISENO DEL ADIGMoP .............................................................................................. 58 5.1.- Modelo conceptual del ADIGMoP ............................................................. 59 5.2.- Arquitectura del ADIGMoP ........................................................................ 60 5.3.- Descripción funcional del ADIGMoP ......................................................... 64

64 5.3.2.- Verificación de la dinámica de los objetos .................................. 67 5.3.3.- Recuperación de un grupo o interfaz ........................................... 67

I/

5.3.1.- Fases de la construcción de una interfaz en el ADIGMoP .......

lCAPITULO 6

PRUEBAS ......................................................................................................................... 68

CAPITULO 7

' CONCLUSIONES Y LINEAS FUTURAS ................................................................... 7.1.- Conclusiones ................................................................................................. 1.2.- Beneficios ..................................................................................................... 7.3.- Alcances logrados 7.4.- Mejoras y ampliaciones a este trabajo ........................................................

I ........................................................................................

ANEXOS . Anexo A Sistema X Window ............................................................................... Anexo B Clases básicas Xt Intrinsics .................................................................. Anexo C Código Fuente de los Widget Barra y Re port .....................................

' Tab1a.de abreviaturas .....................................................................................................

Bibliografia .......................................................................................................................

75 16 71 71 79

79 86 97

122

123

!

LISTA DE FIGURAS.

Figura.

2.1 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.1 4.8 4.9 4.10 4.11 5.1 5.2 5.3 5.4 5.5 5.6 5.1 A. 1 A.3 B. 1 B.2 B.3

Titulo.

Arquitectura convencional del SAD Niveles de programación con Xlib Objeto gráfico Barra Objeto grákm Tendencia Objeto gráfico Alarma Arquitectura del entorno de trabajo Openwindows Arquitectura de la GUI Open Look Arbol jerárquico de widgets del toolkit OLIT Arquitectura común de una clase widget Arquitectura de la clase Barra Arquitectura de la clase Tendencia Arquitectura de la clase Alarma Arquitectura de la clase Report Ligado de widgets Alarma al widget Report Arquitectura de la clase AreaCtrlBarra Ligado de widgets Barra al widget AreaCtrlBarra Arquitectura conceptual del ADIGMoP Arquitectura del ADIGMoP Ventanas de selección de objetos Ventana de grupo Barra Ligado de un objeto Barra con una variable Modelo conceptual de la generación de código Verificación de la dinámica de la interfaz Arquitectura Cliente/Servidor Niveles de programación con X Window Arquitectura de la clase Core Arquitectura de la clase Composite Arquitectura de la clase Constraint

Página.

13 23 27 28 29 33 34 35 40 46 48 51 53 53 55 55 59 60 64 65 66 66 61 81 83 86 91 94

V

t

:j

CAPITULO 1.

1 INTRODUCCION.

'I

CAPITULO 1 INTRODUCCIm4

1.1.- Antecedentes.

En el Instituto de Investigaciones Eléctricas (IIE) se encuentra la unidad de Resultados - Automatización de Procesos (URAP) en la cual se ha venido cultivando la línea de investigación de sistemas de Adquisición de Qatos y Registro de Eventos (SADREs) y sistemas Digitales de - Cbntrol (SDC) de tiempo real. Esta línea de investigación se ha orientado al proceso de generación eléctrica, de centrales de la comisión Federal de Electricidad (CFE), con la finalidad de auxiliar en la supervisión y control de los procesos de generación eléctrica.

I / Los SADREs y los SDC se conforman de equipo de computo y software que realiza las siguientes tareas:

0

O Procesamiento de información. Interfaz hombre/máquina.

Adquisición y control de señales.

I

Desde el punto de vista del software se tiene:

0

0 Sistema de interfaz hombrelmáquina. O Sistema administrador de información. O Software básico.

Programas de aplicación. Alarmas, adquisición, reportes, etc.

Para desarrollar un SADRE o un SDC la URAP ha identificado tres técnicas para integrar cada uno de estos componentes en diferentes niveles de abstracción, estas técnicas son: Desarrollo de Software, Uso de Herramientas y Ambientes Integrados para el Desarrollo de Aplicaciones, que van desde la creación de cada uno de estos módulos utilizando Únicamente herramientas y utilerías del sistema operativo, como el compilador, ligador, depurador, etc; hasta herramientas integradas para el desarrollo de sistemas que proporcionan todas las herramientas necesarias para integrar un SADRE.

La experiencia adquirida con el desarrollo de estos sistemas aplicando las diferentes técnicas de integración de software, ha detectado la necesidad de establecer las bases para iniciar el desarrollo de tecnología propia que permita disefiar herramientas que proporcionen los elementos necesarios para la construcción de aplicaciones de manera sencilla y con una buena relación costo/beneficio.

1.2.- Objetivo de la tesis.

I

I

El objetivo de esta tesis es el desarrollo de un ambiente de software interactivo que permita la construcción de interfaces gráficas para aplicaciones de monitoreo de procesos industriales. Esta herramienta proporcionará despliegues gráficos básicos para la construcción de aplicaciones de supervisión de procesos, estos despliegues básicos son: diagrama de barra,

2

C A P I n n O 1 I~TROWCCION

diagrama de tendencia y un sistema de alarmas. Con estos objetos el desarrollador podrá diseñar sus interfaces gráficas interactivamente, utilizando la técnica de programación visual. De tal forma que Únicamente selecciona el objeto gráfico que desea utilizar (barra, tendencia o alarma), lo liga interactivamente a una variable del proceso y obtiene automáticamente el código en lenguaje " C equivalente de la interfaz construida.

' El código obtenido puede ser compilado para obtener la versión ejecutable del despliegue y Ate, pueda ser ligado a una aplicación que controlará estos despliegues.

o

'/

o

o

01

Los alcances del desarrollo de este trabajo son los siguientes:

Proporcionar la metodología para la construcción de un ambiente de diseño interactivo de interfaces graficas.

Proporcionar objetos gráficos para la construcción de aplicaciones de monitoreo de procesos, estos objetos son: diagrama de barn, diagramas de tendencias y un sistema de alarmas.

La asimilación de la técnica del diseño de tipos de datos abstractos llamados widgets.

La implementación de algoritmos que nos permitan generar código en lenguaje "c", equivalente de la interfaz construida.

1.3.- Beneficios. :I

Los beneficios que se obtendrán con esta herramienta de diseño de interfaces gráficas para el monitoreo de procesos, son los siguientes:

I

O Se proporcionará una herramienta que permita la construcción de prototipos de interfaces gráficas, con miras a un producto que pueda ser fácilmente mostrado al cliente (usuario de la aplicación).

Se Proporcionará una herramienta que permita 18 programación visual de interfaces gráficas con aplicación al monitoreo de procesos que puedan ser utilizadas en prototipos de SAD desarrollados en el IIE, así como en aplicaciones de monitoreo de señales en los laboratorios de electrónica y mecánica del CENIDET.

La asimilación de la técnica del diseño de elementos gráficos denominados widgets, que permiten la construcción de despliegues gráficos de acuerdo a los requerimientos y necesidades del usuario.

I 0

I O

I

I

IWCRODUCCION CAPITULO 1

0 Disminuir los costos de adquisición de software de aplicación al contar con una herramienta propietaria, que permite un fácil mantenimiento y adaptabilidad a las necesidades del usuario.

o

o

El desarrollo tecnológico dentro del CENIDET.

Seguir impulsando la línea de inves?igación en el CENIDET en el área del desarrollo de herramientas con aplicación al monitoreo de procesos.

1

1.4.- Organización de los capítulos.

En el capítulo 2 se describen brevemente los temas relacionados con el desarrollo de este trabajo, interfaces gráficas al usuario, programación visual, programación orientada a objetos y sistemas de adquisición de datos.

El capítulo 3 tiene como propósito describir la problemática relacionada con esta tesis, realizar un análisis del las posibles soluciones ydescribir las herramientas seleccionadas para su implementación.

El capítulo 4 da una introducción a la arquitectura del entorno de trabajo Openwindows, a la GUI Open Look y a los objetos gráficos widgets de los que se describirá la arquitectura de los widgets Alarma, Barra, Tendencia, Report y AreaCtrlBarra.

En el capítulo 5 describe el modelo conceptual del ADIGMoP y su arquitectura, también se da una explicación de sus caractensticas funcionales.

' El capítulo 6 presenta un programa de pruebas que tienen como objetivo verificar el r . . cumplimiento de los requerimientos establecidos para el desarrollo de este trabajo.

El capítulo 7 presenta las conclusiones ohtenidas con el desarrollo del ADIGMoP, también se presentan los beneficios de este trabajo, los alcances logrados y las posibles ampliaciones y mejoras de éste.

I

CAPITULO 2.

I

MARCO TEORICO. En este capítulo se describen brevemente los temas relacionados con el desarrollo de este

tibajo, interfaces gráficas al usuario, programación visual, programación orientada a objetos y sistemas de adquisición de datos.

CAPITIiLO 2 KaFxx TBORICO

I

2.1.- Interfaz Gráfica ai Usuario (GUI). I

Una Interfaz gráfica al usuario Graphics user Interface GUI) es el medio que permite la interacción del hombre con la máquina de manera amigable, esta interacción se logra utilizando elementos gráficos que permiten que la GUI tenga una apariencia atractiva, amigable y de manejo intuitivo, la GUI permite el intercambio de información entre el usuario y la aplicación mediante diálogos que manejan de manera transparente los detalles técnicos que se realizan internamente.

8

0

El dialogo que se lleva acabo entre Usuario-Aplicación se compone de dos lenguajes [l]:

Lenguaje de acción: Permite al usuario comunicarse con la aplicación, vía acciones aplicadas a los dispositivos de interacción (ratón, teclado, lápiz Óptico, etc).

Lenguaje de presentación: Este permite a la computadora comunicarse con el usuario, mediante despliegues en pantalla que interpreta el usuario.

0

La computadora utiliza el lenguaje de presentación para desplegar datos que proporcionan un contexto de interacción al usuario, dando la pauta para que éste tome ciertas acciones (asumiendo que el usuario sabe interpretar la información que se está mostrando) en respuesta a la interpretación de los datos, utilizando para esto, el lenguaje de acciones, ya que el usuario toma una decisión y realiza la acción pertinente, por medio de los dispositivos de interacción.

La calidad de una interface, desde el punto de vista del usuario; depende de como se presente la información, de su organización y de las acciones que se pueden tomar para obtener los resultados requeridos [2].

Las GUI han demostrado que el trabajo con computadora ya no es tedioso. De la misma forma en que las interfaces comunes mostraban menús repletos de opciones que llevaban a otras opciones que las hacían tediosas e intimidantes, las GUI muestran pantallas repletas de opciones, pero de manera atractiva, cómoda y de selección intuitiva. El principio de las GUI fué: hacer más fácil el uso de una computadora, hacer que el ambiente de trabajo fuera fácil de manejar y lograr el menor tiempo de aprendizaje en el manejo de éste.

Hoy en día, las interfaces gráficas son la manera más efectiva de establecer la interacción Hombre/Máquina. Con la rápida evolución del hardware se han desarrollado herramientas de software que permiten mezclar texto y gráficos fácilmente, lo que hace que la información se presente al usuario de manera más eficiente. La manipulación de texto y gráficos cada vez es más frecuente por lo que se requiere de ambientes que permitan una gran flexibilidad en la manipulación de estos.

6

CAPITULO 2 WIlCü TBORICO

A los desarrolladores de software, las GUI les permite construir aplicaciones más eficientes y consistentes. Una interfaz gráfica realmente consistente permite a los desarrolladores concentrarse más en el diseño propio de la aplicación y no de su interfaz.

2.2.- Estado del arte.

Con el acelerado desarrollo del hardware y de las herramientas de software nos vemos en la necesidad de mostrar los últimos avances en el área de las interfaces con el usuario. Estas interfaces tienden a establecer una interacción más directa Hombre/Máquina, permitiendo al usuario introducirse a una realidad artificial donde puede interactuar con objetos creados por la computadora la cual va adaptando el ambiente a las acciones que realiza el usuario. Las siguientes tópicos hablan de los Últimos avances en el área de las interfaces gráficas.

Interfaces Multimedia Inteligentes (IMI).

Las habilidades humanas deben ser agudizadas, no atrofiadas, por el uso de las computadoras. La utilización de herramientas multimedia ayudan a agudizar las habilidades humanas.

Cuando se usan los medios adecuados para la interacción entre la computadora y el hombre, se tiende a:

0

0

Para poder mejorar realmente los puntos anteriores, se requiere de un mejor entendimiento de los aspectos de la información, su relación con las características del medio y cual es la

, relación entre los modelos de tareas, usuarios y medio ambiente. Estos aspectos se han agudizado con el desarrollo de nuevos dispositivos de interacción como: guantes, visores de 3-D y sonido

' tridimensional, pero debido a la falta de estándares, y a un pobre o mal aplicado entendimiento 8 del conocimiento humano y sus capacidades físicas han impedido la difusión de este tipo de dispositivos. El estado del arte en interfaces Multimedia inteligentes (Mi) es ejemplificado por prototipos, limitados en capacidad de interpretar diferentes clases de entradas y en la generación de diferentes tipos de salidas. Estos sistemas frecuentemente integran o construyen componentes, con características de medio simple, que ejecutan tareas como reconocimiento de lenguaje hablado y generación o diseño gráfico. El estado del arte incluye también habilidades para interpretar expresiones en lenguaje natural escrito o hablado, acompañado por señales generadas por guantes o de manera directa mediante un dispositivo apuntador.

Incrementar el flujo de información. Mejorar la relación señal a ruido en el intercambio de información.

t

Desde el punto de vista de la salida, la mayoría de las investigaciones se han realizado sobre la generación automatizada de salidas en un solo medio. En años recientes, se han logrado avances en el área de lingüktica y planeación de texto; también se ha tenido progreso en el diseño gráfico, relacionado con el desarrollo de mecanismos para diseño de tablas y cartas, diagramas de redes, despliegues gráficos para negocios y explicaciones gráficas en 3-D.

7

CAPITULO 2 W C O mnIm

t Además, varios laboratorios han logrado desarrollar prototipos para generar de manera automática y coordinada presentaciones multimedia, por ejemplo el sistema COMET que de manera automática genera una descripción textual acompañada de gráficas en 3-D, para explicar la operación y mantenimiento de radios.

Una de las caracteristicas que distingue a las IMI de las inteSaces estáticas, es la habilidad de razonar acerca de como presentar la información al usuario y de como interpretar las entradas del dialogo entre la computadora y el humano.

Sistemas de Presentación Multimedia Inteligentes

Mientras la infraestnictura para almacenar, transferir y desplegar información, se está desarrollando rápidamente, actualmente no se cuenta con la tecnología adecuada que permita el uso adecuado de ésta. Un Area de investigación reciente, es la relacionada con la aplicación de técnicas basadas en conocimientos para crear Sistemas de Presentación Multimedia Inteligente (SPMI).

Los SPMI proporcionan un medio de comunicación de información a travéS de presentaciones multimedia. Como entradas reciben una colección de información y un conjunto de objetivos de comunicación; brindando un conjunto de medios y métodos de presentación. Su función es diseñar una presentación que exprese la información usando una combmación de técnicas y medios, de manera que alcance los objetivos de comunicación y de soporte ai usuario en la realización de sus actividades.

Para desarrollar aún más esta herramienta se están desarrollando las siguientes tareas de investigación:

e Desarrollar mecanismos para determinar la información apropiada a ser comunicada.

Incorporar conocimiento para seleccionar los medios de presentación y las técnicas.

Incorporar conocimiento para coordinar diferentes medios.

Desarrollar técnicas para explorar de manera interactiva los datos.

I

@

0

e

Consideraciones del porque una presentación multimedia debe ser inteligente.

Cuando los tipos y combinaciones de información a ser presentados no son predecibles, una SPMI automatizan el diseño de la presentación para tener una comunicación efectiva.

La presentación de información es generativa y flexible, basada en las características de la información, disponibilidad de los medios, preferencias del usuario y propósitos. Esto es

8

CAPITULO 2 W C O TEORICO

importante en explicaciones o soluciones de problemas en donde se requiere el manejo de estructuras complejas de información, siendo difícil el m a p a las formas de presentación.

En el diseño de presentaciones, tanto manuales como automáticas, se deben seguir algunos principios:

I "La superficie de representación usada por el dispositivo, debe permitir a la persona el trabajar Únicamente con la información aceptable para realizar la tarea"

"La superficie de representación usada por el dispositivo , debe brindar al usuario la cantidad exacta de información para que realice su tarea"

Realidad Virtual (RV).

El ultimo desarmllo en el área de la Realidad Yirtual (RV) es un prototipo informatico para la creación de RV. Este sistema genera modelos del mundo real basados en representaciones tridimensionales y estereoscópicas de objetos físicos con los que pueden interactuar varias personas simultáneamente.

Este prototipo tiene una capacidad multisensorial, que incluye visión, sonido, gestos y reconocimiento de la voz. El modelo generado por el ordenador narra con voz propia los hechos que aparecen en pantalla generando los sonidos relacionados con éstos. También reconoce el habla humana y responde cuando se le interpela. A este desarrollo se le pretende incorporar el sentido del tacto y quizá, los del gusto y el olfato.

El mundo virtual se presenta a través de dos pantallas de ordenador en las que aparece una habitación tridimensional por la que transitan diversos tipos de objetos. El usuario provisto de gafas especiales y de un casco que registra la posición de la cabeza as¡ como de unos guantes que permiten registrar los movimientos de las manos, puede interactuar manualmente con los objetos virtuales que aparecen en la habitación.

El usuario cambia sus perspectivas simuladas dentro de la pantalla, con un simple , movimiento de la cabeza, pudiendo ordenar verbalmente la aparición de nuevos objetos,

manipularlos por toda la habitación y oír los sonidos que producen sus diferentes movimientos, colisiones o mpturas.

Una innovación fundamental de la nueva arquitectura de RV es el gestor de diálogos, un dispositivo que hace posible construir mundos virtuales flexibles que pueden ser fácil y rápidamente reconfigurados. Este gestor de diálogos separa el contenido de los mundos virtuales, que es lo que ocurre en él, su estilo, como interactuar con él, permitiendo usar el mismo código informático para configurar el resultado final de aplicaciones muy diferentes entre sí.

9

CAPITULO 2 warn TB~RICO

2.3.- Programación Visual.

Con la llegada de herramientas de programación tales como Visual Basic, el termino hogramación Visual se ha incluido en el léxico común de la computación. El objetivo de la programación visual es: hacer mas fácil la programación a los diseñadores y accesible para los programadores inexpertos [3]. Las herramientas de diseño visual utilizan los lenguajes de simbología visual para que los desarrolladores pongan más atención a los problemas particulares de su aplicación que en aprender conceptos computacionales o algún lenguaje de programación.

El termino Bogramación yisuai (PV) rigurosamente implica gráficos. Aunque es posible hablar de programación visual en un ambiente de texto, perdiéndose lógicamente muchos de los aspectos de este tipo de programación. La PV implica también diseño orientado a objetos o al menos algo cercano a este concepto en la visualización de un programa. No hay nada más 'representativo de un proceso de cómputo que un gráfico en pantalla que refuerza los principios .de orientado a objetos.

Una de las principales aplicaciones de la PV es la. construcción de interfaces para aplicaciones. Estas herramientas de PV proporcionan bibliotecas de elementos gráficos para la constnicción de interfaces, como: botones, menús, ventanas y barras de desplazamiento. Cada uno de estos objetos puede ser seleccionado y posicionado en una ventana de diseño para luego

, definir la acción que será ejecutada por este objeto mediante la definición de un bloque de código asociado a cada uno de estos objetos.

I

Lo que se está realizando con estas herramientas, es el diseño visual del software a través de una GUI que permite realizar la implementación de éste. Uno de los aspectos que generalmente no cubren estas herramientas, es la habilidad de definir nuevos objetos a partir de los ya existentes mediante mecanismos de herencia. La Única forma de lograr esto es mediante el uso de técnicas convencionales de programación.

'

Otra categoria de los lenguajes visuales pueden ser las herramientas de modelado visual. Estas se pueden utilizar para crear módulos visuales de sistemas, programas y datos. La diferencia entre estas herramientas y un paquete gráfico es que las herramientas de modelado visual permiten ejecutar el modelo diseñado que simula la operación de un sistema o una aplicación.

'

. La construcción de estos modelos es posible ya que cada uno de los procesos que intervienen en un sistema o en un programa se representan en pequeñas cajas las cuales son seleccionadas y ligadas entre si dependiendo de sus entradas y salidas para formar un flujo de datos o control.

10

m c o TaoRxm CAPITULO 2

2.4.- ProgramaciÓn Orientada a Objetos.

En los últimos años los requerimientos de software han sido mas exigentes y complejos, existe una gran diversidad en la forma en que se manipula y presenta la información. Es común

I tenerla en redes de ambientes heterogéneos, con diferentes productos genéricos y herramientas que pretenden svnplificar la interacción de los usuarios con los sistemas de información.

La diversidad de las herramientas y productos, y la escasez de integración entre éstos, frecuentemente nos lleva a aprender muchos paradigmas de interfaces de usuario y comandos, entre otros.

Existe una enorme necesidad de integración, simplicidad y facilidad de uso de todos los productos, lo anterior sugiere un costo mas alto de desarrollo. Así que la ingeniería de software debe. proveer productos que sean Modulares, Extensibles, Mantenibles y Robustos. La Programación Orientada a Objetos esta habilitando la tecnología de software para cumplir con lo que hoy se requiere.

La Erogramación Qrientada a objetos (POO) es la respuesta que ofrece la ingeniería de software para la modelación y desarrollo de software que hace más fácil construir sistemas complejos a partir de componentes individuales [4].

Las características relevantes de la PO0 es proveer mejores paradigmas y herramientas para:

a) Modelar los problemas en la computadora desde una perspectiva mas cercana al mundo real.

b) Interactuar fácilmente con ambientes computacionales usando mejores metáforas.

c) Construir módulos de software reusables y extensibles.

d) Fácilmente modificar y extender implementaciones de componentes sin tener que recodificar todo desde el inicio.

En el esquema tradicional de la programación estructurada, la entidad centd son los procedimientos, mientras que en la PO0 son los datos.

Con lo anterior se debe suponer que la PO0 provee mejores conceptos y herramientas para modelar y representar el mundo real lo mas fácil posible.

La Programación Orientada a Objetos se basa en úes aspectos fundamentales que son:

Tipos de datos abstractos. Es la modularidad de datos, combinando registros de estructuras con procedimientos y funciones llamadas métodos, los cuales manipulan registros de datos, formando nuevos tipos de datos llamados objetos.

0

9 5 0 7 1 7

C A P I n n O 2

Herencia. Es la propiedad de los objetos que permite la creación de objetos jerárquicos con descendientes que heredan de sus antecesores código y estructuras de datos.

PoJimorfismo. El polimorfismo generalmente representa la cualidad o &do de mr f'Jmas, cumdo se aplica en algún lenguaje de programación india que el

mismo Puede asumir diferentes tipos O se manipulan objetos de diferentes tipos. Podemos sobreargar tnétodos Y operaciones, la sobrecarga permite operadores con el mismo nombre pero diferente significado e implementación, para ser invocadas por objetos de diferentes tipos. Claramente, el polimorfsmo combina la flexibilidad y ventajas de código para tipos genéricos con un poder más fuerte.

2.5.- Sistemas de Adquisición de Datos.

En la actualidad, los fabricantes están preocupados por aumentar la calidad de sus productos así como también reducir los costos de producción. Sin embargo por la complejidad de los procesos industriales y el uso de métodos tradicionales basados en la supervisión ocular del proceso, no se han logrado alcanzar estas metas.

Lo que sugiere el uso de sistemas computarizados que por sus características de velocidad y procesamiento de grandes volúmenes de información, hacen posible el control y supeMsiÓn del proceso mediante el despliegue de gráficos interactivos del comportamiento de las vafiables del proceso, de manera que al operador se le facilite ia detectar oportunamente las am%&mes

en el f u n c i o ~ i e n t o del proceso, para tomar acciones COmtivas, permitiéndole dominar de manera segura los procesos técnicos industriales.

Los principales beneficios que traen los sistemas de monitoreo son:

' 0 Mejorar la seguridad operativa del proceso. 0

a

a 0

Un sistema de supervisión es un sistema de control de lam abierto en donde el operador en base a la observación del comportamiento del proceso realiza las acciones de control y supervisión. Por medio de estos sistemas el operador realiza dos clases de diálogos:

0

Documentación y análisis postmortem del comportamiento del proceso. Procesamiento, almacenamiento y variedad de formas de presentación de la información del proceso Mejorar la calidad del proceso o producto. Reducción de los costos de producción.

Diálogos de vigilancia, organiza la supervisión de püntos clave del proceso y solo interviene en casos de comportamiento anormal o disparos de la planta.

Diálogos que permitan la intervención directa del operador para realizar tareas del proceso en tiempos determinados.

0

I1

12

C A P I m o 2 mco mRIco

un Sistema de Adquisición de QatOS (SAD) se entiende como un sistema de cómputo Y software) orientado a la adquisición, procesamiento Y despliegue de datos en tiempo

El Instituto de Investigaciones Eléctricas (IIE) a través de la Unidad de Automatización de k'rocesos (UAP) ha desarrollado sistemas de este tipo orientados a la operación de plantas de generación de energía ektrica, con el propósito de aumentar la eficiencia y segundad de las centrales de generación eléctrica del país. La experiencia del departamento de simulación incluye desarrollos como el sistema de Adquisición de Patos y Begistro de Eventos (SADRE'S) de Tula Hgo. y Manzanillo Col. así como del astema de Begistro y &xUisis de '&msitorios (SIRAT) para la central nucleoeléctrica de Laguna Verde.

Un SAD se diseña para la supervisión y documentación de la operación de un proceso industrial, a través de despliegues en pantallas dedicadas, reportes en impresoras y de gráficas en registradores; la información se recibe por medio de dispositivos de medición. La función del sistema es la del procesamiento de grandes volúmenes de información y de su presentación de manera simple al operador pqa mantenerlo informado de el estado que guarda el P r o c ~ o .

Las I(

a 1% que se orienta un SA» son las siguientes: I1

0

0

Presentación detallada de condiciones anormales del proceso. Elaboración de cálculos de parámetros del proceso. Almacenamiento y presentación de los datos necesarios Para anaiizar disturbios O disparos del proceso. Documentación de la operación del Proceso.

En la figura 2.1 se muestra la arquitectura convencional de un SAD, en la que se pueden distineuir 5 elementos que constantemente interactuan entre si para obtener un sistema seguro, ., confiable y amigable.

- _- BUS DE COMUNUCACIONES ___.

COMUNICACIONES SOFTWARE

INTERFAZ HOMBRE-MAQUINA

DATOS DATOS

- SOFTWAR&= APLICI\CION -___-

Figura 2.1 Arquitectura convencional del SAD.

13

-. . . ~.

ADQUISIC1oN DE DATOS. El mÓdüIo de adquisición de datos del SAD es el enQWado de adquirir las seiiales del medio externo, procesarlas y convefiirlas en digitales acondicionaldolas para que puedan ser utilizadas por el SAD.

COMt"CACIONES. Este módulo contempla el protocolo de comunicaciones y establece las relaciones entre los diferentes elementos del equipo que configuran un SAD. Es de suma hportancia puesto que es la parte que determina el grado de distribución que el sistema presenta como un todo.

SOmWARE DE APLICACION. Engloba los aspectos computacionales que se encargan de la manipulación de la información; tales como programas de diagnóstico de alarmas y protecciones, manejadores de base de datos, acondicionamiento de señales, registro de eventos, historia de variables, control de periféricos, entre otros. Estos son ejemplos de programas de campo tendientes a controlar el proceso y que son escritos por el usuario.

INTERFAZ HOMBRE-MAQUINA: Es el elemento del SAD que permite al operador obtener el máximo provecho del sistema, de manera amigable y eficiente. Esta es la cara que el sistema le presenta al usuario y por lo tanto es un elemento de suma impamcia dentro del desamilo de un SAD.

INGENIERfA DE SOFTWARE. Debe estar presente en todos 10s ~ p e c t o s del desarrollo intrínseco y de supervisión de cada modulo de un SAD, Para el B e g d e n t o de la calidad total del sistema. Involucra el establecimiento de interacciones entre 10s módulos, debiendo proporcionar apoyo a cada uno de eiios en cuanto a S u mantenimiento> documentación, verificación y validación de los subsistemas.

14

REFERENCIAS.

FOLEY, James, et all. "Computer Graphics. Principles and practice" The Sistemas programming series, Addison Wesley 12110, 1990.

BENET, J.L. IBM Reserch Division, Almanden Reserch Center. "Tools for Building Advanced Interface", IBM SISTEM JOURNAL, vol. 25 Nos. 3 y 4, 1986.

Herramientas de programacion visual, visual basic.

LI A, Jose L. Memorias del Curso de Programacion Orientada a Objetos, Congreso CoNICC93, Cuemavaca Mor 1993.

RAMIREZ, V. et all. "Arquitectura para un Sistema de Adquisicion de Datos en Tiempo Real y Manejo de información", Memonas del XIV Congreso de la ANIAC, Guanajuato, Gto. 1988.

1s

CAPITULO 3.

FLANTEAMIENTO Y ANALISIS DEL PROBLEMA.

Este capítulo tiene como propósito describir la problemática relacionada con esta tesis, realizar un análisis del las posibles soluciones y describir las herramientas seleccionadas para su implementación.

CAPITULO 3 P m . I R D Y ARALIS18 D 5 PU>BLBP

3.1.- Pianteamiento general del problema

Los avances en el campo de la computación, han pemiti&, integrar hemimientas c o m ~ u t a n m d ~ que auxilian las actividades productivas y de segundad en los pn>cesos indUSuides. Herramientas Ides Como computadoras personales, estaciones de trabajo Y tedes locales; combinadas con herramientas de software, como ambientes g,.áficos y sistemas multimedia la han beneficiado enormemente.

I

Las comPUtadOm personales por SU bajo costo, su capacidad de conexión en Y su arquitectura abierta han pemiitido que la industria las adopte como plataforma para el desarrollo de Sistemas de supervisión y control de procesos. Por otro lado las estaciones de trabajo con su gran capacidad de procesamiento, almacenamiento y manipulación de gr6ficos, se perfilan como las sucesoras de las computadoras personales.

Actualmente, en los sistemas de supervisión y control de procesos se está dando gran importancia a la relación que existe entre el usuario (operador del proceso) y el sistema, de hecho se considera que la interface con el operador es un factor de suma importancia para la correcta operación del sistema y para la aceptación de éste por parte del &o.

La interfaz con el operador se diseña con el propósito de que sea agradable y capture su atención, para lograr ésto, se estan utilizando las mismas herramientas que se utilizan con éxito en el desarrollo de aplicaciones administrativas (X Window, Visual C++, Mac Windows, open Look, Motif, etc), el beneficio que se obtiene, es que se puede utilizar la mayona de las herramientas comerciaies existentes.

En las computadoras personales el diseño de Interfaces Gráficas al Usuario (GUI) se está realizando en el ambiente de ventaneo Microsoft Windows que sin ser un estándar aceptado es el de mayor demanda, por presentar una interfaz con una apariencia (Look and Feel) agradable, intuitiva y fácil de aprender. La mayor parte de los productos de software comercial como hojas de crilculo, procesadores de texto y lenguajes de programación han lanzado su versión para Microsoft Windows. La industria de automatización de procesos y de sistemas de supervisión y control de p m o s como GENESIS de Iconics, Real Flex de BJ Software y FIX DMACS de htellution cuentan también con productos basados en M i c m f t Windows.

En las plataformas basadas en estaciones de trabajo, el d e s m i l o de interfaces al usuar¡o se ha Uevado a cabo en ambientes con filosofía de sistemas abiertos, en donde han surgido dos estandares, Motif apoyado por open &ftware _mindation (OSO, Digital y Hewlett Packard y Open Look apoyado por AT&T y Sun Microsystem.

Los desarrollos basados en plataforma de tipo estación de trabajo VAX cuentan con herramientas que han tenido un uso generalizado en aplicaciones industriales, como sus sistemas operativos 0I-S y ULTRK), su sistema de comunicaciones (DECnet) y su software para el &&o de interfaces (DECWindows y Motif).

L

I 17

En el hstituto de bvestigaciones Eléctricas (IIE) en la unidad de Resultados de - Automatización de ~rocesos WRAP), una de las líneas de desarrollo que se ha venido cultivando es la de sistemas de Adquisición de gatos y Registro de Eventos (SADREs), así como de - Sistemas Digitales de Control (SDC) en tiempo real. &tos sistemas han sido utilizados en centrales generadoras de energía eléctnca de la Comisión Federal de Electricidad (CFE), con la finalidad de auxiliar a los operadores en sus tareas de supervisión del proceso de generación de energía.

I Los SADREs son requeridos como parte de la instrumentación de las centrales eléctricas

debido a las facilidades que brindan como son: el monitoreo de variables del proceso por medio de una estación gráfica, su capacidad de procesamiento, la variedad de formas de presentación de la información dependiendo de su prioridad, el despliegues de condiciones de alarma y el reporte del comportamiento de la variable en diferentes instantes de tiempo. Por lo tanto, podemos decir que los beneficios que se obtienen utilizando estos sistemas son la disminución de los costos de producción, condiciones seguras de operación y documentacióti del comportamiento del proceso.

Los SAD- y los SDC se d o r m a n de equipo de cómputo que realiza las siguientes tareas: '

o Adquisición y control de señales.

0 Procesamiento de la información. I

0 interfaz hombre/máqh.

Desde el punto de vista del software que io constituye, se tiene principalmente:

0 Programas de aplicación. Alarmas, adquisición, reportes, entre otros.

* o I el usuario (SAIU).

Sistemas de interfaz Hombre/Maquina o sistema Administrador de Enterfaz con

O - Sistema Administrador de información (SAI). Formado por la base de datos y programas de mantenimiento (dialogo de servicios).

0 - Software Básico (SB). Formado por el sistema operativo, utilerías, editor, compilador, etc.

Actualmente, tanto en el área de la investigación como en la comercial, se ha extendido la creación y uso de herramientas para el desarrollo de software, quedando atrás la idea de desarrollar sistemas basados únicamente en utilerías del sistema operativo y en ambientes de programación.

8

f

18

Ahora contamos con productos que van desde herramientas orientadas a resolver una parte especifica de la aplicación, hasta ambientes integrados para el desarrollo de sistemas. Por ejemplo dentro de las herramientas orientadas se cuenta con paquetes para el diseño de la Interfaz con el Usuario, paquetes para el desarrollo y administración de la base de datos y paquetes para la co~iguración de un SAD.

Técnica

Desurollo & sonware.

En lo que se refiere a los ambientes integrados para el desarrollo de sistemas se cuenta con productos que integran todas las herramientas para la construcción de un SAD.

La siguiente tabla muestra un análisis comparativo de las técnicas utilizadas para la integración de los programas y equipos que conforman un SAD y un SDC, estas técnicas han sido utilizadas por la URAP para el desarrollo de estos sistemas.

Equipo/Sofhvare . Ventajas OOULD -Vel. de ejecuci6n.

FORTRAN -Dsanollo de Tecnolo. S.O. MPX-32 -soflwarc propicurio.

gi. mianal.

VAXsl31M)

Ambientes hlcgrador p a el Damolb de AplicPimes

j

Uso de henamienias. (TealkiUl

QNX C SB Am"& sc Labwinds Mejor licmpo de d-lio. Selcc~ión de kmimtar LabVlEW -Tiempos de -u& I1x DMACS de lnlellution C O Y 0 Liicsi.s.

VMS. "C SB DECnu sc SLUMS SAKI X Window S A N

W S SAI QNXWndows S A W

Desventajas I

Desarrollo de Softwarn. Esta técnica de integración utiliza herramientas básicas, tales como: editor, compilador, ligador y depurador para el desarrollo de aplicaciones. Una vez seleccionada la platafoma de desarrollo conformada por el hardware y software bbico, se procede a desarrollar cada uno de los módulos que integran un SAD como son: SAIU, SA1 y el software de la aplicación. Esta metodología de desarrollo tiene como principal desventaja que el tiempo de desarrollo de un sistema es muy grande. Las ventajas de esta técnica de integración es que el tiempo de respuesta de los programas es el mejor, además de que se cuenta con un software propietario, característica que es importante al momento de producir los sistemas comercialmente, ya que no se requiere de licencias, además al momento del desarrollo de los programas se establece la infraestructura para su mantenimiento. Fn la URAP el sistema SADRE Manzanilla I1 se desarrollo utilizando esta técnica.

't

19

Selección de Herramientas (Toolkits). Una vez que se establecen 10s requerimientos y se tiene clara la configuración y alcance de los módulos principales que conf0mar& el sistema, se procede a seleccionar las herramientas de software comercial que apoyarán el desarrollo de cada uno de los módulos. Por ejemplo para el caso del desarrollo de un SAD se tendrían que seleccionar las herramientas para el diseño de la interfaz Hombrewaquina, la base de datos, el manejador de la base de datos y el generador de reportes de la base de datos, entre otros. Para cada software se compran licencias y en el caso de que se requiera obtener el programa ejecutable de cada módulo para que puedan correr independiente de la herramienta en que se desarrolló, se adquieren las utilerias necesarias. Con lo cual no se requieren licencias para comercializar el producto terminado.

La principal ventaja de este método es la reducción del tiempo de desarrollo la cual puede ser de hasta 5 veces. La principal desventaja de esta técnica es que las herramientas que se utilizan para estos desarrollos constantemente se están mejorando y por consiguiente se deben achializar para que haya una compatibilidad con las versiones actuales, lo que produce gastos de actualización. La URAP y el Departamento de Instrumentation y control utilizaron esta técnica en el desarrollo del Sistema Control Distribuido (SICODI) de Gómez Palacios Durango.

1

Ambientes Integrados para del Desarrollo de Aplicaciones. Actualmente existen varias empresas que se dedican al desarrollo de software para control de procesos, en particular para aplicaciones de adquisición y control distribuido, asi como sistemas integrados que apoyan el desarrollo de aplicaciones en tiempo real. Estos ambientes proporcionan las herramientas necesarias para resolver las necesidades del desarrollo de un sistema. Para sistemas de control se debe tener entre otras herramientas las del confgurador de despliegues, configwador de base de datos y generador de reportes. La forma de desarrollar aplicaciones con estas herramientas es definendo las características de la aplicación en términos de sus entradas, algoritmm de control a usar, funciones que se van a realizar y tipos de despliegues que se van a utilizar.

La principal ventaja de utilizar ambientes integrados para el desarrollo de aplicaciones es que el tiempo de desarrollo se reduce al mínimo. Sus principales desventajas son los tiempos de respuesta, mantenimiento o modificación y los costos ya que para cada herramienta se tiene que comprar una licencia.

81

'

3.d.- A W E de posibles soluciones.

El propósito de las técnicas de integración de software es utilizar diferentes herramientas para la construcción de sistemas, cada técnica utiliza herramientas de diferentes grados de abstracción, que nos permitirán seleccionar los criterios que justifiquen el uso de alguna de estas técnicas para la implementación de este trabajo, para este análisis utilizaremos herramientas tales como el sistema X Window, widgets, funciones Xt intrinsics y SL-GMS..

20

P L M l T I y u T l m Y bXALI818 DüL PROB- CAPITULO 3

Técnica de Desarrollo del Software.

l La herramienta que se proporciona para desarrollar este sistema con la técnica de desarrollo de software es el sistema X Window y el lenguaje "C". Este sistema X Window se ha convertido en los últimos años en un estándur para el desarrollo de interfaces grájcai de usuario en estaciones de trabajo. Una caracteristica importante del sistema X Window es que es independiente del hardware y del sistema operativo en que se este trabajando [2, 31.

Los sistemas X Window pueden ejecutarse sobre distintos dispositivos físicos. La unidad de salida es una pantalla gráfica, cuya resolución al menos es la de VGA. Los dispositivos de entrada mas comunes son el teclado y el ratón.

El corazón de la filosofía X Window es la arquitectura cliente/servidor [2]. Esta arquitectura es el modelo del sistema X Window, mediante el cual los clientes, o programas de aplicación se comunican con los servidores, o unidades de visualización remotas a través de una red local.

El sistema X Window se desarrolló bajo UNIX, pero puede ser implementado sobre cualquier sistema operativo (VAXPMS, DOS, o OS/2). Pero debido a su arquitectura basada en el modelo cliente/servidor es mas eficiente en sistemas operativos de multitarea que soporten procesos distribuidos.

La comunicación cliente/senidor del sistema X Window se efectúa a través de un protocolo de red denominado Protocolo X. Este Protocolo X define el número exacto de bytes que se necesitan para realizar todas las operaciones X Window, incluyendo el dibujo y movimiento de una ventana [2]. La programación con el protocolo X es en extremo ardua, este lenguaje base no ofrece facilidades que ayuden ai programador.

El protocolo X es similar al lenguaje máquina asociado al un determinado procesador. De la misma manera que el lenguaje ensamblador proporciona la potencia del lenguaje máquina con mucho menos esfuerzo, las funciones Xlib del sistema X Window proporcionan la potencia del protocolo X con un costo menor. Xlib, es una biblioteca de aproximadamente 300 funciones en lenguaje " C usadas para generar protocolo X [I]. Estas funciones nos permiten desarrollar aplicaciones potentes y confiables a la medida del problema que se quiera solucionar, sin embargo el costo de desarrollar aplicaciones con esta herramienta es muy alto.

1 ' Programar utilizando Xlib puede llegar a ser muy complicado (es comparado con la

programación en ensamblador), ya que el comprender esta programación depende mucho de la experiencia que se tenga en el desarrollo de aplicaciones para sistemas basados en mensajes y ventanas, también se requiere de experiencia en el modelo de POO.

Las ventajas de utilizar esta técnica en la implementación de este trabajo son el ahorro de memoria, mayor velocidad de respuesta, reducción del tráfico de información en la red y la gran potenciabilidad que proporciona esta programación, ya que se programa a bajo nivel lo que

21

permite un mayor acceso a los recursos del sistema operativo. Las desventajas de esta técnica es la complejidad de esta programación y el tamaño del d i g o de la aplicación.

Técnica de Uso de herramientas.

La técnica del USO de herramientas toolkits nos permite diseñar e implemenm aplicaciones de manera más eficiente, utilizando para ello elementos gráficos y funciones de alto nivel que Proporciona el toolkit del entorno gráfco en que se esté trabajando como son los toolkit proporcionados por Openwindows OLIT, TNT y XView que son proporcionados por Sun Microsystems en el software del sistema operativo Sun Solaris. Utilizando estos toolkits el desarrollo de una aplicación es mas rápido, a diferencia de utilizar la biblioteca de funciones X libraries (Xlib) del sistema X Window. El toolkit proporciona elementos gráficos llamados widget, que permiten al desarrollador concentrarse más en el diseño de la aplicación 5 no de su interfaz, ejemplos de estos elementos widgets son: botones, menúes, ventanas, scrollbars, ventanas popup, entre otros.

El toolkit es una interfaz entre el programador de aplicaciones y las llamadas a funciones Xiib, permitiendo ai programador dar órdenes a la computadora con un lenguaje de más alto nivel. El toolkit sustituye las ventanas y los eventos, utilizados en la programación Xlib, por entidades mas sofisticadas, widgets (elementos gráficos) y procedimientos de llamada de retorno (callbacks). Podemos considerar a los widgets como los bloques básicos con que se construye la interfaz gráfica al usuario (GUI), tales como botones, ventanas popup, menúes, etc. Los procedimientos de llamada de retorno ie informan a la aplicación cuando el usuario a referenciado un widget, por ejemplo oprimiendo un botón, el cual realiza las operaciones definidas en la función de retorno (callback).

Un toolkit se puede ver como una biblioteca de técnicas de interacción, en donde una técnica de interacción es la forma en que se maneja la entrada de un dispositivo físico (ratón, teclado, tableta, u otro) para introducir un valor (comandos, numems, porcentajes, localidades O

nombres), con retroalimentación que aparece en pantalla. Ejemplos de estas técnicas de interacción son menúes, scrollbars o botones, que ititeractúan con el ratón, para definir una selección u acción.

El toolkit se compone de dos partes relacionadas [l]. El Xt intnnsics, que es una colección de funciones y estructuras de datos básicas, que son estandares para el sistema X Window y los elementos gráficos widgets de Open Look que amplían las funciones Xt inkinsics ofreciendo una herramienta mas flexible que permita una programación mas potente. Cada elemento gráfico de Open Look tiene una apariencia propia que define el Look and Feel de w e n Look

El corazón del toolkit es la biblioteca de funciones en C llamada X toolkit h M = , también conocidas como Xt intrinsics, estas funciones proporcionan rutinas para la Creación y manipulación de bloques de pantalla estándar llamados widgets. Xt permite que la aphcación manipule los widgets que está utilizando (botones, menúes, ventanas popup, scrollbas, etc), por

I1 ejemplo, si se necesita asociar un botón de la aplicación con una acción determinada, en este caso un ,procedimiento o función, se utiliza una Xt para crear la liga entre el proceso o función y el botón de la aplicación; ésta es una de tantas funciones que permiten las Xt intrinsics, un ejemplo que ilustra los diferentes niveles de programación en el desarrollo de una aplicación para Open Lobk, utilizando la herramientas Xlib, Xt intrinsics y los widgets, se muestra en la figura 3.4.

1

1

Observemos que el conjunto de Xt intrinsics se implement6 con la biblioteca Xlib. Las Xiib proporcionan un acceso total ai Protocolo X, éste controla el diálogo entre una aplicación y el canal de comunicación (network), además de optimizar el uso de éste.

I/

I1

I/

-u --

PROTOCOLO X

SERVIDOR X

--

Figura 3.1 Niveles de programación con Xlib. I I I/ '!

'1 Para diseñar un widgets se deben conocer primero la características funcionales que se ddean, ya que las superclases definidas por Xt Intrinsics determinan ciertas Características funcionales a sus clases derivadas, estas superclases o metaclases principales son 4, Core, Composite, Constraint y Shell, cada una de estas clases proporciona características particulares a s?s subclases derivadas.

1

I

Las ventajas de utilizar la técnica de uso de herramientas toolkits, es la disminución del tiempo de desarrollo de una aplicación, rápida asimilación de la esúuctura de una aplicación, creación de bibliotecas de despliegues gráficos reusables, disponibilidad de las herramientas en el bftware que incluye el sistema operativo de la plataforma, no se requiere comprar licencias para la comercialización del producto final y transportabilidad. De las desventajas del desarrollo delaplicaciones con esta técnica encontramos alto consumo de memoria, tiempo de respuesta de las aplicaciones, consumo de tiempo de máquina.

t

I 23

R - I ~ O Y )UI~LISIS nn PROBLBU CAPIiVLO 3

i I

Ambientes integrados para el desarrollo de aplicaciones. ,I

Utihando la técnica de ambientes integrados para el desarroIlo de aplicaciones 1 . hemientas Como: SL-GMS, Labview, X Face Maker (XFM), Labwindows, entre o m . técnica nos permite desarrollar aplicaciones de manera interactiva y con un factor de tiempo

mínimo. pero debido a la naturaleza de este trabajo no es posible trabajar con este tipo de hemhientas ya que no se cuenta con un presupuesto para la adquisición de éstas, que oscilan entre los $2,000 y $15,000 dis, también cabe aclarar que para las empresas que adquieren estas hemimientas les resulta caro pagar licencias por cada actualización o instalación.

1

1 Otro de los elementos de juicio para no utilizar esta técnica es que uno de los objetivos de este trabajo, entre otros, es el de asimilar la tecnología para el desarrollo de herramientas que faciliten la integración de sistemas, así como también asimilar la técnica para la construcción de widgets.

3.2.1.- Plataforma de desarrollo. 1 i ' 'I El sistema X Window puede ejecutarse sobre distintos dispositivos físicos. La unidad de

salida es una pantalla gráfka, cuya resolución al menos es la de VGA. Los dispositivos de entrada más comunes son el teclado y el ratón, además de otros dispositivos de entrada m&s sofisticados. La inmensa mayoría de los fabricantes de estaciones de trabajo s o p a a n el sistema X Window. Estas plataformas han tenido una gran aceptación dentro del ámbito de la invdtigación y la industria lo que nos lleva a pensar que es la platafoma que se perfila para susti/ir las computadoras personales; pero debido a que la mayoría de los desarrollos no se pueden permitir el lujo de gastar $ 5,000 dólares o más en comprar una estación de trabajo mmpleta una alternativa es una Terminal X, que es una terminal gráfica sin disco en el que se ejecuta un uniw programa, el programa servidor X Window. Otra plataforma disponible para utilihr el sistema X Window es la PC. Un requisito claro para que esta plataforma sopoae el sistema X Window es la alta resolución gráfica, por lo que es necesario un monitor SVGA, VGA o H$rcules, el procesador mínimo es un 80386 o su equivalente. Es necesario disponer de un disco duro erande y rápido, al menos se le deben dedicar 110 Mb al sistema X Window y las

1

- ~- utilehas que necesite y su entorno UNIX incluido [l].

'I I/

24

D L A W T B U U m Y A", ISIü D 5 P- I/

/I C A P I F C 3

Selección de herramientas.

'1 Dentro de las demandas más comunes de los integradores de sistemas de adquisición de datos se tienen tiempos de muestre0 más rapidos, alta resolución en valores y algoritmos de C O & . d n analOgico/digital, procesamiento distribuido, comunicación está,,&, así software que facilite las fases de adquisición y control, la construcción de interfaces y que pr&taCiOneS graficas personalizables [SI.

f 'I 11 Para alcanzar un alto grado de interoperabilidad entre equipos de diferentes proveedores, '1 se recomienda utilizar tecnología de sistemas abiertos, como UNIX, SQL, ethernet, X Window

y el modelo cliente/servidor. Siguiendo estas recomendaciones, se obtienen sistemas flexibles y 1 fáciles de integrar a nuevos sistemas y tecnologías, además de proporcionar escalabilidad. 1

1 Para el desarrollo de este trabajo se seleccionó una plataforma basada en estaciones de tradjo, debido a su gran capacidad de procesamiento, almacenamiento y manipulación de gráficos, además de que se considera la más completa para el manejo de sistemas de control y supervisión de procesos, otro de los factores tomados en cuenta para esta selección es la tesis que se dkarrollo en el CENIDET titulada Ambiente de Desarrollo para la Programación Visual de Interfaces de usuario para Monitoreo de Procesos en Línea [7], la cual nos proporciona las experiencias y principios básicos en el desarrollo de este tipo de aplicaciones en plataformas de computadoras personales (PCs), la cual nos muestra la dificultad que tiene este desarrollo en piadforma PC y los problemas que se presentaron en la realización de esa tesis que utilizó la tknica de d e s m i l o de software.

,I I I i

En io que se refiere a las herramientas de software se seleccionó la técnica de Uso de hen;amientas toolkits ya que esta nos permite alcanzar en su totalidad los objetivos planteados en este trabajo, con esta técnica podremos asimilar la estructura funcional de objetos abstractos llamados widgets la cual nos permitirá diseñar su apariencia y comportamiento. Otra de las ventajas de utilizar esta técnica es que las herramientas de software que se utilizarán son proporcionadas por el sistema operativo Sun Solaris y no es necesario comprar las licencias para su +. Estas herramientas son el toolkit Open Look btrinsics Toolkit (OLIT) y el compilador de lenguaje "C". La selección de estas herramientas se considera la más correcta ya que en los objepos que se plantearon se pretende asimilar la metodología para el desarrollo de sistemas de constnicción de interfaces gráficas interactivamente así como también la asimilación del d&oilo de widgets.

I 8 1 Considerando que el ID3 y el CENIDET son centros de investigación y desarrollo

teniblógico, debemos establecer las bases para proporcionar las mejores herramientas que p i t a n solucionar problemas reales, con la mejor relación costo beneficio. Así como también d e h o s empezar a construir la base para el inicio del desarrollo de software propietano que nos permita desarrollar tecnología propia, y tener las bases para futuros desarrollos.

'I

25

CAF -

3.4

3.4

Pe' est de grá úni

dm

3.4

Loi

V a l

o

o

a

o

o

3.'

o

o

PLUITWIENTO Y AXALISIS DEL P R O B L W L o 3

Planteamiento de Objetivos.

- Objetivo General.

El objetivo general de esta tesis es el desarrollar un sistema de software interactivo que ta la Programación visual de interfaces gráficas para aplicaciones de monitoreo de procesos, erramienta proporcionará elementos gráficos básicos para la construcción de aplicaciones mitoreo de procesos. Esta herramienta permitirá al desarrollador diseñar sus despliegues OS interactivamente, utilizando la técnica de programación visual, de tal forma que nente seleccione el objeto gráfico que desea utilizar, io ligue interactivamente a una Ile del proceso y obtenga automáticamente el código en lenguaje " C equivalente a este egue, que puede ser compilado para obtener su versión ejecutable.

. Objetivos Específicos.

bjetivos específicos del desarrollo de este trabajo son los siguientes:

Proporcionar una metodología para la construcción de un ambiente de diseño interactivo de interfaces gráficas, utilizando la técnica de programación visual, que facilite el disefio de despliegues gráficos con aplicación al monitoreo de procesos.

El ambiente debe proporcionar objetos gráficos básicos para la construcción de aplicaciones de monitoreo de procesos, que puedan incluir diagramas de barra, diagramas de tendencia o un sistema de alarmas.

La implementación de algontmos que permitan obtener código en lenguaje " C , equivalente de las interfaces construidas.

La asimilación de la técnica para el diseño de widgets.

Seguir con la línea de investigación propuesta en el CENIDET para ei desarrollo de herramientas para aplicaciones de monitoreo de procesos.

Definición de requerimientos.

De manera general el sistema deberá observar las siguientes características:

Documentación completa, que permita el seguimiento de nuevos trabajos a partir de este desarrollo.

El sistema debe ser flexible y amigable, ya que debe permitir la construcción interactiva de interfaces gráficas, ligado de las variables fácilmente y generación de código fuente en lenguaje "C".

26

El s(stema deberá soportar las siguientes funciones:

e 'I 4 Construcción interactiva de interfaces graficas con aplicación al monitoreo de procesos

que contengan despliegues en diagrama de barra, diagrama de tendencia o sistema de 1 1 alarmas.

/I e Proporcionar un despliegue gráfico de tipo barra como se muestra en la figura 3.1 con los siguientes requerimientos [6]:

'1

L-. . . Description i- . ___-

Figura 3 . 2 Objeto gráfico Barra.

El despliegue gráfico de barras debe contener como mínimo 2 objetos y como &irno 8 (deben ser múltiplos de 2).

Cada objeto define los siguientes campos de datos, los variable:

- Límite operativo alto (Ioa). - Límite operativo bajo (lob). - Límite critico alto (lca). - Límite precntico alto (lpa). - Límite precntico bajo (lpb). - Límite crítico bajo (lcb). - carase (dirección hardware). - identificador (id). - descripción. - valor-estado (valor-actual). - Unidades de ingeniería (ui).

cuales describen la

27

1 CATI lVLO 3 PLAUFEWImO Y WAüISI8 DXL R ü ü m

II 0 El color de la barra debe cambiar de acuerdo al valor de la variable. Si el valor

se encuentra en un rango precrítico (alto o bajo) su color es amarillo, si el valor se encuentra en un rango crítico (alto o bajo) su color es rojo y si el valor se encuentra en un estado normal su color es verde.

El objeto debe contener un indicador gráfico de tendencia (flecha) que describe la tendencia lógica de los dos últimos valores obtenidos.

1 li

0

I Proporcionar un despliegue gráfico de tipo tendencia como se muestra en la figura 3.2 cpn las siguientes características [6]: 11

Figura 3 . 3 Objeto gráfico Tendencia. I El despliegue debe soportar el monitorea de 4 variables de tipo analógico.

El objeto tendencia define los siguientes campos de datos para cada una de las variables:

- Límite operativo alto (loa). - Límite operativo bajo (lob). - carase (dirección hardware). - identificador (id). - descripción. - valor-estado (valor-actual). - Unidades de ingeniería (ui).

Cada variable debe tener asociado un color que la identifique. Se emplearán el color rojo, verde, azul y amarillo asociados a la variable 1, variable 2, variable 3 y variable 4 del grupo.

28

1 0

I)

Para cada variable se traza una línea de tendencia, la cual describe una dinámica de desplazamiento. Cada linea de tendencia se identifica por el color correspondiente. i

i 0 Cada punto graficado tiene 2 minutos de exhibición a partir del primer momento de su graficación, después de los 2 minutos el punto se elimina de la gráfica.

Cada variable tiene una representacion gráfica de su valor actual en forma de barra escalada con 6 valores. Cada barra se despliega con el color asociado a la variable.

I

t '1 0

1

I 0 Proporcionar un sistema de alarmas como se muestra en la figura 3.3 que cumpla con los

I' siguientes requerimientos [6]: 11

I

:/ o

T HOW CAFXASE ID DESCRIPCIDN VALOR UI P

I- ._

Figura 3.4 Objeto gráficos Alarma.

El sistema de alarmas debe soportar un total de 20 variables en el gNpo.

Cada objeto alarma define los siguientes c a m p de datos:

- Límite operativo alto (loa). - Limite operativo bajo (lob). - Límite critico alto Oca). - Limite precritico alto opa). - Límite precritico bajo (lpb). - Limite critico bajo (Icb). - carase (dirección hardware). - identificador (id). - descripción.

29

I P L A W X ' E W I ~ O Y AUALISIS DSL PIOBI.- cnP1rp.o 3

- valor-estado (valor-actual). - Unidades de ingeniería (ui).

- Tendencia (T).

Cada objeto alarma debe mostrar los siguientes datos: tendencia, hora en la que se alarmo, carase, identificador, descripción, valor, limite pasado, prioridad.

I ,I - Prioridad (P).

li !I i

:I 0 1 Capacidad de ligar variables del proceso interactivamente con los objetos que aparecen 1 en la ventana.

0 I Asociar el valor de las variables al estado visual de los objetos (refrescamiento dinámico). I

O I Pnieba de la dinámica de los despliegues construidos

0 I 1 Generación automática de código en lenguaje " C equivalente de la interfaz diseñada automáticamente.

O

O 1 Manejo de errores de usuario y emisión de los avisos correspondientes.

'1 Recuperación de las interfaces diseñadas. 1

Ii

30

REFERENCIAS.

REIS, Levi, e al. Aplique X Window, McGrawn-Hill, España 1993.

NYE, Adrian. Xlib Programing Manual, vol. I, O'Reilly & Associates, Inc, Sebastopol, CA, ISBN 0-937175-11-0, 1990.

NYE, Adrian. X Toolkit intrinsics Programing Manual, vol. Iv, Second Edition, OReilly & Associates, Inc, Sebastopol, CA, ISBN 0-937175-17-6, 1990.

MYERS, Brand A. Camegie Mallon University. "User Interface Tools: Introduction and Sorvey" IEEE Software, Enero 1989.

CLEVELAND, Peter. DATA acquisition Sistems User User Demand More.

1992, pgs. 15-22.

Especificación de requerimientos funcionales de la MM para el sistema de control distribuido de la central de ciclo combinado de Gomez Palacios Durango. Clave GP-DO- 21-9305, Rev. 1.0, 2 de Julio de 1993. Documento Interno IIE.

SANTAOLAYA, Rene. "Ambiente de Desarrollo para la hgramacion Visual de Interfaces de Usuario Para Monitoreo de Procesos en Linea", tesis de Maestria, Centro Nacional de Investigacion y Desarrollo Tecnologico (CENIDET), SEP, Cuemavaca Mor. 1994.

31

CAPITULO 4. i I

!j I f

I I I

'I

/I ARQUITECTURA DE LAS HERRAMIENTAS DE SOPORTE.

I)

1 1

En este capítulo se da una introducción a la arquitectura del entorno de trabajo O&nWindows, a la GUI Open Look y a los objetos gráficos widgets de los que se describirá la arquitectura de los widgets Alarma, Barra, Tendencia, Report y AreaCtrlBarra.

i I1 I

'I 'I

I

I)

1 1

En este capítulo se da una introducción a la arquitectura del entorno de trabajo O&nWindows, a la GUI Open Look y a los objetos gráficos widgets de los que se describirá la arquitectura de los widgets Alarma, Barra, Tendencia, Report y AreaCtrlBarra.

i I1 I

'I 'I

I

4.1.; Entorno de trabajo OpenWindows. : , La arquitectura en la que se diseiió el Ambiente de Desarrollo de interfaces Gráficas

HonibreMáquina con Aplicación al &nitoreo de Procesos (ADIGMoP) es la que fue desarrollada por OpenHilindows de SunMicrosystems [5]. Se compone de 5 capas de las cuales en este trabajo fueron desarrolladas las partes que aparecen sombreadas en la figura 4.1.

I I ,I

O P E N L O O K \

APLICACIONES APClCACiON OPEN LOOK ADlGMoP

\ \ . ~~~~~ ~ ~~ TOOLK’T

~. ~ W i d g e l s _ ~ ~ s I ~ n d ? ~ . ~~ F d g ~ w l s sspeciai i~8d~s~_~ ~ ~~ ~~~ ~~ - ~ .

~~~~ . . .. ~~~~ 51 ‘“!rk*!E?-. .. . ~~~ ~~ ~~ . :

OPEN FONTS X1 1/NeWS

WINDOW SERVER I \

HARDWARE Y SOFTWARE GRAFICO

I li

El nivel mas bajo de esta arquitectura es el de Hardware y Software Gráfico que proborciona el soporte para vanos modeladores de imagen avanzados en 2-D y 3-D, incluyendo Xi&, entre otros.

La capa del Servidor de Ventanas (Mindow Server) fusiona dos industrias del estándar; el sistema XMindow y Network Windowing System (NeWS). Esta capa proporciona el soporte que’ permite que las aplicaciones sean independientes de la plataforma asi como también los medios que permiten establecer la arquitectura Cliente-Servidor en sus aplicaciones (ver Anexo

I ,I ,

.I

I La capa de Toolkit de la interfaz usuario proporciona los elementos gráficos widgets y las !unciones Xt intrinsics para construir interfaces gráficas ai usuario (GUI) consistentes con un look and feel definido por la GUI Open Look. En esta capa de la arquitectura se creó una biblioteca de objetos gráficos para aplicaciones de tipo monitoreo de procesos. Esta biblioteca contiene objetos gráficos tales como: Diagramas de Barra, Diagramas de Tendencia, sistema de a labas y dos widgets de clase Composite que nos permiten manipular los objetos barra y alarma.

I I 33

1 1

ARíV'I%- DE U S BIIRRMKWTAS DE SOPORR U L P I n n O 4

.I

!I Estos objetos gráficos son despliegues interactivos que permiten al de-ollador de

interfaces diseñar Sus aplicaciones de una manera sencilla, ya sea utilizando la herramienta para el d h i o de aplicaciones de monitoreo el ADIGMoP o invochcblas directamente, en el de su aplicación.

! El siguiente nivel corresponde a las aplicaciones desarrolladas con el toolkit de la interfaz '

usuario para la GUI Open Look, estas aplicaciones comprenden el conjunto de herramientas de escritorio de Open indows hasta las que se desarrollan con los diferentes toolkits (OLIT, TNT y XView). En esta capa se desarrolló el ADIGMoP utilizando los widgets estándar del toolkit - Open Look lntrinsics Toolkit (OLIT) y la biblioteca de widgets especializados (diagramas de barra, diagramas de tendencia y sistema de alarmas) desarrolladas en este trabajo.

.l

La capa más externa comprende la GUI Open Look sobre la cual corren todas las aplicaciones desarrolladas para Open indows proporcionando una GUI consistente y con un Look and Feel agradable e intuitivo, que proporciona elementos gráficos comunes. Al usuario se le presenta un despliegue consistente que puede ser utilizado en varias platafomias y sistemas opehvos, esto es posible debido a que esta GUI fué desarrollada sobre el Sistema X indow, (Ve: anexo A) la figura 4.2 mustia la arquitectura de la GUi Open Look [SI.

,I

I ;/

!!

.

A P L I C A C I O N

Xt INTAINSICS BIBLOPTECA DE WIDQETS ~

G U I O P E N L O O K

I) I

SISTEMA OPERATIVO SUNSOLARlS(UNIX) ___

__- j/

Figura 4.2 Arquitectura de la GUI open Look.

El desarrollo de ege trabajo se ubicó en la capa del toolkit de la interfaz usuario y en la capa de las aplicaciones donde se encuentra el ADIGMoP, los bloques desarrollados se muestran sombreados. La parte del desarrollo que comprendió la capa del toolkit de la interfaz nos pe&tió asimilar la metodología requerida para el diseño de tipos de datos abstractos llamados widgets. Lo6 widgets estándar proporcionados por el toolkit son cajas negras que e n c i e m SUS dedlles internos de funcionabilidad, por lo que es necesario conocer estos detalles para diseñar widgets con características funcionales especiales.

/I

!I !I 34

I

I ~ ~ ' R C l V B A DE LM EESRAHIP*TM DE 809üRm CAPITOL0 4

1 4.1.1.- introducción al toolkit de Open Look.

I Las herramientas para desarrollo de interfaces ai usuario, también conocidas como toolkits se pueden clasificar en dos clases, las cuales dependen del modelo de programación en el que es& s~pr tadas . El modelo mas común soportado por estas henamientas es el modelo de pro&mación procedural, el cual se compone de una colección de procedimientos que pueden ser invocados por los programas de aplicación. La otra clase de estas herramienta utiliza un estilo de programación soporkid0 por el paradigma de Programación Orientada a Objetos (POO), el cual pedite la organización jerárquica de sus elementos de control de interacción, mas comhmente llamados widgets, utilizando los mecanismos de clase, subclase y herencia.

i

1 11 En este caso en particular para el Toolkit de Open Look se utilizó el modelo PO0 para

implementarlo. Este toolkit define una organización jedrquica de clases que van desde la menos especializada hasta la más especializada, cada clase que es instanciada define un objeto o widget. Esto'nos permite hablar de superclases y subclases. En el modelo PO0 el término de superclase o metaclases io ocupamos para referimos a aquellas clases que definen clases, proporcio&doles mediante el mecanismos de herencia, recursos y métodos a las subclases derivadas de éstas, estos r e c m pueden ser dimensiones, coordenadas, color, tipo de línea, tipo de letra, etc., y algunos métodos básicos propios de cada metaclase.

I

j En la figura 4.3 se muestra el árbol jerárquico de las diferentes clases que componen el toolkit de Open Look, estas clases son los elementos que conforman la apariencia (Lmk and Feel) de la Güi de Open Look [2].

'I

'1 I I T-

I I

[ 0 0 1 1 p 0 8 1 T E I

SHELL

'I

-UN..

I/

35

'I

I/ Figura 4.3 Arbol jerárquico de widgets del toolkit OLIT.

'I 1 11 li

ARQUIncmR1. DE w9 WRWUIWW DP SOPORTE I

'1 1 Las Xt Intnnsics se implementaron con las Xlib, la función de las Xt intrinsics es el pro&rcionar la capa de soporte entre los objetos abstractos llamados idget y la interfaz del usudrio. Un widget es reusable, es una pieza de código configurable que tiene independencia de la aplicación. Un conjunto de widgets proporciona elementos comunes para la construcción de GUIs con una apariencia consistente, lo que se conoce como "Look & Feel", estos elementos son: botopes, scrollbars, menúes, etc.

CAPITULO 4 t

'I

I/ 4.1.2.- Principales clases de Xt Intnnsics.

1

sigl

o

o

an( esc

sol aP' Pe' cia Int wii

li La abstracción fundamental del tollkit es el tipo de dato abstracto denominado widget. Un widget es un apuntador a una estructura de la que se crean instancias dinámicamente, estas instancias contiene información que definen el estado del widget. Un widget puede realizar las

I

ntes funciones:

Desplegar información, como texto o gráficos. Un widget puede ser creado únicamente con función de salida ya que no reacciona a entradas del ratón o teclado, por ejemplo el widget etiqueta (label), que únicamente despliega texto en pantalla. Otros widgets pueden ser creados con función entrada/salida, los cuales reaccionan a entradas del ratón o teclado y en respuesta a estas entradas cambiar su apariencia, por ejemplo, el widget botón (button), que reacciona a entradas del ratón o teclado y cambia su apariencia dando un efecto de haberse oprimido.

Ligado de funciones dinamicamente (callbacks). A un widget se le puede ligar una función dinamicamente, esta función se ejecutará en respuesta a un evento que el widget define, por ejemplo al widget botón se le puede ligar una función que se ejecute cuando éste sea oprimido. A estas funciones se les denomina funciones callback.

Actuar como contenedores de otros widget. Un widget puede ser un contenedor de otros widgets, por ejemplo el widget menú contiene widgets botón. El widget contenedor denomina widgets hijos a los widgets que contiene, generalmente un widget contenedor no tiene una apariencia propia, su función es la de controlar los aspectos geométricos de cada uno de sus hijos, como la posición, el color, el ancho y el largo.

Cada widget define sus propios recursos, estos recursos pueden ser el tipo de letra, color, del borde, tamaño del widget en relación a su ancho y largo, posición en relación a la

ia superior izquierda que se toma como referencia (x, y), etiquetas, entre otros.

Todo widget pertenece a una clase, la cual le proporciona procedimientos y recursos, que eredados a los widgets derivados de ésta (ver anexo B). Físicamente una clase es un ador a una estructura, el contenido de esta estructura es constante para todos los widgets iecientes a ésta, sin embargo k t a puede variar de clase en clase. Xt intrinsics define cuatro I de widgets básicos, que son las superclases de todos los widgets. Estas clases de Xt sics pasan Características fundamentales a sus subclases de Xt Intrinsics y a las clases de :ts de Open Look, estas clases se defmen a continuación:

36

CAPINM 1 1utoomcmR. DS L M IPIIIuaQlTM DI SOVORTa

0 Clase Widget Core (Widget núcleo), está situada en la cima de la jerarquía. Todos los widgets heredan recursos de esta clase. Sin embargo ningún widget Core es útil, a menos que pertenezca a la clase Shell o a una clase widget de Open Look. En términos técnicos, la clase widget Core es una metaclase, una clase que organiza clases, no para organizar los propios widgets [3]. I

0 Clase Widget Composite (Widget compuesto o contenedor), ésta es subclase de Core. , La clase Composite define datos y procedimientos requeridos por las clases widgets que

se diseñan con función de widgets contenedores de otros widgets denominados hijos, de los cuales controla todos sus aspectos geométncos [3].

Clase Widget Constraint(Widget de restricción), ésta es subclase de Compite. Define datos y procedimientos adicionales a los widgets contenedores, estos datos y procedimientos permiten diseñar myejadores geométricos mas complejos [3].

Clase Widget Shell (widget de interfaz), def ie datos y procedimientos para el control I de la interacción de la aplicación y el manejador de ventanas ( ). Los widgets

pertenecientes a esta clase proporcionan una interfaz entre el gestor de ventanas y los otros widgets de la interfaz [3].

0

0

I

Podemos ver a la clase Core como la superclase de todas las clases ya que ésta no se deriva de ninguna clase superior, sin embargo esto no es así, la clase Core tiene tres clases antecesoras, que son las clases Object, RectObj (Rectangle Object) y Unname (sin nombre) que tienen como propósito, futuias ampliaciones. Estas clases son referenciadas como Objects (2, 31.

1 La clase Object contiene la defición de los campos que son comunes a todas las clases Objects. Esta clase encapsula los mecanismos para la administración de los recursos. Todas las clases Objects y los widgets son subclases de Object.

La clase Rectangle Object o RectObj es subclase de Object, esta clase define las áreas rectangulares o bloques en pantalla del Widget. Esta encapsula los mecanismos para la administración geométnca. La clase Unname no tiene ninguna función ya que se diseñó para futuras ampliaciones o mejoras. Para obtener más detalle de los recursos y métodos de estas clases ver el Anexo B.

4.2.- Descripción del dwño de un widget.

Un widget los podemos ver como un apuntador a una estructura la cual define el estado actual de éste, esta estructura contiene apuntadores a metodos que determinan las características funcionales de cada clase widget. Una clase widget se compone de 2 archivos de cabecera *.h y uno'de implementación *.E, para esta descripción utilizaremos el identificador NombreWidget como nombre de la clase, así que los archivos que componen esta clase se definvan como

37

CAPITULO 4 AJIOOXTBC~RI< DE ~JIS ~ ~ R I ~ I I I ~ A S DE 8omm

t

N0mbreWidgetP.h archivo de cabecera privado, N0mbreWidget.h archivo de cabecera público y NombreWidgetc archivo de implementación.

Un widget hereda procedimientos y recursos de la clase de la que se deriva. Los siguientes pasos definen en forma resumida el proceso a seguir para construir un widget:

1) Primero se define los requerimientos funcionales del nuevo widget. Estas características funcionales son necesarias ya que de ellas depende de que superclase se derivará.

Se definen los recursos públicos y privados de la clase, por ejemplo, un recurso color-barra o rango-max. Los recursos públicos de la clase pueden ser accesados por medios externos y los recursos privados no.

Se crea el archivo de cabecera privado NombreWidgetP.h, en el que se definen cuatro eStruCtUlaS.

2)

3)

instancePart (NombreWidgetPart).

instanceRec (NombreWidgetRec).

0 Classpart (NombreWidgetClassPart).

' e ClassRec (NombreWidgetClassRe).

-La estructura NombreWidgetPart. En ésta se definen los recursos públicos y privados de la clase, estos recursos determinan el estado de una instancia de esta clase.

' -La estructura NombreWidgetRec. Esta integra la estructura NombreWidgetPart con las estructuras instancepart de las superclases de las cual se deriva. Por ejemplo, la clase

I NombreWidget se deriva de la clase Core la estructura NombreWidgetRec queda de la siguiente forma:

typedef struct -Nombre idgetRec I

CorePcUr core; Nombre idgetpart nombre Widget;

)Nombre WidgetRec, *nombre WidgetRec;

-La estruetura NombreWidgetClassPart. En kta se definen apuntadores a métodos particulares de la clase, estos métodos pueden ser heredados a las clases que se deriven de ésta por medio de estos apuntadores.

-La estructura NombreWidgetClassRec. Integra la estructura NombreWidgetClassPart y las estructuras ClassPart de sus superclases. Por ejemplo, la clase NombreWidget se

38

denva de la clase Core, la estructura NombreWidgetClassRec quedaría de la siguiente forma: I1

typebf sfnrct I

I1

CoreChsPart core-class; I/ Nombre WidgetClassPatt nombre Widget-chs;

]Nombre WdgetChsRec, “Nombre Widgetclass;

4 -En este archivo se definen apuntadores externos a las estructuras NombreWidgetRec y Nombre WidgetClaPsRec.

I1 4) Se Crea el archivo N0mbreWidget.b en el que se define 10 siguiente:

-Si la nueva clase utiliza recursos no definidos en el archivo StringDeth estos debn ser definidos en este archivo.

I -Una declaración de un apuntador externo a la estructura NombreWidgetClassRec llamado nombreWidgetClass.

-Un apuntador a la estructura NombreWidgetPart del Widget, llamada NombreWidgetWidget.

Se implementa el archivo NombreWidgeLc en el que se desarrolla todo el código de implemeiitación de la clase. Este archivo define las siguientes partes:

- Define la lita de recursos. Esta lista contiene los campos de la estructura NombreWidgetPart que serán públicos, los recursos que tienen entrada en esta lista son los que pueden ser accesados externamente.

- Se define p tabla de traducciones y la tabla de acciones. La tabla de traducciones mapea una secuencia de eventos y los liga a una cadena, la tabla de acciones liga esta cadena a una función llamada acción.

- inicialic!ión de la estructura clase registro (ClassRec) NombmWidgeKlmRw. Esta estructura registra la lista de recursos, las tablas de traducciones, acciones y los apuntadoresla los métodos redefinidos por la clase.

- Definición de los métodos básicos Esta parte es la que requiere mayor Unplementación ya que se befinen los métodos básicos de la clase, como son Expose, SetValues, Initialize, Destroy, entre otros. Cada uno de estos métodos realiza tareas especificas en respuesta a llamadas de funciones Xt Intnnsics.

1)

I/ 5)

I)

I1

39

4.3.- Arquitecturá del Widget.

/I Un widget es un apuntador a una estructura, este apuntador nos permite crear instancias de esa e s t N C t U r a . La manera en que la aplicación puede entablar un diálogo con las instancias de esa estructura es a través de las funciones Xt Intrinsics las cuales establecen la interfaz entre la aplicación y la instancia en memoria. Un widget debe ser creado a partir de alguna superclase o widget existente, como Core, Composite, Constraint o alguna otra clase definida, esta estructura le proporciona recursos y métodos mediante el mecanismo de herencia. Además cada widget puede definir sus'/ propios métodos y recursos públicos y privados que determinan sus caractensticas funcionales. En la figura 4.4, podemos ver la arquitectura típica de una clase widget.

/I

CLASE: "NombreWidget -71

1 Recursos I I/

//

Figura 4.4 Arquitectura común de una clase widget.

4.3.1.- Archivos que componen un Widget.

Un widget se compone de dos archivos de inclusión *.h y un archivo de implementación *.c. Cada uno de estos archivos contiene elementos específicos. El nombre de cada archivo se deriva del nombre de la clase a la que pertenecen, por ejemplo el widget de la clase Barra tendrá los archivos Barr+.h, Barra.c y Barra.h [2, 41.

0 Archivo de cabecera privado, NombreWidgetP.h, defiie la clase del widget y la estructura de instanciación, incluye apuntadores a los métodos.

Archivo de implementación, NombreWidget.c, contiene el código de implementación del Widget, incluye los métodos y acciones de éste.

Archivo de cabecera público, NombreWidget.h, contiene las declaraciones necesarias para que una aplicación pueda utilizar el Widget.

I1

0

/I 0

40

La " P en el nombre del archivo include se entiende como privado. Solo el archivo N0mbreWidget.c y cualquier otra clase derivada de éste pueden incluir el archivo privado N0mbreWidgetP.h. Si una aplicación incluye este archivo y hace referencia a algo de su

público NombreWidgeth

contenido, provocaría I conflictos con la encapsulación, y estas variaciones pueden afectar la aplicación. Una aplicación 1 que utiliza un Widget, únicamente incluye el archivo de cabecera

ARCHIVO N0mbreWidgetP.h. I

Una clase widget se compone de dos estiücturas que Xt htrinsics implements, la estructura Clase (Class stnict) y la estructura instancia (Instance stnict). campos de ambas estructuras son inicializados en tiempo de compilación. Estas estructuras se definen en el archivo de cabecera privado de la clase N0mbreWidgetP.h.

I¡

Cuando se crea la instancia de una clase (un objeto), la aplicación mantiene una soia copia de la estructura en memoria en tiempo de corrida, la cual, es compartida por todas las instancias de la clase. Sin embargo cada instancia tiene su propia copia de la estructura, cuyos campos son inicializados en el 'momento en el que se crea la instancia. Los campos de la estructura Clase contienen apuntaddres a datos y a métodos que defmen la forma en que cada instancia será manipulada por las funciones Xt Intrinsics. La estructura Instancia proporciona todos los campos que definen el estado actual del widget, estos campos determinan las diferencias entre dos o mas instancik de la misma clase. Por ejemplo, la estructura Instancia de la clase Core, tiene los campos x, y, width y height, los cuales corresponden al tamaiio del Widget y a su localización relativa a la esquina superior izquierda de su padre. Estos campos son públicos. Otros campos de la estructura Instancia son privados, y son utilizados internamente por el widget.

II

I/ Realmente, la estructura Instancia no es global. Cuando una función Xt intrinsics invoca

un método, ésta le pasa al método un apuntador a la estructura Instancia del widget. Los métodos realizan sus operaciones utilizando los campos privados de la clase y variando los campos públicos de la estructura Instancia. Por ejemplo, un método que dibuja en una ventana puede obtener sus himensiones directamente de la estructura Instancia del widget. Cuando una función de acción invocada, a ésta también se le pasa un apuntador a la estructura Instancia. La organización de las estructuras Clase e Instancia (Class struct e Instance Stnict) se determina por la jerarquía de la clase del Widget del cual se derivan. Por ejemplo, en el código de la clase NombreWidget, la estructura Clase inicia con los campos definidos por la esiructwa Clase de Core, seguidos por los campos de la estructura Clase NombreWidget.

Xt intrinsics proporciona tres clases básicas para construir Widgets, estas son: Core, Composite y Constraint. Core es la clase de la cual se derivan todos los Widgets. Esta define características comhes para todo Widget, como métodos y recuIsos básicos tales como ancho y largo. Las estd'cturas Clase e Instancia de la clase NombreWidget puede derivarse de Composite, las &cturas de esta clase inician con los campos de la clase Core, continuando con los campos de la clase Composite y finalizando con la clase NombreWidget.

41

Para disefiar una clase O widget es necesario separar la estructura Clase y la estructura Instancia en dos estructuras, esto es, la estructura Instancia se implementará con dos estructuras llamadas Part y Rec o Record, así como la estructura Clase. Primero se implementa la estructura Instancepart que define los recursos públicos y privados del widget, después esta estructura se integm a la estructura InstanceRec que une las estructuras InstancePart de las superclases del wihget. De la misma forma se crea la estructura Classpart y ClassRec. En el código de implementación, a las estructuras Clase se. les llama nombreWidgetClassPart y nombreWidgetCLRec y a las estructuras instancia se les llama nombreWidgetPart y

11

nombreWidgetRec. I

I1

La razón del diseño de estructuras anidadas es principalmente para reducir los cambios que se realicen en el código de la nueva clase. Esto es, si se. realizan cambios en las estructuras de la clase widget, éstos solo afectan el bloque de código donde se inicializan en el archivo de implementación N0mbreWidget.c. Otra de las ventajas de este diseño es que reduce la cantidad de código en la implementación de una nueva clase.

ARCHIVO NombreWidgeLc.

h

I1 La paae medula del archivo de implementación es la inicialización de la estructura Clase

registro (nombreWidgetClassRec). La organización de este archivo es simple. Primero se defmen todos los elementos que serán colocados en la estructura nombreWidgetClassRec: métodos, lista de r&cumos, tabla de acciones y tabla de traducciones. De &Os ekmentos 10s que requieren mayor trabajo son las funciones o metodos que se implementan Para cada Clase (initialize, Wt-values, expose, resize, etc) y las funciones denominadas acciones, se define la lista de recursos, la tabla de traducciones y de la tabla de acciones.

Archivos de cabecera necesarios. I

El archivo de implementación N0mbreWidget.c comienza con los archivos de cabecera estándar: I1

<stdio.h>, ya que la utilización de printf es muy útil para acciones de depuración

<Xll/IntrinsicP.h>, proporcionado por Xt Intrinsics define declaraciones de funciones Intrinsics y &ras macros útiles para la implementación de aplicaciones.

<Xll/StringDefs.h>, proporciona los recursos estándar que se utilizan en la d e f ~ c i ó n de la lista de recursos. Cuando se requiere de un recurso que no es estándar éste se define el archivo N0mbreWidget.h. I

0 "NombreWidgetP.h", se incluye el archivo de cabecera privado de su superclase inmediata (el, cual incluye a su vez el archivo de cabecera privado de su superclase, y así sucesivamente), y cada archivo privado de cabecera incluye los archivos de cabecera públicos de iu clase.

4 2

Prefijo Primera letra del nombre.

XtN ' Minúscula

XtC 11 Mayúscula

XtR Mayúscula

El tipo de representación de un recurso (XtRNombre) es una cadena de caracteres de un tipo definido en ellcud el Widget almacena el valor del recurso.

Tabla de traducciones y tabla de acciones.

Una tabla de traducción, mapea una secuencia de eventos y los liga a una cadena de caracteres. La tabla de acciones liga esta cadena con una función llamada acción. Para esto, primero se construye la tabla de traducciones (translation table) mapeando los eventos en los que el widget debe realizar cierta acción, como por ejemplo, cuando se oprime el botón del ratón sobre el área del widget, éste debe realizar cierta acción relacionada a este evento en particular, como cambiar su color o desplegar una ventana popup. La tabla de acciones se encarga de ligar la cadena que define los eventos a una función de acción que realiza la tarea que se necesite.

t 1)

1

4 3

Descripción

Nombre del recurso.

Clase del recurso.

Tipo de la representación

I/ La tabla de traducciones y la tabla de acciones se deben definir antes de que se inicialice la estructura nombreWidgctClassRec. Estas tablas determinan los eventos a los que el Widget debe responder y las funciones que serán invocadas por estos eventos. La tabla de traducciones es un recurso definido por la clase Core. Este recuso difiere de los demás en varios aspectos, no tiene un valor por omisión, las traducciones no se heredan de la misma forma que otros recursos, no se p u j e hacer la unión de todas las tablas de traducción de las superclases [4]. I

Si en una aplicación se defme una cadena de acción igual a la cadena de algún Widget que esté utilizando, la aplicación determina que cadena no se invocad. Por otro lado, dos clases pueden definir la Asma cadena de acción sin que esto cause conflictos.

Declaración de métodos. I

Un método es invocado cuando la aplicación utiliza ciertas funciones Xt Inmnsics, por ejemplo, cuando F a aplicación crea una instancia de un Widget utilizando la función XtCreateManagedWidget o alguna otra función similar, Xt invoca el método initialize del widget instanciado b cuando se utiliza la función XtSetValues, Xt invoca el método set-values del widget.

Cuando se generan ciertos eventos o llamadas a funciones Xt Inttinsics, estos pueden invocar a más de unlmétodo, como por ejemplo, cuando se genera un evento Expose (exposición) o cuando se utilizan las funciones XtSetValues o XtDestroy se invocan vatios métodos.

I/

Los métodos y las acciones son diferentes. Un método es invocado en respuesta a la llamada de una función Xt Inhinsics o a un evento Expose; mientras que las acciones son llamadas en respuesta a acciones del usuario. Los métodos cuentan con un campo propio en la estmctura Clase, dentras que las acciones se listan en una tabla que se almacena en un solo Campo. I1

ARCHIVO N0mbreWidget.h.

Este archivo público de cabecera define los aspectos del widget que pueden ser accesados desde la aplicación; Este archivo por lo general tiende a ser pequeño. Se compone de dos elementos obligatorios que son:

I

Una declaración externa de un apuntador a la estructura NombreWidgetClaseRec llamado nombreWidgetClass, que es utilizado por la aplicación para crear las instancias de esta clase, mediante llamadas a funciones tales como XtCreateWidget, XtCreateMhaged Widget.

Un apuntador a la estructura NombreWidgetPart del Widget, llamada NombrewidgetWidget. Xt invoca todos los métodos y acciones con un argumento de tipo Widget.

44

Si la nueva '1 clase utiliza recursos XtN, XtC o XtR no definidos en el archivo de cabecera <Xll/StringDefs.h>, estos nuevos recursos se deben definir en este archivo público. Si el Widget proporciona funciones públicas, éstas deben ser declaradas externas en este archivo.

4.4.- Descripción de ,I widgets de aplicación.

El desarrollo de este trabajo comprendió el diseño de una biblioteca de widgets que permitirán la consthcción de interfaces con aplicación de monitorm de procesos. Estos widgets permiten al diseñahor construir aplicaciones de manera sencilla, utilizando estos despliegues interactivos. Se di$ñaron 3 widgets de clase Core: widget Barra, widget Tendencia y widget Alarma y dos widgets de clase Constraint widget Report y widget AreaCtrIBarra, para el diseño de la arquitectura de las clases se utilizó la Notación de Diseño Estructurado Orientado a Objetos para la Representación de Diseño de Software (OOSDN) [l].

t /I

4.4.1.- Descripción del widget Core Barra.

Una instancia de la clase Barra describe una dinámica que muestra el estado operacional de una variable de $0 analógica, este estado operacional se determina por el valor que se asigna al recursos llamado valor-estado del objeto Barra, el valor de este recurso es el valor actual de la vanable de campo, este valor es actualizado cada lo00 milisegundos (aproximadamente 1 seg). Cada variable es descrita en la base de datos del sistema de adquisición de datos (SAD), cada variable define 4 1in)ites de operación estos son: limite crítico alto, limite precrítico alto, limite precrítico bajo y limite crítico bajo. Cada limite de operación tiene asociado un color que lo identifica, a los limites críticos se les asocia un color rojo, a los limites precnticos se les asocia un color amarillo y'al estado normal se le asocia un color verde.

Cada vez que el valor del recurso valor-estado se refresca (esto en penodos de 1 seg) se verifica si éste encuentra en el rango de alguno de estos limites de operación, de ser así la barra cambia al color asociado a &e, de esta forma el operador identifica las variables que se encuentran operando anormalmente.

El objeto Barra defme una flecha indicadora que muestra la tendencia que se obtuvo de los dos últimos valores, si fué mayor o menor que el último valor registrado; así como también un indicador del valor actual de la variable en las unidades de ingeniena en que está definida y las etiquetas descriptoras de la variable. La figura 4.5 describe la arquitectura de la clase barra.

1)

45

I/ La clase b q redefine 6 métodos Xt intrinsics, método Initialize, Setvalues (set-values), Redisplay (expose), D e s h y , Resize y QueryGeometry (queryseometry), estos métodos pertenecen a la clase Core y realizan las funciones que anteriormente se describieron.

La clase Barra defuie la función de acción Notificación, esta función verifica si el ratón se encuentra dentro de su perímetro cuando se oprime el Btnl de ser así, regresa un identificador del objeto, definido por el recurso orden-aparicion, este identificador nos permite reconocer el objeto que fue seleccionado en la fase de ligado del objeto con la variable.

II La clase Barra define un recurso llamado callback que permite ligar una instancia de la

clase Barra a una función en tiempo de comda. La función se liga al objeto Barra por medio de la llamada a XtAddCallback, la cual especifica el nombre de la función que será ligada al objeto.

La clase Barra defme 3 funciones privadas que realizan las siguientes operaciones:

I1 0 Función Color. La función Color se encarga de transformar las cadenas de identificación de color a sus valores equivalentes, los cuales son utilizados por el contexto gráfico.

Función Load-font. Esta función carga un nuevo tipo de letra.

Función Get-GC. Esta función se encarga de crear un contexto gráfico para el widget.

46

0

0 1)

1

XtümrETLm DE IAS E ~ ~ N C I ~ A S DE SOPORTE CAPITULO 4

Recursos del widget Barra.

La clase widget Barra define 13 recursos que se describen en la tabla 1. I/

Nombre Campo

id descripción ui valor-estado Estad0.h Estado.lpa Estado.1pb Estado.lcb loa lob OrdenAparicion foreground callback I

11

i

Nombre Recursos

XtNid XtNdescripcion XtNui XtNvalor-estado XtNlca XNPa XtNlpb XtNlcb XtNloa XtNlob XtNordenAparicion XtNforeground XtNselect

Valor Default

"id" "Descripción" "UP O O O O O O O O P Y NULL

47

I/

4.4.2.- Descripción del widget COR Tendencia. ~

I/ . Una instancia de la clase Tendencia permite observar los valores de cuatro variables de tipo analógicas en un período de exhibición de 2 minutos, estos valores se grafican en un diagrama de tendencia en el cual se describe el comportamiento de cada variable en forma independiente, cada valor de las variables cuenta con 2 minutos de exhibición a partir del primer momento de su graficación. Cada variable define su línea de tendencia con respecto a los valores que ha ido describitndo en un período de 120 segundos (2 min). El refrescamiento de la variable se realiza cada loo0 milisegundos. A cada variable se le asocia un color, el cual la identifica. Cada variable tiene también una representación gráfica en forma de barra, escalada con 6 valores. El objeto tendencia no proporciona los medios para indicar cuando una variable se encuentra operando anormalmente. Unicamente muestra el comportamiento de la variable en un periodo de 2 minutos. Este objeto presenta la siguiente información de cada variable: su came (dirección hardware), identificador, descripción, valor estado y unidades de ingenieria. La figura 4.6 muestra la arquitectura de la clase Tendencia.

I

<To,

ia . La clase Tendencia redefine 6 métodos Xt Intrinsics, estos método son: Initialize,

Setvalues (set-values), Redisplay (expose), Destroy, Resize y QueryGeometry (queryzeometry), estos métodos pertenecen a la clase Core y realizan las funciones que anteriormente se describieron. La clase Tendencia define la función de acción Notificación, esta función verifica si el apuntador del ratón se encuentra dentro de uno de los 4 perímetro definidos cuando se oprime e1,Btnl de ser así regresa un identificador del perímetro seleccionado defindo por el recum id-variable, este identificador nos permite reconocer el área que fue seleccionado en la fase de ligado! del objeto con la variable. La clase Tendencia define un recurso llamado callback que permite ligar una función a una instancia de la clase Tendencia en tiempo de corrida. La función se liga al objeto Tendencia por medio de la llamada a XtAddCallback, la cual especifica el nombre de la función que será ligada al objeto.

1

4 8

'I

1

Nombre Campo

carasel id1 descripcionl ,/ ui 1 valor-estado1 loa1 lob1 carase2 id2 decripcion2 ui2 valor-estado2 loa2

La clase tendencia define 7 funciones privadas que realizan las siguientes funciones: I 1

Nombre Recurso

XtNcarasel XtNidl XtNdescripcion 1 XtNui 1 XtNvalor-estado1 XtNloal XtNlobl XtNcarase2 XtNid2 XtNdescripcion2 XtNui2 XtNvalor-estado2 XtNloa2

Función Dame-hora. Esta h c i ó n obtiene la hora actual del reloj de la máquina y la pasa a una cadena que se utiliza en el despliegue de la gráfica de tendencia para indicar le hora en al que fue capturado el valor de la variable.

Función Lista-segmentos. Esta función genera una lista de 120 nodos que contienen los valores de la variable en un período de 120 segundos, esta función se encarga de actualizar y borrar los valores que dejen de ser desplegados después de que el período de 2 minutos dh terminado.

I

I/

Función Refresca-tendencia. Esta función se encarga de refrescar la lista de los valores de la variable en pantalla cada vez que se agrega un nuevo nodo, también realiza el efecto de corrimiento de la gráfica, que le da la dinámica a este objeto.

Función Color. La función Color se encarga de transformar las cadenas de identificación de color a sus valores equivalentes, los cuales son utilizados por el contexto gráfico.


Función Get-GC. Esta función se encarga de crear un contexto gráfico.

Función Marco. La función Marco crea un despliegue en pantalla con una apariencia de 3D, esto con el fin de establecer una apariencia apegada a la de Open Look.

I1

11

1

Valor Default

"000000'' "idl" "Descnpcionl" "Uil" O O O "000000" "i&" "Descripcion2" "Ui2" O O

4 9

/I CAPITULO 4

Nombre Campo

lob2

I carase3 id3 descnpcion3 ui3 valor-estado3 loa3 lob3 carase4 id4 iescnpcion4 ui4 valor-estado4 loa4 lob4 Foreground 1

Alback

I/

11

Nombre Recursos

XtNlob2 XtNcarase3 XtNid3 XtNdescripcion3 XtNui3 XtNvalor~estado3 - Xtbiioa3 XtNlob3 XtNcarase4 XtNid4 XtNdescnpcion4 XtNui4 XtNvalor-estado XtNloa4 XtNlOb4 KtNforeground XtNselect

0 "000000" "1d3" "Descripcion3" "u13" 0 0 0 "000000" "1d4" "Descripcion4" "u14" D 3 3 P Y NULL

Valor Default

!I

50

4.4.3.- Descripción del widget Core firma. I/

El objeto Alarma permite al operador construir una ventana a la que se asocian 20 variables de tipo /lógicas, las cuales se despliegan cuando entran en un estado critico de operación, el objeto Alarma, con apoyo de otro objeto que controla el despliegue de estas, informa al operad& de las variables que se han ido alarmando, cada vez que el operador abra esta ventana, se mostraran las variables que entraron en estado de alarma, indicando la hora en que sucedió esto.

I/ Una vez que el operador reviso la ventana de alarmas, puede borrar aquellas que seleccione con ayuda del ratón, para que en dado caso que se vuelvan a alarmar se desplieguen en la ventana de almas, el objeto Alarma se muestra en la figura 4.7.

/I

4.7 Arquitectura de la clase --_J

Alarma.

Ij La clase Alarma redefine 6 métodos Xt IntrinSics, estos método son: Initialize, Setvalues

(set-values), Redisplay (expose), Destoy, Resize y QueryGeometry (query-geometry), estos métodos pertenecen a la clase Core y realizan las funciones que anteriormente se describieron.

La clase Alarma define la función de acción Notificación, esta función verifica si el apuntador del ratón se encuentra dentro del perimetro del objeto Alarma cuando se oprime el Bml, de ser así regresa un identificador del objeto seleccionado definido por el recurso idobjeto. Este valor nos permite identificar el objeto barra que fue seleccionado y desactivar su modo de visualización en el momento de la construcción del sistema de alarmas y en tiempo de comda de la aplicación real.

'1

I

51

La clase Alarma define un recurso llamado callback que permite ligar una función a una instancia de la clase Alarma en tiempo de corrida. La función se liga ai objeto Alarma por medio de la llamada a XtAddCallback, la cual especifica el nombre de la función que será ligada ai objeto. '

11 La clase Alarma define 5 funciones privadas que realizan las siguientes funciones:

Función Dame-hora. Esta función obtiene la hora actual del reloj de la máquina y la pasa a una cadena que se utiliza en el despliegue del objeto alarma para indicar la hora en la que entió en alarma la variable.

Función Color. La función Color se encarga de transformar las cadenas de identificación de color a sus valores equivalentes, los cuales son utilizados por el contexto gráficos.


Función Get-GC. Esta función se encarga de crear un contexto gráfko.

Función Marco. La función Marco crea un despliegue en pantalla con un look and feel de 3D, esto con el fin de establecer una apariencia apegada a la de Open Look

I

I

0

O

O

j I

R ~ ~ U I W S del widget Alarma.

~a widget Al- define 14 recursos que se describen en la siguiente tabla..

I1 I Nombre Campo

carase IT 'I descripción

ui valor-estado Ica 1Pa IPb Icb loa lob prioridad foreground callback

1, I/

Nombre Recursos

XtNcarase XtNid XtNdescripcion XtNUi XtNvalor-estado XtNlca XtNlpa XtNlpb XtNlcb XtNloa XtNlob XtNpriotidad XtNforegrOun XtNselect

~

Valor Default

"000000" " i d "DescripciÓn" "Ui" O O O O O O O O gray NULL

52

4.4.4.- Descripción del widget Composite Report.

La clase Report es un widget Composite por lo que su función es contener y controlar widgets de la clase Alarma a los que denomina Hijos (children). Esta clase es la que permite construir un grupo,alannas de 20 objetos de clase Alarma. Esta clase se encarga de controlar las dimensiones y psición de estos widget. La arquitectura de la clase Report se muestra en la figura 4.8. II

_____ Arquitectura de la clase Reporte.

Al construir el sistema de alarmas se crea primen, una instancia de la clase Report la cual es padre de las instancias de la clase Alarma como se muestra en la figura 4.9. Esta instancia padre se encarga de controlar los aspectos geométncos de sus widgets hijos definiendo su posición, tamaño, y orden de aparición.

Figura 4.9 Ligado de widgets Alarma al widget Report.

5 3

E' widget Report redefine 4 métodos de la clase Core que son Initialize (initialize), Resi% RedisPhY (expose), Preferredsize (queryjeometry). También define 2 métodos de la clase ComPmik que son: GeometryManager (geometry-manager) y ChangeManaged (change-managed)! Que se describieron anteriormente.

I I La clase Report defme 2 métodos privados que realizan las siguientes funciones

Función Ry_leYOut. La función tryJayout se encarga de verificar las peticiones de modificaciones geometricas del widget padre. Estas modificaciones deben satisfacer ciertas condiciones que establecen sus widgets hijos, esta condiciones vienen dadas por las dimensiones y cantidad de estos. Esta función verifica si las modificaciones geométricaslpropuestas son adecuadas a las dimensiones requeridas para contener a los

I/

de lo contrario la peticion es rechazada.

Esta función se encarga de establecer la posición del widget en la lista hijos del widget padre. La posición de cada widget hijo en la lista es impomte ya que las características funcionales de este widget Report requieren que se despliegue en primer lugar el último widget hijo que se alarmo. La posición en la lista de hijos detemina el orden de despliegue en la ventana de cada widget, esto en forma de lista.

'I

5 4

CAPITU¿O 4 n ARWIrSCmnr DI1 LAS 5RBAKXmm DI1 SOPORTE ':

4.4.5.- Descripción del widget Composite AreaCtrlBarrs.

La clase AreaCtrlBarra es un widget Composite que tiene como función controlar los aspectos geométricos de sus widgets hijos. Esta clase permite la construcción de gmpos de objetos Barra, dos objetos son posicionados en el área del widget padre dependiendo del número de estos, que pueden ser 2, 4, 6 U 8, a cada objeto se le definen las dimensiones y la posición adecuada para ubicarlos en el bloque de pantalla del padre en forma proporcional a sus dimensiones. La figura 4.10 muestra la arquitectura de la clase AreaCtrlBarra.

I

~. . - ~ __- CLASE 'COmpOQltB. L -_ 1

L-. Figura 4.10 Arquitectura d r l a clase AreaCtrlBarra.

El ligado ddllos widgets Barra al widget AreaCtrlBawa se muestra en la figura 4.11.

Figura 4.11 Ligado del widget Barra al widget AreaCtrlBarra.

55

ULPIrnLO 4 ARQVITBcmRI. DE Wis XERXUaBNTM DE SOPORTB

La clase AyaCklBarra redefine 3 métodos de la clase Core que son: Initialbe, Resbe y Preferredsize (query-geometry). También redefine 2 métodos de la clase Composite estos son: ChangeManaged (changemanager) y GeometryManaged (geometry-managed). I

I1 La clase AreaCtrlBarra define 2 métodos privados que realizan las siguientes funciones

Función hy-layout. La función try-layout se encarga de verificar las peticiones de modificaciones geométricas del widget padre. Estas modificaciones deben satisfacer ciertas condiciones que establecen sus widgets hijos, estas condiciones vienen dadas por las dimensiones y cantidad de estos. Esta función verifica si las modificaciones geométricaS' propuestas son adecuadas para poder contener a los widgets hijos, de lo contrario dpetición es rechazada.

Función do-layout. Esta función se encarga de establecer el tamaño y posición adecuado a cada widget de la lista de hijos. A cada widget hijo del widget Composite AreaCtrlBanri se le debe definir un tamaño y posición de acuerdo al número de estos. Las dimensiones y posición widget hijo varían de acuerdo al número de estos que se da en múitipios de 2 (2,4, 6 U 8).

0

/I 1

56

REFERENCIAS.

111 WASSERMAN, Anthony I. et all. Interactive Development Envimments."The Object- Oriented Structured Disegn Notation for Software Design Representation (OOSDN)", COMPUTER, March 1990. pp 50-62.

NYE, Adrian. X Toolkit intrinsics Programing Manual, vol. N, Second Edition, OReilly & Associates, Inc, Sebastopol, CA,

I/ 121

ISBN 0-937175-17-6, 1990.

[3] STAFF OF OaELLY AND ASSOCIATES, iNC. X Toolkit Inkinsics Reference Manual, vol. V, Sechnd Edition, OReilly & Associates, Inc, Sebastopol, CA, ISBN 0-937175-19-5, 1990.

ASENTE, Paul J. el all. X Window Sistem Toolkit, DIGITAL qREsS, USA 1990.

pmDIE, Jon, Graphical User interface and Graphics Standar,

[4]

II [q McGraw-Hill, USA 1992.

[a] REISS, Levi, et all. Aplique X Window, McGra~n-Hill, España 1993.

I

I

'57

..

CAPITULO 5. I

DISENO DEL ADIGMoP. ~~~ ~ ~

En este capitulo se describe el modelo conceptual del ADIGMoP y su arquitectura, también se da una explicación de sus características funcionales.

I/

CAPIlmC 5 Drs& DEL A ü 1 O p

5.1.- Modelo conceptual /I del sistema ADIGMoP. I1

I Ambiente

de

Conetruccldn.

El modelo conceptual del Ambiente de es arrollo de Interfaces Gráficas Hombre- hkkpina con Aplicación al &nitoreo de _Recesos (ADIGMoP) es el que se presenta en la figura 5.1.

Sistemade Generaclon de Codlgo "C" y

Estructura de Datos descrlptora de la

lnteriez

Controlador de Instancias de [ - - F E - - 7 wldgets espaclallzados. ADIQMoP 7 ,

--

- Figura 5 . 1 Modelo conceptual del ADIGMoP.

I/ El sistema se conforma de 3 paites: Ambiente de construcción, la biblioteca de

widgets especializados y el sistema de generación de código.

0 El Ambiente de construcción proporciona los elementos necesarios para la diseño de las interfades grdficas con despliegues básicos como diagramas de barra, diagramas de tendendia y alarmas, el ligado de los objetos gráficos con variables del proceso y la verificación de la dinámica de la interfaz construida, asf como también la recuperación y edición de las mismas.

El Sistema de generación de código permite obtener el código fuente en lenguaje " C de las interfaces diseñadas, así como también una estructura de datos que describe la interfaz c o p i d a , que permite la recuperación de ésta, para posibles operaciones de edición. , La biblioteca de widgets especializados, proporciona los objetos gráficos básicos para la constnicción de interfaces (diagramas de barra, diagrama de tendencias y alaxmas). Estos objetos gráficos básicos permiten crear instancias de estos, las cuales tienen definidas sus características funcionales y atributos, esto se logra utilizando el modelo de Programación Orientada a Objetos para el diseño de estos objetos gráficos.

iI 0

59

CAPITULO 5 D I ü a DEL AüI<pdoP

5.2.- Arquitectura del sistema ADIGMoP.

La herramienta de diseño visual de Interfaces Gráficas al Usuario de aplicación especializada que se diseño en esta tesis, llamada Ambiente de desarrollo de interfaces Gráficas HombdLMáquina con aplicación al Monitoreo de Procesos, se compone de 5 módulos principales como se muestra en la figura 5.2.

11

r F i

u-

r-- ‘.Figura 5.2 Arquitectura del ADIGMoP.

MODULO DE CONSTRUCCION.

EL módulo de construcción realiza las siguientes tareas:

0

0

Define los atributos del grupo a construir. Crea las instancias del objeto gráfico que se seleccionó y las muestra en pantalla.

Para realizar estas tareas el módulo de construcción utiliza las siguientes estructuras

1 de datos:

typedef struct I

Tipoobjeto to; String NombreGrupo; String Nombre Modelo; int num-de-objetos;

)Grupo;

Grupo grupo; Widget InstanciaObjeto[20];

0 Definición de los atributos del grupo a construir. El módulo de construcción utiliza la estructura grupo para almacenar los atributos del grupo que se va a construir, esta estructura nos pehi te definir los siguientes atributos:

60

CAPITULO 5 DIE& DEL AüI-P

- Tipo de objeto que contiene el modelo grupo.TipoObjeto, este campo define el tipo de objeto gráfico seleccionado, cada objeto tiene una bandera de tipo entero que io identifica:l

BARRA = I TENDENCIA= 2 ALARMA- 3

- Nombre del modelo gmpo.NombreModelo, este campo define el nombre del archivo que contendrá las estructuras de &tos que describen la interfaz construida.

I - Nombre del g m p gnipo.NombreGrupo, este campo almacena la cadena del nombre

Número de objetos gráficos grupo.num-deobjetos, este campo almacena el número

del g N p h que pertenecen las variables que serán ligadas a los objetos gráficos. 11

- que define la cantidad de instancias a crear del objeto gráfico seleccionado. Por ejemplo en el caso del objeto Barra se pueden tener de 2 a 8 objetos en el modelo, del objeto Alarma de 1 a 20 y del objeto Tendencia 1.

0 Creación de las instancias de los objetos @cos. Habiendo definido el gmpo, se crean las instanciab del objeto gráfico seleccionado, este objeto se defme a través del campo grupo.to, cada Atancia del objeto gráfico tiene asignado un apuntador en el arreglo InstanciaObjeto[LO], que permite tener acceso a cada instancia, el número de instancias está en función del campo grupo.num-de-objetos.

MODULO DE LIGADO.

El módulo de ligado realiza las siguientes funciones: 1 e Selección de la variable.

I1

0 Ligado del objeto gráfico con la variable.

Para realizar estas tareas el módulo de ligado utiliza las siguientes estructuras de datos:

Typedef struct I

I' Shing carase; String id; Stnng ui; String descripcion; int loa, lob; int lca, lpa, lpb, lcb;

)CamposVariab le;

I! Campos Variable VariableSeleccwnd; Campos Variable ListaObjetos[lO];

61

CAPITUIiO 5 DISdlO DHi u)Io*DP

~ekcción de la variable. Al seleccionar la variable de la lista de vafiables malógicas, 10s atributos de &a se asignan a la estructura VariableSeleccionada, e& m c t m registra 10s valores de 10s atributos de la variable que se seleccionó de la lista.

Ligado del en el modelo,

con la variable. Al seleccionar el objeto gráfico contenido de los atributos de la estructura VariableSeleccionada son

asignados a un índice del arreglo ListaObjetos, el número del Índice del vector al que corresponden estos valores, es proporcionado por el objeto grgico seleccionado.

Por medio del arreglo de apuntadores a las instancias de los objetos gráficos del modelo InstanciaObjeto, los valores de los atributos de la estructura VariableSelecionada son asignados a la instancia del objeto correspondiente.

MODULO DE SIMULACION. 1

El módulo de simulacion permite verificar la dinámica del modelo que se ha constmido por medio de la generación de señales aleatonas, que son asignadas al recurso valor-estado de cada instancia del arreglo InstanciaObjeto, que permite ¿mesar 10s atributos de cada instancia del objeto.

I/

I/ MODULO DE GENERACION DE CODIGO.

El módulo de generación de código realiza las siguientes tareas:

0

0 Generación de la lista de cadenas de sentencia para cada instancia. Creación del archivo de descripción del modelo. Creación del archivo de código fuente "C".

Para realizar estas tareas el módulo de generación de código utiliza las siguientes b

estructuras de dato& typedef struct nodo I

String sentencia; struct nodo *sig;

)Lista;

Lista *ListaSentencias; Lista Tentencia; Grupo grupo; Camposvariable ListaObjetos[20];

0 Generación de las cadenas de sentencia para cada instancia. Para cada instancia se debe tener una sentencia de código que genere la instancia del objeto en la aplicación, para crear estas sentencias se define una cadena que contiene la sentencia para la creación de instancias de la clase y le asigna los atributos de la variable a la que se ligó. La sentencia construida se almacena en un nodo de la estructura Sentencia que va creando una lista ligada apuntada por Listasentencias.

I

62

C A P I n n O 5 I DISER0 DEL AüIoxOP

e Creación del archivo de descripción del modelo. El archivo de descripción del modelo dmacena las estructuras grupo Y ListaObjetos, estas estructuras son grabadas en el archivo iniciando con la esbuctura grupo seguida por cada uno de los índices del arreglo ListaObjetos.

El archivo descriptor del modelo se graba con extensión *.mod y el nombre definido en el campo grupo.NombreModelo. Este archivo permite que el usuario recupere el modelo construido y realice ediciones en éste, obteniendo el nuevo código fuente.

e Creación dkl archivo de código fuente "C". Para cada modelo construido se genera un

este código se lleva acabo abriendo un archivo llamado template.txt que contiene la estructura común de una aplicación de esta naturaleza, este archivo tiene marcas que indican donde se insertará el bloque de código correspondiente de las sentencias que crean las instancias de los objetos gráficos. P h insertar las sentencias se detecta la marca de inicio y se inserta cada uno de los nodos de lad' lista ligada Listasentencias.

MODULO DE RECUPERACION.

1

archivo de código '1 en lenguaje " C , que permite obtener su versión ejecutable. La generación de

1

El módulo de recuperación realiza ias Siguientes tareas:

o Recuperación de modelos creados. e Generación 'be las instancias de los objetos gráficos.

Para realizar estas tareas el módulo de recuperación utiliza las siguientes estructuras de datos: t

11 Grupo grupo; Widget InstanciaObjeto[20]; Campos Variable ListaObjetos[20];

e Recuperación de modelos creados. Para recuperar un modelo, se abre el archivo descriptor NombreModelo.mod que contiene las estructuras que descnben el contenido del modelo. La primer estructura leída de este archivo es asignada a la estructura grupo, que le indica el tipo de objeto gráfico, el nombre del grupo y la cantidad de objetos gráficos. Este archivo contiene las estructuras que definen los valores de los atributos de cada objeto gráfico, los valores de estas estructuras son asignados al arreglo ListaObjetos, que almacenará estos valores.

e Generación de las instancias de los objetos gráficos. Ya recuperado el archivo descriptor se crean las instancias de los objetos gráficos de acuerdo a los valores contenidos en la estructura grupo, que define el tipo de objeto gráfico y el número de instancias.

t I/

li

If 63

11 DISdlO DñL Aü1-p I I,

rAPlTli,*, 5 ~

5.3.- Descripción funcional del ADIGMop.

Una de las Principales aplicaciones de las herramienta$ de programación visual es la const~cción interactiva de Interfaces Gráficas al usuario (GUI) sin necesidad de codificar código. Esta tesis tiene la finalidad de proporcionar una herramienta de aplicación especializada para disefiar interactivamente interfaces gráficas con aplicación al monitoreo de procesos industriales, utilizddo técnicas de Programación visual.

5.3.1.- Fases de construcción de una interfaz en el ADIGMoP.

t

11

Este sistema realiza las siguientes funciones, las cuales definen una mecánica a seguir en

Construcción de la interfaz con los objetos gráficos básicos proporcionados por el ambiente como son: diagramas de barra, diagramas de tendencia y un sistema de alarmas. Ligado dell1 objeto gráfico con alguna variable del proceso, esto se lleva acabo seleccionando una variable de la lista y asociandola con alguno de los elementos que se incluyeron en la interfaz. Generación de código fuente C de la interfaz, este código describe la interfaz gráfica diseñada, del cual se obtiene la versión ejecutable para poder manipular la interfaz en el ambiente grAfico.

Fase de construcción. La fase de LonstNcciÓn de la interfaz se inicia con la selección del icono del objeto

gráfico que se quiera utilizar, como: diagrama de barra, diagrama de tendencia o sistema de a l m a s , al seleccionar alguno de estos objetos, se constmye lo que se denomina un g N p , est0 es, un conjunto de objetos gráficos de la misma clase (barras, tendencia O sistema de a l m a s ) que se agNpan en una ventana. Para obtener un objeto gráfico Se Selecciona el icono que 10 representa, se abre una ventana en la que se pide el nombre del gNp0 que identificara esta GUI, en el del objeto barra se pide el nombre del gNp0 y por medio de un Panel de botones se detemina el numero de barras que contendrá el este como se muestra en la figura 5.3.

la construcción de una interfaz gráfica para monitoreo de procesos:

0

I

0

j/ !!a LL- -_

Figura 5.3 Ventanas de selección de objetos.

64

EL objeto seleccionado se posiciona en la ventana ocupando el área total de ésta, esto se lleva a cabo en el caso del objeto tendencia, en el caso del objeto barra se pueden defmir conjuntos de 2,4, 6 ú 8 objetos barra que se posicionarán en la ventana automáticamente, sin necesidad de que el usuario lo haga, como se muestra en la figura 5.4.

1 I I1

En el caso del sistema de alarmas se despliega una ventana a la que se denomina área de reporte, ya que en ella se visualizan las variables que se seleccionan de la lista automáticamente, al ser seleccionadas se insertan en esta área, en el orden de precedencia que se vaya dando en su selección, el área de reporte soporta únicamente 20 objetos de tipo alarma, ya que el total de éstas, ocupan el área total de esta ventana..

Figura 5 . 4 Ventana de grupo Barra.

I1 Los objetos: proporcionados por el ambiente (barras, tendencia, alarmas y otros) se

diseñaron utilizando el modelo de programación orientada a objetos, por lo que cada uno de éstos contiene los métodos y acciones necesarios que determinan sus características funcionales.

Fase de ligado.

En la fase de ligado se realiza la asociación de cada objeto gráfico de la interfaz con una variable de la base be datos, como se muestra en la figura 5.6. La liga de las variables con cada uno de los objet0s'~gdficos se realiza interactivamente, esto es asociando cada objeto de la interfaz (barra o teidencia) con alguna variable de la base de datos que se muestra en una lista, esta lista de variables muestra los atributos de cada una de éstas, como: identificador, dirección hardware (carase), descripción y unidades de ingeniería.

DISl#O DBL -1-Q 11 CAPITULO 5

! Cuando se realiza la asociación del objeto con la variable, el objeto gr;ifico o Widget toma

los atributos que requiere de cada variable, redespiegandose automáticamente mostrando los atributos de la variable a la qué fie asociada.

DE ATRIBUTOS DE OWETOS ORAFICOS.

Figura 5.5 Ligado de un objeto barra con una variable.

Generación de código. 1 Al terminar de ligar los objetos que compone el grupo el usuario almacena la interfaz

diseñada y obtiene el código fuente equivalente (código C) de la interfaz y una estructura de datos que la describe, la cual nos permite recuperar la interfaz y hacer modificaciones en ella. El código fuente es compilado y se obtiene la versión ejecutable de la interfaz para su manipulación en la) aplicación del monitoreo de procesos, el modelo conceptual de este método de generación de código se muestra en la figura 5.7.

bAWuLOOENER*DOR

.J DE ESTRUCTURA DE

' DEL ORUPO V ARCYIV r- DATOS OESCRlPTORA

-- I

DE LWTA DE LINEAS I DE OODlOO FUENTE Y CRl2&CION DEARCHIV

Figura 5.6 Modelo conceptual de la generación de código.

66

Esta herramienta se desarrolló en plataforma estación de trabajo utilizando el estándar gráfico Own hd& de sun Microsystems y AT&T y las bibliotecas de funciones del estándar X indow del Inshtuto Tecnológico de Massachusetts. La parte medular del desarrollo de este proyecto es el diseño de objetos gráficos denominados Widgets los cuales se diseñan utilizando el modelo de programación orientado a objetos.

5.3.2.- Veriíícación de la dinámica de los objetos.

11 , La verificacion de la dinámica de los objetos gráficos permite al diseñador de la interfaz, observar la dinámica que describen. Cada objeto fue wdigurado con los atributos que se le asignaron con la liga de su respectiva variable. El verificar la dinámica de los objetos gráficos de la interfaz nos permite observar si el objeto se esta comportando de acuerdo a los límites operacionales que le definió la variable a la que se ligó, como se muestra en la figura 5.8.

... ..

y

Figura 5.7 Verificación de la dinámica de la interfaz.

5.3.3.- Recuperación de un grupo o interfaz.

La opción de recuperación permite al diseñador recuperar alguna de las interfaces o grupos que han 'sido diseñados, esta recuperación se realiza seleccionando el archivo NombreGrupo.mod que se generó al salvar la interfaz en la fase final de construcción. Este archivo NombreGrupo.mod se selecciona de una lista desplazable que se muestra en una ventana, la cual contiene todas las interfaces o grupos que ya han sido diseñados; al seleccionar algunos de estos ?pos automáticamente se despliega la ventana en el h a de edición y aparecen los objetos gráficos mostrando los atributos de las variables a los que fueron ligados.

Ya estando la ventana de la interfaz desplegada en el área de edición se puede volver a

;i

I

I1

I

CAPITULO I/ 6.

PRUEBAS. En este capitulo se presenta un programa de pruebas que tienen como objetivo el verificar

el cumplimiento di’los requerimientos establecidos para el desarrollo de este trabajo.

CAP1TUJ.C 6 11 P R w B i g 't

El objetivo de esta sección es presentar un programa de pruebas que nos permita verificar el cumplimiento de los requerimientos establecidos para el desarrollo de este trabajo, 10s objetivos de estas pruebas son los siguientes:

0 Verificar la construcción de grupos que contengan alguno de los objetos gráficos básicos proporcionahos por el ambiente como: diagramas de barra, diagramas de tendencia o sistema de a lmas .

Verificar la generación de los archivos de descripción del grupo *.mod y el archivo de código en lenguaje "C" *.c.

Verificar la asignación de valores a las atributos de los objetas g r á f h s como: carase, identificador de la variable, etiqueta de descripción de la variable, valores de los limites

t I)

O

0

de los estados de operación y unidades de ingeniería.

de grupos construidos.

I Prueba 1.

Objetivo. La prueba 1 tiene como objetivo la construcción y generación de los archivos de un grupo

que contenga 2 objetos gráficos de tipo Barra con los siguientes atributos que definen el grupo:

- Nombre del Modelo: ModeloBlmod. - Nombre del Grupo: - Numero de Objetos Gfl~cos :

'1 81

Turbina de Vapor. 2.

I

I! Procedimiento.

Se selecciona del menú principal la opción de Construcción que despliega la ventana donde se introduce el nombre del modelo, se selecciona el icono del objeto gráfico Barra, se despliega la ventana para definir los requerimientos de Barra, se introduce el nombre del grupo y se selecciona el botón que indica 2 objetos, estos objetos se ligaron a las variables con el identificador V1234, y V1235. Se seleccionó del menú principal la opción Archivo y Salvar.

/I Resultados. El resultadoiide esta operación es el despliegue de una ventana que contiene 2 objetos

gráficos Barra, cm los atributos de las variables V1234 y VI235 y la creación de los archivos ModeloBlmod y ModeloB1.c.

69

PRWIUS I/ !

CAPITULO 6 - Prueba 2.

Objetivo.

que contenga objetos gráficos de t i p Barra con los siguientes atributos que definen el gmpo:

- Nombre del Modelo: - Nombre del Grupo: - Numero de Objetbs Gráficos:

Procedimiento. Se selecciona del menú principal la opción de Construcción que despliega la ventana

donde se introduce el nombre del modelo, se selecciona el icono del objeto gráfico Barra, se despliega la ventani para definir los requerimientos de Barra, se introduce el nombre del gmpo y se selecciona el /tón que indica 4 objetos, estos objetos se ligaron a las variables con el identificador V1230, V1231, V1232 y V1233. Se seleccionó del menú principal la opción Archivo y Salvar. "

Resultados. El resultado de esta operación es el despliegue de una ventana que contiene 4 objetos

gráficos Barra, con los atributos de las variables V1230, V1231, V1232 y V1233 y la creación de los archivos MobeloB2.mod y ModeloB2.c.

La pmeba 2 tiene COmO objetivo la COlUtmcciÓn y generación de los archivos de un gmpo ~

I ModeloB2.mod. Turbina de Vapor. 4.

I

Prueba 3. 11

Objetivo. La pmeba 3 tiene como objetivo la construcción y generación de los archivos de un gNP0

que contenga 6 objetos gráficos de tipo Barca con los siguientes atributos que definen el gmpo:

- Nombre del Modelo: ModeloB3.mod. - Nombre del Grupb: - Numero de Objetbs Gráficos:


donde se introduce el nombre del modelo, se selecciona el icono del objeto gráfico Barra, se despliega la ventana para definir los requerimientos de Barra, se introduce el nombre del gmpo y se selecciona el botón que indica 6 objetos, estos objetos se ligaron a las variables con el identificador V1237, V1238, V1240, V1244, V1245 y V1250. Se seleccionó del menú principal la opción Archivo 'b Salvar.


gráficos Barra, con los atributos de las variables V1237, V1238, V1240, V1244, V1245 y V1250 y la creación de los archivos ModeloB3.mod y ModeloB3.c.


I/

I/

70 'I

O P I W L O 6 PRtmBJkS I

I1 Prueba 4.

Objetivo. La Pmeba 4 tiene como objetivo ia construcción y generación de 10s archivos de un grupo

contenga 8 objetos gráficos de tipo Barra con los siguientes atributos que definen el grupo: ~

- Nombre del Modho: ModeloB4.mod. - Nombre del Gmh: - Numero de Objeth Gráficos:


donde se introduce el nombre del modelo, se selecciona el icono del objeto gráfico Barra, se despliega la ventana para definir los requerimientos de Barra, se introduce el nombre del grupo y se selecciona el P tón que indica 8 objetos, estos objetos se ligaron a las variables con el identificador V1237, V1238, V1240, V1244, V1245, V1238, V1240, y V1250. Se seleccionó del menú principal la opción Archivo y Salvar.


gráficos Barra, con los atributos de las variables V1237, V1238, V1240, V1244, V1245, V1238, V1240, y V1250 y )a creación de los arcbivos ModeloB4.mod y ModeloB4.c.


11

Prueba 5.

Objetivo. La prueba 5 bene como objetivo la construcción y generación de los archivos de un grupo

que contenga un objetos gráficos de tipo Tendencia con los siguientes atributos que definen el gnipo:

- Nombre del ModAlo: ModeloT5.mod. - Nombre del GruI;b: Procedimiento.

Se selecciona del menú principal la opción de Construcción que despliega la ventana donde se introduce el nombre del modelo, se selecciona el icono del objeto gráfico Tendencia, se despliega la ven” para definir los requerimientos de Tendencia, se introduce el nombre del grupo, las despliegues para las 4 variables se ligaron a las variables con el identificador V1237, V1238, V1240 y V1244. Se seleccionó del menú principal la opción Archivo y Salvar.

Caldera Principal.

i Resultados.

El resultado de esta operación es el despliegue de una ventana que contiene el objeto dfico Tendencia. con los atributos de las variables V1237, V1238, V1240, V1244 y la creación _------ ~

de los archivos ModeloB5.mod y ModeloB5.c.

71

ii

CAPITULO 6 PmmnLs I/

I\

Prueba 6.

Objetivo. La Prueba 6 tiene como objetivo la construcción y generación de 10s archivos de ,,,, g.,,po

que contenga 10 objetos gráficos de t i p Alarma con los siguientes atributos que definen el grupo:

- Nombre del Modelo: - Nombre del Grupo:


donde se introduce el nombre del modelo, se selecciona el icono del objeto gráfico Alarma, se selecciona del menú principal la opción de Ligar Variable a Objeto se seleccionan las variables V1237, V1238, V1240, V1244, V1245, V1238, V1240, V1250, V1251 y V1252, cada vez que se selecciona la variable se crea la instancia de cada objeto Alarma. Se seleccionó del menú principal la opción krchivo y Salvar.

Resultados. El resultado de esta operación es el despliegue de una ventana que contiene IO objetos

gráficos Alarma, con los atributos de las variables V1237, V1238, V1240, V1244, V1245, V1238, V1240, V1250, V1251 y V1252 y la creación de los archivos ModeloA6.mod y ModeloA6.c.

ModeloA6.mod. Turbina de Vapor.

11

11

Prueba 7.

Objetivo. La prueba 7 tiene como objetivo la construcción y generación de los archivos de un grupo

que contenga 5 objetos gráficos de tipo Alarma con los siguientes atributos que definen el grupo:

- Nombre del Modelo: ModeloA7.mod. - Nombre del Grupo:


donde se introduce el nombre del modelo, se selecciona el icono del objeto gráfico Alarma, se selecciona del menú principal la opción de Ligar Variable a Objeto se seleccionan las variables V1201, V1202, V1203, V1204 y V1205, cada vez que se selecciona la variable se crea la instancia de cada objeto Alarma. Se seleccionó del menú principal la opción Archivo y Salvar.


gráficos Alarma, con los atributos de las variable V1201, V1220, V1203, V1204 y V1205 y la creación de los archivos ModeloA7.mod y ModeloA7.c.

Caldera Principal.

'1

72

C A P I n n o 6 PRVEEAS I;

Prueba 8.

gráficos Barra, con V1240, y V1250.

los atributos de las variable V1237, V1238, V1240, V1244, V1245, V1238,

Objetivo.

construidos, el modelo a recuperar será el ModeloA6.mod.

Procedimiento. Se selecciona del menú principal la opción de Archivo y la opción Recuperar, esta

operación despliega una ventana con barra de desplazamiento que muestra los modelos construidos, se selecciona el modelo ModeloB4.mod.

Resultados. El resultadoide esta operación es el despliegue de una ventana que contiene 8 objetos

gráficos Barra, con los atributos de las variable V1237, V1238, V1240, V1244, V1245, V1238, V1240, y V1250. /I

La prueba 9 tiene como objetivo verificar la recuperación de uno de los modelos

I

Prueba 10.

Objetivo. La prueba 10 tiene como objetivo verificar la recuperación de uno de los modelos

construidos, el modelo a recupem será el ModeloA6.mod. 1! \

Procedimiento. Se selecciona del menú principal la opción de Archivo y la opción Recuperar, esta

operación despliega una ventana con barra de desplazamiento que muestra los modelos construidos, se selecciona el modelo ModeloA6.mod.

73

Resultados. 1)

El resultado de esta operación es el despliegue de una ventana que contiene 10 objetos gráficos Alarma, con los atributos de las variable V1237, V1238, V1240, V1244, V1245, V1238, V1240, V1250, VI251 y V1252.

I/

CAPITUbO 7.

CONCLUSIONES. En este capítdo se presentan las conclusiones obtenidas con el desarrollo del ADIGMoP,

también se presentan los beneficios de este trabajo, los alcances logrados y las posibles ampliaciones y mejoras de éste.

I/ 7.1.- Conclusiones.

El Ambiente de Desarrollo de interfaces W i c a s Hombre-Máquina con Aplicación al Monitoreo de Procesos (ADIGMoP) es una herramienta de software interactivo que permite la p rogmción visual de prototipos de interfaces graficas para aplicaciones de monitorm de procesos. Esta hedmienta permite que usuarios inexpertos puedan programar visualmente una aplicación que pueden utilizar para monitorear cualquier tipo de procesos en los que intervengan variables de tipo andógicas.

En base a io propuesto ai principio de este trabajo, concluimos que todos los puntos especificados en el su alcance fueron cubiertos, debiendo proporcionar una hemmienta de software interactivo que soporte la construcción de prototipos de despliegues gráficos con diagramas de barra,!tdiagramas de tendencia o un sistema de alarmas y la generación de código fuente en lenguaje "C" de estos despliegues para poder generar su versión ejecutable.

I

11 Las herramientas utilizadas para el desarrollo del ADIGMoP nos permitieron asimilar la técnica de construcción de elementos abstractos denominados Widgets. Estos tipos de datos abstractos permiten hnstruir cualquier tipo de objeto con características funcionales especiales, que van desde aplicbciones administrativas hasta aplicaciones de ingeniería, esto es posible ya que se utiliza el modelo de Programación Orientada a Objetos, emulado con programación procedural, para su construcción. 1)

El desarrollocie este trabajo nos permite compartir los principios necesarios para el diseño de herramientas de programación visual y la construcción de widgets, de los cuales consideramos que son una herramienta útil para el diseño de bibliotecas de widgets especializados, permitiendo la reusabilidad y escalabilidad de éstos. Es importante remarcar que el diseño de widgets especializados se a5nsidera una de las tendencia que va surgiendo con mucha fuerza para plataformas estación de trabajo y sistema operativo UNIX, plataforma que se esta perfilando como la sucesora de las computadoras personales.

ir

I/

La plataforma de desarrollo que se utilizo, permite que el ADIGMoP sea portable ya que la plataforma estación de trabajo con tecnología RISC, sistema operativo UNIX y ambiente de ventaneo fueron desarrollados con filosofía de sistemas abiertos, lo cual permite que el ADIGMOP emigre a'l otras piataformas con esta filosofía.

El ADIGMoP es escalable ya que permite la integración de nuevos widgets, diseñados de acuerdo a las ne&idades del usuario o de la aplicación. Esta Herramienta puede ser utilizada en diversas aplicaciones de monitoreo como por ejemplo en aplicaciones de monitoreo de señales en el laboratorio de'leiectrónica o de mecánica del CENIDET o en prototipos de sistemas de adquisición de datos del Instituto de investigaciones Eléctricas. Además de permitir la construcción de widgets especializados para cualquier clase de aplicación ya sea de ingenieda o administrativa.

7 6

I/

coNcLIIs10Nxs Y L m RlRlius I/ ULPITULO 7

7.2.- Beneficios. I/

II 0 Contar con una herramienta para la construcción interactiva de interfaces de usuario que

puedan ser usadas en el diseño de prototipos de interfaces para aplicaciones de monitoreo de procesos, en sistemas de adquisición de datos, asi como en aplicaciones de monitoreo de señales de laboratorio, como por ejemplo, de los laboratorios de electrónica y mecánica del CENIDET.

El proporcionar una herramienta propietaria que permita el desarrollo de nuevas aplicacione:' de acuerdo a las necesidades del usuario, disminuyendo con esto los costos de adquisición de software de aplicación.

I1

0

I/

7.3.- Alcances logrados.

En general, el objetivo global de esta tesis fue alcanzado: El desarrollo de una herramienta de construcción interactiva, utilizando la Programación Visual para el diseño de interfaces gráficas con aplicación al monitoreo de procesos, que puedan incluir diagramas de barra, diagramas de tendencia y un sistema de alarmas, que permita ligar interactivamente los objetos gráficos contenidos i n la interfaz con las variables del proceso, recuperación de interfaces creadas y la generación de código fuente en lenguaje "C" de las interfaces diseñadas que permita la obtención de la versión ejecutable de éstas y puedan ser ligadas a una aplicación.

El resultado de los objetivos específicos de esta tesis fueron los siguientes:

El desarrollo de la metodologia para la construcción de herramientas de programación visual de interfaces gráficas con aplicación al monitoreo de procesos.

La asimilación de la arquitectura del widget, que nos permitirá construir nuevos despliegues gráficos de acuerdo a las especificaciones del usuario, creando con esto una biblioteca de despliegues que pueden ser utilizados por la aplicación.

El desarrollo del algoritmo que nos permite obtener el código fuente en lenguaje "C" de las interfaces ,;diseñadas, para poder obtener la versión ejecutable de éstas y puedan ser ligadas a un programa de aplicación.

't

11 0

0

1

0

0 El establecimiento de la metodologia a seguir para poder ligar la versión ejecutable de las interfaces diseñadas a programas de aplicación.

/I

,I

'I

11

7.4.- Mejoras y ampliaciones a este trabajo. j

'i Durante el desarrollo de esta tesis fueron surgiendo nuevas ideas que permitirán mejorar

este trabajo, ya que como tesis tiene sus limitaciones y alcances, por io que se proponen las siguientes modificaciones:

0 Desarrollo de un ambiente prototipo que permita la manipulación de las interfaces, este ambiente debe proporcionar los medios para accesar una base de datos que simule el comportamiento de un proceso.

La amplia?ión de la biblioteca de despliegues gráficos, que permitan la aplicación de esta herramienta en tareas de investigación de esta institución, estos objetos gráficos pueden ser diseñados a partir de necesidades de los laboratorios de electrónica y mecenica

Creación de la versión de esta herramienta para el ambiente Motif que se considera será el estandarlgráfico para la plataforma estación de trabajo.

incluir mecanismos que permitan de fd r la jerarquía de los objetos gráfkos que se insertan en"ia aplicación.

Desarrollarlun sistema de construcción interactiva de widgets, que permita al usuario diseñar interactivamente clases de widgets con caractensticas funcionales y de apariencia deseadas.

t

0

0

0

O

II

h

7 8

ANEXO, A.

ii

I!

SISTEMA X WINDOW.

arquitecaurr. Este capitulo da una introducción al sistema X Window explicando su filosofía y su

I/ -0 A

Sistema X Window.

El sistemk X Window es un sistema de ventaneo independiente del hardware y software, este fue desarrollado conjuntamente por MIT y DEC, y ha sido adoptado por la industria computftcional como un estándar para aplicaciones griificas [l].

EL sistema X Window a creado un gran interés en la industria de la computación, ya que ofrece soluciones a muchos de los problemas que han surgido en el área del trabajo en redes, como: ympartición de recursos, gráficos y multiproceso. Ha reestructurado el concepto Cliente-Servidor, y a la idea de procesos distribuidos le a dado un significado mas real.

I1

De la misma forma que otros sistema de ventaneo, el sistema X Window divide la pantalla en mÚ1t~ple.s áreas de entrada y salida (input-output) llamadas Ventanas (Windows). Utilizando una terminal emuladora, las ventanas pueden actuar como Terminales Virtuales.

Lo que hace diferente al sistema X Windows de los demás sistemas de ventaneo, es que se implemento como un protocolo de red y no como un sistema procedural y de llamadas a sistema (21. Eke diseño basado en un protocolo de red permite que X Window sea portable a diferentes plataformas y sistemas operativos, esto tambikn permite que una aplicación se ejecute en una plataforma o sistema operativo mientras se despliegue en otra. El sistema X Window se ddrrollo bajo W I X , pero este puede ser implementado sobre cualquier sistema operativo (VAX/VMS, DOS, o OS/2). Pero debido a su arquitectura basada en el modelo Cliente-Servidor es mas eficiente en sistemas operativos de muititarea que soporten procesos distribuidos.

,I

El sistema X Window es un sistema que proporciona soporte para trabajo en red, gráficos y técnicas de control de ventanas, además de los anterior ofrece manipulación

otras ventajas que a continuación se describen: 'I

Transparencia. El sistema X Window permite que el usuario accese y despliegue aplicaciones, de forma transparente en otras terminales remotas.

't

Aplicaciones Multiples. El sistema X Window permite al usuario desplegar multiples aplicaciones simultáneamente en ventanas traslapadas.

Exten%ibilidad. El sistema X Window se diseño para soportar futuras extensiones.

Consistencia. El sistema X Window proporciona consistencia a las aplicaciones sin ,I

impoxtar la plataformas.

El cor,azón de la filosofía de X Window es la arquitectura Cliente-Servidor [l]. Esta arquitectura es el modelo del sistema X Window, mediante la cual, los clientes o programas de aplicación: se. comunican con el servidor, o unidades de visualización atravez de una red local. En la figura A.l se muestra la arquitectura cliente/servidor

1 Básicamente el cliente es el programa de aplicación que puede encontrarse en alguna de las terminales de la red, el cliente obtiene una entrada del usuario como por ejemplo, la pulsación del una tecla o la pulsación de un botón del ratón desde el servidor, el cliente al

80

-0 A I

recibir la entrada i1. ejecuta las ordenes X Window que requiere el servidor para poder dibujar los gráficos; varios clientes pueden estar conectados a un único servidor.

1 APLICACION I I 1

RED DE COMUNICACION I/

Figura A.l Arquitectura Cliente/Servidor.

I/

Se puede decir que el servidor es la unidad de visualización, que a su vez puede estar compuesta por vanas pantallas físicas. El servidor ejecuta diversas funciones relacionadas entre si: 1

Permitir el acceso a despliegues de multiples clientes.

- Pasar la entkada del usuario a los clientes mediante el envío de mensajes por la red denominadds eventos, que representan acciones del usuario tales como: oprimir una tecla, o el botón del ratón, entre otros.

Decodificar los mensajes de los clientes, como las peticiones de información o el movimiento de una o varias ventanas. Estos requerimientos se expresan en un protocolo denominado X-protocolo.

Mantener las estructuras de datos complejas. El manejo de estas estructuras de datos por el servidor reduce las necesidades de almacenamiento y de procesamiento del cliente además de disminuir la cantidad de datos a transmitir atravez de la red.

- I /

Protocolo-X. I I!

El Protocolo-X, es un lenguaje de descripción gráfico de alto nivel, este transporta los paquetes de instrucciones desde el programa de aplicación Cliente hasta el Servidor.

Las aplicaciones del usuario desplegadas en una o varias pantallas controladas por un servidor (programa de aplicación que corre en una computadora o en la misma maquina) son llamadas Clientes, estos pueden ser varios clientes conectados a un servidor. Los Clientes

I1 81 I1

-0 A I/

pueden correr en la misma maquina del servidor si la arquitectura de la maquina soporta multitareas, o puede estar corriendo en otras maquinas de la red. En cualquiera de los casos, el cliente utiliza 'k1 Protocolo X para enviar sus peticiones (requqts) de trazo de gráficos, o para consultar información del servidor (query), y es usado por el servidor para enviar las entradas del u s d o , y enviar la información requerida por el cliente.

d

It Todas las comunicaciones desde el cliente al servidor y desde el servidor al cliente son

Por medio del ~ ~ t ~ ~ ~ l ~ X. La vía de comunicación entre el cliente y el servidor es llamada conexión.

Jerarquía del software.

I(

Para dedo l l a r aplicaciones para el Sistema X Window en los estandares gráficos Motif y Open Look se utiliza el lenguaje C ANSI, las bibliotecas Xt intrinsics y un conjunto de widgets, propios del estándar. Esta es una de las muchas manera de desarrollar aplicaciones para iX Window, ya que este no está restringido a un solo lenguaje y sistema operativo. Sin embargo por varias razones se espera que el utilizar estas herramientas sea la forma mas comúdde desanollar aplicaciones para X Window, por su amplio poderío, además de tener buena compatibilidad con otras aplicaciones de X Window y soportar convenciones de interfaces de usuario comerciales.

11

En la figura A.3 se muestran las capas de software que componen una aplicación que utiliza las Xt Intrihics y el conjunto de widgets. Observemos que el conjunto de Xt intrinsics se implemento con las X libraries (Xlib), el nivel mas bajo de librerfas escritas en lenguaje C de la interface X Window. Las Xlib proporcionan un acceso total al Protocolo X. Estas controlan el dialogo entre una aplicación y el canal de comunicación (network), además de optimizar el uso de este.

Las Xt hyinsics se implementaron con las Xlib, la función de las Xt Intrinsics es el proporcionar la capa de soporte entre objetos abstractos llamados Widget y la interfaz del usuario. Un widget ea reusable, una pieza de c6digo configurable que tiene independencia de la aplicación. Un ynjunto de widgets proporciona elementos comunes para la construcción de interfaces usuario con una apariencia consistente lo que se conoce como "Look & Feel", estos elementos son: botones, scrollbars, menúes, etc.

I/

82

AUEXO A

APLICACION

WIDGETS

Xt INTRINSICS

SERVIDOR X

II l i l !

\ ~

MANEJADORES DE DISPOSITIVOS n

Figura A . 3 Niveles de programacion con X

I

Window.

83

[l] REIS, Levi MCGEIWII-

[2] NYE, Adri OReilly & ISBN 0-93

[3] NYE, Adri Second Ed ISBN 0-93

REFERENCIAS.

e al. Aplique X Window, ill, España 1993.

1. Xlib Programing Manual, vol. I, issociates, Inc, Sebastopol, CA, 175-11-0, 1990.

1. X Toolkit Intnnsics Programing Manual, vol. IV, on, OReilly & Associates, Inc, Sebastopol, CA, 175-17-6, 1990.

I

ANEXO

CEASES B Este anexa

Constraint, de cad

SICAS DE XT INTI iestra las superclases principalc ase se muestan sus estructura y

INSICS. de Xt intrinsics Core, Composite y ~CUISOS

-0 B

Clase Widget Core.

La clase idget Core es la clase mas básica. Todo Widget es subclase de Core. Esta clase se compone de doslestnicturas de datos principales: la estructura Clase registro (CoreClassPart) y la estructura registro instancia (Corepart). Ambas estructuras se definen en el archivo de cabecera <Xll/Co:eP.h>. La arquitectura de esta clase se muestra en la figura B.l.

I/

I ' I

.WM

I

L

Figura -_ B.l

CLASE: "Core"

Arquitectura de la clase

I v

Jerarquia de la clase.

Object -> RectObj !> Unname -> Core

Registros y apuntadores predefinidos. I1

extern idgetClassRec widgetClassRec; #&fine CoreCiassRec widgetClassRec extern Widgetclass widgetclass, core Widgetclass:

Estructura registro clase.

typedef struct -CoreClassPart{ WidgetChs supe fclass; string cb-nami! . Cardinal widget-size; Xtproc c.lass-initihiize; /*Procedimiento class-initialize */ XtWidgetClassProc ciassgart-initialize; XtEnum class-inited; /*bandera de inicializacion*/ XtInitProc initialize; XtArgsProc initialize-hook;

I

/*Apuntador a la super clase*/ /*Nombre de la clase $/ /?amaño en bytes de la clase*/

/*Apt. a procedimiento initialize */ /*Notifica llamada de initialize*/

86

XtRealize Proc irealize; XtActionList actions; Cardinal numJactions; XtResourceList resources; Cardinal numiiresources; XrmCLass xnn-class; Boolean compí;ess-motion; XtEnum compress-exposure; Boolean compqess-enterleave; Boolean visible-interest; XtWidgetProc destroy; Xt WidgetProc ;esize; XtExposeProc expose; XtSet ValuesFunc set-values; XtArgsFunc set-values-hook; XtAimostProc iet-values-almost; XYlrgsProc getLvalues-hook; XtAcceptFocusProc accep focus; X t VersionType version; XtPointer callbhckgrivate; String tm-table;

/*XCreateWindow para el Widget*/ /*Cadena a un mapa de acciones*/ /*Numero de entradas de acciones*/ /*Campos recurso de la clase*/ /*Numero de entradas de recursos*/ /*Recurso de la clase*/ /*Compresion MotionNotify */ /*Compresion del evento Expose */ /*Entradas comprimidas y permitidas*/ /*Bandera para modo de notoficacion*/ /*Procedimiento destroy*/ /*Procedimiento de control geomet. */ /*Procedimiento de despliegue */ /*Proc. de iniciaizacion de recur*/ /*Notijca llamada a set-values*/ /*Bandera de notification*/ /*Notijca llamada a get-values*/ /*Asigna el input focus al widget */ /%eversion usada */ /*lista de callbacks*/ /*estado de la marruina*/ -~

XtGeometryHandler querySeome6; /*retorna las dimensiones*/ XtStringProc display-accelerator; /*despliega los aceleradores*/ XtPointer exredion;

)CoreClassPart; /*apuntador al registro extension */

II

Todos las clases de widgets tienen ¡os campos de la clase Core como primer componente. idget como sean necesario, para poder especificar Se pueden definiI! apuntadores a la clase del

la clase del idget.

typedef struct -Corepart/ CoreClassPart 11 core-class; ] WidgetClassRec, *Widgetclass, CoreClassRec, *Core Widgetclass;

La estructura registro instancia se define como sigue.

typedef struct -CorePart(

//I

I1

I

Widget se& Widgetclass widiet-class; Wdget parent; /*Widget padre*/ XrmName xrm-name; Boolean being-destroyed; /*marca de destruction*/ XtCallBackiist dstroy-callBacks; /*llamada a proc. de destroy*/ XtPointer constraints; /*registro de restricciones*/

/*Apuntador a la misma clase*/ /*Apt. a ClassRec del widget*/

/*nombre de recurso del widget*/

11

il 87

II

ANEXO 8

Position x, y; /*Position de la ventana*/ Dimension width, height; /*Dimensiones de la ventana */

/*Ancho del borde*/ /*Bandera de control del widget*/

Dimension border-width; Boolean managed; Boolean sensitive; /*bandera.de sensibilidad a eventos*/ Boolean ancestor-sensitive; /*Bandera de sesibilidad ancestro*/ XtEventTable Jvent-table; /*Campo privado al &spaChador*/

/*Controlador de traducciones*/ XtTranslations accelerators /*Acelerador de traducciones*/

/*Color del borde de la ventana*/ /*Color del borde del pixmap*/

XtTMRec tm;

Pixel borderjixel; Pixmap bordeigixmap; WidgetList popup-list; /*Lista de pop ups*/ Cardinal numgopups; /*Numero de popups*/ String name; /*Recurso nombre del widgel*/ Screen *screen;. /*Pantalla de la ventana */ Colormap colormap; /*colonnap */ window window; /*ID ventana */ Cardinal depth; Pixel backgroundjixel; /*Color del fondo*/ Pixel Backgroundjixmap; /*Color del pixmap*/ Boolean visiblt!; /*Bandera de ventaba mapeada o no*/ Boolean mappid-when-managed; /*Ventana mapeada si esta manejada */

idget se defme lo siguiente:

P

/*Numero de Planos de la ventana*/

]corepart; 11

typedef struct( CorePart core; ] idgetRec, * ' idget, CoreRec, *Core idget;

Para esiecificar el tipo de la clase del I

Los valores por default para los campos de la clase core son los siguientes:

I Campo I Valor por default

I2 self widget-class parent /I xrm-name 1

beingdestroyed destroy-calldacks constraints

:I

X

Y I width I height

Direccion de la estructura del Clase del widget lo pasa XtCreate idget. Padre del widget io pasa XtCreate idget.

Valor del padre. NULL. NULL. O O O O

idget.

8 8

http://bandera.de

Campo

border-width managed 11

sensitive ancestor-sensitive event-table tm accelerators ,, border-pixel border-pixmap popup-list I1 num-popups name screen colormap window I,

depth background-pixel backgrod-pixmap visible mappedwhen-manage

1)

I

Valor por default

1 FALSE TRUE Padres sensitivos y ancestro sensitivos. inicializada por el manejador de eventos. inicializada por el manejador de recursos. NULL XtDefaultForepund XtUnspecifiedPixmap NULL O Argumento nombre pasado pos XtCreateWidget Pantalla padre pasada por el display. El color por default del monitor. NULL Profundidad de la ventana raiz. XtDefaultBac kground XtUnspecifiedPixmap TRUE TRUE

/I

Métodos Definidos por la Clase Widget Core.

La clake widget Core define varios métodos de los cuales describiremos los que fueron de mayor interés para el desarrollo de este trabajo.

e Método realize. Este método es invocado por Xt para cada instancia cuando la aplicación llama XtRealizeWidget para crear el widget toplevel de la aplicación. Este método se encarga de inicializar los recursos de la ventana de la aplicación. UM clase widget puede heredar este método de su superclase en tiempo de compilación mediante la especificación de la bandera XtinheritRealize en el campo del apuntador al método realize.

Método Initialize. El método Initialize realiza las siguientes tareas. Asigna espacio a r a d s que son referenciados por dirección, por ejemplo recursos de tipo String (char *). Calcula los valores apropiados para algunos r e c m , por ejemplo el ancho (width) y largo (height) se calculan basándose en otros recursos. Calcula valor de campos que no son recursos que dependen del valor de algunos campos recurso, por ejemplo el valor del campo contexto gráfico (CC) depende del valor de los recursos foreground, background

I,

8 9 11

y font. El orden de llamada del método Initialize es de superclase a subclase. Si la clase widget n'b necesita desarrollar ninguna de las tareas anteriores puede omitir el metodo initialize'jespecificando NULL en el campo de la estructura clase.

Método Expose. El método expose es el responsable del despliegue inicial del widget en la v&tana y de redesplegar las áreas del widget que estaban ocultas y han sido descubiertas. El método expose. se encarga de dibujar el widget en la ventana que lo contiene, este método permite que el widget se redibuje cada vez que este expone alguna de sus partes que han sido cubiertas o cuando este es expuesto totalmente.

Método set-values. El método set-values es responsable de verificar la validez de los valores que son pasados con XtSetValues, además de actualizar los valores de los campos que no son públicos, como el contexto gráfico (GC) que depende del valor de campos recurso. El método set-values se encarga de determinar si el widget debe ser redesplegado a causa de una modificación del valor de un campo o de algún campo recurso, por ejemplo si se modifica el tipo de font utilizado por el widget, este debe ser redesplegado.

Método hestroy. El método destroy es el responsable de liberar toda la memoria asignada por la idkancia del widget. El orden de llamada del método destroy es de subclase a superclade. El método destroy de un widget solo puede liberar la memoria asignada por el mismo? y no la asignada por su superclase. Si el widget no necesita liberar memoria el campo d h apuntador al método destroy se puede declarar NULL.

Metodo query-geometry. El método queryseometry se encarga de evaluar las propuesta de modificaciones a la geometría del widget. El widget le pa& al método una estructura que contiene la información de los cambios geometría del widget, el método se encarga de evaluar la petición y regresa una respuesta que le indica al widget si se aceptó su petición, si se acepto casi por completo o si no fue aceptada. Si los cambios geométricos son aceptados sin ninguna modificación, el método queryseometry regresa una bandera XtGeometryYes, si alguno de los campos de la propuesta de cambios geométricos es cambiada por el métodos regresa una bandera XtGeometryAlmost y si los cambios geométricos son iguales a la geometría actual del widget el metodo regresa una bandera XtGeometry No.

jl

90

ANEXO 8

4 Clase Widget Composite.

/I La clase widgets Composite es subclase de Core esta define métodos para el control

geométricos db widgets. Todo widget que requiera controlar widgets debe derivarse de la clase Composite. La Clase y la estructuni instancia de Composite se definen en el archivo de cabecera <X1 l/CompoSiteP.h>. En la figura B.2 se muestra la arquitectura de la clase Composite.

I I IFigura B . 2 Arquitectura del widget Composite.

Jerarquía de la clase: Core -2 composite.

I1 Registros y apuntadores predefinidos. 11

exrern CompositeClassRec compositeClassRec; extern YdgetClass composite Widgetclass;

La estructura ,,Clase y Registro Clase.

La m c t u r a Clase del widget Composite se define como sigue:

Typedef struct lCompositeClassPart{ /* anejador geometrico de los widget hijos*/

/*Apt. a Proc. de cambio de estado de control del widget hijo*/

/*Apuntador a Procedimiento para añadir un widget hzjo al padre*/

/*Apuntador a procedimiento que borra un widget hijo del padre*/

XtGeometryHandler geometry-manager;

Xtwídge fProc change-managed;

XtWidge?Proc insen-child;

91 I/

li

I

X t WidgetProc deletechild; /*Apuntador a la exthctura extencion*/ I XPointer extension; JCompositeClassPart, *CompositePartPtr;

11 La clase widget Composite tiene los definidos los c a m p de su estructura inmediatamente

despues de los campos de Core. iI

typedef structt CoreClaisPaA core-class; CompositeClassPart composite-class;

}CompositeClassRecj *Composite Widgetclass;

La estructura Instancia y registro Instancia.

I

I1 La estructura instancia de la clase Compite se define como sigue:

type&! struct -ComjositePart/ /*Arreglo que contiene a todos los widgets hijo*/

WidgetLLrt children; /*Numero total de Widgets hijo*/

Cardinal num-children; /*Numero de espacios en el arreglo de hijos*/

Cardinal /*Apt. a Procedimientos que calcula la nueva posicion de hijo*/

XtOrderProc; insertposition; J CompositePart, *CompositePart;

numshts ; r

El widget Cdmposite define sus campos inmediatamente despues de los campos de Core.

typedef structl core; 1 CorePart

CompositePart composite; / CompositeRec, *Composite Widget;

I/

Recursos

Los recuTos, de Composite con su nombre, clase y tipo de representacion son los siguientes:

92

L -

I1

. - . .-

- Nombre Campo Nombre Recurso

I

children XtNchildren insertposition I) XtNinsertposition numchildren XtNNumChildren num-slot No es recurso

1

Valor Default

NULL hsertAtEnd O O

Los campo? children, num-children y insert-position se declararon como recursos. XtNchildren y XtNnumChildren solamente pueden ser leídos por el cliente. y el widget Composite es el único que puede modificarlos.

Métodos Definidos por la Clase Widget Composite. ‘I

11 La clase widget Composite define varios métodos de los cuales se describen los siguientes

que son los que se consideran de imptancia para el desarrollo de este trabajo.

0 II

Metodo cgangemanaged. El método change-managed es invocado cuando la aplicación instancia un widget que tiene como padre un widget contenedor del que es invocado el método, +e método inserta el widget hijo en su campo children que es una lista de widgets. Este metodo también es invocado cuando un widget es removido de la lista del Padre. I)

Método insert-child. El método b - c h i l d es invocado cuando se inserta un widget hijo a la lista del padre. La llamada a XtCreateWidget invoca ai método insert-child del padre.

Método delete-child. El método delete-child es invocado cuando un widget es borrado de la lista del padre.

II

Método geometry-managerh función del método geometrymanager es la de controlar las peticiones de cambio de dimensiones de un widget hijo. Esta peticiones son analizadas y medidte mecanismos de mensajes que le indican ai hijo si logró satisfacer sus peticiones completamente o parcialmente io que significa si volverá a intentar SU propuesta o terminar6 su petición. Es importante aclarar que un widget no puede catrolar automátihente sus necesidades de redimension, el responsable de los cambios geométncos de un widget es su padre el cual debe ser un widget Composite.

I

II

93

I ANSXO B

Clase Widget Constraint.

La clase widget Constraint es subclase de Composite. Su nombre se deriva del hecho de que esta clase puede controlar la geometría de sus hijos basándose en restricciones asociadas a cada uno de &os. Estas re.stricciones pueden ser tan simples como la definición del máximo ancho y largo de I& hijos que contendrá el widget Constraint, o tan complicadas como cuanto cambiaran las dimensiones o posición de un widget hijo si otro widget hijo es redimensionado o movido. El widget Constraint permite definr recursos que son asignados a cada uno de sus hijos. Por ejemplo un widget padre puede definir un recurso que determine el tamaño máximo de sus hijos, este nuevo recurso es tomado por cada uno de sus hijos como si este hubiera sido declarado en la lidta de recursos del widget. Las estructura Clase e instancia de Constraint se defmen en el archivo de cabecera <Xll/ConstraintP.h>. En la figura B.3 se muestra la arquitectura de la Clase Composite.

II

~. 'I Figura B . 3 Aruitectura de la clase Constraint.

11

Jerarquía de la Clase. '1

Core -> Composite -> Constraint

Registros y apuntadores predefmidos.

extern CcystraintClassRec constraintClssiRec;

extern WidgetCIars constraint Widgetclass; I)

94

ANEXO B 11 I

Estructura Clase y Registro Clase.

La estructura clase define los datos en forma de recursos de la siguiente forma:

rypedef struct -C&traintCíossPart( /*Apuntador a lis& de recursos definidos por constraint*/

XtResourceList resources; /*Numero de recusros de restriccion en la lista*/

Cardinal num-resources; /*Tamaño de la ehuctura constraint*/

Cardinal cbnrtraint-size; /*Apuntador a metodo de inicializacion de la clase constraint*/

XtinitProc constraint-initialize; /*Apuntador a metodo de destruccwn del widget constraint*/

X t WidgetProc constraint-destroy; 11

/*Apuntador a metodo set-values del widget constraint */

/*Apuntador a la 'estructura extension de la clase consíraint*/

}ConstraintClass Part;

XtSet ValuesFunc set-values;

XtPointer extension; I1

Los campos de la clase Constraint se definen inmediatamente despues de los campos de Composite.

typedef srruct { 1, 'I

Coreclasspart core-class; CompositeClassPart composite-class; ConstraintClassPart constraint-class;

)ConstraintClassRec, *ConstraintWidgetClass;

Ir Estructura Inslncia y Registro Instancia.

La estructura instancia no define nuevos recursos, unicamente define un campo d u m m y para evitar comflictos con el compilador.

iJ

rypedef struct -OonrtraitPart{

) Constraintpart; XtPointer dummy;

El Widget Constraint define sus campos inmediatamente despues de los campos de composite. I)

95

81

typedef struct( Corepart 'I core; Compositepart composite; ConstraintPart constraint;

ICostraintRec, *ConstraintWidget; I1

Recursos.

La clase widget Constraint no define ningún recurso propio. II

Métodos definidos por la Clase Widget Constraint. II

La clase widget Constraint define varios métodos de los cuales se describen los siguientes que son los que de consideran de importancia para el desarrollo de este trabajo.

Método initialize de Constraint. El método initialize de Constraint del padre perteneciente a esta clase es llamado después de que el método initialize de Core del widget hijo es invocado durante la creación de este. El método initialize de Constraint podrá calcular los valores de cualquier campo derivado de un recurso de restricción. Este realiza cambios al widget hijo conforme las restricciones especificadas; por ejemplo, cambiar kl tamaño o posición del widget hijo. Se puede prescindir de este método inicializando el campo initialize a N U en la estructura clase de Composite.

Método set-values de Constraint. El método set-values de Constraint es invocado cuando 18s recursos de restricción del widget hijo son llamados. Este se encarga de verificar la validez de los nuevos valores, y recalcula el nuevo despliegue del widget con respecto la los nuevos valores. El método set-values de Constraint opera dentro del contexto del widget hijo.

Método kiestroy de Constraint. Este método es invocado del widget Constraint padre cuando alguno de sus hijos es destruido. Este método limpia los campos de la estructura instanciaidonde se hace referencia al widget borrado.

11 O

11

!I

96

CODIGa DE IMPLEMENTACION DE LA CLASE BARRA.

nexo se presenta el código de implementación del widget Barra, que nos la programación realizada en este trabajo.

En este permite mosw

I!

ANEXO c C6dlgo Fuente Clase Barra 'I

en este anexo corresponde a la clase widget Barn, esta clase se incluyen los archivos que componen el widget Barra en el

siguiente orden:

Código del archivo de cabecera privado BarraP.h, este archivo define 4 estructuras, dos estructuras d&miidas estruchiras instancia (instancepart, InstanceRec) y dos denominadas est~&cturas clase (CiaisPart y ClassRec)

1

String '1 I Position Position I

1 /*se incluye el archivo de cabecera de Bana.h*/ #include "Ba~a.#

#/I

label; /*Etiqueta de descripcion de la barra*/ mx, my; x-barra, y-barra;

Pixel ShOlt

/*Campo int 1

String 1) id; /*apuntador a lisia de procedimientos callback asociados al objeto*/

color-pa, color-ca, colorgb, color-cb desired-width, desired-height;

valor-estado; del valor de la variable*/

il

Rango '1 string '1 /*cadena

98

~-

rango;

ui; de unidades de ingenieria*/

I Pixel , char

JBarraPart; I I

I* I/

color-barra; pos-ind;

1 I* /I Se define un apuntador externo a la estruciura ClassRec de la clase.

CorePart BarraPart

I BarraRec;

*I 1 extern BarraClakRec barraClassRec; Ill

core; ~ barra;

99

de ésta. *I typedef structl

int ] BarraClassPart; ,

I*

Select;

#define XtNmx #define XtCMx Mefine XtNmy ~

MefineXtCMy ,

100

''XI' "Mx" '*Y#' "MY ' I

#define XtNlob '

#define XtNloa I/ #define XtCLoa I/ #define XtNlca #defme XtCLca I #define XtNlpa I

#define XtCLpa I

#define XtCLob I/ 11

#define XtNlpb #define XtCLpb , #define XtNlcb 1 #define XtCLcb

"lob "Lob "loa" "Loa" "lca" "Lca" "lpa" "Lpa" "lpb" "Lpb " lcb "Lcb

#define XtNid #defiie XtCId #define XtNui , Mefine x t c ü i 1

" i d " I d

"Ui" I, ' U u1

wgxo c C6digo Fuente

j l l i /*Referencia externa para el apuntador a la-clase record*/

"BarraWidgetClass;~ typedef struct *Barrawidget;

muestra a continuacion corresponde al archivo de implementacion el codigo que define las caractensticas funcionales del widget.

11. /*Codigo de implementacion de la clase Barra*/ #include <X1 l/&insicP.h> #include <X1 l/ShgDefs.h> #include <X1 l/Xbs.h> #include <X1 l/X&tom.h> #include "Barra1.h #include "Ban&&"

barra.field) I* Campos de la que se definen

struct (

XtResource que define los campos recurso de la estructura BarraPart publicos y se denominin recursos de la clase.

String resource-name; 4 String resource-class; U l String resource-type;

cardinal resource-size; cardinal reiourceoffset; String dJfault-type; Xtpointer default-addr; I XtResource';

11 Lista de recursps de la clase, cada uno de los campos de la estructura BarraPart definidos como publicos deben tener una entrada en esta lista para poder ser definidos como recursos de la clase. *I static XtResoury remurcesa= ( Y

(XtNui, XtCUi, XtRString, sizmf(sling), offset(ui), XtRStrdg, (XtPointer) NULL], ( XtNid, KtCId, XtRString, sizmf(Skng), Offset(id), XtRStriAg, @pointer) NULL),

/I

101

I1 ‘1 I/

-0 c C6digo Fuente Clase Barra

‘i { XtNlahel,XtCLabel,XtString, sizeo&ing), Offset(iaixi), XtRStridg, (XtPointer) NULL], í XtNmxJIXtCMx, XtRPosition, sizeof(Position),Offset(mx), XtRStrin’g, (XtPointer) NULL),

{ XtNmy JIXtCMy, XtRPosition, sizeof(Position),Offset(my), XtRStndg, (XtPointer) NULL),

{ XtNfo&mmd, XtCForegmund, XtRPiiel, sizeof(Piel), Offset(foregmund), XtRStridg, (XtPointer) XtDefaultForeground ) ,

{ XtNdwibth, XtCDwidth, XtRShort, sizeof(sdort), Offset(desired-width), XtMmni’ediate, (XtPointer) -1 1,

{ XtNdhdght, XtCDheight, XtRShort, sizeof(sdort), Offset(desired-height), XtRIdediate, (Xtpointer) -1 1,

{ XtNval&estado, XtCValor-estado, XtRInt, sizeof(i&), Offset(va1or-estado), XtRStrit!g, “O”),

{ XtNordhparicion, XtCOrdenAparicion, XtRInt, sizeof(idt), Offset(ordenAparicion), XtRStnAg, ”O”), (XtNica)lXtCLca, XtRPosition, sizeof(Position), Offset(nivel-operacion.ca.rango), XtRStrdg, Wtpointer) NULL), { XtNlpa’lmXtCLpa, XtRPosition, sizeof(Pbsition), Offset(nivei-operacion.pa.mgo), XtRSdg , (XtPointer) NULL),

{ XtNlcb? XtCicb, XtRPosition, sizeof(P’osition),Offset(nivel-operacion.cb.mgo), XtRstriBg, VtPointer) NULL),

( XtNlptij XtCLpb, XtRPosition, sizeof(Position),Offset(nivel-opemcion.pb.mgo), XtRStriAg, @pointer) NULL),

{ XtNlod: XtCLob, XtRPosition, sizeofqosition), XtOffsetOf(BarraRec, barra.mgo.min), XtRString,(XtPointer) NULL ) {XtNlw! x t c i m , XtRpOsition, sizeof($osition), XtOffsetOf(BarraRec, barra.rango.mx), x t ~ s t n n g , @Pointer) NULL),

{ XtNcaihack, XtCCallback, XtRCallback, sizeof(ktCallbackList), XtOffsetOf(BarraRec, bma.callback),

I

!I ‘t 102

I I

La tabla de acciones liga la cadena asociada a la secuencia de eventos de la tabla de traducciones al hombre de la funcion llamada tambien accion, en este caso la funcion de accion se llama *I static

1;

I*

/*Declaration dk los metodos de la clase*/ static void Initialize(); static void Rdkplayo; static void Des&y(); static void Resite(); static Boolean SetValues(); static XtGeomebyResult QueryGeometryO;

I1

1 'I

Inicializacion de la estnictura ClassRecord de la clase, esta es una de las partes medulares de este archivo ya ,Fue en esta estructura define la lista de recursos, las tablas de accion y traduccion y los metodos que son definidos en la clase y los que se heredaran.

BarraClassRec barraClassRec = { {/*ciase\Core part*/ /*superclass */ (Widgetclass) &coreClassRec, /*ciass-+me */ "Barra", /*widget-size */ sizeof@alTaRec), /*class-$itialize I*classgartinitiali */ NLJLLJ*ClassPartInitialize,"l

*/ 1

*/ NULLJ*apuntador al metodo class-initialize*/

103

/*class-ipted /*initialize I*initialkhook /*reaiizej; */ XtinheritRealize, /*actions */ actions, /*num-+ons */ XtNumber(actions),

/*num-jsources */ XtNumber(resources), /*xrm-class */ NLJLLQUARK, /*compress-motion */ TRUE, /*controlan el filtro de evevtos del toolkit*/ /*compress-exposure *I XtExposeCompressMultiple, /*controlan el filtro de eventos*/ /*compr&s enterleave*/TRUE, /*controlan el filtro de evevtos del toolkit*/ /*visible'l interest */ FALSE,

*/ Destroy, 7 /*destroy /*resjze I/ */ Resize, /*exposel */ Redisplay,

I /*set-values-hook i /*set-valpes-almost */ XtinhentSetValuesAlmost,

/*get-values-hook

/*versi+ */ XtVersion,

/*tm-table */ defaultTranslations, /*query geometry */ QueryGeometry, /*displaYacelerator */ NULL,/*redirecciona eventos a acciones a widgets*/ /*extension */ NULL /*mantiene la compativiiidad binaria*/

*/ FALSE,/*indica cuando la clase a sido inicializa&*/ *I InitializeJ*apuntador a metodo inici&e*/ */ NULL,/*defmen metodos de subpartes del widget*/

/*resources */ resources, 11

Jl 11

/*set-values */ Setvalues, */ NLJLLJ*define subpartes del widget*/

*/ NLJLLJ*defme subpartes del widget*/ /*accept l fm */ NULL,

/*callback-offsets */ NULL,

11

hseiect I/ *I 0

I* li */ 1 Al apuntador externo declarado en el archivo pribado BarraP.ha se le asocia La estmctura

inicializada ClakRec de una instancia de la clase

Widgetclass barrawidgetclass = (Widgetclass) 8cbarraClassRec; !I iI /*Funcion Color regresa el valor en Pixel del nombre del color*/

static Pixel ~oiOr(w, coiomame) Widget w; I String colomame; I /I

104

I1 Cbdigo Fuente Clase Barra

I/

I XrmValue src, dst; Pixel color;

src.size = strlen(colorname) + 1; src.addr = colomame; dst.size 7 sizeof(Pixe1); dst.addr = (caddr-t)&color;

if (!XtConvertAndStore(w, XtRShing, &src, XtRPixel, &&

11 11

rehnn(NüLL);

~

lefaults */

:, join-style);

/*Crea un contexto grafico para el widget*/ static Get-GC(w, gc) Widget w; GC *gc; { il

unsigned long valuemask = O; /* ignore XGCvalues and use XGCValues values; unsigned int line-width = 1; int line-style = LineOnOfíDash; int cap-style = CapRound; int joinistyie = JoinRound; int dashLoffset = O; static char dash-listn = {

12, 24 1; int list-length = 2; Display ?dpy = XtDisplay(w); Window win = XtWmdow(w);

/*Crea el contexto grafico por default*/ *gc = XCreateGC(dpy, win, valuemask, &values);

/* specifica el font */ XSetFont(dpy, *gc, font-9x 15->fid);

/* especifica el foreground*/ XSetForegmund(dpy, *gc, 1);

/*Establece los atributos de la linea */ XSetLineAmibutes(dpy, *gc, line-width, line-style, cap-sty XSetDashes(dpy, *gc, dash-offset, dash-list, list-length);

I/

1.

II

Auno c

105

ANEXO c /I C6digo Fuente Clase Barra ,I

1

Widget w; { int i=O;

I/. /*Carga un tipo de letra especificado por el parametro font-info*/ static load-font(b,font-info) Widget w; '1: XFontStruct **fontjnfo;

'I 1 11

I 1

I 'I)

1 II.

char *fontname = "9x15"; Display {dpy = XtDisplay(w);

/* Accesj font */ if ((*font''info = XLoadQueryFont(dpy,fontname)) == NULL)

X.tWarning("Basic: Cannot open 9x 15 font\\n"); e& -1 1;

106

I1 /I 4 1

=o c C6drgo Fuente C h e e Barra

static void Initialize(request, new, args, num-args) Widget request, dew; ArgList args; Cardinal *num-args; I/ I I/

11 I!

{ I/

Barrawidget mw = (Barrawidget) new;

GetColorSO;

if(mw->core.x e= O)

mw->core.x = 10; mw->barra.mx = 0; I/

.I I I if(mw-Sc0re.y <= O)

{ 1 mw->core.y=10;

11 if(mw->core.width == O) 1 11,

I/ { I

mw->barra.desired-width = 280;

if(mw->core.height == O)

mw->bam.desired-height = 350;

if(mw->b!rra.label == NULL)

{ I/ char etiqueta[l5]; m&mset(etiqueta, 10',15); st!cpy(etiqueta, "Descr¡pcion");mw->barra.label = mw->core.name;

11 mw->barra.label = XtNewStnng(mw->barra.label);

if(mw->barra.id == NULL) I/ I 11 c!ar etiqueta[lO];

memset(etiqueta, ?cV,lO); strcpy(etiqueta, "Id"); mw->barraid = etiqueta; I!

II I IS

B 107

II

ANEXO c //

I { I

' I/ .Ir:

I/ :I/ .

I 1 1

Código Fuente Clase h r r a

I [ mw->barra.id = XtNewStnng(mw->barra.id);

if(mw-S;barra.ui == NULL)

char etiqueta[iO]; 11 memset(etiqueta, 10',1ü); &rcpy(etiqueta, "Ui"); mw->barrami = etiqueta;

mw->barra.ui = XtNewString(mw->barra.ui);

mw->core.width = mw->barra.desired-width; mw->core.height = mw->barra.desired-height; mw->core.border-width = O;

mw->barra.color-barra = Red; mw->b&m.p-ind = W;

mw->barra.nivel-operacion.ca.color = Red; mw->b&ra.nivel-operacion.pa.color = Yellow; mw->barra.niveloperacion.pb.color = Yellow; mw->bdm.niveloperacion:cb.color = Red;

mw->barra.foreground = Color(mw, "gray78");

load-foiit(mw,&font-9~ 15, "9x 15"); load-f&(mw,&font-6~13, "6x 13");

11 4

I

:I/ I

/*Funcion Notsfy llamadas funciones de accion, esta funcion es mapeada en una cadena en la tabla de tradu&iones en la cual se le asocia un evento del raton*/ static void No$fy(w, event, params, numgarams) Widget w; 11 XEvent *event; ,i: String *params; Cardinal *n&params; ( I1 Barrawidget mw = (Barrawidget) w;

int vankble; md! fuera = TRUE; XButtdlvent *b = &event->xbutton; char x[5], y[5];

if(event != NULL && event->type == ButtonRelease && event->xany.window == I1 1

108 .I

XtWindow(w))

if(NE(co!e.width) I I NE(core.height)) I 1 redisplay = TRUE;

ifiNE(core.width))

“I newmw->barra.desired-width = newmw->core.width;

if(NE(core.height))

I I , newmw->barra.desired-height = newmw->core.height;

11 if(NE(barra.ordenAparicion)) 1 I1 1

redisplay = FALSE nLwmw->barra.ordenAparicion = newmw->barra.ordenAparicion;

109

' I II if(NE(barra.labe1))

I I/ reflisplay = TRUE; if(NE(barra.labe1)) (

XtFree((char *) oldmw->barra.label); newmw->barra.label = XtNewString(newmw->barra.label);

I

IL if(NE(barra.nive1-operacion.ca.rango) I I NE(barra.nive1-operacion.pa.rango) I I NE(barra.Nve1-operacion.cb.rango) I I NE(barra.nive1operacion.pb.rango))

rylisplay = FALSE; if(NE(barra.nive1-operacion.ca.rango))

{ 111 .

newmw->barra.nivel-operacion.ca.rango = {I {l

newmw->barra.nivel-operacion.ca.rango; I I¡ if(NE(barra.nivel-operacion.pa.rango))

newmw->barranivel-oprac¡on.ca.rango = newmw->bama.niveloperacion.ca.rango;

1 I if(NE(barra.nive1-operacion.cb.mgo))

, {l. newmw->barra.nivel-operacion.ca.rango = newmw-5barra.mvel-operacion.ca.rang0;

)'I if (NE(barra.nivei-operacion.pb.rango))

newmw->barranivel-operacion.ca.rango = {! I . newmw->barra.nivel-0peracion.ca.rango; )I I

rydisplay = FALSE; if(NE(barra.rango.min))

' newmw->barra.rango.min = newmw->bana.rango.mh;

if(NE(baxra.rango.min) I I NE(bam.rango.max)) ( 1 .

( il I I1

110 Ij 1

(

I

111

newmw->barra.rango.max = newmw->bam.rango.max;

!’

-0 c C6diqo mente Clase Barra

min = (Catdina1)newmw->barra.nivel-opemcion.cb.mngo; max = (Cardinal)newmw->barra.nivei-opemcion.pb.mngo; if(((mngo) > min) && (rango < max)) color =

ifQ(rango) < min) color = newmw->barra.nivel-0peracion.cb.color; newmw->barra.njvel-operacion.pb.color;

11

min = (Cardinal)newmw->b.nivel-ope~cion.pa.; max = (Cardinal)newmw->bar.nivei-opmcim.ca.mgo; if((rang0 >= min) && (rango e rnax)) color =

if((mng0) >= max) color = newmw->barra.nivei-opemcion.ca.color;

newmw->barra.color-barra = color,

/*se borra el ultimo valor de la variable*/ valores.foreground = Gray; valoresfont = font-9xlS->fid; XChangeGC(dpy, mw->barra.gc, GCForegmund I GCFont, valores); sprintf(valor,” %d, old-carase); wi‘dth-text = XTextWidth(font-9x15. valor, strlen(vdor)); XDrawString(dpy,win,

m?v->barra.my+20, valor, strien(va1or));

/:Le pinta el valor actual de la variable*/ valores.foreground = White; valoresfont = font-9xl5->fid; XChangeGC(dpy, mw->barra.@, GCForegmund I GCFont, valores); sprintf(valor,” %d, new-carase); ddth-text = XTextWidth(f0nt-9x15, valor, strlen(va1or)); XDmwString(dpy,win, mw->bana.gc,mw->b.m+(mw->core.widW2 -

newmw->barra.nivel-opemcion.p.wior;

I

1

m w - > b a n ; i . g c , m ~ - ~ b a . ~ + ( m w - > b a r r a . d e s i 2 - width-text/2),

I)

widthVtext/2), I; mw->barra.my+20, valor, strlen(va1or));

ptos = NULL; switch(oldmw->barra.pos-hd) 1

case ‘h’:ptos = ind-hor;break, case Wptos = ind-ver;break; case ’i’:ptos = ind-veri;break;

1

/*se borra el ultimo indicador de tendencia*/ & i c = (mw->core.widúJ8)-16; y jn ic = (mw->core.height/6)*5;

\

112

Código Fuente C l a s i B ~ T I Q 4 -0 c

ii valoresforeground = Lightgray; XChangeGC(dpy, mw->barra.gc, GCFÓreground, valores); for(i=O; i 4 ; i++) {

ptos2[i].x = ptos[i].x + x-ink; ptos2[i].y = y-inic - ptos[i].y; L

XF¡llPolygon(dpy, win, mw->barra.gc, ptos2,8, Complex, CoordModeOrigin);

if(old-carase c new-carase)

else 1

I newmw->barra.pos-ind = 'v';

if(o1d-carase == new-carase)

else newmw->barra.pos-ind = 5'; newmw->barra.pos-ind = W;

I/

t ptos = NULL; switch(mw->barra.pos-ind) {

case W:ptos = ind-hor;break; case 'P.ptos = ind-ver,break; 1 case 'i':ptos = ind-veri;br&,

t

/*se despliega el indicador de tendencia*/ x-inic = (mw->core.~idth/8)-16; y-inic = (mw->core.height/6)*5;

XChangeGC(dpy, mw->barra.gc, GCForeground, valores); f&(i=O; i 4 ; i++)

v/ores.foreground I = Red,

11 ptos2[i].x = ptos[i].x + x-inic; ptosZ[i].y = y-inic - ptos[i].y;

I XFillPolygon(dpy, win, mw->barra.gc,ptos2,8,Complex, CoordModeOrigin);

/*se borra la barra con el untimo valor de la variable*/ ir min-bar = (mw->core.height / 6); numero = ((min-bar + (mw->core.height/6)*4) - min-bar); numero = ((numero / 4095) * newmw->barra.valor_estado) + min-bar; ptol = (int)(min-bar + (mw->core.height/6)*4) - numero;

113

o Dyer0 = ((nunbar + (mw->core.height/6)*4) - min-bar); nymero = ((WIerO / 4095) * oldmw->barra.valor-estado) + min-bar;

= (int)(min-bar + (mw->core.height/6)*4) - numero; It valores.foreground = Lightgray;

XChangeGC(dpy, 4 mw->barra.gc, GCForegmund, valores); XFillRectangleÍdpy, win, mw->baxra.gc, (oldrnw->core.~idth/4),min_bar +

I 11

(oldmw->core.~idth/4)*2+ 1, ((oldmw->core.height/6)*4) - pt02); /*se despliega la barra con el valor actual*/ valores.foreground = color; Xf%angeGC(dpy, mw->barra.gc, GCForegmund, valores); XFillRectangle(dpy, win, mw->barra.gc, (mw->core.widih/4),min-bar + ptol,

f

(mw->core.width/4)*2, ((mw->core.height/6)*4) - ptol); I/ 'I li /*se despliega el contorno de la barra*/

valores.foreground = Gray; XChangeGC(dpy, mw->barra.gc, GCForeground, valores); /llinea vertical derecha*/

XDrawLine(dpy,win, mw->barra.gc, (mw->core.width/4)*3,min-bar +

/llinea horizontal inferior*/ /rawLine(dpy,win, mw->barra.gc,

I/ ptol ,(mw-~core~width/4)*3,((mw-~core.height/6)*5));

(mw-~core.width/4),((mw-~core.height/6)*5),(mw-~core.width/4)*3,((mw~~core.height/6)*5));

1 valores.foreground = White; XChangeGC(dpy, mw->barra.gc, GCForeground, valores); /$linea vertical izquierda*/ XDrawLine(dpy,win,mw->barra.gc, (mw->core.width/4),min-bar + ptol,

/tlinea horizontal superior*/ XDrawLine(dpy,win, mw->ba1~a.gc,(mw->core.~dth/4),min_bar + ptol,

t

I (mw->core.width/4),((mw->core.height/6)*5));

(mw->core.width/4)*3,~n-bm + ptol); I R

I1 if(NE(barra.mx) I NE(barra.my))

r$isplay = TRUE; if(NE(barra.mx)) 11 newmw->core.x = newmw->barra.mx; if(NE(barra.my))

newmw-x0re.y = newmw->barra.my;

( I ] .

I1 I¡

ii 1 1 II

il 114

I l u w o c

1 C6digo Fcente Clase Barra

,/

/I

I newmw->core.height = newmw->barra.desired-height;*/

i f ( ( r e d i s p I I newmw->core.height == O) I

newmw->barra.desired-height = newmw->core.height;

Widget w; XEvent event; Region region; I

'I return redispiay; I1 h d e f NE i

11 static void Destroy(w) Widget w; 11 í I

II Barrawidget mw = (Barrawidget) W;

XtFree((char *) mw->barra.label); XtFree((char *) mw->barra.id); XtFree((char *) mw->barra.ui);

115

11 Display ,;dpy = XtDisplay(mw); Windowl win = XtWindow(mw); int minbar=O, height-bar=O; Position bsy; char valdr[20]; int x-inil, y-inic; XPoint *ptos, ptos2[8]; register iht i; XGCVaihes Valores; double numero, numero2; int val-carase;

Get-GC(mw, &mw->barra.gc);

'I 11

1 I

mw->bam.label);

widget definida por su ancho y largo*/ mw->barra.foreground;

GCForeground, valores); mw->barra.mx, mw-rbarra.my,

mw->core.widd? mw->core.height);

I /*se pinta el contorno del widget*/ valoresforeground = Gray; XChangeGC(dpy, mw->barra.gc, GCForeground, valores); /*linea vertical derecha*/ XDrawLine(dpy,win, mw->barra.gc,

I

mw->barra.mx+!nw->core.width- 1 ,mw->barra.my+2,

mw->core.y -l))<; ~w->bam.mx+mw->bami.desired_width-l,(mw->barra.desired_height +

/*linea hbrizontal inferior*/ XDrawLFe(dpy,win, mw->barra.gc,

mw->barra.mx+2,mw->barra.my+mw->barra.dsird-height- 1,

- l),mw->barra.~y+mw->bam.desired-height- 1); (&w->bam.desired-width + mw->bam.mx

1 vaioresforeground = White; XChangkC(dpy, mw->barra.gc, GCForeground, valores); /*linea &tical izquierda*/ XDrawLhe(dpy,win, mw->barra.gc, mw->barra.mx+ 1,

/*linea dxizontal superior*/ mw->bam.my+'l,mw->barra.mx+, l,(mw->bam.desired-height + m w - > h . m y -1));

1 1; 116

C6digo Fuente C1ase'~aira ,I -0 c

I1 XDrawLine(dpy,win, mw->barra.gc, mw->barra.m+ 1,

mw->barra.my+l,(mw->barra.desired_width + m w - > b W . m -11, mw->b-.my+l);

/*se dibuja el cuadro de despliegue de valores de la variable*/ sprintf(valor," %s"," i oOo00" ); vaiores.foreground = Gray; vaiores.f+t = font_gxi5->fid; XChangeGC(dpy, mw->barra.gc, GCForeground I GCFont, valores); width-texi = XTextWidth(font-9x15, valor, strien(valor)); XFillRectangle(dpy, win, mw->barra.gc,mw->barra.mx+(mw->core.widthp -

t

width-text/2),mw->barta.my+5, width_text,20);

/*se dibuja el Contorno del cuadro de despliegue*/ valores.fobground = White; XChangeGC(dpy, mw->barra.gc, GCForeground, valores); /*linea vertical derecha*/ XDrawLine(dpy,win, mw->barra.gc,

(mw->core.widtb/2)+width-text/2,mw->b~.my+5, (mw->~ore.~id~)+width_text/2~w->ban;.my+25);

/*linea horizontal inferior*/ XDrawLine(dpy,win,

mw-~bami.gc,(mw-~~ore.widtb/2)-~dth~text/2~w->~a.my+25, 11 (mw->wre.width/2)+width-tex~mw->~.my+25);

valores.foreground Black; XChangeGC(dpy, mw->bana.gc, GCForeground, valores); /*linea vertical izquierda*/ XDrawLme(dpy,win, mw->barra.gc,

(mw->Core .widd/2)-widthtext/2,mw->barra.my+ 5, I (mw-~~ore.width/2)-width~text/2,rnw-~ba~.rny+24); I/

I (mw-~core.widtb/2)+width~text/2-l,mw-~barra.my+~);

/*linea horizontal superior*/ XDrawLme(dpy,win, mw-~barra.gc,(mw-~core.wid~2)-width~tex~2,mw-~barra.my+5,

/*se despliega el valor de la variable*/ numero = (mw->barra.rango.max - mw->barra.rango.min); numero = ((numero / 4095) * mw->barra.valor-estado) + mw->barra.rango.mb, valcarase = (int) numero; sprintf(vAior:%d, valsarase); vaiores.foreground = White; valores.font = font-!hl5->fid; XchangeGC(dpy, mw->barta.gc, GCForeground GCFont, valores);

ii

117

C6digo Fuente clase ~ a r r a - -0 c

1 widkteyt = XTextWidth(font-9x15, valor, strlen(valor)); XDrawSFg(dpy,win, mW->barra.gc,mw->barni.mx+(mw->core.width -

/*E despliegan los valores de los rangos de operation */ valoresforeground = Black; valores.font - font-6xl3->fid; X h g k X d p y , mw->ha.gc, GCForeground I GCFont, valores); pos-label = min-bar = mw->core.height / 6;

#define transfor&pto(pto, estado) \ numero = min-bar + (mw->core.height/6)*4; \ numero 7 numero - min-bar; \ numero2 = 4095; \ numero = (numero/numero2); \ numero = (numero*pto) + min-bar; \ posy = (int)(min-bar + (mw->core.height/6)*4) - numero; \ .sprintf(vflor,"-%d, mw->bami.estado); \ valores.fomground = Black; \ valores.fht = font_6xl3->fid; \ XChangk(dpy, mw->barra.gc, GCForeground I GCFont, valores); \ XDrawSbg(dpy, win, mw->barn.gc,mw->core.wid~ - 50,pos-label +

wid~-tex1/:!),mw->barra.my+20, valor, strien(vaior));

posy ,valor,strlen(valor));

numero = (double) 4095; numero2 = (doub1e)mw->barra.rango.max; numero 5 (numero/numero2) * mw->bma.nivel-operacion.ca.rmgo; valcarase = (int) numero; transfoT-pto(val-canise, nivel-operacion.ca.rgo); numero = (double) 4095; numero:! = (doub1e)mw->barra.rango.max; numero = (numero/numero:!) * mw->bam.nivel-operacion.pa.rango; val-carase = (int) numero; transforma-pto(val-carase, nivel-operacion.pa.rngo); numero :: (double) 4095; numero2 = (doub1e)mw->barn.rango.max; numero = (numero/nmero2) * mw->barra.nivel-operacion.pb.rango; val-carase = (it) numero; transforhjto(val-carase, nivel-operacion.pb.rango); numero = (double) 4095; numero2 = (double)mw->barra.rango.max; numero = (numero/numero:!) * mw->barra.nivel-operacim.cb.rango; val-carase = (int) numero; transfonna-pto(val-carase, nive1-operacion.cb.mngo);

11 1)

1)

'1

II i

118

Código Fuente Ciar& Barra

h d e f transforka-pto

m o c I/

I)

if((mw->barranivel-operacion.ca.rango == O)&&(mw->barra.nivel-0peracion.pa.rango == O)&&

O)&&(mw->barra.nivel-operacion.pb.rango == O)) (mw->barra.nivel-operacion.cb.rmgo ==

11 pplabe l = mw->core.height / 6; poSy=O; posy = pos-label*2; XDrawString(dpy, win, mw->bama.gc,mw->core.width - 50,pos-label +

posy = p-label*2+pos-labe1/2; XDrawString(dpy, win, mw->barra.gc,mw->core.width - 50,pos-label +

II ppsy = pos-label*3+pos-Iabel/2; XDrawString(dpy, win, mw->barra.gc,mw->core.width - 50,pos-label +

posy = po~Jabel*4; XDrawString(dpy, win, mw->barra.gc,mw->core.width - 5O,pos-label+

I I

posy,"-lca",4);

posy,"-lpa",4);

posy,"-lpb,4);

po~y,"-l~b,4); I

11 /*se despliega la etiqueta de descripcion de la variable en la parte inferior*/ vaiores.foregrouud = Black; valores.font = font-9xl5->fi& XChangeGC(dpy, mw->barra.gc, GCForegmund I GCFont, valores); width-text = XTextWidth(font-9x15, mw->bam.label, strlen(mw->barra.label)); XDrawString(dpy,win, mw->barra.gc,mw->barra.mx+(mw->core.width/2 -

width~text/2),mw-~barra.my+pos~iabel*6-pos~iabei/2, I1 mw->barra.iabel, strlen(mw->bam.label));

XDrawString(dpy,win, mw->barra.gc, 20, 20, mw->barra.id, strlen(mw->barraid)); XDrawString(dpy,win, mw->barra.gc, (mw->core.width/2)+40, 20, mw->bam.ui,

switch(mw->barra.pos-ind) [

strlen(mw->barra.ui));

case Wptos = indhoqbreak; case 'eptos = ind-veqbreak, case 'i':ptos = ind-veri;break;

I II

/*se despliega el indicador de tendencia*/ x-inic = (mw->core.width/8)-l6;

119

1

,I C6digo Puente Clase Barra

lWIu0 c - II y-inic = (mw->core.height/6)*5; valoresforeground = Red; XChangeGC(dpy, mw->barra.gc, GCForeground, valores); for(i=O; i b ; i++) 1

ptos2[il.x = ptos[i].x + x-inic; ptos2[i].y = y-inic - ptos[i].y; t

' ¡I II

XFiilPolygon(dpy, win, mw->barra.gc,ptos2,8,Complex, CoordModeOrigin); /*se despliega la barra*/ min-bar = pos-label; numero = ((&-bar + (mw->core.height/6)*4) - min-bar); numero = ((numero / 4095) * mw->barra.valor-estado) + min-bar; posy = (ibt)(min-bar + (mw->core.height/6)*4) - numero; valores.foreground = mw->bma.color-barra; XChangeGC(dpy, mw->barra.gc, GCForegmund, valores); XFillRectangle(dpy, win, mw-~barra.gc,(mw->core.width/4),min~bar + posy,

(mw->~ore.width/4)*2,((rnw->~ore.height/6)*4) - posy); /*se dibuja el Contorno de la barra*/ valoresforeground = Gray; XChangeGC(dpy, mw->bam.gc, GCForegromd, valores); /*linea v/cal derecha*/ XDrawLine(dpy,win, mw->barra.gc, (mw->core.width/4)*3,((mw->~ore.height/6)) +

/*linea dhzontal inferior*/ XDrawLine(dpy,win,

posy,(mw-~cor~!width/4)*3,((mw->core.height/6)*5));

mw-~barra.gc,(mw-~~re.width/4),((mw-~core.heigh~6)*5),(mw-~co~.widt~4)*3,((mw-~~re. height/6)*5));

valores.foreground = White; XChang&GC(dpy, mw->barra.gc, GCForeground, valores); /*linea &tical izquierda*/ XDrawdme(dpy,win, mw->barra.gc, (mw->core.width/4),((mw->core.height/6)) +

/*linea horizontal superior*/ XDrawLme(dpy,win, mw-~barra.gc,(mw-~core.width/4),((mw->core.height/6)) +

posy,(mw->cor&'.width/4),((mw->core.height/6)*5));

posy,(mw->core.width/4)*3,((mw->~ore.height/6)) + posy);

if(all0cated) XtFree(string); I

static void Resize(w) 'I

120

C6digo Fuente Clase Barra -0 c

Widget w; I

/*Widget wm = (Barrawidget) w; Arg argsPI;*/

if(XtIsR&lized(w)) I j

/*XClearWindow(XtDisplay(w), XtWindow(w)); (*i(XtClass(w)->core-class.expose))(w, @Event *) NULL, (Region) NULL);*/

t

static XtGeometryResult QueryGeometry(w, proposed, desired) Widget w; XtWidgetGeometry *proposed, *desired; I 'i

!I Barrawidget mw = (Barrawidget) XtParent(w);

#define Set(bit) '((proposed->request-mode & bit)

desired->width = mw->core.width, desired-*height = mw->core.height; desired-kpest-rnode = CWWidth I CWHeight;

if(Set(CWWidth) && propod->width == desired->width && Set(CWHeight) && proposed->height == desired->height)

I I1 return XtGeometryYes; I! t

if(desired->width == mw->core.width && desired->height == mw->core.height) I

I return XtGeometryAlmost;

I

return XtGeometryNo;

h d e f Set I

121

OLlT

GUi

NeWS

ADlGMoP

URAP

SADRE

SIRAT

SDC

SA1

SAIU

SB

OSF

IIE

CENIDET

PO0

RV

SAD

Toolkit

Widget

X Window

TABLA DE ABREVIATURAS

- Open bmk tntrinsics Toolkit

@aphics user Interface) Interface Gráfica de Usuario.

- Network Eindowing sistem.

- Ambiente de -eSarrollo de Interfaces Gráficas Hombre-Maquina con Aplicación al &nitoreo de procesos.

- Unidad &suliados de &tomatización de -besos.

- Sistema de 4dquisición de Datos y Registro de &mtos.

- Sistema de gegistro y Análisis de Transitorios.

&temas mgitaies de control.

- Sistema Administrador de Información.

- Sistema Administrador de Interface &uario.

- Software Básico.

Open software Fundation.

btituto de Investigaciones Eléctricas.

I1

1

I 1

- Centro Nacional de Investigación y Desarrollo Tecnológico.

- Programación orientada a objetos.

- Realidad j!irtuai.

- Sistema de Adquisición de Qatos.

Librería de herramientas de interfaces al Usuario. 11 Objeto gráfico de una interface gráfica al usuario.

Biblioteca de funciones de bajo nivel para la construcción de sistemas GráFcos. !I I

XI Inírimics Libreria de funciones del toolkit estandares al sistema X Window.

Open Look

Motif

Interfaz Grafico con el Usuario de SUN Micmsystems.

Intecfaz Grafica con el Usuario de OSF.

122

li

BIBLIOGRAFIA.

I/ FOLEY, James, et all. The George Washington University. "The human factor of computer graphics interaction tecniques" IEEE-CF&A, Noviembre 1984.

HARSTON, Rey. Virginia Polytechnic Institute and State University. "User q r f a c e Management Control and Comunication" IEEE Software, Enero 1984. pp 62-70.

KUO, Feng-Yang, et all. University of Colorado at Denver. "User Interface Design from a Real time Perspective" Comunication of the ACM, Diciembre 1988 Vol. 31, Num 12. pp. 1456-1466.

ISHMAWA, H. et ail. Fujitsu Lahratoies Ud. "KID dlesigning A Knowledge-Based Natural Language Interface" IEEE EXPERT, Verano de 1987. pp 57-64.

EGLOWSTEIN, Ira. "Friendly Acquisition"

I) It

'11

BYTE, July 1994. pp 147-152.

ROMAN, Ma-Catalin, et all. Departament of Computer Science. Washington Unv. "Program Visualization: The Art of Mapping Programs to Pictures" IEEE SOftware, h e r o 1992.

COUTAZ, Peter. "Abstraktions for User interface Design" COPUTER, September 1985, pp. 21-33.

1

CLEATLAND, Peter, "OperaTr interfaces reap benefits of advanced tecnology" I&CS, Mayo 1993, pp. 29-38.

/I VIZCAINO, Carlos. ~~Interdxx ~iaf icas. Poder simpleza y productividad, PC/TIPS BYTE, Enero 1992, pp. 36-46.

MANDELKERN, Dave, Talarian Corporation. "GUIs h e Next Generation" COMUNICATIONS OF THE ACM, Abril 1993, Vol. 36, NO. 4, pp. 36-39.

/I FAISSONX, John O. "Pi&g & Design for Systemwide Control-Part 2" I", July 1992, p ~ . 22-24.

123

OLSEN! Dan R, et all. Arizona State University. "A Context for User Interface Management" IEEE CG&A, December 1994. pp. 33-42.

MYERS, Brand A. University of Toronto. "The User inteface for Sapphire" IEEE CGBLA, December 1984. pp. 13-23.

SANTAOLAYA, Rene. "Ambiedte de Desarrollo para la Programacion Visual de Interfaces de Usuario Para Monitoreo de Procesos en Linea", tesis de Mastria, Centro Nacional de Investigacion y Desarrollo Tecnologico (CENIDET), SEP, Cuemavaca Mor. 1994.

NYE, Adrian. Xlib Reference Manual, vol. 11, O'Reiily & Associates, Inc, Sebastopol, CA,

I)

iI

ISBN 0-937175-13-7, 1990.

RiFFLET, Jean-Mane, Comunicaciones en UNE, McGraw!Hill, Esparia, 1992.

PEDDE,' Jon, Graphical User Interface and Graphics Standar, M ~ G n i ~ - h l l , USA 1992.

MAYBURY, Mark T. "Inteligement Multimedia Interface", DAAIPrekqThe MIT Press, USA 1993.

VARHOL, Peter D. "Visual Programming's Many Faces", BYTE, July 1994. pp. 187-188.

II

9 5 0 7 1 4 124

Documents

S.E.P. D.G.I.T. CENTRO NACIONAL DE INVESTIGACION Y ... Juan Gabriel... · s.e.p. s.exf. d.g.i.t. centro nacional de investigacion y desarrollo tecnologico cenidet '' ambiente de desarrollo