Specification of Domain-Specific Languages Based on Concern Interfaces

Specification of Domain-Specific Languages Based on

Concern Interfaces

Matthias Schöttle, Omar Alam, Jörg Kienzle and Gunter Mussbacher

2

Software Engineer

Domain-Specific Engineer

I'd fix healthcare.gov myself but i don't write code

Software requirements High level goals

Support for trade-off analysis

3

Many reusable solutions

4

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

concern

A concern groups related models serving the same purpose, and

provides three interfaces to facilitate reuse.

Customization

Usage Interface

Variation Interface

5

Variation Interface

6

Increase performance

Increase access

performance Increase

insertion/deletion performance

ArrayList

FIFO Queue (Linked List)

HashSet

LinkedHashMap

Database

100 50 50

50

1

100

100

50 50

TreeSet

85


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 sizeSequence |Associated

mySeq 1

Association

WithKey Ordered Unordered

alternative (XOR)

structural view

1myLink 0..*+ * |forwardingMethod(..)

+ |Link getAssociated()

|Data

aspect Association

|Associated~ * |targetMethod(..)

|Link

|Data|Link

|Associated|forwardingMethod

|targetMethod

aspect Map extends Association

structural view|Data|Key

|Value

1myMap

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 viewaspect ZeroToMany extends Association realizes Unordered

|Data|Associated

1mySet 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 sizeSet |Associated

Reusable Aspect Models (RAM)

Customization InterfaceUsage 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



|Associated

0..*+ add(|Associated a)+ add(int index, |Associated a)....

int size|Data


int sizeSequence

mySeq 1

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

Concern-Reuse Process

2- Use the customized concern according to its usage interface.Subject.getObservers(), Observer.startObserving

optional

Observer

Push Active PassivePull

ControllerNotificationMethod

ConcurrentUpdate

mandatory

alternative (XOR)

Figure 4. Observer Feature Model

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)+ int getPrice()

Stock - int price

+ refresh(int newPrice)

StockWindow

Figure 6. Simple Stock Application

~ Set<StockWindow> getObservers()+ setPrice(int price)+ int getPrice()

- int priceStock

+ 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 customizationinterface is the same for the active and passive approaches, eventhough the behavior is quite different.

While it is possible to define an <<activePush>> tag, this caseis not interesting. Such a tag would define everthing needed for thevariant of the Observer concern with the Push and Active featuresselected, but this is not any different than defining any other fea-ture by itself from scratch. Therefore, we focus on how to combinethe effects of several tags by defining a tag <<active>>, whichcan be used in conjunction with the tag <<push>>. Consequently,

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..*

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 interactionsbetween the features, allowing us to incrementally define the deltadifferences of the transformation rules.

If the Active feature is selected in addition to the Push feature, aController class must be defined for the stock application (e.g.,the class StockController is added to Fig. 6), and the tag inFig. 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 ( O p e r a t i o n u2)>> = O b s e r v e r ( A c t i v e ) ;( 2 ) f o r O p e r a t i o n m;( 3 ) when m. A n n o t a t i o n! e x i s t s ( a | a . name= ’ push ’ ) o r

m. A n n o t a t i o n! e x i s t s ( a | a . name= ’ p u l l ’ ) ;( 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.

<<ordered>> 1-Apply tags to indicate reuse

10

Domain-Specific Languages (DSL) emerged to make modelling more accessible to domain experts who are not

familiar with software engineering techniques.

11

Association

Database


alternative (XOR)

Event Participant0..*<<ordered>> participants

Examples of Specifying DSL Based on Concern Interfaces

that each occurrence of |Data is replaced by Event and eachoccurrence of |Associated is replaced by Participant.

The example so far used the regular modeling features providedby RAM to reuse the Association concern for the conference regis-tration system. On the other hand, a DSL for the Association con-cern could streamline this process by using a tag instead to indicatethe same reuse of the Association concern, as is illustrated in Fig. 3.


Figure 3. Use of <<ordered>> from Association

In the figure, the association is tagged with <<ordered>> to in-dicate the desired configuration of the feature model of the Associa-tion concern. If a different feature configuration is needed, the tags<<unordered>>, <<withKey>>, or <<persisted>> could be used forthe features Unordered, WithKey, and Database, respectively. In thecase of the Association concern, there is clearly a one-to-one corre-spondence between features and tags in the DSL. This is possiblebecause 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 yetsufficiently define a DSL, because the list only specifies the con-crete syntax of the DSL, but not its semantics. One way to specifythe 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 onthe variation and customization interface of the concern. For exam-ple, the specification of the semantics of the <<ordered>> tag isas follows:( 1 ) << o r d e r e d >> = A s s o c i a t i o n ( Ordered ) ;( 2 ) f o r A s s o c i a t i o n E n d a ;( 3 ) compose | Data ! a . ge tType ( ) ;

| A s s o c i a t e d ! 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 whichtype of modeling element the tag may be applied (e.g., the classAssociationEnd from the RAM metamodel). This line also de-fines a variable for the model element to which the tag may beapplied, 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 inthe case of the Association concern) and application model ele-ments. The application model elements are identified with the helpof an OCL (Object Constraint Language) [12] expression, startingfrom the element identified in line (2). In the RAM metamodel, anAssociationEnd is contained in the source class of the directedassociation (i.e., Event in Fig. 3), which can be found by callinggetType(). Furthermore, the AssociationEnd has as its classthe target class of the directed association (i.e., Participant inFig. 3), which is stored in the myClass attribute. Note that the num-ber of model elements in the customization interface of the concerndetermines the number of composition specifications in line (3).

In summary, the proposed approach for the specification of aDSL based on the three-part concern interface is as follows:

• Define a tag for each feature configuration of interest for theconcern. In the simplest case, a tag is defined for each variablefeature, but it is also possible to only define tags for a subset.The list of tags represents the concrete syntax of the DSL andreflects the key concepts of the domain.

• Formally specify each tag with the help of the proposed speci-fication language for the creation of a concern DSL by defining

1) the corresponding concern, 2) the represented feature selec-tion, as well as 3) how the composition specifications can bederived. The specification language hence defines the seman-tics of the DSL with the help of the existing, reusable concernmodels.

The feature model of the Association concern is rather simple,as any valid configuration consists of one and only one feature.Furthermore, the needed composition specifications are also quitestraightforward. The remainder of this section introduces a morecomplex example involving the Observer design pattern concern,before formally defining the specification language in Section 3.

2.2 Observer ConcernThe feature model of the Observer concern in Fig. 4 identifiesseveral variations of the Observer design pattern.

Each of the variable features is again associated with a tagof the DSL for the Observer concern. Once a subject has beenmodified, the subject may either push the data immediately to itsregistered observers, or the subject may only notify its observersthat a change has occurred and the observers then pull the datafrom the subject if needed. The customization interface for thesetwo variants is the same, i.e., the Subject and Observer classes,as well as the modify, getData, and update methods, need tobe composed with application classes and methods, respectively.Fig. 5 shows the customization and usage interfaces of the PushObserver. Note that the only difference to the Pull Observer isthat the usage interface contains update() instead of update(*),because data is not immediately pushed.

Assuming a stock application with a Stock and StockWindowclass as shown in Fig. 6, the Push Observer may be applied to theapplication by tagging the setPricemethod with <<push(Stock.get-Price, StockWindow.refresh)>>. The result of the composition ofthe Observer concern with the stock application is shown in Fig. 7.

The main difference between the Association example and theObserver example is the fact that the composition of the Observerconcern with the stock application requires three methods to beapplied in a coordinated fashion. For each specific modify method,there exist specific getData and update methods that need towork with the modify method. The tag hence needs to identifythese related methods in addition to the model element that isidentified simply by the fact that the tag is applied to it. Theadditional elements are identified with the help of parameters.Thespecification of the <<push>> tag is hence as follows:

( 1 ) <<push ( O p e r a t i o n d , O p e r a t i o n u)>>= O b s e r v e r ( Push ) ;

( 2 ) f o r O p e r a t i o n 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; | S u b j e c t ! m. C l a s s i f i e r ;

| g e t D a t a ! d ; | u p d a t e ! u ;| O b s e r v e r ! 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) andrefresh with update (i.e., u). The specification of the <<push>>tag also defines a constraint in line (3) that needs to be satisfied forthe 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).

A further variation of the Observer concern is the addition ofa controller based on the model-view-controller design pattern3 asshown in Fig. 8. In the passive approach, the controller manipulatesthe model (|Subject) and then tells the view (|Observer) to up-date itself. In the active approach, the passive approach is extendedto also allow the model to inform the view of a change without the

3 http://msdn.microsoft.com/en-us/library/ff649643.aspx



|Associated

0..*

+ add(|Associated a)+ add(int index, |Associated a)....

int size|Data


int sizeSequence |Associated

mySeq 1

Event Participant0..*participants

Registration System reuses Association<Ordered>!|Data → |Subject; |Associated → Participant!

12


optional

Observer

Push

Active

Passive

Pull

Controller

Notification

Method Concurrent

Update

mandatory

alternative (XOR)

optional

Observer



ConcurrentUpdate

mandatory

alternative (XOR)


aspect Observer

structural view


|Subject


|ObservermySubject

0..1


<<ordered>> 0..*



Stock - int price


StockWindow



- int priceStock



0..1

<<ordered>> 0..*





structural view


|Subject

~ |update(*)

|Observer











aspect Observer

structural view


|Subject


|ObservermySubject

0..1


<<ordered>> 0..*

+ setPrice(int price)+ int getPrice()

Stock - int price


StockWindow
























Stock Exchange reuses Observer<Push>!|Data → |Stock; |Observer → StockWindow; !|modify → setPrice; |getData → getPrice; |update → refresh!

13


optional

Observer



ConcurrentUpdate

mandatory

alternative (XOR)


aspect Observer

structural view


|Subject


|ObservermySubject

0..1


<<ordered>> 0..*



Stock - int price


StockWindow



- int priceStock



0..1

<<ordered>> 0..*





structural view


|Subject

~ |update(*)

|Observer











optional

Observer

Push

Active

Passive

Pull

Controller

Notification

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


structural view


|Subject

~ |update(*)

|Observer




+ 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

DSL for Concerns

3. Domain-Specific Languages for ConcernsBased on the examples and discussion in the previous section, thespecification language for DSLs for a concern may be formally de-fined as shown below. This, of course, is only one possible exampleof a DSL. However, we argue that the three interfaces are essentialas the variation interface exposes the semantic differences betweenvarious features of the concern, the customization interface high-lights composition requirements, and the usage interface definesthe 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 < e l e m e n t _ t y p e > < v a r i a b l e _ n a m e > " ; "[ " 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 ofthe nonterminals such as <tag_name> are omitted as the names ofthe nonterminals are self-explanatory. Also note that it is possibleto replace <feature_list> with <feature_configuration> if such aconcept exists in the feature model notation used for the concern.Furthermore, it is possible that the same tag is to be applied todifferent types of modeling elements, even though all examplesin this paper only required the tag to be applied to one type ofmodeling element. In this case, a second specification for the tagis created where the third line in the above definition indicates thatthe tag may be applied to a different type of modeling elements.Additional composition specifications are then needed with OCLexpressions tailored to each model element type.

The proposed specification language for a DSL provides theblueprint for the transformation of a tag into regular RAM featureconfigurations and RAM bindings between the elements of thecustomization interface of the reused concern and model elementsof the application under development.

4. ConclusionDomain-specific (modeling) languages allow solutions to be ex-pressed at the level of abstraction of the problem domain. Theyencapsulate domain expertise, and guide the user of the DSL byconstraining him to focus on the relevant concepts of the domainand their relationships. In other words, DSLs make it easier to cor-rectly apply domain-specific knowledge.

Concern-oriented software development combines the ideas ofMDE, aspect-orientation, and software product lines. Domain ex-pertise is encapsulated within a concern that groups models thatexpress all relevant concepts, properties, and functionality. A con-cern forms a unit of reuse. Besides the typical usage interface, itsvariation interface specifies the features that the concern provides,and its customization interface details the general concepts of theconcern that need to be composed with application-specific dataand behavior in order to integrate the concern with an application.

In this paper, we demonstrated that it is possible with relativelittle effort to define a DSL based on the information provided inthe variation and customization interfaces of a concern. Further-more, we argue that the three-part concern interface is essential forthe specification of an appropriate DSL. We define a language tospecify the syntax and semantics of such a DSL. We propose to usetags as the syntax of the DSL, representing the interesting featureselections, if needed with additional parameters4. We provide thesemantics of the DSL by describing how to derive the variationconfiguration and the customization bindings of a concern from

4 It is of course possible to define graphical representations of the tags foruse within graphical modeling environments.

the tags. We illustrated our approach by specifying DSLs for theAssociation and Observer concerns, and showed how they can beapplied within an application under development.

In the future, we are planning to extend our specification lan-guage to also consider the impact model of a concern when defin-ing a DSL. The impact model expresses how the different variantsof a concern affect high level goals and system qualities. For in-stance, performance is a good example of a high level goal that isrelevant in the Association concern. For example, a tag <<optimize-insertion-performance>> could be exposed in the DSL to allow auser to specify that the algorithm and data structure used to imple-ment the association should be chosen in such a way that insertionoperations are fast.

5. AcknowledgementsThe authors of this work are partially funded by the Natural Sci-ences and Engineering Research Council of Canada (NSERC).

References[1] ALAM, O., KIENZLE, J., AND MUSSBACHER, G. Concern-oriented

software design. In Model-Driven Engineering Languages and Sys-tems, A. Moreira, B. Schätz, J. Gray, A. Vallecillo, and P. Clarke, Eds.,vol. 8107 of Lecture Notes in Computer Science. Springer Berlin Hei-delberg, 2013, pp. 604–621.

[2] CHUNG, L., NIXON, B. A., YU, E., AND MYLOPOULOS, J. Non-Functional Requirements in Software Engineering. Springer, 2000.

[3] DARDENNE, A., VAN LAMSWEERDE, A., AND FICKAS, S. Goal-directed requirements acquisition. Science of Computer Programming20 (1993), 3–50.

[4] FOWLER, M. Domain-Specific Languages. Addison-Wesley Profes-sional, 2010.

[5] INTERNATIONAL TELECOMMUNICATION UNION (ITU-T). Recom-mendation Z.151 (10/12): User Requirements Notation (URN) - Lan-guage Definition, approved October 2012.

[6] KANG, K., COHEN, S., HESS, J., NOVAK, W., AND PETERSON,S. Feature-oriented domain analysis (FODA) feasibility study. Tech.Rep. CMU/SEI-90-TR-21, Software Engineering Institute, CarnegieMellon University, November 1990.

[7] KIENZLE, J., AL ABED, W., AND KLEIN, J. Aspect-Oriented Multi-View Modeling. In Proceedings of the 8th International Conferenceon Aspect-Oriented Software Development - AOSD 2009, March 1 - 6,2009 (March 2009), ACM Press, pp. 87 – 98.

[8] MUSSBACHER, G., AMYOT, D., ARAÚJO, J., AND MOREIRA, A.Requirements Modeling with the Aspect-oriented User RequirementsNotation (AoURN): A Case Study. In Transactions on Aspect-Oriented Software Development VII (2010), vol. 6210 of LectureNotes in Computer Science, Springer, pp. 23–68.

[9] MUSSBACHER, G., AMYOT, D., AND WHITTLE, J. Composing goaland scenario models with the aspect-oriented user requirements nota-tion based on syntax and semantics. In Aspect-Oriented RequirementsEngineering. Springer Berlin Heidelberg, 2013, pp. 77–99.

[10] OBJECT MANAGEMENT GROUP. Unified Modeling Language: Su-perstructure (v2.4.1), December 2011.

[11] OBJECT MANAGEMENT GROUP (OMG). The UML Profile forMARTE: Modeling and Analysis of Real-Time and Embedded Sys-tems. URL: http://www.omgmarte.org.

[12] OBJECT MANAGEMENT GROUP (OMG). Object Constraint Lan-guage (v2.3.1), January 2012.

[13] YU, E. Modelling strategic relationships for process reengineering.PhD thesis, Department of Computer Science, University of Toronto,1995.

15

Future Work


Increase access

performance Increase

insertion/deletion performance

ArrayList

FIFO Queue (Linked List)

HashSet

LinkedHashMap

Database

100 50 50

50

1

100

100

50 50

TreeSet

85

Association


alternative (XOR)

Use impact model.. Highly performant Association.Ordered?

16

concern DSL

Association

Database


alternative (XOR)























