Embed Size (px)
Citation preview
Universidad Autónoma de Tlaxcala.
Facultad de Ciencias Básicas Ingeniería y Tecnología.
Interacción Humano Computadora.Equipo: 3
Integrantes:Álvaro Mena Meléndez.Cesar Guillen Sánchez.Omar Sánchez Cabrera.
Daniel Copalcua Delgadillo.Jhoan Zapotitla Morales.
Soporte a la Aplicación.
1.-En estos temas se va dar a conocer las herramientas necesarias para la aplicación de un sistema interactivo haciendo énfasis en la programación.
2.-Las Herramientas de programación para sistemas interactivos proporcionan un medio eficaz para traducir los diseños abstracción y los principios de usabilidad en una forma ejecutable. Estas herramientas proporcionan diferentes niveles de servicios para el programador.
3.- El kits de herramientas de interacción abstracto le permitirá al programador describir los comportamientos de los objetos a un nivel similar a cómo los percibe el usuario.
4.- En los sistemas de gestión de la interfaz de usuario son el nivel final de las herramientas de soporte de programación que permite al diseñador y programador controlar la relación entre los objetos y las herramientas con su funcional en la aplicación actual.
elementos de los sistemas de ventanas
capacidad para proporcionar independencia al programador de los detalles de los dispositivos de hardware. Una estación de trabajo típica implicará alguna pantalla de visualización, un teclado y un dispositivo señalador como un ratón. Cualquier variedad de estos dispositivos de hardware se puede utilizar en cualquier sistema interactivo y todos ellos son diferentes en cuanto a los datos que se comunican y los comandos que se utilizan para instruirlos.
Es imprescindible ser capaz de programar una aplicación que se ejecuta en una amplia gama de dispositivos. Para ello, el programador tiene que dirigir una terminal de comandos, que comprende un lenguaje más genérico y puede ser traducido, y también a muchos otros dispositivos específicos. Además de hacer más fácil la tarea de programación, el terminal abstracto hace que la portabilidad de los programas de aplicación sea posible.
Sólo un programa de traducción o controlador de dispositivo tiene que ser escrito para un dispositivo de hardware en particular y luego cualquier programa de aplicación puede acceder a él.
Un sistema de ventanas dado tendrá un lenguaje genérico fijado para el terminal abstracto que se llama la imagen de modelos. Las imágenes de modelos son suficientes para describir imágenes muy arbitrarias. Por razones de eficiencia, primitivas específicas se utilizan para manejar imágenes de texto, ya sea como imágenes de píxeles específicos o definiciones de fuente como más genéricos
Ejemplos de Imágenes de Modelo
Píxelesla pantalla se representa como una serie de columnas y filas de puntos o píxeles que pueden ser explícitamente encendido o apagado, o le da un color. Se trata de un modelo común de imágenes para ordenadores personales .
Sistema gráfico del kernel (GKS)Una norma internacional de los modelos de pantalla como una colección de segmentos conectados, cada uno de ellos es una macro de comandos de gráficos elementales.
Interfaz Jerárquico del Programador de Gráficos (PHIGS)Otra norma internacional, basado en GKS, pero con una extensión al modelo de la pantalla en forma de segmentos editable.
PostScriptUn lenguaje de programación desarrollado por Adobe Corporation, los modelos de pantalla son como un conjunto de caminos que sirven como límites infinitamente delgadas o las plantillas que se pueden rellenar con colores o patrones de textura e imágenes
Arquitectura De Sistema De Ventanas
Arquitectura de sistema de ventanas
Bass and Coutaz [29] identifica tres posibles arquitecturas de software para implementar las funciones de un sistema de ventanas. todos ellos asumen que los controladores de dispositivos son independientes de los programas de aplicación. la primera opción es implementar y replicar la gestión de los múltiples procesos dentro de cada una de las aplicaciones por separado
Arquitectura de sistema de ventanas
esto no es una arquitectura muy satisfactorio ya que si las fuerzas de cada aplicación para estudiar los problemas difíciles de resolver los conflictos de sincronización con los dispositivos de hardware.
Arquitectura de sistema de ventanas
la segunda opción es llevar a cabo la función de gestión dentro de la kernel del sistema operativo, la centralización de la gestión de tareas liberándola de las aplicaciones individuales. aplicaciones aún debe ser desarrollado con las características específicas del sistema operativo en particular en mente
Arquitectura de sistema de ventanas
la tercera opción ofrece la mayor portabilidad, como la función de gestión que está escrito como una aplicación independiente por derecho propio y el apoyo a la gestión de los recursos compartidos.
La arquitectura cliente-servidor
cliente de la aplicación
cliente de la aplicación
cliente de la aplicación
Resumen de terminales
Resumen de terminales
Resumen de terminales
controladores de dispositivo
gestor de recursos
La arquitectura cliente-servidor
Ventana 2
Ventana 1
Ventana n
ratón Teclado
un ejemplo clásico de sistema de ventanas basado en la arquitectura cliente-servidor es el sistema estándar de la industria de ventanas X, deloped en el Instituto Tecnológico de Massachusetts (MIT) en 1980
Aplicación cliente
Servidor_______Controladores de dispositivos
Ventana del administrador de clientes
tecladoratón
8,3 el sistema X de Windows (liberación II) de la arquitectura
Cada cliente del servidor XII es asociado a una abstracta terminal o principal ventana
El servidor X realiza las siguientes tareas:
Permite acceder a la visualización de multiples aplicaciones de clientes
Interpreta las peticiones de los clientes para realizar la operación de la pantalla o proporciona otro tipo de información
Multiplexa la corriente de los eventos de entrada física del usuario y los pasa al cliente adecuado
Minimiza el trafico en la red mediante el alivio de los clientes de tener que realizar un seguimiento de la información a determinadas, como las fuentes, en estructuras complejas de datos que los clientes puedan acceder por ID de números
Un gerente independiente como lo es el gerente hace cumplir las políticas para resolver los conflictos y las solicitudes de entrada y salida hacia los demás clientes
El gerente también adopta diferentes políticas también tiene la opción de moverse dentro de las demás ventanas
Estas políticas incluyen
Permite la transferencia de datos entre clientes
Métodos para seleccionar un cliente El cliente activa el foco de entrada Esquema de trazo de la superposición
de ventanas/azulejos como regiones de la pantalla
8.3 PROGRAMACIÓN DE LE APLICACIÓN
En la programación de la aplicación se describe paradigmas de programación que se puede utilizar para organizar el flujo de control dentro dela aplicación.
El primero es el de lectura-evaluación, que es interno en la misma aplicación.
Diagrama del paradigma de lectura-evaluación.
Lee la entrada
Procesa la entrada
Servidor
Salir?
Dispositivo
Comienza
Termina
Cuando el notificador recibe un evento del sistema, ve si el evento fue identificado por el programa de aplicación y si es así, pasa a la eventos y el control sobre el procedimiento de devolución de llamada que se ha registrado para el evento.Después del procesamiento del evento, se va al procedimiento de devolución de llamada y devuelve el control al notificador, ya sea para continuar recibiendo los eventos o solicitar la terminación.
registro de las devoluciones de llamada con el
notificador
Llama al notificador
Procesa el evento
Lee la entrada
Enviar la devolución apropiada
seguir?
comienzo
no
si
Fin
Notificador
Aplicación
El paradigma de la comunicación basada en la programación
El programa presenta una ventana o marco, con un botón, la etiqueta dejar de fumar, cuando se selecciona el dispositivo de señalización hace que el programa deje de hacerlo.El programa de aplicación se inicia al notificante por la xv_main_loop llamada de procedimiento. Cuando el notificador recibe un evento de seleccionar el botón, se pasa el control a la salir de procedimiento que destruye la estructura exterior y la terminación peticiones.
Supongamos que haiga la condición de error durante el procesamiento de un caso de type_2 tipo. Una vez que la condición de error se reconoce, la aplicación comienza otro ciclo de lectura y evaluación de contenidos dentro de la rama de la declaración del caso. Dentro de ese bucle, todos los eventos no relevantes pueden ser recibidos y descartados. El ejemplo dado anteriormente pseudocódigo podría ser modificado de la siguiente manera:
repeat
read-event(myevent)
case myevent.type
type_l :
do type_l processing
type_2 :
if (error-condition) then
repeat
read-event(myevent2)
case myevent2.type
type_l type_n :
end case until (end-condition2]
end ift y p e _ n :
do type_n processing end caseuntil (end-condition)
En el paradigma de la comunicación basada en un diálogo preventivo no sería tan simple, porque el flujo de control está fuera de las manos del programador de aplicaciones. Los procedimientos de devolución de llamada a todos tendría que ser modificado para reconocer las situaciones en que es necesario el diálogo preventivo y las situaciones caso omiso de todos los eventos que se transmiten a ellos por el notificante.Para ayudar en el diseño de gestores de ventanas específicas, el Consorcio X bas produjo el Inter-cliente Convenciones del manual (ICCCM), que establece las convenciones de diversas cuestiones de política que no están incluidos en la definición de X.
