Escribiendo casos de uso

Actores

• Actor primario: Es la persona dueña de la meta principal
  • Generalmente (pero no siempre) es también el iniciador
  • Cuando no es iniciador (y el iniciador es otra persona, como una secretaria) este tercero se vuelve una conveniencia tecnológica para el ahora llamado Actor primario ulterior
    • El tiempo también puede ser un actor primario

Inicio de un caso de uso

• Se arranca listando todos los posibles actores primarios. Esto da una vista amplia del sistema y permite ver la mayoría de las metas del sistema.
• No importa nombrar muchos actores principales, pues sólo se descubrirían las mismas metas
• Esto también nos permite Enfocarnos en quiénes serán los usuarios del sistema

Durante diseño/descripción del CU

• Un caso de uso puede llegar a ser usado por varios tipos de actores. Por eso, los nombre de actores suelen irse generalizando
  • Para evitar redundancia en los pasos del CU, se puede aclarar que "Actor X puede usar cualquier CU que el Actor Y use, y algo más"
• De todas formas, el actor primario pierde importancia hasta el fin del ciclo

Después del diseño, preparando implementación

• Se vuelve importante el actor primario pues se deben insertar los sistemas en las máquinas de usuario, se deben establecer los niveles de seguridad, y se deben crear las capacitaciones para cada tipo de usuario

Actores, Roles y Especialización

• Con sólo el lenguaje de actores, hay que aclarar qué permisos tiene cada actor, y si engloba los permisos de otro
• Con el lenguaje de roles, cualquier actor puede atarse a una etiqueta que tiene ciertos permisos de uso de CU
  • O sea, podemos enumerar varios roles para cada actor
• La especialización es útil cuando dos actores se solapan en sus funciones (el conjunto de CUs de un actor es subconjunto del de otro actor)
  • La especialización se representa en UML con una flecha con punta hueca hacia el actor más general

Caracterizar a los actores primarios

• Los diseñadores necesitan saber, además de quiénes son los usuarios, qué habilidades o necesidades específicas tiene cada uno, para poder crear las interfaces
• Se crea el artefacto Mapa de Perfil del Actor: una tabla con dos columnas: nombre y perfil (ambiente y habilidades). Ejemplo:

Alcance

• Alcance: El intervalo de funciones del sistema que nos interesa desarrollar.
• Suele haber tres alcances:
  1. Negocio. Este no hace mención de los sistemas, es sólo el flujo de la información
  2. Sistema. Hace mención de los empleados con su flujo de trabajo y de los sistemas, pero no de la arquitectura
  3. Subsistema.

Lista actor-meta

• Un artefacto que describe las prioridades de las funciones que se diseñan en el sistema
• Es el punto inicial de negociación entre el usuario, el financista del proyecto y el grupo de desarrollo

Resumen de caso de uso

• Una variación de la lista Actor-Meta, que incluye una explicación de 2-6 oraciones de lo que hace el sistema
  

Etiquetas

Para abreviar los alcances, se puede usar...

• Para el alcance de Negocio: El nombre de la empresa (representado con una casa)
• Para el alcance de Sistema: El nombre del sistema (representado con una caja)
• Para el alcance de Subsistema: El nombre del subsistema (representado con un tornillo)

Niveles de meta

Metas resumen [Blanco, barrilete]

• Son de alto nivel
• Se escriben primero para dar contexto a los demás CU
• Metas del proceso entero, ponen en contexto a las metas de usuario
• Muestran el overview, el outline, la tabla de contenido de los niveles de CU
• Se realizan por mucho tiempo (horas, días, semanas, meses o años)

Metas de usuario [Azul, mar]

• Son las más importantes
• Es el mismo concepto que un Proceso Elemental de Negocio, pero aplicado a Casos de Uso
• Se cumplen por una sola persona en poco tiempo (2-20 minutos)
• Tienen pasos de color índigo

Metas de subfunción [Índigo, pez]

• Son de bajo nivel
• Sirven para llevar a cabo varias metas de usuario
• Sólo se deben usar cuando muchas metas la usan o cuando mejora la lectura
• Ejemplos: Encontrar un producto, encontrar un cliente
• Una meta de más bajo nivel [Negro] se debe omitir pues sería algo demasiado específico

Anexo

Disparadores

• Es el evento que hace que el CU comience
• Puede ser anterior al primer paso del CU, o puede ser también el primer paso
• Ej:

Relato

El relato está formado por un escenario principal y fragmentos de escenarios de extensión.
Cada uno comienza con una condición disparadora y termina con la concreción de una meta.

Estructura del relato

• Condición de ejecución/Precondiciones
  • Para el escenario principal, es la precondición + el disparador
  • Para un escenario extendido, es la condición de extensión
• Meta a alcanzar
  • Para todos los escenarios es el nombre del caso de uso
  • Los escenarios extendidos pueden también tener la meta de unirse de nuevo al escenario principal después de manejar la excepción
• Cuerpo del escenario
  • Es una serie de pasos (que pueden ser paralelos)
  • Describe una interacción entre actores, validación de dato o cambio interno
    • El cliente ingresa al domicilio
    • El sistema confirma que no haya reclamos contrarios
    • El sistema deduce el importe de la cuenta
• Condición de fin: ~ #Preguntas
• Extensiones/Escenarios alternativos

Directrices para los pasos

1. Usar gramática simple
   • "Sujeto + verbo + objeto directo + [frase preposicional]"
   • "El sistema + deduce + el importe + de la cuenta"
2. Mostrar claramente al protagonista
   • En cada paso un actor "tiene el balón"
3. Escribir en perspectiva top-down
   • Es decir, una vista externa, no como lo ve el sistema
   • DO: "El cliente ingresa tarjeta y PIN"
   • DON'T: "Obtener tarjeta y PIN"
4. Mostrar el avance del proceso
   • En un CUS, cada paso avanza mucho menos que un paso de un CUR
   • Para subir de nivel de descripción, preguntarse ¿Por qué el actor hace esto?
5. Mostrar intención del actor, no el movimiento
   • Describir los movimientos dentro de la UI es una descripción de diálogo, y es indeseable pues es frágil e ineficiente
   • Lo que queremos es una descripción semántica del uso del sistema: las líneas generales de lo que intenta hacer con él
6. Tener un conjunto razonable de acciones
   • Ser razonable con el número de pasos y de qué forma fusionar varios pasos cortos en uno, o separar uno largo en varios pasos
7. Usar "Valida" en vez de "Controla si"
8. Mencionar el tiempo es opcional
9. Expresar interacción con un sistema de terceros
   • Usar la frase "El usuario hace que el sistema A {interactúe} con el sistema B", sin especificar cómo lo hace (para no tener una descripción dialogal)
10. Frase "Hacer los pasos {x-y} hasta {condición}"
    • Si se repiten varios pasos, escribir la repetición después de los pasos, como una nueva línea sin numerar

Extensiones

Son bifurcaciones debajo del escenario principal, que manejan las alternativas dentro del funcionamiento del sistema. Muchas veces tienen la meta de reinsertarse en el camino principal.
La etapa de requerimiento es el mejor momento para descubrirlas.

Condiciones de extensión

Son condiciones

Plantilla

• Primero especifica:
  • #Niveles de meta
  • Estructura [Sin estructurar/Re-estructurado]
  • #Alcance
  • Transparencia [Caja negra/Caja blanca]
    • Casi siempre usamos caja negra
  • Instanciación [Concreta/Abstracta]
    • Una instanciación concreta implica que un actor inicia el CU
    • Si fuera Abstracta, es que el CU es una subfunción iniciada por otro CU
  • Interacción [Semántica/Dialogal]
    • Interacción semántica sólo describe qué se hace
    • La Dialogal incluye los detalles de implementación
• Reglas de negocio relacionadas con cada paso, y sus tipos

Condiciones de ejecución

• Las Precondiciones son la imagen del estado del sistema y sus actores en el momento antes de que se comience a ejecutar un caso de uso
  • De no cumplirse, el CU no empezaría nunca
  • Las poscondiciones de sistema suelen ser las precondiciones del siguiente CU
• Las Poscondiciones reflejan los resultados de los cambios que fueron realizados
• Esto me permite armar una red de pre- y post- condiciones para verificar que
  • tengo todos los CUU necesarios para alcanzar la meta resumen
  • las pre/post condiciones de un CU están bien (las comparo con las post/pre del anterior/siguiente CU)
• En el caso de que el CU se completa por un camino alternativo, pero no cambia a ningún estado que no esté en el principal, se marca Éxito alternativo = <vacío>
  • Sucede lo mismo con el fracaso, si no se alcanza la meta

Anexos

Definiciones previas, abreviaciones

Niveles de meta

Pre/post- condiciones

En un CURS las Pre- de negocio se omiten
En un CURN las Pre- de sistema se omiten
En CURS & CURN se escriben ambos tipos de post-

Preguntas