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.
