UML

1
UML

• Wilson Peláez Hernández

2
LOS CASOS DE USO
3
Contenido

• Introducción
• Antecedentes
• Los casos de uso
• Concepto de Escenario
• Concepto de Actor
• Proceso para especificar un caso de uso
• Busqueda de actores
• Personal involucrado
• Especificación de un caso de uso
• Precondición
• Postcondición

4
Contenido

• Secuencia normal
• Secuencias alternas
• Otra información
• Ejemplo Sacar Dinero
• Actividades donde se usa los casos de uso
• Relación entre los casos de uso
• Relación de extensión
• Relación de inclusión
• Casos de uso abstractos
• Diagramas de los casos de uso

5
Contenido

• Notación
• Elementos de un diagrama
• Modularización de los casos de uso
• Ventajas e los casos de uso
• Lecturas recomendadas
• Bibliografia

6
Introducción

• Los casos de uso son una técnica para especificar
  el comportamiento de un sistema.
• Todo sistema de software ofrece a su entorno una
  serie de servicios.
• Un caso de uso expresa como alguien accede a este
  servicio.
• Los casos de uso ayudan a validar la arquitectura
  y verificar el sistema
• Los casos de uso son un mecanismo utilizado para
  descubrir y registrar los requisitos de una
  aplicación.

7
Antecedentes

• Ivar Jacobson introdujo la idea de utilizar los
  casos de uso para describir los requisitos
  funcionales de un sistema.
• Object-Oriented Software Enginieering A use
  case driven approach Addison-Wesley
• No estableció un formato concreto , ni un proceso
  detallado.

8
Antecedentes

• Un de los autores más influyentes hoy en dia en
  el manejo de los casos de uso es Alistair
  Cockburn.
• Writing Effective Use Cases Addison Wessley
• Estableció la parte de qué son (deberían ser) y
  como escribirlos.

9
Los casos de uso

• Son requerimientos funcionales que describen de
  una manera detallada el comportamiento de un
  sistema con los distintos actores que interactúan
  con él.
• Es un documento que describe la secuencia de
  eventos de un actor (agente externo) que utiliza
  un sistema para completar un proceso.

10
Los casos de uso

• Es una descripción de un conjunto de secuencias
  de acciones, incluyendo variantes, que ejecuta un
  sistema para producir un resultado observable de
  valor para un actor.
• No definen todos los requerimientos, pero
  representan el hilo conductor que vincula a todos
  los requerimientos posibles actuales y futuros-
  de una aplicación

11
Los casos de uso

• Una actitud clave en el trabajo con casos de uso
  es centrarse en la pregunta
• Cómo puedo, utilizando el sistema, proporcionar
  un valor observable al usuario, o cumplir sus
  objetivos
• El concepto de caso de uso trabaja con los
  requisitos centrandose en cómo puede un sistema
  añadir valor y cumplir los objetivos

12
Utilidad de los casos de uso
13
Concepto Escenario

• Un escenario es una secuencia específica de
  acciones e interacciones entre los actores y el
  sistema objeto de estudio.
• Es una historia particular del uso de un sistema
• Escenario principal (caso de éxito flujo común)
• Escenarios alternos ( casos de fallo flujo
  alterno opcional)

14
Escenario

• Un escenario es una secuencia de pasos, que puede
  ser de tres tipos
• Una interacción entre actores
• Una válidación(normalmente a cargo del sistema)
• Un cambio de estado realizado por el sistema

15
Concepto Actor

• El actor es una entidad externa del sistema que
  de alguna manera participa en la historia del
  caso de uso.
• Estimula al sistema con eventos de entrada o
  recibe algo de él.
• Un actor representa un rol en el sistema.
• Se pueden distinguir tres tipos de actores
  básicos
• Actor Silencioso (pasivo)
• Actor Principal
• Actor Soporte

16
Proceso para especificar un CU
17
Búsqueda de actores

• Quién esta interesado en un requerimiento
  concreto?
• Quién será beneficiario de la nueva
  funcionalidad?
• Quien proveerá, usará o eliminará la información?
• Qué usuarios actuarán con diferentes roles?
• Diferentes usuarios actuarán con el mismo rol?
• El sistema interactuará con otros sistemas?

18
Personal involucrado

• CockburnEn el caso de uso no sólo se debe
  identificar el actor principal, sino otros
  actores involucrados.
• Esta lista sugiere y delimita que es lo que debe
  hacer el sistema, y a quién involucra.
• El sistema funciona siguiendo un contrato entre
  el personal involucrado,donde los casos de uso
  detallan la parte de comportamiento del sistema.

19
Especificación de un caso de uso

• Los casos de uso deben tener.
• Identificador
• Nombre
• Versión
• Autores
• Fuentes
• Breve descripción
• Importancia
• Dependencia
• Comentarios

20
Precondición

• Establece lo que siempre debe cumplirse antes de
  comenzar un escenario en el caso de uso.
• Condiciones que describen en que situación se
  debe encontrar el sistema y su entorno para poder
  comenzar el caso de uso.
• Las precondiciones no se prueban en el caso de
  uso.
• Un precondición, generalmente, implica otro caso
  de uso que se ha completado con éxito.

21
Postcondición

• Establece que debe cumplirse cuando el caso de
  uso se completa.
• Condiciones que describen en que situación debe
  quedar el sistema y su entorno una vez el caso de
  uso haya finalizado.
• La postcondición debería satisfacer las
  necesidades de todo el personal involucrado.

22
Secuencia normal

• Denominado tambien flujo básico o escenario
  principal.
• Secuencia de pasos (interacciones) entre los
  actores y el sistema que describen el camino de
  éxito típico que satisface los intereses del
  personal involucrado.
• Se recomienda que no incluya ninguna condición o
  bifurcación.

23
Secuencias alternas

• Indican todos los otros posibles escenarios tanto
  de éxito como de fracaso que se pueden dar en el
  proceso que cubre el caso de uso.
• Consideran las situaciones anómalas o de error
  que se pueden dar en el escenario principal.
• Un escenario alterno, esta formado por tres
  partes básicamente
• CondiciónExpresa la acción que provoca la
  situación excepcional
• ManejoDescribe la respuesta a la situación de
  excepción
• Terminación de la excepción Indica si después
  del manejo de la excepción, el caso de uso
  continua o se cancela.

24
Otra información

• Frecuencia de realizaciónIndica la frecuencia
  con la que se espera se realice el caso de uso.
• Ayuda a identificar los casos de uso críticos.
• Realizaciones simultáneas Indica cuantas
  instancias de casos de uso debe ser capaz de
  realizar el sistema en forma simultánea.
• Ayuda a identificar procesos que podrían afectar
  el rendimiento.
• Criticidad Para un paso especifico o para todo
  el caso de uso, indica el tiempo máximo que puede
  tardar el sistema en completarla.
• Requisitos especiales

25
Ejemplo
26
Ejemplo
27
Actividades en donde se usan los casos de uso
28
Actividades en donde se usan los casos de uso
29
Actividades en donde se usan los casos de uso
30
Formato(plantillas) de los casos de uso

• Los casos de uso se documentan con texto
  informal.
• Las plantillas permiten describir los casos de
  uso de una manera homogénea, ordenada y
  estructurada.
• Pueden expresarse con diferentes grados de
  detalle, dependiendo de este se pueden
  clasificar
• Formato de alto nivel (breve)
• Formato expandido (completo)

31
Formato de alto nivel

• Describe un proceso muy brevemente.

Caso de uso Nombre del caso de uso Actores
Lista de actores que participan Tipo
(pirmario-secundario-opcional) Descripción
bla bla bla bla.........................
32
Ejemplo formato de alto nivel
33
Formato detallado

• Describe un proceso más en detalle, cuenta con
  una sección destinada al curso normal de los
  eventos, que los describe paso a paso.
• Incluye otras alternativas, puede especificar los
  errores o excepciones que provienen de los
  requisitos del usuario

34
Modelo Formato Detallado
35
Modelo Formato Detallado
36
Otro estilo del formato
37
Otro estilo de formato
38
Plantillas para casos de uso - Ejemplos
39
Relación entre los casos de uso

• Dentro de la secuencia normal o alterna de un
  caso de uso se puede presentar la realización de
  otro caso de uso
• Se especifican dos tipos de relación
• De extensión
• De inclusión
• Se establecen una relación de generalización
• Cuando un caso de uso comprende un grupo comun
  de casos de uso

40
Relaciones de extensión

• Se utiliza para modelar la parte de un caso de
  uso que el usuario puede ver como opcional del
  sistema
• También se puede utilizar para modelar un
  subflujo separado que se ejecuta sólo bajo
  ciertas condiciones.
• Son un caso de uso en sí mismas.
• No necesariamente provienen de un error o
  excepción.

41
Relaciones de uso

• Una relación de inclusión significa que un caso
  de uso base incorpora explicitamente el
  comportamiento de otro caso de uso.
• Los casos usados son casos de uso
• El caso es usado siempre que el caso que lo usa
  es ejecutado.

42
Caso de uso Abstracto

• Cuando se identifique una subsecuencia de pasos
  común a varios casos de uso y con la entidad
  suficiente, se puede extraer y considerar un caso
  de uso para ser extendido o incluido por otros
  casos de uso.
• Se considera abtracto porque no puede realizarce
  por sí mismo, sólo puede realizarce como parte de
  otro.

43
Diagrama de Casos de Uso

• Los diagramas de casos de uso tienen por objeto
  permitir conocer rápidamente los actores externos
  del sistema, y las formas básicas en que lo
  utilizan.
• Explican un conjunto de casos de uso, normalmente
  agrupados por funcionalidad.
• Representan la relación entre actores y casos de
  uso.
• Describen la interacción de los actores con el
  sistema

44
Diagrama de Casos de Uso

• Muestran la granularidad del sistema en piezas de
  funcionalidad reutilizables
• Muestran la interacción de los Actores con la
  funcionalidad del Sistema
• Organizan visualmente los requerimientos del
  usuario
• Permiten certificar contractualmente la
  funcionalidad
• Formalizan el mapa de procesos de negocio

45
Notación
Caso de uso (Ovalo)
Actores (Stick-Man)
Procesar préstamo
46
Elementos de un diagrama de caso de uso

• Un diagrama de casos de uso muestra un conjunto
  de casos de uso, actores y relaciones.

47
Modularización casos de uso

• Los casos de uso se pueden organizar
  especificando relaciones de generalización,
  inclusión, y extensión entre ellos.
• Esta organización evita la redundancia y facilita
  su comprensión
• Permiten determinar comportamientos comunes, así
  como variantes.

48
Modularización casos de uso
49
Relacion de uso - extensión
50
Relaciones de uso - generalización
51
Ventajas de los Casos de Uso

• Lenguaje de comunicación entre usuarios y
  desarrolladores
• Comprensión detallada de la funcionalidad del
  Sistema
• Acotación precisa de las habilitaciones de los
  usuarios
• Trazabilidad desde los requerimientos al código
  ejecutable

52
Ventajas de los Casos de Uso

• Gestión de riesgo para gobernar la complejidad de
  un sistema
• Planificación de iteraciones para su
  implementación
• Estimación precisa del esfuerzo para su
  implementación
• Documentación orientada al usuario Manual de
  Procedimientos

53
Conclusiones

• Trabajar con los casos de uso significa escribir
  texto, por tanto los diagramas y sus relaciones
  son secundarios.
• Los casos NO describen el funcionamiento interno
  del sistema, indican que debe hacer el sistema y
  no el como debe hacerlo.

54
Lecturas Recomendadas
55
Bibliografia

• El Lenguaje Unificado de Modelado UML G. Booch-
  J. Rumbauhugh I Jacobson.
• UML Y PATRONES Introducción al Análisis y Diseño
  Orientado a Objetos Craig Larman
• www.vico.org, www.usecases.org
• Universidad de Sevilla. Departamento de Lenguajes
  y Sistemas Informáticos.Documentación Casos de
  Uso

56
Fin