• Executable: Especifica un componente que se puede ejecutar en un nodo. Library: Especifica una biblioteca de objetos estática o dinámica.
• Table: Especifica un componente que representa una tabla de una base de datos.
• File: Especifica un componente que representa un documento que contiene código fuente o datos.
• Document: Especifica un componente que representa un documento
Dependencias entre componentes
Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente.
Subsistemas
• 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 <subsistemas
• 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 queexiste entre subsistemas y componentes en el nivel físico
• Paquetes (Categorias) y clases en el nivel lógico. Paquetes (Subsistemas) y componentes en el nivel físico
El desarrollo orientado a objeto está muy relacionado con el desarrollo basado en componentes, en el sentido de que las clases con sus propiedades de encapsulación y abstracción se ven en muchas ocasiones como componentes cerrados de un sistema. Así pues, la notación UML incluye un diagrama de componentes que según la definición del OMG “muestra las dependencias entre componentes software, incluyendo los clasificadores que los especifican (por ejemplo las clases de implementación) y los artefactos que los implementan, como los ficheros fuente, binarios, scripts, etc.”.
En muchos casos en los que podrían usarse diagramas de componentes, se usan los diagramas de despliegue (que veremos más adelante), ya que éstos nos permiten modelar además dónde va a implantarse cada componente y bajo qué configuración o parámetros. Así pues, el diagrama de componentes ha quedado tradicionalmente relegado a modelar la arquitectura del sistema a nivel lógico o de entorno de negocio
Finalmente, la lista de buenas prácticas en la representación de componentes es la siguiente:
• Aplicar los estereotipos de forma consistente.
• Aunque usemos UML 1.5, la representación de las interfaces de los componentes mediante círculos es mucho más clara que una simple flecha entre ellos.
• Ya que la interfaz es un conjunto de métodos, intentemos no representar demasiadas interfaces, es aconsejable agruparlas bajo un mismo nombre y crear después un diagrama detallado del componente.
• Los componentes pueden heredar unos de otros. En este caso, la flecha que utilizamos en los casos de uso para expresar generalización puede servir perfectamente.
• Para mejorar la comprensión de un diagrama de componentes, es preferible conectarlos siempre a través de interfaces. Es más consistente y evita confusiones o dudas sobre su interpretación.
UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf
Ingeniería de Software. Modelo de implementación: Diagrama de componentes y despliegue. Recuperado el 20 de Noviembre 2011, de http://www.dsi.uclm.es/asignaturas/42530/pdf/M2tema12.pdf
No hay comentarios:
Publicar un comentario