Robert Espinoza Dominguez

Relaciones entre clases

Relaciones entre clases

 Las clases al igual que los objetos no existen aislados.

 En una aplicación real los objetos colaboran e
intercambian información, razón por la cual existirán
relaciones entre clases y entre objetos.
 Unos objetos están compuestos o contienen otros
objetos.
 Unos necesitan de la colaboración de otros objetos para
llevar a cabo ciertas tareas.
 Las relaciones se expresan frecuentemente usando
verbos o frases verbales como: está compuesto de,
contiene, vive en, estudia en, es responsable de, etc.
 Relaciones entre clases

Las relaciones ciertas características:

 Roles. La relación tiene fuente y destino. Éstos pueden
tener un nombre de rol para clarificar la naturaleza de la
asociación (son opcionales)
 Cardinalidad. Refiere el numero de instancias
 Navegabilidad. Tiene direccionalidad, se navegan en cierto
sentido.
Relaciones entre clases

 Los tres grandes tipos de relaciones entre clases son:

 Asociación y dependencia
 Agregación y composición (todo/parte)
 Generalización y especialización (es un)
Diagrama de clases
Diagramas de clases

 Es el más utilizado y más conocido de los diagramas

orientados a objetos. Es la fuente de generación de
código.
 El diagrama de clases representa clases, sus partes y
la forma en la que las clases de los objetos están
relacionados con otro.
 Los diagramas de clases por definición son estáticos,
esto es, representan que partes interactúan entre sí,
no lo que ocurre ni cuándo.
Diagramas de clases

 Contiene la siguiente información:

 Clases, asociaciones y atributos.
 Interfaces, con sus operaciones y constantes.
 Métodos.
 Información sobre los tipos de los atributos.
 Navegabilidad.
 Dependencias.
 En la actualidad se utiliza el estándar UML para
modelar el diagrama de clases y otros diagramas
orientado a objetos.
 Diagrama de clases

 Para elaborar un diagrama de clases:

 Identifique todas las clases que participan en la solución del
software.
 Dibújelas en un diagrama de clases.
 Identifique los atributos provenientes de los conceptos
asociados del modelo conceptual.
 Agregue los nombres de los métodos.
 Incorpore la información sobre los tipos a los atributos y a
los métodos.
 Agregue las asociaciones necesarias para dar soporte a la
visibilidad requerida de los atributos.
 Agregue flechas de navegabilidad a las asociaciones para
indicar la dirección de la visibilidad de los atributos.
Diagrama de clases
Elementos de un diagrama de clases

 Clases
 Atributos, Métodos
 Objetos

 Relaciones
 Herencia
 Composición y agregación

 Asociación
Notación de una clase

Nombre Clase

Atributos

Métodos
 Notación de una clase

Visibilidad (niveles de
encapsulamiento):
(-) Privado: Es el más fuerte. Cuenta
Esta parte es totalmente
invisible desde fuera de la - codigo
clase. - nombre
(~) Package: Sólo es visible - saldo
dentro del mismo paquete.
(#) Protegido: Está visible + depositar()
para las clases amigas y
para las clases derivadas + retirar ()
de la original.
(+) Público: Visible a otras
clases.
UML. Lenguaje Unificado de Modelado

 UML (Unified Modeling Language) es un lenguaje de

modelado diseñado para visualizar, especificar,
construir y documentar software orientado a objetos.
 UML NO es una metodología.
 UML es un conjunto de diagramas para representar
diferentes aspectos de una aplicación.
 Finalmente UML es un estándar respaldado por la
OMG (Object Management Group)
Diagramas UML

 Estáticos o estructurales (organización del sistema)

 Diagrama de Clases
 Diagrama de Objetos.
 Diagrama de componentes.
 Diagrama de despliegue
 Dinámicos o de comportamiento (dinámica del
sistema)
 Diagrama de casos de uso
 Diagrama de secuencia
 Diagrama de colaboración
 Diagrama de estados
 Diagrama de actividades
Asociación
 Asociación

 Una asociación es una relación entre instancias de

clases, especificando que los objetos de una clase
deben “conocer” de alguna manera los objetos de la
otra. Por ejemplo:
 Un objeto de la clase A envía un mensaje a un objeto de
la clase B.
 Un objeto de la clase A crea un objeto de la clase B.
 Un objeto de la clase A recibe un mensaje con un objeto
de la clase B como argumento
 En otras palabras, una relación de asociación permite
asociar clases independientes que colaboran entre si.
 Asociación

 El propósito de la asociación puede expresarse en un

nombre, verbo o frase que describa como los objetos
de un tipo (clase) se relacionan con objetos de otro
tipo (clase). Por ejemplo:
 Una persona tiene un coche
 Una persona maneja un coche
 Las asociaciones pueden ser unitarias, binarias,
ternarias o de cualquier otro orden, aunque la mayoría
sean binarias.

Empleado Compañía
1..* 1
 Asociación – Dirección

 Generalmente las asociaciones son bidireccionales,

aunque pudiesen ser unidireccionales si así se indica
expresamente.
 La dirección en las flechas de la asociación determinan
en que dirección puede recorrerse una asociación en
el momento de la ejecución.
 Una asociación sin flechas significa que se puede ir de
un objeto a otro y viceversa.
 Por ejemplo en el siguiente diagrama se entiende que
desde el objeto Reservación puedes recuperar el
objeto Cliente. También implica que del objeto Cliente
se puede recuperar el juego de reservaciones para ese
cliente.
 Asociación – Dirección

Reservación Cliente
1..* 1

 Supongamos que los requerimientos para un sistema

de reservaciones requieren que “desde una
reservación el sistema pueda recuperar la habitación”

Reservación Habitación
1..* 1
 Asociación – Cardinalidad o multiplicidad

 La cardinalidad es la propiedad que expresa el número

de instancias de una clase que se asocian o conectan
con instancias de la clase asociada.
 Cada asociación tiene dos cardinalidades, una para
cada extremo de la relación.
 Para especificar la cardinalidad de una asociación hay
que indicar la multiplicidad mínima y máxima.
Asociación – Cardinalidad o multiplicidad

Cardinalidad Significado
1 Uno y sólo uno (obligatorio)
0 .. 1 Cero o uno
N .. M Desde N hasta M
* Cero o varios
0 .. * Cero o varios (ilimitado)
1 .. * Uno o varios (al menos uno)
 Asociación – Cardinalidad o multiplicidad

 Cuando la cardinalidad mínima es 0, la relación es

opcional.
 Una cardinalidad mínima mayor o igual que 1
establece una relación obligatoria.
 Asociación – Cardinalidad o multiplicidad

 Existen tres tipos de cardinalidad:

 Una a una
 Una a muchas
 Muchas a muchas
 Asociación – Multiplicidad una a una

 Una relación una a una implica una relación estrecha

entre objetos.
 Por ejemplo la siguiente relación representa la
operación o pago de una venta mediante una tarjeta
de crédito.
1 1
Venta Operación TC

 Otros ejemplos.
1 1
País Capital

1 0..1
Persona DNI
Asociación – Multiplicidad una a muchas

1 1..*
Departamento Profesor

1 1..*
País Ciudad

1 2..*
Segmento Punto
Asociación – Multiplicidad muchas a
muchas

1..* 1..*
Alumno Curso

1..* 1..*
Profesor Alumno

1..* 1..*
Ventas Productos
Asociaciones reflexivas o involutivas

 Las asociaciones pueden ser reflexivas, relacionando

distintos objetos de una misma clase, en otras
palabras cuando la misma clase aparece en los
extremos de la asociación.
 Por ejemplo, para una clase persona puede existir una
asociación pariente que describe que dos objetos de
tipo persona, como Juan Pérez y Laura Pérez son
parientes.
Asociaciones reflexivas o involutivas

 Otros ejemplos:

* 1
Empleado Persona

* 1
dirige casada con
 Roles

 Una relación tiene dos puntos finales, Lector

los cuales pueden tener un nombre de
rol para clarificar la naturaleza de la
asociación Está
Solicita asociado
 El lector “solicita” un libro.

 Un libro está “asociado” a un lector Libro

 Los roles son opcionales y se colocan en el diagrama para

clarificar
 Si no se colocan roles, los nombres de los atributos asumen
ese papel
 Asociación

Representación en UML

Libro es prestado Lector

0..* 0..1

public class Libro{

private Lector lec;
…
}
public class Lector{
…
}
 Asociación

Representación en UML
Jugador Juega en Equipo
0..* 1

public class Equipo{

private Jugador j[];
…
}
public class Jugador{
private Equipo eq;
…
}
 Asociación

public class Libro{

private Lector lec;
…
}
public class Lector{
private Libro lib[];
…
}

Libro Es prestado Lector

0..*

Pidió prestado 0..1

 Relación de Asociación Unidireccional

 Si la relación es navegable y la cardinalidad de la clase destino

es 0..1, entonces:
 En la clase fuente, se coloca un atributo privado de la clase
destino
public class Auto{ public class Conductor{
private String placa; private String tipo;
private Conductor conduce; private nombre;
} }

Auto 0..1 Conductor

3. Relación de Asociación Bidireccional

 Si la relación es navegable en ambos sentidos y la cardinalidad

en ambos es 1:
 Se coloca un atributo privado en cada clase que haga
referencia a la otra clase
public class Auto{ public class Conductor{
private String placa; private String tipo;
private Conductor conducidoPor; private Auto conduce;
} }

1 conduce
Auto Conductor
1
conducido por
Dependencia
Dependencia

 Relación (más débil que una asociación) que muestra

la relación entre un cliente y el proveedor de un
servicio usado por el cliente.
 Cliente es el objeto que solicita el servicio
 Servidor es el objeto que provee el servicio solicitado.
 Dependencia

 Se denomina relación de dependencia o de uso si

una clase A necesita de un objeto de la clase B para
llevar a cabo su funcionalidad
 Cuando los objetos de la primera utilizan objetos de la
segunda como argumentos en alguna operación
 En un método de A se crea un objeto auxiliar de B.
 En un método de A aparece un objeto de B como
argumento
 Significa que una clase utiliza o tiene conocimiento de
otra clase, es una relación transitoria.
 Dependencia

Representación de Dependencia en UML

 Gráficamente la dependencia se muestra como una
línea discontinua con una punta de flecha que apunta
del cliente al proveedor.
 Ejm: Hallar área y perímetro de una figura

Figura Operaciones

area() valorPi()
perimetro() sqrt()
 Dependencia

Resolver una ecuación de segundo grado

Ecuacion Math
-coeficientes[3]
+resolver() +pow( )
+sqrt( )
Dependencia

Punto Math

Alumno java.util.Scanner
 Dependencia

Punto Math

public double distancia(int pX, int pY) {

double dis;
int dx= this.x - pX;
int dy = this.y - pY;

dis = Math.sqrt(dx*dx + dy*dy);

return dis;
}
Agregación y composición
Agregación y composición

 La agregación y composición son relaciones que

representa a los objetos compuestos.
 Permite describir modelos del mundo real que se
componen de otros modelos.
 Es un concepto para expresar tipos de relaciones
entre objetos parte-de o tiene-un.
 Dos objetos tienen estos tipos de relaciones, si existe
entre ellos una relación de todo-parte, continente-
contenido.
 Si dos objetos se consideran normalmente como
independientes, sus relaciones se consideran
normalmente una asociación.
 Son relaciones asimétricas.
Agregación y composición

Casa

tiene tiene

Habitación Tejados

tiene tiene
tiene

Puertas Ventanas Paredes

Agregación y composición
 Agregación

 Se denomina relación de Agregación entre clases

cuando hay una relación entre un “compuesto y
componentes”, “maestro y esclavo entre los objetos de
otras clases.
 Es una relación de contenedor y contenido, donde el
contenedor contiene objetos contenido.
Agregación

 Se pueden observar las siguientes características:

 Independencia existencial: El elemento contenido no
desaparece al destruirse el que lo contiene.
 Pertenencia débil: Se puede decir que el objeto
contenedor no contiene realmente al objeto contenido,
sino que tiene una referencia a él.
 Compartición: Los objetos contenidos también pueden
formar parte del estado de otro objeto.
 En Java y en otros lenguajes OO no disponen de una
implementación especial: básicamente se tratan
como una asociación
 Agregación

Representación de Agregación en UML

Producto Polígono

0..n 0..n

1..n 3..n
Ingrediente Punto

Un producto está compuesto por A un polígono se le puede

uno o más ingredientes agregar puntos
Un ingrediente puede estar en 0 o Un punto puede formar parte de
mas productos. 0 o mas polígonos
Agregación

Biblioteca 0..1 tiene Libro

0..*

Es parte de
 Agregación

Ejemplo:

class Biblioteca { class Libro {

Libro lib[ ]; Pagina pag[ ];
Libro() {
Biblioteca() {
lib = null; pag = new Pagina[300];
} }
} }

 Un objeto de la clase Biblioteca no

necesita crearse junto con los objetos
de la clase Libro.
Composición

 Es una relación de todo y parte de, donde el todo

esta formado por objetos parte de que lo componen.
 Hay una fuerte relación de pertenencia: un objeto
“parte” sólo pertenece a un objeto “todo” y cuando se
destruye el “todo” también lo hacen el o los objetos
“parte”.
 La clase “todo” controla la existencia de las clases “parte”
 Al inicializar: El “todo” construye cada “parte”
 Al finalizar: El “todo” destruye cada “parte”
 Si el objeto se copia o se elimina sus partes se copian o
se borran con él.
Composición

 Se pueden observar las siguientes características:

 Dependencia existencial: El elemento dependiente
desaparece al destruirse el que lo contiene y, si es de
cardinalidad 1, es creado al mismo tiempo.
 Pertenencia fuerte: Se puede decir que el objeto
contenido es parte constitutiva y vital del que lo contiene.
 No compartición: Los objetos contenidos no son
compartidos, esto es, no forman parte del estado de otro
objeto
 La Agregación como la Composición son casos
particulares de Asociación.
Composición - Ejemplos
Composición - Ejemplos
Composición - Ejemplos

Representación de la Composición en UML

Ventana Modulo

1 1

0..2 1..n
ScrollBar Aula

Una ventana está

compuesta por cero o Un módulo está
hasta 2 ScrollBars compuesto por una o
más aulas
 Composición - Ejemplos

Libro tiene
Pagina
1 1..*

es parte de

class Libro { class Pagina {

Pagina pag []; Pagina() {
...
Libro() { }
pag = new Pagina[300]; }
}
}

Un objeto de la clase Libro se crea junto con

sus (objetos) de Pagina.
Referencias bibliográficas

 Deitel J., Paul y Deitel M., Harvey. (2008) Java,

Como Programar. Pearson Prentice-Hall. Mexico.
 Grady Booch, James Rumbaugh y Ivar Jacobson. El
Lenguaje Unificado de Modelado. Addison Wesley,
2001.
 Joyanes Aguilar, Luis y Zahonero Martínez, Ignacio
(2010). Programacion en C, C++, Java y UML.
McGraw-Hill. Mexico D.F.