DIAGRAMAS

DE CASOS DE USO

Ing. CIP. VÍCTOR ANCAJIMA MIÑAN

Perspectivas de un Sistema - MODELOS
QUE REPRESENTA EL DIAGRAMA DE CASO DE USO?

El diagrama de casos de
uso representa la forma en
como un agente (Actor)
opera con el sistema en
desarrollo, además de la
forma, tipo y orden en
como los elementos
interactúan (operaciones o
casos de uso).
DEFINIR EL COMPORTAMIENTO DEL SISTEMA
• El comportamiento de un sistema es cómo un sistema actúa y
reacciona

• El comportamiento del sistema es capturado en los casos de

uso mediante un proceso de recopilación de requerimientos del
sistema.
CASO DE USO Y LOS USUARIOS

• La forma en que los “usuarios” utilicen un sistema le da la

pauta para lo que se diseñará y creará.

• El caso de uso es una estructura que ayuda a los analistas a

trabajar con los usuarios para determinar la forma en que se
usará un sistema.

• Con una colección de casos de uso se puede hacer el

bosquejo de un sistema en términos de lo que los usuarios
intenten hacer con él.
ABSTRAERSE....

1. Imagínese al caso de uso como una colección de

situaciones respecto al uso de un sistema.

2. Cada escenario describe una secuencia de eventos.

3. Cada secuencia se inicia por una entidad que puede ser

una persona, otro sistema o un hardware.

4. A las entidades que inician secuencias se les conoce como

ACTORES.
REPRESENTACION

• Los casos de uso fueron inventados por Ivar

Jacobson.

• Ellos describen la conducta de un sistema desde el

punto de vista del usuario por que generan acciones
y reacciones.

• Un Caso de Uso es representado por una elipse y

describe una situación de uso del sistema
interactuando con actores.
 EL PROPÓSITO
• El propósito primario del modelo caso de uso es comunicar las
funciones y el comportamiento del sistema al cliente o al
usuario final
• Demostrar como interactúa el sistema con los actores!!!!
• Definir que Actores tendrán acceso o no a los procesos.
BENEFICIOS DEL MODELADO CON CASOS DE USO:

•El caso de uso es una excelente herramienta para

estimular a que los usuarios potenciales hablen, de un
sistema, desde sus propios puntos de vista.

•No siempre es fácil para los usuarios explicar como

pretenden utilizar un sistema.

•Puesto que el desarrollo tradicional de los sistemas era,

con frecuencia, algo así como una ciencia oculta, con muy
poca información para los usuarios, a aquellos que osaban
preguntar se les daba información muy poco explícita o
ciertamente confusa respecto a lo que utilizarían.
Los Casos de Usos :

• Son usados para comunicarse con el usuario final y el

experto del dominio

• Proporcionan credibilidad en una etapa inicial del

desarrollo del sistema

• Aseguran una comprensión mutua de los requisitos

• Brindan confianza a los clientes

• Definen accesos de los usuarios (Actores)

Los casos ...

• Es usado para identificar Quién interactuará con el

sistema y qué deberá hacer el sistema

• Qué interfaz deberá tener el sistema

• Es usado para verificar que:

• Se capturan todos los requisitos
• Que los desarrolladores hayan entendido los requisitos
LOS ACTORES

Un actor es un agente, alguien o algo que

solicita un servicio al sistema o actúa como
catalizador para que ocurra algo.

Actor
LOS ACTORES...

• Los actores no son parte del sistema, ellos

representan roles que un usuario del sistema
puede desempeñar

• Un actor puede intercambiar activamente la

información con el sistema

• Un actor es “cualquier cosa” que necesite

interactuar con el sistema

• Un actor puede representar a un humano, una

máquina u otro sistema
Actor
LOS ACTORES...

El modelo de los Casos de Uso

Actor
comprende los actores, el sistema y
los propios casos de uso.

El conjunto de funcionalidades de un
sistema se determina examinando las
necesidades funcionales de cada
actor, expresadas en forma de
interacciones.
IDENTIFICANDO ACTORES

Los actores se determinan observando:

• Usuarios directos del sistema

• Responsables del uso o mantenimiento del

sistema

• Otros sistemas que interactúan con el sistema

en cuestión
Cómo identificar actores
· ¿Quién usará la funcionalidad principal del sistema?

· ¿Quién esta interesado en cierto requerimiento?

· ¿Donde en la organización será usado el sistema?

· ¿Quién se beneficiará con el uso del sistema?

· ¿Quién administrará, soportará y mantendrá el sistema?

· ¿El sistema usa un recurso externo?

· ¿Alguna persona juega varios roles diferentes?

· ¿El sistema interactúa con otro sistema?

ACTORES... TIPS
Observando:
• Usuarios directos del sistema
• Responsables del uso o mantenimiento del
sistema
• Otros sistemas que interactúan con el sistema en
cuestión

Un actor puede:
• Solamente introducir información al sistema
• Solamente recibir información del sistema
• Introducir y recibir información hacia y del
sistema.
CATEGORÍAS DE ACTORES:
1. Personas
1. Principales: involucrado que tienen una interfaz directa con
el sistema para iniciar u ocasionar el evento de negocio o
del sistema.
2. Secundarios: personas que mantienen o administran el
sistema

2. Material físico: Equipos, dispositivos y/o materiales

imprescindibles que forman parte del ámbito del sistema que
se está modelando y deben ser utilizados.

3. Otros sistemas: sistemas con los que el sistema interactúa,

tras localizar los actores, procede a describirlos
RELACIONES ENTRE ACTORES

Debido a que los actores en UML son clases con el

estereotipo <<Actor>>, pueden tener relaciones como el
resto de clases.

En los diagramas de caso de uso se muestra por lo general

las relaciones de generalización para describir
comportamiento común a un número de actores.

CONSULTAR
PRECIOS

Actor 2
Actor 1

Actor 3
RELACIONES ENTRE ACTORES...

Una generalización se utiliza cuando varios actores

juegan – aparte de su rol – un rol más generalizado.

Esto ocurre cuando el comportamiento del rol

generalizado es descrito por la superclase actor.

Los actores especializados heredan el comportamiento

de una superclase y lo extienden de una forma.

Cliente

Cliente Personal Natural Cliente Persona Jurídica

DOCUMENTACIÓN DE LOS ACTORES

Una breve descripción de cada actor debe ser añadida al

modelo. La descripción debería identificar al rol que el
actor juega en su interacción con el sistema.

Por ejemplo si se identificó un actor que se llama Cliente,

una descripción de tal actor sería:

Un cliente es aquella persona que adquiere un

producto en la compañía.
LOS CASOS DE USO

Caso de Uso
LOS CASOS DE USO

• Un caso de uso modela un diálogo entre los actores y

el sistema

• Un caso de uso es iniciado por un actor para invocar

una cierta funcionalidad en el sistema

• Un caso de uso es un flujo de eventos completos y

significativos

• Tomados al mismo tiempo, todos los casos de uso

constituyen todas las formas posibles de ocupar el
sistema
Encontrando Casos de Uso: Preguntas Útiles
• ¿El actor, creará, guardará, cambiará,
eliminará o leerá la información en el sistema?

• ¿Cuál caso de uso creará, guardará, cambiará,

eliminará o leerá esta información?

• ¿Necesitará el actor informar al sistema sobre

cambios externos e imprevistos?

• ¿Cuáles son las tareas de este actor?

Encontrando Casos de Uso: Preguntas Útiles...:

• ¿Es necesario que el actor esté informado sobre

ciertas ocurrencias en el sistema?

• ¿Le proporciona una correcta secuencia el sistema

a las tareas?

• ¿Cuáles casos de uso le darán soporte y

mantenimiento al sistema?

• ¿Pueden todos los requerimientos funcionales ser

realizados por los casos de uso?
Diagramas de Casos de Uso…

 Cada Caso de Uso puede estar definido por:

o texto que lo describe.
o secuencia de pasos ejecutados dentro del escenario.
o condiciones pre-post para que el escenario comience o
termine.
o mezclando las anteriores.
 Un Caso de Uso es representado por una elipse y
describe una situación de uso del sistema
interactuando con actores
TIPOS DE CASOS DE USO : POR IMPORTANCIA

• Primarios: Representan los procesos

principales, los más comunes, como Realizar
Reintegro en el caso del cajero automático,
acceso al sistema, etc.

• Secundarios: Representan casos de uso

menores, que van a necesitarse raramente, tales
como Añadir Nueva Operación.

• Opcionales: Representan procesos que

pueden no ser abordados en el presente proyecto.
TIPOS DE RELACIONES
TIPOS DE RELACIONES ENTRE CASOS DE USO

1. Asociación

2. Herencia (Generalización)

3. Dependencia
1. Extensión (extend)

2. Inclusión (include)
1. ASOCIACIÓN

Este tipo de relación es uno de los más utilizados, es la

participación de un actor en un caso de uso.

Las instancias de un Actor se comunican con instancias de

un caso de uso.
2. GENERALIZACION o HERENCIA

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>>) o de Herencia (<<extends>>).

El Caso de Uso origen hereda la especificación del Caso de

Uso destino y posiblemente la modifica y/o amplía

Caso de Uso Hijo Caso de Uso Padre

3. DEPENDENCIA - EXTEND
Consiste en los pasos extraídos de otro más
complejo para simplificar el caso original y así
ampliar su funcionalidad.

EXTEND El Caso de Uso origen extiende el

comportamiento del Caso de Uso destino

<<extend>>

Caso de Uso Origen Caso de Uso Destino

EJEMPLOS

EXTEND
3. DEPENDENCIA - INCLUDE

Es el caso de uso que reduce la redundancia entre dos

o más caso de uso al combinar los pasos comunes
existentes entre estos casos de uso.

INCLUDE cuando otro caso de uso UTILIZA O

INCLUDE el caso de uso origen

<<include>>

Caso de Uso Origen Caso de Uso Destino

EJEMPLOS

INCLUDE
GRAFICA DE RELACIONES
GRAFICA DE RELACIONES

MOSTRAR
DATOS

CONSULTAR
BOLETA
NOTAS

Estudiante

IMPRIMIR
NOTAS
EJEMPLO DE EXTEND
¿Quién Lee la documentación de Casos de Uso?

• “Probador” del Sistema -- usado como base

para casos de prueba

• Líder de Proyecto -- provee entradas para el

planeamiento de proyectos

• Escritor Técnico -- base para escribir la guía

del usuario
¿Quién Lee la Documentación de Casos de Uso?

• Clientes -- aprueban lo que debe hacer el

sistema

• Usuarios -- obtienen comprensión del sistema

• Desarrolladores del Sistema -- documentan el

comportamiento del sistema

• Revisores --examinan el flujo de eventos

• Analistas del Sistema (Diseñadores) -- proveen la

base para un análisis y diseño
ERRORES CLÁSICOS EN EL
MODELAMIENTO DE
CASOS DE USO
Error en la identificación de actores

Sistema Uso de Cuál es el Se confunde

Cliente- Notación nivel que se con diagrama
Servidor o antigua de tiene que de Secuencia
Web? UML modelar? o DDF
Error en la identificación de caso de uso

Sistema Uso de Cuál es el Se confunde

Cliente- Notación nivel que se con diagrama
Servidor o antigua de tiene que de Secuencia
Web? UML modelar? o DDF
Error en relaciones

Sistema Uso de Cuál es el Se confunde

Cliente- Notación nivel que se con diagrama
Servidor o antigua de tiene que de Secuencia
Web? UML modelar? o DDF
Error en relaciones

Actualizar
Tareas << use >>

Jefe de Proyecto
Realizar
Seguimiento
X
<< use >>
Seleccionar
Tareas

Sistema Uso de Cuál es el Se confunde

Cliente- Notación nivel que se con diagrama
Servidor o antigua de tiene que de Secuencia
Web? UML modelar? o DDF
ANTES DE ELABORAR
DIAGRAMAS
DE CASOS DE USO…..
EJEMPLO DE GLOSARIO DE ACTORES
NOMBRE DE ACTOR DESCRIPCIÓN CASOS DE USO

Cajero Cajeros principales de las 1. Realizar ventas.

tiendas 2. Cobrar ventas-
3. Consultar productos.

Cliente Cualquier persona que 1. Realizar ventas.

ingresa a la empresa a 2. Cobrar ventas.
realizar compra

Jefe de Tienda Funcionario responsable 1. Ingresar nuevos Productos.

de la tienda. 2. Consultar ventas.

Administrador Sistema Especialista de TICS, 1. Incorporar nuevos usuarios.

responsable soporte del 2. Realizar copias de seguridad
sistema. 3. Realizar mantenimiento
NARRACIÓN DE CASOS DE USO
Nombre de Caso de REALIZAR VENTA
Uso
Tipo de Caso de uso Primario

Actor Primario Cliente

Actores Secundarios Cajero

Vendedor
Descripción El cliente llega a la empresa y se apersona al vendedor
El cliente solicita al vendedor una lista de productos
El vendedor verifica stock de los productos y los selecciona
El vendedor genera el pedido para la venta
El cliente se apersona al cajero y cancela su pedido
El cajero entrega comprobante de pago y el cliente recoge
mercadería donde el despachador

Conclusión Concluye cuando el cliente recoge su mercadería o cuando no existe

su pedido.

Post-Condición Se generó un pedido y se han descontado del stock los productos

vendidos.
SOFTWARE PARA MODELAMIENTO UML
SOFTWARE PARA MODELAMIENTO

ARGOUML
QUE ES ARGOUML??

ArgoUML es una herramienta “libre” utilizada en el modelaje

de sistemas, mediante la cual se realizan diseños en UML
("Unified Markup Language") llevados acabo en el análisis y
pre-diseño de Sistemas de Software.
DESCARGAR E INSTALAR : ARGOUML

1º Descargar JDK para windows de:

http://javabasico.osmosislatina.com/java_windows.jsp
 Grabarlo en disco local
 Instalarlo ejecutando:
DESCARGAR E INSTALAR : ARGOUML

2º Descargar ARGOUML de:

http://argouml.tigris.org/download/release020.html
 Descargar argouml-0.20.zip
 Descargar argouml-0.20-modules.zip
 Descomprimir ambos archivos en la misma carpeta
 Ejecutar argouml.jar
ARGOUML ..Pantalla Principal
 MUCHAS GRACIAS

vancajima@equicom.pe