A Family of Languages for Architecture Description

1. A Family of Languages for Architecture Description DSM’08 @ OOPSLA 2008 Markus Voelter(voelter@acm.org, www.voelter.de)

3.  Context

4. Architecture is often non tangible or technology specific

5. Architecture DSL

6. As you understand anddevelopyour Architecture…

7. Develop a languageto express it!

8. Language resemblesarchitecturalconcepts

9. We express theapplication(s) withthelanguage.

10. Textual Syntax: We know how this works from our experience with code.

11. Textual Syntax: We know how this works from our experience with code. Editors areeasy to build.

12. Textual Syntax: We know how this works from our experience with code. Editors areeasy to build. Integrates well with existing Version Control Systems etc.

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

14. 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)

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

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

17. 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 } } }

18. When a graphical notation isbetter, youcanvisualize.

19. Graphviz

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

21. Textual DSLs vs. Graphical vs. Visualization

22. I‘vedone real project workthisway!

23. Currently in usewithfourofmycustomers

25.  Challenge

26. New language foreach system?

27. Common Base?

28. Reusable Language Modules?

29. LanguageFamily?PLE?

31.  Solution Approach

32. Identify common, reusable architectural abstractions(Experience, Patterns)

33. Define syntax

34. Use PLE to configurecustom DSL

35. ComponentsHierarchical, Stateless/ful, Persistent, Threadsafe, Parameters, RuntimeInstantiation, Active

36. Interfaces RPC, Messaging,Async, Pub/Sub, Exceptions, Data Types, DBC, Protocol State Machines

37. Ports • Uni/Bidirectional, Caridinalities, Optional/Required

38. Connectors • Static, Dynamic, Lookup, • Failover, Backup, Multi

39. Data Replication • Realtime, On Demand, 1..1, 1..n

41.  Solution Tooling

42. DSL Editors BuiltwithEclipseoAWXtext

43. Variability is expressed as a feature model in pure::variants

44. Select Features for your language variant

45. Results in a DSL incl. fancy editor (code completion, constraint checks, outline, folding, cross-file nav)

46. Customization: Add you own specific Language elements (beyond what the configuration supports)

48.  Tool Implementation

49. Grammar Elements connected to feature models

50. Joinpoints to which more grammar can be “advised”