Curso UML

Departamento de Sistemas Informáticos y Computación
Universidad Politécnica de Valencia
Desarrollo de Software
Orientado a Objeto usando UML
Patricio Letelier Torres
letelier@dsic.upv.es
Departamento Sistemas Informáticos y Computación (DSIC)

Universidad Politécnica de Valencia (UPV) - España
1
www.dsic.upv.es/~uml
Contenido
I. Introducción
– Modelado de Software
– UML
II. Breve Tour por UML
III. El Paradigma Orientado a Objeto usando UML
– Fundamentos del Modelado OO
– Requisitos del software
– Interacción entre objetos
– Clases y relaciones entre clases
– Comportamiento de objetos
– Componentes
– Distribución y despliegue de componentes
– Object Constraint Language (OCL)
IV. Proceso de Desarrollo de SW basado en UML
V. Conclusiones
2
www.dsic.upv.es/~uml 1
I
Introducción
3
Introducción: Modelado de SW
4
I. Introducción: Modelado de SW
Construcción de una casa para “fido”
Puede hacerlo una sola persona

Requiere:
Modelado mínimo
Proceso simple
Herramientas simples
5
Construcción de una casa
Construida eficientemente y en un tiempo

razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
6
Construcción de un rascacielos
7
Claves en Desarrollo de SI
Notación
Herramientas Proceso
8
Abstracción - Modelado Visual (MV)
“El modelado captura las

partes esenciales del sistema”
Orden
Item
envío
Proceso de Negocios
Sistema Computacional
9
II. Notación (Visual) - Beneficios

Manejar la complejidad
Interface de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)
Múltiples Sistemas
Servidor de BDs
(C++ & SQL, ..)
“Modelar el sistema
independientemente Componentes
del lenguaje de Reutilizados
implementación”
Promover la Reutilización
10
Introducción: UML
11
I. Introducción: UML
¿Qué es UML?
UML = Unified Modeling Language
Un lenguaje de propósito general para el
modelado orientado a objetos. Impulsado por el
Object Management Group (OMG, www.omg.org)
Documento “OMG Unified Modeling Language
Specification”
UML combina notaciones provenientes desde:
• Modelado Orientado a Objetos
• Modelado de Datos
• Modelado de Componentes
• Modelado de Flujos de Trabajo (Workflows)
12
Situación de Partida
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)
Establecer una notación estándar
13
Historia de UML
Comenzó como el “Método Unificado”, con la
participación de Grady Booch y Jim Rumbaugh.
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
14
Historia de UML
2005? UML 2.0
2003 UML 1.5
2000 UML 1.4
1999 UML 1.3 Revisiones menores
1998 UML 1.2
Nov ‘97 UML aprobado

por el OMG
15
Participantes en UML 1.0

Rational Software MCI Systemhouse
(Grady Booch, Jim Rumbaugh y Microsoft
Ivar Jacobson)
Digital Equipment ObjecTime
Hewlett-Packard Oracle Corp.
i-Logix (David Harel) Platinium Technology
IBM Sterling Software
ICON Computing Taskon
(Desmond D’Souza)
Texas Instruments
Intellicorp and James
Martin & co. (James Odell) Unisys
16
UML “aglutina” enfoques OO

Rumbaugh
Booch Jacobson
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
17
Aspectos Novedosos
Definición semi-formal del Metamodelo de UML
Mecanismos de Extensión en UML:
Stereotypes
Constraints
Tagged Values
Permiten adaptar los elementos de modelado,
asignándoles una semántica particular
18
Inconvenientes en UML
Definición del proceso de desarrollo usando UML. UML
no es una metodología
No cubre todas las necesidades de especificación de un
proyecto software. Por ejemplo, no define los
documentos textuales
Ejemplos aislados
“Monopolio de conceptos, técnicas y métodos en torno

a UML y el OMG”
19
Perspectivas de UML
UML es el lenguaje de modelado orientado a objetos
estándar predominante ahora y en los próximos años
Razones:
• Participación de metodólogos influyentes
• Participación de importantes empresas
• Estándar del OMG
Evidencias:
• Herramientas que proveen la notación UML
• “Edición” de libros (más de 300 en www.amazon.com)
• Congresos, cursos, “camisetas”, etc.
20
II
Breve Tour por UML
21
Modelos y Diagramas
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 completa-
mente 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 por arcos
OMG UML 1.4 Specification
22
... Modelos y Diagramas

Un proceso de desarrollo de software debe ofrecer un conjunto
de modelos que permitan expresar el producto desde cada una
de las perspectivas de interés
El código fuente del sistema es el modelo más detallado del

sistema (y además es ejecutable). Sin embargo, se requieren
otros modelos ...
Cada modelo es completo desde su punto de vista del sistema,

sin embargo, existen relaciones de trazabilidad entre los
diferentes modelos
23
Diagramas de UML 1.5

Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Objetos
Diagramas de Comportamiento
Diagrama de Estados
Diagrama de Actividad
Diagramas de Interacción
Diagrama de Secuencia
Diagrama de Colaboración
Diagramas de implementación
Diagrama de Componentes
Diagrama de Despliegue
24
... Diagramas de UML

Los diagramas expresan gráficamente partes de un modelo
State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboración Modelos Componentes
Scenario Component
Scenario Component
Diagramas
Diagrams de
Diagramas de
Diagrams Diagrams
Diagrams Distribución
Estados Diagramas de
Actividad
25
Organización de Modelos
4+1 vistas de Kruchten (1995)
Vista de
Vista Lógica Realización
Vista de los
Casos de Uso
Vista de Vista de
Procesos Distribución
Este enfoque sigue el browser de Rational Rose

26
... Organización de Modelos
Propuesta de Rational Unified Process (RUP)

M. de Casos de Uso del Negocio (Business Use-Case Model)
M. de Objetos del Negocio (Business Object Model)
M. de Casos de Uso (Use-Case Model)
M. de Análisis (Analysis Model)
M. de Diseño (Design Model)
M. de Despliegue (Deployment Model)
M. de Datos (Data Model)
M. de Implementación (Implementation Model)
M. de Pruebas (Test Model)
27
Paquetes en UML
Los paquetes ofrecen un mecanismo general para
la organización de los modelos/subsistemas
agrupando elementos de modelado
Se representan gráficamente como:
Nombre de
paquete
28
… Paquetes en UML
Cada paquete corresponde a un submodelo
(subsistema) del modelo (sistema)
Un paquete puede contener otros paquetes, sin

límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete
Una clase de un paquete puede aparecer en

otro paquete por la importación a través de una
relación de dependencia entre paquetes
29
… Paquetes en UML
Todos los elementos no son
necesariamente visibles desde el
exterior del paquete, es decir,
un paquete encapsula a la vez
que agrupa
El operador “::” permite

designar una clase definida en
un contexto distinto del actual
30
...Paquetes en Rational Rose

Customers
Otra Cl ase
Customers
CheckingAccount
<<access>> (f rom Banking)
Banking Banking
CheckingAccount
31
… Paquetes en UML
Práctica 1
32
Diagrama de Casos de Uso
Casos de Uso es una técnica para capturar

información respecto de los servicios que un
sistema proporciona a su entorno
No pertenece estrictamente al enfoque

orientado a objeto, es una técnica para captura
y especificación de requisitos
33
… Ejemplos
Ejemplo:
Retirar dinero
Consult ar E xt ract o
Cliente
Realizar transferencia
Práctica 2
34
: WInP réstamos :Socio :Video : Préstamo

: Encargado
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
35
:Socio
:Video
2: verificar situación socio
1: prestar(video, socio) 3: verificar situación video

:WInPréstamos
5: entregar recibo
: Encargado 4: registrar préstamo
:Préstamo
Práctica 3
36
Diagrama de Clases
El Diagrama de Clases es el diagrama principal para el
análisis y diseño del sistema
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 debería aportar
información para establecer las clases, objetos,
atributos y operaciones
37
Ejemplos (Clase y Visibilidad)
A lum no
DNI : char[10]
núm ero_ex p : int
nom bre : c har[50]
alta()
poner_nota(as ignatura : c har *, año : int, nota : float)
m atric ular(c ursos : asignatura, año : int)
listar_expediente()
38
… Ejemplos (Asociación)
dirige direc tor

Departam ento Profes or
0..1 1
39
… Ejemplos (Clase Asociación)
empleador trabajadores
Empresa Empleado
* 1..*
Cargo
superior
nombre
sueldo 0..1
subordinado 1..*
40
… Ejemplos (Generalización)
Trabajador
{ disjunta, completa }
Directivo Administrativo Obrero
41
… Ejemplos
Motor Piloto Vendedor de billetes
1..4 1..2 1
1 n
n
1 n 1 n
Avión Vuelo Reserva
n
Avión militar Avión comercial Línea aérea
Prácticas 4
Avión de carga Avión de pasajeros
42
Diagrama de Estados
alta baja
núm ero_préstam os = 0
sin pr éstam os
Socio
número : int
nombre : char[50]
número_prestamos : int = 0
prestar devol ver [ núm ero_p rést amo s = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date) núm ero_préstam os > 0
con prés tam os
pres tar
devolver[ núm ero_prés tam os > 1 ]
43
B u s c a r B e b id a [ n o h a y c a fé ] [ no zumo ]
[ h a y c a fé ]
[ hay zum o ]
P o n e r c a fé A ñ ad i r a g u a C o g e r ta z a
e n filtro a l d e p ó s i to C oger
zum o
P o n e r filtro
e n m á q u in a
E ncender
m áq u in a
/ c a fe t e ra .O n
C afé e n
p re p a ra c ió n
i n d i c a d o r d e fi n
S e rv ir c a fé B eber
Práctica 5 44
Diagrama Componentes
Interfaz de Terminal
Control y Análisis
Gestión de Cuentas Rutinas de conexión Acceso a BD
45
Servidor Central Control y Análisis
Acceso a BD C
Rutinas de Coneccion
C
Terminal de Consulta
Interfaz de Terminal
C C
Punto de Venta
C
Gestión de Cuentas Interfaz de Terminal
C C
46
Diagrama de Despliegue en Rational

C ont rol y An á lisis
Ac ceso a BD
Servidor Central
Component Diagram:
Components / Servidor R utinas de conexión
Central
Servidor Central
Rutinas de conexión
Punto de Venta
Punto de Venta Terminal de
Consulta Gestión de Cuentas Interfaz de Terminal
Terminal de Consulta
Rutinas de con exió n Interfaz de Terminal
Component Diagram: Component Diagram:
Components / Punto de Components / Terminal
Venta de Consulta
Práctica 6
47
Resumen
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
48
III
El Paradigma
Orientado a Objeto
49
III. El Paradigma OO
¿Por qué la Orientación a Objetos?
Proximidad de los conceptos de modelado

respecto de las entidades del mundo real
• Mejora captura y validación de requisitos
• Acerca el “espacio del problema” y el “espacio de la
solución”
Modelado integrado de propiedades estáticas y

dinámicas del ámbito del problema
• Facilita construcción, mantenimiento y reutilización
50
¿Por qué la Orientación a Objetos?
Conceptos comunes de modelado durante el

análisis, diseño e implementación
• Facilita la transición entre distintas fases

• Favorece el desarrollo iterativo del sistema
• Disipa la barrera entre el “qué” y el “cómo”
Sin embargo, existen problemas ...
51
Problemas en OO
“...Los conceptos básicos de la OO se conocen desde hace

dos décadas, pero su aceptación todavía no está tan
extendida como los beneficios que esta tecnología puede
sugerir”
“...La mayoría de los usuarios de la OO no utilizan los

conceptos de la OO de forma purista, como inicialmente
se pretendía. Esta práctica ha sido promovida por
muchas herramientas y lenguajes que intentan utilizar los
conceptos en diversos grados”
--Wolfgang Strigel
52
… Problemas en OO
Un objeto contiene datos y operaciones que operan
sobre los datos, pero ...
Podemos distinguir dos tipos de objetos degenerados:
• Un objeto sin datos (que sería lo mismo que una biblioteca
de funciones)
• Un objeto sin “operaciones”, con sólo operaciones del tipo
crear, recuperar, actualizar y borrar (que se correspondería
con las estructuras de datos tradicionales)
Un sistema construido con objetos degenerados no es
un sistema verdaderamente orientado a objetos
“Las aplicaciones de gestión están constituidas

mayoritariamente por objetos degenerados”
53
Fundamentos de Modelado OO
54
III. El Paradigma OO: Fundamentos de Modelado OO
Objetos
Objeto = unidad atómica que encapsula estado
y comportamiento
La encapsulación en un objeto permite una alta

cohesión y un bajo acoplamiento
Un objeto puede caracterizar una entidad física

(coche) o abstracta (ecuación matemática)
55
… Objetos
En UML, un objeto se representa por un
rectángulo con un nombre subrayado
Otro ob jeto
Un objeto
Otro ob jeto más
56
… Objetos
Ejemplo de varios objetos relacionados:
Cuenta Corriente 101

Juan
Banco de Valencia
Felipe
Cuenta Corriente 114
57
… Objetos
Objeto = Identidad + Estado + Comportamiento
El estado está representado por los valores de los
atributos
Un atributo toma un valor en un dominio concreto
Un coche
Azul
979 Kg
70 CV
...
58
Clases y Objetos
59
Comportamiento
Ejemplo de interacción:
Un Objeto Operación 1
1: Un mensaje Operación 2
Otro Objeto
60
… Comportamiento
Los mensajes navegan por los enlaces, a
priori en ambas direcciones
Estado y comportamiento están relacionados

Ejemplo: no es posible aterrizar un avión si
no está volando. Está volando como
consecuencia de haber despegado del suelo
61
Persistencia
La persistencia de los objetos designa la
capacidad de un objeto trascender en el
espacio/tiempo
Podremos después reconstruirlo, es decir,
cogerlo de memoria secundaria para utilizarlo
en la ejecución (materialización del objeto)
Los lenguajes OO no proponen soporte

adecuado para la persistencia, la cual debería
ser transparente, un objeto existe desde su
creación hasta que se destruya
62
Comunicación
Un sistema informático puede verse como un
conjunto de objetos autónomos y concurrentes
que trabajan de manera coordinada en la
consecución de un fin específico
El comportamiento global se basa pues en la

comunicación entre los objetos que la
componen
63
… Comunicación
Categorías de objetos:
• Activos - Pasivos
• Cliente – Servidores, Agentes
Objeto Activo: posee un hilo de ejecución (thread)
propio y puede iniciar una actividad
Objeto Pasivo: no puede iniciar una actividad pero
puede enviar estímulos una vez que se le solicita un
servicio
Cliente es el objeto que solicita un servicio. Servidor
es el objeto que provee el servicio solicitado
64
… Comunicación
Los agentes reúnen las características de
clientes y servidores
Son la base del mecanismo de delegación

Introducen indirección: un cliente puede
comunicarse con un servidor que no conoce
directamente
65
… Comunicación
Ejemplo con objeto agente:
Servidor 1
2:
Un agente
1: 3:
Un cliente Servidor 2
66
El Concepto de Mensaje
La unidad de comunicación entre objetos se
llama mensaje
Objeto 1 1: Mensaje A Objeto 2
2: Mensaje C
4: Mensaje E
Objeto 3 Objeto 4
3: Mensaje D
67
Mensaje y Estímulo
Un estímulo causará la invocación de una operación, la
creación o destrucción de un objeto o la aparición de
una señal
Un mensaje es la especificación de un estímulo
Tipos de flujo de control:

• Llamada a procedimiento o flujo de control anidado
• Flujo de control plano
• Retorno de una llamada a procedimiento
• Otras variaciones
• Esperado (balking)
• Cronometrado (time-out)
68
III. El Paradigma OO: Requisitos
Requisitos del software
69
Casos de Uso
Los Casos de Uso (Ivar Jacobson) describen
bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el p.d.v.
del usuario
Permiten definir los límites del sistema y las
relaciones entre el sistema y el entorno
Los Casos de Uso son descripciones de la
funcionalidad del sistema independientes de la
implementación
Comparación con respecto a los Diagramas de
Flujo de Datos del Enfoque Estructurado
70
… Casos de Uso
Los Casos de Uso cubren la carencia existente
en métodos previos (OMT, Booch) en cuanto a
la determinación de requisitos
Los Casos de Uso particionan el conjunto de

necesidades atendiendo a la categoría de
usuarios que participan en el mismo
El usuario debería poder entenderlos para

realizar su validación
71
… Casos de Uso
Ejemplo:
Caso de Uso A
Actor A
Caso de Uso B
Actor B
72
… Casos de Uso
Actores:
• Principales: personas que usan el sistema
• Secundarios: personas que mantienen o administran el
sistema
• Material externo: dispositivos materiales imprescindibles
que forman parte del ámbito de la aplicación y deben ser
utilizados
• Otros sistemas: sistemas con los que el sistema interactúa
La misma persona física puede interpretar varios

papeles como actores distintos
El nombre del actor describe el papel desempeñado
73
… Casos de Uso
Los Casos de Uso se determinan observando y
precisando, actor por actor, las secuencias de
interacción, los escenarios, desde el punto de vista del
usuario
Un escenario es una instancia de un caso de uso
Los casos de uso intervienen durante todo el ciclo de

vida. El proceso de desarrollo estará dirigido por los
casos de uso
74
Casos de Uso: Relaciones

UML define cuatro tipos de relación en los
Diagramas de Casos de Uso:
• Comunicación
C aso de U so
Actor
75
… Casos de Uso: Relaciones

• Inclusión : una instancia del Caso de Uso origen
incluye también el comportamiento descrito por el
Caso de Uso destino
<<include>>
Caso de Uso Origen C aso de U so Desti no
<<include>> reemplazó al denominado <<uses>>
76

Ejemplo <<include>>:
<<include>>
Reintegro Cuenta Corriente
Cliente Verificar Operación
<<include>>
Reintegro Cuenta de Crédito
77

• Extensión : el Caso de Uso origen extiende el
comportamiento del Caso de Uso destino
<<extend>>
Caso de Uso Origen C aso de U so Desti no
78

Ejemplo <<extend>>:
Solicitar Préstamo
Cliente
[Tarjeta Caducada]
<<extend> >
Solic itar N ueva Tarjeta
79

Ejemplo <<include>> y <<extend>>:
Ide nt fi i caci ón
<<include>>
Transferencia
Cliente
<< exten d>>
Transferencia en Internet
80

Otro ejemplo <<include>> y <<extend>>:
Supply Custome r Data Orde r Product

Arrange Payment
<<include>> <<include>>
<<include >>
the sale spe rson a sks

for the c a ta l og
1 * <<ex tend>>
Salesperson Re que st Catalog

Place Order
81

• Herencia : el Caso de Uso origen hereda la
especificación del Caso de Uso destino y
posiblemente la modifica y/o amplía
Caso de Uso Hij o Caso de Uso Padre
82
Casos de Uso: Construcción

Un caso de uso debe ser simple, inteligible, claro y
conciso
Generalmente hay pocos actores asociados a cada
Caso de Uso
Preguntas clave:
• ¿cuáles son las tareas del actor?
• ¿qué información crea, guarda, modifica,
destruye o lee el actor?
• ¿debe el actor notificar al sistema los cambios
externos?
• ¿debe el sistema informar al actor de los
cambios internos?
83
… Casos de Uso: Construcción

La descripción del Caso de Uso comprende:
• el inicio: cuándo y qué actor lo produce?
• el fin: cuándo se produce y qué valor devuelve?
• la interacción actor-caso de uso: qué mensajes
intercambian ambos?
• objetivo del caso de uso: ¿qué lleva a cabo o
intenta?
• cronología y origen de las interacciones
• repeticiones de comportamiento: ¿qué
operaciones son iteradas?
• situaciones opcionales: ¿qué ejecuciones
alternativas se presentan en el caso de uso?
Práctica 7
84

Identificador CU-<id-requisito>
Nombre <nombre del requisito funcional>
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso {
concreto cuando <evento de activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}
Precondición <precondición del caso de uso>
Secuencia Paso Acción
Normal
1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el
caso de uso
< caso de uso CU-x>
2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o
sistema>>, se realiza el caso de uso < caso de uso CU-x>
… …
Postcondición <postcondición del caso de uso>

Excepciones Paso Acción
1 Si <condición de excepción>,{el <actor> , el sistema} }<acción realizada por el

actor o sistema>>, se realiza el caso de uso
< caso de uso CU-x>, a continuación este caso de uso {continua, aborta}
… …
Rendimiento Paso Cota de tiempo
1 n segundos
… …
Frecuencia esperada <nº de veces> veces / <unidad de tiempo>

Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>
85
Comentarios
En métodos OO que carecen de una técnica de captura de
requisitos se comienza inmediatamente con la
construcción del modelo de análisis/diseño
Los Casos de Uso son una idea maravillosa que ha sido

generalmente complicada. El verdadero truco para los
Casos de Uso es mantenerlos simples. Recordad, mañana
van a cambiar. Rober C. Martin
Los requisitos NO funcionales también son importantes.

Desempeño, cumplimiento de estándares o leyes,
atributos de calidad (confiabilidad, disponibilidad,
seguridad, mantenibilidad, portabilidad), etc.
86
Interacción entre objetos
87
III. El Paradigma OO: Interacción entre objetos
Interacción
Los objetos interactúan para realizar
colectivamente los servicios ofrecidos por las
aplicaciones. Los diagramas de interacción
muestran cómo se comunican los objetos en
una interacción
Existen dos tipos de diagramas de

interacción: el Diagrama de Colaboración y el
88
Mensajes
Sintaxis para mensajes:

predecesor / guarda secuencia: retorno := msg(args)
89
Diagramas de interacción
El Diagrama de Secuencia es más adecuados
para observar la perspectiva cronológica de las
interacciones
El Diagrama de Colaboración ofrece una mejor

visión espacial mostrando los enlaces de
comunicación entre objetos
El D. de Colaboración puede obtenerse
automáticamente a partir del correspondiente
D. de Secuencia (o viceversa)
90
Muestra la secuencia de mensajes entre
objetos durante un escenario concreto
Cada objeto viene dado por una barra
vertical
El tiempo transcurre de arriba abajo
Cuando existe demora entre el envío y la
atención se puede indicar usando una línea
oblicua
91
… Diagrama de Secuencia
92
Caller Exchange Receiver
a: lift receiver
{b.receiveTime b: dial tone

- a.sendTime < 1 sec.}
{c.receiveTime c: dial digit

-b.sendTime < 10 sec.}
...
The call is routed
d: route
through the network
{d.receiveTime
ringing tone phone rings
-d.sendTime < 5 sec.}
answer phone -----

< 1 sec
At this point the stop tone stop ringing -----
parties can talk
93
mostrando foco de control,
condiciones, recursividad
creación y destrucción
de objetos
94
ob 3 : C3 ob4 : C 4
op( ) ob 1 : C1
[x>0] fool(x) ob2 : C2

[x<0] bar(x)
doit(z )
doit(w)
more( )
95
Dia gram 1 Diagram 2
ob1 : C 1 ob3 : C3 ob4 : C4
[x<0] bar(x)
bar(x)
doit(w)
Sequence D iagram:
D iagrams / D iagram 2
Sequence Diagram:
Diagrams / Diagram 1
96
Son útiles en la fase exploratoria para
identificar objetos
La distribución de los objetos en el diagrama

permite observar adecuadamente la
interacción de un objeto con respecto de los
demás
La estructura estática viene dada por los

enlaces; la dinámica por el envío de
mensajes por los enlaces
97
Mensajes
Un mensaje desencadena una acción en el
objeto destinatario
Un mensaje se envía si han sido enviados los

mensajes de una lista (sincronización):
A.1, B.3 / 1:Mensaje B
98
… Mensajes
Un mensaje se envía de manera condicionada:
[x>y] 1: Mensaje
B
99
… Mensajes
Un mensaje que devuelve un resultado:
1: distancia:= mover(x,y)
B
Práctica 8
100
Clases y relaciones
entre clases
101
III. El Paradigma OO: Clases y relaciones entre clases
Clasificación
El mundo real puede ser visto desde abstracciones
diferentes (subjetividad)
Mecanismos de abstracción:
• Clasificación / Instanciación
• Composición / Descomposición
• Agrupación / Individualización
• Especialización / Generalización
La clasificación es uno de los mecanismos de

abstracción más utilizados
102
Clases
La clase define el ámbito de definición de un

conjunto de objetos
Cada objeto pertenece a una clase
Los objetos se crean por instanciación de las

clases
103
Clases: Notación Gráfica

Cada clase se representa en un rectángulo
con tres compartimientos:
• nombre de la clase
• atributos de la clase
• operaciones de la clase
Motocicleta
color
cilindrada
velocidad máxima
arrancar()
acelerar()
frenar()
104
Clases: Notación Gráfica

Otros ejemplos:
lista
pila
primero()
apilar()
ultimo()
desapilar()
añadir()
cardinalidad()
quitar()
cardinalidad()
105
Clases: Encapsulación
La encapsulación presenta dos ventajas básicas:
• Se protegen los datos de accesos indebidos
• El acoplamiento entre las clases se disminuye
• Favorece la modularidad y el mantenimiento
Los atributos de una clase no deberían ser

manipulables directamente por el resto de objetos
106
… Clases: Encapsulación
Los niveles de encapsulación están heredados de los
niveles de C++:
• (-) Privado : es el más fuerte. Esta parte es
totalmente invisible (excepto para clases friends
en terminología C++)
• (#) Los atributos/operaciones protegidos
están visibles para las clases friends y para las
clases derivadas de la original
• (+) Los atributos/operaciones públicos son
visibles a otras clases (cuando se trata de
atributos se está transgrediendo el principio de
encapsulación)
107
… Clases: Encapsulación
Ejemplo:
Reglas de visibilidad
Atributo público : Integer
Atributo protegido : Integer
Atributo privado : Integer
"Operación pública"()
"Operación protegida"()
"Operación privada"()
108
Relaciones entre Clases

Los enlaces entre de objetos pueden
representarse entre las respectivas clases
Formas de relación entre clases:

• Asociación y Agregación (vista como un
caso particular de asociación)
• Generalización/Especialización
Las relaciones de Agregación y Generalización

forman jerarquías de clases
109
Asociación
La asociación expresa una conexión bidireccional
entre objetos
Una asociación es una abstracción de la relación
existente en los enlaces entre los objetos
Univ. de Murcia : Universidad Un enlace Antonio : Estudiante
Universidad Estudiante
Una asociación
110
… Asociación
Ejemplo:
marido
casado-con
0..1
mujer
0..1 Persona Compañía
nombre * trabaja-para nombre
s.s. dirección
emplea-a *
0.. 1
jefe
*
Administra
empleado
111
… Asociación
Especificación de multiplicidad
(mínima...máxima)
1 Uno y sólo uno
0..1 Cero o uno
M..N Desde M hasta N (enteros naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)
La multiplicidad mínima >= 1 establece una

restricción de existencia
112
Asociación Cualificada
Aerolínea Viajero
* 0..1
nro_billete
Tablero Cuadro
fila 1 1
Ajedrez
columna
Reduce la multiplicidad del rol opuesto al considerar el valor

del cualificador
113
Agregación
La agregación representa una relación parte_de
entre objetos
En UML se proporciona una escasa caracterización

de la agregación
Puede ser caracterizada con precisión

determinando las relaciones de comportamiento y
estructura que existen entre el objeto agregado y
cada uno de sus objetos componentes
114
Ejemplos
Window
scrollbar[2] : Slider
title : Header
body : Panel
Window
1 1
1
scrollbar
2 title 1 body 1
Slider Header Panel
115
... Ejemplos
Member-of * Committee
Person *
{ subset }
1 Chair-of *
Represents an
incorporated entity.
worker Person employee employer Company

0..1
* *
0..1
boss
{Person.employer =
Person.boss.employer}
116
… Ejemplos
Agregación
Polígono contiene Punto
1
3..*
{ordenado}
Persona
*
*
Cuenta
or Asociación excluyente
* Empresa
1
Usuario está-autorizado-en Estación

* *
Autorización
Clase de asociación prioridad
privilegios
camb_privil() 117
Clases y Objetos
Diagrama de Clases y Diagramas de Objetos
pertenecen a dos vistas complementarias del
modelo
Un Diagrama de Clases muestra la
abstracción de una parte del dominio
Un Diagrama de Objetos representa una

situación concreta del dominio
Las clases abstractas no son instanciadas
118
Generalización
Permite gestionar la complejidad mediante un
ordenamiento taxonómico de clases
Se obtiene usando los mecanismos de
abstracción de Generalización y/o Especialización
La Generalización consiste en factorizar las
propiedades comunes de un conjunto de clases
en una clase más general
119
... Generalización
Nombres usados: clase padre - clase hija.
Otros nombres: superclase - subclase, clase
base - clase derivada
Las subclases heredan propiedades de sus

clases padre, es decir, atributos y
operaciones (y asociaciones) de la clase
padre están disponibles en sus clases hijas
120
... Generalización
Vehículo
Veihículo Terrestre Vehículo Aéreo
Coche Camión Avión Helicóptero
121
... Generalización
La especialización es una técnica muy eficaz para la
extensión y reutilización
Coche
Funcionando Est ropeado
Restricciones predefinidas en UML:

• disjunta - no disjunta
• total (completa) - parcial (incompleta)
122
... Generalización
La noción de clase está próxima a la de
conjunto
Dada una clase, podemos ver el conjunto

relativo a las instancias que posee o bien
relativo a las propiedades de la clase
Generalización y especialización expresan

relaciones de inclusión entre conjuntos
123
... Generalización
Particionamiento del espacio de objetos =>
Clasificación Estática
Particionamiento del espacio de estados de

los objetos => Clasificación Dinámica
En ambos casos se recomienda considerar

generalizaciones/especializaciones disjuntas
124
... Generalización
Un ejemplo de Clasificación Estática:
Ve hícu lo Aéreo
{ estática }
Avión Helicóptero
125
... Generalización
Un ejemplo de Clasificación Dinámica:
Coche
{ dinámica }
Funcionando Est ropeado
126
... Generalización
Extensión: Posibles instancias de una clase
Intensión: Propiedades definidas en una

clase
A
int(A) ⊆ int(B)
ext(B) ⊆ ext(A)
B
127
... Generalización
Clasificación Estática
C0
ext(C0) = ∪ ext(Ci) ⇒ completa

{ static }
ext(Ci) ∩ ext(Cj) = ∅ ⇒ disjunta
C1 Cn
128
... Generalización
Clasificación Dinámica
C0
ext(C0) = ∪ ext(Ci) ⇒ completa
extt(Ci) ∩ extt(Cj) = ∅ ⇒ disjunta en t
{ dinámica }
extt1(Ci) ∩ extt2(Cj) ≠ ∅ ⇒ posiblemente
no disjunta en
C1 Cn diferentes
instantes
129
... Generalización
Ejemplo: varias especializaciones a partir de la
misma clase padre, usando discriminadores:
Comercial Militar
uso
Vehículo Aéreo
estructura
Avión Helicóptero
130
Clasificación Múltiple (herencia múltiple)
Se presenta cuando una subclase tiene más de

una superclase
La herencia múltiple debe manejarse con

precaución. Algunos problemas son el conflicto
de nombre y el conflicto de precedencia
Se recomienda un uso restringido y disciplinado

de la herencia. Java y Ada 95 simplemente no
ofrecen herencia múltiple
131
… Herencia Múltiple
Uso disciplinado de la herencia múltiple:
clasificaciones disjuntas con clases padre en hojas
de jerarquías alternativas
Bípedo Cuadrúpedo
nro patas nro patas
Con Pelos Herbívoro
cubertura comida
Animal
Con Plumas cobertura
comida
cobertura Carnívoro
Con Escamas
Conejo
132
Principio de Sustitución
El Principio de Sustitución de Liskow afirma
que:
“Debe ser posible utilizar cualquier objeto

instancia de una subclase en el lugar de
cualquier objeto instancia de su superclase
sin que la semántica del programa escrito en
los términos de la superclase se vea
afectado.”
133
… Principio de Sustitución
Dado que los programadores pueden introducir
código en las subclases redefiniendo las
operaciones, es posible introducir involuntaria-
mente incoherencias que violen el principio de
sustitución
El polimorfismo que veremos a continuación no

debería implementarse sin este principio
134
Polimorfismo
El término polimorfismo se refiere a que una
característica de una clase puede tomar
varias formas
El polimorfismo representa en nuestro caso
la posibilidad de desencadenar operaciones
distintas en respuesta a un mismo mensaje
Cada subclase hereda las operaciones pero
tiene la posibilidad de modificar localmente
el comportamiento de estas operaciones
135
… Polimorfismo
Ejemplo: todo animal duerme, pero cada
clase lo hace de forma distinta
Animal
dormir()
?
dormir
León Oso Tigre
136
… Polimorfismo
Animal Dormir()
{
dormir()
}
León Oso Tigre

dormir() dormir() dormir()
Dormir() Dormir() Dormir()

{ { {
sobre el vientre sobrela espalda en un árbol
} } }
137
… Polimorfismo
La búsqueda automática del código que en
cada momento se va a ejecutar es fruto del
enlace dinámico
El cumplimiento del Principio de Sustitución

permite obtener un comportamiento y diseño
coherente
Práctica 9-12
138
Comportamiento de objetos
139
III. El Paradigma OO: Comportamiento de objetos
Diagrama de Estados
Los Diagramas de Estados representan
autómatas de estados finitos, desde el p.d.v.
de los estados y las transiciones
Son útiles sólo para los objetos con un

comportamiento significativo
El formalismo utilizado proviene de los

Statecharts (Harel)
140
… Diagrama de Estados
Cada objeto está en un estado en cierto instante
El estado está caracterizado parcialmente por los
valores algunos de los atributos del objeto
El estado en el que se encuentra un objeto
determina su comportamiento
Cada objeto sigue el comportamiento descrito en
el D. de Estados asociado a su clase
Los D. De Estados y escenarios son complementarios
141
Los D. de Estados son autómatas jerárquicos
que permiten expresar concurrencia,
sincronización y jerarquías de objetos
Los D. de Estados son grafos dirigidos
Los D. De Estados de UML son deterministas
Los estados inicial y final están diferenciados del
resto
La transición entre estados es instantánea y se
debe a la ocurrencia de un evento
142
Estados y Transiciones
Evento [condición] / Acción
A B
Tanto el evento como la acción se

consideran instantáneos
143
Ejemplo de un Diagrama de Estados para la
clase persona:
c ontratar
en el paro en ac tivo
perder em pleo
jubilars e
jubil ars e
jub ilado
144
Acciones
Podemos especificar la solicitud de un
servicio a otro objeto como consecuencia de
la transición:
Evento [condición] / OtroObjeto.Operación
145
… Acciones
Se puede especificar el ejecutar una acción
como consecuencia de entrar, salir, estar en
un estado, o por la ocurrencia de un evento:
estado A
entry: acción por entrar
exit: acción por salir
do: acción mientras en estado
on evento: acción
146
Generalización de Estados
Podemos reducir la complejidad de estos
diagramas usando la generalización de
estados
Distinguimos así entre superestado y
subestados
Un estado puede contener varios subestados
disjuntos
Los subestados heredan las variables de
estado y las transiciones externas
147
Ejemplo:
e1
A B
e2
e2
148
Quedaría como:
e1
Aa b
B
e2
149
… Generalización de Estados
Las transiciones de entrada deben ir hacia
subestados específicos:
e1
Aa Bb
e2
e0
150
Es preferible tener estados iniciales de
entrada a un nivel de manera que desde los
niveles superiores no se sepa a qué
subestado se entra:
e1
Aa b
B
e2 C
e0
151
La agregación de estados es la composición
de un estado a partir de varios estados
independientes
La composición es concurrente por lo que el

objeto estará en alguno de los estados de
cada uno de los subestados concurrentes
152
Ejemplo:
e1
e1
153
lif t r e c e iv e r
/ g e t d ia l
to n e
A c t iv e
T im e o u t
d o / p la y m e s s a g e
a f t e r ( 1 5 s e c .) d ia l d ig it ( n ) [ in c o m p le t e ]
a f t e r ( 1 5 s e c .)
D ia lT o n e d ia l d ig it ( n ) D ia lin g
d o / p l a y d i a l to n e
Id le
d i a l d ig it ( n )[ in v a l id ]
d ia l d ig it ( n ) [ v a lid ]
P in n e d In v a li d / connect
c a lle r h a n g s u p
/ d isc o n n ec t
d o / p la y m e s s a g e
c a l le e C o n n e c t in g
c a lle e
hang h an g s
s up up
busy
Busy c o n n e c te d
d o / p la y b u s y t o n e
T a lk in g R in g in g
c a lle e a n s w e r s d o / p l a y r i n g i n g to n e
/ e n a b le
speech
154
Historia
Por defecto, los autómatas no tienen
memoria
Es posible memorizar el último subestado
visitado para recuperarlo en una transición
entrante en el superestado que lo engloba
También es posible la memorización para

cualquiera de los subestados anidados (aparece
un * junto a la H)
155
… Historia
Ejemplo:
A
d2
B
in
D x y
out
d1
C
H*
156
… Historia
Ejemplo:
Enjuague Lavado Secado
cerrar puerta abir puerta
Espera
157
Destrucción del Objeto

La destrucción de un objeto es efectiva
cuando el flujo de control del autómata
alcanza un estado final no anidado
La llegada a un estado final anidado implica

la “subida” al superestado asociado, no el fin
del objeto
158
… Destrucción de Objeto
Ejemplo:
c ras h
E n vuelo
des pegar aterriz ar
Crear(m atric ula)

E n t ierra
159
Transiciones temporizadas
Las esperas son actividades que tienen
asociada cierta duración
La actividad de espera se interrumpe cuando

el evento esperado tiene lugar
Este evento desencadena una transición que
permite salir del estado que alberga la
actividad de espera. El flujo de control se
transmite entonces a otro estado
160
… Transiciones temporizadas
Ejemplo: A
/ Abrir ranura
esperar dinero después de

30 segundos anular
entry: Mostrar mensaje
exit: cerrar ranura transacción
Depósito efectuado
161
El Diagrama de Actividad es una especialización
del Diagrama de Estado, organizado respecto
de las acciones y usado para especificar:
• Un método
• Un caso de uso
• Un proceso de negocio (Workflow)
Las actividades se enlazan por transiciones

automáticas. Cuando una actividad termina se
desencadena el paso a la siguiente actividad
162
Ejemplo (con swim lines)

P a s a j e ro V endedo r A i r l i ne
S o lic ita r
p a s a je V e r ific a r
e x is t e n c ia v u e lo
D a r d e ta lle s
v u e lo
I n fo r m a r a lte r n a ti v a s y
p r e c io s
S e le c c io n a r
v u e lo
S o lic it a r R e s e rv a r
pago pla z as
C o n fir m a r p la z a
P agar re s e rv a d a
p a s a je
E m it ir
b i ll e te
163
... Ejemplos C u st o m er S ales S t o ckro o m
Re q ue st se rv i c e O rd e r
[p la c e d ]
T a k e o rd e r O rd e r
[e n te r e d ]
P la y
F i l l o rd e r
O rd e r D e li v e r o rd e r O rd e r
[d e live r ed ] [fille d ]
C o l l e c t o rd e r
164
... Ejemplos
Calculate [cost < $50] Change customer's

total cost account
[cost >= $50] Get

authorization
165
Componentes
166
III. El Paradigma OO: Componentes
Diagrama de Componentes
Los diagramas de componentes describen los
elementos físicos del sistema y sus relaciones
Muestran las opciones de realización

incluyendo código fuente, binario y ejecutable
167
...Diagrama de Componentes
Los componentes representan todos los tipos
de elementos software que entran en la
fabricación de aplicaciones informáticas.
Pueden ser simples archivos, paquetes de
Ada, bibliotecas cargadas dinámicamente,
etc.
Las relaciones de dependencia se utilizan en

los diagramas de componentes para indicar
que un componente utiliza los servicios
ofrecidos por otro componente
168
...Diagrama de Componentes
169
Distribución y despliegue de
Componentes
170
III. El Paradigma OO: Distribución y despliegue de componentes
Los Diagramas de Despliegue muestran la
disposición física de los distintos nodos que
componen un sistema y el reparto de los
componentes sobre dichos nodos
N odo
171
… Diagrama de Despliegue
Los estereotipos permiten precisar la
naturaleza del equipo:
• Dispositivos
• Procesadores
• Memoria
Los nodos se interconectan mediante

soportes bidireccionales que pueden a su vez
estereotiparse
172
… Diagrama de Despliegue
Ejemplo de conexión entre nodos:
<<Cliente>> <<Servidor>>
Terminal Punto <<TCP/IP>>
Base de
de Venta Datos
<<RDSI>>
<<RDSI>>
Podemos distinguir tipos Control
de nodos y connexiones
por estereotipado
173
… Diagramas de Despliegue
Ejemplo:
174
… Diagramas de Despliegue
Ejemplo: Component Diagram: videoStoreServer
Component Diagram:
Component Diagram: <<Contai ner>>
videoStoreApplication /
Client / Client VideoStor eApplication
VideoStoreApplication
Diagram
Component Diagram:
videoStoreServer /
<<brow ser>>
Client videoStoreServer
OpenSourceBrowser Client
<<AppServer>>
videoStoreServer
<<Session>> <<Entity>>
ShoppingS ession Catalog
DBServer
<<Entity>>
ShoppingCart
videoStoreApplication
Component Diagram:
DBServer / DBServer
DBServer
VideoStoreDB
175
Object Constraint Language

OCL
176
III. El Paradigma OO: OCL
¿Qué es OCL?
OCL es un lenguaje formal usado para
describir expresiones acerca de modelos UML
OCL es parte del estandar UML y fue

desarrollado en IBM
Las evaluación de expresiones OCL no afecta
el estado del sistema en ejecución
177
Usos de OCL
Lenguaje de consulta
Especificación de invariantes en clases y tipos
Especificación de invariantes de tipo para Estereotipos
Describir pre- y post condiciones en Operaciones y
Métodos
Describir Guardas
Especificar destinatarios para mensages y acciones
Especificar restricciones en Operaciones
Especificar reglas de derivación para atributos
178
Ejemplo
179
Invariantes
“El número de empleados debe ser mayor que 50”
self.númeroDeEmpleados > 50 (siendo el contexto Company)
context Compañía
inv: self. númeroDeEmpleados > 50
context c:Compañía
inv: c.númeroDeEmpleados > 50
context c:Compañía
inv suficientesEmpleados: c.númeroDeEmpleados > 50
180
Pre- Post condiciones

Sintaxis
context NombreTipo::NombreOperación(Param1 : Tipo1, ... ):TipoRetorno
pre parametroOk: param1 > ...
post resultadoOk : result = ...
Ejemplo
context Persona::nómina(fecha : Date) : Integer

post: result = 5000
181
Valores iniciales y derivados

Sintaxis
context NombreTipo::NombreAtributo: Tipo
init: –- alguna expresión representando el valor inicial
context NombreTipo::NombreRolAsociación: Tipo

init: –- alguna expresión representando la regla de derivación
Ejemplo
context Persona::nómina : Integer

init: padres.nómina->sum() * 1%
derive: if menorDeEdad then
padres.nómina->sum() * 1%
else
puesto.sueldo
endif
182
Expresiones Let
Ejemplo
context Persona inv:

let ingresos : Integer = self.puesto.sueldo->sum() in
if estáEnParo then
ingresos < 100
else
ingresos >= 100
endif
183
Definiciones
Ejemplo
context Persona
def: ingresos : Integer = self.puesto.sueldo->sum()
def: apodo : String = ’Gallito rojo’
def: tieneElTítulo(t : String) : Boolean = self.puesto->exists(título = t)
184
Navegación
Ejemplos
context Compañía
inv: self.director.estáEnparo = false
inv: self.empleado->notEmpty()
context Compañía
inv:self.director.edad > 40
context Persona
inv:self.empleador->size() < 3
context Persona
inv:self.empleador->isEmpty()
context Persona
inv:self.esposa->notEmpty() implies self.esposa.sexo = Sexo::mujer
185
… Navegación
Ejemplo
a) “Los casados tienen al menos 18 años de edad”
context Persona inv:

self.esposa->notEmpty() implies self.esposa.edad >= 18 and
self.esposo->notEmpty() implies self.esposo.edad >= 18
“Una compañía tiene a lo más 50 empleados”
context Companía inv:

self.empleado->size() <= 50
186
IV
Proceso de Desarrollo
de SW basado en UML
187
¿Qué es un Proceso de Desarrollo de SW?

Define Quién debe hacer Qué, Cuándo y Cómo debe
hacerlo
Requisitos nuevos Sistema nuevo

o modificados o modificado
Proceso de Desarrollo
de Software
No existe un proceso de software universal. Las

características de cada proyecto (equipo de desarrollo,
recursos, etc.) exigen que el proceso sea configurable
188
Rational Unified Process (RUP)
Rational Unified Process • Pruebas funcionales

1998 • Pruebas de desempeño
• Gestión de requisitos
• Gestión de cambios y
configuración
• Ingeniería de Negocio
Rational Objectory Process • Ingeniería de datos
1996-1997
• Diseño de interfaces
Objectory Process UML

1987-1995
Enfoque Ericsson
189
Dos Dimensiones
190
Fases e Hitos (Milestones)
Inception Elaboration Construction Transition
Objetivos Arquitectura Capacidad Release

(Vision) Operacional del Producto
Inicial
tiempo
191
Elementos en RUP
Workflows (Disciplinas)
Workflows Primarios
• Business Modeling (Modado del Negocio)
• Requirements (Requisitos)
• Analysis & Design (Análisis y Diseño)
• Implementation (Implementación)
• Test (Pruebas)
• Deployment (Despliegue)
Workflows de Apoyo
• Environment (Entorno)
• Project Management (Gestión del Proyecto)
• Configuration & Change Management (Gestión de Configuración y
Cambios)
192
... Elementos en RUP

Workflow, Workflow Detail , Workers, Actividades y Artefactos
Ejemplo
Workflow: Requirements Workflow Detail:Analyse the Problem
Workers Artefactos
Actividades 193

Workers Testing professional workers
Analyst workers Test Designer
• Business-Process Analyst Tester
• Business Designer Manager workers
• Business-Model Reviewer Change Control Manager
• Requirements Reviewer Configuration Manager
• System Analyst Deployment Manager
• Use-Case Specifier Process Engineer
• User-Interface Designer Project Manager
Developer workers Project Reviewer
• Architect Other workers
• Architecture Reviewer Any Worker
• Capsule Designer Course Developer
• Code Reviewer Graphic Artist
• Database Designer Stakeholder
• Design Reviewer System Administrator
• Designer Technical Writer
• Implementer Tool Specialist
• Integrator 194

Workers, Actividades, Artefactos
Ejemplo: System Analyst Worker
195

Artefactos
Resultado parcial o final que es producido y usado
durante el proyecto. Son las entradas y salidas de las
actividades
Un artefacto puede ser un documento, un modelo o
un elemento de modelo
Conjuntos de Artefactos
Business Modeling Set Deployment Set
Requirements Set Project Management Set
Analysis & Design Set Configuration & Change Management Set
Implementation Set Environment Set
Test Set
196

Artefactos, Workers, Actividades
Ejemplo:Business Modeling Artifact Set
197
Características Esenciales de RUP
Proceso Dirigido por los Casos de Uso

Proceso Iterativo e Incremental
Proceso Centrado en la Arquitectura
198
Proceso dirigido por los Casos de Uso
Capturar, definir y
Requisitos
validar los casos de uso
Análisis & Diseño Casos de Uso

Realizar los
integran el
trabajo casos de uso
Implementación
Verificar que se
Pruebas satisfacen los casos
de uso
199
... Proceso dirigido por los Casos de Uso
«trace» «trace»
Caso de Uso Realización de Análisis Realización de Diseño
«trace»
«trace»
Pruebas
Unitarias
Pruebas Funcionales X
Caso de Prueba
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
200
... Proceso dirigido por los Casos de Uso
201

El ciclo de vida iterativo se basa en la
evolución de prototipos ejecutables que se
muestran a los usuarios y clientes
En el ciclo de vida iterativo a cada iteración
se reproduce el ciclo de vida en cascada a
menor escala
Los objetivos de una iteración se establecen
en función de la evaluación de las iteraciones
precedentes
202
... Proceso Iterativo e Incremental

Las actividades se encadenan en una mini-
cascada con un alcance limitado por los
objetivos de la iteración
Análisis
Diseño
Codific.
n veces Pruebas e
Integración
203

Cada iteración comprende:
• Planificar la iteración (estudio de riesgos)
• Análisis de los Casos de Uso y escenarios
• Diseño de opciones arquitectónicas
• Codificación y pruebas. La integración del nuevo
código con el existente de iteraciones anteriores
se hace gradualmente durante la construcción
• Evaluación de la entrega ejecutable (evaluación
del prototipo en función de las pruebas y de los
criterios definidos)
• Preparación de la entrega (documentación e
instalación del prototipo)
204
Enfoque
Secuencial
Enfoque
Iterativo e
Incremental
205

Grado de Finalización de Artefactos
206
Proceso Centrado en la Arquitectura

Arquitectura de un sistema es la organización o
estructura de sus partes más relevantes
Un arquitectura ejecutable es una implementación
parcial del sistema, construida para demostrar
algunas funciones y propiedades
RUP establece refinamientos sucesivos de una

arquitectura ejecutable, construida como un prototipo
evolutivo
Inception Elaboration Construction Transition
Architecture
207
Fases, Release, Base Line, Generación

ciclo de desarrollo ciclo de evolución
release base line generación

(producto al final de (release asociada (release final de
una iteración) a un hito) un ciclo de desarrollo)
208
Esfuerzo y dedicación por Fases en RUP
Inicio Elaboración Construcción Transición
Esfuerzo 5% 20 % 65 % 10%
Tiempo
10 % 30 % 50 % 10%
Dedicado
209
Distribución de Recursos por Fases en RUP
210
V
Conclusiones
211
V. Conclusiones
Claves en el Desarrollo de SI
Notación
UML
Herramientas Proceso
p.e. Rational Rose p.e. Rational Unified Process
Poseidon Métrica 3.0 o XP
212
V. Conclusiones
Modelado de SI: Algunas Reflexiones

¿Cuál es el propósito de nuestros modelos?
“Documentar” (a posteriori)
Comunicar ideas y estudiar alternativas
Tomar decisiones de análisis/diseño que dirijan la implementación
Generar parcial o totalmente una implementación a partir de los
modelos
Pragmatismo, los modelos deben ser útiles. Principio
básico: “Sencillez y Elegancia”
Gestión de modelos
Distintos nivel de abstracción, expresados en diferentes modelos
Seguimiento de transformaciones durante el proceso (Traceability)
Sincronización de modelos
Dificultades para la introducción de notaciones y
herramientas de modelado. La importancia del Proceso de
Desarrollo
213
V. Conclusiones
Adaptabilidad al contexto del proyecto
214
V. Conclusiones
Tendencias
UML: actualmente la notación más detallada, amplia y
consensuada para modelar software orientado a objetos
Dificultades actuales para derivar de forma directa una
implementación a partir de los modelos UML
Entornos de programación visual y el paradigma OO subyacente
Utilización de bases de datos relacionales
Arquitectura de 3 capas
Frameworks de persistencia para materializar y desmaterializar
objetos
Metodologías de desarrollo de software y el papel que

juega UML en ellas
Modelado Ágil
Modelado opcional y/o desechable (en Metodologías Ágiles)
215
V. Conclusiones
... Tendencias
Nuevas versiones de UML, uff!
Extensiones de UML (SysML, www.sysml.org)
Generación automática de código a partir de modelos
Model-Driven Development (MDD), Model-Driven Architecture (MDA),
Compiladores de Modelos
Round-trip engineering. Convergencia entre herramientas CASE e
IDEs
Extendiendo UML mediante Profiles
(www.objecteering.com/products_uml_profile_builder.php)
Modelado y generación de código en dominios
específicos (más allá de UML)
Eclipse Modeling Framework (EMF,
download.eclipse.org/tools/emf/scripts/home.php)
Microsoft Tools for Domain Specific Languagues
Domain-Specific Modeling (DSM, www.dsmforum.org)
Meta CASE Tools (www.metacase.com)
216
Diagramas en UML 2.0
217
V. Conclusiones
Bibliografía Adicional
UML
• www.omg.org/uml/
• Meta-links www.cetus-links.org/oo_uml.html
• Martin Fowler, autor de “UML Destilled” (“UML Gota a Gota”)
http://www.martinfowler.com/
Herramientas CASE
• Herramientas basadas en UML
www.objectsbydesign.com/tools/umltools_byPrice.html
• International Council in SE (INCOSE) www.incose.org/tools/
Otras
• Revista IEEE Software, Conferencias: OOPSLA, ECOOP
• Patrones http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html,
• Foro UML en yahoo: http://groups.yahoo.com/group/uml-forum/
218

Curso UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Curso UML

Uploaded by

Copyright:

Available Formats

Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia

Departamento Sistemas Informáticos y Computación (DSIC)

Construcción de una casa para “fido”

Puede hacerlo una sola persona

Construcción de una casa

Construida eficientemente y en un tiempo

Abstracción - Modelado Visual (MV)

“El modelado captura las

II. Notación (Visual) - Beneficios

Establecer una notación estándar

1999 UML 1.3 Revisiones menores

1998 UML 1.2

Nov ‘97 UML aprobado

Participantes en UML 1.0

UML “aglutina” enfoques OO

 “Monopolio de conceptos, técnicas y métodos en torno

II. Breve Tour por UML

 Diagrama: una representación gráfica de una colección

OMG UML 1.4 Specification

II. Breve Tour por UML

... Modelos y Diagramas

 El código fuente del sistema es el modelo más detallado del

 Cada modelo es completo desde su punto de vista del sistema,

II. Breve Tour por UML

Diagramas de UML 1.5

II. Breve Tour por UML

... Diagramas de UML

II. Breve Tour por UML

Este enfoque sigue el browser de Rational Rose

II. Breve Tour por UML

... Organización de Modelos

Propuesta de Rational Unified Process (RUP)

II. Breve Tour por UML

 Se representan gráficamente como:

II. Breve Tour por UML

 Un paquete puede contener otros paquetes, sin

 Una clase de un paquete puede aparecer en

II. Breve Tour por UML

 El operador “::” permite

II. Breve Tour por UML

...Paquetes en Rational Rose

II. Breve Tour por UML

II. Breve Tour por UML

Diagrama de Casos de Uso

 Casos de Uso es una técnica para capturar

 No pertenece estrictamente al enfoque

II. Breve Tour por UML

II. Breve Tour por UML

: WInP réstamos :Socio :Video : Préstamo

verificar situación video

II. Breve Tour por UML

2: verificar situación socio

1: prestar(video, socio) 3: verificar situación video

II. Breve Tour por UML

II. Breve Tour por UML

Ejemplos (Clase y Visibilidad)

II. Breve Tour por UML

dirige direc tor

II. Breve Tour por UML

… Ejemplos (Clase Asociación)

II. Breve Tour por UML

Directivo Administrativo Obrero

“Monopolio de conceptos, técnicas y métodos en torno

Diagrama: una representación gráfica de una colección

El código fuente del sistema es el modelo más detallado del

Cada modelo es completo desde su punto de vista del sistema,

Se representan gráficamente como:

Un paquete puede contener otros paquetes, sin

Una clase de un paquete puede aparecer en

El operador “::” permite

Casos de Uso es una técnica para capturar

No pertenece estrictamente al enfoque

UML define una notación que se expresa

El 80 por ciento de la mayoría de los

Proximidad de los conceptos de modelado

Modelado integrado de propiedades estáticas y

Conceptos comunes de modelado durante el

Sin embargo, existen problemas ...

La encapsulación en un objeto permite una alta

Un objeto puede caracterizar una entidad física

Estado y comportamiento están relacionados

Los lenguajes OO no proponen soporte

El comportamiento global se basa pues en la

Son la base del mecanismo de delegación

Tipos de flujo de control:

Los Casos de Uso particionan el conjunto de

El usuario debería poder entenderlos para

La misma persona física puede interpretar varios

El nombre del actor describe el papel desempeñado

Un escenario es una instancia de un caso de uso

Los casos de uso intervienen durante todo el ciclo de