Está en la página 1de 45

Introducción a los Casos de

Uso

Facultad de Ingeniería en Sistemas


Analisis de Sistemas II
Contenido
• Qué es Caso de Uso?
• Elementos de Casos de Uso
▫ Actores
 Tipos de Actores
▫ Caso de Uso
 Construcción de un Caso de uso
 Técnicas para trabajar Casos de uso
▫ Escenarios
Contenido (Continuación)
• Ventajas de los Casos de Uso
• Peligros de los Casos de Uso
• Ejemplos
DIAGRAMAS DE CASOS DE USO

• Definición:
Un caso de uso es una descripción de los
pasos o las actividades que deberán realizarse para
llevar a cabo algún proceso.
• En el contexto de ingeniería del software, un
caso de uso es una secuencia de interacciones
que se desarrollarán entre un sistema y sus
actores en respuesta a un evento que inicia un
actor principal sobre el propio sistema.
Los diagramas de casos de uso sirven para
especificar la comunicación y el comportamiento
de un sistema mediante su interacción con los
usuarios y/u otros sistemas.
Los diagramas de casos de uso se utilizan
para ilustrar los requerimientos del sistema
al mostrar cómo reacciona a eventos que se
producen en su ámbito o en él mismo.
Elementos de un
Diagrama de Casos
de Uso
Actor:

Personaje(s) o entidad(es)
que participarán en un caso de
uso.
Inicia una acción dentro del
sistema, es representado por una
figura en forma de persona.
Los Actores pueden ser:

- Operadores humanos.

- Sistemas externos.

- Entidades abstractas, como el tiempo.


Tipos de actores:

Actores Principales: emplean directamente el


sistema llevando a cabo las tareas más
importantes.

Actores Secundarios: existen para que los


principales puedan utilizar el sistema.
Casos de Uso:
• Es una operación/tarea específica que se
realiza tras una orden de algún agente
externo, sea desde una petición de un actor o
bien desde la invocación desde otro caso de
uso. Se representa por un ovalo, conteniendo
el nombre.
Casos de Uso:
- Describe una funcionalidad más una interacción
entre un actor y un sistema en forma de
secuencia de acciones.
- Se centra en lo que debe hacerse, no en la
manera de hacerlo.
- Evitar expresiones imprecisas.
- Se busca sencillez y claridad.
Casos de Uso
- Puede utilizarse un lenguaje estructurado.
La descripción debe contener:
▫ Inicio del caso de uso
▫ Fin del caso de uso
▫ Interacción entre el caso de uso y los actores
▫ Intercambios de datos
▫ Cronología y origen de los datos
Construcción de un Caso de Uso

Proceso iterativo: Se van descubriendo los


escenarios desde el punto de vista del usuario
(ACTORES).

Para detectar los casos de uso es conveniente


hacer las siguientes preguntas:
¿Cuáles son las principales tareas de cada actor?
¿Escribe/lee/modifica el actor alguna información
del sistema?
¿Informa el actor al sistema de los cambios
externos?
¿Desea el actor ser informado de cambios no
esperados?
Técnicas para trabajar Casos de
Uso:
- Técnicas de observación

- Entrevista estructurada (para describir


los escenarios potenciales desde el
punto de vista del usuario).

Los casos de uso no pueden ser demasiado pequeños, ya


que deben aportar algún valor al actor.
Construcción de
Casos de Uso
1
Identificar a grandes trazos los casos de uso. Las
principales etapas de cada caso de uso se describen
en un par de frases.

Se distingue un caso principal y se identifican los


casos alternativos y excepciones
2
Se establece un proceso iterativo en el cual los
casos de uso se amplían, profundizándose su
descripción, buscando etapas comunes y
alternativas que representar en otros caso de uso
relacionados por las relaciones incluye, generaliza
y extiende.
3
Se debe cuidar que:
• Exista una descripción breve.
• Las condiciones definidas de arranque y parada
del caso de uso
• Los usuarios estén satisfechos de la secuencia de
interacciones entre el actor y el caso de uso
4
El problema fundamental encontrar el nivel de
abstracción adecuado.

Recomendación: Si un caso de uso se hace


demasiado grande es conveniente dividirlo en
varios.
Escenarios:
Situaciones concretas que deben recorrer total o
parcialmente el caso de uso.

Se debe comprobar que el caso de uso represente a


todos los escenarios
Arcos de Comunicación o Relación

Representa la relación que existe entre un Uso-


Caso y un Actor. Se representa por una flecha
que se extiende desde el actor a un caso de uso.
Tipos de Relaciones
• Asociación Es el tipo de relación más básica
que indica la invocación desde un actor o caso de
uso a otra operación (caso de uso). Dicha
relación se denota con una flecha simple.
• Dependencia o Instanciación:
Es una forma muy particular de relación entre
clases, en la cual una clase depende de otra, es
decir, se instancia (se crea). Dicha relación se
denota con una flecha punteada.
• Generalización Este tipo de relación es uno de
los más utilizados, cumple una doble función
dependiendo de su estereotipo, que puede ser
de:
- Uso (<<uses>>)
- Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente
para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso


de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un
conjunto de características que son similares en
más de un caso de uso y no se desea mantener
copiada la descripción de la característica.
Se representa por:
Límite de Sistema
Se emplea para delimitar los limites de un sistema
y es representado por un rectángulo de color
distintivo.
Ejemplo 1:
Ejemplo 2:
Casos de Usos
Ventajas:
• Ayudan a asegurar que se desarrolla el sistema
correcto.
• Documentan las respuestas funcionales de caja
negra.
• Excelente forma de comunicación con los
clientes y los usuarios.
• Ayudan a gestionar la complejidad de los
proyectos grandes.
Casos de Usos
Ventajas:
• Proporcionan el fundamento de los mensajes.
• Ofrecen una buena base para la verificación y
validación.
• Modo objetivo para el seguimiento del
proyecto.
• Pueden servir como base para especificar
respuestas a aplicaciones de tiempo real.
Casos de Usos
Peligros:
• Llevan a una descomposición funcional del
sistema.

• Violación de la ocultación de la información.

• Falta de formalidad.
EJEMPLO CASOS DE USO
Como ejemplo esta el caso de una Máquina
Recicladora:
Contexto

Sistema que controla una máquina de


reciclamiento de botellas, tarros.

El sistema debe controlar y/o aceptar lo siguiente:


Registrar el número de ítems ingresados.
Imprimir un recibo cuando el usuario lo solicita:
▫ Describe lo depositado
▫ El valor de cada ítem
▫ Total
• El usuario/cliente presiona el botón de
comienzo
• Existe un operador que desea saber lo
siguiente:
▫ Cuantos ítems han sido retornados en el día.
▫ Al final de cada día el operador solicita un
resumen de todo lo depositado en el día.
• El operador debe además poder cambiar:
▫ Información asociada a ítems.
▫ Dar una alarma en el caso de que:
 Ítem se atora.
 No hay más papel.
Solución:

Como una primera aproximación identificamos a


los actores que interactúan con el sistema:
Luego, tenemos que un Cliente puede Depositar
Ítems y un Operador puede cambiar la
información de un Ítem o bien puede Imprimir
un informe:
Además podemos notar que un ítem puede ser
una Botella, un Tarro.
Otro aspecto es la impresión de comprobantes,
que puede ser realizada después de depositar
algún ítem por un cliente o bien puede ser
realizada a petición de un operador.
Diseño completo del diagrama

También podría gustarte