UML: Lenguaje de Modelado Unificado

Tema 3. Diagramas de clases (II)

 Tema 3. Diagramas de clases (II)

Licencia de Creative Commons.

UML: Lenguaje de Modelado Unificado

Tema 3. Diagramas de clases (II)

por: Javier Martn Juan

Esta obra est publicada bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Espaa
con las siguientes condiciones:

Reconocimiento - Debe reconocer los crditos de la obra de la manera especificada

por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo
o apoyan el uso que hace de su obra).

No comercial - No puede utilizar esta obra para fines comerciales

Compartir bajo la misma licencia - Si altera o transforma esta obra, o genera una
obra derivada, slo puede distribuir la obra generada bajo una licencia idntica a
sta.

Revisin: 681d899e237d

ltima actualizacin: 27 de marzo de 2013

Javier Martn 2012/2013 2

NDICE Tema 3. Diagramas de clases (II)

ndice

1. Relaciones entre clases 4

2. Asociacin 5
Navegabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Ejemplo: asociacin bidireccional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Ejemplo: asociacin unidireccional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Roles y multiplicidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Ejemplo de multiplicidad: clientes y pelculas . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3. Agregacin y composicin 9
Ejemplos: agregacin y composicin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4. Generalizacin 11
Ejemplo: generalizacin (herencia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Mtodos abstractos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Ejemplo: clases abstractas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5. Realizacin 13
Ejemplo de realizacin: interfaz Hablador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Clases abstractas o interfaces? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Generalizacin o realizacin? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6. Dependencia 17
Ejemplo: dependencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7. Ejercicio guiado 1 19
Solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8. Ejercicio guiado 2 23

Referencias 26

Javier Martn 2012/2013 3

1 RELACIONES ENTRE CLASES Tema 3. Diagramas de clases (II)

1. Relaciones entre clases

En una aplicacin mnimamente compleja habr varias clases cuyos mtodos se llamarn unos a otros.
Para que un mtodo de la clase A pueda llamar a otro mtodo de la clase B, la clase A debe poseer
una referencia a un objeto de la clase B. Esta relacin de posesin se representa con lneas que unen
las distintas clases en el diagrma.
Las relaciones pueden ser varias:

Asociacin

Agregacin

Composicin

Dependencia

Tambin puede ocurrir que varias clases tengan operaciones o atributos en comn y queramos
abstraerlos utilizando mecanismos conocidos de los lenguajes orientados a objetos como la herencia y
los interfaces. UML tambin permite representar estas relaciones entre clases mediante:

Generalizacin (equivalente a la herencia en POO)

Realizacin (equivalente a interfaces POO)

Javier Martn 2012/2013 4

2 ASOCIACIN Tema 3. Diagramas de clases (II)

2. Asociacin

Es el tipo de relacin ms frecuente entre clases. Existe una relacin de asociacin entre ClaseA y
ClaseB cuando en ClaseA hay un atributo de tipo ClaseB y/o viceversa.
Se representa como una lnea continua, que puede estar o no acabada en una flecha en V, segn la
navegabilidad. Adems se suelen indicar los roles y la multiplicidad, que veremos un poco ms
abajo.

Navegabilidad

Si la flecha apunta de la ClaseA a la ClaseB, se lee como ClaseA tiene una ClaseB y se dice que la
asociacin o navegabilidad es unidireccional. Traducido a Java, esto significa que hay un atributo
en la clase A que hace referencia a un objeto de la clase B.
Si no dibujamos la flecha, se lee ClaseA tiene una ClaseB y ClaseB tiene una ClaseA, y se dice que la
asociacin o navegabilidad es bidireccional. En Java, ambas clases tendran atributos que se hacen
referencia recprocamente.

Ejemplo: asociacin bidireccional

Supongamos una aplicacin de gestin con las clases Cliente y Pedido.

En el siguiente diagrama, Cliente guarda informacin sobre los pedidos y Pedido tiene informacin
sobre el cliente que lo realiz. La navegabilidad es, por tanto, bidireccional:

La traduccin a Java podra ser algo similar a:

public class Cliente {

public Vector<Pedido> pedidos;
}

public class Pedido {

public Cliente cliente;
}

En concreto, cada objeto de tipo Cliente tendr un atributo pedidos que contendr una lista de los
pedidos realizados. Los pedidos, por su parte, tendrn una referencia al cliente que lo realiz.
El hecho de que pedidos se traduzca por un vector de objetos Pedido tiene que ver con la multiplicidad
* que veremos un poco ms abajo.

Javier Martn 2012/2013 5

2 ASOCIACIN Tema 3. Diagramas de clases (II)

Ejemplo: asociacin unidireccional

Puede ser que nuestra aplicacin guarde la lista de pedidos en el objeto Cliente, pero no a la inversa.
En este caso la navegabilidad de la asociacin sera unidireccional y su representacin en UML sera:

Traducido a Java:

public class Cliente {

public Vector<Pedido> pedidos;
}

public class Pedido {

// el pedido NO guarda una referencia al cliente
}

El siguiente ejemplo muestra cmo se modelara la asociacin si la relacin fuera a la inversa: los
pedidos contienen informacin del cliente, pero los clientes no guardan pedidos:

Que traducido a Java sera:

public class Cliente {

// esta vez el cliente NO guarda los pedidos
}

public class Pedido {

public Cliente cliente;
}

Roles y multiplicidad

El rol o papel es el nombre de los atributos que intervienen en la relacin:

Javier Martn 2012/2013 6

2 ASOCIACIN Tema 3. Diagramas de clases (II)

En el ejemplo anterior, se dice que la clase Pedido asume el papel pedidos en la asociacin, lo que
simplemente significa que el atributo de Cliente que hace referencia al vector de objetos Pedido se
llamar pedidos.
Es importante notar que el nombre de los atributos se escribe en el lado contrario a la clase que los
contiene.
Un error comn cuando representamos asociaciones es volver a incluir los atributos dentro de la clase.
Lo siguiente sera incorrecto:

Adems de los roles, como hemos visto en ejemplos anteriores, los extremos de la relacin se pueden
rotular con su multiplicidad, que indica cuntos objetos de una clase se pueden relacionar como
mnimo y como mximo con objetos de la otra clase y se expresa del siguiente modo:

muliplicidad mnima .. multiplicidad mxima

Cuando las multiplicidades mnima y mxima son iguales, se suele representar con un nico nmero.
La multiplicidad de tipo muchos se representa con un asterisco: *. Por ltimo, la multiplicidad 0..*
(cero o ms) se suele expresar como simplemente *.
En el ejemplo anterior:

Un cliente se puede relacionar 0 o ms pedidos (multiplicidad *, equivalente a 0..*)

Un pedido debe tener un (y solo un) cliente (multiplicidad 1, equivalente a 1..1).

Javier Martn 2012/2013 7

2 ASOCIACIN Tema 3. Diagramas de clases (II)

Ejemplo de multiplicidad: clientes y pelculas

Veamos en este otro ejemplo las posibilidades que aparecen segn la multiplicidad que pongamos a la
clase Pelicula:

Segn el valor que le demos a ?:

1..1: Una instancia de cliente debe estar relacionada con exactamente una instancia de pelcula, ni
ms ni menos.

1: Significa lo mismo que 1..1.

0..*: Un cliente puede no tener ninguna pelcula alquilada, o puede tener varias (sin lmite).

*: Significa lo mismo que 0..*

0..3: Un cliente puede alquilar entre 0 y 3 pelculas.

2..3: Un cliente debe alquilar como mnimo 2 pelculas, pero como mucho puede alquilar 3.

Javier Martn 2012/2013 8

3 AGREGACIN Y COMPOSICIN Tema 3. Diagramas de clases (II)

3. Agregacin y composicin

Segn la referencia de UML [RJB05], la agregacin y la composicin son asociaciones que

representan una relacin entre un todo y sus partes. Se puede leer como ClaseB es un componente
de ClaseA, o tambin ClaseA est compuesto por ClaseB
Las diferencias entre ellas son:
En la agregacin, los objetos parte pueden seguir existiendo independientemente del objeto todo.
En la composicin, por el contrario, la vida de los objetos compuestos est ntimamente ligada a la
del objeto que los compone, de manera que si el todo se destruye, las partes tambin se destruyen.
La agregacin se representa uniendo las dos clases (todo / parte) con una lnea continua y poniendo
un rombo hueco en la clase todo.
La composicin es igual, pero con el rombo relleno.

Ejemplos: agregacin y composicin

La primera relacin indica que el Coche est compuesto por Ruedas. Las ruedas pueden existir por s
mismas, por tanto la relacin es de agregacin.
En la segunda relacin, una Empresa est compuesta por Departamentos. Los departamentos por s
mismos no pueden existir, ya que deben estar ligados a una empresa. Por este motivo, la relacin ahora
es de composicin.
Una consecuencia de la composicin es que una parte slo puede relacionarse con 1 y slo 1 todo, ya
que si ese todo deja de existir, sus partes tambin debern dejar de existir. Por tanto, la multiplicidad
en la clase todo siempre ser 1 en una composicin.
ste es un buen momento para explorar una til funcin de Modelio: la auditora. La auditora consiste
en verificar el modelo para asegurar que cumple con las normas de UML. Las infracciones se muestran en
la vista Audit como errores o advertencias segn su gravedad. Por ejemplo, si pusiramos multiplicidad

Javier Martn 2012/2013 9

3 AGREGACIN Y COMPOSICIN Tema 3. Diagramas de clases (II)

1..* a la clase Empresa del ejemplo anterior, el programa nos advertira con el siguiente error. Adems,
haciendo doble-clic encima nos dara informacin y pistas para solucionarlo.

La implementacin en Java de la agregacin es idntica a la asociacin:

public class Coche {

private Rueda ruedas[4];
}

La composicin se implementara llamando a los destructores de las clases parte desde el destructor
de la clase todo suponiendo que usemos un lenguaje con destructores, como C++:

class Todo
{
Parte parte1; // construccin y destruccin implcitas
Parte *parte2; // construccin y destruccin explcitas
public:
Todo() { parte2 = new Parte; }
~Todo() { delete parte2; }
}

En Java, sin embargo, la gestin de memoria est basada en la recogida de basura (garbage collection)
y no existen los destructores, as que la composicin se implementa exactamente igual que la
agregacin y la asociacin:

public class Empresa {

private Vector<Departamento> departamentos;
}

Javier Martn 2012/2013 10

4 GENERALIZACIN Tema 3. Diagramas de clases (II)

4. Generalizacin

La relacin de generalizacin entre dos clases indica que una de las clases (la subclase) es una
especializacin de la otra (la superclase). Si ClaseA es la superclase y ClaseB la subclase, la
generalizacin se podra leer como ClaseB es una ClaseA o ClaseB es un tipo de ClaseA.
En Java (y la mayora de lenguajes orientados a objetos), la generalizacin se conoce como herencia.
La herencia se utiliza para abstraer en una superclase los mtodos y/o atributos comunes a varias
subclases.
A la subclase tambin se le puede llamar clase hija o clase derivada.
A la superclase tambin se le puede llamar clase padre o clase base.
La generalizacin se expresa con una lnea acabada en una flecha triangular hueca, dibujada desde la
clase hija hacia la clase padre.

Ejemplo: generalizacin (herencia)

Alumno y Profesor son especializaciones de la clase Persona.

En Java:

public class Persona {

public String nombre;
public int edad;
}

public class Alumno extends Persona {

public String grupo;
}

public class Profesor extends Persona {

public String asignatura;
}

Javier Martn 2012/2013 11

4 GENERALIZACIN Tema 3. Diagramas de clases (II)

Mtodos abstractos

En Java, una clase padre puede tener tener mtodos abstractos, lo que significa que para esos mtodos
no se proporciona ninguna implementacin.
Una clase abstracta es una clase que tiene al menos un mtodo abstracto.
Al tener uno o ms mtodos sin implementacin, las clases abstractas no se pueden instanciar.
Una clase que extiende a una clase abstracta debe implementar los mtodos abstractos (escribir el
cdigo) o bien volverlos a declarar como abstractos, con lo que ella misma se convierte tambin en
clase abstracta.
En UML, tanto las operaciones como las clases abstractas se expresan poniendo el nombre de la
operacin o la clase en cursiva.

Ejemplo: clases abstractas

FiguraGeometrica.java:

abstract class FiguraGeometrica {

abstract void dibujar();
}

Circulo.java:

class Circulo extends FiguraGeometrica {

void dibujar() {
// cdigo para dibujar Circulo
}
}

Todas las figuras geomtricas se pueden dibujar, pero no es lo mismo dibujar un crculo que un
cuadraro, por ello el mtodo dibujar de FiguraGeometrica es abstracto, lo cual convierte a la clase
FiguraGeometrica en abstracta. La implementacin concreta del mtodo dibujar se deja a las clases
hijas (Circulo). En UML:

Javier Martn 2012/2013 12

5 REALIZACIN Tema 3. Diagramas de clases (II)

5. Realizacin

En Java, un interfaz es similar a una clase abstracta pura, es decir una clase donde todos los mtodos
son abstractos (no se implementa ninguno). Permite al diseador de clases establecer la forma de una
clase (nombres de los mtodos, parmetros y tipos de retorno), pero no bloques de cdigo.
Un ejemplo de uso de interfaces son las listas en Java: una lista es una coleccin de elementos a los
cuales se puede acceder por su posicin numrica, mediante bsqueda, se pueden iterar (recorrer) y
trocear en sub-listas.
Las listas segn esa definicin se pueden implementar de muchas maneras, por ejemplo como un
vector, una lista enlazada o una lista doblemente enlazada, dependiendo del uso que vayamos a darle
y la eficiencia de sus operaciones.
Pero todas ellas tienen en comn las operaciones caractersticas de la lista, por ello Java define el
interfaz List con dichas operaciones:

public interface List<E> extends Collection<E> {

int indexOf(Object o);

int lastIndexOf(Object o);

ListIterator<E> listIterator();
ListIterator<E> listIterator(int index);

List<E> subList(int from, int to);

// ... (entre otras)

}

Las implementaciones de List ms conocidas son ArrayList, LinkedList y Vector.

En UML, la implementacin de un interfaz equivale a la realizacin, y se representa con una lnea
discontinua acabada en una flecha triangular hueca que va desde las implementaciones hacia el interfaz:

Javier Martn 2012/2013 13

5 REALIZACIN Tema 3. Diagramas de clases (II)

Ejemplo de realizacin: interfaz Hablador

Los interfaces sirven para aadir comportamiento a las clases. La ventaja es que para invocar ese
comportamiento no necesitamos conocer la clase del objeto. En el siguiente ejemplo tenemos una lista
con dos animales que implementan el interfaz Hablador. Podemos llamar a sus mtodos hablar() sin
que importe demasiado qu clase de animal sean:

import java.util.Iterator;
import java.util.List;
import java.util.ArrayList;

interface Hablador {
public void habla();
}

class Gato implements Hablador {

public void habla() {
System.out.println("Miau");
}
}

class Cuco implements Hablador {

public void habla() {
System.out.println("Cu cu");
}
}

public class Test {

public static List<Hablador> animales = new ArrayList<Hablador>();
public static void main(String [] args) {
animales.add(new Gato());
animales.add(new Cuco());

Iterator<Hablador> i = animales.iterator();
while (i.hasNext()) {
Hablador animal = i.next();
animal.habla();
}
}
}

En UML:

Javier Martn 2012/2013 14

5 REALIZACIN Tema 3. Diagramas de clases (II)

Clases abstractas o interfaces?

En Java, qu diferencia hay entre un interface y una clase que tiene todos sus mtodos abstractos?
En primer lugar, se diferencian en el modo como se definen y se utilizan:

Clase abstracta pura:

abstract public class FiguraGeometrica {

abstract void dibujar();
}

public class Circulo extends FiguraGeometrica {

void dibujar() {
// Cdigo
}
}

public class Test {

public static void main(String args[]) {
FiguraGeometrica fg = new Circulo();
fg.dibujar();
}
}

Interfaz:

interface Dibujable {
void dibujar();
}

public class Circulo implements Dibujable {

void dibujar() {
// Cdigo
}
}

public class Test {

public static void main(String args[]) {
Dibujable d = new Circulo();
d.dibujar();
}
}

Un interfaz puede tambin contener variables, pero siempre static y final. Por el contrario, una clase
abstracta pura s que puede tener atributos de instancia.

Generalizacin o realizacin?

Qu diferencia hay entre la generalizacin (herencia) y la realizacin (interfaces)?

La diferencia ms importante es que una clase puede implementar mltiples interfaces, pero slo puede
heredar de (como mximo) una clase padre.
Por ejemplo, en el siguiente diagrama tenemos los interfaces VehculoMartimo, VehculoAreo,
VehculoDeMercancas y VehculoDePasajeros.

Javier Martn 2012/2013 15

5 REALIZACIN Tema 3. Diagramas de clases (II)

Tambin hay 3 realizaciones de dichos interfaces: un BarcoMercante es una implementacin de un

VehculoMartimo, pero tambin lo es de un VehculoDeMercancas, del mismo modo que una Avioneta
es un VehculoAreo pero tambin es un VehculoDePasajeros. Esta relacin de realizacin con mltiples
clases sera imposible de expresar utilizando la generalizacin.

Javier Martn 2012/2013 16

6 DEPENDENCIA Tema 3. Diagramas de clases (II)

6. Dependencia

Segn el Manual de Referencia de UML [RJB05], una dependencia indica una relacin semntica entre
dos o ms clases del modelo. La relacion puede ser entre las clases propiamente dichas, es decir, no
tiene por qu involucrar a instancias de las clases (como en la asociacin, composicin y agregacin).
Si ClaseA depende de ClaseB, significa que un cambio en ClaseB provoca un cambio en el significado
de ClaseA.
Segn esa definicin, todas las relaciones vistas hasta ahora (asociacin, agregacin, composicin,
generalizacin y realizacin) seran dependencias, pero por tener significados muy especfios se les ha
dado nombres concretos. Por tanto, se podra decir que las dependencias son todas aquellas relaciones
que no encajan en ninguna de las categoras anteriores.
En la prctica, y segn coinciden muchos autores, la dependencia se usa cuando ClaseA utiliza
brevemente a la ClaseB. Por breve se entiende normalmente lo que dura una llamada a un mtodo.
Se representa como una lnea punteada acabada en una flecha en V que va desde ClaseA a Clase B.
Concretando ms an, utilizaremos una relacin de dependencia cuando una clase utilice un objeto
de otra pero sin almacenarlo en ningn atributo (ya que entonces sera una asociacin, agregacin o
composicin). Ejemplos:

Cuando a un mtodo de la clase A se le pasa como parmetro un objeto de la clase B.

Cuando un mtodo de la clase A devuelve un objeto de la clase B

Cuando un mtodo de la clase A tiene una variable local de tipo B

Ejemplo: dependencia

Supongamos una clase Mapa capaz de obtener las coordenadas (latitud y longitud) a partir de una
direccin postal y viceversa:

La clase Coordenadas contiene los datos (latitud y longitud) de un punto geogrfico.

La clase Mapa tiene dos mtodos:

El mtodo direccionACoordenadas devuelve las coordenadas geogrficas a partir de una direccin

dada.
El mtodo coordenadasADireccion devuelve la direccin ms cercana a las coordenadas dadas.

Mapa.java:

public class Mapa {

/** Devuelve coordenadas a partir de direccin postal
* @param d direccin postal
* @return coordenadas
*/
public Coordenadas direccionACoordenadas(String d) {
// ...

Javier Martn 2012/2013 17

6 DEPENDENCIA Tema 3. Diagramas de clases (II)

/** Devuelve direccin postal a partir de coordenadas

* @param c coordenadas
* @return direccin postal
*/
public String coordenadasADireccion(Coordenadas c) {
// ...
}
}

Coordenadas.java:

public class Coordenadas {

public double latitud;
public double longitud;
}

Ambos mtodos utilizan brevemente un objeto de la clase Coordenadas, entendiendo por breve el
hecho de que no la almacenan en ningn atributo de la clase. En consecuencia, Mapa depende de
Coordenadas.
El diagrama que captura dicha relacin sera:

Javier Martn 2012/2013 18

7 EJERCICIO GUIADO 1 Tema 3. Diagramas de clases (II)

7. Ejercicio guiado 1

En una empresa queremos guardar informacin de sus empleados y de los clientes con los siguientes
requisitos:

De los empleados queremos guardar su sueldo bruto.

De los clientes queremos guardar su telfono.

Los clientes y los empleados tienen las siguientes caractersticas comunes: la edad y el nombre.

Los directivos son un tipo de empleado. De ellos queremos conocer su categora.

Queremos una funcin que permita imprimir por pantalla todos los datos de cada persona.

Adems existe una flota de coches de empresa a disposicin de los directivos. Cada coche puede
estar asignado a un nico directivo y viceversa. De los vehculos necesitamos saber su matrcula y el
kilometraje.

Solucin

Empezamos creando un proyecto nuevo:

Los clientes y empleados tienen atributos comunes (edad y nombre), as que vamos a abstraerlos en
una clase Persona. Creamos tambin el resto de clases con sus atributos especficos:

Javier Martn 2012/2013 19

7 EJERCICIO GUIADO 1 Tema 3. Diagramas de clases (II)

Clientes y empleados son un tipo de persona, y a su vez los directivos son un tipo de empleado.
Estableceremos, por tanto, las relaciones de generalizacin entre ellos.
Podemos utilizar el elemento Generalization, o bien Generalization/Realization (auto), que crear
automticamente una generalizacin cuando los dos elementos sean clases, o una realizacin cuando
uno de ellos sea un interfaz:

Entre los directivos y los vehculos existe una relacin de asociacin. No podemos decir que sea
composicin ni agregacin porque un directivo no est compuesto de vehculos y al revs tampoco.

Javier Martn 2012/2013 20

7 EJERCICIO GUIADO 1 Tema 3. Diagramas de clases (II)

Cada directivo puede tener como mximo un vehculo asignado y viceversa, lo que expresamos con
una multiplicidad 0..1 en cada lado de la asociacin. No nos dicen nada de la navegabilidad, as que la
pondremos bidireccional. De este modo un directivo sabe qu coche le corresponde, y un coche sabe
qu directivo tiene asignado. Llamaremos a los roles directivo y vehculo:

Ya slo queda aadir las operaciones. De todas las personas queremos mostrar sus datos, as que
aadimos la operacion mostrarDatos().
Aunque el enunciado no lo especifica, en programacin orientada a objetos es una buena costumbre
poner todos los atributos de una clase con visibilidad privada o protegida por el principio de ocultacin.
En este caso elegimos visibilidad protegida porque queremos que las clases hijas tengan acceso a los
atributos de sus padres. Los atributos de las clases que no tienen descendencia da igual que sean
privados o protegidos, pero les pondremos protegidos por si alguna vez tienen hijas.

Javier Martn 2012/2013 21

7 EJERCICIO GUIADO 1 Tema 3. Diagramas de clases (II)

Con esto queda terminado el diagrama:

Javier Martn 2012/2013 22

8 EJERCICIO GUIADO 2 Tema 3. Diagramas de clases (II)

8. Ejercicio guiado 2

En este ejercicio vamos a ver cmo se representan en modelio los interfaces y la relacin de realizacin
entre interfaces y clases. Para ello vamos a dibujar el diagrama de la pgina 14 (interfaz Hablador ).
Crearemos un nuevo diagrama de clases en el proyecto Tema 3 del ejercicio anterior. Para ello clicamos
con el botn derecho en el Tema 3 de la vista Model Create a diagram...:

Elegimos Class diagram y lo nombramos:

Creamos el interfaz:

Por defecto obtenemos la representacin simplificada del interfaz (un crculo). Podemos cambiarlo en
la vista Symbol :

Javier Martn 2012/2013 23

8 EJERCICIO GUIADO 2 Tema 3. Diagramas de clases (II)

Y obtendremos la representacin estructurada (similar a la de una clase):

A continuacin aadimos el resto de elementos del diagrama:

Creamos las clases Test, Gato y Cuco.

La clase Test contiene un lista (concretamente un ArrayList) de objetos de tipo Hablador. Esto se
representa con una asociacin con multiplicidad 0..*.

Cambiamos el rol de la clase Hablador a animales, que es como se llama el atributo en el cdigo
Java.

La operacin main de la clase Test es el punto de entrada al programa, que en Java es siempre un
mtodo esttico.

Javier Martn 2012/2013 24

8 EJERCICIO GUIADO 2 Tema 3. Diagramas de clases (II)

En Java, el mtodo main toma como parmetro un array de Strings. Esto se puede representar
aadiendo un nuevo parmetro y dndole cardinalidad * para indicar que se trata de un array:

Por ltimo, creamos la relacin de realizacin entre el interfaz Hablador y las clases que lo implementan.
Podemos usar la herramienta Interface realization o Generalization/Realization (auto):

El diagrama finalizado:

Javier Martn 2012/2013 25

8 EJERCICIO GUIADO 2 Tema 3. Diagramas de clases (II)

Javier Martn 2012/2013 26

REFERENCIAS Tema 3. Diagramas de clases (II)

Referencias

[RJB05] Rumbaugh, James, Ivar Jacobson y Grady Booch: The unified modeling language reference
manual. Addison-Wesley, 2a edicin, 2005, ISBN 0321245628.

Javier Martn 2012/2013 27