2009-07-17 9 views
8

He estado usando UML por un tiempo y he leído algunos artículos, libros, foros al respecto, pero todavía no entiendo REALMENTE cuando dos clases deben conectarse con la línea de asociación (una línea simple o flecha (¿o no son lo mismo?)). Proporcionaré tres ejemplos: ¿puede decirme cuál hará que las dos clases estén en esta relación?UML problema de comprensión de asociación

1.

//a field of OtherClass 
    public class MainClass 
    { 
     private OtherClass other; 
    } 

2.

//method argument 
    public class MainClass 
    { 
     public void Action(OtherClass other) 
     { } 
    } 

3.

//method return value 
    public class MainClass 
    { 
     public OtherClass Action() 
     { } 
    } 

4.

//used inside a method 
    public class MainClass 
    { 
     private Something something; 

     public void Action() 
     { 
      OtherClass other = something.GetOtherClass(); 
     } 
    } 

Respuesta

0

Me suelen utilizar dos diferentes conectores en UML:

  1. Cuando una clase depende de la implementación de otra. Esto implicaría que una clase está creando o manejando una instancia de otra. Entonces, la clase de llamada depende de la clase de implementación. Esto sería evidente en todos sus ejemplos.

  2. Cuando una clase extiende o implementa otra.

+0

Entonces, ¿qué conectores usa en cada caso? –

4

Editar: Reescribió respuesta tras su debate en los comentarios (gracias a Chimp para señalar lo que me daba en el Ejemplo 4)

Ejemplo 1: OtherClass es un atributo de MainClass, y por lo tanto se modela como una asociación.

Ejemplos 2 y 3: OtherClass se hace referencia dentro de la definición de clase, aunque no se almacena dentro de un atributo, por lo tanto, es una dependencia.

Ejemplo 4: La clase Something es un atributo y, por lo tanto, una asociación, mientras que OtherClass hace referencia, que no está almacenado en un atributo, por lo que es una dependencia.

Dentro de UML, las dependencias y asociaciones son ambos tipos de relación y no están estrictamente relacionadas (excepto a través de un supertipo común), aunque en mi opinión una asociación implica una dependencia.

Las asociaciones se indican mediante una línea entre las 2 clases con multiplicidades en cada extremo. La navegabilidad se indica con flechas que muestran qué clase conoce (por ejemplo, Clase A ___> Clase B significa que A tiene conocimiento de B, pero no al revés), la navegabilidad en ambas direcciones se muestra con flechas en ambos extremos. Donde no hay flechas, generalmente es más seguro no hacer suposiciones sobre la navegabilidad a menos que se establezca en otra parte.

Las dependencias se indican mediante una línea discontinua con una flecha de la clase dependiente (cliente) a la clase de la que depende (proveedor) (Ej. A ----> B significa que A depende de B). Las dependencias muestran que una clase se referencia en algún momento, y como tal, el cliente depende de las operaciones proporcionadas por el proveedor, pero no indica cómo se hace referencia (a diferencia de una asociación que sugiere una referencia almacenada en un atributo).

+0

bien, pero ¿no está consciente la clase de las clases proporcionadas como argumentos? ¿Y está seguro de lo que está diciendo, porque estoy buscando una respuesta "esto es lo que dice la teoría, fin del tema"? – agnieszka

+0

hmm, probablemente podría decirlo un poco: el viaje de la mente al teclado no siempre es fácil, y creo que he perdido algo de sentido en el camino. Las asociaciones se expresan como atributos. Es aceptable mostrar asociaciones en UML de la misma manera que los tipos de datos primitivos, pero el uso de las líneas de conexión suele ser más informativo. Me temo que no puedo pensar en una explicación para mostrar por qué los argumentos a los métodos no constituyen una asociación (que no sea "porque no lo hacen", lo que no es una explicación en absoluto). Pero, independientemente, estoy seguro de que esto es correcto. – chrisbunney

+0

Por cierto, siempre guardo una copia de UML Distilled a mano cuando trabajo con UML, me parece una muy buena referencia: http://www.martinfowler.com/books.html#uml – chrisbunney

6

En primer lugar, una flecha representa navegabilidad de la asociación.La flecha individual significa relación unidireccional, en este caso solo la clase de origen conoce la clase de destino. La flecha en ambos extremos significa relación bidireccional, donde ambas clases se conocen entre sí. Si no hay flechas, la asociación puede ser bidireccional por defecto o suprimida en aras de la legibilidad. En la práctica, debe dibujar flechas solo cuando desee enfatizar la dirección de la asociación.

Cuando se trata de su segunda pregunta, solo el primer caso describe una asociación (unidireccional) entre MainClass y OtherClass. Ni los argumentos ni los valores de retorno implican asociación en el sentido UML (aunque ambos implican dependencia). En el último ejemplo, existe una asociación entre MainClass y Something clase a través del atributo something. Como regla general, debe buscar asociaciones en los atributos.

Tenga en cuenta que existe un concepto de dependency en UML y se representa mediante una línea discontinua.

Pozdrowienia!

+0

Eso lo resume todo . +1 – Randolpho

1

Una asociación representa a dos o más propiedades relacionadas.

En el ejemplo 1, MainClass tiene una propiedad de tipo OtherClass. Si OtherClass tiene una propiedad explícita de tipo MainClass, entonces habrá una asociación bidireccional entre la clase; si OtherClass tiene una propiedad implícita de tipo MainClass (es decir, no hay ningún atributo, pero la relación puede derivarse trabajando en la otra dirección), entonces habrá una asociación unidireccional de MainClass a OtherClass.

En los ejemplos 2, 3 y 4, MainClass no tiene ninguna propiedad de tipo OtherClass. Sin embargo, depende de OtherClass, por lo que habría una relación de dependencia de MainClass a OtherClass. En el código esto está representado por un usando o #include.