Best Practices für die Entwicklung von DSLs

Einen sehr interessanten Vortrag von Markus Völter auf der JAX 2009 gibt es jetzt als Video Stream. Seine Ausführungen stimmen zu sehr großen Teilen mit meinen Erfahrungen/Erkenntnissen im Bereich der modellgetriebenen Softwareentwicklung überein.

An dieser Stelle ein paar unsortierte Erkenntnisse, die mir nach dem Ansehen des Vortrags im Kopf herumschwirren. Für eine konkrete Einordnung in den Kontext sei an dieser Stelle nochmals das Video empfohlen.

• Verwendung von Standards ≠ Verständnis
  
  • gutes Beispiel UML + Profil was Standard (OMG) ist, aber durch die spezifische Stereotypen etc. nicht zwingend verständlich ist
  • eine klar definierte DSL mit begrenztem Scope ist meistens die bessere Alternative, da einfach auch die Toolunterstützung bzw. die Handhabung einfacher ist (z. B. Xtext)
• die Spezifikation eines UML Profils ist mühselig, komplex und unnötig aufwändig ebenso die Verwendung/Interpretation (bspw. in einem Generator)
• die Verwendung von verschiedenen Tools ist problematisch, erzeugt inhaltliche Brüche und führt zu unnötigen/nervigen Problemen
• Modell-zu-Modell (M2M) Transformationen sind sinnvoll um die Komplexität von Generatoren bzw. Templates zu reduzieren
• Prozess von Entwicklung DSLs:
  
  • siehe Bild rechts (Screenshot aus den Video)
  • viele, sehr kurze Iterationszyklen
• Textuelle DSLs sind eine pragmatische Lösung, die schnell zu ersten Ergebnissen führen
  
  • fühlt sich an sich wie Programmieren an
  • Benutzung von seit Jahren bewährten und ausgereiften Konzepten/Tools (z. B. Eclipse Editoren)
  • wenig Probleme hinsichtlich Zusammerarbeit, da bekannte Konzepte/Techniken für Quellcode verwendet werden können (CVS/SVN, Diff/Merge, ...) - das geht natürlich auch mit XMI (abstrakte Syntax), aber das ist wirklich nicht praxistauglich » bei textuellen DSLs funktioniert das auf der konreten Syntax!
  • einfache Skalierung, Partitionierung

  

  Teilschritte einer Iteration zur Entwicklung einer DSL

  
  

Kurzevaluation Modellierungswerkzeuge (UML)

Auf der Suche nach einem leichtgewichtigen UML-Werkzeug zur Modellierung eines Klassendiagramms probierte ich einige aus und möchte kurz meine Eindrücke beschreiben. Der Fokus lag dabei auf kostenfreien Tools, die auch nur die grafische Modellierung von Klassendiagrammen ermöglichen sollen. Genauer gesagt kann ich gut auf die ganzen CASE- bzw- MDA-Features verzichten, da diese die Modellierung nur unnötig verkomplizieren. Außerdem kann ein solches Modell immer noch mit anderen Tool, wie beispielsweise oAW, nach eigenen Anforderungen verarbeitet werden.

Betrachtete Features:

• Modellierung von Klassendiagrammen
• Speicherung im XMI-Format bzw. Exportfunktion
• Export für die Dokumentation (diverse Bildformate)

Fazit:

Für meine wenigen Anforderungen scheint ArgoUML am besten geeignet. Es ist schlank, also schnell heruntergeladen. Eine Installation ist nicht notwendig, da es als Java JAR ausführbar ist und somit auch auf allen Betriebssystemen läuft. Vom Funktionsumfang nimmt sich ArgoUML grob überblickt eigentlich nichts gegenüber den grafischen Editoren der Eclipse UML Tools. Allerdings lässt sich ArgoUML meiner Meinung nach einfacher bedienen und arbeitet direkt auf XMI in Version 1.2. Die UML Tools arbeiten dagegen mit einem XMI-Dialekt, der zwar auf XMI 2.x aufsetzt, sich aber einfach etwas von der originalen XMI-Spezifikation unterscheidet. Inwiefern sich beide Tools hinsichtlich der Weiterverarbeitung der Modelle - Stichwort MDA - eignen, lässt sich von mir nicht beurteilen.

Hinsichtlich der Komplexität der Handhabung der UML Tools könnte Topcased noch eine Alternative darstellen. Ich verwendete dieses Eclipse-Plugin, was auch auf dem Eclipse UML2-Projekt basiert vor zwei Jahren. Schon damals gab es eine reduzierte Property View, nichtsdestotrotz stellte sich die Modellierung mit diesem Werkzeug als enorm schierig dar. Ich kann nicht sagen, ob das Topcased-Plugin seither verbessert wurde, da zur Zeit die Website offline ist.

Die restlichen von mir kurz betrachteten Modellierungswerkzeuge sind hinsichtlich meiner Anforderungen schlichtweg ungeeignet, da meistens das XMI-Format nicht unterstützt wird oder eine Exportunktion für die Dokumentation fehlt.

Details zu verschiedenen Tools:

TinyUML

• nur Klassendiagramme
• kein XMI
• benötigt Java 6
• Export in SVG, PNG
• http://sourceforge.net/projects/tinyuml

UMLet

• kein XMI
• merkwürdige Auswahl und Bearbeitung von Diagramm-Elementen
• Java Standalone, Eclipse Plugin
• viele Diagrammartens
• Export in SVG, PDF, EPS
• http://www.umlet.com/

BeoModeler

• Webbasiert, Speicherung im XMI-Format (aber nicht valide, evtl. führt ein wenig Bearbeitung im Texteditor zu validen Dateien?!)
• nur einfache Klassendiagramme (z. B. keine Typisierung von Attributen)
• Export: Rational Software Modeler, Topcased
• kein Bildexport
• http://www.beotic.org/

Jink UML

• absolut proprietär
• nur "Klassendiagramm"
• kein XMI, kein Export
• Handhabung unter Mac OSX nicht klar/unfunktional
• http://code.google.com/p/jink-uml/

ArgoUML

• viele Diagrammarten
• für den Funktionsumfang relativ schlank (8 MB)
• Speicherung als komprimiertes XMI
• Export und Import von XMI-Dateien
• Bildexport: PNG, SVG, GIF, PS, EPS
• Java, auch als Webstart Anwendung verfügbar
• http://argouml.tigris.org/

Eclipse UML Tools

• viele Diagrammarten
• Modeling Distribution sehr groß (>300 MB)
• arbeitet auf Basis vom Ecore UML2 XMI-Dialekt
• Export: GIF, BMP, JPG, PNG, SVG, PDF
• integriert in der Eclipse-IDE
• Bearbeitung von Eigenschaften über die Property View ist immer noch etwa gewöhnungsbedürftig - hier wünscht man sich die Möglichkeit die angezeigten Eigenschaften zu definieren/einzuschränken, wie es z. B. bei MagicDraw funktioniert
• Speicherverbrauch erfahrungsgemäß sehr hoch
• http://www.eclipse.org/downloads/

Links

• Comparison of some selected UML tools

Verwendung vom Eclipse UML2 Projekt zur Bearbeitung von UML2-Modellen und Profilen

Das Eclipse UML2 Projekt findet bereits in einigen Werkzeugen (z. B. Topcased UML Editor) Verwendung. Allerdings sind diese Tools zumeist Eclipse-Plugins die das Projekt innerhalb der Eclipse Umgebung verwenden. Möchte man UML2 in einer eigenständigen Java-Anwendung oder im Rahmen eines Unit-Tests verwenden, müssen einige Initialisierungen durchgeführt werden. Das nachfolgende Listing zeigt das erforderliche Setup:

protected static void registerResourceFactories(){
  Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().
    put(UMLResource.FILE_EXTENSION, new UML22UMLResourceFactoryImpl());
  Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().
    put("ecore", new EcoreResourceFactoryImpl());
  Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().
    put("ecore2xml", new EcoreResourceFactoryImpl());
}

protected static void registerPathmaps(URI uri) {
  URIConverter.URI_MAP.put(URI.createURI(UMLResource.LIBRARIES_PATHMAP),
    uri.appendSegment("libraries").appendSegment(""));
  URIConverter.URI_MAP.put(URI.createURI(UMLResource.METAMODELS_PATHMAP),
    uri.appendSegment("metamodels").appendSegment(""));
  URIConverter.URI_MAP.put(URI.createURI(UMLResource.PROFILES_PATHMAP),
    uri.appendSegment("profiles").appendSegment(""));
  final String UML2_200_NS_URI = "http://www.eclipse.org/uml2/2.0.0/UML";
  EPackage.Registry.INSTANCE.put(UML2_200_NS_URI,
    EPackage.Registry.INSTANCE.get(UMLPackage.eINSTANCE.getNsURI()));
  Ecore2XMLPackage.eINSTANCE.getEClassifiers();
}

private static void registerMapping(URI uri) {
  final String ECORE2XML = "platform:/plugin/org.eclipse.uml2.uml/
    model/UML2_2_UML.ecore2xml";
  URIConverter.URI_MAP.put(URI.createURI(ECORE2XML),
    uri.appendSegment("model").appendSegment("UML2_2_UML.ecore2xml"));
}

Mit Hilfe der vorhergehenden Initialisierungen lässt sich ein UML2-Profil (XMI Version 2.x) laden und kann zur Modellierung verwendet werden.

 private Profile loadProfile() {
  registerResourceFactories();
  URI uri = URI.createURI("resources");
  registerPathmaps(uri);
  registerMapping(uri);
  URI profileFile = URI.createFileURI("MyProfile.profile.uml");
  Resource r = new ResourceSetImpl().getResource(profileFile, true);
  Profile p = (Profile) EcoreUtil.getObjectByType(r.getContents(),
    UMLPackage.Literals.PROFILE);
  return p;
}