checking consistency between architectural models using spin requirements and software architectures...

Checking consistency

between architectural

models using SPIN

Requirements and Software Architectures Requirements and Software Architectures

BeginBegin

Paola Inverardi, Henry Muccini, Patrizio PelliccionePaola Inverardi, Henry Muccini, Patrizio Pelliccione

University of L’Aquila (Italy)University of L’Aquila (Italy)

{inverard, muccini, pellicci}@univaq.it {inverard, muccini, pellicci}@univaq.it

2

Requirements and Software ArchitecturesRequirements and Software Architectures

HenryMuccini HenryMuccini

Objective:To validate Software Architectural models with respect to Requirements

How to do this:1)defining a development process that explicitily identifies and manages coordination. [Coordination2000]

2)validating consistency among scenarios and statecharts…

validating SA models of dynamics (statecharts) with respect to the expected behaviors (scenarios)

for instancefor instance

3



Our approach to gain objective 1

Software Development Process

SpecificationsSoftware

Architecture

Step4:drivesStep2:drives

Step3:validates

Step1Step1

RequirementEngineering

The UnifiedUnified

+Coordination

SoftwareArchitecture

RequirementEngineering

+Coordination

Coordination

Specifications

4



In detail (1/4)

Use Case

Diagram

Analysis

model

Interaction

Diagrams

dynamic viewstatic view

Activity

Diagrams

Requirements

SpecificationsSA +

drivesdrives

validatesCoordination Coordination

Specifications

Step1: Identification and representation of Coordination Requirements

Step1: Identification and representation of Coordination Requirements

5



In detail (2/4)Step2: From Requirements to Software ArchitecturesStep2: From Requirements to Software Architectures

Requirements Software Architecture

Analysis

model

Interaction

Diagrams

SA

description

LTS

model

static view

dynamic view

drives

dynamic view

static view

Activity

Diagrams

drives

Specifications

drives

CoordinationSpecifications

6



In detail (3/4)Step3: Validating Software ArchitecturesStep3: Validating Software Architectures

Requirements Software Architecture

LTS

model

dynamic viewInteraction

Diagrams

dynamic view

Activity

Diagrams

validates

Specifications

drives

CoordinationSpecifications

drives

??????

7



Is the SA model correct with respect to the Requirements? I.e., is the SA dynamics conform to the Coordination Requirements?

5

31

0

5

21

0

13

28

SA level scenarios

Useri

CheckCoordinator

Router

sendCheckreceiveCheck

UserAlarmReqUI

AlarmHandl

AlarmInput

SendAlarm

RouterUser

Dbase

Exists?

Yes

ReceiveAlarm

AlarmAck

LogFile

writeAlarm

Req. level scenarios

8

In detail (4/4)Step4: From SA to Coordination ModelsStep4: From SA to Coordination Models



Software Architecture

SA

description

LTS

model

static view

dynamic view

Coordination Models

IWIM

Specification

drives

drives

validates

RequirementEngineering +Coordination

9



Our approach to gain objective 2... Validate statecharts with respect to the scenarios

Statecharts, LTS, Automaton

UML Sequence, MSC, Scenarios

P

PromelaSpecification

m1

m2

m3

m2

m5

Q QP

ScenariosScenarios

y

b

c

?ch1

!ch2

a?ch2

!ch1

x

LTLFormulae

SPIN

Process PProcess P Process QProcess Q

10



In detail (1/2)

Component P Component Q

x

y

!ch1

?ch2

a

b

c

?ch1

!ch2

# define N 10# define N C 2chan channel [N C ] = [0 ] o f { b it };typedef m atrix {in t pos[N ]};matrix ch [2*N C ];in t position [2*N C ];in t cont;proctype P(){<proctype descrip tion>}proctype Q(){s0:<state descrip tion>;goto si ;

... sn:<state descrip tion>;goto sj ;}init{atom ic { run P (); run Q ();}}

b)

c)

d)

a)

Step1: State -> PromelaStep1: State -> Promela

StatechartsStatecharts

11



In detail (2/2)

Step2: Scenario -> LTL FormulaStep2: Scenario -> LTL Formula

P

m1

Q

m2

m2

m1 (ch[ch1_s].pos[0] < ch[ch2_s].pos[0] < ch[ch2_r].pos[0] < ch[ch1_r].pos[0])&& (ch[ch1_s].pos[0] = 1) && (ch[ch2_s].pos[0] = 2)&& (ch[ch2_r].pos[0] = 3)&& (ch[ch1_r].pos[0] = 4)

P sends m1 before P sends m2 before Q receives m2 before Q receives m1AND Send m1 is the first operation AND Send m2 is the second operationAND Receive m2 is the third operationAND Reveice m1 is the fourth operation

ScenariosScenarios

12



Integrating the approachesRequirements Software Architecture

Use Case

Diagram

Analysis

model

InteractionDiagrams

SA

description

LTS

model

static view

dynamic view

drives

dynamic viewstatic view

CoordinationModels

IWIM

Specification

drives

Validates using SPIN

LTL Formulae Promela Spec.

13



Applying the ApproachTRMCS Case Study

CheckR ou terF unction ing

SendA larm

CheckU serE x isten ce

A la rm Ca ll

R o u ter

CheckU serF unction ing

S erv er

NotFunction ingC a ll

U ser SendA larm

SendCheck

R eceiveA la rm&Check

R eceiveA la rm

CheckR ou terE x isten ce

S to reInL og

S to reInLogSend

<<extend>>

<<extend>>

<<extend>>

<<extend>>

Storing

<<extend>>

R eceive <<extend>>

<<extend>>

A cknow ledgm en t

A cknow ledgm en tA cknow ledgm en t

14



User AlarmRequestUI

AlarmHandler

CheckRequest UI CheckHandler

Router

Server

sendAlarm

sendCheck

receiveCheck

receiveAlarm

receiveAlarm

UserDbase

RouterDbase Log File

write&read

write&read

write

write

read

ErrorHandler

AlarmInput

11 22 33

7766

5544

88

UserAlarm

HandlerRouter

Alarm1

Ack1

Ack1

Alarm

HandlerServer

Ack1

Ack1

Check

Handler

Check

Check

Check

Alarm1

Alarm1

Alarm1

Analysis modelAnalysis model

DynamicsDynamics

LTL FormulaLTL Formula

15



SA topologySA topology

User i

Router

Server

AlarmCoordinator

CheckCoordinator

sendCheck

sendAlarm

receiveAlarm

receiveCheck

sendAlarm

receiveAlarm sendAck

receiveAck

sendAckreceiveAck

TimerCoordinator

Clock

Clock

SA dynamicsSA dynamics

201911

106

3

6

1614126

3

63

4

53

97

5

117

6

1196

54

31275

4

1176

4

976 5

201964

1

144

1

12

9

1 1332

2019532

1172

1254

3

11

6

43

96

53

6

5

4

7

4

12

1

96 1

113

2

75

2

65

4

3

6

4

1

5

3

2

2 1

0

10

11

8

7

6

5

4

321

0

9

4

2926

2

2822

20

12

10

13

11

3

9

36

35

33

32

34

15

18

17

16

3114

13

12

16

2051439051

37

22

21

202928

27

26

25

24

23

30

19

25

2421

2320

22

19

24

34

27

33

22

44

43

42

48

46

4140

39

38

4340

4142

3938

45

43

38 49

7271

159 10767

107

117

7769

68111

113

107

112

109

70

43

23

Promela Promela

16



An architectural Error we found:An architectural Error we found:

Req: Req: An User can send Alarms and Checks whenever he wants

SA statechart: SA statechart: An User can send a second check (Check2)only if the first check (Check1) as been forwarded to the RouterComponent

User Router CheckHandler

Check1

Check1

Check2

Check2

User Router CheckCoord

Check1

Check1

Check2

Check2

17

Ongoing and Future WorksOngoing and Future Works

Tool Support

Step1 Refinement (in [ConCoord’01])

Enriched Statecharts and Scenarios

Mapping

Case Study

TimeTime

PerformancePerformance



18



… … and after your presentations...and after your presentations...

Use Case Diagrams Vs. Actors and Goals

Our process Vs. Goal Oriented Req.


Henry MucciniHenry MucciniPh-D Student in Computer Science

University of L’Aquila - [email protected]@univaq.it

http://www.dm.univaq.it/~muccinihttp://www.dm.univaq.it/~muccini

checking consistency between architectural models using spin requirements and software architectures...

Documents

requirements objective

software architectural

spin requirements

scenarios statecharts

instance slide

sa dynamics

sa level scenarios user

expected behaviors scenarios