Richtlinie: Design der Subsysteme für J2EE-Anwendungen
Diese Richtlinie erläutert das Design von Subsystemen für eine J2EE-Anwendung.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

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. 

Im Begleittext beschriebenes Diagramm.

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?

Im Begleittext beschriebenes Diagramm.

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).

Im Begleittext beschriebenes Diagramm.

Abbildung 3: Whitebox-Sicht des Kundendesignersubsystems