ucm path traversal daniel amyot [email protected] sg17, geneva, march 5 th, 2002 ucm scenarios...

UC

M P

ath

Tra

vers

al

Daniel [email protected]

SG17, Geneva, March 5th, 2002

UCM Scenarios andPath Traversal

UCM Scenarios and Path Traversal

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


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


Path Data Model - DTD

<!ELEMENT path-variable-list (boolean-variable)*><!ELEMENT boolean-variable EMPTY ><!ATTLIST boolean-variable name NMTOKEN #REQUIRED boolvar-id ID #REQUIRED ref-count NMTOKEN #REQUIRED ><!ELEMENT variable-operation-list (variable-operation)*><!ELEMENT variable-operation EMPTY ><!ATTLIST variable-operation variable-id IDREF #REQUIRED value CDATA #REQUIRED >


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


Scenario Definitions - DTD<!ELEMENT scenario-list (scenario-group)* ><!ELEMENT scenario-group (scenario-definition)* ><!ATTLIST scenario-group name NMTOKEN #REQUIRED description CDATA #IMPLIED ><!ELEMENT scenario-definition ((scenario-start)*, (variable-init)*, (postcondition)*) ><!ATTLIST scenario-definition name NMTOKEN #REQUIRED description CDATA #IMPLIED ><!ELEMENT scenario-start EMPTY ><!ATTLIST scenario-start map-id IDREF #REQUIRED start-id IDREF #REQUIRED ><!ELEMENT variable-init EMPTY ><!ATTLIST variable-init variable-id IDREF #REQUIRED value (T|F) #REQUIRED ><!ELEMENT postcondition EMPTY ><!ATTLIST postcondition variable-id IDREF #REQUIRED value (T|F) #REQUIRED >


Scenario Highlight (UCMNAV 2) Example


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


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


X7

A RX6

X5X

4

X2

X1

X3

UCM Path Traversal - Example I

X7

A RX6

X5X

4

X2

X1

X3

A,12

4,5,

35

A,12,P3,

A,1,P,6,

,7,R


7,

UCM Path Traversal - Example II

3B

P4,3,R

A SX8

X5X

4

X2

X1

X3

R

B X6

X7

5

A,12

4,5,

3,RB,6,

PP3,R

A SX8

X5X

4

X2

X1

X3

R

B X6

X7

,8,S


down

ExampleUser

Arrival Sensor

Elevator Control System

abovebelow

decide ondirection

at floor

updown

selectelevator

approachingfloor

at requestedfloor

motorstop

doorclosing-delay

[requested]

dooropen

removefrom list

Service Personnel

stationary-memory

[not requested]

[else]

[on list]

already on list

inelevator

add to list

movingdoor close

motor up

motor down

at floor

down

selectelevator

[on list]

already on list

add to list

switch on

OnList


!OnList

!Requested

ExampleUser

Arrival Sensor

Elevator Control System

abovebelow

decide ondirection

at floor

updown

selectelevator

approachingfloor

at requestedfloor

motorstop

doorclosing-delay

[requested]

dooropen

removefrom list

Service Personnelswitch on

stationary-memory

[not requested]

[else]

[on list]

already on list

inelevator

add to list

movingdoor close

motor up

motor downabove

add to list

[else]

decide ondirection

moving

approachingfloor

[not requested]

inelevator

stationary-memory

door closemotor up moving

!Requested

Requested

[not requested]

approachingfloor

moving

approachingfloor

at requestedfloor

doorclosing-delay remove

from list

motorstop

[requested]

dooropen

stationary-memory

[off] exit

switch onabove

app. floorapp. floor

app. floorswitch off

Up

!Off

Off

switch on

switch off


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


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.


Path Traversal Requirements (2)12. 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).13. 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).14. 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).15. The path continuation condition for a static stub shall be always fulfilled.16. 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.17. 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).

18. 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).

19. 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).


Path Traversal Requirements (3)20. The path continuation condition for an end point and a timer connected directly with

each other shall be fulfilled ifa) Path Traversal is currently visiting the end point and the timer andb) the path continuation condition for the non-timeout path of the

timer is fulfilled.21. 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.

22. The path continuation condition for a non-timeout path shall be fulfilled ifa) the timer’s timeout variable is set to false (timeout-variable of

waiting-place) and b) the timer’s guard evaluates to true (logical-condition of waiting-place).

23. The path continuation condition for a timeout path shall be fulfilled ifa) the timer’s timeout variable is set to true (timeout-variable of waiting-

place) and

b) a timeout path exists for the timer.24. The path continuation condition for an empty point shall be always fulfilled.


Path Traversal Requirements (4)25. Path Traversal shall execute the value assignment statements of a responsibility

(variable-operation-list) if the path continuation condition for the responsibility is fulfilled.

26. Path Traversal shall execute the value assignment statements of a responsibility in the order defined by the user.

27. Path Traversal shall update the values of the path data variables immediately after executing one value assignment statement.

28. Path Traversal shall evaluate a logical expression to undetermined if any value within the logical expression evaluates to undetermined.

29. Path Traversal shall stop if it cannot move to another path element from any of the currently visited path elements.

30. Path Traversal shall regard the values of the path variables at the time path traversal stopped as postconditions of the traversed scenario.

31. 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 orb) Path Traversal is currently visiting one or more end points connected

directly to waiting places or timers orc) the postconditions of the traversed scenario do not match the

postconditions defined by the user.


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


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


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


UserA AgentA AgentB UserB

req

msg1

ring

vrfy

upd

chk

UserA Switch SN UserBreq

chk

upd

msg2

ring

msg5

msg4msg3

vrfy

SN

req

chk

upd

User:BUser:A Switch

vrfy

ring

User:A Agent:A Agent:B User:B

req ringvrfy updchk

Refining UCM with Messages


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 MSCs

stub with multiple plug-ins UCM AND-fork MSC parallel inline box UCM loop MSC loop box UCM timer MSC timer


MSC Generation - Example I

A,12

4,5,

A,12,P3,

,6,

A,1,P,7,R

4

7A R6

52

13

System


MSC Generation - Example II

AS85

42

13

R

B

6

7

A,12

4,5,

3,RB,6,

7,

P4,3,R

PP3,R

,8,S

‘

System


Why Stop at MSCs?

UCMspec(XML)

MSC’2000

HMSCUMLcollaboration

diagrams

UMLsequencediagrams

RichTrace(XML)

MSC ’96

LOTOStest cases

TTCN-3test cases

Performancemodels

Documentation(ps, pdf, cgm)


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?

ucm path traversal daniel amyot [email protected] sg17, geneva, march 5 th, 2002 ucm scenarios...

Documents

path traversal x

path traversal slide

ucm path traversal example

ucm path element

path traversal objectives

ucm path traversal mechanisms

path elements u

ucm scenarios