i ngenierÍa de s oftware l aboratorio v diseño - casos de uso eduardo saavedra a. 30/09/2009
Post on 24-Jan-2016
216 Views
Preview:
TRANSCRIPT
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.
top related