Descripción del propósito del modelo de caso de uso
Los usuarios que puedan interactuar con el sistema y con cualquier otro sistema son los protagonistas. Dado que los protagonistas representan a los usuarios del sistema, ayudan a definir el sistema y proporcionan una descripción muy clara de su propósito. Los casos de uso se escriben en función de las necesidades del protagonista. Esto garantiza que el sistema se convierta en lo que los usuarios esperan que sea. Los protagonistas y casos de uso se encuentran considerando las necesidades de los clientes y los usuarios potenciales como información importante. Una vez que encuentre estos casos de uso y protagonistas, debe describirlos brevemente. Antes de describir estos casos de uso en detalle, el cliente debe examinar el modelo de casos de uso para verificar que se hayan encontrado todos los casos de uso y actores y que proporcionen lo que el cliente requiere.
En un entorno de desarrollo iterativo, puede seleccionar un subconjunto de casos de uso que se detallan en cada iteración. Consulte también la actividad: Priorizar casos de uso.
Una vez que haya encontrado sus actores y casos de uso, deberá detallar el flujo de eventos para cada caso de uso. Estas descripciones ilustran cómo el sistema interactúa con el protagonista y las acciones relevantes que realiza el sistema en cada caso de uso.
Finalmente, el desarrollador y el cliente revisan el modelo de caso de uso completo (incluidas las descripciones de los casos de uso) y acuerdan lo que debe hacer el sistema. No es raro que la degradación del modelo de casos de uso conduzca a una descomposición funcional del sistema. Para evitar esta situación, se deben tener en cuenta las siguientes fallas:
Casos de uso "pequeños", es decir, descripciones del flujo de eventos con solo una o unas pocas oraciones. Casos de uso múltiples, es decir, el número de casos de uso es cientos en lugar de docenas. Los nombres de los casos de uso se construyen como "realizar esta acción basándose en estos datos específicos" o "realizar esta función utilizando estos datos". Por ejemplo, "Ingrese en un El "código PIN" de un cajero automático no debe modelarse como un caso de uso separado para un cajero automático, porque nadie usaría el sistema para realizar solo esa operación. Un caso de uso es un flujo completo de eventos que aporta algo de valor al protagonista. .
Para evitar la descomposición funcional, debe asegurarse de que el modelo de casos de uso ayude a responder las siguientes preguntas:
¿Cuál es el contexto del sistema? ¿Qué esperan obtener los usuarios? utilizando el sistema? ¿Qué valor se crea para los usuarios? No es difícil ver que los casos de uso son una buena manera de obtener los requisitos funcionales del sistema. ¿Cuáles son los requisitos no funcionales? divididos en requisitos de usabilidad, requisitos de confiabilidad, requisitos de rendimiento y requisitos de reemplazo (ver también Concepto: Requisitos. Generalmente son requisitos que dictan la necesidad de cumplir con cualquier requisito legal o regulatorio. También pueden ser dictados por el sistema operativo. plataforma y compatibilidad utilizada. Generalmente, cualquier requisito que no permita múltiples opciones de diseño puede considerarse una restricción de diseño.
Muchos requisitos no funcionales se aplican a un solo caso de uso y están disponibles dentro de él. la funcionalidad de ese caso de uso, en cuyo caso estos requisitos se pueden obtener en el flujo de eventos del caso de uso, o como requisitos especiales para el caso de uso (ver Guía: Casos de uso
Ejemplo:
). En un sistema de reciclado, un requisito no funcional específico para el caso de uso de devolución de artículos almacenados es que la confiabilidad del reciclador en la identificación de artículos almacenados debe ser superior a 95.
Normalmente, los requisitos funcionales se aplican a todo el sistema. Dichos requisitos se pueden encontrar en la Carta Suplementaria (ver Artefacto: Carta Suplementaria). Ejemplo:
En un sistema de máquina de reciclaje, los requisitos no funcionales se aplican a todo el sistema. La estipulación es:
.El reciclador solo puede ser utilizado por un usuario a la vez. Aprender a determinar el "principio y el final" de un caso de uso es muy difícil. Finalizando, ¿dónde comienza el diseño? debe definir "qué" hace el sistema, no "cómo". Aquí hay un ejemplo:
Donde termina uno, comienza el otro
Dependiendo de su contexto personal. , puede utilizar diferentes contextos para determinar su comprensión de "qué" y "cómo" al decidir si un detalle debe excluirse de un caso de uso. Cuando se mira fuera del modelo, existe una distinción entre casos de uso concretos y casos de uso abstractos. deben ser considerados cuidadosamente.
Los casos de uso específicos los inicia el protagonista y constituyen un flujo de eventos completo. "Completo" significa que la instancia del caso de uso realiza todas las operaciones llamadas por el actor. Los casos de uso abstractos en sí nunca se crean instancias. Un caso de uso abstracto está contenido (consulte Guía: Contiene relaciones), se extiende (consulte Guía: Ampliar relaciones) o se generaliza (consulte Guía: Relaciones de generalización de casos de uso) a otros casos de uso. Cuando se lanza un caso de uso específico, se crea una instancia de ese caso de uso. La instancia también muestra las actividades especificadas por su caso de uso abstracto asociado. Por lo tanto, no es posible crear instancias separadas a partir de casos de uso abstractos.
Dado que lo que el protagonista "ve" e inicia en el sistema es un caso de uso específico, la distinción entre los dos es importante.
Para indicar que un caso de uso es un caso de uso abstracto, puede poner su nombre en cursiva. Ejemplo:
El caso de uso "Registro" contiene el caso de uso "Crear tarea". El caso de uso "Crear tarea" es un caso de uso abstracto.
En el sistema de gestión de almacenes, el caso de uso abstracto "Crear tarea" se incluye en el caso de uso "Registrar pedido". Cuando se inicia el caso de uso "Registrar orden", se crea una instancia de "Registrar orden". Además de seguir el flujo de eventos para la Orden de registro, esta instancia también sigue el flujo de eventos descrito en el caso de uso "Crear tarea". La propia tarea Crear nunca se ejecuta, pero siempre es parte de "Registrar orden" (o cualquier otro caso de uso que incluya "Crear tarea"). Por lo tanto, crear una tarea es un caso de uso abstracto. Hay tres razones principales para modelar casos de uso:
Los casos de uso son más fáciles de entender. Aísle comportamientos comunes descritos en muchos casos de uso. Los modelos de casos de uso son más fáciles de mantener.
Sin embargo, construir el modelo no es lo primero que hay que hacer. Nunca cree un caso de uso a menos que tenga una comprensión más profunda de su comportamiento que una breve descripción. Como mínimo, debe crear un esquema paso a paso del flujo de eventos para este caso de uso para garantizar que sus decisiones se basen en una comprensión precisa y completa del comportamiento.
Hay tres relaciones que se pueden utilizar para crear casos de uso. Puede utilizar estas relaciones para analizar componentes de casos de uso que se pueden reutilizar en otros casos de uso, o como casos de uso especiales u opciones para ese caso de uso. Los casos de uso que representan modificaciones se denominan casos de uso adicionales. El caso de uso modificado se denomina caso de uso básico.
Si hay una parte de la funcionalidad del caso de uso base que está determinada únicamente por su resultado en lugar del método que produce ese resultado, entonces esta parte de la funcionalidad se puede separar y poner en un caso de uso adicional. Al utilizar relaciones de inclusión, se pueden insertar explícitamente casos de uso adicionales en los casos de uso base. Consulte también la guía: Contener relaciones.
Si parte del caso de uso base es opcional o innecesario para comprender el propósito principal del caso de uso, puede simplificar el caso de uso base separando esa parte en una estructura de casos de uso adicionales. Al utilizar una relación de extensión, se pueden insertar implícitamente casos de uso adicionales en el caso de uso base. Consulte también la guía: Ampliar las relaciones.
Si los casos de uso son más similares en comportamiento y estructura, y más similares en propósito, sus partes más similares se pueden separar para formar un caso de uso básico (caso de uso principal). Otros casos de uso (casos de uso secundarios) pueden heredar del caso de uso principal. Los casos de uso secundarios pueden insertar un nuevo comportamiento o modificar el comportamiento existente en la estructura heredada del caso de uso principal. Consulte también la guía: Relaciones de generalización de casos de uso.
Puedes utilizar relaciones de generalización de actores para mostrar la especialización entre actores. Ver también guía: Relaciones de generalización de protagonistas.
Ejemplo:
Tome como ejemplo la parte del modelado de casos de uso del sistema de gestión de pedidos.
Debido a que sus características son ligeramente diferentes, es útil separar a los clientes genéricos de los clientes de Internet. Sin embargo, dado que los clientes de Internet tienen todas las características de los clientes, se puede decir que los clientes de Internet son un caso especial de clientes y pueden representarse mediante la relación resumida del protagonista.
En el diagrama, los casos de uso específicos son "Pedido telefónico" (enviado por el actor cliente) y "Pedido por Internet" (enviado por el cliente de Internet). Estos casos de uso son los "Casos de uso abstractos" más generales. El caso de uso del catálogo de solicitudes es un segmento opcional de comportamiento que no forma parte del objetivo principal del caso de uso "Pedido". Para simplificar el caso de uso de "ordenar", lo separamos en un caso de uso abstracto.
El caso de uso "Proporcionar datos del cliente" es un comportamiento independiente. La razón por la que se separa es que es una función independiente y solo su resultado afecta el caso de uso "Pedido". También se puede utilizar en otros casos de uso. Reutilizar. En este ejemplo, el caso de uso "Solicitar catálogo" y el caso de uso "Proporcionar datos del cliente" son casos de uso abstractos.
Este diagrama de casos de uso muestra la parte del modelo de usuario del sistema de gestión de pedidos.
La siguiente tabla muestra una comparación más detallada entre tres relaciones de casos de uso diferentes:
Otra forma de organizar un modelo de casos de uso para una comprensión más sencilla es agrupar los casos de uso en paquetes. Un modelo de casos de uso se puede organizar en una estructura jerárquica que consta de paquetes de casos de uso, siendo los protagonistas o casos de uso las "hojas" de la estructura. Consulte también la guía: Paquetes de casos de uso. Este diagrama muestra la estructura jerárquica del modelo de casos de uso. Las flechas indican posibles relaciones de propiedad. La encuesta del modelo de casos de uso debe ilustrar los principales casos de uso del sistema (por qué se construyó el sistema). Resumir realidades técnicas importantes del sistema. Indicar los límites del sistema: acciones que el sistema no realizará. Describa el entorno del sistema, como la plataforma de destino y el software existente. Describa la secuencia de casos de uso que normalmente realiza este sistema. Detalle la funcionalidad que el modelo de caso de uso no maneja. Para ilustrar: Aquí hay un ejemplo de descripción de encuesta de un modelo de caso de uso de reciclador: El modelo consta de tres actores principales y tres casos de uso. El caso de uso principal es "Artículos de reciclaje", que describe el propósito principal de la máquina de reciclaje. Un caso de uso secundario es "Imprimir diariamente", que permite al operador obtener un informe sobre la cantidad de artículos que se han reciclado. "Administrar artículos de almacenamiento", que los operadores pueden usar para cambiar el monto del reembolso para un tipo de artículo de almacenamiento o agregar un nuevo tipo de artículo de almacenamiento.