Was Sie schon immer wissen wollten

Ein Status kommt selten allein …

… und wie nennt man nun mehrere davon? Vielleicht „Stati”, Staten oder gar „Statusse”? Viele der Fremdwörter auf -us, die aus dem Lateinischen oder Griechischen übernommen wurden, bilden den Plural mit der deutschen Endung -e[n], so z. B. „Virus – Viren”, „Zyklus – Zyklen” oder „Globus – Globen/Globusse” (beides ist möglich!). Einige tanzen jedoch aus der Reihe und behalten ihre ursprüngliche Pluralform bei. Auch der Status konnte sich von seinen lateinischen Wurzeln nicht trennen und bildet seinen Plural nach wie vor mit der Endung -us (mit lang gesprochenem u!), also „die Status”. Genauso verhält es sich übrigens auch bei „(der) Passus – (die) Passus” und „(der) Kasus – (die) Kasus”.

Jetzt können sie kommen, die Status!

Go to your domain that you want to adjust, and click Setup. Make sure the CGI and FastCGI options are enabled. Pick a name for your application and make the directory for your application in the httpdocs directory. Upload your files to that directory.

Once you’ve done that, create an .htaccess file in the httpdocs directory with the following text inside:

RewriteEngine On
RewriteRule ^$ /public/index.html [L]
RewriteCond % !^/railsapp/public
RewriteRule ^(.*)$ /public/$1 [L]
RewriteCond % !-f
RewriteRule ^(.*)$ public/dispatch.fcgi/$1 [QSA,L]

Remove the .htaccess file within the public directory of your application and add a file called dispatch.fcgi to that directory which contains:

#!/usr/bin/ruby

You should be able to access your application at http://domain.com/railsapp/

Thx Major Hayden 4 the information

https://bugs.launchpad.net/ubuntu/+source/rubber/+bug/338285

Einfach den Patch, der dort verlinkt ist herunterladen und dann …

You just need to download the patch file to somewhere convenient (let’s say a folder called ~/rubberpatch) and then run the patch tool:

cd ~/rubberpatch
sudo patch /usr/share/rubber/rubber/util.py util.py.diff

Dat wars

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.

Noch ein paar Hintergrundinformationen, bevor es zur Sache geht: Im Prinzip geht es darum, ein KobrA2-Modell (SUM), für das ich ein auf MDT UML basiertes Metamodell erstellt habe, in ein UML-Modell (View) zu transformieren. Dabei sollen speziell für die sogenannte SpecificationStructuralServiceView der KobrA2-Methode nur die «subject»-Komponente mit ihren public Attributen und Methoden, alle «acquired» Komponenten samt public Attributen und Methoden, sowie alle Generalisierungen (rekursiv) der Komponenten mit public Attributen und Methoden aus dem SUM extrahiert werden.

Bis jetzt gehe ich davon aus, dass ich zusätzlich noch die verwendeten “Types” transformieren muss, obwohl in der KobrA2-Methode eine eigene View für die verwendeten Types vorgesehen ist. Doch während ich eben darüber nachgedacht habe, kann es sein, dass es ausreicht auf die Elemente im SUM zu referenzieren, falls sie nicht für die Transformation vorgesehen sind. Ob und inwieweit dies möglich ist, muss ich allerdings noch untersuchen.

Nun zum Eingemachten

SUM->View Pseudocode

Der Hauptteil ist eigentlich ganz simpel. Und auch die folgenden ausgelagerten Funktionen sollten eigentlich selbsterklärend sein …
k2s = select subject in SUM
s = addComponentClass(k2s)
apply stereotype «subject» to s
.
k2aCCs = select acquired componentClasses in SUM
for each k2cc in k2aCCs:
cc = addComponentClass(k2cc)
a = add association between s and cc
apply stereotype «acquired» to a
.
//TODO: add comments or better add constraints? or add both?
//but don't know yet how -.-

function addComponentClass(k2cc):
if not k2cc already passed transformation:
c = create class in view
apply stereotype «componentClass» to c
addPublicAttributes(k2cc, c)
addPublicOperations(k2cc, c)
addGeneralizations(k2cc, c)
return c
else:
return class of view that represents k2cc

function addPublicAttributes(k2classifier, classifier):
for each k2property in (get owned attributes of k2classifier):
if visibility of k2property is public:
k2type = type of k2property
translatedType = mapType(k2type)
add attribute of translatedType with same name as k2property to classifier

function addPublicOperations(k2class, class):
for each k2operation in (get owned operations of k2class):
if visibility of k2class is public:
op = create operation in class with same name as k2operation
for each k2param in (get owned parameters of k2operation):
k2type = type of k2param
translatedType = mapTyppe(k2type)
param = add parameter of translatedType with same name as k2param to op
set direction of param (same as k2param)
set multiplicities of param if values != 1 (same as k2param)
add op to class

function addGeneralizations(k2classifier, classifier):
for each k2general in (get general classifiers of k2classifier):
if k2classifier is instance of K2ComponentClass:
general = addComponentClass(k2general)
if k2classifier is instance of Class:
//this includes the case that k2classifier is a K2Class
general = addClass(k2general)
if k2classifier is instance of Interface:
general = addInterface(k2general)
else:
????
//what about PrimitiveType and Enumeration???
general = null
.
add generalization to classifier that points to general

function addClass(k2class):
if k2class has an according element in the view:
if attributes and operations are missing:
c = select Class from view
else
c = create Class in view
.
if c is not null:
addPublicAttributes(k2class, c)
addPublicOperations(k2class, c)
addGeneralizations(k2class, c)
.
return c

function addInterface(k2interface):
if k2interface has an according element in the view:
if attributes and operations are missing:
i = select Interface from view
else
i = create Interface in view
.
if i is not null:
addPublicAttributes(k2interface, i)
addPublicOperations(k2interface, i)
addGeneralizations(k2interface, i)
.
return i

function mapType(k2type):
if k2type has an according element in the view:
viewType = according element
else:
if k2type is instance of K2ComponentClass
//is this component automatically acquired???
viewType = addComponentClass(k2type)
else
//classifiers are added without any operations and attributes
viewType = create Type of same MetaClass as k2type in view
.
return viewType

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.

Erweiterung des UML-Metamodells

Die Aufgabenstellung meiner Diplomarbeit fordert die Erzeugung eines simplen Metamodells, so dass die in erster Linie geforderten Transformationen (SUM->View und View->SUM) realisiert werden können. Eine Erweiterung des UML-Metamodells liegt quasi auf der Hand.

Da die Views selbst mit einer Lightweight Erweiterung der UML (durch Profile/Stereotypen) umgesetzt werden sollen, war mein erster Gedanke natürlich, auch das Metamodell des SUM über die Lightweight Extension zu realisieren, so dass das Quell- und Zielmodell der Transformationen im Prinzip das selbe Metamodell haben. Der Lehrstuhl allerdings propagiert die Erstellung eines eigenen KobrA2-Metamodells, so dass letztendlich nur eine Middle- oder Heavyweight Extension der UML in Frage kommt, wenn man die Vorteile der Metamodellierung mittels MDT UML2 nutzen möchte (vgl. Abschnitt 3.3.1 in Jans DA):

• property redefinition
• property subsetting
• profiles (users of your metamodel can extend it using profiles just like you can extend UML)
• package merge to separate the concerns in your DSL (not really much impact on the generated result, though)
• pluralized getter methods for singular property names

Plus, you get certain code-generation enhancements provided by UML2:

• Operations classes to factor out single implementations of your operations in a multiple-inheritance context
• derived-value caching in the CacheAdapter
• creation methods (including support for named elements)
• name-based search accessors for list properties

Die Wahl fiel schließlich auf die Middleweight-Extension, aus Gründen, die bereits Jan in seiner Diplomarbeit erwähnt, weshalb ich hier nicht weiter darauf eingehe. Jedoch die Vor- und Nachteile der Middleweight-Extension möchte ich an dieser Stelle nochmals auflisten:

Vorteile

• First class extension mechanism.
• Easier than heavyweight to create initially.
• Easy for end user to use programmatically than profiles.
• Can add behavior.
• Can add structure.
• Can add constraints.

Nachteile

• Creates dependence on specific version of UML.
• Difficult to maintain especially if UML changes.
• User must know about 2 factories for creating elements, the UMLFactory and the new one defined by the extension.

(Quelle: James Bruck, Christian Damus; Tutorial: Creating Robust Scalable DSLs with UML; eclipseCON 2008)

KobrA2 Metamodell erstellen

Nun zum praktischen Teil

Ich gehe mal davon aus, dass der Leser - falls er (also du) diese Schritte nachvollziehen möchte - die erforderlichen Eclipse-Plugins bereits installiert hat, bzw. selbst herausfinden kann, was er benötigt, weshalb ich an dieser Stelle nur mit zwei Stichworten Hilfestellung geben möchte: EMF und UML2.

Zunächst habe ich in Eclipse ein neues Projekt erstellt, genauer gesagt ein neues EMF Project. Hier habe ich Jan’s UML-KobrA2-Metamodell eingefügt, das ich dann mit dem mit MDT UML2 mitgelieferten Editor öffnen konnte. Dieser Editor bietet zwar die Möglichkeit, ein Modell in ein Metamodell umzuwandeln, doch dieser Schritt war nicht mehr notwendig, da ja bereits ein Metamodell vorlag.

Nachdem ein Modell bereits in ein Metamodell umgewandelt wurde, ist es notwendig einer neu hinzugefügten Klasse den Stereotyp Metaclass zu verpassen, um sie zur Metaklasse aufzuwerten. Das benötigte UML-Profil wurde bei der Umwandlung automatisch referenziert.

Nach den bereits in der Einleitung erwähnten Umstrukturierungen und Ergänzungen einiger Metaklassen hatte ich schließlich eine erste Version meines KobrA2-Metamodells. Als nächstes versuchte ich das Metamodell mittels Topcased zu visualisieren, was mir auch ohne Probleme gelang und mir war es auf komfortablem Weg möglich kleinere Änderungen vorzunehmen. Vor allem die Generalisierungen der KobrA2-Elemente ließen sich so sehr einfach in das Metamodell einfügen.

KobrA2 Metamodell (MDT UML2 basiert)
KobrA2 Metamodell grafisch (z.B. für Topcased)

Baumstruktur des Metamodells

Structure Package des Metamodells in Topcased

EMF-Model (generator model) erstellen

Der nächste Schritt war, dem Projekt ein EMF Model hinzuzufügen, das auf dem erstellten Metamodell basiert. Im Package Explorer von Eclipse rief ich über RECHTSKLICK auf den Ordner MODEL > NEW > OTHER > ECLIPSE MODELING FRAMEWORK > EMF MODEL den entsprechenden Wizard auf.

Im Wizard muss man zunächst den Namen des EMF Model mit der Endung .genmodel angeben. Im nächsten Schritt wählt man als Model Importer den Eintrag UML Model. Nach einem Klick auf next habe ich dann das erstellte KobrA2 Metamodell ausgewählt und bei den Optionen zunächst auf Process All geklickt und anschließend die Option Camel Case Names wieder auf ignore gestellt, so dass die von mir verwendeten Namen 1:1 übernommen werden. Im letzten Schritt des Wizards habe ich als root package das Metamodell ausgewählt (Eintrag KobrA2SUM) und die übrigen Modelle (ecore und UML2) referenziert.

Das Ergebnis waren zwei Dateien: das generator model (KobrA2Metamodel.genmodel) und eine ecore-Repräsentation des Metamodells (KobrA2SUM.ecore).

Code generierung

Öffnet man nun das generator model mit dem entsprechenden Editor erhält man in Eclipse wieder eine Baumstruktur. Mit einem Rechtsklick auf den Wurzelknoten des Baums erhält man die Einträge zur Code-Generierung.

Ich möchte hier nicht weiter auf die Code-Generierung eingehen, da es hierzu ausfürliche Tutorials in der Eclipse documentation gibt, z.B. Generating an EMF Model.

Schlusswort

Den generieten Code werde ich in weitere Schritten verwenden, um meine Modelltransformationen zu programmieren - zumindest werde ich es versuchen

So, genug an dieser Stelle. Ich habe Bärenhunger und muss mal sehen, was es im Kühlschrank zu jagen gibt.

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.

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