Apunte Casos de Uso y RCUA
-
Upload
likajm1032 -
Category
Documents
-
view
14 -
download
0
Transcript of Apunte Casos de Uso y RCUA
3
Objetivos del tema
Identificar los actores y casos de uso
Representar en UML y textualmente los casos de uso
Utilizar las relaciones <<include>> y <<extend>>
Relacionar los casos de uso con otras técnicas de modelado de UML
4.1 Requisitos funcionales: los casos de uso
Requisitos funcionales: Modelo de casos de usoRepresentación en UMLDefinición de caso de uso y escenario
5
Tipos de requisitos
Funcionales: características del sistemaSe describe con casos de uso
Requisitos no funcionalesUsabilidadRendimientoMantenibilidadSoporte, adaptabilidad...Implementación
También Requisitos de dominio (restricciones legales, etc.) y Requisitos de información
6
Documentación de requisitos
VisiónGrandes objetivos y restricciones, alcance del proyecto
Modelo de casos de usoDescribe los requisitos funcionales
Especificación adicionalRequisitos no funcionales, Requisitos de dominio y Requisitos de información
GlosarioTerminología básica del dominio
7
Modelo de casos de uso
Un Modelo de casos de uso describe losrequisitos funcionales de sistema desde el punto de vista de casos de uso
Los casos de uso describen: el sistema (casos de uso) el entorno del sistema (actores).la relación entre el sistema y su entorno
8
Modelo de casos de uso
Un caso de uso representa una interacción típica entre un usuario y un sistema informático:
Los casos de uso capturan el comportamiento deseado del sistema bajo desarrollo, pero...
no especifican cómo se implementa esecomportamiento
9
Utilidad de los casos de uso
Los casos de uso tienen dos papeles fundamentales:
Capturar los requisitos funcionales del sistemaSimplificar la construcción de los modelos de objetosServir de base para las pruebas del sistema
10
UML: diagramas de casos de uso
Un diagrama de casos de uso es un grafo con dos tipos de nodos:
Actor - que representa cualquier elemento que intercambia información con el sistema, por lo que estáfuera de élCaso de uso - Es una secuencia de intercambios que representan el diálogo entre el sistema y uno o varios actores. Tiene una descripción informal en lenguaje natural o en un lenguaje estructurado
Entre ellos hay relaciones de asociación
11
Diagramas de Casos de uso
Sistema
Actor A
Caso de uso X
Actor B
Caso de uso Y
El usuario teclea la cantidad que quiere sacar
El sistema comprueba que tiene billetes suficientes
El cajero envía la petición al sistema del banco emisor...
12
Notación de los casos de uso
Los casos de uso se representan por una elipse y un nombre, que puede ir dentro o debajo de la elipse.
Los actores se representan con el icono de estereotipo estándar para casos de uso (el “stick man” o monigote) con el nombre del actor al pie de la figura. Los nombres de los actores suelen empezar por mayúscula.
13
Definición de casos de uso (I)
“Una secuencia de acciones realizadas por el sistema, que producen un resultado valioso para un actor en particular”
Una acción es procedimiento atómico. Se invoca cuando:
el actor envía un estímulo al sistema el sistema recibe un evento temporal
Realizadas por el sistema:El sistema proporciona una respuesta (pero es una caja negra)
14
Definición de casos de uso (II)
“Una secuencia de acciones realizadas por el sistema, que producen un resultado valioso para un actor en particular”
Un resultado valioso:Un caso de uso debe asegurar que un actor puedadesempeñar una tarea que tiene un valor Esto es importante para determinar el nivel correcto para un caso de uso (casos de uso que no son demasiado pequeños)
Un actor en particular: El actor es la llave para encontrar casos de uso correctos (Entrevistas, actividades asociadas a un actor...)Un actor interacciona a través de una instancia concreta del caso de uso (escenario)
15
En realidad, la definición corresponde a un escenario o instancia del caso de uso:
Una secuencia particular de acciones que lleva a un resultado valioso (o exito)También puede llevar a un resultado de fracaso
Un caso de uso es un conjunto de escenarios (éxitos y fracasos) relacionados por el resultado que el actor pretende obtener
La relación entre escenario y caso de uso es idéntica a la que existe entre objeto y clase
Escenarios y casos de uso
16
Actores y casos de uso
El actor suele ser una persona, pero se diferencia de un usuarioUn actor representa un cierto papel que distintos usuarios puede jugar.
El actor sería la clase y el usuario una instancia de la clase. Un mismo usuario podría ser instancia de varios actores.
Una máquina o un sistema también puede ser un actor
Incluso el tiempo (un cronómetro) puede ser un actor
4.2 Descripción y Construcción de los casos de uso
Descripción: plantillasEl proceso de encontrar y construir los
casos de uso
18
Un caso de uso describe su objetivo (la funcionalidadque se pretende) más una interacción entre un actor y un sistema en forma de secuencia de estímulos y respuestas
La descripción se centra en lo que debe hacerse, no en la manera de hacerlo
Deben evitarse expresiones imprecisas: sencillez y claridad
Puede utilizarse un lenguaje estructurado (secuencia, repeticiones y situaciones opcionales)
Descripción de los Casos de uso
19
Casos de uso y caja negra
¿Incorrecto o Correcto?
El cajero pulsa la tecla Inicio El sistema genera un registro en un fichero de ventasEl cajero solicita iniciar una nueva ventaEl sistema genera una sentencia SQLEl sistema registra la venta
20
Formatos de descripción
El caso de uso se puede describir con varios niveles de detalle:
BreveUn resumen inicial en un par de frases
InformalUn conjunto de párrafos y alternativas
CompletoCon todas las alternativas, pre y post-condiciones, etc.
Cf. Ejemplos del Larman
21
Formatos de descripción
Por otro lado, se distinguen:Casos de uso Esenciales
El comportamiento del sistema sin entrar en detalles tecnológicos
Casos de uso Concretos Con el detalle de la interfaz de usuario
Será necesario ajustarlos a los requisitos no funcionales de tipo tecnológico antes de completar el diseño de la capa de interfaz
22
Descripción de los Casos de uso
La descripción debe contener:Inicio del caso de usoFin del caso de usoInteracción entre el caso de uso y los actoresIntercambios de datosCronología y origen de los datos
La descripción se puede completar con diagramas de secuencia o de transición de estados
23
Descripción de los Casos de uso<Identificador> <nombre descriptivo>
Descripción El sistema deberá permitir a [lista actores] en [instante en el que sepuede realizar el caso de uso] [funcionalidad que define el caso de uso]según se describe en el siguiente caso de uso:
Paso Acción
1 {<acción a realizar>, realizar el caso de uso [caso de uso]}
2 <Situación que produce una alternativa>
2a Si [Situación que produce una alternativa] el sistemadeberá {<acción a realizar>, realizar el caso de uso[caso de uso]}
2b Si [Situación que produce una alternativa] el sistemadeberá {<acción a realizar>, realizar el caso de uso[caso de uso]}
… ….… …
SecuenciaNormal
n ….
Paso Acción
p En el caso de que [situación que provoca la excepción] elsistema deberá {<acción a realizar>, realizar el caso de uso[caso de uso]}
… …
Excepciones
q…
Rendimiento El sistema deberá realizar la/s acción /es descrita/s en {los pasos[primer paso] al [último paso], el paso [número de paso]} en unmáximo de [cota de tiempo]
Frecuencia Este caso de uso se espera que se lleve a cabo una media de [número deveces] al [unidad temporal]
Importancia {vital, importante,quedaría bien}Urgencia {inmediatamente, hay presión, puede esperar}Comentarios <otras consideraciones en formato libre>
Habitualmente se utiliza una plantillase algún tipo:
24
RF- <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>
Autores <autor>
Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}
Plantilla de casos de uso (cabecera)
25
Plantilla (pie)
Rendimiento Paso Cota de tiempo
1 n segundos
2 n segundos
Frecuencia esperada <nº de veces> veces / <unidad de tiempo>
Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>
26
Plantilla (secuencia normal)
Precondición <precondición del caso de uso>
SecuenciaNormal
Paso Acción
1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>
3
4
5
6
n
Postcondición <postcondición del caso de uso>
27
Plantilla (excepciones)
Excepciones Paso Acción
1 Si <condición de excepción>,{el <actor> , el sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta}
...1’
4
28
Descubrir y construir los Casos de uso
Es un proceso iterativo. Se van descubriendo los escenarios desde el punto de vista del usuario o ACTOR y sus objetivos.
Pasos del proceso:1. Fijar los límites del sistema2. Identificar los actores principales3. Identificar los objetivos de cada actor4. Definir (elaborar) cada caso de uso
29
Actores y límites del sistema
Procesar venta
Cajero
Cliente
TPDV
Tienda
Objetivos :
Comprar cosas
Empresa
Hacienda
Obj: Recaudar Gerente de Ventas
Analizar ventas
30
En el momento de identificar los actores es conveniente distinguir entre
actores principales (que son los que emplean directamente el sistema llevando a cabo las tareas más importantes)actores secundarios (existen para que los principales puedan utilizar el sistema).
La estructura del sistema debe decidirse teniendo en cuenta a los actores principales.
Los casos de uso no pueden ser demasiado pequeños, ya que deben aportar algún valor al actor.
Descubrir y construir los Casos de uso
31
Preguntas
Pueden utilizarse técnicas de observación o entrevista
La mayoría de los objetivos son obvios (vender, cobrar, gestionar una devolución...)
Para detectar todos los casos de uso, se puede preguntar:
¿Escribe/lee/modifica el actor alguna información del sistema?¿Cuáles son las principales tareas de cada actor?¿Informa el actor al sistema de los cambios externos?¿Desea el actor ser informado de cambios no esperados?
32
Más preguntas
Preguntas estándar para encontrar otros actores y objetivos:
¿quién arranca el sistema?¿quién gestiona los usuarios y la seguridad?¿el sistema debe hacer algo cada cierto tiempo?¿quién evalúa la actividad del sistema?¿Cómo se actualiza el software?
33
Proceso de elaboración
Identificar a grandes trazos los casos de usoLas principales etapas de cada caso de uso se describen con un par de frasesSe distingue un camino principal y se identifican los caminos alternativos y excepciones
Proceso iterativo:Los casos de uso se amplían, profundizándose en su descripción Se buscan etapas comunes y alternativas que representar en otros caso de uso relacionados por las relaciones incluye, generaliza y extiende
34
Se debe cuidar que:Exista una descripción breve que represente una verdadera imagen del caso de uso
Las condiciones de arranque y parada del caso de uso estén bien definidas
Los usuarios estén satisfechos de la secuencia de interacciones entre el actor y el caso de uso
Resultado final (I)
35
El problema fundamental es encontrar el nivel de abstracción adecuado.
En general si un caso de uso se hace demasiado grande a medida que se va detallando es conveniente dividirlo en varios.
Se pueden hacer preguntas como:¿es posible ejecutar un paso de forma independiente a los otros o siempre va encadenado con ellos? ¿es lógico agrupar varios pasos para documentarlos, probarlos o modificarlos en conjunto?
Resultado final (II)
36
Escenarios y casos de uso
Un caso de uso tiene como instancias los escenarios: situaciones concretas que pueden recorrer total o parcialmente el caso de uso
Se deben consideran en lo posible todos los escenarios de modo que se pueda validar el caso de uso.
La última comprobación consiste por tanto en asegurar que el caso de uso represente todos los escenarios.
A veces se confunden casos de uso con escenarios: Si aparecen muchos casos de uso puede que sea un síntoma de una mala descripción del sistema
37
Casos de uso - Ejemplo
Cajero automático
sacar dinero
Consulta de saldo
recarga móvil
administración
usuario
operador
sistema del banco emisor
Compañía telefónica
38
CU-003 Sacar dinero Descripción� El sistema deberá permitir al cliente del banco, en cualquier momento,
sacar dinero según se describe en el siguiente caso de uso: 1+ El usuario inserta la tarjeta en el cajero 2 + El cajero lee el código de la banda magnética de la tarjeta y verifica si es aceptable y pide el código del usuario 3+ El usuario introduce el código 4 + Si el código es correcto, el cajero pide al usuario que seleccione el tipo de transacción deseada 5+ El usuario selecciona la función sacar dinero, 6 + El cajero le pide al usuario que teclee la cantidad deseada
7 + El usuario teclea la cantidad que quiere sacar, 8 + El cajero envía la petición al sistema del banco
9 a Si conecta el sistema deberá comprobar si hay dinero en la cuenta
9 b Si no conecta el sistema deberá comprobar si el dinero es menos que el límite
Secuencia Normal
10 En cualquiera de los dos casos el sistema: + expulsa la tarjeta + imprime el recibo + entrega el dinero
Excepciones� 2' La tarjeta no es aceptada + Se expulsa emitiendo un sonido 4' Código incorrecto (1,2) + Se emite un mensaje dando al usuario la oportunidad de volver a introducir el código (paso 3) 4'' Código incorrecto (3) + Se emite un mensaje y se retiene la tarjeta 9' No autorizado para sacar dinero + El sistema de banco no autoriza a sacar dinero. Se emite un mensaje de información y se expulsa la tarjeta 9 a ', 9 b' No hay dinero suficiente + El cajero no dispone de la cantidad pedida. Emite un mensaje y vuelve al paso 7 1..10' Cancelar + En cualquier momento el usuario puede cancelar la transacción, con lo que se expulsa la tarjeta
39
El sistema pide al usuario que teclee la cantidad deseada9
El usuario selecciona la función sacar dinero, 8
El sistema pide al usuario que seleccione el tipo de transacción deseada
7
El sistema valida el PIN6
El usuario introduce el código 5
El sistema pide el PIN al usuario4
El sistema lee el código de la banda magnética de la tarjeta, verifica si es aceptable
3
El usuario inserta la tarjeta en el cajero2
El sistema visualiza un mensaje de bienvenida en la pantalla1
Cajero automático: secuencia normal
40
El sistema entrega el dinero16
El sistema expulsa la tarjeta15
El sistema imprime un recibo14
El banco emisor confirma que hay fondos13
El cajero envía la petición al sistema del banco emisor12
El sistema comprueba que tiene billetes suficientes11
El usuario teclea la cantidad que quiere sacar10
Cajero automático: secuencia normal
41
...
Si no se consigue comunicación y la cantidad excede del límite máximo, el sistema emite un mensaje de información y el caso de uso continua en el paso 9
13’
Si el banco emisor no autoriza a sacar dinero, el sistema emite un mensaje de información y el caso de uso continua en el paso 7
13
El sistema no tiene suficiente dinero y emite un mensaje y el caso de uso continua en el paso 9
11
Si el usuario introduce un código erróneo por tercera vez, el sistema retiene la tarjeta y el caso de uso termina.
6’
Si el usuario introduce un código erróneo, el sistema pide de nuevo el PIN y el caso de uso continua en el paso 5
6
Si la tarjeta no es aceptada, el sistema la expulsa emitiendo unsonido. El caso de uso termina.
3
Cajero automático: excepciones
42
Médico
Monitorcardiaco
Disparo si algo está fuera
de lo normal
Impresiónimpulsos card.
MonitorRemoto
Paciente
Almacén dediagramas
Casos de uso - Ejemplos
Sistema que controla la actividad cardiaca de un paciente.
4.3 Relaciones entre casos de uso.
IncluyeGeneralizaExtiende
44
Relaciones entre los casos de uso
En OOSE o UML 1.1 las relaciones extiende y usa se representaban por la relación de generalización acompañadas de los esterotipos:
<<extiende>> <<usa>>
45
En UML 1.4 las relaciones entre casos de uso son
Incluye (<<incluye>>) (<<include>>) - Es un estereotipo de dependencia. Indica que un caso de uso es incluido dentro de otro.
Extiende (<<extiende>>) (<<extend>>) - Es un estereotipo de dependencia. Ofrece una forma de extensión más controlada que la relación de generalización.
Generalización (sin estereotipo) - Indica que un caso de uso es una variante de otro.
Relaciones entre Casos de uso: UML
46
Resumen de los tipos de relaciones
Relación Función Notación
Asociación Camino de comunicación entre un actor y un caso de uso en el que participa
Extiende
Inserción de comportamiento adicional en un caso de uso base (sin que éste tenga conocimiento)
Generalización
Relación entre un caso de uso general y otro más específico que hereda características y añade otras
Incluye Inserción de comportamiento adicional dentro de un caso de uso que describe la inserción
<<extiende>>
<<incluye>>
47
Relación Incluye
Es una relación de dependencia donde un caso de uso utiliza otro caso de uso completo, indicando que se incrusta en el primero.
Cuando un número de casos de uso comparten un comportamiento común, se extrae en un caso de uso que es utilizado (<<include>>) por otros.
El caso de uso incluido es el “factor común”.
Si el caso de uso nunca se utiliza por sí mismo se denomina caso de uso abstracto.
48
Sacar dinero
<<include>>
Comprobar tarjeta y PIN
Relación Incluye
<<include>>
Consultar saldo
Actor
49
Indica que un caso de uso es una variante de otro.
El caso de uso especializado puede variar cualquier aspecto del caso de uso base:
Cuando un caso de uso extiende otro, significa que el primero puede incluir parte del comportamiento del caso de uso que él extiende.
No tiene porque incluir el comportamiento completo; pudiendo elegir que partes se quieren reutilizar.
Es una relación muy flexible.
Relación de Generalización
50
Relación de Generalización
Cliente
Giro
Transferencia por Internet
Transferencia
Cliente Remoto
51
Relación Extiende
Es una relación de dependencia donde un caso de uso añade acciones al caso de uso base.
El caso de uso base declara un conjunto de puntos de extensión.
El caso de uso especializado sólo puede alterar el comportamiento de los puntos de extensión marcados.
Si hay más de uno, hay que identificar exactamente cuál es es punto extendido.
Un caso de uso extendido puede manejar excepciones, alternativas, etc.
52
Generaliza y Extiende
Process Sale
Extension Points:Payment
VIP Customer
«extend» Payment,
if Customer....
Handle Gift CertificatePayment
Girotransferencia
transferencia por internet
53
Cashier
Customer
Handle CashPayment
Process Rental
Process Sale
Handle CheckPayment
«include» «include»
«include»
«include» «include»«include»
«actor»Accounting
System
«actor»Credit
AuthorizationService
Handle CreditPayment
Relaciones entre Casos de uso
54
<<include>>
transferenciapor Internet
<<extend>>
transferencia
Cliente
Identificación
Relaciones entre Casos de uso
transferencia local
<<extend>>
55
Comprobación delestado
Realización de unpedido
Completar pedido
Establecer crédito
Venta por catalogo telefónico
Vendedor
Empleado
Supervisor
Atención alCliente
Casos de uso - Ejemplos
56
Casos de uso - Ejemplos
Peticiones alcatálogo con
pedidos
Realización de unpedido
Informaciónsuministrada por el
ClientePedido de productos
Orden de pago
<<include>>
<<include>>
<<include>>
4.5. Utilidad de la técnica: el paso a los objetos
Especificación e implementaciónDiagramas de secuencia de caja negraDescomposición funcional vs colaboración
66
Especificación e implementaciónLa especificación de los casos de uso nos permite conocer el comportamiento externo que define la posible secuencia de mensajes intercambiados entre los actores y el sistema.
Al nivel de casos de uso esto es especificado como
un diagrama de secuencia (diálogo actor/sistema)
una máquina de estados, incluyendo el diagrama de actividad.
67
Diagramas de secuencia: caja negra
: Bibliotecario
sistema : Sistema
Se realiza el caso de uso Identificación de socio
1: comenzar el proceso de préstamo
2: comprueba la situación del socio
4: identifica el libro
6: identifica un ejemplar y solicita al sistema que registre el préstamo
3: identifique el libro
5: ejemplares disponibles
7: proceso de registro ha terminado
68
Casos de uso: Implementación
La relación entre los casos de uso y su implementación es una Realización.La implementación de un caso de uso puede ser vista como una colaboración:
Se trata de objetos y enlaces (instancias de clases y asociaciones) junto con las posibles secuencias de flujos de mensajes que provoca el caso de uso en cuestión.
La vista de los casos de uso es una descripción funcional de las necesidades estructuradas con respecto a un actor
69
Transición hacia los objetosUna descomposición que siga directamente la forma de los casos de uso conduce a una aproximación estructurada clásica, funcional...
Realización de unpedido
Informaciónsuministrada por el
ClientePedido de productos
Orden de pago
<<include>><<include>>
<<include>>
Orden de pago
Pedido de productos
Informaciónsuministrada
Realización de un pedido
70
Es necesario realizar un paso al mundo de los objetos
Se efectúa asociando una colaboración a cada caso de usoLa colaboración describe objetos del ámbito, las
conexiones entre estos objetos y los mensajes que intercambian éstos
La realización de un caso de uso por una colaboración es momento crucial del modelado;
Es el momento del cambio hacia la orientación a objeto
Transición hacia los objetos
71
Objeto Objeto Objeto
Caso de uso Colaboración
<<Realiza>>
<<Participa>>
<<Participa>>
<<Participa>>
Transición hacia los objetos
72
Casos de uso y UP
January February
Use Case: Capture a Sale. . .Main Success Scenario:1. ...2. ...3. ...Extensions:
Use Case: Handle Returns. . .Main Success Scenario:1. ...2. ...3. ...Extensions:
Cuándo Donde
Quién CómoSoftware:
Herramienta CASE + herramienta de requisitos + Hyperlink
Desarrollador
ClienteAnalista
Usuario
Two adjacent projections.
Arquitecto
elaboración
inicio
73
Bibliografía Recomendada
Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado ”. Prentice Hall, 2002.
Capítulos 6..9, 25
Amador Durán y Beatriz Bernárdez, Metodología para la
Elicitación de Requisitos de Sistemas Software. 2002.
Lecturas complementariasJ. Rumbaugh, I. Jacobson, G. Booch, El Lenguaje Unificado
de Modelado. Manual de referencia. Addison-Wesley,2000
A. Cockburn. Writing Effective Use Cases. Addison-Wesley
2001
74
Caso de estudio Punto de venta
Cajero:Procesar ventasProcesar devolucionesAbrir y cerrar caja
Director: Poner en marchaSuspender operaciones
Administrador:Añadir usuarios Modificar usuariosGestionar tablas del sistema
Control de ventas:Analizar los datos de ventas y rendimiento
Actores, objetivos y casos de uso:
75
Diagrama de casos de uso
Gestionar seguridad
Gestionar usuariosAdministrador
del sistema
Sistema de autorización
Sistema contable
Pago con cupón
Pago con tarjeta
Actor_Cajero
Procesar Alquiler
Pago en metálico
Gestionar Devolución
Procesar Venta
<<extend>>
<<extend>>
<<extend>>
76
Caso de uso Procesar venta
1. El cajero inicia una nueva venta cuando un cliente llega a la caja con uno o varios artículos
2. El cajero introduce el código del artículo
3. El sistema registra una línea de detalle y muestra el nombre y precio del artículo
(pasos 2 y 3 se repiten)
4. El cajero indica el fin de la venta
5. El sistema presenta el total
6. Punto de extensión: PAGO
7. El sistema registra la venta y envía la información al sistema contable8. El sistema imprime el recibo
77
1. El cajero inicia una nueva venta cuando un cliente llega a la caja con uno o varios artículos2. El cajero introduce el códiodel artículo3. El sistema registra una línea de detalle y muestra el nombre y precio del artículo(pasos 2 y 3 se repiten)
4. El cajero indica el fin de la venta5. El sistema presenta el total6. Punto de extensión: PAGO7. El sistema registra la venta y envía la información al sistema contable...
: Actor_Cajero
: Sistema
inicia nueva venta
introduce el código del artículo
muestra el nombre y precio del artículo
fin de la venta
presenta el total
Punto de extensión:Forma de PAGO
registra la venta