Archiv für die Kategorie ‘Diplomarbeit’

UUIDs im EMF-Modell verwenden

Dienstag, 07. April 2009

Die Referenzierung erfolgt in der XML/XMI-Repräsentation eines EMF-generierten Modells standardmäßig über XPath Ausdrücke (hm, stimmt das? wo hab ich das denn gelesen?).
<packagedElement xsi:type="KobrA2SUM.Structure:K2ComponentClass" name="TravelBookingSystem">
<generalization general="#//BookingSystem"/>
<!-- ... -->
</packagedElement>
<packagedElement xsi:type="KobrA2SUM.Structure:K2ComponentClass" name="TravelBookingSystem">
<!-- ... -->
</packagedElement>

Hieraus ergibt sich der Nachteil, dass ein SUM-View-Mapping der Modellelemente nur zu Programmlaufzeit sichergestellt werden kann. Ändert man zum Beispiel den Namen der Komponente “BookingSystem” in der View “offline” und möchte dann die Änderung in das SUM importieren, ist die nicht mehr korrekt möglich, da kein passendes Mapping mehr erfolgen kann. Vor allem hinsichtlich einer kollaborativen Entwicklung ergeben sich Schwierigkeiten, die ohne künstliche IDs nicht zu umgehen sind.

Aus diesem Grund gibt es die Möglichkeit UUIDs zu verwenden. Da diese bei EMF-generierten Modellen standardmäßig nicht vorgesehen sind, ist ein kleiner Eingriff des Programmierers in den erzeugten Code notwendig. Wie das funktioniert habe ich vor allem durch einen Artikel von Seweryn Niemiec erfahren: How To Enable UUID In EMF Generated Model [...]

Folgende Änderungen brachten mich zum Ziel:

  1. Die Klasse KobrA2SUMResourceFactoryImpl erweitert org.eclipse.emf.ecore.xmi.impl.XMIResourceFactoryImpl
  2. Die Klasse KobrA2SUMResourceImpl erweitert org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl
  3. Außerdem wurde die Methode useUUIDs() der Klasse KobrA2SUMResourceImpl überschrieben:
    /* (non-Javadoc)
    * @see org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl#useUUIDs()
    */
    @Override
    protected boolean useUUIDs() {
    return true;
    }

Schließlich erhielt ich ein Modell, das UUIDs verwendet und auch über diese referenziert.
<packagedElement xsi:type="KobrA2SUM.Structure:K2ComponentClass" xmi:id="_5F2l0CKuEd654_10FfizxA" name="TravelBookingSystem">
<generalization xmi:id="_5F96kCKuEd654_10FfizxA" general="#_5H7CYSKuEd654_10FfizxA"/>
<!-- ... -->
</packagedElement>
<packagedElement xsi:type="KobrA2SUM.Structure:K2Class" xmi:id="_5H7CYSKuEd654_10FfizxA" name="BookingSystem">
<!-- ... -->
</packagedElement>

Bei der View-Erzeugung werden dann die UUIDs der Elemente “kopiert”, d.h. die UUID des Elements des SUM per eObject.eResource().getURIFragment(eObject) ausgelesen und dann beim Element der View manuell per UMLResource.setID(eObject) gesetzt.

Um dies herauszufinden war das durchstöbern der Newsgroup [news.eclipse.modeling.mdt.uml2] sehr hilfreich, denn dort fand ich den entsprechenden Hinweis.

SUM->SpecificationStructuralServiceView Transformation

Dienstag, 07. April 2009

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.

(more…)

KobrA2 Metamodellierung

Dienstag, 24. März 2009

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: Jan’s Diplomarbeit

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.

(more…)

Konzept zur Programmierung

Donnerstag, 26. Februar 2009

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"

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"

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.

Artikel zu meiner Diplomarbeit

Donnerstag, 19. Februar 2009

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

org.eclipse.uml2 - Erste Schritte und Erfolge

Donnerstag, 19. Februar 2009

Mir war einige Zeit unklar, wie ich beginnen soll, auf programmatischem Weg eine .uml-Datei mittels des UML2-Plugins von Eclipse zu erzeugen.

(more…)

XML-Datei parsen und XPath-Selektion erfolgreich

Montag, 16. Februar 2009

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.
(more…)

Model-Transformation mittels Java und XPath?

Montag, 16. Februar 2009

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?

Eclipse - Welches Package eignet sich für meine DA?

Montag, 16. Februar 2009

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 IDE for Java Developers
  • Eclipse IDE for J2EE Developers
  • Eclipse IDE for C/C++ Developers
    (kam natürlich nicht in Frage)
  • Eclipse IDE for RCP/Plugin Developers
  • Eclipse Modeling Tools (includes incubating components)
  • Eclipse IDE for Java and Report Developers
    (schied ebenfalls spontan aus, da ich keine Report-Unterstützung benötige)
  • Eclipse Classic 3.4.1

Eclipse - Compare Packages

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.

CaseStudy für die DA - Szenario und Beschreibung

Dienstag, 10. Februar 2009

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:

Szenario

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. (more…)