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.
Diagrama de componentes del sistema
Aquí hemos modelado la estructura de los componentes software que están involucrados en la aplicación de gestión comercial. Los componentes incorporan puertos hacia los datos o servicios que proporcionan (en el ejemplo “contacto”, “agenda comercial”, etc.) o puertos para recibir datos o resultados de peticiones.
Cada puerto puede tener una o más interfaces. Ampliemos un componente para mostrarlo más en detalle:
Hemos desarrollado el componente “Cliente” en sus partes constituyentes (clases, muy probablemente) y hemos definido sus interfaces a alto nivel. Vemos que básicamente ofrece interfaces de acceso a sus datos (de entrada y salida) y una interfaz de exportación de datos de facturación para comunicarse con la aplicación de contabilidad. Aquí hemos utilizado partes de la notación UML2.0, que diferencia entre interfaces que el componente ofrece (círculo cerrado) e interfaces que el componente necesita (círculo abierto).
Los conceptos de interfaz y puerto serán muy familiares a los estudiantes que tengan experiencia en desarrollo basado en componentes (CORBA, COM, IDL, etc.) pero en la mayoría de los casos no será necesario llegar a este nivel de detalle en el diagrama en aplicaciones orientadas a objeto convencionales.
En otros entornos donde sea habitual utilizar patrones de diseño, los diferentes objetos, interfaces y la comunicación entre ellos se pueden representar en los detalles del componente.
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 delos 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.