Fragen zu einem Klassendiagramm

[Zrebna]

Hi!

Ich habe grundsätzliche Fragen zu einem Klassendiagramm und habe dazu eine Abbildung hochgeladen.

1. Ist es korrekt, dass man reine get-und set-Methoden (gerrers & setters) sowie Konstruktoren nicht in ein Klassendiagramm einfügt?
2. Oben (Minus-Symbol) kommen nur Member-Variablen (also vor dem Konstruktor deklariert) rein, oder?
3. Wie sieht es mit Methoden aus? Kommen nur public Methoden in das Klassendiagramm, oder auch private Methoden?
4. Wenn eine Klasse eine Member-Variable (egal ob Instanz-oder Klassenvariable) hat, dann sollte diese Member-Varialbe, sofern ein komplexer Datentyp bzw. ebenfalls eine Klasse, auf jeden Fall in das Klassendiagramm, denn diese Klasse (member-Variable) wird ja dann von der "Haupt-Klasse" verwendet (<<use>>) - richtig?
-> Siehe in der Abbildung 'UserRepositiroy'
5. Wenn eine Methode (wohl nur public) etwas zurückliefert und erzeugt (<<create>>, dann kann dieser Return-Typ, sofern eine Klasse, auch in das Klassendiagramm rein?
-> Siehe 'User' im Bild.

6. Nun eine wichtige Frage, bei der ich mir komplett unsicher bin.
Angenommen (unabhängig vom Bild), man hätte in einer Controller-Klasse irgendwo eine public Methode, die Entitäten persistiert.
Dafür gibt es eine eigene Klasse 'PersistenceAPI', die Persistierungslogik enthält.
Diese 'PersistenceAPI'-Klasse bzw. eine Methode (die dann in dieser Klasse zu mehreren private Methoden führt) wird nun in der public Methode dieser zugrundeliegenden Controller-Klasse verwendet. einfach mittels 'new PersistenceAPI().persistEntity(entity)' aufgerufen, d.h. die PersistenceAPI() ist keine Member-Variable. Findet sie trotzdem Einzug ins Klassendiagramm?

Lg,
Zrebna

 

[Marinek]

1. Ist es korrekt, dass man reine get-und set-Methoden (gerrers & setters) sowie Konstruktoren nicht in ein Klassendiagramm einfügt?

Korrekt.

2. Oben (Minus-Symbol) kommen nur Member-Variablen (also vor dem Konstruktor deklariert) rein, oder?

Diese Aussage ist komisch Üblicherweise werden Attribute (Member-Variablen) vor dem Block mit den Konstruktoren definiert. Das Minus bedeutet, dass diese private sind. + Wäre Public oder # protected.

3. Wie sieht es mit Methoden aus? Kommen nur public Methoden in das Klassendiagramm, oder auch private Methoden?

Ich würde sagen private Methoden sind irrelevant. Es sei denn die sind super wichtig für das Verständniss

4. Wenn eine Klasse eine Member-Variable (egal ob Instanz-oder Klassenvariable) hat, dann sollte diese Member-Varialbe, sofern ein komplexer Datentyp bzw. ebenfalls eine Klasse, auf jeden Fall in das Klassendiagramm, denn diese Klasse (member-Variable) wird ja dann von der "Haupt-Klasse" verwendet (<<use>>) - richtig?

Nein. Nur, wenn es wichtig ist. Du machst ja auch nicht use auf Object oder Integer oder String etc.
Das würde dein UML überfrachten und unübersichtlich machen.

5. Wenn eine Methode (wohl nur public) etwas zurückliefert und erzeugt (<<create>>, dann kann dieser Return-Typ, sofern eine Klasse, auch in das Klassendiagramm rein?

Auch hier: Wenn sie ein String zurück gibt, ist das irrelevant würde ich sagen.

Wenn es wichtig für das Gesamtkonstukt ist, dann würde ich es aufnehmen.

Angenommen (unabhängig vom Bild), man hätte in einer Controller-Klasse irgendwo eine public Methode, die Entitäten persistiert.
Dafür gibt es eine eigene Klasse 'PersistenceAPI', die Persistierungslogik enthält.
Diese 'PersistenceAPI'-Klasse bzw. eine Methode (die dann in dieser Klasse zu mehreren private Methoden führt) wird nun in der public Methode dieser zugrundeliegenden Controller-Klasse verwendet. einfach mittels 'new PersistenceAPI().persistEntity(entity)' aufgerufen, d.h. die PersistenceAPI() ist keine Member-Variable. Findet sie trotzdem Einzug ins Klassendiagramm?

Das kannst du im Diagramm gar nicht abbilden, welche Variablen innerhalb der Methode erstellt werden.

 

[AndiE]

Ich würde die Darstellung ändern. Wenn eine Klasse mehrere andere Objekte enthält, dann würde ich an die Klasse, die sie verwaltet den gefüllten Rhombus zeichnen und auf der amderen Seite einen Pfeil. Dann würde ich die Klasse mit durchgehenden Strichen verbinden. Pfeile am Ende weisen dann darauf in, ob sie für die andere Klasse sichtbar ist. Auch beim Interface wäre es wichtig zu sehen, wer es bereitstellt( gestrichelte) und es nutzt( durchgehende Linie). Das Diagramm würde ich für mich leichter lesen lassen, wenn man Controller- Repository und Entity on links nach rechts nebeneinander stehen hat. Dann läßt sich das Klassendiagramm leichter verstehen.

Ich meine, dass das Klassendiagramm der "statische Bauplan" für deine Anwendung ist. Was passiert, erklärt ja das Aktivätätendiagramm.

 

[Zrebna]

Das kannst du im Diagramm gar nicht abbilden, welche Variablen innerhalb der Methode erstellt werden.

Danke, agree mit allem.

Nur bei Punkt 6 verstehe ich nicht, warum das nicht möglich sein soll?
Also in meinem konstruiertem Beispiel:

|ControllerClass| ------------------------<<access>>---------------------------|PersistenceAPI|

Bei PersistenceAPI würde ich dann bei den Methoden nur die Methode im Klassendiagramm sichtbar machen, die in der ControllerClass aufgerufen wird, also:
+ persistEntity(entity: <T>)

 

[Marinek]

Das würde im Prinzip nur aussagen: Irgendwann benutzt man die PersistenceAPI, aber nicht welche Methode intern diese benutzt. Im Zweifel einfach alle.

Es bringt keinen Mehrwert.

 

[Zrebna]

Das würde im Prinzip nur aussagen: Irgendwann benutzt man die PersistenceAPI, aber nicht welche Methode intern diese benutzt. Im Zweifel einfach alle.

Es bringt keinen Mehrwert.

Ich dachte halt, an folgendes Beispiel:

Man will ein Klassendiagramm für einen Integrationstest erstellen. Dieser Integrationstest besteht aus Testklasse und z.B. 10 Hilfsklassen, wobei in einer von Ihnen auf eine Persistenz-Klasse irgendwo in der Anwendung zugegriffen wird bzw. die Persistenz-Schicht so angesprochen wird.
Hier hätte ich gedacht, dass es schon interessant ist zu sehen, welche Komponenten der Anwendung der Integrationstest braucht, und somit mit welchen Komponenten das Zusammenspiel getestet wird.

 

[LimDul]

Ich dachte halt, an folgendes Beispiel:

Man will ein Klassendiagramm für einen Integrationstest erstellen. Dieser Integrationstest besteht aus Testklasse und z.B. 10 Hilfsklassen, wobei in einer von Ihnen auf eine Persistenz-Klasse irgendwo in der Anwendung zugegriffen wird bzw. die Persistenz-Schicht so angesprochen wird.
Hier hätte ich gedacht, dass es schon interessant ist zu sehen, welche Komponenten der Anwendung der Integrationstest braucht, und somit mit welchen Komponenten das Zusammenspiel getestet wird.

Macht man in der Praxis nicht. In der Regel malt man in der Praxis nur relativ rudimentäre UML Diagramme, die auch selten weitergepflegt werden. UML wird schnell unübersichtlich. Eine normale Business-Anwendung besteht schnell aus 100ten Klassen.

Und für einen Integrationstest interessieren mich Klassen nicht - da teste ich Funktionalitäten.

 

[Zrebna]

Macht man in der Praxis nicht. In der Regel malt man in der Praxis nur relativ rudimentäre UML Diagramme, die auch selten weitergepflegt werden. UML wird schnell unübersichtlich. Eine normale Business-Anwendung besteht schnell aus 100ten Klassen.

Und für einen Integrationstest interessieren mich Klassen nicht - da teste ich Funktionalitäten.

Frage hat sich erledigt. Danke^^

 

[thecain]

einfach mittels 'new PersistenceAPI().persistEntity(entity)' aufgerufen, d.h. die PersistenceAPI() ist keine Member-Variable.

Nur als Input. Der Testbarkeit halber würde ich so etwas versuchen zu vermeiden. Im Gegensatz zu einer Injection via DI oder Übergabe im Konstruktor und dann setzen als Membervariable, ist es so nur sehr schwer zu mocken und entsprechend schwer zu testen.