Innovator 11 classix. Übergang OOA-OOD. Skriptbasierter Übergang von OOA nach OOD. Karl Straußberger. HowTo.

Transkript

1 Innovator 11 classix Übergang OOA-OOD Skriptbasierter Übergang von OOA nach OOD Karl Straußberger HowTo

2 Skriptbasierter Übergang von OOA nach OOD Inhaltsverzeichnis Vorbemerkung...2 Methodischer Hintergrund...2 Vorbereitung der Modellkonfiguration...4 Übergang durchführen...4 Abzubildende Klassen vorbereiten...4 Abzubildende Klassen auswählen...4 Abbildung ausführen...4 Zuordnung nutzen...5 Übergang anpassen...5 Optionen der Engineering-Aktion...5 Anpassen der Namensregeln...6 Anpassen der Modellkonfiguration...8 Stereotypen...8 Anlegeschablonen...8 Anlegevoreinstellungen...9 Abhängigkeiten...9 Spezifikationstypen...9 Vorbemerkung Methodischer Hintergrund Mit dem skriptbasierten Übergang zwischen der objektorientierten Analyse (OOA) und dem objektorientierten Design (OOD) wird der aufwändige manuelle Übergang teilautomatisiert und beschleunigt. Dieser Übergang ist nicht als Generierung eines vollständigen Designs aus einer Analyse zu verstehen, sondern als Hilfe zur Erzeugung eines ersten Designs als Kopie der Analyseklassen. Dieses erste Design müssen Sie dann überarbeiten und durch weitere Klassen, Attribute und Methoden verändern, bevor eine sinnvolle Implementierung möglich ist. Das Tcl-Skript zum Übergang können Sie auch dann einsetzen, wenn das Design überarbeitet wurde, um zusätzliche Klassen, Attribute und Operationen aus der Analyse in das Design zu überführen. Wenn Sie den Analyse-Design-Übergang durchführen, können Sie zwischen der Analyse und dem Design navigieren (Wechseln>Referenzen). Auch bei der Dokumentationsgenerierung können die Referenzen zwischen Analyse und Design angezeigt werden. Der Übergang ist so gestaltet, dass er durch Sie angepasst werden kann, um Ihre eigenen Abbildungsregeln oder Namenskonventionen zu berücksichtigen. Beim Einsatz von UML als Modellierungssprache besteht das Analysemodell aus dem Use-Case-System und dem Analysesystem. Damit Sie diese Ergebnisse im Design bearbeiten können, wird ein Abbild der Klassen benötigt. Damit Sie Änderungen im Bereich der Anforderungen einpflegen können, muss aber das Analyse-Klassenmodell erhalten bleiben. Gleichzeitig muss jedoch die Möglichkeit bestehen, Klassen im Designmodell einer Klasse im Analysemodell zuzuordnen, um Änderungen aus den Analyseklassen auch in die Designklassen übernehmen zu können. Der Übergang zwischen OOA und OOD bietet hier die nötige Funktionalität. Zuerst werden die ausgewählten Klassen mit ihren Attributen, Methoden und Beziehungen aus dem Analysesystem in das Designsystem kopiert und dann eine Referenz zwischen Original und Kopie erstellt. Dadurch kann die Klasse im Design unabhängig von der Klasse in der Analyse bearbeitet werden. Es besteht aber weiterhin eine Beziehung zwischen beiden Teilsystemen. 2

3 Abbildung 1: Analyse-Klassendiagramm Abbildung 2: Java-Design-Klassendiagramm 3

4 Vorbereitung der Modellkonfiguration Übergang durchführen Damit Sie den Übergang zwischen objektorientierter Analyse und objektorientiertem Design nutzen können, ist ein UML-Modell nach einer Standard- Modellvorlage UML Profile for <Sprache> Voraussetzung,. In diesem Modell müssen bereits Klassen unterhalb des Pakets analysis system existieren. Haben Sie das Modell nicht mit einer Standardmodellvorlage erstellt, so müssen Sie das Add-on <Sprache> OOD-OOD nachladen. So gehen Sie vor Um das Add-on nachzuladen:» Melden Sie sich als Administrator an ihrem Modell an.» Wählen Sie Modell>Konfiguration>Modelloptionen laden.» Selektieren Sie in der Gruppe Konfigurationsdatei das Alternativfeld Add-on und wählen Sie im Listenfeld <Sprache> OOA-OOD aus.» Klicken Sie auf [Anwenden] und schließen Sie den Dialog. Abzubildende Klassen vorbereiten Abzubildende Klassen auswählen Abbildung ausführen Damit der Übergang ausgeführt werden kann, müssen Klassen unterhalb des Pakets analysis system liegen, die eine Deklaration in der Sprache UML besitzen. Befinden sich dort keine Klassen, so verschieben Sie die Klassen dorthin bzw. benennen die dort befindlichen Klassen in der Sprache UML. Zum Durchführen des Übergangs sind die abzubildenden Klassen auszuwählen. Wenn Sie alle Klassen aus einem Paket oder einer Pakethierarchie abbilden wollen, so genügt es, das oberste Paket zu selektieren. Andernfalls selektieren Sie die Klassen einzeln im Element- bzw. im Ergebnisbereich. So gehen Sie vor Um die Abbildung auszuführen:» Melden Sie sich als Administrator an ihrem Modell an (Modell>Administration>Anmelden).» Selektieren Sie die Klassen oder die Pakete mit den Klassen.» Wählen Sie den Menübefehl Engineering>Forward/Reverse.» Wenn Sie ein Paket selektiert haben, dann klicken Sie bitte im erscheinenden Dialog auf die Schaltfläche [Aktionen].» Wechseln Sie auf die Registerkarte Klasse.» Aktivieren Sie das Alternativfeld Forward-Engineering.» Selektieren Sie im Listenfeld Aktionen den Eintrag <Sprache> Generate <Sprache> design.» Klicken Sie auf [Anwenden]. Die Aktion wird gestartet und gibt einige Informationen im Fenster Auswertung aus. Verfolgen Sie diese, um etwaige Fehlermeldungen zu erkennen. Sobald im Fenster Auswertung drei horizontale Striche erscheinen, ist die Aktion beendet und Sie können die Dialogbox(en) Engineering/Forward/Reverse schließen. Die von der Aktion generierten Klassen befinden sich nun im Paket <Sprache> design system bzw. in einem Unterpaket davon. Außerdem generiert die Aktion auch alle Klassendiagramme, auf denen sich mindestens eine der abgebildeten Klassen befindet, und platziert die generierten Klassen an die entsprechende Stelle. 4

5 Zuordnung nutzen Der Übergang generiert im Paket.<Modellname>.UML Stub-Pakete und Modelleferenzen. Wenn Sie ein Analyse- oder Designelement selektieren und den Menübefehl Wechseln>Referenzen wählen, können Sie über die Registerkarte Andere Modelle das jeweils andere Element bzw. seine Referenz anspringen. Übergang anpassen Optionen der Engineering-Aktion Die Engineering-Aktion <Sprache> Generate <Sprache> design kann mit einigen Optionen auf den jeweiligen Einsatzbereich eingestellt werden. Diese Optionen sind auch in der Hilfe zum Tcl-Skript umldecl.tcl dokumentiert. So gehen Sie vor Um den Übergang anzupassen:» Melden Sie sich als Administrator an ihrem Modell an.» Wählen Sie den Menübefehl Modell>Konfiguration>Engineering> Forward/Reverse.» Selektieren Sie auf der Registerkarte Forward-Engineering im Listenfeld Anwenden den Eintrag Klasse.» Selektieren Sie im Listenfeld Aktionen den Eintrag <Sprache> Generate <Sprache> declaration.» Ändern Sie im Eingabefeld Name den Eintrag in <Sprache> Generate <Sprache> design.» Klicken Sie auf die Schaltfläche [Hinzufügen]. Geben Sie im Eingabefeld Optionen die benötigten Optionen an. (Die Bedeutung der einzelnen Optionen wird im Folgenden erläutert.)» Klicken Sie auf die Schaltfläche [Ändern]. -ovr Ist diese Option gesetzt, so werden bereits existierende Deklarationen überschrieben. -noclass Diese Optionen bewirken, dass Klassen, Attribute bzw. Methoden von der noattr Bearbeitung ausgeschlossen werden. Hierdurch können Sie bei Aktualisierungen verhindern, dass bereits abgebildete Klassen, Attribute bzw. Me- -nometh thoden verändert werden. Diese Option kann auch verwendet werden, wenn Sie keine Methoden oder Attribute ins Design abbilden wollen. -pref [<inifile>] Ist diese Option gesetzt, so wird der Mechanismus für Namensregeln aktiviert. Das Format dieser Datei wird gesondert erläutert. Der Name der Konfigurationsdatei ist optional, bei fehlender Angabe wird inopref.ini verwendet. Die Einträge in dieser Datei beeinflussen die Namensgenerierung im Design (bzw., falls copy nicht gesetzt ist, in der weiteren Deklaration). -copy Durch diese Option wird der Analyse-Design-Übergang aktiviert. Ist diese Option nicht gesetzt, so wird bei den zu bearbeitenden Klassen nur die Deklaration von der Sprache UML in eine weitere Sprache umgewandelt. Ist diese Option gesetzt, so wird von den bearbeiteten Klassen, Attributen und Methoden eine Kopie im Design angelegt. Gleichzeitig wird ein Referenzeintrag (inoref) in der Spezifikation Analyse-Design angelegt. Existiert bereits eine gleichnamige Klasse (UML-Name) im Design, so wird diese verwendet (ebenso für Attribute und Methoden). Alle folgenden Optionen (-copy...) sind nur wirksam, wenn auch copy gesetzt ist. -copyupdate Diese Option bewirkt, dass die Kopien im Design auf jeden Fall aktualisiert werden. Hierdurch gehen etwaige Änderungen in der Deklaration in der Sprache UML verloren. Sollen auch die Deklarationen in der Design- Sprache aktualisiert werden, so geschieht das mit der Option ovr. 5

6 -copyclstpl <Schablone> Beim Anlegen der Designklassen ist eine Klassenanlegeschablone notwendig, die beim Anlegen der Klassenkopien verwendet wird. Diese Schablone enthält unter anderem den Stereotyp der Designklasse, der für die Anlegevoreinstellungen (siehe unten) verwendet wird. -copyclsprefix Durch den Generator werden identische Klassenkopien angelegt. Haben <Zeichenkette> Sie in Ihrem Modell die Verwendung von Namensräumen deaktiviert, so -copyclssuffix wird dies beim Erzeugen der Kopie zu einer Fehlermeldung führen. Mit <Zeichenkette> diesen Optionen können Sie dafür sorgen, dass der Name der Klassenkopie mit einem entsprechenden Präfix und/oder Suffix versehen wird. Damit sollte der Klassenname wieder eindeutig sein und die Fehlermeldung unterbleiben. -copyrel Mit Hilfe dieser Option können Sie das Übernehmen der Beziehungen (Assoziationen, Aggregationen, Vererbungen, Abhängigkeiten, Schnittstellen) aktivieren. Dadurch werden alle Beziehungen ins Design kopiert, deren beteiligte Klassen ebenfalls im Design existieren. Beziehungen werden anhand ihres Namens identifiziert. Haben Sie also den Namen einer Beziehung in der Analyse geändert, so wird eine neue Beziehung erstellt. -copyaimpl Diese Option ist nur wirksam, wenn Sie auch die Option copyrel gesetzt haben. Sie bewirkt, dass Attribute und Methoden, die im Analyse-Modell als «association implementer» gekennzeichnet sind, auch als solche im Design generiert und dem entsprechenden Assoziationsende zugeordnet werden. -copydia Diese Option aktiviert das Kopieren von Klassendiagrammen. Dabei werden in der Kopie alle Klassen hinzugefügt, die bereits im Design abgebildet sind. Das Layout wird so weit möglich und sinnvoll nachgebildet. -copydiatpl <Schablone> Diese Option ist nur wirksam, wenn Sie auch die Option copydia gesetzt haben. Beim Anlegen der Design-Klassendiagramme ist eine Klassendiagramm- Anlegeschablone notwendig, die beim Anlegen der Diagrammkopien verwendet wird. Diese Schablone enthält unter anderem den Stereotyp des Design-Klassendiagramms, der für die Anlegevoreinstellungen (siehe unten) verwendet wird. Anpassen der Namensregeln -copydiaprefix Diese Option ist nur wirksam, wenn Sie auch die Option copydia gesetzt <Zeichenkette> haben. -copydiasuffix Durch den Generator werden gleichnamige Diagrammkopien angelegt. <Zeichenkette> Haben Sie in Ihrem Modell die Verwendung von Namensräumen deaktiviert, so wird dies beim Erzeugen der Kopie zu einer Fehlermeldung führen. Mit diesen Optionen können Sie dafür sorgen, dass der Name der Diagrammkopie mit einem entsprechenden Präfix und/oder Suffix versehen wird. Damit sollte der Diagrammname wieder eindeutig sein und die Fehlermeldung unterbleiben. -copycreatenopkg Ist das Analyse-Modell in Pakete aufgeteilt und soll diese Paketierung im Design nicht verwendet werden, so verhindert diese Option das Anlegen von neuen Paketen. Befinden sich bereits Klassen im Design, so werden diese allerdings nicht in das oberste Design-Paket verschoben. Durch das Setzen der Option pref wird der Mechanismus für Namensregeln aktiviert. Dieser verwendet eine Konfigurationsdatei, deren Format im Folgenden beschrieben wird. Die Datei inopref.ini ist abhängig von der eingestellten Oberflächensprache und befindet sich also im Unterverzeichnis de_de bzw. en_us von $INODIR oder im entsprechenden $HOME-Unterverzeichnis des Benutzers. Die Einträge, die in der Datei inopref.ini möglich sind, können auch in einem Spezifikationstyp "inopref" (Name der Datei ohne Erweiterung) an der Modellbeschreibung gemacht werden. 6

7 Alle drei Stellen ($INODIR, $HOME, Modellbeschreibung) werden ausgewertet und die Einträge zusammengeführt. Ein Eintrag aus der Datei im $HOME- Verzeichnis kann also einen Eintrag aus dem $INODIR-Verzeichnis überschreiben. Einträge in der Modellbeschreibung überschreiben sowohl Einträge aus der Datei im Verzeichnis $INODIR als auch der Datei im Verzeichnis $HOME. Abschnitte Die Regeln sind im Konfigurationsdateiformat aufgebaut. Es gibt also Abschnitte, die in eckigen Klammern stehen. Ein Abschnitt kann nach folgender Regel bezeichnet sein: Elementtyp:Quellinfo->Zielinfo und enthält Vorschriften wie für den Elementtyp (OMFeatures=Klassen, OMFAttribute=Attribute, OMFMethod=Methoden) aus der Quellinfo (Type=Daten/Rückgabetyp, Name, Args=Argumente von Methoden, Init=Initialisierungswerte von Attributen, Property=Elementeigenschaften) die Zielinfo (Type, Name, Args, Init, Property) generiert werden soll. Einträge Innerhalb eines Abschnitts befinden sich nun die einzelnen Vorschriften als einzelne Zeilen. Dabei steht links (vor einem Gleichheitszeichen) ein Suchkriterium und rechts die auszuführende Aktion. Das Suchkriterium ist ein regulärer Ausdruck, der mit der Quellinfo verglichen wird. Trifft die Quellinfo auf den regulären Ausdruck zu, so wird die Aktion als aktiviert gespeichert, aber noch nicht ausgeführt. Für Elementeigenschaften ist eine erweiterte Syntax vorgesehen, bei der zuerst der Name der Elementeigenschaft (abhängig von der Oberflächensprache) und durch einen Doppelpunkt getrennt der Wert oder das Muster für den Wert angegeben wird. Sämtliche Suchkriterien werden auf Deklarationen und Elementeigenschaften angewendet, die denen entsprechen, die im Eigenschaftsdialog für Klassen, Attribute bzw. Methoden über die Schaltfläche [Voreinstellung] der jeweiligen Sprache erhalten werden. Die Aktion kann aus mehreren Teilaktionen bestehen, die durch Kommas voneinander getrennt werden. Eine Teilaktion besteht aus einem Kommando und nach einem Schrägstrich optional einem Parameter des Kommandos. Folgende Kommandos existieren: <RE>/<ZK>: Ersetze den regulären Ausdruck <RE> durch die Zeichenkette <ZK>. FIRST2LOWER: Erster Buchstabe soll klein geschrieben werden. FIRST2UPPER: Erster Buchstabe soll groß geschrieben werden. CUT2UPPER/<Z>: Lösche das Zeichen <Z> und schreibe das darauffolgende Zeichen groß. PREFIX/<ZK>: Setze die Zeichenkette <ZK> an den Anfang (identisch mit ^/<ZK>). PREFIX2UPPER/<ZK>: Schreibe den ersten Buchstaben groß und setze die Zeichenkette <ZK> an den Anfang. PREFIX2LOWER/<ZK>: Schreibe den ersten Buchstaben klein und setze die Zeichenkette <ZK> an den Anfang. SUFFIX/<ZK>: Setze die Zeichenkette <ZK> an das Ende (identisch mit $/<ZK>). QUOTE/<ZK>: Setze die Zeichenkette <ZK> an den Anfang und ans Ende. 7

8 Beispiel [OMFeatures:Property->Property] Stereotyp:.* = Stereotyp:.*/class [OMFAttribute:Init->Init].. = QUOTE/\" [OMFAttribute:Type->Type] Datum = Datum/Date [OMFAttribute:Type->Name] Anpassen der Modellkonfiguration [OMFAttribute:Name->Name] [OMFAttribute:Property->Name] Gültigkeitsbereich:classifier = FIRST2UPPER Gültigkeitsbereich:instance = FIRST2LOWER [OMFMethod:Type->Type] Datum = Datum/Date [OMFMethod:Name->Name] gib = gib/get setze = setze/set ueberpruefe = ueberpruefe/check berechne = berechne/get [OMFMethod:Property->Name].* = FIRST2LOWER [OMFeatures:Name->Name] Für die Durchführung des Übergangs sind einige Einstellungen in der Modellkonfiguration nötig. Deren Wirkung soll im Folgenden beschrieben werden. Sollten Sie nicht mit der Konfiguration von Innovator-Modellen vertraut sein, so können Sie hier die Lektüre dieses Dokuments beenden. Stereotypen Anlegeschablonen Um den Übergang konfigurieren zu können, sind Stereotypen auf Abhängigkeiten zwischen Paketen notwendig: «create <Sprache> class» und «create class diagram». Diese Stereotypen werden verwendet, um die Anlegevoreinstellungen definieren zu können. Außerdem werden auch eigene Stereotypen auf Designklassen und Designklassendiagramme benötigt, die in den Anlegeschablonen verwendet werden. Anlegeschablonen werden verwendet, um im Modellbrowser bzw. Diagrammeditor Elemente nach festen Vorgaben zu erstellen. Diese Anlegeschablonen definieren u.a. den Stereotyp des neu erstellten Elements. Damit bezieht sich die Anlegeschablone indirekt auf die Anlegevoreinstellung, die den Stereotyp der Klassen bzw. des Klassendiagramms abfragt. Der Name der Anlegeschablone wird als Parameter für die Optionen copyclstpl und copydiatpl verwendet. 8

9 Anlegevoreinstellungen Abhängigkeiten Spezifikationstypen Für die Paketstereotypen «analysis system», «analysis package» und «analysis service package» werden jeweils zwei Einträge bei den Anlegevoreinstellungen (Menükommando Modell>Konfiguration>Pakete>Eigenschaften, Registerkarte Anlegevoreinstellungen) benötigt. Der erste Eintrag ist bei Klassen vorzunehmen: Element «class», Abhängigkeit «create <Sprache> class», Neue Pakete «<Sprache> design subsystem». Der zweite Eintrag ist für Klassendiagramme: Element «class diagram», Abhängigkeit «create class diagram», Neue Pakete «<Sprache> design subsystem». Als Konsequenz der Anlegevoreinstellungen sind zwei Abhängigkeiten zwischen den Paketen des Analysemodells und des Designmodells anzulegen. Diese Abhängigkeiten verwenden den Stereotyp, der bei den Anlegevoreinstellungen konfiguriert ist. Damit wird dann tatsächlich bestimmt, in welches Designpaket die einzelnen Elemente eines Analysepakets generiert werden. Normalerweise genügt es, zwischen den Paketen analysis system und <Sprache> design system diese beiden Abhängigkeiten zu erstellen. Für Klassen, Attribute und Methoden muss ein Spezifikationstyp "Analyse- Design" existieren, in dem die Referenzkennung eingetragen wird. Über die Option copyreftext kann der Name des Spezifikationstyps eingestellt werden. An der Modellbeschreibung kann ein Spezifikationstyp "inopref" existieren, dessen Inhalt bei der Bestimmung der Namensregeln mit verwendet wird. Copyright 2010 MID GmbH Bei Fragen wenden Sie sich bitte an unsere Hotline Telefon: , Dieses Dokument finden Sie neben anderen auch im exklusiven Login- Download-Bereich für Innovator-Wartungskunden unter Ihre MID MID GmbH, Eibacher Hauptstr. 141, Nürnberg Telefon: , Fax: Internet: Innovator_11.2_HowTo_Uebergang_OOA_OOD_ doc 9