Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
UML

Dominando el Problema: el Modelo Conceptual
Por Sergio Orozco

Es una preocupación recurrente en la gente que capacitamos en UML saber cuáles son los artefactos mínimos indispensables para obtener beneficios tangibles en su proyectos de software – o en su proceso de mejora continua –. 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 en los cursos.

Por mi experiencia implantando procesos centrados en UML, desde que se formalizó como estándar por la OMG, puedo asegurar lo que ya muchos saben: el mundo no es de color de rosa en esto de los procesos. 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 de las ocasiones no es factible. No son pocos los proyectos en los que la gente no tiene el tiempo suficiente para modelar todo, por lo que busca un mínimo indispensable en el uso de este estándar.
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 terminen no usando ninguno, usando el menos apropiado o usándolos 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 cuestión de calidad y control del proyecto. Y el segundo para desarrollar sistemas más ORIENTADOS A OBJETOS. En este artículo nos concentraremos en el diagrama de clases, pues en números anteriores tratamos ya el tema de casos de uso.

¿Uno o Dos Artefactos?

Hay quien desarrollaría 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 vamos a hablar de la versión de análisis del diagrama: el 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.

Imagina que te solicitaron desarrollar un sistema para vender pólizas de seguros de vida. Pero, quizás nunca en tu vida has comprado un seguro, por lo que no tienes ni idea de los conceptos de dicho. No sabes que las pólizas de estos seguros sirven para asegurar a un cliente por un monto, ni que el plan cubierto por esa póliza es para un tipo de seguro de vida que puede elegir el cliente entre los diferentes planes que aplican de acuerdo a sus características, ni que el cliente puede seleccionar también un tipo de pagos para pagar su póliza a diferentes plazos y montos, ni sabes tampoco que la póliza puede tener desde uno hasta un máximo de 10 beneficiarios.

Bueno, pues si yo fuera el cliente y tú no lograras comprender los puntos anteriores, ten por seguro que me buscaría a alguien más para que me lo desarrollara. Y este es un ejemplo simple, pues las reglas de negocio de cualquier sistema, sabemos que 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.


Figura. Modelo conceptual para la venta de seguros de vida

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” podemos poner una generalización. Aunque esto podría crear confusión en los lectores no técnicos, por lo que hay que asegurarse que el lector del modelo 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. Aunque hay quien gusta de indicar también algunas operaciones que reflejan el comportamiento o las acciones que se pueden realizar asociadas a un concepto. 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 modelo entidad relación, y en efecto puedes aprovechar parte de tu experiencia en ese tipo de diagramas, no trates de hacerlo siguiendo las reglas de ese tipo de diseño. Un entidad relación es un modelo físico para implementar una base de datos relacional, y el modelo conceptual como lo dice el nombre, sólo muestra conceptualmente el dominio del problema.

Publicado en la revista Software Gurú.
Reproducido con permiso del autor.


Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML


indice del manual





Cómo estimar correctamente un proyecto y llevarlo a cabo en tiempo y forma (Nahun Enrique Montoya-Iribe)
+
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.