Diagrama de clases interfaces

Diagrama de clases de dependencia

Los componentes pueden ser de software, como una base de datos o una interfaz de usuario; o de hardware, como un circuito, un microchip o un dispositivo; o de una unidad de negocio, como un proveedor, una nómina o un envío.

Las interfaces de los diagramas de componentes muestran cómo se conectan los componentes entre sí e interactúan. El conector de ensamblaje permite enlazar la interfaz requerida del componente (representada con un semicírculo y una línea continua) con la interfaz proporcionada (representada con un círculo y una línea continua) de otro componente. Esto muestra que un componente proporciona el servicio que el otro requiere.

Aunque puede mostrar con más detalle la relación entre dos componentes utilizando la notación de bola y conector (interfaz proporcionada e interfaz requerida), también puede utilizar una flecha de dependencia para mostrar la relación entre dos componentes.

Puedes utilizar un diagrama de componentes cuando quieras representar tu sistema como componentes y quieras mostrar sus interrelaciones a través de interfaces. Le ayuda a hacerse una idea de la implementación del sistema. A continuación se indican los pasos a seguir para dibujar un diagrama de componentes.

Interfaz en el diagrama de clases

Tengo el siguiente caso. Tengo una interfaz A y una implementación AImpl. Ahora tengo otra implementación de A, llamada A2Impl, que hace referencia a cualquier instancia de A además de implementar ya A.

Si A2Impl tiene una referencia permanente a otra instancia de A, sería mejor sustituir la dependencia por una asociación (una flecha con una línea sólida en lugar de una línea discontinua). Es posible que desee añadir multiplicidades a la asociación (no es obligatorio). En la figura siguiente, he especificado la multiplicidad «1» para indicar que cada instancia de A2Impl siempre se refiere exactamente a una instancia de A.

Diagrama de clases

El diagrama de clases es una técnica de modelado central que recorre casi todos los métodos orientados a objetos. Este diagrama describe los tipos de objetos del sistema y los distintos tipos de relaciones estáticas que existen entre ellos. Hay tres tipos principales de relaciones que son importantes: asociaciones (un cliente puede alquilar varios vídeos), subtipos (una enfermera es una clase de persona) y agregación (un motor forma parte de un avión). Todos los métodos de programación orientada a objetos utilizan una terminología diferente (y a menudo contradictoria) para estos conceptos, lo cual es muy frustrante, pero inevitable: Los lenguajes OO son igual de desconsiderados. Es en esta área donde el UML aportará algunos de sus mayores beneficios al simplificar estos diferentes diagramas. En esta sección utilizaré los términos UML como terminología principal, y me referiré a otros términos a medida que avance.

Antes de empezar a describir los diagramas de clases, tengo que destacar una sutileza importante en la forma en que la gente utiliza los diagramas de clases. Se trata de una sutileza que no suele estar documentada, pero que tiene un impacto importante en la forma en que se debe interpretar un diagrama, ya que realmente tiene que ver con lo que se está describiendo con un modelo. Siguiendo el ejemplo de [Cook y Daniels] digo que hay tres perspectivas que se pueden utilizar al dibujar diagramas de clase (o de hecho cualquier modelo, pero es más notable en los diagramas de clase).

Estática en el diagrama de clase

Nos hemos centrado en el tipo de información que debe incluirse en la documentación sobre arquitectura. En cierto sentido, la arquitectura expresa lo esencial de un sistema de software, y esa esencia es independiente de los lenguajes y notaciones para capturarla. Sin embargo, hoy en día el Lenguaje Unificado de Modelado (UML) ha surgido como la notación estándar de facto para documentar una arquitectura de software. Sin embargo, hay que decir que UML hace su principal aportación en la presentación primaria de una vista, y su contribución secundaria en el comportamiento de un elemento o grupo de elementos. Corresponde al arquitecto aumentar las imágenes UML con la documentación de apoyo necesaria (el catálogo de elementos, la justificación, etc.) que requiere un trabajo responsable. UML no proporciona soporte directo para componentes, conectores, capas, semántica de interfaces o muchos otros aspectos de un sistema que son supremamente arquitectónicos.

Aún así, en la mayoría de los casos podemos utilizar las construcciones que UML ofrece para lograr efectos satisfactorios, al menos en la elaboración de las presentaciones primarias de las vistas arquitectónicas. Empezaremos hablando de las vistas de módulo.