Vistas de una Arquitectura de Software.

El diseño de la arquitectura del software se puede representar desde diferentes perspectivas, denominadas vistas.

Las Vistas de una Arquitectura de Software son diferentes perspectivas o representaciones de un sistema de software que describen aspectos específicos del mismo. Son herramientas esenciales para comprender, comunicar y diseñar la arquitectura general de un software.

Vista estructural de una arquitectura de software.

La visión estructural de una arquitectura de software es una visión estática, que no cambia con el tiempo. En el nivel más alto, los subsistemas se representan en un diagrama de clases. En particular, un diagrama de clases de subsistema representa la relación estructural estática entre los subsistemas, que se representan como clases compuestas o agregadas, y la multiplicidad de asociaciones entre ellos.

Como ejemplo de la visión estructural de una arquitectura de software, considere el diseño de una arquitectura de software cliente/servidor, en la que hay múltiples clientes y un solo servicio. Un ejemplo de dicha arquitectura es el Sistema Bancario, en el que hay múltiples instancias del subsistema Cliente ATM y una única instancia del subsistema Servicio Bancario. En la Figura 1, los subsistemas de cliente y servicio se representan en un diagrama de clases, que proporciona una vista estática de la arquitectura.

La Figura 1 representa la relación estática entre el Servicio Bancario y el Cliente de Cajero Automático para el Sistema Bancario, en particular el nombre y la dirección de la asociación El Cliente de Cajero Automático Solicita Servicio al Servicio Bancario, así como la multiplicidad de la asociación, es decir, la relación uno a -muchas asociaciones entre el servicio y los clientes. Además, tanto el subsistema de cliente como el de servicio (representados como clases agregadas en la Figura 1) se representan con dos estereotipos, el primero es el estereotipo de rol, cliente o servicio, y el segundo es el estereotipo de estructuración arquitectónica, que, en este ejemplo, es subsistema para ambos.

Figura 1

Vista dinámica de una arquitectura de software.

La vista dinámica de una arquitectura de software es una vista de comportamiento, que se representa en un diagrama de comunicación. Un diagrama de comunicación de subsistemas muestra los subsistemas (representados como objetos agregados o compuestos) y la comunicación de mensajes entre ellos. Como los subsistemas se pueden implementar en diferentes nodos, se representan como componentes concurrentes, porque se ejecutan en paralelo y se comunican entre sí a través de una red.

Se proporciona un ejemplo de la vista dinámica de la arquitectura para un software cliente/servidor del sistema bancario, que se representa en un diagrama de comunicación del subsistema en la Figura 2. La Figura 2 muestra dos subsistemas del Sistema Bancario: Cliente Cajero Automático, del cual hay muchas instancias, y Servicio Bancario, del cual hay una instancia. Cada Cliente de Cajero Automático envía transacciones y recibe respuestas del Servicio Bancario. El Cliente de Cajero Automático y el Servicio Bancario se representan como componentes concurrentes, porque cada uno se ejecuta en paralelo con el otro, aunque en ocasiones necesitan comunicarse entre sí. Así, mientras un cliente se prepara para realizar una solicitud al servicio, el Servicio Bancario puede estar atendiendo a otro cliente. Mientras el servicio procesa la solicitud de un cliente determinado, el cliente normalmente espera la respuesta. En los diagramas de comunicación UML como los de la Figura 2, el mensaje sincrónico (ATMTransaction) se representa con una punta de flecha negra y la respuesta (bankResponse) se representa como una flecha discontinua con una punta de flecha.

Figura 2.

Un diagrama para un subsistema de comunicación es un diagrama de comunicación genérico, porque representa todas las interacciones posibles entre objetos. Debido a que describe todos los escenarios posibles, no se utilizan números de secuencia de mensajes. Además, debido a que los diagramas de comunicación genéricos representan instancias genéricas (lo que significa que representan instancias potenciales en lugar de instancias reales), utilizan la convención UML 2 de no subrayar los nombres de los objetos. Además de ser genérico, un diagrama de comunicación también es concurrente porque representa objetos que se ejecutan simultáneamente. Así, la figura 2 muestra dos subsistemas concurrentes, el cliente de cajero automático y el servicio bancario, que están distribuidos geográficamente.

Vista de implementación de una arquitectura de software.

La vista de implementación de la arquitectura de software representa la configuración física de la arquitectura de software, en particular cómo se asignan los subsistemas de la arquitectura a nodos físicos en una configuración distribuida. Un diagrama de implementación puede representar una implementación específica con una cantidad fija de nodos. Alternativamente, puede representar la estructura general de la implementación; por ejemplo, identificando que un subsistema puede tener muchas instancias, cada una de las cuales se puede implementar en un nodo separado, pero sin representar el número específico de instancias. En la Figura 3 se ofrece un ejemplo de esta vista para la arquitectura del software cliente/servidor del sistema bancario. En esta implementación, cada instancia de Cliente ATM se asigna a su propio nodo físico, mientras que el Servicio Bancario centralizado se asigna a un único nodo. Además, los nodos están conectados mediante una red de área amplia.