Soporte a la Aplicación.

1. Universidad Autónoma de Tlaxcala.Facultad de Ciencias Básicas Ingeniería y Tecnología.Interacción Humano Computadora.Equipo: 3Integrantes:Álvaro Mena Meléndez.Cesar Guillen Sánchez.Omar Sánchez Cabrera.Daniel Copalcua Delgadillo.JhoanZapotitla Morales.

2. 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.

3. 2.-Las Herramientasde 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.

4. 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.

5. 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.

6. elementos de los sistemas de ventanas

7. 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.

8.  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éna 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.

9. 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.

10. 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

11. Ejemplos de Imágenes de Modelo

12. 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 .

13. 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.

14. InterfazJerárquicodel 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.

15. 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 eimágenes

16. Arquitectura De Sistema De Ventanas

17. 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

18. 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.

19. Arquitectura de sistema de ventanas • la segunda opción es llevar a cabo la función de gestión dentro de la kerneldel 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

20. 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.

21. 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 gestor de recursos controladores de dispositivo

22. La arquitectura cliente-servidor ratón Ventana 2 Teclado Ventana 1 Ventana n

23. 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

24. Servidor_______ Controladores de dispositivos Ventana del administrador de clientes Aplicación cliente teclado ratón 8,3 el sistema X de Windows (liberación II) de la arquitectura

25. Cada cliente del servidor XII es asociado a una abstracta terminal o principal ventana El servidor X realiza las siguientes tareas:

26. 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

27. 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

28. 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

29. 8.3 PROGRAMACIÓN DE LE APLICACIÓN

30. 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.

31. Comienza Lee la entrada Servidor Dispositivo • Diagrama del paradigma de lectura-evaluación. Procesa la entrada Salir? Termina

32. 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.

33. comienzo El paradigma de la comunicación basada en la programación registro de las devoluciones de llamada con el notificador Notificador Aplicación Llama al notificador Lee la entrada Fin Procesa el evento Enviar la devolución apropiada seguir? no si

34. 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.

35. 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:

36. repeat read-event(myevent) case myevent.type type_l: do type_lprocessing type_2 : if (error-condition) then repeat read-event(myevent2) case myevent2.type type_l type_n: end case until (end-condition2] end if t y p e _ n : do type_nprocessing end case until (end-condition)

37. 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.