Los diagramas de casos de uso es una forma gráfica de plasmar los requerimientos funcionales o servicios de un sistema, independientemente si aplicamos una metodología como RUP (rational unified process) o una metodología ágil como SCRUM+XP, el contar con el “big picture” de los servicios propuestos siempre me ha dado buen resultado.
Es por eso que en esta oportunidad conversaré sobre buenas prácticas a la hora de diagramar los casos de uso, para ello, voy a utilizar la herramienta de modelado de SYBASE: Power Designer 15; en caso de que quieras iniciarte utilizando alguna herramienta libre te recomiendo StarUML.
Una de las fortalezas de los DCU es la simplicidad de su notación,
- Caso de uso, mediante un óvalo (Servicio o funcionalidad del sistema)
- Actor, mediante una figura humana o monigote (Cualquier cosa que interactúa con el sistema; ej: personas, sistemas, tiempo, etc.)
- Relaciones y sus estereotipos: asociación, include, extend o generaliza (de los cuales hablaré en una próxima entrega)
- A partir de UML 2.0 contamos con un recuadro que nos permite indicar el límite de nuestro sistema
Antes de comenzar a dibujar nuestro DCU recordemos algunas premisas:
- Los casos de uso deben utilizar terminología del dominio, es decir, el lenguaje del negocio ya que se realizan desde la perspectiva del usuario o cliente.
- El nombre de los CU se deben colocar en infinitivo, por ejemplo: generar factura, solicitar préstamo, aprobar crédito, etc.
- El DCU debe hacerse iterativamente
Ahora comencemos a dibujar nuestro DCU tomando como base las funcionalidades o servicios básicos del microblogging; “Twitter”.
En mi caso me resulta muy útil comenzar por identificar los actores y luego los casos de uso asociados a cada uno; para identificar los actores me hago la siguiente pregunta: ¿Quién o qué interactuará con el sistema propuesto?
En una primera iteración, se pueden identificar los siguientes actores:
Visitante: Persona que navega en el sitio de Twitter sin estar registrado
Twittero: Usuario previamente registrado en Twitter.
Luego de haber identificados a los actores, podemos asociarlos con los servicios que queremos proveer en el sistema propuesto (casos de uso):
Otras buenas prácticas a seguir:
- Colocar al actor(es) primario(s) en la esquina superior izquierda del diagrama
- Utilizar actor “Tiempo” para indicar el inicio o disparo de servicio mediante eventos agendados
- Los actores modelan “roles” no posiciones
- Los actores no interactúan entre ellos (únicamente pueden relacionarse mediante el estereotipo “generaliza”)
- Nombre de actores en singular
En una próxima publicación colocaré una nueva iteración de este ejercicio agregando los estereotipos: include, extend y generaliza.
Comentarios