asi

1. Modelado del Negocio
Diagramas de Casos de Uso del
Negocio y del Sistema

2. Sumario
 Casos de uso
 Casos de uso del Negocio
 Casos de uso del Sistema

3. Casos de uso

4. Casos de uso
 Los Casos de Uso (Ivar Jacobson) describen,
bajo la forma de acciones y reacciones, el
comportamiento de un sistema desde el punto
de vista 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 negocio/sistema
independientes de la implementación.

5. Casos de uso
 Los Casos de Uso cubren la carencia
existente en métodos previos (OMT,
Booch) en cuanto a la determinación de
requisitos.
 Los Casos de Uso particionan el conjunto
de necesidades atendiendo a la categoría
de usuarios que participan en el mismo.
 Están basado en el lenguaje natural, es
decir, es accesible por los usuarios.

6. Casos de uso vs. DFD
• Un CU es una función (servicio o transacción)
atómica ofrecida por el sistema al entorno
(actores).
• Un proceso de un DFD puede ser detallado en un
DFD hijo. Así, el concepto de “explosión de
proceso” sólo se aplica a los DFDs.

7. Casos de uso vs. DFD
• Un CU y un proceso modelan una pieza de
funcionalidad del sistema, pero su especificación es
diferente. En un CU interesa expresar la funcionalidad
mediante la interacción actores – sistema. En un
proceso la funcionalidad se expresa mediante la
transformación que se hace de los flujos de entrada
para producir flujos de salida.
• Un CU en general no modela un particionamiento (o
detalle) funcional interno del sistema pues se concibe
desde la perspectiva de los actores, es decir una visión
externa del sistema. Un DFD, según sea el nivel de
detalle, puede mostrar descomposición funcional
interna del sistema.

8. ¿En qué momento se usa los CU?

9. Casos de uso del Negocio

10. Modelo de Casos de Uso del Negocio
• Describe los procesos de un negocio,
vinculados al campo de acción, y cómo se
benefician e interactúan los socios y clientes
en estos procesos.
Estereotipos
Actor del
Negocio
Caso de Uso
del Negocio

11. Casos de uso

12. Casos de uso

13. Casos de Uso del Negocio (CUN)
Secuencia de acciones, realizadas en el
negocio, que producen un resultado de valor
observable para ciertos actores del negocio.
Desde la perspectiva de un actor individual,
define un flujo de trabajo completo que
produce resultados deseados.
Cliente Vender Pasaje
asociación
Envía y/o recibe mensajes

14. Identificación de los procesos del negocio
(Clasificación)
Servicio de comidaCliente
Marketing
Cliente potencial Experto en
relaciones públicas
ProveedorComprar suministros
(Ejemplo: Restaurante)

15. Identificación de los procesos del negocio
(Agrupamiento de actividades)
Un grupo funcional que responde a
un objetivo de la organización y que
puede involucrar a varias áreas.
Función Proceso de negocio
Distribución • Recepción
• Embarque
Compras • Elección de proveedores
• Pago a proveedores
Personal • Cubrimiento de plantilla
• Capacitación
(Ejemplo: Empresa productora)

16. Identificación de los procesos del negocio
(Objetivos)
(Ejemplo: Empresa de servicio)
“Satisfacer
pedidos de
los clientes”
SubObjetivo 1
...
...
SubObjetivo n
•Atender pedido
de los clientes.
•Solicitra insumo
a los
proveedores.
Cliente Atender pedido
Comprar suministrosProveedor

17. Casos de uso
 Los Casos de Uso (Ivar Jacobson) describen,
bajo la forma de acciones y reacciones, el
comportamiento de un sistema desde el punto
de vista 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 negocio/sistema
independientes de la implementación.

18. Consideraciones acerca de los CUN
• Su nombre y descripción breve son
claras y fáciles de comprender.
• Cada caso de uso del negocio es
completo desde la perspectiva de un
actor externo.
• Cada caso de uso del negocio
normalmente se involucra con, al
menos, un actor.
• Es posible que un caso de uso de
apoyo no interactúe con ningún actor.

19. Diagrama de CUN
Diagrama que representa gráficamente a los
procesos del negocio y su interacción con los
actores del negocio.
Gerente de Relaciones
Públicas
Cliente Servicio de comida
Proveedor
Comprar
suministros
Cliente
potencial
Marketing
(Ejemplo:Restaurant)

20. Convenios en la representación del
Diagrama de CUN
• Un caso de uso puede asociarse con
uno o más actores.
• Un caso de uso se comunica con al
menos un actor, sino hay error en el
modelo, excepto cuando:
• CU abstracto (puede tenerlas).
• CU hijo en una relación de
generalización/especialización si en el padre se
describe toda la comunicación.

21. Navegabilidad en las relaciones de
comunicación entre actores y CUN
• Indica quién inicia la comunicación en la
interacción y se muestra con una flecha.
• Si la fecha apunta al CUN, inicia el actor.
• Si la flecha apunta al actor, entonces inicia el CUN.
• La relación en los dos sentidos se muestra sin
saetas.
• Por cada flecha de comunicación se asume un
mensaje de retorno.
Convenios en la representación del
Diagrama de CUN

22. Casos de uso
 Los Casos de Uso cubren la carencia
existente en métodos previos (OMT,
Booch) en cuanto a la determinación de
requisitos.
 Los Casos de Uso particionan el conjunto
de necesidades atendiendo a la categoría
de usuarios que participan en el mismo.
 Están basado en el lenguaje natural, es
decir, es accesible por los usuarios.

23. Estructuración de los CUN
• Identificar los comportamiento en
CUN que necesitan considerarse como
casos de uso abstractos (casos de uso
que no se instancian por si solos y que
describen comportamiento reutilizable y
compartido).
• Encontrar actores del negocio que
definan roles compartidos por varios
actores del negocio.

24. Estructuración de los CUN
• Relación de inclusión
• Relación de extensión
• Relación de Generalización-especialización

25. Relación de inclusión <include>
Una relación que especifica un
comportamiento definido para el CU de
inclusión que se inserta explícitamente dentro
del comportamieto definido para el CU base.
El workflow del proceso entero está en el
caso de uso base y el (los) caso(s) de uso
incluido(s).

26. Se justifica cuando:
• Se puede reusar en otros CUN el
comportamiento incluido en el caso de
uso base, o
• Simplifica la comprensión del caso de
uso base.
Relación de inclusión <include>

27. Casos de uso vs. DFD
• Un CU es una función (servicio o transacción)
atómica ofrecida por el sistema al entorno
(actores).
• Un proceso de un DFD puede ser detallado en un
DFD hijo. Así, el concepto de “explosión de
proceso” sólo se aplica a los DFDs.

28. Venta de
producto
<<include>>
Verificar
política de
descuento
Cliente
PARTICIONAR
Es un CU de apoyo que
no se relaciona con
actores
Relación de inclusión <include>.
(Ejemplo: Empresa de servicios)

29. Relación de extensión <extend>
Una vez definido el workflow de un caso
de uso del negocio, se puede encontrar
alguna conducta opcional u optativa.
Tiene sentido definir un nuevo CU cuando:
 Modelar un workflow complejo o un
subflujo separado, que raramente ocurre u
ocurre bajo ciertas condiciones.
 Flujos distintos que pueden ejecutarse en
base a la selección del actor.

30. Pasajero
Manejo Especial de Equipaje
<<extend>>
Check-In Individual
Relación de extensión <extend>.
SOLO PARAALGUNOS PASAJEROS HAY QUE
IR AL COUNTER DE EQUIPAJE ESPECIAL
(Ejemplo: Aduana)

31. Generalización - especialización
Se usa para mostrar worksflows que
comparten estructuras, propósito y
comportamiento.
Un caso de uso padre se puede
especificar en uno o más casos de
uso hijos que representan
formularios más especificos del
padre.

32. Se utiliza para:
Para no tener que describir el mismo flujo
varias veces, se puede colocar el
comportamiento común en un CUN.
Generalización - especialización
Se puede afirmar que constituyen tipos de
procesos. Generalmente tienen un
comportamiento similar pero con diferencias
sustanciales que provocan que sean
considerados CUN diferentes.
Se recomienda usar cuando:

33. Generalización – especialización.
Realizar
visitas
Realizar Visitas a
clientes potenciales
Realizar visitas a
clientes registrados
Jefe zonal
(Ejemplo: Vendedores ambulantes)

34. Casos de uso vs. DFD
• Un CU y un proceso modelan una pieza de
funcionalidad del sistema, pero su especificación es
diferente. En un CU interesa expresar la funcionalidad
mediante la interacción actores – sistema. En un
proceso la funcionalidad se expresa mediante la
transformación que se hace de los flujos de entrada
para producir flujos de salida.
• Un CU en general no modela un particionamiento (o
detalle) funcional interno del sistema pues se concibe
desde la perspectiva de los actores, es decir una visión
externa del sistema. Un DFD, según sea el nivel de
detalle, puede mostrar descomposición funcional
interna del sistema.

35. Generalización entre Actores. Ejemplo
(Ejemplo:Hospital)
Cliente
Despacharmedicamentos
enfarmacia
Administrador
Hospitalización
AsignarcamasAdministrador
ConsultaExterna
Asignarcitas

36. Realizaciones de CUN
Muestran la manera en que colaboran
los trabajadores y entidades de negocio
para ejecutar el proceso. Se
documentan con:
Diagramas de actividad
Descripción textual
 Diagramas de clases
 Diagramas de secuencia

37. • nombre del caso del uso del negocio
• actores
• propósito
• resumen
• flujo de trabajo
- Básico (normal)
- Curso Alterno
• otras secciones
• Prioridad
• Mejoras
Descripción textual de los
Casos de Uso

38. Nombre Atender pedido
Actores CLIENTE
Propósito Analizar viabilidad del Pedido del Cliente y ordenar su producción.
Resumen: El caso de uso se inicia cuando el Cliente envía una orden de pedido de productos. El proceso da curso
al pedido, analizando la posibilidad de satisfacerlo. El caso de uso finaliza cuando se le comunica al cliente el
resultado final del análisis de su pedido.
CURSO NORMAL DE EVENTOS
Acción del actor Respuesta del proceso de negocio
1. El Cliente envía una orden de
pedido que incluye fecha de
solicitud, datos del cliente y
productos solicitados.
9. El Cliente recibe la
comunicación del resultado
final del análisis del pedido.
2.El Comercial recibe el pedido del cliente por teléfono o correo ordinario de la
empresa.
3.El Comercial revisa el pedido, comienza su procesamiento, y lo envía al Jefe
Técnico.
4.El Jefe Técnico analiza la viabilidad de cada producto pedido por separado:
Si el producto pedido está en Catálogo, se acepta su fabricación.
5. El Jefe Técnico informa al Comercial la aceptación o rechazo de cada
producto.
Si el pedido o parte de éste es aceptado pasar a 6
Si el pedido es rechazado pasar a 8
6.El Jefe Técnico crea una orden de trabajo para cada producto del pedido, a
partir de la plantilla de fabricación y las envían al Jefe de Producción, quedando
pendiente su lanzamiento.
7. El Jefe de Producción planifica la producción de las órdenes de trabajo
recibidas.
8. El Comercial informa al cliente.
Cliente Atender pedido

39. ¿En qué momento se usa los CU?

40. Casos de uso del Sistema

41. Casos de uso del sistema
Artefacto narrativo que describe, bajo la forma de
acciones y reacciones, el comportamiento del sistema
desde el punto de vista del usuario (Jacobson).
Descripciones de la funcionalidad del sistema
independientes de la implementación.
Establece un acuerdo entre clientes y
desarrolladores sobre las condiciones y
posibilidades (requisitos) que debe
cumplir el sistema.

42. Casos de uso del sistema
Descripciones de la funcionalidad del sistema
independientes de la implementación.

43. Es el proceso de averiguar, por lo general en
circunstancias difíciles, lo que se debe construir.
Los usuarios deben saber lo que quieren
•Cada uno sabe lo que hace, pero
ninguno tiene una visión global
•No saben qué parte de su trabajo puede
transformarse en software..
•No saben cómo puede hacerse más eficiente
la operación en su conjunto.
Definición de Requisitos

44. Requisito funcional
“Una capacidad o condición que el
sistema cumplirá”
Requisitos
Desarrolladores
Clientes y Usuarios

45. (Funcional)
• Objetivos y metas para un sistema.
• Si están presentes  Cliente satisfecho
(No Funcional)
• Implícitos al sistema.
• Puede que el cliente no los declare,
pero si no están se siente
insatisfecho.
(Funcional y no
funcionales)
• Características que van más allá de la
expectativas del cliente.
Clasificación de los requisitos
funcionales

46. Identificación de requisitos
funcionales a partir del modelo
del negocio
•Descripciones textuales.
•Diagrama de clases del
modelo de objetos del
negocio.
•Diagrama de actividades.
Actividades que serán
automatizadas

47. Atender proyecto nuevoProyectista
(Ejemplo: Empresa constructora)
Diagrama de casos de uso
del negocio

48. Diagrama de Actividad.

49. Requisito funcional
• Registrar características de un
proyecto
• Analizar viabilidad económica
1.1 Evaluar factibilidad económica
1.2 Registrar resultados de la
evaluación.
3. Analizar viabilidad técnica
1.1 Evaluar factibilidad técnica
1.2 Registrar resultados de la
evaluación.
4. Registrar aprobación/rechazo de un
proyecto

50.  No son parte del sistema
 Puede intercambiar información con el sistema.
 Puede ser un recipiente pasivo de información.
Actores

51. Actores

52. Identificación de los CU del sistema a
partir del modelo del negocio
CASO DE USO = PROCESO QUE OBTIENE
UN RESULTADO DE
VALOR

53. • Decidir si el trabajador del negocio va a
utilizar el sistema de información.
• De ser así, identificar un actor en el
modelo de casos de uso del sistema.
• Para cada caso de uso del negocio en el
que participe el trabajador del negocio,
crear un caso de uso del sistema.
• Repetir estos pasos para todos los
trabajadores del negocio.
Comenzar con los trabajadores del
negocio. Para cada uno:
¿Cómo identificar los casos de uso
del sistema?

54. Ejemplo
Casos de uso
Económico
Evaluar un proyecto
económicamente
Evaluar un proyecto
técnicamente
Jefe de obra
Aprobar/rechazar proyecto

55. Casos especiales: Manejo del tiempo
En algunos sistemas se tienen actividades
que se ejecutan periódicamente, como por
ejemplo, el cálculo de intereses de los
clientes de un banco se realizan todas la
noches. Para modelar esto se puede
realizar lo siguiente:
Casos de uso
Calcular intereses
Reloj

56. Perfeccionar la definición de
casos de uso
CASOS
MÚLTIPLES
DE USO
GENERALIZACIÓN/
ESPECIALIZACIÓN
DE CASOS DE USO
GENERALIZACIÓN/
ESPECIALIZACIÓN
DE ACTORES

57.  Se duplica comportamiento en otros CU.
 Un CU es complejo y largo, y su separación
facilita que sean manejables y comprensibles.
¿Cuándo escribir un caso de
uso independiente?
 Crear casos de uso independientes
(Representar relaciones <<include>> o
<<extend>> entre los casos de uso).
 Reescribir los casos de uso de las actividades
ramificadas.

58. Ejemplo
Relación de inclusión
• Casos de uso que tienen una parte común en sus
funcionalidades.
Pagar un servicio
por Internet
Usuario
Chequear pagos
realizados
Verificar
permiso
<<include>>
<<include>>

59. Ejemplo
Relación de inclusión
• Se observa una relativa independencia en una parte del
flujo de trabajo que se describe, aún cuando no se
reutilice. De ese subproceso solo interesa el resultado.
Pagar un servicio
por Internet
<<include>>
Usuario
Redefinir deuda
pendiente

60. Ejemplo
Relación de extensión
• Comportamiento opcional.
Analizar
discrepancias
<<extend>>
Especialista
del banco
Enviar e-mail a
superior
<<extend>>
Resolver
discrepancia

61. Ejemplo
Relación de extensión
• Comportamiento que es ejecutado solamente bajo
ciertas condiciones.
Pagar un servicio
por Internet
<<extend>>
Especialista
del banco Buscar cuentas
alternativas

62. Ejemplo
Relación de extensión
• Flujos distintos y diferentes que pueden ejecutarse
sobre la base de la selección del actor.
Chequear pagos
realizados
<<extend>>
Usuario
Reportar
discrepancias

63. Ejemplo
Casos de uso múltiples
Verificar permiso Redefinir deuda
Reportar
incongruencias
Usuario Pagar un servicio por
internet
<<include>>
<<include>>
<<extend>>

64. Ejemplo
Generalización/Especialización
entre casos de uso
Pagar
Pagar en
efectivo
Pagar con
tarjeta de crédito
Usuario

65. Colocar
Llamada
Colocar Llamada
Local
Colocar Llamada
Larga Distancia
Generalización/Especialización
entre casos de uso

66. Colocar Llamada Local
1.La persona (caller) levanta el auricular
2.El sistema presenta el tono de discar
3.La persona disca un dígito
4.El sistema quita el tono de discar
5.La persona introduce el resto del número
6.El sistema analiza el número
7.El sistema encuentra la parte
correspondiente
8.El sistema conecta las partes
9.Las partes se desconectan

67. Colocar Llamada de Larga Distancia
1.La persona (caller) levanta el auricular
2.El sistema presenta el tono de discar
3.La persona disca un dígito
4.El sistema quita el tono de discar
5.La persona introduce el resto del número
6.El sistema analiza el número
7.El sistema envía el número a otro
sistema
8.El sistema conecta las líneas
9.Las partes se desconectan

68. Descripción del caso de uso Colocar Llamada
Segmento No.1. Proceso inicial.
1. La persona que llama (caller) levanta el auricular.
2. El sistema presenta el tono de discar.
3. La persona que llama disca un dígito.
4. El sistema quita el tono de discar.
5. La persona que llama introduce el resto del número.
6. El sistema analiza el número.
Segmento No.2. Proceso especializado de conexión.
Segmento No.3. Desconexión.
1. Las partes se desconectan.

69. Descripción de caso de uso COLOCARLLAMADA
LOCAL
Segmento No.2. Proceso especializado de conexión.
1. El sistema encuentra la parte correspondiente.
2. El sistema conecta las partes.
Descripción de caso de uso COLOCARLLAMADA
DE LARGADISTANCIA
Segmento No.2. Proceso especializado de conexión.
1. El sistema envía el número a otro sistema.
2. El sistema conecta las líneas.

70. Ejemplo
Generalización/Especialización
entre actores
Chequear
estado de una
cuenta bancaria
Consultor
de cuentas
Especialista
del banco
Usuario
Chequear pagos
realizados
Analizar
discrepancias

71. Descripción de los casos de uso en
formato de alto nivel
Caso de uso: <Nombre>
Actores: <Nombre de los actores>
Descripción: <Frases que describan las
acciones indicando los actores
involucrados, debe quedar claro
cómo se inicia y termina el
proceso y de que forma
intervienen los actores>
Referencias: <Listado de requerimientos y
casos de uso asociados,
indicando tipo de asociación
(include o extend)>

72. Casos de uso del Negocio

73. Ejemplo
Descripción de casos de uso
Caso de uso: Aprobar/rechazar un proyecto
Actores: Jefe de obra
Descripción:
El caso de uso se inicia cuando se han realizado las evaluaciones
técnica y económica de una propuesta de un proyecto y el Jefe de obra
debe valorar si se aprueba o no su ejecución. El sistema debe permitir
ver los resultados de estas evaluaciones y permitir que se registre las
conclusiones del Jefe de obra (aprobar/rechazar y alguna otra
consideración que justifique su decisión, culminando la ejecución del
caso de uso.

74. Ejemplo
Descripción de casos de uso
Referencias R4
Precondiciones Existan proyectos ya evaluados técnica y
económicamente y estén pendientes de aprobación o
rechazo
Poscondiciones Se cambia el estado del proyecto a rechazado o
aprobado y se asocian las causas que motivaron la
decisión
Requerimientos
especiales
-

75. • Cada forma en que los actores usan el
negocio/sistema se representa con un caso
de uso.
• Los CU son fragmentos de funcionalidad
que el negocio/sistema ofrece para aportar
un resultado de valor para los actores.
• Un CU especifica una secuencia de acciones
que el negocio/sistema puede llevar a cabo
interactuando con sus actores, incluyendo
alternativas dentro de la secuencia.
Resumiendo...

76. •Un caso de uso entrega un resultado que añade
valor a un actor en concreto.
Al actor iniciador
Evita CU muy pequeños
A usuarios
individuales reales
Evita CU muy grandes
Resumiendo...

77. Modelo de Casos de Uso del Negocio
• Describe los procesos de un negocio,
vinculados al campo de acción, y cómo se
benefician e interactúan los socios y clientes
en estos procesos.
Estereotipos
Actor del
Negocio
Caso de Uso
del Negocio

78. – Comunicación
Actor
C aso deU so
– Inclusión
– Extensión
– Herencia
Caso de Uso Origen C aso deU so Desti no
<<include>>
Caso de Uso Origen Caso deUso Destino
<<extend>>
Caso de UsoHijo Caso de Uso Padre
Tipos de relaciones en los DCU
Resumiendo...

79. Los casos de uso describen los
procesos de principio a fin.
Representar pasos
como CU
Error común en los CU
Se nombran: Utilizando verbos fuertes en
infinitivo.
Imprimir Recibo
Es un paso del
proceso más amplio
“Comprar Productos”
Resumiendo...

80. Describir los cursos
alternos dentro de
los cursos
normales
Error común en los CU
Se debe definir una
subsección dentro de
la sección de cursos
alternos para cada
curso alterno.
Resumiendo...

81. Acción del actor
1 El usuario suministra su
identificación
3 Actualiza los datos de la
nueva factura
5 El usuario concluye la
operación.
Respuesta del sistema
2 Localiza la identificación
del usuario. Si no existe el
usuario, ejecutar caso de
uso “Registrar Usuario”.
4 Registra los datos de la
factura.
Caso de uso: Actualizar Factura
Presencia de curso alterno
dentro del curso normal
Resumiendo...

82. Describir de manera insuficiente el caso
de uso en aras de “ganar tiempo”
Error común en los CU
Resumiendo...