Casos de uso y descomposición funcional

Imaginemos que estamos capturando requerimientos para una página web que tiene que incluir un foro. Hablamos con el usuario líder, y nos cuenta que es necesario que  el administrador del sistema esté en capacidad de bloquear el acceso a los usuarios que repetidamente muestren un comportamiento inadecuado en el foro (escriban en mayúsculas, resuciten threads antiguos, utilicen palabras malsonantes y otras exquisiteces de los foristas). Después de la entrevista vamos a nuestra oficina, iniciamos nuestra herramienta CASE y aplicamos la técnica de casos de uso según lo que nos enseñaron en la universidad para producir este diagrama:

Diagrama construido con StarUML

Esta primera versión tiene algunos inconvenientes. Por definición, un caso de uso debe producir valor para los actores con los que interactúa (según Kurt Bittner) y no creo que el Administrador encuentre mucho valor a la tarea de "Buscar Usuarios" o de "Mostrar Información de Usuario". A menos que se trate de reportes -y no es el caso- el Administrador del Foro no va a entrar a nuestra aplicación sólamente a realizar una búsqueda o a consultar información de un usuario, sino lo que desea es estar en capacidad de bloquear a los usuarios rebeldes. Por ahí ya tenemos problemas.

Ahora, tal vez nuestra intención inicial de agregar tantos casos era para poner en evidencia que para bloquear a un usuario es necesario primero buscarlo, luego mostrar un formulario con su información básica, después  ingresar los motivos por los que se le va a bloquear para finalmente realizar el bloqueo. Si ese fue el caso caimos en otro error, dado que los casos de uso no "invocan" a otros casos de uso y mucho menos se comunican entre ellos. Realizar esto es intentar convertir los casos de uso en funciones, lo que nos lleva al problema de la descomposición funcional: Descomponer un problema en partes pequeñas y aisladas entre sí, que trabajando juntas nos proveen de una funcionalidad del sistema.

La descomposición funcional de casos de uso hace que estos pierdan contexto, como el caso de uso "Asignar motivos de bloqueo" que no tiene sentido sin el resto de casos de uso del diagrama. También está el tema del valor para los actores que mencionábamos al inicio, el  mismo caso de uso "Asignar motivos de bloqueo" no le va a servir al Administrador si es que el usuario al final no termina bloqueado.

Ahora ¿qué hacemos para no caer en esto?. Navegando me topé con un documento de Kurt Bittner en el que nos sugiere tres cosas:

  1. Centrarse en casos de uso que provean valor real a los stakeholders. En el caso de nuestra administrador, buscando usuarios no gana mucho.
  2. Limitar el uso de "includes" sólamente para representar descripciones comunes entre caso de uso. Y usarlas con muchísimo cuidado.
  3. Limitar el uso de "extends" sólamente para agregar comportamientos opcionales a casos de uso existentes que por si mismos generen valor. Personalmente, no me gusta mucho utilizar esta relación.

Entonces, sabiendo esto borramos nuestro primer borrador defectuoso y lo cambiamos por este mucho más simple y elegante:

Este diagrama también lo hice con StarUML


En la especificación de caso de uso ya podemos explayarnos describiendo el flujo deseado.  Recuerden que un modelo de casos de uso es principal y mayoritariamente texto. Eso sería todo en esta entrega, hasta otra!

4 comments

Creo poder adivinar EL FORO que produce tu inspiración xD

Reply

El tortuoso foro de los martes y jueves xD

Reply

A decir verdad, es miércoles y jueves :)

Qué te puedo decir, la semana pasada hice un caso de uso luego de 2.5 años aproximadamente. Aún así, se agradece el "refresh" de conceptos.

Saludos, y sigue compartiendo conocimiento :D

Reply

Hola doc como estas, a mi parecer uno cae el problema de mal manejo de CU del Sistema, porque cree que todo en si es un CU. Por eso asocia cualquier posible tarea a un CU, eso cuando todo no es CU y muchas veces confunden CU con SubSistemas, eso es lo que refleja el 1er diagrama. Pero no, uno debe de esas tareas verificar que tareas son las candidatas a automatizar y de entre ellas tratar de agrupar a las que requieran y darle un nombre mejor (Gestionar, Controlarm etc) ya que es recomendable que 1 actor de sistema solo tenga una relaciona con 1 CU principal del Sistema y de ahi a este CU Pricipal amarrarlos con SubSistemas (Que son en si los BOTONES de un APP) o con Include o Extend. Una buena ayuda para ello es el manejo de Mockups. Finalemnte, la mayoria de personas piensa que loc CRUD deben de ser modelados e incurren en ellos, pero no se debe de hacer. Creo que escribi mucho doc jejeje. Cuidate.

Reply

Publicar un comentario