language agnostic - Relaciones UML-línea discontinua vs línea sólida

language-agnostic relationship

Question

¿Cuál es la diferencia entre estas 2 relaciones?

Editar: ¡También si pudieras proporcionar un ejemplo de código simple que ilustrara la diferencia, eso sería realmente útil !.

Answer 1

De acuerdo, ya que no aceptaste la primera respuesta; Déjame intentarlo.

Flecha 1: una asociación normal

UML tiene diferentes tipos de líneas y flechas. Arriba está la flecha de asociación simple, eso significa que una clase puede tener un enlace a la otra clase. A continuación explicaré cada tipo CON ejemplos de código.

• En el primer ejemplo, puede ver que no se especifica quién sabe quién (quién es el propietario de la relación). Un animal PUEDE conocer al humano y el humano PUEDE conocer al animal. No está especificado y, por lo tanto, no es realmente útil para el programador.
• En el segundo ejemplo, el artista PUEDE tener una guitarra. Debido a que hay una flecha y no hay una en el otro lado, sabemos que la guitarra no conoce al artista. Una guitarra es un objeto que puede existir totalmente por sí mismo y no necesita a nadie.
• En el tercer ejemplo, ves un matrimonio. Realmente simple; el marido conoce a la esposa y la mujer conoce a su marido. En nuestra situación, el esposo tiene una sola esposa y viceversa.

¿Cómo lo hacemos usualmente en el código?

class Husband{
    Wife bestWomanInTheWorld;

    public Husband(Wife theWife){
        this.bestWomanInTheWorld = theWife;
    }
}

Debido a que el esposo SIEMPRE necesita una esposa, ponemos la relación REQUERIDA en el constructor. Como un artista PUEDE tener una guitarra, dejamos el constructor vacío así:

class Artist{
    List<Guitar> guitars;

    public Artist(){
    }

    public AddGuitarToCollection(Guitar newGuitar){
        Guitars.Add(newGuitar);
    }
}

Entonces, así es como logramos esto en código (¡la mayoría del tiempo!). Normalmente no necesitará diferentes tipos de líneas y flechas si es nuevo en la programación. Mantenlo simple.

Arrow 2: Dependencia

De acuerdo, entonces sabemos sobre asociaciones normales que usaremos la mayor parte del tiempo. ¿Pero cuándo usaremos la flecha de ''dependencia''? Bueno, definamos una dependencia (wikipedia):

Dependency is a weaker form of bond which indicates that one class depends on 
another because it uses it at some point in time. One class depends on 
another if the independent class is a parameter variable or local variable of 
a method of the dependent class. This is different from an association, where 
an attribute of the dependent class is an instance of the independent class. 
Sometimes the relationship between two classes is very weak. They are not 
implemented with member variables at all. Rather they might be implemented as 
member function arguments.

Si hay una conexión, relación, asociación, etc. que requiere estar presente, para que la clase A funcione; es una dependencia Ejemplo: el esposo NECESITA que la esposa exista. Un automóvil NECESITA una rueda para ser un automóvil (y conducir). Una fábrica de automóviles NECESITA una clase de automóvil para fabricar un objeto a partir de ella. Su clase RSSNewsItem NECESITA una clase XMLReader para hacer cualquier cosa.

¿Cuándo usar qué?

Bueno, esta es la única pregunta válida en mis ojos; ya que Google muestra muchas respuestas válidas a tu pregunta. Intente nunca usar una dependencia en un diagrama de clases porque generalmente significa que no es lo suficientemente específico. Siempre apunte a asociaciones, realizaciones, etc. Utilice solo realizaciones (en mi opinión) si se requiere usar otra clase sin mantener una relación. Ejemplo; Clases de utilidad (como el XMLReader).

Si tiene alguna pregunta después de leer esta explicación completa, siéntase libre de preguntar. :-)

Answer 2

Estoy tratando de dar ejemplos simples de los dos tipos de líneas.

En el primer diagrama, la línea continua muestra una asociación:

Si las clases se declararon en Java, esto sería como ClassA almacenando una referencia a ClassB como un atributo (podría pasarse al constructor, crearse, etc.). Entonces, es posible que vea algo como:

public class ClassA {
    ClassB theClassB = ...
    ...
}

En el segundo diagrama, muestra una dependencia:

Una dependencia es mucho más débil que una asociación. Para citar de UML destilado:

Con las clases, las dependencias existen por varias razones: una clase envía un mensaje a otra; una clase tiene otra como parte de sus datos; una clase menciona a otra como un parámetro para una operación. [...] Usas dependencias siempre que quieras mostrar cómo los cambios en un elemento pueden alterar otros elementos.

Nuevamente, usando Java, existen algunos ejemplos: un argumento de tipo ClassB se pasa a un método, o un método declara una variable local de tipo ClassB :

public class ClassA {
    ...
    public void someMethod(ClassB arg1) {...}
    ...
    public void someOtherMethod() {
        ClassB localReferenceToClassB = ...
    }
    ...
}

Otras formas en que ClassA podría depender de ClassB sin tener una asociación (no una lista exhaustiva):

• ClassB tiene un método estático que ClassA llama
• ClassA excepciones de tipo ClassB
• Siempre que se modifique ClassA , ClassA también debe modificarse (por ejemplo, se comparte alguna lógica)

Answer 3

La línea punteada indica dependencia a (en la dirección de la flecha). Asumiendo que ha ensamblado su código fuente ordenadamente en archivos y encabezados separados para cada clase, el regalo es simplemente que el código incluye la línea #include ClassB.h.

SIN EMBARGO El hecho es que todas las relaciones de clase (generalización, realización, composición, agregación, asociación, etc.) heredan la relación de dependencia. Por esta razón, nunca utilizo flechas de puntos al documentar el código. Siempre que sea posible, intentaré documentar la relación en términos más específicos, p. Ej. diamantes, triángulos, etc. Si no conozco la relación exacta, mi punto de partida es una línea continua con flechas (una asociación, con dependencia (implícita)).

A pesar de esto, la notación de la flecha punteada puede ser útil en otros aspectos del modelado UML, por ejemplo. mostrando dependencias a los requisitos en el análisis de caso de uso, por ejemplo. NOTA: La Policía del Pensamiento nos haría reducir el acoplamiento y las dependencias entre clases mediante el uso de interfaces (clases virtuales puras) en la medida de lo posible.

Mientras que las clases virtuales puras ofrecen la posibilidad de herencia múltiple y el acoplamiento más estrecho de todas las clases, como es posible. Las clases de interfaz tienen la ventaja de que están hechas completamente de materia oscura y son totalmente invisibles para la policía. Con esto en mente, es posible escribir código c ++ con un aparente cero acoplamiento entre clases, que les encanta porque de todos modos nunca entendieron todos esos símbolos de aspecto divertido.

Answer 4

Tu pregunta me dio una buena oportunidad de aprenderme a mí mismo, esto es lo que encontré:

Asociación : Propiedad de otro tipo (por ejemplo, ''A'' posee una ''B'')

//@assoc  The Player(A) has some Dice(B)
class Player {
    Dice myDice;
}

Dependencia : uso de otro tipo (por ejemplo, ''C'' usa ''D'')

//@dep    The Player(C) uses some Dice(D) when playing a game
class Player {
    rollYahtzee(Dice someDice);
}

Aquí hay una refinada ref que encontré: Asociación vs. Dependencia

Answer 5

instrumentos de medias punteadas (una interfaz) sólidos significa extensiones (una clase base)

Answer 6

Esta página web dice lo suficiente, creo: http://www.classdraw.com/help.htm El siguiente texto proviene de él, pero debería ser suficiente para entender la diferencia, creo.

Entonces, básicamente, la línea continua es una asociación y la línea punteada / punteada es una dependencia.

Las asociaciones también pueden ser unidireccionales, donde una clase sabe sobre la otra clase y la relación, pero la otra clase no. Dichas asociaciones requieren una punta de flecha abierta para apuntar a la clase que se conoce y solo la clase conocida puede tener un nombre de rol y multiplicidad. En el ejemplo, la clase Cliente sabe sobre cualquier cantidad de productos comprados, pero la clase Producto no sabe nada sobre ningún cliente. La multiplicidad "0 .. *" significa cero o más.

Una dependencia es una relación débil entre dos clases y está representada por una línea de puntos. En el ejemplo, existe una dependencia entre Point y LineSegment, porque la operación draw () de LineSegment usa la clase Point. Indica que LineSegment tiene que saber sobre Point, incluso si no tiene atributos de ese tipo. Este ejemplo también ilustra cómo se usan los diagramas de clase para enfocarse en lo que es importante en el contexto, ya que normalmente no se desea mostrar tales dependencias detalladas para todas las operaciones de su clase.

Como mi reputación es solo 8, no puedo ubicar las imágenes, pero aún pueden encontrarse en la página web que mencioné al principio.

[EDITAR]

No tengo ejemplos de código aquí, pero cómo lo explicaría personalmente es tan simple como un auto y una puerta.

Cuando un automóvil tiene una puerta (o más) es solo un automóvil

Car --- has a --> Door

Pero cuando tienes una puerta que se puede abrir, la clase de puerta tendrá una función como

public void openDoor(){
this.open();
}

Para usar la función anterior, el automóvil tendrá que crear una instancia de la puerta

Class Car(){
Door door1 = new Door();

door1.open();
}

De esta forma, ha creado una dependencia.

Entonces, la línea continua solo señala un objeto (1) a otro objeto (2), pero cuando comienzas a usar el objeto (1) se convierte en una dependencia.

Espero que esto haga;)