Architecture As Language
5 likes753 views
The document discusses the concept of architecture as a language, focusing on Domain-Specific Languages (DSLs) and Model-Driven Software Development (MDSD) for defining software architectures. It presents a real-world case study involving a flight management system and emphasizes the importance of formal languages, viewpoints, and the generation of code from architectural models. The author argues for the necessity of creating tailored languages to express unique architectural concepts rather than relying solely on existing generic languages.
![Backbone:Messaging[Good]](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-43-320.jpg)
![BusinessObject Model[Not so good]](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-45-320.jpg)
![componentDelayCalculator {provides default: IDelayCalculatorrequires screens[0..n]: IInfoScreen}componentInfoScreen {provides default: IInfoScreen}componentAircraftModule {provides default: IAircraftModulerequires calculator[1]: IDelayCalculator}](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-88-320.jpg)
![componentDelayCalculator {provides aircraft: IAircraftStatusprovidesmanagementConsole: IManagementConsolerequires screens[0..n]: IInfoScreen}component Manager {requires backend[1]: IManagementConsole}componentInfoScreen {provides default: IInfoScreen}componentAircraftModule {requires calculator[1]: IAircraftStatus}](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-90-320.jpg)
![componentDelayCalculator { requires screens[0..n]: IInfoScreen …}componentInfoScreen {provides default: IInfoScreen}instance dc: DelayCalculatorinstance screen1: InfoScreeninstance screen2: InfoScreen connectdc.screensto (screen1.default, screen2.default)](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-95-320.jpg)
![namespacecom.mycompany {namespace datacenter {componentDelayCalculator {provides aircraft: IAircraftStatusprovidesmanagementConsole: IManagementConsolerequires screens[0..n]: IInfoScreen }component Manager {requires backend[1]: IManagementConsole } }namespace mobile {componentInfoScreen {provides default: IInfoScreen }componentAircraftModule {requires calculator[1]: IAircraftStatus } }}](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-98-320.jpg)
![structFlightInfo { from: Airport to: Airport scheduled: Time expected: Time …} replicatedsingleton flights { flights: FlightInfo[]} componentDelayCalculator {publishes flights} componentInfoScreen {consumes flights}](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-125-320.jpg)
![Dependency AnalysisAnti Pattern DetectionMetrics[Trend Analysis][Visualization]](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-246-320.jpg)
![componentDelayCalculator {provides default: IDelayCalculatorrequires screens[0..n]: IInfoScreenprovidesmon: IMonitoringfeature monitoring}](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-328-320.jpg)
![componentDelayCalculator {provides default: IDelayCalculatorrequires screens[0..n]: IInfoScreenprovidesmon: IMonitoringfeature monitoring}](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-329-320.jpg)
![namespacemonitoringStufffeature monitoring { componentMonitoringConsole {requires devices:[*]: IMonitor }instance monitor: MonitoringConsoledynamicconnectmonitor.devicesquery { type = IMonitor } }](https://image.slidesharecdn.com/architectureaslanguage-091018023630-phpapp02/85/Architecture-As-Language-330-320.jpg)
Architecture As Language
- 6. AboutMarkus VoelterIndependent ConsultantSoftware ArchitectureDSLs & MDSDProductLines
- 8. Architecture
- 12. ArchitectureWhatever has to be consistent throughout a system to satisfyrequirements and -ilities.!= granularityevolves over time
- 13. DSLs/MDSDModeling Language DesignCode Generation UML, SysML or ADLshere: Textual
- 14. ProductLinesManaging the Variabilitybetween a family of related,but not identical products
- 20. Part 1A real-word Story1.1 System Background1.2 The Starting Point1.3 What is a language?1.4 Developing the Language…
- 21. Part 2TheoryandConcepts2.1 What we did in a Nutshell2.2 Domain Specific Languages2.3 The Importance of Viewpoints2.4 Benefits2.5 Why Textual?2.6 Model Validation2.7 Generating Code2.8 Architecture Analysis Tools2.9 Standards, UML and ADLs…
- 22. Part 2TheoryandConcepts2.10 Why not use a 3GL?2.11 My Notion of Components2.12 Component Implementation2.13 The Role of Patterns2.14 Documentation2.15 Expressing Variability2.16 PLE – Big Picture2.17 Process2.18 Underlying Concepts
- 23. More Reading:Thispresentationis not suitableforreadingwithoutmetalking in parallel. Youcan find documentsdescribingthecontentathttp://www.voelter.de/data/articles/ArchitectureAsLanguage-PDF.pdfhttp://www.voelter.de/data/articles/ArchitectureAsLanguage-Part2-PDF.pdf
- 29. 1.1A Real-World StorySystem Background
- 34. Evolveover 15 – 20 years
- 39. Different Installationshave different features
- 42. 1.2A Real-World StoryThe Starting Point
- 45. BusinessObject Model[Not so good]
- 48. Language!
- 49. FormalLanguage!
- 51. 1.3A Real-World StoryWhatis a language?
- 54. FORMALMetamodel
- 58. 1.4A Real-World StoryDevelopingthe Language
- 59. Let‘sdefine a formal languagetodescribethesystem‘sarchitecture
- 60. Components
- 64. Initial Components:Delay CalculatorInfo ScreenAircraft Module
- 71. Interfaces
- 72. componentDelayCalculatorimplementsIDelayCalculator {}componentInfoScreenimplementsIInfoScreen {}componentAircraftModuleimplementsIAircraftModule {}interfaceIDelayCalculator {}interfaceIInfoScreen {}interfaceIAircraftModule {}
- 74. Interface provision +Interfacerequirement Dependencygraph
- 76. componentDelayCalculator {providesIDelayCalculatorrequiresIInfoScreen}componentInfoScreen {providesIInfoScreen}componentAircraftModule {providesIAircraftModulerequiresIDelayCalculator}interfaceIDelayCalculator {}interfaceIInfoScreen {}interfaceIAircraftModule {}
- 80. componentInfoScreen {providesIInfoScreen}instance screen1: InfoScreeninstance screen2: InfoScreen…
- 83. Ports
- 88. componentDelayCalculator {provides default: IDelayCalculatorrequires screens[0..n]: IInfoScreen}componentInfoScreen {provides default: IInfoScreen}componentAircraftModule {provides default: IAircraftModulerequires calculator[1]: IDelayCalculator}
- 90. componentDelayCalculator {provides aircraft: IAircraftStatusprovidesmanagementConsole: IManagementConsolerequires screens[0..n]: IInfoScreen}component Manager {requires backend[1]: IManagementConsole}componentInfoScreen {provides default: IInfoScreen}componentAircraftModule {requires calculator[1]: IAircraftStatus}
- 91. Enrichmentof Language BetterApplicationArchitecture
- 93. Connectors
- 95. componentDelayCalculator { requires screens[0..n]: IInfoScreen …}componentInfoScreen {provides default: IInfoScreen}instance dc: DelayCalculatorinstance screen1: InfoScreeninstance screen2: InfoScreen connectdc.screensto (screen1.default, screen2.default)
- 97. Namespaces
- 98. namespacecom.mycompany {namespace datacenter {componentDelayCalculator {provides aircraft: IAircraftStatusprovidesmanagementConsole: IManagementConsolerequires 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: DelayCalculatorinstance screen1: InfoScreeninstance screen2: InfoScreenconnectdc.screensto (screen1.default, screen2.default) }}
- 102. DynamicConnectors
- 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 Wiringdoes not invalidatetheoverallapproach
- 106. Similar Approachcanbeusedfor redundant connectors
- 107. RegistrationProperties forinstancesused in lookup
- 108. namespacecom.mycompany.datacenter {registeredinstance dc1: DelayCalculator {parameters {role = primary} }registeredinstance dc2: DelayCalculator {parameters {role = backup} }}
- 111. interfaceIInfoScreen {messageexpectedAircraftArrivalUpdate (id: ID, time: Time)messageflightCancelled(flightID: ID) …}
- 112. Data Structures
- 113. typedef long IDstruct Time { hour: int min: int seconds: int}
- 116. interfaceIAircraftStatus {onewaymessagereportPosition (aircraft: ID, pos: Position )request-replymessagereportProblem {request (aircraft: ID, problem: Problem, comment: String)reply (repairProcedure: ID) }}
- 117. Is itreallyMessages?
- 118. ?
- 120. WrongAbstraction!
- 122. Data Replication
- 123. Data ReplicationDefine DataUpdated byfew, readbymanyFull update, incremental update,invaldation…
- 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 derivesMessages for (full & partial) update, invalidation, etc.
- 128. More specifics
- 129. componentDelayCalculator {publishes flights { publication = onchange }} componentInfoScreen {consumes flights { init = all update = every(60) }}
- 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 => newreportPositionreportProblem } }}
- 138. struct Time { hour: int min: int seconds: intinv 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”}
- 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 :-)
- 145. But everythingisexpressedexplicitlyandconsistently, all in oneplace.
- 147. 2TheoryandConcepts
- 148. 2.1TheoryandConceptsWhatwedid in a Nutshell
- 150. Develop a languageto express it!
- 152. We express theapplication(s) withthelanguage.
- 153. ArchitectureDSL
- 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. internalvs.external
- 170. graphicalvs.textual
- 173. Based on a slideby Steve Cook and IEEE 1471
- 181. Programming Model canbedefinedbased on ConceptualArcitecture
- 185. 2.4TheoryandConcepts… or:why not graphical?
- 187. Languagesand EditorsareeasiertobuildEvolve Language and simple editorasyou understand anddiscussthearchitecture, in real time!
- 191. When a graphicalnotationisbetter, youcanvisualize.
- 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.
- 200. SpecifyGrammar
- 202. Generated Metamodel
- 203. SpecifyConstraints
- 204. Generated Editor
- 206. Generated EditorSyntax ColoringCustom KeywordColoring
- 210. Generated EditorGoto Definition Find ReferencesCross-File ReferencesModel as EMF
- 211. Generated Editor
- 212. XtextOverview
- 213. GrapVizOverview
- 214. GrapVizTrafo Code
- 215. Another Tool…?OSLO
- 217. Another Tool…?
- 223. More ComplexExamples:Version CompatibilityOverall completenessQuality 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);
- 226. Precondition II:All Data Available
- 229. Sincewealreadyhave a formal model….
- 232. Programming ModelGenerated API + Usage IdiomsCompletely Technology-Independent
- 233. Runtime InfrastructureSelect based on fit wrt. toarchitecturalconceptsand non-functionalrequirements
- 234. Glue CodeAka Technology Mapping CodeMaps API toselectedplatform
- 235. Glue CodeContainsConfiguration Files forPlatformMightrequire „mix in models“
- 236. SeveralPlatformsDifferent Platforms, not LanguagesSupport forScaling (non-functionalreq)Testing!
- 238. Code Gen Sequence1) Generate API2) Write Impl Code3) Select Platform4) GenerateGlue Code
- 239. Separate Modelsforstuff relevant forthe APIvs. system/deploymentstuff
- 244. Constraint-Driven:AssemblePackagesinto ComponentsDefinelayers/columnsDefineand Check valid Dependencies
- 245. You do not get a waytodefineandexpress architecturalabstractionsbeyondthose!
- 246. Dependency AnalysisAnti Pattern DetectionMetrics[Trend Analysis][Visualization]
- 247. Police Approach:Detect ProblemsAfter thefact!
- 252. FormalArchitecture Description is not new: ADLs, UML
- 254. Thismissesthepoint!
- 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?
- 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.10TheoryandConceptsWhy not use a 3GL?
- 273. Problems:limited analyzability(not a model)
- 276. 2.11TheoryandConceptsMy Notion of Components
- 277. DefinitionsAbound:A Building Block forsoftwaresystems
- 279. DefinitionsAbound:Something thatcontainsbusinesslogicandruns in a container
- 281. My Understanding:Black Box - Architecturally
- 282. My Understanding:All architecturally relevant aspectsspecifieddeclaratively (model)
- 284. My Understanding:Running in container, providestechnicalservicesatcomponentboundary
- 285. The specificstructureandmetadataof a componentdefinedspecificallyforeachproject/system/ productline
- 286. Thisiswhatwe do withthe …ArchitectureDSL
- 290. Alternatives:Generate, based on config
- 291. Alternatives:Generate, based on configState Machines
- 292. Alternatives:Generate, based on configState MachinesRuleLanguages + Engines
- 293. Alternatives:Generate, based on configState MachinesRuleLanguages + EnginesSpecific DSL
- 294. Tointegratebehavior, createspecificabstractionsin thearchitecture DSL.ADD THE CASCADING STUGGF HERE
- 295. Note:A lotofimplementationcanbegeneratedautomatically (noconfig) fromthe model(persistence, serialization, …)
- 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. patternsTypicallydoes not end up in the DSL, but …
- 303. Design Pattern:More concrete, moreimplementation-relatedthanarch. patternsputintothecodegenerator
- 304. It‘s not thecodegeneratorwhodecidesabouttheimplementationof a pattern – it‘s still the (generator) developer!A Pattern ismorethanthesolution UML diagram!
- 307. The DSL andthe „programs“ aredocumentation.
- 308. So I don‘thavetowrite…… moredocs?
- 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)HowtousethelanguageHowtousetheprogramming model (Howtogeneratecode) (Howtoaddmanualcode)
- 314. Tutorials:ArchitecturalConcepts (Meta Model)HowtousethelanguageHowtousetheprogramming model (Howtogeneratecode) (Howtoaddmanualcode)ExampleDriven!
- 315. 2
- 318. Rationales
- 323. Different Variantsofthe Systemfor different customers.
- 324. How do I expressthis in themodels?
- 328. componentDelayCalculator {provides default: IDelayCalculatorrequires screens[0..n]: IInfoScreenprovidesmon: IMonitoringfeature monitoring}
- 329. componentDelayCalculator {provides default: IDelayCalculatorrequires screens[0..n]: IInfoScreenprovidesmon: IMonitoringfeature monitoring}
- 330. namespacemonitoringStufffeature monitoring { componentMonitoringConsole {requires devices:[*]: IMonitor }instance monitor: MonitoringConsoledynamicconnectmonitor.devicesquery { type = IMonitor } }
- 332. Positive Variability:Conditionallyaddingsomethingto a minimal core
- 333. Positive Variability:Conditionallyaddingsomethingto a minimal coreAspects
- 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 blaaspect (name=S*) <type>all instanceswhosenamestartswith S
- 339. AO + Featuresnamespacemonitoring feature monitoring { componentMonitoringConsole …instance monitor: …dynamicconnectmonitor.devices … aspect (*) component {providesmon: IMonitoring }}
- 341. 2.16TheoryandConceptsPLE – Big Picture
- 345. MDSD - Thumbnail
- 347. MD-PLE: Models
- 348. MD-PLE – Thumbnail IImoreoptions
- 349. Variability in theprocesschainTransformation AO (oAW)
- 350. Variability in theprocesschainGenerator AO (oAW)
- 353. Iterate!
- 354. Iterate!Concepts
- 360. Reviewsstill necessary! but simplified, becausearchitectureismore explicit
- 362. ToolEngineerEditor Customization(API) Code Generator
- 364. ApplicationDeveloperUses LanguageGenerates CodeWrites Manual Code against gen. API Code
- 366. CommonBase?
- 368. LanguageFamily?PLE?
- 369. AnotherTalk!
- 372. Abstraction
- 373. Formalize
- 374. LimitFreedom
- 376. Notation
- 377. Types & Instances
- 378. Viewpoints
- 380. Translate
- 381. HandleCrosscuts
- 382. Go Meta
- 383. Reflection
- 384. Automate
- 385. Orthogonality
- 386. Contracts
- 387. IsolateTechnology
- 388. Don‘tOverspecify
- 389. Make Explicit
- 390. Platforms