1

Programación Orientada a Objetos

Model-View-Controller

César Julio Bustacara Medina

Facultad de Ingeniería Pontificia Universidad Javeriana

28/04/2016

Agenda

Introducción Model-View-Controller Ejemplo

Contexto Problema Solución Estructura Dinámica Implementación

Introducción

• Los sistemas de hoy permiten un alto grado de interacción con el usuario, principalmente lograda con la ayuda de la interfaz gráfica de usuario.

• El objetivo es ampliar la usabilidad de una aplicación.

• Los sistemas de software usables proporcionan acceso conveniente a sus servicios, entonces permite a los usuarios aprender la aplicación para producir resultados rápidamente.

• Cuando se especifica la arquitectura de tales sistemas, el reto es mantener el núcleo funcional independiente de la interfaz de usuario.

• El núcleo del sistema interactivo está basado en los requerimientos funcionales para el sistema, y usualmente permanece estable.

• Las interfaces de usuario, sin embargo, son objeto de cambios frecuentes y adaptación.

Introducción

• Por ejemplo, pueden soportar diferentes estándares de interfaz de usuario, metáforas específicas del cliente, o interfaces que deban ser ajustadas a los procesos de negocio del cliente.

• Esto requiere la adaptación de partes de la interfaz de usuario sin causar mayores efectos a la funcionalidad del software.

Introducción

• Se describen dos patrones arquitectónicos de organización para sistemas de software interactivos: – El patrón Model-View-Controller (MVC). Divide

una aplicación interactiva en tres componentes. • El modelo contiene la funcionalidad central y los datos.

• La vista presenta la información al usuario.

• Los controladores manejan la entrada de usuario. Un mecanismo de propagación de cambios asegura la consistencia entre la interfaz de usuario y el modelo.

Introducción

• El patrón Presentation-Abstraction-Control (PAC). Define una estructura para sistemas de software interactivos en forma de una jerarquía de agentes cooperantes.

– Cada agente es responsable de un aspecto específico de la funcionalidad y consiste de tres componentes: presentación, abstracción, y control.

– Esta subdivisión separa los aspectos de interacción hombre-máquina del agente de su funcionalidad central y su comunicación con otros agentes.

Introducción

Model-View-Controller (MVC)

• Divide una aplicación interactiva en tres componentes.

– El modelo contiene la funcionalidad central y los datos.

– La vista presenta la información al usuario.

– Los controladores manejan la entrada del usuario.

• Considere un sistema de información simple para elecciones políticas con representación proporcional.

• Este ofrece una hoja de cálculo para ingresar los datos y varios tipos de tablas y diagramas para presentar los resultados actuales.

• Los usuarios pueden interactuar con el sistema a través de una interfaz gráfica.

• Toda la información debe reflejar los cambios a los datos de votación inmediatamente..

Ejemplo

Negro: 43% Rojo: 39% Azul: 6% Verde: 10% Otro: 2%

0

10

20

30

40

50

Negro Rojo Azul Verde Ot ro

Negro 43

Rojo 39

Azul 6

Verde 10

Otro 2

Ejemplo

• Debe ser posible integrar nuevas formas de presentación de datos, como la asignación de sillas parlamentarias a partidos políticos, sin mayor impacto en el sistema. Además, el sistema debe ser portable a plataformas con diferente “look and feel”, como estaciones de trabajo corriendo KDE o PCs corriendo Mac o Windows.

Ejemplo

• Aplicaciones interactivas con interfaz hombre-máquina flexible.

Contexto

• Las interfaces gráficas son especialmente propensas a modificaciones. Cuando se extiende la funcionalidad de una aplicación, se deben modificar los menús para acceder a las nuevas funciones.

• Un cliente puede llamar para la adaptación de una interfaz de usuario específica, o se puede necesitar portar un sistema a otra plataforma con un “look and feel” diferente.

• Aún la actualización a una nueva versión de su sistema gráfico puede implicar cambios al código.

• La interfaz gráfica de sistemas de larga duración presenta un objetivo en movimiento.

Problema

• Diferentes usuarios tienen requerimientos conflictivos en la interfaz de usuario, los digitadores querrán ingresar la información en formularios mediante el teclado, un administrador querrá usar el mismo sistema principalmente usando el ratón. Por tanto, se debe poder incorporar fácilmente soporte para varios paradigmas de interfaz de usuario.

• Construir un sistema de tales características es costoso y propenso a errores si la interfaz de usuario está altamente acoplada con la funcionalidad central. Lo que puede resultar en el desarrollo y mantenimiento de varios sistemas diferentes: uno por cada implementación de la interfaz de usuario.

Problema

• Fuerzas : – La misma información es presentada de forma distinta

en ventanas diferentes.

– La presentación y comportamiento de la aplicación deben reflejar la manipulación de datos inmediatamente.

– Los cambios a la interfaz de usuario deben ser fáciles, y posibles en tiempos de ejecución.

– Soportar diferentes “look and feel” o el portar la interfaz de usuario no debe afectar el código en el núcleo de la aplicación.

Problema

• El patrón MVC divide una aplicación interactiva en tres áreas: procesamiento, entrada, y salida.

– El Modelo encapsula los datos y la funcionalidad central; es independiente de las representaciones específicas de la salida o el comportamiento de la entrada.

– La Vista presenta la información al usuario. Una vista obtiene los datos del modelo. Puede haber múltiples vistas del modelo. Cada vista tiene asociado un componente Controlador.

Solución

– Los Controladores reciben entradas, usualmente como eventos que codifican el movimiento del ratón, la activación de los botones del ratón, o el teclado. Los eventos son trasladados a solicitudes de servicio al modelo o a la vista. El usuario interactúa con el sistema únicamente a través de los controladores

Solución

Estructura

19

Estructura

Imagen tomada de: Programming in Java using the MVC architecture, Afzaal Ahmad Zeeshan

Modelo – Contiene la funcionalidad central de la aplicación.

– Encapsula los datos apropiados, y exporta procedimientos que ejecutan procesamiento específico de la aplicación. Los controladores invocan estos procedimientos en beneficio del usuario.

– El modelo proporciona funciones para acceder a los datos que son usados por los componentes vista para adquirir los datos a ser presentados.

Estructura

Modelo – El mecanismo de propagación mantiene un

registro de los componentes dependientes del modelo.

– Todas las vistas y los controladores seleccionados registran su necesidad de ser informados sobre los cambios.

– Los cambios al modelo disparan el mecanismo de propagación del cambio, quien es el único vínculo entre el modelo y las vistas y controladores.

Estructura

Vista

– Presentan la información al usuario.

– Diferentes vistas presentan la información del modelo en formas distintas.

– Cada vista define un procedimiento de actualización que es activado por el mecanismo de propagación de cambios.

– Cuando la actualización es invocada, una vista recupera los valores reales de los datos del modelo para ser presentados, y puestos en la pantalla.

Estructura

Vista – Durante la inicialización todas las vistas son

asociadas con el modelo y registradas con el mecanismo de propagación de cambios.

– Hay una relación uno a uno entre las vistas y los controladores.

– Las vistas frecuentemente ofrecen funcionalidades que permiten a los controladores manipular la presentación, útil para operaciones que no afectan el modelo, como el desplazamiento.

Estructura

Controlador – Aceptan entradas del usuario como eventos. Cómo

tales eventos son pasados al controlador depende de la interfaz gráfica.

– Los eventos son transformados en solicitudes para el modelo o la vista asociada.

– Si un comportamiento de un controlador depende del estado del modelo, el control se registra con el mecanismo de control de cambios, esto es útil cuando un cambio en el modelo activa o no una entrada en el menú.

Estructura

Estructura

• Escenario 1. La entrada del usuario cambia el modelo y dispara el mecanismo de cambio-propagación.

Controlador Modelo View

evento servicio notificación

actualizar desplegar

obtener datos

actualizar

obtener datos

vista actualizada

vista actualizada

Estructura

• Escenario 2. Muestra como la triada MVC es inicializada.

Estructura

• Separar la funcionalidad esencial de la interacción humano-computador.

• Implementar el mecanismo de cambio-propagación.

• Diseñar e implementar las vistas.

• Diseñar e implementar los controladores.

• Diseñar e implementar la relación entre vistas y controladores.

• Implementar:

– La inicialización del MVC completo,

– La creación de dinámica de vistas,

– La controladores que capturan diferentes eventos,

– La infraestructura jerárquica para vistas y controladores,

– Componentes del sistema, con bajo acoplamiento.

Implementación

• Ventajas – Vistas múltiples del mismo modelo. La separación

estricta del modelo de los componentes de la interfaz de usuario, permite que múltiples vistas sean implementadas usando un único modelo.

– Vistas sincronizadas. El mecanismo de propagación del modelo asegura que todos los observadores conectados son notificados de cambios a los datos de la aplicación en el momento correcto. Esto sincroniza todos las vistas y controladores dependientes.

Consecuencias

• Ventajas – Vistas y controladores conectables. La separación

conceptual de MVC permite intercambiar los objetos vista y controlador de un modelo. Los objetos de interfaz de usuario pueden ser sustituidos en tiempo de ejecución.

– Intercambiabilidad de “look and feel”. Como el modelo es independiente de todo el código de la interfaz de usuario, el portar la aplicación a una nueva plataforma no afecta el núcleo funcional de la aplicación.

– Framework potencial. Es posible basar un framework en este patrón

Consecuencias

• Desventajas – Incrementa la complejidad. No siempre seguir la

estructura MVC es la mejor forma de construir una aplicación interactiva. GoF argumenta que usar componentes separados MVC para menús y elementos de texto incrementa la complejidad sin ganar flexibilidad.

– Número potencialmente excesivo de actualizaciones. Si una única acción resulta en muchas actualizaciones, el modelo puede saltarse notificaciones innecesarias de cambios. Puede ser que no todas las vistas estén interesadas en cada cambio propagado por el modelo.

Consecuencias

• Desventajas

– Conexión íntima entre vista y controlador. El controlador y la vista son independientes pero relacionados cercanamente, lo que tiende a ocultar su reutilización individual. Una vista puede ser usada sin su controlador y viceversa.

– Acoplamiento de vistas y controladores al modelo. Tanto la vista como el controlador hacen llamadas directas al modelo. Esto implica que los cambios a la interfaz del modelo romperán el código de la vista y el controlador.

Consecuencias

• Desventajas – Ineficiente acceso a datos en la vista. Dependiendo de

la interfaz del modelo, una vista puede necesitar hacer múltiples llamadas para obtener todos los datos que necesita presentar. Solicitud de datos innecesarios al modelo golpea el rendimiento si las actualizaciones son frecuentes. Usar un caché de datos en la vista mejora el tiempo de respuesta.

– Inevitablemente se deben cambiar vista y controlador cuando se porte la aplicación. Todas las dependencias a la plataforma gráfica están encapsuladas en la vista y el controlador. Sin embargo, estos componentes también tienen código que es independiente de la plataforma.

Consecuencias

Cómo se implementa MVC en Java?

• View

• Controller

• Model

34

View

• AWT (Abstract Window Toolkit): Contiene todas las clases para crear interfaces de usuario y para pintar gráficas e imágenes. Es la base para las clases Swing. • Definido en el package java.awt

• SWING: Es un conjunto de librerías para crear interfaces graficas de usuario (GUI) independiente de la plataforma. • Definido en el package javax.swing

35

Jerarquía AWT

36 Tomada de: Java Programming Tutorial Programming Graphical User Interface (GUI)

Component 0..*

Component

setBounds

setSize

setLocation

setFont

setEnabled

setVisible

setForeground -- colour

setBackground -- colour

37

La clase Component define datos y métodos que son relevantes para TODOS los componentes

Container

• Contiene componentes

• Para que un componente se visualice se debe colocar en un Container

• Container define todos los datos y métodos necesarios para manejar grupos de componentes

38

add

getComponent

getMaximumSize

getMinimumSize

getPreferredSize

remove

removeAll

Jerarquía SWING

39 Tomada de: Java Programming Tutorial Programming Graphical User Interface (GUI)

Componentes de la Vista

• Containers : contenedores de componentes gráficos

– Frame (JFrame): Posee titulo y bordes.

–Panel (JPanel): provee un espacio de trabajo.

–Window (JWindow): ventana sin bordes y sin barra de menú.

40

JFrame

41

java.lang.Object java.awt.Component

java.awt.Container java.awt.Window

java.awt.Frame javax.swing.JFrame

Ejemplo JFrame package Presentacion;

import java.awt.BorderLayout;

import java.awt.EventQueue;

import javax.swing.JFrame;

import javax.swing.JPanel;

import javax.swing.border.EmptyBorder;

public class VentanaPrincipal extends JFrame {

private JPanel contentPane;

/**

* Launch the application.

*/

42

public static void main(String[] args) { EventQueue.invokeLater(new Runnable() { public void run() { try { VentanaPrincipal frame = new VentanaPrincipal(); frame.setVisible(true); } catch (Exception e) { e.printStackTrace(); } } }); } /** * Create the frame. */ public VentanaPrincipal() { setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setBounds(100, 100, 450, 300); contentPane = new JPanel(); contentPane.setBorder(new EmptyBorder(5, 5, 5, 5)); contentPane.setLayout(new BorderLayout(0, 0)); setContentPane(contentPane); } }

Controller

• Se encarga de recibir los eventos del usuario y delegar al modelo la lógica de ejecución.

• De acuerdo al resultado, invoca la vista necesaria para completar la solicitud.

43

Eventos en Java

• Todo componente de la GUI puede generar eventos – Acciones del usuario sobre el componente

– Temporizaciones

– Cambios de estado, etc.

• Modelo de Delegación – La responsabilidad de gestionar un evento que sucede en

un componente (Fuente) la tiene otro objeto (Oyente)

• Propagación de Eventos – El componente Fuente del evento invoca a un método del

objeto Oyente, pasándole como un argumento un objeto que almacena toda la información relativa al evento

44

Fuentes

45

Oyentes (Listeners) de Eventos

• Son objetos que implementan la interfaz correspondiente al tipo de evento a escuchar: – ActionListener – WindowListener – MouseListener – etc.

• Las clases que extienden estas interfaces tienen que implementar TODOS los métodos de la interfaz – ¿Qué pasa si sólo nos interesa uno de los eventos?

• Muchos métodos vacíos • Poca legibilidad • Solución: Adaptadores

46

• Pattern-Oriented Software Architecture: A System of Patterns, F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. John Wiley & Sons, 1996

Bibliografía