ModelDriven Consistency Checking of Behavioural Specifications

1
Model-Driven Consistency Checking of Behavioural
Specifications
VVSS 2007, Eindhoven
Bas Graaf
Software Engineering Research Group
2
Developing Copier Software (ROOM)
Requirements
Stakeholders
Use cases
Architect
Problems
Architecture
Scenarios
C components
Integrator
Maintenance Evolution Mistakes Shortcuts Inconsist
encies
State machines
Developers
Rational Rose RealTime
3
Problem and Solution

• Scenarios vs. state machines
• Inconsistencies -gt integration and maintenance
  problems
• Solution use MDE
• to generate state machines from scenarios
• compare result
• Based on UML -gt model-driven
• Non-intrusive -gt no additional input
• (as good as possible)

4
Content

• Introduction scenarios and state machines
• Running example ATM
• Mapping scenarios -gt state machines
• Case study printer engine software (Océ)
• Results
• Discussion

5
Scenarios

• Interaction-based modelling
• MSCs, LSCs,
• UML Sequence Diagram
• (Collaboration)
• Inter-component behaviour
• Per use case
• Universal / existential
• Components
• Ordered set of messages
• Decomposition use cases
• -gt requirements-driven

6
State Machines

• State-based modelling
• Moore/Mealy FSM, Harel
• UML Statechart Diagram (StateMachine)
• Intra-component behaviour
• Per component
• (Composite) states
• Transitions trigger (event)
• effect (/action)
• Decomposition components
• -gt architecture-driven

7
Running Example ATM

• Scenarios
• Bad account
• Cancel 1
• Cancel 2
• Bad password
• Components
• UI
• ATM
• Consortium
• Bank

8
Scenarios -gt State Machines

• Annotate messages with pre- and postconditions
  (domain theory)
• -gt State vectors
• Generate flat state machines
• Message -gt transition
• Received -gt trigger
• Send -gt effect
• Merge flat state machines by merging similar
  states
• -gt Based on state vectors
• Add hierarchy using partitioning and
  prioritization of state variables
• Whittle and Schumann, 2000

9

• Apply domain theory copy pre-/postconditions to
  messages

ltltpregtgtatm.cardInfalse ltltpregtgtatm.cardHalfWay
false
ltltpregtgtatm.cardInfalse ltltpostgtgtatm.cardIntrue

ltltpregtgtpasswdGivenfalse
ltltpregtgtpasswdGivenfalse ltltpostgtgtpasswdGiventr
ue
10
ltltpregtgtatm.cardInfalse ltltpregtgtatm.cardHalfWay
false
atm.cardInfalse atm.cardHalfWayfalse

• Active Object -gt StateMachine
• Message -gt Transition SimpleState
• Calculate state vector by frame axiom
• Determine consistency
• Pre conditions of next message should be
  unifiable with current state vector

ltltpregtgtatm.cardInfalse ltltpostgtgtatm.cardIntrue

atm.cardIntrue atm.cardHalfWayfalse
ltltpregtgtpasswdGivenfalse
atm.cardIntrue atm.cardHalfWayfalse passwdG
ivenfalse
ltltpregtgtpasswdGivenfalse ltltpostgtgtpasswdGiventr
ue
ltltpregtgtatm.cardInfalse ltltpregtgtatm.cardHalfWay
false
atm.cardIntrue atm.cardHalfWayfalse passwdG
iventrue
ltltpregtgtatm.cardInfalse ltltpostgtgtatm.cardIntrue

ltltpregtgtpasswdGivenfalse
ltltpregtgtpasswdGivenfalse ltltpostgtgtpasswdGiventr
ue
11
Bad account
Cancel 1
Cancel 2
Bad passwd
12
atm.cardIntrue atm.cardHalfWayfalse
Merge similar states
atm.cardIntrue atm.cardHalfWayfalse passwdG
ivenfalse
atm.cardIntrue atm.cardHalfWayfalse
atm.cardIntrue atm.cardHalfWayfalse passwdG
iventrue
atm.cardIntrue atm.cardHalfWayfalse passwdG
ivenfalse
!
atm.cardIntrue atm.cardHalfWayfalse passwdG
iventrue
atm.cardIntrue atm.cardHalfWayfalse passwdG
ivenfalse
atm.cardIntrue atm.cardHalfWayfalse passwdG
iventrue
Cancel 1
Cancel 2
13
atm.cardIntrue
atm.cardIntrue atm.cardHalfWayfalse passwdG
ivenfalse
atm.cardInfalse atm.cardHalfWayfalse
atm.cardIntrue atm.cardHalfWayfalse passwdG
ivenfalse
atm.cardIntrue atm.cardHalfWayfalse
atm.cardInfalse atm.cardHalfWayfalse
atm.cardIntrue atm.cardHalfWayfalse passwdG
iventrue
atm.cardIntrue atm.cardHalfWayfalse passwdG
iventrue

• Add hierarchy
• partitioning
• prioritization

14
(No Transcript)
15
rule EffectTransition from mUML!Message
(m.sender.isActive) to caUML!CallAction
(), trgtUML!SimpleState ( name lt-
'_sent', constraint lt- m.stateVector), t_effec
t UML!Transition( effect lt- ca, target lt-
trgt, source lt- ),
16
Océ Case Study Source Model

• 10 annotated sequence diagrams
• No domain theory
• No state variables
• -gt normalize

17
Process

• Normalize
• Transformation imposes requirements on input
  model
• Manual, context-specific
• Transform (scenarios -gt state machine)
• Specified using model transformations
• Automatic
• Compare (generated and implementation state
  machine)
• Manual

18
Normalization

• Add state variable as public attribute state
• Possible values derived from annotations
• Interpret lifeline annotation as
• Precondition for succeeding message
• ltltpregtgtesm.state
• Postcondition for preceding message
• ltltpostgtgtesm.state

19
(No Transcript)
20
(No Transcript)
21
Results

• Most of the scenario-based and state-based
  behavioural specifications are consistent
• Identified a few small issues wrt
• State decomposition
• Missing scenarios
• -gt add use case / scenario
• Inconsistent behaviour, loops
• -gt refactor (alternative) scenario
• (size 10 SqDs -gt 14 CompositStates, 47
  SimpleStates, 23 Transitions 10KLOC)

22
Discussion

• Executable specification of model transformations
  in terms of UML
• -gt no additional scenario / FSM languages
• Automatic comparison
• Bisimulation
• Graph matching
• Naming inconsistencies
• Pre/postconditions
• Formal parameters ltltpostgtgtesm.statex
• -gt requires evaluation of conditions
• Integration
• Need glue (XSLT) to integrate modeling,
  transformation, and vizualisation tools

23

• Thank You