Objetivos
•
Estudiar los principales patrones para diseño de interfaces•
Estudiar los principales patrones para diseño de componentes•
Estudiar los principales estilos arquitectónicos utilizados en arquitecturas de componentes•
Componentes - Interfaces•
Responsabilidades del componente•
Servicios ofrecidos•
Protocolos utilizados / requeridos•
Retos•
Responsabilidades del componente•
Especificación de contratos•
Atributos de calidad•
Expresividad y simplicidad•
Bajo acoplamiento y estabilidad•
Distribución de componentes•
HeterogeneidadInterfaces
•
Patrones•
Explicit Interfase•
Extension Interfase•
Introspective Interface•
Dynamic Invocation•
Business Delegate•
Proxy•
Facade•
Combined Method•
Iterator•
Enumeration Method•
Batch MethodInterfaces
Interfaces
•
Explicit Interface Pattern•
Separa el uso del componente de los detalles de implementación•
Los clientes depende solo del contrato•
Los clientes no deben conocer•
Diseño interno•
Detalles de implementaciónInterfaces
•
Extension Interface Pattern•
Permite exponer varias interfaces por parte de un componente•
De forma estable para los clientes ante cambios y evolución en el componenteInterfaces
•
Instrospective Interface Pattern•
Ofrece una interfaz suplementaria•
Permite al cliente conocer el interior del componenteInterfases
•
Dynamic Invocation Pattern•
Ofrece una interfaz sumplementaria•
Permite a los clientes invocar métodos del componentes de forma dinámicaInterfaces
•
Business Delegate Pattern•
Hace transparente a los clientes de un componente•
Localización del componente•
Lookup•
Balanceo de cargaInterfaces
•
Proxy•
Los clientes de un componente se comunican con un emisario en lugar del componente mismo•
SeguridadInterfaces
•
Facade•
Un punto único de acceso para el clienteInterfaces
•
Combined Method•
El cliente debe realizar la invocación demétodos en un orden particular muchas veces
•
No facilita su utilizaciónInterfaces
•
Iterator•
Se requiere visitar elementos en un componente agregado•
El cliente no quiere depender de la estructura internaInterfaces
•
Enumeration Method•
Se requiere iterar sobre elementos de un componente agregado•
Se quiere invocar una acción en cada elementoInterfaces
•
Batch Method•
Se requiere visitar un subconjunto de componentes•
Acceder a la colección es costoso•
Remoto / Concurrente•
Se define un único método en batchComponentes
•
Niveles de granularidad y composición•
Alta•
Dificulta entendimiento, evolución y mantenimiento•
Baja•
Se requiere mayor integración y “pegante” entre los componentes•
Patrones•
Encapsulated Implementation•
Whole-part•
Composite•
Master-Slave•
Half Object•
Replicated ComponentComponentes
Componentes
•
Encapsulated Implementation•
Esconde completamente los detalles de implementación•
La implementación encapsulada puede evolucionarComponents
•
Whole-Part•
Un componente agrupa mucha funcionalidad•
No es práctico / apropiado construir un solo componente•
Se particiona el componente en un elemento único que encapsula y orquesta partesindependientes
•
Este único elemento define las interfaces de acceso al componenteComponentes
•
Composite•
Composición de partes recursiva•
Objetos que soportan la misma interfaz•
Se desea utilizar toda la jerarquía como si fuera una sola entidad•
Se utiliza un componente interfaz con la funcionalidad común a todas las partesComponentes
•
Master-Slave•
Requerimientos de calidad altos•
Imposibles de cumplir en un solo hilo de ejecución•
Se subdivide el componente en tareas internas, ejecutadas en paraleloComponentes
•
Half-Object plus Protocol•
Se requiere utilizar componentes que residen en espacios de direcciones diferentes•
Alto costo en transporte y latencia•
Se divide el componente en varios “half object” en cada sitio local, solo con la lógica y datosComponentes
•
Replicated Component Group•
Se requiere garantiza alta disponibilidad de un componente•
Se provee un grupo de componentes•
Se instancian en diferentes nodos de ejecución•
Un requerimiento es enviado a todo el grupoEstilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Estilos
Conectores
•
Realizan transferencia de control y datos entre componentes•
Proveen servicios•
Persistencia•
Invocación•
Mensajería•
TransaccionalidadConectores
•
Roles Principales•
Comunicación•
Coordinación•
Conversión•
FacilitadoresConectores
•
Tipos de Conectores • Procedure Call • Event • Data access • Linkage • Stream • Arbitrator • Adaptor • DistributorConectores
•
Procedure Call Connectors•
Modela el flujo de control entre componentes (Coordinador)Conectores
•
Event Connectors•
Coordinan el flujo de control•
Basado en la ocurrencia de un evento y la generación de mensajesConectores
•
Data Access Connectors•
Permite a los componentes acceder información que reside en uncomponente de almacenamiento
•
Puede almacenar datos de manera persistente o temporalConectores
•
Linkage Connectors•
Facilitan la creación de canales de comunicación y coordinación•
Utilizados por conectores de mas alto nivelConectores
•
Stream Connectors•
Utilizados para transmitir grandes cantidades de datos entre procesos autónomos•
Utilizados con otros conectores para acceso a BD y archivosConectores
•
Arbitrator Connectors•
Ayudan en situaciones donde no se sabe el estado de los componentes•
Ejemplo:Sincronización y concurrencia•
Ayudan en la negociación de niveles de servicioConectores
•
Adaptor Connectors•
Proveen facilidades para soportar interacción entre componentes•
No diseñados para interoperarConectores
•
Distributor Connectors•
Realizan la identificación e interacción de caminos y rutas de comunicación ycoordinación entre componentes
Plan de Trabajo
•
Lo que sigue•
Documento Arquitectura•
Escenarios Operacionales - Casos Uso•
Punto de Vista Funcional•
Diagrama de Componentes•
Identificación / Documentación Servicios•
Preparación para el desarrollo•
Tutoriales Spring/OSGIReferencias
•
Software Architecture: Foundations, Theory and Practice. Richard Taylor, NenadMedvidovic, and Eric Dashofy
