A Modular Method for Global System Behaviour Speciﬁcation

Urooj Fatima and Rolv Bræk

Department of Telematics, Norwegian University of Science and Technology (NTNU), NO-7491, Trondheim, Norway

Keywords:

Model-driven Engineering, Service Composition, Interface Behaviour, Activity Diagrams.

Abstract:

The challenge addressed in this paper is how can we specify the global behaviour of distributed reactive

systems in a way which eases the comprehension of the system without compromising its speciﬁcation’s

correctness, completeness, modularity and readability. Instead of deﬁning the global behaviour models in a

monolithic way, we approach the problem by decomposing the speciﬁcation into interface functionality and

core functionality. The resulting interface-modular method for system speciﬁcation is presented and discussed

in this paper using a TaxiCentral as case study. The novelty of this method lies in the clear separation of

interfaces from core functionality in global speciﬁcation, and the use of activity diagrams in combination with

collaborations to express and compose the speciﬁcations.

1 INTRODUCTION

Normally in system development, after requirements

have been captured and analysed, the desired sys-

tem behaviour is ﬁrst speciﬁed from a global, cross-

cutting, perspectiveinvolvingseveral entities and then

mapped to a design structure of components with

precisely deﬁned local component behaviours. The

global behaviour emerging from the joint local com-

ponent behaviours shall of course correspond to the

speciﬁed global behaviour. Such correspondence can

be assured in two ways: (1) by a process of veriﬁca-

tion, that is verifying after a design has been devel-

oped, that the local behaviours of the designed com-

ponents are in accordance with the speciﬁcation; or

(2) by a process of design synthesis (transformation)

whereby the local designs are derived from speciﬁ-

cations in such a manner that correctness is guaran-

teed. Most current system design methods follow the

ﬁrst approach because fully automated design synthe-

sis has not been practically feasible. There are two

main reasons for this:

a. it is normally very difﬁcult and/or impractical to

completely specify global behaviours.

b. the global behaviour emerging from a direct map-

ping to a distributed design may contain undesired

behaviours that follow from the nature of a dis-

tributed design and not from the speciﬁcation it-

self. This kind of behaviour, sometimes referred

to as implied scenarios, is the cause of so-called

realizability problems.

In order to solve problem ‘b’ mentioned above it is

necessary that all realizability problems can be iden-

tiﬁed and resolved as part of the design synthesis pro-

cess. In (Castej´on et al., 2007) the authors provide a

classiﬁcation of the various causes of such problems

and explain how problems can be detected on the level

of global behaviour and subsequently resolved during

design. Based on this foundation (Kathayat and Bræk,

2011) has proposed some reﬁnements to the analysis

while (Kathayat et al., 2011) and (Fatima and Bræk,

2013) deﬁned a method for design synthesis using ac-

tivity diagrams for both global (source) and local (tar-

get) behaviour where the resulting local behaviour is

in a form of activity diagrams that can be subject to

extensive analysis before generating product quality

(Java) code using a tool called Reactive Blocks (Re-

activeBlocks, 2014). Thus, there is now a systematic

way to overcome problem ‘b’ and principal solutions

to enable highly automated design synthesis.

In this paper, we focus on problem ‘a’ mentioned

above - how to achieve the necessary completeness,

rigour and modularity in global behaviour speciﬁca-

tions to enable highly automatic design synthesis in

practice?

Sequence diagrams of some sort are probably the

most used notations for global behaviour. They de-

ﬁne behaviour in terms of interactions taking place

among different components of a system and/or its

environment, either in the form of asynchronous mes-

sage passing or in the form of synchronous invoca-

tions. They are well suited for speciﬁcations since

490

Fatima U. and Bræk R..

A Modular Method for Global System Behaviour Speciﬁcation.

DOI: 10.5220/0005245104900497

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 490-497

ISBN: 978-989-758-083-3

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

they consider systems and components from the out-

side and describe only their externally visible be-

haviour. Purely sequential behaviours are easy to

specify completely using sequence diagrams. It is

concurrency that causes problems. The service pro-

vided by a distributed reactive system normally in-

volves several concurrent parts. The number of pos-

sible and relevant interaction orderings is then often

beyond what is practically feasible to specify, and

therefore completeness is not achieved. The general

countermeasure for this kind of problem is to factor

out concurrency and thereby reduce the number of in-

teraction orderings needed to be explicitly modelled.

Rather than considering global behaviours involving

many concurrent parts, one may consider only two

parts at a time and their interface behaviour, possibly

decomposed further into smaller and more manage-

able sub-behaviours. This kind of decomposition fol-

lows naturally from the use of collaborations to struc-

ture and decompose global behaviours as we shall see

in the following. The remaining problem then is to

model the dependencies and global ordering among

the interface behaviours.

Even when completely deﬁned, interactions are

not sufﬁcient to fully specify the behaviour of sys-

tems and components. In many cases some internal

data and data manipulation is equally important to the

environment and the users of a system and therefore

need to be speciﬁed as well. We are not considering

internal design details here, only the data and oper-

ations that are important and give value to end users

and other systems in the environment are considered.

From this we deduce that a complete speciﬁcation

needs to cover (at least) two related aspects: the ex-

ternal interactions and their ordering; and the inter-

nal data and operations that give value to the envi-

ronment, which is called the core functionality in the

following. There are (at least) two ways to organise

such speciﬁcations:

1. the integrated approach in which the core func-

tionality is embedded with interactions in one

(large) speciﬁcation,

2. the interface-modular approach where core func-

tionality and interfaces are speciﬁed separately

and then combined.

The second approach is the topic and main contri-

bution of this paper (The authorshave previously used

the integrated approach and found it feasible, but hard

and error prone to develop). The interface-modular

approach is promising because it simpliﬁes the pro-

cess of developing complete speciﬁcations and also

results in more modular speciﬁcations. As it turns

out, the core functionality models serve both to spec-

Problem Domain

Taxi Dispatcher (TD)

Taxi (T)

User (U)

Core

Functionality

TD TD

Functional Speciﬁcation

Interface Functionality

act

U-TD

U TD

act

TD-T

U TD

act

U-TD

U TD

act

TD-T

U TD

Localization and Component Derivations

U TD

Composition of Interface Functionality and Core Functionality

Code Generation

Functional Requirements

Figure 1: The overall illustration of the proposed method.

The area highlighted with grey background is the focus of

this paper.

ify the core functionality itself independently of par-

ticular interfaces, and as a glue taking care of the de-

pendency among interfaces.

The main properties of the method are the follow-

ing:

- It simpliﬁes achieving completeness in functional

speciﬁcations.

- It covers interface functionality as well as core

functionality.

- It deﬁnes interface functionality and core func-

tionality in separate modules that are partly inde-

pendent and may be composed in different ways.

- It speciﬁes interface behaviours in a form that

later can be used as contracts for lookup and vali-

dation purposes.

We use UML activities to deﬁne behaviour be-

cause they provide the ordering constructs needed for

our purpose and allow us to stay within one notation

for both global and local behaviours. Moreover, they

support building blocks of variable granularity with

AModularMethodforGlobalSystemBehaviourSpecification

491

well deﬁned interfaces suitable for composing the in-

terfaces and core functionality.

Figure 1 serves to illustrate the approach in terms

of a TaxiCentral that shall be used as a running ex-

ample throughout the rest of the paper. The rest of

the paper is organized as follows. The functional re-

quirements of the TaxiCentral are presented in Sec-

tion 2. In Section 3, we present our interface-modular

method by explaining the guidelines and applying

them on the TaxiCentral. Section 4 explains our

method validation. We discuss related work in Sec-

tion 5 and conclude in Section 6.

2 FUNCTIONAL

REQUIREMENTS

Functional requirements normally contain an infor-

mal textual speciﬁcation of the core functionality (in

terms of events, data and operations).

In the TaxiCentral, Users can book Taxis by plac-

ing taxi-booking requests to a TaxiDispatcher. Taxis

inform the TaxiDispatcher about their availability.

The TaxiDispatcher keeps an overview of available

Taxis and assigns Taxis to Users as fairly as possible.

Once a Taxi is assigned to a User, it can contact the

User via phone call.

The TaxiDispatcher is driven by events generated

by users and taxis and communicated across the in-

terfaces as messages represented by the tokens in the

activity diagrams. The functional requirements given

below are organized according to the external events

and specify the actions to be taken in response. Itali-

cized items represent important domain entities and

data. Italicized bold items represent important do-

main events.

A. TaxiRequest. The User initiates the taxi-booking

request by sending a request to the TaxiDis-

patcher. As a result, either of the following two

responses shall be generated:

A1. TaxiAssign. If a Taxi is available, the Taxi shall

be taken out of the taxi queue by the TaxiDis-

patcher and assigned to the User.

A2. UserWait. If a Taxi is not available, the User

shall be entered in a user queue and receive

wait notiﬁcation from the TaxiDispatcher, in-

dicating the position in queue.

B. TaxiAvailable. The Taxi updates its availability

status to the TaxiDispatcher. As a result, either of

the following two responses shall be generated:

B1. UserAssign. If a User is waiting in the user

queue, the User shall be taken out of the user

queue and assigned to the available Taxi.

TaxiCentral

User

Taxi

act

User-TD

act

Taxi-TD

act

Taxi-User

pc:

PhoneCall

ts:

TaxiStatus

tr:

TaxiReq

uw:

UserWait

gt:

Grant

tw:

TaxiWait

sz:

Seize

uwd:

UserWithdraw

twd:

Taxi

Withdraw

rqr

rqe

uwr

uwe

uwdr

uwde

twdr

twde

twr

twe

str

ste

Figure 2: UML collaboration diagram showing roles and

collaboration uses in interfaces of TaxiCentral service.

B2. TaxiWait. If no User is waiting in the user

queue, the TaxiDispatcher shall insert the Taxi

reference in a taxi queue and send wait notiﬁca-

tion to the Taxi. The Taxi may receive its queue

position.

C. UserWithdraw. The User can withdraw its re-

quest while waiting in the user queue. Its refer-

ence shall then be removed from the queue by the

TaxiDispatcher.

D. TaxiWithdraw. The Taxi can withdraw while

waiting in the taxi queue. The TaxiDispatcher

shall then remove its reference from the taxi

queue.

The TaxiCentral is not a trivial example since it

has to deal with: (1) the multiplicity of taxis and

users; (2) the queues and other data needed in order

to coordinate users and taxis; (3) all the possible ways

that events generated by taxis and users may inter-

leave.

3 FUNCTIONAL SPECIFICATION

We consider a service here as a collaborative be-

haviour that may involve several components and

more than one interface. In our method, a service pro-

vided by a distributed reactive system is speciﬁed in

four steps: (1) the service structure is deﬁned using

UML collaboration diagrams; (2) the interface func-

tionality is deﬁned using UML activity diagram; (3)

the core functionality is deﬁned using UML activity

diagram; (4) the interface and core functionality is

connected. Each of these steps are illustrated in this

section using the TaxiCentral.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

492

act User-TD

tr.TaxiReq

User

uw.UserWait

User

gt.Grant

User

!!"#$"%&'())

"&*

uwd.User

Withdraw

User

+'#,-"./"0$

10"%2',$

+'#,34',('5("

+'#,300,6&

10"%2,$7*%'8

10"%9:&&";$"*

ts.TaxiStatus

Taxi

tw.TaxiWait

Taxi

sz.Seize

Taxi

act Taxi-TD

twd.Taxi

Withdraw

<<external>>

end

Taxi

!"#$%&"$'"(')

!"#$*"$+

!"#$,)-.)/+

0/)1%//$23

!"#$*$+451"6

!"#$7833)9+)5

(a) User-TD Interface Functionality Model. (b) Taxi-TD Interface Functionality Model.

Role 1

Role 2

Service

name

Terminating

Role

Initiating

Role

role

participation

Figure 3: Interface Functionality Models of TaxiCentral.

3.1 Service Structure

The method guidelines for creating the service struc-

ture (SS) are described below:

SS1: Use UML collaboration diagram to deﬁne the

structure of a service.

SS2: Identify the participants and interfaces of the

service from the functional requirements doc-

ument. Represent the participants as roles in

the collaboration diagram.

SS3: Decompose the service behaviour into

collaboration-uses, where each collaboration-

use encapsulates the interactions needed

to carry a domain event mentioned in the

requirements.

SS4: Bind the roles of each collaboration-use to the

roles of the main collaboration.

SS5: Indicate the initiating role of each

collaboration-use with a ﬁlled circle and

terminating role with a ﬁlled square

Filled circles and squares are not standard UML no-

tations, but can be provided by proﬁling. They represent

information needed during subsequent behaviour analy-

sis and design synthesis.

SS6: Add references to activity diagrams that will

deﬁne the behaviours of interfaces identiﬁed in

‘SS2’ (detailed in Section 3.2).

By inspecting the functional requirements given

in Section 2, three main roles are identiﬁed in the

TaxiCentral: the User, the Taxi and the TD (Taxi-

Dispatcher). Likewise, three interfaces are identiﬁed

namely: User-TD, Taxi-TD and User-Taxi. The UML

collaboration diagram of TaxiCentral is shown in Fig-

ure 2. Each collaboration-use, for instance TaxiReq,

UserWait, etc. encapsulates interactions needed to

carry the events of the TaxiCentral. The decompo-

sition of collaborations into roles and collaboration

uses is one important step towards mastering com-

plexity. Each elementary

collaboration involves only

two roles and has a limited complexity making a com-

plete deﬁnition of its behaviour practically feasible.

3.2 Interface Functionality

The method guidelines for interface functionality (IF)

are as follows:

We consider collaborations that are not further decom-

posed as elementary collaborations.

AModularMethodforGlobalSystemBehaviourSpecification

493

IF1: Develop activity diagrams of each interface

identiﬁed in ‘SS2’ and referenced in ‘SS6’.

IF2: Map the domain events, related to an interface,

from the requirements to pins

on the boundary

of that interface activity. The name of a pin

should correspond to a particular event.

IF3: Add a ‘CallBehaviourAction’ for each

collaboration-use performed on the interface.

IF4: Add partitions on each ‘CallBehaviourAction’

to indicate the participating roles. Mark the

initiating and terminating roles with ﬁlled cir-

cles and squares, respectively.

IF5: Make ﬂows and activity nodes to deﬁne the or-

dering of the CallBehaviourActions identiﬁed

in ‘IF3’ that can be enforced locally in the in-

terface. This may include interrupting regions

and interrupting ﬂows, forks, joins merges,

choices and other elements of UML activities.

IF6: For the ordering that is enforced externally,

make ﬂows to and from the corresponding pins.

In the case of data dependency, connect the

pins externally with dashed ﬂows representing

the external ordering required.

The activity diagrams can have all types of pins that

UML allows, i.e. initiating, terminating, streaming and

alternative pins.

The resulting interface functionality models for

the TaxiCentral are depicted in Figure 3. Note that an

interruptible region and interrupting ﬂows have been

used to specify that the UserWait collaboration-use

shall be terminated when a Taxi becomes available or

the User ends. The interruptible activity region is de-

picted by a dashed rectangle.

The dashed ﬂows in Figure 3 represent essentially

how the responses to incoming events shall be ordered

by the core functionality dependingon its data. Hence

they represent what we may call a data dependency.

In addition to data dependency there may be event de-

pendency when events on one interface trigger actions

on another interface. In the TaxiCentral, the arrival of

an available Taxi on the Taxi-TD interface shall lead

to actions on the User-TD interface, taking the user

out of queue and assigning the Taxi if there is a wait-

ing User. This case of event dependency is taken care

of by the un-connected input pin TaxiAvailable on the

User-TD interface. A corresponding event therefore

has to be generated by the core logic.

Development of interface behaviours separately is

much simpler and more manageable than to develop

a complete behaviour directly as in the integrated ap-

proach. Each of the two interfaces presented in Fig-

ure 3 is relatively simple and easy to understand even

!"#$

%&'(&)*

+,&-./

!"#$0

!"#$

12"$3"43&

+,&-./

5)&60

!"#$7"$*

!"#$"%&'(

!"#$%&%'('(

)*(+%&%'('(

&89*:

&89*:;<*/&89*:

;<*/&89*:

=>)&6*/5)&6/$>/

5)&60

=>)&6*/!"#$/$>/

!"#$0

5)&6

7$*,?6"@

!"#$

7$*,?6"@

%&8<2&

5)&6/A6<8/5)&60

%&8<2&

!"#$/A6<8/!"#$0

B*"6*

=>$*$"3/B&**$>C)

D#*6"-*

!"#$/A6<8/

!"#$0

D#*6"-*

5)&6/A6<8/

5)&60

5)&67"$*

!"#$1))$C>

5)&61))$C>

Figure 4: The Core Functionality Model of T

axiCentral.

for a non-technical person (with a little explanation)

and therefore useful for discussions and validation

with end users. Moreover, they deﬁne a behaviour

contract that both parts of the interface must obey.

3.3 Modelling the Core Functionality

The method rules for core functionality (CF) are as

follows:

CF1: Deﬁne the activity that contains the core func-

tionality by using a UML activity diagram.

CF2: Map the domain events from the requirements

to streaming pins on the edge of the activity

that deﬁnes the core functionality. The name

of each pin should correspond to the name of

an event deﬁned in the requirements.

CF3: Deﬁne local variables in the activity that can

hold the data it shall handle according to the

requirements.

CF4: For each domain event to be handled (repre-

sented by a streaming pin) deﬁne an internal

activity ﬂow that performs the actions given in

the corresponding requirement.

CF5: If necessary add pins to start and stop the ac-

tivity.

The resulting core functionality of the TaxiCentral

is illustrated in Figure 4. The functional requirements

of the TaxiCentral in Section 2 tells that it’s core func-

tionality needs to maintain a user queue (UserQ) and

a taxi queue (TaxiQ) to coordinate multiple users and

taxis. The variables are indicated by a note on the up-

per right corner of the activity diagram as shown in

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

494

act User-TD

tr.TaxiReq

User

uw.UserWait

User

gt.Grant

User

!!"#$"%&'())

"&*

uwd.User

Withdraw

User

+'#,-"./"0$

ts.TaxiStatus

Taxi

tw.TaxiWait

Taxi

sz.Seize

Taxi

act Taxi-TD

twd.Taxi

Withdraw

<<external>>

end

Taxi

+'#,12',('3("

45"678

+'#,9

:0"%;',$

+'#,100,<&

45"678

:0"%9

+'#,;',$

:0"%100,<&

!"#$"%&'(

!"#$%&%'('(

)*(+%&%'('(

"=>$?

"=>$?@A$8"=>$?

@A$8"=>$?

B&0"%$8:0"%8,&8

:0"%9

B&0"%$8+'#,8,&8

+'#,9

:0"%;,$5*%'C

+'#,;,$5*%'C

-"=A2"

:0"%8D%A=8:0"%9

-"=A2"

+'#,8D%A=8+'#,9

E$'%$

B&,$,'(8

E"$$,&<0

F#$%'6$

+'#,8D%A=8

+'#,9

F#$%'6$

:0"%8D%A=8

:0"%9

+'#,;',$

:0"%;',$

+'#,12',('3("

+'#,100,<&

+'#,;,$5*%'C

:0"%100,<&

:0"%;,$5*%'C

+'#,12',('3("

+'#,-"./"0$

+'#,12',('3("

+'#,-"./"0$

:0"%4A&&"6$"*

+'#,4A&&"6$"*

Figure 5: Composition of core functionality model and interface functionality models resulting in global behaviour model of

the TaxiCentral.

Figure 4 since UML does not have any speciﬁc nota-

tion to represent variables in activity diagrams.

Although this model may appear to be very inter-

nal, it actually speciﬁes the core behaviour which is

of importance for end-users, and therefore relevant in

a speciﬁcation. In purely interface oriented speciﬁca-

tions this functionality is completely missing.

3.4 Composing the Core and Interface

Functionality

Once the interface functionality and core functional-

ity models are deﬁned, we need to ensure their cor-

rect alignment and coordination in order to compose

the complete service behaviour. The method rules for

composing the complete service behaviour (CSB) are

as follows:

CSB1: Find matching pins on the core functionality

model and the interface functionality models.

Connect the matching pins.

CSB2: If a matching output pin cannot be found in

the core functionality, look into the core func-

tionality model to identify the appropriate

ﬂow where the required event is represented.

Add a fork to the ﬂow identiﬁed and an output

pin. Connect the fork to the pin.

The resulting complete behaviour of the TaxiCen-

tral is shown in Figure 5. It also illustrates the

rule ‘CSB2’ where the matching TaxiAvailable and

TaxiRequest output pins are not found originally on

the core functionality model. They are then added

to the core functionality model and connected to the

newly added fork on the corresponding ﬂow.

Note that the interface functionalityand core func-

tionality are deﬁned in separate modules, that are

partly independent and may be modiﬁed separately as

long as their interface remains unchanged. This is one

of the advantages of the interface-modular approach.

4 METHOD VALIDATION

First we comment that the development of a global

interface-modular speciﬁcation may not be quite as

straight forward as suggested in the presentation

above. In practice one may need to iterate in order to

discover and resolve all dependencies and to develop

the interface and core functionalities to the level pre-

sented in Figure 5.

We may now ask about the generality of the ap-

proach and completeness of the resulting global spec-

iﬁcation.

For the core functionality, activity diagrams are

both well suited and general enough. They can eas-

ily be expressed in a tool like Reactive Blocks (Krae-

mer et al., 2009; ReactiveBlocks, 2014) that will ana-

lyze the model and generate corresponding code. For

interface functionality, the challenge is to cover all

possible event orderings. This is achieved by the

interface focus, the decomposition into elementary

collaboration-uses and the ordering constructs of ac-

tivity diagram. The functionality of the TaxiCentral

has been implemented in several versions using the

Reactive Blocks tool (Kraemer et al., 2009; Reac-

tiveBlocks, 2014). This includes both the core func-

tionality and the interface functionality including re-

mote communications using a variety of protocols.

A lesson from this is that our use of activity dia-

grams is quite general and enable sufﬁcient complete-

AModularMethodforGlobalSystemBehaviourSpecification

495

ness for design synthesis. We have tested our ap-

proach on a variety of other problems too, in order

to uncover possible shortcomings. Among these is

the bCMS system (bCMS, 2012) which is more com-

prehensive and more distributed than the TaxiCentral.

The bCMS core functionality needs to be partitioned

and distributed accordingly. Other systems on which

we have tested our approach are: a LiftSystem; an

Access-ControlSystem; and a Tele-MedicineSystem.

From this we have encouraging indications that the

approach is sound. These examples are not explained

in this paper due to lack of space.

5 RELATED WORK

Expressing the core functionality using activity dia-

grams is similar to the common practice in work-ﬂow

modelling used in the business process development.

Factoring out interfaces in separate interface contracts

is also according to common practice in the same do-

main as seen in web services and SOA. What is not

so common is to deﬁne the two aspects in modules

that can be directly composed using pins. Within the

embedded and reactive systems domain, it is common

to specify interface functionality using sequence dia-

grams, but less common to specify core functionali-

ties separately. It is more common to map (incom-

plete) sequence diagrams to state machines that inte-

grate interface and core functionality during (manual)

design.

In the literature, one can ﬁnd many proposals to

represent high-level service speciﬁcation such as se-

quence diagrams and Use Case Maps (UCM) (Buhr,

1998; Castej´on, 2005). Interactions, for instance

UML sequence diagram, are commonly used to ex-

press collaborative behaviour using messages which

are exchanged between components. But sequence

diagrams can normally be used for limited scenar-

ios only and contain other drawbacks mentioned

in (Castej´on, 2008), (Zaha et al., 2008).

The WSCI speciﬁcation (Arkin et al., 2002) de-

scribes the interface of a web service participating in

a choreographed interaction using XML-based lan-

guage. Unlike our approach, a WSCI interface de-

scribes only one partner’s participation. The WSCI

does not describe how a web service manages mes-

sage ordering which in our approach is explicitly han-

dled. Other approaches have been proposed (Beyer

et al., 2005a; Beyer et al., 2005b; Mencl, 2004) to

deﬁne interface behaviours, but none of them models

interface behaviour as activities ordering elementary

collaborations. The problem addressed in the multi-

view point approach proposed in (Dijkman and Du-

mas, 2004) is similar to ours. But, there are impor-

tant differences that sets our work apart from their

approach. Interface behaviours for instance are one-

sided in their approach. Moreover, their approach

does not factor out internal tasks as we do in the core

functionality.

Deriving interface contracts by projection from

complete component behaviours have been much

studied and several approaches exist (Bræk and Hau-

gen, 1993; Floch and Bræk, 2003; Sanders et al.,

2005). However, the opposite problem of specify-

ing interfaces ﬁrst, and then composing the com-

plete component behaviours has not been so well re-

searched in the past.

The interface behaviours we develop, deﬁne the

behaviour that is visible on each particular interface.

This may be considered as a projection of the com-

plete behaviour of a component or a system. One

of the original methods of projections is proposed

in (Lam and Shankar, 1984) to reduce the complex-

ity of analyzing non-trivial communication protocols.

The method breaks up the protocol analysis problem

into smaller problemsby constructing a smaller image

protocol system using reﬁnement algorithms that pre-

serves properties of the original protocol system. Our

method is inspired by similar reduction of complexity

by constructing smaller interface behaviours as pro-

jections. In doing this we seek to precisely deﬁne the

visible interface behaviour that users and other en-

tities in the environment will observe, while hiding

other interfaces and details of the core functionality.

Various mathematical approaches have been pro-

posed to deﬁne choreography semantics for exam-

ple Labelled Transition System (Sala¨un and Bultan,

2012). Activity traces are used by (Qiu et al., 2007) to

represent choreography. Most of these proposals lead

to manual synthesis of the components. Whereas,

once the system is speciﬁed using our interface-

modular approach, synthesis of the components can

be automated by using the rules published in (Fatima

and Bræk, 2013).

6 CONCLUSION AND FUTURE

WORK

We have presented an interface-modular method for

system speciﬁcation which is suitable to become the

source of highly automated design synthesis. The

method is demonstrated by a non-trivial case study,

the TaxiCentral. Our method approaches the com-

plexity of global behaviour speciﬁcation problem by

factoring out two separate aspects of a system i.e.

‘core functionality’ and ‘interface functionalities’. In-

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

496

terface behaviours are decomposed using collabo-

rations and deﬁned as activities ordering elemen-

tary collaborations expressed using activity diagrams.

This separation allows interfaces and core functional-

ity to be combined in different ways as long as their

internal interfaces are unchanged.

To our knowledge, the interface-modular method

we have presented is original in the way it deﬁnes in-

terface behaviour, separates the interface behaviour

and core functionality, and composes interfaces and

core functionality.

Currently, we are working on using the interface

contracts (which is a by-product of our method) for

compositional validation to ensure correct interwork-

ing and dynamic binding.

REFERENCES

Arkin, A., Askary, S., Fordin, S., Jekeli, W., Kawaguchi,

K., Orchard, D., Pogliani, S., Riemer, K., Struble, S.,

Takacsi-Nagy, P., et al. (2002). Web service chore-

ography interface (wsci) 1.0. Standards proposal by

BEA Systems, Intalio, SAP, and Sun Microsystems.

bCMS (2012). bcms case study document.

http://cserg0.site.uottawa.ca/cma2013re/CaseStudy.pdf.

Accessed On: 22-09-2014.

Beyer, D., Chakrabarti, A., and Henzinger, T. A. (2005a).

An interface formalism for web services. In Proceed-

ing of the First International Workshop on Founda-

tions of Interface Technologies.

Beyer, D., Chakrabarti, A., and Henzinger, T. A. (2005b).

Web service interfaces. In Proceedings of the 14th

International Conference on World Wide Web. ACM,

New York.

Bræk, R. and Haugen, Ø. (1993). Engineering Real Time

Systems. Prentice Hall.

Buhr, R. J. A. (1998). Use case maps as architectural en-

tities for complex systems. In IEEE Transactions on

Software Engineering, volume 24(12). IEEE Press.

Castej´on, H. N. (2005). Synthesizing state-machine be-

haviour from uml collaborations and use case maps.

In SDL 2005 Model Driven, volume 3530. LNCS,

Springer.

Castej´on, H. N. (2008). Collaborations in Service Engi-

neering: Modeling, Analysis and Execution. PhD

Thesis, Department of Telematics, NTNU.

Castej´on, H. N., Bræk, R., and Bochmann, G. V. (2007).

Realizability of collaboration-based service speciﬁ-

cations. In Proceedings of the 14th Asia-Paciﬁc

Soft. Eng. Conf. (APSEC07). IEEE Computer Society

Press.

Dijkman, R. and Dumas, M. (2004). Service-oriented

design: A multi-viewpoint approach. In Interna-

tional Journal of Cooperative Information Systems,

volume 13.

Fatima, U. and Bræk, R. (2013). On deriving detailed com-

ponent design from high-level service speciﬁcation. In

System Analysis and Modeling About Models, volume

7744. LNCS, Springer.

Floch, J. and Bræk, R. (2003). Using projections for the de-

tection of anomalous behaviours. In SDL 2003 System

Design, volume 2708. LNCS, Springer.

Kathayat, S. B. and Bræk, R. (2011). Analyzing realizabil-

ity of choreographies using initiating and responding

ﬂows. In Proceedings of the 8th International Work-

shop on Model-Driven Engineering, Veriﬁcation and

Validation, MoDeVVa, pages 6:1–6:8, New York, NY,

USA. ACM.

Kathayat, S. B., Le, H., and Bræk, R. (2011). A model-

driven framework for component-based development.

In SDL 2011 - Integrating System and Software Mod-

eling, volume 7083. LNCS, Springer.

Kraemer, F. A., Sl˚atten, V., and Herrmann, P. (2009). Tool

support for the rapid composition, analysis and imple-

mentation of reactive services. In Journal of Systems

and Software, volume 82(12). Elsevier.

Lam, S. S. and Shankar, A. U. (1984). Protocol veriﬁca-

tion via projections. IEEE Transactions on Software

Engineering, 10(4).

Mencl, V. (2004). Specifying component behavior with port

state machines. In Electronic Notes on Theoretical

Computer Science.

Qiu, Z., Zhao, X., Cai, C., and Yang, H. (2007). Towards the

theoretical foundation of choreography. In Proceed-

ings of the 16th International Conference on World

Wide Web, WWW ’07, pages 973–982, New York,

NY, USA. ACM.

ReactiveBlocks (2014). Reactive blocks - the tool for

professional java developers. http://www. bitreac-

tive.com. Accessed On: 10-12-2014.

Sala¨un, G. and Bultan, T. (2012). Realizability of chore-

ographies using process algebra encodings. Services

Computing, IEEE Transactions on, 5(3):290–304.

Sanders, R. T., Bræk, R., Bochmann, G. V., and Amyot,

D. (2005). Service discovery and component reuse

with semantic interfaces. In SDL 2005 Model Driven,

volume 3530. LNCS, Springer.

Zaha, M. J., Dumas, M., Hofstede, A. H. M., Barros, A., and

Decker, G. (2008). Bridging global and local models

of service-oriented systems. In IEEE Transactions on

Systems, Man., and Cybernetics, volume 38(3). IEEE

Press.

AModularMethodforGlobalSystemBehaviourSpecification

497