RABEB MIZOUNI

1
USE CASES COMPOSITION AND VERIFICATION
Proposal For Thesis Research in Partial
Fulfillment of the Requirements for the Degree
of Doctor of Philosophy
RABEB MIZOUNI
June 2004
Research Granted by France Telecom
2
Outline

• 1- Introduction
• Scenario-based Approaches Definition
• Scenario Notations

• 2- Problem Statement
• Modeling
• Composition
• Validation and Verification

• 3-Project Definition and Contributions
• Scenario language
• Graph Generation
• Integration

4- Future Work
5- Time Table
3
Introduction

• Scenario-based approaches are one of the
  approaches used for requirements
• elicitation,
• modeling,
• analysis, and
• validation
• They consist of representing the system
  behaviour as a set of scenarios.
• Each scenario represents a partial description
  of the system behaviour as seen by the user.

4
Introduction (Cont)

• Advantages
• Intuitivity closer to the user view
• Incremental process usually requirements are
  not complete in first stage of the development.

• Disadvantages
• How to integrate Different Scenarios together to
  get the overall system specification
• Large number of scenarios
• Inconsistency
• Incompleteness

5
Scenario Notations

• It exists different notations to represent
  scenarios with different level of abstraction.

6
Problem Statement
Composition
Modeling
Scenario-basedApproaches
How to compose scenarios
How to represent scenarios
V V
What criteria to use ?
7
Problem Statement Modeling

• Modeling
• How to model the scenarios when collecting
• Abstraction Level of the model,
• Aspects to consider
• What is the model to derive after analysis and
  synthesis

Richer is the model, higher is the complexity of
the composition
Trade-off Expressiveness vs. Complexity
8
Problematic Statement Composition
I. State Characterization
Sc1

• S1 can be characterized by
• Valuation of a vector of variables
• S1 v11, v22
• Trace Based
• Traces that end up to it (a)
• Traces that can be executed from it (b, c)

a
S1
b
c
9
Problem Statement Implicit Composition
Composition
Same State
(a,d) originally not specified IMPLIED
SCENARIO Completion of the specification if
it is a desired behaviour - If undesired,
should be removed
Interactivity Not all implied scenarios have to
be removed Automation all implied scenarios are
accepted or all are removed
10
Problem Statement Explicit Composition

• Either a relation of ordering is specified
  between scenarios or they are constrained with
  some conditions.
• Notations like HMSCs are used to specify the
  order of scenarios.

11
Problem Statement Composition with architectural
Constraints
How to respect the architectural Constraints
in the generation of a global system
specification ?
System specification
Composition
?
Architectural Constraints
12
Problem Statement V V

• Validation guided by the user
• Verification
• Detecting inconsistencies
• Intra-scenario inconsistencies
• Inter-scenario inconsistencies
• Conformance Relation
• Trace Equivalence (Trace Inclusion)
• Simulation
• Bisimulation

13
Some Existing Approaches

• Trace-Based Characterization

?

• Alur et al.

MSCsunder asynchronous and synchronous
semantics, and for different communication
architecture Generation of automaton (Weak
Realizability) or deadlock-free automaton (Safe
realizability) - Basic MSCs

• Sÿsta et al.

• No specification of explicit loops (Implicit
  Loops)
• All the variables are used to characterize the
  automaton state.

2. Variable-Based Characterization

• Salah et al.

• Whittle et al.

14
Project Definition
Composition
Model
Explicit Loop
Explicit Loop Protection
State Characterization
Implicit
Explicit
VV
Intra-use Case Inconsistencies
SDL
15
Model Explicit Loops
Project Definition
16
Contributions Model Definition

• State Characterization

V v1, v2, , vi, vi1, ,vn
Location Variable
Control Variable
v1 1, v2, 1, vi 5
vn gt 4
Only Location variables are concerned in the
composition of use cases.
Increment
Action
vn vn1
v1 1, v2, 1, vi 6
17
Intra-Use Case Inconsistencies
a2
a4
a3
a1
a2
a1
a4
a3
Context
Context1
Context 2
Context 3
b1
b2
b1
b5
b2
b4
b3
b4
b3
Context 1 Term 1 Context 2 Term 2 Context
3 Term 3
Context Term 1 ? Term 2 ? Term3

• Context defined by the location constraints.
• B5 location constraints are never satisfied in
  the node so it is eliminated.

Project Definition
18
Composition Loop Protection
Decorating different nodes that belong to a loop.
Project Definition
19
Composition Implicit

• Implicitly, Loop protection points out the
  connections points of the graph.

20
Composition Implicit Integration
Same Location
Same Location
Merging
Same Location
Use Case 1
Use Case 2
Project Definition
21
Future Work
done
done
done
22
Time Table

• Courses
• Comprehensive exam
• Literature Review
• Extension of the model with Control Variables and
  explicit loops
• Articles writing
• Proposal

January 2004
June 2004

• Conformance Relations and Proofs

Implementation
September 2004

• Implied scenarios and Constrained Composition

January 2005

• Architectural Issues

Implementation
May 2005

• HMSCs semantics extensions

September 2005

• Mapping to SDL

January 2006

• Case Study and Thesis Writing

23
Publications

• Ghj
• Jklj
• l
• l

24
Thank you !
25
Contributions Model definition

• The state characterization is done by the
  definition of vector of variables. Each Variable
  has a finite domain of its possible values.
• We distinguish between two types of variables
  Location and Control.
• An action is the elementary component of a use
  case description. It is defined according to the
  state variable constraints, pre-conditions, that
  when fulfilled a label can be executed. The
  system moves to a new state, expressed in term of
  action post-conditions.

Syntax
26
Contributions Syntax Definition
Begin_Use_Case Begin_Loop L1 n1
End_Loop .
Begin_Path Begin_Action a1
End_Action
. Begin_Loop L2
End_Loop End_Path
End_Use_Case
27
Contributions Automaton Derivation
Use Case Graphs
Transform 1
no
SCN Graphs
Transform 2
no
All loops are treated
Use Cases Merging
System Automaton
28
Contributions Automaton Derivation
Use Case Graphs
Transform 1
no
SCN Graphs
Transform 2
no
All loops are treated
Use Cases Merging
System Automaton
Work accepted in NOTERE2004
29
Project Definition

• We propose to
• Develop a model of scenario representation that
  allows
• The distinction between control and location
  variables.
• The reduction of the automaton states
• The specification of explicit loops with an
  optional iteration number.
• Compose the different scenarios
• Implicit and Explicit composition
• Generate an SDL specification by providing an
  architecture specification of the system
• Through the generation of HMSCs

Modeling and Implicit Integration
30
Contribution
Use Case Graphs
Transform 1
no
SCN Graphs
Transform 2
no
All loops are treated
Use Cases Merging
System Automaton
31
Contributions Node Definition

• Each node of the graph is defined by the
  valuation of the location variables.
• We define the context of a node to be
• conjunctions of the disjunction of the
  location post conditions of its ingoing
  actions and the disjunction of the location pre
  conditions of its outgoing actions .
• It has the form

Context Term 1 ? Term 2 ? ? Term n
32
Project Proposition
Textual/Graphical To Graph
G1
G2
SDL
Intra-Use Case Coherence and Loop protection
Mapping
G1
G2
Comp. Pattern
System Graph
Composition (default Implicit)
Composition (default Implicit)
HMSCs MSCs
Comp. Constraints
Conformance relation