Architectural Specification 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 verification 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 specified formally, can be analysed me-
chanically thus enabling the detection of errors long
before the implementation phase.
Unified Modelling Language (UML) (Rumbaugh
et al., 1999) gained wide popularity in modelling de-
sign of software systems. Despite partially serving
the first 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 specified with contracts, but,
in a more systematic and comprehensive way. In-
deed, we consider a number of extensions to DbC
facilitating the specification of components and con-
nectors. To enable formal verification 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
1
. 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-
1
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 Specification 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
Copyright
c
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 specifications 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 firstly been
tackled by Wright (Allen, 1997) in (Allen and Gar-
lan, 1996), which can informally be specified 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 Specification 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 specified 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 configuration of client, server, and mixed-
Comp components interacting via the client2server
connectors.
2.1.1 Client Component
Listing 1 gives the client component type specifica-
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 specified 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 Specification.
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 ();
11
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 ( ) ;
17
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 specified 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 firstly 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[@]
2
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 satisfied, 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 specified (i.e., there-
fore, true) for the open, its FCEnsures increments
the openedConns.
3
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 specification from
which server components (i.e., Experiment Control)
2
@ symbol used inside contracts represents the index of
the executing port, where 0 @numO f Ports 1.
3
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 specified 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 Specification.
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 ();
9
10 @interaction{waits: op en ed [ @] == t r ue ;}
11 @functional{
12 ensures: post ( o pene d [@ ]) := f alse ;}
13 void c lo se ( ) ;
14
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 satisfied, FCEnsures
post-assignment is performed. So, since FCRequires
is not specified 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-
ification 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 Specification.
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 ();
8
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 ( ) ;
12
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 ();
24
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 ( ) ;
31
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
specified (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 specifications, 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 specified (i.e.,
therefore, true). There is no constraints specified 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 specified 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 specified (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 Specification.
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 Configuration 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 configuration 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 specified
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 Specification.
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 specifications. 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
4
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 satisfied 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
V
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 }
4
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 satisfied 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
V
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 satisfied 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 flag 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
V
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
m
:= tru e ;
10 }
11 ::atomic{
12 ICWaits
res
V
c.roleSet
RICWaits
res
13 r e que ste d
m
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
m
:= 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 specifications into formal ProMeLa
models. These produced models can be directly veri-
fied by the SPIN model checker.
Having transformed the Aegis specification 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 verification results no deadlock
was identified
5
.
Table 1: Verification results for Aegis.
State-vector States Memory Time
(in Bytes) Stored Matched (in MB) (in seconds)
524 16734505 90863348 7024 62.7
Formal verification 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 modified 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 verification.
Table 2: Verification results Maximised Concur-
rency.
State-vector States Memory Time
(in Bytes) Stored Matched (in MB) (in seconds)
1024 8350876 47805585 7024 48.1
5
Our verification is limited with 7024MB of memory;
for a full verification, 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 specified
and analysed with Wright (Allen, 1997). We base
our comparison with Wright’s Aegis specification 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 specifications 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 specification To enable
formal reasoning, Wright adopts an extended form of
the CSP process algebra for behaviour specification.
So Aegis is specified using CSP which is not found
practical by practitioners (Malavolta et al., 2012). In
XCD, the behaviour of components and connectors are
specified 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 defined 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-
ification. While the functional and (minimal) inter-
action behaviours of components are specified 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 specification 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-
ification 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 specification and ver-
ification 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 classification
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 unified modeling language reference manual.
Addison-Wesley-Longman.
ArchitecturalSpecificationandAnalysiswithXCD-TheAegisCombatSystemCaseStudy
375