Este capítulo trata sobre el diseño de relaciones entre clases en el análisis y diseño de sistemas. Se describen conceptos como la navegación de relaciones, asociaciones y agregaciones. También se explican opciones para el diseño de la visibilidad, direccionalidad y multiplicidad de las relaciones. El objetivo es diseñar relaciones que modelen adecuadamente las interacciones entre objetos del mundo real.

1. Análisis y Diseño
Capítulo 9: Diseño de Relaciones

2. Objetivos: Diseño de Relaciones
Al final de este capítulo, usted podrá:
• Describir el concepto de navegación de relaciones
• Definir asociaciones y relaciones agregadas
• Describir opciones de visibilidad de objetos
• Describir las decisiones relacionadas al diseño de multiplicidad en
relaciones
• Diseñar clases de asociación.

3. Navegación
• Durante el Análisis la mayoría de las asociaciones son bi-direcionales
• Durante el diseño la mayoría de las asociaciones se vuelven uni-
direccionales, debido a que las asociaciones de dos vías son más
difíciles y costosas de implementar que una asociación de una vía.
• Se agrega una flecha a la asociación para mostrar que la navegación
va en una sola dirección.
Cliente Orden
Un cliente le puede “hablar” a
una orden.
La orden no le puede “hablar” al
cliente
0 *

4. Decisiones de Navegación
Durante el diseño determinamos si es realmente necesario
navegar en ambas direcciones.
La necesidad de navegación se revela por los casos de uso y
escenarios.
Dada la instancia de la clase A, ¿tenemos que acceder a
todas sus instancias en la clase B?
Dada la instancia de la clase B, ¿tenemos que encontrar todas
las instancias asociadas a la clase A?

5. Navegación (2-vías) vs Navegación (1-vía)
• Las asociaciones de dos vías son más difíciles y costosas
de implementar que una asociación de una vía.
• Inclusive si para una asociación, la navegación de dos vías
pareciera ser requerida, la navegación de una vía puede ser
suficiente en muchas circunstancias. Este es el caso si por
ejemplo:
• La navegación en una de las direcciones no es muy
frecuente y no tiene requerimientos críticos de rendimiento
• El número de instancias de una de las clases es muy
bajo.

6. Preguntas de Navegación
• Para determinar que tipo de navegación se requiere
en el sistema, debo contestar preguntas tales como:
•¿De qué proveedor puedo comprar este producto?
(producto a proveedor).
•¿Qué productos han sido ordenados de este proveedor
en particular? (proveedor a producto).
Proveedor Producto
? ?
0..* 0..*

7. Ejemplo: Simplificando una Asociación
• Situación 1: Se necesita saber con mucha frecuencia que
proveedores ofrecen cierto producto, pero para efectos de control de
facturas, sólo se necesita generar una lista de todos los productos
que ha vendido un proveedor cada cuatro meses.
• Implementar la dirección de producto a proveedor y buscar
todas las instancias de producto cuando se produce la lista de
productos vendidos por parte de cada proveedor.
• Situación 2: Sólo existen dos proveedores
• Implementar solamente la dirección de producto a proveedor y
buscar todas las instancias de productos cuando se necesita
reservar la dirección del proveedor.

8. Navegabilidad de asociaciones en Java
Horario
Estudiante
// no necesita importar si están en el
mismo paquete
Class Horario
{
public Horario () {}
private Estudiante : theEstudiante;
}
Class Estudiante
{
public Estudiante () {}
private Horario: theHorario;
}
• Bi-direccionales

9. Navegabilidad de Asociaciones en Java
Horario
Estudiante
Class Horario
{
public Horario () {}
}
Class Estudiante
{
public Estudiante () {}
private Horario : theHorario;
}
• Uni-direccionales

10. Asociaciones en Java: Roles
Profesor
Sección
Class Profesor
{
public Profesor () {}
private Sección : theSección;
}
Class Sección
{
public Sección () {}
private Profesor : instructor;
}
instructor

11. Asociaciones en Java: Multiplicidad
Sección
Horario
Class Sección
{
public Sección () {}
}
Class Horario
{
public Horario () {}
private Sección[ ] : cursosPrimarios = new Sección[4];
}
cursosPrimarios
0..4

12. Curso
Import java.util.vector;
Class Curso
{
public Curso () {}
// La asociación múltiple
// es almacenada en un vector
private Curso[ ]:prerrequisitos;
// private Vector:prerrequisitos;
}
prerrequisitos
0 *

13. Navegación para Agregaciones
• Una agregación puede también ser uni-direccional.
• Para representar esto, la relación de agregación debe
incluir una flecha (normalmente del lado de la parte).
Cliente
Orden
0..*

14. Agregación en Java
Horario
Estudiante
Class Horario
{
public Horario () {}
private Estudiante : theEstudiante
}
Import java.util.Vector;
Class Estudiante
{
public Estudiante () {}
private Vector : theHorario;
}
0..*
1

15. Horario
Estudiante
Class Horario
{
public Horario () {}
private Estudiante : theEstudiante
}
Import java.util.Vector;
Class Estudiante
{
public Estudiante () {}
private Vector : theHorario = new Vector()
}
0..*
1

16. Visibilidad entre Objetos y Dependencias
• Las asociaciones establecen una vía de comunicación entre
objetos, pero no todas las comunicaciones requieren que la
estructura de un objeto dependa de la estructura de (los) objeto (s)
con que este se quiera comunicar.
• Para que dos objetos puedan “conversar” entre ellos deben poder
“verse”.
• Las dependencias permiten la visibilidad entre objetos.

17. Relación de Dependencia
• Una relación de dependencia significa que una clase es
dependiente de otra clase para algunos servicios, pero que no
necesita tener una relación estructural con la otra clase.
• Una relación de dependencia se ilustra con una línea
intermitente.
Cliente
Servidor
El objeto cliente depende del objeto proveedor

18. Una relación de la clase cliente que crean objetos de la clase
proveedor.
Hay operaciones de la clase cliente cuyas características retornan
clases o argumentos que referencian la clase proveedor.
Relación de Dependencia (cont.)
import class2;
public class class1()
class1
class2

19. Las asociaciones son relaciones estructurales.
Las dependencias son relaciones no estructurales.
El tipo de relación determina el tipo de visibilidad que debe haber
entre los objetos.
Dependencias vs. Asociaciones
Servidor2
Cliente
Servidor1
Asociación
Dependencia

20. Existen cuatro opciones de visibilidad
1. Referencia Global DEPENDENCIA
El objeto servidor es un objeto global
2. Referencia de Parámetro DEPENDENCIA
El objeto servidor es un parámetro para una operación en el
objeto cliente.
3. Referencia de Variable Local DEPENDENCIA
El objeto servidor es declarado localmente como una variable
en una operación.
4. Referencia de Campo ASOCIACIÓN
El objeto servidor define la estructura del objeto cliente.
Opciones de Visibilidad de Objetos

21. La instancia de ClaseUtileria es visible para las instancias de
ClaseA porque ClaseUtilería es global.
Visibilidad Global
ClaseA
op1()
ClaseUtileria
opUtil ()

22. Hay visibilidad de parámetro cuando una instancia de
ClaseB se envía como parámetro en una operación de una
instancia de ClaseA.
Visibilidad de Parámetro
ClaseA
op1 (param 1: ClaseB)
ClaseB

23. La operación op1() contiene una variable local de tipo ClaseB
Visibilidad de Variable Local
ClaseA
op1 ()
ClaseB

24. Buscar relaciones que reflejen el mundo real.
Buscar siempre la relación más ligera posible (dependencia).
Es la relación “permanente”? Use asociación (Visibilidad de Campo).
Es la relación “temporal”? Use dependencia.
Varios objetos comparten la misma instancia
• Pasar la instancia como un parámetro (visibilidad de parámetro).
• Hacer que la instancia sea administrada globalmente (visibilidad
global).
Varios objetos NO comparten la misma instancia (visibilidad de variable
local).
Cuanto tiempo toma crear y destruir las instancias de los objetos
relacionados?
Mucho tiempo? Es muy caro, use visibilidad global, de parámetro o de
campo.
Identificación de Dependencias: Consideraciones
Que opción es la correcta? DEPENDE DEL ESCENARIO

25. Ejemplo: Determinar dependencias (antes)
<<control>>
ControlRegistro
+ // enviar horario()
+ //salvar horario()
+ //crear horario con secciones()
+//getSecciones(porSemestre) ListaSecciones
<<entity>>
Estudiante
+ nombre
+ dirección
- carnet : int
+ addHorario(elHorario Horario, porSemestre: Semestre
+ getHorario(porSemestre: Semestre) : Horario
+ TienePrerrequisitos(laSeccion: Seccion) : boolean
# pasada(laSeccion : seccion) : boolean
<<entity>>
Horario
+enviar()
+salvar()
#existen conflictos?()
+crear con secciones()
-Semestre
<<entity>>
Sección
- nombre: String = “100”
- horaInicio: Time
- horaFinal: Time
- días : Enum
+ addEstudiante(elHorario : Horario)
+ removerEstudiante(elHorario : Horario)
+ new ()
+ setDatos()
registrante
0.1
0..1
horarioActual
0.1
0.1
1
0..*
Cursos Alternos
Cursos Primarios
0..*
0..2
0..*
0.4

26. Ejemplo: Determinar Dependencias (diseño)
<<control>>
ControlRegistro
+ // enviar horario()
+ //salvar horario()
+ //crear horario con secciones()
+//getSecciones(porSemestre) :ListaSecciones
<<entity>>
Estudiante
+ nombre
+ direccion
- carnet
+ addHorario(elHorario: Horario, porSemestre: Semestre)
+ getHorario(porSemestre: Semestre) : Horario
+ TienePrerquisitos(laSección Sección) : boolean
# pasada(laSección :sección) : boolean
<<entity>>
Horario
+enviar()
+salvar()
#existen conflictos?()
+crear con secciones()
-Semestre
<<entity>>
Seccion
- nombre: String = “100”
- horaInicio: Time
- horaFinal: Time
- días : Enum
+ addEstudiante(elHorario : Horario)
+ removerEstudiante(elHorario : Horario)
+ new ()
+ setDatos()
registrante 0.1
0..1
horarioActual
0.1
0.1
1
0..*
Cursos Alternos
Cursos Primarios
0..*
0..2
0..*
0.4
Parámetro
Variable Local
De Campo
Parámetro
Campo

27. Ejemplo: Determinar Dependencias (después)
<<control>>
ControlRegistro
+ // enviar horario()
+ //salvar horario()
+ //crear horario con secciones()
+//getSecciones(porSemestre:Semestre) ListaSecciones
<<entity>>
Estudiante
+ nombre
+ direccion
- carnet : int
+ addHorario(elHorario: Horario, porSemestre: Semestre)
+ getHorario(porSemestre: Semestre) : Horario
+ TienePrerquisitos(laSección: Sección) : boolean
# pasada(laSección :sección) : boolean
<<entity>>
Horario
+enviar()
+salvar()
#existen conflictos?()
+crear con secciones()
-Semestre
<<entity>>
Seccion
- nombre: String = “100”
- horaInicio: Time
- horaFinal: Time
- días : Enum
+ addEstudiante(elHorario : Horario)
+ removerEstudiante(elHorario : Horario)
+ new ()
+ setDatos()
registrante
horarioActual
1
0..*
Cursos Alternos
Cursos Primarios
0..*
0..2
0..*
0.4

28. El manejador Transacción es responsable de administrar toda la
información de cursos.
El curso se crea y salva en la base de datos Plan Estudio. Un
Manejador Transacción es responsable de las interfases con
base de datos.
Existe una clase DBCurso que sabe como salvar la información
pertinente del curso.
Cada curso puede tener entre 3 y 10 estudiantes inscritos y
tiene solo un profesor. Un estudiante se puede inscribir en un
máximo de 4 cursos.
Cada profesor imparte 3 cursos.
Se ejecuta un reporte de la lista de cursos, de profesores y
estudiantes inscritos para las primeras 3 semanas del semestre.
Ejemplo: Diseño de Relación

29. El Modelo antes de Diseño de Relaciones
ControladorPlanEstudio
crearCurso()
ManejadorTransaccion
salvarCurso(Curso)
Sección
Estudiante
DBCurso
salvarCurso(Curso)
Curso
Profesor
1
1 3
3..10
1
0..4
0..*
1 1
1
1..*
1 1
1

30. El ControladorPlanEstudio usa al ManejadorTransacción para
cada Curso que maneja.
La operación crearCurso() no es la única que usa al
ManejadorTransacción.
Se escoge visibilidad de campo.
El ControladorPlanEstudio envía mensajes al
ManejadorTransacción pero el ManejadorTransacción no
envía ningún mensaje al ControladorPlanEstudio.
La relación es uni-direccional ControladorPlanEstudio a
ManejadorTransacción.
Decisiones de Diseño

31. El controladorPlanEstudio crea un curso nuevo dentro de la
operación crearCurso()
Se escoge visibilidad local
A la operación salvarCurso() del ManejadorTransacción se le
pasa un objeto Curso
Se escoge visibilidad de parámetro
El ManejadorTransacción usa un objeto DBCurso para salvar
un objeto Curso
Esta es la única operación que necesita el objeto Curso
Se escoge visibilidad local.
Decisiones de Diseño (cont.)

32. A la operación DBCurso se le pasa un objeto Curso
Se escoge visibilidad de parámetro
Un Curso debe conocer sus estudiantes para generar el reporte
Estos requerimientos no especifican que un Estudiante debe
conocer sus cursos
La relación se hace uni-direccional
Un curso debe conocer su Profesor para generar el reporte
Estos requerimientos no especifican que un Profesor debe
conocer sus cursos
La relación se hace uni-direccional
Decisiones de Diseño (cont.)

33. El Modelo después de Diseño de Relaciones
ControladorPlanEstudio
crearCurso()
ManejadorTransaccion
salvarCurso(Curso)
Estudiante
DBCurso
salvarCurso(Curso)
Curso
Profesor
1
3..10
1

34. La multiplicidad es el número de relaciones entre instancias de
objetos que participan en una asociación de dos clases
Los estimados iniciales de multiplicidad hechos durante el
análisis deben actualizarse y refinarse durante el diseño
A toda relación de asociación y agregación se le debe
especificar la multplicidad.
Diseño de Multiplicidad para Relaciones

35. De la multiplicidad, lo primero que se determina es la opcionalidad de
la relación entre dos clases.
Una relación es opcional cuando la multiplicidad incluye 0
Solo es obligatoria cuando la multiplicidad en ambos extremos es
mayor que 0.
Si una relación es opcional, se debe incluir una operación para probar
la existencia de la relación.
Por ejemplo: si un Profesor puede estar de vacaciones, una operación
acorde debe incluirse en la clase Profesor para probar la relación.
Opcionalidad
Profesor
Impartiendo()
Curso
1 0..*

36. Si hay multiplicidad = 1 o multiplicidad = 0..1
Esta se puede implementar como un valor simple, o un puntero
No se requiere diseño adicional.
Diseño de Multiplicidad
Profesor Curso
0..1 0..*
instructor
• Si hay multiplicidad = 0..* o multiplicidad >1
• No se puede usar un valor simple, o un puntero
• Se necesita diseño adicional
Profesor Sección
0..1 0..*
instructor
Se necesita una
clase contenedora

37. La multiplicidad de más de uno usualmente es diseñada usando
clases “contenedor”.
Una clase contenedor es una clase cuyas instancias son
colecciones de otros objetos.
Los tipos de mecanismos para clases contenedor comunes
incluyen:
• Conjuntos, listas, diccionarios, pilas, colas,....
Las clases contenedor se pueden expresar opcionalmente
como clases parametrizadas, pero no todos los lenguajes las
soportan.
Diseñando Opciones para Multiplicidad de más de Uno

38. Las clases contenedor se pueden modelar explícitamente como
clases de apoyo dependientes del tipo de mecanismo que se use.
Para reducir al aglomeramiento en modelos grandes, las clases
contenedor típicamente no se muestran en los diagramas de clase.
Si el tipo de contenedor se debe especificar (normalmente para
mantener un buen nivel de comunicación), se puede usar una nota
en UML.
Notación para Clases Contenedor
Lista
Seccion Estudiante
3.10

39. Modelación explícita de una clase contenedora
Opciones para Modelar Multiplicidad
Profesor Sección
Lista
instructor
0..1 0..*
• Nota
Profesor Sección
instructor
0..1 0..*
<<entity>>
Profesor
ListaSecciones
0..1
0..1
+ instructor
+ new ()
+ add ()
<<entity>>
Sección
1
0..*

40. Una clase de asociación contiene información que pertenece a
un enlace entre objetos, y no de ninguno de los objetos
involucrados en la relación.
Clases de Asociación
Curso Estudiante
calificación
4 3..10

41. Durante el diseño las clases de asociación evolucionan así:
Transformando la clase de asociación en una clase interpuesta
entre otras dos clases.
Estableciendo asociaciones con la multiplicidad apropiada entre
las clases de asociación y las otras dos clases
La multiplicidad es siempre UNA desde la clase que enlaza a la
clase enlazada
Diseñe las nuevas asociaciones
La navegación puede ser bi-direccional o uni-direccional.
Diseñando Clases de Asociación

42. Diseñando Clases de Asociación (cont.)
Curso Estudiante
Reporte
calificación
1 3..10 4 1

43. Clases de Asociación en Java : Deben Resolverse
class InfoSeccionHorarioPrimarios
{
public InfoSeccionHorarioPrimarios() {}
public SecciongetSeccion() {
return the Seccion;
}
public void setSeccion(Seccion nuevaSeccion){
theSeccion = nuevaSeccion;
}
private char getNota() {return nota;}
private void setNota(char nuevaNota) {nota = nueva nota;}
private char npta = ‘ I ‘ ;
private Seccion theSeccion;
}
Horario
InfoSeccionHorarioPrimarios
- nota : char = I
Seccion
0..* 0..4
0..2
0..*
Cursos Alternos
Horario
Seccion
InfoSeccionHorarioPrimarios
- nota: char = I
1 0..4
InfoSeccionHorariosPrimarios
0..* 1
0..*
0..2
Decisiones de Diseño
cursosAlternos
Cursos Primarios

44. Un calificador es un atributo o grupo de atributos cuyos valores
dividen un conjunto de objetos relacionado con un objeto a
través de una asociación.
Calificadores
Departamento
Profesor
Departamento
IdEmpleado
Título
Profesor
1 1
1 1..*
Dado un objeto Departamento y un
valor para la Id. De Empleado existe
exactamente un objeto Profesor.
Dado un objeto Departamento y un
valor para Título existe un conjunto de
objeto Profesor.

45. Una restricción es una expresión de una condición que debe
preservarse
Una restricción se muestra entre llaves {}
Restricciones
Profesor Departamento
1
1..* 1
1
{es director de}
Es miembro de

46. Durante el análisis, las asociaciones y agregaciones son
relaciones bi-direccionales.
Durante el diseño se pueden convertir en relaciones
unidireccionales.
Las agregaciones se diseñan de dos maneras.
Por valor- los objetos tienen tiempo de vida dependiente.
Por referencia – los objetos tienen tiempo de vida independiente.
Una relación de dependencia significa que una clase depende
de otra clase para un servicio particular.
Examinar la visibilidad de un objeto ayuda a determinar el
diseño de las relaciones.
Resumen: Diseño de Relaciones

47. Opciones de visibilidad incluyen:
Visibilidad global – el objeto está disponible globalmente
Visibilidad de parámetro – el objeto es un parámetro para un método
Visibilidad local – el objeto se declara localmente
Visibilidad de campo – el objeto es parte de la esctructura
Normalmente se usan punteros para implementar la multiplicidad de uno o 0..1
La multiplicidad de más de uno se designa usualmente usando clases
“contenedor”, tales como una Lista o una Fila
Una clase contenedor es una clase cuyas instancias son colecciones de otros
objetos.
Una clase de asociación contiene información que pertenece a un enlace entre
objetos, y no de ninguno de los objetos involucrados en la relación.
Resumen: Diseño de Relaciones