Architecture As Language

1,210 views
1,120 views

Published on

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.

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
1,210
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Architecture As Language

  1. 1.
  2. 2.
  3. 3. Architecture As Language<br />MarkusVoelter<br />www.voelter.devoelter@acm.org<br />
  4. 4.
  5. 5. About<br />Markus Voelter<br />Independent Consultant<br />
  6. 6. About<br />Markus Voelter<br />Independent Consultant<br />Software Architecture<br />DSLs & MDSD<br />ProductLines<br />
  7. 7. About<br />Markus Voelter<br />Independent Consultant<br />http://www.voelter.de<br />voelter@acm.org<br />skype: schogglad<br />
  8. 8. Architecture<br />
  9. 9. Architecture<br />DSLs/MDSD<br />
  10. 10. Architecture<br />DSLs/MDSD<br />ProductLines<br />
  11. 11. Architecture<br />DSLs/MDSD<br />ProductLines<br />This Talk<br />
  12. 12. Architecture<br />Whatever has to be consistent throughout a system to satisfy<br />requirements and -ilities.<br />!= granularity<br />evolves over time<br />
  13. 13. DSLs/MDSD<br />Modeling <br />Language Design<br />Code Generation<br /> UML, SysML or ADLs<br />here: Textual<br />
  14. 14. ProductLines<br />Managing the Variability<br />between a family of related,<br />but not identical products<br />
  15. 15.
  16. 16. Based on actualpracticalexperience<br />
  17. 17. Currently in usewithfourofmycustomers<br />
  18. 18. Benchmarkedby<br />suitabilityforuse in today‘sprojects<br />
  19. 19.
  20. 20. Part 1<br />A real-word Story<br />1.1 System Background<br />1.2 The Starting Point<br />1.3 What is a language?<br />1.4 Developing the Language<br />…<br />
  21. 21. Part 2<br />TheoryandConcepts<br />2.1 What we did in a Nutshell<br />2.2 Domain Specific Languages<br />2.3 The Importance of Viewpoints<br />2.4 Benefits<br />2.5 Why Textual?<br />2.6 Model Validation<br />2.7 Generating Code<br />2.8 Architecture Analysis Tools<br />2.9 Standards, UML and ADLs<br />…<br />
  22. 22. Part 2<br />TheoryandConcepts<br />2.10 Why not use a 3GL?<br />2.11 My Notion of Components<br />2.12 Component Implementation<br />2.13 The Role of Patterns<br />2.14 Documentation<br />2.15 Expressing Variability<br />2.16 PLE – Big Picture<br />2.17 Process<br />2.18 Underlying Concepts<br />
  23. 23. More Reading:<br />Thispresentationis not suitableforreadingwithoutmetalking in parallel. Youcan find documentsdescribingthecontentat<br />http://www.voelter.de/data/articles/ArchitectureAsLanguage-PDF.pdf<br />http://www.voelter.de/data/articles/ArchitectureAsLanguage-Part2-PDF.pdf<br />
  24. 24.
  25. 25. 1<br />A Real-World Story<br />
  26. 26. Customer<br />Consultant<br />
  27. 27. Requirements<br />Domain Expertise<br />Solution Approach<br />
  28. 28.
  29. 29. 1.1<br />A Real-World Story<br />System Background<br />
  30. 30. Flight<br />Management<br />System<br />
  31. 31. Monitors<br />Website<br />Aircraft-Module<br />Data Center<br />
  32. 32. Distributed<br />System<br />
  33. 33. A lotofexperiencewithsystemslikethese<br />
  34. 34. Evolveover 15 – 20 years<br />
  35. 35. Multiple Languages<br />Java<br />C++<br />C#<br />
  36. 36. Technology<br />Abstraction<br />
  37. 37. Cannot update <br />everythingatonce<br />
  38. 38. Loose coupling<br />Versioning<br />
  39. 39. Different Installations<br />have different features<br />
  40. 40. Variants<br />ProductLines<br />
  41. 41.
  42. 42. 1.2<br />A Real-World Story<br />The Starting Point<br />
  43. 43. Backbone:Messaging<br />[Good]<br />
  44. 44. Technology Evaluated<br />
  45. 45. BusinessObject Model<br />[Not so good]<br />
  46. 46. Problem:Consistence?<br />Big Picture?<br />Technology Abstraction?<br />
  47. 47. Huge & Typical<br />Problem<br />
  48. 48. Language!<br />
  49. 49. Formal<br />Language!<br />
  50. 50.
  51. 51. 1.3<br />A Real-World Story<br />Whatis a language?<br />
  52. 52. INFORMAL<br />Set of well-definedterms<br />
  53. 53. INFORMAL<br />Stakeholders<br />agree on meaning<br />
  54. 54. FORMAL<br />Metamodel<br />
  55. 55. FORMAL<br />Metamodel<br />Grammar<br />
  56. 56. FORMAL<br />Metamodel<br />Grammar<br />Notation<br />
  57. 57.
  58. 58. 1.4<br />A Real-World Story<br />Developingthe Language<br />
  59. 59. Let‘sdefine a formal languagetodescribethesystem‘sarchitecture<br />
  60. 60. Components<br />
  61. 61. Component:SmallestArchitecturally Relevant Building Block<br />
  62. 62. Component:Piece offunctionality<br />
  63. 63. Component:Can beinstantiated<br />
  64. 64. Initial Components:<br />Delay Calculator<br />Info Screen<br />Aircraft Module<br />
  65. 65. componentDelayCalculator{}<br />componentInfoScreen {}<br />componentAircraftModule {}<br />
  66. 66. Language<br />==<br />ConceptualArchitecture<br />
  67. 67. „Program“<br />==<br />Application<br />Architecture<br />
  68. 68. Conceptual:<br />Component<br />Application:<br />DelayCalculator, InfoScreen, Aircraft Module<br />
  69. 69. DelayCalculator<br />receivesdatafrom<br />Aircraft Module<br />
  70. 70. DelayCalculator<br />forwardsdata<br />to InfoScreens<br />
  71. 71. Interfaces<br />
  72. 72. componentDelayCalculatorimplementsIDelayCalculator {}<br />componentInfoScreenimplementsIInfoScreen {}<br />componentAircraftModuleimplementsIAircraftModule {}<br />interfaceIDelayCalculator {}<br />interfaceIInfoScreen {}<br />interfaceIAircraftModule {}<br />
  73. 73. But wedon‘t<br />express interface<br />requirements!<br />
  74. 74. Interface provision +<br />Interfacerequirement<br /> Dependencygraph<br />
  75. 75. Essentialfor<br />understanding<br />andtool-based<br />Analysis<br />
  76. 76. componentDelayCalculator {<br />providesIDelayCalculator<br />requiresIInfoScreen<br />}<br />componentInfoScreen {<br />providesIInfoScreen<br />}<br />componentAircraftModule {<br />providesIAircraftModule<br />requiresIDelayCalculator<br />}<br />interfaceIDelayCalculator {}<br />interfaceIInfoScreen {}<br />interfaceIAircraftModule {}<br />
  77. 77. Therearemany<br />InfoScreens andAircraftModules<br />
  78. 78. Components<br />needtobeinstantiated<br />
  79. 79. Instantiation:<br />veryimportant<br />conceptwhendefininglanguages<br />
  80. 80. componentInfoScreen {<br />providesIInfoScreen<br />}<br />instance screen1: InfoScreen<br />instance screen2: InfoScreen<br />…<br />
  81. 81. Componets (types)<br />arealreadycompatible<br />viatheirinterfaces.<br />
  82. 82. OneDelayCalculatortypicallytalkstomany InfoScreens<br />
  83. 83. Ports<br />
  84. 84. Port:<br />CommunicationEndpoint<br />
  85. 85. Port:<br />OwnedbyComponent<br />
  86. 86. Port:<br />Instantiatedalong<br />withComponent<br />
  87. 87. Port:<br />Can havecardinality<br />
  88. 88. componentDelayCalculator {<br />provides default: IDelayCalculator<br />requires screens[0..n]: IInfoScreen<br />}<br />componentInfoScreen {<br />provides default: IInfoScreen<br />}<br />componentAircraftModule {<br />provides default: IAircraftModule<br />requires calculator[1]: IDelayCalculator<br />}<br />
  89. 89. Weshould separate<br />portsand interfaces<br />byroles!<br />
  90. 90. componentDelayCalculator {<br />provides aircraft: IAircraftStatus<br />providesmanagementConsole: IManagementConsole<br />requires screens[0..n]: IInfoScreen<br />}<br />component Manager {<br />requires backend[1]: IManagementConsole<br />}<br />componentInfoScreen {<br />provides default: IInfoScreen<br />}<br />componentAircraftModule {<br />requires calculator[1]: IAircraftStatus<br />}<br />
  91. 91. Enrichmentof Language <br /> BetterApplicationArchitecture<br />
  92. 92. Howtoactuallyconnectinstances<br />andtheirports?<br />
  93. 93. Connectors<br />
  94. 94. Connector:<br />Connectstwoormoreportinstances<br />
  95. 95. componentDelayCalculator {<br /> requires screens[0..n]: IInfoScreen<br /> …<br />}<br />componentInfoScreen {<br />provides default: IInfoScreen<br />}<br />instance dc: DelayCalculator<br />instance screen1: InfoScreen<br />instance screen2: InfoScreen<br /> <br />connectdc.screens<br />to (screen1.default, screen2.default)<br />
  96. 96. How do westructure/organizetheoverallsystem?<br />
  97. 97. Namespaces<br />
  98. 98. namespacecom.mycompany {<br />namespace datacenter {<br />componentDelayCalculator {<br />provides aircraft: IAircraftStatus<br />providesmanagementConsole: IManagementConsole<br />requires screens[0..n]: IInfoScreen<br /> }<br />component Manager {<br />requires backend[1]: IManagementConsole<br /> }<br /> }<br />namespace mobile {<br />componentInfoScreen {<br />provides default: IInfoScreen<br /> }<br />componentAircraftModule {<br />requires calculator[1]: IAircraftStatus<br /> }<br /> }<br />} <br />
  99. 99. Systems are a separate viewpoint<br />
  100. 100. namespacecom.mycompany.test {<br />systemtestSystem {<br />instance dc: DelayCalculator<br />instance screen1: InfoScreen<br />instance screen2: InfoScreen<br />connectdc.screens<br />to (screen1.default, screen2.default)<br /> }<br />} <br />
  101. 101. Wedon‘tknowthe InfoScreens statically<br />whenthesystemisdesigned!<br />
  102. 102. Dynamic<br />Connectors<br />
  103. 103. Dynamic Connector:Discovers target(s) atruntimeusing a naming/trader/registryservice<br />
  104. 104. namespacecom.mycompany.production {<br />instance dc: DelayCalculator<br /> // InfoScreen instances are created and <br /> // started in other configurations <br />dynamicconnectdc.screensevery 60 query {<br /> type = IInfoScreen<br /> status = active<br /> }<br />} <br />
  105. 105. Dynamic Wiring<br />does not invalidate<br />theoverallapproach<br />
  106. 106. Similar Approach<br />canbeusedfor redundant connectors<br />
  107. 107. Registration<br />Properties forinstances<br />used in lookup<br />
  108. 108. namespacecom.mycompany.datacenter {<br />registeredinstance dc1: DelayCalculator {<br />parameters {role = primary}<br /> }<br />registeredinstance dc2: DelayCalculator {<br />parameters {role = backup}<br /> }<br />} <br />
  109. 109. Interfaces aren‘treallydefinedyet<br />
  110. 110. Interface:setofrelated<br />messages<br />
  111. 111. interfaceIInfoScreen {<br />messageexpectedAircraftArrivalUpdate (id: ID, time: Time)<br />messageflightCancelled(flightID: ID)<br /> …<br />} <br />
  112. 112. Data Structures<br />
  113. 113. typedef long ID<br />struct Time {<br /> hour: int<br /> min: int<br /> seconds: int<br />}<br />
  114. 114. Different kinds<br />ofmessages:<br />oneway, req/resp<br />
  115. 115. Message Interaction Patterns<br />
  116. 116. interfaceIAircraftStatus {<br />onewaymessagereportPosition<br /> (aircraft: ID, pos: Position )<br />request-replymessagereportProblem {<br />request (aircraft: ID, problem: Problem, <br /> comment: String)<br />reply (repairProcedure: ID) <br /> }<br />} <br />
  117. 117. Is itreally<br />Messages?<br />
  118. 118. ?<br />
  119. 119. Status Updates!<br />Flight Plans…!<br />
  120. 120. WrongAbstraction!<br />
  121. 121. Messages aretheimplementation,<br />notthearchitecturalintent.<br />
  122. 122. Data Replication<br />
  123. 123. Data Replication<br />Define Data<br />Updated byfew, readbymany<br />Full update, incremental update,invaldation…<br />
  124. 124. New architecturalabstractionisadded<br />tothelanguage<br />
  125. 125. structFlightInfo {<br /> from: Airport<br /> to: Airport<br /> scheduled: Time<br /> expected: Time<br /> …<br />}<br /> <br />replicatedsingleton flights {<br /> flights: FlightInfo[]<br />}<br /> <br />componentDelayCalculator {<br />publishes flights<br />}<br /> <br />componentInfoScreen {<br />consumes flights<br />}<br />
  126. 126. More Concise<br />
  127. 127. System derives<br />Messages for (full & partial) update, invalidation, etc.<br />
  128. 128. More specifics<br />
  129. 129. componentDelayCalculator {<br />publishes flights { publication = onchange }<br />}<br /> <br />componentInfoScreen {<br />consumes flights { init = all update = every(60) }<br />}<br />
  130. 130. We stillneedmessages. <br />Semantics?<br />
  131. 131. Pre- and Post-<br />Conditions<br />
  132. 132. interfaceIAircraftStatus {<br />onewaymessagereportPosition(aircraft: ID, pos: Position ) {<br />pre aircraft != null: “aircraft not specified”<br />pre pos != null: “position not specified”<br /> }<br />request-replymessagereportProblem {<br />request (aircraft: ID, problem: Problem, comment: String)<br />reply (repairProcedure: ID) <br />pre aircraft != null: “aircraft not specified”<br />pre problem != null: “problem not specified”<br />postrepairProcedure != null<br /> }<br />} <br />
  133. 133. Common Constraints: Shorter Syntax<br />
  134. 134. interfaceIAircraftStatus {<br />onewaymessagereportPosition(aircraft: ID!, pos: Position! ) <br />request-replymessagereportProblem {<br />request (aircraft: ID!, problem: Problem!, comment: String!)<br />reply (repairProcedure: !ID) <br /> }<br />} <br />
  135. 135. Message Sequences:<br />Protocol State Machines<br />
  136. 136. interfaceIAircraftStatus {<br />onewaymessageregisterAircraft(aircraft: ID! ) <br />onewaymessageunregisterAircraft(aircraft: ID! ) <br />onewaymessagereportPosition(aircraft: ID!, pos: Position! ) <br />request-replymessagereportProblem {<br />request (aircraft: ID!, problem: Problem!, comment: String!)<br />reply (repairProcedure: !ID) <br /> }<br />protocolinitial = new {<br />state new {<br />registerAircraft =&gt; registered<br /> }<br />state registered { <br />unregisterAircraft =&gt; new<br />reportPosition<br />reportProblem<br /> }<br /> }<br />} <br />
  137. 137. Invariantsfor Data Structures<br />
  138. 138. struct Time {<br /> hour: int<br /> min: int<br /> seconds: int<br />inv hour &gt;= 0 && hour &lt;= 23: “hour must be 0-23”<br />inv min &gt;= 0 && min &lt;= 59: “min must be 0-59”<br />inv seconds &gt;= 0 && seconds &lt;= 59: “seconds must be 0-59”<br />}<br />
  139. 139. Widelydistributed!Versioning?<br />
  140. 140. Mark upversionsofcomponents<br />(andotherstuff)<br />
  141. 141. componentDelayCalculator {<br />publishes flights { publication = onchange }<br />}<br />newImplOfcomponentDelayCalculator: DelayCalculatorV2<br />
  142. 142. componentDelayCalculator {<br />publishes flights { publication = onchange }<br />}<br />newVersionOfcomponentDelayCalculator: DelayCalculatorV3 {<br />publishes flights { publication = onchange }<br />providessomethingElse: ISomething<br />}<br />
  143. 143. TheEnd !<br />ofthe Story :-)<br />
  144. 144. None ofthosethingsisnew<br />orunique.<br />
  145. 145. But everything<br />isexpressedexplicitlyandconsistently, all in oneplace.<br />
  146. 146.
  147. 147. 2<br />TheoryandConcepts<br />
  148. 148. 2.1<br />TheoryandConcepts<br />Whatwedid in a Nutshell<br />
  149. 149. As you understand<br />anddevelopyour<br />Architecture…<br />
  150. 150. Develop a languageto express it!<br />
  151. 151. Language resemblesarchitecturalconcepts<br />
  152. 152. We express theapplication(s) withthelanguage.<br />
  153. 153. Architecture<br />DSL<br />
  154. 154.
  155. 155. 2.2<br />TheoryandConcepts<br />Domain SpecificLanguages<br />
  156. 156. Definition<br />
  157. 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.<br />
  158. 158. focussed<br />
  159. 159. processable<br />
  160. 160. language<br />
  161. 161. concern/viewpoint<br />
  162. 162. domain<br />
  163. 163. abstractions<br />
  164. 164. notation<br />
  165. 165. stakeholders<br />
  166. 166. Dimensions<br />
  167. 167. internal<br />vs.<br />external<br />
  168. 168. compiled<br />vs.<br />interpreted<br />
  169. 169. customization<br />vs.<br />configuration<br />
  170. 170. graphical<br />vs.<br />textual<br />
  171. 171. 2.3<br />TheoryandConcepts<br />The ImportanceofViewpoints<br />
  172. 172. viewpoint<br />A „perspective“ towardsthesystem<br />
  173. 173. Based on a slideby Steve Cook and IEEE 1471<br />
  174. 174. Type<br />Deployment<br />Composition<br />
  175. 175.
  176. 176.
  177. 177. 2.4<br />TheoryandConcepts<br />Benefits<br />
  178. 178. Clear Understanding<br />frombuildingthelanguage<br />
  179. 179. Unambigious<br />Vocabulary<br />
  180. 180. Conceptsindependent<br />from Technology<br />
  181. 181. Programming Model canbedefinedbased on ConceptualArcitecture<br />
  182. 182. Architecture„executable“<br />(i.e. morethanrulesanddocs)<br />
  183. 183.
  184. 184. 2.4<br />TheoryandConcepts<br />WhyTextual?<br />
  185. 185. 2.4<br />TheoryandConcepts<br />… or:why not graphical?<br />
  186. 186. Languagesand Editors<br />areeasiertobuild<br />
  187. 187. Languagesand Editors<br />areeasiertobuild<br />Evolve Language and simple editorasyou understand anddiscussthearchitecture, in real time!<br />
  188. 188. Integrateseasilywithcurrentinfrastructure:<br />CVS/SVN diff/merge<br />
  189. 189. Model evolutionistrivial, youcanalwaysusegrep.<br />adaptingexistingmodelsasthe DSL evolves<br />
  190. 190. Many Developers <br />prefertextualnotations<br />
  191. 191. When a graphical<br />notation<br />isbetter, youcanvisualize. <br />
  192. 192. Via M2M<br />Read-Only<br />Auto-Layout<br />Drill-Down<br />
  193. 193. Textual DSLs<br /> vs.<br /> Graphical<br /> vs.<br /> Visualization<br />
  194. 194. Graphviz<br />
  195. 195. Prefuse<br />
  196. 196. I am aware of the usefulness of graphical notations.<br />I am exaggerating here a little bit.<br />But: We’ve been building software with text only for a long time. We know it works.<br />
  197. 197.
  198. 198. 2.5<br />TheoryandConcepts<br />Tooling<br />
  199. 199. Severaltoolsavailable.<br />Example:oAWXtext<br />
  200. 200. SpecifyGrammar<br />
  201. 201. AntlrGrammarandParserisgeneratedfromthisspecification<br />
  202. 202. Generated Metamodel<br />
  203. 203. SpecifyConstraints<br />
  204. 204. Generated Editor<br />
  205. 205. Generated Editor<br />Code Completion<br />
  206. 206. Generated Editor<br />Syntax Coloring<br />Custom KeywordColoring<br />
  207. 207. Generated Editor<br />RealtimeConstraintValidation<br />
  208. 208. Generated Editor<br />Customizable<br />Outlines<br />
  209. 209. Generated Editor<br />Code Folding<br />
  210. 210. Generated Editor<br />Goto Definition <br />Find References<br />Cross-File References<br />Model as EMF<br />
  211. 211. Generated Editor<br />
  212. 212. XtextOverview<br />
  213. 213. GrapVizOverview<br />
  214. 214. GrapVizTrafo Code<br />
  215. 215. Another Tool…?<br />OSLO<br />
  216. 216. Another Tool…?<br />Jetbrains MPS<br />
  217. 217. Another Tool…?<br />
  218. 218.
  219. 219. 2.6<br />TheoryandConcepts<br />Model Validation<br />
  220. 220. Grammaris not<br />expressiveenough<br />
  221. 221. More Validation<br />Rules Required:Constraints<br />
  222. 222. Simple Examples:<br />Name-Uniqueness<br />Type Checks<br />Non-Nullness<br />
  223. 223. More ComplexExamples:<br />Version Compatibility<br />Overall completeness<br />Quality of Service<br />
  224. 224. context Interface ERROR&quot;interface names must start &quot;+ &quot;with a capital I&quot;:<br />name.startsWith(&quot;I&quot;);<br />context Component ERROR&quot;Qualified Name &quot;+qualifiedName()+&quot; must be unique&quot; :<br />allComponents(). select( c | c.qualifiedName() == qualifiedName() ) .size == 1;<br />context Attribute ERROR&quot;no type defined: &quot;+<br /> type.name:<br />visibleInstancesOfType(this, DataType) .contains(type); <br />context Connector ERROR&quot;target must be provided port&quot;:<br />ProvidedPort.isInstance( u);<br />
  225. 225. Precondition I:<br />AlgorithmforConstraint<br />
  226. 226. Precondition II:<br />All Data Available<br />
  227. 227.
  228. 228. 2.7<br />TheoryandConcepts<br />Generating Code<br />
  229. 229. Sincewealready<br />have a formal model….<br />
  230. 230. Generate API<br />MapsArchitecturalConceptsto<br />Implementationlanguage (non-trivial!)<br />
  231. 231. Implementation<br />Implementationonlydepends onthegeneratedprogramming model API<br />
  232. 232. Programming Model<br />Generated API + Usage Idioms<br />Completely Technology-Independent<br />
  233. 233. Runtime Infrastructure<br />Select based on fit wrt. toarchitectural<br />conceptsand non-functionalrequirements<br />
  234. 234. Glue Code<br />Aka Technology Mapping Code<br />Maps API toselectedplatform<br />
  235. 235. Glue Code<br />ContainsConfiguration Files forPlatform<br />Mightrequire „mix in models“<br />
  236. 236. SeveralPlatforms<br />Different Platforms, not Languages<br />Support forScaling (non-functionalreq)<br />Testing!<br />
  237. 237. Benefits:More EfficientImpl.<br />Technology Independent<br />Consistence/Quality<br />Architecture-Conformance<br />
  238. 238. Code Gen Sequence<br />1) Generate API<br />2) Write Impl Code<br />3) Select Platform<br />4) GenerateGlue Code<br />
  239. 239. Separate Models<br />forstuff relevant forthe API<br />vs. system/deploymentstuff<br />
  240. 240.
  241. 241. 2.8<br />TheoryandConcepts<br />Architecture Analysis Tools<br />
  242. 242. SoftwareTomographySonarJ<br />Structure 101<br />… andthelike<br />
  243. 243. How do youdescribe<br />Architecture?<br />
  244. 244. Constraint-Driven:<br />AssemblePackagesinto Components<br />Definelayers/columns<br />Defineand Check valid Dependencies<br />
  245. 245. You do not get a <br />waytodefineandexpress architectural<br />abstractionsbeyondthose!<br />
  246. 246. Dependency Analysis<br />Anti Pattern Detection<br />Metrics<br />[Trend Analysis]<br />[Visualization]<br />
  247. 247. Police Approach:<br />Detect Problems<br />After thefact!<br />
  248. 248. Anti Pattern Detection<br />Metrics<br />Usefulformanuallywrittenpartsofthesystem<br />
  249. 249. Dependency Analysis<br />Usefulformanuallywrittenpartsofthesystem<br />Constraintsgenerated<br />fromthe model.<br />
  250. 250.
  251. 251. 2.9<br />TheoryandConcepts<br />Standards,UML and ADLs<br />
  252. 252. FormalArchitecture Description is not new:<br /> ADLs, UML<br />
  253. 253. But allofthoseuseexisting, genericlanguages!<br />
  254. 254. Thismissesthepoint!<br />
  255. 255. Tryingto express yourspecificarchitecturewithpredefinedabstractionsis not useful!<br />
  256. 256. Youwanttobuild a languagetocaptureyourownarchitecturalabstractionsasyourlearnthings. <br />
  257. 257. Wherearestandardsuseful?<br />
  258. 258. Peoplehavetolearnarchitecturalconcepts anyway.<br />
  259. 259. Is UML with a profilestill a standardlanguage?<br />
  260. 260. On whichmetaleveldo I wanttostandardize?<br />M2 (UML), M3 (MOF)?<br />
  261. 261. Isn‘t a DSLbased on MOFas „standard“ as a profilebased on UML?<br />
  262. 262. UMLProfilesinstead?<br />You‘llthinkmoreabout UML-itiesthanyourownconcepts<br />
  263. 263. UMLProfilesinstead?<br />Tool integrationissues (repository, diff/merge, versioning)<br />
  264. 264. UMLProfilesinstead?<br />Tools areoftencomplex, heavyweight, bloated. Acceptance limited.<br />
  265. 265. UML Generally Useless?<br />No. UML canbeusedfordocu-mentation (sequencediagrams, eg)<br />
  266. 266. NB: Youcando all ofthiswith UML! <br />However, myexprienceshowsitismuchlessproductiveand agile.<br />Ifyouhave a UML-basedorganization, use UML.<br />
  267. 267.
  268. 268. 2.10<br />TheoryandConcepts<br />Why not use a 3GL?<br />
  269. 269. ArchitecturalAbstractionsarenotfirstclasscitizensin 3GLs<br />
  270. 270. Classescanrepresenteverything– especiallywithannotations (metadata) <br />
  271. 271. Problems:shoehorningintoclasses; like UML<br />
  272. 272. Problems:annotations = stereotypes<br />
  273. 273. Problems:limited analyzability(not a model)<br />
  274. 274. Problems:mix architecturalandimplementationconcerns<br />
  275. 275.
  276. 276. 2.11<br />TheoryandConcepts<br />My Notion of Components<br />
  277. 277. DefinitionsAbound:<br />A Building Block forsoftwaresystems<br />
  278. 278. DefinitionsAbound:<br />Something withexplicitcontextdependenciesonly<br />
  279. 279. DefinitionsAbound:<br />Something thatcontainsbusinesslogicandruns in a container<br />
  280. 280. My Understanding:<br />Smallestarchitecturally<br />relevant building block<br />
  281. 281. My Understanding:<br />Black Box - Architecturally<br />
  282. 282. My Understanding:<br />All architecturally relevant aspectsspecifieddeclaratively (model)<br />
  283. 283. My Understanding:<br />Analyzable, Composablebytools<br />
  284. 284. My Understanding:<br />Running in container, providestechnicalservicesatcomponentboundary<br />
  285. 285. The specificstructureandmetadataof a componentdefinedspecificallyforeachproject/system/ productline<br />
  286. 286. Thisiswhatwe do withthe …<br />Architecture<br />DSL<br />
  287. 287.
  288. 288. 2.12<br />TheoryandConcepts<br />ComponentImplementation<br />
  289. 289. By Default:<br />ManualyProgrammingagainsttheProgMod API<br />
  290. 290. Alternatives:<br />Generate, based on config<br />
  291. 291. Alternatives:<br />Generate, based on config<br />State Machines<br />
  292. 292. Alternatives:<br />Generate, based on config<br />State Machines<br />RuleLanguages + Engines<br />
  293. 293. Alternatives:<br />Generate, based on config<br />State Machines<br />RuleLanguages + Engines<br />Specific DSL <br />
  294. 294. Tointegratebehavior, createspecificabstractionsin thearchitecture DSL.<br />ADD THE CASCADING STUGGF HERE<br />
  295. 295. Note:<br />A lotofimplementationcanbegeneratedautomatically (noconfig) fromthe model<br />(persistence, serialization, …)<br />
  296. 296.
  297. 297. 2.13<br />TheoryandConcepts<br />The Roleof Patterns<br />
  298. 298. Pattern:<br />Proven solutions to recurring problems, including their applicability, trade-offs and consequences.<br />
  299. 299. Architecture Patterns:<br />“Blueprint” for a specific architectural style<br />
  300. 300. Architecture Patterns:<br />“Blueprint” for a specific architectural style<br /> Inspires the concepts for architecture DSL<br />
  301. 301. Design Patterns:<br />More concrete, moreimplementation-relatedthanarch. patterns<br />
  302. 302. Design Patterns:<br />More concrete, moreimplementation-relatedthanarch. patterns<br />Typicallydoes not end up in the DSL, but …<br />
  303. 303. Design Pattern:<br />More concrete, moreimplementation-relatedthanarch. patterns<br />putintothecodegenerator<br />
  304. 304. It‘s not thecodegeneratorwhodecidesabouttheimplementationof a pattern – it‘s still the (generator) developer!<br />A Pattern ismorethanthesolution UML diagram!<br />
  305. 305.
  306. 306. 2.14<br />TheoryandConcepts<br />Documentation<br />
  307. 307. The DSL andthe „programs“ aredocumentation.<br />
  308. 308. So I don‘thavetowrite…<br />… moredocs?<br />
  309. 309. Not quite.<br />
  310. 310. 1<br />
  311. 311. Grammaris a good formal definition, but not a teachingtool.<br />
  312. 312. Grammaris a good formal definition, but not a teachingtool.<br />Tutorials<br />
  313. 313. Tutorials:<br />ArchitecturalConcepts (Meta Model)<br />Howtousethelanguage<br />Howtousetheprogramming model<br /> (Howtogeneratecode)<br /> (Howtoaddmanualcode)<br />
  314. 314. Tutorials:<br />ArchitecturalConcepts (Meta Model)<br />Howtousethelanguage<br />Howtousetheprogramming model<br /> (Howtogeneratecode)<br /> (Howtoaddmanualcode)<br />ExampleDriven!<br />
  315. 315. 2<br />
  316. 316. Grammardescribeswhatthearchitecturelookslike.<br />
  317. 317. Grammardescribeswhatthearchitecturelookslike.<br />But: Whyisitthatway?<br />
  318. 318. Rationales<br />
  319. 319. Rationales<br />ConceptualArchitecture<br />RelatetoGrammar<br />
  320. 320. Rationales<br />ConceptualArchitecture<br />RelatetoGrammar<br />Technological Decisions<br />Non-Func. Req.<br />
  321. 321.
  322. 322. 2.15<br />TheoryandConcepts<br />ExpressingVariability<br />
  323. 323. Different Variants<br />ofthe System<br />for different customers.<br />
  324. 324. How do I <br />express<br />this in themodels?<br />
  325. 325. Negative Variability:<br />Conditionallytakingsomethingaway<br />
  326. 326. Negative Variability:<br />Conditionallytakingsomethingaway<br />Feature Models<br />
  327. 327.
  328. 328. componentDelayCalculator {<br />provides default: IDelayCalculator<br />requires screens[0..n]: IInfoScreen<br />providesmon: IMonitoringfeature monitoring<br />}<br />
  329. 329. componentDelayCalculator {<br />provides default: IDelayCalculator<br />requires screens[0..n]: IInfoScreen<br />providesmon: IMonitoringfeature monitoring<br />}<br />
  330. 330. namespacemonitoringStufffeature monitoring {<br /> <br />componentMonitoringConsole {<br />requires devices:[*]: IMonitor<br /> }<br />instance monitor: MonitoringConsole<br />dynamicconnectmonitor.devicesquery {<br /> type = IMonitor<br /> }<br /> <br />}<br />
  331. 331.
  332. 332. Positive Variability:Conditionallyaddingsomethingto a minimal core<br />
  333. 333. Positive Variability:Conditionallyaddingsomethingto a minimal core<br />Aspects<br />
  334. 334. namespacemonitoring {<br /> <br />componentMonitoringConsole …<br />instance monitor: …<br />dynamicconnectmonitor.devices …<br /> <br />aspect (*) component {<br />providesmon: IMonitoring<br /> }<br />}<br />
  335. 335. componentDelayCalculator {<br /> …<br />}<br />componentAircraftModule {<br /> …<br />}<br />componentInfoScreen {<br /> …<br />}<br />
  336. 336. componentDelayCalculator {<br /> …<br />}<br />componentAircraftModule {<br /> …<br />}<br />componentInfoScreen {<br /> …<br />}<br />componentDelayCalculator {<br /> …<br />providesmon: IMonitoring<br />}<br />componentAircraftModule {<br /> …<br />providesmon: IMonitoring<br />}<br />componentInfoScreen {<br /> …<br />providesmon: IMmonitoring<br />}<br />aspect (*) component {<br />providesmon: IMonitoring<br /> }<br />
  337. 337. Weaver isgeneric:<br />workswith all (container)<br />model elements<br />
  338. 338. aspect (*) &lt;type&gt;<br /> all instancesoftype <br />aspect (tag=bla)&lt;type&gt;<br /> all instanceswith tag bla<br />aspect (name=S*) &lt;type&gt;<br />all instanceswhosenamestartswith S<br />
  339. 339. AO + Features<br />namespacemonitoring feature monitoring {<br /> <br />componentMonitoringConsole …<br />instance monitor: …<br />dynamicconnectmonitor.devices …<br /> <br />aspect (*) component {<br />providesmon: IMonitoring<br /> }<br />}<br />
  340. 340.
  341. 341. 2.16<br />TheoryandConcepts<br />PLE – Big Picture<br />
  342. 342. Configuration<br />vs. Customization<br />
  343. 343. Customization<br />vs. Configuration<br />
  344. 344. Customization<br />vs. Configuration<br />
  345. 345. MDSD - Thumbnail<br />
  346. 346. MD-PLE - Thumbnail<br />fewer!<br />
  347. 347. MD-PLE: Models<br />
  348. 348. MD-PLE – Thumbnail II<br />moreoptions<br />
  349. 349. Variability in theprocesschain<br />Transformation AO (oAW)<br />
  350. 350. Variability in theprocesschain<br />Generator AO (oAW)<br />
  351. 351.
  352. 352. 2.17<br />TheoryandConcepts<br />Process<br />
  353. 353. Iterate!<br />
  354. 354. Iterate!<br />Concepts<br />
  355. 355. Iterate!<br />Concepts<br />GrammarConstraints<br />
  356. 356. Iterate!<br />Examples<br />Concepts<br />GrammarConstraints<br />
  357. 357. Iterate!<br />Generator<br />Examples<br />Concepts<br />GrammarConstraints<br />
  358. 358. Iterate!<br />Generator<br />Code Completion, etc.<br />Examples<br />Concepts<br />GrammarConstraints<br />
  359. 359. Reviews<br />still necessary!<br />
  360. 360. Reviews<br />still necessary!<br /> but simplified, becausearchitectureismore explicit<br />
  361. 361. Architect<br />(Team)<br />ArchitecturalConcepts<br />Grammar, Constraints<br />Examples<br />Programming Model<br />
  362. 362. Tool<br />Engineer<br />Editor Customization<br />(API) Code Generator<br />
  363. 363. Platform<br />Expert<br />Glue Code Generator<br />
  364. 364. Application<br />Developer<br />Uses Language<br />Generates Code<br />Writes Manual Code against gen. API Code<br />
  365. 365. New <br />language<br />foreach<br />system?<br />
  366. 366. Common<br />Base?<br />
  367. 367. Reusable<br />Language<br />Modules?<br />
  368. 368. LanguageFamily?PLE?<br />
  369. 369. AnotherTalk!<br />
  370. 370.
  371. 371. 2.18<br />TheoryandConcepts<br />Underlying Concepts<br />
  372. 372. Abstraction<br />
  373. 373. Formalize<br />
  374. 374. LimitFreedom<br />
  375. 375. Declaration<br />Implementation<br />
  376. 376. Notation<br />
  377. 377. Types & Instances<br />
  378. 378. Viewpoints<br />
  379. 379. Hierarchical<br />Decomposition<br />
  380. 380. Translate<br />
  381. 381. Handle<br />Crosscuts<br />
  382. 382. Go Meta<br />
  383. 383. Reflection<br />
  384. 384. Automate<br />
  385. 385. Orthogonality<br />
  386. 386. Contracts<br />
  387. 387. IsolateTechnology<br />
  388. 388. Don‘t<br />Overspecify<br />
  389. 389. Make Explicit<br />
  390. 390. Platforms<br />
  391. 391.
  392. 392. THE END.<br />Thankyou.<br />Questions?<br />

×