OOP Einige Fragen zu UML-Klassendiagrammen

[thousands]

Hi,

zu Dokumentationszwecken möchte ich die Architektur eines von mir erstellten Programmes in Form von UML-Klassendiagrammen darstellen. Dabei sind mir ein paar Dinge nicht so 100%ig klar, gibts hier denn ein paar UML-Profis die mir evtl. weiterhelfen könnten?

Meine Fragen wären im Einzelnen:

1. Da meine Klassendiagramme z.T. recht umfangreich sind, würde ich gerne auf die Aufführung von Vererbungen und implementierten Interfaces (jeweils von "Java-eigenen" Komponenten) verzichten, wäre dies gemäß UML Konvention denn "zulässig"? Wenn also z.B. eine meiner Controller-Klassen vier verschiedene Listener-Interfaces implementiert (ActionListener, MouseListener, etc...), muss ich diese Listener dann alle einzeln im Klassendiagramm aufführen oder kann man soetwas getrost weglassen? Wie siehts bei Vererbungen aus, wenn also z.B. meine Views von JFrame erben, muss ich die Vererbung dann zwangsweise im Klassendiagramm aufführen oder kann auch diese aus Gründen der Übersichtlichkeit weggelassen werden?

2. Mein Programm ist in mehrere (voneinander unabhänginge) Module aufgeteilt, zur Kommunikation zwischen diesen Modulen verwende ich einen eigenen Singleton, der einfach an einer beliebigen Stelle per .getInstance() aufgerufen werden (also genau so wie bspw. der java-eigene Logger) und zur programminternen Kommunikation benutzt werden kann. Mir ist nun nicht ganz klar, wie ich dies in einem Klassendiagramm darstelle. Wenn ich in einer Klasse dieses Singleton verwende, besteht dann einfach eine unidirektionale Assotiation von der Klasse zu dem Singleton oder gibt es dafür eine andere Lösung (evtl. sogar eine Lösung speziell für Singletons)?

3. Daten und Informationen, welche in meinem Programm verwendet oder gespeichert werden, werden grundsätzlich nicht in ihrem "Rohzustand" verwendet, sondern in eigene Objekte "gewrapped". Ein BufferedImage würde also z.B. nicht einfach als BufferedImage verwendet, sondern ich würde eine Klasse ImageObject erstellen, welche das BufferedImage im Konstruktor als Nutzdatum bekommt. Im folgenden arbeite ich dann einfach mit dem ImageObject, welches das darin enthaltene BufferedImage per get()-Methode bereitstellt. Wenn also eine Klasse irgendwo in ihrem Code nun new ImageObject(...) aufruft um ein BufferedImage zu wrappen, welche Art von Beziehung hat diese Klasse dann zu der Klasse ImageObject?

4. Wie kann ich kennzeichnen, ob eine Komposition bidirektional oder unidirektional ist? Manche meiner Klassen erstellen kleine "Helper-Klassen" und lagern in diese eine bestimmte Aufgabe aus. Dabei bekommt die Helper-Klasse manchmal eine Referenz auf die erstellende Klasse übergeben (es ist also bidirektionale Kommunikation möglich), manchmal auch nicht. Wie unterscheide ich zwischen diesen Fällen im Klassendiagramm bzw. muss ich dazwischen überhaupt unterscheiden, oder ist es in beiden Fällen einfach eine normale Komposition (also "ausgefüllte Raute" auf der Erstellerseite)?


Schonmal vielen Dank!

Gruß, thousands

 

[Marcinek]

Hi,

1) Nein musst du nicht. Die Inhalte eines UML- Diagramms kannst du selbst bestimmen. Wie du sie darstellst legt die Konvention fest.

2) Du kannst den stereotype angeben. <<singleton>>.

3) 1:1 unidierektionale Verbindung

4) --> unidirektional <----> bidirektional

Gruß,

Martin

 

[thousands]

Hi,

1) Nein musst du nicht. Die Inhalte eines UML- Diagramms kannst du selbst bestimmen. Wie du sie darstellst legt die Konvention fest.

2) Du kannst den stereotype angeben. <<singleton>>.

3) 1:1 unidierektionale Verbindung

4) --> unidirektional <----> bidirektional

Gruß,

Martin

Danke schonmal! Punkt 1) wäre damit eigentlich geklärt.
Zu den Punkten 2) und 3): das ist also jeweils eine unidirektionale Assosziation, richtig?
Zu Punkt 4): Das Problem bei der Sache ist ja, dass bei der Komposition auf der Erstellerseite bereits die (ausgefüllte) Raute ist, für den Richtungspfeil ist gewissermaßen einfach "kein Platz". Das mit den Pfeilen am Ende geht also (afaik) nur bei der Assoziation. Wie kann ich aber bei der Komposition angeben, ob diese uni- oder bidirektional ist?

Gruß, thousands

 

[nillehammer]

Zu Punkt 4): Das Problem bei der Sache ist ja, dass bei der Komposition auf der Erstellerseite bereits die (ausgefüllte) Raute ist, für den Richtungspfeil ist gewissermaßen einfach "kein Platz". Das mit den Pfeilen am Ende geht also (afaik) nur bei der Assoziation. Wie kann ich aber bei der Komposition angeben, ob diese uni- oder bidirektional ist?

Eine Komposition ist eine spezielle Form der Assoziation, die aussagtm dass ein Teil existenziell Abhängig von einem Ganzen ist. Das hat mit der Navigationsrichtung erstmal nichts zu tun. Genau wie bei normalen Assoziationen kann auch die Komposition bidirektional sein. Auch wenn das im Diagramm vielleicht blöd ausieht, weil Raute und Pfeil sich überlagern.

 

[thousands]

Eine Komposition ist eine spezielle Form der Assoziation, die aussagtm dass ein Teil existenziell Abhängig von einem Ganzen ist. Das hat mit der Navigationsrichtung erstmal nichts zu tun. Genau wie bei normalen Assoziationen kann auch die Komposition bidirektional sein. Auch wenn das im Diagramm vielleicht blöd ausieht, weil Raute und Pfeil sich überlagern.

Ok, das leuchtet ein. Die Frage ist aber halt, ob Kompositionen (bzw. auch Aggregationen) inhärent (also ohne Angabe der Navigationsrichtung, sozusagen ohne Pfeile) uni- oder bidirektional sind.

Da sie ja nichts anderes als Sonderformen von Assoziationen sind, und Assoziationen ohne Pfeile als bidirektional angesehen werden (richtig?), dann sollten ja auch Kompositionen/Aggregationen ohne spezifisch angegebene Navigationsrichtung erstmal bidirektional sein ( wird z.B. hier (s. Navigation) oder hier (s. Aggregation) auch so bestätigt).

Eine unidirektionale Komposition/Aggregation könnte man dann durch die Raute auf der Erzeugerseite und einen Pfeil auf der Hilfsobjektseite angeben, also z.B. so:

Das Problem an der Sache ist, dass ich mittlerweile einen meiner Profs. konsultiert habe, und dieser meint, eine Komposition/Aggregation sei grundsätzlich erstmal inhärent unidirektional. Das ganze wird auch durch automatische Codegenerierung (Enterprise Architect) bestätigt, wenn man eine (ganze normale, also "Pfeil-lose" 🙂) Komposition in Code umwandeln lässt, dann kennt die erzeugte Klasse die Erzeugerklasse nicht, die Koposition ist hier also tatsächlich inhärent unidirektional.

Das ganze ist echt zum Haare raufen! Kanns sein, dass die UML in so manchen Dingen (wie z.B. auch hier) arg "schwammige" Definitionen bereitstellt?

 

[nillehammer]

Da sie ja nichts anderes als Sonderformen von Assoziationen sind, und Assoziationen ohne Pfeile als bidirektional angesehen werden (richtig?)

Ich hab mal meine UML-Referenz (B. Ooestereich) herangezogen. Bei der Beschreibung der Assoziation ist das zwar nicht explizig so geschrieben, aber ich verstehe es auch so.

Das Problem an der Sache ist, dass ich mittlerweile einen meiner Profs. konsultiert habe, und dieser meint, eine Komposition/Aggregation sei grundsätzlich erstmal inhärent unidirektional.

Bei der Beschreibung der Komposition/Aggregation steht das nicht explizit. Es steht aber, dass (abgesehen von den Besonderheiten) alles gilt, was auch bei Assoziationen gilt. Also würde ich nach meiner Quell-Lage sagen, Dein Prof hat unrecht.

Das ganze wird auch durch automatische Codegenerierung (Enterprise Architect) bestätigt,

Das würde ich als Referenz nicht gelten lassen. Klassendiagramme laden zwar zur automatischen Codegenerierung ein, aber ob der EA hier nur einen möglichen Weg beschreitet oder es tatsächlich der einzige UML-Konforme Weg ist?

Die UML ist übrigens selbst in UML formal Beschrieben. Ich werd mal schauen, ob ich das Metamodell irgendwo finde und meld mich dann nochmal.

 

[thousands]

Die UML ist übrigens selbst in UML formal Beschrieben. Ich werd mal schauen, ob ich das Metamodell irgendwo finde und meld mich dann nochmal.

Danke danke, ich glaub aber, ich habs mittlerweile sogar selbst gefunden! 🙂

Ich hab einfach mal bei der Original-Quelle (UML Specifications) nachgeschlagen und da steht, bezogen auf Assoziazionen/Aggregationen/Kompositionen folgendes:

Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress
some of the arrows and crosses and just show exceptional situations:

• Show all arrows and x’s. Navigation and its absence are made completely explicit.
• Suppress all arrows and x’s. No inference can be drawn about navigation. This is similar to any situation in which information is suppressed from a view.
• Suppress arrows for associations with navigability in both directions, and show arrows only for associations with oneway navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation at all; however, the latter case occurs rarely in practice.

Ich hab den letzten der Punkte mal unterstrichen, da dieser ja auf "meine" Problemstellung passt. So werd ichs dann denk ich auch machen. Nochmals danke für die, wie immer, klasse Hilfe! 🙂