casos de uso (informatica); sistemas de informacion

1Tema 3. Casos de uso

Ingeniera del Software I 3 I.T.I.Gestin

Miguel A. Laguna

Contenidos

3.1. Requisitos funcionales: los casos de uso

3.2. Descripcin y Construccin de los casos de uso

3 3 Relaciones entre casos de uso

2

3.3. Relaciones entre casos de uso.

3.4. Ventajas y peligros de los casos de uso

3.5. Utilidad de la tcnica: el paso a los objetos

Objetivos del tema

Identificar los actores y casos de uso

Representar en UML y textualmente los casos de uso

Utilizar las relaciones y

3

Utilizar las relaciones y

Relacionar los casos de uso con otras tcnicas de modelado de UML

3.1 Requisitos funcionales: los casos de uso

Requisitos funcionales: Modelo de casos de uso Representacin en UML Definicin de caso de uso y escenario

Tipos de requisitos

Funcionales: caractersticas del sistema Se describe con casos de uso

Requisitos no funcionales Seguridad

5

Rendimiento Fiabilidad Facilidad de uso etc

Tambin Reglas del negocio (restricciones legales, etc.) y Requisitos de informacin

Documentacin de requisitos

Visin Objetivos Restricciones, alcance del proyecto

Catlogo de requisitos Requisitos funcionales

Requisitos funcionales Modelo de casos de uso describe en detalle los requisitos

6

Modelo de casos de uso, describe en detalle los requisitos funcionales

Requisitos no funcionales Reglas de negocio Requisitos de informacin

Glosario Terminologa bsica del dominio

Modelo del dominio

2Modelo de casos de uso

Un Modelo de casos de uso describe losrequisitos funcionales (nivel sistema) desde el punto de vista de cmo se usar la aplicacin en la prctica diaria

7

Los casos de uso describen: el sistema (casos de uso) el entorno del sistema (actores). la relacin entre el sistema y su entorno

Modelo de casos de uso

Un caso de uso representa una interaccin tpica entre un usuario y un sistema informtico:

8

Los casos de uso capturan el comportamiento deseado del sistema bajo desarrollo, pero...

no especifican cmo se implementa esecomportamiento

Utilidad de los casos de uso

Los casos de uso tienen tres papeles fundamentales: Capturar el detalle de los requisitos

funcionales del sistema

9

Simplificar la construccin de los modelos de objetos

Servir de base para las pruebas del sistema

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 informacin con el sistema, por lo que est fuera de l

10

fuera de l Caso de uso - Es una secuencia de intercambios que

representan el dilogo entre el sistema y uno o varios actores.

Tiene una descripcin informal en lenguaje natural o en un lenguaje estructurado

Entre ellos hay relaciones de asociacin

Diagramas de Casos de uso

Sistema

El usuario teclea la cantidad que quiere sacar

El sistema comprueba que tiene billetes suficientes

El sistema enva la peticin al banco emisor...

11

Actor A

Caso de uso X

Actor B

Caso de uso Y

Notacin 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.

12

Los actores se representan con el icono de estereotipo estndar 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 mayscula.

3Definicin de casos de uso (I)

Una secuencia de acciones realizadas por el sistema, que producen un resultado valioso para un actor en particular

Una accin es procedimiento atmico. Se invoca

13

pcuando: el actor enva un estmulo al sistema el sistema recibe un evento temporal

Realizadas por el sistema: El sistema proporciona una respuesta (pero es una caja

negra)

Definicin 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:

14

Un resultado valioso: Un caso de uso debe asegurar que un actor pueda

desempear 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 pequeos)

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 travs de una instancia concreta del

caso de uso (escenario)

En realidad, la definicin corresponde a un escenario o instancia del caso de uso: Una secuencia particular de acciones que lleva a

un resultado valioso (o exito)Tambin puede llevar a un resultado de fracaso

Escenarios y casos de uso

15

Tambin 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 relacin entre escenario y caso de uso es idntica a la que existe entre objeto y clase

Actores y casos de uso

El actor suele ser una persona, pero se diferencia de un usuario

Un actor representa un cierto papel que distintos usuarios pueden jugar.

El t l l l i i t i d l l

16

El actor sera la clase y el usuario una instancia de la clase. Un mismo usuario podra ser instancia de varios actores.

Una mquina o un sistema tambin puede ser un actor Incluso el tiempo (un cronmetro) puede ser un actor

3.2 Descripcin y Construccin de los casos de uso

Descripcin: plantillas El proceso de encontrar y construir los casos de uso

Un caso de uso describe su objetivo (la funcionalidadque se pretende) ms una interaccin entre un actor y un sistema en forma de secuencia de estmulos y respuestas

Descripcin de los Casos de uso

18

La descripcin 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)

4Casos de uso y caja negra

Incorrecto o Correcto?

El cajero pulsa la tecla Inicio El sistema genera un registro en un fichero

19

El sistema genera un registro en un fichero de ventas

El cajero solicita iniciar una nueva venta El sistema genera una sentencia SQL El sistema registra la venta

Formatos de descripcin

El caso de uso se puede describir con varios niveles de detalle: Breve

Un resumen inicial en un par de frases Informal

U j d f l i

20

Un conjunto de prrafos y alternativas Completo

Con todas las alternativas, pre y post-condiciones, etc.

Cf. Ejemplos del Larman

Formatos de descripcin

Por otro lado, se distinguen: Casos de uso Esenciales

El comportamiento del sistema sin entrar en detalles tecnolgicos

21

Casos de uso Concretos Con el detalle de la interfaz de usuario

Ser necesario ajustarlos a los requisitos no funcionales de tipo tecnolgico antes de completar el diseo de la capa de interfaz


La descripcin debe contener: Inicio del caso de uso Fin del caso de uso Interaccin entre el caso de uso y los actores

22

y Intercambios de datos Cronologa y origen de los datos

La descripcin se puede completar con diagramas de secuencia o de transicin de estados


Descripcin 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]segn se describe en el siguiente caso de uso:

Paso Accin

1 {, realizar el caso de uso [caso de uso]}

2

2a Si [Situacin que produce una alternativa] el sistemadeber {, realizar el caso de uso[caso de uso]}

2b Si [Situacin que produce una alternativa] el sistemadeber {, realizar el caso de uso[caso de uso]}

.

SecuenciaNormal

Habitualmente se utiliza una plantillase algn tipo:

23

n .

Paso Accin

p En el caso de que [situacin que provoca la excepcin] elsistema deber {, realizar el caso de uso[caso de uso]}

Excepciones

q

Rendimiento El sistema deber realizar la/s accin /es descrita/s en {los pasos[primer paso] al [ltimo paso], el paso [nmero de paso]} en unmximo de [cota de tiempo]

Frecuencia Este caso de uso se espera que se lleve a cabo una media de [nmero deveces] al [unidad temporal]

Importancia {vital, importante,quedara bien}Urgencia {inmediatamente, hay presin, puede esperar}Comentarios

RF-

Versin

Autores

f

Plantilla de casos de uso (cabecera)

24

Fuentes

Objetivos asociados

Descripcin El sistema deber comportarse tal como se describe en el siguiente caso de uso { concreto cuando , abstracto durante la realizacin de los casos de uso }

5Plantilla (pie)

Rendimiento Paso Cota de tiempo

1 n segundos

2 n segundos

25

Frecuencia esperada veces /

Importancia {sin importancia, importante, vital}

Urgencia {puede esperar, hay presin, inmediatamente}

Comentarios

Plantilla (secuencia normal)

Precondicin

SecuenciaNormal

Paso Accin

1 {El , El sistema} , se realiza el caso de uso < caso de uso RF-x>

2 Si {el el sistema} , se realiza el caso de uso < caso de uso RF-x>

3

4

5

6

n

Postcondicin

Plantilla (excepciones)

Excepciones Paso Accin

1 Si ,{el , el sistema} }>, se realiza el caso de uso

d RF ti i t

27

< caso de uso RF-x>, a continuacin este caso de uso {continua, queda sin efecto}

...14

Descubrir y construir los Casos de uso

Es un proceso iterativo. Se van descubriendo los escenarios desde el

punto de vista del ACTOR y sus objetivos y actividades.

28

Diagrama de actividades Pasos del proceso: 1. Fijar los lmites del sistema 2. Identificar los actores principales 3. Identificar los objetivos/actividades de cada actor 4. Definir (elaborar) cada caso de uso

Actores y lmites del sistema

Cliente

TPDV

TiendaEmpresaHacienda

29

Procesar venta

Cajero

*Objetivos

Comprar cosasRecaudar Gerente de Ventas

Analizar ventas

La estructura del sistema debe decidirse teniendo en cuenta a los actores principales: Los actores principales utilizan directamente el

sistema Los actores secundarios existen para que los

Actores principales y secundarios

30

Los actores secundarios existen para que los principales puedan utilizar el sistema

Pueden utilizarse tcnicas de observacin o entrevista La mayora de los objetivos y actividades son obvios

(vender, cobrar, gestionar una devolucin...)

6Preguntas

Para detectar todos los casos de uso, se puede preguntar: Escribe/lee/modifica el actor alguna informacin

del sistema? Cules son las principales tareas de cada actor?

Informa el actor al sistema de los cambios

31

Informa el actor al sistema de los cambios externos?

Desea el actor ser informado de cambios no esperados?

Ms preguntas

Preguntas estndar para encontrar otros actores y objetivos: quin arranca el sistema? quin gestiona los usuarios y la seguridad? el sistema debe hacer algo cada cierto tiempo?

32

el sistema debe hacer algo cada cierto tiempo? quin evala la actividad del sistema? Cmo se actualiza el software?

Proceso de elaboracin

Identificar a grandes trazos los casos de uso Las principales etapas de cada caso de uso se

describen con un par de frases Se distingue un camino principal y se identifican

los caminos alternativos y excepciones

33

Proceso iterativo: Los casos de uso se amplan, profundizndose en su

descripcin Se buscan etapas comunes y alternativas que representar en

otros caso de uso relacionados por las relaciones incluye, generaliza y extiende

Se debe cuidar que: Exista una descripcin breve que represente una

verdadera imagen del caso de uso

Las condiciones de arranque y parada, pre- y

Resultado final (I)

34

Las condiciones de arranque y parada, pre y postcondicin del caso de uso estn bien definidas

Los usuarios estn satisfechos de la secuencia de interacciones entre el actor y el caso de uso

El problema fundamental es encontrar el nivel de abstraccin adecuado. En general si un caso de uso se hace demasiado grande a

medida que se va detallando es conveniente dividirlo en varios.

Resultado final (II)

35

Se pueden hacer preguntas como: es posible ejecutar un paso de forma independiente a los

otros o siempre va encadenado con ellos? es lgico agrupar varios pasos para documentarlos,

probarlos o modificarlos en conjunto?

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 considerar en lo posible todos los

36

pescenarios de modo que se pueda validar el caso de uso. La ltima comprobacin 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 sntoma

de una mala descripcin del sistema

7Casos de uso - Ejemplo

sacar dinero

usuariosistema del banco emisor

37

Cajero automtico

Consulta de saldo

recarga mvil

administracinoperador Compaa telefnica

CU-003 Sacar dinero Descripcin El sistema deber permitir al cliente del banco, en cualquier momento,

sacar dinero segn se describe en el siguiente caso de uso: 1+ El usuario inserta la tarjeta en el cajero 2 + El cajero lee el cdigo de la banda magntica de la tarjeta y verifica si es aceptable y pide el cdigo del usuario 3+ El usuario introduce el cdigo 4 + Si el cdigo es correcto, el cajero pide al usuario que seleccione el tipo de transaccin deseada 5+ El usuario selecciona la funcin 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 enva la peticin 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 lmite

Secuencia Normal

38

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' Cdigo incorrecto (1,2) + Se emite un mensaje dando al usuario la oportunidad de volver a introducir el cdigo (paso 3) 4'' Cdigo 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 informacin 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 transaccin, con lo que se expulsa la tarjeta

1 El sistema visualiza un mensaje de bienvenida en la pantalla

2 El usuario inserta la tarjeta en el cajero

3 El sistema lee el cdigo de la banda magntica de la tarjeta, verifica si es aceptable

4 El sistema pide el PIN al usuario

Cajero automtico: secuencia normal

39

5 El usuario introduce el cdigo

6 El sistema valida el PIN

7 El sistema pide al usuario que seleccione el tipo de transaccin deseada

8 El usuario selecciona la funcin sacar dinero,

9 El sistema pide al usuario que teclee la cantidad deseada

10 El usuario teclea la cantidad que quiere sacar

11 El sistema comprueba que tiene billetes suficientes

12 El sistema cajero enva la peticin al sistema del banco emisor

13 El banco emisor confirma que hay fondos

Cajero automtico: secuencia normal

40

14 El sistema imprime un recibo

15 El sistema expulsa la tarjeta

16 El sistema entrega el dinero

3 Si la tarjeta no es aceptada, el sistema la expulsa emitiendo un sonido. El caso de uso termina.

6 Si el usuario introduce un cdigo errneo, el sistema pide de nuevo el PIN y el caso de uso continua en el paso 5

6 Si el usuario introduce un cdigo errneo por tercera vez, el sistema retiene la tarjeta y el caso de uso termina.

Cajero automtico: excepciones

41

11 Si el sistema no tiene suficiente dinero, emite un mensaje 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 informacin y el caso de uso continua en el paso 7

13 Si no se consigue comunicacin y la cantidad excede del lmite mximo, el sistema emite un mensaje de informacin y el caso de uso continua en el paso 9

...

Monitorcardiaco

MonitorRemoto

Casos de uso - Ejemplos

42

Mdico

Disparo si algo est fuera

de lo normal

Impresinimpulsos card.

Paciente

Almacn dediagramas

Sistema que controla la actividad cardiaca de un paciente.

83.3 Relaciones entre casos de uso.

Incluye Generaliza Extiende

Incluye () () Es un estereotipo de dependencia. Indica que un caso de uso es

incluido dentro de otro.

Generalizacin (sin estereotipo) Indica que un caso de uso es una variante de otro

Relaciones entre Casos de uso: UML

44

Indica que un caso de uso es una variante de otro. Tambin se usa entre actores para indicar que un actor hereda

el comportamiento de otro y aade nuevas posibilidades

Extiende () () Es un estereotipo de dependencia. Ofrece una forma de

extensin ms controlada que la relacin de generalizacin.

Resumen de los tipos de relaciones

Relacin Funcin Notacin

AsociacinCamino de comunicacin entre un actor y un caso de uso en el que participa

Extiende

Insercin de comportamiento adicional en un caso de uso

45

Extiende base (sin que ste tenga conocimiento)

GeneralizacinRelacin entre un caso de uso/actor

general y otro ms especfico que hereda caractersticas y aade otras

IncluyeInsercin de comportamiento adicional dentro de un caso de uso que describe la insercin

Relacin Incluye

Es una relacin de dependencia donde un caso de uso utiliza otro caso de uso completo, indicando que se incrusta en el primero.

Cuando un nmero de casos de uso comparten un

46

Cuando un nmero de casos de uso comparten un comportamiento comn, se extrae en un caso de uso que es utilizado () por otros.

El caso de uso incluido es el factor comn.

Si el caso de uso nunca se utiliza por s mismo se denomina caso de uso abstracto.

Sacar dinero

Comprobar tarjeta y PIN

Relacin Incluye

47

Consultar saldo

Actor

1 El sistema visualiza un mensaje de bienvenida en la pantalla

2 El usuario inserta la tarjeta en el cajero



Relacin Incluye

Se realiza el caso de uso

48



7 El sistema pide al usuario que seleccione el tipo de transaccin deseada

8 El usuario selecciona la funcin sacar dinero,

9 El sistema pide al usuario que teclee la cantidad deseada

9Comprobar tarjeta y PIN

Caso de uso UC-00X Comprobar tarjeta y PIN



l d l d

49



Excepciones

1 Si la tarjeta no es aceptada, el sistema la expulsa emitiendo un sonido. El caso de uso termina.

4 Si el usuario introduce un cdigo errneo, el sistema pide de nuevo el PIN y el caso de uso continua en el paso 2

4 Si el usuario introduce un cdigo errneo por tercera vez, el sistema retiene la tarjeta y el caso de uso termina.

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:

Relacin de Generalizacin

50

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 relacin muy (demasiado?) flexible.

Relacin de Generalizacin

Cliente Internet

51

Cliente

GiroTransferencia

Transferencia por Internet

El cliente por Internet tambin puede hacer una transferencia convencional en cualquier sucursal

Relacin Extiende

Es una relacin de dependencia donde un caso de uso aade acciones al caso de uso base.

El caso de uso base declara un conjunto de puntos de extensin

52

extensin.

El caso de uso especializado slo puede alterar el comportamiento de los puntos de extensin marcados. Si hay ms de uno, hay que identificar exactamente cul es es

punto extendido.

Un caso de uso extendido puede manejar excepciones, alternativas, etc.

Generaliza y Extiende

Procesar Venta

Puntos de Extensin :Forma de PagoCliente VIPtransferencia por internet

53

extend Forma de Pago, si el Cliente desea pagar con cupones....

Pago con Cupnde regalo

Girotransferencia

transferencia por internetCashier

Process Sale

extend extend

t d

actorAccounting

Relaciones entre Casos de uso:Extiende

54

Customer

Handle CashPayment

Process Rental

Handle CheckPayment

extend

extend extendextend

gSystem

actorCredit

AuthorizationService

Handle CreditPayment

10

Relaciones entre Casos de uso:Incluye (condicionalmente)

Si el cliente paga en efectivo, se realiza el caso de uso

Si el cliente paga por cheque, se realiza el caso de uso

Si el cliente paga con tarjeta, se realiza el caso de uso

55

Cashier

Customer

Handle CashPayment

Process Rental

Process Sale

Handle CheckPayment

include include

include

include includeinclude

actorAccounting

System

actorCredit

AuthorizationService

Handle CreditPayment

Cliente

Relaciones entre Casos de uso

transferencia local

56

transferenciapor Internet transferencia

Identificacin

Comprobacin delestado

Venta por catalogo telefnico

Vendedor


57

Realizacin de unpedido

Completar pedido

Establecer crdito

Empleado

Supervisor

Atencin alCliente


Peticiones alcatlogo con

pedidos


Orden de pago

58

Informacinsuministrada por el

Cliente

Pedido de productos

Orden de pago

3.4.Ventajas y peligros de los casos de uso

Ayudan a asegurar que se desarrolla el sistema correcto

Excelente forma de comunicacin con los clientes y los usuarios

Casos de uso: Ventajas

60

Ayudan a gestionar la complejidad de los proyectos grandes

Ofrecen una buena base para la verificacin y validacin

Modo objetivo para el seguimiento del proyecto

11

Casos de uso: Ventajas tcnicas

Documentan las respuestas funcionales de caja negra

Proporcionan el fundamento de los mensajes

61

Pueden servir como base para especificar respuestas a aplicaciones de control y tiempo real

Casos de uso: Peligros

Llevan a una descomposicin funcional del sistema.

Los casos de uso son funcionales por naturaleza (esto es, localizan la informacin en torno a las funciones).

62

Debe tenerse cuidado cuando se utilizan dentro de un desarrollo orientado a objetos.

Los problemas pueden surgir cuando en un desarrollo software se utilizan diferentes estrategias

Descomposicin funcional

63


Violacin de la ocultacin de la informacin.

Cuando se describen casos de uso, se debe conocer no slo el elemento para el que se desarrolla el caso de uso,

64

p q ,sino tambin la interfaz pblica definida de cada elemento.

Los autores de casos de uso deben evitar la tentacin de ir ms all de la interfaz pblica, e intentar describir la estructura interna del elemento.


Falta de formalidad.

La informalidad de los casos de uso lleva a un falso sentido de seguridad.

65

La gente se olvida de las normas para los nombres y otras convenciones de estilo. Aumenta la posibilidad de cometer errores Disminuye la probabilidad de reutilizar el caso de uso

No saber cuando parar. Puede existir confusin entre la elicitacin de requisitos y los casos de uso y entre el diseo y los casos de uso. Por ejemplo,

Es un juego completo de casos de uso lo


66

mismo que los requisitos de un producto? Existen otros requisitos (del producto o del proyecto) que no estn capturados en los casos de uso? Hay algn aspecto del diseo/arquitectura del sistema que no se ha capturado con los casos de uso?

12

La cobertura es el mayor problema de quien usa los casos de uso:

Una cosa es decir que el conjunto de todos los


67

Una cosa es decir que el conjunto de todos los casos de uso especifican la totalidad de la funcionalidad del sistema

Otra cosa es demostrar que se ha capturado por completo la funcionalidad deseada del sistema en un conjunto de casos de uso.

3.5. Utilidad de la tcnica: el paso a los objetos

Especificacin e implementacin Diagramas de secuencia de caja negra Descomposicin funcional vs colaboracin

Especificacin e implementacin La especificacin 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 se especifica

69

Al nivel de casos de uso esto se especifica como

un diagrama de secuencia (dilogo actor/sistema)

una mquina de estados (o un diagrama de actividad)

Diagramas de secuencia: prstamo(DSS de caja negra)

: Bibliotecario

sistema : Sistema

Se realiza el caso de uso Identificacin de socio

1: comenzar el proceso de prstamo

70

2: comprueba la situacin del socio

4: identifica el libro

6: identifica un ejemplar y solicita al sistema que registre el prstamo

3: identifique el libro

5: ejemplares disponibles

7: proceso de registro ha terminado

Mquina de estados: cajero automtico

bienvenidaentry/ ^display.mostrar_bienvenida

esperando PINentry/ ^display.pedirPIN

entrega dineroentry/ entregardineroentry/ ^lector.expulsar_tarjeta

insertada( numero )

tarjeta retirada

71

Opcionesentry/ ^display.mostrar_opciones

Importeentry/ ^display.pedir_cantidad

conexion bancoentry/ conectar(banco)entry/ ^display.mostrar_mensaje("espere...conectando")

PINtecleado( PIN )[ error ]

PINtecleado( PIN )[ ok ]

seleccionar "sacar"when( 30 seg ) ^display.mensaje(mximo)

importe introducido

transaccion[ ok ]

Casos de uso: Implementacin

La relacin entre los casos de uso y su implementacin es una Realizacin.

La implementacin de un caso de uso puede

72

ser vista como una colaboracin:

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 cuestin.

13

Transicin hacia los objetos Una descomposicin que siga directamente la forma de los

casos de uso conduce a una aproximacin estructurada clsica, funcional...


Orden de pago

73

Informacinsuministrada por el

ClientePedido de productos

Orden de pago

Pedido de productos

Informacinsuministrada

Realizacin de un pedido ?

Es necesario realizar un paso al mundo de los objetos

Se efecta asociando una colaboracin a cada caso de usoLa colaboracin describe objetos del mbito, las

Transicin hacia los objetos

74

conexiones entre estos objetos y los mensajes que intercambian stos

La realizacin de un caso de uso por una colaboracin es momento crucial del modelado; Es el momento del cambio hacia la orientacin a objeto

Caso de uso Colaboracin

Transicin hacia los objetos

75

Objeto Objeto Objeto

Casos de uso y UP

January February

Cundo Donde

elaboracin

inicio

76

Use Case: Capture a Sale. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

Use Case: Handle Returns. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

Quin CmoSoftware:

Herramienta CASE + herramienta de requisitos + Hyperlink

Desarrollador

ClienteAnalista

Usuario

Two adjacent projections.

Arquitecto

Bibliografa Recomendada

Larman, C. UML y Patrones. Introduccin al Anlisis y Diseo Orientado a Objetos y al Proceso Unificado . Prentice Hall, 2002. Captulos 6..9, 25

Amador Durn y Beatriz Bernrdez, Metodologa para la

Elicitacin de Requisitos de Sistemas Software. 2003.

77

Elicitacin de Requisitos de Sistemas Software. 2003.

Lecturas complementarias J. 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

Caso de estudio Punto de venta

Cajero: Procesar ventas Procesar

Administrador: Aadir usuarios Modificar usuarios

Actores, actividades y casos de uso:

78

devoluciones Abrir y cerrar caja

Director: Poner en marcha Suspender

operaciones

Gestionar tablas del sistema

Control de ventas: Analizar los datos de

ventas y rendimiento

14

Diagrama de casos de uso

Sistema contable

Actor_Cajero

Procesar Alquiler

Procesar Venta

79Gestionar seguridad

Gestionar usuariosAdministrador

del sistema

Sistema de autorizacinPago con cupn

Pago con tarjeta

Pago en metlico

Gestionar Devolucin

Caso de uso Procesar venta

1. El cajero solicita iniciar una nueva venta

2. El sistema solicita el cdigo del artculo

3. El cajero introduce el cdigo del artculo

( se inicia cuando un cliente llega a la caja con uno o varios artculos)

80

4. El sistema registra una lnea de detalle y muestra el nombre y precio del artculo5. El cajero indica el fin de la venta

6. El sistema presenta el total

7. Se realiza el

8. El sistema registra la venta y enva la informacin al sistema contable9. El sistema imprime el recibo

1. El cajero inicia una nueva Venta2. El sistema solicita el cdigo del artculo3. El cajero introduce el cdio del artculo4. El sistema registra una lnea de detalle y muestra el nombre y precio del artculo

: Actor_Cajero

: Sistema

inicia nueva venta

introduce el cdigo del artculo

muestra el nombre y precio del artculo

(pasos 2..4 se repiten)

solicita el cdigo

81

y precio del artculo

5. El cajero indica el fin de la venta6. El sistema presenta el total7. Punto de extensin: PAGO8. El sistema registra la venta y enva la informacin al sistema contable...

fin de la venta

presenta el total

registra la venta

Punto de extensin:Forma de PAGO

Ejemplo Larman, completo

Actor principal: Cajero. Personal involucrado e intereses:

Cajero: quiere entradas precisas, rpidas, y sin errores de pago, ya que las prdidas se deducen de su salario.

Vendedor: quiere que las comisiones de las ventas estn actualizadas. Compaa: Quiere registrar las transacciones con precisin y satisfacer el

inters de los clientes. Quiere asegurar que se registran los pagos aceptados por el Servicio de Autorizacin de Pagos Quiere cierta tolerancia

82

aceptados por el Servicio de Autorizacin de Pagos. Quiere cierta tolerancia a fallos que permita capturar la ventas .

Agencia Tributaria del Gobierno: quiere recopilar los impuestos de cada venta ser mltiples agencias: nacional, provincial y local.

Servicio de Autorizacin de Pagos: Quiere recibir peticiones de autorizacin digital en formato y protocolo correctos. Quiere registrar de manera precisa las cuentas de la tienda.

Precondiciones: El cajero se identifica y autentifica. Garantas de xito (Postcondiciones): Se registra la venta. El impuesto se

calcula de manera correcta. Se actualizan la contabilidad y el inventario. Se registran las comisiones y se genera el recibo. Se registran las autorizaciones de pago aprobadas.

Ejemplo Larman

El caso de uso empieza cuando un Cliente llega a un terminal PDV con mercancas y/o servicios que compra

Escenario principal de xito (o Flujo Bsico):

1. El Cajero comienza una nueva venta. 2. El sistema solicita el identificador del artculo.

83

3. El Cajero introduce el identificador del artculo. 4. El Sistema registra la lnea de la venta y presenta la descripcin del artculo y

suma parcial. El precio se calcula a partir de un conjunto de reglas de precios El Cajero repite los pasos 3-4 hasta que indique el fin de la venta 5. El Sistema presenta el total con los impuestos calculados. 6. El Cajero le dice al Cliente el total y pide que le pague e introduce la cantidad 7. El Sistema gestiona el pago. 8. El Sistema registra la venta completa y enva la informacin de la venta y el pago

al sistema de Contabilidad externo (para la contabilidad y las comisiones) y al sistema ventas (para actualizar el inventario).

9. El Sistema emite el recibo. 10. El caso de uso termina (10. El Cliente se va con el recibo y las mercancas )

Ejemplo Larman

Extensiones (o Flujos Alternativos): *a En cualquier momento el Sistema falla: Para dar soporte a la recuperacin y registro correcto, asegura que

todos los eventos significativos de una transaccin puedan recuperarse desde cualquier punto del escenario. 1. El Cajero reinicia el Sistema, inicia la sesin, y solicita la recuperacin al tenor.

84

2. El Sistema reconstruye el estado anterior. 2a. El Sistema detecta anomalas intentando la recuperacin: 1. El Sistema informa del error al Cajero, registra el error, y pasa a limpio. 2. El Cajero comienza una nueva venta.

3a. Identificador no vlido: 1. El Sistema seala el error y rechaza la entrada.

3b. Hay muchos artculos de la misma categora y tener en cuenta una nica identidad del artculo no es importante (ej. 5 paquetes de hamburguesas vegetales): 1. El Cajero puede introducir el identificador de la categora del artculo y la cantidad.

15

Ejemplo Larman

3-6a. El Cliente le pide al Cajero que elimine un artculo de la compra: 1. El Cajero introduce el identificador del artculo para eliminarlo de la compra. 2. El Sistema muestra la suma parcial actualizada.

3-6b. El Cliente le pide al Cajero que cancele la venta: 1. El Cajero cancela la venta en el Sistema.

3-6c. El Cajero detiene la venta: 1. El sistema registra la venta para que est disponible su recuperacin en cualquier

t i l PDV

85

terminal PDV.

4a. El Sistema genera el precio de un artculo que no es el deseado (ej. el Cliente se queja por algo y se le ofrece un precio ms bajo): 1. El Cajero introduce el precio alternativo. 2. El Sistema presenta el precio nuevo.

5a. El sistema encuentra algn fallo para comunicarse con el servicio externo del sistema de clculo de impuestos. 1. El Sistema reinicia el servicio en el nodo PDV y contina. 1a. El Sistema detecta que el servicio no se remida.

1. El Sistema seala el error. 2. El Cajero podra calcular e introducir manualmente el impuesto, o cancelar la

venta.

Ejemplo Larman

5b. El Cliente dice que le son aplicables descuentos (ej. empleado, cliente preferente): 1. El Cajero seala la peticin de descuento. 2. El Cajero introduce la identificacin del Cliente. 3. El Sistema presenta el descuento total, basado en las reglas de descuento.

5c. El Cliente dice que tiene crdito en su cuenta, para aplicar a la venta:

l C j l l i i d di

86

1. El Cajero seala la peticin de crdito. 2. El Cajero introduce la identificacin del Cliente. 3. El Sistema aplica el crdito hasta que el precio O, y reduce el crdito que queda.

6a. El Cliente dice que su intencin era pagar en efectivo pero que no tiene suficiente: 1a. El Cliente utiliza un mtodo de pago alternativo. 1b. El Cliente le dice al Cajero que cancele la venta. El Cajero cancela la venta en el

Sistema.

Ejemplo Larman

7a. Pago en efectivo: 1. El Cajero introduce la cantidad de dinero en efectivo entregada. 2. El Sistema muestra la cantidad de dinero a devolver y abre el cajn de caja. 3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente. 4. El Sistema registra el pago en efectivo.

7b. Pago a crdito: 1. El Cliente introduce la informacin de su cuenta de crdito. 2 El Sistema enva la peticin de autorizacin del pago al Sistema externo de Servicio

87

2. El Sistema enva la peticin de autorizacin del pago al Sistema externo de Servicio de Autorizacin de Pagos, y solcita la aprobacin del pago.

2a. El Sistema detecta un fallo en la colaboracin con el sistema externo: 1. El Sistema seala el error al Cajero. 2. El Cajero le pide al Cliente un modo de pago alternativo.

3. El Sistema recibe la aprobacin del pago y lo notifica al Cajero. 3a. El Sistema recibe la denegacin del pago:

1. El Sistema seala la denegacin al Cajero. 2. El Cajero le pide al Cliente un modo de pago alternativo. 4. El Sistema registra el pago a crdito, que incluye la aprobacin del pago 5. El Sistema presenta el mecanismo de entrada para la firma del pago a crdito. 6. El Cajero le pide al Cliente que firme el pago a crdito. El Cliente introduce la

firma.

Ejemplo Larman

7c. Pago con cheque... 7d. Pago a cuenta... 7e. El Cliente presenta cupones:

1. Antes de gestionar el pago, el Cajero recoge cada cupn y el Sistema reduce el pago como sea oportuno. El sistema registra los cupones utilizados por razones de contabilidad.

la. El cupn introducido no es vlido para ninguno de los artculos comprados1 El Sistema seala el error al Cajero

88

1. El Sistema seala el error al Cajero.

9a. Hay rebajas en los artculos: 1. El Sistema presenta los formularios de rebaja y los recibos de descuento para cada

artculo con una rebaja.

9b. El Cliente solicita un vale-regalo (sin precio visible): 1. El Cajero solicita el vale-regalo y el Sistema lo proporciona.

casos de uso (informatica); sistemas de informacion

Documents

Transcript of casos de uso (informatica); sistemas de informacion