Modelado Conceptual. Dominando el Problema.

Sin duda, una de las preguntas más frecuentes hacia quienes capacitamos en UML, es: ¿cuáles son los artefactos mínimos indispensables para obtener beneficios tangibles en los proyectos de software? Es difícil expresar en un artículo de este tamaño la respuesta a esta pregunta, aunque trataré de simplificar la respuesta que normalmente damos.

Por mi experiencia implantando procesos centrados en UML, puedo asegurar lo que ya muchos saben: en esto de los procesos el mundo no es color de rosa. Mientras que algunos puristas podrían sugerir usar la mayoría de los artefactos en cada proyecto, la verdad de las cosas es que en muchas ocasiones esto no es factible. En los proyectos de hoy en día, difícilmente se cuenta con tiempo suficiente para modelar todos los aspectos de un sistema, es por ello la eterna búsqueda del mínimo indispensable.

Yo creo en la filosofía de “es mejor poco que nada”, pues he aprendido en todos estos años que sugerir el uso de todos los artefactos ocasiona que al final ninguno se utilice, se use el menos apropiado o se hagan inadecuadamente. Así que mi recomendación es usar por lo menos el diagrama de casos de uso y/o el diagrama de clases, con el primero para obtener más beneficios en cuanto a calidad y control del proyecto, y el segundo para desarrollar sistemas más orientados a objetos. Dado que en números anteriores ya hemos hablado sobre casos de uso, en esta ocasión me concentraré en los diagramas de clases.

¿Uno o Dos Artefactos?
Posiblemente se sientan tentados, o estén acostumbrados a desarrollar el diagrama de clases desde una sola perspectiva, modelando las clases de software a implementar. Es decir, realizando directamente el diseño de la aplicación. Mi recomendación al respecto es que si quieren sacarle el máximo provecho al diagrama de clases es conveniente desarrollarlo en dos ciclos; Uno de análisis y otro de diseño, lo cual implica que en realidad están desarrollando dos artefactos en el proceso en lugar de uno, ambos usando el diagrama de clases como base.

En el primero de estos ciclos, el de análisis, se desarrolla lo que podemos llamar diagrama preliminar de clases, modelo del dominio o modelo conceptual. No importa el nombre, lo que importa es lograr el objetivo de comprender el dominio (contexto del problema); con el beneficio indirecto de estar estableciendo las posibles clases del sistema. Ya en el ciclo de diseño este diagrama preliminar será usado como una base a refinar para determinar las clases definitivas a implementar en el sistema orientado a objetos.

La Comprensión del Problema
En este artículo nos enfocamos en la versión de análisis del diagrama, conocido como modelo conceptual. Su relevancia radica en que si no comprendemos el dominio del problema y las reglas de negocio, habrá pocas esperanzas de sugerir y desarrollarle un buen sistema a nuestro cliente. Y entre más complejas sean las reglas de negocio, más fácilmente tenderemos al fracaso si no logramos esta comprensión.

Imaginen que les solicitaron desarrollar un sistema para vender pólizas de seguros de vida. Pero, quizás nunca han comprado un seguro, por lo que no tienen idea de los conceptos asociados. No saben que las pólizas aseguran a un cliente por un monto determinado, ni que existen diferentes tipos de planes de acuerdo a las características, ni que el cliente puede seleccionar diferentes planes de pago, ni tampoco que la póliza puede tener desde uno hasta un máximo de diez beneficiarios. Bueno, pues si yo fuera el cliente y ustedes no lograran comprender los puntos anteriores, tengan por seguro que buscaría a alguien más que lo desarrollara. Y este es un ejemplo simple, pues sabemos que las reglas de negocio de cualquier sistema pueden ser mucho más complejas. No por nada alguien dijo: “empiezo a pensar que es más fácil enseñarle a mi gente de negocios cómo desarrollar sistemas que a la gente de sistemas el negocio”.

Enlistar textualmente estas reglas en un documento puede ser útil, pero cuando tienes un documento de varias hojas para explicar el dominio es muy fácil que la gente comience a sentirse agobiada por tanta información.

En cambio, si usas un modelo conceptual para expresarlas, será mucho más fácil documentarlas, analizarlas y comprenderlas. Con la ventaja, como ya comenté, que estarás estableciendo las bases para construir una aplicación orientada a objetos.

Los elementos principales a mostrar en el modelo conceptual son:
• Conceptos. Elemento lógico o físico que ayuda a entender el problema, es parte del lenguaje utilizado por el cliente y generalmente se nombra como sustantivo. Se representan con el símbolo de una clase. Ejemplo: Cliente, Póliza y Domicilio.
• Atributos. Información que caracteriza al concepto en el mundo real. Se muestra en el segundo compartimiento de las clases. Ejemplo: Nombre, apellidos y edad del cliente.
• Asociaciones. Relaciones lógicas o físicas que existen en el mundo real entre dos conceptos. Si puedes armar una frase con dos conceptos significa que la puedes representar mediante una relación de asociación entre esos dos conceptos. Puedes colocarle el verbo que usas para relacionar los conceptos en la frase, indicándolo sobre la asociación con una punta de una flecha para indicar la dirección en que se debe leer la frase. Ejemplo: La Póliza cubre-a un cliente asegurado, el cliente vive-en un domicilio.
• Rol. El rol también puede aclarar la relación entre dos conceptos, indica el rol que juega un concepto con respecto a otro en una relación de asociación. Ejemplo: PlanesAplicables al cliente.
• Multiplicidad. El número de instancias de un concepto relacionados con el otro concepto. Ejemplo: Una póliza tiene una lista de uno a diez beneficiarios.
• Generalización. En lugar de poner una asociación para armar la frase “es-un-tipo-de”, utilizamos una generalización. Esto puede llegar a confundir al lector del modelo, por lo que hay que asegurarse que entienda perfectamente el significado de la notación. Ejemplo: El Plan Oro es un tipo de plan de seguro de vida, al igual que el plan tradicional.
• Agregación y composición. Indican una relación donde uno de los conceptos es el contenedor del otro. Ejemplo: la póliza contiene una ListaBeneficiarios.

Estos son los elementos básicos a utilizar para aclarar el dominio de un problema. Algunas personas gustan incluir las operaciones que reflejan el comportamiento o acciones que puede realizar cada elemento. Ejemplo: a un cliente se le pueden cargarPlanesAplicables(). Yo generalmente prefiero definir las operaciones durante una actividad separada de diseño, pero si te da resultado de otra forma está bien.

Un tip adicional, aunque este diagrama se parece a un diagrama entidad relación, no trates de modelarlo siguiendo las reglas de ese tipo de diseño. Un entidad relación es un modelo orientado a implementar una base de datos relacional, y el modelo conceptual como lo dice el nombre, sólo muestra conceptualmente el dominio del problema.