INGENIERÍA DE SOFTWARELABORATORIO VDiseño - Casos de Uso

Eduardo Saavedra A.

30/09/2009

TÓPICOS

1. ¿ Qué es un caso de uso?2. Conceptos

1. Caso de uso2. Actor3. Escenario4. Condiciones5. Relaciones

3. Como confeccionar los casos de uso4. Ejemplos

¿ QUÉ ES UN CASO DE USO?

¿ QUÉ ES UN CASO DE USO?

En ingeniería del software, un caso de uso es una técnica para la captura del comportamiento deseado de un sistema, sin tener que especificar como se implementa ese comportamiento.

¿ QUÉ ES UN CASO DE USO?

Ningún sistema se encuentra aislado, siempre existe la interacción con actores, tanto humanos como mecánicos.

Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.

¿ QUÉ ES UN CASO DE USO?

Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

Son creados bajo la identificación funcional de requerimientos pero no tienen una relación uno a uno con ellos (caso de uso != requerimiento).

CONCEPTOS•Caso de uso•Actor•Escenario•Relaciones

CONCEPTOS – CASO DE USO

Nombre Caso de Uso Debe estar compuesto por lo menos de un

verbo. Representa una acción que los usuarios realizan

ante el sistema.

CONCEPTOS – ACTOR

Actor Representan roles que humanos, dispositivos de

hardware o sistemas externos juegan mientras interactúan con el sistema

No son parte del sistema y están situados fuera de sus límites

CONCEPTOS – ESCENARIO

EscenarioEspecifican el comportamiento de un

caso de uso por descripción, no por modelamiento Ejemplos incluyen texto estructurado informal, texto

estructurado formal con condiciones y pseudocódigo.

Típicamente especifica: Cómo y cuándo el caso de uso comienza y termina Interacción con actores e intercambio de objetos Flujo de eventos: normal (exitoso), alternativo

(exitoso) y excepcional (falla)

Legible para el usuario NO experto.

CONCEPTOS – EJEMPLO ESCENARIO

En el caso de uso “Validación de Tarjeta” de un sistema de cajero automático pueden haber estos escenarios:Escenario normal: Validar un Cliente por

medio de su clave.Escenario alternativo: Validación de tarjeta

fallida y se solicita reintentar.Escenario excepción: Tarjeta se bloquea.

CONCEPTOS – CONDICIONES Pre-Condiciones

Describe el ambiente bajo el cual el caso de uso es invocado.

Post-Condiciones Reflejan el impacto en el ambiente del caso de

uso luego de su ejecución. Requisitos de Calidad (opcional)

Por ejemplo, el sistema debe responder en menos de 30 segundos.

CONCEPTOS – EJEMPLO CONDICIONES Para un caso de ingreso de ficha médica para

un consultorio.

Pre-Condiciones Usuario debe estar validado por el sistema.

Post-Condiciones Ficha médica ingresada en el sistema.

Requisitos de Calidad (opcional) El sistema debe responder en menos de 30 segundos

para todo el flujo.

CONCEPTOS – RELACIONES

Asociación Se utiliza para relación natural entre un actor y

un caso de uso. Nunca existe una asociación entre dos casos de

uso El uso de punta de flecha se deja de utilizar

después de UML 1.2

CONCEPTOS – RELACIONES

<<include>> (<<uses>> en UML 1.2 )Si X incluye Y, Y siempre se realiza cuando

se realiza X.Y es un comportamiento común en más

de un caso de uso.

CONCEPTOS – RELACIONES

<<extend>>Si Y extiende X, bajo ciertas condiciones

de la ejecución de X también se ejecuta Y.Cuando se incluye un comportamiento de

uso sólo bajo ciertas condiciones

CONCEPTOS – RELACIONES

Especialización (herencia) Al igual que en la POO, la herencia consiste en

rasgos que un Caso de uso hijo pueda heredar de su padre.

COMO CONFECCIONAR UN DIAGRAMA DE CU

Identificar contexto: Identificar Sistema - Límite Identificar actores: ¿Quiénes usarán el sistema? Identificar relaciones entre actores.

Identificar requisitios Identificar casos de uso: ¿Qué interacciones

tendrá el actor con el sistema? Identificar relaciones entre los casos de uso:

Extensiones, Inclusiones y Especializaciones. Adornos a los casos de uso, notas, comentarios,

etc.

EJEMPLOS

EJEMPLO

Cajero automático (ATM)! Asumamos un cajero donde se realizan depósitos en dinero y

cheques. El negocio distingue dos actores para efectuar operaciones, el

cliente del banco y el poseedor de tarjeta. El Cliente de banco es el único que puede efectuar depósitos, mientras que el poseedor de tarjeta es el que puede retirar dinero al igual que el Cliente del banco.

Se sabe que el negocio envía cada cierto tiempo a operadores para reabastecer el cajero con dinero. Además ellos desbloquean las tarjeta que los usuarios han dejado en el ATM por fallas en su validación (luego de 5 fallas se bloquea).

LÍMITES

Cajero Automático

EJEMPLO – CAJERO AUTOMÁTICO

Identificación de actores

Poseedor de Tarjeta

(f rom Actors)

Cliente Banco

(f rom Actors)

Operador

(f rom Actors)

Cajero Automático

Cajero Automático

EJEMPLO – CAJERO AUTOMÁTICO

Identificar Casos de uso

Imprimir Recibo Saldo

Retirar Dinero

Validación Tarjeta

Reponer DineroDepositar Cheque

Depositar Efectivo

Desbloquear Tarjeta

EJEMPLO – CAJERO AUTOMÁTICO

Identificar Relaciones

Cajero Automático

Validación TarjetaPoseedor de Tarjeta

(f rom Actors)

Imprimir Recibo Saldo

Depositar Cheque

Depositar Efectivo

Cliente Banco

(f rom Actors)

Retirar Dinero

<<include>>

<<include>>

<<include>>

<<include>>

Reponer DineroOperador

(f rom Actors)

Desbloquear Tarjeta

<<extend>>

EJEMPLO – CAJERO AUTOMÁTICOCajero Automático

Validación TarjetaPoseedor de Tarjeta

(f rom Actors)

Imprimir Recibo Saldo

Depositar Cheque

Depositar Efectivo

Cliente Banco

(f rom Actors)

Retirar Dinero

<<include>>

<<include>>

<<include>>

<<include>>

Reponer DineroOperador

(f rom Actors)

Desbloquear Tarjeta

<<extend>>

ESCENARIOS

Recordar que un escenario es la instancia de un caso de uso!

Validación tarjeta:

ESPECIFICACIÓN DE CASO DE USO

ESCENARIOS

Retiro de dinero

BIBLIOGRAFÍA

I. Jacobson J. Rumbaugh and G. Booch. El Lenguaje Unificado de Modelado. Addison-Wesley, 2000.

Roger S. Pressman. Ingeniería del Software. MC Graw Hill, 2000, Sexta Edición.