A Family of Languages for Architecture Description OOPSLA 2008 Markus Voelter

 Context

Architecture is often non tangible or technology specific

ArchitectureDSL

As you understand and develop your Architecture…

Develop a language to express it!

Language resembles architectural concepts

We express the application(s) with the language.

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

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

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.

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

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)

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

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

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 }

When a graphical notation is better, you can visualize.

Graphviz

Via M2M Read-OnlyAuto-LayoutDrill-Down

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

I‘ve done real project work this way!

Currently in use with four of my customers

 Challenge

Newlanguage for each system?

CommonBase?

ReusableLanguageModules?

Language Family? PLE?

 Solution Approach

Identify common, reusable architectural abstractions (Experience, Patterns)

Define syntax

Use PLE to configure custom DSL

Components Hierarchical, Stateless/ful, Persistent, Threadsafe, Parameters, Runtime Instantiation, Active

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

Ports Uni/Bidirectional, Caridinalities, Optional/Required

Connectors Static, Dynamic, Lookup, Failover, Backup, Multi

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

 Solution Tooling

DSL Editors Built with Eclipse oAW Xtext

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

Select Features for your language variant

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

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

 Tool Implementation

Grammar Elements connected to feature models

Joinpoints to which more grammar can be “advised”

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

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

THE END. Thank you. Questions?