UML - Klassendiagramm

[CEric]

Hallo zusammen,
ich soll in einem kleinen Projekt ein Anwendungssystem erstellen mit dem es möglich ist Rechnungen zu erstellen.
Aktuell bin ich beim Softwareentwurf, also genauer dem Klassendiagramm.
Ich habe momentan noch meine Probleme, da ich u.a. mehrere Datenbanken mit JDBC an mein System anbinden muss.
JDBC an sich ist kein Problem.
Was mir Probleme bereitet sind die Schnittstellen im Klassendiagramm.
Bsp.:
Es gibt eine SQL-Datenbank die alle Kunden enthält (MasterData) und auf die ich lesenden Zugriff will und es muss möglich sein einen Kunden anhand der ID zu suchen oder aus einer Liste auszuwählen.
Ich hätte jetzt ein Inteface IKunde, das mir den DB-Zugriff verschafft und dann die Klasse KundeImpl die dieses Interface realisiert!?
Muss ich in der Klasse KundeImpl die Attribute deklarieren die in der Datenbank hinterlegt sind?!
Danke!

 

[stg]

Zunächst einmal: Brauchst du ein Interface IKunde? Gibt es mehr als eine Implementierung davon? Wenn nein, dann nenne deine Klasse doch einfach "Kunde" und lass das Interface weg. Eine solche zusätzliche Abstraktion ist fehl am Platz, wenn sie gar nicht benötigt wird. Später kannst du dann, falls eine weitere Implementierung benötigt wird, ohne großen Aufwand ein Interface aus der Kunden-Klasse extrahieren.

Dann: Denke zunächst einmal gar nicht an die Datenbank-Anbindung, sondern an die Anforderungen bzgl deiner Geschäftslogik. Wie müssen deine Typen aussehen, damit die gewünschten Anforderungen erfüllt werden können?
Anschließend kannst du Service-Klassen entwerfen, die entsprechend der Anwendungsfälle auf diesen Typen agieren. z.B. die Suche eines Kunden nach seiner ID oder Name, das erstellen eines neuen Kunden usw.. Diese Service-Klassen haben die Information darüber, wo und wie nach diesen Daten zu suchen ist. Um z.B. einen Kunden zu suchen kannst du Daten aus einer oder mehreren Tabellen deiner Datenbank abfragen und daraus ein Kunden-Objekt erstellen, welches du an den Client deiner Service-Klasse auslieferst. Eventuell hilft dir dabei auch ein ORM Framework deiner Wahl.

Weitere Details später, damit hast du denke ich vorerst genug zu tun. Melde dich wieder, wenn etwas unklar geblieben ist oder du soweit fertig bist, dann man den nächsten Schritt gehen kann

 

[CEric]

Das Problem mit dem Interface kommt bei mir vor allem wegen dem Klassendiagramm auf. Wir sollen das System mittels 3-Schichten-Architektur erstellen. Im Klassendiagramm müsste ich dann ja die Schnittstelle zur D-Schicht und eigentlich auch zur K-Schicht darstellen. Das oben genannte Interface war also als Schnittstelle zwischen A- und D-Schicht gedacht!

 

[stg]

Was ist denn bei dir A D und K?

Darstellung, Datenbank, Domäne ... ?
Anwendung, .... ?
K... ?

Was ich bei einer 3-Schichten-Architektur üblicherweise erwarten würde, ist eine Trennung zwischen
Darstellung
Geschäftslogik
Datenhaltung

In dem von mir geschildertern Fall wäre "Kunde" in der Geschäftlogik anzusiedeln. Die DarstellungsSchicht weiß (und das ist legitim), wie das Objekt aufgebaut ist, aber nicht, wie und von wem es erzeugt wird. Dafür brauchst du kein extra Interface, du musst dich nur an Grundregeln der Kapselung usw halten. Ein Interface "Kunde" bringt dir erst dann einen Vorteil, wenn es wirklich verschiedene Implementierungen gibt. Aber das kannst du nachträglich in der Geschäftslogik ändern, ohne dafür in der Darstellungs-Schicht etwas ändern zu müssen.

 

[CEric]

Ja genau, Anwendungslogik, Datenhaltung und Kommunikationsteil!
Ich habe also meine Datenbank und meinen Kunden. Im Klassendiagramm also ein Interface IKunde das als Schnittstelle zwischen Datenbank und Anwendungslogik dient. In der Klasse kann ich dann zB Kunden anlegen etc...

 

[stg]

Mir ist nach wie vor nicht klar, was du mit Kommunikations-Schicht meinst.
Üblicherweise spricht man davon im Rahmen der verwendeten Netzwerkprotokolle, Zertifikaten usw..

Die "Kommunikation" in einer mehrschichtigen Architektur besagt nur, dass eine übergeordnete Schicht mit der darunterliegenden Schicht kommunizieren kann, aber nicht umgekehrt.

Und nocheinmal: Kümmere dich jetzt noch nicht um die Schnittstelle zwischen Datenbank und Geschäftslogik. Das macht erst Sinn, wenn du weißt, wie dein Geschäftsmodel aussehen muss. Und es ist nach wie vor nicht nötig, dass du extra ein Interface IKunde erstellst, wenn es nur eine Implementierung gibt. Solange ist die Implementierung selbst die Schnittstelle bzw dein "Interface". Für die Darüberliegende Schicht macht das keinen Unterschied, wenn du dich an Kapselung, Einschränkungen der Sichtbarkeitsbereiche von Methoden und Feldern usw hältst...

Kunde bzw IKunde ist dabei die Schnittstelle zwischen Darstellung und Anwendungsschicht, nicht zwischen Anwendungsschicht und Datenhaltung (das kommt erst später, ggfls hast du hier sogar die gleichen Schnittstellen, das ist oft der Fall, aber bei weitem nicht immer)

Und nochmal, um es zu betonen: Kümmere dich um die Verbindung zwischen Datenhaltung und Anwendung erst später! Denke zunächst nur an die Anwendungslogik und wie deine Objekte hier aussehen müssen!
z.B: Eine Rechnung hat Rechnungsposten, diese Rechnungsposten bestehen aus einer Stückzahl, einem Preis, einem Artikel usw.... Außerdem ist die Rechnung einem Kunden zugeordnet, es gibt ein Rechnugsdatum, Informationen, ob die Rechnung (teilweise) bezahlt ist oder nicht (und wann) usw... Hier kannst du dich richtig austoben. Vergiss alles andere drumherum und baue ein sauberes Geschäftsmodell hinsichtlich OOP auf. Alles weitere kommt später.