1. Architecture As Language Andreas Graf MarkusVoelter www.itemis.degraf@itemis.de www.voelter.devoelter@acm.org

3. About

5. 1 What is a language?

6. INFORMAL Set of well-definedterms

7. INFORMAL Stakeholders agree on meaning

8. FORMAL Metamodel

9. FORMAL Metamodel Grammar

10. FORMAL Metamodel Grammar Notation

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

13. 2 Architecture DSLs

14. Architecture DSL

15. As you understand anddevelopyour Architecture…

16. Develop a languageto express it!

17. Language resemblesarchitecturalconcepts

18. We express theapplication(s) withthelanguage.

19. DEMO I An architectural DSL for embedded systems

21. 3 Benefits

22. Clear Understanding frombuildingthelanguage

23. Unambigious Vocabulary

24. Conceptsindependent from Technology

25. Programming Model canbedefinedbased on ConceptualArcitecture

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

28. 4 Why Textual?

29. 4 … or:why not graphical?

30. Languagesand Editors areeasiertobuild

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

32. Integrateseasilywithcurrentinfrastructure: CVS/SVN diff/merge

33. Model evolutionistrivial, youcanalwaysusegrep. adaptingexistingmodelsasthe DSL evolves

34. Many Developers prefertextualnotations

35. When a graphical notation isbetter, youcanvisualize.

37. 5 Tooling

38. Severaltoolsavailable. Example:oAWXtext

39. SpecifyGrammar

40. AntlrGrammarandParserisgeneratedfromthisspecification

41. Generated Metamodel

42. SpecifyConstraints

43. Generated Editor

44. DEMO II The language-aware editor for our DSL

46. 6 Generating Code

47. Sincewealready have a formal model….

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

49. Implementation Implementationonlydepends onthegeneratedprogramming model API

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

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

52. Glue Code Aka Technology Mapping Code Maps API toselectedplatform

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

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

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

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

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

58. DEMO III Generating C for the target device

60. 7 Expressing Variability

61. Different Variants ofthe System for different customers.

62. How do I express this in themodels?

63. Negative Variability: Conditionallytakingsomethingaway

64. Negative Variability: Conditionallytakingsomethingaway Feature Models

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

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

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

70. Positive Variability:Conditionallyaddingsomethingto a minimal core

71. Positive Variability:Conditionallyaddingsomethingto a minimal core Aspects

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

73. componentDelayCalculator { … } componentAircraftModule { … } componentInfoScreen { … }

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

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

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

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

78. DEMO III Adding Variability and connectivity to a feature model to the previous DSL

80. Based on actualpracticalexperience

81. Currently in usewithfourofmycustomers

82. Benchmarkedby suitabilityforuse in today‘sprojects

84. THE END. Thankyou. Questions?