Heute möchte ich meine vorgehensweise zur SUM->View Transformation anhand von Pseudocode erläutern. Die Java-Implementierung ist etwas komplexer, doch im Kern spiegelt der Pseudocode meine programmatische Umsetzung wieder.
Endlich melde ich mich nach etwas längerer Pause mit einem neuen Artikel zurück. In der Zwischenzeit ist auch das eine oder andere geschehen, auch hinsichtlich meiner Diplomarbeit. Heute möchte ich mich dem Thema “Metamodellierung” widmen:
Grundlage dieses Teils meiner Arbeit war diesmal vor allem die Diplomarbeit von Jan Kadathukalam, der in den Abschnitten 3.1 und 3.3 die benötigten theoretischen Hintergrund erläutert. Aus seiner praktischen Arbeit habe ich das auf MDT UML2 basierte KobrA2 Metamodell verwendet und an meine Anforderungen angepasst. Diese Anpassungen sind in erster Linie das Umbenennen der Packages, das Ausgliedern der Elemente K2Model und K2Package sowie die Erweiterung des Package Structure (ehemals StructureClasses) um die voraussichtlich für meine Arbeit benötigten Elemente des KobrA2 Metamodells.
In den letzten Tagen habe ich mir nach den bisher gewonnenen Erkenntnissen unter anderem ein grobes Konzept überlegt, wie eine Programmierung der Transformationen in Java aussehen könnte, das ich im Folgenden vorstellen möchte.
Package"views"
Sehen wir uns zunächst den Inhalt des von mir modellierten Package “views” an:
Zu Grunde liegt eine abstrakte Klasse Generation, deren Instanzen das Ergebnis aus von dem SUM ausgehenden Transformationen (-> ViewGenerations) repräsentieren. In den Attribute dieser Klasse werden zum einen die Repräsentation der .uml-Datei (umlFile) und zum anderen die Information, ob diese Datei verändert wurde, gespeichert (isModified).
Diese Klasse wird wiederum von einer abstrakten Klasse View erweitert, die die Informationen zu der Darstellung der Daten, die in einer .umldi-Datei gespeichert werden, kapselt (umldiFile).
Schließlich wird die eben genannte Klasse nochmals erweitert. Die erweiternden Klassen repräsentieren schließlich die tatsächlichen Sichten (z.B. SpecificationClassServiceView und SpecificationClassTypeView).
Package"transformation"
Die eben vorgestellten Elemente werden in dem zweiten modellierten Package “transformation” verwendet, das etwas komplizierter aufgebaut ist:
Ausgangselement dieses Package ist das generische Interface ViewGenerator. In Abhängigkeit des Parameters TGeneration, der die Klasse Generation erweitern muss, wird über die Methode generate() eine View aus dem SUM erzeugt. Als Parameter muss hierbei die Repräsentation der Zieldatei übergeben werden. Das Gegenstück zu dieser Methode, die die Transformation von SUM zu View repräsentiert, ist merge(). Hier wird die als Methodenparameter übergebene View wieder mit dem SUM zusammengeführt.
Dieses Interface wird von einer abstrakten Klasse AbstractViewGenerator “quasi-implementiert”, d.h., dass diese Klasse alle gemeinsamen Attribute und Methoden der verschiedenen View-Generatoren beherbergen soll, wie z.B. die (protected) Methode selectSubject(), die anhand des Klassennamens das entsprechende Element aus dem SUM selektieren und ggf. mit dem vorgesehenen Stereotyp “subject” versehen soll. Der Rückgabewert ist derzeit noch vom Typ org.eclipse.uml2.uml.Class, doch kann es sein, dass dies noch geändert werden muss.
Die konkreten Erweiterungen des (ebenfalls generischen) abstrakten Generators sind schließlich die einzelnen View-Generatoren, z.B. SpecificationClassServiceViewGenerator und SpecificationClassTypeViewGenerator.
Soweit so gut 
Doch ich habe mich entschieden, das Ganze noch etwas zu erweitern, in dem ich das “factory method pattern” (http://en.wikipedia.org/wiki/Factory_method_pattern) anwende.
Zu verwenden ist die daraus entstandene ViewGeneratorFactory folgendermaßen: Über den Konstruktor wird der Factory-Instanz mitgeteilt, welche Datei das SUM repräsentiert. Die Methode getViewGenerator(), der man als Parameter die Klasse der zu erzeugenden View übergibt liefert über ein Mapping stets den passenden ViewGenerator.
Durch die Anwendung dieses Pattern ergeben zwei offensichtliche Vorteile: Zum einen ist es nur noch bei der Erzeugung einer Factory-Instanz notwendig, die SUM-Datei anzugeben. Zum anderen entsteht dadurch ein Transformation-Framwork, das einfach um weitere Views erweitert werden kann. Dazu müssen nur zwei Klassen implementiert werden: eine, die die Klasse Generation (oder View) und eine, die die Klasse AbstractViewGenerator erweitert. Dann muss nur noch die Klasse der ViewGenerator-Implementierung und die zugehörige View-Klasse in der Factory registriert werden.
Wie ihr sehen könnt, veröffentliche ich in der letzten Zeit immer wieder Artikel zu meiner Diplomarbeit. Diese sind zunächst einmal mit einem Passwort geschützt, um die Inhalte nur einem kleinen Kreis zugänglich zu machen. Ein Grund dafür ist, dass diese Artikel Auszüge meiner Diplomarbeit enthalten können. Somit dient mir der Blog zur Zeit als Art DA-Tagebuch und Sketchbook. Ich halte Informationen fest, berichte über neue Erkenntnisse und den Fortschritt meiner praktischen Arbeit. Die Idee dahinter ist, nach dem praktischen Teil viele Informationen und eine gute Grundlage für die schriftliche Ausarbeitung zu haben.
Nach Beendigung meiner DA werde ich alle (oder zumindest den Großteil) der DA-Artikel der öffentlichkeit zugänglich machen. Falls du das nicht abwarten kannst, dich meine DA interessiert und/oder der Meinung bist, auch zu dem kleinen Kreis der “Auserwählten” zu gehören, frag mich einfach nach dem Passwort
Mir war einige Zeit unklar, wie ich beginnen soll, auf programmatischem Weg eine .uml-Datei mittels des UML2-Plugins von Eclipse zu erzeugen.
Wie verwende ich XPath in einem Java-Programm? Diese Frage stellte ich zunächst Tante Gurgel und fand den IBM-Artikel, den ich im vorigen Post bereits erwähnt hatte.
Lies den Rest des Artikels »
Meine Idee für die programmatische Transformation aus dem Single-Underlying-Model (SUM) in eine View (z.B. Structural Specification) ist eine Kombination aus Java und XPath. Für die Rücktransformation habe ich mir bis dato aber noch keine Gedanken gemacht.
Unter der Annahme, dass das SUM im XMI-Format gespeichert ist, könnte ich über XPath die Teile des XML-Baums filtern, die ich für die Transformation benötige. Dies kann dann per Java-Code weiterverarbeitet werden und daraus ein neues Model erzeugt werden, das dann wiederum in eine XMI-Datei serialisiert wird.
http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Getting_Started_with_UML2/article.html
http://www.ibm.com/developerworks/library/x-javaxpathapi.html
Ich werde diesen Ansatz testen, indem ich zunächst versuchen werde, aus einer XMI-Datei mit zwei Klassen eine zu selektieren und diese in die neue .uml-Datei zu schreiben.
@Dietmar, Benjamin: Was haltet ihr davon?
Heute habe ich mich dazu entschlossen für meine DA eine “neue” Eclipse-Installation zu verwenden. Auf der Downloadseite hatte ich dann die Qual der Wahl:
Eclipse - Compare PackagesQuelle: http://www.eclipse.org/downloads/packages/compare-packages
Für mich kamen schließlich die Eclipse IDE for RCP/Plugin Developers und die Eclipse Modeling Tools (includes incubating components) in die engere Auswahl.
Zur Zeit läuft gerade der Download für die Eclipse Modeling Tools, die ich mir als erstes ansehen möchte. Ich denke für die ersten Schritte dürfte das die bessere Wahl sein. Fehlende Features könnte ich zu einem späteren Zeitpunkt auch nachinstallieren.
Für meine DA benötige ich eine Fallstudie, wozu mir ein fiktives, einfach strukturiertes Ticketing-System (aka Task-Tracking-System oder Help-Desk-System) dient, das ich hier beschreiben möchte:
Ein Ticketing-System findet zum Beispiel im User-Support eines Software-Herstellers Anwendung. Grundsätzlich können zwei Benutzergruppen eines solchen Systems identifiziert werden. Auf der einen Seite die Benutzer der Software (= Kunden des Softwareunternehmens), die in diesem Szenario entweder Probleme bei der Bedienung oder Anforderungen bezüglich Customizing/Features haben. Auf der anderen Seite gibt es die Mitarbeiter des Softwareunternehmens, die sich um die Probleme und Anforderungen der Kunden kümmern. Lies den Rest des Artikels »
Auf PlayOnLinux bin ich aufmerksam geworden, als ich auf der Suche nach einer Anleitung und Erfahrungsberichten zum Internet Explorer unter Linux war und auf einen Beitrag auf telemat.de gestoßen bin.
“Warum IE unter Linux?”, fragt sich jetzt vielleicht der ein oder andere. Ganz einfach: Chrome, Safari, Mozilla und Co. haben’s immer noch nicht geschafft den IE zu verdrängen und werden es wohl so schnell auch nicht. Und um meine erstellten Webseiten Cross-Browser-tauglich zu machen benötige ich unter anderem auch den IE zum testen.
PlayOnLinux bietet jedoch nicht nur eine einfach Möglichkeit den Internet Explorer unter Linux zu installieren, sondern noch viele andere Installationsscripte für die verschiedensten Windows Programme. Wie der Name ja schon sagt, war das Tool ursprünglich dafür konzipiert, eine bequeme Möglichkeit zu schaffen, Spiele, die für Windows programmiert wurden, auch unter Linux+Wine zum Laufen zu bringen.
Die Installation ist einfach:
sudo aptitude install wine
… im Terminal ausführen, falls noch kein Wine installiert wurde und dann die aktuelle Version des PlayOnLinux-Tools von der Website beziehen. (Am einfachsten ist es, die .deb-Datei herunterzuladen und zu installieren.)
Danach kann man das Tool bequem über >Anwendungen >Spiele >PlayOnLinux starten (Ubuntu 8.10, Gnome).
Unter >Installiere >Internet findet man dort den Eintrag für den Internet Explorer, neben ein paar weiteren Browsern. Auswählen, Anwenden, durch den Wizard klicken, fertig - das dachte ich zumindest… Aber Pustekuchen 
