Granularidad de los casos de uso
Diferente granularidad
Un caso de uso se puede asociar a un objetivo del usuario o a una interacción básica con el sistema.
Un objetivo implica una o más interacciones.
Se debe definir un caso de uso por cada objetivo del usuario.
Granularidad
Casos de uso del negocio
Procesos de Negocio: Objetivo estratégico de la empresa
Ej. Venta productos
Casos de uso del sistema
Objetivo de un usuario
Ej. Realizar una compra
Casos de uso de inclusión
Forman parte de otro, son como subfunciones
Ej. Buscar, Validar, Login
Granularidad
¿Qué granularidad es apropiada para un caso de uso del sistema?
Sirven para planificar el proyecto
Se les asocia un flujo de interacciones actor-sistema
Deben ser objetivos del usuario
¿En un sistema de venta por internet, son casos de uso “Añadir producto al carro de la compra” o “Introducir datos facturación” ?
Tipos de casos de uso
Según el nivel de detalle
Breve : Descripción en unas pocas líneas
Informal : Varios párrafos que cubren varios escenarios
Completo : Descripción detallada con una plantilla
Según la importancia
Primario, secundario u opcional
Según el nivel de abstracción
Esencial : intenciones del usuario y responsabilidades del sistema
Concreto : Se contemplan detalles de implementación (GUI y tecnología)
Recomendaciones
Especificar casos de uso no es una actividad de dibujar diagramas sino de escribir con el detalle necesario el flujo principal y los flujos alternativos: “centrado en la escritura en vez del dibujo”
El objetivo inicial es identificar los actores y a partir de sus objetivos encontrar los casos de uso, el diagrama de casos de uso es una ayuda visual.
El texto de los casos de uso debe ser claro.
No abusar de la relación de inclusión.
¡No hacer una descomposición funcional!
Las relaciones de generalización y extensión no deberían utilizarse.
Recomendaciones
Un caso de uso debe tener una granularidad apropiada, especifica una interacción en la que se produce un resultado de valor para un actor.
No identificar como caso de uso lo que son interacciones que forman parte de una interacción mayor que las engloba y no son casos de uso de inclusión.
Un error común es no identificar como casos de uso las tareas que inicia el propio sistema (Actor Tiempo)
“Anular reservas pasados quince días”
Recomendaciones
No incluir como caso de uso las operaciones CRUD sobre un objeto de negocio (alta, consulta, borrado, actualización): función del sistema aparte, excepto si se trata de operaciones relevantes para el sistema, como “registrar cliente” en un sistema de venta por Internet.
Cuidado con el empleo de la relación “include”
¡No hacer una descomposición funcional!
Escribir casos de uso independientes de la interfaz o de detalles de implementación, escribirlos a nivel esencial. Centrarse en el qué no en el cómo.
Recomendaciones
Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema.
Preocupación por mantener la validez y consistencia del conjunto de casos de uso.
Cada compañía debe tener un manual sobre uso de los casos de uso.
Algunos requisitos funcionales no conviene expresarlos como casos de uso.
Mal uso de los casos de uso
 Página anterior | Volver al principio del trabajo | Página siguiente  |