Ir al contenido principal

Diagramas de Casos de Uso

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

Dougals dijo…
Excelente Gustavo !
Gustavo Bonalde dijo…
Gracias Dougals, seguimos en contacto.

Entradas más populares de este blog

¿Cuál programa tomo? ScrumAlliance vs. Scrum.org

Luego de participar en varias discusiones de foros acerca de las distintas certificaciones que existen de Scrum, me decidí a escribir este post para tratar de aclarar este enredo (CSM, CSPO, CSD, CSP, CSC,CST, PSD, PSF, PSM, PSPO, PMI-ACP) que a veces surge con todo esto.

Resulta que los 2 principales organismos ScrumAlliance y Scrum.org (hay otros varios como ScrumManager.net) que ofrecen los cursos de certificación en Scrum, vienen del mismo origen: Ken Schwaber. En una carta del año 2010, Ken explica por qué deja el ScrumAlliance y decide crear un nuevo instituto: "Este viajeha sido moldeado pordos fuerzas opuestas: el deseo dehacer lo correcto,y el deseo deganar dinero.ForméScrum.orgpara reenfocarmis esfuerzos enhacer lo correcto.".. Lo cierto es que no se puede negar el factor "revenue" para estas empresas, por su cursos, certificaciones y assessment que ofrecen, al igual que su objetivo de divulgar Scrum y mantenerlo por un buen tiempo.

A continuación les dejo…

Borrador de la 6ta edición de PMBOK

Les dejo un extracto de los cambios más relevantes del borrador del PMBOK 6, cuya versión definitiva se prevé para el tercer trimestre del 2017.

La secciones de la 1-3 han sido modificadas, dejando la información importante y agregando nueva información que refleja la evolución del Gerente de Proyecto hacia agente de cambio y proveedor de valor de negocio. En la sección 1, se incorporan términos relacionados con enfoques ágiles y entornos iterativos y adaptativos.Los grupos de procesos se mantienen igual que en la versión 5.Cambian de nombre 2 área de conocimiento:
Versión 5 Versión 6 Project Time Management Project Schedule Management* Project Human Resource Management Project Resource Management.

*Me gusta, porque definitivamente el tiempo no se gestiona, podemos gestionar son las actividades.

Hacer las cosas correctas vs Hacerlas correctamente

"Hacer las cosas correctas" es un aspecto de satisfacción en el producto, servicio o resultado que se quiere hacer, mientras que "Hacerlas correctamente" se refiere más al método utilizado en su desarrollo o implementación.

Existen cuatro combinaciones posibles:

Hacer lo correcto y hacerlo correctamenteHacer lo correcto y hacerlo incorrectamenteHacer lo incorrecto y hacerlo correctamenteHacer lo incorrecto y hacerlo incorrectamenteSi lo llevamos a los conceptos de Management: "Estrategia y Táctica", la combinación quedaría de la siguiente manera:
Se tiene una estrategía y se cuenta con una táctica adecuada (el estado del arte)Se tiene una estrategía y no se cuenta con una táctica (según Sun Tzu “Strategy without tactics is the slowest route to victory" )No se tiene estrategía, pero se cuenta con una táctica adecuada (según Sun Tzu "Tactics without strategy is the noise before the defeat”)No se tiene estrategía, ni tampoco con táctica (al menos …