Einführung
Diese Richtlinien ergänzen Richtlinie: Designsubsystem durch spezielle
Anleitungen für die J2EE-Anwendungsentwicklung. Es wird empfohlen, dass Sie den Abschnitt "Richtlinie: Designsubsystem"
lesen, bevor Sie diese J2EE-spezifische Richtlinien lesen. Diese Richtlinien gelten für Designsubsysteme mit größerer
Differenzierung als einzelne EJBs. Richtlinien zu EJBs finden Sie unter Richtlinie: Enterprise JavaBean (EJB).
Beachten Sie außerdem, dass ein Anwendungsclient als spezialisiertes Designsubsystem gilt. Siehe hierzu Richtlinie: J2EE-Anwendungsclient.
Designsubsysteme entwickeln
Wenn ein Subsystem zum ersten Mal festgelegt wird, kann es anfangs technologieneutral sein, d. h., es kann durch
Schnittstellen spezifiziert sein, durch eine Textbeschreibung und durch einige Zustandsmaschinen, die das erwartete
Verhalten der Operationen beschreiben. Solche technologieneutralen Subsysteme werden jedoch in der Regel zu
technologiespezifischen Darstellungen entwickelt.
Nachfolgend wird anhand eines Beispiels gezeigt, wie ein technologieneutrales Designsubsystem zu einem
technologiespezifischen Subsystem entwickelt wird.
Subsystemspezifikation (Blackbox-Sicht des Subsystems)
Eine Subsystemspezifikation kann ursprünglich so modelliert werden, dass sie über abstrakte UML-Schnittstellen verfügt.
Betrachten Sie das in Abbildung 1 gezeigte vorläufige Design eines Kundensubsystems.
Abbildung 1: Vorläufiges Design eines Kundensubsystems
Durch weitere Definition werden ICustomerMgt außerdem Operationen wie "getCustomerDetails" und "setCustomerDetails"
zugeordnet.
Während das Design allmählich detaillierter wird (Aufgabe: Subsystemdesign), werden
diese abstrakten Schnittstellen nach und nach durch sprach- und technologiespezifische Elemente ersetzt. (Es ist auch
möglich, das abstraktere Modell des Subsystems beizubehalten, beispielsweise wenn dasselbe Design in mehreren Sprachen
oder Technologien implementiert werden muss. Eine Erläuterung dieser Möglichkeiten finden Sie unter Konzept: Zuordnung von Design zu Code.) Das zugehörige Design (Anwendungsfallrealisierung) wird aktualisiert, um die Schnittstellenänderungen
widerzuspiegeln.
In diesem Beispiel ist Abbildung 2 eine Blackbox- oder Spezifikationssicht des Kundensubsystems. Im nachfolgenden
Design wurde festgelegt, dass das Kundensubsystem eine Entity-EJB sein soll. Das vorläufige Designsubsystem wird wie
folgt in EJB-Schnittstellen umgewandelt:
-
ICustomerMgt =>
-
CustomerHome ?EJBEntityHomeInterface?
-
ICustomer =>
-
Customer ?EJBRemoteInterface?
Abbildung 2: Blackbox-Sicht des Kundendesignsubsystems
Die vom Designsubsystem gezeigten Schnittstellen können reguläre Java-Schnittstellen, EJB-Schnittstellen (z. B.
Java-Schnittstellen), EJB-Schnittstellen (ferne oder Home-Schnittstellen) oder sogar eine oder mehrere delegate-
oder access-Klassen sein, die die Existenz einer oder mehrere EJBs vollständig verbergen. Beachten Sie, dass all
dies, einschließlich der Java-Schnittstellen, als UML-Klassen und nicht als UML-Schnittstellen modelliert wird (siehe
hierzu Richtlinie: Schnittstellen für J2EE-Anwendungen).
Beispielsweise wird eine Session-Bean häufig als Fassade für den Zugriff auf eine Gruppe von eng zusammengehörigen
Entity-Beans verwendet. In diesem Fall würden nur die Schnittstellen der Session-Bean aus dem Subsystem exportiert
werden.
Nachrichtengesteuerte Beans konsumieren Nachrichten asynchron von einer Zieladresse (oder einem Endpunkt). Daher könnte
eine Zieladresse auch als "Schnittstelle" für ein Designsubsystem fungieren, das nachrichtengesteuerte Beans enthält.
Beachten Sie, dass lokale Schnittstellen von anderen eng miteinander verbundenen EJBs innerhalb desselben
Designsubsystems verwendet werden und deshalb in der Realisierung von Subsystemen häufiger erscheinen als in den
sichtbaren Schnittstellen, die von einem Subsystem gezeigt werden.
Nähere Informationen zu Schnittstellen in einer J2EE-Anwendung finden Sie unter Richtlinie: Schnittstellen für J2EE-Anwendungen.
Nähere Informationen zum Modellieren von EJBs finden Sie unter Richtlinie: Enterprise JavaBean (EJB).
Subsystemrealisierung (Whitebox-Sicht des Subsystems)
Designsubsysteme sollten nur das zeigen, was die Clients benötigen. Daher ist die Klasse, die eine EJB implementiert,
für das Subsystem privat und ein logischer Teil der Subsystemrealisierung. Die Subsystemrealisierung könnte wie folgt
aussehen:
-
eine Gruppe von EJBs und Klassen, die zusammenarbeiten und die von einer oder mehreren sichtbaren delegate-
oder access-Klassen verborgen werden.
-
eine einzelne EJB mit keinen anderen Klassen, die mit ihr zusammenarbeiten
Wenn das vorherige Beispiel eines Kundensubsystems fortgesetzt wird, dann beinhaltet die Realisierung des Subsystems
Folgendes:
-
CustomerEntityEJB (Komponente) ?EJBEntityBean?
-
CustomerBean ?EJBImplementation?
-
zusätzliche Helper-Klassen
Abbildung 3 zeigt eine Whitebox-Sicht (d. h. im Subsystem) des Designsubsystems. Beachten Sie, dass die
EJB-Klassen gemäß der Beschreibung in Richtlinie: Enterprise JavaBean (EJB) modelliert
wurden. Die interne Sicht des Subsystems wird als Subsystemrealisierung bezeichnet. In dieser Sicht werden
Entscheidungen gezeigt, die für die Clients nicht sichtbar sind. Beispielsweise greift in dieser Realisierung des
Subsystems eine DAO-Klasse (Data Access Object) mit der JDBC API auf persistente Daten zu. (In einem anderen Design
könnte eine über über Container realisierte Transaktionspersistenz verwendet werden.) Nähere Informationen zu
DAO-Klassen finden Sie unter Richtlinie: Enterprise JavaBean (EJB).
Abbildung 3: Whitebox-Sicht des Kundendesignersubsystems
|