UNIVERSIDAD PRIVADA ANTENOR ORREGO

PROGRAMA DE ESTUDIO DE
INGENIERIA DE COMPUTACION Y SISTEMAS

DOCENTE:
CASTAÑEDA SALDAÑA, JOSE ARTURO

INTEGRANTES:

FERNANDEZ MUGUERZA, ANDY LEE (COORDINADOR)

MELENDEZ QUEZADA, WILDER FABRICIO

QUISPE CESIAS, ANDRO JHOSEP

RODRIGUEZ ACEVEDO, EMERSON RONALDO

CURSO:

PARADIGMAS DE PROGRAMACIÓN

TRUJILLO - PERU
2024
 RELACIONES ENTRE CLASES

Definición

Una relación entre clases es una asociación entre dos o más clases que define cómo interactúan y
colaboran entre sí. Estas relaciones se establecen para representar la estructura y el
comportamiento del sistema de software de manera natural y lógica.

Tipos de Relaciones entre Clases

Existen diferentes tipos de relaciones entre clases, cada una con sus propias características y
aplicaciones. Entre las más comunes encontramos:

1. Asociación:
Es una relación entre dos clases en la que una clase está relacionada con la otra,
pero cada una puede existir independientemente de la otra. (Booch, G. 1998)

2. Agregación:
Es una relación de "todo-parte" entre dos clases, donde una clase es parte de otra
clase, pero ambas pueden existir de forma independiente. ( Gamma, E. 1994)

3. Composición:
Es una relación de "todo-parte" similar a la agregación, pero con la diferencia de
que la parte no puede existir independientemente del todo. (Fowler, M. 2004)

4. Herencia:
Es una relación en la que una clase (subclase) hereda atributos y métodos de otra
clase (superclase). (Jacobson, I. 1992)

5. Dependencia:
Es una relación en la que un cambio en una clase puede afectar a otra clase.
(Rumbaugh, J. 1991)

Asociación

Darel en 2010 nos dio la siguiente definición “La asociación se refiere a una relación entre las
clases (objetos), en donde una instancia de clase origina un mensaje u orden que hace que otra
instancia de clase ejecute alguna acción en nombre de la primera, esta relación se considera
estructurada, porque solo especifica la conexión entre objetos de un tipo y objetos de otro tipo, lo
cual no representa un comportamiento específico”.

En palabras más coloquiales entre estudiantes de programación se podría decir que las “ordenes”
que son emitidas suelen ser “emitir un mensaje” o “invocar un método”, la invocación de estos
usualmente necesita que el objeto que emite la orden, la realice haciendo uso de referencias o
apuntar a la ubicación de memoria en la que está almacenada el objeto que recibe la orden.
(Jhonatan Azuela2017)

A menudo por convencionalismos entre programadores se distinguen los objetos por los roles
que cumplen, por lo tanto, si el objeto permite que otros lo utilicen, seria con el fin de cumplir el
rol que se le fue asignado, un rol hace alusión a las características públicas de un objeto que se
encuentra en asociación.

Figura 1: Asociación de clases

Fuente: Jhonatan Azuela (2017)

Ejemplo textual de asociación.

El secretario usa una tablet-
El cliente usa tarjeta de débito..
 Podemos apreciar que en ambas existe una asociación definida como una relación de uso
entre dos objetos.

Ejemplo de implementación de asociación.

Figura 2: Asociación vs composición

Fuente: Darel (2010)

Composición

Incluiremos el concepto de composición por que se puede comprender como el contrario a

asociación mientras que en la asociación dos objetos colaboran entre sí para cumplir sus roles, en
la composición un objeto está compuesto por otros objetos más pequeños por así decirlo.

Entonces se puede afirmar que la composición es una técnica de programación usada para que
objetos que posean variables instanciadas hagan referencia a otros objetos.
Esta técnica tiene en común con la herencia, que sirve para reutilizar código con la diferencia de
que esta vez el código es más centralizado en un objeto en particular.

Según Jhonatan Azuela en 2017 dice que “La mayoría de veces se prefiere utilizar composición
en vez de herencia ya que, en herencia, la relación es más estrecha con la clase padre, y si esta
llega a cambiar, el objeto podría tener errores en su comportamiento y tendría que ser modificado
de alguna forma, siendo poco eficiente para los programadores; en cambio con la composición,
el objeto contará con variables instanciadas por otros objetos, con lo cual los demás objetos y el
código no tendría que ser modificado, mientras la interfaz no haya sido alterada”.

Otra de las ventajas de la composición sobre la herencia; es que en la herencia obtiene todas las
partes públicas que tenga la clase padre, sin embargo, en la composición, la clase tiene que hacer
referencia explícitamente a los métodos del objeto en cuestión.

Ejemplo de implementación de composición.

Figura 3: Asociación vs composición

Fuente: Darel, 2010

Dependencia

La dependencia de clases, hace alusión al concepto de POO que nos indica la relación que existe
entre dos objetos(Clases), como explícitamente su nombre lo dice , aquí una clase depende de
otra para realizar las funciones que le fueron asignadas. (Zguillez, 2010)
Cuando se trabaja con clases u objetos es normal que realicen una sola función, de esta forma las
clases que deben realizar actividades más complejas son formadas partiendo de una asociación
de clases pequeñas en las que se delegaron funciones. (Zguillez, 2010)

Ejemplo

Figura 4: Dependencia de clases y polimorfismo

Fuente: Zguillez (2010)

En el ejemplo visto anteriormente vemos como en la clase “Foro” se delega la actividad del
método “moderar” al objeto de la clase “Zguillez” haciendo que la implementación esté en en
esa clase dejando sin tanto código la clase principal y a su vez más ordenada; este es un claro
ejemplo donde se permite una mejor reutilización de clases.

Generalización

Al gestionar la complejidad del problema, se usa un orden clasificado de clases, el cual es

posible gracias a la abstracción de la generalización. El concepto de generalización se refiere a la
agrupación de propiedades comunes entre clases, en una clase mas general. Algunos ded los
términos utilizadas en este proceso son “clase padre – clase hija”, “superclase – subclase”, o
“clase base – clase derivada”. Al relacionarse de esta manera, los atributos y operaciones
disponibles de la clase padre son heredadas por las clases hijas. (Nathaly Álava, 2015)

Figura 5: Generalización de clases

Fuente: Nathaly Álava, 2015

Realización

En una relación de realización, una entidad indica una responsabilidad que no lleva a cabo
directamente, sino que la transfiere a otra entidad que sí la ejecuta. Este tipo de relación es
frecuente en el contexto de interfaces, donde una interfaz establece un conjunto de métodos que
deben ser desarrollados por una clase específica. (Alyssa Walker, 2024)

Por ejemplo, consideremos una interfaz llamada `Imprimible` con un método `imprimir()`. Una
clase denominada `Documento` podría implementar esta interfaz al proporcionar su propia
versión del método `imprimir()`. En este caso, la clase `Documento` realiza la interfaz
`Imprimible`, lo que implica que cumple con la responsabilidad definida por la interfaz de contar
con un método `imprimir()`.(Alyssa Walker, 2024)

En un diagrama UML, la relación de realización se muestra con una línea punteada que va desde
la clase que implementa la interfaz hasta la interfaz misma. Esta representación indica que la
clase satisface la interfaz y, por ende, ofrece una implementación específica de los métodos
definidos en la interfaz.
 Figura 6: Realización entre clases
Fuente: InformaticaPC , 2010

Diagrama de Clases

Los diagramas de clases son como mapas que creamos para mostrar las clases en nuestros
códigos y cómo se relacionan entre sí. En estos mapas, cada clase se ve como un rectángulo.
También mostramos cómo las clases se conectan, si una clase hereda de otra, si están asociadas
de alguna manera o si una clase contiene a otra. Estos diagramas nos ayudan a entender mejor la
estructura de nuestro código y cómo las diferentes partes interactúan entre sí. Son una
herramienta muy útil en el diseño y desarrollo de software.

Notación

En una clase podemos representar de forma gráfica, como un rectángulo cortado uniformemente
en tres partes con líneas colocadas horizontalmente.
En la primerea sección, se coloca el nombre de la clase y su estereotipo. En el centro vendría el
nombre de la clase, y se utilizaría cursiva en caso la clase sea abstracta. En caso la clase tuviera
un estereotipo, este vendría a colocarse sobre el nombre, en medio de los símbolos << … >>.
En la segunda sección, se colocaría la lista de características del objeto, o como se conoce
habitualmente, los atributos. Aquí colocamos mas específicamente, el nombre del atributo, el
tipo del atributo, y en caso sea necesario pondríamos también el valor asignado por defecto.
 Figura 7: Notación clases
Fuente: Wondershare, 2024

Asociación Unidireccional: Se trata de una dirección única que se muestra con una línea sólida
que tiene una flecha al final.

Figura 8: Asociación
Fuente: Nuria, 2024

Asociación Bidireccional: Es una relación en ambos sentidos que se muestra con una línea recta
sin flecha.

Figura 9: Asociación Bidireccional

Fuente: Nuria, 2024

Auto asociación: Se muestra con una línea que forma un bucle, donde la flecha apunta hacia la
misma clase.
 Figura 10: Auto asociación
Fuente: Nuria, 2024

Agregación: Se muestra con una línea sólida que tiene un rombo abierto, indicando la parte que
contiene al conjunto.

Figura 11: Agregación

Fuente: Nuria, 2024

Composición: Se muestra con una línea sólida que tiene un rombo lleno, indicando la parte que
forma parte del conjunto.

Figura 12: Composición

Fuente: Nuria, 2024

Dependencia: Se muestra con una línea punteada que tiene una flecha que va desde la clase que
usa hacia la clase de la que depende.

Figura 13: Dependencia

Fuente: Nuria, 2024

Herencia: Se muestra con una línea sólida que tiene una flecha triangular abierta, apuntando
desde la subclase hacia la clase padre.
 Figura 14: Herencia
Fuente: Nuria, 2024

Realización: Se muestra con una línea punteada que tiene una flecha triangular abierta,
apuntando desde la clase que realiza hacia la interfaz.

Figura 15: Realización

Fuente: Nuria, 2024
Visibilidad

Notación habitual:
Nombre: tipo = valor inicial (valor
inicial)
Usualmente, como convencionalismos, la visibilidad puede ser publica definido con un “+”,
privada definida con un “-”, o protegida definida con un “#”, esto puede cambiar dependiendo
del lenguaje en el que estemos programando.
En la tercera y última sección, se muestran las operaciones que la clase puede ejecutar, estas se
ven presentadas con la notación habitual:

En la visibilidad de estas operaciones también podemos identificar las de la segunda sección,

pública, privada o protegida; así como los parámetros que recibe el método, separados por
comas.

En la visibilidad de UML y la programación orientada a objetos. Los modificadores de

visibilidad como público, protegido, privado y paquete controlan este acceso.
 Figura 16: Notación visibilidad
Fuente: Brenda B. 2012

Cardinalidad

Con la cardinalidad se puede conocer cuántas instancias de una clase pueden

aparecer por causa de una relación.
1 --> indica que solo puede haber una instancia.

0..1 --> indica que puede haber cero o una instancia.

n --> indica un número específico de instancias.

n..m --> indica un rango de instancias (varios a varios).

* --> indica que puede haber cero o más instancias.

0..* --> equivale a "cero o más".

1..* --> equivale a "uno o más".
Figura 17: Cardinalidad
Fuente: InformaticaPC , 2010
Referencias Bibliográficas

Cillero, M. (05 de marzo de 2023). Diagrama de Clases. Recuperado el 27 de Abril de

2024, de https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-
clases/

Nuria. (15 de enero de 2024). Guía completa para entender el diagrama de clases UML
básico. (boardmix, Productor) Recuperado el 27 de Abril de 2024, de
https://boardmix.com/es/knowledge/class-diagram/

Darel (14 de julio de 2010). Programación Orientada a Objetos: Asociación vs

Composición. Recuperado el 27 de abril de 2024, de

https://www.cristalab.com/tutoriales/programacion-orientada-a-objetos-asociacion-vs-
composicion-c89337l/#google_vignette

Jhonatan Azuela(2017). Asociación (Programación Orientada a Objetos). Recuperado el

27 de abril de 2024, de
https://hmn.wiki/es/Association_(object-oriented_programming)#google_vignette

Zguillez (09 de Abril de 2009). POO: Dependencia de clases y polimorfismo.

Recuperado el 27 de abril de 2024 de

https://www.cristalab.com/tutoriales/poo-dependencia-de-clases-y-polimorfismo-
c71290l/

Nathaly A. (2015, julio 01). Relaciones entre clases.

https://ingenieriaensoftwarenathalyalava.wordpress.com/2015/07/01/148/

InformaticaPC. (2010). Introducción a la programación orientada a objetos (POO) y

UML.

https://informaticapc.com/poo/uml.php

Booch, G., Rumbaugh, J., & Jacobson, I. (1998). Análisis y Diseño Orientado a Objetos
con Aplicaciones.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Patrones de diseño: elementos
de software reutilizable orientado a objetos.

Fowler, M. (2004). UML Distilled: Una breve guía del lenguaje estándar de modelado
de objetos (3ª ed.).

Jacobson, I. (1992). Ingeniería de software orientada a objetos: un enfoque basado en

casos de uso.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Modelado y
Diseño Orientado a Objetos.

Wondershare. 2024. Diagramas de clases UML.

https://www.edrawsoft.com/es/article/class-diagram-relationships.html

Brenda B. (2012, noviembre 30). Diagrama UML y Programación Orientada a Objetos

https://brendabalderas.wordpress.com/2012/11/30/diagramas-uml-y-programacion-
orientada-a-objetos/