Página 172 A nálisis y D iseño d e Sistem as con el LIMI,

Diagramas de componentes

El diagrama de com ponentes describe los componentes de software y sus dependencias entre sí,
representando la estructura del código. Los componentes son la implementación en la arquitectura
física de los conceptos y la funcionalidad descrita en la arquitectura lógica (clases, objetos, sus
relaciones, y colaboraciones). L os com ponentes son típicamente los archivos de implementación en el
ambiente de desarrollo.

Un componente es mostrado en el UML como un rectángulo con dos rectángulos menores a la

izquierda. E l nombre del com ponente es escrito bajo el símbolo o dentro del rectángulo grande.

Figura 99: Notación del UML para un componente

Un componente de software puede ser cualquiera de lo siguiente:

■ Componente fuente: un componente fuente tiene significado en tiempo de compilación. Es

típicamente un archivo de código fuente que implementa una o más clases.
■ Componente binario: un com ponente binario es típicamente código de objeto que es el resultado
de com pilar un com ponente fuente. Podría ser un archivo de código de objeto, una archivo de
librería estática, o un archivo de librería dinámica. Un componente binario tiene significado en el
momento d e enlazado, o en el caso de una librería dinámica, e n tiempo de ejecución (una librería
dinámica es cargada p o r el componente ejecutable en tiempo ejecución).
■ Componente ejecutable: un componente ejecutable es un archivo de programa ejecutable que es el
resultado de enlazar todos los com ponentes binarios (ya sea estáticos en tiempo de enlace o
dinámicos en tiempo de ejecución). Un componente ejecutable representa la unidad ejecutable que
es corrida p o r el procesador (computadora).

Figura 100: Diagrama de componente que muestra un número de componentes - fuente, binario y ejecutable - y sus
dependencias

Los componentes son tipos, pero solo un com ponente ejecutable puede tener instancias (las cuales son
los programas que representan cuando corren en el procesador). Un diagrama de conponente muestra
solamente los com ponentes como tipos. Para mostrar instancias de los componentes se debe usar un
C apítulo 13: Arquitectura del Sistem a Página 173

diagrama de despliegue, donde las instancias de los conponentes son asignados a instancias de nodos
en las cuales se ejecutan.

Una conexión de dependencia entre com ponentes significa que un componente necesita otro para tener
una definición completa. U na dependencia de un componente d e código fuente A otro componente B
significa que hay una dependencia específica del lenguaje de A a B. En un lenguaje compilado, esto
indicaría que un cambio en B requiere una recompilación de A . Si los componentes son ejecutables,
las conexiones de dependencia pueden ser usadas para identificar que librerías dinámicas un programa
ejecutable necesita para correr.

U n componente puede definir interfaces que son visibles a otros componentes. Las interfaces pueden
ser interfaces a nivel código fuente (como en Java) o interfaces binarias usadas en el momento de la
ejecución (c o n » e n O LE). U na interfaz es mostrada con una línea desde el componente con un círculo
en el extremo. Las dependencias entre componentes pueden apuntar a la interfaz del componente
usado.

updatcthrcadjMKi

Figura 101 : Interfaces y dependencias

Componentes fuentes

Los com ponentes fuentes contienen el código producido en los proyectos. Otros componentes como
los componentes de tiempo de enlace o de tiempo de ejecución pueden ser generados de los
co n ponentes fuentes. A lgunos estereotipos que pueden ser usados para los componentes fuentes son:

■ « f i l e » : una representación de un archivo que contiene código fuente.

■ « p a g e » : una representación de una página Web.
■ « d o c u m e n t» : una representación de un archivo con documentación.

Una dependencia de un componente de compilación a otro revela cuáles otros componentes son
necesarios para com pletar su definición; por ejemplo, qué otros componentes de tiempo de
compilación no incluye en su definición.
 Página 174 A nálisis y D iseño d e Sistem as con el ÜM I.

Figura 102: Dependencias entre componentes de código fuente

Componentes de tiempo de enlace

U n componente de tiempo de enlace es usado cuando se enlaza el sistema. Es típicamente el código

objeto que resulta de com pilar un componente de tiempo de compilación o una librería que es el
resultado de com pilar uno o más com ponentes de tiempo de compilación. Un caso especial es la
librería d e enlace dinám ico (DLL), la cual es enlazada en tiempo de ejecución en vez de en tiempo de
enlace. El estereotipo « l i b r a r y » puede ser usado para mostrar que un componente es una librería
estática o dinámica.

Componentes de tiempo de ejecución

U n componente de tiempo de ejecución representa un componente usado cuando se ejecuta el sistema.

Es generado de los com ponentes de tiempo de enlace (de código objeto y librerías) o en algunos casos
directamente de los com ponentes de código fuente. El estereotipo « a p p lic a tio n » representa un
programa ejecutable, y el estereotipo « t a b l e » representa una tabla de base de datos que también
puede ser vista com o un componente usado en tiempo de ejecución.

Figura 103: Componentes de tiempo de ejecución

Solamente los componentes en tiempo de ejecución tienen instancias y son localizados en nodos (las
unidades en los diagramas de despliegue). Una instancia de un componente de tiempo de ejecución
indica que a partir del tipo del componente se instanciaron varios procesos para correr la aplicación
representada en el archivo de componente. Las dependencias de un componente de tiempo de
C apítulo 13: Arquitectura del Sistem a Página 175

ejecución son otros componentes necesarios para su ejecución: librerías de enlace dinámico, archivos
de imágenes o tablas de base de datos.

Diagramas de despliegue

El diagrama de despliegue presenta la arquitectura de tiempo de ejecución de los procesadores,

dispositivos, y los com ponentes de software que se ejecutan en esa arquitectura. E s la descripción
física última de la topología del sistema, y describe la estructura de las unidades de hardware y el
software que se ejecuta en cada unidad. En una arquitectura así, debe ser posible mirar un nodo
específico de la topología, ver qué componentes se ejecutan en el nodo, ver qué elementos lógicos
están implementados en el componente, y finalmente trazar esos elementos al análisis de
requerimientos inicial del sistema.

Nodos

Los nodos son dispositivos físicos que tienen algún tipo de recurso computacional, entre ellos
computadoras, im presoras, lectores de tarjetas, dispositivos de comunicación, etc. Los nodos son
identificados mirando a o decidiendo los recursos de hardware necesarios para im plementar el sistema,
tanto en términos de capacidad (memoria, velocidad, alm acenamiento secundario) como de
localización (geográfica).

U n nodo puede ser m ostrado como un tipo y una instancia (un nodo es una clase), donde un tipo
describe las características de un procesador o tipo de dispositivo y una instancia representa
ocurrencias actuales (máquinas) de ese tipo. La definición detallada de la capacidad del sistema puede
ser definida ya sea com o atributos o propiedades de los nodos. Un nodo es dibujado como un cubo
tridimensional con el nom bre dentro de él; y si el símbolo representa una instancia el nombre debe
subrayarse.

Figura 104: Tipo nodo e instancia del mismo

Los dispositivos en el sistem a son representados como nodos, típicamente con un estereotipo que
especifica el tipo de dispositivo, o por lo menos con un nombre que lo defina claramente como un
nodo de dispositivo y n o un nodo de procesador.

Figura 105: Nodos de dispositivos y posibles estereotipos

O Página 176 A nálisis y D iseño d e Sistem as con el LIMI,

Conexiones

Los nodos están conectados entre sí por asociaciones de comunicación. Son dibujadas como
asociaciones normales con una línea recta, indicando que hay algún tipo de camino de comunicación
entre ellas, y que los nodos intercambian objetos o envían mensajes mediante el camino de
comunicación. El tipo de comunicación e s representado por un estereotipo que identifica el protocolo
de comunicación o la red usada.

Cliente A
Compaq Pro PC
Servida-(fe
Apicaciones
Silicon Graorics

Cliente B
Compaq Pro PC

Figura 106: Asociaciones de comunicación entre nodos

Componentes

L as instancias ejecutables de los componentes pueden ser contenidas dentro los símbolos de instancia
de los nodos, mostrando que residen y se ejecutan en una instancia de nodo. Del tipo nodo, una flecha
de dependencia con el estereotipo « s u p p o r t s » puede ser dibujada a un tipo componente de tiempo
de ejecución, indicando que el nodo soporta un componente específico. Cuando un tipo nodo soporta
un tipo componente, es posible ejecutar una instancia de ese componente en la instancia del tipo nodo.
Por ejemplo, no es posible crear un programa W indows en un AS/400, por lo que el tipo nodo AS/400
no soporta el tipo componente.

Los com ponentes están conectados a otros componentes mediante flechas de dependencia. Recuerde
que en un diagram a de despliegue solamente los componentes de tiempo de ejecución son mostrados.
Esto significa que un c onponente usa los servicios de otro componente.

Silicon Grapücs

Figura 107: Un tipo nodo soporta un tipo componente de tiempo de ejecución, y un componente de tiempo de
ejecución se ejecuta en una instancia de nodo
C apítulo 13: Arquitectura del Sistem a Página 177

Objetos

U n objeto es colocado dentro de una instancia de nodo para indicar donde reside en esa instancia. El
objeto puede ya sea ser activo (con los estereotipos « P r o c e s s » (proceso) o « T h r e a d » (hilo), y
dibujado con una línea gruesa), que se ejecuta en el nodo, o pasivo. El objeto es contenido dentro de
otro objeto o dentro del componente. Esto es mostrado anidando los símbolos; o, si se complica
mucho, una propiedad de lugar puede mostrar donde un objeto está localizado. Por ejemplo, un objeto
pasivo puede ser contenido dentro de un proceso (un objeto activo), y el proceso vive dentro de un
componente asignado a un nodo.

Figura 108: Un objeto pasivo (de la clase Controlador de Termómetro dentro de un proceso activo (de la clase activa
Supervisor) que vive dentro de una instancia de componente (de tipo guard.exe, que está asignada al sistema de
horno de microondas (de tipo controlador de horno de microondas)

U n objeto puede ser dibujado directamente dentro de un nodo sin enseñar el componente en el que es
im plementado. L a información acerca del componente al que pertenece es identificada ya sea a través
de la propiedad de lugar o es indefinida.

E n un sistema distribuido, un objeto puede moverse entre nodos diferentes durante la vida de un
sistema. Esto es técnicamente hecho mediante sistemas de objetos distribuidos como CORBA u OLE.
donde los objetos pueden ser transmitidos a través de la red y pueden cambiar su localidad en el
sistema. U n objeto que cam bia su localidad durante la vida del sistema puede ser incluido en todos los
nodos en los que puede existir posiblemente. Para mostrar com o un objeto puede ser distribuido en el
sistema, una dependencia con el estereotipo « b e c o m e s » (transformarse) es dibujada entre las
diferentes ocurrencias del objeto. La dependencia puede contener propiedades que definen el tiempo o
condición que dispara el cambio en la localidad del objeto.
 Página 178 A nálisis y D iseño d e Sistem as con el ÜM I,

Modelaje complejo de nodos

Figura 110: Relaciones entre nodos

Los nodos son definidos com o clases en el UML; por lo tanto, pueden existir relaciones más
complejas entre ellos. E sto es usado cuando se describe una familia de nodos, donde la generalización
se usa para definir una configuración general de nodos y la especialización para capturar casos
especiales. Un nodo también puede tener un role en una asociación y tener una interfaz definida.