Domain Specific Languages. Product Line Engineering

Size: px

Start display at page:

Download "Domain Specific Languages. Product Line Engineering"

Abner Barnett
6 years ago
Views:

1 Using Domain Specific Languages in the context of Product Line Engineering Markus Voelter Independent/itemis Using Domain Specific Languages in the context of Product Line Engineering DSLs PLE Concepts & DSLs Customization and Configuration Modular Languages Markus Voelter Independent/itemis 1

2 DSLs 2

3 programming started close to the hardware abstractions computing chips abstractions computing bits 3

4 abstractions computing C abstractions computing? Java 4

5 abstractions computing? SQL 5

6 ? 6

7 general purpose 7

8 domain specific tailor made effective++ specialized, limited used by experts together with other specialized tools 8

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. 9

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. 10

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. 11

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. 12

13 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

14 execute? 14

15 map DSL Program (aka Model) map automated! GPL Program 15

16 map Generation Transformation Compilation Interpretation 16

17 Activities Analysing Domains Defining Languages Adapting/Selecting Building Editors Transforming Models Building Generators Building Frameworks 17

18 Activities Analysing Domains Defining Languages Adapting/Selecting Building Editors Transforming Models Building Generators Building Frameworks and using all of that to build apps 18

19 Embedded Protocol Handler DSLs Some Examples tests refines 19

20 OSGI-based Enterprise System Insurance Contracts

21 Insurance Contracts Insurance Contracts

22 Alarm System Menus Alarm System Menus

23 Hearing Aids Refrigerators A DSL for Hearing Aid Configuration A DSL for Refridgerator Configuration 23

24 BPEL Designer Block Diagrams

25 PLC Programming State Charts

26 PLE Concepts & DSLs 26

27 domain engineering domain analysis classifying variability defining DSLs application eng. using the DSL to express systems 27

28 platform target environment abstractions of solution space can influence DSL concepts (Arch DSLs) config knowledge transformations generators interpreters 28

29 core asset languages generators editors variation point bind how kind of varibility bind when 29

30 PLE Concepts & DSLs Bind How Kinds of Variability Bind When 30

31 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

32 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

Challenge: types for parameters can be non trivial

33 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

34 PLE Concepts & DSLs Bind How Kinds of Variability Bind When 34

35 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

36 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

37 Customization DSLs instantiation connections 37

38 DEMO I Example DSL Fountains 38

39 PLE Concepts & DSLs Bind How Kinds of Variability Bind When 39

40 Interpretation vs. Generation Binding Time Generation resulting code can be easily inspected 40

41 Interpretation vs. Generation Interpretation vs. Generation Generation resulting code can be easily debugged Generation resulting code can be optimized and more efficient 41

42 Interpretation vs. Generation Interpretation vs. Generation Generation Templates can be derived from existing code Generation limitations work around of target language 42

43 Interpretation vs. Generation Interpretation vs. Generation Generation no changes to target environment (leaves no trace) Generation reuse runtime infrastructure (garbage collection, monitoring ) 43

44 Interpretation vs. Generation Interpretation vs. Generation Interpretation faster turnaround no regeneration test build deploy Interpretation for platform indepenence an interpreter might be less porting effort 44

45 Interpretation vs. Generation Interpretation possibly direct feedback from in-ide interpreter 45

46 DEMO II In-IDE Interpreter in Fountains 46

47 Customization and Configuration Customization and Configuration In-Language Varying models DSLs as Parameters 47

48 In language In language 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

49 In language Conditionals #ifdef Specialization inheritance Leaving Holes template methods Inject Stuff AOP 49

50 DEMO III A DSL with variant blocks 50

51 Customization and Configuration In-Language Varying models DSLs as Parameters Two Levels problem space vs. software space Problem Space: Configuration Solution Space: Customization 51

52 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

.n <<dependentob>> Phone number: int regioncode: int countrycode: int address 1 address 0.

53 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

54 Two Levels Removal Two Levels Removal 54

55 Two Levels Injection Two Levels Injection aspect (*) compnent { provides mon: IMonitoring } 55

56 Two Levels Removal Injection + Two Levels varying models, not text fewer var points semantically meaningful more manageable 56

57 Two Levels varying models, not text simplifies traceability you can point easily to any element -> generic traceability approach simplifies traceability 57

58 DEMO IV Feature Annotations 58

59 Customization and Configuration In-Language Varying models DSLs as Parameters 59

60 Feature Model w/ Paramters parameters with simple types complex types: DSL/metamodel 60

61 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

62 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

63 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

64 Modular Languages 64

65 We don t want to model, we want to program! 65

66 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

67 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

68 Big Language? o a b n c m k L d e j f i g h with many first class concepts! 68

69 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

70 Viewpoints 70

71 Viewpoints suitable abstractions and notations for each Viewpoints Integrated via symbolic references and seamless transitions 71

72 Viewpoints General Purpose predefined library configure Viewpoints Domain Specific custom purpose-built create/include 72

73 Custom Notations Viewpoints Domain Specific real business expert integration C General Purpose Viewpoints Domain Specific LEGO Robot Control 73

74 Viewpoints C General Purpose Components State Machines Sensor Access Domain Specific LEGO Robot Control 74

75 Language Integration by Referencing Language Integration by Cascading 75

76 Language Integration by Extension Language Integration by Embedding 76

77 Language Integration by Contributing 77

78 DEMO IV A Modular Language 78

79 THE END..coordinates web skype twitter schogglad markusvoelter xing linkedin THE END..coordinates web skype twitter schogglad markusvoelter xing linkedin

THE END..coordinates web email skype twitter www.voelter.de voelter@acm.

linkedin.com/pub/0/377/a31 linkedin.com/pub/0/377/a31 80

80 THE END..coordinates web skype twitter schogglad markusvoelter xing linkedin THE END..coordinates web skype twitter schogglad markusvoelter xing linkedin

81 THE END..coordinates web skype twitter schogglad markusvoelter xing linkedin

A little History Domain Specific Languages Examples Tools Benefits A more theoretical View Programming and Modeling The LWES Project Bonus: Best

Domain Specific Languages Markus Voelter Independent/itemis voelter@acm.org A little History Domain Specific Languages Examples Tools Benefits A more theoretical View Programming and Modeling The LWES