Contexto: Aplicación gráfica
COMPARACIÓN TEÓRICA DE UNA
ARQUITECTURA MVC CON UNA ARQUITECTURA
PAC
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Separar funcionalidad Principal de la interacción con el
usuario
Implementar el mecanismo de propagación de cambios
Diseñar e Implementar las Vistas
Diseñar e Implementar los Controladores
Diseñar e Implementar las relaciones entre vista y
controlador
Implementar la inicialización del MVC
Creación de Vistas Dinámicas
Controladores agregables
Infraestructura para vistas y controladores jerárquicos
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Definir un modelo de la aplicación;
Definir una estrategia general para organizar la jerarquía
Especificar los Agentes Top-Level
Especificar los Agentes Bottom-Level
Especificar los Agentes Bottom-Level para servicios del sistema
Especificar los Agentes Intermediate-Level que se componen de los
Agentes Bottom-Level
Especificar los Agentes Intermediate-Level que coordinan a los Agentes
Bottom-Level
Separar funcionalidad Principal de la interacción con el usuario
Proveer la interfaz externa
Vincular los agentes de acuerdo con la jerarquía
MVC



Implementación sencilla
Funcionalidades bien
definidas
Facilita el cambio o la
adición de una nueva vista
PAC




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 (VENTAJAS)
MVC



Alto acoplamiento entre
algunos componentes
Al aumentar el numero de
vistas aumenta la
complejidad
Necesidad de contar con una
lista de vistas a actualizar
PAC


Complejo de Implementar
No existe una regla general
para la definición de
responsabilidades entre los
agentes
COMPARACIÓN (DESVENTAJAS)
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?
Descargar

Comparación Teórica de una arqiutectura MVC con una