Gonzalorojas 07 U M L, Casos De Uso ( Final)

1

Fundamentos deModelado OO en UML

Adaptado de Curso de UML, Patricio Letelier T.,

Universitat Politècnica de València, España

2

Objetos

Objeto = unidad atómica que encapsula estado y comportamiento

La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento

Un objeto puede caracterizar una entidad física (coche) o abstracta (ecuación matemática)

3

… Objetos

En UML, un objeto se representa por un rectángulo con un nombre subrayado

Un objeto

Otro objeto más

Otro objeto

4

… Objetos

Ejemplo de varios objetos relacionados:

Felipe

Juan

Cuenta Corriente 101

Cuenta Corriente 114

Banco de Valencia

5

… Objetos

Objeto = Identidad + Estado + ComportamientoEl estado está representado por los valores de los atributosUn atributo toma un valor en un dominio concreto

Un coche

Azul 979 Kg 70 CV

...

6

Clases y Objetos

7

Comportamiento

Ejemplo de interacción:

Un Objeto

Otro Objeto

Operación 1

Operación 21: Un mensaje

8

… Comportamiento

Los mensajes navegan por los enlaces, a priori en ambas direcciones

Estado y comportamiento están relacionados

Ejemplo: no es posible aterrizar un avión si no está volando. Está volando como consecuencia de haber despegado del suelo

9

Persistencia

La persistencia de los objetos designa la capacidad de un objeto de trascender en el espacio/tiempo

Podremos después reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecución (materialización del objeto)

Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debería ser transparente, un objeto existe desde su creación hasta que se destruya

10

Comunicación

Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan de manera coordinada en la consecución de un fin específico

El comportamiento global se basa pues en la comunicación entre los objetos que la componen

11

… ComunicaciónCategorías de objetos:• Activos - Pasivos• Cliente – Servidores, Agentes

Objeto Activo: posee un hilo de ejecución (thread)propio y puede iniciar una actividad

Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se le solicita un servicio

Cliente es el objeto que solicita un servicio. Servidores el objeto que provee el servicio solicitado

12

… Comunicación

Los agentes reúnen las características de clientes y servidores

Son la base del mecanismo de delegación

Introducen indirección: un cliente puede comunicarse con un servidor que no conoce directamente

13

… Comunicación

Ejemplo con objeto agente:

Un cliente

Un agente

Servidor 1

Servidor 2

1:

2:

3:

14

El Concepto de Mensaje

La unidad de comunicación entre objetos se llama mensaje

Objeto 1 Objeto 2

Objeto 3 Objeto 4

1: Mensaje A

2: Mensaje C

3: Mensaje D

4: Mensaje E

15

Mensaje y EstímuloUn estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de una señal

Un mensaje es la especificación de un estímulo

16

UMLDiagrama de Casos de Uso

17

Casos de UsoLos Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario

Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno

Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación

Diferente al Diagrama de Flujo de Datos del Enfoque Estructurado

18

… Casos de UsoActores:

• Principales: personas que usan el sistema• Secundarios: personas que mantienen o administran el

sistema• Material externo: dispositivos materiales imprescindibles

que forman parte del ámbito de la aplicación y deben ser utilizados

• Otros sistemas: sistemas con los que el sistema interactúa

La misma persona física puede interpretar varios papeles como actores distintos

El nombre del actor describe el papel desempeñado

19

… Casos de UsoLos Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario

Un escenario es una instancia de un caso de uso

Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso

20

Casos de Uso: Relaciones

UML define cuatro tipos de relación en los Diagramas de Casos de Uso:

• Comunicación

Actor C aso de U so

21

… Casos de Uso: Relaciones

• Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

<<include>> reemplazó al denominado <<uses>>

Caso de Uso Origen C aso de U so Desti no

<<include>>

22

Verificar Operación

Reintegro Cuenta Corriente

Cliente

Reintegro Cuenta de Crédito

<<include>>

<<include>>


Ejemplo <<include>>:

23


• Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

Caso de Uso Origen C aso de U so Desti no

<<extend>>

24

Solic itar N ueva Tarjeta

Cliente Solicitar Préstamo

<<extend> >

[Tarjeta Caducada]


Ejemplo <<extend>>:

25

… Casos de Uso: RelacionesEjemplo <<include>> y <<extend>>:

Ident ificación

Transferencia en Internet

ClienteTransferencia

<<include>>

<< extend>>

26


Otro ejemplo <<include>> y <<extend>>:

Place OrderSalesperson

*1 *1

Supply Customer Data

<<include>>

Order Product

<<include>>

Arrange Payment

<<include>>

Request Catalog

<<extend>>

the salesperson asks for the catalog

27


• Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía

Caso de Uso Hij o Caso de Uso Padre

28


• Ejemplo de herencia

Cliente

* *Reserva de

Billete Aéreo

Reserva por Agencia

Reserva en Aerolínea

29

Casos de Uso: ConstrucciónUn caso de uso debe ser simple, inteligible, claro y concisoGeneralmente hay pocos actores asociados a cada Caso de UsoPreguntas clave:• ¿cuáles son las tareas del actor?• ¿qué información crea, guarda, modifica,

destruye o lee el actor?• ¿debe el actor notificar al sistema los cambios

externos?• ¿debe el sistema informar al actor de los

cambios internos?

30

… Casos de Uso: ConstrucciónLa descripción del Caso de Uso comprende:• el inicio: cuándo y qué actor lo produce?• el fin: cuándo se produce y qué valor devuelve?• la interacción actor-caso de uso: qué mensajes

intercambian ambos?• objetivo del caso de uso: ¿qué lleva a cabo o

intenta?• cronología y origen de las interacciones• repeticiones de comportamiento: ¿qué

operaciones son iteradas?• situaciones opcionales: ¿qué escenarios

alternativos se presentan en el caso de uso?

31

Ejemplo

Cliente Sistema Bancario

Cajero Automático

Sacar Dinero

RealizarTransferencias

Depositar Dinero

Administrar Cajero

Operador

32

Caso de Uso UC1: Sacar Dinero Actor Principal: Cliente Personal involucrado e intereses:

- Cliente: quiere retirar dinero en efectivo desde su cuenta de forma rápida y sencilla

- Sistema Bancario: quiere recibir peticiones de transacción en formato correcto; quiere mantener actualizada la información de las cuentas de sus clientes a partir de la información de los giros en el Cajero.

Precondiciones: El Cliente suministra tarjeta bancaria Garantías de éxito (Postcondiciones): El Cliente obtiene el monto requerido en dinero en efectivo. Escenario Principal de Éxito (o Flujo Básico):

1. El Cliente inserta la tarjeta en el Cajero 2. El Cajero lee el código de la banda magnética de la tarjeta,

verifica si es aceptable y pide el código del Cliente 3. El Cliente introduce el código 4. Si el código es correcto, el Cajero pide al Cliente que seleccione

el tipo de transacción deseada 5. El Cliente selecciona la función Sacar Dinero 6. El Cajero le pide al cliente que teclee la cantidad deseada 7. El Cliente teclea la cantidad que quiere sacar 8. El Cajero envía la petición al sistema bancario 9. Si la conexión al Sistema Bancario es exitosa, el Sistema

Bancario deberá comprobar si el monto es permitido. 10. El Cajero expulsa la tarjeta, imprime el recibo y entrega el dinero

33

Extensiones (o Flujos Alternativos): 2’ La tarjeta no es aceptada

- El Cajero expulsa la tarjeta, emitiendo un sonido 4’ Código incorrecto (1,2)

- Se emite un mensaje, dando al Cliente la oportunidad de volver a introducir el código

4’’ Código incorrecto (3) - Se emite un mensaje y se retiene la tarjeta

9’a Fallo en la conexión con Sistema Bancario - Se emite un mensaje y se expulsa la tarjeta

9’b El Sistema Bancario no permite girar ese monto - Se emite un mensaje y se expulsa la tarjeta

10’ El Cajero no dispone de la cantidad pedida - Se emite un mensaje y se vuelve al paso 7

1-9’ Cancelar - En cualquier momento, el usuario puede cancelar la

transacción, con lo que se expulsa la tarjeta

34

Ejemplo 2…

Cliente

Venta por Catálogo

Vendedor

Empleado

Supervisor

Comprobar Estadodel Pedido

Realizar Pedido

Completar Pedido

Establecer Crédito

35

…Ejemplo 2

Realizar Pedido

Suministrar DatosCliente

Realizar Pedido deProductos

Realizar Pago

Solicitar Catálogo

<<include>><<include>>

<<extend>>

Cliente

Vendedor

<<include>>

36

Plantilla de documentación propuesta…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>}

37

Precondición <precondición del caso de uso> Postcondición <postcondición del caso de uso>

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

Secuencia Normal

n

Plantilla de documentación propuesta…

38

Plantilla de documentación propuesta…

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}

2

Excepciones

3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos

39

Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales>

…Plantilla de documentación propuesta

40

ComentariosEn métodos OO que carecen de una técnica de captura de requisitos se comienza inmediatamente con la construcción del modelo de análisis/diseño

Los Casos de Uso son una idea maravillosa que ha sido generalmente complicada. El verdadero truco para los Casos de Uso es mantenerlos simples. Recordad, mañana van a cambiar. Rober C. Martin

Los requisitos NO funcionales también son importantes. Desempeño, cumplimiento de estándares o leyes, atributos de calidad (confiabilidad, disponibilidad, seguridad, mantenibilidad, portabilidad), etc.

41

Recomendación Bibliográfica

UML y Patrones, Craig Larman, Sección 6.6

Documents

Gonzalorojas 07 U M L, Casos De Uso ( Final)