Diferencia entre revisiones de «Diagrama de componentes»

De Dos Ideas.
Saltar a: navegación, buscar
(Una guía para construir un diagrama de componentes)
(Una guía para construir un diagrama de componentes)
Línea 7: Línea 7:
 
#Añadir al diagrama todos los '''componentes''' anteriormente creados
 
#Añadir al diagrama todos los '''componentes''' anteriormente creados
 
#Definir las '''relaciones''' que hay entre los componentes
 
#Definir las '''relaciones''' que hay entre los componentes
#Definir que '''interfaces requeridas o expuestas''' contendrá la solución
+
#Definir que '''interfaces expuestas''' contendrá la solución. Las interfaces expuestas pueden tipificarse o clasificarse en requeridas por un componente o provistas por un componente. Por ejemplo, un componente requiere de un servicio externo entonces se utiliza una interfaz requerida. Otro ejemplo, un componente expone un servicio entonces se utiliza una interfaz provista por nuestro software.
  
 
== Ejemplo ==
 
== Ejemplo ==

Revisión del 20:35 20 sep 2011

Los diagramas de componentes muestran las relaciones entre los componentes de software, sus dependencias, comunicación, ubicación y otras condiciones.

Una guía para construir un diagrama de componentes

  1. Pensar en un único diagrama que unifique los componentes de software que utilizaremos en la solución
  2. Dentro de la estructura de proyecto UML es conveniente generar un paquete con todos los componentes a utilizar
  3. Añadir al diagrama todos los componentes anteriormente creados
  4. Definir las relaciones que hay entre los componentes
  5. Definir que interfaces expuestas contendrá la solución. Las interfaces expuestas pueden tipificarse o clasificarse en requeridas por un componente o provistas por un componente. Por ejemplo, un componente requiere de un servicio externo entonces se utiliza una interfaz requerida. Otro ejemplo, un componente expone un servicio entonces se utiliza una interfaz provista por nuestro software.

Ejemplo

DiagramaDeComponentes.jpg

Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre los que estén modelando el sistema.

Ver también