Divide y vencerás. Utilizando paquetes.

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 ti. Lo mismo te puede pasar 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 revisarlos, será más fluida.

El elemento de UML que nos salva de estas situaciones, es simple, pero eficaz: el paquete. Probablemente ya lo has visto. Ese símbolo en forma de fólder 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.

¿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 sólo diagrama?

Aunque la respuesta no es tan simple, los psicólogos nos dan un tip. De acuerdo a ciertos estudios, una persona promedio, tiene la capacidad de razonar sobre siete 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 sólo 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. Esta agrupación puede abarcar las opciones, sobre las cuales tienen acceso ciertos tipos de usuario en particular. Los casos de uso asociados a tales 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 el paquete en varios paquetes, y dentro de ellos, 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étera). Y por otra parte, será bastante conveniente, que cada paquete incluya un diagrama donde se visualice, justo 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.

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

Los alumnos en nuestros cursos suelen preguntar, si esos paquetes de casos de uso se mapean directamente a componentes. La respuesta es: generalmente no. Los paquetes de clases, sí pueden mapearse a componentes, pero los paquetes que contienen casos de uso, rara vez se mapean directamente 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. 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 sólo 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.

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

Paquetes con Clase
La cantidad de clases de un sistema puede crecer de manera importante. Para mantenerlo manejable y entendible, es probable que tengamos que dividirlo también, en varios paquetes.

Una aplicación común de la organizacion básica de 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 se puede representar por un paquete que agrupa un conjunto de clases, que ofrecen cierto tipo de servicios.

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 sólo 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 sólo paquete.

Figura 3. Paquetes de clases para el sistema de hospedaje