Integrated Application
of
MSC
Clive Jervis
Rapporteur Q15
Motorola UK Research Labs
Motorola 2003
System and Software Engineering Research
1
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 …
Motorola 2003
System and Software Engineering Research
2
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
Motorola 2003
System and Software Engineering Research
3
MSC Processes
UK
USA
RMTR
air_in
taxi_in
Requirements V&V
taxi_out
air_out
Model Synthesis
UK
START
MEETING
COMPANY X
OPINION
COMPANY Y
OPINION
MOTOROLA OPINION
THROW OUT
IDEA
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
COFFEE
BREAK
-
USA
RMTR
air_in
alway s takes
too long
PRESENT
ARGUMENTS
where the real
work is done
taxi_in
SDL Validation
taxi_out
air_out
PROPOSE
DECISION
MEETING
AGREES
well
deserv ed
LUNCH
UK
USA
RMTR
START
MEETING
air_in
alway s takes
too long
PRESENT
ARGUMENTS
taxi_in
taxi_out
air_out
COMPANY X
OPINION
SDL Verification
COMPANY Y
OPINION
MOTOROLA OPINION
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
THROW OUT
IDEA
where the real
work is done
COFFEE
BREAK
-
PROPOSE
DECISION
MEETING
AGREES
well
deserv ed
LUNCH
UK
USA
RMTR
air_in
taxi_in
taxi_out
air_out
START
MEETING
TTCN
Generation
always takes
too long
PRESENT
ARGUMENTS
COMPANY X
OPINION
COMPANY Y
OPINION
MOTOROLA OPINION
THROW OUT
IDEA
-
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
COFFEE
BREAK
where the real
work is done
PROPOSE
DECISION
MEETING
AGREES
LUNCH
Motorola 2003
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)
well
deserved
System and Software Engineering Research
4
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
Motorola 2003
System and Software Engineering Research
5
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
- don’t 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.
• Radical, lots of work, backward incompatibility
Motorola 2003
System and Software Engineering Research
6
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?
Motorola 2003
System and Software Engineering Research
7