UML Domine el lenguaje de modelado más utilizado en la actualidad

M o d e la r relaciones Multiplicidad en relaciones ternarias Si bien no son muy comunes, podemos llegar a tener situaciones donde inter­ vienen tre s e n tid a d e s en una asociación. Ante estos casos, debemos detenernos ya que si la situación también es modelable a través de dos relaciones binarias en lugar de una ternaria, siempre es aconsejable optar por dos relaciones binarias. Sin embargo, si el contexto realmente requiere una relación ternaria, debemos estar preparados para lidiar con ella y saber utilizarla. Supongamos que deseamos incluir en nuestro modelo la venta de libros. Para cada venta deseamos mantener el o los libros involucrados, el cliente que efectuó la com­ pra y la factura donde se registró la transacción. Esta situación se podría modelar en UML a través de una relación ternaria entre las clases Libro, Factura y Cliente. El análisis de la multiplicidad es un poco menos intuitivo que en las relaciones bina­ rias y debemos proceder de la siguiente manera: tomamos dos de las clases y vemos, para este par, con cuántas instancias de la clase restante se relacionan. Luego, pro­ cedemos de la misma manera cambiando las clases del par. De esta forma, anali­ zando los tres casos, definimos la multiplicidad de la relación. F igu ra 23. Una relación ternaria Venta involucra un cliente, una factura y los libros comprados. El razonamiento para el caso de la figura 23 es el siguiente; • Dados un cliente y una factura, el cliente puede comprar muchos libros. Entonces, la multiplicidad contra el extremo de la clase Libro es Muchos. • Dados un cliente y un libro, puede haber muchas facturas ya que el cliente puede comprar el mismo libro en repetidas ocasiones. Por eso, la multiplicidad contra el extremo de la clase Factura es Muchos. • Dados un libro y una factura, sólo puede haber un único cliente. Entonces, la multiplicidad contra el extremo de la clase Cliente es Uno. 91