Curso de UML

Actividad 1 Introduccin a UML

Dra. Anaisa Hernndez Gonzlez

Construccin de una casa para fido

Puede hacerlo una sola persona

Requiere:
Modelado mnimo
Proceso simple
Herramientas simples

Construccin de una casa

Construida eficientemente y en un tiempo

razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas ms sofisticadas

Construccin de un rascacielos

Problemas de la Industria de Software

en la actualidad
1

Tendencia al crecimiento del

volumen y complejidad de
los productos.
Proyectos excesivamente tardes y
se exige mayor productividad y
calidad en menos tiempo.
Insuficiente personal calificado.

Por qu fallan los

Proyectos de Software?

Planificacin Irreal

Mala Calidad del Trabajo

Personal Inapropiado

No Controlar los Cambios

6

Planificacin Irreal

El sistema es para hoy y con costo 0

Los ingenieros no son capaces de
enfrentar un plan porque:
NO estn entrenados para usar mtodos
de planificacin.
Frecuentemente, las estimaciones NO
se basan en datos reales.
7

Mala Calidad del Trabajo

CAUSAS
Prcticas pobres de ingeniera
Carencia de mtricas de calidad
Inadecuado entrenamiento en calidad
Decisiones de los directivos guiadas
por una planificacin irreal

Mala Calidad del Trabajo

CONSECUENCIAS

Tiempos de pruebas impredecibles

Productos con muchos defectos
Demoras en la aceptacin de los usuarios
Extensa garanta de servicio y reparaciones

Una pobre calidad afecta la

planificacin y torna ineficente el
proceso de prueba
9

Personal Inapropiado

PROBLEMAS

COMUNES

Demora del personal

Escaso personal
Miembros del equipo a tiempo parcial
Personal con conocimientos
inapropiados

El trabajo se demora o descuida

CONSECUENCIAS Trabajo ineficiente
Sufre la moral del equipo

Con independencia del plan, los

proyectos deben comenzar en tiempo
y con todo el personal.
10

Cambios NO controlados

HECHOS a RECORDAR:
Siempre ocurren cambios en los requerimientos.
Los planes del proyecto se basan en el alcance del
trabajo conocido.
Los cambios siempre requieren ms 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
11

Cmo enfrentarla?

Las organizaciones requieren:

1
2

Desarrollar o adquirir una disciplina

en el desarrollo del software.
Controlar que los ingenieros usen de
forma consistente los nuevos mtodos.
12

Cmo?

Qu debe hacer una

empresa para obtener
software de buena
calidad?
Mejorar el proceso de
desarrollo de software

Cualquier modelo de calidad para

mejorar el Proceso de Desarrollo de
Software, IMPLICA utilizar los
mtodos y procedimientos de

INGENIERIA Y GESTION
DE SOFTWARE
14

Qu es la Ingeniera de Software (IS)?

...la aplicacin de un enfoque

sistmico,
disciplinado
y
cuantificable hacia el desarrollo,
funcionamiento y mantenimiento
de software, es decir la aplicacin
de ingeniera al software
IEEE,1993
15

IS es una tecnologa multicapa

Indican cmo construir
tcnicamente el Sw.
Soporte automtico o
semiautomtico para el
proceso y los mtodos.
Es el fundamento de la
IS. Es la unin que
mantiene juntas las
capas de la tecnologa.
16

Sntomas - Causas
Sntomas

Diagnstico

necesidades usuarios
requerimientos
cambiantes

Causas

requerimientos
insuficientes
comunicacin ambigua

mdulos no calzan

arquitecturas frgiles

poco mantenible

complejidad excesiva

tarda deteccin

inconsistencias no
detectadas

baja calidad

prueba pobre

baja performance

evaluacin subjetiva

versiones y cambios

desarrollo en cascada

liberacin y
distribucin

cambios no controlados

...tratar los Sntomas no

automatizacin
insuficiente
resuelve
el problema
17

Las Mejores Prcticas de la IS

atacan las causas
Desarrolle Iterativamente
Use
Administre
arquitectura
Modele
Requerimientos
Visualmente
de
componentes

Verique
Calidad

Controle Cambios
18

Mejores Prcticas de Software

Son propuestas de desarrollo probadas
comercialmente, que usadas en forma
combinada atacan la raz de las causas de
las fallas, eliminando los sntomas y
permitiendo el desarrollo y mantenimiento de
software de calidad de manera predictiva y
reiterativa.
19

Mejores Prcticas: Equipos de Alto

Rendimiento
Resultado
Proyectos ms exitosos
porque estn en plazo,
en presupuesto y
satisfacen las
necesidades del usuario

Ing. de
Performance
Analisis

Jefe de
Proyecto

Develop Iteratively

Manage
Requireme
nts

Use
Component
Architectures

Model
Visually

Verify
Quality

Desarrollador

Probador

Control Changes

Liberacin y Distribucin

20

Enfrentando las Causas se eliminan los Sntomas

SNTOMAS
necesidades usuarios
requerimientos
cambiantes
mdulos no calzan
poco mentenible
tarda deteccin
baja calidad
baja performance
versiones y cambios
liberacin y distribucin

CAUSAS
Requerimientos
insuficientes
Comunicacin ambigua
arquitecturas frgiles
complejidad excesiva
inconsistencias no
detectadas
testing pobre

MEJORES PRCTICAS
desarrolle iterativamente
adm. requerimientos
use arquitectura de
componetes
modele el software
visualmente
verifique calidad
controle cambios

evaluacin subjetiva
desarrollo en cascada
cambios no controlados
automatizacin
insuficiente

21

Mejores Prcticas se refuerzan entre si

Administre
Asegura participacin del usuario
mientrs evolucionan requerimientos Requerimientos

Desarrolle
Iterativamente

Valida tempranamente
las decisiones arquitectnicas

Use
Arquitecturas
de Componentes

Pemite manejar la complejidad

de disear incrementalmente

Modele
Visualmente

Mide la calidad en forma oportuna

y frecuente
Evoluciona la lnea base
incrementalmente

Verique
Calidad

Controle
Cambios

22

Mejores prcticas para el trabajo

efectivo de un equipo en el
desarrollo del software.

(Dirige y organiza el proceso)

(Notacin)

23

Sumario

Conceptos bsicos del modelo de objetos

Proceso de desarrollo de software.
El Lenguaje Unificado de Modelacin (UML)
El Proceso Unificado de Desarrollo de
Software (RUP)

24

fa
a
r
iog
l
b
Bi

Lecturas Recomendadas

BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar;

El Lenguaje Unificado de Modelacin. Libro
introductorio.2000. Addison Wesley.
RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady;
El Lenguaje Unificado de Modelacin. Manual de
referencia.2000. Addison Wesley.
JACOBSON, Ivar; BOOCH, Grady, RUMBAUGH, James,
El Proceso Unificado de Desarrollo de Software.2000.
Addison Wesley.

LARMAN, Craig UML y patrones 1999, Prentice Hall

Iberoamericana.

25

fa
a
r
iog
l
b
Bi

Lecturas Recomendadas

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
CONALLEN, Jim, Building Web Applications with
UML.2002. 2nd edition. Addison Wesley.

26

Conceptos bsicos del Modelo

de Objetos

27

Enfoque Orientado a Objetos

Se basa en conceptos y relaciones entre ellos.
Todo
Objetos

Atributos
blanco
Partes
28

Enfoque Orientado a Objetos

Tipo de Objeto:
Descripcin generalizada que describe una
coleccin de objetos similares.
Clase:
Implementacin en software de un tipo de
objeto.
Tlibro = class
private

. . .
end;
29

Enfoque orientado a Objetos

Mtodo:
Implementacin en software de la operacin.

Cambiar luz

TSemforo = class
.....
Cambiar luz();
end;
30

Enfoque Orientado a Objetos

Encapsulamiento
Empaque conjunto de datos y mtodos.
Operaciones

Atributos

31

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 operacin con
un mtodo diferente.

32

Proceso de Desarrollo de
Software

33

Proceso
Define quin est haciendo qu, cundo y
cmo para alcanzar un determinado objetivo.

Proceso de desarrollo de software (PDS)

Requisitos del usuario

Sistema informtic
34

Proceso de desarrollo de software (PDS)

35

Proceso de desarrollo de software (PDS)

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
cundo
asignacin de tareas a cada miembro del
equipo y al equipo como un todo
proporcionar heursticas
criterios para controlar el proceso
36

UML

37

Lenguaje de modelacin
Puede ser un seudocdigo, cdigo,
imgenes, diagramas, o largos paquetes
de descripcin; es decir, cualquier cosa
que ayude a describir un sistema

+
38

Lenguaje de modelacin

(Forma de (Descripcin de
expresar el lo que significa
modelo) esa modelacin)

39

Notacin visual
Manejar la complejidad

Interface de Usuario
(Visual Basic,
Java, ..)

Lgica del Negocio

(C++, Java, ..)

Mltiples Sistemas

Servidor de BDs
(C++ & SQL, ..)

Modelar el sistema
independientemente
del lenguaje de
implementacin

Componentes
Reutilizados

Promover la Reutilizacin

40

Situacin de partida
Diversos mtodos y tcnicas OO, con muchos aspectos en
comn pero utilizando distintas notaciones
Inconvenientes para el aprendizaje, aplicacin,
construccin y uso de herramientas, etc.
Pugna entre distintos enfoques (y correspondientes
gurs)

41

UML
Qu es el UML- Unified
Modeling Language?
Lenguaje Unificado de Modelacin

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 metodologas. 42

UML
Qu es el UML- Unified
Modeling Language?
Lenguaje Unificado de Modelacin

Ofrece un estndar 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
programacin, esquemas de BD y componentes de
43
software reutilizables.

UML

Visualizar

Construir

Especificar

Documentar
44

UML no es un mtodo
El UML es una gua al desarrollador para realizar
el anlisis y diseo orientado a objetos, es un
proceso
El UML es un lenguaje que permite la modelacin
de sistemas con tecnologa orientada a objetos

Aprobado como estndar por OMG en

noviembre de 1997
45

Orgenes de UML

El esfuerzo de UML parti oficialmente en

octubre de 1994, cuando Rumbaugh se uni a
Booch en Rational.
El Mtodo Unificado en su Versin 0.8, se
present en el OOPSLA95
El mismo ao se uni Ivar Jacobson. Los Tres
Amigos son socios en la compaa Rational
Software. Herramienta CASE Rational Rose
46

Creacin del UML

UML 2.0
UML 1.5

OMG Acceptance, Nov 1997 Version 1.1

Final submission to OMG, Sep 97
public
feedback

UML 1.1

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

47

Por qu UML 2.0?

Las primeras versiones de UML estaban ms

orientadas hacia la modelacin del software y
ahora se requiere ms la modelacin del sistema.
Necesidad de compartir modelos entre diferentes
herramientas.
Nuevas tecnologas: Arquitectura basada en
componentes, MDA
Las primeras versiones estaban ms diseadas
para las personas y no para las mquinas, por lo
que hay construcciones que no estaban
suficientemente formalizadas.
48

Las Bases de UML

Booch,
Rumbaugh
Jacobson

Rational Software
Corporation. (1995)

JAMES Object Modelling Technique 1991(OMT)

RUMBAUGH
GRADY
BOOCH

Object Oriented Analysis and Design

with Applications 1994

IVAR Object Oriented Software Engineering: A

JACOBSON Use Case Driven Approach 1992 (OOSE)
49

Premisas de UML segn

Booch, Jacobson y Rumbaugh

Modelar sistemas, a partir de los

conceptos hacia los artefactos ejecutables,
utilizando tcnicas orientadas a objeto.
Enfocarnos en las cuestiones de escala
inherentes a sistemas complejos, crticos
en su misin.
Crear un lenguaje de modelacin
utilizable tanto por los humanos, como
por las mquinas.
50

Contribuciones a UML
Diagrama de Casos de uso
OOSE/Jacobson

Diagrama de Clases
Diagrama de Objetos

OOAD/Booch
OMT/Rumbaugh

Diagrama de Secuencia
Diagrama de Estado
Diagrama de Componentes
Diagrama de Estructura Compuesta
Diagrama de Paquetes

Otras mejores
prcticas

Diagrama de Comunicacin
Diagrama de Actividad
Diagrama de Tiempo
Diagrama de Despliegue

51

Ventajas de UML
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 notacin simple.
Es comprensible porque describe todos los
aspecto importante del sistema.
Es escalable por lo que permite describir
proyectos de diferentes tamaos.
52

Ventajas de UML
Contiene las mejores prcticas de la
comunidad orientada a objetos de los
ltimos 15 aos.
Es un estndar abierto.
Da soporte a todo el ciclo de vida de
desarrollo del software.
Da soporte a diversas reas de aplicacin.
Est soportado por muchas herramientas.
53

Limitaciones de UML
Carece de un semntica precisa, lo que ha
dado lugar a que la interpretacin de un
modelo UML no pueda ser objetiva en
ocasiones.
No se presta con facilidad al diseo de
sistemas distribuidos. En estos sistemas
son importantes factores como transmisin,
serializacin, persistencia, etc. No se puede
sealar si un objeto es persistente o
remoto.
54

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 inters

55

Qu es un producto de software?
Un producto de software es el cdigo
mquina 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 mquinas.
artefactos?

Los trabajadores.
Los usuarios.
Los interesados.
56

Artefactos?
Trmino general aplicable a
cualquier tipo de informacin
creada, cambiada o utilizada por
los trabajadores en el desarrollo
del sistema
Ejemplos:
Diagramas UML y su texto.
Bocetos de interfaz.
Planes de prueba.
57

Modelos y Diagramas

Un modelo captura una vista de un sistema del

mundo real. Es una abstraccin de dicho sistema,
considerando un cierto propsito. As, el modelo
describe completamente aquellos aspectos del
sistema que son relevantes al propsito del
modelo, y a un apropiado nivel de detalle.

Diagrama: una representacin grfica de una

coleccin de elementos de modelado, a menudo
dibujada como un grafo con vrtices conectados
por arcos

58

Modelos

Modelo de
Casos de Uso

Modelo de
Anlisis

Modelo de
Diseo

Secuencia
Trazabilidad entre
cronolgica
los modelos

Modelo de
Prueba

Modelo de
Implementacin

Modelo de
Despliegue
59

Diagramas de UML
Diagrama

Dnde aparece?

Caso de uso

1.x

Actividad

1.x

Clase

1.x

Objeto

Informalmente 1.x

Secuencia

1.x

Comunicacin

Antes de Colaboracin 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

Dinmica

Fsica

Gestin del modelo

60

Modelos y Diagramas
Diagrama de Casos de
Uso del Negocio
Diagrama de Casos de
Uso del Sistema
Diagrama de Actividades

Modelo de
Casos de Uso

Diagrama de Secuencia
Diagrama de Comunicacin
Diagrama de Estado
Diagrama de Paquetes
61

Diagramas de UML
Casos de Uso y Diagramas de Casos de Uso

Casos de uso
Diagrama de casos de uso

62

Diagrama de casos de uso

Casos de Uso es una tcnica para
capturar informacin de cmo un
sistema o negocio trabaja, o de cmo
se desea que trabaje
No pertenece estrictamente al
enfoque orientado a objeto, es una
tcnica para captura de requisitos

Cliente

Solicitar Prstamo 63

Diagramas de UML
Diagramas de estructura esttica
Diagrama de clases
Diagrama de Objetos

64

Diagrama de clases
Un diagrama de clases presenta las clases
del sistema con sus relaciones
estructurales y de herencia
La definicin de clase incluye definiciones
para atributos y operaciones
El modelo de casos de uso aporta
informacin para establecer las clases,
objetos, atributos y operaciones
Departamento

Profesor

0..1

1..*

65

Diagramas UML

Diagramas del comportamiento

Diagramas de Estado
Diagramas de Actividad
Diagramas de Secuencia
Diagrama de Comunicacin
Diagrama de tiempo

Diagrama de Secuencia

Diagrama de Comunicacin
66

Diagrama de estado
alta

baja

Socio
nmero : int
nombre : char[50]
nmero_prestamos : int = 0

sin prstamos

nmero_prstamos = 0

alta()
baja()
prestar(cdigo_libro : int, fecha : date)
devolver(cdigo_libro : int, fecha : date)

prestar

devolver[ nmero_prstamos = 1 ]

nmero_prstamos > 0
con prstamos
prestar

devolver[ nmero_prstamos > 1 ]

67

Diagrama de actividades
Buscar bebida

hay caf?

NO

S
Poner caf en
filtro

Aadir agua al
depsito

hay jugo?
S

Coger taza

Servir jugo

Servir caf

Beber

NO

Poner filtro en
mquina

Encender
mquina

Hacer caf

68

Diagrama de secuencia

: Encargado

:WInPrstamos

:Socio

:Video

:Prstamo

prestar(video, socio)
verificar situacin socio
verificar situacin video
registrar prstamo
entregar recibo

69

Diagrama de comunicacin
:Socio

:Video
2: verificar situacin socio

1: prestar(video, socio)

3: verificar situacin video

:WInPrstamos

5: entregar recibo
: Encargado

4: registrar prstamo

:Prstamo

70

Diagramas de UML
Diagramas de implementacin
Diagramas de componentes
Diagramas de instalacin/Distribucin
(Despliegue)

Diagrama de componentes
71

Diagrama de componentes
Interfaz de Terminal

Gestin de Cuentas

Rutinas de conexin

Control y Anlisis

Acceso a BD

72

Diagrama de despliegue
Servidor Central

Control y Anlisis
Comment

Acceso a BD
Comment
Rutinas de Coneccion
Comment

Terminal de Consulta
Rutinas de Coneccion
Comment
Punto de Venta

Interfaz de Terminal
Comment

Rutinas de Coneccion
Comment

Gestin de Cuentas

Interfaz de Terminal

Comment

Comment

73

Cmo se relacionan los diagramas?

So
lo
se para
cu
en com
cia p
de ren
pa der
so la
s

Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.

74

Cmo se relacionan los diagramas?

So
lo
se para
cu
en com
cia p
de ren
pa der
so la
s

Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.

75

Cmo se relacionan los diagramas?

So
lo
se para
cu
en com
cia p
de ren
pa der
so la
s

Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.

76

Cmo se relacionan los diagramas?

So
lo
se para
cu
en com
cia p
de ren
pa der
so la
s

Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use case driven object
modeling with UML: an annotated e-commerce example.

77

Resumen
UML define una notacin que se expresa
como diagramas sirven para representar
modelos/subsistemas o partes de ellos
El 80 por ciento de la mayora de los
problemas pueden modelarse usando
alrededor del 20 por ciento de UML-Grady Booch

78

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

79

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

80

Evolucin de RUP
1998

Pruebas de rendimiento y carga

(Performance Awareness)
Ingeniera de Negocios
Administracin de
Configuracin y Cambios
(Pure-Atria)

1997

1996

1995
1987
1967

Escuela de
Requerimientos
(Requisite Inc.)

OMT
Booch

Rational Unified
Process 5.0

Diseo OO de IU
Ingeniera de Datos
(Vigortech)
UML 1.2

Rational Objectory
Process 4.1

Proceso SQA
(SQA Inc.)
UML 1.0

Rational Objectory
Process 4.0
Rational
Approach

Objectory
Process

UML 0.8

Ericsson
81
method

Estructura Esttica de RUP

Fases e Iteraciones
Disciplinas del Proceso
Actividades, flujo de trabajo

Cundo ocurre el
proceso?
Cmo ocurre el
proceso y sus
detalles?

Artefactos
Modelos, reportes,
documentos

Qu se produce u
obtiene?

Trabajadores

Quin lo hace o se
responsabiliza?
82

Estructura Dinmica
Concepcin

Elaboracin

Construccin

Transicin

Tiempo

Concepcin

Define el alcance del proyecto y el

desarrollo de los casos del negocio.

Elaboracin

Planifica el proyecto, especifica

las caractersticas y define los
cimientos de la arquitectura.

Construccin Construye el producto.

Transicin

Implementa el producto a sus

83
usuarios.

Fases-Flujos de trabajo de RUP

84

Caractersticas del ciclo de vida de

RUP
Dirigido por Casos de Uso.
Centrado en la arquitectura.
Iterativo e incremental.

85

Ciclo de vida de RUP

Dirigido por Casos de Uso
(Reflejar lo que los futuros usuarios
necesitan y desean)
Caso de Uso
Requisitos

Representa los
requerimientos
funcionales

Anlisis

Diseo

Implementacin Prueba

Guan el proceso de desarrollo porque

los modelos que se crean llevan a
cabo los casos de uso.
86

Ciclo de vida de RUP

Dirigido por Casos de Uso
trace
Caso de Uso

trace

Realizacin de Anlisis Realizacin de Diseo

trace

trace

Pruebas
Unitarias
Pruebas Funcionales

Caso de Prueba

87

Ciclo de vida de RUP

Dirigido por Casos de Uso

88

Ciclo de vida de RUP

Centrado en la arquitectura

En la construccin,
vista de:
A) Estructura.
B) Calefaccin.
C) Plomera.
D) Electricidad.

Estticos

Aspectos
Dinmicos

89

Ciclo de vida de RUP

Centrado en la arquitectura
(Visin comn del sistema completo en la que
desarrolladores y usuarios deben estar de acuerdo )
Describe los elementos del modelo que son ms
importantes para su construccin, los cimientos del
sistema que son necesarios como base para
comprenderlo, desarrollarlo y producirlo
econmicamente.
Se desarrolla mediante iteraciones comenzando por los
CU relevantes desde el punto de vista de la
arquitectura.
90

Ciclo de vida de RUP

Centrado en la arquitectura

Vista fsica

Vista lgica

Vista de
Casos de uso
Vista de
despliegue

Vista de
componentes

Vista de
despliegue
Vista
esttica
Vista de
estado

Vista de
componentes

Vista de
Casos de uso
Vista de
actividades

Vista de
diseo
Perfil

Vista de
Gestin del
modelo
91

Ciclo de vida de RUP

Iterativo e incremental
Hito de los
objetivos

Hito de la
arquitectura

Hito de la
Hito de la
funcionalidad versin del
operativa
producto

Dentro de cada fase hay hitos (artefactos a construir)

asociados a resultados de cada iteracin.
La terminacin de una iteracin produce un nuevo
92
incremento.

Ciclo de vida de RUP

Iterativo e incremental
Enfoque
Cascada

Enfoque
Iterativo e
Incremental
93

Ciclo de vida de RUP

Iterativo e incremental
Grado de Finalizacin de Artefactos

94

Beneficios de la iteracin
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.

95

RUP
RUP es un proceso que garantiza la elaboracin
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 modelacin

de sistemas con tecnologa orientada a objetos
96

UML y RUP

Desarrollo
en equipos

Lenguaje de
Modelamiento

Proceso
Unificado

97