OOP(V) – Diseñando la aplicación. EL diagrama de clases

Supongo que ya empezareis a sospechar que se tiene que escribir bastante, y si después de los casos de usos, queréis detallar o aclarar la situación con historias de usuario, sospecho que habréis tenido que retocar los casos de uso, y los diagramas de casos de uso, Pero eso os demuestra que vuestro análisis avanza, y que no os dejáis nada importante en el tintero. Ahora llega el momento de empezar a unir las piezas del puzzle con diagramas de conjunto

Diagrama de clases

El diagrama mas habitual que os podéis encontrar es el «Diagrama de clases», se trata de una especialización del diagrama del modelo conceptual en donde ya especificamos atributos y métodos.

Realmente, el único problema es que se puede llegar a complicar, por lo que deberemos segmentarlo en paquetes, y mostrar solo los atributos y métodos que necesitemos en la vista concreta.

Poco a poco nos hemos ido acercando al código, y en este diagrama, esto se hace evidente. Ahora ya deberemos a cuidar los nombres que demos a clases, atributos y métodos, ya que deberían ser los que se utilicen en el momento de programar.

En UML las clases se representan con un rectángulo dividido en tres partes:

• En la parte superior, aparece el nombre de clase, en este punto, ya procuraremos dar nombres correctos, y utilizar la notación UpperCamelCase, esto es, el nombre de clase empieza con mayúscula y si esta formado por mas de una palabra, todos los inicios de palabra empiezan en mayúscula, y utilizaremos las palabras en singular
• En la siguiente caja, indicaremos los atributos; por lo menos los que afectan al diagrama que estamos dibujando.La notación a emplear seria lowerCamelCase, en donde la primera letra de conjunto siempre es minúscula. También podemos añadir indicaciones acerca de si el atributo es (+)publico, (-)privado o  (#)protected, y el tipo de atributo (Entero, Cadena,…)
• En la ultima caja, aparecen los métodos; como en el caso de atributos, la notación a emplear seria lowerCamelCase, en donde la primera letra de conjunto siempre es minúscula y con indicaciones acerca de si el método es (+)publico, (-)privado o  (#)protected,  el tipo de devolución (Entero, Cadena,…), y le indicaremos si tiene atributos, y de que tipo los espera.

Tenéis mas información acerca de los diagramas de clase en la introduccion al UML

A continuación  podéis ver una posible representación de un carrito de compra con las clases Cliente y Artículos. Se trata solo de una visión parcial, pero creo que nos aclarara el tema:

En el diagrama de clases, podemos ver tres clases, y la relación numérica que existe entre ellas

También veréis que procuramos cumplir con la encapsulación, dejando todos los atributos como privados, para que no puedan ser alterados desde fuera de las clases, y a cambio, generaremos métodos para leerlos y modificarlos. Estos métodos son conocidos como «getters» y «setters» y deberíamos llamarlos con la partícula «get» o «set» y el nombre del atributo sobre el que actúa, entre otros motivos, porque nos podemos encontrar entornos en que esos métodos son creados automáticamente con esa estructura…

Este diagrama se debería parecer mucho al modelo conceptual desarrollado anteriormente, con las salvedades de que al estar mas cerca del código, empezaremos a acercarnos a él , dibujando las clases necesarias, y nombrándolas adecuadamente.

Asociaciones

Un diagrama de clases no tendría sentido si no pudieramos expresar las relaciones que existen entre las clases

En el diagrama precedente,mostramos las distintas clases de asociación:

1. Generalización/especialización o herencia, en donde vemos un objeto usuario y de él «heredan» dos objetos:
   • Cliente
   • Proveedor
2. Composicion: Relación todo-parte, en donde la clase parte, no tiene sentido sin el todo. En nuestro ejemplo, CarritoCompra o PedidoCompra no tiene sentido sin Cliente o Proveedor respectivamente
3. Agregación: en donde ambas clases pueden tener vida independiente y no necesitan de la otra para ser creadas

En las asociaciones, también podemos indicarle la Cardinalidad, como ya habíamos comentado.

Interfaces

Al diagrama también le podemos añadir información acerca de las interfaces que tiene que implementar una clase.

Una interface establece los métodos y constantes que debe «obligatoriamente» contener la clase que la implementa. Esa implementan, se define por la linea de puntos acabada en una flecha vacía en el lado de la Interface.

En nuestro ejemplo, estamos indicando que la clase Usuario debe implementar la interface Persistencia, por lo que deberemos programar todos los métodos allí definidos.

Tened en cuenta que en las interfaces no se programa nada; solo se relacionan los métodos que deberán tener las clases, y en cada clase se escribirá esa parte del programa.

Polimorfismo

Es polimorfismo, es la capacidad que tienen los objetos para responder de forma distinta ante una misma llamada.

Este comportamiento lo podemos realizar a través de herencia o a través de interfaces.

La funcionalidad se genera por medio de el desarrollo de los métodos adecuados en cada clase, respetando la firma, pero realizando el trabajo que en cada caso se considere necesario.

En nuestro ejemplo anterior, hacíamos que Cliente y Proveedor heredaran de usuario. En la clase padre,podríamos haber declarado un método para verSituacionEconomica(), o haber creado una interface,y decir que Usuario(y sus herederos) la implementaban.

Si la hubiéramos declarado en la clase Usuario, al escribir Cliente y Proveedor, puede que nos interesase cambiar alguna cosa; por ejemplo, en el caso de cliente, podría interesarnos saber si tiene algún Carrito de compra activo, y si fuera así, deberíamos reprogramar el método (sobrecargar), en esta clase.

Si lo hubiéramos hecho por Interface, entonces nos veríamos obligados a escribir el método en ambas clases, en cualquier caso, cuando, en un objeto, se ejecutara el método «verSituacionEconomica()», se comportaría de una forma o de otra según ese objeto se hubiera creado con Usuario, con Cliente, o con Proveedor