En programación y en el diseño del software es habitual que usemos gráficos para representar partes o el funcionamiento de nuestras aplicaciones. Diagramas de casos de uso, diagramas de secuenciia, diagramas de clases, etc.

Para representar la estructura de clases de un programa lo mas habitual es un diagrama de clases.

Un diagrama de clases es una representación gráfica de la vista estática del conjunto de clases que forman parte de un sistema, junto con las relaciones existentes entre ellas.

Recordemos que una clase es la creadora de los objetos que compartirán atributos, métodos, relaciones y comportamientos. Mediante las clases podemos representar entidades para las operaciones de un programa, una cliente, un producto, una factura…

Como toda entidad, tiene un nombre que la identifica, unos atributos que determinan sus valores o propiedades, y unos métodos que son las acciones que pueden realizar.

En UML la clase la representaremos con un rectángulo dividido en tres compartimentos para:

Nombre: El identificador del objeto. En una aplicación realizada den POO, todo son objetos y es necesario identificar claramente su nombre, de tal modo que tendremos podremos nombrar a cada tipo de objetos (clientes, factura, producto…)
Atributos: Dentro del mismo tipo, todos los objetos son propios (independientes), aunque se relacionaran con otros. Los atributos son los que definen esta individualidad. Por ejemplo; si queremos dar de alta a un cliente, este será un objeto de tipo cliente, pero tendrá su nombre, nº de identificación fiscal, etc.
Métodos: Un objeto es un elemento del programa con el que esperamos poder hacer una serie de acciones. Por ejemplo; si queremos imprimir los datos de un cliente, este tendrá que tener un método para imprimirse.

Cuando diseñamos un programa, realizamos el modelado en UML de las clases del mismo normalmente sin especificar los datos del objeto, los cuales como es obvio variaran según sea el caso.

Pero a la hora de la realización del diseño, debemenos tener siempre en cuenta que un diagrama no es más que la representación gráfica que tendrá nuestra codificación

Veamos un ejemplo de la representación de una clase y un ejemplo del los objetos resultantes.

Si quisiéramos codificar la clase representada sería:

class Cuenta { 
    long numero; 
    String titular; 
    float saldo; 
    float interesAnual; 
    void ingreso(float cantidad) { } 
    void reintegro(float cantidad) { } 
    void ingresoInteresMes() { } 
    boolean enRojos() { } 
    float leerSaldo() { } 
}

class Cuenta {

long numero;

String titular;

float saldo;

float interesAnual;

void ingreso(float cantidad) { }

void reintegro(float cantidad) { }

void ingresoInteresMes() { }

boolean enRojos() { }

float leerSaldo() { }

}

Para representar un diagrama de clases en UML, podemos hacerlo sin poner los atributos y/o métodos, aunque estaría menos definido estaría permitido. Pero si debemos siempre incluir el cuadro para el nombre.

A la hora de realizar nuestros diagramas tendremos que tener en cuenta:

Cuando se dibuja una clase no es obligatorio mostrar ni todos los compartimentos, ni todos los atributos, ni todas las operaciones.
El contexto donde aparece la clase debe ser significativo y contribuir a que el dibujo sea claro y ayude a comprender su utilidad.
Un compartimento vacío no significa que la clase no tenga atributos u operaciones, simplemente se ha decidido no mostrarlos.
Para indicar que hay más atributos u operaciones en un compartimento se termina la lista con puntos suspensivos.

Visibilidad de los atributos

Cuando creamos una clase podemos establecer diferentes niveles de encapsulación de métodos y atributos. Esto definirá la forma en la que se podrá acceder a ellos.

-privado

Cuando esta definido como privado, significa que el método o atributo solo es visible para la propia clase. De tal modo que solo se puede acceder a ellos desde los métodos implementados en ella. En UML se representara poniendo un (-) al inicio de cada método o atriburo.

+público

Este es la opción más permisiva de todas. En este caso al declararlo como público hacemos que sea visible para todas las demás clases. Para definirlo como público se usa el símbolo (+).

#protegido

En el caso de la visibilidad protegida los métodos o atributos serán visibles para las clases que hereden de ella.

class Persona { 
    private String nombre; 
    public int numero; 
    protect String  telf; 
    private void imprimeNombre() { 
    .... 
    } 
    public void publicaNombre() { 
       .... 
    } 
}

class Persona {

private String nombre;

public int numero;

protect String telf;

private void imprimeNombre() {

....

}

public void publicaNombre() {

....

}

Las relaciones entre las clases

En un diagrama de clases básicamente se pueden dar tres tipos de relaciones:

Relación de asociación

Es una relación entre varias clases, incluso puede estar relacionada consigo misma. Los objetos en muchas ocasiones están relacionados por algunos atributos, como puede ser un cliente a un pedido y/o a una factura, etc.

Relación de generalización (herencia)

Es la relación de clases donde una entidad más general se divide en otras más especificas. Son las relaciones de herencia, donde el elemento padre posee los atributos y métodos que heredan todos sus descendientes, mientras que los hijos poseen atributos únicos respecto al padre.

Relación entre dos clases en las que un elemento puede afectar el estado de otro. Esta es la relación menos importante de las comentadas. Simplemente refleja que la implementación de una clase depende del estado de la otra.

Tipos de relación de asociación

Como hemos vimos en el punto anterior, la relación de asociación indica que dos clases se relacionan entre sí. Es decir, para realizar una acción unos objetos necesitas de otras. Esta es la relación más común en nuestros desarrollos. Un ejemplo bastante completo y fácil de entender es el de una factura, la cual necesita de otros objetos como el cliente, los productos, etc.

En el caso de la factura la relación es normal, pues simplemente es ir relacionando los objetos que la componen. Pero en algunos casos esta relación es mas compleja. Y no solo es una asociación de objetos, si no que la existencia de uno depende del otro.

Este tipo de relaciones, donde la existencia del propio objeto depende de la existencia de otro, (y sin ser una herencia), se llaman de composición o agregación.

Pongamos un ejemplo; imaginemos que queremos crear un objeto “mesa”, este constara de varios objetos “pata”. Lo que significa que para poder instanciar la mesa, obligatoriamente necesitaríamos tener instanciadas las patas. De este modo se crea una relación de composición entre ellas.

Si la relación es normal (los objetos no dependen de la existencia del otro) puede representarse por una línea simple.

Otro ejemplo sería, una ventana que tiene un marco, bisagras… Estos objetos componen el objeto principal y, a diferencia de las herencias, son objetos diferentes.

Para diferenciar este tipo de asociaciones existe la agregación o la composición.

Agregación

Implica que una de las clases es el «todo» y la otra «es parte». Este tipo de asociación no obliga a que objetos de las dos clases tengan existencia dependiente una de la otra.

Para representar este tipo de relaciones, podemos un rombo en el principio de la relación. Este será de color blanco para indicar la agregación o negro para la composición.

Composición

A diferencia de la agregación, esta relación sí obliga a la existencia de la otra clase. No puede existir de forma independiente.

Multiplicidad de las asociaciones

La multiplicidad indica el número de objetos que se relacionan con otra. Toda asociación tiene dos multiplicidades, una en cada extremo de la misma.

Por ejemplo, un cliente compra varios productos, pero un producto no puede ser comprado por más de un cliente.

Para indicar la multiplicidad de una relación tenemos que indicar un mínimo y un máximo.

Las multiplicidades que podemos representar son:

- - Uno y solo uno.
  - .1 Cero o uno.
  - Cero o varios.
  - .* Al menos uno.

Clases enumeradas

Un enumerado (o Enum) es una clase en la que solo podemos crear objetos con una especificación determinada. Los enumerados, respecto al resto de clases, sí tienen constructor, debe ser privado y no permitirá la creación de objetos no especificados en la misma.

En UML estas clases no suelen estar relacionadas directamente, pero se representan en el diagrama si se considera necesario.

public enum Tipo { 
    SOBREMESA, PORTATIL, TODOENUNO, MINIPC 
}

public enum Tipo {

SOBREMESA, PORTATIL, TODOENUNO, MINIPC

}

En la mayoría de las ocasiones este tipo de propiedades se puede representar también con una relación de dependencia.

Caso práctico I

Vamos a realizar un caso practico de la elaboración de un diagrama de clases a partir de una serie de requisitos:

Se precisa realizar un diagrama de clases el siguiente sistema para gestionar libros, con las siguientes condiciones:

Los libros tienen un título, año de publicación, género al que pertenece, idioma original y puntuación media.
Un autor o autores, de los que sabemos el nombre, seudónimo y la nacionalidad.
Los libros se organizan en líneas editoriales que tienen un nombre y una referencia, cada línea editorial se crea con el primer libro a la que pertenece.
Los lectores pueden escribir críticas acerca de un libro.
Las críticas tienen una puntuación de 1 a 10, fecha en la que se hizo, nombre de la persona, nacionalidad del que escribe la crítica, edad y el comentario realizado.

Existen varias soluciones, una posible sería:

En la resolución podemos ver como se han relacionado los objetos según las exigencias del enunciado. En este caso de planteamientos, lo importante es siempre empezar por identificar los objetos que compondrán nuestro programa y una vez identificados ver las relaciones que tienen entre ellos.

Ya sea una herencia, como el caso de persona que tiene como hijos a autor y lector, ya que tienen atributos y métodos comunes. Y también, quizá la mas complicada, se sería la de composición entre línea editorial y libro, ya que se trata de dos objetos independientes, pero que en este caso, una línea editorial necesita tener libros para poder existir.

Caso práctico II

Realicemos otro ejemplo partiendo de otro supuesto:

Se quiere realizar una aplicación para la gestión de pedidos de una empresa. Representa el diagrama de clases de dicha aplicación con la siguiente especificación:

La empresa desea guardar la información de los pedidos realizados por los clientes indicando la fecha de realización y la localidad donde reside la empresa cliente.
Cada pedido constará de varios productos.
El precio total del pedido se calcula con todos los productos incluidos, indicando su cantidad e impuestos.
El sistema debe saber el stock de cada producto.
El pago de cada pedido se puede hacer de tres formas diferentes: con tarjeta de crédito, pidiendo la fecha de caducidad y número; en efectivo, pidiendo el tipo de moneda; y mediante cheque, indicando el nombre y el banco.

Una posible solución sería:

Dia diagram editor

Dia diagram Editor es un software gratuito que nos permite realizar cualquier diagrama UML que deseemos, proporcionando asistentes y ayudas para una correcta implementación.

Disponible para las plataformas Windows, Mac y Linux, es una excelente opción para la diagramación UML.

El modelado es multilenguaje, permitiéndonos realizar los diagramas independientemente del lenguaje de programación que vayamos a utilizar.

Dia diagram Editor

Puedes acceder a la página oficial del programa para descargarlo. http://dia-installer.de/