Prof. Hooberth Chávez Bedoya
Un diagrama de componentes es un diagrama de clases a gran escala. Cada componente en el diagrama debe ser documentado con un diagrama de componentes más detallado, un diagrama de clases, o un diagrama de casos de uso. Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones Muestran las opciones de realización incluyendo código fuente, binario y ejecutable Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas Un módulo de software se puede representar como componente.
Se utilizan para modelar la vista estática de un sistema. Muestra la organización 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. Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.
Los artefactos de los que depende su construcción son: ◦
◦
Diagrama de objetos Diagrama de clases
Los artefactos que se generan a partir del diagrama de complementos son: ◦
◦
Diagrama de ejecución Diagrama de despliegue
Es una parte física reemplazable de un sistema que empaqueta su implementación y es conforme a un conjunto de interfaces a las que proporciona su realización. Los componentes tienen dos características: Empaquetan el código que implementa la funcionalidad de un sistema, y algunas de sus propias instancias de objetos que constituyen el estado del sistema. Los llamados últimos componentes de la identidad, porque sus instancias poseen identidad y estado.
Transacciones
componente
Relación de uso
Cliente: PC
Nodo físico
Un módulo de software se puede representar como componente. Algunos componentes existen en tiempo de compilación, algunos en tiempo de enlace y algunos en tiempo de ejecución, otros en varias de éstas. Un diagrama de componentes muestra clasificadores de componentes, las clases definidas en ellos, y las relaciones entre ellas. Los clasificadores de componentes también se pueden anidar dentro de otros clasificadores de componentes para mostrar relaciones de definición.
Normalmente los diagramas de componentes se utilizan para modelar código fuente, versiones ejecutables, bases de datos físicas, entre otros. Un diagrama de componentes se representa como un grafo de componentes software unidos por medio de relaciones de dependencia. Puede mostrar también que un componente software contiene una interfaz, es decir, la soporta.
Un estereotipo es la forma de clasificar las clases de alto nivel. Los estereotipos se muestran con doble ángulo. Ej: <> UML define cinco estereotipos estándar que se aplican a los componentes: ◦
◦
◦
◦
◦
Especifica un componente que se puede ejecutar en un nodo. Especifica una biblioteca de objetos estática o dinámica. Especifica un componente que representa una tabla de una base de datos. Especifica un componente que representa un documento que contiene código fuente o datos. Especifica un componente que representa un documento.
Se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente Sí un componente es la realización de una interfaz, se representa con un círculo unido al símbolo del componente por un segmento de línea.
Así si tenemos en cuenta las dependencias asociadas al proceso de compilación un componente podría ser: que depende de otros componentes (no necesariamente código fuente) que deben estar disponibles durante la compilación del componente. , como por ejemplo una librería que puede depender de otros programas ejecutables con los que interacciones en tiempo de ejecución.
Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación Son paquetes estereotipados en <>
Los subsistemas organizan la vista de realización de un sistema Cada subsistema puede contener componentes y otros subsistemas La descomposición en subsistemas no es necesariamente una descomposición funcional La relación entre paquetes y clases en el nivel lógico es el que existe entre subsistemas y componentes en el nivel físico Paquetes (Categorías) y clases en el nivel lógico. Paquetes (Subsistemas) y componentes en el nivel físico
Son los puntos visibles de entrada o los servicios que un componente está ofreciendo y dejando disponibles a otros componentes y clases. Típicamente, un componente está compuesto por numerosas clases y paquetes de clases internos. También se puede crear a partir de una colección de componentes más pequeños. La estructura estática, ejecutable de una implementación de un sistema se puede representar como un conjunto interconectado de componentes.
Las dependencias entre componentes significan que los elementos de la implementación en un componente requieren los servicios de los elementos de implementación en otros componentes. Tal uso requiere que dichos elementos sean de visibilidad pública.
Un componente de identidad tiene identidad y estado. Posee los objetos físicos que están situados en él. Puede tener atributos, relaciones de composición con los objetos poseídos, y asociaciones con otros componentes. Desde este punto de vista es una clase. Sin embargo la totalidad de su estado debe hacer referencia a las instancias que contiene.
Un componente ofrece un conjunto de elementos de implementación, esto significa que el componente proporciona el código para los elementos. Un componente de identidad es un contenedor físico para las entidades físicas como bases de datos. Para proporcionar manejadores para sus elementos contenidos, puede tener atributos y asociaciones salientes, que deben ser implementadas por sus elementos de implementación.
En un diagrama de componentes representa una división física del sistema. Los paquetes se organizan en una jerarquía de capas donde cada capa tiene una interfaz bien definida. Un ejemplo típico de una jerarquía en capas de este tipo es: Interfaz de usuario; Paquetes específicos de la aplicación
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o tipos de nodos. Se representa como un cubo 3D en los diagramas de implementación.
Los componentes pueden tener requisitos adjuntos para indicar sus obligaciones contractuales; esto es, qué servicios proveen en el modelo. Los requisitos ayudan a documentar el comportamiento funcional de los elementos de software.
Los componentes pueden tener restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna función; las post-condiciones indican lo que debe ser verdadero después de que un componente haya realizado algún trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente.
El diagrama puede usarse para mostrar interfaces y las dependencias de llamada entre componentes, usando flechas con líneas discontinuas desde los componentes a las interfaces de otros componentes. El diagrama de componente hace parte de la vista física de un sistema, la cual modela la estructura de implementación de la aplicación por sí misma, su organización en componentes y su despliegue nodos de ejecución. Esta vista proporciona la oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos. La vista de implementación se representa con los diagramas de componentes.
