Modelando con clase. El rey de la orientación a objetos.

Si alguien se lleva la corona en UML, lo más probable es que sean las clases. Finalmente, todo surgió en un principio en UML debido a la necesidad de unificar los criterios para la representación de la orientación a objetos, y las clases son un elemento básico en este paradigma. Podríamos decir que lo que hemos visto hasta el momento en ediciones anteriores de esta sección, es el preámbulo para llegar a un buen diseño de clases.

Por supuesto que cada artefacto tiene un valor importante en el ciclo de vida. Los casos de uso ayudándonos a identificar y a validar mejor con el usuario sus necesidades; el modelo conceptual (un previo del diagrama de clases) permitiéndonos comprender mejor el problema del usuario; el diagrama de interacción, mostrándonos la colaboración entre los objetos para ejecutar un proceso o un caso de uso. Pero a fin de cuentas, todos estos elementos aportan para llegar al punto que trataremos en esta ocasión: el diseño de las clases que constituirán nuestro sistema.

Efectos del Diagrama de Interacción en las Clases
Vamos a ver cómo es que las decisiones que tomamos en los diagramas de interacción se pueden ver reflejadas en el diagrama de clases. Estas decisiones pueden afectar tanto la funcionalidad de las clases, como las relaciones que debe haber entre éstas.

De acuerdo con lo trabajado previamente, hasta el momento nuestro diagrama de clases debe contar con las clases candidatas a ser de diseño, así como algunos posibles atributos y relaciones (las obtenidas en el modelo conceptual). La figura 1 ilustra una parte del modelo conceptual obtenido al analizar una terminal punto de venta (TPV).

Figura 1. Modelo conceptual del punto de venta.

El diagrama de clases de diseño al que llegaremos, por lo menos en la capa de negocio, probablemente tenga un gran parecido al modelo conceptual que mostramos. Entre los cambios más importantes está la aparición de operaciones y el refinamiento de las relaciones, que se verán reflejadas en el código, como la funcionalidad asignada en cada clase de nuestro sistema y en el mecanismo de comunicación entre ellas, respectivamente.

Las Relaciones y los Mensajes
¿Cómo nos puede ayudar el diagrama de interacción para refinar nuestras clases de diseño? En primer lugar, para identificar relaciones entre dos clases basta con observar cuáles son las que se comunican en el diagrama de interacción, y representarlas con algún tipo de relación en el diagrama de clases. ( Ver Figura 2 )

Figura 2. Diagrama de secuencia para “Realizar Venta”

Como ejemplo, en el diagrama de secuencia ilustrado en la figura 2, se ve cómo la clase TPV (en realidad las instancias de esta clase) requiere comunicarse con Venta para enviarle mensajes, y a su vez Venta requiere comunicarse con los objetos de la clase RenglonVenta. Esto significa que en el diagrama de clases tendremos que mostrar una relación con navegabilidad de TPV a Venta, y otra de Venta a RenglonVenta. (Ver Figura 3)

Figura 3. Relaciones obtenidas del diagrama de secuencia.

Las relaciones mostradas en el diagrama de clases de diseño pudieron o no haber existido durante el modelo conceptual, pero es en este momento (en el diseño) donde se toma la decisión final con respecto a las relaciones a incluir en la construcción (implementación) del sistema orientado a objetos, de conectar o no dichas clases. Recuerda que con fines de diseño, el modelo conceptual no es más que un previo o bosquejo de lo que podría ser nuestro sistema.

Cabe aclarar que el tipo específico de relación se define de una manera más elaborada, tema que será tratado en ediciones posteriores de esta sección. Sólo para no dejar un hueco en la descripción de nuestro ejemplo, hay que mencionar que las relaciones aquí mostradas corresponden a una dependencia y composición, respectivamente.

Los Mensajes y las Operaciones
Las operaciones son uno de los elementos de UML más relevantes para la implementación del sistema, pues proveen el elemento fundamental para ubicar la funcionalidad de nuestro sistema. Una identificación adecuada de las operaciones de cada clase es clave para el desarrollo de un sistema de calidad. Incluso facilitará el contar con cualidades como el “reuso” y “mantenibilidad” del mismo.

El realizar un diagrama de secuencia con una perspectiva de diseño nos puede ayudar a identificar y a ubicar de una mejor manera estas operaciones en sus correspondientes clases. Cuando existe un mensaje entre dos objetos tenemos que tomar la decisión de diseño de usar o no dicho mensaje como una llamada a operación, esto significa que la clase receptora del mensaje tendrá asignada dicha operación en el diagrama de clases de diseño.

Si volvemos al ejemplo ilustrado en la figura 2, podemos observar cómo los cuatro mensajes corresponden a llamadas a operaciones de las clases. Dos de estas operaciones corresponden a constructores de las clases y las otras dos a métodos tradicionales implementadas en las clases que reciben los mensajes.

La clase Venta recibe los mensajes agregarRenglonVenta( ) y registrarPago( ), lo cual se traduce en el diagrama de clases como dos operaciones en dicha clase, como podemos observar en el siguiente diagrama:

Conclusión
Diseñar un sistema orientado a objetos no es cosa fácil, pues requiere tomar diferentes decisiones que sólo el conocimiento de las técnicas y una apropiada experiencia nos permiten lograr. Naturalmente resulta complejo compartir, en un artículo tan breve, todo este conocimiento y experiencia. Pero, en cada uno de estos artículos esperamos poder transmitir lo más relevante para facilitarles el uso de UML como una buena herramienta de desarrollo.