Implementación de

relaciones entre clases

Landero. P (2021). Implementación de

relaciones entre clases [apunte]. Chile. UNAB
Implementación de relaciones
entre clases

CONTENIDO
1. INTRODUCCIÓN………………………………………………………………………………...………...………..2

2. ASOCIACIÓN (RELACIÓN) - COLABORACIÓN ENTRE OBJETOS………………………………….3

2.1. ¿Qué es la asociación entre Objetos y como se representa?..............................3
2.2. Declarar atributos a partir de un Diagrama de Clases…………………………………….10
2.3. ¿Cómo programar la relación de COLABORACIÓN ( )?........................13
2.4. ¿Cómo programar la relación de AGREGACIÓN ( )? …………………..20
2.5. ¿Cómo programar la relación de COMPOSICIÓN ( )?........................26
2.6. ¿Cómo programar la relación de DEPENDENCIA (USO) ( )?..............29

3. CASO PROPUESTO: Aplicación ventas de productos “SuperM”………………………………31

1
Implementación de relaciones
entre clases

1. INTRODUCCIÓN

Como lo mencionamos en el apunte de fundamentos de la POO, para diseñar los

mensajes o interacciones entre objetos, se representan en un diagrama de clases a
través de distintos tipos de relaciones. La interacción entre objetos también se
denomina “Colaboración entre objetos”. La figura 1 muestra la representación de los
tipos de relaciones: de uso (dependencia), de asociación, Agregación,
Composición y Herencia que serán explicados en este documento. Cabe mencionar
que la aplicación de la relación de herencia lo dejaremos para el próximo apunte
(unidad 2).

Figura 1: Tipos de Relaciones entre Clases: Uso, Asociación, Agregación, Composición y

Herencia.

Una relación es una conexión semántica entre clases que permite que una conozca
los atributos, operaciones y relaciones de otras, debido a que las clases no actúan
aisladas, sino relacionadas. Una clase puede ser un tipo de otra, a lo que se llama
generalización; o puede contener objetos de otra clase de varias formas posibles,
dependiendo de la fortaleza de la relación que exista entre ambas. Le sugiero utilizar
la siguiente herramienta de diseño: https://staruml.io/

Finalmente, se deja al estudiante el desafío Aplicación para administrar ventas

de productos “SuperM” para que lo desarrolle con el apoyo del docente a través
de las herramientas virtuales diseñadas en el aula de la asignatura, en beneficio del
logro del aprendizaje esperado de esta unidad.
Implementación de relaciones
entre clases

2. ASOCIACIÓN (RELACIÓN) - COLABORACIÓN ENTRE OBJETOS

2.1. ¿Qué es la asociación entre Objetos y cómo se representa?

Los objetos interaccionan entre sí enviándose mensajes. Una colaboración consiste

en que un objeto de una clase envía un mensaje a otro objeto de otra clase (ver
figura 2). Para realizar su tarea el objeto puede delegar trabajos en otro que puede
ser parte de él mismo o de cualquier otro objeto del sistema. El objeto que envía
mensaje a otro lo hace mediante una llamada a sus atributos o métodos. Los
mensajes son tratados por la interfaz pública (métodos públicos) del objeto que
los recibe. Eso quiere decir, que solo podemos hacer llamadas a aquellos atributos
o métodos de otro objeto que sean públicos o accesibles desde el objeto que hace la
llamada.

Por otro lado, el objeto receptor reaccionará cambiando su estado (modificando

los valores de sus atributos) o enviando otros mensajes (llamando a otros
atributos o métodos del mismo objeto o de otros objetos).

Figura 2: Paso de mensajes entre objetos.

En orientación a objetos, las principales relaciones que se pueden establecer entre

objetos son las de generalización (o herencia), asociación, agregación,
composición y dependencia (o uso). La decisión para establecer una u otra
relación entre los objetos no es una tarea de programación, sino de diseño
orientado a objetos y depende básicamente de la experiencia del diseñador. En la
figura 3 se muestra la representación de estos tipos de relaciones a través de un
diagrama de clases del lenguaje estándar UML1.

1
El Unified Modeling Language, UML (Lenguaje Unificado de Modelado) (Booch et al., 1998), se trata de un estándar que se
ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa
a los desarrollos de software (programas informáticos).
Implementación de relaciones
entre clases

Figura 3: Ejemplo que ilustra el uso de la notación en la construcción de un diagrama de

clases.

En la tabla siguiente se muestra el concepto y significado de la notación UML para

cada tipo de relación que usaremos en este curso: 4

SÍMBOLO DEL TIPO

SIGNIFICADO DE LA RELACIÓN
DE RELACIÓN
Uso o dependencia: representa un tipo de relación en
la que:
• Una clase instancia a un objeto de otra clase.
• Es una relación de uso, es decir, una clase usa a otra,
que la necesita para su cometido.
• Con la dependencia denotamos que un cambio en la
clase utilizada puede afectar al funcionamiento de la
clase utilizadora, pero no al contrario.

Asociación o colaboración. Es una relación semántica

entre objetos, es decir:
• Un objeto accede a los atributos y métodos de otro
objeto estableciendo una relación a través de un
atributo que referencia a la clase con la que se
relaciona.
Implementación de relaciones
entre clases

• Estas asociaciones se pueden representar, además,

con su multiplicidad o cardinalidad.
• También, cuando corresponda, puede representar la
unidireccionalidad o la navegabilidad (expresa que el
objeto relacionado con otro va solo en una de las
clases).

Agregación: Es un tipo particular de asociación donde:

• Un objeto se puede formar de otros objetos (de
distinto tipo), en la cual sus objetos componentes y
el objeto constituido forman un todo; por ello,
modela una relación entre un "todo" y sus "partes".
• Sin embargo, la existencia de los objetos
componentes es independiente, es decir, “las partes”
no dependen de la existencia del ”todo”.
• Además, las "partes" pueden pertenecer a varios
"todos".
• Gráficamente se representa colocando un rombo
blanco en el extremo de la clase constituida (parte
del "todo").
5
• Por ejemplo: un Vuelo (el "todo") tiene varios pilotos
(algunas de sus "partes"), de tal forma que, para que
exista un vuelo deben existir pilotos, pero no es
necesario que sean asignados en el momento de
crear el vuelo y estos mismos pilotos pueden ser
asignados a otros vuelos.

Composición: Al igual que en la agregación, en este

tipo de relación:
• Un objeto se conforma de varios otros objetos.
• Sin embargo, cada una de sus "partes" solamente
puede pertenecer a un "todo" y tienen una relación
fuerte de existencia; es decir, un "todo" no puede
existir si antes no existen sus "partes" y a su vez las
"partes" desaparecen cuando se elimina el "todo".
• Gráficamente se representa colocando un rombo
negro en el extremo de la clase constituida (parte del
"todo").
• Por ejemplo, una empresa (el "todo") tiene varios
departamentos (algunas de sus "partes"), de tal
Implementación de relaciones
entre clases

forma que para que exista la empresa deben existir

los departamentos y al desaparecer la empresa,
también lo hacen sus departamentos.

Generalización o de Herencia. Expresa que una clase

es derivada (subclase) o se define a partir de otra clase
(la superclase). Este tipo de relación la aplicaremos en
la unidad 2 de este curso.

Es una relación especial que ocurre cuando una clase

implementa una clase que es una Interface. Este
tipo de relación la aplicaremos en la unidad 2 de este
curso.

Cabe destacar que Las relaciones generalmente son binarias, es decir, el vínculo se
establece entre dos clases. También existe las asociaciones n-arias, vale decir el
vínculo que se establece entre tres o más clases.

La cardinalidad o multiplicidad de las relaciones representa cuántos objetos de

una clase pueden participar en la relación con otra clase. Las distintas cardinalidades
6
que existen en la relación entre clases se describen en la figura 4.

Figura 4: Cardinalidades o multiplicidad de las relaciones de un Diagrama de clases UML.

Estas cardinalidades pueden ser usadas en cualquier tipo de relación (excepto en la

herencia), sin embargo, si el diagrama no lo indica, dependiendo del contexto, es
porque no es necesario expresarla. Pero no significa que no sea importante.

En la figura 5 se entrega un ejemplo de cardinalidades de la relación entre las clases

Cliente y OrdenCompra establece, por un lado (ya que la relación se da por los dos
sentidos), que cada objeto Cliente participa en varias órdenes de compras pudiendo
Implementación de relaciones
entre clases

no participar en ninguna; y por otro, en cada objeto orden de compra participa un

solo cliente.

Figura 5: Ejemplo de Cardinalidades entre los objetos de las clases Cliente y OrdenCompra.

Otros ejemplos de cardinalidades (la relación se da en un solo sentido):

• Un equipo de beisbol se compone de 9 jugadores:

• Un profesor imparte asignaturas a muchos estudiantes

• Un vehículo de transporte tiene cero o más ruedas:

Implementación de relaciones
entre clases

Ejercicio propuesto 1:

Para el diagrama siguiente escriba lo que se está expresando en cada una de las
relaciones.

Figura 6: Diagrama de clases del ejercicio propuesto 1.

Parte de la solución ejercicio propuesto 1: 8

Les dejo solo algunas relaciones descritas:
• Cada avión posee hasta 4 motores y mínimo 1. La asignación del motor se
puede realizar después de creado el avión (de manera independiente) pero un
motor solo puede ser asignado a un solo avión a la vez. Si el avión desaparece
los motores pueden ser reasignados a otro avión (Si hubiese sido una relación
compuesta, con rombo de color negro, las ruedas se crearían en el mismo
momento que se crea el avión, no pudiendo ser reasignadas a otro avión en
ningún momento, por lo tanto, si el avión desaparece sus ruedas también
desaparecen).
• Cada vuelo debe tener por obligación un piloto como mínimo y dos máximos,
pudiendo estos pilotos ser reasignados a otros vuelos. No es necesario crear
los pilotos en el mismo momento que se crea un vuelo.
• Un vuelo tiene asociado varias reservas y cada reserva es para un único vuelo.
La reserva se puede crear después de crear el vuelo (no en el mismo
momento) y no es posible reasignarla a otro vuelo.
Implementación de relaciones
entre clases

Ejercicio propuesto 2:

Se requiere implementar una aplicación para un banco de acuerdo con los siguientes
requerimientos:
• Que el ejecutivo de cuentas pueda registrar datos de los clientes y sus cuentas
de débitos cuando sean autorizadas. Los clientes forman parte del registro de
personas del banco y se registran o mantienen clientes en su base de datos
pudiendo tener al menos una cuenta.
• Las cuentas de los clientes se caracterizan por el número de la cuenta, saldo,
el cliente y un estado. Estas por ningún motivo pueden ser reasignadas a otro
cliente (aunque el cliente haya sido eliminado). Al ingresar (crear) una cuenta
se exige, además, los datos de la tarjeta asociada (id y tipo de tarjeta).
• Que el cliente a través de su tarjeta de débito bancaria se conecte al sistema
y pueda realizar movimientos.
• El sistema verifica que la tarjeta usada por el cliente corresponda al id
registrado en el sistema del banco, versus la ingresada por el cliente en el
cajero automático. En el caso de no cumplir con la verificación la tarjeta
quedará bloqueada. Podrá desbloquear su tarjeta solo si se presenta al banco
personalmente.
• El ejecutivo podrá cancelar la cuenta cuando sea solicitado por el cliente.
9
Diseñe el diagrama de clases representando los tipos de relaciones según
corresponda e indique la multiplicidad de todas ellas. Asigne atributos y
comportamientos (métodos) a cada clase. Suba al foro su respuesta indicando los
fundamentos de los tipos de relaciones elegidas (¿Por qué eligió ese tipo relación y
no otra?) para que sea retroalimentada por sus compañeros y docente.

Parte de la solución ejercicio propuesto 2:

Les dejo un ejemplo de diagrama de clases que representa el enunciado del ejercicio
propuesto 2. Al leer el enunciado debe identificar los objetos para agruparlos en
clases. Recuerde que NO TODO se modela, ya que debe aplicar el principio de
abstracción en la POO, por lo tanto, lea bien el enunciado e identifique solo aquello
que se necesite almacenar (junto con sus comportamientos) para que el usuario
pueda ejecutar dichos comportamientos una vez que se haya programado la
aplicación.
Implementación de relaciones
entre clases

Figura 7: Alternativa de solución Diagrama de clases del ejercicio propuesto 2.

2.2. Declarar atributos con Java a partir de un Diagrama de Clases

10
Cabe destacar que en el diagrama de clases no se indica explícitamente el atributo
(u objeto) de las relaciones, pero en el momento de implementarlo debe declarar los
atributos (objetos) asociados a las relaciones. En la figura 8 se muestra un ejemplo
de cómo declarar los atributos a partir de un diagrama de clases. Los atributos
(objetos) empdir, cargoemp no están dentro de las clases, pero los hemos definido,
ya que son los atributos (objetos) que han salido de las relaciones MultiTienda –
Empleado y Empleado - Cargo.

Si te fijas, la navegabilidad hace que el atributo (objeto) de la relación se defina

solo en una de las clases de dicha relación, es por eso que la relación entre
Multitienda y Empleado define el objeto empdir en MultiTienda (y no se define
otro atributo en Empleado que referencie a MultiTienda), del mismo modo, entre la
relación Empleado y Cargo se define el objeto cargoemp en Empleado (y no se
define otro atributo en Cargo que referencie a Empleado).

La figura 8, también muestra la relación de uso que existe entre

SistemaMultiTienda con las clases Multitienda, Empleado y Cargo, esto significa
que debemos crear en el main los objetos que participan en la aplicación, que en
este caso particular hemos creado m1, e1 y c1.
Implementación de relaciones
entre clases

Figura 8: Ejemplo de declaración de atributos usando Java para el diagrama de clases

donde Empleado colabora con MultiTienda y Cargo colabora con Empleado.

En este ejemplo una multiTienda tiene asociado

un solo empleado director y a un empleado se le
asigna un sólo cargo (las relaciones son en un
sólo sentido)

11

Esta forma de definir los atributos (figura 8) se realiza en todo tipo de relación con
navegabilidad (relaciones en un solo sentido). A continuación, te entrego
ejemplos de definición de atributos para relaciones en ambas direcciones y
también te muestro relaciones con distintas cardinalidades. Si la cardinalidad es
superior a 1 vamos a usar arreglos estáticos (los arreglos los trabajamos en la
práctica 1 al inicio de la unidad).
Implementación de relaciones
entre clases

Ejemplo 1:

Un departamento tiene una secretaria y

una secretaria pertenece a un sólo
departamento.

Ejemplo 2:

12
Un departamento posee varios
profesores y un profesor pertenece a un
sólo departamento.

Ejemplo 3:

Un estudiante tiene muchas asignaturas

y una asignatura posee varios
estudiantes.
Implementación de relaciones
entre clases

Ejemplo 4:

Una nota es de un alumno que pertenece a

una sección. Un estudiante y una sección
poseen varias notas.

Ahora que has aprendido como se definen los atributos de las clases que participan
en un diagrama, a continuación, implementaremos ejemplos para cada tipo de 13
relación (colaboración, composición, agregación y de uso). Recuerda que la Herencia
es otro tipo de relación, pero la aplicaremos en la siguiente unidad. Te sugiero que
tú también programes este ejemplo para enfrentar lo que sigue correctamente y sin
dificultades.

2.3. ¿Cómo programar la relación de COLABORACIÓN? ( )

Este tipo de conexión entre objetos, como ya lo mencionamos, se representa

gráficamente con una línea recta continua que une las clases relacionadas. Pueden
ser uni o bidireccional. Cuando es unidireccional, la línea termina con una punta de
flecha indicando el sentido ( ). Este tipo de relación no es una
relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Vamos a implementar el diagrama de clases de la figura 9 que fue diseñado sobre la
base de los siguientes requerimientos:
• Se necesita crear una aplicación para agregar estudiantes. Adicional al Rut y
nombre, es necesario saber la carrera que estudia.
• Cada carrera se define por el nombre, número de semestres y su situación
(true: vigente o false: no vigente) y cada carrera es de una (solo) facultad.
• De la facultad se necesita saber su nombre y número.
Implementación de relaciones
entre clases

Figura 9: Diagrama de Clases para una aplicación que necesita registrar estudiantes. Un
estudiante estudia una carrera y una carrera pertenece a una facultad.

Después de implementar las clases (Estudiante, Carrera y Facultad) vamos a 14

programar el main para realizar las siguientes pruebas:
1) Escriba las sentencias necesarias para ingresar un estudiante. Muestre sus datos
para probar que se hayan seteado (asignado) correctamente.
2) Revise que haya quedado correctamente asignado el número de semestres de la
carrera del estudiante.
3) Revise que haya quedado correctamente asignado el nombre de la facultad de la
carrera del estudiante.
4) Pruebe si está funcionando correctamente la actualización del nombre de la
facultad de la carrera del estudiante (use método setNombre de Facultad). Para
actualizar el nombre de la facultad acceda a través del estudiante creado.
Implementación de relaciones
entre clases

Programación de la clase Facultad: (aquí no hay nada nuevo de lo que ya has

aprendido).

Programación de la clase Carrera:

Aquí tienes que definir un atributo (objeto), que lo he llamado facCarr, generado
por la existencia de la relación de colaboración entre Carrera y Facultad (la facultad
posee una carrera). El constructor se comporta de la misma forma como si facCarr
fuera un atributo más, considerando que el parámetro respectivo referencie a
Facultad.
15
Al método toString(), como la carrera tiene una sola facultad, puedes agregar al
retorno del string los datos de la facultad.
Implementación de relaciones
entre clases

16

Programación de la clase Estudiante:

Aquí tienes que definir un atributo (objeto), que lo he llamado carrEst, generado
por la existencia de la relación de colaboración entre Estudiante y Carrera (el
estudiante estudia una carrera) y considerar lo que ya mencionamos en Facultad.
Implementación de relaciones
entre clases

17

Si te das cuenta, como facCarr y carrEst son atributos como los demás, puedes
usar sus respectivos métodos set y get cuando sea necesario.

Finalmente, programar el main es lo más importante para que logres una real
comprensión de la POO. Antes, te explicaré (leer figura 10), el acceso desde un objeto
estudiante (que crearemos en el main y que lo llamaremos est1) a cualquiera de los
métodos del diagrama:
Implementación de relaciones
entre clases

Figura 10: Ejemplo que explica el acceso a los distintos métodos de las Clases del diagrama.

En Facultad, están los métodos: getRut(), getNombre(),

sertRut(..), setNombre(..) y toString() que pueden ser
invocados desde la misma Facultad y también desde
Carrera, desde Estudiante y desde la clase donde está el
main.

Para invocar los métodos getNumero() y toString() de

Facultad desde Carrera, se hace a través del objeto facCarr:
facCarr.getNumero() y facCarr.toString(). Pero facCarr es un
facCarr atributo, entonces es mejor que uses su método get:
getFacCarr().getNumero() y getFacCarr.toString()
Si no existiera el atributo facCarr y si aun así necesito acceder
a Facultad estamos obligados a crear un objeto que no es
atributo, pero este caso ya no sería una relación de
colaboración, sino que de Uso.

Lo mismo anterior, desde Estudiante puedes

carrEst acceder a Carrera y también a Facultad; y lo puedes
hacer con los objetos que tengas disponibles. Desde
18
Estudiante a Carrera accedes con getCarrEst(). y
desde Estudiante a Facultad accedes con
getCarrEst().getFacCarr.
Por lo tanto, para invocar a los métodos getNumero()
y toString() de Facultad haces:
getCarrEst().getFacCarr().getNumero()
est1 – carr1 -fac1 getCarrEst().getFacCarr.toString()

En el main crearemos el objeto est1 que referencia a la clase

Estudiante, pero para crear est1 es necesario crear previamente
su carrera (objeto que llamaremos carr1) y a su vez para crear el
objeto carr1 necesitamos crear un objeto facultad (que
llamaremos fac1), por lo tanto, si necesito invocar al método
setNombre de facultad desde el main debes hacer:
est1.getCarrEst().getFacCarr().setNombre(....)
est1 no es atributo, por eso no usas su get respectivo.
Si te das cuenta, cada clase tiene sus objetos que serán seteados
en el main a través de sus constructores. De esta forma puedes
acceder a los métodos públicos de todas las clases del diagrama.
Implementación de relaciones
entre clases

El main siguiente (figura 11) crea un estudiante (est1) y realiza todas las pruebas
solicitadas en el enunciado de este ejercicio y te deja dos pruebas propuestas para
que tú las implementes. Para comprenderlo lee la explicación de la figura 10.

Figura 11: Programación método main ejemplo de aplicación relación de Colaboración.

19

Esto es lo que arroja la ejecución del main de la figura 11. Si tienes dudas plantea
tus preguntas en el foro para que puedas seguir avanzando y comprendiendo los
ejercicios que siguen.
Implementación de relaciones
entre clases

2.4. ¿Cómo programar la relación de AGREGACIÓN? ( )

Como ya lo mencionamos, la relación de Agregación es un tipo particular de

asociación (colaboración) donde un objeto de una clase se puede formar por otros
objetos de otras clases, en la cual sus componentes y el objeto constituido forman
un todo; por ello, modela una relación entre un "todo" y sus "partes". Por ejemplo,
un servidor de servicios de impresión puede tener relaciones de agregación con sus
periféricos (impresora y scanner), ya que estos dispositivos no son exclusivos de un
servidor en particular, sino que se pueden conectar a varios; además, no dependen
exclusivamente del tiempo de vida del servidor; es decir, si el servidor se
descompone, los periféricos continúan operando (ver figura 12).

Figura 12: Ejemplo de Agregación donde un objeto Servidor de Impresión más los objetos 20
impresoras y escáneres que lo componen es el “todo” y sus componentes son sus “partes”.

Es muy importante que diferencies la agregación con la asociación (colaboración) que

hemos profundizado en el apartado 2.3. La agregación expresa que un objeto “el
todo” no puede existir sin sus partes, o sea, es MUY necesario que en algún
momento sus partes sean asignadas, aunque estas no se creen en el mismo momento
de crear el todo y que tienen independencia, ya que pueden ser usadas por otros. No
así la asociación, ya que “el todo”, si quisiera, puede seguir operando sin sus partes
Implementación de relaciones
entre clases

y también podrá darse que las partes no sean compartidas por otros. En el ejemplo
del apartado 2.3, también podría ser expresado como una agregación, pero no lo es,
porque así como está definida la navegabilidad entre los objetos, se pueden dar
algunas situaciones no permitidas por la agregación, por ejemplo: “el todo” no está
conformado por varias partes (un estudiante tiene solo una carrera y la carrera se
asocia a una facultad), el sistema podría tener registrado carreras sin que nunca se
le asocie su facultad y la carrera puede seguir operando sin problemas.

La agregación se programa exactamente igual como una colaboración (visto en el

apartado 2.3 de este apunte), la diferencia está en la restricción de dependencia y
que las partes, por lo general, se trabajan con arreglos (estáticos o dinámicos según
corresponda). A continuación, vamos a programar un caso de Agregación, donde la
relación entre “el todo” y “sus partes” posee una cardinalidad mayor que 1 que nos
obliga a utilizar arreglos. Los arreglos estáticos lo vimos en la práctica 1 de esta
unidad, te sugiero que vuelvas a revisar dicha práctica para que comprendas este
ejemplo.

Vamos a implementar el diagrama de clases de la figura 13 que fue diseñado sobre

la base de los siguientes requerimientos:
• Se necesita crear una aplicación para agregar los cursos de un colegio solo de
enseñanza básica caracterizadas por un número y una letra (1° A, 1° B, 2° A,
etc.) 21
• Cada curso posee asignaturas (mínimo 3, máximo 5). Un curso necesita
asignaturas para existir, aunque no es necesario crearlas al mismo tiempo
que el curso. Una asignatura puede ser compartida en varios cursos. Las
asignaturas se caracterizan por un código (número correlativo) y nombre.
• Se requiere un método que muestre los datos de las asignaturas de un curso.
• Se requiere un método que permita verificar si el curso fue creado con la
cantidad válida de asignaturas (mínimo 3 y máximo 5). Si el curso no es válido
no debe ser almacenado.
Implementación de relaciones
entre clases

Figura 13: Ejemplo de relación de Agregación para una Apps que registra asignaturas de
los cursos de un colegio. “El todo” es el curso más sus asignaturas que son sus “partes”.

El constructor de Curso (”el

todo”) recibe un conjunto de
objetos en un arreglo que son sus
asignaturas (“las partes”).
Por lo tanto, sus partes
(asignaturas) deben existir antes
de crear el curso.

22

Después de implementar las clases (Asignatura y Curso) vamos a programar el main

para realizar las siguientes pruebas:
1) Escriba las sentencias necesarias para ingresar un curso con sus asignaturas.
Muestre sus datos para probar que se hayan seteado (asignado) correctamente.
2) Revise que haya quedado correctamente asignada la primera asignatura del
curso.
3) Revise que haya quedado correctamente asignado el correlativo de la segunda
asignatura del curso.
4) Pruebe si está funcionando correctamente la actualización del nombre de la
segunda asignatura asignada (método setNombre). Para actualizar el nombre de
la segunda asignatura, acceda a través del curso creado.
5) Cree un nuevo curso con más o menos asignaturas de las permitidas y pruebe si
está funcionando correctamente el método que verifica que el curso
efectivamente se le asignó a mínimo de 3 y máximo de 5 asignaturas, en caso
contrario, elimine el curso (destrúyalo).
Implementación de relaciones
entre clases

Programación de la clase Asignatura: (aquí no hay nada nuevo de lo que ya has

aprendido).

23

Programación de la clase Curso (“el todo”):

Aquí tienes que definir un atributo arreglo (“las partes” de Curso), que he
llamado asigLis, donde cada elemento del arreglo es un objeto asignatura, generado
por la relación de agregación entre Curso y Asignatura (un curso tiene hasta 5
asignaturas y mínimo 3) y debes programar también los métodos customer
solicitados en el enunciado.
Implementación de relaciones
entre clases

24
Implementación de relaciones
entre clases

El main de la figura 14 realiza las pruebas requeridas:

Figura 14: Programación método main ejemplo de aplicación relación de Agregación.

25
Implementación de relaciones
entre clases

Al ejecutar el main de la figura 14 arroja los siguientes:

2.5. ¿Cómo programar la relación de COMPOSICIÓN ( )?

Al igual que la agregación, la composición es un tipo particular se asociación, donde

un objeto de una clase (“el todo”) se conforma por varias objetos de otras clases
(“sus partes”), sin embargo, cada una de sus "partes" solo puede pertenecer a uno
y solo un "todo" (no se comparten con otro “todo”) y tienen una relación muy fuerte
de existencia; es decir, un "todo" no puede existir si no existen sus "partes" y, a su
vez, las "partes" desaparecen cuando se elimina el "todo".

Por ejemplo, la relación entre una empresa y sus departamentos es de composición,

ya que cuando se crea una empresa, en ese mismo momento se deben crear sus
departamentos; además, estos departamentos son exclusivos para esta empresa lo
26
que significa que, si la empresa desaparece, los departamentos también desaparecen
(ver figura 15).

Figura 15: Ejemplo de Composición donde un objeto Empresa más los objetos
Departamentos que lo componen es el “todo” y sus componentes son sus “partes”.

El rombo negro
representa la
relación de
composición y se
pone en el lado del
'todo"
Implementación de relaciones
entre clases

Si al ejemplo de agregación del apartado 2.4, cambiamos los requerimientos,

indicando que cada asignatura es propia para un solo curso (no puede ser compartida
con otros cursos) y además las asignaturas del curso se crean en el mismo momento
(no antes, ni después) que se crea el curso. El diagrama quedaría como se muestra
en la figura 16, que aparte del color del rombo (negro en vez de blanco), el
constructor “del todo” NO recibe un arreglo de objetos con sus partes
asignaturas sino que recibe un conjunto de datos (que en este caso son los nombres
de las asignaturas) para crear sus partes dentro de dicho constructor.

Figura 16: Ejemplo de relación de Composición para una Apps que registra asignaturas de
los cursos de un colegio. “El todo” es el curso más sus asignaturas que son sus “partes”.

El constructor de Curso (de la

clase (“todo”) NO recibe sus
objetos asignaturas (“sus
partes”). Recibe datos para
crear dentro del constructor
sus partes.
27

Por lo tanto, a pesar que a nivel de diseño (semántico) es una tremenda diferencia
con la asociación y agregación, la diferencia en programación es muy sutil. Solo debes
crear los objetos “partes” en el constructor “del todo” (en el mismo momento de
crear el todo). Entonces, los objetos asignaturas (las partes), que en la agregación
los creamos en el main (antes de crear el todo curso), ahora en la composición
debemos crear los objetos asignaturas (“sus partes”) en el constructor de Curso (“el
todo”).
Implementación de relaciones
entre clases

Programación de la clase Curso (“el todo”):

28
Implementación de relaciones
entre clases

El main de la figura 17 realiza las pruebas requeridas:

Figura 17: Programación método main ejemplo de aplicación relación de Composición.

Al ejecutar el main de la figura 17 arroja lo siguiente:

29

2.6. ¿Cómo programar la relación de DEPENDENCIA o USO ( )

En este tipo de relación muchas veces se confunde su aplicabilidad, pero es muy

diferente a los tres tipos de relaciones vistas anteriormente, ya que la relación NO
genera un atributo en la o las clases que participan en la relación, solo que la clase
dependiente hará referencia a la clase de la que depende en algún punto: variable
local o parámetro que referencia a la clase a la que depende). Por esta razón,
suele ser habitual encontrar declaraciones import de las clases de las que se depende
cuando estas se crean en package distintos al package de la clase dependiente.

Nosotros ya hemos aplicado este tipo de relación cuando realizamos las pruebas de
los ejemplos de los otros tipos de relaciones (ver figura 18). La relación de
dependencia existe entre la clase donde se encuentra el método main y la que
es necesario instanciar para cumplir los requerimientos establecidos.
Implementación de relaciones
entre clases

Figura 18: Ejemplos de relaciones de dependencias entre las clases dependientes

donde está el main y las clases Estudiante, Facultad, Curso y Asignatura
respectivas.

Ejemplo 1 Ejemplo 2 Ejemplo 3

30

Las dependencias con color rojo de los ejemplos de la figura 18 no es necesario

representarlas en el Diagrama de Clases, pero sí existen (implícitamente), ya que el
main (ver main de las figuras 11, 14 y 17) ha definido variables locales que
referencian a Estudiante, Facultad, Curso y Asignatura según corresponda. Estas
relaciones no se definieron en el diagrama de clases, porque es suficiente establecer
la dependencia entre la clase Principal y Curso, es decir, se debe evitar explicitar en
el diagrama de clases relaciones que no aporten comprensión al diseño de la solución
a la problemática (o situación a resolver).

En el siguiente ejemplo de dependencia (ver figura 19), existe la relación entre una
clase que usa referencias a objetos de otra clase como parámetros de un método
(que en este caso es el método imprimir) de la misma. Si en el diagrama de clases
se suministra la signatura2 completa de este método, como en el caso de la figura

2
Se llama signatura a la parte donde se declaran los parámetros o argumentos de un
método. Cada parámetro se declara indicando el nombre del parámetro y su tipo de datos o
referencia a una Clase.
Implementación de relaciones
entre clases

19, no es necesario indicar la relación de dependencia puesto que, el uso de una

clase por otra está implícito en la signatura. Por ejemplo, si tenemos una clase
Impresora que tiene una operación imprimir que toma como parámetro una
instancia (un objeto) de la clase Documento, diremos que Impresora depende de
Documento. Nótese que las impresoras no mantienen enlaces con los documentos
que imprimen (no se crea un atributo objeto en impresora), solo los procesan con la
operación correspondiente (que en este caso es imprimir), pero después de cada
llamada a imprimir, no “recuerdan” los documentos que imprimieron (no lo
almacenan en un atributo). Se dice que este es el tipo de relación entre clases “más
débil”, y como recomendación general, solo debería mostrarse en los
diagramas de clases cuando aporten alguna información importante.

Figura 19: Ejemplo de relación de Dependencia (o de uso) entre las clases Impresora y
Documento.

31

3. CASO PROPUESTO: Aplicación ventas de productos “SuperM”

Considere la siguiente situación: El gerente de SuperM”, un conocido supermercado

de la región, lo ha contratado a usted para que programe una aplicación usando POO.
Se le ha solicitado que utilice el lenguaje de programación Java y el diagrama de
clases siguiente:
Implementación de relaciones
entre clases

Se solicita:

1) Programar atributos, constructores, setters, getters, toString y las relaciones del

diagrama. Considere que el correlativo del Ítem es un número que comienza en
0 y que va aumentando de 1 en 1. Considere también que el atributo totalVenta
inicialmente vale 0 cuando una venta ha sido instanciada. Además, considere lo 32
siguiente:
• Use instrucciones iterativas para crear y mostrar los objetos con arreglos.
• En el main solicite los datos (nombre y precio) de los productos asociados
a la venta y guárdelos en un array de objetos prods.
• La venta posee 3 fechas: fecha de venta, fecha de despacho y fecha de
recepción. Use la clase Date de Java para el tratamiento de fechas y
guarde las fechas en el main en un arreglo llamado fecs.
• En la venta se registran 2 personas: el cliente y el empleado que realiza
la venta. Del mismo modo guarde los datos del cliente y el empleado en
un arreglo de objetos llamado pers.
• Al ingresar una venta, debe validar que la fecha de venta es mayor o igual
a fecha de despacho y esta es mayor o igual a la fecha de recepción.

2) Implemente el main para generar una venta y realizar las pruebas que se
solicitan. Pruebe lo siguiente:
a) Escriba las sentencias necesarias para ingresar una venta inválida al sistema y
muestre sus datos para probar que no se hayan seteado los valores.
b) Escriba las sentencias necesarias para ingresar una venta válida al sistema y
muestre sus datos.
c) Revise que fue correctamente asignado el correlativo del producto de la venta del
primer ítem.
Implementación de relaciones
entre clases

d) Revise que fue correctamente asignado el precio del producto del segundo ítem
vendido.
e) Pruebe si está funcionando correctamente la actualización del precio del producto
del primer ítem que fue vendido. Muestre el producto modificado a navegando a
través de la venta y mostrando el producto de forma directa.

NOTA IMPORTANTE: Te sugiero que para realizar la actividad te guíes

principalmente por el presente apunte, el apunte de fundamentos y la práctica 1 que
desarrollaste al inicio del curso. Si navegas por internet buscando más información
te podrías confundir más, ya que existen muchos errores en las definiciones y en su
aplicabilidad. Recuerda que también puedes hacer tus preguntas en el foro.

33