Language Co-ordination 05/05/2019 Language Co-ordination Issues and Objectives Rick Reed TSE Ltd This presentation was used to introduce the ITU-T SG17 work shop on 02 March 2002: “Framework and scope of formal languages”. The work shop was organised to launch the Language Co-ordination project - described in this presentation. Contributions were invited on the various languages and notations related to SG17 regardless of whether these are SG17 or even ITU standards. Methods and tools are also an issue, so contributions were also invited on the viewpoints and interests of various different organisations. From outside ITU the other contributions include UML 2.0, and a tool producer view from Klocwork Solutions. Other contributions from SG17 members focused on the IETF view, and supplier specific issues. Two contributions from Telenor proposed a matrix to co-ordinate the languages. Contributors were advised of the intention to have a work shop rather the a short conference: that is as well as presenting ideas it is important to raise and discuss issues to be resolved. The “Results and plans” at the end of the day is intended to be a summary of the various discussions and input to the Language Co-ordination project. This presentation kicked off the work shop and the Language Co-ordination project. At the end of the day the conclusions were not very specific, partly because few of the presentations focussed on the specific needs of the project. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Language Co-ordination 05/05/2019 System viewpoints enterprise engineer with view view technology System information For systems engineering in general it is useful to be able to view the system in different ways. Different views of the system allow different facts about the system to be considered. The Open Distributed Processing (ODP) approach has five different views: enterprise, information, computation, design ("engineering") and technology as above. There may be other views of the system such as the (rather important) user view and the financial view. Each view of a system is an abstraction of the system omitting some some details and including others. Though it may be the case that the boundary of “the system” is different in different views, that will be ignored. A record of the view from a viewpoint can be made, producing a model of the system. Such a model could just be a natural language description or (more usefully) in some formal notation with names and annotations adding inferred meaning. If a model of a system does not include the unique identity of the system it describes a number of systems: there can be other systems that correspond to the same model. Engineering is usually concerned with such models, sometimes with identity as an attribute. For example the C program code of a protocol handler is instantiated for each instance of the protocol handler. The benefit of different views is that it allows the engineer to concentrate on different issues, and there is usually a different formal notation for each view that emphasises the issues to be considered. design computational Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

ITU-T Formal Languages for Software Engineering Language Co-ordination 05/05/2019 ITU-T Formal Languages for Software Engineering ASN.1 data to encode/decode MSC interaction sequences SDL stimulus/response behaviour TTCN trace conformance other issues requirements modelling deployment Software engineering is a large proportion of the engineering in modern telecommunications systems, and even some elements that are implemented in hardware are specified and sometimes implemented using software techniques. The main ITU-T languages used for this purpose are ASN.1, MSC, SDL and TTCN. For requirements capture and object modelling, languages such as UML are sometimes used. For implementation languages such as C, C++ or CHILL are used - though increasingly code is generated from SDL using C (or C++) as an intermediate language. Similarly, encoders and decoders in C are often generated directly from ASN.1 for the data content of messages to generate data to some agreed encoding rules such as BER or PER or ECN. Use of ASN.1 and agreed encoding ensures that the data sent is decoded to represent the same values everywhere. This alone does not ensure inter-operability. Interoperation stimulus/response sequences of messages between entities can be given in MSC, and while this is useful to get an overview of the interaction, it is usually not practical to specify the whole behaviour using MSC. SDL is used to state how the responses (including parameter values) are generated for each stimulus. TTCN can be derived from MSC or SDL descriptions to define tests for conformance to a specification. Although these four languages give good engineering coverage, there are still some aspects that are not covered such as requirements capture. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Methodology of Z.100 Supplement 1 Language Co-ordination 05/05/2019 ??? Methodology of Z.100 Supplement 1 ??? ASN.1 MSC+SDL TTCN ??? Z.100 Supplement 1 gives a framework methodology for the use of ASN.1, MSC, SDL and TTCN. The general framework of activities is shown in the diagram above. Within ETSI this is supplemented by a number of additional guidelines and advice from the PEX. The SDL+ methodology is not comprehensive because it does not cover deployment issues, and more over is now a little out of date because all the languages have evolved since its publication. However, it can be seen that no specific language is mentioned for requirements capture, classification or validation. The issue therefore arises: What is the appropriate set of languages for a methodology? Probably the implementation language should be omitted, but it might be appropriate to include some UML notations, URN and ODL. What about languages such as XML and the ROSE (remote operations) standard? Even within the four languages mentioned above there are some co-ordination issues. For example, ASN.1 enables sets of values to be defined, but does not define any operations so that expressions such as x+1 do not have any meaning in ASN.1. When ASN.1 is used with SDL, some operations are implicitly defined (for example giving meaning to x+1), but further issues arise with compatibility of values, adding operators that are not implicitly defined and inheritance. Another example, is the meaning of consuming a message at an MSC instance and consuming a signal in SDL. Are these the same? C, C++, ??? Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Common language models Language Co-ordination 05/05/2019 Common language models ASN.1 MSC SDL Notation set theory process algebra ASM Formal Semantic model Common concrete syntax? Common abstract syntax? Common semantics? It has been proposed (several times) that perhaps one language could be used for all models, and it is already the case that languages such as SDL can be used in different ways for different purposes, such as specification and implementation. However, it is doubtful whether one language would be suitable for all purposes, and it is more likely that different notations will continue to co-exist. On the other hand items specified in one model in one language, often have a one to one correspondence with items specified in another model of the same system in another language. What is needed are way of using different languages in combination to so that overlapping parts can: be compared, thus detecting errors if they differ; or be made common, or one model derived from the other. This can be done easily if the two notations have the same syntax and also the same semantics for the concept behind the items in common. Unfortunately a common grammar between languages is relatively unusual. Even for items such as INTEGER, there can be some differences depending on the notation (for example, maximum and minimum). It is difficult enough to define the formal semantics of one notation. Some issues are: Can common semantics be defined? Does a common meta-model help? Previous experience is that formal semantic models take a lot of effort for one language, and languages with different paradigms increase the difficulty. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Co-ordination in Ongoing SG17 Language Studies Language Co-ordination 05/05/2019 Co-ordination in Ongoing SG17 Language Studies Q.13/17 SDL-2000 with ASN.1 2002 Q.14/17 SDL data encoding Q.16/17 MSC-2000 data interface binding to SDL-2000 data Q.17/17 SDL and MSC UML profiles Q.18/17 User requirements notation Q.20/17 TTCN-3 (Z.142 graphical) Q.23/17 SDL time and performance Q.Z/17 Grammars for Recs defining notations Some overlaps and gaps between notations are covered by existing studies. The impact (if any) of ASN.1 2002 on SDL will be covered by an update of the ASN.1 to SDL mapping in Z.105 under Q.13/17. The possibility of using SDL data with TTCN or on normative interfaces should be partially covered by Q.14/17 which has the objective to define encoding rules for SDL data. On possibility is to provide a SDL to ASN.1 mapping (Note Z.105 is a one way mapping of ASN.1 to SDL). Q.16/17 fills one gap between MSC and SDL providing SDL data to be used in sequences. Q.23/17 should fill in another gap by providing similar timing features in SDL to those for MSC. The issue of using ASN.1 with sequence charts is not yet a subject of study. Q.17/17 is really awaiting stabilisation of UML V2, which is expected to include notations which could be considered as variants of MSC and SDL. The current planned results for Q.17/17 are mapping profiles from UML models and notations to MSC and SDL. The further issue is therefore, whether it is in the interest of both OMG and ITU-T (and others such as ETSI) if the notations converge. URN is the proposed new (pair of) notation(s) in Q.18/17, which therefore also should cover co-ordination with the other languages. Under Q.20/17 a graphical format is being added to TTCN-3. The current proposal is a notation similar to MSC developed partly within ETSI. Whether the similarity is desirable, and if this notation will be accepted by SG17 is still an open issue. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Language Co-ordination Project Objectives 05/05/2019 Language Co-ordination Project Objectives Improve engineering process framework integrated set of languages Easy integration from requirements to decommission all languages (whether SG17 or not) Better Recommendations more easily implemented products improved conformance The Language Co-ordination project has the following objectives: To improve the engineering process of products by providing a framework and a set of languages that are smoothly integrated; To allow easy integration with relevant languages developed and maintained outside ITU; To improve Recommendations in the sense that they can be more easily implemented as products and that products can be more rigorously tested for conformance. There is a need to present the ITU-T languages in a framework that is co-ordinated to enable users to understand where the languages can be used; standardisation bodies to co-ordinate and set priorities; everyone to ascertain what is covered or not covered by the ITU-T languages. Therefore, there is a need to present all the languages/notations in a common framework as a co-ordinated language family; adopt a common approach to presentation of the languages; co-ordinate methods for use of the languages; adopt a common approach to promotion. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Issues for the Language Co–ordination? 05/05/2019 Issues for the Language Co–ordination? Who are the language users? Collective name for ITU-T languages? How much UML to Recommend? What activities should be covered? Consistency versus custom syntax? Legacy models and tool support? Reuse & libraries, or features? Currently most users have been protocol and services designers, but the market is real time systems which includes automotive, aeronautics and medical applications. It would be easier to address the users in all markets if a collective name could be used for the family of languages. One possibility would be to consider the languages as an ITU flavour of UML, especially as with SDL-2000, MSC-2000 and UML V2 there is already much commonality between the languages. This is no accident as the languages have some common origins in CCITT. More recently SDL-2000 uses UML class and association notation and MSC-2000 adopted some UML ideas. UML v2 is heading for further convergence. The languages are used for both specifications in standards and for implementation, but the requirements are not completely the same. The languages were first developed for standards, but these days most users are product implementers. The scope of application needs to be considered: for example requirements capture, product and network testing, and deployment . There has been a trend to remove notation inconsistencies between different languages. There could be confusion if what looks the same, has different meanings, and different presentation may suit different views. Moreover existing models have to be considered, though tools could overcome this issue. The final issue is offering more application specific features. This can be done by making common libraries available, or by building features into the languages. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Issues for the Language Co–ordination? 05/05/2019 Issues for the Language Co–ordination? Collective name for ITU-T languages Unified Family of Languages (ULF)? The ITU-T Language Environment (TILE)? How much UML to Recommend? Framework? Consistency versus custom syntax? Legacy models and tool support? Currently most users have been protocol and services designers, but the market is real time systems which includes automotive, aeronautics and medical applications. It would be easier to address the users in all markets if a collective name could be used for the family of languages. One possibility would be to consider the languages as an ITU flavour of UML, especially as with SDL-2000, MSC-2000 and UML V2 there is already much commonality between the languages. This is no accident as the languages have some common origins in CCITT. More recently SDL-2000 uses UML class and association notation and MSC-2000 adopted some UML ideas. UML v2 is heading for further convergence. The languages are used for both specifications in standards and for implementation, but the requirements are not completely the same. The languages were first developed for standards, but these days most users are product implementers. The scope of application needs to be considered: for example requirements capture, product and network testing, and deployment . There has been a trend to remove notation inconsistencies between different languages. There could be confusion if what looks the same, has different meanings, and different presentation may suit different views. Moreover existing models have to be considered, though tools could overcome this issue. The final issue is offering more application specific features. This can be done by making common libraries available, or by building features into the languages. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019

Language Co-ordination 05/05/2019 Initial Studies Choose a name though promoted to LAB Common model for data starting with study of differences Identify key concepts such a message events Common meta-grammar needed “yesterday” for URN It was agreed at joint strategy meetings that results of project should: Limit any further divergence of the languages; Facilitate of the convergence of ITU-T languages by providing guidelines for future development and time-scales for convergence; Define the joint use of specific languages in selected Recommendations; For key concepts crucial for the real-time and telecommunications area (such as signal consumption, time) identify mapping between languages at the semantic level that concentrate on the most important issues, and enabling key terminology to harmonised to avoid confusion; Take into account legacy and backwards compatibility, though tools could be used to overcome some difficulties and objections in this area; Consider guidelines on the relationship between the tools that show proof of concept and consent of Recommendations for new languages or new language features. The proposed new question addresses some of these points. Two other studies are: A feasibility study on defining a common mathematical data model for the data languages of ASN.1, SDL and TTCN. If it is decided that this can be done cost effectively, then further work would be done (in the project or as a Question study) to define the model. Such a model would allow unified data notation that can be used with all three languages, but the LAB and SG would have to decide whether defining yet another data notation might not create more divergence than convergence. Work to identify the key concepts and related behaviour semantics indicated above, to determine whether mappings between the languages is realistic. The plan for the November 2002 meeting is therefore to try to get commitment of effort towards this work, and produce reports to the next SG meeting. The two items should be done BEFORE work on defining the framework or environment. Language Co-ordination - ETSI MTS 34 Rome 11 April 2002 05.05.2019