Apunte de Viewtypes (Ingeniería II)

De Cuba-Wiki
Saltar a: navegación, buscar
Back.png Volver a la página de la materia

Components and Connectors[editar]

Componentes y conectores da información sobre el sistema en runtime. Da visibilidad de los componentes y sus asignaciones funcionales, así como de los caminos de la información en el sistema. Los conectores entre los componentes son elementos de 1er nivel. Cada componente o conector puede estar instanciado más de una vez en el diagrama.

  • Elementos: Los elementos son tanto los componentes (unidades de procesamiento, datastores, etc) como los conectores entre ellos.
  • Relaciones: La única relación es de attachment, se asocian un puerto de un componente con un rol de un conector.

Todo elemento se corresponde a un tipo en el sistema. Todo componente define su interfaz a través de puertos, que se attachean a roles en los conectores. Notar que los conectores no tienen por qué ser binarios, y generalmente describen una interacción relativamente compleja.

Una vista de CnC permite ver los componentes ejecutables y su interacción, el acceso a las fuentes de datos, la replicación de ciertos componentes del sistema, el flujo de datos, los protocolos de interacción, la concurrencia y los cambios en runtime de la estructura del sistema.

Client Server[editar]

Cliente-servidor utiliza componentes cliente y servidor, donde el cliente inicia un pedido a un servidor conocido y recibe su respuesta de manera síncrona o asíncrona. Los conectores indican los protocolos sobre los que se realizan los pedidos.

Se relaciona con el estilo Layered del module viewtype al identificar una layer con los clientes y la de los servidores con la de los servicios que los clientes consumen.

Permite analizar distintos atributos de calidad como ser dependability, security o performance.

Shared Data[editar]

Se basa en el intercambio de datos persistentes. Los componentes son los data stores y los data accessors, y los conectores se basan en lectura y escritura de datos. El datastore tiene que manejar las responsabilidades de acceso concurrente, integridad, tolerancia a fallos, caching, etc.

Los data stores pueden ser blackboards (si notifican a los consumidores o knowledge sources del arribo de ciertos datos) o repositories (si no lo hacen, como es el caso de una base de datos). Notar que una DB con triggers es un híbrido.

En su forma más pura la interacción entre los componentes del sistema se hace solamente a través del datastore; aunque es común que haya mensajes fuera del store entre los distintos procesos.

Este style se centra en persistencia de datos y desacoplamiento entre productores y consumidores de datos. Permite análisis de modificabilidad, seguridad, reliability, performance, etc.

Pipes and Filters[editar]

Estilo orientado a la transformación de datos. Hay un único componente, el filter, encargado de la transformación de datos, con puertos de entrada y de salida. Los filters se conectan únicamente mediante pipes, que no modifican los datos, sino que son conectores unidireccionales que manejan buffering y movimiento de datos entre los filters.

Como especializaciones, la estructura puede ser lineal, en cuyo caso se la denomina pipeline, o acíclica.

Este style es fuertemente algorítmico y se relaciona de manera directa con la vista de módulos.

Publish Subscribe[editar]

Se basa en la comunicación de eventos. Los componentes son cualquier tipo de objeto pasible de suscribirse a o publicar un evento; mientras que los únicos conectores son de suscripción, encargados de llevar los eventos a los suscriptores. Generalmente se tiene un event bus encargado de esto.

Es importante distinguir cómo se hace la suscripción, y si esta puede hacerse dinámicamente. Una especialización de este style es la invocación implícita, en la que cada suscriptor mapea un evento a algún procedure; mientras que otra especialización se basa en el simple ruteo de eventos hacia los componentes y cada componente debe decidir cómo reaccionar ante el evento.

Este style permite relacionar muchos componentes, a veces heterogéneos, de manera asíncrona, sin que ellos se conozcan mutuamente. Favorece el desacoplamiento y la registración dinámica en runtime.

Peer to Peer[editar]

Basado en la interacción de peers mediante el intercambio de servicios. Esquema de request/reply similar al de client server pero sin asimetría. Los conectores se corresponden con la invocación de servicios.

Se deben especificar las propiedades de los protocolos entre peers y las propiedades orientadas a la performance de los peers.

Este style particiona la aplicación por áreas de colaboración y otorga la flexibilidad necesaria para realizar un deployment distribuido del sistema, facilitando la distribución de carga e interoperabilidad.

Communicating Processes[editar]

Permite el análisis de concurrencia de las distintas unidades de procesamiento. Los componentes son threads o procesos, y los conectores son señales para sincronización, intercambio de datos, pasaje de mensajes, control, etc.

El objetivo de este style es analizar el paralelismo y concurrencia dentro del sistema. Permite analizar performance y reliability.


Modules[editar]

La vista de módulos ofrece una descomposición del sistema en función de su implementación. La modularización se refiere a la organización del software en tiempo de diseño, no a runtime (como sucedía en CnC).

  • Elementos: Módulos, unidades de código (clases, layers, etc) que implementan un conjunto de responsabilidades con una interfaz bien definida. Las propiedades de un módulo pueden ser su nombre', responsabilidades, visibilidad e información sobre implementación.
  • Relaciones: es-parte-de (composición), depende-de (dependencia), o es-un (generalización).

El module viewtype no sirve para analizar comportamiento de runtime, pues solamente detalla las particiones de las unidades de software. Los usos están relacionados al tiempo de diseño del soft.

  • Construcción: Permite construir y organizar los fuentes.
  • Análisis: Tanto de requerimientos funcionales (cada requerimiento funcional debe ser satisfecho por uno o más módulos) como análisis de impacto (sensibilidad a los cambios).
  • Comunicación: Explicar funcionalidades del sistema.

Decomposition[editar]

Se basa en la relación es-parte-de para partir cada módulo o sistema en subsistemas. Los criterios de descomposición pueden ser para lograr determinados atributos de calidad (como modificabilidad), analizar el uso de módulos third party o identificar módulos comunes en una familia de productos.

La vista de descomposición ayuda al análisis de impacto de modificabilidad (aunque no muestra dependencias, con lo que no es completa) y a la comunicación del sistema a alguien que no lo conoce. También se mapea bien a la vista de asignación de trabajo.

Uses[editar]

Basado en la especialización de la relación depende-de a usa. Esta dependencia puede no ser directa, se basa en que un módulo requiere el correcto funcionamiento de otro para ser correcto.

Permite la planificación de desarrollos incrementales, test plans y análisis de impacto ante posibles cambios.

Layered[editar]

La vista de capas se basa en que cada elemento es un layer, que agrupa a módulos similares y provee una determinada interfaz (no solamente api, sino también cuestiones no funcionales). Divide al sistema en un conjunto de layers, cada una pudiendo representar incluso una VM. La relación en este caso, depende-de, se especializa a puede-usar.

Esta vista permite analizar la modificabilidad y portabilidad del sistema, además de proveer al arquitecto un blueprint inicial del sistema.

Generalization[editar]

Vista de clases, donde la relación es-un se especializa a herencia, instanciación, implementación, etc. Se usa para diseños orientados a objetos principalmente.


Allocation[editar]

El allocation viewtype busca mappear la arquitectura a su entorno, sea hardware, implementación o workforce. Las relaciones de este viewtype son de allocated-to.

Deployment[editar]

El deployment style mapea una vista de CnC a la infraestructura en la que será desplegada. Los elementos son de software y de hardware. Las propiedades relevantes son los recursos de ejecución (CPU, RAM, etc) que provee el hard y los que requiere cada componente de soft. Permite analizar la performance y la confiabilidad del sistema según dónde es desplegado.

A las relaciones de allocated-to se agregan migrates-to, que indica que un elemento de soft en un procesador puede migrar a otro procesador; copy-migrates-to, donde el proceso es copiado en lugar de movido; y execution-migrates-to, donde hay múltiples copias de un proceso en distintos procesadores, pero solamente una activa.

Implementation[editar]

Vincula una vista de modules con configuration management. En su forma más simple, se refiere a la estructura de archivos usada para soportar los fuentes del proyecto.

Work Assignment[editar]

Vincula módulos con equipos de trabajo. Las propiedades relevantes son para los elementos de soft, los conocimientos necesarios para implementarlos, y para los equipos, los conocimientos que poseen.