J'utilise UML depuis un moment et j'ai lu quelques articles, livres, forums à ce sujet, mais je ne comprends toujours pas vraiment lorsque deux classes doivent être liées à la ligne d'association (une ligne simple ou une flèche (ou ne sont pas les mêmes?)). Je vais vous donner trois exemples - Pouvez-vous me dire lequel les deux classes seront dans cette relation?
1. P>
//used inside a method
public class MainClass
{
private Something something;
public void Action()
{
OtherClass other = something.GetOtherClass();
}
}
4 Réponses :
J'utilise généralement deux connecteurs différents dans UML:
Lorsqu'une classe dépend de la mise en œuvre d'une autre. Cela impliquerait qu'une classe crée ou gère une instance d'une autre. Donc, la classe d'appel dépend de la classe de mise en œuvre. Cela serait évident dans tous vos exemples.
Quand une classe s'étend ou implémente une autre.
Alors, quels connecteurs utilisez-vous dans chaque cas?
edit: réécrire la réponse après la discussion dans les commentaires (grâce à chimp pour souligner quoi J'ai négligé dans l'exemple 4)
Exemple 1: Un autreClass est un attribut de principaleclass, et est donc modélisé en tant qu'association.
Exemples 2 et 3: Un autreClass est référencé dans la définition de la classe, bien que non stocké dans un attribut, il s'agit donc d'une dépendance.
Exemple 4: La classe quelque chose est un attribut, et donc une association, tandis que la classement référencée, qui n'est pas stockée dans un attribut, et c'est donc une dépendance.
Au sein de l'UML, les dépendances et les associations sont à la fois des types de relations et ne sont pas strictement liés (sauf par un supericiel commun), bien que, à mon avis, une association implique une dépendance.
Les associations sont indiquées par une ligne entre les 2 classes avec des multiplicités à chaque extrémité. La navigabilité est indiquée par des flèches montrant quelle classe est consciente de laquelle (par exemple la classe A ___> La classe B signifie A est consciente de B, mais pas l'inverse) La navigabilité dans les deux sens est indiquée par des flèches aux deux extrémités. Où il n'y a pas de flèches, il n'est généralement plus sûr de ne faire aucune hypothèse sur la navigabilité, sauf indication d'ailleurs.
Les dépendances sont indiquées par une ligne pointillée avec une flèche de la classe dépendante (client) à la classe étant dépendante sur (fournisseur) (par exemple, A ----> B signifie que A est dépendant de b). Les dépendances montrent qu'une classe est référencée à un moment donné et, en tant que tel, le client dépend des opérations fournies par le fournisseur, mais elle n'indique pas comment elle est référencée (contrairement à une association qui suggère une référence stockée dans un attribut). < / p>
Ok mais la classe n'est-elle pas consciente des classes fournies comme arguments? Et êtes-vous sûr de ce que vous dites, car je cherche une réponse "C'est ce que la théorie dit, fin du sujet"?
Hmm, je pourrais probablement reformuler cela un peu: le voyage de l'esprit au clavier n'est pas toujours facile, et je pense avoir perdu une signification sur le chemin. Les associations sont exprimées en tant qu'attributs. Il est acceptable d'afficher des associations d'UML de la même manière que des types de données primitifs, mais l'utilisation des lignes de connexion est généralement plus informative. J'ai bien peur que je ne puisse pas penser à une explication pour montrer pourquoi les arguments aux méthodes ne constituent pas une association (autre que «parce qu'elles ne« ont pas », ce qui n'est pas une explication du tout). Mais, peu importe, je suis sûr que c'est correct.
Au fait, je garde toujours une copie de UML distillée à la main lorsque vous travaillez avec UML, je trouve une très bonne référence: martinfowler.com/books.html#uml
Désolé, devait descendre cette réponse. Seul exemple 1 est une association; 2,3 et 4 sont des dépendances.
Bien que je conviens que 2 et 3 sont des dépendances simples, je pense que, en modélisant 4 comme dépendance, vous perdez la signification que la classe en question est également un attribut, préférerait une association (que je crois impliquerait une dépendance) car elle le rend plus clair que la classe est non seulement référencée, mais aussi stockée en tant que données au sein de la classe en question. Cela dit, je suis intéressé à entendre les réflexions d'autres personnes à ce sujet (comme il y a rarement une seule façon de le faire) et posera une question sur la question de savoir si les associations impliquent des dépendances.
Pour référence, la question que j'ai demandé peut être trouvée ici: Stackoverflow.com/questions/1152335
Juste pour préciser: dans l'exemple 4, la relation de la classe principale à une autre classe est une dépendance; La relation de Magrasclass à quelque chose est une association.
ah, j'ai mal interprété le code ... erreur de ma part, je n'ai pas pris la référence sur la référence à une autreclass ... maintenant je me rendais compte, je suis en train d'accepter avec vous et mettra à jour ma réponse
Tout d'abord une flèche représente navigabilité de l'association. Une arrow unique signifie unidirectionnel relation, dans ce cas, seule la classe source connaît la classe cible. La flèche sur les deux extrémités signifie la relation bidirectionnelle , où les deux classes se connaissent les unes des autres. Si aucune flèche n'est présente, l'association peut être soit bidirectionnelle par défaut ou supprimée pour le souci de lisibilité. En pratique, vous devez dessiner des flèches uniquement lorsque vous souhaitez mettre l'accent sur la direction de l'association.
En ce qui concerne votre deuxième question, seul le premier cas décrit une association (unidirectionnelle) entre Veuillez noter qu'il existe un concept de pozdrionia! mainclass et autreclass . Ni des arguments ni des valeurs de retour impliquent une association au sens de l'UML (bien que cela impliquent la dépendance). Dans le dernier exemple, il existe une association entre mainclass et quelque chose la classe via le quelque chose attribut. En règle générale, vous devez rechercher des associations en attributs.
dépendance en UML et il est représenté par une ligne pointillée.
Cela résume à peu près tout. +1
Une association représente deux propriétés ou plus connexes.
Dans l'exemple 1, MAINCLASS a une propriété de type autreClass. Si autreclass a une propriété explicite de type MAINLLASCLASS, il y aura une association bidirectionnelle entre la classe; Si une autre classe a une propriété implicite de type MAINCLASCLASS (I.E. Il n'y a pas d'attribut, mais la relation peut être dérivée en travaillant dans l'autre sens), il y aura une association unidirectionnelle de Magrasclass à d'autresClass.
Dans les exemples 2, 3 et 4, MAINCLASS n'a pas de propriétés de type autreClass. Cela dépend de l'autreClass cependant, il y aurait donc une relation de dépendance de Magrasclass à d'autresClass. Dans le code, cela est représenté par un