Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Transkript

1 Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 4: Domänenspezifische Sprachen Dr. Steffen Skatulla IBYKUS AG 1

2 Inhalt Teil 4: Domänenspezifische Sprachen Nutzung vorhandener Sprachen und Strukturen für DSLs UML, XML Sprachen mit dynamischer Typisierung: LISP, Ruby Tabellen, Excel-Sheets, Entwicklung eigener DSLs Textuelle und graphische DSLs Mögliche Techniken zur DSL-Entwicklung Xtext-Framework GMF-Framework IBYKUS Configuration Spaces Weitere Werkzeuge Selbststricken mit Parsergeneratoren Microsoft Visio & DSL-Tools Generic Modelling Environment (GME), MetaEdit+ Praktische Aspekte DSL-Evolution Modellierung von Verhalten Prinzipien: DRY, Defaults 2

3 Domänenspezifische Sprachen Konkrete Syntax zu einem Metamodell Verschiedene Varianten möglich, auch gleichzeitig Textuell, graphisch, tabellarisch, Zielstellung: primär gute Unterstützung der Modellierer Lesbarkeit Verständlichkeit Unterstützung von Denkweisen Technische Überlegungen sollten eher sekundär berücksichtigt werden Weitere Kriterien Geeignete Toolunterstützung Klare Prinzipien, Erweiterbarkeit, Modularität, Einfachheit der DSL 3

4 Nutzung vorhandener Sprachen und Strukturen für DSLs Interne DSL: wird mit Mitteln einer anderen Hostsprache ausgedrückt Vorhandene Werkzeuge können benutzt werden Editoren, Parser, UML XML Nutzung von Profilen, um den UML-Konstrukten neue eigene Bedeutungen aus der jeweiligen Domäne zu geben Definition einer abstrakten Syntax und Statischen Semantik mit XSD (XML Schema Definition) Immer einheitliche konkrete Syntax: verschachtelte XML-Elemente mit Attributen Vorteil: Werkzeuge Nachteil: keine Domänenspezifische Gestaltung Sprachen mit dynamischer Typisierung: LISP, Ruby Programme, die aussehen wie (deklarative) DSL Tabellen, Excel-Sheets, 4

5 Entwicklung eigener DSLs Externe DSL: eigene, speziellentwickelte Konstrukte Vorteil Genau anpaßbar an die Domäne und die Bedürfnisse der Modellierer Nachteil Keine Werkzeugunterstützung Aber es gibt Parsergeneratoren, DSL-Frameworks (DSL-Workbench) Textuelle vs. graphische DSL Graphische DSLs Übersicht Weglassen von Details Ausschnitte Präsentation, Diskussionsgrundlage Wichtig bei beiden: Werkzeugunterstützung Textuelle DSLs Genaue Details Umfassende Spezifikation 5

6 Textuelle DSL & Tools 6

7 Graphische DSL & Tools 7

8 Mögliche Techniken zur DSL-Entwicklung Xtext-Framework Ursprünglich aus dem openarchitectureware-projekt Jetzt TMF (Textual Modeling Framwork) im Eclipse Modeling Project Beschreibung der konkreten und gleichzeitig der abstrakten Syntax mit EBNF (Extended Backus-Naur-Form) EBNF DSL Model: (entities+=entity)+; Entity: "Entity" name=id "{" (attributes+=attribute)* "}"; Attribute: type=id name=id; Entity Kunde { String name Adresse adresse } Entity Adresse { String strasse String plz String ort } Daraus werden generiert Parser Metamodell basierend auf AST (Abstract Syntax Tree) Eclipse-Basierter Textueller Editor mit Syntax Highlighting, Code Completion, Validierung, Folding, Outline, 8

9 Eclipse-Basierter Textueller Editor 9

10 Mögliche Techniken zur DSL-Entwicklung GMF-Framework Basiert ebenfalls auf EMF Unterstützt die Konfiguration und automatische Genereierung von graphischen Editoren für EMF-Modelle Vorgehen Metamodell mit EMF erstellen GMF-Konfigurationsmodelle erstellen Mapping von Metamodell auf graphische Darstellung Konfiguration der Palette für Metamodellelemente Generieren des GMF-Editors mit Zeichenfunktionen, Palette, View für Elementproperties 10

11 Graphische DSL & Tools 11

12 Mögliche Techniken zur DSL-Entwicklung IBYKUS Configuration Spaces Einfache textuelle Beschreibung der Metamodelle (Konfigurationsräume) <attributedescription name="name" description="name der Komponente valuetype="str(80)"/>... <relationtype name="child" description="untergeordneter Knoten" class="child"> <relationpair from="ibk.nt.src-item" to="ibk.nt.src-item"/> <relationpair from="ibk.nt.src-component" to="ibk.nt.src-subcomponent"/>... </relationtype>... <nodetype name="component" description="komponente"> <attributeassignment name="ibk.ad.src-name" optional="false"/> <attributeassignment name="ibk.ad.src-description" optional="true"/>... <relationfrom relationtype="ibk.rt.src-child" tonodetype="ibk.nt.src-component optional="true"/>... </nodetype>... Generierung der Editoren Speicherung der Modelle im Repository Versionsverwaltung Inkrementelle Transformationen/Generierungen Unterstützung von Teilmodellen Unterstützung von Modellaspekten 12

13 IBYKUS CS-Editoren 13

14 Weitere Techniken zur DSL-Entwicklung Weitere Werkzeuge Selbststricken mit Parsergeneratoren Microsoft Visio & DSL-Tools Generic Modelling Environment (GME) MetaEdit+ 14

15 Best Practices DSL-Evolution: Don t break the public API DSLs entwickeln sich mit Projekt/Systemfamilie/Produktline DSLs sind öffentliche Schnittstellen, deshalb gleiche Spielregeln Verträge dürfen nicht gebrochen werden Weiterentwicklungen müssen abwärtskompatibel bleiben Wenn das nicht geht Dann müssen mit erheblichem Aufwand alle Modelle angepaßt werden Oder automatische Migrationen angeboten werden In jedem Fall ist saubere Versionierung das A und O 15

16 Best Practices Modellierung von Verhalten Implizite Modellierung von Verhalten bei strukturellen Aspekten Das Verhalten, das strukturelle Aspekte nach sich ziehen, wird implizit mit modelliert Für die Explizite Modellierung von Verhalten gibt es mehrere Varianten: Reduzierung des Verhaltens auf einfache Varianten und Optionen Beschreibbar mit üblicher deklarativer DSL Nur in speziellen einfachen Fällen möglich Z.B. on delete restrict cascade set null execute synchronous asynchronous Abbildung des Verhaltens auf einen Formalismus State Machines, Prädikatenlogik, Rule-Engines,... Nicht in allen Fällen effektiv möglich Vorteile Sehr klare, kompakte Notation und Semantik Toolunterstützung: Editoren, Codegeneratoren, Interpreter, 16

17 Best Practices Modellierung von Verhalten Verwendung einer Ausdruckssprache Eigene Sprache entwickeln oder vorhandene verwenden/anpassen (OCL, executable UML, ) I.d.R. sehr aufwendig: Sprache, Tools, Generator/Interpreter Verwendung der Sprache der Zielplattform Programmierung des Verhaltens z.b. in Java, SQL, Schaffung einer sinnvollen Schnittstelle zwischen generiertem und handgeschriebenem Code nötig Z.B. Generierung einer (Basis-)Klasse und Programmierung des Verhaltens in einer definierten Methode Problematisch wird es, wenn die handgeschriebene Methode auf den generierten Code zugreifen muß, z.b. um Aktionen auszulösen usw. Sehr effizient Aber wenig Informationen im Modell, deshalb Einbinden in Modell: Pfad zur Implementierung Grobe deklarative Beschreibung des Verhaltens (einfache Eigenschaften) je nach Bedarf 17

18 Best Practices Konkrete Syntax ist wichtig Zwar ist konkrete Syntax für Transformationen, Generierungen, Interpretierung irrelevant Aber konkrete Syntax ist wichtig für die Modellierer, DSL ist ihr tägliches Werkzeug Lesbarkeit, Verständlichkeit, Übersichtlichkeit Effiziente Aufschreibbarkeit Effiziente Syntax und Toolunterstützung können die Arbeit sehr effektivieren Prinzipien DRY: Don t repeat your self Keine doppelte Schreibarbeit Keine Pflege an verschiedenen Stellen Vermeidung von Inkonsistenzen Defaults: Configuration by Exception Häufigste Konfigurationsvarianten sollten als Defaults vorgesehen werden Dann sind in den meisten Fällen keine Angaben nötig Nur in Ausnahmefällen sind Angaben erforderlich 18

19 Zusammanfassung Nutzung vorhandener Sprachen und Strukturen für DSLs UML, XML Sprachen mit dynamischer Typisierung, Tabellen, Excel-Sheets, Entwicklung eigener DSLs Textuelle und graphische DSLs Mögliche Techniken zur DSL-Entwicklung Xtext-Framework, GMF-Framework, IBYKUS Configuration Spaces Best Practices DSL-Evolution: Don t break the public API Modellierung von Verhalten Konkrete Syntax ist wichtig Prinzipien DRY: Don t repeat your self Defaults: Configuration by Exception Als nächstes Codegenerierung, Modellinterpretation, Modelltransformationen 19