sábado, septiembre 27, 2008

UML Relaciones, Composicion, Agregacion, Asociacion, Dependencia, Generalizacion, Realizacion



Trabajando con los miembros de mi team de desarrollo me di cuenta que a los programadores le costaba interpretar los Diagramas de Clases que el analista realizaba. O existían interpretaciones ambiguas de lo que el realizaba, perdiendo asi la principal funcionalidad del lenguaje UML. Especialmente en cuanto a las relaciones que existían entre las clases. Por eso me dispuse a realizar este pequeño documento, donde voy a tratar de explicar que significa cada relación, en mis palabras, y como se traduce esto a código.
Asociación:
Es generalmente, una relación estructural entre clases, es decir, que en el ejemplo, existe un atributo de la clase medio de transportes, que es del tipo Conductor. La navegalidad nos muestra donde esta ubicado el atributo. Es decir cual es la clase que tiene contiene el atributo si ésta no lo mostrase. La multiplicidad en una Asociación dice bastante, ya que de eso dependerá si el atributo, es una colección o simplemente una variable de referencia a un objeto.
Agregación:
Es una relación que se derivó de la asociación, por ser igualmente estructural, es decir que contiene un atributo, que en todos los casos, será una colección, es decir un Array, Vector, Collections, etc, y además de ello la clase que contiene la colección debe tener un método que agregue los elementos a la colección. También se puede leer como que un medio de transporte tiene varios pasajeros.
Nos esta diciendo que los objetos pasajero forman parte del objeto medio de transporte. Pero, su ciclo de vida no esta atado al del objeto medio de transporte. Es decir si el Autobus se destruye los pasajeros pueden seguir existiendo independientemente, ( o por lo menos por eso rezaríamos)
Composición
Al igual que en la agregación, es una relación estructural pero se le suma, que tiene un método de destrucción de los objetos. Y a diferencia de la asociación, el ciclo de vida del objeto area está relacionado con el del objeto ruta. Es decir que si la ruta de viaje se levanta, las áreas que surgían a partir de ella desaparecen. También se puede leer como que una ruta tiene varias áreas de cobertura.
Mucho se ha discutido a cerca de las agregaciones y las composiciones, el debate es casi tan caliente como el de los include y extends de los casos de uso. Ya que algunos sostienen que los lenguajes orientados a objetos, tienen garbage collector, por lo que no necesitan métodos de destrucción de los objetos (relacionados a los ciclos de vida en la compocición). Y que la programación es la misma para las composiciones y las agregaciones, y que la diferencia es meramente conceptual entre una y otras. Es mas existen varias interpretaciones, pero la expuesta es a la cual yo adhiero.
Clase de Asociación
Es una Clase que surge de una multiplicidad de muchos a muchos, y fue incorporada en UML para dar soporte a este caso. Se sacan los atributos de las clases involucradas y se los incorpora a una clase a parte. Al igual que las anteriores hace referencia a una relación estructural. En el ejemplo son los objetos viaje y ruta
Realización
Es una relación de contrato con otra clase. Se la utiliza para implementar una interfaz. En lenguajes como java o php utilizamos la palabra reservada “implements”
public class Viaje implements Registrable{…}
Generalmente cuando no estamos seguros si “algo” es una interfaz o una clase abstracta, por que dibujaron los tag que hacen referencias a las interfaces, debemos ver la relación para saber.
Generalización
Es una relación de herencia. Se puede decir que es un relación “es un tipo de” ( IS-A ). En nuestro ejemplo: “un Autobus es un tipo de Medio de transporte”. Es entre una clase hija y su clase madre. En la codificación podemos encontrar la palabra “extends” que hace referencia a esta relación. Además podemos encontrar palabras claves tales como “this” y “super” ( Java ) o "self" y “parent” ( PHP ). Para darnos cuenta que existe una relación de este tipo involucrada.
public class Autobus extends MedioDeTransporte{…}
Dependencia
Es una relación de uso, es decir que una clase utiliza a otra. Y si esta ultima se altera, la anterior se puede ver afectada.
En código se suelen traducir principalmente como las clases donde se hace la instanciación de un objeto. En nuestro ejemplo la clase Viaje realiza los “new” de los distintos objetos. En este momento puede que te preguntes como puede hacer un new de una clase abstracta, jeje. No realiza los new de la clase abstracta, si no de sus hijas. Seria algo así como
MedioDeTransporte medio = new Autobus();
También se sostiene que este tipo de relación hace referencias, a los parámetros que se pasan en un método, bajo este concepto, en java, podría ser algo así como:
public void crearViaje(MedioDeTransporte medio){}
Por ultimo también se sostiene que podemos codificar esta relación realizando un “return” del tipo de dato en algún método.
Bueno espero haber limpiado algunas dudas, hay mucho para discutir sobre el asunto.
Saludos team.
Acá les dejo otro ejemplo, un poco más complejo y con los métodos de cada una de las clases para ser más especifico.
Anl. Ariel Diaz Molina.
Mas información sobre UML en la etiqueta Diseño.

65 comentarios:

Servicios avanzados de comunicacion dijo...

Buenisimo! Gracias maestro, me viene al pelo para el parcial.... jejeje Saludos

aro dijo...

jeje... suerte en tu parcial. Me olvide en el apunte del diagrama de clases, escribir sobre las responsabilidades que tienen los repocitorios en el caso de las compociciones, pero eso sera tema de otro post.

Blog de Karin dijo...

HOLA, MUY BUENA LA INFO !

Y UNA DUDA ACERDA DE ASOSIACION Y COMPOSICION ...¿Qué diferencias deberíamos tener en cuenta al implementarlas?

GRACIAS!

SALU2

KARINA

aro dijo...

tanto la asociacion como la compocicion son relaciones estructurales. En cuanto a la implementacion tendremos que la clase que asocia tendra una variable del tipo asociado. Mientras que la clase que es compuesta tendria una coleccion, o array o algo asi. Ademas un metodo para agregar objetos a esa coleccion, y un metodo para destruirlos. Ademas en cuanto a arquitectura se habla de las "responsabilidades de creacion" es decir que puede tener un metodo donde haga un new de los objetos que lo componene

Oscar Daniel Villarraga Castro dijo...

Interesante, Gracias

Anónimo dijo...

Hola

Publicaste un post muy valioso pero seria genial si pudieras poner las equivalencias de los terminos a ingles, se que eres de España y supongo que alla es mas comun encontrarlo como lo escribiste pero para latinoamerica es mas facil utilizar los terminos en ingles. Saludos

aro dijo...

Nop soy argentino. y voy a postear mi opinion sobre los terminos.
Saludos.
Gracias.

Anónimo dijo...
Este blog ha sido eliminado por un administrador de blog.
TuringMX dijo...

No conocía la relación Clase de Asociación. Tu blog es interesante.

Anónimo dijo...
Este blog ha sido eliminado por un administrador de blog.
aro dijo...

Sep, esta forma de representar una clase es bastante nueva, en realidad me parece que lo hicieron más para generar un macheo con el modelo relacional, en fin. Otro deuda de los digrmas de clases, son las nested class, que todavia no han unificado creiterios ya veremos en un futuro.
Saludos

Anónimo dijo...

¡MUCHAS GRACIAS POR LA INFO!

aro dijo...

;)

Anónimo dijo...

Buena info, hermano. Gracias.

Jose Antonio Escribano Ayllon dijo...

Buenas amigo!

Buen post! Mucha gente no entiende las diferentes funciones que realizan los actores en UML. Yo mismo tenia una ligera duda.

Gracias por resolverla.
Seguire tu blog a menudo, te animo a que le eches un vistazo al mio :)

Saludos!

aro dijo...

Thx, me daré una vuelta! saludos

Anónimo dijo...

Muy buena la info, pantallazos generales como estos sirven para unir los pedazos de conocimiento desparramados que tenemos los inexpertos.
Gracias.

Saludos

aro dijo...

Thx, gracias por los comentarios! saludos

Anónimo dijo...

tuve que utilizar mozilla para poder leer tu pagina y poder desactivar el css ya que por si no lo sabias es espantoso leer una pagina con fondo negro y letras blancas, lastima la vista, el estandar es usar fondo blanco y letras negras.

Anónimo dijo...

Te queria preguntar, cuando hablas de una relacion de vida en la composicion lo que la diferencia en la agregacion. Te referis de vida de un objeto o por el contrario conceptualmente de la realidad, o sea una matricula con un auto, o un pie con una pierna.
Gracias

aro dijo...

Anonimo 1:
no te gusta firefox? Heee... estandar???? no la verdad no conocia el "estandar"... en fin.. es un template de blogspot y me gusta.. :) por ahi lo cambio en el futuro ... (o no je).
Anonimo 2:
je, bueno... nice question! en cuanto a la relacion con el ciclo de vida que tiene en la compocicion, todo dependerá de tu modelado. Por supuesto que siempre deberia tener relación con la realidad. Yo no elegiría una compocicion para los dos ejemplos que mencionas, podria ser una asocioacion pura con alguna restriccion. Matricula (entiendase, por la patente) existe sin el auto...(es una chapa con un numero)... es mas bien una relacion conseptual algo asi como una Universidad y sus Departamentos (organizacion administrativa), o sea los departamentos de la universidad no existirian... si la universidad no existe. Saludos

Anónimo dijo...

buenisima info, al fin lo pude entender!
Gracias!!

rolo dijo...

Muy util y clara la info, gracias master. buen post!

Radamanthys17 dijo...

buenisimo entonces lo podemos diferenciar agregacion y composicion en que la composicion es una relacion mas fuerte.como los departamentos de la universidad que sin la universidad no existen.

muy claro gracias.

aro dijo...

gracias gente! un abrazo

Anónimo dijo...

Muy interesantes y aclaratorios tus comentarios, me sirviero mucho realmente. Saludos desde Mendoza, Argentina!

yola dijo...

muy interesante... :) gracias por compartir tus conocimientos!

aro dijo...

Anonimo: la idea es compartir conocimiento, y debatir algunas ideas sobre esto. Me alegro que te haya servido! un abrazo a mi argentina querida! se la extraña!
Yola:
;)

manols dijo...

felicitaciones!! muy buena publicación

aro dijo...

De nada Manols!

oswaldo dijo...

Hola amigo, tengo una duda que diferencia habría en una relación de dependencia y una relación de agregación o composición, cuando se que es una y es otra puesta que para esos tres tipos una consituye parte de la otra

cote dijo...

Tengo una gran duda...
Parece conveniente creer que hay que usar agregacion/composicion cuando se trata de una coleccion... pero... existe algo que se llama cardinalidad... a lo que voy es que existes asociaciones que no son de agregacion/composicion que pueden terner una relacion de 1 a muchos (o sea que se guarda en una lista).

No se si me explico, pero seria algo asi, ejemplo:

(clase auto)1------------->1..*(clase configuracion)

1..* = uno o mas.
------> = flecha de asociacion
(clase) = clase

aro dijo...

Existen varios artículos escritos sobre este tema en mi blog, y estoy seguro que en alguno de ellos debo haber comentado lo que tu me estas diciendo. Es así, La agregación y la composición, no tienen que ver con una variable de instancia, o de clase, que sea una "colección", ( eso es condición necesaria, pero no suficiente ). Si no más bien, con la responsabilidad que se tiene, a la hora de agregar un elemento a esa colección. Si deseas puedes repasar los otros post, ahi lo explico mejor. Saludos y buen código!

aro dijo...

Oswaldo, a grande rasgos una relación de dependencia, es una relación de "uso" mientras que la agregación y la composición son relaciones "estructurales", las dos ultimas, tendrían variables de instancia o de clase, mientras que la primera seria un "new" comun y corriente dentro de la clase en algún lado. Si quieres, le puede dar una vuelta a los otros post, donde veras ejemplos con codigo, y teorico. Saludos

Unknown dijo...

Tengo una observación Lic Ariel Diaz ,en el ejmplo 4 nos muestras un ejemplo en UML y la duda se encuentra en las relaciones Persona y medio de transporte ,porque en el diagrama dices que es una asociación ? Yo veo que persona esta creando una lista de medios de transporte,esto me hace pensar que es una composición no una asociación? según la descripción de asociación y composición que nos compartes.Y tambien aprovecho para felicitarte me limpiaste muchas dudas que tenia ..actualmente estoy estudiando para una certificacion de SJCA y estamos viendo estos temas..gracias

aro dijo...

Yamil primero que todo, gracias por lo de licenciado, en mi equipo nunca me llaman por mi titulo de graduación (Aprendan los del team!! jeje)En segundo lugar, todo va a depender del modelo que quieras transmitir. Pero por sobre todas las cosas de la RESPONSABILIDAD, que le quieras asignar a esa clase. Si crees que la case debe ser responsable por crear las instancias de medio de transporte ( método add que no recibe parámetro ), sería una COMPOSICIÓN, si crees que debe ser responsable por agregar los elementos a la lista (un método add que recibe un parámetro), seria una AGREGACIÓN, pero si la tomas como una variable más de la clase, a la lista, entonces, debería ser una ASOCIACIÓN. Todo dependerá de la responsabilidad que le asignes a la clase Persona.
Saludos

Anónimo dijo...

Felicitaciones me ha aclarado bastante el panorama, aunque tengo una inquietud

La relación entre Ruta y Area es de composición pero en la respuesta a la pregunta anterior (de Yamil Delgado) dice que es de composición si tiene un metodo add sin argumentos y en el diagrama se vé que el metodo agregarArea(Area unArea) recibe un objeto tipo Area, lo que me hace pensar que es una relación de agregación, me podría explicar por favor

aro dijo...

Yamil, perdón se me fue la hoya, jeje. Bien detectado, el gráfico tiene un bug! cuando es COMPOSICIÓN = sin parametros, AGREGACIÓN = con parametro. Ya que en el metodo add de la composición, es donde se va a manejar el ciclo de vida, en cambio, al recibirlo por parametro en al asociacion, otra clase crea el new del objeto, y se la pasa a esta por parametro. Ciclo de vida nace en otro lado.
Saludos. Ya veré de cambiar el gráfico. Gracias por tu aporte

Roman dijo...
Este comentario ha sido eliminado por el autor.
Unknown dijo...

Excelente aporte! Si no te molesta lo voy a compartir.. saludos.

Anónimo dijo...

me gustaria ver ejemplos de cada relacion pero implementado en codigo de c++ =)

Unknown dijo...

me gustaria saber si tienes el codigo para poder probarlo en netbeans y si tanbien puedes poner las herncias

Marisol dijo...

hasta que por fin encontre una muy buena explicaciòn. Muchas gracias en pocas lineas aclare muchas cosas.

aro dijo...

Maximiliano, gracias por el reconocimiento, y no hay problema comparta tranquilo... saludos

aro dijo...

c++? mmm not for now folks! jaja

aro dijo...

Pato, la verdad que según veo este post no tiene el código, pero por ahí hay post del mismo tipo que tienen el código fuente y que te podrían servir

aro dijo...

Marisol, Yes! ese fue el espíritu de escribir estos post por que a mi me sucedía lo mismo de estudiante y de profesional. Saludos

Anónimo dijo...

self no es lo mismo que this, en php también existe this. Es para atributos o funciones estáticas.

Anónimo dijo...

Una profesión es divertida cuando además es tu aficción.

Anónimo dijo...

necesito dos ejemplos de cada tipos de relacion de generalizacion composicion agregacion dependencia navegabilidad en enterprise y java ayuda porfavor

Unknown dijo...

Hola, una consulta. En una clase de Asociación (PRÉSTAMO), por ejemplo entre LIBRO y SOCIO_BIBLIOTECA: Modelando de esta manera, no podría un SOCIO tener más de un PRÉSTAMO de un mismo LIBRO (en distintos momentos)? Para eso debería relacionar de SOCIO a PRÉSTAMO y de éste u último a LIBRO?. Muy buen aporte. Saludos !!!

Unknown dijo...

Me encanta lo bien que expones y relacionas todo

aro dijo...

Si, así es, this existe en PHP. por eso digo... algunas palabras a modo de generar un ejemplo no de enumerar todos los casos. Saludos.

aro dijo...

Si, la profesión es algo interesante, en mi siempre me ha apacionado la programación y el software, pero a veces tengo temor de que esto me temrmine por cansar. Saludos.

aro dijo...

Si +ALFREDO FEDERICO DUARTE, por eso la clase Prestamo, ademas de Libro y Socio debería tener una variable del tipo temporal, (Calendar por ejemplo). Eso haría la diferencia entre un prestamo y otro. Y si tienes algún ORM como hibernate, le podrias agregar otra variable que sea idPrestamo. Y otras tantas, que hagan singular a tu prestamo, como un descuento por ejemplo. Saludos

aro dijo...

Gracias Lourdes Sánchez Redondo, lamentablemente no tengo tanto tiempo como me gustaría para escribir sobre esto que nos gusta a todos. Saludos.

Unknown dijo...

Disculpa. Que significa relación estructural?

Unknown dijo...

Oye cuando hablas de la relaciones que derivan de asociación(agregación o composición), ¿a que te refieres con relación estructural?, es a caso que una clase tiene contenida no solo un atributo, sino una colección, arreglos o listas dinamicas de esa clase

JR. dijo...

Y en cuanto a los patrones GRASP y GOF como seria. Por ejemplo en el GRASP cuál es el experto, creador, bajo acoplamiento, alta cohesión y el controlador. y en el GOF cuál de estos 3 se adecúa mejor, en los creacionales en los estructurales o los comportamientos. (del mismo diagrama de clases).

kevin1998 dijo...

Ufffff que buena información​ me has salvado, eres un Dios generoso :'v

Anónimo dijo...

Me vino bien esta información para cuando ves el diagrama de clases para entenderlo mejor, además la manera en que la explicas un saludo y gracias por aportar este conocimiento

aro dijo...

Muchas gracias, gente. A ver, si puedo volver a escribir algo uno de estos dias. Sí, tienen algun tema favorito, o alguna duda, sobre lo que escribir, dejenlo en los comentarios.
Saludos

Fabián Leonardo Salva dijo...

Excelente Blog!!!! Felicitaciones!!!

nidia_pinto dijo...

Hola!! me puede clarar sobre el ejemplo 4 ¿que representa en aspectos generales el modelo, que clases y atributos componen?

Anónimo dijo...

Hola, porque no habría una relación de agregacion hacia las butacas?