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.
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.
Muchas gracias.
ResponderEliminarNo hay problema
Eliminarexcelente brother
ResponderEliminar