Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Varios (https://www.clubdelphi.com/foros/forumdisplay.php?f=11)
-   -   Relaciones UML: Asociación y dependencia (https://www.clubdelphi.com/foros/showthread.php?t=63631)

noob 23-02-2009 22:25:56

Relaciones UML: Asociación y dependencia
 
Hola, me gustaría saber si estoy en lo cierto.

Yo cuando veo una clase de este tipo digo que hay relaciones UML de asociación:

Código Delphi [-]
TClase = class
               private
                 Atributo1: TClase2;
                 Atributo2: TClase3;
               public
             end;

TClase tiene una relación de asociación con TClase2 y con TClase3.

Ahora, cuando veo una clase de este otro tipo digo que hay relaciones de dependencia:

Código Delphi [-]
TClase = class
               private
                 Atributo1: Integer;
                 Atributo2: String;
               public
             end;

implementation

uses uClase2;

procedure TClase.Procedimiento;
var
  Clase2: TClase2; // TClase2 es una clase de la unt uClase2
begin
  Clase2 := TClase2.Create; // Relación de dependencia (TClase ---> TClase2)
end;

¿Estoy en lo cierto?

Saludos.

AzidRain 24-02-2009 01:58:01

De acuerdo completamente, TClase en el segundo ejemplo depende de TClase2, por lo que cualquier cambio en TClase2 afectará el comportamiento de TClase, de manera que TClase es el elemento dependiente y TClase2 el independiente. Obviamente los cambios en TClase no afectan a TClase2.

En el caso de la asociación se trata de elementos que son mutuamente dependientes, es decir, el uno no puede existir sin el otro por decirlo de alguna manera, por ejemplo un objeto TCuaderno debe tener THojas, obviamente el cuaderno se puede quedar sin hojas pero aun asì requiere de aquellas para ser un cuaderno, por el otro lado las hojas requieren un cuaderno. De ahí el término asociación.

Acoto: Todo el trabajo que se realiza en UML es completamente independiente del código por lo que la implementación real de cada concepto puede variar ligeramente a veces incluso varia entre programador y programador, sin embargo la colección de diagramas de esta herramienta permite mantener cierta coherencia entre el todo. De manera que puede haber interpretaciones que diferentes ante un mismo diagrama, sin embargo UML garantiza que al final el resultado sea el correcto.

noob 24-02-2009 07:45:16

Muchas gracias AzidRain.

Delphius 24-02-2009 14:59:18

Si me lo permiten, creo que hay que aclarar algo, una asociación puede ser de agregación de composición o agregación compartida.

El concepto de agregación de composición o comunmente llamado a secas, composición (en UML se lo identifica con el rombo relleno o pintado) implica una relación de dependencia absoluta, las partes no pueden existir sin el Compuesto puesto que es éste último quien las crea.
En una composición se da por establecido que el tiempo de vida de las partes depende en exclusiva del Compuesto: El Compuesto y las partes existen mientras exita el Compuesto.

La agregación compartida, (que en UML se la representa con el rombo hueco) o simplemente llamada agregación, implica una asociación en la que tanto el Compuesto como las Partes no tienen una relación de dependencia extricta. Ambos tienen tiempos de vida independientes, por tanto uno puede vivir sin el otro. Y además, la parte Puede estar presente en muchas instancias de un Compuesto: es decir que se rompe la depedencia extricta de que una Parte le pertenece a un Compuesto.

No se si he entendido bien, pero me parece que AzidRain ha mezclado ambos conceptos.

Ahora bien, existe otro concepto relacionado con el término asociación: la clase asociación. La clase asociación se emplea, haciendo analogía con las bases de datos, para romper la relación mucho-mucho entre dos entidades. Vendría a ser como la tabla intermedia.
Básicamente la clase asociación establece asociaciones entre una clase y otra de forma que en ésta se establezca el atributo vinculante en la relación.

Dado el código de noob no podemos inferir que se trate de agregación, ni composición; si podemos afirmar que existe una relación o vínculo, de algún tipo no establecido o reconocido, entre dichas clases.
No se puede afirmar que existe una asociación, en todo caso existe una relación.

El concepto asociación, que yo sepa, implica el concepto de Compuestos y Partes (ya sea de composición o compartida), y por tanto de como se empleen dichos atributos o campos privados. Una asociación implica una dependencia, pero a la inversa, una dependencia no implica una asociación.

La dependencia como bien menciona AzidRain, establece que una clase A, depende de otra clase B puesto que A debe diseñarse para responder apropiadamente al diseño e implementación de B; mientras A haga uso de B existirá una dependencia. En el caso del ejemplo de noob, TClase es la clase dependiente y TClase2 es la independiente.

Al menos eso es lo que yo tengo entendido, si estoy equivocado les agradecería que me señalacen mis errores (u horrores:D:().

Saludos,


La franja horaria es GMT +2. Ahora son las 03:51:04.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi