Domain Specific Languages. Requirements (Engineering)

Transcription

1 Domain Specific Languages and Requirements (Engineering) Andreas Graf Markus Voelter

2

3 What are Requirements?

4 a requirement is a singular documented need of what a particular product or service should be or perform. Wikipedia

5 specifies a verifiable constraint on an implementation that it shall undeniably meet or (a) be deemed unacceptable, or (b) result in implementation failure, or (c) result in system failure. Wiktionary

6 what a system should do, and with which quality attributes, without presupposing a specific implementation. Mine.

7

8 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Wikipedia

9

10 Brain [Domain Person] Prose Brain [Developer] Code

11 Brain [Domain Person] Prose Brain [Developer] Code

12 Brain [Domain Person] Prose lossy lossy Brain [Developer] Code

13 Brain [Domain Person] Prose Brain [Developer] Code lossy lossy buggy

14 Brain [Domain Person]??? Code

15 Brain [Domain Person]??? Code

16

17 What vs. How

18 What vs. How The System shall be 99.9 % reliable Failover, Replication, RAID

19 Us vs. Them

20 Us vs. Them We specify the system the offshore folks implement it

21 Us vs. Them OEM specifies functions / interfaces the E/E vendor develops system

22 Domain vs. Software

23 Domain vs. Software Insurance contract rules the actual realization as JEE app

24 Domain vs. Software Communication protocol spec The protocol handler state machine

25

26

27 Us -> Them Domain -> Software What -> How

28 Us -> Them Domain -> Software What -> How Informal -> Formal

29 Informal -> Formal

30 Informal -> Formal

31 Informal -> Formal

32 Informal -> Formal

33 Informal -> Formal

34 Informal -> Formal

35 Formal vs. Informal

36

37 Formal Requirements & Design

38 ORMAL processable by tools

39 ORMAL Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous processable by tools Mandatory Verifiable

40 ORMAL Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous processable by tools Mandatory Verifiable implementation

41 Domain -> Software Informal -> Formal What -> How

42

43 Requirements & Design

44 Requirements & Design

45 Requirements & Design

46 Requirements & Design

47 Requirements & Design What -> How

48 Requirements & Design What -> How Informal -> Formal

49 Requirements & Design Informal -> Formal What -> How Domain -> Software

50

51 Formal requirements specify what a system should do from a domain perspective, and with which quality attributes, without presupposing a specific software implementation, but processable by tools. Mine++

52

53 Requirement/Informal: It shall not be possible to get radiated when operating a microwave.

54 Requirement/Informal: It shall not be possible to get radiated when operating a microwave. Design/Informal: The radiator may only work iff the door of the microwave is closed. + door isolation + some quality requirements

55 Requirement/Informal: It shall not be possible to get radiated when operating a microwave. Design/Formal:

56

57 Domain Specific Languages

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

59

60 general purpose

61 domain specific

62 tailor made effective++ specialized, limited used by experts together with other specialized tools

63

64 execute?

65 map

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

67 map Generation Transformation Compilation Interpretation

68

69 Example 1: Embedded Protocol Handler

70 CONTEXT Factory Control System Plug-in Cards Componentized System

71 PROBLEM Cards have to communicate via predefined protocol Protocol only specified as plain text and pictures Verification tough, no automatic processing

72 SOLUTION Define DSL for describing the protocol, formally define protocol with it Generate Handler Express test cases

73 SOLUTION Component Specification

74 SOLUTION Message Format Definition

75 SOLUTION Testing tests refines

76 BENEFITS Testing could be simplified and automated Handler could be generated Mistakes in Spec could be found automatically Second version could be done trivially

77 TOOLS Eclipse Modeling Eclipse Xtext

78

79

80 Example 3: Radar Systems Engineering

81 CONTEXT Radar Systems for satellites need to be designed Radar requirements influence sensor design influences satellite bus influences launch vehicle circular.

82 PROBLEM Requirements cannot simply be written down because tradeoffs studies need to be performed These need to be numerical.

83 SOLUTION Break system down into components Use approximate numerical fomulae to how requirements and design effect other components

84 SOLUTION Component Definition

85 SOLUTION Component Behavior Specification

86 SOLUTION Resulting System Behaviour

87 SOLUTION Analysis

88 BENEFITS Numerical approximate requirements/design tradeoffs can be performed

89 TOOLS Eclipse Modeling Eclipse Xtext Wolfram Mathematica Mathematica Workbench

90

91 Example 4: Alarm System Menus

92 CONTEXT Alarm Systems Operator Panels

93 PROBLEM The structure of the UI and menus of the operator panel was described in Word, and then manually implemented. Error prone, slow,

94 SOLUTION Use a DSL to describe menu structures directly, and generate various artifacts from it: - flash simulator data - C code for implementation - i18n templates

95 SOLUTION Menu Structure

96 SOLUTION Software Components

97 BENEFITS Various non-software artifacts could be generated Integration with software structure simpler Fewer errors, faster

98 TOOLS Eclipse Modeling Eclipse Xtext

99

100 Example 5: Requirements Tracability

101 CONTEXT Embedded Systems developed with a C-derivative

102 PROBLEM Tracability to textual requirements is necessary.

103 SOLUTION Import Requirements into the tool and then use traceability annotations to refer to them from any program element.

104 SOLUTION Imported Requirements

105 SOLUTION Program Code with Annotations (green)

106 SOLUTION Selecting from the Requirements Find Usages of Requirements

107 TOOLS JetBrains MPS

108

109 What if I don t yet have a language?

110 Actually, this is the normal case! Domain Specific Language

111

112 Building Languages

113 As you understand the domain

114 develop a language to express it!

115 Language resembles domain concepts

116 Then express the design with the language.

117 Clear understanding of the domain from building the language

118 Iterate! Understand Domain Define Language Use Language

119 Iterate! Understand Domain Domain Expert Language Engineer Define Language Language Engineer Use Language Domain Expert Domain User

120 Iterate! Understand Domain Domain Expert Language Engineer Define Language FORMAL! Use Language FORMAL!

121

122 Like Analysis!

123 Like Analysis! but with an executable result

124

125 DSL Engineering Tools

126 Notations

127 Notations Editors

128 Notations Editors Multi-Languages

129 Notations Editors Multi-Languages Debugger

130 Notations Editors Multi-Languages Debugger Testing

131 Notations Editors Multi-Languages Debugger Testing Groupware

132 Notations Editors Multi-Languages Debugger Testing Groupware Scalable

133 Notations Editors Multi-Languages Debugger Testing Groupware Scalable Integrated

134

135 Open Source Eclipse Public License

136 Large wold wide community

137 graphical, textual and form-based DSLs

138 Developed by JetBrains Open Source Apache 2.0

139 Projectional Editor all kinds of notations, mainly textual

140 Commercial Product Projectional Editor Most flexible notations

141

142 Notational Flexibility?

143 Textual Rich IDEs

144 Textual Rich IDEs

145 Textual Languages and Editors are easier to build

146 Textual Languages and Editors are easier to build Evolve Language and simple editor as you understand and discuss the architecture, in real time!

147 Textual Integrates easily with current infrastructure: CVS/SVN diff/merge

148 Textual adapting existing models as the DSL evolves Model evolution is trivial, you can always use grep.

149 Textual Many Developers prefer textual notations

150 When a graphical notation is better, you can visualize.

151 Mixed

152 Mixed

153 Multiple

154

155

156 Standards & UML

157 You can model everything with UML

158 You can model everything with UML somehow!

159 Problem Shoehorning domain abstractions into the generic language

160 Problem Sidetracked by existing abstractions and notations

161 Problem UML Theory Practice Notations/ Abstractions extensible via Profiles Very Limited Tool Support!

162 Problem Meta Model Complexity!

163 But! But don t reinvent the wheel either.

164 Where are standards useful?

165 People have to learn underlying concepts anyway.

166 Is UML with a profile still a standard language?

167 On which meta level do I want to standardize? M2 (UML), M3 (MOF)?

168 Isn t a DSL based on MOF as standard as a profile based on UML?

169

170 Similar statements can be made relative to BPMN

171

172 Textual Requirements?

173 Textual Requirements still necessary.

174

175

176

177

178 Tracing

179 Tracing

180

181 Things to keep in mind

182

183 Limit Expressiveness

184 Notation is important!

185 Graphical vs. Textual

186 Invest in good constraints

187 Testing may be an important benefit of your DSL

188 Simulations ( play around with the models)

189 Who are 1st Class Citizens?

190 Learn from - but don t copy programming languages

191 Support for Reuse and Variations

192 Tooling Matters!

193 Annotation Models to add technical details

194 Develop the language iteratively!

195 Co-Evolve Language and Concepts

196 Can domain users actually program?

197 Domain Users vs. Experts

198

199 Summary

200 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Wikipedia

201 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Validation Checking Simulation Wikipedia

202 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Everything is a model tracing links simple Wikipedia

203 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Described Formally Wikipedia

204 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Domain Expert involved in Definition and Review Wikipedia

205 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Executable Automatic Refinement downstream, Code Gen.

206 Cohesive Complete Consistent Atomic Traceable Current Feasible Unambiguous Mandatory Verifiable Executable Reward for the additional effort of formalization!

207 And Developers???

208 And Developers??? Languages Technology Evaulation Generators Testing Operations what they want to do anyway!

209

210 Brain [Domain Person]??? Code

211 Brain [Domain Person] DSL Code Brain [Developer]

212

213 One more thing:

214 One more thing: Why all these pictures?

215 I like airplanes.

216 Build a research airplane for high AoA and thrust vector control

217 Build a research airplane for high AoA and thrust vector control Not enough!

218 Build a research airplane for high AoA and thrust vector control Not enough! Systems Engineering

219 Build a research airplane for high AoA and thrust vector control Not enough! Systems Engineering Requirements Design continuous. Early Formalization of many aspects.

220 And: The airplane is custom-built for the task. One size does not fit all.

221

222 THE END..coordinates web skype schogglad xing linkedin