Towards a Design-by-contract based Approach for Realizable

Connector-centric Software Architectures

Mert Ozkaya and Christos Kloukinas

Department of Computer Science, City University London, London, EC1V 0HB, U.K.

Keywords:

Architecture Description Language, Design by Contract, Complex Interaction Protocols, Realizable Designs.

Abstract:

Despite being a widely-used language for specifying software systems, UML remains less than ideal for soft-

ware architectures. Architecture description languages (ADLs) were developed to provide more comprehen-

sive support. However, so far the application of ADLs in practice has been impeded by at least one of the

following problems: (i) advanced formal notations, (ii) lack of support for complex connectors, and (iii) po-

tentially unrealizable designs. In this paper we propose a new ADL that is based on Design-by-Contract (DbC)

for specifying software architectures. While DbC promotes a formal and precise way of specifying system be-

haviours, it is more familiar to practising developers, thus allowing for a more comfortable way of specifying

architectures than using process algebras. Furthermore, by granting connectors a ﬁrst-class status, our ADL

allows designers to specify not only simple interaction mechanisms as connectors but also complex interaction

protocols. Finally, in order to ensure that architectural designs are always realizable we eliminate potentially

unrealizable constructs in connector speciﬁcations (the connector “glue”).

1 INTRODUCTION

Since the early work on software architectures (Perry

and Wolf, 1992; Garlan and Shaw, 1993), specialized

architecture description languages (ADLs) (Medvi-

dovic and Taylor, 2000) have been proposed for spec-

ifying software architectures. But UML has become

a de facto design language for specifying and design-

ing software systems – more practitioners use it than

all other languages (e.g., AADL, ArchiMate, etc.)

combined (Malavolta et al., 2013), even though it is

less than ideal (Dashofy et al., 2002). This is de-

spite some ADLs having formally deﬁned semantics,

enabling not only formally precise models that help

avoid confusion about what is meant by the speciﬁ-

cation but also early formal analysis of software ar-

chitectures. Other ADLs offer automatic code gener-

ation, etc. Nevertheless, UML is still the ﬁrst choice

of practitioners for specifying software architectures,

with most ADLs seemingly remaining of interest to

the research community alone. In our view, there are

three main problems that ADLs suffer from: (i) for-

mal notations for behaviour speciﬁcations that require

a steep learning curve, (ii) lack of support for com-

plex connectors (i.e., interaction protocols), and (iii)

potential for producing unrealizable designs. Indeed,

to the best of our knowledge, there is no ADL that is

easy to learn, treats connectors as ﬁrst-class elements

and ensures that architecture speciﬁcations are realiz-

able. While (i) has been identiﬁed by practitioners as

being a serious impediment to their adoption of cur-

rent ADLs, (ii) is not an issue that they consider as

crucial

but we believe that it can substantially help

in developing concise designs, as it promotes reuse-

by-call instead of reuse-by-copy. Condition (iii) is in

fact something that has not been identiﬁed so far at all

to the best of our knowledge

but we believe that it is

crucial to identify and resolve, if a connector-centric

ADL is to succeed.

Formal Notations. Many ADLs (e.g., Wright

(Allen and Garlan, 1997), LEDA (Canal et al., 1999),

SOFA (Plasil and Visnovsky, 2002), CONNECT (Is-

sarny et al., 2011), etc.) adopt formal notations, e.g.,

process algebras (Bergstra et al., 2001), for specify-

ing the behaviours of architectural elements. They do

so in order to enable the architectural analysis of sys-

tems, which is extremely important in uncovering se-

rious system design errors early on in the lifetime of

Along with a number of researchers, as many ADLs do

not support connectors.

Perhaps due to the non-adoption of ADLs supporting

connectors, as it is a side-effect of their connector speciﬁ-

cation structure.

555

Ozkaya M. and Kloukinas C..

Towards a Design-by-contract based Approach for Realizable Connector-centric Software Architectures.

DOI: 10.5220/0004592305550562

In Proceedings of the 8th International Joint Conference on Software Technologies (ICSOFT-PT-2013), pages 555-562

ISBN: 978-989-8565-68-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

a project. Indeed, if such an analysis is not possible,

then there is no point in using a specialized language

for software architectures – even simple drawings suf-

ﬁce. However, the aforementioned ADLs employ no-

tations that practitioners view (with reason) as having

a steep learning curve (Malavolta et al., 2013). Thus,

practitioners end up avoiding them and use instead

simpler languages, even if that means that they lose

the ability to properly describe and analyze their sys-

tems – better an informal description of a system that

everybody understands than a formal description of a

system that people struggle understanding.

Limited Support for Complex Connectors. An-

other problem with many ADLs (e.g., Darwin (Magee

and Kramer, 1996), Rapide (Luckham, 1996), LEDA

(Canal et al., 1999), and AADL (Feiler et al., 2006)),

as well as with UML, is that they provide limited or

no support for complex connectors, treating them in-

stead as simple connections. Other ADLs, such as

UniCon (Shaw et al., 1995), provide only partial sup-

port through a limited number of basic connectors

but do not allow designers to freely specify their own

(complex) types. This is unfortunate because connec-

tors represent the interaction patterns between com-

ponents, i.e., the interaction protocols that are em-

ployed to achieve the system goals using the sys-

tem components, such as reliability. By instead of-

fering support only for components, architects end

up with two alternatives. One is to ignore protocols,

which inhibits the analysis of crucial system proper-

ties, such as deadlock-freedom, and also leads to ar-

chitectural mismatch (Garlan et al., 1995), i.e., the in-

ability to compose seemingly compatible components

due to wrong assumptions these make about their in-

teraction. The other is to incorporate the protocol

behaviour inside the components themselves, which

leads to complicated component behaviour that is nei-

ther easy to understand nor to analyze and makes

it difﬁcult to reuse components with different pro-

tocols, as well as to ﬁnd errors in speciﬁc protocol

instances. Incorporating protocol behaviour inside

components is essentially following a reuse-by-copy

approach, whereby each component has its own copy

of the protocol constraints. On the other hand, support

for protocols through ﬁrst-class connectors promotes

a reuse-by-call approach, whereby there is only one

instance of the protocol constraints and these are sim-

ply called wherever they are needed.

Potentially Unrealizable Designs. The third prob-

lem of existing ADLs is that when they do support

user-deﬁned, complex connectors, they do so in a way

that can lead to unrealizable designs. This is because,

Figure 1: A nuclear power plant’s unrealizable MSCs (Alur

et al., 2003).

connector Plant Connector =

role Incrementor = ur→na→Incrementor

role Doubler = ur→na→Doubler

role NA = increment→ NA u double→NA

role UR = increment→ UR u double→UR

glue =Incrementor.ur→UR.increment→Incrementor.na→

NA.increment→Doubler.ur→UR.double→

Doubler.na→NA.double→ glue 

Doubler.ur→UR.double→Doubler.na→NA.double→

Incrementor.ur→UR.increment→Incrementor.na→

NA.increment → glue

Figure 2: Wright’s (unrealizable) Connector for Alur’s nu-

clear power plant.

Figure 3: An implied bad scenario in Alur’s plant (Alur

et al., 2003) (hidden by Wright’s glue speciﬁcation).

ADLs of this category are following the approach ini-

tiated by Wright (Allen and Garlan, 1997) and re-

quire connectors to include a glue element. As stated

in (Allen and Garlan, 1997), a connector role speci-

ﬁes the “obligations of [a] component participating

in the interaction” and a glue speciﬁes “how the ac-

tivities of the [. . . ] roles are coordinated.” – a con-

nector glue is supposed to be more than simple def-

inition/use relationships. The fact that the glue can

introduce inter-role interaction constraints is deeply

problematic however, because these constraints can-

not always be implemented in a decentralized manner

by the components that assume the connector roles,

as these can only observe their local state (Tripakis,

2001; Tripakis, 2004). In fact, it has been shown that

the problem of deciding whether a glue can be real-

ized is undecidable (Tripakis, 2001; Tripakis, 2004;

Alur et al., 2003; ?), so there is no general algorithm

that can be implemented to warn architects that the

glue they are specifying is not realizable by the exist-

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

556

ing roles. The only easy solution to realize a protocol

then is to introduce yet another component that will

assume the role of the glue, thus transforming all pro-

tocols into centralized ones.

An example of such an unrealizable protocol from

a simpliﬁed nuclear power plant is described in (Alur

et al., 2003) and reproduced in Figure 1. The in-

teraction therein involves an Incrementor (P

) and a

Doubler (P

) client roles updating the amounts of the

Uranium fuel (UR) and Nitric Acid (NA) server pro-

cesses in a nuclear reactor. After the update opera-

tions, the amounts of UR and NA must be equal to

avoid nuclear accidents, for which reason we wish to

allow only the sequences shown in Figure 1. The in-

teraction of the two clients with the NA and UR vari-

ables, can easily be speciﬁed in Wright as in Figure 2.

Note that this glue speciﬁcation does two things. First

it establishes bindings between clients and servers

(e.g., Incrementor.ur → UR.increment). Then it con-

straints interactions by requiring that we only al-

low UR.increment → NA.increment or UR.double →

NA.double. This speciﬁcation is however unrealiz-

able as (Alur et al., 2003) have shown because it is

impossible to implement it in a decentralized manner

in a way that avoids behaviours excluded by the glue,

e.g., the one depicted in Figure 3. The only way to

achieve the desired behaviour is to introduce another

role, for a centralized controller G. Roles Incrementor

and Doubler then need to inform G when they wish to

interact with UR and NA and have G perform the in-

teractions with UR and NA in their place.

2 OUR APPROACH

The ADL we are developing tries to overcome the

problems identiﬁed in the previous section and offer:

• ﬁrst-class support for user-deﬁned complex con-

nectors;

• realizable software architectures by construction;

and

• a simple to understand, yet formal, language

for specifying behaviour, based on design-by-

contract (DbC).

2.1 Support for Complex Connectors

Our ADL grants connectors in software architectures

ﬁrst-class status, allowing designers to specify both

simple interaction mechanisms and complex proto-

cols. These can then be instantiated as many times

as needed, allowing architects to simplify the speciﬁ-

Figure 4: Simple Connectors in Circuits.

→ (r

,||(→ (r

),r

))

Figure 5: Complex Connectors in Circuits.

cations of their components and easily reuse the spec-

iﬁcation of complex protocols.

To illustrate how important this is for both archi-

tectural understandability and also analysis, we will

use a simple example from electrical engineering. Let

us consider k concrete electrical resistors, r

,· ·· ,r

i.e., our system components. When using a sequen-

tial connector (→), the overall resistance is computed

as R

→

(N,{R

}

i=1

) =

∑

i=1

, where N, R

are vari-

ables (R

correspond to connector roles), to be as-

signed eventually some concrete values k,r

. If us-

ing a parallel connector (k) instead, it is computed

as R

(N,{R

}

i=1

) = 1/

∑

i=1

1/R

. So the interaction

protocol (connector) used is the one that gives us the

formula we need to use to analyze it – if it does not

do so, then we are probably using the wrong connec-

tor abstraction. The components (r

) are simply pro-

viding some numerical values to use in the formula,

while the system conﬁguration tells us which speciﬁc

value (k, r

) we should assign to each variable (N, R

)

of the connector-derived formula. By simply enumer-

ating the wires/connections between resistors/compo-

nents, we miss the forest for the trees. This leads to ar-

chitectural designs at a very low level that is not easy

to communicate and develop – as (Delanote et al.,

2008) found the case to be with AADL.

Figure 4 shows the number of simple connectors

(identiﬁed with red ellipses) that are needed in our

system. It is easy to see that there are many of them

and it is not so easy to identify the protocol logic,

especially as the system size increases – this is the

equivalent of spaghetti code. By making interaction

protocols implicit in designs, analysis also becomes

difﬁcult and architectural errors can go undetected un-

til later development phases. Indeed, we are essen-

tially forced to reverse-engineer the architect’s intent

in order to analyze our system – after all, the architect

did not select the speciﬁc wire connections by chance

but because they form a speciﬁc complex connector.

When complex connectors are employed instead as in

Figure 5 then the number of connectors to be consid-

ered is reduced substantially. This makes it much eas-

ier to understand the system and to analyze its overall

resistance by taking advantage of the connector prop-

TowardsaDesign-by-contractbasedApproachforRealizableConnector-centricSoftwareArchitectures

557

erties as:

→(r

,||(→(r

),r

))

= r

+ r

||(→(r

),r

)

= r

→(r

)

= r

2.2 Realizable Software Architectures

Connectors in our ADL are not speciﬁed with glue-

like elements. Instead, we consider connectors as a

simple composition of roles, which represent the in-

teraction behaviour of participating components, and

channels that allow actions of one role to reach an-

other. Coordination is now the responsibility of roles

alone. If a particular property is desired then it must

be shown that the roles satisfy it. But this is a prob-

lem that is decidable for ﬁnite state systems – model-

checking. Thus an architect can easily specify a pro-

tocol and be sure that it has the required properties.

Designers can also feel reassured that the architectural

protocols are indeed realizable in principle.

So in the case of Figure 1, the architect should

quickly realize that the desired property is not sat-

isﬁed by the roles and opt for a centralized protocol

instead, by adding a centralized controller. Thus, sur-

prises are avoided – it becomes clear early on whether

something can be made to work in a decentralized

manner or not, as it is tested by the more experienced

architect. The less experienced designers do not have

to waste their time trying to achieve the impossible or

take the easy way out and turn a decentralized pro-

tocol into a centralized one. We essentially turn the

glue from constraints to be imposed, to a property that

needs to be veriﬁed, thus turning an undecidable prob-

lem that the implementers have to deal with, into a de-

cidable one for them (and pushing the responsibility

to resolve the issue to the more experienced architect).

2.3 DbC-based Speciﬁcations

Java Modelling Language (JML) (Chalin et al., 2006)

seems to be gaining popularity among developers, as

they use it for “test-driven development” and even for

static analysis in some instances. Our new ADL at-

tempts to follow this trend so as to maximize adop-

tion by practitioners. Thus, it departs from the ADLs

that adopt process algebras, and instead follows a

Design by Contract (DbC) (Meyer, 1992) approach

like JML, specifying behavioural aspects of systems

through simple pairs of method pre-/post-conditions,

in a syntax reminiscent of JML. DbC allows for a for-

mal speciﬁcation of systems, as it is based on Hoare’s

logic (Hoare, 1969) and VDM’s (Bjørner and Jones,

1978) rely-guarantee speciﬁcation approach. DbC

has so far been mainly considered for programming

languages (e.g., Java through JML), which is why

contracts have been restricted to provided services

(i.e., class methods).

There are very few ADLs that employ DbC. The

work of Schreiner et al. (Schreiner and G

oschka,

2007) along with the TrustME ADL (Schmidt et al.,

2001) are some of the very few examples applying

DbC at the level of software architecture. Schreiner

et al.’s work however does not support component

interfaces emitting or receiving events. Moreover,

they view connectors as simple interconnection mech-

anisms, providing no support for the contractual spec-

iﬁcation of complex interaction protocols. Likewise,

TrustME supports only required and provided inter-

faces for components, again neglecting asynchronous

events. Our approach attempts to apply DbC in a

more comprehensive manner, covering both methods

and events. As we view connectors as ﬁrst-class el-

ements, we use DbC to specify their behaviour as

well. Our ADL further extends DbC by structuring

contracts into functional and interaction parts.

2.3.1 Component Contracts

Components are used to specify at a high-level the

functional units in software systems. Our ADL allows

designers to describe freely as components whatever

they deem appropriate in their system, not impos-

ing, nor introducing, low-level notions (e.g., threads,

processes) as AADL does. Component types are es-

sentially speciﬁed in terms of (i) ports representing

the points of interaction with their environment, and

(ii) data representing the component state. Simi-

larly to CORBA interfaces (OMG, 2006), component

ports can be either event consumer/emitter ones, cor-

responding to CORBA sink and source events respec-

tively, or provided/required method ones, correspond-

ing to CORBA facets and receptacles.

The behaviour of components are speciﬁed in

terms of contracts attached to event/method actions

(e.g., method call and event emission) performed via

the ports. Extending DbC, our ADL allows to attach

contracts to required methods too, to specify usage

patterns of the required service, and also to the events

emitted/received by emitter/consumer ports. Another

extension we applied is the separation of contract

speciﬁcation into functional and interaction contracts,

allowing to distinguish between the functional and in-

teraction behaviour. The former allows for relating

component data, event/method parameters, and re-

sults, while the latter specify (i) the particular manner

in which components want to behave (i.e., the order of

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

558

actions), and (ii) the cases in which they do not know

how to behave, thus leading to chaotic behaviour.

2.3.2 Connector Contracts

As aforementioned, connectors in our ADL are in-

troduced to represent high-level complex interaction

protocols, which the components interacting through

connectors adhere to. Connector types are speciﬁed

in terms of roles and channels. Each role can be

viewed as a component wrapper as depicted in Fig-

ure 6, which further constrains the interaction be-

haviour of the component assuming it. A role is

described with data and port-variables, mirroring a

component – a role is essentially a component vari-

able, with extra state. The port-variables of a role

are bound to ports of the components assuming the

role. Channels of a connector represent the commu-

nication links between interacting roles and can be

synchronous or asynchronous. A channel is described

with a pair of communicating role port-variables and

its communication type.

The behaviour of connectors is speciﬁed with in-

teraction contracts attached to the port-variable ac-

tions. These interaction contracts constrain port-

variable actions so that the respective component

ports behave in a particular manner (i.e., enforcing

a certain action order), according to the desired in-

teraction protocols. In doing so, components avoid

undesired interactions with other components associ-

ated with the same connector. The end result is then a

set of components interacting with their environments

successfully to compose the whole system. All con-

straints imposed are local ones, ensuring realizability.

3 CASE STUDY: SHARED-DATA

ACCESS

Listing 1 below illustrates our ADL’s DbC-based be-

havioural speciﬁcation on shared-data access. An im-

portant thing to note is the overall syntax; it resem-

bles JML, with expressions that shouldn’t feel alien

to practitioners – a far step from process algebraic

notations. Two component types are speciﬁed, user

between lines 1–21 and memory between lines 22–

44. User comprises a required port, puser r (lines

4–12), through which its instances call method get

from the memory and an emitter port, puser e (lines

13–20), through which event set is emitted. Memory

comprises a provided port, pmem

p (lines 25–34),

through which its instances accept calls for method

get from users and a consumer port, pmem c (lines

35–43) through which event set is received.

Figure 6: Connectors with Roles Wrapping Components.

Ports are speciﬁed in terms of method/event

signatures and contracts (i.e., @ f unctional and

@interaction). @interaction constraints on port ac-

tions (e.g., method call and event emission) have

precedence over @functional, i.e, the evaluation of

the latter depends on the satisfaction of the former.

User Component Type. User’s required port puser r

is used to call method get. These calls are delayed un-

til the promised condition speciﬁed in @interaction

is met. Since it is true in line 6, get can be called

immediately. Next, the @ f unctional in lines 7–10

is evaluated; since get has no parameters, there is

no promised actual parameters (promises condition in

line 8 is true). Upon receiving the response after call-

ing get, the received result is ensured to be stored in

variable data.

The user components emit event set through its

emitter port puser e. Note that events are speciﬁed

without return types – they can only have an identi-

ﬁer and parameters. The emission of event set is de-

layed until the promised condition of @interaction in

lines 14–15 is met. Since it is speciﬁed as true, emis-

sion can be made at any instance, using the promised

actual parameters speciﬁed in @ f unctional (line 17).

This then ensures that initialised

u is set to true. Also

note that events are emitted/received asynchronously.

Memory Component Type. Memory’s provided port

pmem p receives calls for method get. These calls are

accepted when the accepts condition in @interaction

is met, initialised m evaluating to true (line 27). Oth-

erwise, the call is re jected when initialised m is

f alse (line 29) leading to chaotic behaviour. If the

call is accepted, then @ f unctional in lines 30–32 is

evaluated. There, it is ensured that the result value to

be emitted is equal to the sh data.

The memory components receive event set via

the consumer port pmem c. The reception of event

set is delayed until the promised condition is met

in @interaction. Since it is speciﬁed as true in

line 37, the set event can be received at any in-

stance. Upon reception of the event set, @ f unctional

in lines 38–41 is evaluated. As the functional

pre-condition (requires) is true, the event’s post-

condition initialised m is ensured and sh data is set

to data arg.

1 component u ser {

2 bool in i ti al i se d_ u = fal se ;

3 int data ;

TowardsaDesign-by-contractbasedApproachforRealizableConnector-centricSoftwareArchitectures

559

4 required port pu ser _r {

5 @interaction{

6 promises : true ; }

7 @functional{

8 promises : true ;

9 requires : tru e ;

10 ensures : data = \ res u lt ; }

11 int get () ;

12 };

13 emitter : port pu se r_e {

14 @interaction{

15 promises : true ; }

16 @functional{

17 promises : da ta _a rg = 7;

18 ensures : in ti a li se d _u = tru e ; }

19 set ( in t da ta_ ar g );

20 }; // port en ds

21 }; // co mp on en t en d s

22 component memo ry {

23 bool in i ti al i se d_ m = fal se ;

24 int sh _da ta = 0;

25 provided port p me m_p {

26 @interaction{

27 accepts : in it i al is e d_ m ;

28 also :

29 rejects : ! in it ia l is ed _ m ; }

30 @functional{

31 requires : tru e ;

32 ensures : \ resu lt = sh _d at a ;}

33 int get () ;

34 }; // port end s

35 consumer port p me m_c {

36 @interaction{

37 accepts : tr ue ; }

38 @functional{

39 requires : tru e ;

40 ensures : in ti a li se d _m = tru e

41 && sh_ da ta = da ta _a rg ; }

42 set ( in t da ta_ ar g );

43 }; // port en ds

44 }; // co mp on en t en d s

45 connector sha r ed Da ta (

46 u se rR ol e { pv _us er }, me mo r yR ol e { pv _m em }) {

47 role use rR ol e {

48 bool i n it ia l is ed _ u = true ;

49 required port

variable p v_ us er _r {

50 @interaction{

51 promises : when ( i nt i al is ed _ u ); }

52 int get () ;

53 };

54 emitter port variable p v_ us e r_ e {

55 @interaction{

56 promises : true ;

57 ensures : in i ti al i se d_ u = true ; }

58 set ( in t da ta_ ar g );

59 }; // port - va ri ab le e nds

60 }; // role en ds

61 role me mo ry Ro le {

62 bool i n it ia l is ed _ m = true ;

63 provided port

variable p v_ m em _p {

64 @interaction{

65 accepts : wh en ( i nt ia l is ed _m );}

66 int get () ;

67 }; // port - va ri ab le e nds

68 consumer port variable p v_ me m_ c {

69 @interaction{

70 accepts : tr ue ;

71 ensures : in i ti al i se d_ m = true ; }

72 set ( in t da ta _ ar g );

73 }; // port - v ar ia bl e en ds

74 }; // role en ds

75 channel asy nc u se r 2m em o ry _m ( p v_u ser _r ,

76 pv _m em _p );

77 channel asy nc u se r 2m em o ry _e ( p v_u ser _e ,

78 pv _m em _c );

79 }; // co nn ec to r en d s

80 \ vsp ac e { -0. 15 cm }

Listing 1: Shared-data Access in our ADL.

Shared-Data Connector Type. The connector type

sharedData, speciﬁed in lines 45–79, serves as a

mediator between users and memory. It essentially

avoids memory from behaving chaotically. In the

sharedData, two roles are speciﬁed, userRole in lines

47–60 and memoryRole in lines 61–74, where the for-

mer is assumed by the user component instances and

the latter by the memory instances.

The interaction behaviour of the event ports is

constrained via the respective port-variables (i.e.,

pv user e of the userRole and pv mem c of the

memoryRole) so that emission/receipt of event set en-

sures that the respective role data initialised u/m is

set to true. Furthermore, the pv mem p in lines 63–

67 and pv user r in lines 49–53 constrain the mem-

ory provided port, so that it delays calls for method

get until the shared data is initialized, and the user

required port so that it does not make calls for get un-

til the data is initialized. Therefore, the correspond-

ing ports of the user and memory components playing

the roles interact in a way that an event set is always

executed before method get is called. This avoids at-

tempts to access uninitialized data and the resulting

chaotic behaviour, as well as deadlocks.

In lines 75–78, there are two channels speciﬁed to

indicate which role port-variable communicates with

which other role port-variable.

Finally, the matching between connector roles and

components is performed via the connector parame-

ters, as speciﬁed in line 46. At conﬁguration time,

when sharedData is instantiated, the user and mem-

ory component instances and their ports are passed as

its parameters.

4 DISCUSSION

As can be seen by Listing 1, the notation used for DbC

in our ADL follows a JML-like syntax, which is fa-

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

560

miliar to practitioners. This should help facilitate its

adoption as it does not require a steep learning curve

– one should be able to use it with minimal train-

ing. At the same time, it introduces connector con-

structs that are essentially (decentralized) algorithms

(as protocols are). So practitioners who have expe-

rienced the distinction between say C++ classes and

C++ generic algorithms should feel comfortable with

the distinction between components and connectors

as made here. Apart from π calculus’ ability to send

channels as messages, which we do not support, our

ADL should allow architects to express what they can

express now with ADLs based on process algebras.

All constraints in our ADL are local, expressed

on local component/role data and parameters. This

ensures realizability and makes reasoning about the

effects of actions easier. Data are encapsulated, so

there are no aliasing problems, and concurrency is

controlled through the ports – each port is a concur-

rent unit, thus ensuring that actions of a port are mu-

tually exclusive. As event emission/consumption and

method servicing (at provided ports) are atomic, ar-

chitects need only guarantee (and verify) that method

calling (at required ports) will not lead to data race

conditions.

The type of constraints an architect uses depends

on the tool support they have. If for example they ex-

press something like 0 ≤ x +y +z ≤ 25 then their tool

would probably need to use an SMT solver or theo-

rem prover and be helped by the architect whenever

it cannot prove or disprove a claim. However, we be-

lieve that in practice one can constrain the type of ex-

pressions used, so as to enable automated veriﬁcation

through a model-checker, without losing much. The

aforementioned constraint can easily be expressed as

x ∈ [0, 25] ∧ y ∈ [0,25 − x] ∧ z ∈ [0,25 − x − y], which

makes it easy for a model-checker to establish, as it

introduces an order for selecting values for variables.

By constraining the form of expressions we enable

better tool support for practitioners and make it pos-

sible for these tools to be fully automated

5 CONCLUSIONS

This paper presents a new ADL that aims at resolving

three main problems in current ADLs: (i) advanced

formal notations used for specifying behaviours, (ii)

lack of support for complex connectors, and (iii) po-

tentially unrealizable designs.

In response to these problems, our ADL follows

a Design-by-Contract approach for specifying be-

Less is more.

haviour, using a JML-like syntax as much as pos-

sible. Thus, practitioners should be able to use it

with minimal training and ﬁnd it not much differ-

ent to other languages that they might have used,

such as JML. Furthermore, architectural connectors

in our ADL can be used to specify either simple inter-

connection mechanisms or complex interaction pro-

tocols. So, large and complex systems can be spec-

iﬁed at a high level as components interacting via

complex interaction protocols, like someone may use

C++ classes and C++ generic algorithms to structure

a system so as to avoid re-coding generic algorithm

fragments inside the classes. Finally, connectors are

speciﬁed as a set of decentralized, independent roles

assumed by the participating components. There is

no glue-like centralized element in connector speci-

ﬁcations or elsewhere – all constraints are expressed

on local state. This leads to architectural designs that

are realizable by construction and whose veriﬁcation

is decidable (when restricted to a ﬁnite number of el-

ements) through model-checking.

ACKNOWLEDGEMENTS

This work has been partially supported by the EU

project FP7-257367 IoT@Work – “Internet of Things

at Work”.

REFERENCES

Allen, R. and Garlan, D. (1997). A formal basis for architec-

tural connection. ACM Trans. Softw. Eng. Methodol.,

6(3):213–249.

Alur, R., Etessami, K., and Yannakakis, M. (2003). Infer-

ence of message sequence charts. IEEE Trans. Soft-

ware Eng., 29(7):623–633.

Alur, R., Etessami, K., and Yannakakis, M. (2005). Realiz-

ability and veriﬁcation of msc graphs. Theor. Comput.

Sci., 331(1):97–114.

Bergstra, J. A., Ponse, A., and Smolka, S. A., editors

(2001). Handbook of Process Algebra. Elsevier.

Bjørner, D. and Jones, C. B., editors (1978). The Vienna De-

velopment Method: The Meta-Language, volume 61

of Lecture Notes in Computer Science. Springer.

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.

Chalin, P., Kiniry, J. R., Leavens, G. T., and Poll, E. (2006).

Beyond assertions: Advanced speciﬁcation and ver-

iﬁcation with JML and ESC/Java2. In FMCO’05 –

Formal Methods for Comp. and Obj., volume 4111 of

LNCS, pages 342–363. Springer.

TowardsaDesign-by-contractbasedApproachforRealizableConnector-centricSoftwareArchitectures

561

Dashofy, E. M., van der Hoek, A., and Taylor, R. N. (2002).

An infrastructure for the rapid development of xml-

based architecture description languages. In Tracz,

W., Young, M., and Magee, J., editors, ICSE, pages

266–276. ACM.

Delanote, D., Baelen, S. V., Joosen, W., and Berbers, Y.

(2008). Using aadl to model a protocol stack. In

ICECCS, pages 277–281. IEEE Computer Society.

Feiler, P. H., Gluch, D. P., and Hudak, J. J. (2006). The Ar-

chitecture Analysis & Design Language (AADL): An

Introduction. Technical report, Software Engineering

Institute.

Garlan, D., Allen, R., and Ockerbloom, J. (1995). Architec-

tural mismatch or why it’s hard to build systems out

of existing parts. In ICSE, pages 179–185.

Garlan, D. and Shaw, M. (1993). An introduction to soft-

ware architecture. In Ambriola, V. and Tortora, G., ed-

itors, Advances in Software Engineering and Knowl-

edge Engineering, pages 1–39, Singapore. World Sci-

entiﬁc Publishing Company. Also appears as SCS and

SEI technical reports: CMU-CS-94-166, CMU/SEI-

94-TR-21, ESC-TR-94-021.

Hoare, C. A. R. (1969). An axiomatic basis for computer

programming. Commun. ACM, 12(10):576–580.

Issarny, V., Bennaceur, A., and Bromberg, Y.-D. (2011).

Middleware-layer connector synthesis: Beyond state

of the art in middleware interoperability. In Bernardo,

M. and Issarny, V., editors, SFM, volume 6659 of

Lecture Notes in Computer Science, pages 217–255.

Springer.

Luckham, D. C. (1996). Rapide: A language and toolset

for simulation of distributed systems by partial order-

ings of events. Technical report, Stanford University,

Stanford, CA, USA.

Magee, J. and Kramer, J. (1996). Dynamic structure in soft-

ware architectures. In SIGSOFT FSE, pages 3–14.

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

Tang, A. (2013). What industry needs from archi-

tectural languages: A survey. IEEE Transactions

on Software Engineering, 99(PrePrints):1–25. DOI:

10.1109/TSE.2012.74 .

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.

OMG (2006). Corba component model 4.0 speciﬁcation.

Speciﬁcation Version 4.0, Object Management Group.

Perry, D. E. and Wolf, A. L. (1992). Foundations for the

study of software architecture. SIGSOFT Softw. Eng.

Notes, 17(4):40–52.

Plasil, F. and Visnovsky, S. (2002). Behavior protocols

for software components. IEEE Trans. Software Eng.,

28(11):1056–1076.

Schmidt, H., Poernomo, I., and Reussner, R. (2001). Trust-

by-contract: Modelling, analysing and predicting be-

haviour of software architectures. J. Integr. Des. Pro-

cess Sci., 5(3):25–51.

Schreiner, D. and G

oschka, K. M. (2007). Explicit con-

nectors in component based software engineering for

distributed embedded systems. In Proceedings of the

33rd conference on Current Trends in Theory and

Practice of Computer Science, SOFSEM ’07, pages

923–934, Berlin, Heidelberg. Springer-Verlag.

Shaw, M., DeLine, R., Klein, D. V., Ross, T. L., Young,

D. M., and Zelesnik, G. (1995). Abstractions for soft-

ware architecture and tools to support them. IEEE

Trans. Software Eng., 21(4):314–335.

Tripakis, S. (2001). Undecidable problems of decentral-

ized observation and control. In Proc. of the 40

IEEE Conf. on Decision and Control, volume 5, pages

4104–4109, Orlando, FL, USA. IEEE.

Tripakis, S. (2004). Undecidable problems of decentralized

observation and control on regular languages. Inf. Pro-

cess. Lett., 90(1):21–28.

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

562