Search

Architecture As Language

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    1 Favorite

    Architecture As Language - Presentation Transcript

    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?
    SlideShare Zeitgeist 2009

    + Markus VoelterMarkus Voelter Nominate

    custom

    206 views, 1 favs, 0 embeds more stats

    Software Architecture is often either imprecise and more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 206
      • 206 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 0
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved