[UML] Klassen als Attribute = Assoziationen?

[pzypher]

Hallo,

ich habe ein Skript vor mir und hab eine Frage dazu:

Einmal heißt es:

Zitat:

	Attribute sind nie Zeiger/Referenzen auf andere Objekte (dafür gibt es Assoziationen).

einandermal:

wird behauptet, A und B im folgenden Bild wären gleichwertig. Dass sie gleichwertig sind will ich nicht bestreiten, aber ist dann nicht Ersteres ein bisschen widersprüchlich?



Gruß

[spindler]

Assoziationen bilden in der objektorientierten Softwareentwicklung einen wichtigen Bestandteil.
Mehrere Objekte tauschen Nachrichten aus, damit müssen sich diese Objekte "kennen". Dieses "Kennen" nennt man Assoziation.

Dein Schaubild zeigt meiner Ansicht nach dasselbe Verhalten: Im ersten Schaubild ist die Assoziation über einen Pfeil kenntlich gemacht.
Im zweiten Schaubild wird die Assoziation über ein Attribut ausgedrückt. (-vorlesung). Attribute sind in Java auch keine Zeiger, sondern können Referenzen sein.

Ja beide Schaubilder bedeuten das selbe, jedoch würde ich eher Representation A wählen, da es dort finde ich klarer und übersichtlicher ist.

[nillehammer]

Die Schaubilder drücken zwar dieselbe Assoziation aus. Allerdings enthält Schaubild B ein für das Abstraktionsniveau des UML-Klassendiagramss unzulässiges Implementierungsdetail. Nämlich, dass die Assoziation über ein Attribut von Student abgebildet wird. Zwar hat man das als Java-Entwickler sofort im Kopf (inkl. der getter/setter für die Zugriffe), aber in UML-Klassendiagrammen hat das nix zu suchen. Deswegen würde ich in einer Klausur für Abbildung B Punktabzug geben.

Das Stimmt, schließlich könnte ich auch bei Vorlesung eine Liste mit Studenten haben, die ebenso die Assoziation auflöst
Wie gesagt, ich würde auch auf jedenfall zu A tendieren. Aber wie gesagt, bei beiden wird gezeigt, das Student in verbindung mit Vorlesung steht.

[Tomate_Salat]

Ich würde a) nehmen. Das ist imho auch Aussagekräftiger.

Beispiel b) könnte zu Verwechslungen führen. Ab und an findet man Java-Klassen die so benannt sind, wie bereits bestehende. Hier könnte es theoretisch sein, dass eben eine Vorlesungsklasse aus einem andere Package (und eben nicht die, die rechts daneben gezeichnet ist) verwendet werden soll.

[schalentier]

Muss dann name:String nicht ebenfalls als Assoziation gezeichnet werden?

[nillehammer]

Nein, auch wenn String eine Klasse ist, würde ich es als so "primitiven" Datentypen ansehen, dass er ein Attribut ist und keine Assoziation. Zumal ja auch String nicht Bestandteil der Fachdomäne "Studentenverwaltung" ist.

In dem UML Diagramm bzw in Klassendiagrammen, stellt man ja die fachlichkeit, also die Fachlichen Klassen dar, mit ihren Atributen und ihren Beziehungen, aber ein Student steht in keiner Beziehung zu einem String (wenn dann sind das die Studentinnen und das tut hier nichts zur Sache )

[Tomate_Salat]

Ich bin kein UML-Experte (und nutze es eigentl. auch nie - auch wenn ichs praktisch finde). Aber wenn ich das als Planung nehme, würde ich bestehende Klassen (mit vollqualifiziertem Namen) als Attribute nehmen und eigene (neue) Klassen als Assoziation/Komposition/Aggregation darstellen.

[maki]

Zitat: schalentier

	Muss dann name:String nicht ebenfalls als Assoziation gezeichnet werden?

Kommt immer darauf an, was man mit dem Diagramm ausdrücken möchte, wenn es nur um die Problem Domäne geht, dann wohl nicht.

Das gilt übrigens für alle UML Diagramme IMHO, es kommt immer darauf an was man zeigen will, das was nicht so relevant ist um einen Sachverhalt zu verdeutlichen, lässt man weg.

IME ist weniger mehr, die klassische DIN A0 Tapete wo alles drauf ist taugt doch nur dazu, um Kunden zu verwirren, genauso sinnvoll wie den ganzen Quelltext auszudrucken.

[X5-599]

Ich würde auch zu A tendieren. "Student kennt Vorlesung". Frage in den Raum:

Dürfte man das auch so darstellen, wenn es später in der Implementierung kein Attribut vom Typ Vorlesung in der Klasse Student gibt? Also wenn z.B. die Klasse Student nur ein Vorlesungsobjekt in einer Methode benutzt?

1
2
3
4
5
6
7
8
class Student
{
    public void setVorlesungBesucht()
    {
        Vorlesung vorlesung = getVorlesungVonIrgendwo();
        vorlesung.setBesucht(true);
    }
}

Oder würde man so eine Verbindung aus einem UML Diagramm gänzlich rauslassen?

Also ich bin der Meinung, das der Student, nicht unbedingt ein Vorlesungsobjekt braucht um die beziehung zu haben, sondern die Vorlesung kann auch eine Liste an Studenten haben, oder täusche ich mich da jetzt?
Das würde dann ja deine Variante machen

[X5-599]

Ich wollte damit eigentlich mehr fragen, ob überhaupt ein Attribut in einer Klasse existieren muss um (in UML) von einer Beziehung sprechen zu können. In meinem Beispiel hätte keine der beiden Klassen ein Attribut der jeweils anderen. Sie hätten nur in Methoden miteinander zu tun, wenn die Instanzen (die von sonstwoher stammen) bearbeitet werden.

[maki]

Zitat: X5-599

	Ich wollte damit eigentlich mehr fragen, ob überhaupt ein Attribut in einer Klasse existieren muss um (in UML) von einer Beziehung sprechen zu können. In meinem Beispiel hätte keine der beiden Klassen ein Attribut der jeweils anderen. Sie hätten nur in Methoden miteinander zu tun, wenn die Instanzen (die von sonstwoher stammen) bearbeitet werden.

Nein, für eine Assoziation muss man keine Membervariablen mit Typ der anderen Klasse haben.

Aber wie gesagt, es gibt nicht "den Standard" was UML Diagramme alles zeigen müssen, nur die Elemente der UML selber sind definiert.
Was man im Diagramm zeigt, kommt immer darauf an was man mit dem Diagramm zeigen will

Es ist zB. eher selten so, dass man Assoziationen zu den JDK Klassen darstellt (String, HashMap, etc. pp.), weil man meist etwas aus der Fachdomäne zeigen will.

Die Frage wie die Assoziation zwischen Student und Vorlesung modelliert wird ist eine Designfrage, da gibt es mehrere Alternativen, unidirektionale 1:n (zB. Student -> Vorlesungen), n:1 (Student <- Vorlesungen), bidirektionale n:n (Student <-> Vorlesungen) usw. usf.
Das Design sollte sich stark am Verwendungszweck orientieren.