4.- Introducci

1
4.- Introducción a Patrones Arquitectónicos Justo
N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA
INFORMÁTICA
2
Índice

• Qué es un patrón arquitectónico
• Algunos patrones
• Layers
• MVC
• Publisher-Subscriber

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

4
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

5
Patrón Layers
6
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

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

8
Estructura (I)

• POSA utiliza una tarjeta CRC (Class-Responsibility
  -Collaboration).
• Realmente, llamémosle Component-Responsibility-Col
  laboration.

9
Estructura (y II)
Capa 3
Componente 3.1
Componente 3.2
Componente 3.3
Capa 2
Componente 2.1
Componente 2.2
Componente 2.3
Capa 1
Componente 1.1
Componente 1.2
Componente 1.3
10
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 ltgt bottom-up)

11
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 (gt interfaces)
• Estructurar cada capa individualmente
• Desacoplar capas adyacentes
• Crear una estrategia de manejo de errores

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

13
Beneficios

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

14
Posibles problemas

• Cambio de comportamiento gt errores en cascada
• Menores prestaciones
• Trabajo innecesario
• Dificultad en la decisión de granularidad de capas

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

16
Patrón Model-View-Controller
17
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)

Modelo
Controlador
Vista
Vista
Vista
18
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.

19
Estructura (I) modelo
20
Estructura (II) vista
21
Estructura (III) controlador
22
Estructura (y IV)
23
Escenarios (I)
24
Escenarios (y II)
25
Casos

• Smalltalk
• MFC (Microsoft Foundation Library)
• J2EE (Front Controller)
• Skins

26
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

27
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

28
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

29
Patrón Publisher-Subscriber
30
Definición

• Publisher-Subscriber mantenimiento del estado de
  componentes cooperantes, de manera sincronizada
• Ejemplo subscripción a foro

Subscriptor
Publicador
Canal de Eventos
Subscriptor
Subscriptor
31
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.

32
Estructura (I) push
33
Estructura (II) pull
34
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()
35
Estructura (IV) canal de eventos (push)
36
Estructura (V) canal de eventos (pull)
37
Estructura (VI) canal de eventos (push-pull)
38
Estructura (y VII) IDL del CORBA Event Service
con Event Channel

• interface ProxyPushSupplier
• CosEventCommPushSupplier
• void connect_push_consumer(
• in CosEventCommPushConsumer
  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()

• include CosEventComm.idl
• module CosEventChannelAdmin
• exception AlreadyConnected
• exception TypeError
• interface ProxyPushConsumer
• CosEventCommPushConsumer
• void connect_push_supplier(
• in CosEventCommPushSupplier
  push_supplier)
• raises(AlreadyConnected)
• interface ProxyPullSupplier
  CosEventCommPullSupplier
• void connect_pull_consumer(
• in CosEventCommPullConsumer
  pull_consumer)
• raises(AlreadyConnected)
• interface ProxyPullConsumer
  CosEventCommPullConsumer
• void connect_pull_supplier(
• in CosEventCommPullSupplier
  pull_supplier)
• raises(AlreadyConnected,Type
  Error)

39
Servicio de Notificaciones CORBA
40
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

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

42
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)