4.- Introducción a Patrones Arquitectónicos Justo N. Hidalgo Sanz

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


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.


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


Patrón Layers


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


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.


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


Estructura (y II)

Componente 3.1 Componente 3.2 Componente 3.3



Capa 3

Capa 2

Capa 1


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)


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


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, ...


Beneficios Reutilización de capas Estandarización posible Las dependencias son siempre locales Capacidad de intercambio


Posibles problemas Cambio de comportamiento => errores en

cascada Menores prestaciones Trabajo innecesario Dificultad en la decisión de granularidad de

capas


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.


Patrón Model-View-Controller


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


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.


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


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


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.


Estructura (y IV)


Escenarios (I)


Escenarios (y II)


Casos Smalltalk MFC (Microsoft Foundation Library) J2EE (Front Controller) “Skins”


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”


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


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


Patrón Publisher-Subscriber


Definición Publisher-Subscriber: mantenimiento del

estado de componentes cooperantes, de manera sincronizada

Ejemplo: subscripción a foro

Publicador

Subscriptor

Subscriptor

Subscriptor

Canal deEventos


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.


Estructura (I): push


Estructura (II): pull


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();

};

};


Estructura (IV): canal de eventos (push)


Estructura (V): canal de eventos (pull)


Estructura (VI): canal de eventos (push-pull)


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(); };};


Servicio de Notificaciones CORBA


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


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.


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)

http://www.omg.org/

4.- Introducción a Patrones Arquitectónicos Justo N. Hidalgo Sanz

Documents

Transcript of 4.- Introducción a Patrones Arquitectónicos Justo N. Hidalgo Sanz