Comenzaste a desarrollar tus diagramas de casos de uso para tu primer proyecto en forma. Antes de darte cuenta, ya tienes tantos casos de uso en un mismo diagrama que empiezas a dudar que la presunta simplicidad de los modelos aplique para tí. Lo mismo te puede estar pasando con otros diagramas, como el de clases y componentes.

No te preocupes, sólo tienes que aplicar la antigua, pero a la vez actual filosofía de “divide y vencerás”. Es decir, divide tu modelo (de casos de uso o de clases) en varias partes agrupando elementos que tengan algún tipo de coincidencia entre sí. Te aseguro que tu vida será más fácil en el manejo de tus modelos, y la comunicación con las personas que tengan que revisar tus modelos será más fluída.

El elemento de UML que nos salva de estas situaciones es simple, pero eficaz: el paquete. Probablemente ya lo hayas visto. Es ese símbolo en forma de folder con una pestaña. La analogía es apropiada para su significado. Así como organizamos documentos en folders organizamos casos de uso, clases, componentes, actores y todo tipo de elementos en los paquetes de UML.

Paquetes de Casos de Uso

¿Te ha tocado desarrollar, o por lo menos ver diagramas gigantescos con decenas de casos de uso? A mí sí, y uno puede sentirse abrumado entre tanta información.

Los modelos tienen que facilitarte la comunicación, tienen que facilitar la comprensión del sistema. Por ejemplo, los diagramas de casos de uso deberían facilitar la comunicación con tus usuarios y demás stakeholders para validar que comprendes sus necesidades y requerimientos.

Pero, si le presentas un diagrama saturado de casos de uso a tu cliente probablemente terminará con un dolor de cabeza y un tanto confundido. Así que no esperes que la validación de tu modelo sea tan efectiva como debería de ser si este es tu caso.

Y ¿cuándo podemos considerar que es suficientemente grande un diagrama? ¿Cuántos, por ejemplo, son suficientes casos de uso o clases para colocar en un solo diagrama?

Aunque la respuesta no es tan simple, los psicólogos nos dan un tip al respecto. De acuerdo a ciertos estudios una persona promedio tiene la capacidad de razonar sobre 7 elementos (más menos dos elementos, es decir, de cinco a nueve elementos) relacionados al mismo tiempo. Así que considéralo dos veces cuando tengas un solo diagrama de caso de uso con mucho más de esa cantidad; puede ser válido por alguna circunstancia especial, pero no está mal si usas este número como referencia.

Pero, ¿qué criterios considerar para agrupar los elementos de tu modelo? Con los casos de uso, en esencia estás hablando de funcionalidad de tu sistema. Así que cuando piensas en una agrupación de funcionalidad completa desde la perspectiva de un usuario final, como la de los casos de uso ¿en qué piensas? Podría ser en módulos.

Un ejercicio para entender esto consiste en consultar el menú inicial en alguna aplicación que utilices, por ejemplo la de un administrador de un hotel. Alguien decidió realizar agrupación de diferentes opciones del sistema pensando en que a los usuarios se les facilitaría ubicar opciones similares.

Figura 1. Paquetes que contienen casos de uso para Administrar un Hotel

Esta agrupación puede abarcar las opciones sobre las cuales tienen acceso ciertos tipos de usuario en particular. Los casos de uso asociados a esas opciones podrían conformar un paquete (sin pretender, de ninguna manera, afirmar que una opción de un sistema sea necesariamente un caso de uso).

Si el módulo tuviera demasiados casos de uso entonces podría convenir subdividir ese paquete en varios paquetes, y dentro de estos estarían los casos de uso; recuerda la regla del siete más-menos dos elementos.

Debes asegurarte que los paquetes sean cohesivos, es decir, que manejen información o funcionalidad relacionada. No querrás agrupar funcionalidad para el cálculo de nómina junto con funcionalidad de ventas.

¿Qué pasa con los diagramas y su relación con los paquetes? Puedes tener un diagrama de alto nivel donde visualizas los paquetes (ver figura 1). Donde cada uno de esos paquetes que visualizas contendrá físicamente sus propios casos de uso (o clases, paquetes, etc.).
Y por otra parte, será bastante conveniente que cada paquete incluya un diagrama donde visualicemos precisamente el contenido de dicho paquete, como en la figura 2, donde se muestra el contenido de uno de los módulos del hotel, así como los actores que utilizan los casos de uso de dicho módulo.

Los alumnos en nuestros cursos nos suelen preguntar si esos paquetes de casos de uso se mapean directamente a componentes. La respuesta es: generalmente no. Los paquetes de clases si pueden mapearse a componentes, pero los paquetes que contienen casos de uso rara vez se mapean directemente a un componente.

Esto se debe a que los paquetes de casos de uso son agrupaciones lógicas desde la perspectiva del usuario final, y rara vez se mapea directamente hacia una agrupación física desde la perspectiva que necesita un programador como ocurre con los paquetes de clases.

Figura 2. Diagrama contenido en el paquete de Registro de Hospedaje

No tiene nada de extraño que la funcionalidad de varios paquetes de casos de uso se implemente en un sólo paquete de clases (n a 1). O al contrario, un solo paquete de casos de uso se puede implementar en varios paquetes de clases (1 a n). Todo depende de cómo se decida implementar la arquitectura de la aplicación y la definición de sus componentes.

Paquetes con Clase

La cantidad de clases de un sistema puede crecer de manera importante. Para mantenerlo manejable y entendible probablemente tengamos que dividirlo también en varios paquetes.

Figura 3. Paquetes de clases para el sistema de hospedaje

Una de las organizaciones básicas de las clases en paquetes corresponde a la representación de capas; conjuntos de clases que ofrecen servicios similares, como el caso de las capas de usuario, negocio y datos. Cada una puede ser representada por un paquete que agrupa un conjunto de clases que ofrecen cierto tipo específico de servicios.

A su vez cualquier capa se puede dividir a su vez en varios grupos, dependiendo de la funcionalidad y comportamiento de las clases identificadas. Como ejemplo podríamos tener un paquete con las clases relacionadas con las cuentas y sus pagos y otra con la información y reglas de negocio relacionadas con el hospedaje en las habitaciones.

Los paquetes de clases pueden representar una agrupación lógica. Es decir, al implementar las clases de varios paquetes podrían incluirse en un solo componente del sistema y no necesariamente en varios. Aunque es bastante común que decidamos implementar un componente por cada paquete. Así que el mapeo puede ser de uno a uno: cada componente conteniendo las clases de un solo paquete.

VER MÁS ARTÍCULOS