Toolmentor: Implementierungsmodell mit Rational Systems Developer strukturieren
Dieser Toolmentor beschreibt, wie Sie mit der Modellierungsumgebung von RSD das Implementierungsmodell für ein Projekt strukturieren.
Tool: Rational Systems Developer
Erweiterung: Implementierungsmodell mit Rational Software Development strukturieren
Beziehungen
Hauptbeschreibung

Ü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:

Struktur des Implementierungsmodells erstellen

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:

  1. Erstellen Sie ein neues Java-Projekt und fügen Sie den Bibliotheken Referenzen hinzu.
  2. Öffnen Sie das Diagramm, dem Sie das visualisierte Element hinzufügen möchten.
  3. Wechseln Sie in die Perspektive "Java".
  4. Suchen Sie das Element (Paket, Klasse, Interface, etc.), das Sie Ihrem Modell hinzufügen möchten.
  5. 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.

Implementierungssubsysteme anpassen

Nachfolgend werden die Schritte beschrieben, die Sie bei der Anpassung der Implementierungssubsysteme unterstützen:

  1. Verwenden Sie bei der Ermittlung problematischer Subsysteme (z. B. zyklische Abhängigkeit) Folgendes:
    • Themen- und Anzeigediagramme
    • Architekturerkennung
    • Codeüberprüfung/Strukturelle Codeanalyse
  2. Erstellen Sie ein neues Subsystem.
  3. Verschieben Sie die ermittelten Elemente in das neue Subsystem.
  4. Zeichnen Sie neue Abhängigkeiten.

Importe für die einzelnen Implementierungssubsysteme definieren

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

Behandlung von ausführbaren Dateien (und anderen abgeleiteten Objekten) festlegen

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

Behandlung von Test-Assets festlegen

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.

Implementierungssicht aktualisieren

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.

Implementierungsmodell bewerten

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 Symbol für OnlinehilfeModelle veröffentlichen und im Lernprogramm Symbol für OnlinehilfeModell in einem Web veröffentlichen.