Un caso de uso representa la funcionalidad completa tal y como la percibe un actor. Un caso de uso en UML es definido como un conjunto de secuencias de acciones que un sistema ejecuta y que permite un resultado observable de valores para un actor en particular. Gráficamente se representan con una elipse y tiene las siguientes características:
- Un caso de uso siempre es iniciado por un actor.
- Un caso de uso provee valores a un actor.
- Un caso de uso es completo.
Los casos de uso son una herramienta esencial en la toma de requisitos del sistema. Nos permiten expresar gráficamente las relaciones entre los diferentes usos del mismo y sus participantes o actores. El resultado es un conjunto de diagramas muy fácilmente entendibles tanto por el cliente, como por los analistas del proyecto.
No definen todos los requisitos (por ejemplo, tipos de datos, interfaces externas, rendimiento, etc.) pero sí que representan el hilo conductor que los vincula a todos con los actores del sistema.
Facultad de Ingeniería de la UNAM. Temas especiales e computación. Diagrama de casos de uso. Ing. Carlos Alberto Román Zamitiz. Recuperado el 20 de Noviembre 2011, de http://profesores.fib.unam.mx/carlos/aydoo/uml.html
UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf
No definen todos los requisitos (por ejemplo, tipos de datos, interfaces externas, rendimiento, etc.) pero sí que representan el hilo conductor que los vincula a todos con los actores del sistema.
Se componen de los siguientes elementos:
• Actores: representan los roles que juegan los usuarios u otros sistemas en el sistema del problema. Identificar a los actores de un caso de uso pasa por averiguar quién está involucrado en cada requisito concreto, quién se beneficiará de cada funcionalidad o quién proveerá o usará la información.
• Caso de uso: son las acciones que pueden tener lugar en el sistema que queremos modelar. Para identificarlas, puede ser útil preguntarse cuáles son las tareas y responsabilidades de cada actor, si habrá actores que recibirán información del sistema, etc.
• Relaciones: indican actividad o flujo de información.
• Límite del sistema: define el ámbito donde se produce el caso de uso que estamos representando y que va a ser tratado por el sistema. Los actores no son parte del sistema y por lo tanto están fuera de sus límites.
La etiqueta <<incluye>> entre dos casos de uso indica que uno tiene la funcionalidad de otro como parte integrante suya.
La etiqueta <<extiende>> indicará que un caso de uso amplía la funcionalidad de otro.
La etiqueta <<generaliza>> indica también una relación padre e hijo similar a la extensión, con la diferencia de que actúan exactamente igual en cuanto a reglas de negocio se refiere.
Dado el alto nivel al que estamos modelando el sistema en esta fase, es importante tener presentes algunas buenas prácticas con respecto a la interpretación y creación de diagramas de casos de uso:
• Empezar los nombres de los casos de uso con un verbo.
• Aunque no hay forma de indicar el orden en que un actor aplicará los casos de uso, suele ser más intuitivo representarlos en orden descendiente, situando los más importantes en la parte superior del diagrama.
• Situar a los actores principales en la parte superior del diagrama también ayuda a su comprensión y a generalizar de forma más entendible.
• Nombrar a los actores con sustantivos relacionados con las reglas de negocio, de acuerdo con los roles que representan. No con su cargo o posición en el sistema.
• Anteponer “Sistema” o <<sistema>> a los actores que sean procesos externos.
• Para representar eventos que ocurren de forma programada, podemos introducir un actor de sistema “Tiempo” para modelar sus casos de uso.
• La etiqueta <<incluye>> no es obligatoria. Es aconsejable incluirla sólo si en un punto específico la lógica del caso de uso incluido es necesaria.
• No debe abusarse de la etiqueta <<extiende>>, ya que dificulta la comprensión del caso.
• La generalización de clases suele identificarse porque una sola condición del caso de uso (en el ejemplo, el método de envío), cambia por completo su lógica interna, pero no así las reglas de negocio del sistema.
• Debe evitarse representar más de dos niveles de asociaciones de casos de uso en un mismo diagrama. Si nos encontramos en esta situación, hay muchas probabilidades de que estemos haciendo una representación funcional de lo que ocurre en el caso de uso. Debemos concentrarnos sólo en los requisitos de uso, ya que la descomposición funcional es parte de la fase de diseño.
• Situar los casos incluidos a la derecha del caso que los incluye ayuda a comprender mejor el diagrama. De la misma forma, es más intuitivo situar los casos que extienden debajo del caso padre, al igual que los casos que heredan o generalizan.
• Es útil intentar expresar con “es como” la generalización de actores para comprobar si los estamos modelando correctamente.
Fuentes:
UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf
No hay comentarios:
Publicar un comentario