1. Desarrollo de software
orientado a objetos
Unidad 1:
El proceso unificado de software
RUP

2. Agenda




Introducción.
La Estructura del Proceso Unificado
Características del RUP
RUP y UML

3. Introducción

4. ¿Qué es un proceso de
software?
 Es un marco de trabajo que permite la
programación de las tareas
necesarias para construir un software
de alta calidad.
Requerimientos
Proceso de
ingeniería de
software
Software

5. Características
Marco común de trabajo del proceso
Actividades del marco del trabajo
Conjunto de tareas
Tareas
Hitos, Entregas
Puntos SQA
Actividades de protección y administración
E

6. Modelos
 Para resolver los problemas reales de
las organizaciones, los ingenieros de
software deben incorporar una
estrategia de desarrollo que integre el
proceso, los métodos y las
herramientas necesarias para la
construcción del software.

7. Existen síntomas de
problemas en el desarrollo
del software …..
 Mala comprensión de las necesidades del
usuario.
 Incapacidad de afrontar cambios en los
requerimientos.
 Módulos que no calzan entre si.
 Software difícil de mantener y extender.
 Descubrimiento tardío de defectos en el
proyecto
 ....

8. Existen síntomas de
problemas en el desarrollo
del software …..
…..
Pobre calidad del software.
Pobre e inaceptable rendimiento.
Falta de definición de
responsabilidades en los miembros del
equipo.
 Falta de confiabilidad en el proceso
de construir y producir.





9. Sin embargo….tratar los síntomas
no resuelve el problema
Síntomas
• necesidades usuarios
• requerimientos
cambiantes
Causas
• requerimientos
insuficientes
• comunicación ambigua
• módulos no calzan
• arquitecturas frágiles
• poco mentenible
• complejidad excesiva
• tardía detección
• inconsistencias no
detectadas
• baja calidad
• baja performance
• versiones y cambios
• liberación y distribución
Diagnóstico
• testing pobre
• evaluación subjetiva
• desarrollo en cascada
• cambios no controlados
• automatización insuficiente

10. Causas de los problemas de
desarrollo de software
 Administración inadecuada de
requerimientos.
 Comunicación ambigua e imprecisa.
 Arquitectura frágil.
 Complejidad excesiva.
 Inconsistencias no detectadas entre los
requerimientos, el diseño y la
programación.
 Pruebas insuficientes.
 …

11. Causas de los problemas de
desarrollo de software
 ….
 Evaluación subjetiva del avance del
proyecto.
 Enfrentamiento tardío de riesgos
(desarrollo en cascada).
 Propagación de cambios sin control.
 Bajo nivel de automatización.

12. Las mejores prácticas
enfrentan las causas
Mejores Prácticas
Causas






Desarrolle iterativamente.
Administre requerimientos.
Use arquitectura de componentes.
Modele el software visualmente.
Verifique calidad.
Controle los cambios.
......Enfrentando las Causas se eliminan
los Síntomas
E

13. Las mejores prácticas de
software
 Las mejores prácticas de software
son propuestas comercialmente
probadas de desarrollo que usadas
en forma combinada atacan la raíz
de las causas de las fallas,
eliminando los síntomas y
permitiendo el desarrollo y
mantenimiento de software de
calidad de manera predictiva y
reiterativa.

14. Las mejores prácticas se
refuerzan entre si
Asegura participación del usuario
mientrás evolucionan requerimientos
Valida tempranamente
las decisiones arquitectónicas
Desarrolle
Iterativamente
Permite manejar la complejidad
de diseñar incrementalmente
Mide la calidad en forma oportuna
y frecuente
Evoluciona la línea base
incrementalmente
Administre
Requerimientos
Use Arquitectura
de Componentes
Modele
Visualmente
Verifique
Calidad
Controle
Cambios

15. ¿Que es el RUP?
 Es un proceso de ingeniería de software.
 Se describe entre otras cosas como:




Centrado en una arquitectura.
Guiado por casos de uso.
Iterativo e incremental.
Enfrenta riesgos.

16. ¿Que es el RUP?
 Provee: Lineamientos, templates para
herramientas, que guían una
implementación efectiva de las
6 Mejores Practicas.
 Se define como una “Base de
Conocimiento”
 Soportada en la Web.
 Con búsquedas e hiper-vínculos.

17. Estructura del proceso
unificado

18. Estructura del Proceso
Unificado
E
Fases
Disciplinas del Proceso
ConcepciónElaboración
Construcción
Transición
Modelo del negocio
Requerimientos
Análisis y diseño
Implementación - Codificación
Prueba - Test
Despliegue
Disciplinas de Soporte
Adm. configuración y cambios
Adm. del proyecto – Gestión del Proy.
ambiente
Iteracion(es)
Preliminar(es)
Iter.
#1
Iter.
#2
Iter. Iter. Iter.
#n #n+1 #n+2
Iter. Iter.
#m #m+1
Iteraciones - Tiempo

19. Estructura del proceso
unificado
 Dimensiones
 El eje horizontal representa el tiempo y
muestra el ciclo de vida del proceso tal y
como se desenvuelve.
 Muestra el aspecto dinámico (iteraciones).
 El eje vertical representa los flujos de
trabajo (workflows) nucleares, que
agrupan actividades por su naturaleza.
 Representa el aspecto estático

20. Estructura dinámica
Concepción Elaboración
Construcción
Transición
Tiempo
Concepción
Define el alcance del proyecto y el
desarrollo de los casos del negocio.
Elaboración
Planifica el proyecto, especifica
las características y define los
cimientos de la arquitectura.
Construcción
Construye el producto.
Transición
Implementa el producto a sus
usuarios.

21. Principales hitos de control
Concepción Elaboración
Construcción
Transición
Tiempo
Visión
Soporte
base de la
Arquitectura
Capacidad
Inicial
Versión
del
Producto

22. Ciclo de Vida
Concepción
Iteración ...
Elaboración
Iteración
...
Construcción
Iteración Iteración
...
Transición
Iteración
Release Release Release Release Release Release
...
Release
Release
Una iteración es una secuencia de actividades con un
plan establecido y criterios de evaluación, cuyo resultado
es una versión o release.

23. Ciclo de Vida-Dos
perspectivas

24. Estructura Estática
Fases e iteraciones
Flujos del Proceso
Actividades, pasos
Artefactos
Modelos, reportes y/o
documentos
Trabajadores
¿Cuándo ocurre el
proceso?
¿Cómo ocurre el
proceso y sus detalles?
¿Qué se produce u
obtiene?
¿Quién lo hace o se
responsabiliza?

25. Estructura Estática
Es un rol asumido
por un empleado
Actividad
Es una unidad
de trabajo
Trabajador
Analista
Es responsable por
Descripción de
un caso de Uso
Artefacto
Caso de Uso
Paquete de
Caso de Uso
Es una pieza de información
producida, modificada o
usada por un proceso

26. Estructura Estática




Trabajador
Actividades
Artefactos
Workflows
-
el Quién
el Cómo
el Qué
el Cuándo

27. Trabajador (Worker)
 El término Worker define el comportamiento y
responsabilidades de un individuo o un grupo
de individuos trabajando juntos como
equipo.
Trabajador
Responsable
Artefactos
Lleva a cabo
Actividades

28. Actividad
 Es una unidad de trabajo de un
Worker que:
 tiene un propósito claro.
 es expresada normalmente en
términos de creación o actualización
de artefactos.
 es asignada a un worker específico

29. Actividades
 Están fraccionadas en “pasos”. Los
pasos se agrupan en:
 Pasos pensantes.
 Pasos de desarrollo.
 Pasos de revisión.
Actividad
Tiene
Pasos
Tiene
Guías de
Trabajo
Tiene
Tool
Mentor

30. Artefacto
 Es una pieza de información que es
producida, modificada o usada por un
proceso.
Trabajador
Responsable
Resultado
Artefacto
Input
+ Modelo
Tiene
Reporte
Tiene
Guías
Tiene
Template
Actividad

31. Workflows
 Es una secuencia de actividades que
produce un resultado de valor
observable.
 En terminos de UML un workflow puede
ser expresado como un diagrama de
secuencias, de colaboración o de
actividades.
 RUP usa un diagrama de actividad para
representar el workflow.

32. Workflows
 El RUP organiza el conjunto de
actividades usando:
 Workflows del proceso
 Workflows de iteración
 Workflows de detalle

33. Workflows del proceso
 Los workflows del proceso agrupan las
actividades propias de las disciplinas de
ingeniería de software.
 Hay seis workflows de de procesos
propiamente dichos:






Modelo del negocio
Requerimientos
Análisis y Diseño
Implementación
Prueba
Distribución

34. Workflows del proceso
 .......y tres workflows de apoyo:
 Configuración y administración de
Cambios
 Administración del proyecto
 Definición del ambiente

35. Workflows de iteración
 Es otra forma de mostrar el proceso, describiéndolo
desde la perspectiva de “lo que sucede en una
iteración típica”.
 Estas actividades se establecen en un cronograma.
Fases
Disciplinas del Proceso
Inception
Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Workflow de
Iteración
Disciplinas de Soporte
Configuration Mgmt
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1

36. Workflows de detalle
 Es una descripción de un workflow del
proceso a más bajo nivel. RUP los usa
para expresar:
 un grupo específico de actividades que
están relacionadas y que son desarrolladas
juntas o en un modelo cíclico.
 actividades que son desarrolladas por un
grupo de gente.
 actividades que producen un resultado
intermedio interesante.

37. Modelos y Workflows
Cada workflow describe
cómo crear y mantener un
“modelo” en particular
Business
Modeling
Business Model
Requirements
Workflow
Analysis /Design
Workflow
Implementation
Workflow
Test Workflow
realized by
Use-Case
Model
implemented by
Design
Model
verified by
Implementation
Model
Test
Model

38. Características del RUP

39. Características del RUP
 Las principales características del RUP
son:





Centrado en una arquitectura.
Guiado por casos de uso.
Iterativo e incremental. evolutivo
Manejo de proyectos y riesgos.
Administración y control de cambios.

40. Características: Centrado en
una arquitectura.
 Los modelos son los vehículos para visualizar,
especificar, construir y documentar la arquitectura.
 RUP prescribe el refinamiento sucesivo de una
arquitectura ejecutable.
 Vista 4+1 arquitectura ruc
Inception
Elaboration
Construction
tiempo
Arquitectura
Transition

41. “Vista 4+1” modelo de
arquitectura
Vista
Estructural
Analistas/
Diseñadores
Estructura
Usuarios Finales
Funcionalidad
Vista de
Implementación
Programadores
Administración
del Software
Vista Casos de
Uso
Vista de
Vista de Proceso
Despliegue
Integradores de sistemas
Rendimiento
Escalabilidad agregar o quitar …
Operatividad
Ingenieros de sistemas
Topología
Entrega, instalación
comunicación

42. El dominio de la arquitectura
El “para qué”
EL “qué”
Cualidades
Arquitectura
Características
del Sistema
Satisface
Condiciona
Requerimientos
Representación
Produce
El “quién”
Arquitecto
Atributos de
calidad del sistema
Tecnología
El “cómo”
Sigue
Procesos
Técnicas
Participantes
Define
Define roles
Organización

43. La Arquitectura y las
Iteraciones
Modelo de
Casos de
Uso
Modelo
Modelo de
Modelo de
del
Implementación despliegue
Diseño
Contenido
Modelo
de Prueba

44. RUP es la armazón de un proceso
No existe un proceso universal
• RUP está diseñado para la flexibilidad y la extensión.
» Permite una variedad de estrategias de ciclos de vida.
» Selecciona que artefactos producir y cuado.
» Define actividades y roles.
» Aplica los conceptos de modelamiento (UML)

45. Características: Guíado por
Casos de Uso
Requer.
Análisis
Diseño
Implem.
Los casos de uso vinculan a todos los
workflows juntos
Prueba

46. Manejo de Casos de Uso

47. Los Casos de Uso manejan
las Iteraciones
 Conduce un buen número de actividades
de desarrollo.
 Creación y validación de la arquitectura del
sistema.
 Definición de casos de prueba y
procedimientos.
 Planeamiento del iteraciones.
 Creación de la documentación del usuario.
 Despliegue del sistema
 Sincroniza el contenido de diferentes
modelos.

48. Artefactos de
Requerimientos
Requerim.
Funcional
No Funcional (URPS)
Especificaciones Complementarias
Casos de Uso

49. Casos de Uso - Conceptos
•
Actor
Caso de Uso
•
Un actor es algo o
alguien fuera del
sistema que
interactúa con este.
Un caso de uso es una
secuencia de
acciones ejecutadas
por un sistema para
obtener un resultado
de valor para un actor

50. Actores y ámbito del
sistema
Sistema Bancario
Cliente
Sistema Agencias
Cajero Bancario
¿Límites del
Sistema?

51. ¿Qué hay en un modelo de
Casos de Uso?
 Los actores y sus descripciones
 Diagramas de Casos de Uso mostrando
relaciones
 Para cada caso de uso






Nombre y pequeña descripción
Flujo de eventos
Pre-condiciones y post-condiciones
Requerimientos especiales
Opcionalmente, prototipos de interfaz usuaria
Otros diagramas, como diagramas de
actividad o diagramas de estado

52. Desde los Casos de Uso
hasta los Ejecutables
Casos de
Uso
Clases de
Análisis
Clases de
Diseño
Código
Fuente
Exec

53. Casos de Uso e Interfaces
 Desde los casos de uso se pueden
obtener prototipos de las pantallas
propuestas
 Ellas constituyen la base del diseño de
interfaz usuario.

54. Casos de Uso y
Documentación
Implantación
Modelo de Casos de Uso
Material soporte usuarios
•Manual de Usuario
•Help en línea
•Demos
•Tutoriales
•Material entrenamien

55. Casos de Uso y el Modelo de
Pruebas
Modelo de Casos de Uso
Test
Modelo de Test
Especificaciones
Complementarias

56. Modelo de Casos de Uso y
otros modelos
Modelo de Casos de Uso
(requerimientos)
realización
influencia
Modelo de
diseño
(clases y objetos)
Modelo de
Implementación
(código fuente)
verificación
Modelo de Test
(casos de test y procedimientos de test)

57. Casos de Uso e Iteraciones
Restricciones
Modelo de Casos
de Uso
Administración
del Proyecto
Plan de Iteración
Especificación
Complementaria
Plan detallado para una
iteración en particular

58. Características: Iterativo e
Incremental
 El ámbito de cada iteración está
basado en:
 Los principales riesgos del proyecto.
 La funcionalidad requerida por el sistema.
 El tiempo asignado a la iteración en el
plan del proyecto.
 La fase y sus objetivos específicos.

59. Planificación de Iteraciones
 El alcance de la iteración se expresa
en términos de:
 Casos de uso elegidos.
 Requerimientos no funcionales elegidos.

60. Cada Iteración consiste de
una mini-cascada
Plan de Iteración
Requerimientos
Análisis & Diseño
Implantación
Prueba
Prepara Versión
Iteración 3
Iteración 4
Chequeo de
preparación para
la iteración
Iteración 5
Evaluación de
la Iteración

61. Ciclos de desarrollo
 Un ciclo de desarrollo incluye una ejecución
completa de las cuatro fases y produce una
generación de software.
 La mayoría de los sistemas requiere múltiples ciclos.
 Un ciclo de desarrollo inicial genera la liberación
inicial.
 Ciclos posteriores se usan para mantener o mejorar
el sistema.
 Los ciclos pueden ser secuenciales o traslaparse.

62. Estrategias de Desarrollo
Iterativo
Incremental (1)
Incremental
In c e p t io n
P r e l.
I t e r a t io n
Co
(1)
E la b o r a tio n
#1
nce
p tu
C o n s tru c tio n
#2
A rc
h ite
#n+1
c tu
al p
ra l
ro t
bas
o ty
e lin
pe
e
# ..
#m
T r a n s itio n
# m + 1 # m + 2 . . It e r.
No.
Re
De
le a
liv e
se
ry

63. Estrategias de Desarrollo
Iterativo
Evolucionario (2)
E la b o ra tio n
In c e p tio n
P r e l.
I te r a t io n
Co
C onstru c tio n
#1
nc
ep
#2
#n+1
# . .
#m
Ar
tu a
lp
ro t
o ty
pe
ch
T r a n s itio n
#m +1
Re
le a
ite
se
c tu
ra l
ba
se
li n
e
# m + 2 . . Ite r.
N o.
De
li v e
ry

64. Estrategias de Desarrollo
Iterativo
Incremental (1)
Entregas incrementales (3)
In c e p tio n
Constru c tio n
E la b o r a tio n
P r e l.
#1
I t e r a t io n
Co
nc
ep
T r a n s itio n
#2
Ar
tu a
lp
ch
ro t
ite
o ty
#n+1
Re
c tu
pe
ra l
le a
ba
se
se
li n
e
# ..
#m
# m + 1 # m + 2 . . I t e r.
N o.
De
liv e
ry

65. Estrategias de desarrollo
Iterativo
El gran diseño (4)
In c e p tio n
E la b o ra tio n
C o n s tr u c tio n
#1
Co
Ar
ch
nc
ite
ep
c tu
tu a
ra l
lp
ro t
ba
o ty
se
li n
pe
e
T r a n s itio n
#2
Re
le a
se
#3 . .
Ite r.
N o.
De
li v e
ry

66. Ciclo de Retroalimentación
Evaluación de Iteración N
•
Costos y Plazos
Reales Iteración N
Evaluación de Calidad de la Iteración N
• Resultado de Tests
• Densidad de
Defectos
• Estabilidad
Arquitectura
• Otras métricas
•
•
•
•
Compare costos y plazos
reales con los del plan de
iteración
Determine si hay trabajo a
rehacer
- Asígnelo a futura(s)
iteración(es)
Determine que riesgos han
sido reducidos, eliminados
o cuales identificados
Actualice el plan del
proyecto
Prepare plan próxima
iteración
- Use lista de riesgos
revisada y seleccione
Casos de Uso
Lista de riesgos
revisada
Plan Proy. revisado
• Costo Total
• Programac. Gral.
• Ambito
Plan Iteración N+1
• Costo
• Programación
• Contenido

67. Plan de Iteración
 Definir criterios de evaluación objetivos.
 Identificar que artefactos concretos y
medibles serán desarrollados o
actualizados y las actividades necesarias
para lograrlo.
 Descomponer las actividades hasta
llegar a sub-actividades con una
asignación y responsabilidad clara y una
duración controlable.

68. Plan de Iteración
 Usar estimaciones para asignar duración
y esfuerzo de cada actividad.
 Hacer los ajustes necesarios de acuerdo
a las restricciones de recursos.

69. Plan de Iteraciones
 ¿Cuántas iteraciones deben hacerse en
cada proyecto?
Total
I
E
C
T
Bajo
3
0
1
1
1
Típico
6
1
2
2
1
Alto
9
1
3
3
2
 ¿Cuánto debe durar cada iteración?
 Depende de un número de consideraciones:
 Tamaño del sistema: Mientras mayor el sistema, más
larga la duración
 Número de personas: Mientras más gente, más larga la
duración

70. Controlando el ciclo de vida
iterativo
 La evaluación de la iteración provee el
feedback necesario para controlar el
proceso
Ejecute
Plan de
Iteración
Desarrolle
Business
Case
Identique
Riesgos
Desarrolle
Plan
Proy.
Lider de
Proyecto
Desarrolle
Plan de
Iteración
Evalue
Iteración
Asigne
Personal
Analice lista de Riesgos

71. Características: Manejo de
Proyectos y Riesgos
Significado
Métrica
Progreso

Tamaño y Complejidad
Estabilidad

Tasa de cambio en el tamaño o
complejidad del sistema
Adaptabilidad

Facilidad de cambio
Modularidad

Ambito de cambio
Calidad

Número de errores
Madurez

Frecuencia de errores
Gastos

Costo del proyecto versus presupuesto

72. Asignación de Recursos:
Duración y Esfuerzo
 Distribución de esfuerzo para un ciclo de
desarrollo inicial de un proyecto de tamaño
medio
Recursos
5%
esf.
20% esfuerzo
Concep Elaboración
65% esfuerzo
Construcción
10%
esf.
Transición
Tiempo

73. Manejo de Riesgos
 Riesgo - Todo lo que pueda afectar el
éxito del proyecto
 Riesgo Directo - el proyecto tiene un alto
grado de control
 Riesgo Indirecto - el proyecto tiene poco
o ningún control

74. Manejo de Riesgos
 Atributos de Riesgo:
 Probabilidad de ocurrencia
 Impacto en el proyecto (severidad)
 Indicador de magnitud de Riesgo: Alto,
Significativo, Moderado, Parcial, Bajo

75. Estrategias frente al Riesgo
 Evitar el riesgo reorganizar el proyecto, de
manera que no sea
afectado por el riesgo.
 Transferir el riesgo reorganizar el proyecto, de
manera que el riesgo sea
asumido por otro.

76. Estrategias frente al Riesgo
 Aceptar el Riesgo - vivir
con él
 Amortiguar el Riesgo reducir su probabilidad o
impacto
 Definición de plan de
contingencia - que hacer
si el riesgo se transforma
en un problema real
(“Plan B”)

77. El Riesgo conduce el Ciclo
de Vida Iterativo
 La evaluación del riesgo es un
proceso continuo; los riesgos van
cambiando en el tiempo.
 Las primeras iteraciones enfrentan los
mayores riesgos

78. Características:
Administración y Control de
Cambios
Yo necesito un nuevo requerimiento
y cambios a los casos de uso actuales...
Cliente
 ¡El cliente está consciente
que hay un cambio al
Modelo de Casos de Uso!
 Hace el impacto en costo
más visible para el cliente

79. Administración y
configuración de Cambios
 La administración de configuraciones
y cambios de los requerimientos es
importante por las mismas razones
que la administración de
configuraciones de código fuente es
importante

80. Administración y
configuración de Cambios
 Beneficios de administración de
requerimientos bajo CM
 Previene de cambios no autorizados
 Conserva las revisiones de los
documentos de los requerimientos
 Permite recuperar versiones anteriores de
los documentos
 Previene la actualización simultanea de
documentos

81. La administración de Cambios es
Clave
Los requerimientos de cambio vienen de muchas
fuentes durante el ciclo de vida del producto
CM Artifacts
Proceso
Aprobación
(Equipo
Revisión
Cambios)
Nueva
Característica
Nuevo
Requerimiento
Error
Mejoras
Inputs de Clientes y
Usuarios Finales
Vision
Marketing
Reqs
CR
System
Code
CR
System
Inputs de
programadores y
testeadores
Test
Mesa de Ayuda
CR

82. RUP y UML
Desarrollo
en equipos
Lenguaje de
Modelamiento
Proceso
Unificado

83. ¿Qué es UML?
 El lenguaje de modelamiento unificado
(UML) está descrito en "The Unified Modeling
Language for Object-Oriented
Development" escrito por Grady Booch,
James Rumbaugh e Ivar Jacobson.
 Está basado en las experiencias personales
de los autores.
 Incorpora contribuciones de otras
metodologías.

84. ¿Qué es UML?
 UML es el lenguaje “Standard” para
visualización, especificación,
construcción, y documentación de los
elementos de un sistema “software
intensivo”
 Puede ser utilizado a través de todo el
ciclo de vida de desarrollo

85. ¿Qué es UML?
 UML combina lo mejor de:
 Conceptos de modelamiento de
datos.
 Modelamiento del negocio
(workflow).
 Modelamiento de objetos.
 Modelamiento de componentes.

86. Ventajas del UML
 Es un estándar abierto
 Da soporte a todo el ciclo de vida de
desarrollo del software.
 Da soporte a diversas áreas de
aplicación.
 Está soportado por muchas
herramientas.

87. Creación del UML
UML 1.3
OMG Acceptance, Nov 1997
UML 1.1
Final submission to OMG, Sep ‘97
public
feedback
First submission to OMG, Jan ´97
UML 1.0
UML partners
UML 0.9
Web - June ´96
OOPSLA ´95
Other methods
Unified Method 0.8
Booch method
OMT
OOSE

88. Contribuciones al UML
Harel
Meyer
Before and after
conditions
Statecharts
Gamma, et al
Frameworks and patterns,
HP Fusion
Booch
Operation descriptions and
message numbering
Booch method
Embley
Rumbaugh
Singleton classes and
high-level view
OMT
Jacobson
Wirfs-Brock
OOSE
Responsibilities
Shlaer - Mellor
Object lifecycles
Odell
Classification

89. Workflows y Modelos
Requerimientos
Análisis
Diseño
UML - Sus diagramas
proporcionan vistas dentro
de cada modelo
Use Case
Model
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Implementación
Test
Model
Prueba
Cada Workflow está
asociado con uno o
más modelos

90. Modelos, Vistas, y
Diagramas
Use Case
Use Case
Diagrams
Diagramas
Diagrams
de Secuencia
Use Case
Use Case
Diagrams de
Diagramas
Diagrams
Casos de Uso
Scenario
Scenario
Diagrams de
Diagramas
Diagrams
Colaboración
Scenario
Scenario
Diagramas
Diagrams de
Diagrams
Transición de
Estados
State
State
Diagrams de
Diagramas
Diagrams
Clase
Modelos
State
State
Diagrams
Diagramas
Diagrams
de Objeto
State
State
Diagrams de
Diagramas
Diagrams
Componentes
Component
Component
Diagrams
Diagramas
Diagrams
Diagramas
de Actividades
de
Implementación

91. Modelo de casos de uso
Use Case
Diagrams
Use Case
Model
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Class
Diagrams
Component
Diagrams
Deployment
Diagrams
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
Object
Diagrams

92. Modelo de análisis y diseño
Use Case
Diagrams
Use Case
Model
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Class
Diagrams
Object
Diagrams
Component
Diagrams
Deployment
Diagrams
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
Incluye
subsistemas y
paquetes

93. Modelo de despliegue
Use Case
Diagrams
Use Case
Model
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Class
Diagrams
Object
Diagrams
Component
Diagrams
Deployment
Diagrams
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
Incluye clases y
componentes

94. Modelo de prueba
Use Case
Diagrams
Use Case
Model
Class
Diagrams
Analysis
Model
Component
Diagrams
Design
Model
Deployment
Diagrams
Depl.
Model
Impl.
Model
Test
Model
Prueba la
sincronización de
los modelos
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
Object
Diagrams

95. La arquitectura y los
modelos
Use Case
Model
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Modelos
Vistas

96. Funciones versus Formas
Casos de uso
Arquitectura
• Los casos de uso especifican funciones. La
arquitectura especifica la forma.
• Los casos de uso y la arquitectura deben estar
balanceados.

97. Dos partes de un todo
unificado
UML
• Es un estándar
de OMG
RUP
• Convergencia
en el futuro
• Convergencia
a través de los
esquemas de
proceso.