divide y venceras

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 queaplicar 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 salvade 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 lomenos, 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 yrequerimientos. 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, paracolocar 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 esacantidad; 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 lascuales 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...