Checking consistency between architectural models using SPIN

1
Checking consistency between architectural models
using SPIN
Requirements and Software Architectures
Paola Inverardi, Henry Muccini, Patrizio
Pelliccione University of LAquila
(Italy) inverard, muccini, pellicci_at_univaq.it
Begin
2

• ObjectiveTo 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 instance
3
Our approach to gain objective 1
Step1
Step2drives
Step4drives
Software Architecture
Requirement Engineering
Specifications
Step3validates
4
In detail (1/4)
Step1 Identification and representation of
Coordination Requirements
drives
drives
SA
Specifications
Specifications
Coordination
Coordination
validates
5
In detail (2/4)
Step2 From Requirements to Software Architectures
Requirements
Software Architecture
drives
static view
static view
Analysis
SA
model
description
Activity
drives
Diagrams
Specifications
Specifications
Coordination
dynamic view
dynamic view
Interaction
LTS
Diagrams
model
drives
6
In detail (3/4)
Step3 Validating Software Architectures
Requirements
Software Architecture
drives
dynamic view
drives
Specifications
Specifications
Coordination
???
validates
7

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

SA level scenarios
Req. level scenarios
8
In detail (4/4)
Step4 From SA to Coordination Models
Software Architecture
Coordination Models
drives
static view
drives
SA
IWIM
Requirement Engineering
description
Specification
Coordination
dynamic view
validates
LTS
model
9
Our approach to gain objective 2... Validate
statecharts with respect to the scenarios
Statecharts, LTS, Automaton
Process P
Process Q
P
Q
P
Q
m1
m2
m2
m5
m3
Scenarios
UML Sequence, MSC, Scenarios
10
In detail (1/2)
Step1 State -gt Promela
Statecharts
11
In detail (2/2)
Step2 Scenario -gt LTL Formula
P sends m1 before P sends m2 before Q receives m2
before Q receives m1 AND Send m1 is the first
operation AND Send m2 is the second
operation AND Receive m2 is the third
operation AND Reveice m1 is the fourth operation
Q
P
m1
m2
m2
(chch1_s.pos0 lt chch2_s.pos0 lt
chch2_r.pos0 lt chch1_r.pos0)
(chch1_s.pos0 1) (chch2_s.pos0
2) (chch2_r.pos0 3) (chch1_r.pos0
4)
m1
Scenarios
12
Integrating the approaches
Requirements
Software Architecture
Coordination Models
drives
Use Case
static view
Diagram
SA
drives
description
dynamic view
static view
IWIM
dynamic view
Analysis
Interaction Diagrams
Specification
LTS
model
model
Promela Spec.
LTL Formulae
Validates using SPIN
13
Applying the Approach
TRMCS Case Study
14
Analysis model
Dynamics
Alarm
Alarm
Check
User
Router
Server
Handler
Handler
Handler
Alarm1
Alarm1
Alarm1
Alarm1
LTL Formula
Check
Ack1
Ack1
Check
Ack1
Ack1
Check
15
SA topology
SA dynamics
Promela
16
An architectural Error we found Req An User
can send Alarms and Checks whenever he wants
SA statechart An User can send a second check
(Check2) only if the first check (Check1) as
been forwarded to the Router Component
Check Coord
User
Router
Check1
Check1
Check2
Check2
17
Ongoing and Future Works

• Tool Support
• Step1 Refinement (in ConCoord01)
• Enriched Statecharts and Scenarios
• Mapping
• Case Study

18
and after your presentations...

• Use Case Diagrams Vs. Actors and
  Goals
• Our process Vs. Goal
  Oriented Req.

19
Requirements and Software Architectures
Henry MucciniPh-D Student in Computer
ScienceUniversity of LAquila -
Italymuccini_at_univaq.ithttp//www.dm.univaq.it/m
uccini