UCM Path Traversal UCM Scenarios and Path Traversal

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

Page 2 Objectives u u 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 UCM Scenarios and Path Traversal

Page 3 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… Variables may possibly have different types (integers…) u Variables may be scoped to paths or components u Scenarios may be structured into sub-scenarios u UCM Scenarios and Path Traversal

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

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

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

Page 7 Scenario Highlight (UCMNAV 2) Example UCM Scenarios and Path Traversal

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

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

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

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

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

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

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

Page 15 Path Traversal Requirements (1) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Path Traversal shall start at 1 to N parallel scenario start points as defined by the user (scenario-start). Path Traversal shall start with initial values (true, false, or undetermined) for each path data variable as defined by the user (variable-init). 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. 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). The path continuation condition for end points not directly connected to waiting places or timers shall be always fulfilled. The path continuation condition for a responsibility shall be always fulfilled. 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. 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). The path continuation condition for an OR-join shall be always fulfilled. The path continuation condition for each branch of an AND-fork shall be always fulfilled. 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. UCM Scenarios and Path Traversal

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

Page 17 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 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 if a) 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. UCM Scenarios and Path Traversal

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

Page 19 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 u Loops – – – u 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 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 UCM Scenarios and Path Traversal

Page 20 Key Points - UCM Path Traversal u u u 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 UCM Scenarios and Path Traversal

Page 21 Generation of MSCs u u u 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 (requirements) and Stage 2 descriptions (design). Stage 1 … Requirements and Service Description, Stage 2 … Message Sequence Information UCM Scenarios and Path Traversal

Page 22 Refining UCM with Messages User. A Agent. B User. B req User: A Agent: B chk vrfy upd req User: B chk msg 1 ring vrfy upd ring SN User. A chk User: A Switch req Switch msg 2 msg 3 msg 4 User: B vrfy req upd ring SN msg 5 chk vrfy upd ring UCM Scenarios and Path Traversal User. B

Page 23 From UCM to MSC u u u u u 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 UCM Scenarios and Path Traversal

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

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

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

Page 27 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 – u u 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 postprocessed? UCM Scenarios and Path Traversal