SuS-06.4: Modellgetriebene Softwareentwicklung

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/SS2012/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
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
22
#include
#include "gws.h"
"gws.h"
Beispiel mit Yakindu
void
void show(struct
show(struct Gws_Handle
Gws_Handle *sm)
*sm)
{{
int
int reset
reset == gws_getVar_reset(sm),
gws_getVar_reset(sm), park_led
park_led == gws_getVar_park_led(sm),
gws_getVar_park_led(sm), drive_led
drive_led == gws_getVar_drive_led(sm);
gws_getVar_drive_led(sm);
printf("%d
%d
%d\n",
reset,
park_led,
drive_led);
printf("%d %d %d\n", reset, park_led, drive_led);
}}
Modellierung der Funktionalität eines Gangwahlschalters
(aus dem Bachelor-Fachprojekt „Software im Automobil“)
int
int main(void)
main(void)
{{
struct
struct Gws_Handle
Gws_Handle sMachine;
sMachine;
gws_init(&sMachine);
gws_init(&sMachine);


Hebelstellung
Knopf gedrückt (Sport-, Park-, Schalt-)
show(&sMachine);
show(&sMachine);
gws_runCycle(&sMachine);
gws_runCycle(&sMachine);
show(&sMachine);
show(&sMachine);
gws_raiseTrigger_p_but_press(&sMachine);
gws_raiseTrigger_p_but_press(&sMachine);
gws_runCycle(&sMachine);
gws_runCycle(&sMachine);
show(&sMachine);
show(&sMachine);
gws_runCycle(&sMachine);
gws_runCycle(&sMachine);
show(&sMachine);
show(&sMachine);
}}
return
return 0;
0;
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
23
„echte“ MDSD
06.4 – Modellgetriebene Softwareentwicklung
24
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
25
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
26
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
27
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
28
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
29
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
30
(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
31
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
32
Metaebenen bei EMF
Modell
Modell
Metametamodell
Metametamodell
Metamodell
Metamodell
06.4 – Modellgetriebene Softwareentwicklung
33
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
34
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
35
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);
36
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
37
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
38
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
39
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
40
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
41
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
42
(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
43
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
44
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
45
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
46
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
47
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
48
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]
49
●
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]
50
ContextUML: Beispiel
06.4 – Modellgetriebene Softwareentwicklung
51
Zusammenfassung
06.4 – Modellgetriebene Softwareentwicklung
52
Fazit
●
aufwändig
●
Domänenanalyse
●
Referenzimplementierung
●
Domänenarchitektur
- Metamodelle
- Transformationen
●
lohnt sich das?
06.4 – Modellgetriebene Softwareentwicklung
53
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
54
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
55
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
56
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»
57
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
58