¿que se representa en las clases y diagramas de clases uml?

[Filantropo]

Hola.
Me causa confusion esto del uml, las clases uml se dice que representan la estructura estatica del sistema, en su interior se describen los datos y metodos que tendra la entidad.
Esto suena a clases como las que se escribirian en algun lenguaje de alto nivel C++, java, php, su representacion de rectangulo con atributos y metodos tambien suena a clases de lenguajes de POO.
Pero lo que no entiendo es por que en los diagramas de clase uml las clases tienen lineas de relaciones incluso tienen cardinalidad 1-N , N-N etc,  esto suena a tablas de una BD.
entonces ¿que se representa en un diagrama, las clases de POO o las tablas de una BD?

[K-YreX]

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í:
  
  Código [Seleccionar] Expandir
  
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í:
  
  Código [Seleccionar] Expandir
  
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.

[Filantropo]

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í:
  
  Código [Seleccionar] Expandir
  
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í:
  
  Código [Seleccionar] Expandir
  
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.
  

Hola, gracias me ayudo, buena explicacion, ejemplo, lo entendi a la primera, no le hallaba el sentido ni explicacion a las relaciones de clases, en mis estudios llevaba un tiempo sin entenderlo y nadie sabia explicarme o dar un ejemplo.
Salu2