UML Komponenten als Java-Klassen abbilden

[noobstudent]

hi,
wir hatten dieses semester uml gelernt, was für mich totales neuland ist. jedoch kenne ich bereits recht gut java und wollte mir ein komponenten diagramm als java klassen abbilden um ein besseres verständnis davon zu erhalten. nur stehe ich da irgendwie auf dem schlauch, da ich nicht weiß, welche klasse wen kennt...

ich bin mir nichtmal so sicher, ob das überhaupt geht. aber soweit ich es verstanden habe, sollte es schon möglich sein, da selbst eine einzelne klasse eine komponente ist. (...richtig??)

foglendes beispiel habe ich mir aufgemallt:


A, B und C sind komponenten und DS, ES und FS sind jeweils die schnittstellen. in java müsste das dann so aussehen:

class A {
   B b;
   C c;
   DS ds;
   ES es;
   FS fs;
}

class B {
   DS ds;
   ES es;
}

class C {
   ES es;
   FS fs;
}

interface DS { }
interface ES { }
interface FS { }

- liege ich damit richtig, dass die komponente A sämtliche anderen komponenten UND interfaces kennen muss? denn A muss ja B und C verbinden.
- muss B auch C kennen, oder reicht es wenn lediglich das angebotene interface von C bekannt ist?
- sehe ich das richtig, dass jede komponente jeweils das angebotene und konsumierte interface kennen muss?


gruß 🙂

 

[Marcinek]

Ich weiß nicht 100 %, was das Schaubild zeigen soll.

Ein UML Klassendiagramm, aus dem man 1:1 Java Klassen erstellen kann ist es sicherlich nicht.

Hier musst du dir erstmal eine geeignete Datenstruktur überlegen. Da ist die Frage, was das für einzelene Komponenten sind und wie sie sich verhalten zueinander...

 

[Spin]

Hallo TO,

ich beschäftige mich auch gerade mit Komponentendiagramme und habe herausgefunden, dass eine Komponente eine einzelne Klasse sein kann, aber auch ein Paket aus Klassen. Stelle dir vor du hast ein Paket aus Klassen, die sich um das parsen von Zeichen und Dateien kümmern. Es gibt einen XMlParser, einen JsonParser, einen Prser um Bilder zu decodieren usw. Das wäre die Parser Komponente. Aber auch eine einzelne Klasse kann eine Komponente sein, wie beispielsweider ein FileLoader oder Configuration. Anschließend werden abhängigkeiten definiert. Es gibt das Provider und das Required Interface. Eine Komponente kann Objekte anbieten und Objekte benötigen.

In deinem Beispiel ist A eine Komponente und B,C Subkomponenten.
Die Komponente A ist abhängig von Ereignissen, die außerhalb des Komponentensystems passieren. Es wird also die innerer Struktur von der äußeren abgekoppelt. Ein Beispiel wäre ein UserLogin. Ohne User Login kann keiner dein System betreten. (Beispiel für FC) Anders rum kann dein System nur Funktionieren, wenn beispielsweise Daten in der Datenbank (Beispiel für DS) vorhanden sind oder wenn das Internet erreichbar ist, oder was weiss ich 😉

Die Komponente C könnte beispielsweise ein Kunde sein und die Komponente B eine Bestellung. Ohne Kunde auch keine Bestellung, daher die Abhängigkeit. Weiter sobald eine Bestellung rein kommt, müssen Daten in der Datenbank vorliegen, was soll sonst der Kunde bestellen können?

Mit meinen Beispielen überlege dir nochmal die Kompositionen 😉 Jetzt kennt gefühlt jeder jeden bei dir, was aber nicht sein muss. Denk dran Komponenten muss man auch austauschen können.

grüße spin

 

[noobstudent]

Ein UML Klassendiagramm, aus dem man 1:1 Java Klassen erstellen kann ist es sicherlich nicht.

ne, es ist ein komponentendiagramm 😛
aber mal spass bei seite, es ist sehr abstrakt gehalten (was ich auch erreichen wollte) und ich denke auch, dass es syntaktisch korrekt ist. dementsprechend müsste es sich auch in java code darstellen lassen...zumindest war das mein gedankengang.

Jetzt kennt gefühlt jeder jeden bei dir, was aber nicht sein muss.

ja mindestens einen fehler habe ich gefunden. mein vorgehen war eigentlich ganz simpel:
- A, B und C müssten mindest die schnittstellen kennen, die sie anbieten.
- da A jeweils beide schnittstellen delegiert, müsste A auch die anderen komponenten kennen

daraus würde sich nun ergeben:

class A {
   B b;
   C c;
   DS ds;
   FS fs;
}
 
class B {
   DS ds;
   ES es;
}
 
class C {
   ES es;
   FS fs;
}
 
interface DS { }
interface ES { }
interface FS { }

ich wollte mir also sowas wie ein rezept machen, wie ich ganz abstrakt komponenten zu code mappen kann.
wobei ich irgendwie das gefühl habe, dass die komponente A die komponenten B und C nicht kennen sollte, sondern nur deren schnittstellen. wegen der austauschbarkeit, wie du schon sagtest.

somit würden alle komponenten jeweils nur ihre eigenen schnittstellen kennen:

class A {
   DS ds;
   FS fs;
}
 
class B {
   DS ds;
   ES es;
}
 
class C {
   ES es;
   FS fs;
}
 
interface DS { }
interface ES { }
interface FS { }

die verdrahtung müsste dann aber irgendwo anders passieren, z.b. mittels dependency injection. das problem wäre nur, dass dieses "externe", also da wo die verdrahtung stattfindet, das komplette modell kennen müsste...

Mit meinen Beispielen überlege dir nochmal die Kompositionen ;)

werde ich heute abend mal machen. evtl. verstehe ich es ja dann und kann es auf dieses beispiel übertragen.

 

[Andreas-P]

Hi,

das Problem ist, dass folgendes eben nicht möglich ist:

...dass es syntaktisch korrekt ist. dementsprechend müsste es sich auch in java code darstellen lassen...

Die Begründung lieferst Du auch gleich mit, in dem Du sagst, dass es sehr abstrakt gehalten ist. Gerade das ist ein Kern der UML, das man Sachverhalte durch verschiedene Sichten Abstrakt und Verständnis fördernd darstellen kann, ohne das es dafür eine explizite Lösung in Form von Quellcode gibt oder geben muss.

Vergegenwärtige dir, dass Du mit salopp gesagt 'ein paar Rechtecken', ein ganzes Softwaresystem bestehend aus vielen Millionen Zeilen Code in der UML darstellen kannst (Stichwort: Layer Model). Hier wird viel deutlicher wieso man trotz syntaktischer Korrektheit, keine konkreten Klassen oder gar die gesamte Software daraus ableiten kann.

Ähnlich ist es für dein Komponentendiagramm, es gibt hier also mindestens unendlich viele richtige Interpretationen und genauso viele falsche. Die Einzige Aussage die sich mit deinem Diagramm treffen lässt:

A ist eine Komponente bestehend aus B und C. A bietet als Schnittstelle nach außen DS an, in diesem Fall realisiert durch die Komponente B. A bzw. dessen Subkomponente C benötigt die Schnitstelle FS. B und C sind über die Schnittstelle ES verbunden.

Diese Informationen können genügen, falls man jemanden den Zusammenhang zwischen Softwarekomponenten erklären möchte. Oder auch nicht, falls man konkreten Code daraus erzeugen will, hier ist dann ggf. eine weitere Modellierung auf Klassenebene notwendig.

Für die Generierung von Quellcode sind eigentlich nur folgende Kandidaten geeignet:

• Klassendiagramme
• Statecharts
• Sequenzdiagramme

Viele Grüße,
Andreas