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

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. Componente: Capa J Colaboradores: Capa J-1 • Responsabilidades: • Proveer servicios utilizados por capa J+1 • Delegar subtareas a capa J-1 Estructura (I) • POSA utiliza una tarjeta CRC (Class-Responsibility-Collaboration). • Realmente, llamémosle Component-Responsibility-Collaboration.

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 <=> 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 (=> 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 => 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. Componente: Modelo • Colaboradores: • Vista • Controlador • Responsabilidades • Core funcional de la aplicación • Registro de vistas dependientes y controladores • Notificación de cambios de datos a los componentes Estructura (I): modelo

20. Componente: Vista • Colaboradores: • Modelo • Controlador • Responsabilidades • 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 (II): vista

21. Componente: Controlador • Colaboradores: • Modelo • Vista • Responsabilidades • 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 (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: 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(); }; }; #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); };

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)