Relations UML - ligne pointillée vs ligne continue

Cette page web en dit assez, je pense: http://www.classdraw.com/help.htm Le texte qui suit en est issu mais devrait suffire à comprendre la différence que je pense.

donc en gros la ligne pleine est une association et la ligne pointillée/pointillée est une dépendance.

les Associations peuvent aussi être unidirectionnelles, où une classe sait l'autre classe et la relation, mais pas l'autre classe. Ces associations ont besoin d'une arrowhead pour pointer vers la classe qui est connu et seule la classe connue peut avoir un nom de rôle et multiplicité. Dans l'exemple, la classe de Client sait à propos de tout nombre de produits achetés, mais la classe de produits ne sait rien sur tout client. La multiplicité " 0..*" signifie zéro ou plus.

une dépendance est une relation faible entre deux classes et est représentée par une ligne pointillée. Dans l'exemple, il y a une dépendance entre le Point et le segment de ligne, parce que LineSegment du tirage au sort() de l'opération utilise la classe des Points. Il indique que LineSegment doit savoir Point, même s'il n'a pas d'attributs de ce type. Cet exemple aussi illustre les diagrammes de classes sont utilisés pour se concentrer sur ce qui est important dans le contexte, comme vous ne voudriez pas normalement montrer détaillée des dépendances pour toutes vos opérations de classe.

comme ma réputation n'est que de 8 Je ne peux pas placer les images elles-mêmes, mais elles peuvent encore être trouvées sur la page Web I mentionné au début.

[EDIT]

Je n'ai pas d'exemple de code ici, mais la façon dont je l'expliquerais personnellement est aussi simple qu'une voiture et une porte.

Quand une voiture a une porte (ou plus) c'est juste une voiture

Car --- has a --> Door

Mais quand vous avez une porte qui peut être ouvert la classe door aura une fonction comme

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

utilisation De la fonction au-dessus de la voiture pour créer une instance de la porte

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

door1.open();
}

De cette façon, vous avez créé une dépendance.

donc la ligne continue pointe juste un objet(1) vers un autre objet(2), mais quand vous commencez à utiliser l'objet (1) cela devient une dépendance.

j'espère que ça va le faire ;)

j'essaie de donner des exemples simples des deux types de lignes.

Dans le premier diagramme, la ligne continue montre une association:

si les classes étaient déclarées en Java, ce serait comme ClassA stocker une référence à ClassB comme attribut (il peut être passé au constructeur, créé, etc.). Donc, vous pourriez voir quelque chose comme:

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

Dans le deuxième diagramme, il montre une dépendance:

une dépendance est beaucoup plus faible qu'une association. Pour citer UML Distilled:

avec les classes, les dépendances existent pour diverses raisons: une classe envoie un message à une autre classe; une classe en a une autre comme partie de ses données; une la classe en mentionne un autre comme paramètre d'une opération. [...] Vous utilisez dépendances chaque fois que vous voulez montrer comment des changements dans un élément pourrait modifier d'autres élément.

encore une fois, en utilisant Java, quelques exemples existent: un argument de type ClassB est passé à une méthode ou une méthode déclare une variable locale de type ClassB:

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

d'Autres moyens ClassAdépendentClassB sans avoir une association (liste non exhaustive):

• ClassB possède une méthode statique qui ClassA appelle
• ClassA captures exceptions de type ClassB
• Quand ClassB est modifié, ClassA doit aussi être modifié (par exemple, une certaine logique est partagée)

la ligne pointillée indique la dépendance à (dans la direction de la flèche). En supposant que vous avez assemblé votre code source proprement dans des fichiers et des en-têtes séparés pour chaque classe - le give away est simplement que le code inclut la ligne # include ClassB.h.

malgré cela, la notation par des flèches pointillées peut être utile pour d'autres aspects de la modélisation UML, par exemple: montrer les dépendances aux exigences dans l'analyse de cas D'utilisation par exemple. Notez que la police pense que nous devrions réduire l'accouplement et les dépendances entre les classes à l'aide des interfaces (pur classes virtuelles) dans la mesure du possible.

tandis que les classes virtuelles pures offrent la perspective d'un héritage multiple et d'un couplage le plus étroit possible entre toutes les classes. Les cours d'Interface ont l'avantage d'être entièrement faits de matière noire et donc totalement invisibles pour la police. Avec cela à l'esprit, il est possible d'écrire du code C++ avec apparemment zéro couplage entre les classes-qu'ils aiment parce qu'ils Je n'ai jamais vraiment compris tous ces symboles drôles de toute façon.

OK, puisque vous n'avez pas accepté la première réponse, laissez-moi essayer.

Flèche 1: une association normale

UML a différents types de lignes et de flèches. Ci-dessus est la flèche d'association simple, qui signifie qu'une classe peut avoir un lien avec l'autre classe. Ci-dessous, je vais expliquer chaque type avec des exemples de code.

• Dans le premier exemple, vous pouvez voir qu'il n'y a pas vraiment spécifié qui sait qui (qui est le propriétaire de la relation). Un animal PEUT connaître l'homme et l'être humain PEUT connaître l'animal. Il n'est pas spécifié et donc pas vraiment utile pour le programmeur.
• dans le second exemple, l'artiste peut avoir une guitare. Parce qu'il y a une flèche et qu'il n'y en a pas de l'autre côté, on sait que la guitare ne connaît pas l'artiste. Une guitare est un objet qui peut totalement exister tout seul et qui n'a besoin de personne.
• Dans le troisième exemple, vous voyez un mariage. Vraiment simple; le mari connaît la femme et la femme connaît son mari. Dans notre situation, le mari n'a qu'une femme et vice versa.

comment procédons-nous habituellement en code?

class Husband{
    Wife bestWomanInTheWorld;

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

parce que le mari a toujours besoin d'une femme, nous mettons la relation requise dans le constructeur. Parce qu'un artiste PEUT avoir une guitare, nous laisserait le constructeur vide comme ceci:

class Artist{
    List<Guitar> guitars;

    public Artist(){
    }

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

donc, c'est ainsi que nous accomplissons ceci en code (la plupart du temps!). Vous n'aurez généralement pas besoin de différents types de lignes et de flèches si vous êtes nouveau dans la programmation. Garder les choses simples.

Flèche 2: Dépendance

D'accord, donc nous connaissons les associations normales que nous utiliserons la plupart du temps. Mais quand utiliserons-nous la flèche "dépendance"? Eh bien, définissons une dépendance (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.

S'il y a une connexion, une relation, une association, etc. cela exige d'être présent, de travailler pour la classA; c'est une dépendance. Exemple: le mari a besoin de la femme pour exister. Une voiture a besoin d'une roue pour être une voiture (et conduire). Une usine automobile a besoin d'une classe de voiture pour en faire un objet. Votre classe RSSNewsItem a besoin d'une classe XMLReader pour faire quoi que ce soit.

quand utiliser quoi?

Eh bien, c'est la seule question valable à mes yeux; depuis google montre beaucoup de réponses valables à votre question. Essayez de ne jamais utiliser une dépendance dans un diagramme de classe, car cela signifie généralement que vous n'êtes pas assez précis. Toujours viser les associations, les réalisations, etc. N'utilisez les réalisations (à mon avis) que s'il est nécessaire d'utiliser une autre classe sans maintenir une relation. Exemple: classes D'utilité (comme XMLReader).

si vous avez des questions après avoir lu cette explication complète, n'hésitez pas à les poser. : -)

Votre question m'a donné une bonne chance d'apprendre moi-même, voici ce que j'ai trouvé:

Association: Propriété d'un autre type (par exemple " A " possède un 'B')

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

Dépendance: Utilisation d'un autre type (par exemple, 'C' utilise un 'D')

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

Voici un croustillant ref que j'ai trouvé - Association vs dépendance

instruments moyens pointillés (une interface) solide signifie s'étend (une classe de base)