Simbología y elementos de un diagrama de clases

Iniciado por rubcr, 5 Junio 2020, 12:57 PM

0 Miembros y 1 Visitante están viendo este tema.

rubcr

Hola a todos tengo un diagrama de clases y no acabo de entender los símbolos que aparecen (rombos).
El diagrama es el siguiente:

Espero que alguien pueda echarme una mano.
Un saludo.

K-YreX

Los rombos con relleno (los únicos que aparecen en tu diagrama) representan una relación de composición.
La característica de estas relaciones es que determina una entidad débil (Parque) y una entidad fuerte (Zona). La entidad débil no puede existir por sí misma sin la entidad fuerte, es decir, que no puedes guardar los parques de una zona en tu sistema si no tienes guardada esa zona. De igual manera entre Zoo - Parque, no puedes guardar en tu sistema los Zoos de un parque si no tienes guardado ese parque.
Otra característica es que una instancia de la entidad débil no puede ser compartida por varias de la fuerte. Un Zoo no puede pertenecer a varios parques diferentes.
Y una última característica sería que si en algún momento eliminas la instancia de la entidad fuerte, se deberán eliminar todas las instancias de la entidad débil que estuviesen relacionadas con esa instancia de la fuerte. Resumido: Si en tu sistema eliminas un parque, se deberán eliminar primero todos los zoos de ese parque.

Existe otro tipo de rombo que no está relleno y estos representan relaciones de agregación. Son un poco "la otra mitad":
También podemos diferenciar una entidad débil y una fuerte, y que la débil forma parte de la fuerte, pero en este caso no existe una dependencia tan fuerte como en el caso anterior.
En este caso una instancia de la entidad débil puede estar relacionada con más de una instancia de la entidad fuerte.
Si se elimina la instancia de la entidad fuerte, no se eliminan las instancias de la entidad débil con las que tuviese relación.
Por ejemplo: En un taller, Piezas - Vehículos. Tienen unas piezas guardadas en un almacén y esas piezas se usan para reparar unos vehículos. Pero cuando el vehículo sale del sistema, no tiran todas las piezas que valían para ese vehículo, siguen ahí para utilizarlas con otro.
Código (cpp) [Seleccionar]

cout << "Todos tenemos un defecto, un error en nuestro código" << endl;

rubcr

Cita de: YreX-DwX en  5 Junio 2020, 13:20 PM
Los rombos con relleno (los únicos que aparecen en tu diagrama) representan una relación de composición.
La característica de estas relaciones es que determina una entidad débil (Parque) y una entidad fuerte (Zona). La entidad débil no puede existir por sí misma sin la entidad fuerte, es decir, que no puedes guardar los parques de una zona en tu sistema si no tienes guardada esa zona. De igual manera entre Zoo - Parque, no puedes guardar en tu sistema los Zoos de un parque si no tienes guardado ese parque.
Otra característica es que una instancia de la entidad débil no puede ser compartida por varias de la fuerte. Un Zoo no puede pertenecer a varios parques diferentes.
Y una última característica sería que si en algún momento eliminas la instancia de la entidad fuerte, se deberán eliminar todas las instancias de la entidad débil que estuviesen relacionadas con esa instancia de la fuerte. Resumido: Si en tu sistema eliminas un parque, se deberán eliminar primero todos los zoos de ese parque.

Existe otro tipo de rombo que no está relleno y estos representan relaciones de agregación. Son un poco "la otra mitad":
También podemos diferenciar una entidad débil y una fuerte, y que la débil forma parte de la fuerte, pero en este caso no existe una dependencia tan fuerte como en el caso anterior.
En este caso una instancia de la entidad débil puede estar relacionada con más de una instancia de la entidad fuerte.
Si se elimina la instancia de la entidad fuerte, no se eliminan las instancias de la entidad débil con las que tuviese relación.
Por ejemplo: En un taller, Piezas - Vehículos. Tienen unas piezas guardadas en un almacén y esas piezas se usan para reparar unos vehículos. Pero cuando el vehículo sale del sistema, no tiran todas las piezas que valían para ese vehículo, siguen ahí para utilizarlas con otro.
Y la flecha de empleado que significa?

rubcr


K-YreX

La flecha de Empleado es una relación de Generalización.

Si has trabajado con programación orientada a objetos es la herencia de toda la vida. Lo que quiere decir es que Cuidador y Guía heredan (se especializan) de Empleado. O dicho al revés que Empleado es una generalización de Cuidador y Guía. Se habla de generalización/especialización según si lo miras en un sentido o en otro.

Esto se usa cuando varias clases tienen aspectos en común para no escribirlos dos veces (una vez en cada clase) se hace una superclase (o clase padre) que engloba estos aspectos comunes. Al final el resultado es que si una clase (hija) hereda/se especializa de una clase (padre), la clase hija contendrá de forma implícita todos los atributos y comportamientos (métodos) de la clase padre.

Prácticamente siempre si no siempre se tiene que poder leer como: <clase hija> ES UN <clase padre>. Ejemplos:
  • Cuidador ES UN Empleado.
  • Guía ES UN Empleado.
Código (cpp) [Seleccionar]

cout << "Todos tenemos un defecto, un error en nuestro código" << endl;

ThunderCls

-[ "...I can only show you the door. You're the one that has to walk through it." – Morpheus (The Matrix) ]-
http://reversec0de.wordpress.com
https://github.com/ThunderCls/

rubcr

Cita de: YreX-DwX en  5 Junio 2020, 15:01 PM
La flecha de Empleado es una relación de Generalización.

Si has trabajado con programación orientada a objetos es la herencia de toda la vida. Lo que quiere decir es que Cuidador y Guía heredan (se especializan) de Empleado. O dicho al revés que Empleado es una generalización de Cuidador y Guía. Se habla de generalización/especialización según si lo miras en un sentido o en otro.

Esto se usa cuando varias clases tienen aspectos en común para no escribirlos dos veces (una vez en cada clase) se hace una superclase (o clase padre) que engloba estos aspectos comunes. Al final el resultado es que si una clase (hija) hereda/se especializa de una clase (padre), la clase hija contendrá de forma implícita todos los atributos y comportamientos (métodos) de la clase padre.

Prácticamente siempre si no siempre se tiene que poder leer como: <clase hija> ES UN <clase padre>. Ejemplos:
  • Cuidador ES UN Empleado.
  • Guía ES UN Empleado.
Gracias por responder   :)