Architectural Speciﬁcation and Analysis with XCD

The Aegis Combat System Case Study

Mert Ozkaya and Christos Kloukinas

Department of Computer Science, City University London, London, U.K.

Keywords:

Design-by-Contract, ProMeLa, Architectural Modelling, Formal Analysis.

Abstract:

Despite promoting precise modelling and analysis, architecture description languages (ADLs) have not yet

gained the expected momentum. Indeed, practitioners prefer using far less formal languages like UML, thus

hindering formal veriﬁcation of models. One of the main issues with ADLs derives from process algebras

which practitioners view as having a steep learning curve. In this paper, we introduce a new ADL called XCD

which enables designers to model their software architectures through a Design-by-Contract approach, as for

example in the Java Modelling Language (JML). We illustrate how XCD can be used in architectural modelling

and analysis using the Aegis combat software system.

1 INTRODUCTION

Architectural modelling and analysis of complex soft-

ware systems has always been a crucial aspect of sys-

tem development for two reasons. First modelling

of architectures enables a highly abstracted view of

systems making their complexity tractable. Second,

models, if speciﬁed formally, can be analysed me-

chanically thus enabling the detection of errors long

before the implementation phase.

Uniﬁed Modelling Language (UML) (Rumbaugh

et al., 1999) gained wide popularity in modelling de-

sign of software systems. Despite partially serving

the ﬁrst reason of modelling, i.e, tractability of large

and complex systems, it however does not do so for

the second reason – analysis of models for early error

detection. This is because UML lacks in formally pre-

cise semantics thus leading to informal and ambigu-

ous models which cannot be mechanically analysed.

Apart from UML, since nineties, several architecture

description languages (ADLs) (Medvidovic and Tay-

lor, 2000) have been proposed. Unlike UML, many of

these ADLs are based on formally precise semantics,

so as to enable analysis of software architectures too.

Despite enabling modelling and analysis, ADLs

unfortunately have not gained the expected momen-

tum among practitioners. As stated in (Malavolta

et al., 2012), this could be due to the steep learning

curve these languages require. According our ADL

study (Ozkaya and Kloukinas, 2013a), indeed ADLs

are based on process algebras (e.g., FSP (Magee and

Kramer, 2006) and CSP (Hoare, 1978)) which most

practitioners are unfamiliar with.

In this paper, we present our new ADL called XCD

that aims at architectural modelling and analysis in a

more practitioner-friendly manner. To this end, XCD

is based on widely known Design-by-Contract (DbC)

approach (Meyer, 1992). So, just like Java Modelling

Language (JML) (Chalin et al., 2006), behaviour of

architectural elements is speciﬁed with contracts, but,

in a more systematic and comprehensive way. In-

deed, we consider a number of extensions to DbC

facilitating the speciﬁcation of components and con-

nectors. To enable formal veriﬁcation of contractual

software architectures, we provide formal mapping of

XCD constructs to SPIN’s formal ProMeLa language

(Holzmann, 2004) which is not only supported by a

powerful model checker but also developer-friendly

language resembling C programming.

2 XCD ADL via Aegis CASE STUDY

Figure 1 depicts the meta-model of the XCD

ADL

. XCD offers two main architectural elements,

components and connectors. As introduced in

(Ozkaya and Kloukinas, 2013b), components are used

to specify the abstractions of computational units and

connectors the interaction protocols for the interact-

Although XCD supports emitter/consumer ports too

for emitting/consuming asynchronous events, we have not

mentioned them herein due to lack of space.

368

Ozkaya M. and Kloukinas C..

Architectural Speciﬁcation and Analysis with XCD - The Aegis Combat System Case Study.

DOI: 10.5220/0004714403680375

In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 368-375

ISBN: 978-989-758-007-9

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

Figure 1: Meta-model of XCD.

ing components. In the rest of this section, using the

Aegis combat software system, we illustrate the con-

tractual speciﬁcations of components and connectors.

The Aegis system has been developed for navy

ships to make them capable of controlling their

weapons against enemies. The Aegis has ﬁrstly been

tackled by Wright (Allen, 1997) in (Allen and Gar-

lan, 1996), which can informally be speciﬁed as

Figure 2 comprising a set of components interact-

ing with each other. The Experiment Control, at

the top of the diagram, essentially provides linked

components the information obtained via sensors.

The track information is, for instance, required by

the Track Server which stores it and provides other

components (Doctrine Validation and Geo Server)

the location information about the enemies operat-

ing around the ship. The Doctrine Authoring requires

doctrine rules from the Experiment Control and pro-

vides them to the other components (Geo Server,

Doctrine Validation, and Doctrine Reasoning) that

require rules to take actions. Using the doctrine

rules and track information from its environment, the

Geo Server provides to the Doctrine Reasoning the

precisely calculated region information for enemies.

Lastly, the Doctrine Reasoning makes the decision of

which task(s) to take against the enemies.

2.1 XCD Speciﬁcation of Aegis

We specify three types of primitive components to

be able model the components depicted in Figure 2.

These are client, server, and mixedComp types. Each

component comprises a set of data variables repre-

senting their state and ports representing the points of

Figure 2: Conceptual Diagram of Aegis.

interactions with their environment. To model the in-

teractions between the components, we also specify

a connector type, client2server which is speciﬁed as

a set of roles played by the components representing

their interaction protocols. It also has built-in connec-

tors establishing the communication links between

the component ports. Finally, we specify a compos-

ite component type aegis con f iguration which rep-

resents a conﬁguration of client, server, and mixed-

Comp components interacting via the client2server

connectors.

2.1.1 Client Component

Listing 1 gives the client component type speciﬁca-

tion, from which client components are instantiated

(i.e., Doctrine Validation and Doctrine Reasoning)

that only require services of server components to be

able perform their tasks. The state of the component

is speciﬁed with two data variables (lines 2-3): the

data holds any information maintained by the com-

ponent and openedConns holds the number of client

ports that open their connections with their servers (by

making call for the method open).

Listing 1: Client Type Speciﬁcation.

1 component c lien t (int nu mOf Por ts ){

2 int data = 0 ,

3 int o p en e dC o nns = 0;

4 required port se r vic e [ n umO f Po r ts ]{

5 @interaction{

6 waits: o p en e dC o nn s < n umO fPo rts ;}

7 @functional{

8 ensures: post ( o pene d [@ ]) : = tr u e

9 && post ( o pen edC onn s )++ ; }

10 void o p en ();

12 @interaction{waits: o pe n ed C on n s > 0;}

13 @functional{

14 ensures: post ( o pene d [@ ]) : = fal s e

15 && post ( o pen edC onn s ) - -;}

16 void c lo se ( ) ;

18 @interaction{

19 waits: o pe n ed C onn s == nu mOf Por ts ;}

20 @functional{ensures: post ( d at a ):= r e sult ;}

21 int r equ e st ();

22 }

ArchitecturalSpecificationandAnalysiswithXCD-TheAegisCombatSystemCaseStudy

369

23 }

The client includes an array of required ports service

(lines 4–22) for making method calls to the connected

server ports. The size of the service is speciﬁed as the

component parameter numO f Ports. Each port of the

service includes three methods that can be requested

from the connected server ports : open, close, and

request. Methods are augmented with @interaction

and @ f unctional contracts comprising a set of con-

straints to satisfy the ultimate goal: a client can make

request for a service only after it opens the connec-

tions to all of its connected servers.

The methods of a required port ﬁrstly get their

parameters promised via their functional constraint’s

promise expression sequence (FCPromises in Fig-

ure 1). However, since none of the methods in the

port service[@]

has parameters, they do not have

FCPromises. So, if the port interaction constraint

guard (ICWaits) on the method open (lines 5–10 in

Listing 1) is satisﬁed, i.e., the data openedConns

is less than the component parameter numO f Ports,

the request is made for the open. When the re-

spective response is received, if the pre-condition

of the functional constraint (FCRequires) is met,

its post-assignment (FCEnsures) may then be per-

formed. Since FCRequires is not speciﬁed (i.e., there-

fore, true) for the open, its FCEnsures increments

the openedConns.

Note that a while FCPromises

assigns promised values to method parameters, the

FCEnsures assigns new values to data variables. The

other port method close (lines 12–16) is requested if

the data openedConns is greater than zero (ICWaits).

Upon receiving the response, FCEnsures decrements

the openedConns data directly, without any pre-

conditions (FCRequires). For the method request

(lines 18–21), it is called if the openedConns data is

equal to the numO f Ports parameter (ICWaits) indi-

cating that all the port of the client opened their con-

nections. Upon calling the method and receiving the

response, FCEnsures updates the data directly (with

no FCRequires) assigning it the received result from

the connected server port.

2.1.2 Server Component

Listing 2 gives the server type speciﬁcation from

which server components (i.e., Experiment Control)

@ symbol used inside contracts represents the index of

the executing port, where 0 ≤@≤numO f Ports − 1.

A component may be in one of the two states at a time:

pre-state is when a method operation is ready to be started

and post-state is when it is to be completed. So, the post-

state values (post(d)) are updated via FCEnsures which

may refer to their pre-states (d).

instantiated that provide services to the client com-

ponents. The component state is speciﬁed with two

data variables (lines 2-3): the opened array variable

holding for each port true if a method-call open is

received ( f alse otherwise) and the data holding the

information maintained by the server.

Listing 2: Server Type Speciﬁcation.

1 component s erve r (int n u mOf Por ts ){

2 bool o pene d [ n umO f Po r ts ] = fa l se ;

3 int d a ta = 1;

4 provided port s erv i ce [ n um O fPo rts ] {

5 @interaction{waits: o pene d [ @ ] = = f a lse ;}

6 @functional{

7 ensures: post ( o pene d [@ ]) := t r ue ;}

8 void o p en ();

10 @interaction{waits: op en ed [ @] == t r ue ;}

11 @functional{

12 ensures: post ( o pene d [@ ]) := f alse ;}

13 void c lo se ( ) ;

15 @interaction{waits: o pene d [ @ ] == tr u e ;}

16 @functional{ensures:\ res ul t := data ;}

17 int r equ e st ();

18 }

19 }

The server includes an array of provided ports service

(lines 4-18) each of which is to receive method-calls

from a required port of the client. Note that the server

ports are connected with the client ports via the con-

nectors which we will discuss shortly. The interaction

(ICWaits) and functional constraints (FCRequires

pre-condition and FCEnsures post-assignment) at-

tached to the service port methods serve to meet the

goal: requests for services can be received after the

respective connection is opened. The method open of

the port service[@] (lines 5–8) is delayed by ICWaits

until the data opened[@] is f alse. Upon receipt of

the request, if the FCRequires is satisﬁed, FCEnsures

post-assignment is performed. So, since FCRequires

is not speciﬁed for the method open (i.e., therefore,

true), FCEnsures assigns true to the data opened[@]

directly. Then, the response is sent back with no re-

sult due to the method open holding void type. For

the method close (lines 10–13), its requests are de-

layed until the opened[@] is true. When received,

FCEnsures assigns f alse to the same data directly

again, and, the response is sent. The calls for the

method request (lines 15–17) are also delayed until

the data opened[@] is true. Then, FCEnsures assign

the value of data to result that is sent back to the client

port. Note that provided ports process method opera-

tions atomically; that is, upon receiving a request suc-

cessfully, the response is to be sent back immediately.

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

370

2.1.3 MixedComponent Component

Listing 3 gives the mixedComp component type spec-

iﬁcation which represents those acting both as server

and clients (i.e., Doctrine Authoring, Track Server,

and Geo Server) That is, they not only require ser-

vices from outside, but also offer too.

The component state is represented via three data

variables (lines 2–3): the server opened array vari-

able holds for each server port true if a method-call

is received for open. The data openedConns holds

the number method-calls made for open via the client

ports. Finally, the data holds any information main-

tained by the component.

Listing 3: Mixed-Component Type Speciﬁcation.

1 component m ix e dCo mp (int CSi z e ,int SS i ze ){

2 bool s e rv e r_ ope ned [ SS i ze ] = f alse ;

3 int o p en e dC o nns = 0 , d a ta = 3;

4 required port cl i ent [ C S ize ]{

5 @interaction{waits: o pe n ed C on n s < C Si ze ;}

6 @functional{ensures: post ( op ene dCo nns ) ++ ;}

7 void o p en ();

9 @interaction{waits: o pe n ed C on n s > 0;}

10 @functional{ensures: post ( op ene dCo nns ) - -;}

11 void c lo se ( ) ;

13 @interaction{waits: o pe n ed C on n s == CSi z e ;}

14 @functional{ensures: post ( d at a ):= r e sult ;}

15 int r equ e st ();

16 }

17 provided port se r ver [ S S ize ]{

18 @interaction_req{

19 waits: o pe n ed C onn s == CSi z e

20 && se rv e r_ o pe n ed [ @ ]== fals e ;}

21 @functional_req{

22 ensures: po s t ( s e rv er_ ope ne d [ @ ] ): = tr u e ;}

23 void o p en ();

25 @interaction_req{

26 waits: o p en e dC o nn s == CSiz e &&

27 se rve r_o pe n ed [ @] == true ;}

28 @functional_req{

29 ensures: po s t ( s e rv er_ ope ne d [ @ ] ): = f a ls e ;}

30 void c lo se ( ) ;

32 @interaction_req{

33 waits: s e rv er_ ope ned [ @ ] = = t r u e &&

34 op e ne d Co n ns == C Size ;}

35 @functional_res{ensures:\ res ul t := d a ta ;}

36 int r equ e st ();

37 }

38 }

The mixedComp has an array of required ports client

(lines 4–16) with the size equal to the component pa-

rameter CSize. Herein, the ports client[@] behave in

the same way as those of the client component type

aiming to meet the same goal.

There is also an array of provided ports server

speciﬁed (lines 17–37) with the size equal to the SSize

parameter. The ports server[@] comprises complex

methods, i.e., upon successful receipt of the request,

the response does not have to be sent immediately,

as the component may need to require some services

via its client ports, to calculate the response result. In

complex method speciﬁcations, interaction and func-

tional contracts are split into two atomic parts: the

request part (∗ req) evaluated upon the receipt of the

method request and the response (∗ res) part eval-

uated when the port is ready to send the method

response. The methods of the server ports are at-

tached with such contracts to meet the goal: the

ports server[@] may not operate until all the client

ports open their connections. To this end, the request

ICWaits for the method open (lines 18–23) delays

the method request until the openedConns is equal to

the CSize and the respective data server opened[@] is

f alse. Upon receiving the method request, the request

FCEnsures assigns true to the server opened[@] di-

rectly as the request FCRequires is not speciﬁed (i.e.,

therefore, true). There is no constraints speciﬁed for

the method response, indicating that it may be sent

back randomly at any time after receiving the request.

The server port operates the method close (lines 25–

30) in the opposite way of the open, receiving the

request when the server opened[@] is true; and the

request FCEnsures of the close assigns f alse to the

same data. For the method request, its request is

accepted when the port’s already received a call for

open (i.e., server opened[@] is true) and all of the

clients’ve called open (i.e., the openedConns being

equal to CSize is true). Unlike the open and close,

the method request (lines 32–36) is attached with a

@functional_res that includes FCEnsures to assign

the value of data to the result directly. Indeed, its re-

turn type is int requiring a result to be sent back in the

response.

2.1.4 Client2Server Connector

The connectors of the Client2Server type essentially

represent the complex interactions between client and

server components.

The Client2Server is speciﬁed with two roles and

one built-in connector. The role client is played by the

participating client component, while the role server

by the participating server component. Note also that

the mixedComp components can play either of the

roles in their interaction. Each role comprises data-

variables representing their local state and a set of

port-variables representing the ports of the compo-

nents. The port-variables attach the port methods with

@interaction contracts that comprise interaction con-

straints further constraining the method behaviours.

Unlike port interaction constraints, the port-variable

ArchitecturalSpecificationandAnalysiswithXCD-TheAegisCombatSystemCaseStudy

371

interaction constraints may update the role state data

too via their post-assignments and, thereby, compris-

ing a pair of RICWaits and RICEnsures in Figure 1.

The role client (lines 3–18) imposes on the client

an interaction protocol that the client may not request

a service of the server before opening the connection

of the respective server. To this end, the role client

has a single data opened. Its port-variable service

imposes interaction constraints on the methods. So

the method open of the associated port may not be

called until the opened is f alse (RICWaits). Upon the

satisfaction of the interaction constraints, the respec-

tive post-assignment (RICEnsures) assigns true to the

same data. This then allows the methods request and

close to be called, whose role interaction guards delay

them until the opened is true. Note also that the inter-

action constraint on the close has RICEnsures that as-

signs f alse to the opened allowing the method open

to be called again.

The role server (lines 19–25) does not impose any

interaction constraints on its port-variable methods

allowing the associated component ports to receive

method requests in any order.

There is a built-in connector speciﬁed (lines 26–

27) which represents the communication link between

the role port-variables. Therefore, the component port

represented by the service port-variable of the server

role may communicate with the component port rep-

resented by the service port-variable of the client role.

The matching between component ports and role

port-variables are performed when the connector is

instantiated in composite components and compo-

nents are passed as parameters (see Section 2.1.5).

Listing 4: Client2Server Type Speciﬁcation.

1 connector cl i en t 2s erv er ( c lien t { s e rvi c e },

2 ser v er { s ervi ce } ) {

3 role c lien t {

4 bool o pene d := fals e ;

5 required port_ v ari abl e s e rvi c e {

6 @interaction{

7 waits: op e ned == f a ls e ;

8 ensures: post ( o pene d ):= true ;}

9 void o p en ();

10 @interaction{

11 waits: op e ned == tru e ;

12 ensures: post ( o pene d ):= fa l se ;}

13 void c lo se ( ) ;

14 @interaction{

15 waits: op e ned == f a ls e ;}

16 int r equ e st ();

17 }

18 }

19 role s erve r {

20 provided port_ v ari abl e s e rvi c e {

21 void o p en ();

22 void c lo se ( ) ;

23 int r equ e st ();

24 }

25 }

26 connector l i nk ( cli en t { se rvic e },

27 ser v er { s ervi ce } ) ;

28 }

2.1.5 Aegis Conﬁguration Component

Unlike the client and server component types, the

aegis con f iguration is a composite type that consists

of component and connector instances representing

an architectural conﬁguration for the Aegis.

The aegis con f iguration includes a component

instance for each component depicted in the Figure 2.

There is also a set of connector instances speciﬁed

that represent the interactions between those compo-

nent instances. Note that the connector instances re-

ceive as parameters the participating components and

their ports (component{portList}). Indeed, this is

how connector roles and their port-variables are as-

sociated with the components and their ports.

Listing 5: Composite Component Type Speciﬁcation.

1 component ae gis _c o nf ig u ra ti o n (){

2 component se r ver e_C t rl (3);

3 component mi xed Com p d _ Auth (1 ,3);

4 component cl i ent d_V alid ( 3 );

5 component mi xed Com p t _ Srvr (1 ,3);

6 component mi xed Com p g _ Srvr (2 ,1);

7 component cl i ent d_ R son ing ( 3 );

8 connector c l ie n t2 ser ver cs_ 1 (

9 d_Au t h { cl i ent [0]} , e_ C trl { s erv i ce [0 ]} );

10 connector c l ie n t2 ser ver cs_ 2 (

11 d_V a lid { se r vic e [0]} , e _ Ctrl { se r vic e [1 ] });

12 connector c l ie n t2 ser ver cs_ 3 (

13 t_Sr v r { cl i ent [0]} , e_ C trl { s erv i ce [2 ]} );

14 connector c l ie n t2 ser ver cs_ 4 (

15 d_V a lid { se r vic e [1]} , d _ Auth { se r ver [ 0 ]});

16 connector c l ie n t2 ser ver cs_ 5 (

17 d_V a lid { se r vic e [2]} , t _ Srvr { se r ver [ 0 ]});

18 connector c l ie n t2 ser ver cs_ 6 (

19 d_R son i ng { ser vice [0]} , d _ Auth { se r ver [ 1 ]});

20 connector c l ie n t2 ser ver cs_ 7 (

21 g_Sr v r { cl i ent [0]} , d_ A uth { s erve r [2] }) ;

22 connector c l ie n t2 ser ver cs_ 8 (

23 d_R snin g { se rvic e [1]} , t_ Srvr { ser v er [1 ] });

24 connector c l ie n t2 ser ver cs_ 9 (

25 g_Sr v r { cl i ent [1]} , t_ S rvr { s erve r [2] }) ;

26 connector c l ie n t2 ser ver cs _ 10 (

27 d_R snin g { se rvic e [2]} , g_ Srvr { ser v er [0 ] });

28 }

3 FORMAL MODELLING/

REPRESENTATION

We implemented the semantics of XCD in SPIN’s for-

mal ProMeLa language (Holzmann, 2004) which en-

ables formal reasoning about XCD speciﬁcations. We

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

372

chose ProMeLa due to two main reasons. XCD se-

mantics match those of ProMeLa well, facilitating

the transformation from XCD constructs to ProMeLa.

Finally, ProMeLa is supported by a powerful model

checker whose implementation is open. The rest of

this section summarises at an abstract level how com-

ponents and connectors can be mapped to ProMeLa

notation.

3.1 Transforming XCD to ProMeLa

3.1.1 Composite Component Transformation

A composite component c is mapped as shown in

Listing 6. A request and response asynchronous chan-

nel arrays are produced from each sub-component

provided port (lines 3–6). The arrays include a dis-

tinct channel for each required port connected to the

provided port via built-in connectors. As shown in

the port semantics, these channels are used by the

provided ports and the connected required ports of

other sub-components, to transfer request and re-

sponse messages. Then, a process is declared for the

composite component c (lines 7–10) that executes via

ProMeLa’s run operator the processes corresponding

to its sub-components and thereby enables their con-

current interaction.

Listing 6: Composite Component semantics in

ProMeLa.

1 f orall su bcom p ∈ c . c o mpo nen ts

2 f orall pp ∈ s ubco mp . P ro v id e dP o rt s

3 chan re q ue stC han ne l [ pp . n um O fCo nns ]

4 = [1 ] of { R e que s t };

5 chan re s po nse Ch a nn e l [ pp . nu mOf C on n s ]

6 = [1 ] of { R e spo nse };

7 proctype c. ID (){

8 f orall s u bco m p ∈ c . co mpo n en t s

9 run s ubc o mp . ID ();

10 }

3.1.2 Primitive Component Transformation

A primitive component c is mapped as shown in

Listing 7. The process declaration comprises a set

of variable declarations corresponding to component

data and the data of the role(s) the component

assumes (lines 3–5). Each component data is mapped

to two variables, one for storing the pre-state and the

other for its post-state value. Besides data variables,

a repetition construct (i.e., do..od) is included (lines

7–9) that repeatedly executes a set of guarded action

sequences for the component port behaviours.

Listing 7: Primitive Component semantics in

ProMeLa.

1 proctype c. ID (){

2 f orall dat a ∈ c . D at a

S S

c.roleSet

role . D a t a

3 d at a . type data . p re_ sta t e

4 = d at a . i n it i al V al ue ;

5 d at a . type data . p ost _st ate ;

6 S tart :

7 do

8 .. . ... ...

9 od

10 }

Listing 8 shows that each method of a required

port is transformed into two guarded atomic actions.

The request action (lines 3–8) is guarded by the as-

sign params method

that selects method parame-

ters via the functional constraint FCPromises. Then,

if the chosen parameters satisfy the port interaction

constraint ICWaits and the role interaction constraint

RICWaits guards, the request message is written to

the requestChannel (line 7), and, the port holds the

lock. Otherwise, control moves back to the beginning

of the component repetition construct executing the

port behaviour (line 6 in Listing 7). The response ac-

tion (lines 12–20) is guarded by the responseChannel

which is satisﬁed if the channel includes a response

message and the port holds the lock. Upon reading the

response, if the functional constraint pre-condition is

met (FCRequires), the assign data method is used

that updates component and role data via the con-

straint post-assignments (FCEnsures and RICEnsures

respectively).

Listing 8: Required Port semantics in ProMeLa.

1 f orall rp ∈ c . R e qu ire dPo rt s

2 f orall m ∈ rp . M e tho d s

3 ::atomic{

4 as sig n_p ar a ms (FCPromises) →

5 if

6 ::ICWaits ∧

c.roleSet

RICWaits →

7 r eq u es t Ch ann el ! m , m . p a ra m ete rs ;

8 loc k = true ;

9 ::else→ goto St a rt

10 fi

11 }

12 ::atomic{

13 re spo ns e Ch ann el ? m , m. r esul t ∧lo c k →

14 if

15 ::FCRequires→

16 as s ig n _d a ta (FCEnsures);

17 f orall r o l e ∈ c . ro l eSe t

18 as s ig n _d a ta (RICEnsures);

19 fi

20 }

The methods assign params and assign data represent

an iterative execution of ProMeLa’s select statement to im-

plement each assignment of the inputted sequence.

ArchitecturalSpecificationandAnalysiswithXCD-TheAegisCombatSystemCaseStudy

373

Provided port methods are each mapped to a single

atomic action as shown in Listing 9. The action is

guarded by the requestChannel which is satisﬁed if

there exist a request message that meets the port in-

teraction constraint (ICWaits) and the role interac-

tion constraint guards (RICWaits). Upon satisfaction

of the guards, the component and role data are up-

dated through the constraint post-assignments (lines

6-8), and, subsequently, the result is written to the re-

sponseChannel (line 9).

Listing 9: Provided Port semantics in ProMeLa.

1 f orall pp ∈ c . P r ov ide dPo rt s

2 f orall m ∈ pp . M e tho d s

3 ::atomic{

4 re que st C ha n ne l ? m ,m . p a ram ete rs

5 :ICWaits ∧

c.roleSet

RICWaits →

6 as s ig n _d a ta (FCEnsures);

7 f orall r o l e ∈ c . ro l eSe t

8 as s ig n _d a ta (RICEnsures);

9 re sp o ns e Ch ann el ! m ,m . resu lt

10 }

Complex methods of provided ports are each

mapped to two separate atomic actions as shown in

Listing 10, one for receiving the request and another

for sending the response. Just like the simple method,

the top request action (lines 3–10) is guarded by the

requestChannel which is satisﬁed if there exists a re-

quest that meets request interaction constraint guards.

Then, the component and role data are updated via the

constraint post-assignments on the method request;

and, the request ﬂag is set to true. The bottom re-

sponse action (lines 11–19) is executed if the interac-

tion guards on the method response part are met and

the method request has been received. Then, again,

the component and role data are updated via the post-

assignments on the method response. Finally, the re-

sponse is written to the responseChannel.

Listing 10: Provided Port semantics in ProMeLa–

Complex Methods.

1 f orall pp ∈ c . P r ov ide dPo rt s

2 f orall m ∈ pp . C om p le x Me tho ds

3 ::atomic{

4 re que st C ha n ne l ? m ,m . p a ram ete rs

5 :ICWaits

req

∧

c.roleSet

RICWaits

req

→

6 a ssi gn_ dat a (FCEnsures

req

);

7 f orall r o l e ∈ c . ro l eSe t

8 a ssi gn_ dat a (RICEnsures

req

);

9 r equ e st e d

:= tru e ;

10 }

11 ::atomic{

12 ICWaits

res

∧

c.roleSet

RICWaits

res

13 ∧r e que ste d

→

14 a ssi gn_ dat a (FCEnsures

res

);

15 f orall r o l e ∈ c . ro l eSe t

16 a ssi gn_ dat a (RICEnsures

res

);

17 r equ e st e d

:= fa ls e ;

18 r es p on seC ha n ne l ! m , m. r e sult }

4 AUTOMATED FORMAL

VERIFICATION

A tool is available (Ozkaya, 2013) to automatically

translate XCD speciﬁcations into formal ProMeLa

models. These produced models can be directly veri-

ﬁed by the SPIN model checker.

Having transformed the Aegis speciﬁcation in

Section 2.1 into a ProMeLa model via the tool, we

were able to formally verify it via the model checker.

Table 1 shows the veriﬁcation results – no deadlock

was identiﬁed

Table 1: Veriﬁcation results for Aegis.

State-vector States Memory Time

(in Bytes) Stored Matched (in MB) (in seconds)

524 16734505 90863348 7024 62.7

Formal veriﬁcation of software architectures is

highly crucial for many reasons. Firstly, It aids in de-

tecting design errors, e.g., incompatible component

behaviours, causing deadlocks. If such issues were

left to the implementation stage, the cost of correct-

ing the errors would highly increase. Furthermore,

different design choices can easily be explored that

enables to determine the optimal one. Indeed, the cur-

rent Aegis model in Section 2.1 includes in compo-

nents a single port that has all three methods (open,

close, and request). However, this choice of design

minimises the level of concurrency. In XCD, each port

operates its method sequentially while the ports are

operated concurrently by the components. So, design-

ers may wish the components to operate port meth-

ods concurrently. In such a case, a distinct port is

created per method. That is, client and server have

three ports each including a unique method. When we

analyse our modiﬁed model with this design choice,

the state-vector size nearly doubles as shown in Ta-

ble 2; indeed, fewer number of states could be stored

in the same amount of memory. This is because each

newly added provided port introduces extra commu-

nication channels which causes the state-vector size

to grow. Thus, while maximised concurrency may be

a desired choice for designers, it requires greater state

space and memory for formal veriﬁcation.

Table 2: Veriﬁcation results – Maximised Concur-

rency.

State-vector States Memory Time

(in Bytes) Stored Matched (in MB) (in seconds)

1024 8350876 47805585 7024 48.1

Our veriﬁcation is limited with 7024MB of memory;

for a full veriﬁcation, more memory seems to be required.

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

374

5 EVALUATION – XCD VS

WRIGHT

As aforementioned, Aegis has also been speciﬁed

and analysed with Wright (Allen, 1997). We base

our comparison with Wright’s Aegis speciﬁcation on

three key features that, we believe, affect designer’s

choice in choosing an ADL to use.

Realisable connectors As mentioned in our ADL

study (Ozkaya and Kloukinas, 2013a), Wright and

those inspired from it include a glue in their connector

structure which constrains the behaviour of the com-

ponents globally. However, its global nature causes

potentially unrealisable speciﬁcations for distributed

systems, as explained in (Ozkaya and Kloukinas,

2013b). Indeed, the Aegis connector in (Allen and

Garlan, 1996) includes such a glue for coordinating

the client and server component behaviours. There-

fore, XCD connectors may only impose local con-

straints on the components via the roles; glues are not

allowed. As shown in Section 2.1, the client2server

connector has roles with local constraints only.

DbC-based behaviour speciﬁcation To enable

formal reasoning, Wright adopts an extended form of

the CSP process algebra for behaviour speciﬁcation.

So Aegis is speciﬁed using CSP which is not found

practical by practitioners (Malavolta et al., 2012). In

XCD, the behaviour of components and connectors are

speciﬁed in an extended form of Design-by-Contract

(DbC) approach which is more familiar to developers

and easier to learn for them. For example, JML has

been taught to undergraduate students for a number of

years (Kiniry and Zimmerman, 2008).

SPIN’s Promela as the formal basis The seman-

tics of XCD are deﬁned using ProMeLa which allows

the use of a free and open tool for analysing architec-

tures.

6 CONCLUSIONS

XCD is a new ADL that extends Design-by-Contract

approach and enables contractual architecture spec-

iﬁcation. While the functional and (minimal) inter-

action behaviours of components are speciﬁed via

functional and interaction contracts respectively, the

interaction protocols of connectors are via interac-

tion contracts. Connectors in XCD are decentralised

and do not impose global constraints on the compo-

nents. In this way, the common problem of connector-

supporting ADLs – potentially unrealisable software

architectures – is avoided. XCD comes with a tool that

translates architectures into ProMeLa models, which

can be analysed by the SPIN model checker. As a fur-

ther work, we are considering to improve our tool-set

so that visual architecture speciﬁcation can be possi-

ble. Designers might feel more comfortable if they

could specify the structure of their components and

connectors diagrammatically and attach contracts to

them via a graphical user interface.

REFERENCES

Allen, R. and Garlan, D. (1996). A case study in architec-

tural modelling: The aegis system. In Proceedings of

the Eighth International Workshop on Software Spec-

iﬁcation and Design (IWSSD-8), pages 6–15, Pader-

born, Germany.

Allen, R. J. (1997). A formal approach to software architec-

ture. PhD thesis, Pittsburgh, PA, USA. AAI9813815.

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.

Hoare, C. A. R. (1978). Communicating sequential pro-

cesses. Commun. ACM, 21(8):666–677.

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

and reference manual. Addison-Wesley.

Kiniry, J. R. and Zimmerman, D. M. (2008). Secret Ninja

Formal Methods. In Cu

ellar, J., Maibaum, T. S. E.,

and Sere, K., editors, FM, volume 5014 of Lecture

Notes in Computer Science, page 214228. Springer.

Magee, J. and Kramer, J. (2006). Concurrency – State mod-

els and Java programs (2. ed.). Wiley.

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.

Ozkaya, M. (2013). XCD website.

http://www.soi.city.ac.uk/

abdz276/xcd.html.

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

yet? analyzing architecture description languages

for formal analysis, usability, and realizability. In

Software Engineering and Advanced Applications

(SEAA), 2013 39th EUROMICRO Conference on,

pages 177–184.

Ozkaya, M. and Kloukinas, C. (2013b). Towards a design-

by-contract based approach for realizable connector-

centric software architectures. In ICSOFT, pages 555–

562.

Rumbaugh, J. E., Jacobson, I., and Booch, G. (1999).

The uniﬁed modeling language reference manual.

Addison-Wesley-Longman.

ArchitecturalSpecificationandAnalysiswithXCD-TheAegisCombatSystemCaseStudy

375