Using Domain Specific Languages in the context of Product Line Engineering Markus Voelter Independent/itemis voelter@acm.org Using Domain Specific Languages in the context of Product Line Engineering DSLs PLE Concepts & DSLs Customization and Configuration Modular Languages Markus Voelter Independent/itemis voelter@acm.org 1
DSLs 2
programming started close to the hardware abstractions computing chips abstractions computing bits 3
abstractions computing C abstractions computing? Java 4
abstractions computing? SQL 5
? 6
general purpose 7
domain specific tailor made effective++ specialized, limited used by experts together with other specialized tools 8
DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. 9
DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. 10
DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. 11
DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. 12
DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. DSL A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern. 13
execute? 14
map DSL Program (aka Model) map automated! GPL Program 15
map Generation Transformation Compilation Interpretation 16
Activities Analysing Domains Defining Languages Adapting/Selecting Building Editors Transforming Models Building Generators Building Frameworks 17
Activities Analysing Domains Defining Languages Adapting/Selecting Building Editors Transforming Models Building Generators Building Frameworks and using all of that to build apps 18
Embedded Protocol Handler 31.01.2011 DSLs Some Examples tests refines 19
OSGI-based Enterprise System Insurance Contracts 31.01.2011 20
Insurance Contracts Insurance Contracts 31.01.2011 21
Alarm System Menus Alarm System Menus 31.01.2011 22
Hearing Aids Refrigerators 31.01.2011 A DSL for Hearing Aid Configuration A DSL for Refridgerator Configuration 23
BPEL Designer Block Diagrams 31.01.2011 24
PLC Programming State Charts 31.01.2011 25
PLE Concepts & DSLs 26
domain engineering domain analysis classifying variability defining DSLs application eng. using the DSL to express systems 27
platform target environment abstractions of solution space can influence DSL concepts (Arch DSLs) config knowledge transformations generators interpreters 28
core asset languages generators editors variation point bind how kind of varibility bind when 29
PLE Concepts & DSLs Bind How Kinds of Variability Bind When 30
Variability Mechanisms Removal optionally take away from overall whole Variability Mechanisms Removal optionally take away from overall whole Challenge: overall whole can get big and unwieldy 31
Variability Mechanisms Injection optionally add to minimal core Variability Mechanisms Injection optionally add to minimal core Challenge: how to point into the core and add something to it 32
Variability Mechanisms Parametrization define values for predefined params Variability Mechanisms Parametrization define values for predefined params Challenge: types for parameters can be non trivial (DSLs) 33
PLE Concepts & DSLs Bind How Kinds of Variability Bind When 34
Configuration vs. Customization Variability Guidance, Efficiency Complexity, Flexibility Routine Configuration Creative Construction Configuration Parameters Property Files Feature-Model Based Configuration Graph-Like Languages Framworks Manual Programming Wizards Tabular Configurations Configuration selecting options setting param values 35
Configuration selecting options setting param values Configuration Feature Models Size Stack Counter Fixed Dynamic Optimization value ElementType [open] Speed Memory Usage Additional Features int float String Thread Safety Bounds Check Type Check 36
Customization DSLs instantiation connections 37
DEMO I Example DSL Fountains 38
PLE Concepts & DSLs Bind How Kinds of Variability Bind When 39
Interpretation vs. Generation 31.01.2011 Binding Time Generation resulting code can be easily inspected 40
Interpretation vs. Generation Interpretation vs. Generation 31.01.2011 Generation resulting code can be easily debugged Generation resulting code can be optimized and more efficient 41
Interpretation vs. Generation Interpretation vs. Generation 31.01.2011 Generation Templates can be derived from existing code Generation limitations work around of target language 42
Interpretation vs. Generation Interpretation vs. Generation 31.01.2011 Generation no changes to target environment (leaves no trace) Generation reuse runtime infrastructure (garbage collection, monitoring ) 43
Interpretation vs. Generation Interpretation vs. Generation 31.01.2011 Interpretation faster turnaround no regeneration test build deploy Interpretation for platform indepenence an interpreter might be less porting effort 44
Interpretation vs. Generation 31.01.2011 Interpretation possibly direct feedback from in-ide interpreter 45
DEMO II In-IDE Interpreter in Fountains 46
Customization and Configuration Customization and Configuration In-Language Varying models DSLs as Parameters 47
In language In language 31.01.2011 The language provides explicit support! (we can learn that from GPLs) Conditionals conditional execution Specialization overriding, overwriting Leaving Holes for variant to fill in Inject Stuff several places at a time? 48
In language 31.01.2011 Conditionals #ifdef Specialization inheritance Leaving Holes template methods Inject Stuff AOP 49
DEMO III A DSL with variant blocks 50
Customization and Configuration In-Language Varying models DSLs as Parameters Two Levels problem space vs. software space Problem Space: Configuration Solution Space: Customization 51
Two Levels problem space vs. software space Two Levels Removal #if defined (ACE_HAS_TLI) static ssize_t t_snd_n ( ACE_HANDLE handle, const void *buf, size_t len, int flags, ACE_Time_Value *timeout = 0, size_t *bytes_transferred = 0); #endif /* ACE_HAS_TLI */ 52
Two Levels Removal Phone Party NeedsState Multiple Addresses International Phone LocalPhone Persistence XML Hibernate JDO not <<entity>> Party name: String 0..n <<dependentob>> Phone number: int regioncode: int countrycode: int address 1 address 0..n <<dependentob>> Address city: String state: String zip: String street: String Two Levels Removal System Failover Monitoring Data Management Graceful Degradation Redundancy Centralized Distributed 53
Two Levels Removal Two Levels Removal 54
Two Levels Injection Two Levels Injection aspect (*) compnent { provides mon: IMonitoring } 55
Two Levels Removal Injection + Two Levels varying models, not text fewer var points semantically meaningful more manageable 56
Two Levels varying models, not text simplifies traceability you can point easily to any element -> generic traceability approach simplifies traceability 57
DEMO IV Feature Annotations 58
Customization and Configuration In-Language Varying models DSLs as Parameters 59
Feature Model w/ Paramters parameters with simple types complex types: DSL/metamodel 60
Customization and Configuration Trafo Variability Model-Based Implementation 61
Model-Based Implementation Problem Space Software Space Domain Engineering Domain Requirements Formal Domain MetaModel M Formal Solution Space MetaModel Core Assets Application Engineering Product Requirements Formal Domain Model M Formal Solution Space Model... Product Transformation Variability create System transformps2cbd( Building building ): hasfeature("burglaralarm")? ( handleburglaralarm() -> this) : this; handleburglaralarm( System this ): let conf = createburglarconfig(): ( configurations.add( conf ) -> conf.connectors.add( connectsimtopanel( createsimulatorinstance(), createcontrolpanelinstance() ) ) -> hasfeature( "siren" )? conf.addalarmdevice("alarmsiren") : null -> hasfeature( "bell" )? conf.addalarmdevice("alarmbell") : null -> hasfeature( "light" )? conf.addalarmdevice("alarmlight") : null ); 62
Transformation Variability transformation transformation aspect around... workflow transform configuration model Generator Variability template file template aspect workflow AROUND generate (osgi) configuration model generate (cbd) transformaspect generatoraspect generatoraspect template file template aspect AROUND x()... extend file extend aspect x():... around... 63
Modular Languages 64
We don t want to model, we want to program! 65
We don t want to model, we want to program! at different levels of abstaction from different viewpoints integrated! We don t want to model, we want to program! with different degrees of domain-specificity with suitable notations with suitable expressiveness 66
We don t want to model, we want to program! And always: precise and tool processable We don t want to model, we want to program! PLE for DSLs suitable to related domains 67
Big Language? o a b n c m k L d e j f i g h with many first class concepts! 68
Small Language? L with a few, orthogonal and poweful concepts Modular Language a b c my L d e f g h i j k l with many optional, composable concepts 69
Viewpoints 70
Viewpoints suitable abstractions and notations for each Viewpoints Integrated via symbolic references and seamless transitions 71
Viewpoints General Purpose predefined library configure Viewpoints Domain Specific custom purpose-built create/include 72
Custom Notations Viewpoints Domain Specific real business expert integration C General Purpose Viewpoints Domain Specific LEGO Robot Control 73
Viewpoints C General Purpose Components State Machines Sensor Access Domain Specific LEGO Robot Control 74
Language Integration by Referencing Language Integration by Cascading 75
Language Integration by Extension Language Integration by Embedding 76
Language Integration by Contributing 77
DEMO IV A Modular Language 78
THE END..coordinates web email skype twitter www.voelter.de voelter@acm.org schogglad markusvoelter xing linkedin http://www.xing.com/profile/markus_voelter http://www.linkedin.com/pub/0/377/a31 THE END..coordinates web email skype twitter www.voelter.de voelter@acm.org schogglad markusvoelter xing linkedin http://www.xing.com/profile/markus_voelter http://www.linkedin.com/pub/0/377/a31 79
THE END..coordinates web email skype twitter www.voelter.de voelter@acm.org schogglad markusvoelter xing linkedin http://www.xing.com/profile/markus_voelter http://www.linkedin.com/pub/0/377/a31 THE END..coordinates web email skype twitter www.voelter.de voelter@acm.org schogglad markusvoelter xing linkedin http://www.xing.com/profile/markus_voelter http://www.linkedin.com/pub/0/377/a31 80
THE END..coordinates web email skype twitter www.voelter.de voelter@acm.org schogglad markusvoelter xing linkedin http://www.xing.com/profile/markus_voelter http://www.linkedin.com/pub/0/377/a31 81