jueves, 28 de noviembre de 2013

Diagramas de casos de uso - Parte 1 de 2





El caso de uso es un poderoso concepto que ayuda a un analista a comprender la forma en que un sistema deberá comportarse. Le ayuda a obtener los requerimientos desde el punto de vista del usuario. Es necesario aprender a visualizar los conceptos del caso de uso que conoció en la hora anterior.

En esta hora se tratarán los siguientes temas:
  • Representación de un modelo de caso de uso
  • Concepción de las relaciones entre casos de uso
  • Diagramas de casos de uso en el proceso de análisis
  • Aplicación de los modelos de caso de uso
  • Vera la idea general del UML

El caso de uso es muy poderoso, pero lo es aún más cuando se visualiza por medio del UML. Esta visualización le permitirá mostrar los casos de uso a los usuarios para que ellos le puedan dar mayor información. Es un hecho que los usuarios con frecuencia saben más de lo que dicen: el caso de uso ayuda a romper el hielo. A su vez, una representación visual le ayuda a combinar los diagramas de casos de uso con otro tipo de diagramas.

Una de las finalidades del proceso de análisis de un sistema es generar una colección de casos de uso. La idea es tener la posibilidad de catalogar y hacer referencia a esta colección, que sirve como el punto de vista de los usuarios acerca del sistema. Cuando llegue el momento de actualizar el sistema, el catálogo de casos de uso funcionará como un fundamento para obtener los requerimientos de la actualización.


Representación de un modelo de caso de uso

Hay un actor que inicia un caso de uso y otro (posiblemente el que inició, pero no necesariamente) que recibirá algo de valor de él. La representación gráfica es directa. Una elipse representa a un caso de uso, una figura agregada representa a un actor. El actor que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El nombre del actor aparece justo debajo de él, y el nombre del caso de uso aparece ya sea dentro de la elipse o justo debajo de ella. Una línea asociativa conecta a un actor con el caso de uso, y representa la comunicación entre el actor y el caso de uso. La línea asociativa es sólida, como la que conecta a las clases asociadas.

Uno de los beneficios del análisis del caso de uso es que le muestra los confines entre el sistema y el mundo exterior. Generalmente, los actores están fuera del sistema, mientras que los casos de uso están dentro de él. Utilizará un rectángulo (con el nombre del sistema en algún lugar dentro de él) para representar el confín del sistema. El rectángulo envuelve a los casos de uso del sistema.

Los actores, casos de uso y líneas de interconexión componen un modelo de caso de uso. La figura siguiente le muestra estos símbolos.

En un modelo de caso de uso, una figura agregada representa a un actor; una elipse a un caso de uso y una línea asociativa representa la comunicación entre el actor y el caso de uso.

Una nueva visita a la máquina de gaseosas


Apliquemos los símbolos al ejemplo de la hora anterior. Como recuerda, desarrolló los casos de uso para una máquina de gaseosas. El caso de uso “Comprar gaseosa" se encuentra dentro del sistema junto con “Reabastecer y “Recolectar dinero". Los actores son el Cliente. Representante del proveedor y el Recolector. La siguiente figura le muestra un modelo UML de caso de uso para una máquina de gaseosas.


Un modelo de caso de uso proveniente de la máquina de gaseosas de la hora 6.

Secuencia de pasos en los escenarios

Cada caso de uso es una colección de escenarios y cada escenario es una secuencia de pasos. Como puede ver, tales pasos no aparecen en el diagrama. No se encuentran en notas adjuntas a los casos de uso. Aunque el UML no lo prohíbe, la claridad es clave en la generación de cualquier diagrama y el adjuntar notas a cada caso de uso podría volverlo confuso. ¿Cómo y dónde haría la secuencia de pasos?

El uso de los diagramas de casos de uso será, por lo general, parte de un documento de diseño que el cliente y el equipo de diseño tomarán como referencia. Cada diagrama tendrá su propia página, de igual manera, cada escenario de caso de uso tendrá su propia página, donde se listará en modo de texto a: 

El actor que inicia al caso de uso

Condiciones previas para el caso de uso

Pasos en el escenario

Condiciones posteriores cuando se finaliza el escenario

El actor que se beneficia del caso de uso


También puede enumerar las conjeturas del escenario (por ejemplo, que un cliente a la vez utilizará la máquina de gaseosas) y una breve descripción de una sola frase del escenario.

La hora 6, “Introducción a los casos de uso”, presentó algunos escenarios alternativos del caso de uso “Comprar gaseosa". En su descripción, también podría poner estos escenarios de manera separada (“Sin el producto” y “Cambio incorrecto”), o podría considerarlos como excepciones al primer escenario del caso de uso. La forma exacta de hacerlo sólo le concemirá a usted, su cliente y los usuarios.

Para mostrar los pasos en un escenario, hay otra posibilidad que es utilizar un diagrama de actividades UML sobre el cual hablaremos en la hora 11, Diagramas de actividades".


Concepción de las relaciones entre casos de uso

El ejemplo de la hora 6 también mostró dos formas en que los casos de uso se pueden relacionar entre sí. Una de ellas. la inclusión, le permite volver a utilizar los pasos de un caso de uso dentro de otro. La otra, extensión, le permite crear un caso de uso mediante la adición de pasos a uno existente.

Existen otros dos tipos de relaciones que son generalización y agrupamiento. Como en las clases, la generalización cuenta con un caso de uso que se hereda de otro. El agrupamiento es una manera sencilla de organizar los casos de uso.

  • Inclusión

Examinemos los casos de uso “Reabastecer" y “Recolectar dinero" del ejemplo de la hora 6. Ambos se inician mediante la apertura de la máquina, y finalizan con el cierre y sellado de la misma. El caso de uso “Exhibir el interior" se creó para capturar el primer par de pasos; y “Cubrir el interior" para el segundo. Tanto “Reabastecer”, como “Recolectar dinero” incluyen este par de casos de uso.

Para representar a la inclusión utilizará el símbolo que usó para la dependencia entre clases: una línea discontinua con una punta de flecha que conecta las clases apuntando hacia la clase dependiente. Justo sobre la línea, agregará un estereotipo: la palabra “incluir” bordeada por dos pares de paréntesis angulares. La siguiente figura le muestra la relación de «inclusión» en el modelo de caso de uso de la máquina de gaseosas.

Tenga en cuenta que un caso de uso incluido nunca aparecerá solo. Simplemente funciona como parte de un caso de uso que lo incluya.

En la notación de texto que sigue los pasos en la secuencia, indicará los casos de uso incluidos. El primer paso en el caso de uso “Reabastecer” podría ser «incluir» (Exhibir el interior).

El modelo de caso de uso en la máquina de gaseosas con la inclusión.
  • Extensión
La hora 6 mostró que el caso de uso “Reabastecer” podría ser la base de otro caso de uso: “Reabastecer de acuerdo a las ventas”. En lugar de sólo reabastecer la máquina de gaseosas para que todas las marcas tengan la misma cantidad de latas, el representante podría anotar aquellas que se venden mejor y reabastecer acorde con ello. Por lo que podemos decir que el nuevo caso de uso extiende al original dado que agrega otros pasos a la secuencia del caso de uso original, que se conoce como el caso de uso base.

La extensión sólo se puede realizar en puntos indicados de manera específica dentro de la secuencia del caso de uso base. A estos puntos se les conoce como puntos de extensión. En el caso de uso Reabastecer, los nuevos pasos (anotar las ventas y abastecer de manera acorde) se darían luego que el representante haya abierto la máquina y esté listo para llenar los compartimientos de las marcas de gaseosas.
En este ejemplo, el punto de extensión es “Llenar los compartimientos”.


Como la inclusión, podrá concebir la extensión con una línea de dependencia (línea discontinua con punta una punta de flecha), junto con un estereotipo que muestra “extender” entre paréntesis angulares. Dentro del caso de uso básico, el punto de extensión aparecerá debajo del nombre del caso de uso. La siguiente figura le muestra la relación de extensión para “Reabastecer” y “Reabastecer de acuerdo a las ventas”, junto con la inclusión de relaciones para “Reabastecer” y “Recolectar dinero”. 

Un diagrama de casos de uso que muestra la extensión y la inclusión.


  • Generalización
Las clases pueden heredarse entre sí y esto también se aplica a los casos de uso. En la herencia de los casos de uso, el caso de uso secundario hereda las acciones y significado del primario, y además agrega sus propias acciones. Puede aplicar el caso de uso secundario en cualquier lugar donde aplique el primario. En el ejemplo, deberá imaginar un caso de uso “Comprar un vaso de gaseosa” que se hereda de “Comprar gaseosa”. El caso de uso secundario tiene acciones como “agregar hielo” y “mezclar marcas de gaseosas”. Modelará la generalización de casos de uso de la misma forma que lo hace con las clases: con líneas continuas y una punta de flecha en forma de triángulo sin rellenar que apunta hacia el caso de uso primario, como se muestra en la siguiente figura.

Un caso de uso puede heredar el sentido y comportamiento de otro.
La relación de generalización puede establecerse entre actores, así como entre casos de uso. Quizá tenga personificados al representante del proveedor, al recolector y al agente del proveedor. Si cambia el nombre del representante como Reabastecedor, tanto éste como el Recolector serán secundarios del Agente Proveedor, como muestra la siguiente figura.

Como las clases y los casos de uso, los actores pueden estar en una relación de generalización.

  • Agrupamiento

En ciertos diagramas de casos de uso, podría tener varios casos de uso que querrá organizar. Esto puede ocurrir cuando un sistema consta de varios subsistemas. Otra posibilidad sería cuando entrevista a los usuarios para obtener los requerimientos de un sistema. Cada requerimiento podría ser representado como un caso de uso por separado. Necesitará alguna forma de ordenar los requerimientos por categorías. 


La forma más directa de organizar sería agrupar en un paquete los casos de uso que se relacionen. Recuerde que un paquete aparece como una carpeta tabular. Los casos de uso agrupados aparecerán dentro de la carpeta.



Espero haber ayudado en algo. Hasta la próxima oportunidad!






2 comentarios:

  1. Muchas gracias por compartir, seguiré tu web esto de UML lo vengo buscando desde hace tiempo

    ResponderEliminar
    Respuestas
    1. Hola Cyberkiller, gracias por la visita y el aporte de tus comentarios!!
      Espero te ayude!!
      Los mejores deseos! Hasta cualquier instante!

      Eliminar

       
free counters

Páginas vistas en total según Google