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