casos de uso

1. EJEMPLO DE CASOS DE USO
Se trata de entender el sistema como una historia. Una historia
tiene personajes, unas acciones, y un contexto. Un diagrama de
casos de usos es la representación en UML de una historia.
Un caso de uso describe lo que siempre tiene que pasar dentro de nuestro
sistema y los pasos para llegar a ello, pero también debe contemplar casos menos
comunes. Por ejemplo, en caso de una avería o si el usuario cambia de idea a lo
largo de su interacción
Ejemplo de un caso de uso
Vamos a ver algunos casos de uso para una tienda online.
Se pide desarrollar el siguiente sistema de información.
1. Un vendedor de libros se conecta a la web para subir el articulo que tiene
a la venta.
2. Un cliente se conecta a la página web de una tienda online para comprar
un libro. Escribe el título del libro en la barra de búsqueda y busca el mejor
precio entre los resultados. Cuando encuentra una oferta que le interesa, le
añade al carrito de la compra. Tiene que haber iniciado una sesión para
poder hacerlo.
Solución
Los casos de uso siempre deben comportar un verbo.
Este es un caso de uso muy sencillo. Muchas veces, la descripción será más larga
si el proyecto es más complejo.
Ahora tratemos de traducir nuestro caso de uso a un diagrama de casos de uso.
Este diagrama incluye lo siguiente :
 Un actor o varios actores.
 Acciones.
 Relaciones de "include" y "extend".
Los actores son los diferentes participantes en nuestro escenario. Son los que
llevan a cabo las acciones que describimos en los casos de uso. Los actores se
representan como figuras de palo. No hace falta ser muy buen dibujante
¡Los actores no son necesariamente personas! Pueden representar
organizaciones o incluso componentes del software.

2. Las acciones son aquello que hacen los actores con el sistema. Son
funcionalidades que deberán ser luego implementadas.
En el centro, dibujamos el sistema. Es el escenario dónde nuestros actores
interactúan. Lo representaremos como un rectángulo, y dibujaremos los casos de
uso dentro del sistema.
Primera etapa del diseño de un diagrama de casos de uso
Empecemos con las primeras acciones descritas en el caso de uso textual: el
comprador buscando un artículo. Podemos añadir “ver artículos” en el sistema.
Dibujamos una linea entre el comprador y la acción para significar quien lleva a
cabo la acción. También añadimos la acción “subir artículo” y dibujamos una línea
entre el vendedor y la acción.

3. Actores y acciones
Para poder elegir la mejor oferta, el comprador tiene que ser capaz de ordenar los
articulos por precio. Usaremos la palabra clave <<extend>> para designar una
acción que puede derivar de otra, dibujando una linea punteada entre los casos
de uso con la palabra<<extend>>en la linea.
Añadimos la palabra clave <<extend>>

4. Ahora pasamos a la acción “comprar articulo”. Esta acción involucra
el comprador así como el vendedor. También hemos de añadir otro actor, ya que
para efectuar el pago, necesitamos usar el sistema de pagos. Lo añadiremos
como otro actor (recordar que los actores no son necesariamente humanos!).
Dibujamos una línea entre cada actor y la acción.
Añadimos la acción "comprar artículo"
Finalmente, hemos de asegurarnos de que para poder comprar, un usuario este
registrado en la plataforma. Este requerimiento lo modelamos con la palabra
clave<<include>>con una flecha desde “comprar artículo” hacía “iniciar sesión”.

5. Añadimos una acción con la palabra clave <>
Con esto hemos visto los principales elementos de un diagrama de casos de uso.
Es bastante sencillo, ¿no? Pero no te dejes engañar: esta etapa es muy
importante para entender el contexto del trabajo que vamos a realizar, y nos
permite enfocarnos solo en lo importante y descartar el resto. Recuerda que los
elementos que siempre debe llevar un diagrama de casos de uso son
 Actores
 Acciones
 Líneas entre los actores y las acciones que les corresponden
Adicionalmente, puede comportar
 relaciones <<include>> entre acciones cuando una acción es prerequisito
de otra
 relaciones <<extend>> entre acciones cuando una acción es una opción
después de realizar otra.