 ¡Por fin una descripción de la arquitectura! ¡Por fin una descripción de la arquitectura!  La vista de la arquitectura del modelo de casos de uso La vista de la arquitectura del modelo de casos de uso  La vista de la arquitectura del modelo de diseño La vista de la arquitectura del modelo de diseño  La vista de la arquitectura del modelo de despliegue La vista de la arquitectura del modelo de despliegue  La vista de la arquitectura del modelo de implementación La vista de la arquitectura del modelo de implementación  ¿Qué es una arquitectura? ¿Qué es una arquitectura?  ¿Cómo se obtiene la Arquitectura ? ¿Cómo se obtiene la Arquitectura ?  ¿Cómo se describe la Arquitectura ? ¿Cómo se describe la Arquitectura ?

Hemos estado hablando bastante tiempo sobre lo que es la arquitectura sin ofrecer un ejemplo significativo. Presentamos ahora un ejemplo concreto de la apariencia de una descripción de arquitectura. Sin embargo, antes tenemos que explicar por qué no es fácil hacerlo. Recuérdese que la descripción de la arquitectura es sencillamente un extracto adecuado de los modelos del sistema (es decir, no añade nada nuevo). La primera versión de la descripción de la arquitectura es un extracto de la versión de los modelos que tenemos al término de la fase de elaboración en el primer ciclo de vida. Dado que no intentarnos hacer una reescritura más legible de esos extractos, la descripción de la arquitectura se parece mucho a los modelos normales del sistema. Esta apariencia significa que la vista de la arquitectura del modelo de casos de uso es muy parecida a un modelo de casos de uso normal.

La única diferencia reside en que la vista de la arquitectura sólo contiene los casos de uso significativos para la arquitectura (Sección ), mientras que el modelo de casos de uso final contiene todos los casos de uso. Lo mismo ocurre con la vista de la arquitectura del modelo de diseño. Es igual que un modelo de diseño, pero sólo representa los casos de uso que.son interesantes para la arquitectura. Otra razón por la cual es difícil ofrecer un ejemplo es que sólo es interesante hablar de la arquitectura en sistemas reales, y cuando queremos hablar aquí sobre un sistema en detalle, debe ser por necesidad un sistema pequeño. Sin embargo, vamos a emplear el ejemplo del CA del Capítulo 3 para ilustrar lo que podrían llevar las vistas de la arquitectura. Lo haremos comparando lo que debería estar en las vistas y lo que debería estar en los modelos completos del sistema.

La descripción de la arquitectura tiene cinco secciones, una para cada modelo. tiene una vista del modelo de casos de uso una vista del modelo de análisis (que no siempre se mantiene), una vista del modelo de diseño, una vista del modelo de despliegue, y una vista del modelo de implementación. No incluye una vista del modelo de prueba porque no desempeña ningún papel en la descripción de la arquitectura, y sólo se utiliza para verificar la línea base de la arquitectura. Regresar

 La vista de la arquitectura del modelo de casos de uso presenta los actores y casos de uso más importantes (o escenarios de esos casos de uso). Sección 3.3.  “La captura de casos de uso”, en lo relativo al modelo de casos de uso del sistema de CA.

En el ejemplo del CA, el caso de uso más importante es Sacar Dinero. Sin él, no existiría un verdadero sistema de CA. Los casos de uso Ingresar Dinero y Transferencia entre Cuentas se consideran menos importantes para un cliente de banco normal. Para definir la arquitectura, el arquitecto sugiere por tanto que el caso de uso Sacar Dinero se implemente en su totalidad durante la fase de elaboración, pero ningún otro caso de uso (o parte de caso de uso) se considera interesante para la arquitectura. (En la práctica, esta decisión podría ser un poco precipitada, pero la utilizamos para los propósitos de esta explicación.) La vista de la arquitectura del modelo de casos de uso debería por tanto, mostrar la descripción completa del caso de uso Sacar Dinero. Regresar

La vista de la arquitectura del modelo de diseño presenta los clasificadores más importantes para la arquitectura pertenecientes al modelo de diseño: Los subsistemas e interfaces más importantes, así como algunas pocas clases muy importantes, fundamentalmente las clases activas. También presenta cómo se realizan los casos de uso en términos de esos clasificadores, por medio de realizaciones de casos de uso. Las clases activas también las trataremos en la Sección cuando hablemos del modelo de despliegue (en el cual las clases activas se asignan a nodos).

En la Sección 3.4.3, identificamos tres clases activas: Gestor de Clientes, Gestor de Transacciones, y Gestor de Cuentas (Figura 4.7). Estas clases activas se incluyen en la vista de la arquitectura del modelo de diseño. Además, en la Sección 3.4.4, se describieron los tres subsistemas: Interfaz del CA, Gestión de Transacciones, y Gestión de Cuentas: Figura 4.8. Estos subsistemas son necesarios para la realización del caso de uso Sacar Dinero, por lo cual son subsistemas significativos para la arquitectura. El modelo de diseño incluye muchos otros subsistemas, pero no los consideramos.

El subsistema Interfaz del CA se encarga de todas las entradas y salidas del cliente del banco, tales como la impresión de los recibos y la recepción de los comandos del cliente. El subsistema de Gestión de Cuentas mantiene toda la información persistente sobre las cuentas, y se utiliza en todas las transacciones relativas a ellas. El subsistema de Gestión de Transacciones contiene las clases para el comportamiento específico de los casos de uso, como el comportamiento especifico del caso de uso Sacar Dinero. En el ejemplo de la Sección 3.4.4, dijimos que las clases específicas de los casos de uso acaban a menudo en distintos subsistemas de servicio, como los subsistemas de servicio para cada una de las clases Retirada de Efectivo, Transferencia e Ingreso dentro del subsistema de Gestión de Transacciones (no se muestran en la Figura 4.8). En realidad, cada uno de esos subsistemas de servicio contiene normalmente varias clases, pero nuestro ejemplo es muy sencillo.

Los subsistemas de la Figura 4.8 proporcionan comportamiento unos a otros mediante interfaces, como la interfaz Transferencias que proporciona la Gestión de Transacciones. Las interfaces Transferencias, Retirada, y Entrega se describen en la Sección También tenemos interfaces Transferir, Depósitos, e Historia, pero no se ven implicadas en el caso de uso que tratamos en este ejemplo, por lo que no las hemos explicado. No basta con la estructura estática. También tenemos que mostrar cómo se llevan a cabo, por parte de los subsistemas del modelo de diseño, los casos de uso significativos para la arquitectura. Por tanto, describiremos una vez más el caso de uso Sacar Dinero, esta vez en términos de subsistemas y actores que interactúan utilizando un diagrama de colaboración, como se muestra en la Figura 4.9.

Los objetos de las clases que poseen los subsistemas interactúan unos con otros para ejecutar una instancia de un caso de uso. Los objetos se envían mensajes; el diagrama muestra estos intercambios. Los mensajes llevan nombres que especifican operaciones contenidas en las interfaces de los subsistemas. Esto se indica mediante la notación :: (por ejemplo, Retirada::realizar(cantidad, cuenta), donde Retirada es una interfaz proporcionada por una clase dentro del subsistema de Gestión de Transacciones).

La siguiente lista explica brevemente el flujo de la ejecución del caso de uso. El texto es casi el mismo que el de la Sección (la descripción de la ejecución del caso de uso), pero aquí lo presentamos en términos de subsistemas en lugar de clases. Precondición: El cliente del banco tiene una cuenta bancaria válida para el CA. El actor Cliente de Banco selecciona sacar dinero y se identifica en la Interfaz del CA, quizás a través de una tarjeta de banda magnética, mediante un número y una contraseña. El Cliente de Banco también indica la cantidad a retirar y de qué cuenta hacerlo. Suponemos que el subsistema Interfaz de CA es capaz de verificar la identidad. La Interfaz de CA solicita al subsistema de Gestión de Transacciones que retire el dinero. Este subsistema es responsable de llevar a cabo la secuencia entera de retirada a modo de transacción atómica, de manera que el dinero se deduce de la cuenta y también se entrega al Cliente de Banco.

Gestión de Transacciones solicita al subsistema Gestión de Cuentas que retire el dinero. El subsistema Gestión de Cuentas decide si puede retirarse el dinero y, si es así, deduce la suma de la cuenta y devuelve una respuesta que indica que es posible ejecutar la retirada. Gestión de Transacciones autoriza al Interfaz de CA a entregar el dinero. Interfaz de CA entrega el dinero al Cliente de Banco. Regresar

El modelo de despliegue define la arquitectura física del sistema por medio de nodos interconectados. Estos nodos son elementos hardware sobre los cuales pueden ejecutarse los elementos software. Con frecuencia conocemos cómo será la arquitectura física del sistema antes de comenzar su desarrollo. Por tanto, podemos modelar los nodos y las conexiones del modelo de despliegue tan pronto como comience el flujo de trabajo de los requisitos. Durante el diseño, decidiremos qué clases son activas, es decir, son hilos o procesos.

Determinaremos lo que debería hacer cada clase activa, cómo debería ser el ciclo de vida de cada una de ellas, y cómo deberían comunicarse, sincronizarse, y compartir información. Los objetos activos se asignan a los nodos del modelo de despliegue. Al hacer esta asignación, debemos considerar la capacidad de los nodos, como su capacidad de proceso y tamaño de memoria, y las características de las conexiones, como el ancho de banda y la disponibilidad. Los nodos y conexiones del modelo de despliegue y la asignación de los objetos activos a los nodos pueden mostrarse en diagramas de despliegue. Estos diagramas también pueden mostrar cómo se asignan los componentes ejecutables a los nodos. El sistema de CA de nuestro ejemplo se distribuye en tres nodos distintos.

El Cliente de Banco accede al sistema a través del nodo Cliente CA, que accede al Servidor cié Aplicaciones CA para realizar las transacciones (Figura 4.10). El Servidor de Aplicaciones CA utiliza, a su vez, al Servidor de Datos CA para ejecutar transacciones concretas sobre cuentas, por ejemplo. Esto es así no sólo para el caso de uso Sacar Dinero, que hemos clasificado como significativo para la arquitectura, sino también para los demás casos de uso, como Ingresar Dinero y Transferir entre Cuentas. En la Sección 3.4.3, describimos qué clases habíamos seleccionado para llevar a cabo el caso de uso Sacar Dinero. Cuando se han definido los nodos, podemos distribuir la funcionalidad sobre ellos. Por sencillez, lo haremos distribuyendo cada subsistema (véase la Figura 4,8) como un todo a un único nodo. El subsistema Interfaz de CA se implanta sobre el nodo Cliente CA, el subsistema Gestión de Transacciones sobre el Servidor de Aplicaciones CA, y el subsistema de Gestión de Cuentas sobre el Servidor de Datos CA.

En consecuencia, cada clase activa dentro de estos subsistemas (véase la Sección y la Figura 3,10) se implanta en su correspondiente nodo —mediante un proceso ejecutándose sobre el mismo—. Cada uno de estos procesos gestiona, y mantiene en su espacio de direcciones, objetos del resto de las clases dentro del subsistema (clases ordinarias, no activas). La Figura 4.11 muestra la distribución de los objetos activos. Éste es un ejemplo simplista de distribución de un sistema. En un sistema real, la distri­bución es por supuesto más compleja. Una solución alternativa al problema de la distribución habría sido el uso de alguna capa intermedia para la distribución de objetos como un object request broker (ORE).

Regresar

El modelo de implementación es una correspondencia directa de los modelos de diseño y de despliegue. Cada subsistema de servicio del diseño normalmente acaba siendo un componente por cada tipo de nodo en el que deba instalarse —pero no siempre es así—. A veces el mismo componente (por ejemplo, el componente de gestión de buffers) puede instanciarse y ejecutarse sobre varios nodos. Hay lenguajes que proporcionan construcciones para el empaquetado de los componentes, como es el caso de los JavaBeans. En otros casos, las clases se organizan en ficheros con el código que representa los diferentes componentes.

En la Sección 3.4.5, indicarnos que el subsistema de servicio Gestión de Retiradas posiblemente podría implementarse mediante dos componentes, “Retirada en Servidor”, y “Retirada en Cuente”. El componente “Retirada en Servidor’ podría implementar la clase Retirada de Efectivo, y “Retirada en Cliente” podría implementar una clase Proxy de Retirada. En nuestro ejemplo sencillo, estos componentes sólo imple mentarían una clase cada uno. En un sistema real, habría varias clases más en cada subsistema de servicio, de forma que un componente podría implementar varias clases. Regresar

Es lo que especifica el arquitecto en la descripción de la arquitectura. La descripción de la arquitectura permite al arquitecto controlar el desarrollo del sistema desde la perspectiva técnica. La arquitectura software se centra tanto en los elementos estructurales significativos del sistema, como subsistemas, clases, componentes y nodos, como en las colaboraciones que tienen lugar entre estos elementos a través de las interfaces. Los casos de uso dirigen la arquitectura para hacer que el sistema proporcione la funcionalidad y uso deseados, alcanzando a la vez, objetivos de rendimiento razonables. Una arquitectura debe ser completa, pero también debe ser suficientemente flexible como para incorporar nuevas funciones, y debe soportar la reutilización del software existente. Regresar

La arquitectura se desarrolla de forma iterativa durante la fase de elaboración pasando por los requisitos, el análisis, el diseño, la implementación y las pruebas. Utilizamos los casos de uso significativos para la arquitectura y un conjunto de otras entradas para implementar la línea base de la arquitectura, o “esqueleto” del sistema. Ese conjunto de entradas incluye requisitos del software del sistema, middleware, qué sistemas heredados deben utilizarse, requisitos no funcionales, y demás. Regresar

La descripción de la arquitectura es una vista de los modelos del sistema, de los modelos de casos de uso, análisis, diseño, implementación y despliegue. La descripción de la arquitectura describe las partes del sistema que es importante que comprendan todos los desabolladores y otros interesados. Regresar