UML Anfängerfragen

[Guest]

Hallo,
Ich hätte mal ein paar Anfängerfragen.
Wann herrscht denn eine uses und wann eine has-a Beziehung vor?

Also uses gilt doch dann, wenn die eine Klasse, die andere zum Beispiel aufruft.
Also wenn ich zum Beispiel eine Thread Klasse hätte und diesen Thread auf eine andere Klasse anwende, wäre das dann eine uses Beziehung?
Und was ist denn dann der Unterschied zur has-a Beziehung? + Wie sehen diese Beziehungen denn dann im Diagramm aus? Ich blicke langsam ned mehr durch.

Ich wäre auch über gute Tutorials oder online Nachschlagewerke dankbar. Die Wikipedia Artikel zu UML-Klassendiagrammen waren irgendwie nicht so wirklich hilfreich.

MfG
Daniel

 

[Evolver]

Meine Erfahrung sagt mir, dass diese Beschriftungen nicht so viel Relevanz haben. Dazu sei gesagt, meine Erfahrung sind ein paar Uni-Projekte, nichts aus der Wirtschaft. Also 'has_a' ist z.B. bei Aggregationen angebracht. Also wenn KlasseA als Attribut ein Objekt der KlasseB hält, könnte man von einer 'has_a' Beziehung sprechen. Aber die Bezeichnung sind eher semantischer Natur, um also die Bedeutung einer Bezeihung zu verdeutlichen.

Ich kann das Buch "UML glasklar" (Verlag Hanser oder so) empfehlen.

 

[SnooP]

hasA ist eine "hat eine Instanz/Referenz" Beziehung... sagt nur aus, dass z.B. eine Klasse A eine Referenz auf B hat. Als Membervariable. Sprich eine ganz normale Assoziation.

uses ist etwas anders. Das kann man nämlich auch benutzen, um anzudeuten, dass Klasse A eine Methode von Klasse B aufruft, ohne dass eine Assoziation besteht. Beispielsweise rufst du in der Methode foobar() : void in A eine Methode foo() von Klasse B auf:
new B().foo(); - dann besteht keine Assoziation, A benutzt aber was von B. Eine solche Beziehung wird durch eine gestrichelte Linie dargestellt - häufig aber auch weggelassen, weil man meist mit CDs die strukturellen Abhängigkeiten von Klassen darstellen will... aber manchmal will man halt auch noch andere Dinge am CD zeigen und da bietet sich "uses" halt an.

<<create>> ist ein ähnlich gearteter Stereotyp auch an so ner gestrichelten Linie... z.B. halt bei Factory-Klassen gerne verwendet.

 

[Gast]

Ahhh, vielen Dank!
So in etwa habe ich mir das eigentlich auch gedacht.
Ich hätte nurnonoh eine Frage zur genauen Darstellung.
Ich meine eine Interface Beziehung hat ja auch eine gestrichelte Linie. Was wird denn dann noch benötigt (Raute, Pfeil? gefüllt, leer?). Und an welcher Klasse liegt der "Kopf" des Pfeils. Also an der, die die Instanzvariable trägt oder an der Klasse die quasi die Instanzvariable darstellt.
Und bei uses halt bei der benutzenden oder benutzten Klasse.
Tut mir wirklich Leid für die blöden Fragen,
aber wie gesagt auf Wikipedia und auch bei google finde ich hier irgendwie nix sinnvolles, was alles kurz und bündig zusammenfasst.
http://de.wikipedia.org/wiki/Klassendiagramm

 

[Stephan Christoph]

Guter Thread, so ziemlich das gleiche wollte ich auch gerade fragen

@ Daniel: Zufällig auch Informatikstudent bei dem's jetzt auf die Prüfungen zugeht?

Also ich würd gern nochmal zusammenfassen um sicherzugehen dass ichs auch verstanden habe:

Is-A-Beziehung: Bei Subclasses. Der Pfeil geht von der Subclass zur Superclass.

uses-Beziehung: Wenn irgendwie eine Methode einer anderen Klasse aufgerufen wird. z.B. bei sowas:

public class A
{
public static void main (string[] args)
{
    B b = new B();
    b.foobar();
}

public class B
{
public static void main(string[] args)
{
    public void foobar() { }
}

Oder auch wenn das Objekt von A in einer Main-Klasse erzeugt würde und dann an die Klasse B übergeben wird:

public class A
{
    private B b ;
    public A (B b) { this.b = b; }
}

public class Main
{
    B b = new B();
    A a = new A(b);
}

Die Klasse A ruft hier jetzt keine Methode von B auf. Kommt dann trotzdem ein Uses-Pfeil?
Und wird die Klasse Main mit uses-Pfeilen auf A und B gekennzeichnet weil ja im Prinzip beides mal der Konstruktor von A und B aufgerufen wird?


Könntet ihr vllt. ein kleines Beispiel dazu machen wie zwei Klassen aussehen wenn sie eine Has-A beziehung haben?

Und dann evt. noch ein kleines Beispiel dazu wie ein Verweis-Pfeil aussieht?


Danke

 

[Guest]

hi Stephan,
Ja ich bin auch (Bio)info Student und ich glaube ich bin sogar an der selben Uni wie du.
Habe gesehen, dass du Fragen zur Bank(konto) GUI hattest... also denke mal du bist von der LMU, so wie ich .
Schöne Grüße an dieser Stelle.

Deine Fragen würden mich im übrigen auch interessieren, also wollte dir hier nicht den Wind aus den Segeln nehmen .

 

[Stephan Christoph]

Moin,

Ja exakt LMU :lol: Wie klein die Welt doch ist...

 

[Torsten_]

Moin erstmal,

bin neu hier, bin Anfänger und stehe grade in etwa vor der selben Problematik. Also die Sache mit der is-a-Beziehung ist mir ja klar, die ist immer dann gegeben wenn eine subclass gebildet wird aslo dort das Schlüsselwort "extends" zu finden ist.
Mit der uses-Beziehung bzw. der has-a-Beziehung blicke ich nicht so ganz durch. Also um auf die Methode einer Klasse zugreifen zu können müsste ich doch in der Regel eine Instanz dieser Klasse bilden (es sei den es handelt sich um eine static-Methode) - bitte korrigiere mich jemand wenn ich falsch liege!
Ist das nun so, das im Moment der Instanziierung quasi die has-a-Beziehung zutrift, also das die Superklasse in dieser Beziehung zu der Subklasse steht? Und in dem Moment wo die Methode der Superklasse von der Subklasse aufgerufen wird kann von einer uses-Beziehung gesprochen werden?
... am Anfang lohnt es sich wahrscheinlich jede Erbse besser zweimal zu zählen, bevor eine vergessen wird

 

[SnooP]

eine has-a Beziehung hat man immer nur dann, wenn eine Klasse eine Referenz auf eine andere Klasse hält. Dann "besitzt" z.B. Klasse A ein Objekt der Klasse B (oder auch mehrere in Form einer Liste - Kardinalitäten). Logischerweise sollte Klasse dann dieses Objekt auch benutzen, man geht in der uml dann implizit davon aus - eine gestrichelte Linie für "uses" muss man dann aber nicht machen.

Anders bei uses-Beziehungen. Hier muss eine Klasse A kein Objekt der Klasse B besitzen, d.h. es gibt keine Referenz von A auf B, aber es wird das Objekt instanziert und somit nur benutzt: new B().foobar(); halt. Dadurch wird in A keine Referenz auf B angelegt... beim Entwickeln treten solche Fälle ständig auf, trotzdem hat eine Klasse in dem Fall dann keine statischen Abhängigkeiten auf andere Klassen... man müsste diese Beziehung auch noch nicht einmal darstellen, weil es eigentlich schon zu sehr Implementierungsdetail ist. Aber wenn man es halt darstellen will, dann benutzt man dafür die gestrichtelte Linie.

Superklassen-Subklassen Beziehungen haben damit rein gar nix zu tun. Auch die Interface-Beziehung, was man als spezielle Form einer Subklassenbeziehung bezeichnen kann, hat damit nischts zu tun. Bei der Interfacebeziehung wird nur zufällig auch ne gestrichelte Linie verwendet - viele uml-tools stellen für die Strichelung da auch nen anderen Abstand dar, damit man das nicht aus versehen mal misinterpretieren kann...

Zu den Pfeilen: Man spricht da ja auch von der Navigierbarkeit. Wenn Klasse A eine "has-a" Beziehung zu B aufbaut, dann geht der Pfeil von A nach B. Die Spitze zeigt also auf B. Das heißt, dass man von A nach B "navigiert". Die Referenz von B liegt also bei A:

public class A {
   private B itsReferenceToB;
//..
}

Wenn Pfeilspitzen in beide Richtungen zeigen, heißt das die Beziehung ist bidirektional, man kann also von beiden Seiten aus zu der jeweils anderen Seite navigieren. Im oberen Fall weiß ja Klasse B nicht, dass sie in A referenziert wird. Wenn B jetzt auch eine Referenz nach A hat, die für die selbe Beziehung benutzt wird, quasi an gleicher Stelle, werden zwei Pfeilspitzen gemalt.

Übrigens können natürlich auch mehrere Assoziationen von einer Klasse A nach B gehen, wenn damit jeweils neue Referenzen benutzt werden... z.B. bei einer doppelt verketteten Liste, bei der es jeweils Verweise auf next und prev Elemente gibt - zwei Pfeile von Element auf Element mit einmal der Rolle next und einmal prev.

Aggregation und Komposition sind dann noch zusätzliche spezielle Assoziationen/Beziehungen - aber das kann man dann auch selbst nachlesen

hth

 

[Torsten_]

... ich glaube so ungefähr habe ich das verstanden