Integrated Application

1
Integrated Application of MSC Clive
Jervis Rapporteur Q15 Motorola UK Research Labs
2
MSC Used Across Lifecycle

• Standards
• Telecommunication Standards incorporate MSCs
• System Requirements
• MSC used at highest levels of system
  specification
• - e.g. end-to-end protocol for wireless telephony
• Each Instance corresponds to network element
• Box Requirements
• MSCs used to express behaviour within network
  element
• - e.g. processes within a box, processes within
  an application
• Test Specification
• Test purposes defined using MSC
• - i.e. specifications for constructing tests
• Validation
• MSC traces generated from
• - e.g. system tests, model simulations,
  application code

3
MSC Used with Different Languages

• In each of its uses, MSC may
• interface to different languages
• have a different levels of abstraction
• have different semantics ascribed
• Interface Languages
• System Requirements
• SDL, ASN.1, URN
• Box Requirements
• SDL, ASN.1, programming languages, op systems
• MSC refinement
• Test Verification
• SDL, ASN.1
• TTCN 2/3, JUNIT, scripting languages
• Same MSC used in different contexts
• e.g. MSC used as SDL Requirement TTCN test
  purpose hence may have different data
  semantics

Integration is Tool Specific
4
MSC Processes

• Verification Validation
• property/pathology checking
• refinement
• model synthesis
• Design Validation
• model validation
• application code validation
• test validation
• Design Verification
• model checking
• SDL upholds MSCs
• Test Specification
• test generation (one-2-many)
• test scripting (one-2-one)

Requirements VV
Model Synthesis
SDL Validation
SDL Verification
TTCN Generation
5
Binding to Other languages

• No formal binding between MSC and other languages
• excepting MSC data with SDL data
• foundational differences that make this
  impossible today
• Other Language Concepts not expressible in MSC
• multiple creation of processes/blocks
• no signal queuing/buffering/priority
• - hence no queue manipulation
• MSC Concepts not Expressible in Other Languages
• time constraints
• conditions (global states)
• substitution (messages, instances, )
• Semantics can vary depending upon MSC use
• with the same language
• - e.g. MSC as SDL requirement vs MSC as SDL trace
• across languages
• - queue semantics differ between TTCN and SDL

6
Possible Solutions

• Adopt a UML-like profiling approach
• e.g. GFT as MSC profile
• e.g. SDL trace profile
• - receipt interpreted as consumption,
• - lost message as queued signal
• requires profiling standard
• Warning! This could create too much diversity
• - dont introduce new symbols, permit only simple
  semantic mapping
• Define Core Integrated languages
• only include things that can be mapped between
  languages
• mapping is part of requirement
• May be prove too restrictive
• Factor Languages
• separate out different concepts into different
  languages
• - e.g. data language, process language, test
  configuration language
• parameterise languages
• - allow plug-ins for data, etc.

7
Drivers for Integration

• Tools
• users want tools not standards
• - influencing standards is a route to tools
• language integration will only be useful if
  there is also tool integration
• Benefit
• must have clear benefit
• - marginal benefits tend to be rejected by users
• must be straightforward to use
• - e.g. consider generating TTCN-2 from SDL
• must be reasonably priced
• Competition (UML)
• language marketed as integrated language
• reflected by closer integration within tools
• - e.g. identifiers declared once and shared
  between diagram types

What Form will an Integrated ITU Solution Take?