Tal y como dices, los diagramas uml se asemejan bastante a las clases cuando hablamos de POO, sin embargo; que aparezcan relaciones no significa que hagan referencia a bases de datos. Las relaciones son necesarias también para saber cómo interactúan unas clases con otras y además existen pequeños detalles que se pueden apreciar en la implementación.
Te pongo un ejemplo donde creo que se puede ver bien:
Imagina que estás creando una aplicación para un banco donde entre otras muchas cosas tienes una clase Cliente y otra clase Cuenta. Según cómo definas la relación entre ambas clases tendrás una estructura u otra.
- Según la cardinalidad: Definimos si hace falta utilizar una colección de datos (array u otras) para relacionar los datos. Por ejemplo: "Un cliente puede tener una o más cuentas pero una cuenta solo puede ser de un cliente" esto suena a diagrama entidad-relación de bases de datos pero también se aplica a las clases de tu programa. Las clases de tu aplicación quedarían así:
class Cuenta {
string numeroCuenta;
Cliente propietario;
//...
}
class Cliente {
string nombre;
Array<Cuenta> cuentas;
//...
} - Según la dirección: La dirección de la relación indica qué clase conoce (y puede acceder) a las instancias de la otra. Aunque en UML se suelen usar relaciones bidireccionales (sin punta de flecha), también se pueden hacer unidireccionales. Por ejemplo imagina la relación anterior Cliente-Cuenta pero en este caso unidireccional: Cliente -> Cuenta (solo el cliente conoce sus cuentas entonces desde un cliente puedes acceder a sus cuentas pero desde una cuenta no puedes acceder a su propietario) Esto en tus clases se representaría así:
class Cuenta {
string numeroCuenta;
}
class Cliente {
string nombre;
Array<Cuenta> cuentas;
} Mediante UML se puede llegar a un nivel de precisión muy alto aunque no está muy estandarizado. Sí que existen algunos estándares a seguir pero a la hora de la verdad cada uno utiliza los elementos que cree convenientes para representar la información.
Hace un año tuve que preparar unas cosas mediante UML y me costó mucho trabajo encontrar algo de información en claro así que al final acabé leyendo por encima la guía "UML 2 Certification Guide Fundamental & Intermediate Exams (Tim Weilkiens y Bernd Oestereich)" y más o menos pude apañarme aunque es muy extensa pues está preparada precisamente para los exámenes de certificación en UML.
Yo creo que al final UML está ahí como un modelo teórico para representar las ideas de forma rápida y más o menos común para que todo el que conozca UML pueda entenderlo pero al final cada empresa o grupo de trabajo se crea sus propias anotaciones para entenderse. Mientras tanto emisor como receptor entiendan el diagrama, queda muy abierto a posibilidades.
Autor
En línea
