 Autor
|
Tema: Simbología y elementos de un diagrama de clases (Leído 4,063 veces)
|
rubcr
 Desconectado
Mensajes: 51
|
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.
|
|
|
|
|
En línea
|
|
|
|
K-YreX
Desconectado
Mensajes: 1.008
|
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.
|
|
|
|
|
En línea
|
cout << "Todos tenemos un defecto, un error en nuestro código" << endl;
|
|
|
rubcr
Desconectado
Mensajes: 51
|
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?
|
|
|
|
|
En línea
|
|
|
|
rubcr
Desconectado
Mensajes: 51
|
Y la flecha de empleado que significa? Composición?
|
|
|
|
|
En línea
|
|
|
|
K-YreX
Desconectado
Mensajes: 1.008
|
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.
|
|
|
|
|
En línea
|
cout << "Todos tenemos un defecto, un error en nuestro código" << endl;
|
|
|
|
|
rubcr
Desconectado
Mensajes: 51
|
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 
|
|
|
|
|
En línea
|
|
|
|
rubcr
Desconectado
Mensajes: 51
|
Gracias por la información.
|
|
|
|
|
En línea
|
|
|
|
|
| Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
|
Diagrama de clases
Java
|
Franer
|
2
|
4,092
|
11 Octubre 2012, 17:28 pm
por Nephewless
|
|
|
|
Dudas sobre Diagrama de Clases ... !
Programación General
|
llAudioslavell
|
4
|
3,475
|
17 Noviembre 2011, 05:18 am
por llAudioslavell
|
|
|
|
Diagrama de clases, urgente
Java
|
el_otro_yo
|
2
|
3,114
|
17 Agosto 2012, 02:02 am
por leogtz
|
|
|
|
Ayuda con un diagrama de clases para un proyecto sobre Venta de Artículos
Programación General
|
arts
|
1
|
2,764
|
1 Noviembre 2013, 19:07 pm
por arts
|
|
|
|
Consulta sobre diagrama de clases de un consultio oftalmologico
Dudas Generales
|
itzg3
|
0
|
2,424
|
3 Junio 2020, 18:26 pm
por itzg3
|
 |
