Diferencia dependencia y asociacion, UML

[sterlingdiazd]

Saludos, me gustaria saber cual es la diferencia que establece java para la dependencia y la asociacion.

Osea, como puedo reconocer en codigo cuando se trata de una dependencia y cuando es asociacion.

[chuidiang]

Hola:

Una asociación es un concepto general de UML para indicar que dos clases están asociadas, sea como sea. La dependencia es un caso específico de asociación, igual que agregación, composición y herencia.

Normamente en una etapa temprana del diseño cuando no se quiere todavía profundizar en detalles se usan asociaciones en general. Cuando se quiere entrar en el detalle, ya se va identificando cada asociación de qué tipo es.

Se bueno.

[sterlingdiazd]

Saludos Chuidiang!

Pensaba que este tema quedaria sin respuesta, y me responde Chuidiang!
Gracias por responder y por todos tus aportes en tu pagina. Han sido de gran ayuda para mi mientras comenzaba a aprender Java, sobretodo la forma sencilla de explicar a pesar de saber tanto. (No muchos tienen esa capacidad o simplemente quieren aparentar que saben tanto que tu ni los puedes entender).

Por lo que entendi, en una diagrama detallado y completo de UML, habran dependencia, agregaciones o composiciones.

Tengo una duda relacionada con lo anterior, el siguiente codigo es parte del constructor de la clase ControlForm. Aqui se instancia la clase PersistenceManager, y esa es usada para obtener los objetos de la clase Categorias. Todo eso se hace en el constructor de la clase ControlForm.

Código java:

public ControlForm(Component parent) {
 
manager = new PersistenceManager();
List<Categoria> categorias = manager.getCategorias();
Categoria tmp = new Categoria();
 
}
 

Entiendo que la relacion que tiene ControlForm con PersistenceManager es una dependencia, y que Categorias tiene una relacion de agregacion, pero no se si es con el PersistenceManager, que se usa para obtener las categorias, o si ControlForm directamente.

Este es el metodo del PersistenceManager que obtiene las categorias.

Código java:

public List<Categoria> getCategorias() {
 
        CriteriaQuery cq = em.getCriteriaBuilder().createQuery();
        cq.select(cq.from(Categoria.class));
        Query q = em.createQuery(cq);
 
        return q.getResultList();
}
 

[chuidiang]

Hola:

No hay una relación clara y directa entre el tipo de asociación y cómo se codifica, cada lenguaje tiene sus trucos y UML pretende ser universal. El criterio que yo aplico, que creo que es más o menos estándar aunque como te digo no hay nada estandar, es lo siguiente:

Herencia: Está claro, class A extends B.

Composición: Una clase es atributo de la otra, se le hace new en el constructor y necesita estar ahí siempre. Por ejemplo, A está compuesta de B y C.

Código java:

public class A {
   B b = new B();
   C c;
   public A () {
      c = new C();
   }
}
 

es el caso de una ventana con un botón. El botón se crea junto a la ventana y está toda su vida ahí.

Agregación: Una clase es atributo de la otra, pero puede ser null o no instanciarse siquiera

Código java:

public class A {
   B b = null;
   C c;
   public A () {
      c = null;
   }
   public void otroMetodo(B unaB) {
      b = unaB;
      c = new C();
   }
}
 

La diferencia entre agregación y composición está mucho más clara en C++, donde se podría hacer así

Composición: B b; // Se declara la clase
Agregación: B *b; // Un puntero.

Dependencia: Una clase utiliza a otra, pero no como atributo. O bien se la pasan como parámetro de un método (y no loa guarda en ningún atibuto de la clase) , o bien la instancia como variable local de un método.

Código java:

public class A {
   public void otroMetodo(B unaB) {
      int a = unaB.unMetodo();
      C c = new C();
      a = c.otroMetodo();
   }
}
 

En tu caso, yo diría con ControlForm está "compuesto" por PersistenceManager (lo instancia en el constructor y se lo guarda como atributo de la clase) y depende de Category (lo usa, pero lo guarda en variables locales del constructor).

A su vez, ControlForm depende de Category (hasta donde se ve en el código), ya que lo usa pero no se lo guarda en ningún atributo.

Se bueno.

[sterlingdiazd]

Muchisimas Gracias. Esto me aclaró las dudas que tenia.

[sterlingdiazd]

Tengo otra pregunta, y creo k si estoy equivocado trabajaria como 800 veces menos.

Digamos que ControlForm tiene una composicion con PersistenceManager y dependencia de Categoria. Cuando yo vaya a conectar la clase Categoria, debo crear otra fecha que se conecte con ControlForm, y cuando vaya a conectar las clases relacionadas con PersistenceManager, debo conectarlo con una composicion con ControlForm?

[sterlingdiazd]

Tengo un programa bastante grande para hacerle el diagrama UML, cualquier que pudiera aclararme esa tal vez tonta pero importante duda, se lo agradeceria.

[chuidiang]

Hola:

No debes perder el objetivo de UML. La idea no es plasmar en un diagrama UML exactamente todo lo que tienes en código, para eso está el código. En UML debes hacer varios diagramas (incluso del mismo tipo) de forma que en cada uno de ellos expliques a alguien algún aspecto concreto de tu código y sólo pongas lo necesario para explicar eso que quieres explicar. Debes siempre pensar qué quieres explicar y a qué tipo de persona (un desarrollador, un jefe de proyecto, un cliente, tu profesor) y en función de eso hacer el o los diagramas necesarios para explicar eso concreto a esa persona.

En tu caso, si reflejas todo

ControlForm composicion con PersistenceManager
ControlForm dependencia de Category
PersistenceManager dependencia de Category

pero como te digo, no suele tener mucho sentido reflejar TODAS las dependencias de TODAS las clases (salvo que seas el diseñador, alguien te lo vaya a codificar después y no quieras dejarle absolutamente nada a su imaginación). ¿Qué estás intentando explicar en el UML que tienes?

Si intentas reflejar un esquema de dependencias entre clases, no es necesario poner la dependencia de ControlForm con Category, ya que al depender (composición) ControlForm de PersistenceManager, depende indirectamente de todo lo que depende PersistenceManager, así que se puede sobreentender.

Si quieres hacer hincapié en que ControlForm trata con entidades tipo Category (porque las muestra en pantalla por ejemplo), entonces sí debes poner esa dependencia.

Se bueno

[sterlingdiazd]

Gracias de nuevo Chuidiang. Lo que intento hacer es un esquema de dependencias entre clases para el profesor. Ya veo que no necesito plasmar todas las dependencias indeirectas.

[chuidiang]

Ten cuidado

Ahí debes saber de qué pie cojea tu profe. Igual es un "detallista" y quiere que le pongas todas. Como te digo, no hay una forma 100% correcta de hacerlo, depende mucho de lo que se quiera expresar y del que lo vaya a leer.

Se bueno.

[Acertijo-007]

Para explicar las diferencias voy a suponer que tengo dos clases A y B que poseen una relación de Dependencoa y también otra relación de Asociación.

Yo las diferencio basándome en los siguientes criterios

Definición

a) Dependencia (linea punteada con punta de flecha: Es una relación semántica entre dos clases, en la cual una utiliza el funcionamiento de la otra para realizar su tarea (ver patrón de diseño DELEGATE).

b) Asociación Bidireccional (linea continua sin punta de flecha): Es una relación estructural más fuerte que la dependencia. Relaciona a los objetos de forma bidireccional, creando una dependencia mutua entre ellos.

c) Asociación Unidireccional (linea continua con punta de flecha): igual que el anterior pero se establece una dependencia en un solo sentido


Acoplamiento

a) Dependencia: La clase A depende de la clase B, por lo que un cambio en la clase B podría afectar el funcionamiento de la clase A, no así a la inversa. A pesar de esto, se dice que es una dependencia débil, ya que el tiempo en el que los objetos de ambas clases están relacionados, sólo dura mientras se ejecuta el método en que el objeto A usa a B para realizar la tarea especifica.

b) Asociación Bidireccional: Ambas clases dependen de la otra, y por todo el tiempo de vida de sus objetos, por lo que esta relación tiene un acoplamiento mayor que la relación de dependencia.

c) Asociación Unidireccional: Los objetos de la clase A, que depende de los objetos de la clase B, está acoplados durante toda su vida, por lo que el acoplamiento es mayor al de la relación de dependencia y menor que la asociación bidireccional porque en este caso sólo una clase es dependiente.

Visibilidad

a)Dependencia: La clase A conoce a la clase B y puede llamar a sus métodos, la clase B en cambio no sabe de la existencia de la clase A

b) Asociación Bidireccional: ambas clases conocen a la otra y pueden llamar a sus métodos

c)Asociación Unidireccional: En este sentido igual a la dependencia.

Implementación (Tu respuesta)

a) dependencia: Se puede implementar de dos formas: La Clase A hace uso de la Clase B instanciándola directamente dentro de un método, o bien, recibiéndola como parámetro de entrada en uno de sus métodos. Ejemplo:

Instanciación dentro de un método

public void cualquierMetodo(){
ClaseA a = new ClaseA();
a.unMetodo();
}

Recibiendola como parámetro

public void cualquierMetodo(ClaseA a){
a.unMetodo();
}

b) Asociación Bidireccional: Tanto la clase A como la clase B incluyen entre sus atributos un objeto de la otra clase (Aquí es donde está la diferencia en el código), a diferencia de la dependencia en donde la clase B no forma parte de los atributos de la clase A. Ejemplo:

public class ClaseA {
private ClaseB b;
.....
}

public class ClaseB{
private ClaseA a;
.....
}

c) Asociación Unidireccional: Sólo la clase A incluye dentro de sus atributos a la clase B


IMPORTANTE: Nótese que en ningún caso he incluido colecciones de objetos, ya que en tal caso cuando la asociación posee multiplicidad 0..1...n a muchos pasamos a un caso especial de asociación que puede ser agregación, en el caso que el objeto contenido deba ser compartido por otros objetos (multiplicidad muchos a muchos) o que éste no sea necesario para la instanciación del objeto de la clase contenedora (multiplicidad 0 a muchos); o Composición cuando el objeto contenido sólo pueda pertenecer a un contenedor (1 a muchos) y sea requerido para crear al contenedor (1 a muchos)

Como puedes ver sí existen diferencias visibles en el código.

Casi se me olvida. También existen diferencias en como diseñar la base de datos dependiendo si es dependencia, asociación unidireccional, asociación bidireccional, agregación y composición. Te lo dejo como dato ya que ese es tema para otro post.