Ejemplo de análisis de caso de uso

Si el análisis pone en descubierto las partes de aquello que se ha visto como un todo, entonces el análisis de casos de uso ha de poner en descubierto las instancias que intervienen en el sistema a la hora de realizar la funcionalidad descrita en dicho caso de uso.

Para efectos de la tarea análisis de caso de uso, en su versión con modelo de domino, dichas instancias van a pertenecer a alguna de las clases descritas en el modelo de dominio. El objetivo del análisis va a establecer los detalles de la relación que es necesaria que tengan estas clases para lograr la funcionalidad descrita en el caso de uso.

Tomemos el siguiente modelo de dominio para el sistema de subterráneo (Metro) de una ciudad cualquiera:

Fig. 1 – Diagrama de clases del modelo de dominio del sistema metro

Y complementemos con el siguiente modelo de casos de uso; asumiendo de momento que los casos de uso han sido descrito en detalle en algún documento apropiado.

Fig. 2 – Diagrama de casos de uso del sistema metro

Finalmente, tomemos el caso de uso Compra de Ticket para completar nuestro ejemplo:

Nombre: Compra de Ticket.
ID: N/A.
Actor: Usuario del Metro.
Descripción breve: El usuario del metro compra un boleto del sistema luego del pago de la cantidad apropiada.

Tabla 1 – Detalles del caso de uso: Compra de Ticket

Ya armados con todos estos detalles, nos podemos hacer la siguiente pregunta:

¿Qué clases del modelo de dominio intervienen en el caso de uso?

No existe una respuesta necesariamente correcta, queda a juicio del analista el tomar una u otra clase según su visión y particular enfoque del problema; en mi caso, he tomado las clases Usuario del Metro, Venta de Ticket, y Ticket.

Luego de identificar que conceptos de nuestro modelo de dominio intervienen en el caso de uso, necesario ahora indicar cuales son los mensajes que estas instancias deben intercambiar para completar la funcionalidad. Este intercambio lo presentamos en un diagrama de UML, típicamente un diagrama de secuencia.

Fig. 3 – Diagrama de secuencia con el escenario de análisis
del caso de uso: Compra de Ticket

El resultado de nuestro análisis ha sido una primera versión de los mensajes que han de intercambiar las instancias de las clases Usuario del Metro, Venta de Ticket y Ticket, para lograr la funcionalidad requerida en el caso de uso Compra de Ticket.

Hay que fijarse que el modelo de domino original tenía pocos o ningún atributo o método para sus clases. El resultado del análisis es que ahora estas clases han sido detalladas un poco más, indicando para algunas de ellas (las que intervienen en el los escenarios de análisis) cuales métodos son necesarios e incluso, el proposito de cada uno de estos.

Cuando se parte de un modelo de dominio, el análisis de caso de uso no hace más que enriquecer este modelo, detallando como he dicho ya, cuales métodos son necesarios que estén presentes. Al final, el análisis habrá completado un esbozo de un modelo del sistema; modelo este que ya habrá asumido todos los requisitos de nuestros clientes y presentará una relación de clases capaz de instanciar lo visto en el análisis.

Queda por supuesto más pasos antes de contar con un sistema listo para su uso; es necesario que realicemos la integración con las clases de análisis (si las hemos usado) así como llevar a cabo el diseño del sistema; es decir, aún no estamos listos para programar, pero si estamos listos para diseñar.

, , , , , , , ,

  1. #1 por Iván Garcerant el 12-07-08 - 7:05 pm

    Según UML, las relaciones de dependencia entre los casos de uso son las de inclusión y la extensión; sin embargo en el diagrama de casos de uso que he colocado tengo una relación diferente: prerequisito. Esto es valido siempre y cuando tengamos un documento o anexo donde hayamos detallado el significado de este estereotipo personalizado.

    En nuestro caso, este comentario cubre esa exigencia de tener definido lo que hemos personalizado; espero que sea obvio que el estereotipo de relación «prerequisito» une dos casos de uso cuando uno requiere que otro se haya completado previo a su activación. (Si lo piensas utilizar debes arrastrar la definición también!)

    El ejemplo en verdad lo hice con otro propósito en mente, por lo que el estereotipo lo puse en español y los casos de uso sin ID numérico; pero a fin de cuentas el modelado ha de ser flexible para que pueda ser expresivo.

    Espero que nadie se me confunda.

  2. #2 por YOP el 16-04-09 - 7:12 pm

    muy bueno el ejemplo muy claro y muy entendible disipe todas las dudas que tenia gracias

  3. #3 por ramon el 2-12-09 - 7:14 pm

    Interesante el ejemplo, pero la relación prerrequisito puede obviarse utilizando include.
    Gracias por la idea.

    Ramon

    • #4 por Iván Garcerant el 3-12-09 - 9:40 pm

      Saludos Ramon.

      Pienso que no, no es lo mismo decir que un caso de uso incluye otro a decir que un caso de uso requiere que otro se haya ejecutado antes de él.

      Es decir, creo que hay diferencia entre «include» y «prerequisito».

      Para dejar clara la diferencia, imagina la posibilidad de dos ejecuciones del caso de uso «Viajar en el sistema». Dos ejecuciones cuyo prerequisito se puede satisfacer con una sola ejecución de «Comprar Ticket» incluso, con mucho tiempo entre estas.

      Si hubiera una relación «include», sería obligar a comprar el Ticket cada vez que se va a viajar en el metro, cosa falsa la verdad, ya que uno puede entrar en la estación y comprar tickets para toda la semana sin tener que viajar necesariamente ese día.

      Eso sí, hay que recordar que lo de «prerequisito» visto como relación es poco frecuente. Lo más común es documentar los reprequisitos en una sección del caso de uso en forma textual y no en el diagrama.

  4. #5 por JUDITH el 21-01-10 - 8:47 pm

    Hola buenas noches, mi nombre es Judith, y revisando esta pagina tambien me hice la pregunta de cual seria la diferencia entre el include y el prerequisito(creado por usted)….

    En el mensaje de respuesta que da, hace la referencia a que es diferente comprar un ticke y no utilizarlo hasta despues (prerequisito), a comprarlo y utilizarlo en ese momento (include); sin embargo. cuando usted mismo dice «obligar a comprar el ticket –cada vez–que se va a viajar en el metro» ya de antemano esta condicion se debe cumplir para ambos casos independientemente del tiempo, ya que para viajar ya se «ahora» o «despues»de todas maneras implica comprar un tique.

    Para efectos, Usted hace la distincion de los terminos basado en el tiempo que existe entre usarlos ahora o a futuro, y en base a ello queria saber si hay una descripcion en UML que determine que el INCLUDE solo sea referenciado a relaciones entre casos que deban ser desarrollados en el mismo momento.

    Disculpe el analisis, y si estoy errada aun mas…pero tiendo a buscarle el total entendimiento a lo que voy estudiando (como es leer esta pagina) para saber con certeza el por que y la verdad de las cosas.

    Gracias de antemano por su tiempo….y contestacion

    • #6 por Iván Garcerant el 22-01-10 - 10:14 am

      Saludos Judith.

      En líneas generales, UML no especifica la forma en que se deben utilizar sus elementos. UML se define como un lenguaje y modelado, y aspectos como los que usted me comenta son más cosa de lo que se dice, que del lenguaje en el cual se dice. Es decir, son aspectos cubiertos por los métodos de desarrollo, como RUP o XP, y no directamente por el UML.

      En lo personal, interpreto a la relación include como un requisito funcional, que eventualmente se convertirá en código. Desde este punto de vista, si al viajar en metro se «incluye» comprar un ticket, es porque habrá código, sea una llamada de función u otra, que ejecute la compra en ese momento y no en en ningún otro.

      Lo que veo como lógico, sería «incluir» el hipotetico caso de uso «buscar el ticket», ya que al momento de viajar hay que contar con un ticket y de no tenerlo en la cartera habría que comprarlo, pero dejando la posibilidad de tener este de antemano, en la cartera, como dije.

      Sin embargo, un caso de uso «buscar el ticket» lo veo como muy de bajo nivel, por lo que algo así no lo aconsejo.

      En cuanto a la relación de dependencia, efectivamente es un ejemplo del libre uso y estereotipado de una relación. Típicamente los cursos universitarios sobre casos de uso se refieren solo a las relaciones de include y extend, pero dejan en un segundo o tercer lugar, la posibilidad de crear o adaptar el modelado a las necesidades y culturas de cada proyecto en particular. El modelado ha de ser flexible, y el aceptar como entendible una relación ad-hoc, como «requisito» es posible de haber esta flexibilidad.

      Iván.

  5. #7 por luZ sUAREZ el 19-03-10 - 4:03 pm

    Muy bueno el ejemplo entendible y claro!!! gracias me sirvio bastante

  6. #8 por Augusto el 6-05-10 - 9:09 am

    Muy bueno el ejemplo. ¡GRACIAS POR COMPARTIR!

  7. #9 por davan el 3-06-10 - 1:41 am

    hola::
    gracias por tu ayuda me fue muy util, de verdad que hace falta mas gente como tu en la RED.
    bueno yo tambien quiero dar mi granito de arena, tengo muchos temas para compartirlos aqui
    espero los sirba de algo

    • #10 por Iván Garcerant el 4-06-10 - 8:48 am

      Gracias por la buena opinión. Coincido con lo que dices en tu página: «la información es para compartirla, no para guardarla»

  8. #11 por Roberto el 5-09-10 - 11:05 pm

    Hola, muchas gracias por la informacion, me ayudo de mucho, gracias por compartir el conocimiento para que otros puedan guiarse mas ^^
    saludos.

  1. Definimos UML como… « Tecnología y Synergix

Deja un comentario