contexto: aplicación gráfica. siempre que se piensa en separar la funcionalidad de una...
TRANSCRIPT
COMPARACIÓN TEÓRICA DE UNA ARQUITECTURA MVC CON UNA ARQUITECTURA PAC
Contexto: Aplicación gráfica
INTRODUCCIÓN
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.
DEFINICIÓN DEL PROBLEMA
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.
DEFINICIÓN DEL PROBLEMA
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
DEFINICIÓN DEL PROBLEMA
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?
OBJETIVO
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.
ARQUITECTURA MVC
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
ARQUITECTURA MVC
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
ARQUITECTURA MVC (COMPONENTES)
ARQUITECTURA MVC (ESTRUCTURA)
CREACIÓN DE LOS COMPONENTES
FLUJO DE INFORMACIÓN
PATRONES DE DISEÑO INVOLUCRADOS 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.
PASOS PARA LA IMPLEMENTACIÓN
1. Separar funcionalidad Principal de la interacción con el usuario
2. Implementar el mecanismo de propagación de cambios3. Diseñar e Implementar las Vistas4. Diseñar e Implementar los Controladores5. Diseñar e Implementar las relaciones entre vista y
controlador6. Implementar la inicialización del MVC7. Creación de Vistas Dinámicas8. Controladores agregables9. Infraestructura para vistas y controladores jerárquicos10. Desacoplamiento de las dependencias del sistema
ARQUITECTURA PAC
Este patrón define una descomposición modular para sistemas interactivos utilizando agentes cooperativos organizados de manera jerárquica.
ARQUITECTURA PAC
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
ARQUITECTURA PAC (COMPONENTES)
ARQUITECTURA PAC (ESTRUCTURA)
ARQUITECTURA PAC (EJEMPLO)
FLUJO DE INFORMACIÓN
PATRONES DE DISEÑO INVOLUCRADOS El componente de Control usualmente
se implementa usando un “Mediator” El componente de Presentación
usualmente se implementa usando un “Strategy”
PASOS PARA LA IMPLEMENTACIÓN
1. Definir un modelo de la aplicación; 2. Definir una estrategia general para organizar la jerarquía3. Especificar los Agentes Top-Level4. Especificar los Agentes Bottom-Level5. Especificar los Agentes Bottom-Level para servicios del
sistema6. Especificar los Agentes Intermediate-Level que se componen
de los Agentes Bottom-Level7. Especificar los Agentes Intermediate-Level que coordinan a
los Agentes Bottom-Level8. Separar funcionalidad Principal de la interacción con el
usuario9. Proveer la interfaz externa10. Vincular los agentes de acuerdo con la jerarquía
COMPARACIÓN (VENTAJAS)
MVC PAC
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
COMPARACIÓN (DESVENTAJAS)
MVC PAC
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
CONTEXTO: APLICACIÓN GRÁFICA (MVC) 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.
CONTEXTO: APLICACIÓN GRÁFICA (MVC) 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.
CONTEXTO: APLICACIÓN GRÁFICA (PAC) 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
CONTEXTO: APLICACIÓN GRÁFICA (PAC) 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
CONCLUSIONES
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
¿PREGUNTAS?