Casos de Uso

admin

April 19, 2016

UML

No Comment

Los Casos de Uso

Los Casos de Uso son los escenarios que se pueden presentar en el sistema, son el corazón del diseño y se obtienen de la especificación funcional.

La especificación funcional es platicada, cómo contarle a un colega como funciona el sitema. Los Casos de Uso son tables, separando esta plática en partes, manteniendo simplicidad.

Los Casos de Uso son escenarios, desde el punto de vista del usuario, sobre lo que puede hacer en el sistema, el orden en el que acontecen los eventos y los diferentes caminos que se pueden tomar. Simplemente los escribes o bocetas y luego los vacías en tablas.

Tal como la especificación funcional, responde las seis preguntas maestras:

¿Que? ¿Quién? ¿Cómo? ¿Cuándo? ¿Dónde? ¿Por qué?

¿Qué? es el título, el nombre del escenario, del Caso de Uso, ¿Qué está haciendo el usuario?

¿Quién? es el rol del usuario que está realizando las acciones (el administrador, el cliente, el que solo ve reportes, etc.)

¿Cómo? Son los pasos que tiene que realizar para llevar a cabo la actividad.

¿Cuándo? y ¿Dónde? Son las condiciones que se tienen que cumplir para que se lleve a cabo el Caso de Uso, les llamaremos Pre Condiciones.

¿Por qué? es la razón escencial por la cuál se lleva a cabo el caso de uso, es el resumen, la descripción del mismo.

Los Diagramas

Son los clásicos “monitos”, simplemente es un garabato representando a una persona con sus acciones en forma de globos y una flechita para indicar que el usuario puede utilizarlos.

Una línea punteada de un caso de uso a otro significa “extender” y es un flujo alternativo del mismo. Un flujo alternativo es otro camino que puede tomar el caso de uso, cuando ocurre una desición. En el ejemplo, al dar de alta un usuario, puede ser que el usuario ya exista, entonces el sistema responde al usuario de diferente manera.

Por simplicidad, el primer caso de uso, del cual se extienden los demás, es el conocido “happy path”, en el que todo sale bien y sin contratiempos. Todo lo que pueda salir mal, causar contratiempo o tenga dependencia de una desición es una extensión del caso de uso inicial, un flujo alternativo.

Caso de Uso

El ejemplo

Los casos de uso no solo son los diagramas, lo importante es escribirlos de forma tabular para que sean fáciles de leer.

El punto fundamental aqui es la lista de pasos a seguir en el caso de uso, estos deben estar listados y escribirse en forma protocolaria, es decir, una comunicación entre dos partes: El usuario y el sistema. Se entiende mejor con un ejemplo:

Caso de Uso

Título Alta de usuario
Actor Administrador de Sistema
Resumen El administrador necesita dar de alta un nuevo usuario
Precondiciones El administrador ha iniciado sesión con sus credenciales.
Pasos
1 Administrador: Elije la opción “Nuevo usuario”
2 Sistema: Solicita se capture la información del usuario: Email, Nombre, Rol.
3 Administrador: Captura la información solicitada
4 Sistema: Valida la información registrada.
5 Sistema: Registra al nuevo usuario.
6 Sistema: Muestra al usuario administrador un mensaje de éxito.
Resultado El administrador ha creado un nuevo usuario con éxito

Flujo Alternativo 1: El usuario ya está dado de alta.

Título Alta de usuario: Usuario ya se encuentra en el sistema.
Actor Administrador de Sistema
Resumen El administrador necesita dar de alta un nuevo usuario, sin embargo, este ya se encuentra registrado en el sistema.
Precondiciones El administrador ha iniciado sesión con sus credenciales.
Pasos
4.1 Sistema: Encuentra que el usuario ya ha sido registrado.
4.2 Sistema: Informa del error al usuario mediante un mensaje.
4.3 Administrador: Cancela la operación
Resultado El administrador no pudo crear un nuevo usuario, este ya se encontraba registrado en el sistema

Como podemos ver, el flujo alternativo es una extensión del flujo principal, en el cual por una condición podemos llegar a otro resultado.

Hacer los diagramas es muy sencillo, puedes usar cualquier programa de gráficos, desde Power Point hasta MS Visio. Mi favorito es Dia, para hacer diagramas, tiene muchas preplantillas, hay versión portable, es ligero y sencillo.

Sin embargo, no es necesario instalar nada, el pequeño diagrama que ves lo realicé con Google Docs.

Un punto muy importante a destacar es que documentar normalmente es percibido como un proceso doloroso. Yo mismo lo sufrí mucho tiempo, pero no tiene que ser así, lo mejor es expresarte lo más sencillo que puedas y mantener el foco en el resultado final: La comunicación de ideas.

Esto es especialmente difícil cuando trabajas en una empresa altamente burocratizada donde tienes que seguir formatos que parecen hechos por tu peor enemigo, en donde todo, desde tablas hasta documentos y gráficos los tienes que poner en Excel.

Créeme, esto lo sufrí sobremanera. Pero siempre es mejor tener documentación a no tenerla, y nada facilita más el trabajo de los programadores que unos casos de usos completos y detallados pero simples.

Related Posts

Orientación a objetos: Introducción

admin

February 9, 2010

UML

No Comment

¿Qué es la orientación a objetos? Es una forma de modelar y desarrollar software la cual se basa en la creación de componentes reutilizables y tiene como principal característica la simulación de objetos reales.Ok, muy bonito, pero ¿Qué es eso? Pues bien, para conocer realmente la orientación a objetos tenemos que determinar sus principios básicos. […]

Read More

Diagrama de clases: Introducción

admin

February 9, 2010

UML

1 Comment

¿Qué es una clase? Estrictamente hablando, es una abstracción de una entidad, pero más sencillamente, podemos pensar en una clase como una plantilla, utilizada para categorizar o clasificar (de allí su nombre) alguna cosa en particular. Vale, pero ¿Cómo hago esto? Pues simplemente como lo harías con cualquier cosa, ¿Cómo clasificarías un auto? Veamos: Me […]

Read More

Leave a Reply

Your email address will not be published. Required fields are marked *