Contexto: Aplicación gráfica.  Siempre que se piensa en separar la funcionalidad de una aplicación de su interacción con el usuario, bien sea una aplicación.

Presentación del tema: "Contexto: Aplicación gráfica.  Siempre que se piensa en separar la funcionalidad de una aplicación de su interacción con el usuario, bien sea una aplicación."— Transcripción de la presentación:

1 Contexto: Aplicación gráfica

2  Siempre que se piensa en separar la funcionalidad de una aplicación de su interacción con el usuario, bien sea una aplicación Web o una aplicación de escritorio, se piensa en una descomposición utilizando MVC como una obligación.

3  Las arquitecturas de software buscan mostrar formas de aplicar una descomposición modular de las diferentes funcionalidades de un sistema, separando responsabilidades bien definidas en cada uno de los módulos.

4  Existen patrones de arquitectura que definen la estructura modular que deben seguir los sistemas interactivos, dicha estructura a modo general, separa los componentes de visualización, lógica de procesamiento y almacenamiento de datos

5  De los patrones existentes el más utilizado en los sistemas interactivos es el patrón MVC, sin embargo:  ¿Cuál es la razón para utilizar este patrón de manera tan amplia?  ¿Existen otras alternativas de implementación?

6  El objetivo de la presentación es realizar una comparación teórica entre las arquitecturas MVC y PAC, dentro de un contexto enfocado a la realización de una aplicación gráfica interactiva.

7  La arquitectura MVC busca desacoplar el modelo de la visualización de un sistema, responsabilizando a cada módulo de una parte específica de las responsabilidades más comunes en una aplicación interactiva

8  Separación modular de las responsabilidades  M (Modelo/Model) es el encargado de realizar la funcionalidad central y gran parte del procesamiento de los datos  V (Vista/View) es el componente encargado de desplegar la información del sistema y sus sistemas de interacción al usuario  C (Controlador/Controller) es el componente encargado de manejar las interacciones del usuario, traduciendo datos de la interfaz al modelo y viceversa. Es el encargado de mantener la consistencia entre la vista y el modelo

9

10

11

12

13  Registrar Vistas con el Modelo para que éste los notifique usualmente se realiza con el patrón Observer  Es posible realizar una variación del patrón en donde existen diferentes listas de vistas a ser actualizadas de acuerdo con su interés.

14 1. Separar funcionalidad Principal de la interacción con el usuario 2. Implementar el mecanismo de propagación de cambios 3. Diseñar e Implementar las Vistas 4. Diseñar e Implementar los Controladores 5. Diseñar e Implementar las relaciones entre vista y controlador 6. Implementar la inicialización del MVC 7. Creación de Vistas Dinámicas 8. Controladores agregables 9. Infraestructura para vistas y controladores jerárquicos 10. Desacoplamiento de las dependencias del sistema

15  Este patrón define una descomposición modular para sistemas interactivos utilizando agentes cooperativos organizados de manera jerárquica.

16  La descomposición de componentes se realiza de la siguiente manera:  Se definen agentes que se hacen cargo de un aspecto de la funcionalidad  Cada uno de los agentes definidos contiene 3 componentes: Presentación, Abstracción y Control  P (Presentación /Presentation) Es el encargado de mostrar la interfaz del usuario  A (Abstracción / Abstraction) Se encarga de mantener el estado del agente y sus modificaciones.  C (Control /Control) Es el encargado de comunicación entre agentes, este componente generalmente tiene las mismas responsabilidades en los diferentes agentes

17

18

19

20

21  El componente de Control usualmente se implementa usando un “Mediator”  El componente de Presentación usualmente se implementa usando un “Strategy”

22 1. Definir un modelo de la aplicación; 2. Definir una estrategia general para organizar la jerarquía 3. Especificar los Agentes Top-Level 4. Especificar los Agentes Bottom-Level 5. Especificar los Agentes Bottom-Level para servicios del sistema 6. Especificar los Agentes Intermediate-Level que se componen de los Agentes Bottom-Level 7. Especificar los Agentes Intermediate-Level que coordinan a los Agentes Bottom-Level 8. Separar funcionalidad Principal de la interacción con el usuario 9. Proveer la interfaz externa 10. Vincular los agentes de acuerdo con la jerarquía

23 MVCPAC  Implementación sencilla  Funcionalidades bien definidas  Facilita el cambio o la adición de una nueva vista  Funcionalidades especificas  Procesamiento en paralelo por definición  Facilita el cambio de una funcionalidad  Comunicación bien definida sin necesidad de conocer los otros agentes

24 MVCPAC  Alto acoplamiento entre algunos componentes  Al aumentar el numero de vistas aumenta la complejidad  Necesidad de contar con una lista de vistas a actualizar  Complejo de Implementar  No existe una regla general para la definición de responsabilidades entre los agentes

25  La arquitectura más utilizada es la MVC, ya que facilita la implementación de la representación visual de los datos generados en el modelo.  MVC es utilizado para aplicaciones que se basan en un mismo modelo, esto ocurre en una gran cantidad de aplicaciones gráficas como juegos.

26  Las posibles limitaciones del MVC en cuanto a diferentes entradas y múltiples vistas se ven amortiguadas por el hecho que, usualmente, las aplicaciones gráficas son mono usuario y la gran parte del procesamiento se encuentra en el modelo.

27  En una implementación con el patrón PAC facilita la lectura de datos y la presentación adecuada de éstos  Cada uno de los agentes involucrados se encarga de una parte de la funcionalidad y realiza procesos en paralelo

28  Una aplicación que requiera procesar gran cantidad de datos para visualizarlos puede beneficiarse de la eficiencia brindada por el PAC.  Un ejemplo es un simulador de fuerzas físicas, en el cual se tienen en cuenta gran cantidad de datos que requieren ser procesados y visualizados rápidamente y de forma realista

29  Aunque con el patrón PAC se aumenta la complejidad de implementación, se solucionan algunos problemas que el MVC contiene, como la necesidad de tener la lista de vistas a implementar y la necesidad de implementar paralelismo en el modelo, ya que el patrón PAC funciona de forma paralela desde su definición.  PAC puede generar un en el rendimiento de una aplicación gráfica similar a un simulador

30

31  Implementación de una aplicación gráfica, tipo simulador utilizando ambos patrones y comparar tiempos de respuesta y de procesamiento con el fin de comparar el rendimiento de un sistema que utiliza MVC con otro que utiliza PAC