Components & Connectors Viewtype. Estilos

Transcripción

1 Components & Connectors Viewtype Estilos 1

2 Estilos Especializan el C&C viewtype introduciendo tipos de componente y conector a los cuales pertenecerán las instancias del modelo Especifican patrones de interacción que prescriben como los componentes interactúan en runtime Un componente puede pertenecer a más de un estilo ej. Repository & cliente server styles Estilos 2

3 Estilos Estos patrones de interacción los agrupamos a lo largo de 6 estilos que presentaremos a continuación client-server shared-data pipes & filters publish-subscribe peer-to-peer communicating-processes Estilos 3

4 Client-Server Style En el estilo Client-Server el patrón de interacción se basa en componentes clientes que requieren servicios de componentes server La comunicación es establecida e iniciada por los componentes cliente El requerimiento de un servicio es de un cliente vinculado con la provisión de ese servicio por un server Client-Server Style 4

5 Elementos Los Servers proveen un conjunto de servicios a través de una o más interfaces Los Clientes consumen cero o más servicios de los servers El vínculo se establece entre el request role del conector y el puerto del cliente, y el reply role y el puerto del server Existe uno o más servers en los sistemas dentro de este estilo Client-Server Style 5

6 Especialización Como posibles topologías podemos agrupar de acuerdo a la forma en que los clients y servers se comunican estableciendo una jerarquía Los sistemas n-tier establecen como n-1 niveles de comunicación entre servers existen en la jerarquía, siendo el estímulo inicial generado por el cliente Se puede establecer limitaciones en la cantidad de clientes que se conectan a un server Client-Server Style 6

7 Ejemplo Client / Server Component Storage Component Request / Reply Connector Binding DB Connector Distribution Bus Connector Service Provided Interface Service Request Interface App Server Web based UI Web App Server Business App Server Windows Form based UI Business App Server Client-Server Style 7

8 Resumen & Comentarios Computación asimétrica: Es iniciada por el cliente y la computación ocurre en el server Los clientes deben conocer a los servers, pero los servers reaccionan a las peticiones que reciben de clientes potencialmente desconocidos La invocación es generalmente síncrona pero pueden existir casos de comunicación asíncrona donde a través de eventos se notifica al cliente la resolución del servicio Client-Server Style 8

9 Resumen & Comentarios Desacopla a los clients de los servicios que requieren Facilita el entendimiento del sistema a través de agrupar servicios comunes Facilita la interoperabilidad con sistemas legacy a partir de la cohesión de servicios comunes La asignación de servicios en diferentes tiers permite mejor escalabilidad y atención de los atributos de calidad Client-Server Style 9

10 Resumen & Comentarios Permite analizar la vinculación entre los servicios requeridos por el cliente y los servers que resuelven dichos servicios Permite analizar relaciones de dependencia. Por ejemplo que sucede ante la caída de un server, o si la información provista a los clientes está restringida por los servers Client-Server Style 10

11 Resumen & Comentarios Se relaciona cercanamente con el estilo layered de Module Viewtype especialmente cuando vinculamos layers con tiers. En el estilo layered la relación entre los layers es se permite usar, mientras que en n-tier se extiende esto por establecer el mecanismo de interacción entre los tiers que alojan diferentes layers Presenta el mismo esquema invocaciónresolución- respuesta que el estilo peer-topeer solo que aquí la computación es asimétrica Client-Server Style 11

12 Shared Data Style El patrón de interacción está dominado por el intercambio de datos persistentes Los datos tienen múltiples clientes y existe al menos un repositorio compartido para retener los datos persistentes Shared Data Style 12

13 Elementos Los componentes son almacenamientos de datos compartidos y data accessors Los conectores son accesos de lectura y escritura que vinculan data accessors y almacenamiento El modelo de computación generalmente se centra en data accessors que realizan cálculos que requieren datos de los almacenamientos y que a su vez producen resultados que son escritos en los almacenamientos Shared Data Style 13

14 Elementos Especialización Si el consumidor de los datos tiene la responsabilidad de extraer los datos, la especialización del estilo se denomina repositorio Si el almacenamiento tiene como responsabilidad notificar a los consumidores que un nuevo dato de interés fue incorporado o alterado, la especialización del estilo se denomina blackboard Shared Data Style 14

15 Servicios Acceso compartido a datos. Soporte para datos persistentes. Administran acceso concurrente a datos. Tolerancia a fallas. Control de Acceso. Distribución. Caching de datos. Shared Data Style 15

16 Especialización - Blackboard style Los almacenamientos compartidos notifican a los data accessors cuando algún dato de interés es actualizado Diferentes data accessors son invocados con diferente prioridad, y su activación dispara a su vez nuevas actualizaciones que generan nuevas activaciones Los data accessors se conocen como knowledge sources. Los almacenamientos compartidos como Blackboard Shared Data Style 16

17

18 Especialización - Repository Los responsables por obtener los datos son los data accessors Dada la posibilidad de que las BD actualmente tengan mecanismos de triggering este modelo no se presenta en forma pura Shared Data Style 18

19 Resumen & Comentarios Adecuados cuando hay requerimientos de persistencia Adecuados cuando hay requerimientos de compartir datos Desacopla consumidores de datos de los productores Shared Data Style 19

20 Resumen & Comentarios Adecuados para analizar performance, seguridad, privacidad, confiabilidad, capacidad Es central el análisis de cómo se vincula la computación con los datos El estilo client-server se relaciona fuertemente con este estilo en arquitecturas n-tier El estilo publish-subscribe es similar pero carece de persistencia en los datos Shared Data Style 20

21 Pipes & Filters Style El patrón de interacción se caracteriza por sucesivas transformaciones de datos Los datos arriban a un filtro, son transformados y luego transferidos a través de un pipe a un segundo filtro Pipes & Filters Style 21

22 Pipes & Filters Style - Elementos Contempla Un único tipo de conector: the pipe Un único tipo de componente: the filter Los filtros reciben datos a través de uno o más pipes, transforman los datos, y los transmiten a través de uno o mas pipes Los pipes son conectores binarios que toman datos de un puerto de salida de un filtro y lo transmiten a un puerto de entrada de otro filtro Pipes & Filters Style 22

23 Pipes & Filters Style - Elementos Los pipes son unidireccionales Preservan orden Buffering de mensajes No transforman los datos Los filtros solo interactúan a través de pipes Dado el buffering de los pipes, los filtros pueden actuar asincrónicamente, concurrentemente o independientemente Pipes & Filters Style 23

24 Pipes & Filters Style - Elementos El filter requiere conocer la identidad de sus antecesores y sucesores La computación puede ser tratada como la composición funcional de los filtros Restricciones en la configuración Los pipes conectan puertos de salida con puertos de entrada Pipeline: Especialización que indica que la configuración es lineal Acyclic: Especialización que indica que no debe haber ciclos en la configuración Pipes & Filters Style 24

25 Ejemplo Filtro Puerto de salida Pipe Binding Puerto de entrada Splitter Grep Merge Merge&Sort Sort Pipes & Filters Style 25

26 Resumen & Comentarios Fuertemente orientados a transformación de datos Deseamos que las transformaciones sucesivas estén desacopladas El modelo arquitectónico resultante es tremendamente algorítmico La relación con la vista de módulos es bastante directa por este motivo Pipes & Filters Style 26

27 Publish-Subscribe Style El patrón de interacción se centra en la reacción de componentes ante la anunciación de eventos Los componentes se subscriben a un conjunto de eventos, y la infraestructura asegura que cualquier evento publicado alcance a todos los subscriptores Publish-Subscribe Style 27

28 Elementos El conector es un event-bus El conector desacopla productores y consumidores de eventos Mensajería asíncrona ocurre de esta manera centrada en el bus de eventos Publish-Subscribe Style 28

29 Especialización Invocación implícita Eventos asociados con procesos del componente que subscribe La infraestructura es responsable que los procesos ocurran ante la aparición de un evento Ruteo de los eventos hasta los componentes El componente es responsable de saber qué hacer ante cada evento al que subscribe Posibilidad de que convivan componentes heterogéneos Publish-Subscribe Style 29

30 Ejemplo Publicador Publicador 1 Port: Port: Publisher Publisher 1 1 Port: Port: Suscriber Suscriber 1 1 Suscriptor Suscriptor 1 Publicador Publicador i i Port: Port: Publisher Publisher i i E/H E/H Port: Port: Suscriber Suscriber j j Suscriptor Suscriptor j j Publicador Publicador N Port: Port: Publisher Publisher N N Port: Port: Suscriber Suscriber M M Suscriptor Suscriptor M Publish-Subscribe Style 30

31 Resumen & Comentarios Útil para relacionar un número no predeterminado de componentes en forma asíncrona Posibilidad de agregar dinámicamente nuevos componentes sin impacto en los atributos de calidad del sistema Componentes desacoplados Publish-Subscribe Style 31

32 Resumen & Comentarios Es similar a shared-data pero sin persistencia Puede considerarse un refinamiento del estilo communicating-processes cuando los componentes tienen diferentes threads de control Publish-Subscribe Style 32

33 Peer-to to-peer Style El patrón de interacción en este estilo se basa en componentes intercambiando servicios como pares Los mecanismos de interacción son un tipo de request/reply simétricos En principio cualquier componente puede conectarse con cualquier otro componentes para requerir un servicio Peer-to to-peer Style 33

34 Elementos Los componentes son peers Los conectores son del tipo invoquesprocedure La computación puede ser iniciada por cualquiera de las partes Los peers tienen interfaces que describen los servicios que proveen y los servicios que requieren de sus pares Peer-to to-peer Style 34

35 Elementos Los peers proveen interfaces y encapsulan estado Es necesario declarar entre las propiedades los protocolos de interacción de los conectores y las propiedades orientadas a performance de los peers Peer-to to-peer Style 35

36 Resumen & Comentarios Divide la aplicación por áreas de colaboración Los peers pueden cumplir el role de cliente y server Facilitan la distribución de carga gracias a la granularidad de los componentes Facilitan la interoperabilidad e integración futura gracias a la mayor granularidad de estado y distribución de la computación Service Oriented Applications son un buen ejemplo de estos sistemas Peer-to to-peer Style 36

37 Communicating-Processes Style El patrón de interacción se caracteriza por un conjunto de procesos concurrentes como componentes que interactúan a través de diferentes mecanismos de interacción La interacción puede responder a necesidades de sincronización, pasaje de mensajes, intercambio de datos, stop/start Son necesarios en todo sistema distribuido Communicating-Processes Style 37

38 Elementos Los componentes son unidades concurrentes que ejecutan en forma paralela con otras unidades Las unidades son una abstracción de elementos de software más complejo Los conectores identifican el mecanismo de interacción entre las unidades ejecutores Las interacciones en general se distinguen por control o pasaje de datos Communicating-Processes Style 38

39 Elementos Es necesario identificar si las unidades ejecutan e interrumpen voluntariamente su ejecución, o si pueden ser interrumpidas por otras unidades (preemptability) Las unidades deben tener asociada su prioridad, la cual es necesaria para schedulability Es posible asociar requerimientos de tiempo real sobre las unidades Capacidad de buffering si los datos recibidos no pueden ser inmediatamente procesados Communicating-Processes Style 39

40 Resumen & Comentarios Es usado para entender que porciones del sistema se ejecutan en paralelo, para mapear componentes con procesos, y entender los threads de proceso presentes y su sincronización Podemos analizar performance y confiabilidad desde este estilo Communicating-Processes Style 40