08/2008 - KaffeeKlatsch
08/2008 - KaffeeKlatsch
08/2008 - KaffeeKlatsch
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Umgemodelt<br />
Das Potential von POJOs für die<br />
Modellierung mit UML<br />
von Lars Fiedler<br />
M<br />
it der Einführung<br />
von Annotationen<br />
in Java 5 und der<br />
Rückbesinnung<br />
auf die guten,<br />
alten Java-Objekte<br />
(POJOs) sind viele APIs wieder<br />
einfacher geworden. Dieser Artikel<br />
beschäftigt sich damit, dass mit POJOs<br />
auch die Modellierung sehr vereinfacht<br />
werden kann, was bisher leider kaum<br />
beachtet wird.<br />
Haben sie sich in ihrer Jugend auch gewundert, warum in<br />
den Indianerfilmen vor wichtigen Entscheidungen immer<br />
die konservativen Alten befragt werden? Heute finde<br />
ich das gar nicht mehr so schlecht, da alte Weisheiten oft<br />
auch dann gültig bleiben, wenn man die Begründung gar<br />
nicht mehr kennt. Wenn sich jedoch die Rahmenbedingungen<br />
ändern, lohnt es sich alles neu zu überdenken.<br />
Diskrepanz zwischen Design und Diagramm<br />
Früher einmal habe ich ein Persistenz-Framework verwendet,<br />
das zu jeder Entität einen Container und ein<br />
Interface hat. Entität und Container implementierten<br />
das Interface. Der Container delegiert alle Methoden-<br />
aufrufe an die Entität, realisiert aber noch zusätzlich so<br />
Dinge wie z. B. lazy loading. Haben Sie gerade versucht,<br />
sich das bildlich vorzustellen? Dann dürfte Ihnen Abbildung<br />
1 helfen. Das ist auch der Grund, warum wir<br />
gerne graphisch modellieren: Wir Menschen erkennen<br />
Zusammenhänge oft sehr viel schneller, wenn sie bildlich<br />
dargestellt werden.<br />
KundeContainer<br />
Abbildung 1: Design einer Entität<br />
<br />
KundeInterface<br />
Kunde<br />
Ich finde übrigens, dass dies ein sehr gutes Design ist.<br />
Und es ist auch sehr wichtig diese Information in einem<br />
Diagramm darzustellen: Für jede Entität gibt es ein Interface<br />
und einen Container. Dennoch gibt es dabei eine<br />
Sache, die niemandem gefallen kann. Modelliert man<br />
mehrere Entitäten (Abbildung 2), so wird das ganze sehr<br />
schnell unübersichtlich. Eigentlich wäre eine Darstellung<br />
wie in Abbildung 3 übersichtlicher. Diese stellt die konzeptionellen<br />
Beziehungen der Entitäten dar, aber nicht<br />
das tatsächliche Design mit Interfaces und Container.<br />
Für welche Darstellung sollte man sich also entscheiden?<br />
Klar, natürlich für Abbildung 3, denn das Muster,<br />
das allen Entitäten eigen ist (Entität, Container, Interface)<br />
wurde ja schon in Abbildung 1 dargestellt. Jede weitere<br />
Darstellung dieses Musters wäre nur redundant.<br />
<br />
KundeInterface<br />
<br />
AdresseInterface<br />
KundeContainer<br />
Kunde<br />
AdresseContainer<br />
Adresse<br />
Abbildung 2: Design mehrerer Entitäten<br />
Seite 14 <strong>KaffeeKlatsch</strong> Jahrgang 1 / Nr. 8 / August 20<strong>08</strong>