Documentos de Académico
Documentos de Profesional
Documentos de Cultura
U03 Clases2 PDF
U03 Clases2 PDF
Esta obra est publicada bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Espaa
con las siguientes condiciones:
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
ndice
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
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:
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.
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.
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:
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:
Roles y multiplicidad
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:
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:
Veamos en este otro ejemplo las posibilidades que aparecen segn la multiplicidad que pongamos a la
clase Pelicula:
1..1: Una instancia de cliente debe estar relacionada con exactamente una instancia de pelcula, ni
ms ni menos.
0..*: Un cliente puede no tener ninguna pelcula alquilada, o puede tener varias (sin lmite).
2..3: Un cliente debe alquilar como mnimo 2 pelculas, pero como mucho puede alquilar 3.
3. 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
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 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:
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.
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.
FiguraGeometrica.java:
Circulo.java:
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:
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:
ListIterator<E> listIterator();
ListIterator<E> listIterator(int index);
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();
}
Iterator<Hablador> i = animales.iterator();
while (i.hasNext()) {
Hablador animal = i.next();
animal.habla();
}
}
}
En UML:
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:
Interfaz:
interface Dibujable {
void 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?
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:
Ejemplo: dependencia
Supongamos una clase Mapa capaz de obtener las coordenadas (latitud y longitud) a partir de una
direccin postal y viceversa:
Mapa.java:
Coordenadas.java:
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:
7. Ejercicio guiado 1
En una empresa queremos guardar informacin de sus empleados y de los clientes con los siguientes
requisitos:
Los clientes y los empleados tienen las siguientes caractersticas comunes: la edad y el nombre.
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
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:
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.
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.
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...:
Creamos el interfaz:
Por defecto obtenemos la representacin simplificada del interfaz (un crculo). Podemos cambiarlo en
la vista Symbol :
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.
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:
Referencias
[RJB05] Rumbaugh, James, Ivar Jacobson y Grady Booch: The unified modeling language reference
manual. Addison-Wesley, 2a edicin, 2005, ISBN 0321245628.