A Family of Languages for Architecture Description

DSM’08 @ OOPSLA 2008

Markus Voelter(voelter@acm.org, www.voelter.de)

Context

Architecture is often

non tangible or technology specific

Architecture

DSL

As you understandand develop

yourArchitecture…

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: DelayCalculatorinstance screen1: InfoScreeninstance 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 M2MRead-OnlyAuto-LayoutDrill-Down

Textual DSLs vs. Graphical vs. Visualization

I‘ve done real projectwork this way!

Currently in use with four of my customers

Challenge

New languagefor eachsystem?

CommonBase?

ReusableLanguageModules?

LanguageFamily?PLE?

Solution Approach

Identify common, reusable architectural

abstractions(Experience, Patterns)

Define syntax

Use PLE to configure custom DSL

ComponentsHierarchical, Stateless/ful,

Persistent, Threadsafe, Parameters,Runtime Instantiation, Active

InterfacesRPC, Messaging, Async, Pub/Sub,

Exceptions, Data Types, DBC,Protocol State Machines

PortsUni/Bidirectional,

Caridinalities, Optional/Required

ConnectorsStatic, Dynamic, Lookup,Failover, Backup, Multi

Data Replication

Realtime, On Demand,

1..1, 1..n

Solution Tooling

DSL Editors Built withEclipse 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 specificLanguage elements(beyond what the

configuration supports)

Tool

Implementation

Grammar Elements

connected to feature

models

Joinpoints to which

more grammar

can be “advised”

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

THE END.Thank you.

Questions?