1. System and Software Engineering Research 1 Motorola 2003 Integrated Application of MSC Clive Jervis Rapporteur Q15 Motorola UK Research Labs

2. 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 …

3. 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, 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. System and Software Engineering Research 4 Motorola 2003 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) UKUSARMTR air_in taxi_in taxi_out air_out UKUSARMTR air_in taxi_in taxi_out air_out SDL Validation UKUSARMTR air_in taxi_in taxi_out air_out UKUSARMTR air_in taxi_in taxi_out air_out TTCN Generation SDL Verification Requirements V&V Model Synthesis

5. 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

6. 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 - 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. Radical, lots of work, backward incompatibility

7. 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?