Daniel Amyot

1
UCM Scenarios andPath Traversal

• Daniel Amyot
• damyot_at_site.uottawa.ca
• SG17, Geneva, March 5th, 2002

2
Objectives

• Introduce scenario definitions
• Illustrate one possible path traversal mechanism
• Illustrate the generation of MSCs from UCMs
• Present current collection of requirements and
  point out general issues which need to be resolved

3
Scenario Definitions

• Enhances the behavioral modeling capability of
  UCM paths and path elements
• Requires a path data model (for conditions at
  various points along the path)
• Currently, global and modifiable Boolean
  variables
• Values may be assigned to variables along a path,
  in responsibilities
• Could be considered
• Variables may possibly have different types
  (integers)
• Variables may be scoped to paths or components
• Scenarios may be structured into sub-scenarios

4
Path Data Model - DTD

• lt!ELEMENT path-variable-list (boolean-variable)gt
• lt!ELEMENT boolean-variable EMPTY gt
• lt!ATTLIST boolean-variable
• name NMTOKEN REQUIRED
• boolvar-id ID REQUIRED
• ref-count NMTOKEN REQUIRED
  gt
• lt!ELEMENT variable-operation-list
  (variable-operation)gt
• lt!ELEMENT variable-operation EMPTY gt
• lt!ATTLIST variable-operation
• variable-id IDREF REQUIRED
• value CDATA REQUIRED
  gt

5
Scenario Definitions

• Requires a more formal definition of some
  notational elements
• Currently, logical expressions with global
  variables
• Currently, OR forks, selection policies, start
  points, waiting places, timers covered
• Scenario definitions consist of
• Name of scenario (scenarios may be grouped)
• Set of concurrent start points
• Set of initial values assigned to global
  variables
• Postcondition, expressed as a logical expression

6
Scenario Definitions - DTD

• lt!ELEMENT scenario-list (scenario-group) gt
• lt!ELEMENT scenario-group (scenario-definition) gt
• lt!ATTLIST scenario-group
• name NMTOKEN REQUIRED
• description CDATA IMPLIED gt
• lt!ELEMENT scenario-definition ((scenario-start),
• (variable-init),
  (postcondition)) gt
• lt!ATTLIST scenario-definition
• name NMTOKEN REQUIRED
• description CDATA IMPLIED gt
• lt!ELEMENT scenario-start EMPTY gt
• lt!ATTLIST scenario-start
• map-id IDREF REQUIRED
• start-id IDREF REQUIRED
  gt
• lt!ELEMENT variable-init EMPTY gt
• lt!ATTLIST variable-init
• variable-id IDREF REQUIRED
• value (TF) REQUIRED
  gt
• lt!ELEMENT postcondition EMPTY gt

7
Scenario Highlight (UCMNAV 2)
Example
8
Key Points - Scenario Definitions

• Path data model is not a problem domain data
  model
• Improves understanding of scenarios
• Scenario definitions are the foundation for more
  advanced functionality based on UCM path
  traversal mechanisms

9
UCM Path Traversal

• Starts at one or more parallel start points as
  defined by user
• Starts with initial values (true, false, or
  undetermined) for each path data variable as
  defined by the user
• Moves from path element A to path element B if
  continuation criteria are met for element A
• Each UCM path element has specific criteria
• Issues a warning if path traversal is stuck

10
UCM Path Traversal - Example I
?
?
?
?
A
R
A,1
3
2
5
4,?
5,?
,7,R
,6,?
3,?
11
UCM Path Traversal - Example II
?
B
S
3
A
R
5
B
?
A,1
2
7,?
4,?
5,?
3,R
,8,S
B,6,?
12
Example
User
Elevator Control System
down
not requested
up
already on list
down
moving
motor up
select elevator
door close
at floor
on list
OnList
decide on direction
below
motor down
above
else
stationary- memory
requested
in elevator
add to list
motor stop
door open
door closing-delay
remove from list
at requested floor
Arrival Sensor
Service Personnel
switch on
approaching floor
13
Example
User
Elevator Control System
down
not requested
up
already on list
switch on
moving
motor up
select elevator
above
door close
at floor
app. floor
on list
decide on direction
app. floor
below
motor down
above
app. floor
else
switch off
stationary- memory
requested
!OnList
in elevator
add to list
motor stop
Up
!Requested
door open
!Requested
door closing-delay
Requested
remove from list
at requested floor
Arrival Sensor
Service Personnel
switch on
approaching floor
14
Applications of UCM Path Traversal

• Highlighting
• Animation
• Requires sequence numbers
• MSC generation
• Requires component information
• Well-nestedness transformation and warning
  mechanism
• LQN generation
• Requires arrival and device characteristics,
  device demands, data access modes, response-time
  requirements
• Test case generation
• Requires controllable and observable activities

15
Path Traversal Requirements (1)

1. Path Traversal shall start at 1 to N parallel
   scenario start points as defined by the user
   (scenario-start).
2. Path Traversal shall start with initial values
   (true, false, or undetermined) for each path data
   variable as defined by the user (variable-init).
3. Path Traversal shall move from path element A to
   path element B if a) Path Traversal is
   currently visiting path element A, and b) there
   is a direct connection from A to B
   (hyperedge-connection), and c) the path
   continuation condition of path element A to path
   element B is fulfilled.
4. The path continuation condition for a start point
   shall be fulfilled if the logical expression for
   its guard evaluates to true (logical-condition of
   start).
5. The path continuation condition for end points
   not directly connected to waiting places or
   timers shall be always fulfilled.
6. The path continuation condition for a
   responsibility shall be always fulfilled.
7. The path continuation condition for an OR-fork
   shall be fulfilled if the path continuation
   condition of exactly one branch of the OR-fork is
   fulfilled.
8. The path continuation condition for a branch of
   an OR-fork shall be fulfilled if the logical
   expression for the branch evaluates to true
   (branch-condition of path-branching-characteristic
   ).
9. The path continuation condition for an OR-join
   shall be always fulfilled.
10. The path continuation condition for each branch
    of an AND-fork shall be always fulfilled.
11. The path continuation condition for an AND-join
    shall be fulfilled if Path Traversal is currently
    visiting the AND-join for all of its incoming
    paths.

16
Path Traversal Requirements (2)

1. The path continuation condition for a loop shall
   be fulfilled if the path continuation condition
   of exactly one branch is fulfilled (either the
   loop branch or the exit branch).
2. The path continuation condition for the loop
   branch shall be fulfilled if the logical
   expression for the loop exit evaluates to false
   (exit-condition of loop).
3. The path continuation condition for the exit
   branch shall be fulfilled if the logical
   expression for the loop exit evaluates to true
   (exit-condition of loop).
4. The path continuation condition for a static stub
   shall be always fulfilled.
5. The path continuation condition for a dynamic
   stub shall be fulfilled if the path continuation
   condition of exactly one plug-in of the dynamic
   stub is fulfilled.
6. The path continuation condition for a plug-in of
   a dynamic stub shall be fulfilled if the logical
   expression for the selection policy of the
   plug-in evaluates to true (branch-condition of
   plug-in-binding).
7. The path continuation condition for an end point
   and a waiting place connected directly with each
   other shall be fulfilled if a) Path Traversal is
   currently visiting the end point and the waiting
   place and b) the logical expression for the
   guard of the waiting place evaluates to true
   (logical-condition of waiting-place).
8. The path continuation condition for a waiting
   place shall be fulfilled if the logical
   expression for its guard evaluates to true
   (logical-condition of waiting-place).

17
Path Traversal Requirements (3)

1. The path continuation condition for an end point
   and a timer connected directly with each other
   shall be fulfilled if a) Path Traversal is
   currently visiting the end point and the timer
   and b) the path continuation condition for the
   non-timeout path of the timer is
   fulfilled.
2. The path continuation condition for a timer shall
   be fulfilled if exactly one of the following
   cases occurs a) The path continuation condition
   for the non-timeout path is fulfilled. b) The
   path continuation condition for the timeout path
   is fulfilled.
3. The path continuation condition for a non-timeout
   path shall be fulfilled if a) the timers
   timeout variable is set to false
   (timeout-variable of
   waiting-place) and b) the timers guard
   evaluates to true (logical-condition of
   waiting-place).
4. The path continuation condition for a timeout
   path shall be fulfilled if a) the timers
   timeout variable is set to true (timeout-variable
   of waiting-place) and b) a
   timeout path exists for the timer.
5. The path continuation condition for an empty
   point shall be always fulfilled.

18
Path Traversal Requirements (4)

1. Path Traversal shall execute the value assignment
   statements of a responsibility (variable-operation
   -list) if the path continuation condition for the
   responsibility is fulfilled.
2. Path Traversal shall execute the value assignment
   statements of a responsibility in the order
   defined by the user.
3. Path Traversal shall update the values of the
   path data variables immediately after executing
   one value assignment statement.
4. Path Traversal shall evaluate a logical
   expression to undetermined if any value within
   the logical expression evaluates to undetermined.
5. Path Traversal shall stop if it cannot move to
   another path element from any of the currently
   visited path elements.
6. Path Traversal shall regard the values of the
   path variables at the time path traversal stopped
   as postconditions of the traversed scenario.
7. Path Traversal shall issue a warning if Path
   Traversal has stopped, and a) Path Traversal is
   currently visiting one or more path elements
   other than end points or b) Path
   Traversal is currently visiting one or more end
   points connected directly to
   waiting places or timers or c) the
   postconditions of the traversed scenario do not
   match the postconditions defined
   by the user.

19
UCM Path Traversal Issues

• Component and plug-in instances
• Is a component a new instance or does it
  reference an existing component on the same or
  another map?
• If path traversal visits a plug-in map more than
  once, is it visiting the same plug-in or a new
  instance?
• If the plug-in is a new instance, the path
  segment on the plug-in map is also a new instance
  but components on the plug-in map may not
  necessarily be new instances
• Loops
• Suggested path traversal mechanism may be able to
  deal with loops
• For which applications do loops have to be
  preserved?
• Do we need integers?
• Multiple triggering of the same event (start
  point)
• Other elements not covered
• aborts, asynchronous interactions, and dynamic
  responsibilities

20
Key Points - UCM Path Traversal

• Many correct path traversal mechanisms exist
  because of breadth-first and depth-first
  approaches and various ways of dealing with
  concurrency
• Path traversal is instrumental for advanced
  functionality such as highlighting, animation, as
  well as the generation of MSC, LQN, and test
  cases
• The biggest open issues for path traversal
  revolve around component plug-in instances as
  well as loops

21
Generation of MSCs

• UCMs are good for (Stage 1)
• Describing multiple scenarios abstractly
• For analysing architectural alternatives
• MSC Sequence Diagrams are better for (Stage 2)
• Developing and presenting the details of
  interactions
• Describing lengthy sequences of messages in
  scenarios
• Providing access to well-developed methodologies
  and tools for analysis and synthesis
• UCM-to-MSC transformation helps to further bridge
  the gap between Stage 1 descriptions
  (require-ments) and Stage 2 descriptions (design).

Stage 1 Requirements and Service Description,
Stage 2 Message Sequence Information
22
Refining UCM with Messages
23
From UCM to MSC

• UCM component MSC instance
• UCM path crossing from abstract MSC message
  one component to another (implements
  causal flow)
• UCM start (or end) point abstract MSC message
• UCM pre/post-condition MSC condition
• UCM responsibility MSC action
• UCM OR-fork or dynamic multiple basic
  MSCsstub with multiple plug-ins
• UCM AND-fork MSC parallel inline box
• UCM loop MSC loop box
• UCM timer MSC timer

24
MSC Generation - Example I
System
A,1
2
4,?
5,?
,6,?
3,?
25
MSC Generation - Example II
System
?

4
8
2
S
5
7
1
A
3
R
6
?
B
26
Why Stop at MSCs?
UCMspec(XML)
RichTrace(XML)
MSC 96
LOTOStest cases
TTCN-3test cases
Performance models
Documentation (ps, pdf, cgm)
27
Key Points - MSC Generation

• Much value in a tool-supported translation
• Effortless (push of a button)
• MSCs in-sync with UCMs, forward traceability
• Basis for further refinement
• Synthetic abstract message may be refined into
  more concrete protocol messages
• Help to bridge the requirements/design gap
• Requires the path data model, scenario
  specifications, and traversal mechanism
• Issue (XML) intermediate output, which will be
  post-processed?