UTML

Programación Orientada a Objetos 1

Notación UML para modelado Orientado a
Objetos

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

2 Notación UML para modelado Orientado a Objetos

Índice

1.1. ¿Qué es UML?.................................................................................................. 3
1.2. ¿Por qué interesa UML en la asignatura de Programación Orientada a
Objetos? ........................................................................................................................ 3
1.3. ¿Qué se va a modelar? ...................................................................................... 3
1.4. Diagramas......................................................................................................... 4
1.4.1. Diagramas de Clases................................................................................. 4
1.4.2. Diagramas de Objetos............................................................................... 5
1.4.3. Diagramas de Interacción ......................................................................... 6
1.4.3.1. Diagramas de secuencia........................................................................ 6
1.4.3.2. Diagramas de colaboración .................................................................. 8
1.5. Clases................................................................................................................ 8
1.5.1. Clases Abstractas...................................................................................... 9
1.5.2. Interfaces .................................................................................................. 9
1.6. Objetos............................................................................................................ 10
1.7. Relaciones....................................................................................................... 10
1.7.1. Detalles ................................................................................................... 10
1.7.1.1. Navegabilidad..................................................................................... 11
1.7.1.2. Multiplicidad ...................................................................................... 11
1.7.1.3. Rol ...................................................................................................... 12
1.7.2. Composición........................................................................................... 13
1.7.3. Uso.......................................................................................................... 13
1.7.4. Asociación .............................................................................................. 13
1.7.5. Herencia.................................................................................................. 14
1.8. Recapitulación ................................................................................................ 15
1.9. Consideraciones.............................................................................................. 16
1.10. Bibliografía................................................................................................. 17



1.1. ¿Qué es UML?

El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un
lenguaje estándar, basado en una notación gráfica, que se utiliza para modelar software.

Es un lenguaje de propósito general que pretende ser un estándar mundial y se
utiliza para visualizar, especificar, construir y documentar las diferentes “piezas” de un
sistema.

¿Qué es un modelo? Una simplificación de la realidad.

¿Por qué se modela? Se construyen modelos para poder entender mejor el
sistema a desarrollar, o bien, un sistema desarrollado.

1.2. ¿Por qué interesa UML en la asignatura de Programación Orientada a
Objetos?

En la asignatura de Programación Orientada a Objetos se aprende un nuevo
paradigma de programación: el paradigma orientado a objetos. A su vez, se utiliza el
lenguaje Java para implementar el código de los programas orientados a objetos.

Para modelar los programas de forma gráfica, viendo las relaciones entre las
clases y cómo colaboran unos objetos con otros, se prefiere utilizar una notación
estándar. De esta manera, el alumno va conociendo parte de la notación, UML en este
caso, lo cual le será útil por varias razones:

Le permite ir familiarizándose con un lenguaje de modelado estándar que
verá en otras asignaturas de la titulación.
Le permite entender modelos con esta notación.

Por todo ello, se verá cómo implementar en código Java un modelo diseñado con
UML. De esta manera, se podrán hacer diagramas modelando los programas orientados
a objetos que se implementen con el lenguaje Java.

1.3. ¿Qué se va a modelar?

Se presentará una selección de las características más representativas de UML.
De éstas no se detallará todo de forma completa, sino sólo aquello que nos interese para
representar nuestros diseños orientados a objetos implementados con el lenguaje Java.



Además, conviene dejar claro que:

• UML es un lenguaje de modelado

• Java es un lenguaje de implementación

Por lo tanto, no existe una representación única para código Java, ni tampoco
unas reglas exactas de “dado cierto código, entonces cierta representación”, que se
puedan seguir siempre. De hecho, dos modelados diferentes pueden tener el mismo
código asociado, por lo que no “hay viaje de vuelta”. Es decir, dado un código no es
posible determinar las relaciones entre las diferentes clases y, por lo tanto, cual es la
representación UML. Se trata de un modelado a nivel conceptual.

El estándar UML no pide que se indique todo en los diagramas, sino que lo que
se refleje en ellos sea cierto.

En nuestro caso, dado un programa orientado a objetos nos interesa tanto su
visión estática como su visión dinámica. La visión estática se puede ver como un
conjunto de clases que permiten alcanzar altas cotas de abstracción, encapsulación,
modularidad y jerarquía. Por otra parte, la visión dinámica de un programa se puede ver
como un conjunto de objetos, los cuales colaboran entre sí mediante el
desencadenamiento de instanciaciones y de paso de mensajes.

Por ello, se van a modelar tanto los aspectos estáticos como los aspectos
dinámicos de un programa orientado a objetos.

Los aspectos estáticos se modelan mediante diagramas de clases y diagramas de
objetos. Los primeros se componen de un conjunto de clases y las relaciones entre ellas,
mientras que en los segundos las relaciones se dan entre un conjunto de objetos.

Los aspectos dinámicos se modelan mediante diagramas de interacción. Éstos,
presentan la forma en la que interactúan los diferentes objetos del diagrama.

1.4. Diagramas

1.4.1. Diagramas de Clases

Los diagramas de clases proporcionan una perspectiva estática del código. Se
componen de:

• Clases

o Gráficamente se representan mediante un rectángulo con el nombre de
la clase.

• Relaciones

o De forma gráfica se trata de una línea que une las clases que relaciona.

Un ejemplo de diagrama de clases se presenta en la figura 1.



Ter

Turno Tablero
Jugador

Ficha Coordenada

Figura 1. Diagrama de clases

1.4.2. Diagramas de Objetos

Los diagramas de objetos proporcionan una perspectiva estática de una
ejecución del código. Presentan instantáneas de instancias de los elementos que
aparecen en los diagramas de clases. En definitiva, muestran un conjunto de objetos y
sus relaciones en un momento concreto (“fotografía” de un momento determinado).

Básicamente se componen de:

• Objetos

o De forma gráfica se representa mediante un rectángulo con el nombre del
objeto.

• Relaciones

Un ejemplo de diagrama de objetos se presenta en la figura 2.



:Ter

:Turno
:Tablero
:Coordenada

...
:Jugador
:Coordenada
:Jugador
:Ficha

:Ficha

:Ficha

Figura 2. Diagrama de objetos

La diferencia clara entre un diagrama de clases y un diagrama de objetos es que
el primero representa los aspectos estáticos del sistema, y el segundo los aspectos
estáticos de una interacción concreta entre los objetos.

1.4.3. Diagramas de Interacción

En los diagramas de interacción se puede ver el patrón de comportamiento de un
conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un
contexto para lograr un propósito. Son dos los tipos de diagramas de interacción:
secuencia y colaboración. Ambos están basados en la misma información, aunque cada
uno enfatiza un aspecto diferente: el diagrama de secuencia destaca la ordenación
temporal de los mensajes y el diagrama de colaboración destaca la organización
estructural (qué objetos colaboran con otros) de los objetos que intercambian mensajes.

1.4.3.1. Diagramas de secuencia

Estos diagramas presentan, ordenados temporalmente, los objetos que participan
en una interacción y los mensajes que se intercambian.

En el diagrama, en cada eje vertical se coloca un objeto. Los mensajes se
representan mediante flechas horizontales de un objeto a otro, donde el retorno se
representa mediante una línea punteada del objeto pasivo al objeto agente del mensaje.
El tiempo fluye de arriba hacia abajo.

Un ejemplo de diagrama de secuencia de presenta en la figura 3.



ter:Ter turno:Turno t:Tablero j:Jugador

jugar()
mostrar()

poner(t)

cambiar()

mostrar()

...

Figura 3. Diagrama de secuencia

Para especificar quién y cuándo se crean los objetos, se utiliza el estereotipo1
“<<create>>”. Como ejemplo se presenta el diagrama de la figura 4.

j:Jugador t:Tablero

poner(t)

<<create>> c:Coordenada

recoger()

poner(c,f)

...

Figura 4. Diagrama de secuencia con estereotipos

1
Estereotipo: mecanismo de extensibilidad de UML para representar una distinción de uso. Es aplicable a
cualquier elemento de modelado.



1.4.3.2. Diagramas de colaboración

Un diagrama de colaboración también muestra la interacción entre los objetos,
pero basándose en las relaciones entre ellos. En la figura 5 se puede ver un ejemplo de
diagrama de colaboración.

5: mostrar()
1: jugar() 2: mostrar()

ter:Ter t:Tablero
4: c am
bi ar(
)

3: poner(t)

turno:Turno
j:Jugador

Figura 5. Diagrama de colaboración

El diagrama de secuencia y el diagrama de colaboración son equivalentes,
ambos muestran una interacción entre los objetos. Simplemente uno de ellos destaca la
ordenación temporal y el otro la estructura de la interacción.

1.5. Clases

Las clases de Java se representarán tal como aparece en la figura 6. Se trata de
un rectángulo dividido en tres partes: la parte superior indica el nombre de la clase; la
parte central contiene los atributos y, por último, la parte inferior presentará las
operaciones de la clase.

NombreClase

Atributos

Operaciones

Figura 6. Representación de una clase con UML

Los niveles de visibilidad de los elementos se representan como sigue:

Privado: -
Protegido: #
Público: +

En la figura 7 se presenta un ejemplo de clase Java junto con su representación
UML.



Ficha class Ficha {

private char color;
-color:char
public void mostrar() {...}
public boolean igual(Ficha ficha) {...}
}
+mostrar()
+igual(Ficha):boolean

Figura 7. Ejemplo de representación de una clase con UML

1.5.1. Clases Abstractas

La representación para las clases abstractas es igual que para las clases normales,
salvo que el nombre de la clase se escribe en cursiva, como se puede apreciar en la
figura 8.

ClaseA
abstract class ClaseA {

...
}

Figura 8. Representación de una clase abstracta con UML

1.5.2. Interfaces

Una interfaz se representa exactamente igual que una clase normal, salvo que se
añade un estereotipo (“<<interface>>” en este caso) en la parte superior del
rectángulo, indicando, precisamente, que se trata de una interfaz y no de una clase
normal. En la figura 9 se presenta un ejemplo.

<<interface>>
InterfazA
interface InterfazA {

...
}

Figura 9. Representación de un interfaz con UML



1.6. Objetos

Para representar una instancia concreta de una clase con la notación UML
también se utiliza un rectángulo con tres partes. En la primera se especifica el nombre
del objeto separado por dos puntos del nombre de la clase, todo ello subrayado. En la
segunda parte aparecerán los atributos del objeto con sus valores. Aquellos atributos
compartidos por todas las instancias de una clase no se añaden aquí. Por último, en la
parte inferior del rectángulo van las operaciones que puede realizar el objeto por
pertenecer a una clase determinada, aunque éstas se pueden omitir.

También es posible, entre otras cosas, omitir la parte central del rectángulo e,
incluso, poner sólo la clase del objeto sin hacer referencia a su nombre.

Ejemplos de esta notación se pueden ver en la figura 10.

f:Ficha f:Ficha

color=`× ´ :Ficha

Figura 10. Notación UML para representar objetos

En nuestro caso utilizaremos la notación en la que aparece simplemente el
nombre de la clase a la que pertenece el objeto (ver figura 11). La razón es porque
¿realmente qué nombre tienen los objetos?, es decir, ¿qué ocurre si se tienen muchas
referencias al mismo objeto? (¿cuál de todos los nombres de esas referencias se refleja
en el diagrama?).

:Ficha

Figura 11. Notación UML para objetos con nombre de clase únicamente

1.7. Relaciones

Cuando se realizan abstracciones son pocas las clases que actúan solas; lo
normal es que existan diferentes relaciones entre las clases.

Entre clases pueden existir cuatro tipos de relación: composición, asociación,
uso y herencia. Las tres primeras se dan cuando objetos de las clases colaboran entre sí.
Sin embargo, el hecho de que exista una relación de herencia entre dos clases no implica
que los objetos de dichas clases colaboren, puede que nunca lo hagan.

1.7.1. Detalles

Se tendrán en cuenta una serie de detalles para todas las relaciones. Estos
detalles deberán acompañar a la relación en los diagramas.



1.7.1.1. Navegabilidad

Se contemplará la navegabilidad en las relaciones, es decir, el sentido de las
mismas. Se representará mediante una flecha, la cual indica que es posible “navegar”
desde el objeto de la clase origen al objeto de la clase destino. Por tanto, el objeto de la
clase origen conoce a los objetos de la clase destino, de manera que podrá invocar
operaciones de éstos. En la figura 12 se presenta un ejemplo de navegabilidad.

class Jugador {
Jugador Ficha
private Ficha ficha;
}

Figura 12. Navegabilidad entre clases

Si se observa la figura anterior, atendiendo solo a la navegabilidad, se puede ver
que un objeto de la clase Jugador conoce a un objeto de la clase Ficha, por
consiguiente, le puede lanzar mensajes, y no al revés.

1.7.1.2. Multiplicidad

La multiplicidad consiste en especificar el rango de cardinalidades que puede
asumir un conjunto, de forma que se indica cuántos objetos de una clase se relacionan
con objetos de la otra clase que forma parte de la relación.

Las restricciones de multiplicidad se deberán indicar en el diagrama. En UML es
posible especificar la multiplicidad de una clase mediante una expresión en la esquina
superior derecha de la misma e, incluso, también se puede especificar la multiplicidad
para los atributos.

En nuestro caso, simplemente reflejaremos la multiplicidad en los diagramas de
clases a nivel de las relaciones entre clases. Por lo tanto, se especificará el número de
instancias de una clase que se relaciona con instancias de otra clase, y se indicará al lado
de la clase cuyo número de instancias se intenta precisar. En la figura 13 se puede ver
un ejemplo.

class Jugador {
Jugador Ficha
}

Figura 13. Multiplicidad de la relación entre clases

Las multiplicidades con valor 1 no se suelen representar, lo cual queda patente
mediante el diagrama presentado en la figura anterior. En este caso, un objeto de la
clase Ficha forma parte de un único objeto de la clase Jugador y, a su vez, un objeto
de la clase Jugador tiene un único objeto de la clase Ficha.

Para representar una multiplicidad de varios elementos, donde no se sabe el
número exacto que tienen, se suele indicar mediante el rango posible. Por ejemplo: “0..



*”,“1..*”, etc. En nuestro caso, simplemente indicaremos la parte máxima del rango y,
además, utilizaremos una restricción2 para indicar el tipo de secuencia de elementos que
es. Por ejemplo: “{array}” (si es una tabla normal), “{ArrayList}” (si se trata de un
objeto de la clase ArrayList de Java), “{List}” (si se trata de un objeto de la clase List
de Java), etc. Un ejemplo se presenta en la figura 14.

Ter Jugador
{array} 2

class Ter {

private final Jugador [ ] JUGADORES = new Jugador[2];
}

Figura 14. Uso de restricciones en la multiplicidad de la relación entre clases

En el ejemplo presentado en la figura 14 se conoce el número exacto de la
multiplicidad. En caso de ser mayor que 1 y no conocerse con exactitud se indicará con
“*”.

1.7.1.3. Rol

Por último, con respecto al nombre de la relación, éste no será especificado. Lo
que si se reflejará en los diagramas será el rol que juega en la relación la clase destino
de la navegación.

El rol es el comportamiento de una entidad que participa en un contexto
particular. Es decir, se indica el rol que juega una clase dentro de la relación con otra
clase.

De forma general se presenta un ejemplo en la figura 15. El nombre del rol que
desempeña la clase se especifica al lado de ésta.

Empresa Empleado

trabajador

Figura 15. Roles de las clases

Además, en nuestro caso, el rol de la clase será el nombre del atributo. Un
ejemplo se presenta en el diagrama de la figura 16.

class Jugador {
Jugador Ficha
ficha
}

Figura 16. Rol de la clase Ficha en la relación con Jugador

2
Restricción: restricción de la semántica de un elemento de UML, que permite añadir nuevas reglas o
modificar las existentes.



1.7.2. Composición

La relación de composición es la relación entre el “todo” y la “parte”, siendo
responsabilidad del “todo” lo que le ocurra a cada una de las “partes”.

En UML, para referirse a este tipo de relación, se hace distinción entre
Composición y Agregación. Nosotros simplemente vamos a referirnos a composición,
representando la relación como una línea acabada en un rombo en el extremo de la clase
que representa el “todo” (ver figura 17).

Tablero
tablero

Ter class Ter {

private Tablero tablero;
Jugador private final Jugador [ ] JUGADORES;
}
2
JUGADORES

Figura 17. Relación de composición entre clases

1.7.3. Uso

La relación de uso (en UML se denomina de dependencia) es una relación
momentánea que se establece entre un “cliente” y un “servidor”. La responsabilidad de
manejar un objeto “servidor” no tiene porqué depender únicamente de la clase “cliente”.

En UML se representa mediante una línea punteada que une ambas clases. En la
figura 18 se presenta un ejemplo de relación de uso.

class Jugador {
Jugador Coordenada public void mover(Tablero tablero) {
Coordenada c = new Coordenada();
c.recoger();
...
}

Figura 18. Relación de uso entre clases

En el caso de la relación de uso no hay posible rol a establecer (siguiendo la
pauta de que el rol sea el nombre del atributo).

1.7.4. Asociación

La relación de asociación es una relación que perdura entre un “cliente” y un
“servidor”, donde la responsabilidad de manejar el objeto de la clase “servidor” no tiene
porqué depender, únicamente, de la clase “cliente”.

Esta relación se representa en UML mediante una línea que une ambas clases,
como se puede apreciar en la figura 19.



class Jugador {
Jugador Ficha
ficha
...
}

Figura 19. Relación de asociación entre clases

1.7.5. Herencia

La relación de herencia (en UML denominada Generalización) es aquella que se
establece entre dos clases, transmitiendo tanto atributos como métodos de la clase padre
a la clase hija. La clase hija será una especialización de la clase padre.

En este caso la representación UML se realiza mediante un triángulo en el
extremo de la relación donde se encuentra la clase más general, la clase padre (ver
figura 20).

ClasePadre

class ClaseHija extends ClasePadre {
...
}
ClaseHija

Figura 20. Relación de herencia entre clases

La representación es la misma si la relación de herencia se da entre interfaces
(ver figura 21), o si una clase hereda por implementación de una interfaz (ver figura 22).

<<interface>>
InterfazPadre

interface InterfazHijo extends InterfazPadre {
...
}
<<interface>>
InterfazHijo

Figura 21. Relación de herencia entre interfaces



<<interface>>
InterfazPadre

class ClaseHija implements InterfazPadre {
...
}
ClaseHija

Figura 22. Relación de herencia por implementación

1.8. Recapitulación

Una vez estudiados todos los detalles de clases, objetos y relaciones, en este
apartado se presentan de nuevo los diagramas de clases y objetos mostrados en el
apartado 1.4. Dichos diagramas se han completado indicando los tipos de relaciones
entre las clases, la navegabilidad, la multiplicidad, los roles, etc.

El diagrama de clases completo se presenta en la figura 23.

Ter

turno
tablero
JUGADORES 2 {array}
Turno Tablero
Jugador

ficha

FICHAS

{array}
* Coordenada
Ficha

Figura 23. Diagrama de clases completo

El diagrama de objetos que se tenía se ha completado añadiendo la
navegabilidad, quedando como se muestra en la figura 24.



:Ter

:Turno
:Tablero
:Coordenada

...
:Jugador
:Coordenada
:Jugador
:Ficha

:Ficha

:Ficha

Figura 24. Diagrama de objetos completo

1.9. Consideraciones

Observando la notación gráfica de UML para las clases, se puede apreciar que se
indican los diferentes atributos de una clase. Estos atributos pueden ser objetos de otras
clases, lo que va a marcar seguro algún tipo de relación entre ellas. Por lo tanto, es
necesario tomar una decisión con respecto al lugar en el que se ponen dichos atributos,
de forma que en el diagrama de clases no sea redundante.

Un ejemplo de esta situación se muestra en la figura 25.

Persona Libro

fechaNacimiento: Fecha publicacion: Fecha

(a)

Persona Fecha Libro

fechaNacimiento publicacion

(b)

Figura 25. Equivalencia “parcial” entre notaciones



Como se puede apreciar, en la figura 25(a) el atributo que hace referencia a la
fecha de nacimiento de una persona va incluido en la parte central de la notación gráfica
de la clase Persona. Sin embargo, en la figura 25(b) la fecha de nacimiento de la
persona se manifiesta a través de una relación entre clases.

Para intentar unificar la forma de representar nuestros programas orientados a
objetos, en principio se va a optar por la segunda opción (figura 25(b)), y sólo en aquel
caso en el que el diagrama esté muy “cargado”, se optará por representar algunos
atributos mediante la primera opción (figura 25(a)).

1.10. Bibliografía

G. Booch, I. Jacobson, J. Rumbaugh; “El Lenguaje Unificado de Modelado. Manual de
Referencia”. Addison Wesley.


UTML

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a UTML

Similar a UTML (20)

UTML