Relaciones entre clases.

Publicado por el 9/07/2016. Categoría: Análisis y Diseño Orientado a Objetos

Hola amig@s! ¿Cómo están? Siguiendo el hilo del post anterior, donde vimos una pequeña introducción a UML, hoy veremos las relaciones que existen entre clases (si no sabes qué es una clase puedes ir al post “Conceptos básicos y pilares de la Programación Orientada a Objetos (POO)”).

Como bien sabemos las cosas en la vida real se relacionan de alguna forma, por ejemplo, un profesor está relacionado con un curso y con una universidad. Y de la misma forma que en la vida real sucede en la orientación a objetos. Las clases no existen de manera aislada, sino que están relacionadas de una u otra forma. En la orientación a objetos existen tres tipos de relaciones especialmente importantes: dependencias, que representan relaciones de uso entre clases; generalizaciones, que conectan clases generales con sus especializaciones y asociaciones, que representan relaciones estructurales entre objetos.

DEPENDENCIA

Las dependencias son relaciones de uso (una usa la otra). Por ejemplo, un curso depende de un profesor que lo imparta.

Gráficamente las relaciones de dependencia se representan con una línea discontinua dirigida hacia el elemento del cual se depende.

dependencia

Dependencia representada con la notación de UML

 

GENERALIZACIÓN

Una generalización es una relación que conecta clases generales con otras más especializadas, en lo que se conoce como relaciones subclase/superclase o hijo/padre. Por ejemplo, un profesor es un tipo de persona que tiene nombre, apellido, edad, etc. A menudo (no siempre) el hijo añade atributos y operaciones diferentes a los de su clase padre.

En otras palabras, la generalización es la relación de herencia que existe entre una clase padre y una clase hija, por lo tanto, la clase hija hereda los atributos, propiedades y métodos de la clase padre.

Gráficamente, la generalización se representa con una línea dirigida continua, con una gran punta de flecha vacía, apuntando al padre, como podemos ver en la siguiente imagen.

herencia

Herencia representada con la notación de UML

 

ASOCIACIÓN

Una asociación es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro. Esta relación expresa la navegabilidad y la multiplicidad entre las clases asociadas.

Gráficamente una asociación se representa como una línea continua que conecta la misma o diferentes clases. Las asociaciones se utilizan cuando se quiere representar relaciones estructurales.

En las relaciones de asociación tenemos ciertos elementos o adornos que se agregan, estas son:

Nombre: Que es utilizado para describir la naturaleza de la relación. Para que no exista ambigüedad en el significado se puede dar una dirección al nombre mediante una flecha que apunte en la dirección que se lea el nombre, por ejemplo:

asociacion

Asociación con nombre representada con la notación de UML

Rol: El nombre del rol identifica el rol específico que juega en la asociación. Se puede nombrar claramente el rol que juega una clase en una asociación. Es mejor usarlos cuando son realmente necesarios para explicar mejor el diagrama.

Por ejemplo, siguiendo con el diagrama anterior, podemos decir que una “Persona” trabaja para la “Universidad” pero esa sería la asociación básica, entonces si especificamos el rol de cada una de las clases, la clase “Persona” juega el rol de “Profesor” que está asociado con una “Universidad” que juega el rol de “Rector”. Veámoslo gráficamente:

asociacionRoles

Asociación con roles representada con la notación de UML

Multiplicidad: Muestra la cantidad de objetos que pueden conectarse a través de una instancia de una asociación. Podemos dar una multiplicidad de uno (1), cero o uno (0 . . 1), muchos (0 . . *), o uno o más (1 . . *). Incluso podemos indicar un número exacto (por ejemplo, 4).

asociacionMultiplicidad

Asociación con multiplicidad representada con la notación de UML

 

Agregación: Este tipo especial de asociación es cuando queremos modelar una relación en la cual una clase representa una cosa grande, que consta de elementos más pequeños. En simples palabras, podemos decir que la agregación pretende describir que un objeto del todo consta de objetos más pequeños que son parte del “todo”. Entonces cuando queramos modelar con este tipo de relación podemos pensar que el “objeto todo” -> “tiene un” -> “objeto parte del todo”. La agregación es una relación débil, que quiero decir, que, si el objeto “todo” deja de existir, el objeto “parte” no deja de existir, por lo tanto, no existe una dependencia del objeto parte hacia el objeto todo. Por ejemplo, una “Facultad” no deja de existir si la “Universidad” no existe, hay Facultades que funcionan sin ser parte de una Universidad.

Gráficamente se representa con un rombo vació en la parte del todo como podemos ver en la siguiente imagen:

agregacion

Agregación representada con la notación de UML

Explicando un poco el ejemplo anterior, podemos decir que una clase “Facultad” es parte de una clase “Universidad”, ya que en una universidad puede haber Facultad de Ingeniería, de Medicina, de Diseño, entre otras.

Composición: Esta relación es una variación especial de la agregación, lo que hace que sea diferente es que la relación que existe entre una clase “todo” y una clase “parte” es fuerte, es decir, que la clase parte no existe si la clase todo no existe. Por ejemplo, en un “Auto”, un “Motor” especifico, pertenece exactamente a un “Auto” y al crear un “Motor” hay que asignarlo a un “Auto”. Lo mismo pasa si destruimos el “Auto”, éste debe a su vez destruir su parte “Motor”. Lo podemos ver en la imagen a continuación:

composicion

Composición representada con la notación de UML

Bueno amig@s eso ha sido todo por hoy, espero que les sirva esta información. Y como siempre digo muchas gracias a todos por leer, comentar y compartir. ¡Espero sus comentarios! ¡Saludos! 🙂

cc
Los textos e imágenes de este sitio están disponibles bajo una licencia Creative Commons Atribución 2.5 Argentina.

Puedes compartir nuestro post en los siguientes medios:

Emi Garin es una programadora y diseñadora web apasionada por las nuevas tecnologías y el constante aprendizaje. Estudió analista y programador superior de sistemas y le encanta la cocina y la pastelería.

  1. Excelente entrada, muy bueno el blog. Saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *