¿Cómo puedo determinar qué debo agregar a mis diagramas de casos de uso? 1 por cada botón/forma? ¿Deben incluirse cosas como ordenar y buscar? ¿O están bajo "elementos de la lista", por ejemplo? Sin embargo, una lista de elementos parece entendido?Granularidad de caso de uso. ¿Debiera clasificarse/buscarse?
El diagrama de casos de uso está destinado a ayudar a definir las tareas comerciales de alto nivel que son importantes, no una lista de funciones del sistema. Por ejemplo, un sistema para su uso en el servicio al cliente podría incluir una tarea de búsqueda de buscar información para ayudar a alguien en una llamada de soporte.
La mayoría de la literatura describe los casos de uso como un punto de partida para definir lo que el sistema necesita lograr. La tentación siempre ha sido ser lo más completo posible; añadiendo cada vez más detalles para definir el caso de uso hasta un nivel funcional (basado en el código). Si bien es útil tener una comprensión exhaustiva de los requisitos, el diagrama de casos de uso no pretende proporcionar ese nivel de documentación.
Una cosa que empeora el problema es la sintaxis que nunca he visto utilizada en un proyecto en funcionamiento. No es que los términos no sean útiles, es debido a la falta de consenso sobre cuándo usar cualquiera de los términos para un caso de uso dado. Los artefactos UML esperan un proceso que se centre más en el lenguaje comercial en lugar del lenguaje de implementación, y con eso no me refiero a un lenguaje informático. La tendencia de algunos ha sido acercarse a los diagramas con una inclinación legalista y preocuparse por cosas como cuándo usar para casos de uso relacionados o cómo expresar el manejo de errores como excepciones a una lista definida de tareas de proceso.
Si alguna vez ha intentado trabajar con el ejemplo de la máquina de cajero automático (ATM), sabrá a qué me refiero. En el sistema solar de aprendizaje UML, el ejemplo ATM es un agujero negro que te absorberá en los detalles. Evite usarlo para comprender UML o el Análisis y Diseño Orientado a Objetos. Tiene muchos de los problemas, típicos de los dominios del mundo real, que distraen la comprensión general, a pesar de que sería un buen estudio avanzado.
Sí, el código finalmente se producirá a partir de los artefactos UML, pero eso no significa que deba debatirse como un tratado en el Senado.
El OMG UML spec dice:
Los casos de uso son un medio para especificar los usos necesarios de un sistema. Por lo general, se utilizan para capturar los requisitos de un sistema, es decir, lo que se supone que debe hacer un sistema. Los conceptos clave asociados con los casos de uso son actores, casos de uso y el tema. El sujeto es el sistema bajo consideración al que se aplican los casos de uso. Los usuarios y cualquier otro sistema que pueda interactuar con el sujeto se representan como actores. Los actores siempre modelan entidades que están fuera del sistema.
El comportamiento requerido del sujeto se especifica mediante uno o más casos de uso, que se definen según las necesidades de los actores. Estrictamente hablando, el término "caso de uso" se refiere a un tipo de caso de uso. Una instancia de un caso de uso se refiere a una ocurrencia del comportamiento emergente que se ajusta al tipo de caso de uso correspondiente. Tales instancias a menudo se describen mediante especificaciones de interacción.
Un actor especifica una función que desempeña un usuario o cualquier otro sistema que interactúa con el sujeto. (El término “papel” se utiliza informalmente aquí y no implica necesariamente la definición técnica del término encontrado en otras partes de esta especificación.)
Ahora la mayoría de la gente estaría de acuerdo en que las interacciones a nivel de empresa y el usuario son el punto dulce , pero no hay limitaciónPiense en los actores/roles que están fuera del sistema principal/sistemas en los que se está enfocando. Pero en una vista, un sistema podría ser un actor, pero en otro, el implementador de otros casos de uso.
La granularidad normal de usecase es el objetivo del escenario, no el paso. –