El modelo de casos de uso

1
El modelo de casos de uso
Ingeniería de la Programación Capítulo 4
2
Contenidos

• 3.1 Introducción
• 3.2 Actores y Casos de Uso
• 3.3 Modelo de casos de uso
• 3.3.1 Diagrama de contexto y modelo inicial.
• 3.3.2 Plantillas de especificación.
• 3.3.3 Modelo estructurado.
• 3.4 Relaciones entre actores y casos de uso
• 3.5 Proceso de construcción del modelo de casos
  de uso
• 3.6 Propuesta de ciclo de desarrollo

3
3.1 Introducción

• Introducidos por I. Jacobson en Objectory.
• Los casos de uso describen bajo la forma de
  acciones y reacciones el comportamiento de un
  sistema desde el punto de vista de los usuarios.
• Son descripciones de la funcionalidad del futuro
  sistema independientes de la implementación.
• Sirven para captar los requisitos funcionales de
  un sistema software.

4
Introducción

• Por qué casos de uso?
• Fácilmente compresibles por clientes-usuarios.
• Representan los requisitos funcionales.
• Se utilizan como base para un desarrollo
  iterativo e incremental.
• Incorporados en la mayor parte de los métodos de
  desarrollo OO de segunda generación.

5
3.2 Actores y Casos de Uso

• Los actores definen qué existe fuera del sistema
• Un actor puede ser una persona, un conjunto de
  personas, un sistema hardware, un sistema
  software o un reloj.

6
Actores

• Un actor representan un rol que puede desempeñar
  alguien o algo que necesita intercambiar
  información con el sistema.

7
Casos de uso

• Un caso de uso describe una forma concreta de
  utilizar parte de la funcionalidad del sistema.
• La colección de todos los casos de uso describe
  toda la funcionalidad del sistema.

8
Caso de uso (definición)

• I. Jacobson propone dos definiciones
• Documento que describe una secuencia de eventos
  que realiza un actor (agente externo) que usa el
  sistema para llevar a cabo un proceso que tiene
  algún valor para el.
• Cada caso de uso está formado por una secuencia
  de eventos, iniciada por un actor, que describe
  la interacción que tiene lugar entre el actor y
  el sistema.

9
Caso de uso

• Características
• Son iniciados por un actor (actor primario o
  principal).
• Pueden participar otros actores (secundarios)
• Poseen un nombre.
• Pueden contener condiciones de inicio
  (precondiciones) y condiciones de terminación
  (postcondiciones)
• La descripción del caso de uso contiene la
  secuencia de eventos.

10
Caso de uso (notación)

• La comunicación entre actores y casos de uso se
  muestra de la forma

11
3.3 Modelo de casos de uso

• Notación gráfica con actores y casos de uso.
• Relaciones
• Entre actores herencia.
• Entre actores y casos comunicación.
• Entre casos de uso
• Usa, extiende (UML 1.3)
• Incluye, extiende, hereda de (UML 1.5)
• Descripción plantillas textuales para cada caso
  de uso.

12
Notación gráfica

• El modelo de casos de uso muestra gráficamente
  toda la funcionalidad del sistema.

13
Organización del modelo

• Estructurado en tres capas
• Diagrama de contexto y modelo inicial.
• Plantillas de descripción.
• Modelo estructurado.

14
3.3.1 Diagrama de contexto.

• El diagrama de contexto muestra los límites del
  sistema y los actores (agentes externos) que
  interactuarán con el mismo.

15
Modelo inicial

• Contiene la agrupación jerárquica de los
  distintos casos de uso
• Mediante paquetes UML (subsistemas).

16
Modelo inicial (2)

• O bien

17
Modelo inicial (2)

• Utilizando un árbol de descomposición funcional.

Nuevo Cliente
Buscar Cliente
18
3.3.2 Plantillas de descripción

• Los casos de uso se describen utilizando
  plantillas en lenguaje natural.
• Habitualmente
• Nombre del CU.
• Descripción.
• Actores (primario y secundarios)
• Precondiciones, Postcondiciones.
• Flujo de eventos.

19
Ejemplo TPV

• Para un terminal punto de venta

Un terminal punto de venta (TPV) es un sistema
computerizado usado para registrar las ventas y
gestionar pagos. Se usa en supermercados y en
grandes almacenes. Incluye componentes hardware
(como el ordenador y el escáner del código de
barras) y software para ejecutar el sistema.
20
Ejemplo TPV (2)

• Diagrama de contexto y modelo inicial

21
Ejemplo TPV (3)

• Variaciones sobre el ejercicio

22
Plantillas TPV

• Si únicamente se desea mostrar la interacción de
  los actores con el sistema informático.

23
Plantilla TPV
24
Plantilla TPV
25
Plantilla TPV

• Si únicamente se desea mostrar la interacción con
  el sistema informático, debe eliminarse la
  referencia al cliente dentro de la descripción
  anterior.

26
Plantilla TPV (caso de uso sistema)
27
Plantilla TPV (caso de uso sistema)
28
Estilos de descripción casos esenciales y reales

• Los casos de uso esenciales son independientes de
  la interfaz y de la tecnología.

Caso de uso esencial (descripción muy abstracta)
Caso de uso real/concreto (descripción muy
detallada)
29
Casos esenciales y concretos
30
Escenarios y Casos de Uso

• Un escenario es una descripción textual de una
  interacción particular entre los actores y el
  sistema.
• A un caso de uso le corresponden varios
  escenarios.
• Los escenarios básicos o principales no contienen
  situaciones de error.
• Los secundarios describen situaciones de error o
  alternativas de ejecución.

31
3.3.3 Modelo estructurado

• Contiene los actores y las relaciones entre los
  casos de uso (explicado después)

Ejemplo tomado de Telelogic Tau 2.2
32
Modelo estructurado (2)

• Ejemplo de UML 1.5

33
3.4 Relaciones entre actores y casos de uso.

• Herencia entre actores La relación de herencia
  entre actores indica que el actor descendiente
  puede jugar todos los roles del actor antecesor.

34
Herencia entre actores

• Actor abstracto Participa en el modelo pero no
  interactúa directamente con el sistema.

35
Relaciones entre casos de uso incluye

• Inclusión Un caso de uso A incluye a un caso de
  uso B, si una instancia de A puede realizar todos
  los eventos que aparecen descritos en B.

La instanciación de Baja Socio utiliza siempre el
flujo de eventos de Buscar Socio
36
Inclusión de casos de uso

• En la descripción de A se incluye una referencia
  a B.

37
Relación de extensión

• Un caso de uso B extiende a un caso de uso A, si
  en la descripción de A figura una condición cuyo
  cumplimiento origina la ejecución del flujo de
  eventos de B.

38
Relación de extensión (2)

• Una extensión equivale a una inclusión una
  condición.

Descripción del caso de uso A
Condición
Descripción del caso de uso B
39
Relación de extensión (3)

• Útil para
• Partes opcionales de un caso de uso.
• Representar sub-cursos de eventos que se ejecutan
  bajo ciertas condiciones.
• Para representar un menú con opciones.

40
Extensión (4)

• Se pueden tener varios puntos de extensión.

Caso base Reservar un vuelo
Seleccionar asiento
Imprimir asignación
Extensión realizar asignación de asiento
41
Relación de herencia

• Un caso de uso B se dice que especializa a un
  caso de uso A si el flujo de eventos asociado a B
  es un refinamiento del flujo de eventos asociado
  a A.
• Relación similar a la herencia OO.
• Permite separar un patrón de interacción genérico
  (caso padre) de un patrón de interacción más
  específico (caso descendiente).

42
Herencia (2)

• Ejemplo

43
Relaciones entre casos de uso (1)

• Dado un conjunto de casos de uso no existe una
  única forma de representar las relaciones entre
  ellos.
• Diferencias entre inclusión y extensión
• Una inclusión es equivalente a una extensión sin
  condiciones.
• El caso incluido siempre forma parte del caso que
  incluye.
• El caso que incluye no tiene sentido sin el
  incluido.

44
Relaciones entre casos de uso (2)

• Diferencias extensión y especialización
• La extensión se utiliza para representar
  alternativas de ejecución que se llevan a cabo en
  algunas ocasiones.
• La especialización se utiliza para representar
  patrones genéricos de interacción que pueden
  especializarse en patrones más específicos o
  concretos.

45
3.5 Proceso de construcción del modelo de casos
de uso

• Para construir el modelo de casos de uso
• Técnica descendente.
• Técnica ascendente.

Descendente
Ascendente
Detectar actores
Organizar modelo de Casos de uso
Encontrar Casos de uso
Generalizar escenarios
Detallar Casos de uso
Crear escenarios
46
Reglas para identificar actores

• Los usuarios pueden jugar varios roles cuando
  interactúan con el sistema.
• Un usuario se puede corresponder con varios
  actores.

47
Reglas para detectar actores

• Cualquier grupo o individuo que caiga en alguna
  de las siguientes categorías
• Quién usará el sistema?
• Quién instalará el mismo?
• Quién hará labores de mantenimiento?
• Quién lo apagará?
• Qué otros sistemas se comunicarán con éste?
• Quién obtiene información?
• Quién proporciona información?

48
Reglas para identificar casos de uso

• Prestando atención a los actores
• Cuáles son las tareas que los actores quieren
  que el sistema realice para ellos?.
• Podrá un actor crear, almacenar, cambiar o
  borrar datos del sistema?.
• Será necesario que un actor informe al sistema
  sobre cambios que han ocurrido en el exterior del
  mismo?.
• Será necesario que el actor sea informado sobre
  ciertas ocurrencias o cambios dentro del
  sistema?.

49
Reglas...

• Las respuestas a cada una de las preguntas
  anteriores representan flujos de eventos que
  identifican casos de uso candidatos.

50
3.6 Propuesta de ciclo de desarrollo

• El ciclo de desarrollo en espiral se puede
  estructurar tomando como base los casos de uso
  del sistema.

51
Ciclo de desarrollo...

• Cada ciclo de desarrollo conlleva análisis,
  diseño, implementación y pruebas.

52
Ejemplo

• Desarrollo de un software para procesar ordenes
  de pedido para una compañía de ventas por correo.
  Ésta se encarga de vender productos comprados a
  diversos proveedores.
• Dos veces por año, la compañía publica un
  catalogo con sus productos, el cual es enviado a
  sus clientes y a otras personas interesadas.
• Los clientes compran productos enviando una lista
  de los mismos con la forma de pago. La empresa
  completa la orden y envía el pedido a la
  dirección correspondiente del cliente.
• El software de procesamiento de pedidos debe ser
  capaz de efectuar un seguimiento completo de una
  orden desde que ésta es recibida hasta que ésta
  es enviada.
• Los clientes pueden devolver artículos.
• Una interfaz electrónica, como la Web, puede ser
  apropiada para algunos clientes.
• La compañía utilizará diversas compañías de
  envío para atender los pedidos.
• ! NO se incluyen todos los requisitos!