Diagrama de clases

Una dependencia es un tipo de asociación donde existe una conexión semántica entre elementos dependientes e independientes del modelo. ^{[ 7 ]} Existe entre dos elementos si los cambios en la definición de uno de ellos (el servidor o destino) pueden provocar cambios en el otro (el cliente o origen). Esta asociación es unidireccional. Una dependencia se representa con una línea discontinua con una flecha abierta que apunta del cliente al proveedor.

Una asociación representa una familia de vínculos estructurales. Una asociación binaria se representa con una línea continua entre dos clases. Una asociación reflexiva es una asociación binaria entre la clase y sí misma. Una asociación entre más de dos clases se representa con un rombo conectado con una línea continua a cada una de las clases asociadas. Una asociación entre tres clases es una asociación ternaria. Una asociación entre más de tres clases se denomina asociación n-aria.

Se puede nombrar una asociación, y sus extremos pueden adornarse con nombres de roles, indicadores de agregación, multiplicidad, visibilidad, navegabilidad y otras propiedades. La notación de punto, por ejemplo, permite representar con un pequeño punto al lado de una clase que el extremo de la asociación pertenece a la otra clase. ^{[ 8 ]}

Existen tres tipos de asociación: asociación simple, agregación compartida y agregación compuesta (composición). Una asociación puede ser navegable en una o más direcciones. La navegabilidad no tiene que especificarse explícitamente. Una flecha abierta en el lateral de una clase indica que se puede acceder a ella de forma eficiente en tiempo de ejecución desde el lado opuesto. La navegación unidireccional se muestra con una pequeña cruz en la línea de asociación del lado de la clase que no es accesible. Por ejemplo, una clase de vuelo se asocia bidireccionalmente con una clase de avión.

La agregación es una variante de la relación de asociación "tiene un"; sin embargo, es más específica que la asociación. Representa una relación de parte-todo o parte-de. Como se muestra en la imagen, un profesor "tiene" una clase que impartir. Al igual que una asociación, una agregación puede nombrarse y tener los mismos adornos que una asociación. No obstante, una agregación no puede involucrar más de dos clases; debe ser una asociación binaria. Además, durante la implementación, apenas existe diferencia entre agregaciones y asociaciones, y el diagrama puede omitir por completo las relaciones de agregación. ^{[ 9 ]}

La agregación puede ocurrir cuando una clase es una colección o contenedor de otras clases, pero las clases contenidas no tienen una fuerte dependencia del ciclo de vida del contenedor. El contenido del contenedor sigue existiendo cuando este se destruye.

En UML , se representa gráficamente como un rombo hueco en la clase contenedora, con una sola línea que lo conecta a dicha clase. El agregado es semánticamente un objeto extendido que se trata como una unidad en muchas operaciones, aunque físicamente está compuesto por varios objetos más pequeños.

La relación de agregación compuesta (o simplemente composición) es una forma más fuerte de agregación donde el agregado controla el ciclo de vida de los elementos que agrupa. Su representación gráfica consiste en un rombo relleno en el extremo de la línea que conecta las clases contenidas con la clase contenedora.

Relación de composición

1. Al intentar representar relaciones de todo-parte del mundo real, por ejemplo, un motor es una parte de un automóvil.

2. Cuando se destruye el contenedor, también se destruye su contenido, por ejemplo, una universidad y sus departamentos.

Relación de agregación

1. Al representar una relación de software o base de datos, por ejemplo, el motor del modelo de automóvil ENG01 forma parte de un modelo de automóvil CM01, ya que el motor, ENG01, también puede formar parte de un modelo de automóvil diferente. ^{[ 10 ]}

2. Cuando el contenedor se destruye, el contenido generalmente no se destruye, por ejemplo, un profesor tiene estudiantes; cuando el profesor deja la universidad, los estudiantes no se van con el profesor.

Por lo tanto, la relación de agregación suele ser una contención de "catálogo" para distinguirla de la contención "física" de la composición. UML 2 no especifica ninguna semántica para la agregación en comparación con la asociación simple.

La relación de generalización —también conocida como herencia o relación "es un" — refleja la idea de que una clase, la llamada subclase , es una forma especializada de la otra (la superclase , supertipo o clase base ). Cuando se cumple esta relación, la superclase se considera una generalización de la subclase. En la práctica, esto significa que cualquier instancia de la subclase es también una instancia de la superclase. Un ejemplo de árbol de generalizaciones de esta forma se encuentra en la clasificación biológica , donde, por ejemplo, el ser humano es una subclase del simio , que a su vez es una subclase del mamífero , y así sucesivamente. La relación se comprende mejor con la frase "un A es un B " (un ser humano es un mamífero, un mamífero es un animal).

La representación gráfica UML de una generalización es un triángulo hueco situado en el extremo de la superclase de la línea (o árbol de líneas) que la conecta con uno o más subtipos.

 símbolo de generalización (subclase) ———————▻ (superclase)

Dual a la generalización es la relación de especialización . Otros términos para una subclase (especializada) de una superclase más general incluyen subtipo , clase derivada , tipo derivado , clase heredada , tipo heredado , hijo y clase hija .

Cabe señalar que esta relación, si bien es similar a la relación biológica entre padres e hijos, es distinta de ella. El uso de los términos padre/madre e hijo/a es sugerente, pero puede resultar engañoso.

A es un tipo de B

Por ejemplo, "un roble es un tipo de árbol", "un automóvil es un tipo de vehículo".

La generalización solo puede mostrarse en diagramas de clases y en diagramas de casos de uso .

En el modelado UML, una relación de realización es una relación entre dos elementos del modelo, en la que un elemento del modelo (el cliente) realiza (implementa o ejecuta) el comportamiento que especifica el otro elemento del modelo (el proveedor).

La representación gráfica UML de una Realización es un triángulo hueco en el extremo de la interfaz de la línea discontinua (o árbol de líneas) que la conecta con uno o más implementadores. Se utiliza una punta de flecha simple en el extremo de la interfaz de la línea discontinua que la conecta con sus usuarios. En los diagramas de componentes, se utiliza la convención gráfica de rótula (los implementadores muestran una rótula o piruleta, mientras que los usuarios muestran un enchufe). Las Realizaciones solo se pueden mostrar en diagramas de clases o componentes. Una realización es una relación entre clases, interfaces, componentes y paquetes que conecta un elemento cliente con un elemento proveedor. Una relación de realización entre clases/componentes e interfaces muestra que la clase/componente realiza las operaciones ofrecidas por la interfaz.

 símbolo de realización (implementador) -------▻ (interfaz)

La dependencia puede ser una forma más débil de vínculo que indica que una clase depende de otra porque la utiliza en algún momento. Una clase depende de otra si la clase independiente es una variable de parámetro o una variable local de un método de la clase dependiente. A veces, la relación entre dos clases es muy débil. No se implementan con variables miembro en absoluto, sino que se implementan como argumentos de funciones miembro.