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

3.  Context

4. Architecture is often non tangible or technology specific

5. ArchitectureDSL

6. As you understand and develop your Architecture…

7. Develop a language to express it!

8. Language resembles architectural concepts

9. We express the application(s) with the language.

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 are easy to build.

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

13. component DelayCalculator { provides IDelayCalculator requires IInfoScreen } component InfoScreen { provides IInfoScreen } component AircraftModule { provides IAircraftModule requires IDelayCalculator } interface IDelayCalculator {} interface IInfoScreen {} interface IAircraftModule {}

14. component DelayCalculator { requires screens[0..n]: IInfoScreen … } component InfoScreen { provides default: IInfoScreen } instance dc: DelayCalculator instance screen1: InfoScreen instance screen2: InfoScreen connect dc.screens to (screen1.default, screen2.default)

15. interface IAircraftStatus { oneway message reportPosition (aircraft: ID, pos: Position ) request-reply message reportProblem { request (aircraft: ID, problem: Problem, comment: String) reply (repairProcedure: ID) }

16. struct FlightInfo { from: Airport to: Airport scheduled: Time expected: Time … } replicated singleton flights { flights: FlightInfo[] } component DelayCalculator { publishes flights } component InfoScreen { consumes flights }

17. interface IAircraftStatus { oneway message registerAircraft(aircraft: ID! ) oneway message unregisterAircraft(aircraft: ID! ) oneway message reportPosition(aircraft: ID!, pos: Position! ) request-reply message reportProblem { request (aircraft: ID!, problem: Problem!, comment: String!) reply (repairProcedure: !ID) } protocol initial = new { state new { registerAircraft => registered } state registered { unregisterAircraft => new reportPosition reportProblem }

18. When a graphical notation is better, you can visualize.

19. Graphviz

20. Via M2M Read-OnlyAuto-LayoutDrill-Down

21. Textual DSLs vs. vs. Graphical Graphical vs. vs. Visualization Visualization

22. I‘ve done real project work this way!

23. Currently in use with four of my customers

25.  Challenge

26. Newlanguage for each system?

27. CommonBase?

28. ReusableLanguageModules?

29. Language Family? PLE?

31.  Solution Approach

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

33. Define syntax

34. Use PLE to configure custom DSL

35. Components Hierarchical, Stateless/ful, Persistent, Threadsafe, Parameters, Runtime Instantiation, 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 Built with Eclipse oAW Xtext

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

44. Select Features for your language variant

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

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”

52. Same approach used for other artifacts (constraints, editor customization, etc.)

53. You’ll have to read the paper for details You’ll have to read the paper for details

54. THE END. Thank you. Questions?