Implementing Contract-based Software Architectures in Java: The

Structural, Behavioural, and Interaction Design Decisions

Mert Ozkaya

Department of Computer Engineering, Altinbas University, Istanbul, Turkey

Keywords:

Software Architecture, XCD, Code Generation, Java, Design-by-Contract.

Abstract:

Architectural languages (ALs) have been so actively researched since the nineties and this leads to many

ALs with different capabilities that have been proposed each day. However, most of the ALs ignore the

speciﬁcations of the structural, behavioural, and interaction design decisions and do not support their analysis

and development. The ALs that do support suffer from the process algebra based notation sets that practitioners

do not prefer to work with. This issue is tackled in the paper by extending the Design-by-Contract based

architectural language called XCD that supports the contractual speciﬁcations of the structural, behavioural,

and interaction design decisions about software systems and their formal analysis. XCD is extended with a

development support in Java so as to transform the contractual speciﬁcations in XCD into a complete Java

program that considers all the structural, behavioural, and interaction decisions speciﬁed. So, practitioners

will be able to specify non-algebraic, contractual speciﬁcations in XCD, formally analyse them, and produce

the Java source-code that reﬂects the speciﬁed architecture completely and consistently. The produced Java

code can also be tested for incompleteness and wrong use of component services automatically.

1 INTRODUCTION

Software architecture have been proposed essen-

tially for describing large software systems in terms

of independent computations (i.e., components) and

their relationships with each other (i.e., connectors)

(Clements et al., 2003). Many high-level design deci-

sions can also be speciﬁed at the level of software ar-

chitecture design. This includes the design decisions

about the system structure, behaviour, interaction pro-

tocols, non-functional properties, concurrency, devel-

opment, and deployment.

With the evolution of the model-based software

engineering, architectural design decisions can be

speciﬁed at different levels of abstractions, analysed

for the properties of interest, and then transformed

into software implementation code. Indeed, many ar-

chitectural languages (ALs) (Medvidovic and Taylor,

2000; Ozkaya and Kloukinas, 2013) have been pro-

posed, which offer different ways of modelling soft-

ware architectures and provide many interesting fea-

tures such as non-functional property support, analy-

sis support, extensibility, code generation, graphical

notation set, etc.

One of the most trendy topics of ALs is the for-

mal analysis, i.e., the exhaustive checking of architec-

tural models for some properties (e.g., deadlock and

live-lock) or any user requirements. This allows for

checking the behavioural and interaction design deci-

sions for every state of the components and proving

their correctness. Many of the ALs nowadays offer

formally deﬁned semantics and tool-support for trans-

forming architectural models in these formalisms. By

doing so, the exhaustive model checker tools of the

formalisms can be used and the design errors can be

detected before the design decisions are used in the

low-level design and implementation stages.

While the analysis of the design decisions is so

crucial, it is also desirable to transform the anal-

ysed speciﬁcations in some programming languages

so as to reduce the development effort. This not

only prevents the coding-from-scratch but also any

inconsistencies between the architectural design de-

cisions and the actual system implementation due to

manual transformations. Developing code from soft-

ware architecture also guarantees the communication

integrity (Aldrich et al., 2002). That is, the imple-

mented software systems consist of the components

that can communicate only with those components

that have been speciﬁed to communicate in the soft-

ware architecture.

346

Ozkaya, M.

Implementing Contract-based Software Architectures in Java: The Structural, Behavioural, and Interaction Design Decisions.

DOI: 10.5220/0006568203460355

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 346-355

ISBN: 978-989-758-283-7

2 MOTIVATION AND GOAL

There are tens of ALs that are existing in the lit-

erature, and, Malavolta et al. have kept a list of

125 different ALs (Ivano Malavolta, 2017). When

those ALs have been analysed, many ALs (48%)

have been found out to support the structural and

behavioural design decisions

. So, these ALs sup-

port the (i) structural decompositions of software sys-

tems into independent components and connectors,

(ii) the behavioural descriptions of how the compo-

nents will change their states upon the events occuring

in their environment (e.g., receiving/making method-

calls) and (iii) the interaction protocols for connec-

tors (if supported as part of the behaviour speciﬁ-

cations). However, when also the exhaustive model

checking and software implementation are considered

too, many of those ALs supporting the structural and

behavioural design decisions remain weak. As dis-

cussed in Section 6, just 5 ALs support the spec-

iﬁcations of the system structures and behaviours,

their exhaustive analysis, and generation into software

code; and, unfortunately, those ALs are not so conve-

nient for practical use in industry due to their notation

sets. Indeed, those ALs offer process algebra based

notation sets; so, practitioners are forced to learn and

use process algebras for the behaviour speciﬁcations.

Note however that as indicated by Malavolta et al.’s

survey (Malavolta et al., 2012), algebraic ALs are not

used by the practitioners due to being found as requir-

ing a steep learning curve.

In this paper, the goal is to propose a new software

architecture modeling approach that allows practi-

tioners to specify, analyse, and develop their software

architectures without using any algebraic code. To

this end, the XCD AL (Ozkaya and Kloukinas, 2014)

is aimed to be extended in this study, which uses

the well-known Design-by-Contract (DbC) (Meyer,

1992) approach for specifying the structural, be-

havioural, and interaction design decisions. XCD’s

semantics have been deﬁned in terms of its precise

translation in SPIN’s ProMeLa formal veriﬁcation

language (Holzmann, 2004). Using XCD’s translator,

practitioners can obtain the ProMeLa model of their

contractual software architectures that satisfy the se-

mantics rules and verify them using the SPIN model

checker for a set of pre-deﬁned properties (e.g., dead-

lock, race-conditions, wrong use of services, and in-

completeness) and user-deﬁned properties in linear

temporal logic (LTL). However, XCD currently does

not provide any support for the implementation of the

software architecture speciﬁcations. Practitioners are

The analysis results for the ALs can be found in the fol-

lowing link: https://sites.google.com/site/ozkayamert1/als

expected to transform their design decision speciﬁca-

tions into software implementation manually, which

is error-prone and time-consuming. Therefore, to

bridge this gap, this paper introduces XCD’s precise

translations in the Java programming language. This

will let practitioners who use XCD for the contractual

speciﬁcations of component behaviours and connec-

tors’ interaction protocols have the complete and con-

sistent Java code that reﬂects all the decisions speci-

ﬁed. Furthermore, to increase the code maintenance

and understandability, the adapter design pattern has

been applied for the Java code produced.

In the rest of this paper, initially, XCD’s DbC-

based notation set is introduced. This is followed by

the explanations of the algorithms for translating XCD

in Java. Next, the Java translation of XCD has been

illustrated via the gas station case-study. Lastly, the

related work and conclusion are given.

3 XCD’s NOTATION SET

XCD offers components and connectors as ﬁrst-class

elements, which can be speciﬁed contractually.

3.1 Components in XCD

Components in XCD are the units of computations,

which are speciﬁed with state data and ports. Fig-

ure 1 illustrates the component speciﬁcations via the

client (lines 1-12) and server (lines 13-24) compo-

nents. Both component speciﬁcations include the

variable initialisations ﬁrstly (line 2 and 14), which

represent the component state that are changed via

the ports. The asynchronous (i.e., one-way event)

communication is performed via the emitter and con-

sumer types of ports (lines 8-11 and lines 20-23 re-

spectively). The synchronous (i.e., request-response

methods) communication is performed via the re-

quired and provided types of ports (lines 3-7 and 15-

19 respectively).

XCD extends DbC and offers functional and inter-

action contracts for the port method/event behaviours,

whose syntax and semantics differ by the type of

the port. XCD introduces accept and wait interac-

tion contracts. If the accept contract is not satis-

ﬁed, the method call (or the event) is rejected im-

mediately (line 16). If the wait contract is not sat-

isﬁed, the method call (or the event) is delayed un-

til it is satisﬁed (line 21). Whenever the interaction

contract for a method/event is satisﬁed, the functional

contract for that method/event is evaluated that essen-

tially updates the component state under some condi-

tions. The functional contract for emitter events or

Implementing Contract-based Software Architectures in Java: The Structural, Behavioural, and Interaction Design Decisions

347

1 component Cli ent (int cli e n tN a m e ){

2 bool cl ie n t Dat a := -1;

3 required port c l i e nt P o rt1 {

4 @functional{promises: na me := cl i ent N ame ;

5 requires : \result >= 0 ;

6 ensures : cl i e ntD a ta :=\result;}

7 int get D at a (int name ); }

8 emitter port c l i en t P o rt 2 {

9 @functional{promises: da ta := cl i ent D ata ;

10 requires: true; ensures: \nothing;}

11 se t Da t a (int d ata ); }

12 }

13 component Ser ver (){

14 bool is Da t a Se t := f al se ; int se r v er D a ta =1;

15 provided port se rv e r Por t 1 {

16 @interaction{accepts: i sDa t aSe t ;}

17 @functional{ requires: name >= 0;

18 ensures: \result := s erv e r Da t a * 3; }

19 int get D at a (int name ); }

20 consumer port s e r ve r P o rt 2 {

21 @interaction{waits:! isD a taS e t ;}

22 @functional{ensures : is D at a S et := tru e ; s e rv e r Da t a = d at a ;}

23 se t Da t a (int d ata ); }

24 }

Figure 1: Contractual component speciﬁcations in XCD - client and server components.

1 connector c l i en t _ s e rve r _ c o nn ( cli ent { g et Da ta , set D ata } , se r ve r { getD at a , set D at a }){

2 role cl ien t {

3 bool isS et : = false;

4 required port variable pv1 {

5 @interaction{ waits: is Set ;ensures: \nothing;}

6 int get D at a (int name ); }

7 emitter port variable pv2 {

8 @interaction{waits:! isS et ;ensures: is Se t :=true;}

9 se t Da t a (int d ata ); }

10 }

11 role se rve r {

12 provided port variable pv 1 {

13 int get D at a (int arg ); }

14 consumer port variable pv2 {

15 se t Da t a (int a rg2 ); }

16 }

17 connector l in k1 ( cl ie nt { pv1 } , s e rv e r { pv1 } );

18 connector l in k2 ( cl ie nt { pv2 } , s e rv e r { pv2 } );

19 }

Figure 2: Contractual speciﬁcation of a connector for client and server.

required methods consists of promises (lines 4 and

9) and requires-ensures pair (lines 5-6, and line 10),

where the former assigns parameters for the even-

t/method to be emitted/called and the latter changes

the component state after the emission/call if the re-

quires pre-condition is satisﬁed. The functional con-

tracts for consumer events or provided methods are

evaluated after the method-call (or event) is received.

Each functional contract consists of the requires and

ensures pair (lines 17-18 and line 22) for updating the

component state with the ensures data assignments

whenever the requires pre-condition is satisﬁed.

Lastly, a component may be a composite, which

consists of the instance speciﬁcations of other com-

ponents and connectors. Indeed, system conﬁgura-

tions are speciﬁed as a composite component in XCD,

which includes the component instances composing

the system and the connector instance(s) that are re-

sponsible for the interactions of those components.

3.2 Connectors in XCD

Connectors in XCD are the units of component inter-

actions and used to specify the interaction protocols

for a set of interacting components. As illustrated

in Figure 2, connectors are speciﬁed with roles that

are played by the participating components and a set

of links that establish the connections between the

roles (essentially the components). In Figure 2, the

client role in lines 2-10 are played by the client com-

ponent and the server role in lines 11-16 are played

by the server component. Each role, just like com-

ponents, consists of state data variables (line 3) and

port-variables that represent the ports of the compo-

nent playing the role. Role port-variables (lines 4-6 &

7-9 for the client role and lines 12-13 & 14-15 for the

server role) may include any methods/events of the

corresponding component ports, and each method-

/event is attached with an extra interaction contract

that constrains the interaction behaviour of the meth-

ods (lines 5 and 8). Note that role interaction contracts

also have ensures data assignments for changing the

role data if the waits condition is satisﬁed.

Connectors also have role parameters and these

parameters are passed with the relevant components

when the connectors are instantiated in a composite

component for specifying the system conﬁguration.

4 TRANSLATING XCD TO JAVA

In this section, XCD’s translation in Java is discussed

in a modular and thus more understandable manner.

Initially the component translation is given, which is

further modularised into translations of different types

of ports. Then, the connector translation is given.

Lastly, the translation of the system conﬁgurations is

given, which consists of the instances of the compo-

nents and the connectors.

Basically, each component is translated as a sep-

arate Java class and each connector is translated as a

set of classes each corresponding to a different com-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

348

munication link of the connector. These classes are

instantiated and used together in another main Java

class translated from the system conﬁguration.

4.1 Translating Components

Listing 1 gives the component translation in Java.

Each component that is instantiated in the system con-

ﬁguration is translated into a Java class. The body

of the Java class ﬁrstly includes the declarations of

the instance variables corresponding to the compo-

nent state data (lines 3–4) and the data of the con-

nector role(s) that the component plays (lines 5–7).

Then, the class body includes the port method/event

translations, which is discussed in the next section.

1 FORALL c ∈ c o n f i g u r a t i o n . c omp o n e n t Se t

2 p u b l i c c l a s s c . ID {

3 FORALL d a t a ∈ c . d a t a S e t

4 d a t a . ty p e d a t a . ID = d a t a . i n i t i a l V a l u e ;

5 FORALL r o l e ∈ c . r o l e S e t

6 FORALL d a t a ∈ r o l e . d a t a S e t

7 d a t a . ty p e d a t a . ID = d a t a . i n i t i a l V a l u e ;

8 C o m p o n e n t P o r t s t o J a v a ( c . t y p e )

9 }

Listing 1: Translating component type.

4.2 Translating Component Port to

Java

For each port, its methods/events are translated into

a Java method in the body of the Java class trans-

lated for the component that owns the port. The port

method/event translation is considered in two parts as

shown in Listing 2. While the provided methods and

consumed events are translated in the same way (line

8), the required methods and emitted events are the

other two that are also translated in the same way (line

9).

1 C o m p o n e n t P o r t s t o J a v a ( co m pon e nt c )

2 LET

3 p r o v i d e d Me t h o ds ={ p o r t . m et h od S e t | p o r t ∈c . p r o v i d e d P o r t S e t }

4 r e q u i r e d M e t h o d s ={ p o r t . m e t h o d S et | p o r t ∈c . r e q u i r e d P o r t S e t }

5 c o n s u me r E v ent s ={ p o r t . m e t h o d Se t | p o r t ∈c . co n s u m e r P o r t S e t }

6 e m i t t e r E v e n t s ={ p o r t . m et h o dS e t | p o r t ∈c . e m i t t e r P o r t S e t }

7 IN

8 o f f e r e d S e r v i c e s ( c , pr o v id e d M et h o d s ∪ c o n s um e r E ve nt s )

9 r e q u e s t e d S e r v i c e s ( c , r e q u i r e d M e t h o d s ∪ e m i t t e r E v e n t s )

Listing 2: Translating component port.

4.2.1 Translating Provided Methods and

Consumer Events to Java

Listing 3 gives the translation of provided methods

and consumer events. For each provided method (or

consumer event), a Java method with public visibility

is created (lines 3-22) in the Java class of the rele-

vant component type. Note that each method is syn-

chronised, which locks the class instance when the

method is called. The body of the Java method starts

with a while loop (lines 4–6) that essentially checks

whether the port’s wait interaction contract and the

component’s role interaction contracts for the relevant

service are together satisﬁed. Java Object class’s wait

method is called (line 6) in the loop until the interac-

tion contracts are satisﬁed. The wait method serves to

stop the thread that executes the calling method and

another thread that executes a different method of the

same class (i.e., another port service of the same com-

ponent) may interleave. The newly executing method

may indeed change the component state that will

later on satisfy the interaction contracts of the wait-

ing thread. A provided method (or a consumed event)

may alternatively have an accepting interaction con-

straint (lines 8–9). In such a case, the interaction con-

tract is translated into an if statement whose dissatis-

faction leads to an exception to be thrown, indicating

the wrong use of component services. When the inter-

action contracts are all satisﬁed, ﬁrstly the role state

data are updated using the role interaction contract’s

ensures data-assignments (lines 10–11). Then, the

functional contracts for the provided method (or con-

sumed event) can be processed (lines 13–19). Each

functional contract for a method (or an event) is trans-

lated as an if statement, whose condition is the re-

quires pre-condition and body includes the ensures

assignments. So, whenever the functional constraint

pre-condition is satisﬁed, the functional contract’s en-

sures assignments are performed. Note that the en-

sures clause changes the component state data and as-

sign the method result (if the result type is not void).

If none of the functional contract’s pre-condition is

satisﬁed, an exception is thrown (lines 18-19), indi-

cating the incompleteness of the functional constraint

speciﬁcations. In line 20, the Java Object class’s

notify method is called, which notiﬁes any waiting

thread to resume its execution. Lastly in line 21, the

result is returned for the method-call.

1 o f f e r e d S e r v i c e s ( c omp o nen t c , p r o v i de dM et ho d s , c o n s u m e d E v e n t s )

2 FORALL s ∈ p r o vi d e d Me t h o ds ∪ c o n s u m e d E v e n t s

3 p u b l i c sy nc hr o n i z ed s . r e t u r n T y p e s . ID ( s . p a r a m L i s t ) {

4 w h i l e ! ( s . I C o n t r a c t . w a i t s

role∈c.roleSet

r o l e . s . I C o n t r a c t . w a i t s )

6 { Ob j ect . wa i t ( ) ; }

7 IF s . I C o n t r a c t . a c c e p t s 6= NULL

8 i f ! ( s . I C o n t r a c t . a c c e p t s )

9 throw new Exception(”Wrong use of component services” ) ;

10 FORALL r o l e ∈ c . r o l e S e t

11 r o l e . s . I C o n t r a c t . e n s u r e s ;

12 IF s . F C o n t r a c t S e t 6= NULL

13 FORALL f c ∈ s . F u n c t i o n a l C o n t r a c t S e t

14 i f ( f c . r e q u i r e s ) {

15 f c . e n s u r e s

dataAssignment

;

16 r e s u l t = f c . e n s u r e s

result

;

17 }

18 e l s e

19 throw new Exception( ”Incomplete func. behavior” ) ;

20 Obj e c t . n o t i f y ( ) ;

21 r e t ur n r e s u l t ;

22 }

Listing 3: Translating provided and consumer ports.

Implementing Contract-based Software Architectures in Java: The Structural, Behavioural, and Interaction Design Decisions

349

4.2.2 Translating Required Methods and

Emitter Events to Java

Required methods and emitter events are translated as

depicted in Listing 4. For each required method (or

emitter event), a Java method is created again within

the Java class corresponding to the component (lines

5–28). Required ports (or emitter ports) of compo-

nents make method requests (or event emission in the

case of emitter ports) to the connected provided port

(or consumer). Therefore, the translated Java meth-

ods are actually supposed to make method-calls to

the translated Java methods of the connected provided

methods (or consumed events). This issue has been

tackled with using the adapter design pattern, where

the adapter is the connector link class and the adaptee

is the component class that operates the provided port

(consumer port). As shown in lines 3-4, each Java

class includes an instance variable for each required

port (or emitter event). This instance variable is ex-

pected to store a reference to the adapter class in-

stance (i.e., the connector link). Whenever the re-

quired method (or emitter event’s method) is called

via the adapter instance, the adapter directs the call

to the class instance corresponding to the providing

component.

The ﬁrst statement in the translated Java meth-

ods for required methods (or emitter events) is the

while loop for checking the port and role interaction

contracts (lines 5–8). As in the translations of pro-

vided methods (and consumed events), the Java Ob-

ject class’s wait method is called in the loop (line

8) until the interaction contracts are satisﬁed, which

causes another thread that executes another port ser-

vice of the same component to interleave. When

the interaction contracts are satisﬁed, the role data

are updated initially using the role interaction con-

straints’ ensures data-assignments (lines 9–10). Then,

the Java method of the connected provided port are

called via the connector variable (line 11). Note that

the functional contract’s promises assignments for the

required port method (emitter event) are passed as

parameters to the called method. After calling the

method of the provided port (or consumer port), the

functional contracts for the required method (or emit-

ter event) are processed (lines 12-17). If none of

the functional contract’s pre-condition is satisﬁed, the

program execution is again halted with an exception

thrown to indicate the incomplete behaviour speciﬁ-

cation (lines 16-17). Lastly in line 18, the Java Ob-

ject class’s notify method is called to notify the wait-

ing thread (i.e., the one whose wait method has been

called) to resume their execution.

If a component has a required port (or emitter),

besides the Java methods created for each required

method (emitter event), another compute method is

created (lines 20-27). The compute method serves

for making service requests on behalf of the compo-

nent’s required (or emitter) ports. So, it is translated

as the concurrent execution of multiple Java threads

each calling a Java method corresponding to a unique

required port method (or emitter event).

1 r e q u e s t e d S e r v i c e s ( Component c , r e q u ir e d M e t h o d s , e m i t t e r E v e n t s )

2 FORALL p o r t ∈ c . r e q u i r e d P o r t S e t ∪ c . e m i t t e r P o r t S e t

3 p o r t . ID l i n k

port

;

4 FORALL s ∈ r e q u i r e d M e t h o d s ∪ e m i t t e r E v e n t s

5 p u b l i c s y n c h ro ni z ed s . r e t u r n T y p e s . ID ( s . p a r a m L i s t ) {

6 wh il e ! ( s . I C o n t r a c t . w a i t s

role∈c.roleSet

r o l e . s . I C o n t r a c t . wa i t s )

8 { wa i t ( ) ; }

9 FORALL r o l e ∈ c . r o l e S e t

10 r o l e . s . I C o n t r a c t . e n s u r e s ;

11 r e s u l t = l i n k

port

. s e r v i c e ( s . F C o n t r a c t S e t . pr o m i s e s ) ;

12 IF s e r v i c e . F C o n t r a c t S e t 6= NULL

13 FORALL f c ∈ s . F u n c t i o n a l C o n t r a c t S e t

14 i f ( f c . r e q u i r e s )

15 f c . e n s u r e s ;

16 e l s e

17 throw new Exception(”Incomplete fun. behavior” ) ;

18 n o t i f y ( ) ;

19 }

20 p u b l i c v o i d co m pu te ( ) {

21 FORALL s e r v i c e ∈ r e q u i r e d M e t h o d S e t ∪ e m i t t e r E v e n t S e t

22 ( new Thread ( ) {

23 p u b l i c vo i d run ( ) {

24 t ry { s e r v i c e ( s e r v i c e . a r g u m e n t L i s t ) ; }

25 c a t c h ( Ex c e p t i o n e ) { e . p r i nt St a c k T r ac e ( ) ; }

26 }

27 } ) . s t a r t ( ) ;

28 }

Listing 4: Translating required and emitter ports.

4.3 Translating Connectors

Besides components, connectors are translated in Java

too, depicted in Listing 5. As aforementioned, con-

nectors are speciﬁed with (i) component roles for im-

posing interaction protocols on components and (ii)

links for connecting the component ports. For each

link that a connector has, a Java class is created

(lines 3–19). This Java class implements a Java in-

terface (line 3) that has the methods corresponding to

the methods/events communicated between the con-

nected component ports. The connector class also

has a constructor (lines 6–7) for receiving the class

instance for the providing component (i.e., the one

that provides the method/event services to the con-

nected requiring component). In lines 9-18, the in-

terface methods are implemented in a way that each

method directs the call to the corresponding method

of the providing component class instance. So, as dis-

cussed in Section 4.2.2, the required component class

may use the connector link class instance to call the

methods of the provided component class indirectly.

1 FORALL c o n n e c t o r ∈ c o n f i g u r a t i o n . c o n n e c t o r S e t

2 FORALL l i n k ∈ c o n n e c t o r . l i n k S e t

3 p u b l i c c l a s s l i n k . ID i m pl e m en t s inter f aceID(requiredPort(link)){

4 type(providesComponent(link)) o f f e ri n g C o m p o n e n t ;

6 p u b l i c l i n k . ID (type(providesComponent(link)) c ) {

7 o f fe r i n g C o m p o n e n t = c ;

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

350

8 }

9 IF t y p e ( l i n k ) = p r o v i d e d r e q u i r e d

10 FORALL m ∈ providedPort(link) . me t ho dS e t

11 m. r e t T y p e m. ID (m. p a r a m S i g n a t u r e s ) thr ows Ex ce pt io n {

12 r e t u rn o f f e r i n g C o m p on e n t .m(m . p a r a m L i s t ) ;

13 }

14 ELSE

15 FORALL e ∈ emitterPort(link) . e v e n t S e t

16 vo id e . ID ( e . p a r a m S i g n a t u r e s ) thro w s E xc e pt io n {

17 of f e r i n g C o m p o n e n t . e ( e . p a r a m L i s t ) ;

18 }

19 }

Listing 5: Translating connectors.

The underlined functions each returns a speciﬁc part of a VXCD speciﬁcation (e.g., port

element) and serves for simplifying the algorithm, making it more modular and easier to

understand.

4.4 Translating Conﬁgurations

The system conﬁguration is translated as a Java class,

depicted in Listing 6. The Java class herein includes

(i) for each component involved in the conﬁguration

an instance variable referencing to the class instance

of that component and (ii) for each connector link

that connects the components an instance variable ref-

erencing to the class instance of that link. In lines

13-17, the link variables of the requiring component

instances (i.e., the components with required/emitter

ports) are each instantiated with a reference to the in-

stance of the relevant connector’s link.

The Java class for a conﬁguration also has a main

method (lines 19–26). This main method creates an

instance of the conﬁguration class and activates its

components that need to request services from other

components which offer services. To do so, the com-

pute methods of those components are called.

1 p u b l i c c l a s s c o n f i g u r a t i o n . ID {

2 FORALL c o mpo n e nt ∈ c o n f i g u r a t i o n . c o m p on en tS et

3 co m pon e nt . t y p e com p one n t . ID ;

4 FORALL c o n n e c t o r ∈ c o n f i g u r a t i o n . c o n n e c t o r S e t

5 FORALL l i n k ∈ c o n n e c t o r . l i n k S e t

6 l i n k . ID l i n k

instance

;

7 pu b l i c c o n f i g u r a t i o n . ID ( ) {

8 FORALL c o mpo n ent ∈ c o n f i g u r a t i o n . co m p on en tSe t

9 co m pon e n t . ID = new c o mpo n ent . t y p e ( ) ;

10 FORALL c o n n e c t o r ∈ c o n f i g u r a t i o n . c o n n e c t o r S e t

11 FORALL l i n k ∈ c o n n e c t o r . l i n k S e t

12 l i n k

instance

= new l i n k . ID ( ) ;

13 FORALL c o mpo n ent ∈ c o n f i g u r a t i o n . co m p on en tSe t

14 FORALL r e q P o r t ∈ c omp o n ent . t y p e . r e q u i r e d P o r t S e t

15 com p one n t . l i n k

reqPort

= ConnectorLinkIns(reqPort) ;

16 FORALL e m P o rt ∈ com p one n t . t y p e . e m i t t e r P o r t S e t

17 com p one n t . l i n k

emPort

= ConnectorLinkIns(emPort) ;

18 }

19 pu b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) {

20 c o n f i g u r a t i o n . ID s y s t e m c o n f i g = new c o n f i g u r a t i o n . ID ( ) ;

22 FORALL c o mpo n ent ∈ c o n f i g u r a t i o n . co m p on en tSe t

23 IF c omp o nent . r e q u i r e d P o r t S e t ! = NULL OR

24 co m pon e n t . e m i t t e r P o r t S e t != NULL

25 ( c omp o n ent . ID ) . c omp u te ( ) ;

26 }

27 }

Listing 6: Translating system conﬁgurations.

5 EVALUATION

The code generation facility has been illustrated using

the well-known gas station case-study (Naumovich

et al., 1997). The gas station system consists of a

number of customer components, a cashier compo-

nent, and a pump component. Each customer basi-

cally makes a payment to the cashier, and, the cashier

informs the pump for releasing the gas to the cus-

tomer. Then, the customer gets the gas from the

pump. The gas station case-study has been speci-

ﬁed in XCD and translated into a formal ProMeLa

model using XCD’s ProMeLa translator. The resulting

ProMeLa models have been formally analysed using

the SPIN model checker. During the analysis here, the

deadlock, race-condition, incompleteness, and wrong

use of services properties have been checked, which

are supported by XCD. Some user-deﬁned properties

have also been speciﬁed in LTL, which can be anal-

ysed via the SPIN model checker. More detailed info

can be found in (Ozkaya and Kloukinas, 2014). After

analysing the speciﬁcations and correcting the design

errors, the gas station speciﬁcation has been trans-

formed into a Java source-code, which is partially

given in Figure 3. Note that due to the space restric-

tion, the translation of gas station’s conﬁguration is

not shown here

. To automate the translation process,

a code generator has been developed in the Metaedit

environment

, which can be accessible via the XCD’s

visual extension called VXCD

Figure 4 depicts the structure of the classes gener-

ated from gas station. Initially, a Java class is gener-

ated for each component involved - customer (lines 1–

24 of Figure 3), cashier (lines 25-50), and pump (lines

52-81). Note that these classes have method deﬁ-

nitions for each required/provided method and emit-

ter/consumer event of the corresponding components.

For each connector link that connects any two com-

ponent ports, a class is created. This link class imple-

ments a Java interface that consists of the Java method

deﬁnitions corresponding to the services which are

communicated between the linked component ports.

The Java interfaces for gas station are given in lines

83-98 of Figure 3, and the connector link classes

that implement the relevant interfaces are given in

lines 100-120. Each connector link class is associ-

ated with the component classes. Whenever the com-

ponent classes are instantiated as part of the conﬁg-

uration class, their link variables are initialised with

The XCD speciﬁcation for the gas station system,

the translated full Java source-code, and the Java code-

generator can be accessible via the link: https://sites.

google.com/site/ozkayamert1/ vxcd

http://metacase.com/

Implementing Contract-based Software Architectures in Java: The Structural, Behavioural, and Interaction Design Decisions

351

1 p u b l i c c l a s s C ust o me r {

2 / / Da ta −v a r i a b l e s

3 i n t c ho se nA mo un t = 0 ;

4 bo ole a n r e q u e s t M a de = f a l s e ;

5 / / R e q u i r e d −p o r t l i n k

6 g a s L i n k g a s L i n k I n s t a n c e ;

7 p u b l i c sy n c h r o n i z e d v o i d pump ( ) {

8 wh il e ( ! r e q u e st M ad e ) { t r y { w a i t ( ) ; } c at ch ( I n t e r r u p t e d E x p e ){ } }

9 i n t r e s u l t = g a s L i n k I n s t a n c e . pump ( ) ;

10 i f ( r e s u l t == ch os en Amount ){ r e q u e s t M a de = f a l s e ; }

11 e l s e i f ( r e s u l t ! = c ho se nA mount ) { / / . . }

12 e l s e throw new Exp ( ” I n c o m p l e t e fu n c . be h a v i o u r ” ) ;

13 n o t i f y ( ) ;

14 }

15 / / E m i t t e r p o r t l i n k

16 p a y L i n k p a y L i n k I n s t a n c e ;

17 p u b l i c s y n c h r on i z e d v o i d pay ( i n t amo unt ) {

18 wh il e ( r e q u es t M ad e ) { t r y { w a i t ( ) ; } c a t ch ( I n t e r r u p t e d E x p e ) {}}

19 p a y L i n k I n s t a n c e . pa y ( 0 ) ;

20 re qu e s tM a de = t r u e ;

21 n o t i f y ( ) ;

22 }

23 / / c omp ut e m e th o d s f o r t h e r e q u e s t e d me t hod s ( s e e S ec . 4 . 2 . 2 )

24 }

25 p u b l i c c l a s s C a s h i e r {

26 i n t p a y me n t am o unt [ ] = new i n t [ 3 ] ;

27 i n t va r N , v ar M ;

28 p u b l i c C a s h i e r ( i n t N , i n t M) {

29 va r N = N ;

30 va r M = M;

31 f o r ( i n t i = 0 ; i<pa ym e n t am ou n t . l e n g t h ; i ++)

32 pa y men t am o unt [ i ] = 0 ;

33 }

34 p u b l i c sy n c h r o n i z e d v o i d pay ( i n t a m o u n t ar g , i n t p o r t I D ) {

35 i f ( ! ( p a y me n t am o un t [ p o r t I D ] == 0 ) )

36 throw new Exp ( ” Wrong u s e o f s e r v i c e s ” ) ;

37 i f ( t r u e ) { pa y m e nt

am o u n t [ p o r t I D ] = am o u n t a r g ; }

38 e l s e throw new Exp ( ” I n c o m p l e t e fu n c . be h a v i o u r ” ) ;

39 n o t i f y ( ) ;

40 }

41 / / e m i t t e r p o r t l i n k

42 to P ump Li nk t o P u m p L i n k I n s t a n c e ;

43 p u b l i c sy n c h r o n i z e d v o i d r e l ea se P u m p ( i n t pumpID , i n t a mount ) {

44 wh il e ( ( p aym e n t am ou n t [ pumpID ]= = 0 ) )

45 { t r y { wa i t ( ) ; } ca t c h ( I n t e r r u p t e d E x p e ) {}}

46 t o P u m p L i n k I n s t a n c e . re le as e P u m p ( pumpID , amo un t ) ;

47 n o t i f y ( ) ;

48 }

49 / / com pu te me t ho d s f o r th e r e q u e s t e d me t hod s ( s e e S ec . 4 . 2 . 2 )

50 }

52 p u b l i c c l a s s Pump {

53 bo o l e a n P ump Re l ea s ed [ ] = new b o o l e an [ 3 ] ;

54 i n t p a y me n t am o unt [ ] = new i n t [ 3 ] ;

55 i n t v a r N ;

56 p u b l i c Pump ( i n t N) {

57 va r N = N ;

58 f o r ( i n t i = 0 ; i<Pu mpR el e as e d . l e n g t h ; i ++ )

59 Pum pRe lea se d [ i ] = f a l s e ;

60 f o r ( i n t i = 0 ; i<pa ym e n t am ou n t . l e n g t h ; i ++)

61 pa y men t am o unt [ i ] = 0 ;

62 }

63 p u b l i c sy n c h r o n i z e d i n t pump ( i n t p o r t I D ) {

64 i f ( ! ( P um pRe le a se d [ p o r t I D ] == t r u e ) )

65 { th row new Exp ( ” Wrong u s e o f s e r v i c e s ” ) ; }

66 i f ( p a y men t am o unt [ p o r t I D ] != 0 ) {

67 P u mp R el eas ed [ p o r t I D ] = f a l s e ;

68 }

69 e l s e {throw new Exp ( ” I n c o m p l e t e f un c . b e h a v i o u r ” ) ; }

70 n o t i f y ( ) ;

71 re t u r n p a yme n t am o un t [ p o r t I D ] ;

72 }

73 p u b l i c sy n c h r o n i z e d v o i d r e l ea se P u m p ( i n t pumpID , i n t a mount ) {

74 i f ( t r u e ) {

75 Pum p Re lea se d [ pumpID ] = t r u e ;

76 pa y men t am o unt [ pumpID ] = amou nt ;

77 }

78 e l s e throw new Exp ( ” I n c o m p l e t e fu n c . be h a v i o u r ” ) ;

79 n o t i f y ( ) ;

80 }

81 }

83 p u b l i c i n t e r f a c e p a y L i n k { p u b l i c v o i d pay ( i n t amo unt ) th r ow s Exp ; }

85 p u b l i c i n t e r f a c e to Pu m p Lin k {

86 p u b l i c vo i d r e l e a se Pu m p ( i n t pumpID , i n t amo un t ) thr ow s Exp ; }

88 p u b l i c i n t e r f a c e g a s L i n k { p u b l i c i n t pump ( ) t hr ow s Exp ; }

90 p u b l i c c l a s s C u s to m e r to Pum p i m p l em e nt s ga s L i n k {

91 Pump Pu m p i n s ;

92 i n t po r t I D ;

93 p u b l i c C u s t o mer to Pu mp ( Pump Pump arg , i n t p o r t I D ) {

94 Pu mp in s = Pum p ar g ;

95 p o r t I D = p o r t I D ;

96 }

97 p u b l i c i n t pump ( ) { r e t u r n P ump

in s . pump ( p o r t I D ) ; }

98 }

100 p u b l i c c l a s s C u s t o m e r t o C a s h i e r im p le m en ts p ay L i n k {

101 C a s h i e r C a s h i e r i n s ;

102 i n t p o r t I D v a r ;

103 p u b l i c C u s t o m e r t o C a s h i e r ( C a s h i e r C a s h i e r a r g , i n t p o r t I D ) {

104 C a s h i e r i n s = C a s h i e r a r g ;

105 p o r t I D v a r = p o r t I D ;

106 }

107 p u b l i c vo i d p ay ( i n t a mo un t ){

108 t r y { C a s h i e r i n s . pa y ( amou nt , p o r t I D v a r ) ; }

109 ca tc h ( Exp e ) { e . pr i nt St a ck Tr ac e ( ) ; }

110 }

111 }

112

113 p u b l i c c l a s s Ca s h i e r t o P u mp i m p l e m e nt s t o Pu m p Lin k {

114 Pump Pu m p i n s ;

115 p u b l i c Ca s h i e r t o P u m p ( Pump Pu mp a rg ) { P u mp in s = Pum p ar g ; }

116 p u b l i c vo i d r e l e a se Pu m p ( i n t pumpID , i n t amo un t ){

117 t r y { Pum p in s . re le as eP u m p ( pumpID , amo un t ) ; }

118 c a t c h ( Exp e ) { e . pr i nt St ac k Tr ac e ( ) ; }

119 }

120 }

Figure 3: The translated Java code from the Gas Station speciﬁcation in XCD.

Note: ”Exp” represents Exception.

Figure 4: Gas station class diagram.

the relevant connector link class instances. The cus-

tomer link variable in line 6 is initialised with the

Customer2Pump class instance (lines 90-96). The

customer link variable in line 16 is initialised with

the Customer2Cashier class instance (lines 100-111).

The cashier link variable in line 42 is initialised

with the Cashier2Pump class instance (lines 113-

120). So, whenever the component class instances

make a method-call using the associated link vari-

ables, the link class instances receive the calls and di-

rect them to the linked component class instances. For

instance, the customer class instance makes a pump

method-call using the Customer2Pump link class in-

stance (see line 9). Then, the Customer2Pump class

instance receives the call (see line 97) and directs it

to the pump component (i.e., calling the pump class

instance’s pump method).

As illustrated in Figure 3, the Java source-code

translations for XCD consider not only the structural

design decisions but also the behavioural and interac-

tion design decisions that may be speciﬁed. For in-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

352

stance, the pump component’s pump method is trans-

lated in lines 63-72, which essentially consists of

three parts. In the ﬁrst part (lines 64–65), the interac-

tion contracts imposed on the pump method are trans-

lated. Apparently, the method is not constrained with

any delaying interaction contracts (waits) - neither by

the component port nor the connector roles. How-

ever, the method is constrained with an accepting in-

teraction contract, translated as a selection construct

in lines 64-65. So, if the pump has not been released

yet, a Java exception will be thrown, which will halt

the system execution. If the interaction constraints

are satisﬁed (i.e., no exception thrown), the functional

contract translated in lines 66-69 is executed. If the

payment amount recorded for the customer is not zero

(i.e., the ﬁrst requires pre-condition), the correspond-

ing ensures assigns the pump-released data to false to

be able to release the gas again upon request. Other-

wise, a Java exception is thrown and the program is

halted (line 69) to indicate the incomplete behaviour

speciﬁcation (i.e., the case when the payment infor-

mation is not received is not considered by the pump

speciﬁcation). Lastly, inline 70, the Object class’s no-

tify method is called and the result (i.e., the payment

amount) is returned to the caller.

To enhance the understandability of the generated

Java code, the translation algorithms have been de-

signed using the adapter design pattern. For any con-

nector link that connects the compatible ports of any

two components, the translated Java class from the

connector link acts as an adapter, the providing com-

ponent class (i.e., the one with the provided/consumer

port) acts as an adaptee, and the requiring compo-

nent class (i.e., with the required/emitter port) acts

as a client. The requiring component class uses the

connector class to call the methods of the providing

class indirectly. So, the classes of the two compo-

nents whose required and provided (or emitter and

consumer) ports are interconnected and request the

methods (or events) of each other do not know each

other thanks to the connector.

Practitioners may also test the executable Java

programs produced from the XCD speciﬁcations. In-

deed, as discussed in Section 4.2.1 and 4.2.2, the

translation algorithms consider the incomplete func-

tional behaviours and wrong use of component port

services. Whenever such issues occur during the

system execution, a Java exception is thrown with

the necessary explanation message. When the Java

source-code in Figure 3 produced from the gas station

speciﬁcation was run, a Java exception was thrown

due to the wrong use of services and the program

halted. According to the error message, the error has

essentially been resulted from the pump method of the

pump component (see lines 63-72 in Figure 3). Dur-

ing the system execution, the accepting interaction

contract in lines 64-65 has been violated as the pump

method has been called before the pump has been re-

leased. Note though that unlike formal analysis, soft-

ware testing does not check every possible system

paths for the aforementioned properties. Therefore,

the non-existence of any errors during the software

testing does not guarantee that every single path can

also be executed successfully.

6 RELATED WORK

According to Malavolta etal.’s recent survey on the

ALs, there are 125 different ALs that have been de-

veloped so far (Ivano Malavolta, 2017). The exist-

ing ALs have been analysed in this study for (i) the

support for structural, behavioural, and interaction

design decisions, (ii) the exhaustive model checking

of those design decisions, and (iii) generating soft-

ware code from the design decision speciﬁcations.

According to the analysis results, only 6 ALs sup-

port all those requirements, i.e., Prisma (P

erez et al.,

2003), Ambient-Prisma (Ali et al., 2010), Aspect-

Leda (Navasa et al., 2007), Korrigan (Choppy et al.,

2001), pi-ADL (Oquendo, 2004), and XCD (Ozkaya

and Kloukinas, 2014). Table 1 shows the notations

that the ALs use for specifying the structural, be-

havioural, and interaction decisions, the supported

properties for analysis, and the programming lan-

guage used in generating software code.

Prisma offers a UML-like graphical notation for

specifying system structures in terms of compo-

nents and connectors, and their behaviours/proto-

cols are speciﬁed as an aspect that is speciﬁed in

the pi-calculus process algebra (Milner et al., 1992).

Prisma’s modelling toolset allows for specifying user-

deﬁned requirements in temporal logics and checking

the consistencies of the speciﬁcations and analysing

them for the requirement speciﬁcations. Prisma’s

toolset also generates C# code, which can be ex-

ecuted on the .NET platform. Ambient-Prisma is

the extension of Prisma with the notion of ambi-

ents for specifying mobile software systems. Un-

like Prisma, Ambient-Prisma is based on Ambient-

calculus (Cardelli and Gordon, 1998), in which the

aspects are speciﬁed formally. Like Ambient-Prisma,

pi-ADL also focuses on the software architecture

speciﬁcations of mobile systems. Pi-ADL is based

on the pi-calculus process algebra. Pi-ADL supports

the speciﬁcations of user-deﬁned requirements in pi-

calculus (or temporal logic) and supports the exhaus-

tive model checking via the CADP veriﬁcation tool

Implementing Contract-based Software Architectures in Java: The Structural, Behavioural, and Interaction Design Decisions

353

Table 1: The ALs supporting the structural, behavioural, and interaction design decisions, and their analysis & code genera-

tion.

ALs

Structure

Speciﬁcation

Behaviour

Speciﬁcation

Interaction

Speciﬁcation

Analysis

Support

Code Gen.

Support

Prisma

Graphical

Notation

Pi-calculus Pi-calculus

Consistency,

User-deﬁned reqs.

Ambient-Prisma

Graphical

Notation

Ambient-calculus Ambient-calculus

Consistency,

User-deﬁned reqs.

Aspect-Leda

Graphical

Notation

Pi-calculus Pi-calculus

Consistency,

Model Checker

Java

Korrigan

Graphical

Notation

Symbolic

Transition System

Temporal

Logic

Model

Checker

Java

pi-ADL Predicate Logic Pi-calculus Pi-calculus

Model Checker,

User-deﬁned reqs

.NET

XCD Textual Notation DbC DbC

Model Checker,

Completeness,

User-deﬁned reqs

Java

(Garavel et al., 2001). Pi-ADL is supported with

a compiler that translates the pi-ADL speciﬁcations

into software code (e.g., C# and Visual Basic) in

.NET platform. Aspect-Leda is another aspectual AL

that extends the LEDA AL (Canal et al., 1999). So,

like LEDA, Aspect-LEDA is based on pi-calculus for

specifying component behaviours and connector in-

teractions. Aspect-LEDA is supported by a couple of

translators that translate the speciﬁcations in LEDA

for using LEDA’s model checking facilities. The

Aspect-Leda speciﬁcations can be translated in Java

for testing whether the software system behaves in the

expected way or not. Korrigan uses again a UML-

like graphical notation for specifying system struc-

ture and the behaviours of components are speciﬁed in

symbolic transition system (i.e., a derivation of state

transition systems). Korrigan uses temporal logic for

specifying the component interactions (i.e., connec-

tors). Korrigan speciﬁcations can be translated in the

LOTOS formal veriﬁcation language (Bolognesi and

Brinksma, 1987) for model checking. Korrigan spec-

iﬁcations can also be translated in Java. Lastly, XCD

that has been extended with the Java development

support in this paper is the only AL that offers non-

algebraic, contractual (i.e., pre- and post-conditions)

notation set for the speciﬁcations of structural, be-

havioural, and interaction design decisions. Note also

that thanks to XCD’s ProMeLa translator, the contrac-

tual speciﬁcations can be exhaustively analysed for a

number of properties including completeness, dead-

lock, race-condition, wrong use of services, and user-

deﬁned requirements.

7 CONCLUSION

While the software architecture community offers

tens of different ALs with a variety of capabilities,

only a few of those ALs have been determined to sup-

port the speciﬁcations of the system structures, be-

haviours, and interactions that can be exhaustively

analysed and then transformed into software imple-

mentation. Those ALs however have algebraic nota-

tion sets that are not preferred by practitioners unfor-

tunately due to requiring a steep learning curve. To

bridge this gap, this paper focuses on the XCD AL,

which is based on the well-known DbC approach for

the contractual (i.e., non-algebraic) speciﬁcations of

the system structure, behaviour and interaction de-

sign decisions. XCD also supports the formal (i.e., ex-

haustive) analysis of the speciﬁcations using the SPIN

model checker. So, XCD has been extended in the

paper with a development viewpoint support and of-

fered with the precise translation of the contractual

XCD speciﬁcations in Java. XCD’s Java translations

considers all the structural, behavioural, and interac-

tion design decisions supported by XCD and the trans-

lations have been designed using the adapter design

pattern so as to enhance the quality of the code to

be produced. The translation algorithms also con-

sider checking for incomplete functional behaviours

and wrong use of component services. So, practition-

ers can obtain the executable Java-based software sys-

tems that are complete and consistent with regard to

their architecture speciﬁcations. To illustrate the Java

extension for XCD, the gas station system has been

speciﬁed, formally analysed, and then translated in

Java. A prototype tool has also been developed for

automating the Java source-code translation.

In the future, the XCD language is planned to be

extended with the deployment, physical, and opera-

tional viewpoints to offer practitioners with the lan-

guage that supports the full development life-cycle.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

354

ACKNOWLEDGEMENTS

This work has been supported by the project of the

Scientiﬁc and Technological Research Council of

Turkey (TUBITAK), Grant No: 215E159.

REFERENCES

Aldrich, J., Chambers, C., and Notkin, D. (2002). Archjava:

Connecting software architecture to implementation.

In Tracz, W., Young, M., and Magee, J., editors, ICSE,

pages 187–197. ACM.

Ali, N., Ramos, I., and Sol

ıs, C. (2010). Ambient-prisma:

Ambients in mobile aspect-oriented software architec-

ture. Journal of Systems and Software, 83(6):937–958.

Bolognesi, T. and Brinksma, E. (1987). Introduction to the

iso speciﬁcation language lotos. Computer Networks

and ISDN Systems, 14(1):25 – 59.

Canal, C., Pimentel, E., and Troya, J. M. (1999). Speciﬁca-

tion and reﬁnement of dynamic software architectures.

In Donohoe, P., editor, WICSA, volume 140 of IFIP

Conference Proceedings, pages 107–126. Kluwer.

Cardelli, L. and Gordon, A. D. (1998). Mobile ambients,

pages 140–155. Springer Berlin Heidelberg, Berlin,

Heidelberg.

Choppy, C., Poizat, P., and Royer, J. (2001). The korrigan

environment. J. UCS, 7(1):19–36.

Clements, P. C., Garlan, D., Little, R., Nord, R. L., and

Stafford, J. A. (2003). Documenting software archi-

tectures: Views and beyond. In Clarke, L. A., Dillon,

L., and Tichy, W. F., editors, ICSE, pages 740–741.

IEEE Computer Society.

Garavel, H., Lang, F., and Mateescu, R. (2001). An

overview of CADP 2001. Research Report RT-0254,

INRIA.

Holzmann, G. J. (2004). The SPIN Model Checker - primer

and reference manual. Addison-Wesley.

Ivano Malavolta, Patricia Lago, H. M. P. P. A. T.

(2017). Architectural languages today.

http://www.di.univaq.it/malavolta/al/.

Malavolta, I., Lago, P., Muccini, H., Pelliccione, P., and

Tang, A. (2012). What industry needs from architec-

tural languages: A survey. IEEE Transactions on Soft-

ware Engineering, 99.

Medvidovic, N. and Taylor, R. N. (2000). A classiﬁcation

and comparison framework for software architecture

description languages. IEEE Trans. Software Eng.,

26(1):70–93.

Meyer, B. (1992). Applying “Design by Contract”. IEEE

Computer, 25(10):40–51.

Milner, R., Parrow, J., and Walker, D. (1992). A calculus of

mobile processes, i. Inf. Comput., 100(1):1–40.

Naumovich, G., Avrunin, G. S., Clarke, L. A., and Oster-

weil, L. J. (1997). Applying static analysis to software

architectures. In Jazayeri, M. and Schauer, H., editors,

ESEC / SIGSOFT FSE, volume 1301 of Lecture Notes

in Computer Science, pages 77–93. Springer.

Navasa, A., P

erez, M. A., and Murillo, J. M. (2007). Aspec-

tLEDA: Extending an ADL with Aspectual Concepts,

pages 330–334. Springer Berlin Heidelberg, Berlin,

Heidelberg.

Oquendo, F. (2004). pi-adl: an architecture description

language based on the higher-order typed pi-calculus

for specifying dynamic and mobile software architec-

tures. ACM SIGSOFT Software Engineering Notes,

29(3):1–14.

Ozkaya, M. and Kloukinas, C. (2013). Are we there yet?

analyzing architecture description languages for for-

mal analysis, usability, and realizability. In Demir

ors,

O. and T

uretken, O., editors, EUROMICRO-SEAA,

pages 177–184. IEEE.

Ozkaya, M. and Kloukinas, C. (2014). Design-by-

contract for reusable components and realizable ar-

chitectures. In Seinturier, L., de Almeida, E. S.,

and Carlson, J., editors, CBSE’14, Proceedings of

the 17th International ACM SIGSOFT Symposium

on Component-Based Software Engineering (part of

CompArch 2014), Marcq-en-Baroeul, Lille, France,

June 30 - July 4, 2014, pages 129–138. ACM.

erez, J., Ramos, I., Mart

ınez, J. J., Letelier, P., and

Navarro, E. (2003). Prisma: Towards quality, aspect

oriented and dynamic software architectures. In QSIC,

pages 59–66. IEEE Computer Society.

Implementing Contract-based Software Architectures in Java: The Structural, Behavioural, and Interaction Design Decisions

355