[UML] Generalisierung im Objektdiagramm?

[Aldaron]

Servus...
Ich hab in UML ein Klassendiagramm.
Unter anderem mit ner Generalisierung also
Klasse "Konto" hat 2 Unterklassen "Girokonto" und "Sparkonto":

+--------------------------+
| Konto............................|
+--------------------------+
.......^......................^
.......|.......................|
+-----------+...+-----------+
| Sparkonto..|...| Girokonto...|
+-----------+...+-----------+

(wehe jemand lacht über die Zeichnung ;) )

So jetz will ich das im Objektdiagramm darstellen. Wie mach ich das denn?
Soll ich da ein Objekt von Konto, oder Sparkonto "erzeugen"?

[eViL_oNe]

das hängt wohl von der Anwendung ab

ich würde dazu tendieren, Konto abstrakt oder gar als Interface zu definieren und dann nur noch die spezialisierten Klassen zu instanzieren. Ich bin kein besonderer Fan von Ableitungswulst daher würde ich sogar das letztere empfehlen ;) ;) ;)

[Schorsch]

Ich würde das über Komposition lösen.

So kann man sich die verschiedenen Kontotypen dynamisch zur Laufzeit zusammensetzen lassen, wodurch man das ganze über ein ini-File oder eine Datenbank parametrieren kann.

Beispiel:

Klasse Girogebühr // Enthält den Kostensatz. (Was kosten Überweisungen, Jahresgebühr für das Konto)

Klasse Sparzins, Girozins ( Wie wird das Guthaben verzinst, was kostest des Dispokredit, ist Dispo überhaupt möglich?)

etc...


das Ganze wird dann einfach zusammengesetzt.

Beispiel:

Konto *konto = new Konto(new Girogebuehr(), new Girozins());

if (konto->uberziehungMoeglich) {
cout << "Zinssatz für Überziehung beträgt: " << konto->getDispoZins();
}


Wobei der Konstruktor nur Interfaces erwartet und keine konkreten Objekte....

Die Implementierung dann so in der Art:


BOOLEAN Konto::uberziehungMoeglich()
{
return this->zinsklasse->uberziehungMoeglich();
}

double Konto::getDispoZins()
{
return this->zinsklasse->getDispoZins();
}

double Konto::getJahresgebuehr()
{
return this->gebuehrKlasse->getJahresgebuehr();
}



Dadurch solltest du das ganze recht flexibel zur Laufzeit zusammensetzten können und implementiertst nicht für eine einzige Bank sondern bietest eine Schnittstelle, so dass nahezu alle Banken diese Software einsetzen können......unabhängig davon wie die Konten bei denen aufgebaut sind.


EDIT: Ich sehe gerade das die Frage ja ne ganz andere war :D: Wenn die Methoden in beiden Klassen identisch sind würd ich Konto nehmen. Wenn die Klassen unterschiedliche Methoden haben jeweils ein Diagramm für beide Klassen.

[eViL_oNe]

im Prinzip eine nette Lösung für Kompositionen, sogar mit Dependency Injection -- sehr löblich, das erleichtert einem Unit-Tests ungemein ;)

zur eigentlichen Problemlösung:

erzeuge Instanzen von den spezialisierten Klassen, die du nach außen mit der Schnittstelle Konto ansprichst. Prinzipiell könnte man hier sogar eine Factory-Klasse/Methode vorsehen:

statt

Konto konto = new GiroKonto();

Konto konto = Konto.createGiroKonto();

oder

Konto konto = KontoFactory.createGiroKonto();

oder (falls die Factory selber eine Instanz ist):

KontoFactory factory = ...;
...
Konto konto = factory.createGiroKonto();

auf diese Art und Weise braucht man nach außen hin gar nicht die interne Implementierung eines Kontos zu kennen. Auch kann man dadurch komplexe Erzeugungsvorgänge wie das Lesen aus einer Datenbank, das individuell auf einen Benutzer zugeschnittene Erzeugen eines neuen Kontos unter Berücksichtigung von speziellen Ratings etc vor dem Verwender verbergen.

[etuli]

> So jetz will ich das im Objektdiagramm darstellen. Wie mach ich das denn?

Im Objektdiagramm wird die konkrete Klasse angegeben und die Attribute und Links (konkrete Assoz.) aller Oberklassen dargestellt. Das eine Vererbung vorliegt kannst du mit einer Generalisierungsbez. darstellen, dies ist aber idR. nicht notwendig und das Vermischen von Elementen verschiedener Diagramme keine meist keine gute Praxis.

[Aldaron]

Danke, das wollt ich wissen. ;)
Implementierung bzw. Umsetzbarkeit ist in dem Fall nicht so wichtig, ich muss nur die Diagramme erstellen (DV-Abi nächste Woche ;))