Post on 22-Feb-2016
description
4.- Introducción a 4.- Introducción a Patrones ArquitectónicosPatrones Arquitectónicos
Justo N. Hidalgo SanzJusto N. Hidalgo Sanz
DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Índice Qué es un patrón arquitectónico Algunos patrones:
Layers MVC Publisher-Subscriber
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Introducción Los patrones de diseño se aplican a problemas
concretos y reducidos en una parte de nuestro diagrama general.
Pero ¿cuál es el estilo general de nuestra aplicación? ¿Qué “tipos de columnas” y “frisos” vamos a utilizar?
Los patrones arquitectónicos responden a un nivel de abstracción más alto que los de diseño. Arquitectura: división de alto nivel del sistema en
diferentes partes. Otra definición: “decisiones que son difíciles de cambiar”
(Fowler). Puede -y generalmente hay- más de una arquitectura
en un solo sistema.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Biblias Aunque hay MUCHA bibliografía sobre
patrones arquitectónicos: POSA (Pattern-Oriented Software Architecture). El
primer volumen tiene gran cantidad de patrones de todo tipo, algunos de los cuáles son arquitectónicos.
Patterns of Enterprise Application Architecture. Dedicado explícitamente a p.p.a.a.
http://hillside.net/patterns
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Patrón Layers
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Definición Layers: estructura de aplicaciones como
descomposición en grupos de subtareas, donde cada subgrupo es un nivel de abstracción particular.
Ejemplo: protocolo OSI
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Contexto Un sistema que requiera descomposición.
Modificaciones en partes del código no deben afectar a otras.
Las interfaces han de ser estables -incluso estandarizadas-.
Partes del sistema deben ser intercambiables (p.e. acceso a bases de datos).
Las partes de más bajo nivel pueden servir de base para otras aplicaciones (p.e. módulo de comunicaciones, o de seguridad).
Cada componente ha de ser coherente: agrupación por responsabilidades similares.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (I) POSA utiliza una tarjeta CRC (Class-
Responsibility-Collaboration). Realmente, llamémosle Component-Responsibility-
Collaboration.
Componente:Capa J
Colaboradores:Capa J-1Responsabilidad
es:•Proveer servicios utilizados por capa J+1•Delegar subtareas a capa J-1
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (y II)
Componente 3.1 Componente 3.2 Componente 3.3
Componente 2.1 Componente 2.2 Componente 2.3
Componente 1.1 Componente 1.2 Componente 1.3
Capa 3
Capa 2
Capa 1
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Escenarios Escenario Top-Down Escenario Bottom-Up Escenario Parcial: la petición sólo viaja a
través de un subconjunto de capas (p.e. cachè).
Escenario mixto (top-down <=> bottom-up)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Implementación Iterativamente:
Definir el criterio de abstracción Determinar el número de niveles de abstracción Nombrar y asignar tareas Especificar los servicios (=> interfaces)
Estructurar cada capa individualmente Desacoplar capas adyacentes Crear una estrategia de manejo de errores
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Casos Stacks de comunicación (OSI, TCP/IP, …) Máquinas virtuales (Java Virtual Machine) APIs de desarrollo Sistemas de Información:
Presentación Lógica de aplicación Capa de acceso a repositorio Repositorio
Sistemas Operativos Middleware de comunicaciones:
Física, Red, Sockets, RPC/RMI, CORBA/J2EE/.NET, ...
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Beneficios Reutilización de capas Estandarización posible Las dependencias son siempre locales Capacidad de intercambio
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Posibles problemas Cambio de comportamiento => errores en
cascada Menores prestaciones Trabajo innecesario Dificultad en la decisión de granularidad de
capas
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejercicio Diseño e implementación de un sistema de
jugadas de baloncesto mediante el patrón Layers Implementad cada capa en un paquete diferente. Considerad cada capa como un conjunto de objetos
de una misma clase con su interfaz correspondiente. Implementad la solución en Java/C++ Modificad una capa (p.e. capa de jugadores) para
que se comporte de manera diferente: nueva clase, misma interfaz.
Pista: la capa superior es el Plan de Juego Maestro del equipo de baloncesto.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Patrón Model-View-Controller
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Definición MVC: división de una aplicación interactiva en
tres componentes: Modelo: funcionalidad de la aplicación + datos Vista: muestra de información al usuario Controlador: manejador de los datos de entrada
Vista + Controlador: interfaz de usuario Ejemplo: sistema de actualización de notas
(Observer + GUI)
Vista
Controlador
Vista Vista
Modelo
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Contexto Aplicaciones interactivas con una interfaz
HOMBRE-MÁQUINA flexible. Diferentes interfaces para una misma funcionalidad Diferentes “look and feel”, sistemas de ventanas,
etc. Una misma información mostrada de diferentes
maneras.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (I): modelo
Componente:Modelo
Colaboradores:•Vista
•ControladorResponsabilidades
•Core funcional de la aplicación•Registro de vistas dependientes y controladores•Notificación de cambios de datos a los componentes
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (II): vista
Componente:Vista
Colaboradores:•Modelo
•ControladorResponsabilidades
•Creación e inicialización del controlador•Muestra de información al usuario•Implementación del procedimiento de actualización•Obtención de datos del modelo
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (III): controlador
Componente:Controlador
Colaboradores:•Modelo•VistaResponsabilidades
•Aceptación de datos de entrada como eventos.•Traducción de eventos a peticiones de servicio para el modelo o peticiones de muestra para la vista.•Si es necesario, implementación del procedimiento de actualización.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (y IV)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Escenarios (I)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Escenarios (y II)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Casos Smalltalk MFC (Microsoft Foundation Library) J2EE (Front Controller) “Skins”
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Beneficios Vistas múltiples de un único modelo Vistas sincronizadas Vistas y controladores añadibles
dinámicamente Intercambio de “look and feel” Potencial de convertirse en “framework”
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Posibles problemas Complejidad Número excesivo de actualizaciones:
El modelo debe “pasar” de algunas actualizaciones innecesarias.
Desacoplamiento complicado entre vista y controlador.
Acomplamiento entre modelo y los otros dos elementos Vista y controlador realizan llamadas directas al
modelo. Utilización del patrón Command.
Prestaciones en acceso a datos desde la vista
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejercicio Diseño e implementación de una interfaz H-M
para acceso a notas de una asignatura. Cada alumno tiene diferentes interfaces de usuario –
web, móvil, e-mail, …- Es parecido al ejemplo del Observer visto en clase,
pero utilizando el MVC para las peticiones de los alumnos:
Vista de nota Vista de nota media Vista de nota mínima Vista de nota máxima
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Patrón Publisher-Subscriber
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Definición Publisher-Subscriber: mantenimiento del
estado de componentes cooperantes, de manera sincronizada
Ejemplo: subscripción a foro
Publicador
Subscriptor
Subscriptor
Subscriptor
Canal deEventos
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Contexto Un dato (o un conjunto de ellos) cambia en un
lugar, pero otros componentes dependen de ese cambio. Uno o más componentes han de ser notificados del
cambio El número e identidades de los componentes
dependientes no se conoce a priori, o puede cambiar.
“Polling” explícito no es posible o recomendable. El publicador y los subscriptores no deben estar
acoplados en un mecanismo de propagación de cambios.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (I): push
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (II): pull
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (III): IDL del CORBA Event Service
module CosEventComm {
exception Disconnected{};
interface PushConsumer {
void push (in any data)
raises(Disconnected);
void disconnect_push_consumer();
};
interface PushSupplier {
void disconnect_push_supplier();
};
interface PullSupplier {
any pull () raises(Disconnected);
any try_pull (out boolean has_event)
raises(Disconnected);
void disconnect_pull_supplier();
};
interface PullConsumer {
void disconnect_pull_consumer();
};
};
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (IV): canal de eventos (push)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (V): canal de eventos (pull)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (VI): canal de eventos (push-pull)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Estructura (y VII): IDL del CORBA Event Service con Event Channel
#include “CosEventComm.idl” module CosEventChannelAdmin { exception AlreadyConnected {}; exception TypeError {}; interface ProxyPushConsumer: CosEventComm::PushConsumer { void connect_push_supplier( in CosEventComm::PushSupplier push_supplier) raises(AlreadyConnected); }; interface ProxyPullSupplier:
CosEventComm::PullSupplier { void connect_pull_consumer( in CosEventComm::PullConsumer pull_consumer) raises(AlreadyConnected); }; interface ProxyPullConsumer:
CosEventComm::PullConsumer { void connect_pull_supplier( in CosEventComm::PullSupplier pull_supplier) raises(AlreadyConnected,TypeError); };
interface ProxyPushSupplier: CosEventComm::PushSupplier { void connect_push_consumer( in CosEventComm::PushConsumer push_consumer) raises(AlreadyConnected, TypeError); }; interface ConsumerAdmin { ProxyPushSupplier obtain_push_supplier(); ProxyPullSupplier obtain_pull_supplier(); }; interface SupplierAdmin { ProxyPushConsumer obtain_push_consumer(); ProxyPullConsumer obtain_pull_consumer(); }; interface EventChannel { ConsumerAdmin for_consumers(); SupplierAdmin for_suppliers(); void destroy(); };};
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Servicio de Notificaciones CORBA
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Casos CORBA Event Service (información anterior):
Event Service Specification v1.1 (March 2001) CORBA Notification Service
Notification Service Specification v1.0.1 (August 2002)
Sistemas MOM (Message-Oriented Middleware) IBM MQSeries JMS (Java Messaging Service) …
Gateways SMS
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejercicio Diseño e implementación de un sistema de
publicación/subscripción de noticias del Rayo Vallecano. Los subscriptores se pueden subscribir cuando
deseen. Las noticias se generan manualmente desde una
clase que interactúa con el Publicador.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Bibliografía Pattern-Oriented Software Architecture. Vol.
1. Buschmann, F. et al. Ed. Wiley. ISBN: 0-471-95869-7
Patterns of Enterprise Application Architecture. Fowler, M. Ed. Addison-Wesley. ISBN: 9-780321-127426
The Unified Software Development Process. I. Jacobson, G. Booch, J. Rumbaugh. Ed. Addison-Wesley. ISBN: 0-201-57169-2
www.omg.org (Publish-Subscribe)