Este documento describe el Rational Unified Process (RUP) y el Lenguaje Unificado de Modelado (UML). RUP es una metodología iterativa e incremental para el desarrollo de software que utiliza UML para la modelación. UML es un lenguaje estándar para la modelación orientada a objetos que permite visualizar, especificar y documentar sistemas de software. El documento explica las fases y flujos de trabajo de RUP así como los diagramas y artefactos de UML para la modelación del negocio, requerimientos, análisis, diseño e implement

1. Desarrollo de Aplicaciones con RUP y UML

2. Introducción

3. I. RATIONAL UNIFIED PROCESS
¿Qué es RUP?
Es una metodología
RUP es un proceso de desarrollo de software que forma
disciplinada de asignar tareas y responsabilidades en una
empresa de desarrollo (quién hace qué, cuándo y cómo).
¿Qué es UML? ( versión 2.3 )
UML tiene por objetivo ser un lenguaje de modelado de
proposito general.
No tiene propietario y esta basado en el común acuerdo de la
gran parte de la comunidad informática.
¿Qué es Rational Rose?
Es una Herramienta ( versión 7.0 )

4. II. FASES PRINCIPALES DEL CICLO DE VIDA
ITERATIVO E INCREMENTAL
Flujos de Trabajo
de Ingeniería
Flujos de Trabajo
de Apoyo

5. III. ESTRUCTURA DEL RUP
El proceso puede describirse en dos dimensiones, o a lo
largo de dos ejes:
El eje horizontal representa tiempo y muestra el
aspecto dinámico del proceso, expresado en términos de
ciclos, fases, iteraciones, y metas.
El eje vertical representa el aspecto estático del
proceso; como está descrito en términos de actividades,
artefactos, trabajadores y flujos de trabajo.

6. ¿Qué es UML?

UML = Unified Modeling Language

Un lenguaje de propósito general para el
modelado orientado a objetos

UML combina notaciones provenientes desde:
Modelado Orientado a Objetos ( mejora la
captura de requerimientos)
 Modelado de Datos ( base de datos )
 Modelado de Componentes ( piezas de
software )


7. ¿Qué es UML?
El Lenguaje Unificado de Modelado es un lenguaje gráfico
para visualizar, especificar, construir y documentar los
artefactos de un sistema con gran cantidad de software.
UML proporciona una forma estándar de escribir los planos de
un sistema, cubriendo tanto las cosas conceptuales, tales como
procesos del negocio y funciones del sistema, como las cosas
concretas, tales como las clases escritas en un lenguaje de
programación específico, esquemas de bases de datos y
componentes software reutilizables.

8. UML AGLUTINA ENFOQUES OO
Booch
Rumbaugh
Jacobson
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly
Singleton classes
Wirfs-Brock
Fusion
Operation descriptions,
message numbering
Responsabilities

9. Modelo del
Negocio

10. ¿POR QUÉ MODELAMOS?
• Construimos modelos para: comunicar, visualizar y controlar la
arquitectura, comprender mejor el sistema y para controlar los
riesgos.
• La importancia de modelar
• Principios del modelado
• Modelado orientado a objetos

11. ¿POR QUÉ MODELAMOS?
MODELO DE DATOS
Entidad : Empleado
codigo
nombre
dni
fechaIngreso
telefono
direccion
cargo
sueldo
MODELO DE OBJETOS
Clase : Empleado
Persona
Direccion
ATOMIZACION
COMPONENTES
REUTILIZABLES
HOMOGENEIZACION
Empleado
Telefono
Cargo
UNIFORMIZACION
ENTE CON DATOS HETEROGENEOS ENTES CON DATOS HOMOGENEOS

12. LA IMPORTANCIA DE MODELAR
• ¿Qué es un modelo? Un modelo es una simplificación de la realidad.
• ¿Por qué modelamos? Construimos modelos para comprender mejor el
sistema que estamos desarrollando.
• A través del modelado conseguimos: visualizar cómo es, especificar la
estructura o el comportamiento, guías para la construcción,
documentar.
•Construimos modelos de sistemas complejos porque no podemos
comprender en sistema en su totalidad.
•Construimos La palabra clave aquí es “formal”. En realidad, incluso en
el proyecto más simple los desarrolladores hacen algo de modelado, si
bien muy informalmente.

13. PRINCIPIOS DEL MODELADO
• Primero: La elección de qué modelos crear tiene una profunda
influencia sobre cómo se acomete un problema y cómo se da
forma a una solución
• Segundo: Todo modelo puede ser expresado a diferentes niveles
de precisión.
• Tercero: Los mejores modelos están ligados a la realidad.
• Cuarto: Un único modelo no es suficiente. Cualquier sistema no
trivial se aborda mejor a través de un pequeño conjunto de
modelos casi independientes.

14. Modelado Orientada a Objetos
Caracteriza la estructura estática de los objetos, en términos de grupos de
objetos análogos (clases), la herencia y relaciones de importancia con otros
objetos.
Pasos para el modelamiento:
1ro. Identificación de objetos y clases:
 Cosas tangibles, concretas; e intangibles.
 Funciones desempeñadas por personas u otros.
 Incidencias, ocurrencias y eventos que suceden.
 Interacciones “transacciones”.
Ej. Compra (comprador, vendedor y producto comprado).

15. MODELADO ORIENTADA A OBJETOS
2do. Identificación de atributos:
 ¿ Qué características posee cada objeto?
 ¿Qué información se necesita conocer, proposito de una
entidad?
3ro. Identificación de Relacionamiento:
 Relaciones
 Multiplicidad o cardinalidad.

16. BUSINESS MODELING AND SYSTEM DEVELOPMENT
Use-Case Business
Model
Object Model
Business Modeling
Use-Case
Model
Analysis
Model
Design
Model
Deployment
Model
Implementation
Model
System Development
Business modeling results can be used as input to
system development.
Test
Model

17. MODELO DE DESARROLLO OO ITERATIVO E
INCREMENTAL
MOD. NEG. OO
ANALISIS OO
Clases
DISEÑO OO
y
Objetos
N VECES
IMPLEMENTACION OO
INTEGRACION OO

18. CICLO DE VIDA DE LOS PROYECTOS
ITERATIVO E INCREMENTAL
“Iteración” se refiere a un paso en el ciclo de vida, formado por un
conjunto de actividades, con un plan y criterios de evaluación, que
acaba en una versión.
Una iteración resulta en un “incremento” o crecimiento del proyecto
general.
El Proceso de Desarrollo de Software Unificado sugiere que se itere
a través del ciclo produciendo actualizaciones incrementales.
Cada incremento mejora, corrige y se construye sobre los
incrementos previos.

19. CICLO DE VIDA DE LOS PROYECTOS
ITERATIVO E INCREMENTAL
En cada iteración se deben hacer las siguientes actividades:
Seleccionar y analizar los casos de uso relevantes
Crear un diseño utilizando la arquitectura elegida
Implementar el diseño en componentes
Verificar que los componentes satisfacen los casos de uso
Cuando una iteración alcanza sus objetivos, se procede con la
siguiente iteración

20. FASES PRINCIPALES DEL CICLO DE VIDA
ITERATIVO E INCREMENTAL
•
•
Fases
– Iniciación: la idea inicial se lleva al punto de estar suficientemente
bien fundamentada para garantizar la entrada en la fase de
elaboración.
– Elaboración: se definen la visión del producto y su arquitectura.
Se expresan con claridad los requisitos del sistema, se priorizan se
usan para producir una base arquitectónica
– Construcción: el software se lleva desde una base arquitectónica
ejecutable hasta su disponibilidad para los usuarios.
– Transición: el software es puesto en manos de los usuarios, se
erradican errores y se añaden
características nuevas.
Cada fase contiene una o más iteraciones

21. Rational
Unified
Process
El proceso para
desarrollo de Software

22. Rational Unified Process (RUP)
• Captura varias de las mejores prácticas en el desarrollo
moderno de software en una forma que es aplicable para un
amplio rango de proyectos y organizaciones.
• Es una guía de cómo utilizar de manera efectiva UML.
• Provee a cada miembro de un equipo un fácil acceso a una
base de conocimiento con guías, plantillas y herramientas
para todas las actividades críticas de desarrollo.
• Crea y mantiene modelos, en lugar de enfocarse en la
producción de una gran cantidad de papeles de
documentación.

23. Estructura de RUP Cont.
Fases
Flujos de Trabajo de Procesos
Inicio
Elaboración
Construcción
Transición
Modelación de Negocios
Requerimientos
Análisis y Diseño
Contenido
Implementación
Prueba
Implantación
Flujos de Trabajo de Soporte
Admin. Configuración
Administración
Ambiente
Iteración(es)
Preliminar
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iteraciones
Iter.
#m
Iter.
#m+1

24. Flujos de Trabajo y Modelos
Disciplinas
Business
Modeling
Modelos
Realized
By
Business UseCase Model
Analysis &
Design
Implementation
Realized By
Requirements
Implemented
By
Verified By
Use-Case
Model
OK
OK
B
B
Test
B
B
Business
Object Model
Automated
By
Fail
Design Model Implementation
Model
Test Model

25. El Proceso Unificado
Fases
Flujos de Trabajo de Procesos
Inicio
Elaboración
Construcción
Transición
Modelación de Negocios
Requerimientos
Análisis y Diseño
Implementación
Prueba
Implantación
Flujos de Trabajo de Soporte
Workflow de
Iteración
Admin. Configuración
Administración
Ambiente
Iteración(es)
Preliminar
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iteraciones
Iter.
#m
Iter.
#m+1

26. Modelo del Negocio
Objetivo:
Comprender el conjunto de procesos de negocio que
tienen lugar dentro de una empresa, como paso previo
a establecer los requisitos del sistema a desarrollar.
¿Cómo consigue la empresa sus objetivos?
Reingeniería.

27. Como ...?
• Identificar y delimitar los procesos de negocio según los
objetivos de la organización.
• Definir un caso de uso del negocio para cada proceso
del negocio, utilizando un diagrama de casos de uso del
negocio para mostrar el contexto y los límites de la
organización bajo estudio.
• Identificar los roles implicados en los diferentes
procesos del negocio y describirlos en un diagrama de
roles.

28. Propósito
• El modelo del negocio “no implica” que se hagan
cambios en la forma como se hace el negocio.
Simplemente es una técnica para documentar
visualmente lo que su negocio hace.
• Comprender los problemas actuales de la organización y
su impacto.

29. Propósito
• Comprender la estructura y la dinámica de la organización
para la que se desarrolla el proyecto.
• Asegurar que los clientes, usuarios finales y desarrolladores
tengan un entendimiento común de la organización. Visión
compartida.
• Obtener, de forma preliminar, los requerimientos del
sistema que necesita la organización.

30. Propósito
• El modelo del negocio es una técnica que permite
responder algunas preguntas críticas:
 ¿Cómo sabe usted que ha identificado todos los casos de
uso del sistema (funcionalidades del sistema).?
 ¿Qué hacen los trabajadores (usuarios) antes de usar el
sistema?
 ¿Qué valor del negocio brinda el sistema?
 ¿Cuál es el sistema de negocio (proceso) que el sistema
computarizado apoya?

31. Propósito
• ¿Cómo aseguramos que el sistema tendrá valor si no
entendemos como, quién y en que circunstancias se usará?
• Para asegurar que estamos construyendo soluciones
orientadas al cliente (es decir sistemas de información que
satisfacen a nuestros clientes) no debemos pasar por alto:
– El ambiente en el que estos sistemas trabajarán,
– Los roles y responsabilidades de los empleados que usan
el sistema,
– Las "cosas" que son manejadas por el negocio,

32. Beneficios
• Uno de los grandes beneficios de modelar el negocio es
mejorar la obtención de requisitos del sistema, requisitos
que conducirán a la creación de sistemas de información
que realmente encajen en la organización y sean usados
por usuarios finales.

33. Problema
• Un problema que frecuentemente se produce la dificultad
para que los analistas del negocio comuniquen sus
resultados eficazmente a los participantes del equipo.
• Dicho problema se puede resolver usando el UML.

34. Modelado del Negocio
• Artefactos del modelo del negocio
Modelo de Casos de
Uso del Negocio
Actores del
Negocio
Especificación de
Casos de Uso del
Negocio
Casos de Uso
del Negocio
Modelo de Objetos
del Negocio
Trabajadores
del Negocio
Entidades del
Negocio
Visión
Glosario de
Términos

35. Notación UML Para el Modelo del
Negocio
Icono
Nombre
UML Definición
Actor del
Negocio
Alguien o Algo, fuera del negocio que
interactúa con el negocio.
Trabajador del
Negocio
Rol o conjunto de roles dentro del negocio.
Un trabajador del negocio interactúa con
otros trabajadores del negocio y manipula
entidades del negocio.
Entidad del
Negocio
una "cosa" manipulada
trabajadores del negocio.
Caso de uso del
negocio
Una sucesión de acciones que un negocio
ejecuta para producir un resultado de valor
observable a un actor de negocio particular.
(En este caso, sinónimo de proceso del
negocio)
o
usada
por

36. Diagramas UML (M. Negocio)
• Cada diagrama de UML proporciona una vista diferente del
negocio:
– Diagramas de casos de uso describen el contexto del negocio.
– Diagramas de actividad describen las conductas en el
negocio, o el flujo de trabajo del negocio.
– Diagramas de clase que describen la estructura estática del
negocio.
– Diagramas de interacción describen la interacción dinámica
entre los empleados y las cosas que ellos manipulan.

37. Actores del Negocio
Negocio
Organización
Mundo Exterior

38. Actores del Negocio
• ¿Dónde encontrar a los actores del negocio?
–
–
–
–
–
–
–
–
Clientes.
Socios.
Proveedores.
Autoridades.
Entidades legales y reguladoras.
Sucursales.
Dueños e inversionistas
Sistemas informáticos fuera del negocio con los que se
interactúa.
– Otras partes de la organización.

39. Actores del Negocio
• La lista de los actores del negocio se realiza
especificando:
– Nombre del actor:
• Debe dar idea clara de la función que realiza o
desempeña.
• Sustantivo con letra inicial mayúscula.
– Descripción:
• Describir la función que realiza fuera del negocio y la
responsabilidad que tiene para el negocio.

40. Trabajador del Negocio
Negocio
Organización
Mundo Exterior

41. Trabajador del Negocio
• ¿Dónde encontrar trabajadores del negocio?
– Roles dentro del negocio.
– Personas que ejecutan los proceso o actividades del
negocio.
– Hardware o sistemas informáticos dentro del negocio con
los que se intercambia información directamente.

42. Trabajador del Negocio
• La lista de los trabajadores del negocio se realiza
especificando:
– Nombre del trabajador:
• Debe dar idea clara de la función que realiza o
desempeña.
• Sustantivo con letra inicial mayúscula.
– Descripción:
• Describe la función que realiza dentro del negocio y su
responsabilidad.

43. Caso del Uso del Negocio
Negocio
Organización
Mundo Exterior

44. Caso del Uso del Negocio
• ¿Dónde encontrar casos de uso del negocio?
– Principales procesos del negocio.
– Servicios principales para el cliente.
– Procesos de servicio a otras entidades.

45. Caso del Uso del Negocio
• La lista de los casos del negocio se realiza especificando:
– Nombre del caso de uso:
• Debe dar idea clara de las acciones a realizar.
• Se concibe desde el punto de vista del actor.
• Debe ser un verbo o una frase verbal en infinitivo.
– Descripción:
• Se indica el objetivo fundamental del caso de uso

46. Entidad del Negocio
Negocio
Organización
Mundo Exterior

47. Entidad del Negocio
• Una entidad del negocio (business entity) representa a un
conjunto de información con propiedades, comportamiento y
semántica similares y que es manipulado o manejado por
trabajadores del negocio.
• Ejemplo:
– Factura.
– Solicitud de pago.
– Tarjeta de crédito.
Factura

48. Entidad del Negocio
• ¿Dónde encontrar entidades del negocio?
–
–
–
–
–
–
–
Áreas, departamentos, direcciones.
Objetos físicos.
Transacciones.
Personas.
Sistemas externos.
Organizaciones.
Socios.

49. Entidad del Negocio
• La lista de las entidades del negocio se realiza
especificando:
– Nombre de la entidad:
• Debe dar idea clara de la función que realiza o
desempeña.
• Sustantivo con letra inicial mayúscula.
– Descripción:
• Describir la función que realiza dentro del negocio.

50. Diagrama de Casos de uso
del Negocio
• Un diagrama de Casos de Uso del negocio representa
visualmente la interacción entre los servicios primarios (casos
del uso del negocio) que su negocio proporciona y aquellos a
quienes los servicios se proporcionan (los actores del
negocio).

51. Diagramas de clase (objetos)
• Los diagramas de clase del negocio documentan la estructura
interior del negocio.
• Cada clase en este diagrama o representa a un trabajador del
negocio (el empleado del negocio) o a una entidad del
negocio (una 'cosa' que el negocio manipula).

52. D. Objetos “Caso Cuentas”
verifica
Documento Indentidad
verifica
Boleta incripción
Especialista en Cuentas
Genera
(from Actores y Trabajadores)
Abre
Tarjeta de Ahorro
Conjunta
Cuenta
Individual
Indistinta

53. Diagrama de Casos de Uso
Los diagramas de casos de
uso representan, en sus
dos versiones, diferentes
conceptos:
Los casos de uso de
negocio representan los
procesos del negocio que
son usados por los roles
del negocio.
los casos de uso de
sistema
describen
un
sistema desde el punto de
vista del usuario.
Atender Reservas
Caso de Uso de Negocio
Cliente
Atender Bar
Caso de Uso de Sistema
Programar entrega
Despachador

54. “Caso Salsa Dance”
Lea y analice con detenimiento el caso de estudio propuesto y elabore los siguientes diagramas:
Diagrama CUN
Actores del negocio
Diagrama
Modelo de objeto de Negocio
Trabajadores del negocio
Entidades del negocio
Diagrama
Caso de estudio Academia de Baile “Salsa Dance”
La academia de baile “Salsa Dance” ofrece a sus clientes lecciones privadas y por grupos. Se dan lecciones privadas
todo el día, y las lecciones por grupo se ofrecen en las noches. Los estudiantes que reciben lecciones privadas
algunas veces provienen de lecciones en grupo y los grupos también se pueden haber formado por estudiantes que
han tomado lecciones privadas, en este momento no se puede determinar que cambio es mas frecuente pero no se
han venido incrementando, lo que mas preocupa a la academia es que después de tres cambios un cliente
normalmente abandona la academia.
La academia está interesada en determinar las razones por las que un estudiante pasa entre lecciones de grupo a
privadas y viceversa, para ello cada vez que un estudiante que esta recibiendo un tipo de lección decide cambiar a
otro tipo, se le toma un cuestionario.
La academia emplea dos tipos de instructores de tiempo completo y por horas, de los últimos se debe tener su
disponibilidad horaria. Los instructores son asignados a lecciones privadas como a lecciones por grupo
indistintamente.
Además de las lecciones, la academia auspicia dos noches en la semana de concursos de baile. El propósito de los
concursos es dar a los estudiantes un lugar para que practiquen sus habilidades y también para buscar nuevos
valores.
A la academia le gustaría desarrollar un sistema de información para registrar a los estudiantes y las clases que han
tomado y registrar los resultados de los cuestionarios que son tomados cada vez que un estudiante cambia de tipo de
lección. Los administradores también desearían saber cuántos y cuáles tipos de lecciones ha enseñado cada
instructor. Finalmente, es deseable registrar los concursos en los que ha participado cada estudiante y el puesto
obtenido.

55. MODELADO DEL NEGOCIO
“Caso Salsa Dance”
I. Evaluar la organización
Organización:
Nombre de la Organización : Escuela Salsa Dance
II. Modelo de Casos de Uso del Negocio
1. Lista de los actores del negocio
Cliente
Estudiante
2. Lista de los casos de uso del negocio
Inscribir
Dar Lecciones
Programar Horario
Cambiar Modalidad
Concursar
Encuestar
3. Diagrama de casos de uso del negocio
( Rational Rose )

56. RATIONAL ROSE

57. MODELADO DEL NEGOCIO “Caso Salsa Dance”

58. MODELADO DEL NEGOCIO “Caso Salsa Dance”

59. MODELADO DEL NEGOCIO “Caso Salsa Dance”
Ver / ocultar documentación
o Ir a diagramas de clase, de interacción, de componentes, de estado, de despliegue, de caso de uso. Al
activar estos botones se muestra una lista con los diagramas del tipo correspondiente, para seleccionar cuál
se quiere visualizar.
o Ir al diagrama padre
o Ir al diagrama anterior
o Aumentar zoom, disminuir zoom
o Ajustar a ventana, deshacer ajustar
o Ayuda general

60. MODELADO DEL NEGOCIO “Caso Salsa Dance”
Esta ventana tiene los
siguientes componentes:
• “Browser”: muestra
de forma jerárquica
todos los elementos
de los modelos de un
proyecto.
Documentación:
muestra
texto asociado al elemento
seleccionado.
Permite
también modificar ese texto.
• “Log”: muestra mensajes
sobre errores, progreso de
tareas, etc.
• Diagramas: cada diagrama
se muestra con una ventana
diferente. Las ventanas de
diagrama cuentan con un
botón
“overview”,
que
permite
desplazarse
rápidamente
por
el
contenido de diagramas

61. MODELADO DEL NEGOCIO “Caso Salsa Dance”

62. MODELADO DEL NEGOCIO “Caso Salsa Dance”

63. MODELADO DEL NEGOCIO “Caso Salsa Dance”

64. MODELADO DEL NEGOCIO “Caso Salsa Dance”

65. MODELADO DEL NEGOCIO “Caso Salsa Dance”

66. MODELADO DEL NEGOCIO “Caso Salsa Dance”

67. MODELADO DEL NEGOCIO “Caso Salsa Dance”

68. MODELADO DEL NEGOCIO “Caso Salsa Dance”
Ahora
continuamos
creando
los casos de uso de negocio :
Inscribir
Dar Lecciones
Programar Horario
Cambiar Modalidad
Concursar
Encuestar
Para ello debemos crear un
p
a
q
u
e
t
e
donde crearemos los casos de

69. MODELADO DEL NEGOCIO “Caso Salsa Dance”

70. MODELADO DEL NEGOCIO “Caso Salsa Dance”
Ahora continuamos
creando los casos de uso de
negocio :
Inscribir
Dar Lecciones
Programar Horario
Cambiar Modalidad
Concursar
Encuestar
Comenzamos creando el
primer caso de uso de negocio
para ello seguimos los pasos a
la derecha

71. MODELADO DEL NEGOCIO “Caso Salsa Dance”

72. MODELADO DEL NEGOCIO “Caso Salsa Dance”

73. MODELADO DEL NEGOCIO “Caso Salsa Dance”

74. MODELADO DEL NEGOCIO “Caso Salsa Dance”

75. MODELADO DEL NEGOCIO “Caso Salsa Dance”
Ahora crearemos los caso
de
uso de negocia que faltan
crear de la manera anterior :
Dar
Lecciones
Programar
Horario
Cambiar
Modalidad
Concursar
Encuestar

76. MODELADO DEL NEGOCIO “Caso Salsa Dance”

77. MODELADO DEL NEGOCIO “Caso Salsa Dance”

78. MODELADO DEL NEGOCIO “Caso Salsa Dance”

79. MODELADO DEL NEGOCIO “Caso Salsa Dance”

80. MODELADO DEL NEGOCIO “Caso Salsa Dance”

81. MODELADO DEL NEGOCIO “Caso Salsa Dance”
1.- Proceso de
Negocio
2.- Objetivo
Inscribir
Selección de Candidatos mas adecuados para la
academia
3.- Actores
Postulante , secretaria
4.- Precondiciones
divulgar lecciones que ofrece la Academia
5.- Flujos
1.- Recepción de Documentos
2.- Si documentación esta conforme
2.1- Llenado de ficha de inscripción
2.2.- Elegir Horario
2.3.-Pago de Inscripción
2.4 Llenado de Boleta de Pago
2.5 Entrega de Boleta al Postulante
3.- de lo contrario
3.1 No conforme
6.- Pos condiciones
Informe de fecha de Inicio de Clases
7.- Excepciones
No exista Vacante
Reclutamiento directo por el área vacante

82. MODELADO DEL NEGOCIO “Caso Salsa Dance”
Para especificar cada caso de uso deberíamos de tomar en consideración los
siguientes aspectos:
1.Interacciones. Mencionar la participación del actor primario y la de cada actor secundario desde que inicia el caso de
uso hasta que termina.
Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos,
etc.)
Nivel de detalle. Los casos de uso y sus especificaciones son la base del contrato que establecemos con nuestro
cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la
funcionalidad del sistema más precisas serán las estimaciones de nuestro plan de trabajo.
Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de
explicar cada uno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y excepcionales.
Claridad y Enfoque de Usuario. Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la
hora de redactarlo sin mencionar detalles técnicos a los que no está acostumbrado. Sobre todo te interesa poder validar
con éste que lo documentado en las espceificaciones de los casos de uso es lo que requiere para su sistema, así que si
no los entiende no cumplirán su propósito principal.
Durante los cursos y consultoría que impartimos a los analistas, les pido que me “platiquen” de qué se trata el caso de
uso solicitado por su cliente, y después escribimos eso mismo en las especificaciones, generalmente logramos así un
documento más claro que cuando lo escriben directamente sin platicarlo. La experiencia me dice que, por lo menos en
sistemas, la gente explica mejor las cosas oralmente que de forma escrita.
2.Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso. Pero, puedo
asegurarte que la esencia es lo mencionado anteriormente. Pero, a continuación se mencionan algunos de esos
elementos extras con los que puedes complementar la plantilla para documentar tus especificaciones de casos de uso.
3.Propósito. Si comienzas por este punto se te facilitará definir los pasos más relevantes para ejecutar el caso de uso.
4.Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El estado en que se
debe encontrar el sistema antes de ejecutarlo. (Ej: Algún catálogo debe estar actualizado, debe estar en conexión con
otro sistema, el usuario debe estar conectado con cierto perfil específico)
5.Postcondiciones. Te indica como queda el sistema después de ejecutar el caso de uso. Imagina que eres un tester y
quieres comprobar si alguien acaba de ejecutar el caso de uso. ¿Qué cosas buscarías en el sistema? Seguramente
datos nuevos, modificados, eliminados o la posibilidad de elegir nuevas opciones en el sistema.
6.Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado.
7.Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>.

83. MODELADO DEL NEGOCIO “Caso Salsa Dance”

84. MODELADO DEL NEGOCIO “Caso Salsa Dance”

85. MODELADO DEL NEGOCIO “Caso Salsa Dance”
Una entidad del negocio
(business entity) representa
a un conjunto de información
con propiedades,
comportamiento y semántica
similares y que es
manipulado o manejado por
trabajadores del negocio.
Ejemplo:
Factura.
Solicitud de pago.
Tarjeta de crédito.
¿Dónde encontrar entidades
del negocio?
Áreas, departamentos,
direcciones.
Objetos físicos.
Transacciones.
Personas.
Sistemas externos.
Organizaciones.
Socios.

86. MODELADO DEL NEGOCIO “Caso Salsa Dance”

87. MODELADO DEL NEGOCIO “Caso Salsa Dance”

88. MODELADO DEL NEGOCIO “Caso Salsa Dance”

89. MODELADO DEL NEGOCIO “Caso Salsa Dance”

90. MODELADO DEL NEGOCIO “Caso Salsa Dance”

91. MODELADO DEL NEGOCIO “Caso Salsa Dance”

92. MODELADO DEL NEGOCIO “Caso Salsa Dance”

93. MODELADO DEL NEGOCIO “Caso Salsa Dance”

94. MODELADO DEL NEGOCIO “Caso Salsa Dance”

95. Capítulo N°4
Aplicación de los Casos de
Uso

96. TEMAS
• Diagramas de Casos de Uso de Sistema
– Relación de Generalización
– Relación Incluye
– Relación Extiende
– Especificación de casos de uso
– Prototipos

97. Relación de Generalización
 Es una relación de Herencia
 Puede ocurrir entre actores o entre casos de uso
Representación Gráfica
 Mediante una línea sólida con cabeza de
flecha hueca
 Apunta desde el Hijo hacia el Padre

98. Relación de Generalización
Actor 2 es el padre de Actor 1
Caso Uso 2 es el padre de Caso Uso 1

99. Ejemplos de Generalización
Entre Actores
En una empresa comercial, el Supervisor de Ventas realiza
las funciones de cualquier vendedor, pero además
supervisa a otros vendedores.
Muestre los actores y la relación entre ellos

100. Solución

101. Ejemplos de Generalización
Uc Casos de Uso
«inherits»
«include»
Validar Usuario
Seguir Pedido
Comprobar clave
«inherits»
«include»
Examinar Retina
Hacer Pedido
____________
Establecer Prioridad
«extends»
Hacer Pedido
Urgente

102. Ejemplos de Generalización
(Entre Casos de Uso)
Cliente
Realizar llamada
telefónica
Realizar llamada Realizar llamada
internacional
nacional

103. Ejemplos de Generalización
(Entre Casos de Uso)
Realizar orden
Cliente
Realizar orden
por teléfono
Usuario
Realizar orden
por internet

104. Relación Incluye
 Es una relación de dependencia (para CU)
 Factoriza comportamientos comunes para no repetir la definición
 Los casos de uso “factorizados” pueden ser utilizados por otros
Casos de Uso
Representación Gráfica
 Estereotipado: <<includes>>
 Apunta desde el CU base hacia el
CU incluido
Uc Casos de Uso
«include»
Caso de Uso Base
Caso de uso
incluido

105. Relación Incluye
<<include>>
 Caso Uso 1 debe también incluir el comportamiento
especificado por el Caso Uso 2
 Cada que se use el caso de uso 1, siempre se utilizará el
caso de uso 2

106. Ejemplo Relación Incluye
En un sistema de ventas de una Ferretería tenemos los Casos de uso
Registrar Pedido y Consultar Estado de Documento en ambos casos
es necesario Validar Cliente.
Muestre los casos de uso y sus relaciones
Registrar
Pedido
Consultar
Estado Doc
<<include>>
<<include>>
Validar
Cliente

107. Ejemplo Relación Incluye
• Venta de productos y
compra de insumos en un
supermercado.
• Las acciones para
“Realizar
movimiento
de
producto” en
kardex puede
separarse en un caso
de uso
independiente.
(Aumenta o disminuye el
Cajero
Realizar venta
de producto
<<include>>
Realizar movimiento
de producto
<<include>>
Comprador
Realizar compra
de insumos

108. Relación Extiende
 Es una relación de dependencia (para CU)
 Se ejecuta el CU base pero bajo ciertas condiciones
Representación Gráfica
 Estereotipado: <<extend>>
 Apunta desde el CU extendido hacia el
CU base.

109. Relación Entiende
<<extend>>
 Caso Uso 2 puede ser extendida por el comportamiento
especificado por el Caso Uso 1
 El CU1, será ejecutado cuando al ser ejecutado el CU2, se
den las condiciones que activen el CU1

110. Ejemplo Relación Entiende
En un sistema de ventas de una Ferretería tenemos el caso de Uso
Enviar Orden y se podrá Enviar Orden Parcial cuando falte algún
producto en sus almacenes.
Muestre los casos de uso y sus relaciones