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