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?