A Perspective on Harmonisation Benefits and Barriers Clive
A Perspective on Harmonisation: Benefits and Barriers Clive Jervis Rapporteur Q 15 Motorola UK Research Labs Motorola Copyright 2001 System and Software Engineering Research 1
ITU Languages Across Lifecycle UK USA RMTR air_in ITU languages are being used together today! taxi_in MSC taxi_out air_out ITU, ETSI Standards UK USA RMTR UK air_in USA RMTR air_in taxi_in MSC System/Integration Testing taxi_in Test Generation taxi_out air_out System Requirements TTCN UK USA RMTR air_in taxi_in UK MSC USA RMTR air_in taxi_out Test Generation taxi_out air_out ASN. 1 Everywhere! Box Requirements SDL Design Motorola Copyright 2001 Box Testing TTCN Code Generation Code System and Software Engineering Research 2
Problems: User Perspective Disparate languages that require: • individual training • separate tools & licenses Poor formal connection between languages: • leads to misuse of languages - e. g. MSC conditions used to represent SDL states • limited support for moving between languages - e. g. MSC to SDL or TTCN SDL to TTCN Management Perspective: • expensive tool & training costs • demarcation, i. e. less transferable skills Opportunity: More integrated tools leading to improved productivity, wider uptake Motorola Copyright 2001 System and Software Engineering Research 3
Some Benefits & Barriers Wouldn’t it be nice if: • there was a common look & feel across all notations - e. g. common representation for basic types, such as strings, Booleans, . . . • one notation could be used within another notation - e. g. parts of an SDL system could be defined by MSCs TTCN could incorporate SDL diagrams for state based test scripts • there was a universal data language - e. g. ASN. 1 could define operations, pointer types, … Unfortunately: • languages evolve independently - there are exceptions, such as GFT/MSC • same concepts treated differently - e. g. time • no general interfaces provided in languages - exception is MSC universal data interface - cannot use one notation within another • different formal basis between languages - e. g. MSC receive events, SDL/TTCN have consume events Motorola Copyright 2001 System and Software Engineering Research 4
Harmonisation: Minor Steps New recommendation that defines things common to all languages in family • meta-grammars, graphical and textual • basic lexical definitions - e. g. <letter>, <name>, <text>, … • basic graphical symbols - e. g. <frame symbol>, <text symbol>, <comment symbol> Compile glossary for commonly (mis)used terms • technical terms (i. e. have formal meaning in recommendations) - gates, environments, ports, messages • time - e. g. distinguishing timers, constraints, durations, absolute, relative … - agree timer event names (set, reset, timeout, stop, start, end) • descriptive terms (have informal meaning in recs. ) - e. g. specification, design, implementation Define common document formats • e. g. agreed subsection titles & order Motorola Copyright 2001 System and Software Engineering Research 5
Harmonisation: Medium Steps Agreement of core concepts • data types - e. g. time, duration, Boolean, integers, … (does not have to be formal - e. g. absolute time will be measured in seconds, represented by decimal numbers) • events - instantaneous, or take time - is creation one event or two (creating & created)? • channels & buffering Define relationship between languages • will permit languages to be used together accurately - e. g. does a message receipt in MSC correspond to message arrival or message consumption in SDL/TTCN? • will allow tools to span languages correctly - e. g. test generation from SDL to TTCN verify SDL upholds MSCs map types of one language to another Motorola Copyright 2001 System and Software Engineering Research 6
Harmonisation: Major Steps Common semantic framework • one semantic framework consisting of dynamic model, static model, data model, … Have core notation(s) and profiles • e. g. TTCN as profile of SDL GFT as profile of MSC SDL Types as profile of ASN. 1 Parameterise non-core aspects of a language • have separate languages for each core concept - e. g. ASN. 1 for data SDL for state machine definitions ? ? ? for channel/buffering semantics ? ? ? for time/performance • parameterise non-core aspects - permits users to ‘bolt-in’ their favourite languages/notations - e. g. data in MSC Motorola Copyright 2001 System and Software Engineering Research 7
- Slides: 7