Uml

1. 1
Curso de UML
Actividad 1 Introducción a UML
Dra. Anaisa Hernández González

2. 2
Construcción de una casa para “fido”
Puede hacerlo una sola persona
Requiere:
Modelado mínimo
Proceso simple
Herramientas simples

3. 3
Construcción de una casa
Construida eficientemente y en un tiempo
razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas

4. 4
Construcción de un rascacielos

5. Problemas de la Industria de Software
en la actualidad
Tendencia al crecimiento
del volumen y complejidad
de los productos.
1
2 Proyectos excesivamente tardes y
se exige mayor productividad y
calidad en menos tiempo.
3 Insuficiente personal calificado.

6. 6
Planificación Irreal1
2 Mala Calidad del Trabajo
3 Personal Inapropiado
4 No Controlar los Cambios
¿ Por qué fallan los¿ Por qué fallan los
Proyectos de Software?Proyectos de Software??

7. 7
Los ingenieros no son capaces de
enfrentar un plan porque:
PlanificaciPlanificacióón Irrealn Irreal 1
• NO están entrenados para usar métodos
de planificación.
• Frecuentemente, las estimaciones NO
se basan en datos reales.
“El sistema es para hoy y con costo 0”

8. 8
2
Mala Calidad del TrabajoMala Calidad del Trabajo
CAUSAS
• Prácticas pobres de ingeniería
• Carencia de métricas de calidad
• Inadecuado entrenamiento en calidad
• Decisiones de los directivos guiadas
por una planificación irreal

9. 9
2
Mala Calidad del TrabajoMala Calidad del Trabajo
CONSECUENCIAS
• Tiempos de pruebas impredecibles
• Productos con muchos defectos
• Demoras en la aceptación de los usuarios
• Extensa garantía de servicio y reparaciones
““Una pobreUna pobre calidad afecta lacalidad afecta la
planificaciónplanificación y torna ineficentey torna ineficente elel
proceso de pruebaproceso de prueba””

10. 10
3
Personal InapropiadoPersonal Inapropiado
Con independencia del plan, los
proyectos deben comenzar en tiempo
y con todo el personal.
• Demora del personal
• Escaso personal
• Miembros del equipo a tiempo parcial
• Personal con conocimientos
inapropiados
PROBLEMAS
COMUNES
• El trabajo se demora o descuida
• Trabajo ineficiente
• Sufre la moral del equipo
CONSECUENCIAS

11. 11
4
CambiosCambios NONO controladoscontrolados
• Siempre ocurren cambios en los requerimientos.
• Los planes del proyecto se basan en el alcance del
trabajo conocido.
• Los cambios siempre requieren más trabajo.
• Sin planes detallados, los equipos no pueden
estimar el efecto o magnitud de los cambios.
• Si los equipos no controlan cada cambio, se
pierde gradualmente el control del plan del
proyecto
HECHOS a RECORDAR:

12. 12
Las organizaciones requieren:
¿Cómo enfrentarla?¿Cómo enfrentarla?
?
Desarrollar o adquirir una disciplina
en el desarrollo del software.
1
2 Controlar que los ingenieros usen de
forma consistente los nuevos métodos.

13. Mejorar el proceso deMejorar el proceso de
desarrollo de softwaredesarrollo de software
¿Qué debe hacer una
empresa para obtener
software de buena
calidad?
Cómo?

14. 14
Cualquier modelo de calidad para
mejorar el Proceso de Desarrollo de
Software, IMPLICA utilizar los
métodos y procedimientos de
INGENIERIA Y GESTION
DE SOFTWARE

15. 15
¿Qué es la Ingeniería de Software (IS)?
“...la aplicación de un enfoque
sistémico, disciplinado y
cuantificable hacia el desarrollo,
funcionamiento y mantenimiento
de software, es decir la aplicación
de ingeniería al software”
IEEE,1993

16. 16
IS es una tecnología multicapa
Soporte automático o
semiautomático para el
proceso y los métodos.
Es el fundamento de la
IS. Es la unión que
mantiene juntas las
capas de la tecnología.
Indican cómo construir
técnicamente el Sw.

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

18. 18
Las Mejores Prácticas de la IS
atacan las causas
Controle CambiosControle Cambios
Desarrolle IterativamenteDesarrolle Iterativamente
AdministreAdministre
RequerimientosRequerimientos
ModeleModele
VisualmenteVisualmente
VeriqueVerique
CalidadCalidad
UseUse
arquitecturaarquitectura
dede
componentescomponentes

19. 19
Mejores Prácticas de Software
Son propuestas de desarrollo probadas
comercialmente, 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.

20. 20
Mejores Prácticas: Equipos de Alto
Rendimiento
Jefe de
Proyecto
Ing. de
Performance
Liberación y Distribución
Analisis
Desarrollador
Probador
ResultadoResultado
• Proyectos más exitosos
porque están en plazo,
en presupuesto y
satisfacen las
necesidades del usuario
Control ChangesControl Changes
Develop IterativelyDevelop Iteratively
UseUse
ComponentComponent
ArchitecturesArchitectures
ManageManage
RequiremeRequireme
ntsnts
ModelModel
VisuallyVisually VerifyVerify
QualityQuality

21. 21
SÍNTOMAS
necesidades usuarios
requerimientos
cambiantes
módulos no calzan
poco mentenible
tardía detección
baja calidad
baja performance
versiones y cambios
liberación y distribución
CAUSAS
Requerimientos
insuficientes
Comunicación ambigua
arquitecturas frágiles
complejidad excesiva
inconsistencias no
detectadas
testing pobre
evaluación subjetiva
desarrollo en cascada
cambios no controlados
automatización
insuficiente
MEJORES PRÁCTICAS
desarrolle iterativamente
adm. requerimientos
use arquitectura de
componetes
modele el software
visualmente
verifique calidad
controle cambios
Enfrentando las Causas se eliminan los Síntomas

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

23. 23
Mejores prácticas para el trabajo
efectivo de un equipo en el
desarrollo del software.
(Dirige y organiza el proceso)
(Notación)

24. 24
Sumario
• Conceptos básicos del modelo de objetos
• Proceso de desarrollo de software.
• El Lenguaje Unificado de Modelación (UML)
• El Proceso Unificado de Desarrollo de
Software (RUP)

25. 25
Lecturas Recomendadas
• JACOBSON, Ivar; BOOCH, Grady, RUMBAUGH, James,
“El Proceso Unificado de Desarrollo de Software”.2000.
Addison Wesley.
• BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar;
“El Lenguaje Unificado de Modelación. Libro
introductorio”.2000. Addison Wesley.
•LARMAN, Craig “UML y patrones” 1999, Prentice Hall
Iberoamericana.
• RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady;
“El Lenguaje Unificado de Modelación. Manual de
referencia”.2000. Addison Wesley.
Bibliografía

26. 26
Lecturas Recomendadas
• CONALLEN, Jim, “Building Web Applications with
UML”.2002. 2nd edition. Addison Wesley.
• BOOCH, Grady, MAKSIMCHUCK, Robert, ENGLEm
Michael, YOUNG, Bobbi, CONALLEN, Jim, Houston,
Kelli; “Objetct-Oriented Analysis and Design with
Applications”. Third Edition. Addison Wesley. 2007.
• HAMILTON, Kim, MILES, Russell; “Learning UML
2”.2006. O´ Reilly Media
Bibliografía

27. 27
Conceptos básicos del Modelo
de Objetos

28. 28
Enfoque Orientado a Objetos
• Se basa en conceptos y relaciones entre ellos.
Objetos
Atributos
blanco
Todo
Partes

29. 29
Enfoque Orientado a Objetos
Tipo de Objeto:
Descripción generalizada que describe una
colección de objetos similares.
Clase:
Implementación en software de un tipo de
objeto.
Tlibro = class
private
. . .
end;

30. 30
Enfoque orientado a Objetos
Método:
Implementación en software de la operación.
TSemáforo = class
.....
Cambiar luz();
end;
Cambiar luz

31. 31
Encapsulamiento
Empaque conjunto de datos y métodos.
Atributos
Operaciones
Enfoque Orientado a Objetos

32. 32
Enfoque Orientado a Objetos
Herencia: Propiedad de una clase de
heredar el comportamiento de sus
ancestros.
Polimorfismo: Mecanismo que permite a la
subclase implementar la misma operación con
un método diferente.

33. 33
Proceso de Desarrollo de
Software

34. 34
Proceso
Define “quién” está haciendo “qué”, “cuándo” y
“cómo” para alcanzar un determinado objetivo.
Proceso de desarrollo de software (PDS)
Requisitos del usuario Sistema informático

35. 35
Proceso de desarrollo de software (PDS)

36. 36
• Un proceso software debe especificar:
– la secuencia de actividades a realizar por
el equipo de desarrollo: flujo de
actividades
– productos que deben crearse: qué y
cuándo
– asignación de tareas a cada miembro del
equipo y al equipo como un todo
– proporcionar heurísticas
– criterios para controlar el proceso
Proceso de desarrollo de software (PDS)

37. 37
UML

38. 38
“ Puede ser un seudocódigo, código,
imágenes, diagramas, o largos paquetes
de descripción; es decir, cualquier cosa
que ayude a describir un sistema ”
Lenguaje de modelación
= +

39. 39
(Forma de
expresar el
modelo)
Lenguaje de modelación
+=
(Descripción
de lo que
significa esa
modelación)

40. 40
Interface de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)
Servidor de BDs
(C++ & SQL, ..)
Múltiples Sistemas
Componentes
Reutilizados
Manejar la complejidad
Modelar el sistema
independientemente
del lenguaje de
implementación
Promover la Reutilización
Notación visualNotación visual

41. 41
• Diversos métodos y técnicas OO, con muchos aspectos en
común pero utilizando distintas notaciones
• Inconvenientes para el aprendizaje, aplicación,
construcción y uso de herramientas, etc.
• Pugna entre distintos enfoques (y correspondientes
gurús)
Situación de partidaSituación de partida

42. 42
• Descrito en "The Unified Modeling Language for
Object-Oriented Development" de Grady Booch,
James Rumbaugh e Ivar Jacobson.
• Basado en las experiencias personales de los
autores.
• Incorpora contribuciones de otras metodologías.
Lenguaje Unificado de Modelación
?
¿Qué es el UML- Unified
Modeling Language?
U M L

43. 43
• Ofrece un estándar para describir un “plano” del
sistema.
• Incluye aspectos conceptuales tales como procesos
de negocio y funciones del sistema y aspectos
concretos como espresiones de lenguajes de
programación, esquemas de BD y componentes de
software reutilizables.
Lenguaje Unificado de Modelación
?
¿Qué es el UML- Unified
Modeling Language?
U M L

44. 44
UML
DocumentarDocumentar
VisualizarVisualizar EspecificarEspecificar
ConstruirConstruir
Σ

45. 45
UML no es un método
El UML es una guía al desarrollador para realizar
el análisis y diseño orientado a objetos, es un
proceso
El UML es un lenguaje que permite la modelación
de sistemas con tecnología orientada a objetos
Aprobado como estándar por OMG en
noviembre de 1997

46. 46
 El esfuerzo de UML partió oficialmente en
octubre de 1994, cuando Rumbaugh se unió a
Booch en Rational.
 El “Método Unificado” en su Versión 0.8, se
presentó en el OOPSLA’95
 El mismo año se unió Ivar Jacobson. Los “Tres
Amigos” son socios en la compañía Rational
Software. Herramienta CASE Rational Rose
Orígenes de UML

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

48. 48
• Las primeras versiones de UML estaban más
orientadas hacia la modelación del software y
ahora se requiere más la modelación del sistema.
• Necesidad de compartir modelos entre diferentes
herramientas.
• Nuevas tecnologías: Arquitectura basada en
componentes, MDA
• Las primeras versiones estaban más diseñadas
para las personas y no para las máquinas, por lo
que hay construcciones que no estaban
suficientemente formalizadas.
¿Por qué UML 2.0?

49. 49
GRADY
BOOCH
IVAR
JACOBSON
JAMES
RUMBAUGH
Object Modelling Technique 1991(OMT)
Object Oriented Analysis and Design
with Applications 1994
Object Oriented Software Engineering: A
Use Case Driven Approach 1992 (OOSE)
Las Bases de UML
• Booch,
• Rumbaugh
• Jacobson
Rational Software
Corporation. (1995)
Las Bases de UMLLas Bases de UML

50. 50
• Modelar sistemas, a partir de los
conceptos hacia los artefactos ejecutables,
utilizando técnicas orientadas a objeto.
• Enfocarnos en las cuestiones de escala
inherentes a sistemas complejos, críticos
en su misión.
• Crear un lenguaje de modelación
utilizable tanto por los humanos, como
por las máquinas.
Premisas de UML según
Booch, Jacobson y Rumbaugh

51. 51
Contribuciones a UML
Diagrama de Casos de uso
Diagrama de Clases
Diagrama de Objetos
Diagrama de Secuencia
Diagrama de Estado
Diagrama de Componentes
Diagrama de Estructura Compuesta
Diagrama de Paquetes
Diagrama de Comunicación
Diagrama de Actividad
Diagrama de Tiempo
Diagrama de Despliegue
OOSE/Jacobson
OOAD/Booch
OMT/Rumbaugh
Otras mejores
prácticas

52. 52
• Es un lenguaje formal ya que cada elemento
del lenguaje tiene un significado fuerte que
ayuda a modelar un aspecto particular del
sistema.
• Es conciso con una notación simple.
• Es comprensible porque describe todos los
aspecto importante del sistema.
• Es escalable por lo que permite describir
proyectos de diferentes tamaños.
Ventajas de UML

53. 53
• Contiene las mejores prácticas de la
comunidad orientada a objetos de los
últimos 15 años.
• 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.
Ventajas de UML

54. 54
• Carece de un semántica precisa, lo que ha
dado lugar a que la interpretación de un
modelo UML no pueda ser objetiva en
ocasiones.
• No se presta con facilidad al diseño de
sistemas distribuidos. En estos sistemas
son importantes factores como transmisión,
serialización, persistencia, etc. No se puede
señalar si un objeto es persistente o
remoto.
Limitaciones de UML

55. 55
Un proceso de desarrollo de
software debe ofrecer un conjunto
de modelos que permitan expresar
el producto de software desde cada
una de las perspectivas de interés

56. 56
Un producto de software es el código
máquina y los ejecutables de un sistema
Un producto de software es el conjunto de
artefactos que se necesitan para
representarlo en forma comprensible para:
• Las máquinas.
• Los trabajadores.
• Los usuarios.
• Los interesados.
¿artefactos?
¿Qué es un producto de software?

57. 57
¿Artefactos?
Término general aplicable a
cualquier tipo de información
creada, cambiada o utilizada por
los trabajadores en el desarrollo
del sistema
• Diagramas UML y su texto.
• Bocetos de interfaz.
• Planes de prueba.
EjemplosEjemplos::

58. 58
• Un modelo captura una vista de un sistema del
mundo real. Es una abstracción de dicho sistema,
considerando un cierto propósito. Así, el modelo
describe completamente aquellos aspectos del
sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle.
• Diagrama: una representación gráfica de una
colección de elementos de modelado, a menudo
dibujada como un grafo con vértices conectados
Modelos y DiagramasModelos y Diagramas

59. 59
Modelo de
Casos de Uso
Modelo de
Diseño
Modelo de
Implementación
Trazabilidad entre
los modelos
Secuencia
cronológica
ModelosModelos
Modelo de
Despliegue
Modelo de
Análisis
Modelo de
Prueba

60. 60
Diagramas de UML
Diagrama ¿Dónde aparece?
Caso de uso 1.x
Actividad 1.x
Clase 1.x
Objeto Informalmente 1.x
Secuencia 1.x
Comunicación Antes de Colaboración en 1.x
Tiempo 2.0
Estructura interna 2.0
Componente 1.x, pero cambia su significado en 2.0
Paquete 2.0
Estado 1.X
Despliegue 1.x
Estructura Dinámica Física Gestión del modelo

61. 61
Modelo de
Casos de Uso
Modelos y Diagramas
Diagrama de Casos de
Uso del Negocio
Diagrama de Secuencia
Diagrama de Comunicación
Diagrama de Casos de
Uso del Sistema
Diagrama de Actividades
Diagrama de Estado
Diagrama de Paquetes

62. 62
• Casos de Uso y Diagramas de Casos de Uso
Diagramas de UML
Casos de uso
Diagrama de casos de uso

63. 63
 Casos de Uso es una técnica para
capturar información de cómo un
sistema o negocio trabaja, o de cómo se
desea que trabaje
 No pertenece estrictamente al enfoque
orientado a objeto, es una técnica para
captura de requisitos
Diagrama de casos de uso
Cliente
Solicitar Préstamo

64. 64
• Diagramas de estructura estática
• Diagrama de clases
• Diagrama de Objetos
Diagramas de UML

65. 65
 Un diagrama de clases presenta las clases
del sistema con sus relaciones estructurales
y de herencia
 La definición de clase incluye definiciones
para atributos y operaciones
 El modelo de casos de uso aporta
información para establecer las clases,
objetos, atributos y operaciones
Diagrama de clases
ProfesorDepartamento
0..1 1..*0..1

66. 66
Diagramas UML
• Diagramas del comportamiento
•Diagramas de Estado
•Diagramas de Actividad
•Diagramas de Secuencia
•Diagrama de Comunicación
•Diagrama de tiempo
Diagrama de Secuencia Diagrama de Comunicación

67. 67
con préstamos
sin préstamos
alta baja
prestar devolver[ número_préstamos = 1 ]
prestar
devolver[ número_préstamos > 1 ]
número_préstamos = 0
número_préstamos > 0
Socio
número : int
nombre : char[50]
número_prestamos : int = 0
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date)
Diagrama de estado

68. 68
Diagrama de actividades
Buscar bebida
¿hay café?
Poner café en
filtro
Añadir agua al
depósito
Coger taza
Poner filtro en
máquina
Encender
máquina
Hacer café
Servir café Beber
Servir jugo
¿hay jugo?
SÍ
NO
NO
SÍ

69. 69
Diagrama de secuencia
: Encargado
:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo

70. 70
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo
5: entregar recibo
Diagrama de comunicación

71. 71
• Diagramas de implementación
• Diagramas de componentes
• Diagramas de instalación/Distribución
(Despliegue)
Diagramas de UML
Diagrama de componentes

72. 72
Interfaz de Terminal
Gestión de Cuentas Rutinas de conexión Acceso a BD
Control y Análisis
Diagrama de componentes

73. 73
Diagrama de despliegue
Punto de Venta
Servidor Central
Terminal de Consulta
Gestión de Cuentas
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Rutinas de Coneccion
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Acceso a BD
Comment
Control y Análisis
Comment

74. 74
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.
¿Cómo se relacionan los diagramas?
Solo para comprender la
secuencia de pasos

75. 75
¿Cómo se relacionan los diagramas?
Solo para comprender la
secuencia de pasos
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.

76. 76
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.
¿Cómo se relacionan los diagramas?
Solo para comprender la
secuencia de pasos

77. 77
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.
¿Cómo se relacionan los diagramas?
Solo para comprender la
secuencia de pasos
¿Cómo se relacionan los diagramas?

78. 78
 UML define una notación que se expresa
como diagramas sirven para representar
modelos/subsistemas o partes de ellos
 El 80 por ciento de la mayoría de los
problemas pueden modelarse usando
alrededor del 20 por ciento de UML--
Grady Booch
Resumen

79. 79
El Proceso Unificado de
Desarrollo
(Rational Unified Process- RUP)

80. 80
Rational Unified Process
RUP es un proceso para el desarrollo de
software orientado a objeto que utiliza UML
para describir un sistema
Rational Software Corporation, 1998

81. 81
Rational Unified
Process 5.0
Rational Objectory
Process 4.1
Rational Objectory
Process 4.0
Rational
Approach Objectory
Process
Pruebas de rendimiento y carga
(Performance Awareness)
Ingeniería de Negocios
Diseño OO de IU
Ingeniería de Datos
(Vigortech)
UML 1.2
Proceso SQA
(SQA Inc.)
UML 1.0
Administración de
Configuración y Cambios
(Pure-Atria)
Escuela de
Requerimientos
(Requisite Inc.)
OMT
Booch
UML 0.8
1998
1997
1996
1995
Ericsson
method1967
1987
Evolución de RUP

82. 82
Estructura Estática de RUP
Fases e Iteraciones
Disciplinas del Proceso
Actividades, flujo de trabajo
Artefactos
Modelos, reportes, documentos
Trabajadores
¿Cómo ocurre el
proceso y sus
detalles?
¿Qué se produce u
obtiene?
¿Quién lo hace o se
responsabiliza?
¿Cuándo ocurre el
proceso?

83. 83
Estructura Dinámica
Tiempo
Concepción Elaboración Construcción Transición
• 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.

84. 84
Fases-Flujos de trabajo de RUP

85. 85
Características del ciclo de vida de
RUP
• Dirigido por Casos de Uso.
• Centrado en la arquitectura.
• Iterativo e incremental.

86. 86
Dirigido por Casos de Uso
Ciclo de vida de RUP
(Reflejar lo que los futuros usuarios
necesitan y desean)
Representa los
requerimientos
funcionales
Requisitos Análisis Diseño Implementación Prueba
Caso de Uso
Guían el proceso de desarrollo porque
los modelos que se crean llevan a
cabo los casos de uso.

87. 87
Caso de Uso Realización de Análisis Realización de Diseño
Caso de Prueba
X
«trace» «trace»
«trace»
«trace»
Pruebas Funcionales
Pruebas
Unitarias
Dirigido por Casos de Uso
Ciclo de vida de RUP

88. 88
Dirigido por Casos de Uso
Ciclo de vida de RUP

89. 89
Centrado en la arquitectura
Ciclo de vida de RUP
En la construcción,
vista de:
A) Estructura.
B) Calefacción.
C) Plomería.
D) Electricidad.
Estáticos
Dinámicos
Aspectos

90. 90
Centrado en la arquitectura
Ciclo de vida de RUP
(Visión común del sistema completo en la que
desarrolladores y usuarios deben estar de acuerdo )
• Describe los elementos del modelo que son más
importantes para su construcción, los cimientos del
sistema que son necesarios como base para
comprenderlo, desarrollarlo y producirlo
económicamente.
• Se desarrolla mediante iteraciones comenzando por los
CU relevantes desde el punto de vista de la
arquitectura.

91. 91
Centrado en la arquitectura
Ciclo de vida de RUP
Vista lógica
Vista de
componentes
Vista de
despliegue
Vista física
Vista de
Casos de uso Vista de
diseño
Vista de
actividades
Vista de
estado
Vista
estática Vista de
Casos de uso
Vista de
despliegue
Vista de
componentes
Vista de
Gestión del
modelo
Perfil

92. 92
Iterativo e incremental
Ciclo de vida de RUP
Hito de losHito de los
objetivosobjetivos
Hito de laHito de la
arquitecturaarquitectura
Hito de laHito de la
funcionalidadfuncionalidad
operativaoperativa
Hito de laHito de la
versión delversión del
productoproducto
• Dentro de cada fase hay hitos (artefactos a construir)
asociados a resultados de cada iteración.
• La terminación de una iteración produce un nuevo
incremento.

93. 93
Enfoque
Cascada
Enfoque
Iterativo e
Incremental
Iterativo e incremental
Ciclo de vida de RUP

94. 94
Grado de Finalización de Artefactos
Iterativo e incremental
Ciclo de vida de RUP

95. 95
Beneficios de la iteración
•Reduce el coste del riesgo al coste de un
solo incremento.
•Menos riesgo de no sacar el producto al
mercado en fecha.
•Acelera el ritmo de desarrollo.
•Las necesidades del usuario y
correspondientes requisitos no pueden
definirse completamente al principio. Se
requieren iteraciones sucesivas.

96. 96
RUP
• RUP es un proceso que garantiza la elaboración
de todas las fases de un producto de software
orientado a objetos.
•RUP es dirigido por los casos de uso, centrado en
la arquitectura, iterativo e incremental.
• RUP utiliza el UML.
• UML es un lenguaje que permite la modelación
de sistemas con tecnología orientada a objetos

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