Diagrama de Componentes

Las vistas centrales de un modelo arquitectnico son los diagramas de componentes, donde se
muestran los elementos primarios del sistema y cmo dependen unos de otros. Para obtener ms
informacin sobre diagramas de componentes,

Un diagrama de componentes tpico de un sistema grande podra incluir componentes como estos:
Presentacin. Es el componente que proporciona acceso al usuario, normalmente mediante
la ejecucin en un explorador web.
Componentes del servicio web. Proporcionan conexiones entre clientes y servidores.
Controladores de casos de uso. Dirige al usuario a travs de los pasos de cada escenario.
Ncleo del negocio. Contiene clases que se basan en las clases del modelo de requisitos,
implementa las operaciones clave e impone las restricciones del negocio.
Base de datos. Almacena los objetos de negocio.
Componentes de registro y control de errores.

Dependencias entre componentes

Adems de los propios componentes, puede mostrar las dependencias entre ellos. Una flecha de
dependencia entre dos componentes indica que los cambios que se realicen en el diseo de uno de
ellos pueden afectar al diseo del otro. Esto normalmente ocurre porque uno de los componentes
usa los servicios o funciones proporcionados por el otro componente, ya sea de forma directa o
indirecta.
Una arquitectura bien estructurada tiene una organizacin clara de dependencias en las que su
cumplen estas condiciones:
El mapa de cdigo no incluye bucles.
 Los componentes pueden organizarse en capas en las que cada dependencia sale de un
componente de una capa hacia un componente de la siguiente capa. Todas las
dependencias entre dos capas van en la misma direccin.

Puede mostrar las dependencias directamente entre los componentes o puede mostrar las
dependencias entre las interfaces necesarias y proporcionadas que se asocian a los componentes.
Mediante las interfaces, puede definir qu operaciones se usan en cada dependencia. Normalmente,
las dependencias entre componentes se muestran cuando los diagramas se dibujan por primera vez.
Posteriormente, a medida que se agrega ms informacin, se sustituyen por dependencias entre
interfaces. Las dos versiones son descripciones correctas del software, pero la versin con interfaces
proporciona ms detalles que la versin anterior.

La administracin de dependencias es muy importante para la generacin de un software sostenible.

Los diagramas de componentes deben reflejar todas las dependencias del cdigo. Si el cdigo ya
existe, asegrese de que todas las dependencias aparecen en los diagramas. Si el cdigo se est
desarrollando, asegrese de que no contiene dependencias que no estn planeadas en el diagrama
de componentes. Para ayudarle a detectar las dependencias del cdigo, puede generar diagramas de
capas. Para asegurarse de que se cumplen las restricciones de dependencia planeadas, puede validar
el cdigo con los diagramas de capas.

Interfaces
Mediante las interfaces de sus componentes, puede separar los grupos principales de operaciones
que proporciona cada componente y asignarles un nombre. Por ejemplo, los componentes de un
sistema de ventas basado en web podran tener una interfaz a travs de la cual los clientes compran
artculos, una interfaz a travs de la cual los proveedores actualizan sus catlogos y una tercera
interfaz a travs de la cual se administra el sistema.

Un componente puede tener cualquier nmero de interfaces proporcionadas y necesarias. En las

interfaces proporcionadas se muestran los servicios que proporciona el componente para que los
usen otros componentes. En las interfaces necesarias se muestran los servicios que el componente
usa en otros componentes.

Si define tanto interfaces proporcionadas como interfaces necesarias, le ser ms fcil separar
claramente el componente del resto del diseo de modo que pueda usar estas tcnicas:

Coloque el componente en un agente de prueba en el que se simulen los componentes de

alrededor.
Desarrolle el componente independientemente de los dems componentes.
Vuelva a usar el componente en otros contextos acoplando las interfaces a diferentes
componentes.

Si desea definir la lista de operaciones de una interfaz, puede crear otra vista de la interfaz en un
diagrama de clases UML. Para ello, busque la interfaz en el Explorador de modelos UML y arrstrela
hasta un diagrama de clases. A continuacin, puede agregar operaciones a la interfaz.
Una operacin de una interfaz UML puede representar cualquier mecanismo para invocar el
comportamiento de un componente. Podra representar una solicitud de servicio web, una seal o
interaccin de algn otro tipo o una llamada ordinaria a una funcin del programa.

Para determinar qu operaciones se van a agregar, cree diagramas de secuencia en los que se muestre
cmo interactan unos componentes con otros. En cada uno de estos diagramas de secuencia se
muestran las interacciones que se producen en un caso de uso diferente. De esta manera, puede
ampliar gradualmente la lista de operaciones de la interfaz de cada componente a medida que
explora los casos de uso.

Descomponer un componente en elementos

Puede aplicar el procedimiento que se describe en las secciones anteriores a cada componente.
Dentro de cada componente, puede mostrar sus componentes secundarios como elementos. Un
elemento es en realidad un atributo de su componente primario, que es un tipo de clase. Cada
elemento tiene su propio tipo, que puede ser un componente. Puede colocar este componente en un
diagrama y mostrar sus elementos. Es til aplicar esta tcnica a todo el sistema. Dibjelo como un
componente nico y muestre sus componentes principales como elementos. Esto le ayudar a
identificar claramente las interfaces de su sistema en el mundo externo.

A menudo, cuando el diseo de un componente usa otro componente, tiene que decidir si va a
representarlo como un elemento o como un componente independiente al que se obtiene acceso a
travs de una interfaz necesaria.

Use elementos en las siguientes situaciones:

El diseo del componente primario siempre debe usar el tipo de componente del elemento.
Por lo tanto, el diseo del elemento es intrnseco al diseo del componente primario.
El componente primario no tiene una existencia concreta propia. Por ejemplo, puede tener
un componente conceptual denominado Capa de presentacin que represente una
coleccin de componentes reales que controlan vistas e interacciones con el usuario.

Use componentes independientes a los que se obtiene acceso a travs de las interfaces necesarias
en estas situaciones:
El componente que se necesita puede acoplarse a travs de sus interfaces a distintos
componentes proveedores en tiempo de ejecucin.
El diseo se ha realizado de modo que sera fcil reemplazar un proveedor por otro.

El uso de interfaces necesarias normalmente es preferible al uso de elementos. Aunque el diseo

puede llevar ms tiempo, el sistema resultante es ms flexible. Tambin es ms fcil probar los
componentes por separado. Esto permite un grado de acoplamiento menor en los planes de
desarrollo.
Interacciones entre componentes
Las principales recomendaciones de esta seccin son las siguientes:
Identifique los casos de uso del sistema.
En cada caso de uso, dibuje uno o ms diagramas para mostrar el modo en que los
componentes del sistema logran el resultado requerido gracias a la colaboracin entre ellos
y con los usuarios. Normalmente, se tratarn de diagramas de secuencia o de actividades.
Use las interfaces para especificar los mensajes recibidos por cada componente.
Describa los efectos de las operaciones en las interfaces.
Repita el procedimiento con cada componente, mostrando cmo interactan sus
elementos.
Por ejemplo, en un sistema de ventas basado en web, el modelo de requisitos podra definir la compra
de un cliente como un caso de uso. Puede crear un diagrama de secuencia para mostrar las
interacciones que el cliente tiene con los componentes en la capa de la presentacin y para mostrar
las interacciones que tiene con los componentes de contabilidad y almacenamiento.

Identificar los eventos de iniciacin

El trabajo realizado por la mayor parte de los sistemas de software puede dividirse cmodamente
en las respuestas que da a diferentes entradas o eventos. El evento de iniciacin puede ser uno de
los eventos siguientes:
La primera accin de un caso de uso. Podra aparecer en el modelo de requisitos como un
paso de un caso de uso o una accin de un diagrama de actividades. Para obtener ms
informacin.
Un mensaje en una interfaz programtica. Si el sistema que est desarrollando es un
componente de un sistema mayor, debera describirse como una operacin de una de las
interfaces del componente.
Una determinada condicin que el sistema supervisa, o un evento peridico como una hora
del da.

Describir los clculos

Dibuje diagramas de secuencia para mostrar la respuesta de los componentes al evento inicial.
Dibuje una lnea de vida para cada instancia del componente que tome parte en una secuencia
normal. En algunos casos, podra haber varias instancias de cada tipo. Si ha descrito todo su sistema
como un nico componente, deber haber una lnea de vida por cada elemento que contenga.

Los diagramas de actividades tambin resultan tiles en algunos casos. Por ejemplo, si los
componentes tienen un flujo de datos continuo, puede describirlo como un flujo de objeto. Si el
componente tiene un algoritmo complejo, puede describirlo como un flujo de control. Asegrese de
dejar claro qu componente realiza cada accin, por ejemplo, mediante comentarios.

Especificar las operaciones

En los diagramas se muestran las operaciones que realiza cada componente; estas operaciones se
representan como mensajes en un diagrama de secuencia o como acciones en un diagrama de
actividades.
Recopile las operaciones de cada componente. Cree interfaces proporcionadas en el componente y
agregue las operaciones a las interfaces. Normalmente, se usa una interfaz diferente para cada tipo
de cliente. Resulta muy fcil agregar operaciones a las interfaces en el Explorador de modelos
UML. De la misma manera, recopile las operaciones que usa cada componente de los dems
componentes y sitelas en las interfaces necesarias asociadas al componente.

Resulta til agregar comentarios a los diagramas de actividades o a los diagramas de secuencia para
dar cuenta de lo que se ha logrado despus de cada operacin. Tambin puede especificar el efecto
de cada operacin en su propiedad Condicin posterior local.

Modelo de datos de los componentes e interfaces

Defina los parmetros y los valores devueltos de cada operacin de las interfaces de los
componentes. Cuando las operaciones representan invocaciones como solicitudes de servicio web,
los parmetros son esos fragmentos de informacin que se envan como parte de la solicitud.
Cuando se devuelven varios valores de una operacin, puede usar parmetros con la
propiedad Direccin establecida en Fuera.

Cada parmetro y cada valor devuelto tienen un tipo. Puede definir estos tipos mediante los
diagramas de clases UML. No tiene que representar en detalle la implementacin en estos
diagramas. Por ejemplo, si est describiendo los datos que se transmiten en formato XML, puede
usar una asociacin para representar cualquier tipo de referencia cruzada entre los nodos del
cdigo XML y usar las clases para representar los nodos.

Use los comentarios para describir las restricciones de negocio que presentan las asociaciones y
atributos. Por ejemplo, si todos los elementos del pedido de un cliente deben proceder del mismo
proveedor, puede describir esta circunstancia mediante referencias a las asociaciones entre los
elementos del pedido y los elementos del catlogo de productos, y entre los elementos del
catlogo y su proveedor.
Elementos de un diagrama de componentes
En la tabla siguiente se describen los elementos que puede usar en un diagrama de componentes,
junto con sus propiedades principales.

Forma Elemento Descripcin y propiedades principales

1 Componente Un fragmento reutilizable de funcionalidad del

sistema. Un componente proporciona y consume el
comportamiento a travs de interfaces y puede usar
otros componentes.

Puede ocultar o mostrar los elementos internos de un

componente mediante el control Expandir y contraer
(9).

Un componente es un tipo de clase.

- Is Indirectly Instantiated. Si es true (valor

Forma Elemento Descripcin y propiedades principales

predeterminado), el componente solo existe como

artefacto de diseo. En tiempo de ejecucin, solo
existen sus partes.

2 Puerto de la Representa un grupo de mensajes o llamadas que

interfaz implementa un componente y que pueden usar otros
proporcionada componentes o sistemas externos. Un puerto es una
propiedad de un componente que tiene una interfaz
como su tipo.

3 Puerto de la Representa un grupo de mensajes o llamadas que enva

interfaz necesaria el componente a otros componentes o sistemas
externos. El componente est diseado para acoplarse
a componentes que proporcionan al menos estas
operaciones. El puerto tiene una interfaz como su tipo.

4 Dependencia Se puede usar para indicar que una interfaz necesaria

en un componente se puede satisfacer mediante una
interfaz proporcionada en otro.

Las dependencias tambin se pueden usar de manera

ms general entre los elementos del modelo para
mostrar que el diseo de uno depende del diseo del
otro.

5 Parte Un atributo de un componente, cuyo tipo suele ser otro

componente. Un elemento se usa en el diseo interno
de su componente primario. Los elementos se
muestran grficamente, anidados dentro del
componente primario.

Para crear un elemento de un tipo de componente

Forma Elemento Descripcin y propiedades principales

existente, arrastre el componente desde el Explorador

de modelos UML hasta el componente propietario.

Para crear un elemento de un nuevo tipo, haga clic en

la herramienta Componente y, a continuacin, haga
clic en el componente propietario.

Por ejemplo, un componente Car tiene los

elementos engine:CarEngine, backLeft:Wheel, frontRight
:Wheel, etc.

Ms de un elemento puede tener el mismo tipo y

componentes diferentes pueden tener elementos del
mismo tipo.

- Tipo. El tipo del elemento, que se define en otra parte

del modelo. Normalmente, el tipo es otro componente.
- Multiplicidad El valor predeterminado es 1. Puede
establecerlo en 0..1 para indicar que el elemento puede
tener el valor null, en * para indicar que el elemento es
una coleccin de instancias del tipo especificado o en
cualquier expresin que se pueda evaluar en un
intervalo de nmeros.

6 Part Assembly Una conexin entre los puertos de la interfaz necesaria

de un elemento y los puertos de la interfaz
proporcionada de otro elemento. La implementacin de
un ensamblado de elementos puede variar de un
componente a otro. Los elementos conectados deben
tener el mismo componente primario.

7 Delegacin Vincula un puerto a una interfaz de uno de los

elementos del componente. Indica que los mensajes
enviados al componente son administrados por el
 Forma Elemento Descripcin y propiedades principales

elemento o que los mensajes enviados desde el

elemento se envan desde el componente primario.

(sin Generalization Indica que un componente hereda de otro componente.

mostrar) Los elementos y las interfaces se heredan.

9 Control Contraer o selo para mostrar u ocultar los elementos internos de

expandir un componente.

(sin Comentario Para obtener notas adicionales. Puede vincular un

mostrar) comentario a cualquier nmero de elementos del
diagrama mediante la herramienta Conector.

Conclusin
Un diagrama de componentes representa cmo un sistema de software es dividido en componentes
y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos,
cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los diagramas de
Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para
modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son ms parecidos a los diagramas de casos de usos,
stos son utilizados para modelar la vista esttica y dinmica de un sistema. Muestra la organizacin
y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya
todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe
un apartado del sistema.

En l se situarn libreras, tablas, archivos, ejecutables y documentos que formen parte del sistema.

Uno de los usos principales es que puede servir para ver qu componentes pueden compartirse
entre sistemas o entre diferentes partes de un sistema.
Referencias
https://msdn.microsoft.com/es-es/library/dd409390.aspx