grvafiskerktøyskrin - colorado state university our project partner telenor. in [7], we demonstrate...

Automated Encapsulation of UML Activities for Incremental Development and Verification

Frank Alexander Kraemer Peter Herrmann

{kraemer, herrmann}@item.ntnu.nowww.item.ntnu.no/~kraemer

Norwegian University of Science and Technology

Selvhjelpspakken for informasjon og formidling ved NTNU:

www.ntnu.no/info/selvhjelp

Grafisk

verktøyskrinGrafisk profil ved Norges teknisk-naturvitenskapelige universitet

578 F.A. Kraemer and P. Herrmann

«esm»

Ax

ExS

xencapsulation

(automatic) x

Fig. 6. Encapsulating an activity

«esm»

refinement(design + verification)

SEy

Ay

y

y

Fig. 7. Refining an ESM

of a system, both styles may be combined: An activity developed bottom-up mayat some level be composed with one that is to be developed top-down, and aninitial top-down design of an application may be refined until a level is reachedwhere existing activities can be used and encapsulated. If an activity is useful ina number of applications, it can be stored in a library and reused later in othersystems.

4.1 Case Studies

To evaluate the impact of the presented specification technique with streamingparameters and ESMs, we conducted a number of case studies, covering severaldomains:

Web Services. For the orchestration of web services, we demonstrated in [6]how WSDL descriptions can be imported automatically as activities. Eachweb service operation can be invoked by corresponding streaming parameternodes. The ESMs ensure that these operations are invoked in a sensible orderonly.

Embedded Systems. In [4] we composed a sensor network from reusable build-ing blocks. A complete leader election protocol is contributed by one singleactivity, encapsulated by an ESM. The system was automatically imple-mented on Sun SPOTs for embedded Java [19].

Mobile Services. In [17] we developed a mobile, location-aware application,in which users solve tasks depending on their current location. This systemis used within the FABULA project for mobile learning platforms [20]; thedeveloped activities are also usable in other application areas.

Home Automation. Within the project ISIS (Infrastructure for IntegratedServices), we develop solutions for the domain of home automation togetherwith our project partner Telenor. In [7], we demonstrate the composition ofa remote fire alarm, in which most parts are reused from libraries.

Trust Management. [5] presents a number of activities encapsulated by ESMsfor the domain of trust management.

4.2 Libraries of Reusable Building Blocks

The ESMs act as behavioral interfaces [21] that can be used to separate thework of di!erent developers. When a new activity is introduced providing some



Grafisk


Activities

Abstract

Detailed



Grafisk


Call Behavior Action

Behavior

Activity

+behavior 1*



Grafisk


Activities

ArctisTransformer

State Machines

J J J

J J JCode Generator 1

Code Generator 2

Java

The SPACE Method

[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]

[bu!er.size()=0][else]

stopped = true

[sending or bu!er.size()>0]

[else]

[stopped]

Bu!ered SMS Sendingsend: SMSMessage

stop

start

ok

stoppedfailed

ok failed ok: Auth failed

report error[else]

bu!er: List // holding SMS messagessending: booleanstopped: booleancredentials: Auth

: Request

remove smsfrom bu!er

s: Send SMSa: Authenticate

storecredentials

start/starting

/ok

send/

«esm» Bu!ered SMS Sending

/failed

activestop/

stopping/stoppedstop/stopped

Supported by the Arctis tools, www.arctis.item.ntnu.no



Grafisk


start: SMS Message

ok failed

Call Behavior Actions

s: Send SMS



Grafisk


failed

Streaming Parameters

sms: SMSMessagestop Receive SMS

start: Setup

stopped

65 %



Grafisk


ok failed

: Request

s: Send SMS

[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]


stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials



Grafisk


External State Machines

Receive SMS

start: Setup

stop sms: SMSMessage

stopped failed

«esm» Receive SMS

start/

active/sms/failed

stop/stopping

/stopped



Grafisk


Formal Relationship

[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]


stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials

start/starting

/ok

send/


/failed

activestop/


module Activity

extends Naturals, Sequences

variables i , t , f , s, a

variables q1, q2

receive(signal , queue)∆=

∧ Len(queue) > 0∧ Head(queue) = signal

∧ queue� = Tail(queue)

send(signal , queue)∆=

queue� = Append(queue, signal)

count(signal , queue)∆=

let match(n)∆= n = signal

in Len(SelectSeq(queue, match))

AInit∆=

∧ i = 1 ∧ t = 0 ∧ f = 0 ∧ s = 0 ∧ a = 0∧ q1 = �� ∧ q2 = ��

r1∆=∧ i = 1 ∧ i

� = 0 ∧ t� = 1

∧ send(“SUBSCRIBE”, q1)∧ unchanged �s, f , a, q2�

r2∆=∧ receive(“SMS”, q2)∧ unchanged �i , s, t , f , a, q1�

r3∆=∧ t = 1 ∧ t

� = 0∧ send(“UNSUBSCRIBE”, q1)∧ unchanged �i , s, f , a, q2�

r4∆=∧ f

� = 1∧ receive(“UNSUBSCRIBE ACK”, q2)∧ unchanged �i , s, t , a, q1�

g1∆=∧ s

� = 1∧ receive(“SUBSCRIBE”, q1)∧ unchanged �i , t , f , a, q2�

g2∆=∧ s = 1∧ count(“SMS”, q2) = 0∧ send(“SMS”, q2)∧ unchanged �i , s, t , f , a, q1�

g3∆=∧ a = 0 ∧ a

� = 1 ∧ s� = 0

∧ receive(“UNSUBSCRIBE”, q1)∧ unchanged �i , t , f , q2�

g4∆=∧ a = 1 ∧ a

� = 0∧ send(“UNSUBSCRIBE ACK”, q2)∧ unchanged �i , s, t , f , q1�

Invariant∆=

∧ Len(q1) + Len(q2) < 3

ANext∆= ∨ r1 ∨ r2 ∨ r3 ∨ r4

∨ g1 ∨ g2 ∨ g3 ∨ g4

ASpec∆= AInit ∧ ✷[ANext ]�i, s, t, f , q1, q2�

Figure 1: TLA module for the activity

1 TLA Module for the Activity

The first compartment declares all variables. The second compartment de-fines actions for sending and receiving via queues, and also defines a functionto count how may signals of a certain type are within a queue, used in actiong2. The third compartment lists all actions r1..r4 and g1..g4 as illustrated inthe paper. Action g2 has the additional condition count(”SMS”, q1) to takethe time estimate into account which is required for boundedness. The fifthcompartment contains an invariant about the boundedness.

1

Amodule InterfaceR

extends Naturals, Sequences

variables queue In, queue Out , state

receive(signal , queue)∆=

∧ Len(queue) > 0∧ Head(queue) = signal∧ queue � = Tail(queue)

send(signal , queue)∆= queue � = Append(queue, signal)

INIT∆=

∧ state = 1∧ queue In = �� ∧ queue Out = ��

subscribe∆=

∧ state = 1 ∧ state � = 2∧ send(“SUBSCRIBE”, queue Out)∧ unchanged �queue In�

sms∆=

∧ state = 2 ∨ state = 3∧ receive(“SMS”, queue In)∧ unchanged �state, queue Out�

unsubscribe∆=

∧ state = 2 ∧ state � = 3∧ send(“UNSUBSCRIBE”, queue Out)∧ unchanged �queue In�

unsubscribe ack∆=

∧ state = 3 ∧ state � = 4∧ receive(“UNSUBSCRIBE ACK”, queue In)∧ unchanged �queue Out�

otherSends∆=

∧ send(“SMS”, queue In) ∨ send(“UNSUBSCRIBE ACK”, queue In)∧ unchanged �state, queue Out�

otherReceives∆=

∧ receive(“SUBSCRIBE”, queue Out) ∨ receive(“UNSUBSCRIBE”, queue Out)∧ unchanged �state, queue In�

NEXT∆= subscribe ∨ sms ∨ unsubscribe ∨ unsubscribe ack ∨ otherSends ∨ otherReceives

RSpec∆= INIT ∧ ✷[NEXT ]�state, queue In, queue Out�

Figure 2: TLA module for the interface Ir at the receiver side

3

E

removal of τ -steps. Since this may again result in multiple steps with the samelabel between a pair of states, we remove duplicate steps during merging.

4.5 Step 5: Encapsulation as Service Contracts

From the graphs obtained after minimization we construct UML state machinesas the final representation for the service contracts. These state machines arestored within a UML model repository, for which we use the one provided bythe Eclipse Modeling Project [9]. Each state of a graph is represented by a UMLstate. Graph states with no outgoing edge are represented by UML final states,and the initial state is marked by an initial transition originating from an initialpseudo state. The edges are represented by UML transitions. Receiving labels(?) are translated to corresponding signal triggers, and sending labels (!) tosend signal actions as part of a transition’s effect. The signals referred by thesesending actions and triggers declare typed attributes if the activity flows theyrepresent transport objects, so that the interface also defines which data typesare required.

5 Discussion

5.1 Soundness of the Generated Interfaces

By taking activities as starting point, we can utilize a property of activities thatdistinguishes them from the state machines used to model interfaces: State ma-chines must for every control state explicitly declare signals they can receive. Werecall the example from the introduction, in which s r3 in Fig. 2 must explic-itly declare ?sms. Forgetting the declaration of this reception results in inputinconsistent behavior, and may result in unspecified receptions.

In contrast, activities do not exhibit unspecified receptions: Signal sendingsand receptions are modeled by the very same element, a single flow crossingpartition borders. Whenever a token representing a signal is at the head of aqueue entering a partition, it may continue and trigger the behavior declaredby the downstream flow.3 The activities we take as input for the generation ofinterfaces therefore describe input-consistent behavior.

To ensure, that the interfaces generated by the algorithm do in fact describethe behavior observed in the activity, we reason in temporal logic. The interfacesneed to be abstractions of the complete behavior described by the activity, or,vice-versa, the activity must be a valid refinement of all the interfaces. In tempo-ral logic, this can be verified by a refinement proof. Both, the complete behaviorof the collaboration A and the generated interfaces Ii, can be represented byTLA specifications Sa and Si, respectively. In TLA, refinement corresponds toimplication (⇒). This means we have to prove that for all interfaces i, Sa ⇒ Si

holds. With refinement mappings, TLA offers a quite elegant method to perform3 If this behavior would harm any of the properties in Sect. 3.4, it would be detected

by the analysis and the construction of the interface would be aborted.

Activity ESM



Grafisk


RefinementEncapsulation

Incremental Development

top-downbottom-up

«esm»

x

ExS

x

x

«esm»

SEy

Ay

y

y



Grafisk


Automatic Encapsulation

[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]

Bu!ered SMS Sendingsend

stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials

PeriodicTimer

start

stoptick



Grafisk


State Space

start/

/failed /ok

//send//ok/ok/ok

stop/

///stopped

/stopped

stop/stop/stopped

send/

send/

Automatic EncapsulationT-Removed

start/

/failed /ok

/ok/ok/ok stop/

/stopped/stopped

stop/ stop/stopped

send/

Minimized

start/

/failed/ok

send/

stop/stopped

/stopped

stop/✗✗

✗✗



Grafisk


start/starting

/ok

send/


/failed

activestop/


[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]

Bu!ered SMS Sendingsend

stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials +



Grafisk


SMS Inquiry Service

start

stoppedfailed

stop

create setup

failed stopped

create answer

report

t:TERMINATE

report

send: SMSMessage

stop

s2: Bu!ered SMS Sending s1: SMS Reception

sms: SMSMessage

start: ReceiveSMSSetupok

start/starting

/ok

send/


/failed

activestop/


start/

/sms

«esm» SMS Reception

/failedactive

stop/stopping

/stopped

stop

failed stopped

s1: SMS Reception

sms: SMSMessage

start: ReceiveSMSSetup

start

stoppedfailed

send: SMSMessage

stop

s2: Bu!ered SMS Sendingok



Grafisk


Incremental Verification

[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]


stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials

start/starting

/ok

send/


/failed

activestop/





5 Discussion







1

2


automatically on UML activities in order to check numerous properties thatshould hold for any application, like the freedom of deadlocks or bounded com-munication queues. Problems identified are presented in the form of animationsand annotations within the diagrams, as demonstrated in [7], so that engineersdo not require a formal background to assure the quality of their models.

A well-known challenge of model checking is the problem of state explo-sion [25], i.e., that realistic systems often have so many reachable states thata complete analysis cannot be handled within acceptable time. By using ESMs,however, we can verify systems incrementally, since each activity is analyzedseparately. When an activity is model checked, all its subordinate activities re-ferred to by call behavior actions are represented by their respective ESMs. Thisreduces the number of states to be checked significantly, since the ESMs haveusually much less states as they are more abstract than the activities they en-capsulate. To achieve that, our model checker verifies two properties for eachactivity:

(i) The activity has always to comply with its own ESM, i.e., Ax ! Ex asmentioned in Sect. 3 holds.

(ii) An activity must always fulfill the ESMs of its subordinate activities.

Formally, a system S using activity Ax is described by S ! Ax " N , with N asthe behavior of the surrounding context of Ax (see [16]). To prove a propertyI during the analysis, PA ! S ! "I must hold.1 Using the ESMs instead,the model checker verifies the less complex proof PE ! Ex " N ! "I. SincePE " (Ax ! Ex) ! PA holds trivially and (i) holds, the replacement of theactivities by their ESMs is formally correct. (See also [2].)

The degree of reduction of the size of the state space is discussed below.Further, when an activity is reused, the analysis e!ort spent will be reused aswell. We assume that the designer of a building block only adds an activity toa library after it passed the analysis and does not contain any errors. Thus,other engineers may simply apply the building block without the need to checkthe correctness of it’s internal behavior again. They only have to prove that theenvironment of the block complies with its ESM.

It is also beneficial for the human developers that the analysis is focused onone activity at a time: Once an erroneous situation is identified by the modelchecker, the underlying problem is typically easier to understand and solve whenonly a single activity has to be understood. This makes it also possible to studyintricate synchronization problems isolation, as demonstrated in [8].

5.1 Scalability and Reduction of State Space

To make a point in case, we consider a simple example from the domain ofGrid technology. These systems stand out for their high number of processesrunning in parallel. Here, each combination of the local process states forms a1 In temporal logic, " is the “always” operator stating that a property holds in all

states of a system description.


































[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]


stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials

start/starting

/ok

send/


/failed

activestop/





5 Discussion







[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]


stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials

SMS Inquiry Service

start

create setup

create answer

report

t:TERMINATE

report



Grafisk





Grafisk


Case Study: Mobile Game System [1]


[1] Tool Support for the Rapid Composition, Analysis and Implementation of Reactive Services.Frank Alexander Kraemer, Vidar Slåtten and Peter Herrmann. Journal of Systems and Software, Elsevier, 2009. (to appear)

575 states



Grafisk



22 17 11 7 4

Case Study: Mobile Game System [1]

[1] Tool Support for the Rapid Composition, Analysis and Implementation of Reactive Services.Frank Alexander Kraemer, Vidar Slåtten and Peter Herrmann. Journal of Systems and Software, Elsevier, 2009. (to appear)



Grafisk


Reuse Metrics

28 edges[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]


stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials

= 55+ 27 nodes



Grafisk


Reuse MetricsSMS Inquiry Service

start

create setup

create answer

report

t:TERMINATE

report

stop

failed stopped

s1: SMS Reception

sms: SMSMessage


start

stoppedfailed

send: SMSMessage

stop


start

stoppedfailed

send: SMSMessage

stop


n=60stop

failed stopped

s1: SMS Reception

sms: SMSMessage

start: ReceiveSMSSetup n=55

SMS Inquiry Service

start

create setup

create answer

report

t:TERMINATE

report

n=42

Specific Reused

n=115n=42

= 73 %115 + 42

R = 115



Grafisk


Reuse Metrics

SPOT Sensor System 71 %create event

:Event

create event:Event

create event:Event

leader: ID

Spot Sensor Systemspot sensor

select leader

set leader:ID

set leader:ID

leader==myID

else

2

spot sensorsother

myID: ID

leader=myID

initialize myID

«system»

l: Leader Electionactivate

new leader : ID

i am leader: ID

a: Alarm Filter

eventalarm

start stopg: GSM Alarm

eventactivate

s1: Motion Sensor

movedactivate

s2: Light Sensorthreshold exceeded

activate

s3: Temp. Sensoractivate threshold

exceeded

Trusted Auction System 75 %

SMS-Based Service 79 % Mobile Education Game 64 %

Mobile Alarm System 68 %

userServer

chatServer

poiServer

positionServeruser [0..*]

City Exploration Service

ui1:PositionUpdateUI

l1: PositionModule

ui2: QuizUI

ui3: ChatUI

ui4: UserInfoUI c2: SocialMatchingService

c1: ChatService

c4: QuizService

c3: GroupPositionService

position: MainUI

myPosition: Position

othersPosition: Position

groupPosition: Position

question: Question

groupSuggestions: Answer

mySuggestion: Answer

start

finished

sendMessage: Message

receiveMessage: Message

statusIn: Status

statusOut: Status

init: UserProfile

matchedUsers: User[]

update: UserProfile

init: MainUI

init: MainUI

init: MainUI

init: MainUI

start

Position

myPosition: Position

question: Question

groupSuggestions: Answer

mySuggestions: Answer

send: Message

receive: Message

statusIn: Status

statusOut: Status

quiz: MainUI

chat: MainUI

userInfo: MainUI

m: Main

submission: Answersubmission: Answer

matchingUsers: User[]

check Position

update

position: Position

position: Position

othersPosition:

start: UserCredentials

star

t: U

serC

reden

tial

s elsetrue

: boolean

Menu of the Day System

s1: SMS Reception

extract Menu

s3: Send SMS

stop

d: Daily Alarm

c: Calendar

get next subscriberstart: Time

start

failed confirmed

create menu sms

sms: SMSMessage

add sender To subscribers

remove sender from subscribers

create unsubscribe confirm sms

create subscribe confirm sms

create service explanation sms

s2: Send SMS

failed confirmed

b: SMS Bufferinit add

next

out

:Event[]

[menu=null]

:Event[]

[else]

log failure

[sendList.size()==0] copy list

[else]

subscribers: List<MSID> = new ArrayList<MSID>();subscribers_copy: List< MSID > = new ArrayList<MSID>();menu: String;

:MSID:MSID

:SMSMessage

send: SMSMessage

send: SMSMessage

[sms.startsWith("subscribe")] [sms.startsWith("unsubscribe")] [else]

:SMSMessage

alarm

log failure


create setup:ReceiveSMSSetup

failed stopped

log failure

:SMSMessage:SMSMessage

Trusted Auctionbuyer seller

MakeBid

WinBid

EndBidLoseBid

bto: Timeliness Observer

timeout

inTime late

okelse

checkproduct

posit

ive

ts: Trusted Sale

(buyer, seller, mediator)

MakeBid

WinBid

sto: Timeliness Observer

inTimelate

reputation system

sell trusted

non-trusted

buy trusted

non-trustedbuy

nega

tive

confi

rm

confi

rm

nega

tive

posit

ive

confi

rm

high

tru

st

low

tru

st

no trust

low

tru

st

no t

rust

high

tru

st

paym

ent

confi

rmde

liver

y

bre: Report Experience

str: Trust Retrieval

sre: Report Experience

btr: Trust Retrieval

j2

j1

d1

i1

timeout

sell

71 %



Grafisk


Summary

[retry]

create request

sending = true

add to bu!er

[sending]

[else]

sending = false

[else]


stopped = true


[else]

[stopped]


stop

start

ok

stoppedfailed


report error[else]


: Request



storecredentials

Activity

+start/starting

/ok

send/


/failed

activestop/


External State Machine

new



Grafisk


Summary

Incremental Verification:



Grafisk


Summary

~70 %Reused Specific

grvafiskerktøyskrin - colorado state university our project partner telenor. in [7], we demonstrate...

Documents