Software Architecture is often either imprecise and hard to grasp or technology specific. What you really want is a succinct, precise, technology-independent and tool-processable description of an architecture. In this tutorial we illustrate how textual DSLs can be used to this end. The core idea is to actually develop an architecture language as you understand the architecture, formalizing the growing intuitive understanding into a formal language. This removes ambiguity from the discussion, requires answers to arising questions and results in a more consistent and (re-)usable architecture. The tutorial has three parts: we start with a role play where we showcase how an architecture DSL is developed as part of a discussion about a system's architecture. We actually build an example DSL in real time. In part two we look at some of the concepts, rationales and benefits of the approach, and briefly point to tools that can be used to build languages and associated tooling. The third part looks at how to use the approach for product lines: how to express variability in the architectural descriptions, and how to integrate the DSL with feature-modeling based variability management. The tutorial is for practitioners, by practitioners. It is guaranteed to contain only practice-oriented material.

3. Architecture As Language MarkusVoelter www.voelter.devoelter@acm.org

5. About Markus Voelter Independent Consultant

6. About Markus Voelter Independent Consultant Software Architecture DSLs & MDSD ProductLines

7. About Markus Voelter Independent Consultant http://www.voelter.de voelter@acm.org skype: schogglad

8. Architecture

9. Architecture DSLs/MDSD

10. Architecture DSLs/MDSD ProductLines

11. Architecture DSLs/MDSD ProductLines This Talk

12. Architecture Whatever has to be consistent throughout a system to satisfy requirements and -ilities. != granularity evolves over time

13. DSLs/MDSD Modeling Language Design Code Generation  UML, SysML or ADLs here: Textual

14. ProductLines Managing the Variability between a family of related, but not identical products

16. Based on actualpracticalexperience

17. Currently in usewithfourofmycustomers

18. Benchmarkedby suitabilityforuse in today‘sprojects

20. Part 1 A real-word Story 1.1 System Background 1.2 The Starting Point 1.3 What is a language? 1.4 Developing the Language …

21. Part 2 TheoryandConcepts 2.1 What we did in a Nutshell 2.2 Domain Specific Languages 2.3 The Importance of Viewpoints 2.4 Benefits 2.5 Why Textual? 2.6 Model Validation 2.7 Generating Code 2.8 Architecture Analysis Tools 2.9 Standards, UML and ADLs …

22. Part 2 TheoryandConcepts 2.10 Why not use a 3GL? 2.11 My Notion of Components 2.12 Component Implementation 2.13 The Role of Patterns 2.14 Documentation 2.15 Expressing Variability 2.16 PLE – Big Picture 2.17 Process 2.18 Underlying Concepts

23. More Reading: Thispresentationis not suitableforreadingwithoutmetalking in parallel. Youcan find documentsdescribingthecontentat http://www.voelter.de/data/articles/ArchitectureAsLanguage-PDF.pdf http://www.voelter.de/data/articles/ArchitectureAsLanguage-Part2-PDF.pdf

25. 1 A Real-World Story

26. Customer Consultant

27. Requirements Domain Expertise Solution Approach

29. 1.1 A Real-World Story System Background

30. Flight Management System

31. Monitors Website Aircraft-Module Data Center

32. Distributed System

33. A lotofexperiencewithsystemslikethese

34. Evolveover 15 – 20 years

35. Multiple Languages Java C++ C#

36. Technology Abstraction

37. Cannot update everythingatonce

38. Loose coupling Versioning

39. Different Installations have different features

40. Variants ProductLines

42. 1.2 A Real-World Story The Starting Point

43. Backbone:Messaging [Good]

44. Technology Evaluated

45. BusinessObject Model [Not so good]

46. Problem:Consistence? Big Picture? Technology Abstraction?

47. Huge & Typical Problem

48. Language!

49. Formal Language!

51. 1.3 A Real-World Story Whatis a language?

52. INFORMAL Set of well-definedterms

53. INFORMAL Stakeholders agree on meaning

54. FORMAL Metamodel

55. FORMAL Metamodel Grammar

56. FORMAL Metamodel Grammar Notation

58. 1.4 A Real-World Story Developingthe Language

59. Let‘sdefine a formal languagetodescribethesystem‘sarchitecture

60. Components

61. Component:SmallestArchitecturally Relevant Building Block

62. Component:Piece offunctionality

63. Component:Can beinstantiated

64. Initial Components: Delay Calculator Info Screen Aircraft Module

65. componentDelayCalculator{} componentInfoScreen {} componentAircraftModule {}

66. Language == ConceptualArchitecture

67. „Program“ == Application Architecture

68. Conceptual: Component Application: DelayCalculator, InfoScreen, Aircraft Module

69. DelayCalculator receivesdatafrom Aircraft Module

70. DelayCalculator forwardsdata to InfoScreens

71. Interfaces

72. componentDelayCalculatorimplementsIDelayCalculator {} componentInfoScreenimplementsIInfoScreen {} componentAircraftModuleimplementsIAircraftModule {} interfaceIDelayCalculator {} interfaceIInfoScreen {} interfaceIAircraftModule {}

73. But wedon‘t express interface requirements!

74. Interface provision + Interfacerequirement  Dependencygraph

75. Essentialfor understanding andtool-based Analysis

76. componentDelayCalculator { providesIDelayCalculator requiresIInfoScreen } componentInfoScreen { providesIInfoScreen } componentAircraftModule { providesIAircraftModule requiresIDelayCalculator } interfaceIDelayCalculator {} interfaceIInfoScreen {} interfaceIAircraftModule {}

77. Therearemany InfoScreens andAircraftModules

78. Components needtobeinstantiated

79. Instantiation: veryimportant conceptwhendefininglanguages

80. componentInfoScreen { providesIInfoScreen } instance screen1: InfoScreen instance screen2: InfoScreen …

81. Componets (types) arealreadycompatible viatheirinterfaces.

82. OneDelayCalculatortypicallytalkstomany InfoScreens

83. Ports

84. Port: CommunicationEndpoint

85. Port: OwnedbyComponent

86. Port: Instantiatedalong withComponent

87. Port: Can havecardinality

88. componentDelayCalculator { provides default: IDelayCalculator requires screens[0..n]: IInfoScreen } componentInfoScreen { provides default: IInfoScreen } componentAircraftModule { provides default: IAircraftModule requires calculator[1]: IDelayCalculator }

89. Weshould separate portsand interfaces byroles!

90. componentDelayCalculator { provides aircraft: IAircraftStatus providesmanagementConsole: IManagementConsole requires screens[0..n]: IInfoScreen } component Manager { requires backend[1]: IManagementConsole } componentInfoScreen { provides default: IInfoScreen } componentAircraftModule { requires calculator[1]: IAircraftStatus }

91. Enrichmentof Language  BetterApplicationArchitecture

92. Howtoactuallyconnectinstances andtheirports?

93. Connectors

94. Connector: Connectstwoormoreportinstances

95. componentDelayCalculator { requires screens[0..n]: IInfoScreen … } componentInfoScreen { provides default: IInfoScreen } instance dc: DelayCalculator instance screen1: InfoScreen instance screen2: InfoScreen connectdc.screens to (screen1.default, screen2.default)

96. How do westructure/organizetheoverallsystem?

97. Namespaces

98. namespacecom.mycompany { namespace datacenter { componentDelayCalculator { provides aircraft: IAircraftStatus providesmanagementConsole: IManagementConsole requires screens[0..n]: IInfoScreen } component Manager { requires backend[1]: IManagementConsole } } namespace mobile { componentInfoScreen { provides default: IInfoScreen } componentAircraftModule { requires calculator[1]: IAircraftStatus } } }

99. Systems are a separate viewpoint

100. namespacecom.mycompany.test { systemtestSystem { instance dc: DelayCalculator instance screen1: InfoScreen instance screen2: InfoScreen connectdc.screens to (screen1.default, screen2.default) } }

101. Wedon‘tknowthe InfoScreens statically whenthesystemisdesigned!

102. Dynamic Connectors

103. Dynamic Connector:Discovers target(s) atruntimeusing a naming/trader/registryservice

104. namespacecom.mycompany.production { instance dc: DelayCalculator // InfoScreen instances are created and // started in other configurations dynamicconnectdc.screensevery 60 query { type = IInfoScreen status = active } }

105. Dynamic Wiring does not invalidate theoverallapproach

106. Similar Approach canbeusedfor redundant connectors

107. Registration Properties forinstances used in lookup

108. namespacecom.mycompany.datacenter { registeredinstance dc1: DelayCalculator { parameters {role = primary} } registeredinstance dc2: DelayCalculator { parameters {role = backup} } }

109. Interfaces aren‘treallydefinedyet

110. Interface:setofrelated messages

111. interfaceIInfoScreen { messageexpectedAircraftArrivalUpdate (id: ID, time: Time) messageflightCancelled(flightID: ID) … }

112. Data Structures

113. typedef long ID struct Time { hour: int min: int seconds: int }

114. Different kinds ofmessages: oneway, req/resp

115. Message Interaction Patterns

116. interfaceIAircraftStatus { onewaymessagereportPosition (aircraft: ID, pos: Position ) request-replymessagereportProblem { request (aircraft: ID, problem: Problem, comment: String) reply (repairProcedure: ID) } }

117. Is itreally Messages?

118. ?

119. Status Updates! Flight Plans…!

120. WrongAbstraction!

121. Messages aretheimplementation, notthearchitecturalintent.

122. Data Replication

123. Data Replication Define Data Updated byfew, readbymany Full update, incremental update,invaldation…

124. New architecturalabstractionisadded tothelanguage

125. structFlightInfo { from: Airport to: Airport scheduled: Time expected: Time … } replicatedsingleton flights { flights: FlightInfo[] } componentDelayCalculator { publishes flights } componentInfoScreen { consumes flights }

126. More Concise

127. System derives Messages for (full & partial) update, invalidation, etc.

128. More specifics

129. componentDelayCalculator { publishes flights { publication = onchange } } componentInfoScreen { consumes flights { init = all update = every(60) } }

130. We stillneedmessages. Semantics?

131. Pre- and Post- Conditions

132. interfaceIAircraftStatus { onewaymessagereportPosition(aircraft: ID, pos: Position ) { pre aircraft != null: “aircraft not specified” pre pos != null: “position not specified” } request-replymessagereportProblem { request (aircraft: ID, problem: Problem, comment: String) reply (repairProcedure: ID) pre aircraft != null: “aircraft not specified” pre problem != null: “problem not specified” postrepairProcedure != null } }

133. Common Constraints: Shorter Syntax

134. interfaceIAircraftStatus { onewaymessagereportPosition(aircraft: ID!, pos: Position! ) request-replymessagereportProblem { request (aircraft: ID!, problem: Problem!, comment: String!) reply (repairProcedure: !ID) } }

135. Message Sequences: Protocol State Machines

136. interfaceIAircraftStatus { onewaymessageregisterAircraft(aircraft: ID! ) onewaymessageunregisterAircraft(aircraft: ID! ) onewaymessagereportPosition(aircraft: ID!, pos: Position! ) request-replymessagereportProblem { request (aircraft: ID!, problem: Problem!, comment: String!) reply (repairProcedure: !ID) } protocolinitial = new { state new { registerAircraft => registered } state registered { unregisterAircraft => new reportPosition reportProblem } } }

137. Invariantsfor Data Structures

138. struct Time { hour: int min: int seconds: int inv hour >= 0 && hour <= 23: “hour must be 0-23” inv min >= 0 && min <= 59: “min must be 0-59” inv seconds >= 0 && seconds <= 59: “seconds must be 0-59” }

139. Widelydistributed!Versioning?

140. Mark upversionsofcomponents (andotherstuff)

141. componentDelayCalculator { publishes flights { publication = onchange } } newImplOfcomponentDelayCalculator: DelayCalculatorV2

142. componentDelayCalculator { publishes flights { publication = onchange } } newVersionOfcomponentDelayCalculator: DelayCalculatorV3 { publishes flights { publication = onchange } providessomethingElse: ISomething }

143. TheEnd ! ofthe Story :-)

144. None ofthosethingsisnew orunique.

145. But everything isexpressedexplicitlyandconsistently, all in oneplace.

147. 2 TheoryandConcepts

148. 2.1 TheoryandConcepts Whatwedid in a Nutshell

149. As you understand anddevelopyour Architecture…

150. Develop a languageto express it!

151. Language resemblesarchitecturalconcepts

152. We express theapplication(s) withthelanguage.

153. Architecture DSL

155. 2.2 TheoryandConcepts Domain SpecificLanguages

156. Definition

157. A DSL is a focussed, processablelanguagefor describing a specific concernwhen building a system in a specific domain. Theabstractionsandnotationsused are natural/suitablefor the stakeholderswho specify that particular concern.

158. focussed

159. processable

160. language

161. concern/viewpoint

162. domain

163. abstractions

164. notation

165. stakeholders

166. Dimensions

167. internal vs. external

168. compiled vs. interpreted

169. customization vs. configuration

170. graphical vs. textual

171. 2.3 TheoryandConcepts The ImportanceofViewpoints

172. viewpoint A „perspective“ towardsthesystem

173. Based on a slideby Steve Cook and IEEE 1471

174. Type Deployment Composition

177. 2.4 TheoryandConcepts Benefits

178. Clear Understanding frombuildingthelanguage

179. Unambigious Vocabulary

180. Conceptsindependent from Technology

181. Programming Model canbedefinedbased on ConceptualArcitecture

182. Architecture„executable“ (i.e. morethanrulesanddocs)

184. 2.4 TheoryandConcepts WhyTextual?

185. 2.4 TheoryandConcepts … or:why not graphical?

186. Languagesand Editors areeasiertobuild

187. Languagesand Editors areeasiertobuild Evolve Language and simple editorasyou understand anddiscussthearchitecture, in real time!

188. Integrateseasilywithcurrentinfrastructure: CVS/SVN diff/merge

189. Model evolutionistrivial, youcanalwaysusegrep. adaptingexistingmodelsasthe DSL evolves

190. Many Developers prefertextualnotations

191. When a graphical notation isbetter, youcanvisualize.

192. Via M2M Read-Only Auto-Layout Drill-Down

193. Textual DSLs vs. Graphical vs. Visualization

194. Graphviz

195. Prefuse

196. I am aware of the usefulness of graphical notations. I am exaggerating here a little bit. But: We’ve been building software with text only for a long time. We know it works.

198. 2.5 TheoryandConcepts Tooling

199. Severaltoolsavailable. Example:oAWXtext

200. SpecifyGrammar

201. AntlrGrammarandParserisgeneratedfromthisspecification

202. Generated Metamodel

203. SpecifyConstraints

204. Generated Editor

205. Generated Editor Code Completion

206. Generated Editor Syntax Coloring Custom KeywordColoring

207. Generated Editor RealtimeConstraintValidation

208. Generated Editor Customizable Outlines

209. Generated Editor Code Folding

210. Generated Editor Goto Definition Find References Cross-File References Model as EMF

211. Generated Editor

212. XtextOverview

213. GrapVizOverview

214. GrapVizTrafo Code

215. Another Tool…? OSLO

216. Another Tool…? Jetbrains MPS

217. Another Tool…?

219. 2.6 TheoryandConcepts Model Validation

220. Grammaris not expressiveenough

221. More Validation Rules Required:Constraints

222. Simple Examples: Name-Uniqueness Type Checks Non-Nullness

223. More ComplexExamples: Version Compatibility Overall completeness Quality of Service

224. context Interface ERROR"interface names must start "+ "with a capital I": name.startsWith("I"); context Component ERROR"Qualified Name "+qualifiedName()+" must be unique" : allComponents(). select( c | c.qualifiedName() == qualifiedName() ) .size == 1; context Attribute ERROR"no type defined: "+ type.name: visibleInstancesOfType(this, DataType) .contains(type); context Connector ERROR"target must be provided port": ProvidedPort.isInstance( u);

225. Precondition I: AlgorithmforConstraint

226. Precondition II: All Data Available

228. 2.7 TheoryandConcepts Generating Code

229. Sincewealready have a formal model….

230. Generate API MapsArchitecturalConceptsto Implementationlanguage (non-trivial!)

231. Implementation Implementationonlydepends onthegeneratedprogramming model API

232. Programming Model Generated API + Usage Idioms Completely Technology-Independent

233. Runtime Infrastructure Select based on fit wrt. toarchitectural conceptsand non-functionalrequirements

234. Glue Code Aka Technology Mapping Code Maps API toselectedplatform

235. Glue Code ContainsConfiguration Files forPlatform Mightrequire „mix in models“

236. SeveralPlatforms Different Platforms, not Languages Support forScaling (non-functionalreq) Testing!

237. Benefits:More EfficientImpl. Technology Independent Consistence/Quality Architecture-Conformance

238. Code Gen Sequence 1) Generate API 2) Write Impl Code 3) Select Platform 4) GenerateGlue Code

239. Separate Models forstuff relevant forthe API vs. system/deploymentstuff

241. 2.8 TheoryandConcepts Architecture Analysis Tools

242. SoftwareTomographySonarJ Structure 101 … andthelike

243. How do youdescribe Architecture?

244. Constraint-Driven: AssemblePackagesinto Components Definelayers/columns Defineand Check valid Dependencies

245. You do not get a waytodefineandexpress architectural abstractionsbeyondthose!

246. Dependency Analysis Anti Pattern Detection Metrics [Trend Analysis] [Visualization]

247. Police Approach: Detect Problems After thefact!

248. Anti Pattern Detection Metrics Usefulformanuallywrittenpartsofthesystem

249. Dependency Analysis Usefulformanuallywrittenpartsofthesystem Constraintsgenerated fromthe model.

251. 2.9 TheoryandConcepts Standards,UML and ADLs

252. FormalArchitecture Description is not new: ADLs, UML

253. But allofthoseuseexisting, genericlanguages!

254. Thismissesthepoint!

255. Tryingto express yourspecificarchitecturewithpredefinedabstractionsis not useful!

256. Youwanttobuild a languagetocaptureyourownarchitecturalabstractionsasyourlearnthings.

257. Wherearestandardsuseful?

258. Peoplehavetolearnarchitecturalconcepts anyway.

259. Is UML with a profilestill a standardlanguage?

260. On whichmetaleveldo I wanttostandardize? M2 (UML), M3 (MOF)?

261. Isn‘t a DSLbased on MOFas „standard“ as a profilebased on UML?

262. UMLProfilesinstead? You‘llthinkmoreabout UML-itiesthanyourownconcepts

263. UMLProfilesinstead? Tool integrationissues (repository, diff/merge, versioning)

264. UMLProfilesinstead? Tools areoftencomplex, heavyweight, bloated. Acceptance limited.

265. UML Generally Useless? No. UML canbeusedfordocu-mentation (sequencediagrams, eg)

266. NB: Youcando all ofthiswith UML! However, myexprienceshowsitismuchlessproductiveand agile. Ifyouhave a UML-basedorganization, use UML.

268. 2.10 TheoryandConcepts Why not use a 3GL?

269. ArchitecturalAbstractionsarenotfirstclasscitizensin 3GLs

270. Classescanrepresenteverything– especiallywithannotations (metadata)

271. Problems:shoehorningintoclasses; like UML

272. Problems:annotations = stereotypes

273. Problems:limited analyzability(not a model)

274. Problems:mix architecturalandimplementationconcerns

276. 2.11 TheoryandConcepts My Notion of Components

277. DefinitionsAbound: A Building Block forsoftwaresystems

278. DefinitionsAbound: Something withexplicitcontextdependenciesonly

279. DefinitionsAbound: Something thatcontainsbusinesslogicandruns in a container

280. My Understanding: Smallestarchitecturally relevant building block

281. My Understanding: Black Box - Architecturally

282. My Understanding: All architecturally relevant aspectsspecifieddeclaratively (model)

283. My Understanding: Analyzable, Composablebytools

284. My Understanding: Running in container, providestechnicalservicesatcomponentboundary

285. The specificstructureandmetadataof a componentdefinedspecificallyforeachproject/system/ productline

286. Thisiswhatwe do withthe … Architecture DSL

288. 2.12 TheoryandConcepts ComponentImplementation

289. By Default: ManualyProgrammingagainsttheProgMod API

290. Alternatives: Generate, based on config

291. Alternatives: Generate, based on config State Machines

292. Alternatives: Generate, based on config State Machines RuleLanguages + Engines

293. Alternatives: Generate, based on config State Machines RuleLanguages + Engines Specific DSL

294. Tointegratebehavior, createspecificabstractionsin thearchitecture DSL. ADD THE CASCADING STUGGF HERE

295. Note: A lotofimplementationcanbegeneratedautomatically (noconfig) fromthe model (persistence, serialization, …)

297. 2.13 TheoryandConcepts The Roleof Patterns

298. Pattern: Proven solutions to recurring problems, including their applicability, trade-offs and consequences.

299. Architecture Patterns: “Blueprint” for a specific architectural style

300. Architecture Patterns: “Blueprint” for a specific architectural style  Inspires the concepts for architecture DSL

301. Design Patterns: More concrete, moreimplementation-relatedthanarch. patterns

302. Design Patterns: More concrete, moreimplementation-relatedthanarch. patterns Typicallydoes not end up in the DSL, but …

303. Design Pattern: More concrete, moreimplementation-relatedthanarch. patterns putintothecodegenerator

304. It‘s not thecodegeneratorwhodecidesabouttheimplementationof a pattern – it‘s still the (generator) developer! A Pattern ismorethanthesolution UML diagram!

306. 2.14 TheoryandConcepts Documentation

307. The DSL andthe „programs“ aredocumentation.

308. So I don‘thavetowrite… … moredocs?

309. Not quite.

310. 1

311. Grammaris a good formal definition, but not a teachingtool.

312. Grammaris a good formal definition, but not a teachingtool. Tutorials

313. Tutorials: ArchitecturalConcepts (Meta Model) Howtousethelanguage Howtousetheprogramming model (Howtogeneratecode) (Howtoaddmanualcode)

314. Tutorials: ArchitecturalConcepts (Meta Model) Howtousethelanguage Howtousetheprogramming model (Howtogeneratecode) (Howtoaddmanualcode) ExampleDriven!

315. 2

316. Grammardescribeswhatthearchitecturelookslike.

317. Grammardescribeswhatthearchitecturelookslike. But: Whyisitthatway?

318. Rationales

319. Rationales ConceptualArchitecture RelatetoGrammar

320. Rationales ConceptualArchitecture RelatetoGrammar Technological Decisions Non-Func. Req.

322. 2.15 TheoryandConcepts ExpressingVariability

323. Different Variants ofthe System for different customers.

324. How do I express this in themodels?

325. Negative Variability: Conditionallytakingsomethingaway

326. Negative Variability: Conditionallytakingsomethingaway Feature Models

328. componentDelayCalculator { provides default: IDelayCalculator requires screens[0..n]: IInfoScreen providesmon: IMonitoringfeature monitoring }

329. componentDelayCalculator { provides default: IDelayCalculator requires screens[0..n]: IInfoScreen providesmon: IMonitoringfeature monitoring }

330. namespacemonitoringStufffeature monitoring { componentMonitoringConsole { requires devices:[*]: IMonitor } instance monitor: MonitoringConsole dynamicconnectmonitor.devicesquery { type = IMonitor } }

332. Positive Variability:Conditionallyaddingsomethingto a minimal core

333. Positive Variability:Conditionallyaddingsomethingto a minimal core Aspects

334. namespacemonitoring { componentMonitoringConsole … instance monitor: … dynamicconnectmonitor.devices … aspect (*) component { providesmon: IMonitoring } }

335. componentDelayCalculator { … } componentAircraftModule { … } componentInfoScreen { … }

336. componentDelayCalculator { … } componentAircraftModule { … } componentInfoScreen { … } componentDelayCalculator { … providesmon: IMonitoring } componentAircraftModule { … providesmon: IMonitoring } componentInfoScreen { … providesmon: IMmonitoring } aspect (*) component { providesmon: IMonitoring }

337. Weaver isgeneric: workswith all (container) model elements

338. aspect (*) <type> all instancesoftype aspect (tag=bla)<type> all instanceswith tag bla aspect (name=S*) <type> all instanceswhosenamestartswith S

339. AO + Features namespacemonitoring feature monitoring { componentMonitoringConsole … instance monitor: … dynamicconnectmonitor.devices … aspect (*) component { providesmon: IMonitoring } }

341. 2.16 TheoryandConcepts PLE – Big Picture

342. Configuration vs. Customization

343. Customization vs. Configuration

344. Customization vs. Configuration

345. MDSD - Thumbnail

346. MD-PLE - Thumbnail fewer!

347. MD-PLE: Models

348. MD-PLE – Thumbnail II moreoptions

349. Variability in theprocesschain Transformation AO (oAW)

350. Variability in theprocesschain Generator AO (oAW)

352. 2.17 TheoryandConcepts Process

353. Iterate!

354. Iterate! Concepts

355. Iterate! Concepts GrammarConstraints

356. Iterate! Examples Concepts GrammarConstraints

357. Iterate! Generator Examples Concepts GrammarConstraints

358. Iterate! Generator Code Completion, etc. Examples Concepts GrammarConstraints

359. Reviews still necessary!

360. Reviews still necessary! but simplified, becausearchitectureismore explicit

361. Architect (Team) ArchitecturalConcepts Grammar, Constraints Examples Programming Model

362. Tool Engineer Editor Customization (API) Code Generator

363. Platform Expert Glue Code Generator

364. Application Developer Uses Language Generates Code Writes Manual Code against gen. API Code

365. New language foreach system?

366. Common Base?

367. Reusable Language Modules?

368. LanguageFamily?PLE?

369. AnotherTalk!

371. 2.18 TheoryandConcepts Underlying Concepts

372. Abstraction

373. Formalize

374. LimitFreedom

375. Declaration Implementation

376. Notation

377. Types & Instances

378. Viewpoints

379. Hierarchical Decomposition

380. Translate

381. Handle Crosscuts

382. Go Meta

383. Reflection

384. Automate

385. Orthogonality

386. Contracts

387. IsolateTechnology

388. Don‘t Overspecify

389. Make Explicit

390. Platforms

392. THE END. Thankyou. Questions?