home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Übersicht

Nachdem die Komponenten identifiziert sind, gilt es, das Innenleben der Komponenten zu modellieren. Das beinhaltet alle Klassen und deren Beziehungen. UML Klassen- und Paketdiagramme helfen, dieses statische Verhalten zu entwerfen. Im Gegensatz zur Spezifikationsphase liegt der Fokus nicht auf dem Fachklassen (diese werden als existent vorausgesetzt) sondern auf den Geschäftsklassen und deren genauen Beziehungen untereinander wie Vererbung, Schnittstellen usw. EJBs sind ein Beispiel dafür, wie für eine Fachklasse viele Geschäftsklassen entworfen werden müssen.

Für das Modellieren des dynamischen Verhaltens bedient man sich der Sequenz- oder Aktivitätsdiagramme. Damit lassen sich die Reihenfolge des Aufrufs von Methoden ebenso beschreiben wie der Ablauf des Programmcodes innerhalb der Methoden.

Assoziationen

Die in der Spezifikationsphase bereits begonnene Beschreibung der Assoziationen wird weiter verfeinert. So gilt es die 1:1-, 1:n- und n:m-Beziehungen zu differenzieren. Je nach eingesetzter Technologie müssen die n:m-Beziehungen über ein "Link-Objekt" in zwei 1:n-Beziehungen aufgelöst werden.

Anmerkung:

In Java kann eine 1:1 Beziehung ausgedrückt werden durch :

 

aClassA.setClassB(aClassB);

 

Im Fall der 1:n-Beziehung könnte Folgendes implementiert werden:

 

aClassA.addClassB(aClassB); //oder
aClassA.addClassBBy(aClassB, key);
aClassA.getClassBBy(key);
aClassA.remoreClassBBy(key);
Iterator iterator = aClassA.createClassBIterator();

 

Als nächstes kann die Navigierbarkeit eingeschränkt werden, was in UML durch einen Pfeil ausgedrückt wird, der impliziert, das die umgekehrte Richtung nicht mehr navigierbar ist. D.h. es gibt keinen Code mehr, der von der einen Klasse auf die andere Klasse zugreift.

Auch die Entscheidung darüber, ob die Assoziation eine assoziative Komposition oder assoziative Aggregation ist, sollte hier gefällt werden.

Vererbung

Die Vererbung sollte dann eingesetzt werden, wenn damit eine wirklich existente Hierarchie abgebildet werden soll, z.B. wenn ein Geschäftskunde eine besondere Ausprägung eines Kunden ist. Ansonsten sollte geprüft  werden, ob nicht Interfaces oder Assoziationen geeigneter sind.

Java erlaubt keine Mehrfachvererbung. Es ist also nicht möglich, dass eine Klasse von zwei anderen Klassen erbt. Hingegen sind mehrstufige Vererbungshierarchien möglich. Es wird jedoch empfohlen, nur von abstrakten Klassen zu erben, d.h. die konkrete Implementierung nur auf unterster Ebene vorzunehmen.

In diesem Kontext sei der Unterschied zwischen überladen und überschreiben einer Methode verdeutlicht: Bei der Vererbung kann eine Methode gleichen Namens und gleicher Signatur der vererbenden Klasse durch die erbende Klasse überschrieben werden. Unter Überladen versteht man hingegen, in einer Klasse zwei Methoden gleichen Namens aber mit unterschiedlicher Signatur zu haben.

Interfaces

Den Schnittstellen, Interfaces, kommt besonders im Hinblick auf eine komponentenorientierte Entwicklung eine hohe Bedeutung zu. Sie ermöglichen die Abstraktion von einer konkreten Implementierung. D.h. die Implementierung kann ausgetauscht werden, ohne dass die Komponente, welche die Schnittstelle nutzt, davon betroffen ist.

In UML gibt es zwei Darstellungen, um Interfaces zu beschreiben. Zum einen verwendet man die Lollipop, zum anderen die klassische Darstellung mit Pfeilen. Die folgende Abbildung entstammt www.jeckle.de.