Diagrama de componentes

Los diagramas de componentes se utilizarán para ilustrar la descomposición de un sistema en componentes arquitectónicos de grano grueso y sus interre- laciones a través de sus respectivas interfaces.

En versiones anteriores de UML, los componentes se consideraban como una representación de estructuras físicas, tales como archivos, DLL, etc. En UML 2.0, los componentes pasan a constituir un potente mecanismo de especifica- ción a nivel lógico, ya que sólo se utilizan para representar y especificar los requisitos para cada elemento software.

En UML 2.0, un componente es una unidad modular del sistema que encapsula una cierta funcionalidad, que posee interfaces bien definidas y que es reemplazable dentro de su entorno.

Los componentes se conectan a través de interfaces implementadas (o propor- cionadas) e interfaces requeridas. Por ejemplo, en la figura 17, el componente "Gestor transacciones" implementa una interfaz que requiere el componente "Sistema cuentas".

Figura 17. Ejemplo de componentes UML 2.0

Los componentes pueden definir comportamientos; será el diseño interno del componente el que defina la implementación de estos comportamientos. Por tanto, el componente debe aportar los medios para que otros componentes puedan requerir los servicios que ofrece.

Una interfaz�implementada (o proporcionada) define cómo se debe acceder a los servicios que ofrece un componente.

Por otra parte, puede darse el caso de que un componente necesite soporte de otros componentes. Éste deberá, por tanto, definir de manera análoga qué necesita exactamente de los demás.

Una interfaz�requerida define el tipo de servicios que un componente requerirá de otros.

Además de las interfaces, UML 2.0 permite que los componentes incluyan in- formación acerca de sus realizaciones1 _{y artefactos, y sobre sus propiedades} internas. UML 2.0 lo permite para poder "refinar" estos componentes arqui- tectónicos en las siguientes fases del desarrollo, incluyendo los detalles tecno- lógicos sobre cómo están realizados internamente. Desde el punto de vista arquitectónico, sólo es relevante la información sobre sus interfaces e interac- ciones con otros componentes. Sin embargo, a la hora de desarrollar el sistema es necesario decidir cómo se implementarán internamente estos componen- tes. Este proceso será tratado con detalle en el módulo 3.

Otro aspecto que se debe considerar es el caso en el que un componente ofrezca diferentes tipos de servicios a sus congéneres. Por lo general, es posible imple- mentar múltiples interfaces para expresar estas diferencias. Sin embargo, sería preferible establecer algún criterio de agrupación, de modo que se permita es- clarecer qué tipo de servicio da una determinada interfaz. Para ello, UML 2.0

(1)_{Una realización se refiere a la im-} plementación de un requisito.

hace uso de los puertos, en los que se agrupan conjuntos de interfaces (tanto requeridas como implementadas), según criterios de diseño y de los servicios que requieran o proporcionen.

Un puerto puede tener dos tipos de interfaz

Con las interfaces� proporcionadas, el puerto exhibe un conjunto de operaciones al mundo exterior.

Con las interfaces�requeridas, el puerto establece qué conjunto de operaciones utilizará del mundo exterior.

Un puerto es una característica del componente que especifica un pun- to de interacción diferenciado entre el componente y su entorno, o en- tre el comportamiento del componente y sus partes internas.

Con ello, UML 2.0 permite especificar puntos de interacción, que expondrá a su entorno el componente, y aportar explícitamente la correspondencia entre las interfaces publicadas y los mecanismos de implementación internos. • Hacia�el�exterior, los puertos se conectan con otros puertos mediante co-

nectores, a través de los cuales se realizan las peticiones al componente

para invocar un determinado comportamiento.

• Hacia�el�interior, un puerto conecta los mecanismos internos de imple-

mentación del componente (las clases, asociaciones u otros componentes que lo componen) con su entorno. Esto implica que el puerto sirve al com- ponente como apertura al exterior.

Los puertos son una importante aportación de UML 2.0, ya que permiten en- capsular la entrada o salida de las interacciones hacia el componente. Este fac- tor es crucial a la hora de la reusabilidad, puesto que, manteniendo el puerto, es posible modificar la parte interna del componente sin que afecte al modo como éste se muestra ante su entorno.

En un nivel de abstracción superior, el concepto de puerto se corres- ponde con el de servicio. De este modo, definiremos un puerto por ca- da uno de los servicios que implementa o requiere un componente, y que definen su funcionalidad. Las interfaces UML asociadas al puerto definen la signatura de las operaciones que definen el servicio.

Utilizando todos estos elementos estructurales describiremos la arquitectura software de un sistema centrando la atención en la estructura global del mis- mo, y destacando su descomposición en paquetes, componentes e interfaces y relaciones de dependencia entre ellos.

Uso de paquetes para representar capas

Cada capa a nivel lógico se re- presenta en UML mediante un paquete.

Figura 18. Ejemplo de representación de la arquitectura de tres capas para el ejemplo de la banca electrónica

Basándonos en el modelo de casos de uso refinado, organizaremos los paquetes en niveles o capas conceptuales independientes para el caso concreto que nos ocupa: las arquitecturas de tres capas. El diseño de cada capa comprenderá dos tareas claramente diferenciadas:

• El diseño�interno tiene como finalidad el modelado de los elementos per- tenecientes a ese nivel.

• El diseño�externo define la interacción entre esa capa y las demás. Para el diseño interno nos ayudaremos de cuantos diagramas de componen- tes sean necesarios: cada uno de ellos proporcionando un mayor nivel de de- talle o descomposición de los paquetes y componentes si es preciso. A modo de ejemplo, la figura 18 ilustra un diagrama de componentes correspondien- te a una distribución o arquitectura en tres capas para el ejemplo del banco en línea. Como vemos, cada capa es modelada como un paquete UML, pro- porcionando un límite bien definido alrededor de un conjunto de elementos

relacionados. A su vez, cada capa exporta sólo aquellos elementos que otros paquetes precisan ver realmente e importa sólo aquellos elementos requeridos para que los elementos del paquete puedan llevar a cabo su tarea.

Observad cómo en la figura 18 sólo han sido presentados los elementos más significativos. Cuando se revela el contenido de un paquete, deben mostrarse sólo los elementos necesarios para transmitir de manera concisa su finalidad. Sin embargo, podríamos refinar el diagrama anterior con una descripción más detallada de los componentes y elementos que figuran en cada nivel, como veremos en el módulo 3. Cuanto más detallado es el diseño, más cercano re- sultará el modelo a la implementación.