a family of languages for architecture description dsm’08 @ oopsla 2008 markus voelter...
TRANSCRIPT
A Family of Languages for Architecture Description
DSM’08 @ OOPSLA 2008
Markus Voelter([email protected], 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?