Richtlinie: Strukturierung des Implementierungsmodells für J2EE-Anwendungen
Diese Richtlinie erläutert, wie das Implementierungsmodell für eine J2EE-Anwendung strukturiert wird.
Beziehungen
Hauptbeschreibung

Einführung

Es wird vorausgesetzt, dass Sie vertraut sind mit den grundlegenden Informationen über J2EE als Technologieplattform, die unter Konzept: Überblick über Java 2 Platform Enterprise Edition (J2EE) und Konzept: Zuordnung von Design zu Code erläutert werden. Einige der Konzepte in dieser Richtlinie gehören zu UML 1.4, obwohl Sie sie möglicherweise im Kontext eines auf UML 1.3-basierenden Plug-in verwenden. Falls Sie etwas nicht verstehen, schlagen Sie die Informationen zu den fraglichen Punkten in den beiden UML-Spezifikationen nach.

Strukturierung des Implementierungsmodells

Aufgabe: Implementierungsmodell strukturieren beschreibt, wie eine Implementierungsmodellstruktur erzeugt wird, die sich zwar stark an der Struktur des Designmodells ausrichtet, gleichzeitig aber alle Einschränkungen widerspiegelt, die die Entwicklungsumgebung auferlegt, und eine parallele Entwicklung und schrittweise Integration unterstützt.

Die Struktur des Implementierungsmodells für eine J2EE-Anwendung ist abhängig von der Entwicklungs- und Implementierungsumgebung. Im allgemeinen gibt es innerhalb eines J2EE-Implementierungsmodells jedoch vier potenzielle Strukturen:

  • Implementierungsunterstützung (J2EE-Module und Implementierungsdeskriptoren)
  • Virtuelle Verzeichnisstruktur (JSPs, HTML-Seiten)
  • Java-Verzeichnis für Elemente, die auf einem Webserver implementiert werden (Servlets, JavaBeans)
  • Java-Verzeichnis für Elemente, die auf einem EJB-Anwendungsserver implementiert werden (EJBs)

Implementierungssubsysteme modellieren

Die Implementierungssicht im Arbeitsergebnis: Softwarearchitekturdokument bietet einen abstrakten Überblick über das Implementierungsmodell. Dazu gehört die Angabe der Implementierungssubsysteme. In einer J2EE-Anwendung sind die Implementierungssubsysteme möglicherweise nicht nur einem einzelnen Verzeichnis im Dateisystem oder einem einzelnen Paket im Modell zugeordnet, weil das Implementierungssubsystem Nicht-Java-Elemente aus einem Modell (z. B. JSPs und HTML-Seiten) und Java-Elemente aus einem anderen Modell enthalten kann. Eine mögliche Strategie zur Behandlung einer solchen Situation sieht vor, in jedem Modell eine parallele Paketstruktur zu verwenden. Pakete mit demselben Namen werden in jedem Modell implizit zugeordnet.

Ein Implementierungssubsystem stellt normalerweise die Implementierung für eine einzelne implementierbare Implementierungsdatei (eine JAR-, WAR- oder EAR-Datei) bereit. In diesem Fall können die Implementierungssubsysteme angegeben werden, indem die implementierbaren Dateien angegeben werden.

Eine Darstellung der physischen Elemente, bestehend aus den Implementierungsverzeichnissen und Implementierungsdateien, kann in jedem Implementierungssubsystem enthalten sein. Es können auch logische Elemente vorhanden sein, bestehend aus Klassen, Komponenten, Paketen usw., die den Elementen des Arbeitsergebnis: Designmodells entsprechen, aber ein präzises Modell des Quellcodes sind (ein Round-trip-Engineering-Modell). Unter Konzept: Zuordnung von Design zu Code finden Sie nähere Informationen zu den Beziehungen zwischen Designmodell und Implementierungsmodell.

Round-trip-Engineering-Modelle zeigen eine genaue Darstellung des Quellcodes. In J2EE stellt jedes Paket in einem Java-Modell ein Java-Paket dar, jede Klasse eine Java-Klasse usw. Allerdings muss das Round-trip-Engineering-Modell häufig durch zusätzliche Informationen ergänzt werden. Dazu gehört Folgendes:

  • Diagramme mit Informationen, die nicht automatisch als Teil des Round-trip-Engineering erzeugt werden
  • Abstraktionen des Modells auf höherer Ebene

Das Designmodell stellt eine Abstraktion der Klassen, Komponenten, Pakete usw. dar. Allerdings werden eventuell auch Abstraktionen auf höherer Ebene oder zusätzliche Diagramme für die physischen Elemente (Dateien und Verzeichnisse) benötigt. Diese werden in den nachfolgenden Abschnitten erläutert.

Implementierungsverzeichnisse modellieren

Beim Round-trip-Engineering wird normalerweise nur eine Untergruppe der in der Entwicklungsumgebung erforderlichen Verzeichnisse verwendet. Zusätzliche Verzeichnisse werden häufig benötigt, um Testartefakte, Deployment-Einheiten, die Dokumentation usw. zu verwalten. Im allgemeinen ist keine Modellierung erforderlich, weil die Verzeichnisse als Teil des Dateisystems angezeigt werden können.

Implementierungsdateien modellieren

Implementierungsdateien werden im allgemeinen nicht modelliert, sofern nicht eine entsprechende Unterstützung durch ein Round-trip-Engineering-Tool vorhanden ist oder sofern nicht eine Abhängigkeit gezeigt werden muss, die nicht offenkundig ist.

Normalerweise gibt es für jede Java-Schnittstelle oder Java-Klasse eine .java-Datei und für jede .java-Datei eine kompilierte .class-Datei. Daher ist die Modellierung dieser Dateien nicht von großer Bedeutung.

In J2EE enthält ein Subsystem normalerweise eine oder mehrere Archivierungsdateien (JAR-, WAR- oder EAR-Dateien).

Archivierungsdateien werden korrekt als Zusammensetzungsbeziehung zwischen den Archivierungsdateien und den darin enthaltenen Dateien modelliert. Werden jedoch kompilierte .class-Dateien zu einer JAR-Datei kombiniert, kann es sinnvoller sein, eine Abhängigkeit der JAR-Datei von den Klassen und Schnittstellen darzustellen, die sie letztlich implementiert.

Wenn das Implementierungssubsystem nur eine JAR-Datei erzeugt, dann ist möglicherweise überhaupt keine Modellierung erforderlich, insbesondere dann, wenn davon ausgegangen werden kann, dass alle implementierbaren Dateien im Implementierungssubsystem Teil der JAR-Datei sind.

Überlappende Archivierungsdateien

Es ist möglich, wenn auch im allgemeinen nicht zu empfehlen, zwei Archivierungsdateien zu definieren, die teilweise dieselben Elemente enthalten. Beispielsweise können zwei EAR-Dateien teilweise dieselben EJB JARs enthalten, oder zwei EJB JARs könnten dieselben EJBs enthalten, aber unterschiedliche Implementierungsdeskriptoren verwenden.

Es ist am besten, wenn sich die Archivierungsdateien nicht überlappen, um eine enge Zugehörigkeit zwischen den Implementierungssubsystemen und den implementierbaren Archivierungsdateien beizubehalten. Wenn jedoch Überlappungen nötig sind, kann es hilfreich sein, diese zusammen mit einer Begründung für diese Überlappungen zu modellieren.