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/SS2010/SuS/ 1 Agenda ● ● ● ● ● ● Motivation Begriffe Beispiele für Modellierungswerkzeuge Standards, Werkzeuge und Techniken MDSD & Ubiquitäre Systeme 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: Nokia Smartphone HW: Nokia Smartphone SW: J2ME, Java SW: J2ME, Java HW: iPAQ PDA HW: iPAQ PDA SW: Windows, C-Sharp SW: Windows, 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 … oder Eingabegeräten ● tastaturbasiert ● Touchscreen ● Clickwheel 06.4 – Modellgetriebene Softwareentwicklung 5 Problem ● (nicht nur bei GUI-Code) ● 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 → 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 (mittels Generator, auch „Modellcompiler“) - ● i.d.R Quellcode einer Hochsprache, aber auch 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 Beispiele für Modellierungswerkzeuge 06.4 – Modellgetriebene Softwareentwicklung 16 … 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 17 Automotive Softwareentwicklung ● Gründe für MDSD ● Einsparung von Kosten (Entwicklungsdauer) ● Sicherheitsanforderungen - weniger Fehler durch domänenspezifische Sprachen - generierte Software evtl. automatisch zertifiziert ● Beispiel: 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) 06.4 – Modellgetriebene Softwareentwicklung 18 Modelle in der Automobilindustrie Stateflow Simulink 06.4 – Modellgetriebene Softwareentwicklung 19 „echte“ MDSD: Standards, Werkzeuge und Techniken 06.4 – Modellgetriebene Softwareentwicklung 20 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 21 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 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 Werkzeuge für externe DSLs ● „echte“ MDSD-Werkzeuge können Metamodell-Beschreibungen ● Modellconstraints (über Constraint-Sprachen) ● Transformationsregeln (Mapping-Sprachen, Template-Sprachen) ● als Vorlage für Modelleditoren ● Modellparser ● Checker für statische Semantik ● Modelltransformatoren ● verarbeiten ● ● „Metawerkzeuge“ Vorraussetzung dafür ist natürlich, dass das Metamodell ebenfalls formal ist! 06.4 – Modellgetriebene Softwareentwicklung 24 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 25 Standards in der MDSD ● MDA – Model-Driven Architecture MDSD-Standard der OMG ● diverse Werkzeuge (u.A. oAW) ● Metametamodell: MOF ● ● EMF – Eclipse Modeling Framework Werkzeug & „Quasistandard“ ● Metametamodell: Ecore ● ● xPand ● ● früher openArchitectureWare (Generatorframework) XML Definition von Metamodellen über XML Schema Definitions ● oft Speicher-/Austauschformat für Modelle: ● - XML Metamodel Interchange (XMI) 06.4 – Modellgetriebene Softwareentwicklung 26 Model-Driven Architecture ● vordefinierte Metamodelle ● bekanntestes Beispiel: Klassendiagramme ● im Prinzip Metamodelle m.H. der MOF definierbar ● i.d.R. werden Profile verwendet - Erweiterungen der UML - Definition von Stereotypen ● 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 27 Metaebenen bei EMF Modell Modell Metametamodell Metametamodell Metamodell Metamodell 06.4 – Modellgetriebene Softwareentwicklung 28 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 29 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 30 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); 31 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 32 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 33 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 34 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 35 MDSD mit Metawerkzeugen 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 application engineering FSM FSM {{ ready->wash(start) ready->wash(start) wash->pause(opened) wash->pause(opened) Modellpause->wash(closed) pause->wash(closed) Beschreibung wash->ready(finished) wash->ready(finished) Anwendungsentwickler }} 06.4 – Modellgetriebene Softwareentwicklung M2T M2M Quellcode Generat 36 Modellierungswerkzeuge XML EMF MDA EMF (+oAW) (p::v) Metameta XSD Ecore MOF Ecore, oAW classic, MOF, XSD,(erweiterbar) FeatureMetamodell statische Sem. Schematron OCL Check Relations, Restrictions, Prolog M2M XSLT Mapping: Ecore → Ecore, XML QVT xTend M2T XSLT JET QVT, Mof2Text xPand StandardTransformat ion, XSLT, (eigene) 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. - pure::variants ist kein MDSD-Werkzeug 06.4 – Modellgetriebene Softwareentwicklung 37 Generierung vs. Interpretation ● ● Anstatt Code aus Modellen zu generieren, können diese natürlich auch interpretiert werden 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 Zwischenvariante: Umwandlung des Modells in Bytecode (Generierung+Interpretation) 06.4 – Modellgetriebene Softwareentwicklung 38 MDSD und ubiquitäre Systeme 06.4 – Modellgetriebene Softwareentwicklung 39 MDSD & Ubiquitäre Systeme ● Plattformen für ubiquitäre Systeme: verschieden(st)e ● Interaktionsmöglichkeiten - Anzeige - Eingabegeräte ● ● ● Software: Plattformen (JavaME, Windows, ...) Umgang mit Kontext: verschiedene ● Kontextontologien ● Kontextrepräsentationen ● → Anwendungsentwickler soll sich nicht um Details kümmern MDSD to the rescue: Modellierung ● abstrakter Benutzerschnittstellen ● von Kontext ● von Kontextadaption 06.4 – Modellgetriebene Softwareentwicklung 40 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 41 ContextUML[4] Context Modeling AtomicContext Service 1 CompositeContext MechanismAssignment * 1..* Operation input output 0..1 0..1 Message part Part SourceAssignment * CAMechanism CAObject 1..* * * ContextBinding 1..* ContextConstraint ContextSource 1..* * ContextTriggering * 0..* Context 1..* ContextService * ContextService Community * 1..* member * Action Context-Awareness Modeling Quelle: [5] 06.4 – Modellgetriebene Softwareentwicklung 42 ContextUML[4] Context Modeling AtomicContext Service 1 CompositeContext MechanismAssignment * 1..* Operation input output 0..1 0..1 Message part Part CAMechanism CAObject 1..* Context * * ContextBinding 1..* 1..* ContextBinding: ContextBinding: ContextConstraint Verknüpft Verknüpft ein ein CAObject CAObject (ContextAwareObject) (ContextAwareObject) mit mit einem einem Contextu Contextu ContextSource * ContextTriggering * 0..* SourceAssignment * 1..* ContextService * ContextService Community * 1..* member * Action Context-Awareness Modeling Quelle: [5] 06.4 – Modellgetriebene Softwareentwicklung 43 ContextUML[4] Context Modeling AtomicContext Service 1 CompositeContext MechanismAssignment * 1..* Operation input output 0..1 0..1 Message part Part SourceAssignment * CAMechanism CAObject 1..* Context * * 1..* * ContextBinding ContextTriggering * 0..* 1..* ContextConstraint Context-Awareness Modeling ContextSource 1..* ContextService * ContextService Community * 1..* member * Action ContextTriggering: ContextTriggering: Legt Legt fest, fest, welche welche Action Action ausgeführt ausgeführt 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] 44 ● Beispiel für eine Applikation, die abhängig vom Wetter ContextUML[4] Informationen zu Sehenswürdigkeiten liefert: Context Modeling WeatherTrigger AtomicContext Service 1 1..* Operation input output 0..1 0..1 Message part Part Context triggering MechanismAssignment harshWeather=true * * * 1..* ContextConstraint Context-Awareness Modeling SourceAssignment * Context ContextSource 1..* * ContextBinding ContextTriggering 0..* * FilterOutdoorActivities Action ContextConstraint CAMechanism CAObject 1..* CompositeContext 1..* ContextService * ContextService Community * 1..* member * Action ContextTriggering: ContextTriggering: Legt Legt fest, fest, welche welche Action Action ausgeführt ausgeführt 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] 45 ContextUML: Beispiel 06.4 – Modellgetriebene Softwareentwicklung 46 Zusammenfassung 06.4 – Modellgetriebene Softwareentwicklung 47 Bewertung ● Trotz umfangreicher Werkzeugunterstützung ist MDSD zunächst einmal mit zusätzlichem Aufwand verbunden ● Domänenanalyse ● Referenzimplementierung - enthält alles, was der Generator erzeugen können muss - dient als Vorlage für DSL und Generator - wird i.d.R. zunächst „von Hand“ (ohne Generator) erstellt ● Domänenarchitektur - Metamodelle - Transformationen ● lohnt sich das? 06.4 – Modellgetriebene Softwareentwicklung 48 Bewertung ● ● ● 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 49 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 50 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 51 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» 52 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 53
