SOPORTE A LA IMPLEMENTACI

1
SOPORTE A LA IMPLEMENTACIÓN.
2
SOPORTE A LA IMPLEMENTACIÓN.

• ÍNDICE.
• SISTEMA DE VENTANAS.
• Concepto De Terminal Virtual......................
  .................................................3
  
• Características Principales.......................
  ..................................................
  .....9
• Arquitecturas De Un Sistema De Ventanas...........
  ........................................14
• PROGRAMANDO UNA APLICACIÓN.
• Introducción......................................
  ..................................................
  ...........21
• Paradigma Bucle Lectura-Evaluación...............
  ...........................................22
• Paradigma Basado En La Notificación..............
  ...........................................24
• LOS PAQUETES DE HERRAMIENTAS.
• Introducción......................................
  ..................................................
  ...........25
• Características Principales.......................
  ..................................................
  ....26
• SISTEMAS DE GESTIÓN DE INTERFACES DE USUARIO.
• Características Generales.........................
  ..................................................
  ....28
• UIMS Como Arquitectura Conceptual.................
  ..........................................29
• Paradigma MVC.....................................
  ..................................................
  ......30
• Paradigma PAC.....................................
  ..................................................
  .......39
• Diferencias Entre MVC y PAC.......................
  ...............................................40
• Modelado De Diálogos Para UIMS....................
  ............................................41

3
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Concepto de terminal virtual.
• - En un S.I se pueden utilizar múltiples
  dispositivos.
• - Un terminal virtual entiende un lenguaje
  genérico y lo traduce al lenguaje particular de
  cada dispositivo .
• - Cada sistema de ventanas posee su propio
  lenguaje genérico, denominado modelo de imagen.

4
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Ventanas.
• Ejemplos de modelos de imágenes.
• Píxel.
• Graphical Kernel System(GKS).
• Programmers hierarchical interface to
  graphics(PHIGS).
• PostScript.

5
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema de Ventanas.
• Ejemplos de modelos de imágenes.
• Modelo de imagen de Píxel.
• La pantalla está representada por un conjunto de
  filas y columnas de píxeles, los cuales se pueden
  encender o apagar de forma individual o bien
  asignarles un color.
• Es el modelo más usual para los PC y por los
  sistemas X Windows.

6
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas de ventanas.
• Ejemplos de modelos de imágenes.
• Modelo Graphical Kernel System(GKS).
• Sistema internacional, en el cual se representa
  la pantalla como una colección de segmentos
  conectados, cada uno de los cuales es un macro de
  comandos gráficos elementales.

7
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema de ventanas.
• Ejemplos de modelos de imágenes.
• Modelo Programmers Hierarchical Interface To
  Graphics (PHIGS).
• Otro estándar internacional.
• Está basado en GKS , pero lo amplia al incorporar
  segmentos editables .

8
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Ejemplos de modelos de imágenes.
• Modelo PostScript.
• Un lenguaje de programación desarrollado por
  Adobe Corporation.
• Se modela la pantalla como un conjunto de líneas
  cuyo contorno o calado puede ser infinitamente
  fino y que se puede rellenar con varios colores
  o patrones de texturas e imágenes.

9
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Características Generales.
• Proporcionarle al programador independencia de
  los dispositivos hardware.
• Soportar múltiples procesos de usuario
  independientes y concurrentes .
• Permitir la visualización de cada una de las
  aplicaciones individuales.

10
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Características.
• Independencia de los dispositivos hardware.
• Se consigue mediante el empleo de los terminales
  virtuales, ya que el programador no realiza la
  aplicación para unos dispositivos hardware
  particulares.

11
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Características.
• Soporte de múltiples procesos de usuario
  independientes y concurrentes .
• Se consigue compartiendo los recursos hardware
  entre varias copias de terminales virtuales.
• Cada copia se comporta como un proceso
  independiente, que se ejecuta de forma
  concurrente.
• La ejecución concurrente de los procesos está
  gestionada por el sistema de ventanas.

12
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Características.
• Permitir la visualización de cada una de las
  aplicaciones individuales.
• Se le asigna una parte de la pantalla a cada uno
  de los terminales virtuales.
• Es necesario un mecanismo que gestione los
  conflictos de visualización.

13
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Características.
• En definitiva, los sistemas de ventanas
  proporcionan
• Independencia a la hora de programar de los
  diferentes dispositivos hardware.
• La gestión de múltiples, independientes pero
  simultaneas aplicaciones activas.

14
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Arquitectura de un Sistema de Ventanas.
• Bass y Coutaz identificaron tres tipos de
  arquitecturas.
• Se diferencian en la forma de gestionar los
  procesos.
• En la práctica la división entre cada una de
  ellas no está clara.

15
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Arquitectura de un Sistema de Ventanas.
• La primera opción consiste en implementar y
  replicar la gestión de los procesos en cada
  aplicación.
• La segunda opción consiste en implementar el
  role de gestor en el Kernel del S.O.
• La tercera opción consiste en una arquitectura
  cliente-servidor.

16
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Arquitectura de un Sistema de Ventanas.
• Implementar y replicar la gestión de los procesos
  en cada aplicación.
• No es una arquitectura optima, ya que obliga a
  cada una de las aplicaciones a tener que
  gestionar los conflictos de sincronización con
  los recursos hardware compartidos.
• Esto reduce la portabilidad de las aplicaciones
  individuales.

17
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Arquitectura de un Sistema de Ventanas.
• Implementar el role de gestor en el kernel del
  S.O.
• Se centralizan las tareas de gestión para
  liberar de las mismas a las aplicaciones.
• Las aplicaciones deberían desarrollarse teniendo
  en cuenta las características propias de cada
  S.O.
• Esto reduce la portabilidad de las aplicaciones
  individuales.

18
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Arquitectura de un Sistema de Ventanas.
• Arquitectura Cliente-Servidor.
• Las funciones de gestión son implementadas en una
  aplicación independiente, y así se puede ofrecer
  un interface a otras aplicaciones, común a todos
  los S.O.
• En principio es la que permite una mayor
  portabilidad.
• Un ejemplo de esta arquitectura El X Window
  System.

19
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Arquitectura de un Sistema de Ventanas.
• El X Window System.
• Características Principales.
• Estándar industrial desarrollado en el (MIT) a
  mediados de los 80.
• El X (o X11), está basado en un modelo de
  imágenes de píxel.
• El X está basado en un protocolo de red
  (protocolo X), el cual clarifica la comunicación
  cliente-servidor y lo convierte en el más
  independiente.
• Cada cliente está asociado con un terminal
  virtual o venta principal.
• Un cliente independiente, el gestor de ventanas,
  se encarga de la resolución de conflictos entre
  los clientes.

20
SOPORTE A LA IMPLEMENTACIÓN.

• Sistema De Ventanas.
• Arquitectura de un Sistema de Ventanas.
• El X Window System.
• Principales funciones del servidor X.
• Permite (o deniega) las peticiones de los
  clientes para realizar operaciones en la
  pantalla.
• Demultiplexar los flujos de eventos físicos de
  entrada desde el usuario y se los pasa al
  cliente apropiado.
• Minimiza el trafico a través de la red, al
  liberar a los clientes de tener que almacenar
  cierta información de la pantalla.

21
SOPORTE A LA IMPLEMENTACIÓN.

• Programando Una Aplicación.
• Introducción.
• Las aplicaciones interactivas generalmente son
  conducidas por el usuario.
• Existen dos paradigmas para gestionar el flujo
  control en el interior de la aplicación.
• Paradigma basado en un bucle lectura-evaluación.
  
• Paradigma basado en la notificación.

22
SOPORTE A LA IMPLEMENTACIÓN.

• Programando Una Aplicación.
• Paradigma basado en un bucle lectura-evaluación.
  
• Consiste en un bucle de lectura-evaluación, que
  se encuentra en el interior de la aplicación.
• El servidor envía las entradas del usuario a la
  aplicación del cliente.
• El cliente lee el evento que se le pasa y
  determina el comportamiento de aplicación.

23
SOPORTE A LA IMPLEMENTACIÓN.

• Programando Una Aplicación.
• Ejemplo de un bucle lectura evaluación
• Repeat
• Read-event(myevent)
• Case myevent.type
• Type_1
• Do type_1 processing
• Type_2
• Do type_2 processing
• Type_n
• Do type_n processing
• End case
• End repeat

24
SOPORTE A LA IMPLEMENTACIÓN.

• Programando Una Aplicación.
• Paradigma basado en la notificación.
• El ciclo de control no reside dentro de la
  aplicación.
• Un notificador centralizado recibe los eventos
  del sistema de ventanas y los filtra al programa
  de aplicación.
• La aplicación informa al notificador que eventos
  son interesantes para ella, y para cada uno de
  ellos declara un procedimiento de callback .

25
SOPORTE A LA IMPLEMENTACIÓN.

• Los paquetes de Herramientas.
• Introducción.
• Para el usuario es importante que el
  comportamiento de las entradas y de las salidas
  esté relacionado.
• Para el programador lograr esta relación
  entrada-salida supone un gran esfuerzo.
• Los paquetes de herramientas surgen para
  facilitarle al programador esta tarea.

26
SOPORTE A LA IMPLEMENTACIÓN.

• Los paquetes de Herramientas.
• Características.
• Los kits de herramientas proporcionan al
  programador objetos de interacción ya creados.
• Existen kits de herramientas para todos los
  entornos de ventanas. ( OSF/Motif , Xview ,
  Macintosh Toolbox, Software Development Toolkit
  for Microsoft Windows).
• Facilitan la generalización, reutilización y la
  consistencia.

27
SOPORTE A LA IMPLEMENTACIÓN.

• Los paquetes de Herramientas.
• Características.
• Son apropiados para la programación orientada a
  objetos ya que
• Poseen la capacidad de definir clases de objetos
  de interacción.
• La construcción de objetos de interacción
  complejos resulta más fácil si su definición se
  basa en objetos más simples. (Herencia).

28
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas de Gestión De Interfaces De Usuario
• Introducción.
• Para lograr una buena especificación,diseño e
  implementación no basta con los kits de
  herramientas ya que estos presentan algunas
  limitaciones
•  Proporcionan un rango limitado de objetos de
  interacción.
• Son caros de crear y difíciles de usar paro los
  no programadores. 
• Por tanto es necesario un nuevo nivel de
  abstracción que solvente estas deficiencias Los
  sistemas de gestión de la interface de usuario
  (UIMS).

29
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Características.
• Proporcionan una arquitectura conceptual para la
  estructura de un sistema interactivo que se
  concentre en la separación entre la semántica de
  la aplicación y la interface.
• Proporcionan técnicas para implementar una
  aplicación y una presentación independientes al
  mismo tiempo que conserva la conexión entre
  ellas.
• Proporcionan técnicas de soporte para la gestión,
  la implementación y evaluación de un entorno
  interactivo en tiempo de ejecución.

30
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• La primera arquitectura conceptual fue formulada
  por Seeheim.
• Consta de tres elementos
• Presentación.
• Dialogo Control.
• Interface de la aplicación.

31
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Elementos de la arquitectura.
• Presentación.
• Componente responsable de la apariencia de la
  interface incluyendo que salidas y entradas son
  accesibles por el usuario.

32
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Elementos de la arquitectura.
• Interface de la aplicación.
• La visualización de las semánticas de aplicación
  que se proporcionan a modo interface.

33
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Elementos de la arquitectura.
• Dialogo Control.
• Componente que regula la comunicación entre la
  presentación y la aplicación. Puede ser interno a
  la aplicación mediante un bucle de
  lectura-evaluación o externo a la aplicación,
  basándose en la notificación.

34
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Características.
• Se separa la aplicación y la presentación.
  Existen cuatro motivos para ello
• Portabilidad.
• Reutilización.
• Interfaces múltiples.
• Interfaces a medida del usuario.
• En la práctica, esta separación no está tan
  clara.

35
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Razones separación presentación-aplicación.
• Portabilidad.
• Para que una aplicación pueda ser utilizada en
  diferentes sistemas es mejor desarrollarla
  independientemente de su interface, ya que esta
  es dependiente de los dispositivos.

36
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Razones separación presentación-aplicación.
• Reutilización.
• La separación incrementa la probabilidad de que
  los componentes sean reutilizados para así
  disminuir los costes de desarrollo.

37
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Razones separación presentación-aplicación.
• Interfaces múltiples.
• Para aumentar la flexibilidad interactiva de una
  aplicación, se pueden desarrollar múltiples
  interfaces diferentes que consiguen la misma
  funcionalidad.

38
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Uims como una arquitectura conceptual.
• Razones separación presentación-aplicación.
• A medida del usuario.
• La interfaz del usuario puede estar hecha a su
  medida, tanto en el diseño como en el uso, para
  incrementar su efectividad sin tener que alterar
  la aplicación.

39
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario.
• Paradigma Modelo-Visor-Controlador (MVC).
• El modelo de Seeheim no permite construir
  grandes y complejos S.I a partir de componentes
  mas pequeños.
• Se formulo el paradigma MVC en el entorno de
  programación Smaltalk.
• En Smalltalk, el enlace entre las semánticas de
  aplicación y presentación se establecen por medio
  del trío MVC.
• El modelo representa las semánticas de
  aplicación.
• La visualización dirige la salida gráfica o de
  texto de la aplicación.
• El controlador dirige la entrada.
• El comportamiento básico de modelos,
  visualizaciones y controladores ha sido
  incorporado en clases de objetos Smalltalk.

40
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Paradigma Presentación-Abstracción-Control (PAC).
  
• Fue propuesto por Coutaz.
• PAC está basado también en una colección de
  tríos.
• La semántica de aplicación está representada por
  el componente de abstracción.
• Las entradas y las salidas se combinan en un solo
  componente de presentación
• Un componente explícito de control dirige el
  diálogo y la correspondencia entre la aplicación
  y la presentación.

41
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Diferencias entre MVC Y PAC.
• PAC agrupa la entrada y la salida mientras que
  MVC las separa
• PAC no está ligado a ningún entorno de
  programación, aunque si que está próximo a una
  orientación a objetos.
• PAC es una arquitectura más conceptual que MVC
  porque es menos dependiente de la implementación.

42
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Modelado de diálogos para UIMS.
• Myers dio varias técnicas usadas en el modelado
  del diálogo para UIMS.
• Redes de Menús.
• Connotaciones gramaticales.
• Diagramas de transición de estados.
• Lenguajes de eventos.
• Lenguajes Declarativos.
• Sistemas cerrados.
• Especificaciones Graficas.

43
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario.
• Modelado de diálogos para UIMS.
• Redes de Menús.
• La comunicación entre aplicación y presentación
  se modela como una red de menús y submenús
• La comunicación entre aplicación y presentación
  se modela como una red de menús y submenús
• El menú puede representarse como elementos
  gráficos o botones que el usuario puede
  seleccionar mediante un puntero

44
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario.
• Modelado de diálogos para UIMS.
• Connotaciones Gramaticales.
• El diálogo entre la aplicación y la presentación
  puede ser considerado como una gramática de
  acciones y respuestas.
• El dialogo puede ser descrito mediante
  gramáticas libres de contexto, como BNF .
• Es adecuada para describir interfaces basadas en
  comandos, pero no lo son para técnicas de
  interacción gráfica.
• No es posible saber si el evento lo inicia el
  usuario o la aplicación.

45
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario.
• Modelado de diálogos para UIMS.
• Diagramas de transición de estados.
• Pueden ser usados como un medio gráfico de
  expresión de diálogo.
• La dificultad reside en unir los eventos de
  diálogo con la presentación correspondiente.
• No esta claro como se representa la comunicación
  entre la aplicación y la presentación.

46
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Modelado de diálogos para UIMS.
• Lenguajes de eventos.
• Similares a las connotaciones gramaticales, pero
  pueden ser modificados para dirigir y
  proporcionar algún feedback semántico.
• Son buenos para describir el comportamiento de
  entrada-salida en términos de reglas de
  producción.
• Una regla de producción se activa cuando una
  entrada se recibe y emite respuestas de salida.
• Es ahora más difícil modelar el flujo global del
  diálogo.

47
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Modelado de diálogos para UIMS.
• Lenguajes declarativos.
• Los lenguajes declarativos describen el resultado
  de la comunicación entre la aplicación y la
  presentación, y no como ocurriría en términos de
  una secuencia de eventos.
• Un método declarativo se concentra más en
  describir como se relacionan la presentación y la
  aplicación en vez del flujo de eventos que se
  produce entre ambos.
• Esta relación puede modelarse como una base de
  datos compartida a cuyos valores pueden acceder
  tanto la presentación como la aplicación.

48
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Modelado de diálogos para UIMS.
• Sistemas Cerrados.
• Son un subconjunto especial de lenguajes
  declarativos.
• Se usan para hacer explícita la conexión entre la
  información independiente de la presentación y la
  aplicación.

49
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Modelado de diálogos para UIMS.
• Especificación Gráfica.
• Permiten programar gráficamente la especificación
  de diálogo en términos de su propio lenguaje de
  presentación.
• El programador construye el diálogo de
  interacción directamente en términos de los
  objetos de interacción gráfica real que verá el
  usuario, en lugar de hacerlo mediante algún
  lenguaje de especificación textual.
• Esta técnica abre la especificación de diálogo
  al no-programador, lo cual es una importante
  contribución.

50
SOPORTE A LA IMPLEMENTACIÓN.

• Sistemas De Gestión De Interfaces De Usuario
• Modelado de diálogos para UIMS.
• Uso de técnicas de modelado.
• Las técnicas que permiten la descripción de la
  aplicación independientemente de la aplicación,
  presentan ventajas desde una perspectiva de
  ingeniería del software.
• Existen discrepancias entre el uso de técnicas
  con dificultad pero poderosas a la hora de
  describir tanto la comunicación y la
  correspondencia entre aplicación y la
  presentación y por otro lado, el uso de técnicas
  sencillas pero limitadas.
• Los programadores probablemente, optarán por
  técnicas poderosas que proporcionan la mayor
  flexibilidad.
• Los no programadores optarán por la simplicidad a
  pesar de la deficiencia en la expresividad de la
  técnica.