1. UCM Path Traversal Daniel Amyot damyot@site.uottawa.ca SG17, Geneva, March 5 th, 2002 UCM Scenarios and Path Traversal

2. Page 2 UCM Scenarios and Path Traversal Objectives u Introduce scenario definitions u Illustrate one possible path traversal mechanism u Illustrate the generation of MSCs from UCMs u Present current collection of requirements and point out general issues which need to be resolved

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

4. Page 4 UCM Scenarios and Path Traversal Path Data Model - DTD <!ATTLIST boolean-variable name NMTOKEN #REQUIRED boolvar-id ID #REQUIRED ref-count NMTOKEN #REQUIRED > <!ATTLIST variable-operation variable-id IDREF #REQUIRED value CDATA #REQUIRED >

5. Page 5 UCM Scenarios and Path Traversal Scenario Definitions u 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 u 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. Page 6 UCM Scenarios and Path Traversal Scenario Definitions - DTD <!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 > <!ATTLIST scenario-start map-id IDREF #REQUIRED start-id IDREF #REQUIRED > <!ATTLIST variable-init variable-id IDREF #REQUIRED value (T|F) #REQUIRED > <!ATTLIST postcondition variable-id IDREF #REQUIRED value (T|F) #REQUIRED >

7. Page 7 UCM Scenarios and Path Traversal Scenario Highlight (UCMN AV 2) Example

8. Page 8 UCM Scenarios and Path Traversal Key Points - Scenario Definitions u Path data model is not a problem domain data model u Improves understanding of scenarios u Scenario definitions are the foundation for more advanced functionality based on UCM path traversal mechanisms

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

10. Page 10 UCM Scenarios and Path Traversal X 7 AR X 6 X 5 X 4 X 2 X 1 X 3 UCM Path Traversal - Example I X 7 AR X 6 X 5 X 4 X 2 X 1 X 3 A,1 2 4, 5, 3 5 A,1 2,P 3, A,1,P,6,,7,R

11. Page 11 UCM Scenarios and Path Traversal 7, UCM Path Traversal - Example II 3 B P 4, 3,R A S X 8 X 5 X 4 X 2 X 1 X 3 R B X 6 X 7 5 A,1 2 4, 5, 3,R B,6, P P 3,R A S X 8 X 5 X 4 X 2 X 1 X 3 R B X 6 X 7,8,S

12. Page 12 UCM Scenarios and Path Traversal down Example User Arrival Sensor Elevator Control System above below decide on direction at floor up down select elevator approaching floor at requested floor motor stop door closing-delay [requested] door open remove from list Service Personnel stationary- memory [not requested] [else] [on list] already on list in elevator add to list moving door close motor up motor down at floor down select elevator [on list] already on list add to list switch on OnList

13. Page 13 UCM Scenarios and Path Traversal !OnList !Requested Example User Arrival Sensor Elevator Control System above below decide on direction at floor up down select elevator approaching floor at requested floor motor stop door closing-delay [requested] door open remove from list Service Personnel switch on stationary- memory [not requested] [else] [on list] already on list in elevator add to list moving door close motor up motor down above add to list [else] decide on direction moving approaching floor [not requested] in elevator stationary- memory door close motor up moving !Requested Requested [not requested] approaching floor moving approaching floor at requested floor door closing-delay remove from list motor stop [requested] door open stationary- memory [off] exit switch on above app. floor switch off Up !Off Off switch on switch off

14. Page 14 UCM Scenarios and Path Traversal Applications of UCM Path Traversal u Highlighting u Animation – Requires sequence numbers u MSC generation – Requires component information – Well-nestedness transformation and warning mechanism u LQN generation – Requires arrival and device characteristics, device demands, data access modes, response-time requirements u Test case generation – Requires controllable and observable activities

15. Page 15 UCM Scenarios and Path Traversal 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. Page 16 UCM Scenarios and Path Traversal 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).

17. Page 17 UCM Scenarios and Path Traversal Path Traversal Requirements (3) 20. 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. 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 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). 23. 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. 24. The path continuation condition for an empty point shall be always fulfilled.

18. Page 18 UCM Scenarios and Path Traversal 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 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. Page 19 UCM Scenarios and Path Traversal UCM Path Traversal Issues u 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? u 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 u 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? u Multiple triggering of the same event (start point) u Other elements not covered – aborts, asynchronous interactions, and dynamic responsibilities

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

21. Page 21 UCM Scenarios and Path Traversal Generation of MSCs u UCMs are good for… (Stage 1) – Describing multiple scenarios abstractly – For analysing architectural alternatives u 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 u 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. Page 22 UCM Scenarios and Path Traversal UserAAgentAAgentBUserB req msg1 ring vrfy upd chk UserASwitchSNUserB req chk upd msg2 ring msg5 msg4 msg3 vrfy SN req chk upd User:BUser:ASwitch vrfy ring User:AAgent:AAgent:BUser:B req ring vrfy upd chk Refining UCM with Messages

23. Page 23 UCM Scenarios and Path Traversal 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

24. Page 24 UCM Scenarios and Path Traversal MSC Generation - Example I A,1 2 4, 5, A,1 2,P 3,,6, A,1,P,7,R 4 7 AR 6 5 2 1 3 System

25. Page 25 UCM Scenarios and Path Traversal MSC Generation - Example II A S 8 5 4 2 1 3 R B 6 7 A,1 2 4, 5, 3,R B,6, 7, P 4, 3,R P P,8,S System

26. Page 26 UCM Scenarios and Path Traversal Why Stop at MSCs? UCM spec (XML) MSC2000HMSC UML collaboration diagrams UML sequence diagrams Rich Trace (XML) MSC 96 L OTOS test cases TTCN-3 test cases Performance models Documentation (ps, pdf, cgm)

27. Page 27 UCM Scenarios and Path Traversal Key Points - MSC Generation u Much value in a tool-supported translation – Effortless (push of a button) – MSCs in-sync with UCMs, forward traceability – Basis for further refinement u Synthetic abstract message may be refined into more concrete protocol messages… – Help to bridge the requirements/design gap u Requires the path data model, scenario specifications, and traversal mechanism u Issue: (XML) intermediate output, which will be post- processed?