Flujos de eventos alternativos

En un caso de uso, los flujos de eventos se refieren a los pasos que alternativamente van realizando los actores y el sistema en el contexto del requisito funcional capturado en el caso. Dichos pasos por claridad, se separan en el flujo principal y los flujos alternativos; de forma tal que en el flujo principal representamos el día feliz, donde todo ocurre sin problemas y en los flujos alternativos lidiamos con las situaciones de error y el comportamiento esperado del sistema en respuesta a dichos errores.

Es necesario entonces contar con una aproximación sistemática sobre como disponer los flujos de eventos principal y alternativos, de forma que capturen en forma clara y precisa cada condición que el flujo del día feliz ha asumido como libre de error pero que es a su vez, el punto de inicio de un flujo alternativo.

La idea aquí es la de indicar el paso del flujo principal y la condición precisa que de violarse hace que se ejecute el flujo alternativo. De ser posible la condición ha de estar expresada en términos del modelo de dominio de forma tal que facilitar su traducción al sistema software.

Los pasos del flujo alternativo han de tener una enumeración propia de forma tal que no choquen los unos con los otros ni con los pasos del flujo principal. La forma exacta en que vamos a enumerar es cosa de cada quien, por lo que es un punto a documentar como parte del Plan de Gestión de Requisitos, documento este que suele ser parte del Plan de Desarrollo de Software.

Un ejemplo de todo lo anterior puede ser visto como parte del ejemplo de caso de uso en este blog. En el ejemplo referido se hace mención al caso de uso “llamada de voz” y se ha señalado la condición de error “número incorrecto”. Veamos una versión ligeramente modificada del caso de uso de ejemplo para discutir como se puede implementar los flujos alternativos:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Diagrama:

Sencillo Modelo de Casos de Uso

Flujo Principal:
Paso 1 – Usuario:
Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Flujo alternativo: Número incorrecto
Paso 3 – Sistema:
Presenta tono de error. El caso de uso termina.

Flujo alternativo: Desconexión inesperada
Paso 5.1 – Sistema:
Detecta un fin inesperado de la conexión. Indica todo de error.
Paso 5.2Usuario: Tranca el teléfono.
Paso 5.3 – Sistema: Registra error. El caso de uso termina.

Tabla 1 – Ejemplo de caso de uso con flujos alternativos

Como ya dije, este ejemplo es una modificación del ya visto en el post ejemplo de caso de uso, donde ahora se han considerado dos flujos alternativos, uno para la condición de número incorrecto y otro para la desconexión inesperada.

La condición ha sido indicada en términos abstractos, comprensibles desde una perspectiva técnica y luego se ha indicado el paso en que dicha condición se puede violentar. En el flujo alternativo del número incorrecto el paso es el tres y en caso de problemas las acciones a tomar son solo una: el sistema presenta tono de error.

Otro tanto puede ser dicho en el segundo flujo alternativo. La desconexión inesperada sin embargo a dado lugar a tres pasos. El sistema detecta un fin inesperado e indica tono de error. El usuario entonces tranca el teléfono. Finalmente el sistema registra el error. Estos tres pasos han sido enumerados con la secuencia 5.1, 5.2 y 5.3, de forma de hacer referencia a que son un flujo alternativo del paso cinco del flujo principal al tiempo de mantener una secuencia numerica propia.

, , , , , , , , ,

  1. #1 por Kamilo Cervantes el 13-03-11 - 2:37 am

    Con respecto a este punto siempre he tenido una duda… usted le llama flujos de eventos, otros le llaman documentacion de caso de uso, otros le dicen escenario de caso de uso, al fin cual es el nombre correcto y la estructura correcta ( los tres son similares pero no del todo ).

    • #2 por Iván Garcerant el 13-03-11 - 10:08 am

      La documentación de un caso de uso incluye su nombre, su descripción breve, su diagrama, sus flujos de eventos, sus precondiciones y postcondiciones, entre otros elementos que puedas llegar a incluir.

      Por esto, el flujo de eventos, ya sea el principal o los alternativos, son solo una parte de una colección de cosas que se incluyen en la documentación de un caso de uso.

      Sobre los escenarios, yo utilizo esa palabra solo para referirme a los esfuerzos de análisis que se hagan, por lo que hablo de escenarios de análisis más que de escenarios de casos de uso. Aquí bien puede ser una diferencia entre la documentación que cada uno ha tomado como referencia.

      • #3 por Kamilo Cervantes el 13-03-11 - 1:01 pm

        Vaya gracias por la pronta respuesta, entiendo su explicación pero aún me queda la duda de cuando se debe escoger uno u otro. En conclusión para acabar con la indecisión haré de cuenta que no conozco los escenarios de casos de uso ^ ^… esta de acuerdo con que la documentación de casos de uso es la herramienta que se debe usar en todos los casos?

    • #4 por JV el 16-08-11 - 12:48 am

      Lo podes llamar “Especificación de Caso de Uso”. Con respecto a la estructura correcta, podes generar tu propio template que respete algo similar a lo que arriba se detalló, e incluso poder adicionarle mas datos: Te acerco un modelo:

      Titulo: Especificaciones de Casos de Uso
      Código: 1_Login
      Nombre: Login de Usuarios
      Descripción: Valida el acceso al sistema por parte de los Usuarios
      Autor: JV
      Fch. Creación Sábado 23 de Septiembre de 2011 Fch. Ultima Modificación

      Actores: UsuarioQA
      Pre-condiciones: Tener disponible la aplicación
      Post Condiciones: Acceso Exitoso del usuario

      Flujo Normal de Eventos:
      1. El sistema informa al usuario que debe ingresar su Alias y su Clave.
      2. El usuario ingresa los datos requeridos, envia los datos y espera respuesta del sistema.
      3. El sistema procesa el alias de Usuario y Clave.
      4. En caso que los datos se condigan con los existentes en los registros, el sistema informara sobre el ingreso exitoso del usuario al sistema.

      Flujos Alternos:

      Usuario no reconocido:

      En el paso 2 del flujo normal, si el nombre de usuario (“Alias”) y la clave no estan entre los usuarios conocidos, el sistema informa que debe conunicarse con el administrador y muestra los datos de contacto.

      Usuario registrado pero inactivo durante un periodo de tiempo:

      En el paso 2 del flujo normal, si el nombre de usuario (“Alias”) y la clave estan entre los usuarios conocidos, pero permanecio inactive durante un “X” periodo de tiempo, el sistema informa que debe conunicarse con el administrador para reactivar sus credenciales y muestra los datos de contacto del administrador.

      Excepciones:
      Si el usuario intenta ingresar al sistema y en tres oportunidades consigna erroneamente sus datos de ingreso, el sistema deshabilitara la opcion de loguea y lo remitira al Administrador ya que interpretará un posible intento de violacion de permisos.

      Referencias:
      Anotaciones: Solo podrán acceder al sistema los empleados registrados y activos

  2. #5 por katty el 29-08-11 - 2:38 am

    Hola amigo gracias por la info esta buena, Tengo una pregunta.. Para un sistema de recargas..supongamos q un cliente ingresa una cantidad que desea recargar y da ‘siguiente’.. Luego se da cuenta q ingreso una cantidad mala de dinero y da ‘atras’.. Eso es un flujo alternativo? :/ Gracias

  3. #7 por Henry el 25-01-16 - 10:35 am

    Buen Día a todos, Alguien sabe donde puedo encontrar un decálogo o similar para el correcto diligenciamiento de casos de uso en especial temas como cuantos flujos alternativos anidados pueden permitirse, máximo de pasos en un flujo y limitantes similares que hagan que un caso de uso sea sencillo y fácilmente entendible por cualquier desarrollador?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: