LAS PREGUNTAS MÁS FRECUENTES DE CÓMO ELABORAR UN DIAGRAMA DE CASOS DE USO

Bueno en realidad el motivo que me conlleva a escribir este artículo, es porque  me veo motivado a escribir sobre algo particular que viene sucediendo en la academia de la universidad en la que estoy, no quiero entrar en más detalle pero siempre trato de ser una persona que cuestiona todo hasta no aclarar la situación, objeto, o material que estudio. Es como diría un maestro “no coman entero”. Tal vez esa es la verdadera razón por la que estoy aquí escribiendo, tampoco quiero repetir lo que todo mundo vuelve a escribir una y otra vez por eso creo que será interesante.
En esta  ocasión y en comparación a los anteriores artículos en donde prefiero guardar mis razones de por qué escribí eso, podría decir que esta vez sí hay un impulso no solo de conocimiento sino un impulso de aclarar las cosas y preguntas que estoy seguramente no sea el único que las planteo. Entonces es hora de “ir al grano”. Espero que les guste y pues si no, también, estoy dispuesto a escucharlos pues nadie es perfecto.

Es correcto decir que este artículo no será un curso completo y teórico de diagramas de caso de uso, lo que simplemente pretendo es brindar de manera rápida, que se debe tener en cuenta para elaborar un diagrama de caso de uso sin abusar de lo indebido o lo no recomendado para hacerlos.

1. ¿Qué representa un diagrama de caso de uso?

Representan de manera esencial el comportamiento de un sistema, no son ni muy específicos ni demasiado generales. En pocas palabras, diría que son el punto ideal para que todo usuario final del sistema, experto y desarrolladores entiendan el comportamiento deseado del sistema. El caso de uso describe toda la secuencia de acciones que ejecuta un sistema para producir un resultado a un actor.

2. ¿Cómo se deben especificar los nombres en los casos de uso?




“El nombre de un caso de uso puede constar de texto con cualquier número de letras, números y la mayoría de los signos de puntuación (excepto los dos puntos). En la práctica, los nombres de los casos de uso son expresiones verbales que describen algún comportamiento del vocabulario del sistema que se está modelando”. (Booch, 2006).

Bueno si analizamos el párrafo anterior existen dos maneras de nombrar los casos de uso de manera correcta: nombre simple (una cadena de texto que inicia con un verbo), nombre calificado (una cadena de texto que inicia con el nombre del paquete que lo contiene separadamente por dos puntos y luego el nombre simple). Como es lógico ya entenderán porque no usar (:).

Desviándome un poco un profesor decía que comenzaba con un verbo porque le estamos hablando a una máquina, esto no es cierto, simplemente como lo dice el párrafo un verbo describe de manera completa el comportamiento de un sistema y por tal motivo no hay manera más fácil de agrupar cierto comportamiento si no es a través de un verbo.

3. ¿Un actor puede ser el mismo sistema?


No, no y no. Antes de dar explicaciones revisemos el concepto de actor. “Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso representan al interactuar con estos. Normalmente, un actor representa un rol que es desempeñado por una persona, un dispositivo hardware o incluso otro sistema al interactuar con nuestro sistema”. (Booch, 2006)

Bueno esto es muy simple, en ¿dónde dice que el mismo sistema es un actor? Inevitablemente la primera imagen no es la forma de hacerlo, la segunda sí. Como es posible decir que el actor va hacer el mismo sistema si lo que plasmamos en el diagrama es el comportamiento del mismo, además si así fuera se consideraría como un sistema externo y no el mismo sistema, esto es supremamente ilógico pero lo he visto señores, lo he visto, es más el mismo profesor que me dijo que los casos de uso se escribían con verbos, era el que nos decía que el actor era el mismo sistema. De por Dios, como se come de entero sin masticar a veces las cosas.

4. ¿Cuáles son las relaciones usadas en el diagrama de casos de uso?

Relación de asociación. “Los actores sólo se pueden conectar a los casos de uso a través de asociaciones. Una asociación entre un actor y un caso de uso indica que el actor y el caso de uso se comunican entre sí, y cada uno puede enviar y recibir mensajes”. (Booch, 2006). Creo que esta parte es más clara que el agua, no he visto hasta el momento que existan dudas referentes a esta relación.

Relación de generalización. 

Es como la generalización entre clases. Significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre; el hijo puede añadir o redefinir el comportamiento del padre”. (Booch, 2006).  Esto no significa que comprobar clave y examinar retina sean diferentes a validar el usuario. Lo importante aquí es identificar que se podrían hacer uso de los términos en OO, para el caso de herencia “es”, por ejemplo, el comprobar la clave es validar el usuario con un documento o texto y examinar retina es validar el usuario con un patrón del ojo humano. Es importante indicar que el sentido de las flechas siempre sale de los hijos apuntando hacia el padre, no al contrario (esto también se ve mucho como error frecuente).

  
Relación de inclusión.

“Significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. El caso de uso incluido nunca se encuentra aislado, sino que es instanciado sólo como parte de algún caso de uso base toma el comportamiento del caso de uso proveedor . La relación de inclusión se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso aparte. ” (Booch, 2006).

Es un poco confusa la definición de la relación, pero el final se hace más claro el camino.  El autor nos indica en pocas palabras que un caso contiene a otro, es decir, simplemente se usa este tipo de relación para no repetir el mismo flujo de eventos que son necesarios para el caso de uso en acción. Voy a tomar los mismos ejemplos del libro para no complicarme en la explicación:

Seguir un pedido es un caso de uso, el cual necesita obtener y verificar el pedido, luego validar el usuario (caso de uso con flujo de eventos), después consultar el estado del pedido y termina con informar el estado global del usuario. Entonces en pocas palabras podemos modelarlo así:


Ahora comprendo más al ver el gráfico, aquí hay dos cosas muy importantes que destacar el sentido de la flecha no es como se interpreta, es decir, no podemos inferir que seguir pedido es el que está dentro de validar usuario, no podemos decir que validar usuario necesita el flujo de eventos de seguir el pedido. Al contrario, lo que se pretende decir es que el caso de uso seguir pedido hace uso, o incluye a validar usuario para continuar con su flujo de eventos, es decir, no es necesario volver a repetir las mismas acciones del caso de uso de validar usuario dentro del caso de uso Seguir pedido. “Espero no confundirlos”.
Y lógicamente el caso de uso base es validar usuario porque es el caso de uso necesario para elaborar o incorporar el otro.

Ahora ustedes nunca se preguntaron ¿por qué esta relación es igual a la dependencia? Porque en realidad es la misma, lo único que cambia es que se usa un estereotipo, es decir, se usa una etiqueta que en este caso es <<include>>. Importante tener en cuenta que en esta relación el comportamiento del caso base está obligado a pertenecer al otro caso de uso.

Relación extensión.

“Significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en lugar especificado indirectamente por el caso de uso que extiende al base. El caso de uso base puede estar aislado pero, en algunas condiciones, su comportamiento puede extenderse con el comportamiento de otro caso de uso”. (Booch, 2006)

Realmente su palabra lo dice, “extiende”, es decir, es usado cuando un comportamiento se bifurca (tiene varios caminos) y es necesario documentarlo pero no obligatorio. En pocas palabras se usan para documentar los comportamientos opcionales que puede tener un sistema. Las relaciones son iguales a la dependencia como en el anterior caso, pero usa ahora como estereotipo <<extends>>. Veámoslo ahora con un modelo.


Bueno para resumir todo esto las únicas relaciones en el diagrama de casos de uso son las de dependencias estereotipadas como <<include>>  y <<extend>>, las de generalización y por ultimo las de asociación. Cualquier otra relación diferente a estas “son mentiras” y simplemente se están inventando un nuevo lenguaje de modelado.  

 6.       ¿Cuándo se considera el límite o alcance de un caso de uso?

Realmente no existe un límite. Un profesor indicaba que por máximo 10 acciones o pasos dentro de un caso de uso. Mmm… que puedo decir referente a esto, creo que no es verdad, lo que se aconseja y se recomienda antes de hacer un diagrama de caso de uso es primero hacer un flujo de eventos, este flujo de eventos es el que realmente nos puede indicar cuando comienza y termina un caso de uso, es decir, el flujo de eventos nos indica realmente cuando un actor inicia una interacción con el sistema y cuando termina ya sea con un entregable o cualquier resultado ofrecido por el sistema. Entonces podríamos decir que no hay un límite, debemos ser conscientes que si deseamos realmente identificar el comportamiento de un sistema es el mismo flujo de eventos quien nos indica en donde comienza y termina un nuevo caso de uso.

En pocas palabras, hagamos la tarea completa y primero escribamos todo en papel de todos los pasos de interacción entre los actores y el sistema. Es aquí donde también puedo decir, que el profesor al cuál he venido criticando mucho durante el transcurso de este artículo si me dijo esto con claridad y nos aconsejó que lo hiciéramos. No todo en la vida es malo, ¿verdad?

7.       ¿Es necesario incluir los casos de uso en un rectángulo?

Realmente no, en los documentos y libros que he leído no encuentro alguna especificación que sea una condición, pero a mi parecer y criterio el diseño del diagrama de casos de uso se hace más entendible si especificamos su contexto, es decir, podemos mediante el rectángulo indicar que estamos hablando de un sistema en particular o un módulo del comportamiento que deseamos modelar. Para mi concepto es como hablar de la célula sin membrana, realmente, se ve asquerosamente horrible el diagrama de casos de uso sueltos por ahí sin que se delimiten, parecen divagar en el ambiente sin forma alguna. Entonces, si me preguntan a mí… ya saben la respuesta. Hagamos las cosas que no solamente se entiendan sino que también tengan un diseño, una estructura que sea entendible para todo mundo.  

Me disculpo por escribir tanto y alargarme en un tema tan sencillo pero se me hace de vital importancia escribir y desahogarme, y esta es una de las formas. Quiero agregar un vídeo respecto al tema pero no me quedo tiempo, por el momento esta abierto a que alguien aporte el vídeo o tal vez después yo lo haga. Pienso que no soy de la generación del vídeo y eso me motiva hacerlo de la antigua forma, escribiendo.

“Bueno creo que eso fue todo amigos”. Espero verles ayudado de alguna forma y seguir con buenas prácticas en la elaboración de diagramas UML, es importante tener estos aspectos muy claros, para que todos seamos buenos Ingenieros de sistemas en el tema de modelamiento, no simplemente por hacer diagramas de paso. Si tienen alguna crítica no duden en comentarla, eso sí espero que sea fundamentada a través de un libro o algo que le de peso a lo que escriben, “no coman entero”. 

Bibliografía

Booch, G. (2006). EL LENGUAJE UNIFICAO DE MODELADO GUÍA DEL USUARIO. Madrid: PEARSON EDUCATION.





2 comentarios: