El Lenguaje

Unificado de Modelado (UML)

Enrique Hernndez Orallo(ehernandez@disca.upv.es)

Cualquier rama de ingeniera o arquitectura ha

en-contrado til desde hace mucho tiempo la
representa-cin de los diseos de forma grfica.
Desde los inicios de la informtica se han estado
utilizando distintas formas de representar los
diseos de una forma ms bien personal o con
algn modelo grfico. La falta de estandarizacin
en la manera de representar grfica-mente un
modelo impeda que los diseos grficos realizados
se pudieran compartir fcilmente entre distintos
diseadores.

El lenguaje UML
tiene una notacin
grfica muy expresiva
que permite representar
en mayor o menor
medida todas las fases
de
un
proyecto
informtico: desde el
anlisis con los casos
de uso, el diseo con
los diagramas de clases,
objetos, etc., hasta la
imple-mentacin
y
configuracin con los
diagramas de despliegue.

HISTORIA DE
UML
Figura 1: Logo de UML

Se necesitaba por tanto un lenguaje no slo

para comunicar las ideas a otros desarrolladores
sino tam-bin para servir de apoyo en los
procesos de anlisis de un problema. Con este
objetivo se creo el Lenguaje Unificado de
Modelado (UML: Unified Modeling Lan-guage).
UML se ha convertido en ese estndar tan ansiado para representar y modelar la informacin
con la que se trabaja en las fases de anlisis y,
especialmente, de diseo.

El lenguaje UML
comenz a gestarse en
octubre de 1994 [1],
cuando Rumbaugh se uni
a la compaa Rational
fundada por Booch (dos
reputados investiga-dores
en el rea de metodologa
del software). El ob-jetivo
de ambos era unificar dos
mtodos
que
haban
desarrollado: el mtodo
Booch y el OMT (Object
Mode-lling Tool ). El

primer borrador apareci en octubre de 1995. En esaotras empresas para que

misma poca otro reputado investigador, Jacobson, se aportaran sus ideas. Todas
uni a Rational y se incluyeron ideas su-yas. Estas estas
colaboraciones
tres personas son conocidas como los tres amigos.condujeron a la definicin
Adems, este lenguaje se abri a la colabora-cin de de la primera versin de

UML.

91
93
95

Booch'91
Booch'93

OMT-1

OtrosOOSE

El modelado visual permite manejar la

compleji-dad de los sistemas a analizar o disear.
De la misma

OMT-2
UML 0.8
Revisin por parte

96

UML 0.9

del pblico

UML 1.0
97

UML 1.1

Aprobado como

98

UML 1.2 estndar por OMG

99

UML 1.3
Cambios menores

00

UML 1.4

02

UML 2.0

esenciales del sistema. Para facilitar este

modelado, se realiza una abstraccin y se
plasma en una notacin grfica. Esto se conoce
como mode-lado visual.

Figura 2: Evolucin de UML

Esta primera versin se ofreci a un grupo de

tra-bajo para convertirlo en 1997 en un estndar
del OMG (Object Management Group
http://www.omg.org). Este grupo, que gestiona
estndares relacionados con la tecnologa orientada
a objetos (metodologas, bases de datos objetuales,
CORBA, etc.), propuso una serie de
modificaciones y una nueva versin de UML (la
1.1), que fue adoptada por el OMG como estndar
en noviembre de 1997. Desde aquella versin han
habido varias revisiones que gestiona la OMG
Revision Task Force. La ltima versin aprobada
es la 1.4. En estos momentos se est desarrollando
una nueva versin en la que se incluirn cambios
importantes (principalmente aadir nuevos
diagramas) que conducirn a la versin 2.0
planificada para fines del 2002.

MODELADO VISUAL
Tal como indica su nombre, UML es un
lenguaje de modelado. Un modelo es una
simplificacin de la realidad. El objetivo del
modelado de un sistema es capturar las partes

cdigo fuente ge-nerar los modelos). Esto

permite que el modelo y el cdigo estn
actualizados, con lo que siem-pre se puede
mantener la visin en el diseo, de ms alto
nivel, de la estructura de un proyecto.

forma que para construir una choza no hace falta

un modelo, cuando se intenta construir un
sistema com-plejo como un rascacielos, es
necesario abstraer la complejidad en modelos
que el ser humano pueda entender.
UML sirve para el modelado completo de
sistemas complejos, tanto en el diseo de los
sistemas software como para la arquitectura
hardware donde se ejecuten.

Otro objetivo de este modelado visual es que

sea
independiente
del
lenguaje
de
implementacin, de tal forma que los diseos
realizados usando UML se pueda implementar
en cualquier lenguaje que soporte las
posibilidades de UML (principalmente lenguajes
orientados a objetos).
UML es adems un mtodo formal de
modelado. Esto aporta las siguientes ventajas:

1 Mayor rigor en la especificacin.

QU ES UML?
UML es ante todo un lenguaje. Un lenguaje
pro-porciona un vocabulario y una reglas para
permitir una comunicacin. En este caso, este
lenguaje se cen-tra en la representacin grfica
de un sistema.
Este lenguaje nos indica cmo crear y leer
los mo-delos, pero no dice cmo crearlos. Esto
ltimo es el objetivo de las metodologas de
desarrollo.
Las objetivos de UML son muchos, pero se
pue-den sintetizar sus funciones:

1 Visualizar: UML permite expresar de una

for-ma grfica un sistema de forma que
otro lo puede entender.

2 Permite realizar una verificacin y

validacin del modelo realizado.

2 Especificar: UML permite especificar

3 Se

pueden automatizar determinados

procesos y permite generar cdigo a partir
de los mode-los y a la inversa (a partir del

cules son las caractersticas de un

sistema antes de su construccin.
2

1 Construir: A partir de los modelos

especifica-dos se pueden construir los
sistemas diseados.

2 Documentar:

Los propios elementos

grficos sirven como documentacin del
sistema des-arrollado que pueden servir
para su futura re-visin.

Aunque UML est pensado para modelar

sistemas complejos con gran cantidad de
software, el lenguaje es los suficientemente
expresivo como para modelar sistemas que no
son informticos, como flujos de trabajo
(workflow ) en una empresa, diseo de la estructura de una organizacin y por supuesto, en el
diseo de hardware.
Un modelo UML esta compuesto por tres
clases de bloques de contruccin:

1 Elementos:

Los
elementos
son
abstracciones de cosas reales o ficticias
(objetos, acciones, etc.)

2 Relaciones: relacionan los elementos entre

s.

3 Diagramas: Son colecciones de elementos

con sus relaciones.
Veamos con mayor detalle los diagramas de
UML.

DIAGRAMAS UML
Un diagrama es la representacin grfica de un
conjunto de elementos con sus relaciones. En
concre-to, un diagrama ofrece una vista del
sistema a mode-lar. Para poder representar
correctamente un sistema, UML ofrece una amplia
variedad de diagramas para visualizar el sistema
desde varias perspectivas. UML incluye los
siguientes diagramas:

1 Diagrama de casos de uso.

2 Diagrama de clases.
3 Diagrama de objetos.
4 Diagrama de secuencia.

1 Diagrama de colaboracin.
2 Diagrama de estados.
3 Diagrama de actividades.
4 Diagrama de componentes.
5 Diagrama de despliegue.
Los diagramas ms interesantes (y los ms
usados) son los de casos de uso, clases y
secuencia, por lo que nos centraremos en stos.
Pare ello, se utilizar ejem-plos de un sistema de
venta de entradas de cine por Internet.
El diagrama de casos de usos representa
grficamente los casos de uso que tiene un
sistema. Se define un caso de uso como cada
interaccin supuesta con el sistema a desarrollar,
donde se representan los requisi-tos funcionales.
Es decir, se est diciendo lo que tiene que hacer
un sistema y cmo. En la figura 3 se mues-tra un
ejemplo de casos de uso, donde se muestran tres
actores (los clientes, los taquilleros y los jefes de

taquilla) y las operaciones que pueden realizar

(sus roles).
El diagrama de clases muestra un conjunto de
clases, interfaces y sus relaciones. ste es el
diagrama ms comn a la hora de describir el diseo
de los sistemas orientados a objetos. En la figura 4 se
muestran las clases globales, sus atributos y las
relaciones de una posible solucin al problema de la
venta de entradas.

En el diagrama de secuencia se muestra la

interaccin de los objetos que componen un
sistema de forma temporal. Siguiendo el
ejemplo de venta de entradas, la figura 5
muestra la interaccin de crear una nueva sala
para un espectculo.
El resto de diagramas muestran distintos
aspectos del sistema a modelar. Para modelar el
comportamien-to dinmico del sistema estn los
de interaccin, colabora-cin, estados y
actividades. Los diagramas de componentes y
despliegue estn enfocados a la implementacin
del sistema.

Figura 3: Diagrama de casos de uso

Figura 4:
Diagrama de
clases.

Figura 5: Diagrama de secuencia.

nte
indepe
ndiente
del
proceso de
desarro
llo que
se siga,
los
mismo
s
creado
res de
UML
han
propue
sto su
propia
metod
ologa
de
desarro
llo,
denom
inada
el
AProces
unqu o
Unific
e
UM ado de
L esDesarr
basta ollo

P
R
O
C
ES
O
D
E
D
ES
A
R
R
O
L
L
O

[2].
El
Proce
so
Unifi
cado
est
basad
o en
comp
onentes, lo
cual
quier
e
decir
que el
siste
ma
softw
are en
constr
ucci
n est
forma
do
por
comp
onent
es
softw
are
interc
onect

ados son
a tres:
trav es
s iterati
de vo e
inter incre
face mental
s
,
bien dirigid
defi o por
nido casos
s. de uso
Ade y
ms, centra
el do en
Proc la
eso arquit
Unif ectura
icad [3]:
o
1 D
utili
i
za el
UM
r
L
i
para
g
expr
i
esar
d
grfi
o
cam
ente
p
todo
o
s los
r
esqu
ema
c
s de
a
un
s
siso
tem
s
a
soft
d
war
e
e.
Pero
u
,
s
real
o
men
:
te,
los
B
aspe
a
ctos
s
que

defin
nen
d
este
o
Proc
s
eso
e
Unif
icad
o
e

n
los
cas
os
de
us
o,
los
de
sar
rol
lad
ore
s
cre
an
un
a
ser
ie
de
mo
del
os
de
dis
e
oe
im
ple
me
nta
ci
n
qu
e
los
lle
va
na
ca
bo.
Ad
em
s,
est
os
mo
del
os
se
val
ida
n
par
a
qu

e
s
e
a
n
c
o
n
f
o
r
m
e
s
a
l
o
s
c
a
s
o
s
d
e
u
s
o
.
F
i
n
a
l
m
e
n
t
e
,
l
o
s
c
a
s
o
s
d
e
u
s
o
t
a
m
b
i

n
s
i
r
v
e
n
p
a
r
a
r
e
a
l
i
z
a
r
l
a
s
p
r
u
e
b
a
s
s
o
b
r
e
l
o
s
c
o
m
p
o
-

ne
nt
es
de
sar
rol
la
do
s.

1 Ce
ntr
ad
o
en
la
ar
qu
ite
ct
ur
a:
En
la
ar
qu
ite
ctu
ra
de
la
co
nst
ru
cci
n,
ant
es
de
co
nst
rui
r
un
edi
fic
io
st
e
se
co
nte
m
pla
de
sd
e
va

ri
o
s
p
u
n
t
o
s
d
e
v
is
t
a
:
e
st
r
u
c
t
u
r
a
,
c
o
n
d
u
c
c
i
o
n
e
s
e
l

c
tr
i
c
a
s,
f
o
n
t
a
n
e
r
a
,
e

tc.
Ca
da
uno
de
est
os
asp
ect
os
est

rep
res
entad
o
por
un
gr
fic
o
con
su
not
aci
n
cor
respon
die
nte.
Sig
uie
ndo
est
e
eje
mp
lo,
el
con
cep
to
de
arq
uite
ctu
ra
soft
war
e
incl
uye
los
asp
ect
os

est
ti
co
sy
di
n
mi
co
s
m
s
sig
nif
ica
tiv
os
del
sis
te
ma
.

2 Ite
rat
iv
o
e
in
cr
em
en
tal
:
To
do
sis
te
ma
inf
or
m
tic
o
co
m
ple
jo
su
po
ne
un
gr
an
esf
ue
rz
o

q
u
e
p
u
e
d
e
d
u
r
a
r
d
e
s
d
e
v
a
ri
o
s
m
e
s
e
s
h
a
st
a
a

o
s.
P
o
r
l
o
t
a
n
t
o
,
l
o
m

s
p
r

c
ti
c

o
es
div
idir
un
pro
yec
to
en
var
ias
fas
es.
Act
ual
me
nte
se
sue
le
hab
lar
de
ciclo
s
de
vid
a
en
los
que
se
real
iza
n
var
ios
rec
orrid
os
por
tod
as
las
fas
es.
Ca
da
rec
orri
do
por
las
fas
es
se

de
no
mi
na
ite
rac
i
n
en
el
pr
oy
ect
o
en
la
qu
e
se
rea
liz
an
va
rio
s
tip
os
de
tra
baj
o
(d
en
o
mi
na
do
s
flu
jos
).
Ad
em
s,
ca
da
ite
rac
i
n
pa
rte
de
la
ant
eri
or
inc

r
e
m
e
n
t
a
d
o
o
r
e
v
is
a

ndo
la
fun
cio
nali
dad
im
ple
me
nta
da.
Se
sue
le
den

omi
na
r
pr
oc
es
o.
Ve
r
fig
ur
a
6.
5

Etapas
Flujos de trabajo
fundamentales

Inicio

Elaboracin Construccin Transicin

Una iteracin en la
fase de elaboracin

Requisitos
Anlisis
Diseo
Implementacin
Prueba
Iter.
#1

Iter.
#2

---

---

---

---

Iter. Iter.
#n-1 #n

Figura 6: Proceso iterativo e incremental

Resumiendo, el Proceso
Unificado
es
un modelo
complejo
con
mucha
terminologa propia, pensado
principalmente para el desarrollo
de grandes proyec-tos. Es un
proceso que puede adaptarse y
extenderse en funcin de las
necesidades de cada empresa.

CONCLUSIONES

estndar por
la OMG.

4 Prcticament
e todas las
herramientas
CASE y de
desarrollo la
han adaptado
como
lenguaje de
modelado.

En
resumen,
Es fcil predecir que UMLUML resuelve de
ser el lenguaje de mo-deladoforma bastante sade software de uso universal.tisfactoria un viejo
Las principales razones paraproblema
del
ello son:
desarrollo
de
softwa-re como es
1 En el desarrollo hansu
modelado
participado
grfico. Adems, se
investigadores
deha llega-do a una
reconocido prestigio.
solucin unificada
basada en lo mejor
2 Ha sido apoyado porque haba hasta el
prcticamente todas lasmomento, lo cual lo
empresas importantes dehace todava ms
excepcional.
informtica.

REFERENC
IAS
1. G.

Booch,
J.
Rumbaugh y I.
Jacobson,
"El
Lenguaje
Unificado
de
Modelado",
Addison Wesley,
1999

2. I. Jacobson, G.
Booch,
J.
Rumbaugh , "El
Proceso Unificado
de
Desarrollo",
Addision Wesley,
2000

3. E. Hernndez, J.
Hernndez,
C.
Lizandra,
"C++
Es-tandar",
ITP
Paraninfo 2001.

3 Se ha aceptado como un
6