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 siguiente |