Überblick
Dieser Toolmentor setzt voraus, dass Sie die Ausgangsstruktur des Implementierungsmodells entsprechend den im White
Paper Model Structure Guidelines for RSx beschriebenen Richtlinien definiert haben. Mit
den Schritten in diesem Tool kann diese Ausgangsstruktur verfeinert werden.
In diesem Toolmentor werden die folgenden Schritte ausgeführt:
Es wird die modellorientierte Entwicklung (Model Driven Development, MDD) empfohlen. (Nähere Informationen finden Sie
im Abschnitt MDD (Model
Driven Development) und MDA (Model Driven Architecture)). Wenn das Entwicklungsteam diesen Ansatz verfolgt,
orientiert sich das Implementierungsmodell sehr stark am Aufbau des Designmodells. Nach der Ermittlung der
Implementierungssysteme sollten diese als Pakete oder Subsysteme in das Designmodell modelliert werden. Generell
sollten Sie bei der Ermittlung von Paketen im Designmodell daran denken, wie Sie sie den toolspezifischen Projekten
zuordnen können. Große Subsysteme werden normalerweise auf eigene Projekte abgebildet, während kleinere Pakete auf
Quellenordner in Projekten abgebildet werden. Nähere Informationen finden Sie im White Paper Model Structure Guidelines for RSx in den Abschnitten, in denen die
Projektstrukturen und die interne Organisation der Implementierungs- und Designmodelle behandelt werden.
Die Implementierungssicht kann durch Verwendung von <<Perspective->>-Paketen
definieren. Diese enthalten Diagramme, die die Abhängigkeiten zwischen den Subsystemen verdeutlichen. Je nachdem,
welche Art der Umsetzung Sie auf das Designmodell anwenden, können Abhängigkeiten zwischen den Paketen und Subsystemen,
die Sie definieren, möglicherweise auf 3GL-Importdeklarationen und Projektabhängigkeitsdeklarataionen in den Metadaten
des Projekts abgebildet werden.
Nach der Codegenerierung können Sie detailliertere UML-Diagramme erstellen, die die Konstrukte auf
Implementierungsebene und ihre Beziehungen zeigen. Erstellen Sie hierzu in den Projekten Klassendiagramme und ziehen
Sie die Implementierungsartefakte darauf. Nähere Informationen finden Sie in der Onlinehilfe in den Themenbereichen zu
UML Visual Editor for Java.
Wenn Referenzen auf bestimmte Klassen, Interfaces, Pakete etc. aus einer Codebibliothek in Ihrem Implementierungsmodell
dargestellt werden sollen, können Sie sie mit den Codevisualisierungsfunktionen des Produkts erstellen. Die folgenden
JAR-Dateien enthalten Dateien, die Sie für das Design und die Entwicklung von J2EE-Anwendungen verwenden können:
-
j2ee.jar, jsf-api.jar, soap.jar, soap-sec.jar (alle im Verzeichnis lib)
-
core.jar, xml.jar, security.jar (alle im Verzeichnis java\jre\lib)
Wenn Sie ein Element aus einer dieser Bibliotheken in Ihrem Modell referenzieren müssen, führen Sie die folgenden
Schritte aus:
-
Erstellen Sie ein neues Java-Projekt und fügen Sie den Bibliotheken Referenzen hinzu.
-
Öffnen Sie das Diagramm, dem Sie das visualisierte Element hinzufügen möchten.
-
Wechseln Sie in die Perspektive "Java".
-
Suchen Sie das Element (Paket, Klasse, Interface, etc.), das Sie Ihrem Modell hinzufügen möchten.
-
Klicken Sie mit der rechten Maustaste auf das Element und wählen Sie den Eintrag "Visualisieren > Zu aktuellem
Diagramm hinzufügen" aus.
Wenn Sie die Projekte und Pakete, in denen der Code und die zugehörigen Dateien gespeichert werden sollen, in einem
Modell darstellen möchten, kann die Erstellung eines Implementierungsübersichtsmodells vor der Codegenerierung sinnvoll
sein. Nähere Informationen finden Sie im White Paper Model Structure Guidelines for RSx in den Abschnitten zum Implementierungsmodell.
Nachfolgend werden die Schritte beschrieben, die Sie bei der Anpassung der Implementierungssubsysteme unterstützen:
-
Verwenden Sie bei der Ermittlung problematischer Subsysteme (z. B. zyklische Abhängigkeit) Folgendes:
-
-
Themen- und Anzeigediagramme
-
Architekturerkennung
-
Codeüberprüfung/Strukturelle Codeanalyse
-
Erstellen Sie ein neues Subsystem.
-
Verschieben Sie die ermittelten Elemente in das neue Subsystem.
-
Zeichnen Sie neue Abhängigkeiten.
In einer MDD-Umgebung entsprechen die Abhängigkeiten im Implementierungsmodell sehr genau den Abhängigkeiten, die
explizit oder implizit im Designmodell definiert sind. Die Spezifikationen werden durch die Umsetzungen der
Codegenerierung bestimmt, die auf das Designmodell angewendet wurden.
Neben dem Eingabemodell gibt es noch andere Artefakte, die für die Durchführung einer Umsetzung notwendig sind. Für
einen Umsetzungsprozess sind eine Umsetzungsdefinition und die entsprechenden Umsetzungsregeln erforderlich.
Eine Umsetzungsregel beinhaltet eine Beschreibung, die vom Umsetzungsprozess verwendet wird, um ein Element im
Quellenmodell in mehrere Elemente oder kein Element im Zielmodell zu konvertieren. Sie ordnet Elemente einer
Abstraktionsebene der ausführlicheren Entsprechung auf einer niedrigeren Abstraktionsebene zu.
Wenn Sie die manuelle Umsetzung verwenden, müssen Sie sicherstellen, dass Sie Ihren Entwicklern genaue Anleitungen für
die Umsetzung des Designmodells in Code bereitstellen. Sie müssen eine Umsetzungsdefinition zur Verfügung stellen, die
eine Reihe von Umsetzungsregeln enthält. Diese zusätzlichen Anleitungen können folgendermaßen aussehen:
-
Elemente aus dokumentierten Profilen
-
Notizen im Modell
-
Zusätzliche Informationen im Softwarearchitekturdokument
-
Entwicklungsrichtlinien
Wenn Sie ein Implementierungsübersichtsmodell verwenden, können Sie hier die erwarteten Abhängigkeiten zwischen den
Projekten und Paketen anzeigen. Dies kann hilfreich bei der Identifizierung von Anforderungen für den System-Build
sein. (Nähere Informationen finden Sie im White Paper Model Structure Guidelines for RSx.)
In einer MDD-Umgebung können, je nach dem, welche Art der Umsetzung für das Designmodell verwendet wird, verschiedene
implementierbare Artefakttypen generiert werden. Aus Elementen wie z. B. <<Steuerungs>>- und
<<Entity>>-Klassen können Session- und Entity-EJBs für ein J2EE-Ziel generiert werden, einschließlich Code
für die Implementierungsklassen, Interfaces und Deployment-Deskriptorinhalt. Hierbei werden EJBs EJB-JARs zugeordnet
und diese JARs dann EARs zugeordnet.
Sie können implementierbare Artefakte auf Konzeptebene unter Verwendung eines Implementierungsmodells modellieren. Wenn
Sie sich hierfür entscheiden, modellieren Sie sie mit UML-Knoten und Artefakten. Zurzeit verwenden die Umsetzungen
keine Diagrammsemantik zum Generieren von Implementierungsdaten. Ihre Diagramme können daher nur als Konzepte und für
Dokumentationszwecke eingesetzt werden.
Sie können die Implementierungsartefakte optional auch in den Diagrammen darstellen, indem Sie sie im
Erstellungsbereich ablegen und sie mit den konzeptionellen Elementen des Diagramms verbinden (unter Verwendung von
Abhängigkeiten).
Die Struktur der Test-Assets hängt hauptsächlich von der Entscheidung ab, wie Sie Ihre Test-Assets erstellen.
Sie können mit den Funktionen des automatisierten Komponententests Ihre Tests erstellen. In diesem Fall werden mehrere
voneinander getrennte Testfallprojekte als Teil des Erstellungsprozesses eingerichtet. Der Vorteil dieses Features
besteht darin, dass Sie die Testfallerstellung über eine erste Codegenerierung und die Verwendung von Code-Stubs
vorantreiben können.
Organisieren Sie das Projekt-Repository in einer Verzeichnisgruppe oder -hierarchie. Es wird empfohlen, die Test-Assets
in unterschiedlichen Verzeichnissen zu speichern, so dass die verschiedenen Testtypen (Einheitentest, Integrationstest
und Systemtest) getrennt voneinander aufbewahrt werden.
Wenn es eine gesonderte Implementierungssicht gibt, muss diese gepflegt werden. In dem White Paper Model Structure Guidelines for RSx wird empfohlen, die
<<Perspective>>-Pakete zu verwenden, die Diagramme enthalten, die die Abhängigkeiten zwischen den
Subsystemen verdeutlichen.
Es ist wichtig, sicherzustellen, dass sich Ihre Subsystemabhängigkeiten (ebenso wie andere Abhängigkeiten) während der
Weiterentwicklung des Systems weiterhin an den Best Practices orientieren. Mit der Architekturerkennung, der
Codeprüfung im Allgemeinen und Strukturanalyse im Besonderen können Sie überprüfen, ob sich die Modelle an den Best
Practices orientieren.
Sie sollten ebenfalls Zeit einplanen, um benutzerdefinierte Regeln zu erstellen, mit denen die von Ihnen festgestellten
Abhängigkeiten umgesetzt werden können. Notieren Sie sich während der manuellen Überprüfung alle Regeln, die noch nicht
erstellt wurden, und fügen Sie sie dem Regelsatz für die nächste Iteration hinzu.
Es kann hilfreich sein, die Modelle im HTML-Format zu veröffentlichen. Beachten Sie, dass Diagramme in Microsoft Word
und andere Programme kopiert werden können.
Nähere Informationen finden Sie im Onlinehilfethema Modelle veröffentlichen und im Lernprogramm Modell in einem Web
veröffentlichen.
|