From UCMs to MSC

1
From UCMs to MSC

• Daniel Amyot
• Canada
• damyot_at_site.uottawa.ca

2
Table of Content

• Part I User Requirements Notation (URN)
• Motivation
• Requirements for URN
• Current proposal
• Use Case Maps (UCM) as URN-FR
• Part II Moving from URN-FR towards MSC
• Motivation
• Data Model, Scenarios, and Transformation
• Example and Prototype
• Part III Issues, Conclusions and Future Work

3
Part IUser Requirements Notation (URN)
4
Motivation for URN
SDL
MSC
Informal requirements? Use Cases?
URN!

• Common design and standardisation approaches
  already uses scenarios
• Needs improvement to cope with new realities

5
User Requirements Notation Initial Requirements

• Focus on early stages of design, with scenarios
• Capture user requirements when little design
  detail is available
• No messages, components, or component states
  required
• Reusability of scenarios and allocation to
  components
• Dynamic refinement capabilities
• Modelling of agent systems, early performance
  analysis, and early detection of undesirable
  interactions

6
Use Case Maps as URN-FR

• Satisfy most of initial Q12/10 requirements
• UCM scenario paths illustrate causal
  relationships among responsibilities
• Optional integration of behaviour to structure
• Description of dynamic variation of
  behavior/structure
• Facilitate abstract thinking, provide an overview
  of the system at an appropriate level of detail
• Allow reasoning about architectural alternatives
• Convey a lot of information in a compact form
• Show interactions of scenarios (features)
• Low learning curve, positive experience so far

7
URN-FR Example
8
URN-FR Advanced Notation
9
Plug-ins for Sorig and Sscreen
10
Plug-ins for Sterm and Sdisplay
11
Part IIMoving from URN-FRtowards MSC
12
Motivation for Transformation

• URN-FR is good for describing multiple scenarios
  abstractly and for analysing architectural
  alternatives (Stage 1).
• MSCs are better for developing and presenting the
  details of interactions, for describing lengthy
  sequences of messages in individual scenarios,
  and for providing access to well-developed
  methodologies and tools for analysis and
  synthesis (Stage 2).
• URN-FR to MSC transformation bridges the gap
  between Stage 1 descriptions and Stage 2
  descriptions.

13
Refining URN-FR with Messages
14
From URN-FR to MSC

• URN-FR component MSC instance
• URN-FR path crossing from one component to
  another abstract MSC message
• URN-FR start (or end) point abstract MSC
  message
• URN-FR pre/post-condition MSC condition
• URN-FR responsibility MSC action
• URN-FR OR-fork or a dynamic stub with multiple
  plug-ins multiple basic MSCs
• URN-FR AND-fork MSC parallel inline box
• URN-FR loop MSC loop box
• URN-FR timer MSC timer

15
Approaches to Transformation

• Intermediate Formalism
• Extract LOTOS or SDL model from URN-FR
• Generate MSC from model
• High quality and realistic MSC, but much effort
• Direct transformation
• Requires less effort, but MSC of lower quality
• Might be enough for early analysis and refinement
• In both cases, URN-FR descriptions need to be
  supplemented by a path data model

16
Need for Data Model

• 64 potential combination of end-to-end paths
• Reduced to 4 when conditions are taken into
  account
• Similar problem with combinations of plug-ins in
  dynamic stubs
• Path data model can help identify specific
  scenarios

17
Scenario Variables and Definitions

• Scenario variables are needed for conditions
• Simplest model global, boolean, unmodifiable
  variables, with logical operators
• Possible extensions scoping rules, data types,
  assignments, sub-scenarios
• Scenario definition named end-to-end scenario
  characterised by initial values assigned to the
  (boolean) scenario variables
• Scenarios can be grouped for convenience

18
Example

• From the example URN-FR specification
• Seven scenario variables are required
• Potential of 27 128 scenarios (assuming all
  choice points are guarded and deterministic)
• 15 MSC scenarios can be generated
• Basic Call 2 (success or busy)
• CND 1 (display)
• OCS 3 (success, busy, or denied)
• TeenLine 6 (active, valid PIN, timeout, busy)
• CND-OCS 1 (success/display)
• CND-TeenLine 2
• OCS-TeenLine 0 (already covered)
• CND-OCS-TeenLine 0 (already covered)

19
Example OCS, Successful Call

• subOCS T
• subCND F
• subTL F
• Busy F
• OnOCSList F
• PINvalid X
• TLactive X
• Start point req

20
OCS - CND Interaction

• subOCS T
• subCND T
• subTL F
• Busy F
• OnOCSList F
• PINvalid X
• TLactive X
• Start point req
• Desirable interaction!

21
OCS - TeenLine Interaction

• subOCS T
• subCND F
• subTL T
• Busy T
• OnOCSList F
• PINvalid F
• TLactive T
• Start point req
• Undesirable interaction! TeenLine prevented by
  OCS.

22
Prototype UCMNav 2.0.0 (alpha)
23
Part IIIIssues, Conclusionsand Future Work
24
Issues for Transformation

• Is URN-FR sufficient? Need to consider URN-NFR?
• Precise URN-FR semantics (plug-in new instances)?
• Advanced constructs (dyn. resp/comp, comp.
  types)?
• Need for intermediate model (LOTOS, SDL, )?
• Need for message patterns? How much info in URN?
• Path data model align with ASN.1, MSC2000, SDL?
• Extend data types (enumerations, integers, )?
• Operations on scenario variables by
  responsibilities?
• Scope definitions for scenario variables?
• Token variables for concurrent scenarios?
• Loop detection? Access to timers (timeouts)?
• Generation of HMSCs? MSC2000?

25
Why Stop at MSCs?
26
Conclusions and Future Work

• There is much value in a tool-supported
  URN-FR-to-MSC translation
• Need for data model and related issues were
  identified
• Good experience so far
• Method and tool being applied to industrial
  examples
• Prototype under development
• Should we go Open Source to accelerate its
  development?
• Should we target a Rich Trace format?
• What do we do next?
• What should be part of the URN standard?

27
For More Information

• http//www.UseCaseMaps.org/urnhttp//www.cs.toron
  to.edu/km/GRL/http//www.cs.toronto.edu/km/OME/