Arbeiten mit der Rational-XDR
Hier wird anhand eines minimalen Beispiels die Rational XDE eingeführt.
Hier gibt es das Beispiel zum Download: RationalTest.zip
Schritt 1: Anwendung erstellen
Erstellen des Anwendungsgerüsts (SDI-Anwendung) gemäß Beschreibung von Hr. Dreher.
Einziger Unterschied ist dass wir im letzten Schritt als Basisklasse der View-Klasse
"CView" auswählen. Benannt wird das Beispiel "RationalTest"
Die in Hr. Drehers Anleitung deaktivierte Druckunterstützung (Schritt "Erweiterte Features") können wir belassen,
da eine CView druckbar ist.
Schritt 2: Ein Klassendiagramm zufügen
Im "Solution Explorer" auf den Sychronize-Toolbar-Button klicken und einen Kaffee kochen gehen.
Ein Projekt "RationalTestModel" wird angelegt.
Jetzt die von Hr. Dreher vorgeschlagenen Einstellungen unter "Tools"->"Options" vornehmen:
Automatische Synchronisierung aktivieren im Zweig "Rational XDE" -> "Round Trip Engineering -> Synchronization Settings".
Die benötigten C++-Datentypen und C++-Containerdatentypen definieren (siehe Doku zu Adresseverwaltung).
Jetzt wechseln wir in den "Model Explorer" und ziehen die 5 generierten Klassen ins Diagramm:
-CAboutDialog
-CMainFrame
-CRationalTestApp
-CRationalTestDoc
-CRationalTestView
Das Ergebnis sollte so aussehen:
Rechtsklick ins Diagramm und im Contextmenü die Option "Refresh Inheritance Overview" wählen.
Dies führt zu diesem Diagramm:
Dies wollen wir noch erweitern und die gesamte Vererbungshierarchie einblenden.
Dazu Rechtsklick auf jede der im letzten Schritt hinzugekommen Parent-Klassen und im Kontextmenü
"Add Related Shapes..." wählen. In dem erscheinenden Dialog (das Beispiel stammt vom Parent von
CAboutDialog, CDialog) als Relationships nur "Generalization" wählen, als Richtung "From Selection to
suppliers" und als Schrittzahl "Expand indefinitely" wählen.
Jetzt explodiert unser Klassendiagramm vor lauter Methoden, deshalb blenden wir in den Parentklassen
alles aus was uns nicht wirklich betrifft. Rechtklick auf jede der neu hinzugekommen Klassen und die
Option "Select Compartment Items" wählen. In dem erscheinenden Dialog alle Methoden ausblenden
(nach links verschieben).
Das Ergebnis sieht so aus:
Vererbung im Collection Editor:
Im "Collection Editor" können Attribute, Methoden und Verbindungen zu anderen Klassen bearbeitet werden.
Erreicht wird er, indem man z.B. auf die Document-Klasse "CRationalTestDoc" rechtsklickt und im Contextmenü
"Collection Editor" wählt. Auf der Registerkarte "Relationships" sehen wir Beziehungen zu anderen Klassen.
Aktuell finden wir hier die Vererbung zu CDocument:
Schritt 3: Abhängigkeiten
Wir pinseln diverse Abhängigkeiten in das Diagramm.
- "CRationalTestApp" erzeugt eine Instanz von "CAboutDialog", also zeichnen wir eine Assoziation zwischen beiden
Klassen und beschriften sie entsprechend (Property "End1Name" auf "erzeugt" setzen, sprich "CRationalTestApp erzeugt CAboutDialog").
- Unser Document hat eine Liste von CViews. Das sehen wir, wenn wir "CDocument" im Diagramm auswählen und die
Option "Select in Model Explorer" wählen. Hier finden wir die Property "m_viewList" vom Typ "CPtrList".
In CView finden wir umgekehrt eine Variable "m_pDocument" vom Typ "CDocument". Also könnten wir hier eine Aggregation
einzeichnen. Leider nicht möglich, da dieser Teil des Modells nicht änderbar ist (interne Klassen).
Eine kleine Hilfe ist allerdings, dass wir eine Assoziation von CView auf CDocument zufügen können.
(CDocument wählen, Rechtsklick, "Add/Remove Connectors" wählen, in dem erscheinenden Dialog nur die Option
"Association" auf "Add" setzen).
- Die Beziehung zu CDocTemplate zufügen. Hierzu im Model Explorer die Klasse "CSingleDocTemplate" suchen
und in das Diagramm ziehen. Alle Methoden ausblenden. Über "Add Related Shapes" die Parentklasse "CDocTemplate"
zufügen. Da wir im letzten Schritt in "Add/Remove Connectors" Assoziationen eingeblendet haben, wird automatisch eine
Assoziation zu "CDocument" zugefügt (Membervariable "m_pOnlyDoc").
"CDocTemplate" wiederum hat eine Beziehung zu "CView", die wegen der Liste nicht modellierbar ist.
Außerdem ziehen wir die Klasse "CDocManager" ins Diagramm, die eine Membervariable von CWinApp ist ("m_pDocManager").
Diese Klasse wiederum hat eine Membervariable "m_templateList", die eigentlich eine Aggregation von "CDocTemplate" ist.
- CView hat eine Assoziation zu "CFrameWnd" (m_pViewActive), aktive View.
- CFrameWnd hat eine Assoziation zu sich selbst (m_pNextFrameWnd), die uns allerdings nicht interessiert.
Daraus ergibt sich dieses Modell:
Schritt 4: Hinzufügen einer Membervariablen
Viele Wege führen hier zu unserem Ziel.
Weg 1: (Von UML zu Code) Im ModelExplorer Rechtsklick auf die Klasse und die Option "Add UML" -> "Attribute" wählen.
Das Attribut erscheint direkt im Model Explorer. Rechtsklick darauf und die Option "Properties" wählen.
Wir benennen es um in "m_sText1", geben als Type Expression "CString" an und wählen bei "Visibility" natürlich
PRIVATE.
Weg 2: (Von Code zu UML) Im ModelExplorer Rechtsklick auf die Klasse und die Option "Add C++" -> "Field" wählen.
Wir geben dem Feld den Namen "m_sText2" und wählen Field Access und Field Type aus. Außerdem lassen wir uns nicht von
der eigentlich FALSCHEN Angabe des Namens der Headerdatei irritieren (hier ist ein "C" zuviel).
Für die Auswahl des Field Types gibt es einen Assistenten. Wenn wir in den VisualStudio-Optionen den Datentyp "CString"
bereits bekannt gemacht haben, taucht er hier auf.
Haben wir den Typ "CString" vorher nicht konfiguriert, dann wird diese Variable als Assoziation dargestellt.
Man beachte dass die Variable aus Weg 1 korrekt ist ! Seltsames Tool...
Aus dieser Situation kommen wir allerdings heraus, indem wir im Contextmenü von "m_sText2" die Option
"Convert to Attribute" wählen. Aber ACHTUNG ! Jetzt haben wir einen "CString *" am Hacken,
d.h. manuell in der Header-Datei oder in den Properties ändern. Wenn wir den Typ vorher bekannt gemacht
hätten wäre uns das nicht passiert...
Weg 3. (Von UML zu Code) Dieser Weg führt über den "Collection Editor" von CRationalTestDoc (Rechtsklick auf
Klasse und im Contextmenü "COllection Editor" wählen). Hier können wir auf der Registerkarte "Attributes" ein neues
hinzufügen. Zwar ohne schicken Dialog, aber dafür effektiv.
>h3>Schritt 5: Hinzufügen einer Funktion
Es soll eine Methode "SetText" mit einem Parameter zugefügt werden. Hier gibt es genauso viele Weg wie in
Schritt 3, allerdings bleibt nur ein Weg für uns gangbar.
Weg 1: (Von Code zu UML, der einzig mögliche). Im Model Explorer Rechtsklick und "Add C++" -> "Member Function" wählen.
Wichtig: Hier muss der Name der Implementierungsdatei geändert werden, im Default steht hier
ein "C" zuviel. Dass der Name der Headerdatei falsch ist stört uns nicht, es wird nämlich trotzdem die richtig verwendet.
Weg 2: (Von UML zu Code) Im Model Explorer Rechtsklick und "Add UML" -> "Operation" wählen: Leider landet die
Methode in der Datei "CRationalTestDoc.cpp" statt "RationalTestDoc.cpp", d.h. für uns nicht praktikabel.
Weg 3: (Von UML zu Code) Dieser Weg führt wieder über den Collection Editor. Wir fügen eine Methode "SetText3" zu.
Den Parameter definiert man, indem man in der Zelle "Collections" auf den Detail-Button klickt.
Dummerweise landet die Methode genau wie in Schritt 2 in der falschen Datei !
Schritt 6: Hinzufügen einer Klasse
Hierfür würde ich weiterhin den MFC-Anwendungsassistenten empfehlen. Hier landen zuviele MFC-spezifische Informationen in
den Headern, und z.B. Dialoge kann Rational wahrscheinlich nicht mit allen Resourcen erzeugen.
Schritt 6: Publizieren des Modells
Im Menü "Tools" die Option "Publish Model" wählen. Hierdurch wird eine komplette HTML-Doku
zum Modell erzeugt.
Version 1.0.0.0, Stand 10.04.2005
Historie: