system and software engineering research 1 motorola 2003 integrated application of msc clive jervis...
TRANSCRIPT
System and Software Engineering Research 1 Motorola 2003
Integrated Applicationof
MSC
Clive JervisRapporteur Q15
Motorola UK Research Labs
System and Software Engineering Research 2 Motorola 2003
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 …
System and Software Engineering Research 3 Motorola 2003
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, URNBox 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 contextse.g. MSC used as SDL Requirement & TTCN test purpose hence may have different data & semantics
Integration is Tool Specific
System and Software Engineering Research 4 Motorola 2003
MSC Processes
START
-
always takes too long
MEETING
PRESENT ARGUMENTS
COMPANY X OPINION
MOTOROLA OPINION
THROW OUT IDEA
COMPANY Y OPINION
AGREESUPERIOR ARGUMENT
COFFEE BREAK
where the real work is done
PROPOSE DECISION
MEETING AGREES
LUNCHwell deserved
MOTOROLAWITH
START
-
always takes too long
MEETING
PRESENT ARGUMENTS
COMPANY X OPINION
MOTOROLA OPINION
THROW OUT IDEA
COMPANY Y OPINION
AGREESUPERIOR ARGUMENT
COFFEE BREAK
where the real work is done
PROPOSE DECISION
MEETING AGREES
LUNCHwell deserved
MOTOROLAWITH
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)
UK USA RMTR
air_intaxi_in
taxi_out
air_out
UK USA RMTR
air_intaxi_in
taxi_out
air_out
SDL Validation
UK USA RMTR
air_intaxi_in
taxi_out
air_out
UK USA RMTR
air_intaxi_in
taxi_out
air_out
START
-
always takes too long
MEETING
PRESENT ARGUMENTS
COMPANY X OPINION
MOTOROLA OPINION
THROW OUT IDEA
COMPANY Y OPINION
AGREESUPERIOR ARGUMENT
COFFEE BREAK
where the real work is done
PROPOSE DECISION
MEETING AGREES
LUNCHwell deserved
MOTOROLAWITH
TTCN Generation
SDL Verification
Requirements V&V
Model Synthesis
System and Software Engineering Research 5 Motorola 2003
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
System and Software Engineering Research 6 Motorola 2003
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
System and Software Engineering Research 7 Motorola 2003
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?