UML Unified Modeling Language

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje grfico

utilizado para visualizar, especificar y documentar modelos en sistemas de software orientado a
ojetos! Estos modelos son astracciones del mundo real en t"rminos de ojetos, #ue esconden los
detalles espec$ficos relacionados a un prolema, pero #ue son dise%ados para dar soluciones!
UML no es un lenguaje de desarrollo, no dice #ue &acer primero ni #ue &acer luego, ni como dise%ar un
sistema' pero ayuda a visualizar un dise%o y comunicarlo con otros de la misma manera #ue
ar#uitectos, traajadores e ingenieros se entienden a trav"s de planos!
UML tiene distinto tipos de diagramas #ue pueden ser utilizados para descriir un modelo desde
diferentes tipos de vistas y #ue pueden ser categorizados en tres categor$as(
Modelado Funcional
El diagrama utilizado para modelar la parte funcional de un sistema, es decir a#uello #ue indica #ue es
lo #ue &ace el sistema, es el diagrama de casos de usuarios!
Modelado de Objetos
El diagrama utilizado para modelar la parte de estructural de un sistema, es decir a#uel #ue muestra el
estado y el comportamiento del sistema, es el diagrama de clases!
Modelado Dinmico
Los diagramas utilizados para modelar la parte dinmica de un sistema, son el )iagrama de *ecuencias,
El )iagrama de +ctividades, y El diagrama de estado de m#uinas!
Diagramas de Casos de Usuarios
)escrien #u" ms #ue c,mo, lo #ue un sistema &ace desde el punto de vista de un oservador e-terno!
+ continuaci,n se descrie los elementos #ue son parte de un diagrama de casos de usuarios(
Uso de de Caso o escenario

Estn relacionados con escenarios! Un escenario o caso de uso es lo #ue ocurre, la tarea u operaci,n
#ue se ejecuta, cuando alguien interactua con el sistema! Un caso de uso es representado por un
ovalado(
Actor
Ese alguien, algo o cliente #ue origina las tareas o interactua con el sistema es denominado +ctor, y no
necesariamente es una persona, o un ojeto' sino ms ien representa un rol! Un actor puede ser a su
vez otro caso de uso respectivamente! Un actor es representado por la siguiente figura(
Relacin
La relaci,n por asociaci,n indica la invocaci,n desde un actor o caso de uso a otro caso de uso y esta
representado simplemente por una flec&a!
Un diagrama de .asos puede tener varios escenarios o usos de casos y un escenario puede contar con
ms de un actor!
Ejemplo /( *istema tradicional de pedido de radiom,viles(
Diagramas de Clases
Muestra la estructura o una vista general del sistema, representando sus clases y las
relaciones entre ellas! E-presa amos, el estado persistente del sistema, as$ como
tami"n el comportamiento del sistema!
*in emargo los diagramas de .lases son estticos! Ellos descrien #ue ojetos
interactuan, pero no descrien #ue pasa cuando ellos lo &acen!
Un diagrama de clases tiene los siguientes elementos(
Clase
Una clase es lo #ue encapsula la informaci,n sica de un ojeto! Es tami"n un plano
del cual se crean o instancian los ojetos!
*olicita radiom,vil
0peradora
.liente
.onsulta radiom,vil
1eclama radiom,vil
.ancela radiom,vil
Una clase esta representada en un diagrama UML por un rectangulo compuesto de tres
secciones &orizontales, cada una de ellas representando a su vez el nomre, los atriutos
y las operaciones o m"todos de la clase respectivamente, tal como se ilustra a
continuaci,n(
2omre de la .lase 3 Nombre de la Clase
+triutos
M"todos 3 Mtodos
El nomre de la clase dee estar en italicas, cuando la clase es astracta!
)e acuerdo a la visiilidad de los atriutos, "stos pueden ser representados de la
siguiente manera(
4 pulic
- private
5 protected
.uando los m"todos son definidos astractos, "stos tami"n deen estar en
italicas!
)e acuerdo a la visiilidad de los m"todos, "stos pueden ser representados de la
siguiente manera(
4 pulic
- private
5 protected
6 pac7et-private
Relacin
.uando se modela un sistema, ciertos ojetos estan relacionados entre ellos! )e acuerdo
a la forma como se relacionan &ay cinco tipo de relaciones(
.lase+ .lase8
+sociaci,n 8idireccional(
9odo :arte
+gregaci,n(
:arte)ependiente :arte1e#uerida
)ependencia(
*uper.lase *u.lase
;eneralizaci,n(
.lase+ .lase8
+sociaci,n )ireccional(
Una asociaci,n es una relaci,n entre las instancias de dos clases! En el diagrama
es representado por un enlace connectando a dos clases!
Una asociaci,n es idireccional entre dos clases, cuando amas instancias
necesitan saer una de la otra para e-istir o poder &acer su traajo! 9odas las
relaciones entre ojetos se asumen idireccionales por defecto! :or ejemplo(
Un avi,n para volar tiene #ue saer de un vuelo! +s$ mismo un ojeto vuelo para
e-istir, dee estar relacionado con un avi,n!

Una asociaci,n es unidireccional entre dos clases, cuando la asociaci,n es
solamente conocida por una de las clases! La flec&a indica la direcci,n en #ue la
asociaci,n puede ser consultada o recorrida! :or ejemplo un detalle de venta esta
relacionado a un item de producto oligadamente! *in emargo desde un item de
producto no podemos recorrer a un detalle de venta espec$fico! 0tro ejemplo
ser$a la relac$on entre un ojeto de reporte de cuentas sore giradas y el ojeto de
cuenta ancaria! El ojeto de reporte de cuentas soregiradas dee saer de las
cuentas ancarias con esa condici,n en determinada fec&a! :ero una cuenta
ancaria por ms #ue "ste soregirada no tiene idea a #ue reporte de ctas sore
girada pertenece o &a pertenecido en el pasado!
+gregaci,n es un tipo especial de relaci,n para modelar una relaci,n entre un
todo y sus partes! <ay dos tipos de relaciones por +gregaci,n(
+gregaci,n 8sica
+gregaci,n por .omposici,n
En la agregaci,n sica, el tiempo de vida de la clase #ue es parte, es
independiente de la clase #ue es el todo! :ara modelar, este tipo de relaci,n se
traza una l$nea entre amas clases con un romo vac$o del lado de la clase #ue es
todo! Un ejemplo ser$a la relaci,n #ue &ay entre una clase auto y otra llanta! Una
llanta puede estar lista semanas antes, y puede permanecer en un almcen antes de
ser colocadas a un autom,vil en la l$nea de ensamlaje!
1ep.tas*ore;iro .ta8ancaria
+vi,n =uelo
En la agregaci,n por composici,n, el tiempo de vida de la clase #ue es parte, s$ es
dependiente de la clase #ue es el todo! :ara modelar, "ste tipo de relaci,n se traza
una l$nea entre amas clases con un romo relleno del lado de la clase #ue es un
todo! Un ejemplo ser$a la relaci,n #ue &ay entre una empresa y sus
departamentos! 2o pueden &aer instancias de departamentos, sin antes o despu"s
de e-istir una empresa!
La relaci,n de dependencia, representa un tipo de relaci,n muy particular, cuando
la instanciaci,n de una clase es dependiente de otro ojeto o clase! *e denota por
una flec&a a rayas! :or ejemplo la relaci,n entre una aplicaci,n y sus cuadros de
dialogo! Un ojeto de clase cuadro de dialogo, necesita de un ojeto de clase
aplicaci,n para #ue pueda e-istir o funcionar correctamente! Un ojeto de clase
de aplicaci,n de juego de ingo, necesita de otro ojeto de matemticas de juego
#ue est" cargado previamente!
+s$ mismo, a partir de UML >!? una interface es considerada como un elemento
de modelado, de manera similar a un clase, s,lo #ue lleva la palara
@@interfaceAA antes del nomre! +l igual #ue en la relaci,n de dependencia, una
relaci,n entre una clase y la interface #ue implementa es especificada por una
flec&a a rayas! La orientaci,n de la flec&a va desde la clase #ue implementa una
interface y #ue es la parte dependiente, &asta la interface #ue es la parte re#uerida!
Matemticas Buego
:rofesor
@@CnterfaceAA
:ersona
=e&iculo Llanta
Empresa )epartamento
La relaci,n de generalizaci,n "sta relacionada con &erencia! Una clase puede
&eredar las funciones y propiedades de una superclase, y adems puede a%adir su
propia funcionalidad! :ara modelar &erencia en un diagrama se diuja una flec&a
sin la punta rellenada desde la clase &ijo &asta la clase padre! Un ejemplo puede
ser #ue tanto una clase cuenta corriente, como otra clase caja de a&orro, amas
pueden &eredar de una clase padre cuenta ancaria!
Cardinalidad de Relaciones
La cardinalidad de las relaciones indica el grado y nivel de dependencia, se
anotan en cada e-tremo de la relaci,n y "stas pueden ser(
uno o muc&os( /!!D (/!!n)
? o muc&os( ?!!D (?!!n)
n nEmero fijo( m (m denota el n mero)
uno( /
? o muc&os( D
? a cinco( ?!!F
Nombres de Rol
+l igual #ue la cardinalidad #ue se coloca en los e-tremos de una relaci,n,
tami"n se puede colocar los nomre de rol para clasificar la naturaleza de la
asociaci,n
a!uetes
Los pa#uete o pac7ages, permiten organizar a las clases en namespaces, lo #ue es
similar a carpetas en un sistema de arc&ivos! )ividir un sistema en pa#uetes, lo
&ace ms fcil de entenderlo, especialmente s$ los pa#uetes representan una parte
espec$fica del sistema! Los pa#uetes son representados en el diagrama de clases
como unos cuadrados, con una solapa en la parte superior iz#uierda indicando el
espacio de nomre! :uede representar las clases #ue agrupa de dos maneras
diferentes, tal como se muestra a continuaci,n(
.ta8ancaria
.ja+&orro
+ continuaci,n se presenta un ejemplo ms detallado(
Sistema de Pedido de Ordenes
.ta8ancaria
.ja+&orro .ja+&orro
.uentas
.ta8ancaria
.ja+&orro .ja+&orro
.uentas
4
Diagrama de "ecuencia
+ petici,n de un evento o para realizar alguna tarea, un diagrama de secuencias
representa en el tiempo como los ojetos interactuan entre s$ secuencialmente!
Es decir un diagrama de secuencia muestra #ue mensajes son enviados entre los
ojetos del sistema, as$ como tami"n el orden en #ue ocurren!
Los diagramas de secuencia esta organizados de acuerdo al tiempo! El tiempo
progresa a medida #ue se va aajo de la pgina!
Los ojetos involucrados en la operaci,n son mostrados de iz#uierda a derec&a,
de acuerdo a cuando ellos van formando parte de la secuencia de mensajes! Estn
representados por cuadrados indicando de manera surayada el nomre de la
instancia en minEsculas y el nomre de la clase a la #ue pertenecen en mayEsculas
seguido de dos puntos!
.ada ojeto tiene un a-is de tiempo vertical representado por una l$nea a rayas,
indicando el tiempo #ue el ojeto se encuentra vivo! Ej(
<ay veces #ue en vez de mostrar instancias de un ojeto, en un diagrama de
secuencias se muestran roles! :or ejemplo podemos especificar roles tales como
comprador o vendedor, sin especificar #uien juega esos roles! En esos casos el
nomre del rol en el cuadrado no va surayado!
En cada a-is se encuentra una arra de activaci,n #ue indica el tiempo de
ejecuci,n de un mensaje o m"todo invocado!
Los mensaje son enviados, o los m"todos son invocados de un ojeto a otro, a
trav"s de flec&as &orizontales, #ue van desde la arra de activaci,n de un ojeto,
&asta la punta o el comienzo de la arra de activaci,n de otro ojeto!
*$ la llamada al m"todo del ojeto #ue esta reciiendo el mensaje, es s$ncrona' la
flec&a #ue representa dic&a operaci,n es s,lida! )e lo contrario s$ la llamada es
as$ncrona, la punta de la flec&a es normal! :or ejemplo el siguiente diagrama de
secuencias muestra llamadas s$ncronas(
rojo(.olor
El primer mensaje de un diagrama de secuencias siempre empieza arria a la
iz#uierda! *usecuentemente los mensajes a%adidos al sistema se uican
ligeramente ms aajo y a la derec&a #ue el anterior mensaje!
Los mensajes de retorno #ue se ven en el anterior diagrama son opcionales y son
representados por una flec&a normal de retorno de l$nea punteada! Encima de la
flec&a se descrie el o los ojetos #ue esta retornando el mensaje!
Un ojeto puede invocar un m"todo en s$ mismo! En tal caso la flec&a &ace un
loop! El siguiente diagrama por ejemplo, es una versi,n mejorada del anterior, en
el cual el ojeto system se env$a un mensaje as$ mismo para determina cuales son
los reportes disponiles, despu"s #ue &a verificado #ue el usuario esta limpio
registro criminales y de formar la respuesta con los reportes disponiles!

*e puede colocar tami"n e-presiones entre corc&etes para representar
condiciones #ue controlen el flujo en la secuencia! )ic&as condiciones se colocan
encima de la l$nea de mensaje y antes del nomre de mensaje! *$ se cumple la
condici,n reci"n se envia el mensaje, tal como se ilustra en el siguiente ejemplo(
.omo se puede ver en el diagrama de secuencias, la oficina de registros solo
puede registrar a un estudiante a una clase, siempre #ue no tenga cuentas
pendientes!
*e puede utilizar fragmentos cominados tami"n para relacionar ms de una
iteracci,n entre otros ojetos #ue est"n sujeta a una condici,n! )ic&os
fragmentos cominados son cuadros #ue engloan las iteracciones de ojetos
sujetas a una condici,n, con una eti#ueta en forma de oreja de perro en la parte
superior iz#uierda con la palara reservada option, y la condici,n entre corc&etes
deajo de la misma! :or ejemplose puede detallarse ms aEn el anterior ejemplo,
tal como se muestra a continuaci,n(
9ami"n se puede utilizar fragmentos cominados para modelar una condici,n
l,gica if t&en else! *in emargo ya no se utiliza opt, sino alt, tal como se muestra
a continuaci,n(
9ami"n se puede utilizar fragmentos cominados para modelar una iteracci,n en
ucles! *in emargo ya no se utiliza ni opt, ni alt como la eti#ueta! *e utiliza
loop! + continuaci,n se presenta un ejemplo(
*olicita.onfirmaci,n
(tiempo)
asigna9iempo+tenci,n(tiempo)
new(datoEncargo)
encargo
tiluc&i(1adioM,vil cliente(.liente (Encargo pedido(:edidoMovil
solicitaMovil(cliente,
uicaci,n, datosEncargo)
loop
G<ay EncargoH
crear:edido(cliente,
uicaci,n)
a%adir.ola:edidos(pedido)
a%adir(encargo)
reciir.onfirmaci,n
(confirmaci,n)
alt
Gconfirmaci,n I 0!7!H
asigna(movil)
GelseH
elimina(pedido)
Diagrama de Com#onentes
El principal prop,sito de un diagrama de componentes es mostrar las relaci,nes
estructurales entre los componentes de un sistema!
Un diagrama de componentes tiene un nivel de astracci,n ms grande #ue un
diagrama de clases! Usualmente un componento esta compuesto por una o ms
clases, o por uno o ms ojetos en tiempo de ejecuci,n!
Un componente es considerado una unidad auton,ma dentro de un sistema o
susistema #ue encapsula comportamiento a trav"s de una o ms interfaces por lo
cual es reutilizale!
)esarrolladores &allan Etil el diagrama de componentes, por#ue provee una vista
ar#uitect,nica de alto nivel del sistema #ue empezarn a construir!
+ntes de UML > se representaa la relaci,n entre dos componentes de la siguiente
forma(
La notaci,n anterior era muy simple y no escalaa ien en sistemas muy grandes,
por lo #ue UML >!? mejor, consideralemente el conjuto de notaciones para
diagramas de componentes!
En UML >!? un componente es representado por una caja con divisiones
opcionales alineadas verticalmente! .omo m$nimo se dee colocar el nomre del
componente y el te-to yJo icono #ue representa un componente tal como se
muestra a continuaci,n(
En las otras divisiones de un componente se pueden colocar las interfaces #ue un
componente provee y re#uiere! Las interfaces #ue un componente provee
representan un contrato formal de los servicios #ue presta! :ero un componente
KcomponentL
0rden

0rden
KcomponentL
0rden
*istema
de 0rden
*istema
de 0rden
tami"n puede re#uerir interfaces de otros componentes, por#ue a pesar de ser una
unidad auton,ma, para funcionar un componente tami"n puede re#uerir de los
servicios de otros componentes!
El mismo componente puede ser ilustrado en una una notaci,n ligeramente
diferente de la siguiente manera(
En esta notaci,n s$molos con un circElo completo, tami"n conocidos como
c&upetes, representan las interfaces #ue el componente provee! Mientras los
s$molos de medio circElos, tami"n conocidos como soc7et, representan las
interfaces #ue un componente re#uiere!
:ara mostrar las relaciones entre componentes, se dee diujar una flec&a de
dependencia #ue va desde la interface re#uerida de un componente &asta la
interface provista por otro componente!
KcomponentL
0rden
Kinterfaces proveidasL
Entrada)e:edido
.uenta:agale
Kinterfaces re#ueridasL
:ersona
KcomponentL
0rden
Entrada)e:edido
.uenta:agale
:ersona
KcomponentL
*istema de 0rdenes
8us#ueda.liente
KcomponentL
*istema de Cnventario
+cceso:roducto
+cceso:roducto
KcomponentL
1epositorio de .liente
8us#ueda.liente
En el anterior diagrama a pesar de #ue el nomre de las interfaces re#uerida y
provista entre dos componentes relacionados es la misma, &ay veces #ue puede
ser diferente! :or ejemplo cuando un componente provee una interface #ue es una
su-clase de una interface re#uerida!
9ami"n se puede modelar la estructura interna de un componente, cuando esta
compuesta por otros componentes, tal como se muestra a continuaci,n(
En el anterior diagrama el componente tienda esta compuesto de tres
componentes( *istema de 0rdenes, *istema de Cnventario y 1epositorio de
.liente! + su vez provee la interface Entrada0rden y re#uiere la interface .uenta!
Las relaciones entre componentes internamente dentro de otro componente son
modeladas, con lo #ue en UML se llama conector ensamlador( es decir
directamente el soc7et y c&upete juntos sin l$neas de dependencia!
*e puede usar un conector ensamlador tami"n cuando varios componentes
re#uieren la misma interface de un solo componente, como forma de simplificar
varias lineas de dependencia!
El componente cuenta con dos puertos en forma de cuadrado en los lados, #ue
representan la forma de modelar como las interfaces de un componente se
.uenta
9ienda
KcomponentL
*istema de 0rdenes
KdelegaL
KcomponentL
*istema de Cnventario
+cceso:roducto
Entrada0rden
KcomponentL
1epositorio de .liente
8us#ueda.liente
Entrada0rden
KdelegaL
.uenta
relacionan con sus partes internas! En el anterior caso el diagrama es sencillo, y es
ovio #ue la interface entrada ordenes est relacionada con el componente sistema
de ordenes! :ero en un ejemplo ms adelante se puede apreciar ms como las
interfaces se relacionan con clases y partes internas de un componente, a trav"s de
los puertos!
En un puerto de un componente se pueden colocar todas las interfaces #ue est"n
relacionadas o con otro componente o por una agrupaci,n l,gica!
:or claridad es mejor relacionar un puerto con una sola interface! +dems los
puertos pueden soportar comunicaci,n unidireccional o idireccional! :ueden
&aer puertos de entrada, de salida, o de entrada y salida!
En el siguiente ejemplo se muestra por#ue es ms fcil relacionar una interface
con un solo puerto, y #ue los puertos ayudan a modelar como las interfaces se
relacionan con las clases, otros componentes o partes internas de un componente!
KcomponentL
Estudiante
+dministracionEstudiante
<orarioEstudiante
.ontrol+cceso
Encryptacion
:ersistencia
)ataacceso
KcomponentL
M-*ecurity
.ontrol+cceso
Encriptacion
KcomponentL
MegaEncrypter
Encriptacion
Un diagrama de componentes puede representar tanto aspectos t"cnicos como
l,gicos! :or ejemplo un componente puede ser t"cnico al relacionarse a la api de
una ase de datos, o puede ser un componente relacionado con la inteface grfica,
o tami"n puede ser l,gico como referirse a un componente estudiante! +
continuaci,n por ejemplo se presenta un diagrama del dominio de componentes
de un sistema universitario en mayor escala(
Estudiante
Nacade+dministracion
+dministracionEstudiante
KinfrastructureL
:rocesador MML
MML
Nacade<orario
)ataEstudiante
Estudiante
)ireccion
)ata
*eguridad
<orarioEstudiante
)ata+cceso
.ontrol+cceso
Encryptacion
:ersistencia
<ay dos estrategias para desarrollar un modelo por componentes, el de arria
&ac$a aajo o el de aajo &ac$a arria! La estrateg$a de arria &ac$a aajo es un
uen mecan$smo para proveer una visi,n de la ar#uitectura del sistema temprano
en el proyecto! +lgo #ue es importante cuando se traaja en e#uipos, ya #ue se
#uiere traajar &ac$a una misma visi,n! El prolema de "ste enfo#ue, es #ue sufre
de una tendencia a sore dise%ar el sistema con componentes #ue tal vez no &ayan
sido necesarios! :or ejemplo en el anterior diagrama se colocan los componentes
de seguridad y persistencia, y posilemente la verdad no se necesita nada tan
remotamente complicado!
El otro enfo#ue de desarrollar un modelo por componentes, es el de aajo &ac$a
arria! *e &ace "sto, cuando ya &ay un sistema orientado ojetos y se desea
componetizarlo para rescatar funcionalidad reutilizale o se lo decide dividirlo
entre e#uipos! .uando estamos siguiendo "ste enfo#ue es uena prctica seguir
los siguientes pasos(
Mantener a los componentes co&esivos! Un componente dee implementar
un conjunto simple de funcionaliades relacionadas! Un componente es un
conjunto de clases #ue colaoran entre ellas para proveer servicios a trav"s
KcomponentL
Edificios
+cceso)ata
Edificios
KcomponentL
Estudiante
+cceso)ata
Estudiante
KcomponentL
*eminario
+cceso)ata
*eminario
KcomponentL
<orario
+cceso)ata
<orario
Encripcion
.ontrol+cceso
:ersistencia
KUCL
+dm*eminario
KUCL
+dmEstudiante
KCnfraestructuraL
*eguridad
KCnfraestructuraL
:ersistencia
KasededatosL
8) U2C=!
B)8.
de un conjunto de contratos o interfaces co&esivas!
*e asignan todas las clases relacionadas a la l,gica de negocio a
componentes estereotipados como dominio!
*e asignan todas las clases relacionadas a la interfaces con el usuario a
componentes estereotipados como aplicaci,n
*e asignan todas las clases t"cnicas, es decir a#uellas #ue presentan
servicios a nivel de sistema como seguridad, persistencia, o midleware, a
componentes estereotipados como infraestructura,
Cdentificar el tipo de colaoraci,n de una clase de negocio! <ay clases #ue
son servidor, otras clientes, y otras servidorJcliente! 9odas las clases #ue
son servidor a menudo forman su propio componente de dominio! Las
clases #ue son clientes pura, normalmente no pertenecen a componentes de
dominio por#ue solo recien mensajes y no a%aden a la funcionalidad! Las
clases cliente normalmente terminan en componentes de aplicaci,n!
Minimizar el tama%o del flujo de mensajes entre componentes! La
comunicaci,n dentro de un componente normalmente se refiere a mensajes
enviados entre ojetos en memoria! :ero la comunicaci,n entre
componentes puede re#uerir un esfuerzo caro denominado mars&alling' en
el #ue un mensaje y sus parmetros son convertidos en datos, transmitido, y
luego convertido en mensaje nuevamente! :or lo #ue &ay #ue ver donde
corresponde ms convenientemente una clase, s$ fuera de un componente o
incluida en un componente de acuerdo a como se tiene #ue comunicar con
otras clases!