Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Primer Cuatrimestre de 2009 Estilos C&C Viewtype / Module Viewtype Buenos Aires, 6 de Abril de 2009er

2 Estilos COMPONENTS & CONNECTORS (C&C) 2

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

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

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

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

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

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

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

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

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

12 Resumen & Comentarios Se relaciona cercanamente con el estilo layered de Module Viewtype especialmente cuando vinculamos layers con tiers. Presenta el mismo esquema invocaciónresolución- respuesta que el estilo peer-topeer solo que aquí la computación es asimétrica 12

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

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

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

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

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

18

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

20 Resumen & Comentarios Adecuados cuando hay requerimientos de persistencia Adecuados cuando hay requerimientos de compartir datos Desacopla consumidores de datos de los productores 20

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

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

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

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

25 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 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 27

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 28

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 29

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 30

30 Ejemplo Publicador 1 Port: Publisher 1 Port: Suscriber 1 Suscriptor 1 Publicador i Port: Publisher i E/H Port: Suscriber j Suscriptor j Publicador N Port: Publisher N Port: Suscriber M Suscriptor M 31

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 32

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 33

33 Peer-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 34

34 Elementos Los componentes son peers Los conectores son del tipo invoques-procedure 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 35

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 36

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 37 Service Oriented Applications son un buen ejemplo de estos sistemas

37 Estilos MODULE VIEWTYPE 38

38 Estilos Cada estilo restringe y/o especializa elementos, relaciones y propiedades del viewtype básico. Se presentarán a continuación cuatro estilos Descomposición Usos Capas

39 Descomposición Este estilo está focalizado en la relación es parte de. Está relacionado con técnicas de divide y conquistarás. Representa la descomposición del código en sistemas, subsistemas, etc. Esta descomposición permite mostrar las responsabilidades del sistema y cómo éstas son fragmentadas entre distintos módulos y a su vez sub-módulos.

40 Criterios de descomposición Basado en el propósito de la descomposición. Alcanzar ciertos atributos de calidad Mantenibilidad vía information hiding Performance vía separar funcionalidades Comprar versus reutilizar versus construir Algunos módulos pueden reutilizarse de proyectos anteriores, otros pueden comprarse Líneas de producción (variantes) Cuando se implementa un producto de una familia de productos, es esencial distinguir entre módulos comunes a los distintos productos y aquellos que varían según el producto.

41 Elementos & Relaciones Elementos Como en el viewtype en general, el elemento de este estilo es el módulo. Un módulo que compone (agrega) a otros módulos suele llamarse subsistema el cual en general: Relaciones Es responsable de un conjunto de funcionalidad cohesiva de la funcional total del sistema. Puede ser ejecutado independientemente del resto del sistema. Puede ser desarrollado y desplegado independientemente del resto. La relación de descomposición es una especialización de la relación es parte de.

42 Propiedades Los elementos poseen las mismas propiedades del viewtype en general. La relación de descomposición posee la propiedad de visibilidad, que define si un submódulo es sólo visible por el módulo al cual agrega o bien, también por cualquier otro módulo. Topología No se permiten ciclos. Un módulo no puede ser parte de más de otro módulo en una vista.

43 Utilidad Facilita el aprendizaje y la comunicación de un sistema. Este estilo, suele servir como input para la vista de asignación de trabajo, la cual mapea partes del software a equipos de trabajo responsables de su desarrollo, testing, etc. Puede contribuir a realizar cierto análisis de impacto de cambios. (!) Dado que no todas las dependencias son visibles en esta vista, el análisis de impacto no puede ser total.

44 Descomposición: notación

45 Descomposición: notación UML A A B C D B C D 46

46 Relación con otros estilos Es posible, y muchas veces deseable, realizar un mapeo entre la vista de descomposición y la vista de C&C. Un mismo módulo puede implementar varios componentes y/o conectores. Un componente podría requerir varios módulos para su implementación. El mapeo puede ser muy simple o muy complejo. Este estilo está muy relacionado con la vista de asignación de trabajo.

48 Usos Este estilo está focalizado en la relación depende de (especializada en la relación usa) Este estilo informa al desarrollador qué otros módulos deben existir para que cierto módulo funcione correctamente.

49 Elementos y Relaciones Elementos Como en el viewtype en general, el elemento de este estilo es el módulo. Relaciones La relación de usa es una especialización de la relación depende de. Esta vista hace explícito como una funcionalidad se mapea con una implementación, mostrando la relaciones existentes entre las distintas partes de código que finalmente la implementan.

50 Sobre la relación usa Una unidad de software P1 usa a otra unidad P2, si la correctitud de P1 depende de la correctitud de P2. Usar sin invocar: P1 asume que P2 deja un dispositivo listo para ser usado. P1 espera que P2 deje un resultado escrito en memoria compartida. P1 puede ser un proceso dormido hasta que P2 genera una señal determinada. Invocar sin usar P0 invoca a P1, el cual depende de su resultado. (P0 usa P1.) Supongamos que P0 invoca a P1 incorrectamente. Parte de la especificación de P1 es que en caso de error, se invoque a un programa pasado como argumento. Una vez que P1 invoca a este programa, ha satisfecho si especificación. En este caso P1 invoca a P2 pero no existe relacion usa.

51 Sobre la relación usa Diferencia con otras especializaciones de la relación depende de: La relación incluye trata de dependencias de compilación, no suele tener influencia sobre la correctitud en tiempo de ejecución. La relación hereda de tampoco representa una dependencia presente en tiempo de ejecución.

52 Usos: utilidad Planificación de desarrollos incrementales. Planificación de planes de test. Estimación de impacto ante posible cambios.

53 Notación Informalmente, la relación de uso puede representarse a través de una matriz. Una marca en la posición (x,y) representa que el módulo X usa al módulo y.

54 Notación

55 Relación con otros estilos Usualmente este estilo se complementa muy bien con el estilo de capas, utilizando la relación puede usar.

57 Capas Organiza el código en módulos disjuntos llamados capas. Las distintas capas interactúan respetando una relación de orden: Las capas superiores están autorizadas a usar las capas inferiores. Es recomendable que cada capa use sólo a la inmediatamente inferior. Clave para soportar portabilidad: El código es descompuesto en máquinas virtuales. Cada capa provee un conjunto de servicios (cohesivos entre sí).

58 Síntesis de Capas desde código Las capas no pueden ser derivadas examinando el código. Examinando el código se puede inferir la relación usa, no la relación puede usar

59 Elementos & Relaciones Elementos El elemento de este estilo es la capa (layer). Una capa es una colección cohesiva de módulos, cada uno de los cuales puede ser invocado o accedido. Cada capa puede representar una máquina virtual con una interface para acceder a sus servicios. Relaciones La relación puede usar es una especialización de la relación depende de.

60 Propiedades Las capas poseen las siguientes propiedades o atributos Nombre Contenido Lista de los módulos incluidos en la capa. Qué software puede usar la capa La capa puede usar sólo la capa inmediatamente inferior? O cualquier capa inferior? Los módulos dentro de la capa, pueden usarse entre sí? Cohesión El conjunto de servicios que provee la capa, quizás sean de utilidad en otro contexto.

61 Utilidad Promueve portabilidad y mantenibilidad. Aplicación del principio de Information Hiding. Un cambio en una capa inferior puede ser ocultado detrás de su interface, sin impactar a las capas superiores. La interface de una capa es más que una simple API: Existen supuestos que otra capa puede considerar (i.e. cuestiones de performance). No introduce un overhead adicional en tiempo de ejecución. Las capas forman parte del rol del arquitecto al diseñar el blueprint para la construcción del software.

62 Notación

63 Relación con otros estilos Descomposición Una tendencia es presentar la vista de capas idéntica a la vista de descomposición. Una capa no es necesariamente un módulo, una capa posee uno o más módulos. 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 Usos La vista de capas expresa la relación puede usar, la cual está ligada con la relación usa.

64 Estilos de Module Viewtype RESUMEN 65

65 Descomposición El estilo descomposición muestra como las responsabilidades son distribuidas a través de los módulos. Sirve para comunicar la arquitectura a nuevos participantes y para realizar análisis de impacto de posibles cambios.

66 Usos El estilo de usos muestra cómo los módulos dependen entre sí. Contribuye a alcanzar un desarrollo incremental y a obtener rápidamente subconjuntos funcionales del sistema.

67 Capas El estilo en capas divide al sistema en un conjunto de máquinas virtuales, relacionadas por la relación puede usar Contribuye a lograr portabilidad y bajo impacto ante cambios.

68 Estilos ALLOCATION VIEWTYPE 69

69 Asignación Elementos Arquitectónicos Elementos Entorno Construcción Module Viewtype Implementation Configuración Components & Connectors Viewtype Work assignment Equipo de Trabajo Ejecución Deployment Infraestructura

70 Despliegue Elementos de un estilo del viewtype C&C son asignados a elementos de la infraestructura. Condicionada por requerimientos de cada elemento arquitectónico y el soporte en el elemento de la infraestructura. A través de la traza con la arquitectura y la táctica aplicada se puede analizar cada concern.

71 Elementos Elementos de software Suelen corresponderse con procesos del C&C viewtype. Elementos del entorno Unidades físicas que almacenan, transmiten o computan información. CPUs, canales de comunicación, dispositivos de memoria, de almacenamiento, dispositivos de red, etc.

72 Relaciones Generalmente es Allocated to En caso de ser una relación dinámica Migrates to va de un proceso en un procesador, hacia el mismo elemento de software en otro procesador. Copy migrates to es similar a la relación migrates to con la diferencia que en lugar de mover el proceso, se envía una copia del mismo. Execution migrates to una copia de un proceso existe en más de un procesador, pero sólo una estará activa.

73 Propiedades Las propiedades relevantes (tanto de elementos de entorno como de software) son aquellas que afectan la asignación del software a las unidades físicas. Cómo un elemento del entorno satisface un requerimiento de un elemento de software es determinado por las propiedades de los dos.

74 Ejemplo: propiedades de unidades físicas CPU Número de procesadores, memoria, velocidad del bus, velocidad de procesamiento de instrucciones, etc. Memoria Tamaño, velocidad, latencia, etc. Disco (unidad de almacenamiento) Capacidad, velocidad de acceso, etc. Canal de comunicaciones Ancho de banda, etc. Servidores Tolerancia a fallas, servicios de detección preventiva de fallas.

75 Ejemplos de propiedades del software Utilización de recursos Cantidad de instrucciones, requerimientos de memoria, de espacio en disco, etc. Requerimientos y restricciones Requerimientos sobre el tiempo de ejecución, 7x24, etc. Sobre la migración Atributos que determinan cuándo se debe realizar la migración. 76

76 Utilidad Performance Buenas asignaciones entre software y hardware evitan cuellos de botella y contribuye a distribuir mejor el procesamiento a lo largo del sistema. Confiabilidad Directamente relacionada con el comportamiento del sistema ante eventuales fallas o baja performance de las unidades de ejecución y/o los canales de comunicación.

77 Notación: Asignación Estilo Despliegue Las vistas de deployment pueden ser fácilmente representadas con UML, mientras que para las otras dos se suelen usar notaciones informales. Diagramas de deployment en UML Nodo Componente Asociación Componente UML 1.* Dependencia Componente UML

78 Ejemplo Estilo Despliegue (Allocation viewtype) 79

79 Fin