SuS-06.4: Modellgetriebene Softwareentwicklung
Werbung
Software ubiquitärer Systeme Modellgetriebene Softwareentwicklung Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund [email protected] http://ess.cs.uni-dortmund.de/~os/ http://ess.cs.tu-dortmund.de/DE/Teaching/SS2011/SuS/ 1 Agenda ● ● ● ● ● ● Motivation/Idee Konzepte Beispiele für Modellierungswerkzeuge „richtige“ MDSD: Standards, Werkzeuge und Techniken Modellierung von Kontext Zusammenfassung 06.4 – Modellgetriebene Softwareentwicklung 2 Motivierendes Beispiel ● Anwendung SmartSpeaker[3] kontextabhängige Regelung der Lautstärke (für Musik etc.) ● lauffähig auf unterschiedlichen Hard- und Softwareplattformen ● HW: HW: Nokia Nokia Smartphone Smartphone SW: SW: J2ME, J2ME, Java Java HW: HW: iPAQ iPAQ PDA PDA SW: SW: Windows, Windows, C-Sharp C-Sharp 06.4 – Modellgetriebene Softwareentwicklung 3 Motivierendes Beispiel public public class class SmartSpeaker SmartSpeaker public public SmartSpeaker() SmartSpeaker() super(); super(); }} extends extends MIDlet MIDlet {{ {{ protected protected void void startApp() startApp() throws throws MIDletStateChangeException MIDletStateChangeException {{ Display display = Display.getDisplay(this); Display display = Display.getDisplay(this); Form Form SmartSpeakerMainFrame SmartSpeakerMainFrame == new new Form("SmartSpeaker"); Form("SmartSpeaker"); SmartSpeakerMainFrame.append(new SmartSpeakerMainFrame.append(new StringItem(" StringItem(" Current Current Location","")); Location","")); SmartSpeakerMainFrame.append(new StringItem(" Current SmartSpeakerMainFrame.append(new StringItem(" Current Volume","")); Volume","")); ... ... ... ... display.setCurrent(SmartSpeakerMainFrame); display.setCurrent(SmartSpeakerMainFrame); }} ... ... ... ... public public class class SmartSpeaker SmartSpeaker :: System.Windows.Forms.Form System.Windows.Forms.Form {{ private private System.Windows.Forms.Label System.Windows.Forms.Label CurrentLocation_label; CurrentLocation_label; private System.Windows.Forms.TextBox private System.Windows.Forms.TextBox CurrentLocation_textBox; CurrentLocation_textBox; ... ... ... ... public public SmartSpeaker() SmartSpeaker() {{ InitializeComponent(); InitializeComponent(); ... ... ... ... }} ... ... ... ... private private void void InitializeComponent() InitializeComponent() {{ this.CurrentLocation_label this.CurrentLocation_label == new new System.Windows.Forms.Label(); System.Windows.Forms.Label(); this.CurrentLocation_textBox this.CurrentLocation_textBox == new new System.Windows.Forms.TextBox(); System.Windows.Forms.TextBox(); ... ... ... ... this.CurrentLocation_label.Size this.CurrentLocation_label.Size == new new System.Drawing.Size(128, System.Drawing.Size(128, 16); 16); this.CurrentLocation_label.Text = "Current this.CurrentLocation_label.Text = "Current Location:"; Location:"; this.CurrentLocation_label.ParentChanged this.CurrentLocation_label.ParentChanged += += new new System.EventHandler(this.CurrentLocation_label_ParentChanged); System.EventHandler(this.CurrentLocation_label_ParentChanged); this.CurrentLocation_textBox.Size = new System.Drawing.Size(80, this.CurrentLocation_textBox.Size = new System.Drawing.Size(80, 22); 22); this.CurrentLocation_textBox.Text this.CurrentLocation_textBox.Text == ""; ""; this.CurrentLocation_textBox.TextChanged this.CurrentLocation_textBox.TextChanged += += new new System.EventHandler(this.CurrentLocation_textBox_TextChanged); System.EventHandler(this.CurrentLocation_textBox_TextChanged); ... ... ... ... 06.4 – Modellgetriebene Softwareentwicklung 4 Motivierendes Beispiel ● den GUI-Code von Hand zu erzeugen ist aufwändig ● und das für mehrere Softwareplattformen (JavaME, Windows/C#, ...) ● … ganz zu Schweigen von verschiedenen Arten von Anzeigen... ● Größe („passt dieses Eingabefeld so auf die Anzeige?“) ● Auflösung („ist Schriftgröße x auf Gerät y noch lesbar“) ● Anzahl Farben 06.4 – Modellgetriebene Softwareentwicklung 5 Problem ● ● ● viele Konventionen manuell einzuhalten. ● fehleranfällig! ● viel gleichförmiger rein „architektureller Code“, der im Grunde keine (anwendungsspezifische) Information beinhaltet ● pflegen derselben Information an unterschiedlichen Stellen Eigentlich sollte man ● Informationen nur an einer Stelle pflegen müssen (DRY*) ● sich nicht x-fach über die korrekte Benutzung Gedanken machen müssen Ist das Problem auf GUIs beschränkt? → höhere Abstraktionsebene *don't repeat yourself 06.4 – Modellgetriebene Softwareentwicklung 6 bekannte Beispiele: Abstraktion++ ● manuelle GUI-Instantiierung? → ● Stubs für Remote Procedure Calls: nötig für Marshalling und Versenden der Parameter ● manuelle Implementierung? → Beschreibung der Schnittstelle in IDL automatische Generierung ● 06.4 – Modellgetriebene Softwareentwicklung 7 MDSD-Idee Assembler Modell Problem Maschinencode Hochsprache Abstraktionsgrad Quelle: [2] ● logischer weiterer Schritt den Abstand zwischen Problem und Lösung zu verringern, durch Abstraktion von den Details der unterliegenden Plattform ● automatische Transformation in die Idiome der unterliegenden Plattform ● Idiom: Muster zur Verwendung von Plattform-Features Hardware/Assembler: Parameterübergabe beim Funktionsaufruf ● Software-Plattform: Marshalling, Design Patterns, ... ● 06.4 – Modellgetriebene Softwareentwicklung 8 Begriffe 06.4 – Modellgetriebene Softwareentwicklung 9 Modellgetriebene Softwareentwicklung ● Definition Modellgetriebene Softwareentwicklung ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen¹ [1] ● formale Modelle ● Beschreiben einen Aspekt² eines Softwaresystems vollständig - Struktur (z.B. Komponenten-/Klassendiagramm) - Verhalten (z.B. Statechart) ● gehorchen einem strengen Schema/Regeln (Metamodell) - kann vieles sein (nicht nur UML) ¹) einschließlich Interpretation zur Laufzeit ²) im umgangssprachlichen Sinn 06.4 – Modellgetriebene Softwareentwicklung 10 Modellgetriebene Softwareentwicklung ● ● ● eindeutige Beziehung zwischen Modell und lauffähiger Software Modelle sind ein Teil der Implementierung und haben denselben Stellenwert wie (handgeschriebener) Quellcode! generierter Quellcode darf nicht manuell geändert werden! 06.4 – Modellgetriebene Softwareentwicklung 11 Metamodell meta von altgr. μετά = „danach, hinter, jenseits“ ● Formale Modelle sind Instanzen eines Metamodells. ● Ein Metamodell sagt etwas über Modelle aus. ● abstrakte Syntax ● statische Semantik Modell Metamodell Instanz von Teil des Metamodells für UML 2.0, Quelle: [2] 06.4 – Modellgetriebene Softwareentwicklung 12 Modellierungssprachen ● ● ● ● Metamodell definiert nur abstrakte Syntax zusammen mit einer konkreten Syntax erhält man die Modellierungssprache (auch domänenspezifische Sprache (DSL) genannt) konkrete Syntax kann textuell oder grafisch sein Beispiel: 2 verschiedene Modellierungssprachen mit gleichem Metamodell FSM(ready) FSM(ready) {{ ready->wash(start) ready->wash(start) wash->pause(opened) wash->pause(opened) pause->wash(closed) pause->wash(closed) wash->ready(finished) wash->ready(finished) }} 06.4 – Modellgetriebene Softwareentwicklung 13 Statische Semantik ● syntaxkonforme Modelle nicht automatisch gültig/sinnvoll. ● ● nicht erreichbare Zustände in einer state machine sind z.B. ein Indiz dafür, dass irgendetwas nicht stimmt Problem: diese Regeln über die Syntax auszudrücken würde die Syntax unnötig komplex machen ● evtl. kontextsensitive Grammatiken nötig machen ● ● Diese Regeln werden daher nach dem Parsen überprüft → statische Semantik ● vgl. z.B. Typprüfung im Compiler ● void foo() { void foo() { int eastwood; int eastwood; eastwood=”bar”; eastwood=”bar”; }} 06.4 – Modellgetriebene Softwareentwicklung 14 Transformation ● eine Transformation erzeugt aus einem Modell ● das Endprodukt – M2T (Codegenerator, „Modellcompiler“) - ● Quellcode einer Hochsprache Bytecode Dokumentation Konfigurationsdateien Webseiten Hardwarebeschreibungen … ein anderes Modell – M2M - um Änderungen an einem Modell vorzunehmen - um eine niedrigere Abstraktionsebene zu erreichen 06.4 – Modellgetriebene Softwareentwicklung 15 Zwischenstand ● Metamodelle beschreiben Konzepte einer Domäne ● besitzen eine statische Semantik ● besitzen eine abstrakte Syntax ● ● domänenspezifische Sprachen besitzen ein Metamodell ● besitzen eine konkrete Syntax ● besitzen eine Semantik ● ● Modelle sind Instanzen eines Metamodells ● werden mit Hilfe domänenspezifischer Sprachen beschrieben ● können interpretiert werden ● können transformiert werden ● 06.4 – Modellgetriebene Softwareentwicklung 16 Beispiele für Modellierungswerkzeuge 06.4 – Modellgetriebene Softwareentwicklung 17 … außer Zustandsdiagrammen ● architekturzentrierte DSLs ● Metamodell beschreibt Konzepte einer Softwareplattform ● Modell beschreibt deren Instantiierung ● Beispiele: - Komponentenmodell - GUI-Modell - Datenbankmodell ● rein fachliche DSLs Eine DSL zur Beschreibung von Bayes-Netzen ● Domäne enthält wenige oder gar keine Softwarekonzepte ● Beispiele: - mathematische oder naturwissenschaftliche Modelle - Geschäftsprozesse → Geeignet für die Einbeziehung von Domänenexperten 06.4 – Modellgetriebene Softwareentwicklung 18 Automotive Softwareentwicklung ● Gründe für MDSD ● Einsparung von Kosten (Entwicklungsdauer) ● Sicherheitsanforderungen - weniger Fehler durch domänenspezifische Sprachen - generierte Software evtl. automatisch zertifiziert ● ● Beispiele: Simulink + Stateflow ● Erweiterungen für Matlab ● Simulink – kontinuierliche Modellierung/Simulation ● Stateflow – diskrete Modellierung/Simulation ● jeweils vorgegebenes Metamodell ● verschiedene Werkzeuge können aus diesen Modellen Code für verschiedene Hardwareplattformen generieren (z.B. TargetLink) „praktisches“ Beispiel: Yakindu → 06.4 – Modellgetriebene Softwareentwicklung 19 Modelle in der Automobilindustrie Stateflow Simulink 06.4 – Modellgetriebene Softwareentwicklung 20 Beispiel mit Yakindu Modellierung der Funktionalität eines Gangwahlschalters (aus dem Bachelor-Fachprojekt „Software im Automobil“) Hebelstellung Knopf gedrückt (Sport-, Park-, Schalt-) LEDs an/aus (R, N, D, Park, Tiptronic, Sport) blockieren Gangwahlschalter sendet Statusnachrichten und empfängt Befehle 06.4 – Modellgetriebene Softwareentwicklung Steuergerät mit Statemachine implementiert die eigentliche Funktionalität 21 „echte“ MDSD 06.4 – Modellgetriebene Softwareentwicklung 22 MDSD-Werkzeuge ● Bisher: Werkzeuge für festes Metamodell zu spezifisch → nur für diese (Sub-)Domäne brauchbar ● zu generisch → Metamodelle werden unnötig kompliziert, mehr Möglichkeiten für Fehler ● ● eigentliches Potential der MDSD liegt woanders eigene, domänenspezifische Metamodelle ● enthalten nur die Konzepte der Domäne ● ● Parser/Editor + Generator von Grund auf neu schreiben? Muss für jede Domäne neu gemacht werden ● Trotz gewisser Hilfsmittel (Parsergeneratoren) aufwändig ● → würde sich nur in seltenen Fällen lohnen ● ● andere Möglichkeiten? interne DSLs ● „Metawerkzeuge“ für externe DSLs ● 06.4 – Modellgetriebene Softwareentwicklung 23 interne DSLs ● DSL ist Teilmenge einer anderen Sprache ● ● ● im Wesentlichen eine Bibliothek Vorteil: „geschenkter“ Parser Möglichkeiten für konkrete Syntax sind beschränkt → evtl. völlig unbrauchbar ● Beispiele Definition eines XML-Schemas ● Definition eines UML2-Profils ● rake → ● file file sh sh end end file file sh sh end end 'hello.o' 'hello.o' 'cc 'cc -c -c -o -o => => ['hello.c'] ['hello.c'] do do hello.o hello.o hello.c' hello.c' 'hello' 'hello' => => ['hello.o'] ['hello.o'] do do 'cc 'cc -o -o hello hello hello.o' hello.o' 06.4 – Modellgetriebene Softwareentwicklung 24 Beispiel: State Machine mit Boost struct struct ready; ready; struct struct WashingMachine WashingMachine :: state_machine< state_machine< WashingMachine, WashingMachine, ready> ready> {}; {}; struct struct struct struct struct struct ready ready :: simple_state< simple_state< ready, ready, WashingMachine WashingMachine wash : simple_state< wash, wash : simple_state< wash, WashingMachine WashingMachine >> pause pause :: simple_state< simple_state< pause, pause, WashingMachine WashingMachine struct struct struct struct struct struct struct struct start start :: event< event< start start >> {}; {}; finish : event< finish : event< finish finish >> {}; {}; open open :: event< event< open open >> {}; {}; close close :: event< event< close close >> {}; {}; struct struct pause pause :: simple_state< simple_state< typedef typedef transition< transition< close, close, }} pause, pause, wash wash >> struct struct wash wash :: simple_state< simple_state< wash, wash, {{ typedef typedef mpl::list< mpl::list< custom_reaction< custom_reaction< finish finish >, >, transition< finish, ready transition< finish, ready >> >> reactions; reactions; result result wash::reaction( wash::reaction( &finish &finish )) {{ cout << “FERTIG!”; cout << “FERTIG!”; return return [TODO] [TODO] }} int int main() main() {{ WashingMachine WashingMachine wm; wm; wm.initiate(); wm.initiate(); wm.processEvent(start()}; wm.processEvent(start()}; // // ... ... }} WashingMachine> WashingMachine> {{ reactions; reactions; WashingMachine WashingMachine >> result result reaction( reaction( &finish &finish ); ); }; }; >> {}; {}; {}; {}; >> {}; {}; ● generative Programmierung z.B. mit Untermenge von C++-Templates als DSL ● Modell = Graph von Template-Instanzen ● Vorteile: - mit „Bordmitteln“ machbar - keine externen Tools nötig ● Nachteile - weniger gut les-/editierbar - weniger geeignet für Nicht-C++ler ● 06.4 – Modellgetriebene Softwareentwicklung 25 MDSD-Werkzeuge ● Bisher: Werkzeuge für festes Metamodell zu spezifisch → nur für diese (Sub-)Domäne brauchbar ● zu generisch → Metamodelle werden unnötig kompliziert, mehr Möglichkeiten für Fehler ● ● eigentliches Potential der MDSD liegt woanders eigene, domänenspezifische Metamodelle ● enthalten nur die Konzepte der Domäne ● ● Parser/Editor + Generator von Grund auf neu schreiben? Muss für jede Domäne neu gemacht werden ● Trotz gewisser Hilfsmittel (Parsergeneratoren) aufwändig ● → würde sich nur in seltenen Fällen lohnen ● ● andere Möglichkeiten? interne DSLs ● „Metawerkzeuge“ für externe DSLs ● 06.4 – Modellgetriebene Softwareentwicklung 26 Werkzeuge für externe DSLs ● Input Metamodell-Beschreibungen ● Modell-Constraints (über Constraint-Sprachen) ● Transformationsregeln (Mapping-Sprachen, Template-Sprachen) ● ● Output Modell-Editoren ● Modell-Parser ● Checker für statische Semantik ● Modell-Transformationen ● → „Metawerkzeuge“ Vorraussetzung dafür ist natürlich, dass das Metamodell ebenfalls formal ist! 06.4 – Modellgetriebene Softwareentwicklung 27 Metametametametametametametametameta metametametametametametametametameta Metametamodell Metametamodell Metamodell Metamodell Modell Modell ● ● Meta → relative Beziehung Konsens: Quelle: Wikipedia statisches Anwendungsmodell → Modell ● Metamodell des Anwendungsmodells → Metamodell ● Metamodell des Metamodells: → Metametamodell ● ● i.d.R ist beim Metametamodell auch Schluss mit Meta 06.4 – Modellgetriebene Softwareentwicklung 28 (Quasi-)Standards in der MDSD ● MDA – Model-Driven Architecture MDSD-Standard der OMG ● diverse Werkzeuge ● Metametamodell: MOF ● ● EMF – Eclipse Modeling Framework Werkzeug & „Quasistandard“ ● Metametamodell: Ecore ● ● xPand früher openArchitectureWare ● Generatorframework (für EMF, MDA, ...) ● ● XML Definition von Metamodellen über XML Schema Definitions ● oft Speicher-/Austauschformat für Modelle: ● - XML Metamodel Interchange (XMI) 06.4 – Modellgetriebene Softwareentwicklung 29 Model-Driven Architecture ● vordefinierte Metamodelle ● ● bekanntestes Beispiel: Klassendiagramme Metamodellierung? ● im Prinzip eigene Metamodelle m.H. der MOF definierbar ● üblich Profile: Menge von Prototypen „Spezialisierung“ existierender UML-Elemente ● Ziel: hauptsächlich (Software-)Plattformunabhängigkeit ● weniger die Einbindung von Domänenexperten ● Platform Independent Model (PIM): Anwendungsmodell ● Platform Specific Model (PSM): EJB, CORBA, ... 06.4 – Modellgetriebene Softwareentwicklung 30 Metaebenen bei EMF Modell Modell Metametamodell Metametamodell Metamodell Metamodell 06.4 – Modellgetriebene Softwareentwicklung 31 Metawerkzeuge ● Metawerkzeuge verwenden Metamodellbeschreibungen um die eigentlichen Werkzeuge bereitzustellen Editor ● DSL-Parser ● ● durch Generierung von Hilfsklassen ● EMF → Erzeugung von Java-Code für das Metamodell - Java-Klassen, die Metamodellelemente repräsentieren - Factories, Switch-Klassen ● durch Interpretation von Generator-Templates ● Metamodell-Mappings ● Constraint-Definitionen (in Constraint-Sprachen) ● 06.4 – Modellgetriebene Softwareentwicklung 32 MDSD mit Metawerkzeugen domain engineering Domänenarchitekt Metamodell Metamodell Metamodell Metamodell Metawerkzeuge Generator/ Interpreter Werkzeuge Werkzeuge Werkzeuge mit mit Hilfe Hilfe generierter generierter Modellzugriffsklassen Modellzugriffsklassen selbst selbst entwickeln entwickeln Repräsentation Checker Modell Modell Modell Modell Keine (eigene) konkrete Syntax. Keine (eigene) application engineeringkonkrete Syntax. Das Das Metawerkzeug Metawerkzeug stellt stellt evtl. evtl. eine eine Standardsyntax Standardsyntax zur zur Verfügung. Verfügung. M2T M2M Quellcode Generat Anwendungsentwickler 06.4 – Modellgetriebene Softwareentwicklung 33 MDSD mit Metawerkzeugen domain engineering Domänenarchitekt Metamodell Metamodell Metamodell Metamodell Metawerkzeuge Generator/ Interpreter Werkzeuge Repräsentation Checker Modell Modell Modell Modell M2T M2M application engineering Quellcode Generat public public EReference EReference getStatemachine_States() getStatemachine_States() {{ return return (EReference)statemachineEClass.getEStructuralFeatures().get(2); (EReference)statemachineEClass.getEStructuralFeatures().get(2); Anwendungsentwickler }} // // …… // // public public EList<Transition> EList<Transition> getTransitions() getTransitions() {{ if (transitions == null) if (transitions == null) {{ 06.4 – Modellgetriebene Softwareentwicklung transitions transitions == new new EObjectContainmentEList<Transition>(Transition.class, EObjectContainmentEList<Transition>(Transition.class, this, this, FowlerdslPackage.STATE__TRANSITIONS); FowlerdslPackage.STATE__TRANSITIONS); 34 MDSD mit Metawerkzeugen domain engineering Domänenarchitekt konkrete Syntax Abbildung Metamodell Metamodell Metamodell Metamodell Zur Zur Generierung Generierung eines eines Parsers Parsers ist ist evtl. evtl. eine eine Abbildung Abbildung der der konkreten konkreten Syntax Syntax auf auf das das Metamodell Metamodell nötig nötig Metawerkzeuge Generator/ Interpreter Werkzeuge Generator/ Interpreter Repräsentation Checker Parser Modell Modell Modell Modell M2T M2M application engineering ModellBeschreibung Quellcode Generat Anwendungsentwickler 06.4 – Modellgetriebene Softwareentwicklung 35 Variante: Variante: aus aus konkreter konkreter Syntax Syntax werden werden Metamodell Metamodell und und Editor Editor domain engineering generiert generiert (xText) (xText) MDSD mit Metawerkzeugen konkrete Syntax Abbildung Domänenarchitekt Metamodell Metamodell Metamodell Metamodell Metawerkzeuge Generator/ Interpreter Werkzeuge Generator/ Interpreter Repräsentation Checker Editor Modell Modell Modell Modell M2T M2M application engineering ModellBeschreibung Quellcode Generat Anwendungsentwickler 06.4 – Modellgetriebene Softwareentwicklung 36 MDSD mit Metawerkzeugen domain engineering Domänenarchitekt konkrete Syntax Abbildung Metamodell Metamodell Metamodell Metamodell Metawerkzeuge Generator/ Interpreter Werkzeuge Generator/ Interpreter Repräsentation Checker Editor Modell Modell Modell Modell M2T M2M application engineering ModellBeschreibung Quellcode Generat Anwendungsentwickler 06.4 – Modellgetriebene Softwareentwicklung 37 Restliche Restliche Metawerkzeuge Metawerkzeuge werden werden MDSD mit Metawerkzeugen anhand anhand entsprechender entsprechender Beschreibungen Beschreibungen ebenfalls ebenfalls generiert generiert domain engineering Domänenarchitekt konkrete Syntax Abbildung Metamodell ModellConstraints M2M-Abbildung GenerierungsTemplate Generator/ Interpreter Generator/ Interpreter Generator/ Interpreter Metamodell Metamodell Metamodell Metawerkzeuge Generator/ Interpreter Werkzeuge Generator/ Interpreter Repräsentation Checker Parser Modell Modell Modell Modell M2T M2M application engineering ModellBeschreibung Quellcode Generat Anwendungsentwickler 06.4 – Modellgetriebene Softwareentwicklung 38 MDSD mit Metawerkzeugen: Beispiel mit xtext domain engineering Domänenarchitekt konkrete Syntax Abbildung Metamodell GenerierungsTemplate Generator/ Interpreter Generator/ Interpreter Generator/ Interpreter Metawerkzeuge Werkzeuge Repräsentation Editor Modell M2T application engineering ModellBeschreibung Quellcode Generat Anwendungsentwickler 06.4 – Modellgetriebene Softwareentwicklung 39 MDSD mit Metawerkzeugen: Beispiel mit xtext domain engineering Domänenarchitekt konkrete Syntax Abbildung Metamodell GenerierungsTemplate Generator/ Interpreter Generator/ Interpreter Generator/ Interpreter Metawerkzeuge Werkzeuge Repräsentation Editor Modell M2T application engineering ModellBeschreibung Quellcode Generat Anwendungsentwickler 06.4 – Modellgetriebene Softwareentwicklung 40 (Quasi-)Standards XML MDA EMF (+oAW) Metameta XSD MOF Ecore, oAW classic, MOF, XSD,(erweiterbar) statische Sem. M2M Schematron OCL Check XSLT QVT xTend, Ecore → Ecore Ecore → XML M2T XSLT QVT, Mof2Text xPand, JET Achtung: weder vollständig noch vollständig ernst zu nehmen - XML ist eigentlich kein „Werkzeug“ und wird z.B. von anderen Werkzeugen als Speicher- oder Austauschformat (XMI!) benutzt. 06.4 – Modellgetriebene Softwareentwicklung 41 Generierung vs. Interpretation ● ● Anstatt Code aus Modellen zu generieren, kann man diese auch interpretieren Vorteile Modell kann im laufenden Betrieb ausgetauscht werden ● „Code“ ist i.A. kleiner ● ● Nachteil: Interpreter/VM nötig ● ● ● Performance, Leistungsaufnahme eher geeignet für fachliche Modelle als strukturelle Modelle Zwischenvarianten ● Transformation des Modells in Bytecode (Generierung+Interpretation) ● JIT-Kompilation 06.4 – Modellgetriebene Softwareentwicklung 42 MDSD & Ubiquitäre Systeme ● Plattformen für ubiquitäre Systeme: verschieden(st)e ● Interaktionsmöglichkeiten - Anzeige - Eingabegeräte ● ● ● Software: Plattformen (JavaME, WindowsCE, Android, ...) Umgang mit Kontext: verschiedene ● Kontextontologien ● Kontextrepräsentationen ● → Anwendungsentwickler soll sich nicht um Details kümmern MDSD to the rescue: Modellierung ● abstrakter Benutzerschnittstellen ● von Kontext und Kontextadaption 06.4 – Modellgetriebene Softwareentwicklung 43 Modellierung von Kontext ● Es existieren verschiedene, meist auf der MOF basierende, Modellierungssprachen für Kontext ● Allgemeine Metamodelle für Ontologien: OWL (+RDF) ● Kontextontologien enthalten wissen über eine Kontextdomäne[3]: ● ● Objekte/Subjekte (Entitys) und deren ● Attribute ● Funktionen (Operationen, Dienste) ● Beziehungen zwischen Entitys konkretes Beispiel: ContextUML – Context-Awareness für Webservices 06.4 – Modellgetriebene Softwareentwicklung 44 ContextUML[4] Context Modeling AtomicContext Service CompositeContext MechanismAssignment 1 * 1..* Operation part Part CAMechanism CAObject input output 0..1 0..1 Message 1..* * * ContextBinding Context 1..* ContextConstraint ContextSource 1..* * ContextTriggering * 0..* SourceAssignment * 1..* ContextService * ContextService Community * 1..* member * Action Context-Awareness Modeling Quelle: [5] 06.4 – Modellgetriebene Softwareentwicklung 45 ContextUML[4] Context Modeling AtomicContext Service CompositeContext MechanismAssignment 1 * 1..* Operation part Part CAMechanism CAObject input output 0..1 0..1 Message 1..* Context * * ContextBinding 1..* 1..* ContextBinding: ContextBinding: ContextConstraint Verknüpft Verknüpft ein ein CAObject CAObject (ContextAwareObject) (ContextAwareObject) mit mit einem einem Context Context Context-Awareness Modeling ContextSource * ContextTriggering * 0..* SourceAssignment * 1..* ContextService * ContextService Community * 1..* member * Action Quelle: [5] 06.4 – Modellgetriebene Softwareentwicklung 46 ContextUML[4] Context Modeling AtomicContext Service CompositeContext MechanismAssignment 1 * 1..* Operation part Part CAMechanism CAObject input output 0..1 0..1 Message 1..* Context * * 1..* ContextConstraint ContextSource 1..* * ContextBinding ContextTriggering * 0..* SourceAssignment * 1..* ContextService * ContextService Community * 1..* member * Action ContextTriggering: ContextTriggering: Legt Legt fest, fest, welche welche Action Action ausgeführt ausgeführt Context-Awareness Modeling werden werden soll, soll, wenn wenn eine eine bestimmte bestimmte Bedingung Bedingung (ContextConstraint) (ContextConstraint) erfüllt erfüllt ist. ist. 06.4 – Modellgetriebene Softwareentwicklung Quelle: [5] 47 ● Beispiel für eine Applikation, die abhängig vom Wetter ContextUML[4] Informationen zu Sehenswürdigkeiten liefert: Context Modeling WeatherTrigger AtomicContext Service MechanismAssignment 1 harshWeather=true 1..* input output 0..1 0..1 part Part 1..* * * * 1..* ContextConstraint SourceAssignment * Context ContextSource 1..* * ContextBinding ContextTriggering * 0..* CompositeContext FilterOutdoorActivities Action ContextConstraint CAMechanism CAObject Operation Message Context triggering 1..* ContextService * ContextService Community * 1..* member * Action ContextTriggering: ContextTriggering: Legt Legt fest, fest, welche welche Action Action ausgeführt ausgeführt Context-Awareness Modeling werden werden soll, soll, wenn wenn eine eine bestimmte bestimmte Bedingung Bedingung (ContextConstraint) (ContextConstraint) erfüllt erfüllt ist. ist. 06.4 – Modellgetriebene Softwareentwicklung Quelle: [5] 48 ContextUML: Beispiel 06.4 – Modellgetriebene Softwareentwicklung 49 Zusammenfassung 06.4 – Modellgetriebene Softwareentwicklung 50 Fazit ● aufwändig ● Domänenanalyse ● Referenzimplementierung ● Domänenarchitektur - Metamodelle - Transformationen ● lohnt sich das? 06.4 – Modellgetriebene Softwareentwicklung 51 Fazit ● ● ● MDSD kann die Anwendungsentwicklung beschleunigen ● Entkopplung verschiedener Abstraktionsebenen ● Wiederverwendung von Generatoren, insb. bei Produktlinien ● generierter Plattformcode, insb. bei Verwendung von Cartridges MDSD hilft, Fehler zu vermeiden ● Modell bietet weniger Möglichkeiten als handgeschriebener Code ● Fehler im Generator fallen recht schnell auf MDSD bietet somit Lösungen für die speziellen Probleme ubiquitärer Systeme ● Heterogenität (v.a. der Benutzerschnittstellen) ● Umgang mit Kontext 06.4 – Modellgetriebene Softwareentwicklung 52 Zusammenfassung ● Begriffe ● ● Techniken/Werkzeuge ● ● ((Meta-)Meta-)Modell, Softwareplattform, (abstrakte/konkrete) Syntax, architekturzentrierte/fachliche MDSD, Transformation, DSL, statische/dynamische Semantik, Abstraktionsebenen, MDA, PIM, PSM interne DSLs, M2M, M2T – Generierung, Interpretation, Metawerkzeuge, Constraint-Sprachen, Transformationssprachen, Modellierung von Kontext und Kontextadaption Warum? ● (Software-)plattformunabhängigkeit, DRY, Fehlervermeidung, Flexibilität, Entwicklungsgeschwindigkeit, Produktlinien, Trennung von Domänen-&Plattformwissen 06.4 – Modellgetriebene Softwareentwicklung 53 Literatur [1] [2] [3] [4] [5] T. Stahl, M. Völter, S. Efftinge, A. Haase, Modellgetriebene Softwareentwicklung – Techniken, Engineering, Management, dpunkt.verlag, 2. Auflage, 2007 S. J. Mellor, K. Scott, A. Uhl, D. Weise, MDA Distilled: Principles of Model-Driven Architecture, Addison Wesley, März 2004 N. Georgalas, S. Ou, M. Azmoodeh, K. Yang, Towards a Model-Driven Approach for Ontology-Based Context-Aware Application Development: A Case Study. International Workshop on Model-Based Methodologies for Pervasive and Embedded Software (MOMPES 2007), März 2007. Q. Z. Sheng, B. Benatallah, ContextUML: A UML-Based Modeling Language for Model-Driven Development of ContextAware Web Services Development, International Conference on Mobile Business (ICMB 2005), Juli 2005 www.cs.adelaide.edu.au/~qsheng/presentations/ICMB05Sheng.ppt 06.4 – Modellgetriebene Softwareentwicklung 54 Transformation ● von UML-Profilen «DEFINE «DEFINE Root Root FOR FOR uml::Model» uml::Model» «EXPAND «EXPAND PackageRoot PackageRoot FOREACH FOREACH allOwnedElements().typeSelect(uml::Package)» allOwnedElements().typeSelect(uml::Package)» «ENDDEFINE» Iteration «ENDDEFINE» Iteration über über Unterelemente Unterelemente «DEFINE «DEFINE PackageRoot PackageRoot «EXPAND «EXPAND ClassRoot ClassRoot «ENDDEFINE» «ENDDEFINE» FOR FOR uml::Package» uml::Package» FOREACH FOREACH ownedType.typeSelect(uml::Class)» ownedType.typeSelect(uml::Class)» «DEFINE «DEFINE ClassRoot ClassRoot FOR FOR uml::Class» uml::Class» «FILE «FILE name+".java"» name+".java"» public public class class «name» «name» {} {} Polymorphes Polymorphes Matching Matching auf auf Metamodell-Elemente Metamodell-Elemente «ENDFILE» «ENDFILE» «ENDDEFINE» «ENDDEFINE» «DEFINE «DEFINE ClassRoot ClassRoot FOR FOR test::test» test::test» «FILE «FILE name+".java"» name+".java"» public public class class «name» «name» {{ public public void void hallo hallo {{ System.out.println(“ich System.out.println(“ich bin bin «name»”); «name»”); }} }} // // stereotyped stereotyped «ENDFILE» «ENDFILE» «ENDDEFINE» 06.4 – Modellgetriebene Softwareentwicklung «ENDDEFINE» 55 Hinz.java: Hinz.java: public public class class Hinz Hinz {} {} Transformation ● Beispiel für M2T: oAW Kunz.java: Kunz.java: «DEFINE FOR uml::Model» «DEFINE Root FORKunz uml::Model» public class {} publicRoot class Kunz {} xPand «EXPAND «EXPAND PackageRoot PackageRoot FOREACH FOREACH allOwnedElements().typeSelect(uml::Package)» allOwnedElements().typeSelect(uml::Package)» «ENDDEFINE» Iteration «ENDDEFINE» Iteration über über Unterelemente Unterelemente Foo.java: Foo.java: public class \\ uml::Package» publicPackageRoot class Foo Foo FOR «DEFINE «DEFINE PackageRoot FOR uml::Package» {{«EXPAND «EXPAND ClassRoot ClassRoot FOREACH FOREACH ownedType.typeSelect(uml::Class)» ownedType.typeSelect(uml::Class)» public «ENDDEFINE» public void void hallo() hallo() {{ «ENDDEFINE» System.out.println(“ich System.out.println(“ich bin bin Foo”); Foo”); «DEFINE «DEFINE ClassRoot FOR FOR uml::Class» uml::Class» }} ClassRoot «FILE name+".java"» name+".java"» }}«FILE public public class class «name» «name» {} {} Polymorphes Polymorphes Matching Matching auf auf Metamodell-Elemente Metamodell-Elemente «ENDFILE» «ENDFILE» Bar.java: Bar.java: «ENDDEFINE» «ENDDEFINE» public public class class Bar Bar \\ {{ «DEFINE ClassRoot «DEFINE ClassRoot FOR FOR test::test» test::test» public void «FILE name+".java"» public void hallo() hallo() {{ «FILE name+".java"» public class bin public System.out.println(“ich class «name» «name» {{ System.out.println(“ich bin Bar”); Bar”); public public void void hallo hallo {{ System.out.println(“ich System.out.println(“ich bin bin «name»”); «name»”); }} } } // stereotyped stereotyped }} }} // «ENDFILE» «ENDFILE» «ENDDEFINE» «ENDDEFINE» 06.4 – Modellgetriebene Softwareentwicklung 56
