Programa de

Ingeniería de
Sistemas

Programaci
ón
Orientada a
Objetos
Sesión 2

Tema:
Relación de Dependencia
Resultado de aprendizaje Evidencia de aprendizaje

Construye programas usando conceptos básicos de Informes académicos individuales de relación de

programación orientada a Objetos. dependencia
Contenido
Relación de Dependencia

• Dependencia por visibilidad local.

• Dependencia por visibilidad de
parámetro
• DRY (principio de no repetir
código).
• Notación grafica con UML
(diagrama de clases).
• Casos de estudio
• Guía de Practica de Laboratorio02:
Relación de Dependencia
Revisa el
siguiente
video:
Después de haber visualizado el video en la slide
anterior, reflexionamos y respondemos las
siguientes interrogantes:

01 ¿Qué han visto? ¿Qué opinan?

¿Qué es una relación de dependencia en programación

02
orientada a objetos?

¿Qué medidas se pueden tomar para gestionar eficazmente

03 las relaciones de dependencia en un sistema de software?
 Tema
Relación de
dependencia
Programación Orientada a Objetos– Sesión 2

Dependencia (Definición)
Programación Orientada a Objetos– Sesión 2

Dependencia (Notación)
Programación Orientada a Objetos– Sesión 2

Dependencia (Implementación)
Programación Orientada a Objetos– Sesión 2

Dependencia (Implementación)
Autoevaluación
Sesión 1
 ¿Qué es una relación de dependencia en programación orientada a
objetos?

Una relación donde una clase es una instancia de otra clase.

Pregunta 1

Una relación donde una clase utiliza los servicios de otra clase.

Una relación donde una clase hereda propiedades y comportamientos de otra clase.

Una relación donde una clase contiene instancias de otras clases.

 ¿Cuál de las siguientes afirmaciones describe mejor una relación de
dependencia?

Una relación donde una clase es una subclase de otra clase.

Pregunta 2

Una relación donde una clase tiene una instancia de otra clase.

Una relación donde una clase usa una instancia de otra clase para realizar alguna función.

Una relación donde una clase contiene una colección de instancias de otras clases.
 ¿Cuál es la característica principal de una relación de dependencia en
programación orientada a objetos?

Facilita la reutilización de código.

Pregunta 3

Promueve la encapsulación de datos.

Introduce acoplamiento entre clases.

Simplifica la jerarquía de clases.

 ¿Cuál es el principal desafío de manejar relaciones de dependencia en el
diseño de software?

Maximizar el acoplamiento entre clases.

Pregunta 4

Minimizar el acoplamiento entre clases.

Evitar completamente el uso de relaciones de dependencia.

Limitar el uso de herencia en el diseño de clases.

Autoevaluación
¡Vamos por más logros!

¡Felicitaciones!
Ha concluido la autoevaluación
 Las relaciones de dependencia son un
Conclusiones

aspecto crucial del diseño de software

en POO. Un manejo adecuado de
estas dependencias es esencial para
construir sistemas robustos, flexibles
y fáciles de mantener. Al minimizar
las dependencias innecesarias y
seguir principios de diseño sólidos,
podemos crear sistemas más
escalables y extensibles en el largo
plazo.
Diagrama de Clases
Son los diagramas más comunes en el modelado de sistemas
orientados a objetos.

El diagrama de clase representa clases, sus partes y la forma en la que

las clases de los objetos están relacionados con otro.

Son importantes no sólo para visualización, especificación y

documentación de modelos estructurales, sino también para construir
sistemas ejecutables.
Ejemplo de Diagrama de Clases

Los diagramas de clases proporcionan una perspectiva estática del

sistema (representa su diseño estructural)
Pasos para realizar el diagrama de clases
Identificar las clases.
Mostrar los atributos y operaciones (posteriormente).
Dibujar asociaciones.
Etiquetar asociaciones y en caso necesario los roles.
Indicar multiplicidad.
Dibujar fechas de dirección
Partes de un Diagrama de Clases
Clases:
Atributos
Métodos
Visibilidad
Relaciones:
Asociación
Composición
Agregación
Dependencia
Generalización
Clase
Es la unidad básica que encapsula toda la información de un Objeto (un
objeto es una instancia de una clase). A través de ella podemos
modelar el entorno en estudio (una Casa, un Auto, una Cuenta
Corriente, etc.).

En ellos se ponen el nombre, los atributos, las operaciones y además se

pueden usar para anotar otras propiedades del modelo como son
(reglas del negocio, responsabilidades, excepciones, etc.)
Clase: Notación Gráfica
En UML, una clase es representada por un rectángulo que posee tres
divisiones:
Ejemplo
La clase automóvil que posee como
característica: El diseño asociado es:
Matrícula
Color.
Velocidad.
Puede realizar las operaciones de:
Arrancar
Acelerar
Frenar
Visibilidad
public (+) : Cualquier clase externa puede usar la característica.
protected (#) : Cualquier descendiente de la clase usa la característica.
private (-) : Sólo la clase misma puede usar la característica.
Relaciones entre clases
Las relaciones existentes entre las distintas clases nos indican cómo se
comunican los objetos de esas clases entre si.
Los mensajes “navegan” por las relaciones existentes entre las distintas
clases.
Existen distintos tipos de relaciones:
- Asociación (Conexión entre clases).
- Dependencia (relación de uso).
- Generalización/especialización (relaciones de herencia).
Tipos de Relaciones

1.- Relación de Asociación

1.1.- Asociación de Agregación

1.2.- Asociación de Composición

2.- Relación de Dependencia

3.- Relación de Generalización

Asociación
• Una asociación en general es una línea que une dos o más símbolos. Pueden tener

varios tipos de adornos, que define su semántica y características. Los tipos de

asociaciones entre clases presentes en un diagrama estático son:

• Asociación binaria, asociación reflexiva, asociación n-aria, agregación, composición

• La asociación expresa una conexión bidireccional entre objetos. Una asociación es una

abstracción de la relación existente en los enlaces entre los objetos. Puede

determinarse por la especificación de multiplicidad (mínima...máxima)

Multiplicidad

Determina cuantos objetos de cada tipo intervienen en la relación.

El número de instancias de una clase que se relacionan con UNA instancia de la otra
clase

Cada Asociación tiene dos multiplicidades (una para cada extremo de la relación).

Cuando la multiplicidad mínima es CERO, la relación es opcional.

Una multiplicidad mínima mayor o igual que UNO establece una relación obligatoria.
Tipos de Multiplicidad
Dirección
• 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.

• En el ejemplo siguiente el tipo de flecha en la asociación implica que desde el objeto

Reservación puedes recuperar (dirigirte hacia) el objeto Cliente. También implica que del

objeto Cliente puede recuperar el juego de reservaciones para ese cliente.

Asociación Binaria
• Una asociación binaria se representa mediante una línea sólida que une dos clases, se trata de
una relación entre las dos clases no muy fuerte, es decir, no se exige dependencia existencial ni
encapsulamiento.
Asociación Reflexiva

Una clase puede asociarse con sí misma. Una clase Empleado

puede relacionarse con sí misma a través del rol gerente/dirige.

No significa que una instancia está relacionada consigo misma,

sino que una instancia de la clase está relacionada con otra
instancia de la misma clase.
 Ejemplo

Nota:
Una instancia de Empleado puede ser el jefe de otras instancias de Empleado. Como el rol
subordinado tiene una multiplicidad de 0…*, significa que puede tener o no tener otros
empleados a quien dirigir.
Una instancia de Empleado tiene un sólo jefe o ninguno (en caso de ser el mismo jefe).
Asociación N-aria
• Es una forma de expresar una relación entre tres o más clases.
La clase de asociación es dependiente en existencia de las otras
clases.
 Asociación de Composición
• Es un tipo de relación fuerte, el objeto agregado no puede existir de forma independiente.

• Agregación disjunta y estricta: Las partes sólo existen asociadas al compuesto (sólo se accede a ellas

a través del compuesto).

• Gráficamente, se muestra con un rombo lleno en uno de los extremos (compuesto).

Ejemplo
Asociación de Agregación
• Es un tipo de relación débil, el objeto agregado puede existir de forma
independiente.

• Las partes pueden forma parte de distintos agregados.

• Gráficamente, se muestra con un rombo vacío en uno de los extremos.

Ejemplo
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 un servicio.

• Servidor es el objeto que provee el servicio solicitado.

• Un cambio en un elemento (el elemento independiente) puede afectar a la

semántica del otro elemento (elemento dependiente).

• Gráficamente, la dependencia se muestra como una línea discontinua
con una punta de flecha que apunta del cliente al proveedor.

Clase dependiente Clase independiente

Video Televisión

... Canal ...

... ...
Grabar(c : canal) cambiar(c : canal)
Generalización

• Es una relación entre dos clases en donde una de ellas, llamada subclase o clase hija,
hereda los atributos y el comportamiento de otra, llamada superclase o clase padre.

• En una generalización no hay multiplicidad ni roles.

• Las subclases heredan características de las clases de las que se derivan y añaden características
específicas que las diferencian.

• La visibilidad “protected” permite que solo objetos de la misma clase ó subclase

vean el elemento.
Representación Gráfica:

Clase hija Clase Padre

Vehículo

Terrestre Aéreo

camión auto avión helicóptero

Interfaces
• Una interface no es una clase.

• Una clase tiene una instancia de su tipo, mientras que una interface debe tener al menos
una clase para implantarla. En UML, una interface es considerada como una especialización
de una clase.

• Una interface se dibuja como una clase, pero en el compartimento superior del rectángulo
aparece un texto ó una inicial que indica que se trata de una interface y no de una clase.

• Se representan como clases pero con el estereotipo <<interface>>.

• Solo contienen operaciones públicas.

Ejemplo

En el diagrama anterior las clases Professor y Student implementan a la

interface Person y no heredan de ésta, podemos deducirlo a partir de:
1) El objeto Person de acuerdo a la simbología del diagrama está como una
interface y Professor y Student están como clases.
2) No se trata de herencia ya que la línea con la flecha está punteada y no
sólida.
Clase Abstracta
• Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto
indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han
sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que
implementan los métodos abstractos definidos.
Aplicando lo
aprendido:

Resolver la guía de Laboratorio N° 2

 JOYANES, Luis: Programación En Java Algoritmos Programación
Orientadas A Objetos E Interfaz Gráfica De Usuario [en línea].
México: Mc Graw Hill, 2011. ISBN 9786071506184. Disponible en:
Referencias

https://ucv.primo.exlibrisgroup.com/permalink/51UCV_INST/175ppoi/
alma991001051429707001