UML es sólo un lenguaje para expresar tus modelos software. Sí, el más utilizado y más popular (aunque siempre mejorable)  pero un lenguaje nada más. No es una metodología ni viene con explicaciones acerca de qué diagrama usar en cada momento. Su gran ventaja es que es suficientemente expresivo como para cubrir todas tus necesidades de modelado, sea cual sea la fase de desarrollo en la que se encuentre tu proyecto.

Pero esto es una arma de doble filo, ya que tenemos que aprender que subconjunto de la notación UML hay que usar en cada momento. No sólo qué diagramas corresponden a cada etapa del proceso (ej. supongo que todo el mundo entiende que los diagramas de componentes y de despliegue sólo tiene sentido utilizarlos en fases avanzadas del proyecto) sino también que elementos de un mismo diagrama son apropiados en cada momento. Y esto ya es más difícil.

Obviamente, no pretendo en este post dar una guía completa de como utilizar UML (y tampoco muchos de vosotros estarías de acuerdo conmigo). Pero sí sacar a relucir que no es suficiente que un equipo se ponga de acuerdo en utilizar UML, hay que ponerse de acuerdo en cómo utilizarlo.

Os pongo un pequeño ejemplo, que, confieso, es también una manía mía: el uso de la navegabilidad en modelos conceptuales.

Los que han trabajado conmigo ya saben que no soporto ver “flechitas” en un diagrama de clases que represente el modelo de dominio del sistema (es decir, un modelo del conocimiento que necesita el sistema para poder operar).

Una fecha expresa en una asociación en UML expresa que esa asociación se puede navegar únicamente en la dirección de la flecha. Veamos un ejemplo. La figura muestra que un Empleado está asociado a un departamento y que éste, a su vez, puede tener varios empleados en él. Pero además indica que la asociación sólo se puede recorrer en la dirección Employee-to-Department y no en la contraria. En cambio, si no hubiera la punta de flecha se interpreta que la asociación es navegable en los dos sentidos.

Notation to express association directions

El propio standard UML define el concepto de Navigability como:

Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient – UML standard

Fijaros en el énfasis en los detallos más técnicos y de implementación en la definición. Y es por eso que me niego a usar la navegabilidad en modelos de dominio. En este tipo de modelos nos preocupamos en definir la informació del sistema y, conceptualmente, sólo queremos expresar que los objetos Empleado y Departamento están relacionados. Si luego la implementación, por temas de eficiencia, sólo permitirá la navegación en un sentido u otro ahora no me importa.

Esta discusión la tendremos y modelaremos cuando procedamos a la fase del diseño, donde refinaremos los modelos de análisis con este tipo de detalles más técnicos.

En los dos casos usamos UML y en concreto los diagramas de clases para especificar la perspectiva del sistema que nos interesa en cada momento. Cada perspectiva incluye un cierto número de elementos UML para llegar al nivel  de detalle que queremos en una fase del proceso de desarrollo en concreto. Ni más ni menos.