Presentation of the paper at FOAL 2014.

1. Specification of Domain-
Specific Languages Based on
Concern Interfaces
Matthias Schöttle, Omar Alam, Jörg Kienzle and Gunter
Mussbacher

2. 2
Software Engineer
Domain-Specific Engineer
I'd fix healthcare.gov myself
but i don't write code

3. Software requirements High level goals
Support for
trade-off analysis
3
Many reusable
solutions

4. 4
We introduced a new unit of reuse called concernthat allows model reuse
and exposes a variation of choices and their impact on high level goals and properties
concern

5. A concern groups related models
serving the same purpose, and
provides three interfaces to
facilitate reuse.
Customization
Usage Interface
Variation Interface
5

6. Variation Interface
6
Increase
performance
Increase
access
performance
Increase
insertion/deletion
performance
ArrayList
FIFO Queue
(Linked List)
HashSetLinkedHashMap
Database
10050 50
50
1
100
100
50 50
TreeSet
85
Increase
performance
Minimize
message
exchanges
Minimize
memory usage
aspect Association.Ordered
structural view
|Data
|Associated
0..*
+ add(|Associated a)
+ add(int index, |Associated a)
....
int size
|Data
|Associated
~ create()
~ add(|Associated a)
~ add(int i, |Associated a)
...
int size
Sequence
|Associated
mySeq 1
Association
WithKeyOrdered Unordered
alternative (XOR)
structural view
1
myLink 0..*+ * |forwardingMethod(..)
+ |Link getAssociated()
|Data
aspect Association
|Associated
~ * |targetMethod(..)
|Link
|Data
|Link
|Associated
|forwardingMethod
|targetMethod
aspect Map extends Association
structural view
|Data
|Key
|Value
1
myMap
1+ add(|Key key, |Value val)
+ remove(|Key key)
+ Set<|Keys> getKeys()
+ |Value getValue(|Key k)
|Data
|Value
<<Java>>
Map
|Key
Instantiations:
Association: |Data → |Data; |Associated → |Value; |Link → Map; |add → |add; |remove → |remove
structural view
aspect ZeroToMany extends Association realizes Unordered
|Data
|Associated
1
mySet 0..*
+ add(|Associated a)
+ remove(|Associated a)
+ Set<|Associated> getAssociated()
+ boolean contains(|Associated)
|Data
|Associated
~ Set create()
~ add(|Associated )
~ boolean remove(|Associated)
~ boolean contains(|Associated)
int size
Set
|Associated

7. Reusable Aspect Models (RAM)
Customization Interface
Usage Interface
specifies the design structure and behaviour that the unit
provides to the rest of the application
specifies how to adapt the reusable unit to be
application-specific
7
aspect Association.Ordered
structural view
|Data
|Associated
0..*
+ add(|Associated a)
+ add(int index, |Associated a)
....
int size
|Data
|Associated
~ create()
~ add(|Associated a)
~ add(int i, |Associated a)
...
int size
Sequence
mySeq
1

8. 8
Concern-Reuse Process
1- Use the variation interface to select the most appropriate features.
This generates the detailed design of the selected features.
2- Use the customization interface to customize the models of the
selected features for application-specific needs.
3- Use the customized concern according to its usage interface.
Observer reuses Association<Unordered reexpose TreeSet, HashSet>
|Data → |Subject; |Associated → |Observer; getAssociated → getObservers!
Subject.getObservers(), Observer.startObserving

9. 9
Concern-Reuse Process
2- Use the customized concern according to its usage interface.
Subject.getObservers(), Observer.startObserving
Push ActivePull
Figure 4. Observer Feature Mo
aspect Observer
structural view
~ Set<|Observer> getObservers()
+ * |modify(..)
~ * |getData()
|Subject
+ startObserving(|Subject)
+ stopObserving()
~ |update(*)
|ObservermySubject
0..1
|Subject<|modify<IgetData, |update>>
|Observer<|update>
<<ordered>>
0..*
Figure 5. RAM Customization and Usage Interface for Push Ob-
server
<<push(Stock.getPrice, StockWindow.refresh)>>
+ setPrice(int price)
Stock
- int price
+ refresh(int newPrice)
StockWindow
aspect O
structural
|Subjec
+ * |upda
|C
<<ordere
<<ordered>>
1-Apply tags to indicate reuse

10. 10
Domain-Specific Languages (DSL) emerged to make
modelling more accessible to domain experts who are not
familiar with software engineering techniques.

11. 11
Association
DatabaseWithKeyOrdered Unordered
alternative (XOR)
Event Participant
0..*
<<ordered>> participants
Examples of Specifying DSL Based on Concern Interfaces
because the feature model identifies the key concepts of the concern,
and hence the domain-specific language!
However, the specification of a list of tags by itself does not yet
sufficiently define a DSL, because the list only specifies the con-
crete syntax of the DSL, but not its semantics. One way to specify
the semantics is to express the tag in an already existing notation,
e.g., by means of a transformation to another notation. The specifi-
cation language for DSLs proposed in this paper does exactly that:
it provides a way to specify how a tag is to be translated into a fea-
ture model configuration and composition specification based on
the variation and customization interface of the concern. For exam-
ple, the specification of the semantics of the <<ordered>> tag is
as follows:
( 1 ) <<ordered >> = A s s o c i a t i o n ( Ordered ) ;
( 2 ) f o r AssociationEnd a ;
( 3 ) compose | Data ! a . getType ( ) ;
| Associated ! a . myClass ;
The first line defines the name of the tag as well as the fea-
ture selection of the concern. The second line specifies to which
type of modeling element the tag may be applied (e.g., the class
AssociationEnd from the RAM metamodel). This line also de-
fines a variable for the model element to which the tag may be
applied, which is then used for the rest of the specification. Line
(3) specifies the desired binding of elements in the customiza-
tion interface of the concern (i.e., |Data and |Associated in
the case of the Association concern) and application model ele-
ments. The application model elements are identified with the help
aspect Association.Ordered
structural view
|Data
|Associated
0..*
+ add(|Associated a)
+ add(int index, |Associated a)
....
int size
|Data
|Associated
~ create()
~ add(|Associated a)
~ add(int i, |Associated a)
...
int size
Sequence
|Associated
mySeq 1
Event Participant
0..*
participants
Registration System reuses Association<Ordered>!
|Data → |Subject; |Associated → Participant!

12. 12
Examples of Specifying DSL Based on Concern Interfaces
optional
Observer
Push Active PassivePull
ControllerNotification
Method
Concurrent
Update
mandatory
alternative (XOR)
Figure 5. RAM Customization and Usage Interface for Push Ob-
server
<<push(Stock.getPrice, StockWindow.refresh)>>
+ setPrice(int price)
+ int getPrice()
Stock
- int price
+ refresh(int newPrice)
StockWindow
Figure 6. Simple Stock Application
~ Set<StockWindow> getObservers()
+ setPrice(int price)
+ int getPrice()
- int price
Stock
+ startObserving(Stock stock)
+ stopObserving()
+ refresh(int newPrice)
StockWindowmySubject
0..1
<<ordered>>
0..*
Figure 7. Simple Stock Application with Observer Concern
help of the controller. Similar to push and pull, the customization
interface is the same for the active and passive approaches, even
though the behavior is quite different.
While it is possible to define an <<activePush>> tag, this case
is not interesting. Such a tag would define everthing needed for the
variant of the Observer concern with the Push and Active features
selected, but this is not any different than defining any other fea-
ture by itself from scratch. Therefore, we focus on how to combine
|Subject<|modify<
|Controll
+ * |updateControll
|Controller
<<ordered>> 0..*
Figure 8. Interface
only one tag needs t
straints of the featu
between the feature
differences of the tr
If the Active feat
Controller class m
the class StockCon
Fig. 6 must be exten
.refresh)>>. The sp
( 1 ) << a c t i v e ( Ope
( 2 ) f o r Operation
( 3 ) when m. Annota
m. Annotation!
( 4 ) compose | u p d a
| C o n t r o l l e r !
Note how the c
<<push>> or <<p
gether with either th
aspect Observer
structural view
~ Set<|Observer> getObservers()
+ * |modify(..)
~ * |getData()
|Subject
+ startObserving(|Subject)
+ stopObserving()
~ |update(*)
|ObservermySubject
0..1
|Subject<|modify<IgetData, |update>>
|Observer<|update>
<<ordered>>
0..*
+ setPrice(int price)
+ int getPrice()
Stock
- int price
+ refresh(int newPrice)
StockWindow
e list only specifies the con-
mantics. One way to specify
an already existing notation,
another notation. The specifi-
this paper does exactly that:
is to be translated into a fea-
sition specification based on
ace of the concern. For exam-
s of the <<ordered>> tag is
dered ) ;
the tag as well as the fea-
cond line specifies to which
ay be applied (e.g., the class
etamodel). This line also de-
nt to which the tag may be
est of the specification. Line
elements in the customiza-
Data and |Associated in
and application model ele-
ts are identified with the help
age) [12] expression, starting
. In the RAM metamodel, an
source class of the directed
hich can be found by calling
ciationEnd has as its class
iation (i.e., Participant in
s attribute. Note that the num-
ation interface of the concern
n specifications in line (3).
ch for the specification of a
be composed with application classes and methods, respectively.
Fig. 5 shows the customization and usage interfaces of the Push
Observer. Note that the only difference to the Pull Observer is
that the usage interface contains update() instead of update(*),
because data is not immediately pushed.
Assuming a stock application with a Stock and StockWindow
class as shown in Fig. 6, the Push Observer may be applied to the
application by tagging the setPrice method with <<push(Stock.get-
Price, StockWindow.refresh)>>. The result of the composition of
the Observer concern with the stock application is shown in Fig. 7.
The main difference between the Association example and the
Observer example is the fact that the composition of the Observer
concern with the stock application requires three methods to be
applied in a coordinated fashion. For each specific modify method,
there exist specific getData and update methods that need to
work with the modify method. The tag hence needs to identify
these related methods in addition to the model element that is
identified simply by the fact that the tag is applied to it. The
additional elements are identified with the help of parameters.The
specification of the <<push>> tag is hence as follows:
( 1 ) <<push ( Operation d , Operation u)>>
= Observer ( Push ) ;
( 2 ) f o r Operation m;
( 3 ) when m. C l a s s i f i e r = d . C l a s s i f i e r ;
( 4 ) compose | modify ! m; | Sub ject ! m. C l a s s i f i e r ;
| getData ! d ; | update ! u ;
| Observer ! u . C l a s s i f i e r ;
Line (1) now defines parameters in addition to the tag. The pa-
rameters are then used in line (4) for the composition specifica-
tions. Therefore, getPrice is composed with getData (i.e., d) and
refresh with update (i.e., u). The specification of the <<push>>
tag also defines a constraint in line (3) that needs to be satisfied for
the composition to occur. In this case, the getData method (i.e., d)
must be in the same class as the modify method (i.e., m).
Stock Exchange reuses Observer<Push>!
|Data → |Stock; |Observer → StockWindow; !
|modify → setPrice; |getData → getPrice;
|update → refresh!

13. 13
Examples of Specifying DSL Based on Concern Interfaces>
+ refresh(int newPrice)
StockWindow
ck Application
+ startObserving(Stock stock)
+ stopObserving()
+ refresh(int newPrice)
StockWindowect
ed>>
0..*
on with Observer Concern
h and pull, the customization
nd passive approaches, even
<activePush>> tag, this case
efine everthing needed for the
the Push and Active features
than defining any other fea-
we focus on how to combine
ng a tag <<active>>, which
g <<push>>. Consequently,
+* |modify(..)
~* |getData()
~ |update(*)
|Observer
+ * |updateController(*)
|Controller
<<ordered>> 0..*<<ordered>> 0..*
Figure 8. Interface (cust. + usage) for Observer(Push,Controller)
only one tag needs to be defined per feature. Furthermore, the con-
straints of the feature model help avoid undersirable interactions
between the features, allowing us to incrementally define the delta
differences of the transformation rules.
If the Active feature is selected in addition to the Push feature, a
Controller class must be defined for the stock application (e.g.,
the class StockController is added to Fig. 6), and the tag in
Fig. 6 must be extended by appending + <<active(StockController
.refresh)>>. The specification of the <<active>> tag is as follows:
( 1 ) << a c t i v e ( Operation u2)>> = Observer ( Active ) ;
( 2 ) f o r Operation m;
( 3 ) when m. Annotation! e x i s t s ( a | a . name= ’ push ’ ) or
m. Annotation! e x i s t s ( a | a . name= ’ pull ’ ) ;
( 4 ) compose | u p d a t e C o n t r o l l e r ! u2 ;
| C o n t r o l l e r ! u2 . C l a s s i f i e r ;
Note how the constraint in line (3) enforces that either the
<<push>> or <<pull>> tag is applied to the same element. To-
gether with either the <<push>> or <<pull>> tag, the <<active>>
tag defines all composition specifiations required to apply the Ob-
server concern.
optional
Observer
Push Active PassivePull
ControllerNotification
Method
Concurrent
Update
mandatory
alternative (XOR)
<<push(Stock.getPrice, StockWindow.refresh)>>
+ <<active(Controller.refresh)>>
+ setPrice(int price)
+ getPrice() : int
Stock
- price : int
+ refresh() : void
Controller
+ refresh() : void
StockWindow
aspect ObserverWithController
structural view
+* |modify(..)
~* |getData()
|Subject
~ |update(*)
|Observer
|Subject<|modify<IupdateController<|getData>, |update<|getData>>>
|Controller<|updateController>, |Observer<|update>
+ * |updateController(*)
|Controller
<<ordered>> 0..*<<ordered>> 0..*
+ setPrice(int price)
+ getPrice() : int
Stock
- price : int
+ refresh() : void
Controller
+ refresh() : void
StockWindow
Stock Exchange reuses Observer<Push,Active>!
|Data → |Stock; |Observer → StockWindow; |Controller → Controller!
|modify → setPrice; |getData → getPrice;
|update → refresh; |upateController → Controller.refresh!

14. 14
DSL for Concerns
specification language for DSLs for a concern may be formally de-
fined as shown below. This, of course, is only one possible example
of a DSL. However, we argue that the three interfaces are essential
as the variation interface exposes the semantic differences between
various features of the concern, the customization interface high-
lights composition requirements, and the usage interface defines
the detailed capabilities of the concern.
<DSL> : : = <tag > ("+" <tag >)*
<tag > : : = "<<" <tag_name > [ " ( " < p a r a m e t e r _ l i s t > " ) " ]
">> = " <concern > " ( " < f e a t u r e _ l i s t > " ) ; "
f o r <element_type > <variable_name > " ; "
[ " when" ( < OCL_expression > " ; " ) + ]
" compose " ( < c u s t o m i z a t i o n _ i n t e r f a c e _ e l e m e n t >
"!" <OCL_expression > " ; " ) +
Terminals are shown in quotes. The detailed specification of
the nonterminals such as <tag_name> are omitted as the names of
the nonterminals are self-explanatory. Also note that it is possible
to replace <feature_list> with <feature_configuration> if such a
concept exists in the feature model notation used for the concern.
Furthermore, it is possible that the same tag is to be applied to
different types of modeling elements, even though all examples
in this paper only required the tag to be applied to one type of
modeling element. In this case, a second specification for the tag

15. 15
Future Work
Increase
performance
Increase
access
performance
Increase
insertion/deletion
performance
ArrayList
FIFO Queue
(Linked List)
HashSetLinkedHashMap
Database
10050 50
50
1
100
100
50 50
TreeSet
85
Association
WithKeyOrdered Unordered
alternative (XOR)
Use impact model..
Highly performant Association.Ordered?

16. 16
concern DSL
Association
DatabaseWithKeyOrdered Unordered
alternative (XOR)
Event Participant
0..*
<<ordered>> participants
In the figure, the association is tagged with <
dicate the desired configuration of the feature mod
tion concern. If a different feature configuration i
<<unordered>>, <<withKey>>, or <<persisted>>
the features Unordered, WithKey, and Database, r
case of the Association concern, there is clearly a
spondence between features and tags in the DSL
because the feature model identifies the key conce
and hence the domain-specific language!
However, the specification of a list of tags by
sufficiently define a DSL, because the list only
crete syntax of the DSL, but not its semantics. O
the semantics is to express the tag in an already
e.g., by means of a transformation to another not
cation language for DSLs proposed in this paper
it provides a way to specify how a tag is to be tra
ture model configuration and composition spec
the variation and customization interface of the c
ple, the specification of the semantics of the <<
as follows:
( 1 ) <<ordered >> = A s s o c i a t i o n ( Ordered ) ;
( 2 ) f o r AssociationEnd a ;
( 3 ) compose | Data ! a . getType ( ) ;
| Associated ! a . myClass ;
The first line defines the name of the tag as
ture selection of the concern. The second line s