Tarea: Detallar un guión de uso
En esta tarea es donde se añaden detalles a un guión de uso específico.
Objetivo

El objetivo de esta tarea es:

  • Describir uno o varios de los flujos de sucesos del caso de uso con el detalle suficiente para que el desarrollo de software pueda empezar en él.
  • Detallar el caso de uso para aumentar la comprensión y la satisfacción del cliente o el representante del actor.
Relaciones
Pasos
Revisar y perfeccionar los casos de ejemplo

Empiece por revisar y perfeccionar los casos de ejemplo con los que tratará en el ciclo de desarrollo actual. Puede que ya se hayan identificado inicialmente en la Tarea: Encontrar actores y casos de uso . Utilice los casos de ejemplo enumerados como punto de partida para determinar el ámbito de los flujos que se deben describir.

Detallar el flujo de sucesos

Durante la Tarea: Buscar actores y casos de uso , puede que ya se hayan descrito los flujos de sucesos del caso de uso . Utilice esta descripción como punto de partida y aumente gradualmente el nivel de detalle.

Los Guiones gráficos le ayudarán a entender y detallar los flujos del caso de uso . Otra entrada a tener en cuenta es el Prototipo de interfaz de usuario, si se ha desarrollado alguno.

Describa el caso de uso de acuerdo con los estándares decididos para el proyecto. Decida los siguientes puntos antes de describir el caso de uso para mantener la coherencia entre los casos de uso :

  • ¿Cómo empieza el caso de uso ? El inicio del caso de uso debe describir claramente la señal que activa el caso de uso . Por ejemplo, escriba "El caso de uso puede iniciarse cuando ocurre..."
  • ¿Cómo termina el caso de uso ? Debe indicar claramente qué ocurre en el curso del flujo para que termine el caso de uso . Por ejemplo, escriba "Cuando ocurre..., el caso de uso termina".
  • ¿Cómo interactúa el caso de uso con los actores? Para minimizar el riesgo de malentendidos, indique exactamente qué residirá dentro del sistema y qué residirá fuera. Estructure la descripción como una serie de párrafos, en los que cada párrafo expresa una acción con el formato: "Cuando el actor hace..., el sistema hace..." También puede enfatizar la interacción escribiendo que el caso de uso envía y recibe señales de los actores, por ejemplo: "El caso de uso se inicia cuando recibe la señal 'iniciar' del operador".
  • ¿Cómo intercambia datos el caso de uso con un actor? Si lo desea, puede hacer referencia a los argumentos de las señales, pero se recomienda escribir, por ejemplo, "El caso de uso se inicia cuando el usuario inicia una sesión en el sistema proporcionando su nombre y contraseña".
  • ¿Cómo repite el caso de uso algún comportamiento? Intente expresar esto en un idioma natural. En casos muy excepcionales se recomienda utilizar constructos de tipo código como, por ejemplo, "WHILE-END WHILE", "IF-THEN-ELSE" y "LOOP-END LOOP", si los términos del idioma natural correspondientes son difíciles de expresar. No obstante, en general, debe evitar el uso de constructos de tipo código en las descripciones de casos de uso , ya que son difíciles de leer y mantener.
  • ¿Existen situaciones opcionales en el flujo de sucesos de un caso de uso ? A veces, se presentan varias opciones a un actor. Esto debe escribirse de la misma forma. Por ejemplo:

    "El actor puede elegir una de las siguientes opciones, una o más veces:

    a) . . .

    b) . . .

    c) . . ." etc.

  • ¿Cómo se debe describir el caso de uso para que el cliente y los usuarios puedan entenderlo? El uso terminología específica de la metodología como, por ejemplo, el caso de uso , el actor y la señal, pueden dificultar innecesariamente la comprensión del texto. Para que el texto sea más fácil de leer, puede enumerar las acciones o adoptar otro tipo de estrategia. Sea cual sea la estrategia que utilice, debe especificarla en las directrices generales del modelo del caso de uso , para tenerla en cuenta durante toda la tarea de descripción de los casos de uso .

Concéntrese en la descripción de las acciones que se realizan en el caso de uso , no en cómo deben resolverse los problemas internos específicos del sistema. Esos detalles se considerarán más adelante en el ciclo vital, por lo que la descripción no debe ser muy detallada en este punto. Describa sólo aquello que crea que se mantendrá estable más adelante.

Si el flujo de sucesos de un caso de uso se vuelve demasiado amplio o complejo, o parece que tiene partes que son independientes entre ellas, divídalo en dos o más casos de uso .

Cuando escriba el texto descriptivo, consulte el Producto de trabajo: Glosario. A medida que nuevos conceptos evolucionen en nuevos términos, inclúyalos en el glosario. No cambie la definición de un término sin informar a los miembros del proyecto correspondientes.  Para obtener más información, consulte Tarea: Crear un vocabulario común.

El contenido de una descripción de flujo de sucesos

Una descripción de flujo de sucesos explora:

  • Cómo y cuándo se inicia el caso de uso .
Ejemplo:

"El caso de uso puede iniciarse cuando un usuario activa la función 'Administrar orden'".

  • Cuándo interactúa el caso de uso con los actores y qué datos intercambian.
Ejemplo:

"Para crear un nuevo orden, el usuario activa la función 'Nuevo' y, a continuación, especifica los siguientes datos obligatorios relacionados con el orden: nombre, elementos de red (al menos uno) y tipo de función de medida. También se pueden especificar datos opcionales relacionados con el orden: un comentario (una breve descripción textual). A continuación, el usuario activa la función 'Aceptar' y crea un nuevo orden en el sistema".

Nota: debe ser explícito sobre los datos intercambiados entre los actores y el caso de uso ; de lo contrario, el cliente y los usuarios no entenderán la descripción del caso de uso .

  • Cómo y cuándo utiliza el caso de uso los datos almacenados en el sistema, o almacena datos en el sistema.
Ejemplo:

"El usuario activa la función 'Modificar' para modificar un orden existente y especifica un número de orden (un entero pequeño). A continuación, el sistema inicializa un tipo de orden con el nombre del orden, sus elementos de red y su tipo de función de medida. Estos datos se recuperan desde un dispositivo de almacenamiento secundario".

  • Cómo y cuándo finaliza el caso de uso .
Ejemplo:

"El caso de uso finaliza cuando el ordenante activa la función 'Salir'".

También debe describir flujos de sucesos extraños o excepcionales. Un flujo excepcional es un subflujo del caso de uso que no cumple el comportamiento normal o básico del caso de uso . No obstante, este flujo puede ser necesario en una descripción completa del comportamiento del caso de uso . Un ejemplo típico de un flujo excepcional es el proporcionado en el primer ejemplo. Si el caso de uso recibe datos inesperados (que el actor no es el esperado en ese contexto concreto), el guión terminará. Tener el actor incorrecto y terminar prematuramente no son sucesos que pertenezcan al flujo de sucesos típico.

Otras reglas que se deben tener en cuenta cuando se describe un caso de uso son:

  • Describa el flujo de sucesos, no sólo la funcionalidad o el objetivo del caso de uso .
  • Describa sólo los flujos que pertenecen al caso de uso , y no lo que sucede en otros casos de uso que funcionan en paralelo.
  • No cite actores que no se comuniquen con el caso de uso en cuestión.
  • No proporcione demasiado detalle cuando describa la interacción del caso de uso con un actor.
  • Si el orden de los subflujos descrito para el caso de uso no debe solucionarse, no lo describa como si se debiera solucionar.
  • Utilice los términos en el glosario común y tenga en cuenta lo siguiente cuando escriba el texto:
  • Utilice un vocabulario directo. No utilice un término complejo cuando pueda utilizar uno sencillo.
  • Escriba frases breves y precisas.
  • Evite adverbios como, por ejemplo, muy, más, preferiblemente y como.
  • Utilice una puntuación correcta.
  • Evite las frases compuestas.

Para obtener más información, consulte en Directriz: Caso de uso la descripción del contenido y el estilo del flujo de sucesos.

Estructurar el flujo de sucesos

El flujo de sucesos de un caso de uso se puede dividir en varios subflujos. Cuando se activa el caso de uso , los subflujos se pueden combinar de varias formas si se cumple lo siguiente:

  • El caso de uso puede proceder de una o varias vías posibles, dependiendo de la entrada de un determinado actor, o de los valores de algún atributo u objeto. Por ejemplo, un actor puede decir qué hacer a continuación entre varias opciones, o el flujo de sucesos puede ser distinto si un valor es menor o mayor que un valor concreto.
Ejemplo:

Parte de la descripción del caso de uso Retirar dinero en un sistema de cajero automático puede ser "La cantidad de dinero que desea retirar el cliente de la cuenta se compara con el saldo de la cuenta. Si la cantidad excede el saldo, se informa al cliente y el caso de uso termina. De lo contrario, se extrae el dinero de la cuenta".

  • El caso de uso puede ejecutar algunos subflujos en secuencias opcionales.
  • El caso de uso puede ejecutar varios subflujos al mismo tiempo.

Debe describir todos estos flujos opcionales o alternativos. Se recomienda describir cada subflujo en un suplemento aparte del apartado Flujo de sucesos. Esto último es obligatorio en los siguientes casos:

  • En los subflujos que ocupan un segmento grande de un determinado flujo de sucesos.
  • En los flujos de sucesos excepcionales. Esto permite que el flujo de sucesos básico del caso de uso sea más visible.
  • En los subflujos que se puedan ejecutar en varios intervalos en el mismo flujo de sucesos.

Si un subflujo implica sólo una pequeña parte del flujo de sucesos completo, se recomienda describirlo en el cuerpo del texto.

Ejemplo:

"Este caso de uso se activa cuando los actores Ordenante o Administrador de gestor de rendimiento invocan la función 'administrar orden'. Si la señal no proviene de uno de estos actores, el caso de uso terminará la operación y mostrará el mensaje correspondiente al usuario. No obstante, si se reconoce el actor, el caso de uso continúa..."

Puede ilustrar la estructura del flujo de sucesos con un diagrama de tarea. Consulte el apartado Directriz: Diagrama de actividad en el modelo de caso de uso .  

Para obtener más información, consulte el apartado sobre estructura en Directriz: Caso de uso .

Ilustrar las relaciones con los actores y otros casos de uso

Cree diagramas de casos de uso que muestren el caso de uso y sus relaciones con los actores y otros casos de uso . Un diagrama de este tipo funciona como diagrama local del caso de uso y debe estar relacionado con él. Tenga en cuenta que este tipo de diagrama de caso de uso tiene normalmente poco valor, a menos que el caso de uso tenga relaciones de caso de uso que se deban explicar o que exista una complejidad inusual entre los actores implicados.

Para obtener más información, consulte  Directriz: Diagrama de caso de uso .

Describir los requisitos especiales

Los requisitos que se pueden relacionar con el caso de uso , pero que no se tienen en cuenta en el flujo de sucesos del caso de uso , se deben describir en los requisitos especiales del caso de uso . Estos requisitos no suelen ser funcionales.

Para obtener más información, consulte el apartado sobre requisitos especiales en Directriz: Caso de uso .

Definir protocolo(s) de comunicación

Defina el protocolo de comunicación que se utilizará para un actor que sea otro sistema o un hardware externo. Si se va a utilizar un protocolo existente (protocolos reconocidos especialmente o protocolos considerados estándar), la descripción del caso de uso debe nombrar simplemente el protocolo. Si el protocolo es nuevo, debe apuntar a donde se encuentre la definición del protocolo, que se debe describir completamente durante el desarrollo del modelo de objeto.

Describir condiciones previas

Una condición previa sobre un caso de uso explica el estado en el que debe estar el sistema para que se pueda iniciar el caso de uso .

Ejemplo:

Para que un cajero automático pueda dispensar dinero, se deben cumplir las siguientes condiciones previas:

  • Se debe poder acceder a la red de cajeros.
  • El cajero automático debe estar en el estado preparado para aceptar transacciones.
  • El cajero automático debe tener como mínimo algo dinero en efectivo que pueda dispensar.
  • El cajero automático debe tener papel suficiente para imprimir al menos un recibo de una transacción.

Estas son todas condiciones previas válidas para el caso de uso Proporcionar efectivo.

Tenga cuidado cuando describa el estado del sistema; no describa el detalle de otras tareas incidentales que puedan tener lugar antes de este caso de uso .

Las condiciones previas no se utilizan para crear una secuencia de casos de uso . Nunca se dará el caso de que tenga que ejecutar primero un caso de uso y luego otro para tener un flujo de sucesos significativo. Si cree que debe hacerlo, es probable que haya descompuesto demasiado el modelo de caso de uso . Corrija este problema combinando los casos de uso que dependan secuencialmente en un único caso de uso . Si esto hace que el caso de uso   resultante sea demasiado complejo, aplique técnicas para estructurar casos de uso , tal como se describe en el paso anterior Estructurar el flujo de sucesos del caso de uso , o en la Tarea: Estructurar el modelo de caso de uso .

Para obtener más información, consulte el apartado de condiciones previas en la Directriz: Caso de uso .

Describir condiciones posteriores

Una condición posterior sobre un caso de uso enumera los posibles estados en los que puede estar un sistema al final del caso de uso . El sistema debe estar en uno de esos estados al final de la ejecución del caso de uso . También se utiliza para indicar acciones que el sistema ejecuta al final del caso de uso , independientemente de qué haya ocurrido en el caso de uso .

Ejemplo:

Si el cajero automático siempre muestra el mensaje de 'Bienvenida' al final del caso de uso , esto se puede documentar en la condición posterior del caso de uso .

De la misma manera, si el cajero automático siempre cierra la transacción del cliente al final de un caso de uso como Retirar dinero, independientemente del curso que hayan seguido los sucesos, ese hecho se debe registrar como condición posterior del caso de uso .

Las condiciones posteriores se utilizan para reducir la complejidad y mejorar la legibilidad del flujo de suceso del caso de uso .

En ninguna circunstancia se deben utilizar las condiciones posteriores para crear una secuencia de casos de uso . Nunca se dará el caso de que tenga que ejecutar primero un caso de uso y luego otro para tener un flujo de sucesos significativo. Si cree que debe hacerlo, los casos de uso que dependan secuencialmente se deben combinar en un único caso de uso . Si esto hace que el caso de uso combinado sea demasiado complejo, aplique técnicas para estructurar casos de uso , tal como se ha descrito anteriormente en Estructurar el flujo de sucesos del caso de uso , o en la Tarea: Estructurar el modelo de caso de uso .

Para obtener más información, consulte el apartado de condición posterior en Directriz: Caso de uso .

Describir puntos de ampliación

Si el caso de uso se va a ampliar con otro caso de uso (consulte Directriz: Relación ampliada), debe describir cuáles son los puntos de ampliación (consulte el apartado de puntos de ampliación de la Directriz: Caso de uso ).

Evaluar los resultados

Revise y analice el caso de uso con los interesados, para que tengan una percepción clara del caso de uso y estén de acuerdo con sus descripciones.

La descripción del caso de uso sólo finaliza cuando describe todo lo que realiza, implementa o permite de otra forma el caso de uso . Antes de terminar, compruebe que el caso de uso exhiba las propiedades que lo caracterizan como un "buen" caso de uso . Para obtener más información, consulte Lista de comprobación: Caso de uso .

Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información