uml-based test speciﬁcation for communication systems

UML-based Test Specification forCommunication Systems

- A Methodology for the use of MSC and IDL in Testing -

Dissertation

zur Erlangung des Doktorgrades

der Mathematisch-Naturwissenschaftlichen Fakultäten

der Georg-August-Universität zu Göttingen

vorgelegt von

Michael Ebner

aus Titisee-Neustadt

Göttingen 2004

Diese Dissertation ist elektronisch veröffentlicht und unterhttp://webdoc.sub.gwdg.de/diss/2004/ebner/ebner.pdf archiviert.

This dissertation is published electronically and available viahttp://webdoc.sub.gwdg.de/diss/2004/ebner/ebner.pdf.

D7

Referent: Prof. Dr. Dieter Hogrefe

Korreferent: Prof. Dr. Jens Grabowski

Tag der mündlichen Prüfung: 29. März 2004

ii

http://webdoc.sub.gwdg.de/diss/2004/ebner/ebner.pdf

http://webdoc.sub.gwdg.de/diss/2004/ebner/ebner.pdf

Abstract

Nowadays, the complexity of modern telecommunication systems has in-creased significantly and the requirement for thorough and systematictesting is undisputed. The Testing and Test Control Notation (version3) (TTCN-3) is an universal and standardised language for the specifica-tion and implementation of tests for communication systems. Many sys-tems and in particular object-oriented systems are described using the Uni-fied Modeling Language (UML). Therefore, UML models are an import-ant source for test development and in particular for manual test purposespecification and automatic test generation. Thus, usage of UML from atest perspective is considered.

UML models provide interface information by class diagramms and de-scription of scenarios by sequence diagrams respectively Message SequenceCharts (MSCs). Most UML tools permit conversion of class diagrams intoInterface Definition Language (IDL) which widens applicability. The com-bination of TTCN-3 and UML by MSC and IDL is a new approach. Thus,new mappings for MSC and IDL to TTCN-3 have been worked out. Ad-ditionally, to widen usability and applicability, the deficiency of object-orientation in TTCN-3 is inspected and a proposal for an object-orientedrevision is given.

iii

Zusammenfassung

Die Komplexität moderner, verteilter Kommunikationssysteme hat sich er-heblich gesteigert und die Notwendigkeit gründlichen und systematischenTestens ist unbestritten. Die Testing and Test Control Notation (version3) (TTCN-3) ist eine universelle und standardisierte Sprache zur Spezifi-kation und Implementierung von Tests für verteilte Systeme. Viele Systeme,insbesondere objekt-orientierte Systeme, werden heutzutage mittels derUnified Modeling Language (UML) beschrieben und deshalb sind UML-Modelle eine wichtige Quelle für die Testentwicklung und insbesonderefür die manuelle Testzweckspezifikation und die automatische Testgene-rierung. Folglich wird die Verwendung von UML aus der Testperspektiveheraus betrachtet.

UML-Modelle bieten Informationen über Schnittstellen durch Klassen-diagramme und Szenarienbeschreibungen durch Sequenzdiagramme be-ziehungsweise Message Sequence Charts (MSCs) an. Die meisten UML-Werkzeuge erlauben die Konvertierung der Klassendiagramme in die In-terface Definition Language (IDL), wodurch die Anwendbarkeit erweitertwird. Die Kombination von TTCN-3 und UML durch MSC und IDL istein neuer Ansatz. Deshalb wurden Abbildungen von MSC und IDL nachTTCN-3 ausgearbeitet. Um eine verbesserte Bedienbarkeit und Anwend-barkeit zu erreichen, wird zusätzlich die Verwendung von Objektorientie-rung in TTCN-3 untersucht und ein Vorschlag für eine objektorientierteÜberarbeitung gegeben.

v

Acknowledgements

Firstly, I like to thank my supervisor Prof. Dr. Hogrefe for his kind supportand the possibility to research under excellent conditions. The work at theInstitute for Telematics in Lübeck and Telematics Group in Göttingen hasbeen a very positive experience.

I would also like to thank my former colleagues in Lübeck and mycurrent colleagues in Göttingen who have accompanied me through theyears. It was always a pleasure to work with them. Special thanks go toProf. Dr. Jens Grabowski, Helmut Neukirchen, and Dr. Michael Schmittwith whom I shared a lot of discussions and debates. It has been a verynice and interesting time.

This thesis would not be in its current shape without the comments ofnumerous people. Thus, I truly appreciate the efforts of Zhen Ru Dai,Helmut Neukirchen, Dr. Michael Schmitt, Rene Soltwisch, and EdithWerner.

I am also grateful to Prof. Dr. Jochen Seitz who has encouraged me toprepare a doctoral thesis. In addition, I like to thank Carmen and Barbarafor their continuous motivation to finish this thesis.

Finally, I have to thank my parents for providing so much support formy unusual career path throughout the years.

vii

Contents

1. Introduction 1

2. Fundamentals of Testing 52.1. Dynamic Testing Concepts . . . . . . . . . . . . . . . . . . 52.2. Problems of Object-Orientation for Testing . . . . . . . . . 102.3. Test Generation . . . . . . . . . . . . . . . . . . . . . . . . 142.4. Testing and Test Control Notation . . . . . . . . . . . . . 192.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3. UML-based Testing 393.1. Unified Modeling Language . . . . . . . . . . . . . . . . . 393.2. Suitability of UML for Testing . . . . . . . . . . . . . . . . 413.3. UML-based Test Specification . . . . . . . . . . . . . . . . 433.4. Message Sequence Chart . . . . . . . . . . . . . . . . . . . 453.5. Interface Definition Language . . . . . . . . . . . . . . . . 533.6. Summary and Outlook . . . . . . . . . . . . . . . . . . . . 58

4. Mapping of MSC to TTCN-3 614.1. Fundamental Concept . . . . . . . . . . . . . . . . . . . . 624.2. MSC Documents and Comments . . . . . . . . . . . . . . 644.3. Basic Message Sequence Charts . . . . . . . . . . . . . . . 654.4. Structural Concepts . . . . . . . . . . . . . . . . . . . . . . 694.5. High-Level Message Sequence Charts . . . . . . . . . . . . 754.6. Summary and Outlook . . . . . . . . . . . . . . . . . . . . 76

5. Mapping of IDL to TTCN-3 795.1. Fundamental Concept . . . . . . . . . . . . . . . . . . . . 795.2. Lexical Conventions and Preprocessing . . . . . . . . . . . 805.3. Structural Elements . . . . . . . . . . . . . . . . . . . . . . 825.4. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 855.5. Communication Declaration . . . . . . . . . . . . . . . . . 965.6. Names and Scoping . . . . . . . . . . . . . . . . . . . . . . 1025.7. Summary and Outlook . . . . . . . . . . . . . . . . . . . . 103

ix

Contents

6. Object-Oriented Enhancements for TTCN-3 1076.1. Object-Orientation in TTCN-3 . . . . . . . . . . . . . . . 1076.2. Object-Oriented Revision of TTCN-3 . . . . . . . . . . . . 1136.3. Summary and Outlook . . . . . . . . . . . . . . . . . . . . 116

7. Conclusion 119

A. IDL Mapping Summary 121A.1. Conceptual IDL to TTCN-3 Mapping . . . . . . . . . . . . 121A.2. Comparison of IDL, ASN.1, TTCN-2, and TTCN-3 Data

Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122A.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

B. The TTCN-3 Inres Protocol Module 133

Acronyms 139

Bibliography 141

List of Figures 151

List of Tables 153

x

1. Introduction

The complexity of modern telecommunication systems has increased sig-nificantly and the necessity for thorough and systematic testing is undis-puted. For instance, conformance and functional testing is widely used inthe telecommunication area. However, testing is an expensive and time-consuming task. Before concrete tests can be carried out on a system,much effort has to be spent on specifying what and how to test and on ob-taining the test descriptions in a format that is accepted by the test equip-ment.

Testing of distributed systems based on Internet technologies has notmatured that much. However, testing becomes more and more importantif we consider the increasing amount of provided services and transfereddata with Internet-based technologies. Furthermore, traditional telecom-munication systems develop to Internet-based services to provide morepowerful systems and to create new services. Testing of these new Internet-based applications is as crucial for their success as in the telecommunica-tion area.

Testing has to be integrated into the development process. Therefore,to reduce testing effort tests should be generated from system specificationwhich is named Computer Aided Test Generation (CATG). Manual testgeneration is error-prone wherefore test generation must be automated tobe effective and repeatable. However, test generation based on state spaceexploration is helpful but generates frequently inefficient tests, lacks tocover specific parts, or may not be possible because of an incomplete ormissing specification. Thus, scenario-based, manual test specification isinteresting where the test designer can focus on specific elements in theSystem Under Test (SUT) and requires no test specific knowledge like theused test language.

In the telecommunication area, the Tree and Tabular Combined Nota-tion (TTCN) is used as a standardised test description language. Tree andTabular Combined Notation (version 2) (TTCN-2) (ISO/IEC 1998b) hasbeen applied successfully to functional testing of communication proto-cols for years. Testing and Test Control Notation (version 3) (TTCN-3)has been especially designed to test CORBA-based systems to satisfy thedemand for testing Internet-based distributed systems (ETSI 2002a). Com-

1

1. Introduction

UML

Interfaces (IDL) Scenarios (MSC)

Tests (TTCN-3) Object-Orientation

use

map

use

map

enhance

Figure 1.1.: Fundamental concept of the thesis

mon Object Request Broker Architecture (CORBA) is a standard architec-ture for distributed object systems and standardised by the Object Man-agement Group (OMG) (OMG 2001b). Many systems and in particularobject-oriented systems can be described using the Unified Modeling Lan-guage (UML) which is also defined by the OMG (OMG 2003c). Thus,UML models are an important source for test development and using UMLfrom a test perspective has to be considered. Additionally, there is ongoingwork on an UML Testing Profile (UTP) which can be mapped to TTCN-3.

Scope

UML provides sequence diagrams which are very similar to Message Se-quence Charts (MSCs). Thus, they are used to specify test scenarios.Most UML tools permit generation of Interface Definition Language (IDL)wherefore it is used to provide interface information (see Figure 1.1). Inaddition, it widens application because IDL is very common. For in-stance, CORBA systems are using IDL to describe their object interfacesand there exist mappings to different languages like Abstract Syntax Nota-tion One (ASN.1) and Web Services Description Language (WSDL). Us-ing TTCN as test description language is quite natural because of its suc-cessful application in the telecommunication area by using automatic testgeneration, and the possible usage of TTCN-3 with UML via the UMLTesting Profile (UTP). In addition, it was successfully applied for testingCORBA-based systems. The combination of TTCN-3, UML sequence dia-grams substituted by MSCs, and IDL to provide scenario-based, manualtest specification is a new approach. Thus, new mappings for IDL andMSC to TTCN-3 have to be worked out which can be seen in chapter 4and chapter 5 (see Figure 1.1).

2

To widen usability and applicability of TTCN-3, the object-orientedconcepts in TTCN-3 are inspected and a proposal for an object-orientedrevision is made (see Figure 1.1).

Outline

The remainder of this thesis is structured as follows. Chapter 2 intro-duces some fundamentals on testing with focus on object-orientation andtest generation and then introduces the test description language TTCN-3.Chapter 3 discusses the usage of UML for testing of systems and explainsthe concept of scenario-based testing with UML. Furthermore, it intro-duces MSC and IDL. Chapter 4 deals with a mapping of MSCs to TTCN-3to allow test generation based on scenarios defined in UML. In chapter 5,a mapping of IDL to TTCN-3 is detailed to use interface information fortest generation. The deficiency of object-orientation in TTCN-3 and anobject-oriented revision are discussed in chapter 6. Finally, conclusionsare given.

3

2. Fundamentals of Testing

Testing is an important part of the analytical quality control of inform-ation technology systems and hence, is part of each software/hardwareengineering process to assure functionality and reliability (Balzert 1998;Kaner et al. 1999). Test methods aim at detecting faults whereas verifica-tion methods try to show the formal correctness against the specification,and validation methods try to confirm the suitability of systems or systemcomponents for the application purpose.

There are static and dynamic test methods. Static methods like inspec-tion, review, and walkthrough analyse the source code while dynamicmethods execute the system and provide concrete input data (Myers 2001).Static testing methods are especially useful in early stages of programmingand for finding structural problems.

Dynamic testing allows testing in the environment1 of the system butcannot prove the absence of faults because the selected test input datadoes not cover all cases. Testing all cases would be the same like formalverification which mostly is too difficult for modern systems. However,when it comes to the later development stages, in which systems get largerand more complex, dynamic testing is a way to get a better coverage of thesystem as it can be done with static testing. Hence, a better confidence inthe system is possible. In this thesis, only dynamic testing for distributed,object-oriented systems is considered.

The testing area is divided into many fields wherefore some classific-ations are given first. Afterwards, some remarks on problems in testingobject-oriented systems and test generation are given. Furthermore, thetest description language TTCN-3 gets explained. Finally, the chapter issummarised.

2.1. Dynamic Testing Concepts

The dynamic testing area is divided into many fields with different meth-ods, procedures, and objectives depending on the application area. Somecharacteristics to classify dynamic testing are

1It is quite common to simulate the environment.

5


• the implementation type (target platform),

• the place in the development cycle,

• the knowledge about the underlying system,

• the test objective,

• the test data selection, and

• the test result authority.

Below, these characteristics are explained in more detail (Balzert 1998;Kaner et al. 1999; Myers 2001).

Type of Implementation

Testing depends on the target platform which can be hardware, software,or both. Hardware testing is done on the physical level with signal inputand output. This concerns physical elements such as transistors, gates,and circuits, or functional elements like busses. Software testing is doneon the logical layer where the hardware is assumed to be correct. In thefollowing, we only consider software testing.

Development Cycle

Faults can occur in each phase of the software development cycle. There-fore, the phase influences the kind of test such as module test, integrationtest, system test, or approval test as shown in Figure 2.1. Thus, the testerconsiders which piece of software to test which can be just a single func-tion (method), a complete class, a collection of functions or classes (lib-rary), or a whole application with its internal and graphical interfaces. Forinstance, integration testing checks the communication between differentmodules to ensure that they interwork correctly.

System Knowledge

The amount of knowledge about the underlying system determines whichkind of test and test architecture can be used. There are three distinguish-able testing types:

6


Requirementdefinition

Approval test

Rough design System test

Fine design Integrationtest

Module im-plementation

Module test

Figure 2.1.: The V process model for software development (Balzert 1998, page 101)

Black-box testing is applied to systems about which no internal know-ledge is available. Only the interfaces to the environment are access-ible. In addition, the specification is available from which tests canbe generated. Hence, test data can be given as input and the outputdata can be evaluated against the specification. Black-box testing ismainly done in the later development stages.

Grey-box testing is used if some internal knowledge is available. Theknowledge is used to improve code coverage for black-box testing.

White-box testing, also called glass-box or structural testing, is used iffull knowledge about the implementation is available. For instance,the source code is available. Hence, the information can be usedto center testing, to control code coverage, to check value boundar-ies, and to do algorithmic specific testing. Furthermore, knowledgeabout control flow and data integrity can be used to design tests.White-box testing is mainly done in the implementation phase.

Test Objectives

The application area influences the requirements which have to be fulfilled.Thus, there are also different kinds of tests.

Functional testing is used to check the behaviour with regard to the func-tional requirements. Test data are sent to the system and the receivedoutput is checked against the specification. The term functional test-ing is sometimes used as synonym for black-box testing.

7


Performance testing is used to check non-functional requirements like re-sponse time or memory usage in normal or overload situations.There are three special cases:

Real-time testing checks some real-time requirements. They can bedivided into hard and soft requirements. Hard requirementsconcern definite time boundaries which have to be fulfilled.Soft requirements describe time boundaries or some varianceswhich may be violated within a definite range.

Load testing checks the behaviour when heavy load is generated.For instance, the response time is checked.

Stress testing checks the behaviour under unusual conditions by, forinstance, sending inopportune or malformed data.

Portability testing is used to check the portability to other environmentslike other hardware or software platforms. For example, operationsystem derivates have to be checked against the different environ-ments.

Penetration testing is used to check the vulnerability of a system likewhether it is possible to get unauthorised rights, wrong configura-tions can lead to successful attacks, or are there any known bugs inused software.

Usability testing checks (graphical) user interfaces with regard to criteriasuch as adequacy, simplicity, clarity, and consistency. Typically, us-ability tests are performed by recording and evaluating the beha-viour of an external test person interacting with the system (gestures,response times, eye movement, etc.).

Test Data Selection

Testing is always concerned with feeding a system with input and evaluat-ing the output. Hence, the method to choose the test data is important.

Exhaustive testing means to enter all possible data on each possible inputrequest. This would be a complete test regarding the claimed in-put but it is only applicable for small amounts of input requests orpossible test data because of the increasing complexity for a biggeramount.

8


Partition testing segments the input domains into sub-domains withoutoverlapping. For instance, boundary testing to check boundariesand extreme values.

Random testing refers to the random choice of test data from the wholeset of data.

Mutation testing is based on the approach that many different system ver-sions, called mutations, are generated. Each mutation is the resultof a small modification like removing or modifying statements. Testdata have to be selected in such a way that all modifications are de-tected. Hence, the probability could increase to get good test datafor the original system.

Authority for Test Results

Another criterion for classifying tests is the authority which is used asreference to decide whether a system passes a test successfully.

Conformance testing checks the underlying system against its specifica-tion. This implies black-box testing.

Interoperability testing or compatibility testing checks the interworkingof different implementations of the same specification. For instance,protocol implementations from different companies. Conformanceto the specification does not ensure interoperability because the spe-cification can be, for instance, incomplete and hence interpretable.Likewise, interoperability does not ensure conformance to the spe-cification, because both implementations could misinterpret the spe-cification in the same way.

There are two kinds of tests, namely active and passive interworkingtests. Passive tests check only valid behaviour whereas active testsallow to introduce errors, wrong behaviour, wrong data, etc.

Regression testing is used if a part of a system has been modified and thebehaviour of the whole system has to be tested. To detect side effectsof the modifications, only outputs have to be considered which differin comparison to output from the old system.

Comparison testing compares the output of different systems which arebased on the same specification. The aim is to find output differ-ences.

9


2.2. Problems of Object-Orientation for Testing

The main idea of object-orientation is to bind data and belonging methodstogether and encapsulate them in classes. Additionally, to provide moreexpressive mechanisms like inheritance and polymorphism to enhance re-usability. It was believed that the new paradigm also leads to less faultysystems and is easier for system testing because of more compact code.However, object-oriented software is still produced in the same imperfectway as before. For instance, with the same humans and similar developingmethods. Despite of the expectations the object-oriented paradigm has itsown kinds of pitfalls because of powerful concepts like inheritance, poly-morphism, late binding, and encapsulation. Consequently, the advantagesof object-orientation with regard to development are disadvantages fortesting. Therefore, testing object-oriented systems is still necessary and ef-fective testing requires special attention to object-oriented pitfalls (Binder2000; Kung et al. 1998; McGregor & Sykes 2001).

The test model and consequently the test strategy depends on the testaim (ISO/IEC 1994). For instance, a system crash must not be a reasonto fail a functional test but it would be a reason for a fault directed test.Nevertheless, knowledge about object-oriented faults is useful for bothcases. The paradigms like encapsulation, object composition, and com-plex runtime behaviour by polymorphism are an obstacle for testing. Testcase design and coverage analysis are difficult wherefore automatic gen-eration tools have to provide special support for object-orientation. In-teraction is described by a complex set of message sequences and states.Polymorphism and dynamic binding increase number of execution paths.Furthermore, objects and consequently object states are distributed overthe whole system which makes state control difficult. Inheritance has theeffect that correctness of a superclass does not lead to correctness of a sub-class of it. Additionally, reusability of a class requires careful testing andretesting in each new context. Interfaces are used quite a lot wherewithmore interface faults occur.

An error and a failure list and a method scope fault taxonomy is givenin Binder (2000, section 4.2.7). Some language-specific hazards for C++,Smalltalk, and Java are also given in Binder (2000, section 4.3). Somedetails of the above mentioned problems are detailed now.

10


Encapsulation

Information hiding and modularity are achieved by encapsulation of dataand methods in classes where access is controlled. Therefore, dependenciesand global access are prevented by hiding implementation. Encapsulationis not directly related to faults but it is a obstacle for testing because ab-stract and concrete states have to be influenced by testing. However, directaccess to states by, for instance, get and set methods is often not possible.

Inheritance

An essential aim of object-orientation is to support reusability by usingelements of a common entity. For instance, types and subtypes with ex-tensibility can be defined. If inheritance can be mirrored in the test suite,the test effort for a subclass can be reduced. Inheritance can be a verypowerful means but some weaknesses and misuses can lead to a lot oftrouble:

• deep (hierarchy of subclasses) and wide (usage in many classes) in-heritance,

• inheritance weakens encapsulation because subclasses can get directaccess to superclass elements (hence, contract of superclass could beviolated by subclass),

• participation in implicit control mechanism for dynamic binding be-cause of unanticipated bindings or misinterpretation of correct us-age,

• abuse by using as macro expansion mechanism, and

• as a model of hierarchy where no sharing or using is done.

Thus, faults by side effects, inconsistencies, and incorrect behaviour haveto be considered.

Incorrect initialisation of objects by missing initialisation in the super-class, modified super initialisation, or forgotten overwrite of methods likecopy and isequal lead to faults. Especially in retesting modified methods/al-gorithms, the dependencies between classes have to be considered. Mix-ing problem domain relationships and shared implementation features areproblematic. For instance, class/subclass and type/subtype relationshipsrequire careful handling. A subtype has a specification relationship and asubclass has an implementation relationship. Subclasses have to be tested

11


against their specifications and against the specification of the superclass.Reuse is difficult if it was not intended initially because of assumptions oroptimisations specific to the original application. Identically named meth-ods from different classes can produce faults because of incorrect dynamicbinding or when used from another class. Scoping rules influence bindingwherefore usage in subclasses may fail.

Abstract and generic classes require the creation of a concrete class toget tested. For generic classes, the interaction between class and used typehas to be tested. However, an exhaustive testing of all types for a genericclass is not feasible and would be equal with formal verification.

Polymorphism

Binding a reference to more than one possible object or method allows forcompact, elegant, and extensible code and is called polymorphism. Bind-ing and type checking at compile time is called static polymorphism. Atruntime, it is called dynamic polymorphism respectively dynamic binding.

Semantics, syntax, and binding search mechanisms to select a methodat runtime differ between programming languages. Polymorphism makescode difficult to understand and error-prone because behaviour is not pre-dictable by a static analysis and the code is hard to read. Thus, wrongmethod binding has to be excluded by testing. Many variables, whichinfluence polymorphic methods, are not visible in source so that it is dif-ficult to understand all possible interactions with all bindings. Depend-encies among polymorphic methods are stronger than for normal meth-ods because of their wider application. Therefore, method specificationmodifications have more influence and unmodified classes lead to faults.Method redeclaration in subclasses is dangerous especially in the contextof polymorphism.

Consequently, usage of polymorphism can be fault-prone. Commonmistakes are ignoring responsibility, independent revision of its definitionand usage, contract inconsistency, not provided method, method misuse,or incorrect interface signature.

Interaction

Classes are collections of methods and states and they interact by call-ing methods where interpretation depends on the current state. However,which are correct sequences of method calls? A corrupt state can be oc-cur by faulty method interworking or method implementation. Method

12


interworking may be faulty by overlapping responsibilities or if there is aconcrete sequence pattern to produce a corrupt state. For instance, over-lapping responsibility is given if an internal variable is modified by severalmethods without considering the implications. Method implementationmay be faulty by using a corrupt algorithm or giving an incorrect output.Furthermore, a method implementation can be overridden, for instance,by bad inheritance, or a wrong contract is implemented.

In case where sequences lead to the same result, an equivalent sequenceset is found. If different instances do not produce the same result, a fault isfound. State rules of objects have to be considered and thus, illegal methodcalls in definite states are forbidden. This is necessary to prevent wastingcomputation time and to provide a stable system. However, a defensivesystem design should consider wrong method calls and forbidden methodcalls have to be tested. Methods have to be tested in cooperation becausetesting a method alone is not enough. A fault could occur later duringusing another message.

Services

There are services provided by the programming language and used com-piler respectively which have also to be considered for testing. Defaultservices like providing default constructor, deconstructor, or copy con-structor are supported. Runtime conversion services for classes, whichare similar to type conversion, are used to convert superclass objects tosubclass objects and vice versa. Garbage collection services could causeproblems under high loads. Providing an object identity during run-timeto distinguish types, subtypes, and objects is only done for subclasses bythe programmer itself (via copy and isequal methods).

Summary

To sum up, static testing is less effective for object-oriented systems be-cause of dynamic effects like late binding and coding complexity like in-heritance and polymorphism. An effective test process for object-orientedsystems has to consider these problems (Binder 2000; Kung et al. 1998;McGregor & Sykes 2001) and thus,

• design for testability in all phases is important,

• testing must adapt to iterative and incremental development,

13


• test design has to consider methods, classes, and clusters at the sametime because testing a cluster of classes and not a class alone is ne-cessary to consider the environment of a class,

• test suite structure should correspond to SUT structure which en-hances readability, maintenance, and automatic generation.

Thus, black-box testing like component testing is not enough becausespecific bugs of object-oriented systems are missed and methods using codecoverage analysis have to consider object-orientation, too.

2.3. Test Generation

As discussed before, testing has to be integrated into the development pro-cess. Therefore, to reduce testing effort tests (test purposes and test cases)should be generated from system specification which is named CATG.

Manual test generation is error-prone wherefore test generation mustbe automated to be effective and repeatable. Efficiency allows a quick val-idation which speeds up debugging. Repeatability, through usage of testcases once more, enables more often testing wherefore minor system modi-fications can be validated immediately. Furthermore, automation leads toconsistent test results which eases test result analysis. The uniform testprocess is independent of the responsible person for testing. Using auto-mation enables better productivity because test staff can concentrate ontest design and not test execution and test suite maintenance. The selec-tion of test method and tools for automation depends on test experience,test goals, budget, used software process, kind of application under devel-opment, particulars of the development and target environment, etc.

Automated testing can permit test execution of long and complex tests,automate comparison for many test outputs to evaluate test results, andautomatic adaptation to different versions of the SUT. For instance, re-gression testing benefits a lot from automation. Automatic testing involvesrunning test suites without manual intervention and generation of test in-puts and expected results.

However, manual test generation is also useful if, for instance, manyuser interaction is necessary, no repeat is necessary, automatic generationis too expensive, or full automatic generation is not possible or not effect-ive. Skilled testers with good knowledge of SUT can develop good butlimited test cases where focus is mostly on specific scenarios. Thereby,combining manual and automated testing is quite common. Thus, it is an

14


advantage if manual tests are written in the same language or languages asthe system specification. It provides seamless integration between manualand automatic test generation and improves maintenance and readability.

In the section remainder some remarks to the tools Autolink and Test-Composer are given which provide manual and automatic test generationfacilities (Schmitt et al. 2000). Firstly, an introduction is given. Secondly,an overview about the test generation process is given. Lastly, scenario-based testing by direct translation of MSCs is described. Test purposebased testing and test case generation with Autolink are described inKoch (2001) and automatic test generation using state space explora-tion with Autolink based on formal specifications is described in Schmitt(2003).

Autolink and TestComposer

In many cases, a formal specification of the SUT is given in the Specific-ation and Description Language (SDL) (Ellsberger et al. 1997; ITU-T1999). SDL not only allows to describe the structure and behaviour ofa communicating system in a semi-graphical way; there also exist toolsfor dynamic analysis of SDL specifications by means of simulation andvalidation. Hence, a reasonable approach is to generate test cases auto-matically based on a given SDL specification. In addition to an increasedefficiency in terms of both time and cost, automatic test generation ensuresconsistency between the formal specification and the test cases applied toan implementation.

For that reason, the two major SDL tool vendors Telelogic and formerVerilog have integrated automatic test generation tools into their soft-ware development environments.2 Telelogic complemented its TAU toolsuite with Autolink in 1997. Autolink has been developed at the In-stitute for Telematics, Medical University of Lübeck (Koch 2001; Schmitt2003) and is based on the former work of the SaMsTaG project (Grabow-ski et al. 1997). In 1998, Verilog extended ObjectGeode with Test-Composer. Similar to Autolink, it has its root in the research area as itis based on TGV and TVEDA which were developed at IRISA/Verimagand France Telecom/CNET (Kerbrat et al. 1999).

Both tools share the same basic concepts. For example, they apply statespace exploration techniques to search for suitable test sequences. In addi-tion, they support the second edition of the standardised TTCN (ISO/IEC

2In December 1999, the two companies have merged.

15


1998b) as a common output language. Nevertheless, many concepts arerealised differently in TestComposer and Autolink. Moreover, the twotools put their focus onto different steps of the test generation process.The strengths of TestComposer are in the flexible specification of testpurposes whereas Autolink has its strong points when it comes to thecustomisation of the generated TTCN test suites.

TestComposer and Autolink have been described separately in detailin former publications (Grabowski et al. 1999; Kerbrat et al. 1999; Kochet al. 1998). A short introduction to the overall process of test generationis given in order to make the reader familiar with the general approach.

Overview

Autolink and TestComposer are tightly integrated into their corres-ponding development environments. TestComposer is built on top ofthe ObjectGeode Simulator; Autolink is part of the TAU Validator. Inthis way, the tools can make use of the functionalities of their underly-ing applications. The Simulator as well as the Validator are used to finddynamic errors and inconsistencies in SDL specifications. They provideroughly the same basic features with state space exploration as their fun-damental concept.

Test generation with TestComposer and Autolink follows a three-stage process. An overview is given in Figure 2.2. In the diagram, actionsare represented by rounded boxes. Data structures and files are depicted inrectangles. Finally, configuration scripts that influence the test generationare indicated by hexagons.

In a first step, the user has to specify a set of test purposes. Each test pur-pose defines a specific aspect of the behaviour of the implementation thatis intended to be tested. With regard to TestComposer and Autolink, atest purpose is considered to be a sequence of input and output events thatare to be exchanged between the given SDL system and its environment.Test purposes are developed either manually by using, e.g., an MSC editor,interactively by stepwise simulation of the SDL system, or fully automat-ically.

There are different representations for test purposes: Autolink usesMessage Sequence Chart-1996 (MSC-96) (ITU-T 1996) as an uniformformat. TestComposer uses MSC-96 as well but also creates scripts in aproprietary format that can be handled by ObjectGeode more efficientlythan MSCs. Both tools support observer processes which are similar to

16


Test environment

Automaticcomputation

Interactivesimulation

Manualspecification

Script files MSCs Observerprocesses

State spaceexploration

Directtranslation

Test cases Constraints Constraintmodification

Application Programming Interface/Production modules Test architecture

User definedoutput format

TTCN test suite Test suitestructure

Figure 2.2.: Test generation with TestComposer and Autolink

regular SDL processes. They run in parallel with the actual SDL systemand allow to inspect and control its simulation.

Based on a set of test purposes, test case generation takes place. Nor-mally, a generation engine computes a test case based on state space ex-ploration of the SDL system. By this, it can determine additional valid in-teractions between the tester and the SUT which are not already specifiedin the test purpose description. However, sometimes it is not possible tosimulate a test purpose. For these cases, Autolink provides a way totranslate test purposes directly into test cases.

All test case descriptions along with their constraints, i.e. the definitionsof the data values exchanged between the tester and the SUT, are storedin an internal data structure. Autolink allows to save and reload gen-erated test cases to disk such that the user can suspend and continue thegeneration of a full test suite.

In a final step, Autolink produces a test suite in TTCN-2 format.TestComposer provides an Application Programming Interface (API)(which is public) that allows customers to adapt the tool to any arbitrarytest specification language. In addition to the internal test case repres-

17


entations, the API provides access to general information about timers,signal types, etc. and Point of Control and Observation (PCO). Test-Composer already includes a module that produces test suites for secondedition TTCN. In the following, only TTCN will be considered for outputas many features of the tools are related closely to this notation.

Test generation with Autolink and TestComposer is influenced bya number of configuration settings. For example, when generating testpurposes (semi-) automatically, the developer has to provide the simulatorwith information on the test environment of the system, i.e. reasonableinput values. The look of the test suite can also be controlled by variousoptions. In Autolink, constraints can be named and parameterised byuser-defined rules. In addition, test cases can be combined in a hierarchyof test groups to express their relationships. Last but not least, the testarchitecture has a great impact on the final test descriptions. A test casethat is executed on a monolithic tester will look differently from a test casethat is designed for a distributed test system.

Scenario-based Testing

If a test purpose defined as MSC covers certain aspects of a protocol spe-cification which are not represented in the corresponding SDL model or ifa SDL model is missing completely, it is obviously not possible to generatea test case by state space exploration. To handle these cases, Autolinkprovides direct translation of MSCs into TTCN test cases with consistencychecks regarding the SDL system interface definitions. Hence, an SDL sys-tem has to be provided which at least defines the channels to the systemenvironment in order to identify the PCO and the signals sent via thesechannels.

Direct translation of MSCs into TTCN test cases has to be applied withcaution. There is no guarantee that the MSCs and hence the test casesdescribe valid traces of the specification or the implementation, respect-ively. Instead, Autolink relies on the developer that the test cases arevalid. Furthermore, it is not possible to compute test events which leadto an inconclusive test result, meaning any deviation from the behaviourdescribed in the MSC is considered to be false.

On the other hand, there are good reasons to specify MSC test pur-poses instead of directly writing TTCN test cases. Firstly, test cases typ-ically span trees with several tree leaves because of the partial order oftest events. In MSCs, the partial order is expressed inherently due to thesemantics of MSC. While it is arduous for a test suite developer to write

18

2.4. Testing and Test Control Notation

down a complete TTCN test case, Autolink automatically computes allvalid permutations of test events for a given MSC.

Secondly, since Autolink always translates MSCs into an intermediateinternal test case representation, test cases generated by an MSC to TTCNtranslation can be merged with test cases generated by state space explora-tion. This leads to uniform and compact test suites with a reduced numberof constraints.


The Tree and Tabular Combined Notation (TTCN) is the third part ofthe Conformance Testing Methodology and Framework (CTMF) (ISO/IEC1994) standard for the specification of test suites for conformance testing.In May 2001, the new version of TTCN, called Testing and Test ControlNotation (version 3) (TTCN-3), was finally standardised (ETSI 2002a).The TTCN-3 (ETSI 2002a) is a universal and standardised language forthe specification and implementation of tests for distributed systems.

TTCN-3 is the target language for test generation within the scope ofthis thesis. TTCN is widely accepted in the area of testing telecommu-nication protocols. Contrary to existing programming or scripting lan-guages like C and the DejaGNU GNU Testing Framework (Savoye 2001)or test frameworks like XUnit, the TTCN-3 provides an appropriate levelof abstraction, high-level testing concepts, and control structures. Hence,writing abstract and implementation independent test suites gets possiblewhich widens the application area. It is also easier to read and write testsand to provide standardised test suites for standardised protocols. Further-more, test engineers have to learn only one test language and can mostlyuse the same testing tool set. TTCN-3 tools are offered, for instance, byTelelogic, Testing Technologies, and Da Vinci Communicationswhich support editing, compilation, debugging, and execution of TTCN-3modules.

Improvements

TTCN-3 is called the successor of TTCN-2 (ISO/IEC 1998b) but it was re-designed from scratch and uses another style. TTCN-3 improves conceptsof TTCN-2 and introduces new concepts to support a broad spectrum oftesting types, e.g., conformance and interoperability testing, and its com-munication mechanisms allow for testing various platforms such as theCORBA or Internet-based protocols. An important feature of TTCN-3

19


Other Types& Valuesn

IDL Types& Values

ASN.1 Types& Valuesn

TTCN-3

CoreLanguage

Presentationformatn

Graphicalformat

Tabularformat

TTCN-3

User

Figure 2.3.: User’s view of TTCN-3 core language, presentation formats, and imported types

is the enhanced communication concept which now supports procedure-based communication to provide synchronous communication, as well asthe asynchronous message-based communication. Additionally, a test ex-ecution control part, a module and grouping concept, and new data typesare introduced to provide better control and grouping mechanisms.

TTCN-2 was designed to test networks which are conform to the Inter-national Organisation for Standardisation (ISO) Open Systems Intercon-nection (OSI) reference model. The OSI terminology and concepts like Ab-stract Service Primitive (ASP) and Packet Data Unit (PDU) and conform-ance testing peculiarities have been removed as far as required to widenapplicability of TTCN-3. Additionally, constraint handling was replacedby templates which provide parameterisation and matching mechanisms.Use of data types defined via ASN.1 is also possible in TTCN-2. Ho-wever, TTCN-3 has integrated some ASN.1 data types into the languageitself and allows import of ASN.1 data types.

As the name TTCN states, a tabular form was used in TTCN-2. Ho-wever, TTCN-3 abandons the tabular form and uses instead a text-basedlanguage which is comparable to an implementation language like C. Thisnew core language is used as base for document interchange and also for atabular presentation format defined in ETSI (2001). A graphical presenta-tion format is also defined in ETSI (2002b) (see Figure 2.3) which is calledTTCN-3 Graphical Presentation Format (GFT).

The remaining part of this section shall describe some basic conceptsof TTCN-3 itself to set a base for the following chapters. This includesthe module and group concept, the data concept, communication, test

20


configuration, templates, and behaviour description. The Inres examplegets described first.

2.4.1. Inres Case Study

The concepts of TTCN-3 are illustrated by test suites for Inres, a serviceand protocol designed for educational purposes (Hogrefe 1989). It is alsoused in section 3.4 for the description of the formal specification languageMSC.

Inres – which stands for INitiator-RESponder – is a reliable, asymmetricand connection-oriented service on the OSI data link layer that ensures thesafe transmission of data over an unreliable medium. For that purpose, asequence number is transmitted along with each data. The responder pro-tocol entity must acknowledge each data packet by the correct sequencenumber.

The Inres service comprises the three phases connection establishment,data transfer, and connection release. The message exchange that takesplace when a service user A transmits one data packet to some serviceuser B is shown in the MSC in Figure 2.4.

The main features of TTCN-3 are illustrated by test suites for testing theconformance of Initiator protocol entity implementations. The local testmethod of the CTMF is chosen, i.e., both upper and lower tester resideinside the test system. The upper tester takes the role of Service UserA and exchanges Inres ASPs with the SUT via Inres service access pointISAP1. The lower tester simulates the behaviour of a Responder protocolentity and communicates with the SUT via service access point MSAP2of the Medium service provider. The conceptual architecture is shown inFigure 2.5.

In the following sections, only simplified extracts are presented. A com-plete test suite can be found in Appendix B (Schmitt 2003).

2.4.2. Structuring

Modules are the top-level structuring element in TTCN-3 and a TTCN-3document is composed of one or more modules. Each module representseither a complete executable test suite or a library. It consists of defini-tions and an optional control part that guides the execution of test cases.Modules support usage of parameters to permit the re-use of modules indifferent test environments. A module can import definitions from other

21


Service UserUser A

Protocol EntityInitiator

Service ProviderMedium

Protocol EntityResponder

Service UserUser B

disconnected

ICONreqMDATreq(CR)

MDATind(CR)ICONind

waiting ICONrespMDATreq(CC)

MDATind(CC)ICONconf

connected

IDATreq(data)MDATreq(DT,no,data)

MDATind(DT,no,data)IDATind(data)

sending MDATreq(AK,no)

MDATind(AK,no)

connected

IDISreqMDATreq(DR)

MDATind(DR)IDISindIDISind

disconnected

msc Inres

Figure 2.4.: The Inres service and protocol

modules but it cannot import their control parts. Unfortunately, modulescannot be nested.

Definitions in the definitions part include constants, data types, com-munication data such as messages, signatures, and templates, test config-uration elements like ports and components, and dynamic behaviour bydefinition of test cases, altsteps, and functions. The declaration of vari-ables in the definition part is not supported whereby no global variables,timers, etc. are available.

Definitions can be combined into groups, but a group does not definea new scope and has no semantics purpose except when definitions areimported by another module. Groups are used to structure test data in alogical manner and to enhance readability.

In the module control part test case execution and their execution orderis given why it can be seen as the main method respectively program ofthe module. Test case execution order can be controlled by dependenciesfrom results of other test cases or timers, for example.

In Listing 2.1, a TTCN-3 module for testing conformance of an InresInitiator protocol entity is presented. Its definition part starts with an

22


Test System System Under Test

UpperTesterMain Test Component

MainTC

TCPCP CoordinationPoint

LowerTesterParallel Test Component

ParallelTC

PCO MSAP2Medium-ASPs

(MDATreq, MDATind)

IUTInitiator

Inres-ASPs(ICONreq, ICONconf, etc.)

PCO ISAP1

Service-Provider Medium

Figure 2.5.: The local test method applied to Inres

import statement (line 2–5) to adopt data type UserPDU and constantsomeUserPDU from an external module called ServiceUser. All data typedefinitions that are required to describe an Inres PDU are combined ingroup BasicDefinitions (lines 7–17). Thereafter, global constant maxTest-CaseTime is declared in line 19. Module TestsForInres includes manymore definitions. For better readability and comprehension, these defini-tions are presented separately in Listings 2.2–2.8.

In the module control part (lines 23–29), test case SingleDataTransferis executed first. Depending on whether its execution has been successful(test verdict is pass) and module parameter testInopportuneEvents equalstrue, a second test case (DataLoss) is invoked.

2.4.3. Data Concepts

TTCN-3 provides its own data type model which was inspired by ASN.1and programming languages. The types are listed in Table 2.1. Most basictypes such as integer, char (see ISO/IEC 1990), universal char (see ISO/IEC1993), and boolean are well known from programming languages. Thebasic string types differ only in the used character set where charstringand universal charstring are based on the same character sets as char and

23


Listing 2.1: TTCN-3 Module TestsForInres

1 module TestsForInres( integer maxRepetitions, boolean testInopportuneEvents ) {2 import from ServiceUser language "ASN.1:1997" {3 type UserPDU;4 const someUserPDU;5 }6

7 group BasicDefinitions {8 type UserPDU InresSDU;9 type enumerated InresPDUType { CR(1), CC(2), DR(3), DT(4), AK(5) };

10 type enumerated SequenceNumber { zero(0), one(1) };11 type record InresPDU {12 InresPDUType iPDUType,13 SequenceNumber seqNo optional,14 InresSDU iSDU optional15 }16 type InresPDU MediumSDU;17 } with { encode "PER−BASIC−UNALIGNED:1997" } // apply Packed Encoding Rules18

19 const float maxTestCaseTime := 50;20

21 . . . further definitions . . .22

23 control {24 var verdicttype overallVerdict := pass;25 overallVerdict := execute( SingleDataTransfer (), maxTestCaseTime );26 if ( overallVerdict == pass and testInopportuneEvents == true ) {27 overallVerdict := execute( DataLoss() );28 }29 }30 } with { encode "BER:1997" } // apply Basic Encoding Rules by default

universal char. The TTCN-3 special basic type verdicttype is used to handletest verdicts where only the five distinguished values pass, fail, inconc, none,and error are available for it. Type objid is used as object identifier and isimported from ASN.1.

Available structured base types are enumerated, record, set, union, andarray. The type record is an ordered type whereas set is an unordered typewhich is important in case of data encoding. Apart from order, both areequal and provide optional fields. In case of using only a single type, thetypes record of and set of are available. They can be considered similar toan ordered and unordered array respectively.

In case of handling data of unknown type the data can be assignedto type anytype which is shorthand for the union of all known types ina TTCN-3 module. The anytype was especially introduced to provide abetter mapping of IDL (see chapter 5) which was proposed by the author.

TTCN-3 provides three special configuration types where type address

24


Table 2.1.: Overview of TTCN-3 types

Class of Type Type (Keyword)

Simple basic integer

char

universal char

float

boolean

objid

verdicttype

Basic string bitstring

hexstring

octetstring

charstring

universal charstring


Structured record

record of

set

set of

enumerated

union

Special data anytype

Special configuration address

port

component

Special default default

is used to address entities inside the SUT. Test configuration is organ-ised via type component, and type port is used to handle communicationbetween components which is described in more detail in subsection 2.4.5on page 31.

Lastly, the type default is mentioned which is used to handle defaultbehaviour defined by altsteps which is described in detail on page 35.

The test specifier may define own types by sub-typing of types. The setof valid values of basic and structured types can be restricted by usageof value ranges, lists of values, and length restrictions. The data modeldefines no dynamic types why no pointers are available. However, recurs-ive data structures can be used, instead.

A set of predefined functions is available to support data value con-version like integer to string, to get the number respectively length of re-cords, sets, and strings, to check the presence of optional fields, to checkthe chosen type in unions, to retrieve substrings, and to generate randomnumbers (ETSI 2002a, appendix C).

Attributes

TTCN-3 provides assigning of attributes to statements to provide, for in-stance, additional information for compilers or other tools like graphicaleditors or viewers. The provided attributes are display, encode, variant, andextension. Attribute display is used for presentation purposes and attrib-

25


Table 2.2.: Overview of TTCN-3 type variants respectively useful types

Base Type Variant Useful Type

integer 8 bit byte

unsigned 8 bit unsignedbyte

16 bit short

unsigned 16 bit unsignedshort

32 bit long

unsigned 32 bit unsignedlong

64 bit longlong

unsigned 64 bit unsignedlonglong

float IEEE754 float IEEE754float

IEEE754 double IEEE754double

IEEE754 extended float IEEE754extfloat

IEEE754 extended double IEEE754extdouble

universal UTF-8 utf8string

charstring UTF-16 utf16string

UCS-2 bmpstring

8 bit iso8859string

record IDL:fixed FORMAL/01-12-01 v.2.6 IDLfixed

ute extension is used for user-defined extensions. The encoding attributesencode and variant define encoding rules and encoding variants respect-ively.

Especially the encoding attributes are important for data types becauseencoding is important for data transmission and variants are important tospecify well defined sub-types. TTCN-3 itself specifies no such implement-ation specific information.

There is a set of predefined variant attributes available. The usage ofthese variants to define useful types is shown in ETSI (2002a, appendix E)and is listed in Table 2.2. They were proposed by the author to improvemapping of IDL (see chapter 5).

Type Import

Sometimes it is useful to import existing type and data definitions fromother sources like the SUT implementation or specification. Therefore,TTCN-3 provides the possibility of importing definitions defined in an-other language than TTCN-3. Until now, only import rules for ASN.1 aresupported (ETSI 2002a, appendix D). ASN.1 is heavily used in telecom-

26


munication applications it was also supported in TTCN-2. There existmany SDL specifications for telecommunication applications and there-fore, usage of SDL is also interesting. However, until now there are noimport rules defined.

Nevertheless, for system specifications using IDL the author has definedexplicit mapping rules which can be seen in chapter 5 and in ETSI (2003).

2.4.4. Communication

TTCN-3 distinguishes between message-based and procedure-based com-munication which could also be called asynchronous and synchronouscommunication respectively. Communication is used between test systemand SUT and within the test system itself.

Message-based communication is done by send and receive operationsand is based on asynchronous message exchange where only the receivergets blocked (see Figure 2.6). The transferred data can be defined by anytype but typically records are used.

Procedure-based communication is used to call procedures in remoteentities like it is done in Remote Procedure Call (RPC), CORBA, and Dis-tributed Common Object Model (DCOM). On caller side the communica-tion is handled by operations call, getreply, and catch and on callee side byoperations getcall, reply, and raise. Procedure calls in general may blockon the calling and called side (see Figure 2.6). In TTCN-3 the called sidegets always blocked and blocking on the caller side is adjustable. Non-blocking procedure calls marked by the keyword noblock have some limit-ations because no values can be transmitted from the called side in contextof the procedure call. Furthermore, blocking of procedure calls marked bykeyword nowait may be ignored any time whereas continuing is possibleat all times. In contrast to noblock procedure calls, nowait procedure callshave no limitations because a possible response may be handled after-wards.

Signatures

The information to be transmitted or to be received in sending or receiv-ing operations for procedure-calls are defined by (inline) signatures. Usingsignatures enables semantics checking of corresponding communicationoperations. Signatures consist of a parameter list, return value, exceptionlist, and blocking characteristic (default is blocking), as demonstrated be-low. The signature parameter list includes identifier, type, and direction as

27


Sender

send

Receiver

receive or triggerMessage

Caller

call

getreply orcatch exception

Callee

getcall

reply orraise exception

Procedure

Figure 2.6.: Message- and blocking procedure-based communication

used in IDL (see subsection 3.5.5). Parameters with direction type in havecall-by-value semantics and parameters with direction types inout and outhave call-by-reference semantics.

TTCN-3

signature MyBlockingProcedure (in integer par1, inout float par2, out float par3)return integer exception (Excep1, Excep2);

signature MyNonblockingProcedure (in integer par1) noblock;

Templates

Templates handle distinct values to be sent or received. They are usedto organise and re-use test data by providing a structure to define them.Templates can also be used inline to enhance readability and to avoid un-necessary expense in case of empty templates or templates with only fewfields. Signature templates are used for procedure-based communicationand type templates are used for message-based communication.

Templates provide parameterising, referencing by using other templates,and modification by extending templates. Values, value ranges, and match-ing mechanisms can be used in templates. At time of sending, templateshave to define concrete values why ranges and matching expressions haveto be fully resolved. If used in receive operations, received data is testedagainst the used template where templates with value ranges and matchingmechanism simplify testing. Hence, templates are very powerful, but thematching expressions could be improved as described in Schmitt & Ebner(2003). Type templates are mostly used together with records where allrequired values are defined.

28


Listing 2.2: TTCN-3 Templates

1 template MDATind ConnectionRequest := {2 mSDU := { iPDUType := CR, seqNo := omit, iSDU := omit }3 }4

5 template MediumSDU ConnectionConfirmation := { // this template is used with6 iPDUType := CC, seqNo := omit, iSDU := omit // template ’MediumDataRequest’7 }8

9 template MDATreq MediumDataRequest( template MediumSDU data ) := {10 mSDU := data11 }12

13 template MDATind DataTransfer( InresSDU data ) := {14 mSDU := { iPDUType := DT, seqNo := ?, iSDU := data }15 }

In Listing 2.2, various templates are defined that are used in functionMediumAccess (see Listing 2.7). Template ConnectionRequest (lines 1–3)specifies a message of type MDATind where the fields mSDU.seqNO andmSDU.iSDU shall have no value. It is used in combination with a receivestatement in Listing 2.7, line 6.

The two templates ConnectionConfirmation and MediumDataRequest(Listing 2.2, lines 5–11) illustrate the dynamic chaining of templates. Me-diumDataRequest is parameterised by a template of type InresPDU. InListing 2.7, line 8, it is instantiated with template ConnectionConfirma-tion as actual parameter. Template DataTransfer (lines 13–15) makes useof a simple matching mechanism. Operator “?” states that any value forseqNo is acceptable in an incoming message.

Many templates are defined inline in test case SingleDataTransfer (List-ing 2.6, lines 17, 18, 25, 26, 32, and 33) and function MediumAccess(Listing 2.7, lines 13, 25, 26, and 28). In particular, many messages ex-changed with the SUT via port ISAP1 are distinguished by their type only.Hence, there is no need for template definitions whose bodies would onlyconsist of empty brackets syntactically.

Ports

Communication under TTCN-3 is characterised by communication end-points which are called ports. Each communication operation is directedto a port and not to a connection. For each port there is a list definedwhere all allowed message types and procedures including their direction

29


are given. A port allowing message- and procedure-based communicationis of port type mixed and of type message or procedure respectively if onlyone communication type is allowed. Each message type or procedure hasone of the three directions in, inout, or out defined. Hence, fine control ofcommunication directions is possible which was not defined in TTCN-2.

Ports are modelled as an infinite FIFO queue where all incoming mes-sages or procedure calls are stored until explicitly consumed or removedby the owner of the port. Since there is no automatic removing, each in-coming calls have to be handled. Hence, specified tests have to considerall incoming calls and if a call is not necessary for the test result it has tobe explicitly ignored by removing.

There are several operations available to control ports. The top elementof a port queue can be checked without removing it. Port queues can becleared, started, and stopped during execution of a test. The receiving op-erations receive, getcall, getreply, and catch consume the top correspondingelement of the port queue if matching was successful. Despite the receiveoperation the trigger operation consumes each incoming message even incase of a mismatch. In case of a match it works like a receive operation.Hence, searching or waiting for a specific message gets easily possible.

In Listing 2.3, definitions for message-based communication are presen-ted. ICONreq and IDATreq (lines 1 and 2) are – among others – twomessages (ASPs) that can be sent to the Initiator entity of the Inres pro-tocol. A port type definition is given in lines 4–7. The keywords out and inindicate that messages ICONreq, IDATreq, and IDISreq can be sent andICONconf and IDISind can be received by a corresponding port instance.For communication with the Medium, similar definitions are made in lines9–15. A concrete message exchange is described in the test case shown inListing 2.6. In lines 17, 18, 22, 32, and 33 various messages are sent andreceived at port ISAP1 which is of type InitiatorSAP.

A simple example of procedure-based communication is introduced inListing 2.4. In line 1, procedure acknowledgmentSent is defined whichhas neither a parameter nor a return value. It is used for coordinationbetween the components of the tester. Conceptionally, it resides at theMTC. 3 Two contrary port types are defined for it: PortAtMTC (lines 3–5) accepts incoming calls, whereas PortAtPTC (lines 7–9) is used to invokethe remote procedure. A concrete procedure call is realised in Listing 2.6,lines 25 and 26, and Listing 2.7, lines 25 and 26.

3Please note that the procedure is not implemented as such. Instead, only its invocation andtermination is modeled by the MTC by getcall and reply operations. The procedure-basedcommunication in the given example is only made for illustration purposes.

30


Listing 2.3: TTCN-3 Message-based Com-munication

1 type record ICONreq {};2 type record IDATreq { InresSDU iSDU };3

4 type port InitiatorSAP message {5 out ICONreq, IDATreq, IDISreq;6 in ICONconf, IDISind;7 }8

9 type record MDATreq { MediumSDU mSDU };10 type record MDATind { MediumSDU mSDU };11

12 type port MediumSAP message {13 in MDATind;14 out MDATreq;15 }

Listing 2.4: TTCN-3 Procedure-basedCommunication

1 signature acknowledgementSent();2

3 type port PortAtMTC procedure {4 in acknowledgementSent;5 }6

7 type port PortAtPTC procedure {8 out acknowledgementSent;9 }

10

11

12

13

14

15

2.4.5. Test Configuration

TTCN was designed for functional, black-box testing and to describe Ab-stract Test Suites (ATSs) which are independent of concrete test platforms.Therefore, special interfaces between SUT and ATS are required to makea test suite executable. Furthermore, a distributed and concurrent test ar-chitecture is used and TTCN-3 additionally supports dynamic test config-uration, whereby test configuration can be modified during test execution.

Test configuration in TTCN-3 is structured by test components whichare interconnected by well-defined communication endpoints called ports(in TTCN-2 via Communication Points (CPs)). There is exactly one MainTest Component (MTC) which controls all other test components calledParallel Test Components (PTCs). PTCs can be dynamically created where-as the MTC is created automatically at each test case execution. The PTCsare independent of each other. Termination of the MTC automaticallyterminates all PTCs. A test component terminates by leaving its functionor testcase respectively, executing a stop command, or getting terminatedby another test component. Test components can have local timers, vari-ables, and constants. Ports are allowed to have one-to-many connectionsto support multicast connections.

The environment of the test system is defined by an Abstract Test Sys-tem Interface (ATSI) which specifies all communication endpoints to theSUT in an implementation independent manner. Hence, communication

31


System Under Test

Real Test System Interface

Abstract Test System Interface

Mapped PortsMapped Ports

MTC

Test System

PTC

Connected PortsIN

IN

OUT

OUT

INOUTINOUT

Figure 2.7.: Conceptual view of a typical TTCN-3 test configuration

between test components and the test system is also done via ports. Be-side, the Real Test System Interface (RTSI) defines the implementationdependent adaptation between ATSI and SUT (see Figure 2.7). The ac-cess respectively communication points between ATS and SUT were calledPCO in TTCN-2.

Test case execution is defined in the module control part and may bestructured by functions. A testcase is used to initiate a test case wherethe MTC is automatically created. Using the runs on and system clause fortestcase the MTC and ATSI can be given. Functions are used to structurePTC behaviour. Some available operations are

• create to create a component,

• connect to connect ports between components,

• map to connect ports between components and the test system inter-face,

• running to check if a component is still running, and

• done to wait for the termination of a component.

In Figure 2.5, a conceptual view of the test configuration used in theInres example is given. The tester consists of two test components calledMainTC and ParallelTC. They communicate with each other via a connec-tion established between the ports CoordinationPTC and Coordination-MTC. In addition, one port in each test component, namely ISAP1 and

32


Listing 2.5: TTCN-3 Test configuration – Component type definition

1 type component MainTC {2 port InitiatorSAP ISAP1;3 port PortAtMTC CoordinationPTC;4 timer supervisionTimer;5 }6

7 type component ParallelTC {8 port MediumSAP MSAP2;9 port PortAtPTC CoordinationMTC;

10 }11

12 type component TestSystem {13 port InitiatorSAP ISAP1;14 port MediumSAP MSAP2;15 }

MSAP2, is mapped to a port with the same name of the ATSI. TTCN-3abstracts from implementation issues such as encoding. Therefore, con-ceptionally the ports of the tester are not directly linked with the SUTitself. Instead, it is assumed that interaction with the SUT is realised by aRTSI which is outside the scope of TTCN-3 (see Figure 2.7).

In Listing 2.5, TTCN-3 test component definitions are presented forMainTC, ParallelTC, and the abstract test system (TestSystem) which isdefined just like a common test component type. In addition to an arbit-rary number of ports, a TTCN-3 test component can have its own set oflocal timers, variables, and constants. For example, any component oftype MainTC has a supervisionTimer at its disposal (line 4).

2.4.6. Behaviour Description

Functional and dynamic behaviour of components over ports is describedby functions, test cases, alternatives, and altsteps and executed in modulecontrol parts. Test cases are used for the behaviour description of MTCs.Functions are used to structure and specify test behaviour, to organisetest execution, and to structure computation in a module. For instance,functions can be used to organise behaviour of PTCs.

In the following these concepts are described in more detail. Examplesof a test case, function, and altstep definition are given in Listings 2.6, 2.7,and 2.8.

33


Listing 2.6: TTCN-3 Test case SingleDataTransfer

1 testcase SingleDataTransfer () runs on MainTC system TestSystem {2 var ParallelTC ptc;3 var default def1, def2;4

5 ptc := ParallelTC .create ;6

7 map( self : ISAP1, system:ISAP1 );8 map( ptc:MSAP2, system:MSAP2 );9

10 connect( self :CoordinationPTC, ptc:CoordinationMTC );11

12 ptc. start ( MediumAccess() );13

14 def1 := activate ( MTCFailure() );15 def2 := activate ( ReceptionIDISind( inconc ) );16

17 ISAP1.send( ICONreq : {} ); // connection request18 ISAP1.receive( ICONconf : {} ); // connection confirmation19

20 supervisionTimer. start ( maxTransferTime ); // restrict time for data transfer21

22 ISAP1.send( InresDataRequest( someUserPDU ) ); // data transfer23

24 // delay disconnection request until ’ptc’ has received and acknowledged the data25 CoordinationPTC.getcall( acknowledgementSent : {} );26 CoordinationPTC.reply( acknowledgementSent : {} );27

28 supervisionTimer.stop; // cancel timer to avoid a timeout in the following29

30 deactivate( def2 ); // a disconnection indication is no undesirable event any longer31

32 ISAP1.send( IDISreq : {} ); // disconnection request33 ISAP1.receive( IDISind : {} ); // disconnection indication34

35 all component.done;36

37 setverdict ( pass );38 }

Control Structure

Behaviour is described in sequential order by basic control structures likewhile, for, do...while, and if...else and alternative behaviour statements likealt and interleave. Furthermore, usage of goto with labels is possible tosupport conversion of TTCN-2 test cases to TTCN-3.

The alt statement describes a set of alternative behaviour depending onthe reception and handling of communication, timer events, and PTC ter-mination which are called reception statements. Each alternative consistsof the three parts boolean expression, guard, and statement block. Thestatement block of an alternative gets executed if the corresponding guard

34


can be executed which has to be a reception statement. The boolean ex-pression has to evaluate to true or has to be empty to enable a guard. Itis possible to provide as last alternative an optional else part which getsexecuted if no alternative matched.

To evaluate guards a snapshot semantics is defined. Entering an altern-ative statement activates the snapshot mechanism where the state of allrelevant components, port queues, and timers are frozen to allow undis-turbed evaluation of the boolean expressions and guards. The evaluationorder is given by the order of the alternatives. If no guard can be executed,a new snapshot is taken and evaluation starts from the beginning until oneguard can be executed. However, an alternative is called blocked if allguards can never be fulfilled which must lead to a test error. There is therepeat statement to initiate a re-evaluation of an alt statement where a newsnapshot is taken and evaluation starts again from the first alternative.

If exact order of receiving messages or procedures is not predictable ornot important, an interleaved handling is possible by the interleave state-ment. Thus, writing down all possible combinations of alternatives is notnecessary. Interleaves are structured like alternatives with empty booleanexpressions and with no else clause. Furthermore, usage of control state-ments, functions, and communication operations inside interleaves is re-stricted.

Altsteps

Beside structuring behaviour by functions it is especially possible to struc-ture alt statements by usage of altstep where a collection of alternativescan be defined. Additionally, default behaviour can be defined via alt-steps. Altsteps provide local definitions and own parameters including aruns on clause. The body of altsteps is structured by a set of alternativeslike in alt statements.

There is a default mechanism for alternatives in TTCN-3 where altstepscan be activated by default. Defaults are stored in a default list and canbe activated and deactivated any time by operations activate and deactivaterespectively. The deactivate operation requires a default reference whichis delivered by the activate operation and which can be stored in a defaulttype. A default reference gets necessary because an altstep can be activ-ated with different parameters. The default list is called if no alternativeof an alt statement can be executed. The default altsteps and their altern-atives are evaluated step by step until an alternative can be executed. If

35


Listing 2.7: TTCN-3 Function MediumAccess

1 function MediumAccess() runs on ParallelTC {2 var integer receipt ;3 var default def := activate ( PTCFailure() );4 var MDATind indication ;5

6 MSAP2.receive( ConnectionRequest );7 receipt := 1; // first (received) connection request of the initiator8 MSAP2.send( MediumDataRequest( ConnectionConfirmation ) );9

10 alt {11 [ receipt <= maxRepetitions ] MSAP2.receive( ConnectionRequest ) {12 receipt := receipt + 1;13 MSAP2.send( MediumDataRequest( { CC, omit, omit } ) );14 repeat;15 }16 [ receipt > maxRepetitions ] MSAP2.receive( ConnectionRequest ) {17 setverdict ( fail );18 stop;19 }20 [] MSAP2.receive( DataTransfer( someUserPDU ) ) −> value indication { /* empty */ }21 }22

23 MSAP2.send( DataAcknowledgement( indication.mSDU.seqNo ) );24

25 CoordinationMTC.call( acknowledgementSent : {} );26 CoordinationMTC.getreply( acknowledgementSent : {} );27

28 MSAP2.receive( MDATind : { mSDU := { DR, omit, omit } } );29 setverdict ( pass ); // disconnection request30 }

there is no executable alternative found in the default list then the defaultmechanism will return back where it has been invoked.

In Listing 2.8, altsteps MTCFailure and ReceptionIDISind are defined.Altstep MTCFailure makes test execution fail if a message is received atport ISAP1 that is not handled elsewhere or a timer expires. Altstep Re-ceptionIDISind illustrates the definition of a parameterised altstep. De-pending on variable result, the reception of message IDISind leads to dif-ferent test verdicts.

Timer

TTCN-3 supports usage of timers. Local timers declared in componenttype definitions are running on the component. There are operations tocontrol and evaluate timers. The start and stop operation are used forcontrol of timers. The elapsed time after starting a timer can be retrievedby the read operation. The status of a timer can be get by the running

36

2.5. Summary

Listing 2.8: TTCN-3 Altsteps MTCFailure and ReceptionIDISind

1 altstep MTCFailure() runs on MainTC {2 [] ISAP1.receive {3 setverdict ( fail );4 stop;5 }6 [] any timer.timeout {7 setverdict ( fail );8 stop;9 }

10 }11

12 altstep ReceptionIDISind( verdicttype result ) runs on MainTC {13 [] ISAP1.receive( IDISind : {} ) {14 setverdict ( result );15 stop;16 }17 }

operation which delivers a boolean to express if the timer is still running.The timeout operation can be used in guards of alternatives to check ifa timer has expired or is used as stand-alone operation. A stand-alonetimeout operation blocks execution until the timer expires.

Verdicts

The TTCN-3 special basic type verdicttype is used to handle test verdicts.Only the five distinguished values pass, fail, inconc, none, and error areavailable as verdicts. Test verdicts are delivered by test cases and dependon the local verdict of each component of a test case. After terminationof a component the test case verdict gets updated. Component verdictscan be set and read by the setverdict and getverdict operations respectively.Verdicts can only be downgraded why it is not permitted to revise a verdictfrom fail to pass, for instance. Test verdict setting does not stop test caseexecution.

2.5. Summary

In the first section of this chapter dynamic testing concepts have been clas-sified to provide an overview and motivation about different kinds of dy-namic tests. The classification distinguishes between type of implementa-tion, phase in development cycle, system knowledge, test objectives, testdata selection, and authority for test results.

37


The second section explained why testing object-oriented systems is dif-ferent from testing of other systems and why static testing is not sufficient.The object-oriented concepts encapsulation, inheritance, and polymorph-ism as well as method interaction and language and compiler servicesmake testing more difficult.

Thirdly, manual and automatic test generation were discussed. Someremarks about the test generation tools Autolink and TestComposerwere given.

Fourthly, the test description language TTCN-3 was described whichpermits the specification and implementation of tests for distributed sys-tems in an implementation language independent manner. Important tomention is the possibility of importing data specifications from other lan-guages, the introduction of procedure-based communication, and dynamictest configuration.

38

3. UML-based Testing

As explained in the preceding chapter, testing requires automation andinterworking between system and test development. Nowadays, many(object-oriented) systems are described using the UML which is definedby the OMG (OMG 2003c). Thus, UML models are an important sourcefor test development why using UML from a test perspective has to beconsidered. Additionally, there is ongoing work on an UML Testing Pro-file (UTP) (Schieferdecker et al. 2003) and an improved version of UML,namely Unified Modeling Language 2.0 (UML 2.0) (Jeckle et al. 2004;OMG 2003b).

The automatic test generation process approach based on SDL, MSC,and TTCN as described in section 2.3 is used as inspiration for UML-based scenario testing. Scenario-based testing, manual as automatic, isapplicable for black-box and specific white-box testing for communica-tion protocols and distributed systems like CORBA-based systems. Inparticular, manual scenario-based testing is often used by test designersto test specific parts of the SUT which are interesting or not covered byan automatic test generation process. Furthermore, there is a discussionof TTCN-3 Graphical Presentation Format (GFT) in context of MSC andUML in Schieferdecker & Grabowski (2003) available where the close re-lation between all three standards is detailed.

This chapter is structured as follows. Firstly, some remarks to UMLand its diagram types are given. Secondly, suitability of UML models fortesting is discussed. Thirdly, scenario-based testing with UML is explained.Fourthly, MSCs are explained. Fifthly, the IDL will be described. Finally,a summary and an outlook are given.

3.1. Unified Modeling Language

Unified Modeling Language (UML) is a model with focus on structure andbehaviour definition for object-oriented systems for which several diagramtypes are defined (OMG 2003c). It defines only the notational syntax andinformal semantics for object-oriented models but there is no methodo-logy given. Some model elements can be used in several diagrams. Each

39


diagram has its own usage and point of view on the system why the sys-tem can be described from many different perspectives. Hence, systemdevelopers can choose the right view to describe a specific system struc-ture or behaviour. There are several tools which support drawing UMLmodels and code generation for different languages like C++, Java, andIDL.

The following diagram types are available in UML version1.5:

Usecase diagrams are used to describe in an abstract way the system re-sponse to external inputs given by some external actor, normallyhumans. Mainly used for specifying system requirements.

Class diagrams describe the class or interface structure including their at-tributes, methods, and relationships. Class diagrams are used todescribe distribution of data and behaviour to classes.

Behaviour diagram types are used for describing dynamic issues.

Activity diagrams or object flow charts show sequences of activities(processes not states) where concurrent execution is possible.They are mainly used to model human work flow and may beassociated to a usecase or class diagram.

Collaboration diagrams describe interactions among objects in con-text or a limited role under emphasis of relationship betweenobjects and their topography. Mainly used to explain or todocument sequences.

Sequence diagrams are used to describe sequences of message ex-changes between objects in a time limited situation with em-phasis on the temporal order. Can be used to describe neces-sary collaborations to implement a use case.

State diagrams show the sequential control requirements of objectsby sequences of states depending on external stimuli (finitestate machines).

Implementation diagram types are used to describe implementation issues.

Component diagrams show dependency relationships between com-ponents which have their own identity and a defined interface.Components define boundaries and groups and organise ele-ments.

40

3.2. Suitability of UML for Testing

Deployment diagrams represent objects and components on nodeslike hardware, software, or network architecture and their com-munication associations. Deployment diagrams are useful forintegration planning.

Sequence diagrams and collaboration diagrams are describing the sameissue. Contrary to sequence diagrams, where the temporal order is thefocus, collaboration diagrams are focussed on the working relationship.Diagrams can be grouped and organised into hierarchical packages wherepackage dependencies can be described. This kind of diagram is realisedas a special case of class diagrams.

3.2. Suitability of UML for Testing

Using a system specification defined in UML to generate, maybe automat-ically, and to specify test cases the applicability of UML and its diagramtypes has to be inspected first (Binder 2000, chapter 8).

Using UML as a test model requires unambiguousness to support auto-matic production and relation to probable faults to provide a test designwhy identification, analysis, and demonstration of relationship is required.UML provides only a notational syntax where no prescription of result,technique, or process is given. Furthermore, UML is very flexible becauseonly restrictions on usage of notation are given. However, models can befragmentary, incomplete, inconsistent, and ambiguous without violatingUML. Additionally, the models are indifferent to testability because com-binational logic and domain definitions are missing which requires muchhand work to produce tests. Thus, automatic test code generation is notpossible. Nevertheless, the models are still an important source for testdevelopment. Responsibility and architecture of SUT can be modelled andpartly automatic test generation may be possible if models are complete,correct, and consistent.

Usecase diagrams use input and output variables without providing anydefinition and conditions are missing to determine basic and alternateflows (Miga et al. 2001; Mulvihill 2003). They can be instantly mappedonto sequence diagrams. However, usecase testing alone is not enoughbecause of incomplete system coverage. Class diagrams are the main re-source for structural information like types, methods, and attributes andtherefore, are very important for test specification. For instance, inform-ation missing in other diagram types like usecases can be obtained fromclass diagrams. Furthermore, test cases could be generated to test mutual

41


constraints and dependencies defined by associations, correct create anddestroy of aggregated objects, and correct usage of generalisation. Activ-ity diagrams could be used to develop test models by control flow where,for instance, decision tables and composite control flow graphs for a col-lection of sequence diagrams are usable. Control flow graphs at methodstate could be used for analysing path coverage. Furthermore, structuringtest cases can be modelled by activity diagrams, especially in conjunctionwith associated usecase or class diagrams.

Collaboration diagrams show all required methods for a complete inter-action. They are usable for structuring an implementation and for specify-ing a method implementation, all methods in a class, or an usecase. Only asmall slice in comparison to the whole system is described wherefore cover-age analysis is limited to this slice. The method call hierarchy must not bea tree why it is ambiguous. However, transformation into several sequencediagrams with resolved ambiguities is possible. Sequence diagrams showhow the collaboration via message exchange is done in the temporal di-mension to implement, for instance, a usecase. A sequence diagram cannotdescribe all possible paths why several sequence diagrams are necessary toget all paths. Sequence diagrams are less expressive in the selection and it-eration notation, the conditional and delayed message distinction is weak,and dynamic binding and unique superclass/subclass behaviour cannot beshown. Using the round-trip scenario test pattern a sequence diagram isused as test purpose where each possible path can be used for test casegeneration. The intention of the test approach is to “extract a controlflow model from a UML Sequence Diagram and develop a path set thatprovides minimal branch and loop coverage” (Binder 2000, page 579).State diagrams describe possible states and transitions of objects by usageof finite state machines but the provided notation is less expressive andlacks a well defined semantic. Thus, state diagrams are very important forautomatic test generation by coverage analysis but due to their shortcom-ings usage for testing is difficult. However, using usecase and sequencediagrams could partially replace state-based testing. In (Binder 2000,chapter 7) usage of state models like UML state charts, Object ModelingTechnique (OMT) dynamic model, and Real-time Object-Oriented Mod-eling (ROOM) statechart are discussed to test object-oriented systems. InMellor & Balcer (2002), using executable UML is described.

Component diagrams describe distribution and dependencies of com-ponents with own interfaces (implementation entities) like classes from aphysical point of view which is used, for instance, to describe concretedistribution into libraries. Thus, component diagrams provide structural

42

3.3. UML-based Test Specification

information which can be used to identify method call paths. The pathsfound can be expressed in sequence diagrams to allow test case specifica-tion and generation. Deployment diagrams represent distribution of ob-jects and components on nodes and communication associations betweennodes. Nodes are used for execution. Depending on the number of showndetails in deployment diagrams they can be used for dependency analysisand for integration planning especially.

Hence, existing diagrams from the specification can be used directly fortest generation such as sequence diagrams, if fully defined. Additional dia-grams, especially for scenario-based testing, can be specified, too (Amyot& Eberlein 2003). Thus, automatic and manual test case generation andspecification are together possible. Test case generation based on test pur-poses specified by sequence diagrams where each possible complete pathgets a test case is usable, but usage of test coverage analysis is difficult.Overall, UML is missing a well defined semantics to be well applicable forautomatic test generation (Binder 2000, chapter 18). See Binder (2000,chapter 9) for test strategies and test patterns. A coverage model forobject-oriented systems is given in Binder (2000, section 4.4).

3.3. UML-based Test Specification

As discussed in the section before, existing system specifications done viaUML could be used for test generation. However, some diagram typescould be used for test purpose or test case specification especially. Thus,scenario-based, manual test specification with UML is more interestingwhere the test designer can focus on specific elements in the SUT and re-quires no test specific knowledge like the used test language.

One diagram type does not provide enough information to specify andgenerate a complete test case, and responsibility and architecture of a SUTcan only be modelled if the used models are complete, correct, and con-sistent. However, if we take a look into test suites defined via TTCN-3we can find a partitioning into a statical and dynamic part. The stat-ical part contains elements like type, test data, method signature, and testconfiguration definitions, whereas the dynamical part contains elementslike method calls and their order, response evaluation, test configurationset up, and test result handling. Thus, usage of class diagrams for staticinformation and sequence diagrams for dynamic information to generatetest cases is quite enough. Furthermore, other UML diagrams can be usedto generate class or sequence diagrams (see Figure 3.1).

43


Component

Usecase,Activity, State,Collaboration,Deployment

Class Sequence UTP

IDL

Test Suite(TTCN-3)

Figure 3.1.: UML-based test specification

Information from component diagrams can be translated into class dia-grams and usecase, activity, state, and collaboration diagrams can be usedto generate sequence diagrams. More information about generation ofsequence diagrams are given in Binder (2000). For instance, activity dia-grams are associated to class and usecase diagrams, a usecase or collabor-ation diagram can be used instantly to generate several sequence diagrams.Activity diagrams can also be used to control test case execution order ascan be done with High-Level Message Sequence Charts (HMSCs) (see sec-tion 4.5).

The concept of using static and dynamic information from differentsources and its applicability and usefulness was shown earlier by usageof SDL as static source and MSC as dynamic source as described in sec-tion 2.3. SDL is a very expressive state-based specification language andMSCs are used to describe message exchanges like in sequence diagrams.Despite its good results in testing communication protocols, tool vendorslike Telelogic with ist tool TAU G2 shift from SDL and MSC to UML toreach a wider audience. Due to this shift a combination of SDL and MSCwith UML or at least the integration of well-defined and widely used con-cepts of SDL and MSC into UML is wished to enhance UML with moreexact semantics. Thus, automatic test generation from UML would bemore expressive. Additionally, there is ongoing work to define the UMLTesting Profile (UTP) which allows test suite specification and presentationinside UML (Schieferdecker et al. 2003). There is ongoing work on ITU– Telecommunications Standardisation Sector (ITU-T) standard Z.149 todefine a mapping of UTP to TTCN-3. Hence, UTP specifications could beused to provide a more complete test suite.

44

3.4. Message Sequence Chart

TTCN-3 is a well established testing environment and therefore, usageof TTCN-3 for test suite specification is used in this thesis where onlyclass and sequence diagrams have to be mapped to TTCN-3. Missingparts to provide a full TTCN-3 test suite can be integrated by using UTP,and generated test cases from class and sequence diagrams may be used inUTP, too. Most UML tools support conversion from class diagrams intoIDL where all required information for test generation are still available.Hereby, IDL can be used instead of class diagrams to widen application(see Figure 3.1). Mapping sequence diagrams and IDL to TTCN-3 is de-scribed in chapter 4 and chapter 5 respectively.


Sequence charts like UML sequence diagrams (OMG 2003c) and MessageSequence Charts (MSCs) (ITU-T 2001) are used to specify and describecommunication behaviour by message interchange including procedurecalls between several distributed entities in a temporal order. Since UMLsequence diagrams do not provide well defined semantics in contrary toMSCs, MSCs are more expressive than sequence diagrams. MSCs are wellused for test purpose and test case specification and MSCs support mostfunctionality of sequence diagrams, so MSCs are used to discuss usage ofsequence charts to specify test cases (see chapter 4). Furthermore, thereis ongoing work which introduces MSC concepts into UML 2.0 whichleads to the convergence of sequence diagrams to MSCs (Jeckle et al. 2004;OMG 2003b).

MSC is a graphical specification language standardised by ITU-T as Re-commendation Z.120 (ITU-T 2001). It is a scenario language to describecommunication behaviour between system entities and their environment.There is a textual and a graphical notation available whereat the textualnotation is mainly used by tools to store and interchange charts and thegraphical notation is used for intuitive representation of charts. Threetypes of charts are provided by MSC. Namely, (basic) MSC to describeconcrete events in a temporal ordering, High-Level Message SequenceChart (HMSC) to illustrate how to combine MSCs, and MSC documentswhich serve as a summary of belonging charts. The current version ofMSC is called Message Sequence Chart-2000 (MSC-2000) (ITU-T 2001)and provides better support, in comparison to its predecessor MSC-96(ITU-T 1996), for real-time systems, object-oriented systems, and sequen-

45


mscdoc MyDeclarations

MSC_A MSC_B MSC_C

Pattern_A

Figure 3.2.: MSC document example

tial programs by added concepts for data, time, control flow, and object-orientation on MSC documents.

In the following MSC-2000 will be detailed by document structure, ba-sic elements, structural elements, and HMSCs.

3.4.1. MSC Documents and Comments

MSC documents are used to provide an associated collection of MSCs (setof traces) and define all kinds of instances used in the MSCs. In the defin-ition part, available MSCs are defined, and the utility part is used to de-scribe patterns of MSCs which can be used by MSCs in the definition part(see Figure 3.2). The relation to documents like TTCN, SDL, and UMLdocuments can be given by the keyword related to. Instance definitionscan use inheritance concepts to describe among others decomposition ofinstances.

MSC supports three kinds of comments. The note is only available intextual notation, the comment is used for informal explanations associatedwith symbols or text, and the text is used for global comments associatedto a chart.

3.4.2. Basic Message Sequence Charts

Basic MSCs are used to specify and describe the communication flowbetween system entities where the concept of instances and messages isused. Communication with the environment can be described and usageof gates to compose MSCs is supported. Actions are used to describeinternal behaviour of entities and conditions are used to restrict numberof traces. Timers are available to express time limits for execution. In-stances can be dynamically created and terminated. Basic MSCs are nowexplained in detail.

46


blockStation_Ini

blockMedium

disconnected

idle

ICONreq

counter:=1

T,5MDATreq(CR)

MDATind(CR)

idle

MDATreq(CC)

MDATind(CC)

idle

ICONconf

connected

msc ConnectionEstablishment

(a) Basic MSC

envISAP1

IniBlockdecomposed as IniProcs

Initiatorblock

Mediumenv

MSAP2

ICONreq MDATind(CR)

ICONconf MDATreq(CC)ConnectionEstablishment

IDATreq(42)

MDATreq(DT,one,42)

loop <4,4>

IDISind

MDATreq(DT,one,42)

MDATind(DT,one,42)

MDATreq(AK,one)

MDATind(AK,one)

IDISreq

IDISind

MDATreq(DR)

MDATind(DR)

alt

msc DataTransfer

(b) MSC Expressions, Coregions, and Gates

Figure 3.3.: Basic MSCs for the Inres protocol

In Figure 3.3(a) an MSC with two instances, Station_Ini and Medium,is shown that are displayed as vertical lines with an additional rectanglefor the instance header and a horizontal bar for denoting the instance end.Instance Station_Ini is a block that represents an Inres protocol instanceat the sender (initiator) side (see subsection 2.4.1). Instance Medium rep-resents an underlying medium over which data are exchanged with someimaginary responder. The MSC describes the typical scenario of a con-nection establishment: If Station_Ini receives message ICONreq (repres-ented by the annotated arrow pointing from the diagram border to theinstance axis), the connection request is forwarded via the medium (mes-sages MDATreq(CR) and MDATind(CR)). Provided that the other partyresponds with a confirmation (MDATreq(CC) and MDATind(CC)), a con-firmation message (ICONconf ) is sent by Station_Ini. Typically, the de-

47


scription of an instance finishes with a special end symbol. However, thissymbol does not mean that the instance actually terminates.

Instances, Messages, and Control Flow

The base elements of basic MSCs are instances and messages. Instancesrepresent system entities which exchange messages with each other andthe environment. Instances have a name and can have a type, and mes-sages have a name and optional parameters. Message interchanges aredivided into asynchronous events, where in events are used for receivinga message and out events for sending a message. If there is only an inevent available an unknown sender message can be described and if thereis only an out event used a lost message is described. Messages have anoptional time attribute wherewith delay of message sending and receivingcan be specified. The textual representation of MSCs may be ordered byinstances or events where an event order describes a valid execution trace.

Temporal ordering of exchanged messages is defined by a total temporalordering on instance axis and a partial order between instances where onlythe order is defined but no concrete timing. Hence, it is nonrelevant if amessage arrow is directed up or down because a message has to be sendfirst to get consumed. However, in case where unrelated events on differentinstances have to be ordered a general ordering can be defined explicitly.Furthermore, in case ordering on a instance axis is not important it canbe suspend by coregions for a part of the axis. Nevertheless, the usage ofgeneral ordering in coregions is possible.

Apart from message interchange, MSC supports synchronous messageexchange by means of calls and replies. Calls are like remote methodinvocations where the result is returned by the reply. The call name rep-resents the named unit of behaviour inside an instance. The reply usesthe same name as the corresponding call. Calls can be distinguished intoblocking and non-blocking calls. In case of a blocking call the callerenters a suspension region where the caller is waiting for a reply and noother events may happen, whereas in case of a non-blocking call the callermay proceed further. Non-blocking calls are called asynchronous whereasblocking calls are called synchronous.

Environment and Gates

The environment is represented by the rectangular frame of each MSC(see Figure 3.3(a)). Communication between instances and environment

48


is permitted by message interchange. Each in and out message with theenvironment is assigned to a gate (interface to environment) which allowsto compose MSCs in conjunction with usage of MSC references inside anMSC. The environment provides no total ordering for messages why in-stances should be used as environment if gates are not required or orderingis required.

Actions

Beside message exchange, internal actions of instances can be given byinformal text or formal data statements which can be used to modify in-ternal states or counters, for instance. Actions are an atomic element andare represented by a rectangular symbol. For instance, in Figure 3.3(a) thevariable counter of instance Station_Ini is set to one.

Conditions

Conditions are used to restrict valid traces or the composition of MSCreferences in HMSCs. Conditions can be used for one, several, or all in-stances. There are two kinds of conditions, namely setting and guardingconditions. A setting condition defines a state of an instance where thestate is given by a state name. If all instances are involved, it describes aglobal state. A guarding condition, depending on a boolean expression,restricts the following event execution. The boolean expression can begiven in the data language or by an active state which was set in a formercondition.

Timers

Beside the temporal order of messages, the usage of timers is possible toexpress duration dependencies (see Figure 3.3(a)). Timers are described bythe three events start, timeout, and stop and corresponding events have tobe attached on the same instance. Timer duration for timeout is settableby lower and upper bounds. There is a global clock assumed but globaltimers are not supported.

Instance Creation and Termination

Apart from static creation, instances can be dynamically created by otherinstances. Instance termination is done by instances itself. Instance cre-ation is represented by a dashed arrow beginning at the creating instance

49


and ending at the new instance head. Instance termination is representedby a cross. Since all instances, static and dynamic, have to be explicitlyshown, the creation of an unknown number of instances is not possible.This may be a hard restriction but it is sufficient for scenario descriptionwhich is the purpose of MSCs.

3.4.3. Structural Concepts

Beside basic MSCs the structural concepts coregions, MSC references, in-stance decomposition, and inline expressions are supported which will bedescribed in the following.

Coregion

Total ordering on instance axes can be suspended by coregions where or-dering gets changed to allow any event order. For instance, sending orreceiving several messages may be interchanged. Suspending total eventordering can be useful to describe higher-level systems, too. Ordering incoregions can still be ordered or limited respectively by usage of the gen-eral ordering mechanisms. Coregions are graphically marked by a dashedinstance axis as done in Figure 3.3(b) on instance Initiator.

Inline Expressions

Inline operators are used for easier definition of event structures. Theoperators alt, par, seq, opt, exc, and loop are available to define alternative,parallel, and sequential composition, optional regions, exceptions, anditerations.

Alternative composition is used to define alternative execution tracesof an MSC whereby only one trace gets executed. The choice betweendifferent traces has to be done after executing the common part of thepossible traces. Parallel composition represents parallel execution of alldefined sections whereas event order within each section gets preserved.Sequential composition represents the weak sequencing operation. Op-tional events can be defined by an optional region which is equal to analternative with an empty MSC as second operand. Exceptional cases canbe handled by the exception operator which is equal to an alternative withthe remaining MSC as second operator. Thus, if the exception part getsexecuted the MSC terminates. The option and exception operator are verysimilar except continuation or termination of the MSC after operator exe-cution. As last operator the loop operator is provided to define iterations.

50


Number of loop executions are defined by a lower and upper boundary inwhich usage of the keyword inf is supported to express an infinite bound-ary.

An alternative and loop expression is shown in (see Figure 3.3(b)).

MSC References

Due to structure MSCs an MSC can reference other MSCs of the MSCdocument. All instances used in a referenced MSC must also appear in thecalling MSC. Events can be send to and received from a referenced MSCby gates. References may have parameters which have to match with thecorresponding MSC parameter declaration. MSC reference expressionscan be defined by the operators alt, par, seq, loop, opt, and exc as definedby inline expressions before. Therefore, several MSCs can be referenced.

At the beginning in Figure 3.3(b) a reference to MSC ConnectionEstab-lishment is given.

Instance Decomposition

In addition to MSC references instances can be decomposed to structurecharts as done with instance Initiator in Figure 3.3(b). Instance decompos-ition can be used to control level of detail where interaction is described.Behaviour and internal structure of decomposed instances are defined byan own MSC document which uses the instance kind name as documentname. The behaviour is described by an MSC and the structure by usedinstances. A hierarchy of decomposed instances may be used.

3.4.4. High-Level Message Sequence Charts

Apart from MSC documents and basic MSCs there are High-Level Mes-sage Sequence Charts (HMSCs) available as another structuring type. Theyare directed graphs which describe how to combine a set of MSCs. Thus,HMSCs provide a higher description and structuring level by abstractingfrom concrete message exchanges.

Each node in an HMSC can be either a start or end node, an MSC ref-erence, a condition, a connection point, or a parallel frame. Nodes areconnected by flow lines and flow lines can be connected by connectionpoints. MSC references may use reference expressions to reference to sev-eral charts. Conditions are used for describing system states, guards, orrestrictions as similarly done by conditions in basic MSCs. Parallel frames

51


loop <0,inf> ConnectionFailure

ConnectionSuccess

connected

TransmissionSuccess

ConnectionRelease

TransmissionFailure

disconnected

hmsc HMSC Example

Figure 3.4.: HMSC example

contain smaller HMSCs which are part of a parallel operator and hence,are executed in parallel and events from different smaller HMSCs can beinterleaved. An HMSC example is given in Figure 3.4.

52

3.5. Interface Definition Language


There exist several standards which define an Interface Definition Lan-guage (IDL). However, the IDL standard defined and used in the CORBAis the most popular one and others are mostly derived from it (ISO/IEC1999; ITU-T 1997a; OMG 2001b). Furthermore, we are in particular in-terested in using it for CORBA-based systems and if the IDL standard isimprecise or lacking some information, the CORBA standard can be usedas reference. Therefore, only CORBA IDL is mentioned here.

The IDL is a language to describe interfaces in an implementation lan-guage independent manner and can also be used by other systems thanCORBA. It does not support the description of implementation character-istics like behaviour, instances, or relationships.

For better understanding of IDL, the CORBA gets explained first. After-wards, IDL is explained in detail by the object model, data types, modulesand interfaces, and attributes and operations.

3.5.1. Common Object Request Broker Architecture

The Common Object Request Broker Architecture (CORBA), defined bythe OMG, is a standard architecture for distributed object systems. Theheart of CORBA is the Object Request Broker (ORB) which is the commu-nication infrastructure for the distributed environment. The ORB providesa mechanism for transparently communicating client requests to target ob-ject implementations. It simplifies distributed programming by decouplingthe client from the details of the method invocations, and hence, makesclient requests appear to be local procedure calls. The ORB consists ofthe ORB core and some interfaces on top of it. The ORB core providesthe basic representation of objects and means for the communication ofrequests.

The technology used in the ORB core is hidden by the public interfaceslayered on top of it. There are the IDL Stub and Skeletons which presentthe language mapping and support the static invocation of requests toobjects, the Dynamic Invocation Interface (DII) and the Dynamic SkeletonInterface (DSI) which allow dynamic creation and invocation of requeststo objects at run-time, and the Interface Repository (IR) that providesstorage of object interface definitions which are accessible by applicationsat run-time (see Figure 3.5).

53


IDLStubs

DII

DSIStatic IDLSkeleton

ObjectAdapter

Object Request Broker

Client Object Implementation

Figure 3.5.: The CORBA architecture

3.5.2. Object Model

To understand IDL, one must know the object model of CORBA. All fea-tures of the object model must be captured by IDL because it shall describethese features. Therefore, the object model and IDL can be described to-gether. All that is valid for the object model should be valid for IDL andvice versa except the special restrictions of a model and a language. Anexample for this exceptions is the module and data type concept of IDL.

The object model of CORBA is the elementary part of the whole stand-ard. It describes the view, called interface, on each object. This view isdescribed using the IDL of the OMG for CORBA (OMG 2001b, chapter3). It is a language to describe interfaces in an implementation languageindependent manner. It shall not describe implementation characteristicslike behaviour, instances, or relationships. Therefore, the following con-structs are defined:

Constants to assist with type declarations,

Data type declarations to use for parameter typing,

Attributes which allow getting and setting of a value of a particular type,

Operations which take parameters and return values,

Interfaces which group data type, attribute, and operation declarations,

Modules for name space separation.

54


Thus, each client can invoke remote operations on an object withoutknowing about the implementation details. The communication betweenobjects per default is peer-to-peer and synchronous in an at-most-oncemanner. Asynchronous communication is only available in using one-wayand best-effort manner.

The IDL is a base of the whole CORBA standard and an importantpoint in developing distributed systems with CORBA. It allows the reuseand interoperability of objects in a system. A mapping between IDL anda programming language is defined in the CORBA standard. IDL is verysimilar to C++ in containing pre-processor directives (include, comments,etc.), grammar as well as constant, type, and operation declarations. Thereare no programming language features like, e.g., if-statements.

The most important part of IDL are operation specifications. The oper-ations are a part of interfaces for an object. Interfaces may be summarisedto modules. This leads to hierarchical composition with naming scopes.The next sections explain the data types, module and interface concept,and operation declarations.

3.5.3. Data Types

IDL supports the most basic data types from C++, but there are no ref-erences in IDL. Instead, the types string, boolean, and any are available.Some data types have a different specification, like char which is a type ofits own in CORBA. The constructed types enum, struct, array, and unionare similar to the ones in C++. The template type sequence is a variablelength array of elements of one, but any, IDL type. The type string is likesequence but only supports ASCII ISO-LATIN characters. Type any is liketype Object in Java a placeholder for any possible IDL type (see Table 3.1).A code example is given in Listing 3.1.

3.5.4. Modules and Interfaces

The main concept behind IDL consists of interfaces. Each interface maycontain constants, types, attributes, exceptions, and operations for oneobject. A module is a method to separate name spaces and may containany IDL construct. Each IDL construct is automatically public accordingto the object-orientated concept. (Multiple-) Inheritance is only permittedfor interfaces, not for modules. Forward declarations of interfaces permittheir use before their definition. The concepts can be seen in Listing 3.2which illustrates an interface hierarchy structure.

55


Table 3.1.: Overview of IDL types


Basic short, long

long long

unsigned short

unsigned long

unsigned long long

float, double

long double

char, wchar

boolean

octet

any


Object reference Object

Constructed struct

union

enum

Template sequence

string, wstring

fixed

Complex arrays

Native native

Concrete language mappings between C, C++, SmallTalk, Cobol,Ada, Java, and IDL can be found in the CORBA standard (OMG 2001b).

3.5.5. Attributes and Operations

Each client knows the IDL interface specification of each object contain-ing all information about the object. Attributes are like variable definitionsbut they behave like operations in CORBA. Each read-write attribute getsa set- and a get-function and each read-only attribute gets a get-function.The main part of an interface is based on operations. An operation declar-ation consists of

• an operation attribute that specifies the invocation semantics,

• the type of the operation result,

• the operation name,

• a parameter list,

• optional exceptions, and

• optional context expressions.

The default operation attribute is synchronous invocation and one-waystands for asynchronous invocation. Each operation may return exactlyone value or must be void. The parameter list contains the direction, type,

56


Listing 3.1: IDL data type example

1 const long number = 017; // 017 == 0xF == 152 const float decimal = 15.7;3 const char letter = ’A’;4 const boolean isValid = TRUE;5 const octet anOctet = 0x55; // limited to 8 bit6 const string myName = "my name";7

8 union MyUnion switch( long ) {9 case 0 : boolean b; case 1 : char c; case 2 : octet o; case 3 : short s ;

10 };11

12 enum NotFoundReason { missing_node, not_context, not_object };13

14 typedef sequence <NameComponent> Key;15 typedef fixed<12,7> Fix;16 typedef long NumberList[100];17 typedef struct NC { MyString id; MyString kind; } NameComponent;

Listing 3.2: IDL structure example

1 module InheritanceExample {2 interface A { . . . };3

4 interface B : A { . . . };5 };

and name of each operation parameter (see Listing 3.3). The direction in-formation tells the direction in which the parameter is to be passed wherethe following directions are supported:

in to pass the parameter from client to server,

out to pass the parameter from server to client, and

inout to pass the parameter in both directions.

Listing 3.3: Structure of an IDL operation declaration

1 returnValue operationName( in Type1 par1, inout Type2 par2, out Type3 par3 )2 raises ( AnException )3 context ( "ContextInformation" );

57


Listing 3.4: IDL interface example

1 interface NamingContext {2 attribute string object_type;3 readonly attribute Key external_form_id;4

5 exception NotFound { NotFoundReason why; Name rest_of_name; };6

7 MyString bind( in Name n, inout Object obj, out Object myObj )8 raises ( NotFound )9 context ( "Hostname" );

10

11 oneway void rebind( in Name n, in Object obj );12 };

Exceptions are especially used to handle errors caused by the networkenvironment like connection failures. The context expression allows theclient to transfer context specific information, like security context inform-ation for the security service.

An example containing declarations of interfaces with operations andattributes is given in Listing 3.4. It was taken from the NamingService ofthe CORBAservices (OMG 1997).

3.6. Summary and Outlook

Summary

In this chapter first, the different diagram types of UML were shortly ex-plained. Afterwards, suitability of UML models for automatic test gener-ation and usage for test case specification were discussed. UML modelsuntil now are not suitable for automatic test generation because of short-comings in its semantics and missing features as described in section 3.2(Binder 2000).

Test case specification is possible wherefore MSCs, as substitute for se-quence diagrams, are best suitable from all UML diagrams. Some otherdiagram types, for instance usecase diagrams, can be mapped to MSCs asdiscussed in section 3.3 (Miga et al. 2001). In addition to MSCs, classdiagrams are used to provide static information used in MSCs. Therefore,more complete test suites can be specified.

Sequence diagrams are detailed by MSC which are partly introducedinto sequence diagrams of UML 2.0. MSC provides, for instance, descrip-tion of message- and procedure-based communication, usage of timer, in-

58


line expressions to describe, for instance, alternatives, and HMSCs to de-scribe sequences of MSC execution. The new data and time concept todescribe usage of an external data language and time dependencies wasnot detailed because it is not introduced into UML until now.

The IDL was introduced which permits the specification of softwareinterfaces. The interfaces are independent of the programming languageor the platform which is used and can be automatically generated fromUML class diagrams.

If TTCN-3 is used for testing systems with interfaces specified by IDL,these interface definitions can be used as ATSI. Therefore, the mappingsuggestion which will be given in chapter 5 can be used to generate thestatic ATS parts automatically. This would effect definitions like data typesand signatures for procedures. Hence, interface modifications could beseamlessly introduced into the static part of TTCN-3 test suites whichwould improve consistence and allow simplified test specification via UMLmodels or testing of CORBA-based systems.

Outlook

The progress of UML to UML 2.0 will enhance support for automatic testgeneration because of more semantics information and more expressivediagrams like sequence diagrams which are enhanced by MSC featuresand state diagrams wich are enhanced by SDL features. For instance, toolsupport for UML 2.0 is given by second generation of Telelogic TAUtools.

Furthermore, in conjunction with the new approach Model Driven Ar-chitecture (MDA) (OMG 2001a) the UML and XML Metadata Interchange(XMI) is used to specify systems where full automatic code generation,simulation, and validation gets possible. It is thought to use them for de-scribing standards, too (Koch 2001). MDA separates system specificationfrom implementation specification on a specific technology platform byspecifying, for instance, architectures for models and a set of guidelines tostructure specification by models.

To use MDA for specific application areas UML profiles may be defined.Thus, UTP gets introduced which will widen usage of UML for testing.Especially, in conjunction with the mapping of UTP to TTCN-3 as it willbe defined in ITU-T Recommendation Z.149. A case study can be seen inDai et al. (2004). Automatic code generation using MDA increases the de-mand for conformance testing, certification, and branding. Using TTCN-3in conjunction with eXtensible Markup Language (XML) is shown, for in-

59


stance, in Schieferdecker & Stepien (2003). Additionally, usage of IDL fordifferent application areas is detailed in section 5.7.

In particular, automatic test generation and full test specification can besimplified through better semantics, more expressive features, and combin-ation with TTCN-3. The approach described in this thesis is a first step inthis new direction but focusses more on test case specification instead of afull test suite.

60

4. Mapping of MSC to TTCN-3

CATG based on state space exploration, as described in section 2.3 onpage 14, generates frequently inefficient test cases. Therefore, it is desir-able to use, for instance, graphical test purposes, for CATG which are alsomore suitable for a test designer. Test case generation and specificationusing MSCs were formerly done for TTCN-2 by using MSC-96 and isprovided, for instance, with Autolink in the TAU tool set from Telelo-gic (see section 2.3 on page 15). Hence, a mapping from MSC to TTCN-3(see section 2.4) gets defined to allow definition of graphical test purposesfor TTCN-3, too (Ebner 2004).

The focus is on timed order of message exchanges and test suite detailsare hidden. This distinguishes this concept in contrary to UTP where a testsuite is represented in more detail. Thus, specification of scenario-basedtest cases gets simplified. Furthermore, usage of a given specification byMSCs or UML diagrams which can be converted into MSCs is possible. Asstated in section 3.4 the MSC-2000 is used as substitute for UML sequencecharts. UML activity diagrams can be converted to HMSC which is used todefine test execution order (see Figure 4.1). Thus, MSC is used to generateTTCN-3 test cases and control parts.

MSC is also used for real-time testing and MSC concepts have been usedto develop GFT and UTP. The introduction of new concepts for real-timetesting with TTCN-3 and MSC is discussed in Dai et al. (2002, 2003);Neukirchen (2004). The GFT in context of MSC and UML is discussed inSchieferdecker & Grabowski (2003). The deployment of UTP is detailedin Schieferdecker et al. (2003) where a UML-based specification of testdescriptions is explained.

The mapping starts with a description of the used concept to motivatethe following parts which are structured similar to the MSC specificationdocument (ITU-T 2001) to provide easy access to the mapping of eachMSC element. Therefore, mapping of the MSC documents and comments,basic MSCs, structural concepts, and HMSCs are explained. Finally, asummary and an outlook are given.

61


UML

Sequence Chart Activity Diagram

Basic MSC HMSC

TTCN-3Test Case

TTCN-3 ModuleControl Part

Test Suite

Figure 4.1.: Basic MSC to TTCN-3 mapping concept

4.1. Fundamental Concept

Contrary to the TTCN-3 presentation format GFT (ETSI 2002b) andUML test specification via UTP (Schieferdecker et al. 2003) which are in-spired by MSC the concept here uses MSC to manually specify test pur-poses and cases. However, the concept is also not using the full MSCsemantics because some restrictions and adaptations respectively have tobe done to permit test case specification via MSC. Thus, MSC semantics isoverwritten by an own MSC to TTCN-3 semantics which is as near as pos-sible to the MSC semantics without introducing new graphical elements.Hence, seamless use by test designer familiar with MSC is supported.

Requirements

There are some requirements which are desirable to provide good supportfor TTCN-3 with MSC and to widen usability and acceptance:

Structure It should be feasible to control the TTCN-3 test case generationprocess to get a desired test suite structure. For instance, the MSCdocument structure can be used.

Aliases Use of aliases is important to write easily test cases via MSCswherefore usage of TTCN-3 templates has to be supported.

Statements Support insertion of TTCN-3 statements (program code) inMSC, for instance, insertion of setverdict(pass) at the end of an MSCdiagram.

62


ISAP1SUT

syminres ISAP2

ICONreq

ICONind

ICONresp

ICONconf

msc Structure Example

Figure 4.2.: Basic instance structure to specify test cases via MSC

Defaults Usage of predefined TTCN-3 defaults must be possible.

Concurrency Support concurrent and non-concurrent TTCN-3 whereforenon-concurrent should be a special case of concurrent TTCN-3.

Basic Structure

In order to use MSC for generating TTCN-3 the test architecture and com-munication has to be mapped first (see subsection 2.4.4 on page 29 andsubsection 2.4.5 on page 31). Static information like types and data hasto be given by other sources as shown in chapter 5. Test architectureand communication is based on components and ports whereby ports arethe element which connects both together. Furthermore, usage of com-ponents would be too abstract for scenario-based testing. Therefore, MSCinstances are mapped to ports. At least the static MTC and SUT ports haveto be used to specify test cases (see Figure 4.2). Dynamic PTCs can be rep-resented by instance creation. In order to distinguish ports by componentsthe instance head provides the component name in addition. Hereby, anown test case for each component can be generated in case of concurrentTTCN. In case of non-concurrent TTCN usage of PTCs is forbidden andcomponent name MTC is optional and only test case(s) for the MTC aregenerated.

In case where an MSC is ambiguous in sense of a TTCN-3 test case sev-eral test cases will be generated to comply the ambiguities. Nevertheless,an ambiguous test case specification in sense of this concept cannot beseen as a test purpose in its proper meaning because traces have not to becompleted. Ambiguous test cases can appear by using sending messages infront of alternative inline expressions and must appear by using HMSCs.

63


Restrictions and Adaptations

As stated before, some restrictions and adaptations are made to use MSCin conjunction with TTCN-3:

Configuration file A configuration file has to provide the used data types,templates (constraints), and configuration information like defini-tion of ports and their types and components (for create, connect,visibility) which can be provided by a SDL or IDL specification, forinstance.

The configuration file has to be a correct TTCN-3 module. A ref-erence to the configuration file can be given via a text comment inthe MSC because the generated test case will be inside a TTCN-3module, too.

Synchronisation At the border of inline expressions synchronisation isalways assumed to prevent cases of interleave and to permit loopabortion in loop expressions. MSC references are synchronised percomponent.

Synchronise conditions and local synchronise rules will be used andhence, no global synchronisation and global references are available.

Message type In an inline expression the first message has to be type lim-ited to make sense in TTCN-3. Therefore, only receive messagesand receive statements respectively are permitted as first message inan alternative, optional, and exceptional inline expression.

4.2. MSC Documents and Comments

MSC documents are used to structure test cases in a TTCN-3 modulewherefore the MSC document name is used as module name and the ref-erenced MSCs are converted to appropriate test cases inside the module.The document relation is used to bind a configuration file to the MSCswhere static information are provided.

The three comment types note, comment, and text are used to insertTTCN-3 statements and comments. Notes occur only in the textual syn-tax and therefore, may be used in comment types comment or text toinsert TTCN-3 comments. Comments are associated with a symbol orcomment type text why they can be used to insert TTCN-3 statements at

64

4.3. Basic Message Sequence Charts

special positions. Text is used for global TTCN-3 comments and state-ments which have to be set at the beginning of the generated TTCN testcase. For instance, defaults can be activated in text comments.


The conversion concepts for basic MSC are given below. Instances, mes-sages, and control flow is discussed first and the ordering and synchron-isation of events gets explained afterwards. At the end the conversion ofenvironment and gates, actions, timers, and dynamic instances is detailed.

Each chart contains a chart name which gets the test case name whichmay include used parameters.

4.3.1. Instances, Messages, and Control Flow

Instances and communication by message exchange and procedure invoc-ation are the basic parts of MSCs. According to the concept mentioned be-fore instances are used as ports and PCO respectively where the corrspond-ing component is mentioned, too. Instance name is used as port name andinstance kind without denominator is used as corresponding componentname (see Figure 4.3).

The instance definition itself provides no further information but at-tached elements are considered to belong to the port or component re-spectively. Hence, attached messages and procedure invocations belongto the given port and all others to the component why all elements areput into the same component test case(s). The used port type like message,procedure, or mixed may be given in the instance name but is only necessaryif semantic checks will be done without further available configuration in-formation or because of consistency for test designer. The concrete portdefinitions are given by the separate static information in the configurationfile as also done for the component definition.

If no architecture information beside ports and SUT is given a heuristiccan be used or only a MTC is assumed. It is indicated which ports be-long to the SUT. Message interchange, where no SUT instance is involved,indicates use of a PTC as far as the MTC sends no message to itself. Forinstance, in case of concurrent TTCN-3 synchronisation between compon-ents is done via synchronisation coordination messages. Furthermore, testcases are focussed on communication with the SUT why SUT instances aremostly involved in message interchange. However, usage of such heuristicsis up to tool vendors because they have no influence to the mapping itself.

65


An MSC message and procedure consists of a relation between an out-put and input event from and to an environment or instance. These canbe matched to send and receive operations in TTCN-3. Output messageevents can only be matched to send and output procedure events to call,reply, or raise operations whereas input message events can be matched toreceive, trigger, and check and input procedure events to getcall, getreply,and catch operations. It is possible to provide a TTCN-3 statement at-tached to an event by a comment to force its conversion to a specificcommunication operation. The default conversion converts to send andreceive for messages and call and reply for procedures if a statement ismissing. Value assignments and optional parameters can also be providedin comments to a communication event. One-to-many connections are notsupported until now by MSC and therefore, are not considered here.

Procedure calls in TTCN-3 have a blocking characteristic to state whet-her test case execution is blocked or not until the call has returned by aresponse or exception. Thus, MSC asynchronous and synchronising callsare mapped to TTCN-3 non-blocking and blocking calls.

The message and procedure names represent either the used type (mes-sage type or procedure) or template (message or signature template). Incase of a template without parameters no parameter list is given. Oth-erwise, the parameter list is used to provide the necessary parameters.TTCN-3 templates and their arguments provide easier usage of comm-unciation operations because there are no further information necessary.Inline templates for matching receiving events can be used, too. Thus, testcases get more understandable and maintainable.

4.3.2. Ordering and Synchronisation

To specify and implement test case generation from MSC the specificationof the underlying event ordering is fundamental. Using MSC event order-ing implies generation of test cases for each possible trace through a chart.However, intention of using sequence diagrams by test designer directly iscontrol of generated test cases. Thus, a limited MSC event ordering getsused. In the following only non-concurrent TTCN-3 is mentioned to keepexplanation simpler. Concurrent TTCN-3 differs mainly in generation oftest cases for each component which can be easily adopted by consideringinvolved instances only (Grabowski et al. 1999).

Event ordering in MSC is defined by

• total ordering on instance axis,

66


ISAP1SUT

syminres ISAP2

ICONreq

ICONind

ICONresp

ICONconf

IDATreq(0)

IDATind(0)

Synchronisation

IDATreq(55)

IDATind(55)

IDISreq

IDISind

msc BaseExample testcase BaseExample() runs on syminres {ISAP1.send( ICONreq )ISAP2.receive( ICONind )ISAP2.send( ICONresp )ISAP1.receive( ICONconf )ISAP1.send( IDATreq ( 0 ) )ISAP2.receive( IDATind ( 0 ) )ISAP1.send( IDATreq ( 55 ) )ISAP2.receive( IDATind ( 55 ) )ISAP2.send( IDISreq )ISAP1.receive( IDISind )

}

(a) MSC (b) TTCN-3

Figure 4.3.: MSC to TTCN-3 base mapping

• partial ordering between instances,

• a general ordering mechanism, and

• coregions.

Total ordering on instance axis is also used because event order on a porthas to be ordered totally by default. If another behaviour is wished theordering has to be modified explicitly by using corresponding elements.Partial ordering between instances can enable several permitted traces ofa chart which prevents exact test case design because of unwished traces.Thus, partial ordering is limited by synchronisation points, send events areexecuted as early as possible, and graphical order is used to decide aboutused trace if necessary. Graphical order means ordering is given by theorder from left to right and top to bottom in the MSC until the end or asynchronisation point.

Synchronisation points are used to provide a well defined point whereall send and receive events have been executed. Event execution before isforced and no event after can be moved before a synchronisation point.Due to the limitation of the partial ordering between instances and thepreference of the graphical order the general ordering mechanism is notnecessary but can be used for additional, more precise, and explicit order

67


information. Coregions are used to override explicitly any ordering byall permutations of the involved events which is done by the interleavestatement in TTCN-3. If the above mentioned rules for ordering can bewiden by automatic detection of interleave cases like reception of twoconsecutive events at the SUT an interleave statement shall be used forit.

Synchronisation can be forced by using conditions (see Figure 4.3). Itis assumed around all inline expressions and actions. MSC references aresynchronised per component. Since synchronise conditions and local syn-chronise rules like described before are used, no global synchronisationand global references are available.

4.3.3. Miscellaneous

Mapping of environment, actions, conditions, timers, and dynamic in-stances gets described in the following.

Environment and Gates

Support of external message exchange can be designed similar to the nor-mal message exchange by handling the environment like another instance.Gates require no special mapping rules because they are only used for bet-ter organisation of charts.

Actions

An action describes an internal activity of an instance and hence, it can beused to insert comments and TTCN-3 statements directly into test casesdepending on an instance.

Conditions

Conditions are only used for synchronisation which requires coordinationmessages if concurrent TTCN-3 is used.

Timers and Time Constraints

Timers can be started and stopped according their position in the MSCand global timers are considered. Timer time out can be catched by usingthe default behaviour statement of TTCN-3 where the test case verdict can

68

4.4. Structural Concepts

be set to fail and a log message can be written. There is no stop after theverdict to allow ending in a defined state.

Instance Creation and Termination

Dynamic instances are mapped like static instances but are created andstarted only during test case execution and not at the begin of a test caselike it is done for MTC and SUT. However, dynamic instances make onlysense if a new component is used. Information for connecting and map-ping of ports to each other can be taken from exchanged messaged. In-stance termination is mapped to the stop component operation but canonly be inserted if no other port of the component is in use.


Conversion of coregions, references, instance decomposition, and inlineexpressions, which are all summarised as structural concepts in MSC, aredetailed now.

4.4.1. Coregions

Coregions are used to override explicitly the total ordering of an instanceaxis by unordered events. In sense of a test case description best mappingis done by using all permutations of the involved events which is done bythe interleave statement in TTCN-3, as well. This was mentioned earlierin subsection 4.3.2.

Usage of coregions is limited on message exchange among componentsand between SUT and a component. Overlapping of coregions on differ-ent instance axes for the same component has to be prevented. The firstevent must be always a receive event. In case of non-concurrent TTCN-3coregions are only used on SUT axes.

4.4.2. MSC References

MSC references provide usage to import other charts which easies decom-position and reuse. However, test cases cannot be decomposed into othertest cases and therefore, references are converted to function calls. Never-theless, test case decomposition is done by HMSCs which is described insection 4.5 on page 75. To allow correct behaviour of function calls by

69


references they have to be synchronised per test component. Several func-tion calls can be provided in one reference by usage of the seq operator forreferences.

The sequential MSC reference expression seq is used to call several func-tions in sequential order. The alternative and optional expression alt andopt is used to generate a test case for each possible alternative. Loopexpressions are converted according done for MSC inline expressions inHMSCs (see section 4.5).

4.4.3. Instance Decomposition

Instance decomposition is used to replace an instance axis by a detailedchart. The instance axis can be seen as the environment from the detailedchart. Therefore, instance decomposition has only to be resolved duringconversion wherefore no further special conversion concept is required.

4.4.4. Inline Expressions

In order to structure charts inline expressions are provided which allowalternatives, loops, and parallel execution.

An appropriate mapping requires synchronisation before and after eachinline expression to prevent cases of interleave which cannot be solvedeasily. In addition, handling concurrent TTCN-3 gets better. From MSCpoint of view events before and after an inline expression may influence theexpression behaviour but for test case design this behaviour is not wishedbecause it makes test case design more complicated by loosing controlabout the number of generated test cases. To provide a good mapping toTTCN-3 alternative and loop statements synchronisation is required, aswell. Especially, good support of loop expressions by using TTCN-3 loopstatements is also wished.

The inline expressions alternative, option, exception, and loop are de-tailed below. Inline expression parallel will not be mentioned becausethere is no appropriate mapping available.

Alternative

The alternative expression is directly mapped to the alternative behaviourstatement of TTCN-3. Therefore, the first element of each alternativepart has to be a reception statement according the specification of the altstatement (see subsection 2.4.6 on page 34). For each alternative of an

70


ISAP1SUT

syminres ISAP2

ICONreq

ICONind

ICONresp

ICONconf

IDATreq

IDATind

IDISind

ICONreq

ICONind

ICONresp

ICONconf

IDATreq

IDATind

alt

IDISreq

IDISind

msc Inline Alternative testcase Inline_Alternative () runs on syminres {ISAP1.send( ICONreq )ISAP2.receive( ICONind )ISAP2.send( ICONresp )ISAP1.receive( ICONconf )ISAP2.send( IDISreq )ISAP1.send( IDATreq )alt {

[] ISAP2.receive( IDATind ){}

[] ISAP1.receive( IDISind ){

ISAP1.send( ICONreq )ISAP2.receive( ICONind )ISAP2.send( ICONresp )ISAP1.receive( ICONconf )ISAP1.send( IDATreq )ISAP2.receive( IDATind )

}

}

ISAP2.send( IDISreq )ISAP1.receive( IDISind )

}

(a) MSC (b) TTCN-3

Figure 4.4.: MSC to TTCN-3 alternative mapping

alternative expression containing a send event as first event another testcase containing this alternative is generated. In worst case an own test casegets generated for each alternative. Of course, all events in alternatives arerestricted by the alt statement semantic (see Figure 4.4).

Optional

The optional expression can be seen as a special case of the alternativeexpression with an additional empty alternative part. The empty altern-ative part gets realised by an else guarded empty alternative part (see Fig-ure 4.5).

Exception

The exception expression is a special case of the alternative expressionwhere the last alternative part is the remainder of the MSC (see Figure 4.6).

71


ISAP1SUT

syminres ISAP2

ICONreq

IDISind

ICONreq

opt

IDISind

ICONreq

opt

ICONind

ICONresp

ICONconf

IDATreq

IDATind

msc Inline Optional testcase Inline_Optional () runs on syminres {ISAP1.send( ICONreq )alt {


ISAP1.send( ICONreq )}

[else ]{}

}

alt {[] ISAP1.receive( IDISind )

{ISAP1.send( ICONreq )

}

[else ]{}

}

ISAP2.receive( ICONind )ISAP2.send( ICONresp )ISAP1.receive( ICONconf )ISAP1.send( IDATreq )ISAP2.receive( IDATind )

}

(a) MSC (b) TTCN-3

Figure 4.5.: MSC to TTCN-3 optional mapping

Loop

The loop expression can be converted onto the for and while loop state-ments of TTCN-3 whereby infinite loops are best mapped to while loops(see Figure 4.7) and finite loops to for loops (see Figure 4.8). In contrary tothe alternative expression there is no special first event necessary. Instead,loop operations require an abortion criteria if lower and upper bound-ary are not equal. Equal boundaries impose exact number of loop passeswhere no abortion criteria is required. The abortion criteria from MSCpoint of view is the next receive event after the loop expression. There-fore, a receive message has to be given after each loop expression. Thereceive message gets checked inside the loop and concrete message con-sumption is done after loop execution.

72


ISAP1SUT

syminres ISAP2

ICONreq

ICONind

ICONresp

ICONconf

IDATreq

IDISind

IDISreq

IDISind

exc

IDATind

IDISreq

IDISind

msc Inline Exception testcase Inline_Exception () runs on syminres {ISAP1.send( ICONreq )ISAP2.receive( ICONind )ISAP2.send( ICONresp )ISAP1.receive( ICONconf )ISAP1.send( IDATreq )alt {


ISAP2.send( IDISreq )ISAP1.receive( IDISind )

}

[else ]{

ISAP2.receive( IDATind )ISAP2.send( IDISreq )ISAP1.receive( IDISind )

}}

}

(a) MSC (b) TTCN-3

Figure 4.6.: MSC to TTCN-3 exception mapping

ISAP1SUT

syminres ISAP2

ICONreq

IDISind

ICONreq

loop <1,3>

ICONind

ICONresp

ICONconf

msc Inline Loop 1 testcase Inline_Loop1() runs on syminres {ISAP2.send( ICONresp )ISAP1.send( ICONreq )while ( true ) {

alt {[] ISAP1.receive( IDISind )

{ISAP1.send( ICONreq )

}

[ iterator__1 >= 0] ISAP2.receive( ICONind ){

goto iterator__1_label}

}

iterator__1 := iterator__1 + 1;}

label iterator__1_label ;

ISAP1.receive( ICONconf )}

(a) MSC (b) TTCN-3

Figure 4.7.: MSC to TTCN-3 loop mapping 1

73


ISAP1SUT

syminres ISAP2

ICONreq

ICONind

ICONresp

ICONconf

IDATreq

IDATind

IDATreq

loop <1,3>

IDATind

msc Inline Loop 2 testcase Inline_Loop2() runs on syminres {ISAP1.send( ICONreq )ISAP2.receive( ICONind )ISAP2.send( ICONresp )ISAP1.receive( ICONconf )ISAP1.send( IDATreq )var integer iterator__1 := 0;for ( iterator__1 := 0; iterator__1 < 3;

iterator__1 := iterator__1 + 1 ) {alt {

[] ISAP2.receive( IDATind ){

ISAP1.send( IDATreq )}

[ iterator__1 >= 1] ISAP2.receive( IDATind ){

goto iterator__1_label}

}}label iterator__1_label ;

}

(a) MSC (b) TTCN-3

Figure 4.8.: MSC to TTCN-3 loop mapping 2

74

4.5. High-Level Message Sequence Charts

4.5. High-Level Message Sequence Charts

HMSCs are thought to describe possible combinations of MSCs. As men-tioned in section 3.3, UML activity diagrams are comparable with HMSCs.If they are seen as a kind of test suite decomposition they can be used tospecify test case execution order. Therefore, HMSCs are used to describetest case execution in the module control part of TTCN-3.

loop <10,10> ConnectionFailure

exc ConnectionSuccess

connected

TransmissionSuccess

ConnectionRelease

TransmissionFailure

disconnected

hmsc Mapping Example module {

function testExecution1() {verdicttype verdict ;integer i ;

for ( i :=10; i>0; i := i−1)execute ConnectionFailure ();

verdict = execute ConnectionSuccess();if ( verdict == false )

return ;

execute TransmissionSuccess ();execute ConnectionRelease();

}

function testExecution2() {verdicttype verdict ;integer i ;

for ( i :=10; i>0; i := i−1)execute ConnectionFailure ();

verdict = execute ConnectionSuccess();if ( verdict == false )

return ;

execute TransmissionFailure ();}

control {testExecution1 ();testExecution2 ();

}}

(a) HMSC (b) TTCN-3

Figure 4.9.: MSC to TTCN-3 mapping of HMSCs

MSC references including reference expression in HMSCs are conver-ted to corresponding test case execution calls and conditions and parallelframes are ignored. Each execution trace of a HMSC gets collected in anown function and all functions are called in the control part. No back-ward loops are allowed and there are only reference expression loops withsame finite lower and upper boundary allowed because data concept isnot introduced into UML and thus, not considered here. Alternative and

75


optional expressions lead to several traces only. Exception expressions areused to stop further trace execution if the test case fails. An example isgiven in Figure 4.9.


Summary

The chapter describes a mapping of MSC elements to TTCN-3 statementsin order to use UML sequence charts to define test cases and test caseexecution order in TTCN-3.

A conceptual mapping list is given in Table 4.1. Usage of commentsfor introducing direct TTCN-3 statements is used especially for TTCN-3defaults. One-to-many connections are not supported until now by MSCand therefore, are not considered. Apart from mapping chart elements theordering semantics of events had to be defined which differs from the ori-ginal semantics of MSC to be adequate for test specification. For instance,default synchronisation points were introduced for references and inlineexpressions.

Procedural communication is represented by flow control concept andmapped to call and getreply statements. However, alternative handlingof reception events by usage of alternative statement in a blocked callor a getreply statement is not supported until now. Data and time con-cepts of MSC-2000 have not been considered because they are not usedin UML 2.0, until now. Nevertheless, in context of TIMEDTTCN-3 it hasbeen shown that is possible to translate real-time information containedin MSC to TIMEDTTCN-3 (Dai et al. 2002, 2003; Grabowski 2002; Neuk-irchen 2004). Data support was not considered but can be easily used toenhance expressiveness and integration into TTCN-3.

A prototype was implemented to demonstrate feasibility. A first versionwas demonstrated on the TTCN-3 launching event in October 2000 atEuropean Telecommunications Standards Institute (ETSI). Most examplesin this chapter are converted with it. The prototype is based on the MSCparser developed at the Institute for Telematics, University Luebeck, Ger-many. The parser was implemented via ANother Tool for Language Re-cognition (ANTLR) which “is a language tool that provides a frameworkfor constructing recognizers, compilers, and translators from grammaticaldescriptions containing Java, C#, or C++ actions” (http://www.antlr.org).The MSC parser is used to build an Abstract Syntax Tree (AST) first whichwill be given to a tree parser. The tree parser parses the AST and generates

76

http://www.antlr.org


Table 4.1.: Conceptual list of MSC to TTCN-3 mapping

MSC TTCN-3

basic MSC test case

HMSC module control part

instance axis represents a port

note comment

comment insert statements directly at element position

text comment insert statements directly at beginning

chart name test case name

instance name port name

instance kind component name or SUT

message send or receive statement

flow control call or getreply statement

action insert statements directly

condition marks a synchronisation point

timer time start, stop, or timeout statement

instance creation create componenent

coregion interleave statement

reference function call or test case execution call (depending on MSC or HMSC)

alt,exc, or opt expression alt statement or function calls (depending on MSC or HMSC)

loop expression for or while statement

par expression not used

TTCN-3 code by using C++ inline code. The prototype shares code withthe IDL to TTCN-3 converter prototype mentioned in chapter 5.

Outlook

In further work the prototype should support concurrent TTCN-3 andHMSC which have been explained but not implemented until now. Adiscussion of concurrent TTCN-2 and MSC can be found in Koch (2001).Usage of TTCN-3 as data language has also to be considered. There isa prototype enhancement available which supports the time concept asdescribed by TIMEDTTCN-3 (Dai et al. 2003; Neukirchen 2004). Industrialinterest on the prototype has been shown.

77

5. Mapping of IDL to TTCN-3

In conjunction with UML-based manual test purpose specification, as de-scribed in chapter 4, the usage of static information like types and inter-faces for test specification was mentioned in section 3.3. The IDL (see sec-tion 3.5) was selected as intermediate format to provide a transition fromUML class diagrams to TTCN-3 (see section 2.4). IDL is well supportedby UML tools and widens applicability because of the wide usage of IDLor similarities with IDL. For instance, IDL is used in CORBA, is similarwith Simple Object Definition Language (SODL), and a mapping betweenWSDL and IDL exists.

Usage of IDL for TTCN-3 is described by a mapping of IDL elementsto corresponding TTCN-3 elements. Each mapping consists of rules tomap an IDL element and rules which have to be considered in the IDLdefinition to prevent conflicts with TTCN-3 rules. Furthermore, therecould be suggestions how to use a provided feature of IDL in TTCN-3.For example, the possibility of raising an exception and the exception typedefinition is defined in IDL but not catching of exceptions itself.

The mapping described here is based on some recent work in Ebner(2001a, b); Ebner et al. (2002); Yin (2001); Yin et al. (2001). and is alsosummarised as ETSI Technical Specification 102 219 (ETSI 2003).

Firstly, a description of the used approach gets described. Secondly, themapping of the lexical conventions and preprocessing is explained. After-wards, the mapping of the IDL structuring elements and types is detailed.Fifthly, communication declaration mapping is shown. Sixthly, mappingof names and scoping are described. Finally, a summary and an outlookare given.


Two different approaches can be followed: either using the implicit or theexplicit mapping. The implicit mapping makes use of the import mechan-ism of TTCN-3, denoted by the keywords language and import. It facil-itates the immediate use of data specified in other languages. Therefore,the definition of a specific data interface for each of these languages is re-quired. Currently, ASN.1 data can be used besides the native TTCN-3

79


types. The data interface for IDL types and values is still a topic of on-going research. The work presented here follows the approach of explicitmapping, that is IDL data are converted into appropriate TTCN-3 data.Only those TTCN-3 data are used further in the test specification.

There are former mappings for TTCN-2, but TTCN-3 provides newfeatures as stated before (Li 1998; Mednonogov 2000; Mednonogov et al.2000; Schieferdecker et al. 1998). The old mapping of IDL to TTCN-2has to be redesigned to make use of these new features. It was inten-ded to describe a mapping which is independent of implementation detailswherewith it can be used in general. For instance, in conjunction withCORBA it is assumed that a CORBA/TTCN-3 gateway executes the con-crete mapping between the TTCN-3 test suite and the CORBA-based SUT.Furthermore, it was not intended to map IDL to ASN.1 data as it was usedin Mednonogov (2000); Mednonogov et al. (2000).

5.2. Lexical Conventions and Preprocessing

The lexical conventions of IDL define comment, identifier, keyword, andliteral conventions which are described below. Thereafter, some commentsto the preprocessing support of IDL are given.

Comments

Comments can be defined in IDL and TTCN-3 by using the pair “/*” and“*/” for comment blocks or “//” for end of line comments like defined inISO C++ (ISO/IEC 1998c).

Identifiers

Identifiers in IDL and TTCN-3 consist of alphabetic, digit, and underscorecharacters where the first character must be an alphabetic character and allcharacters are significant. However, there is no case distinction in IDL butthe spelling has to be consistent throughout the whole definition. TTCN-3uses case sensitive identifiers and therefore, the IDL rule defines a subsetof the TTCN-3 rule.

Keywords

It has to be made sure that no TTCN-3 keywords (see ETSI 2002a, ap-pendix A.1.5) are used as identifiers in the IDL definition if a seamless

80

5.2. Lexical Conventions and Preprocessing

Table 5.1.: IDL to TTCN-3 literal mapping

Literal IDL Convention TTCN-3 Convention

Integer no "0" as first digit no "0" as first digit

Octet "0" as first digit ’FF96’O1

Hex "0X" or "0x" as first digits ’AB01D’H

Floating 1222.44E5 (Base 10) 1222.44E5 (Base 10)

Char ’t’ "t"

Boolean TRUE, FALSE true, false

String "text" "text"

Wide string "text" "text"

Fixed point 12.34D 12.34

identifier mapping is wished. However, identifiers can be renamed, forexample, by appending a special prefix or suffix in case of a conflict withkeywords in TTCN-3. Concrete identifier mapping is left to tool vendors.

Literals

The definition of literals differ slightly between IDL and TTCN-3 whysome changes have to be made. In Table 5.1 a mapping for each lit-eral type is given. IDL uses the ISO Latin-1 character set for string andwide string literals and TTCN-3 uses ISO/IEC 646 for string literals andISO/IEC 10646 for wide string literals (ISO/IEC 1990, 1993, 1998a).

Preprocessing

IDL preprocessing is defined by the ISO C++ standard (ISO/IEC 1998c).TTCN-3 does not support preprocessing wherefore only the include state-ment could be supported directly. The include preprocessor statement ofIDL could be mapped onto the import statement of TTCN-3 to use defin-itions from other files. Furthermore, users could use IDL definitions byimporting it and using the language option as shown here

TTCN-3

import all from IDLSpecification language "IDL";

1Octet literals require an even number of hexadecimal digits as given by the octetstring defin-ition.

81


However, this is not always possible because import allows only importof types if the module is written in another language as TTCN-3 (ETSI2002a, section 7.5.10). This would prevent, for instance, use of constants.Nevertheless, because of providing only an explicit mapping the importmechanism is not supported. Thus, it has to be rolled out.

All other preprocessor statements, which are mostly text replacements,are not mapped to TTCN-3 because the IDL specification should be usedafter preprocessing it.

5.3. Structural Elements

IDL specifications consist of type, constant, exception, interface, mod-ule, and value declarations. Beside basic and constructed data types IDLprovides the object-oriented types interface and valuetype. This object-oriented types cannot be mapped straight forward because they containstructural information which have to be considered in the TTCN-3 con-figuration architecture.

The mappings of modules, interfaces, values, and constants are de-scribed now. The data type and exception mappings as well as the bodiesof interfaces are described later.

5.3.1. Module Declaration

IDL uses modules as main grouping and scoping unit. TTCN-2 mappingsuse modules to define nested test groups whereas TTCN-3 owns an ownmodule concept. For this, the module concept of TTCN-3 is used.

IDL

module identifier { body }

TTCN-3

module identifier { body }

5.3.2. Interface Declaration

Interfaces describe objects with all their access methods by using opera-tions and attributes. Additionally, interfaces can contain local type defin-itions like exceptions and constants which can be used by its operationsand attributes. A mapping for interfaces should provide a similar scop-ing and grouping mechanism as well as an appropriate handling underTTCN-3 as in IDL. Since lacking an object model in TTCN-3, the groupconstruct is used to retain the scoping information and interfaces have

82

5.3. Structural Elements

to be flattened. Hence, import of single interface definitions from othermodules via the importing group statement gets possible. Using modulewould not be appropriate because the module concept from IDL has to beconsidered as well as the module concept of TTCN-3.

The test configuration concept of TTCN-3 requires use of componentand port respectively PCO. According to the TTCN-2 mappings, an in-terface is best mapped to a PCO. Hence, they are mapped to ports inTTCN-3. They are associated with signatures converted from attributesand operations of the interface (see subsection 5.5.1). Hereby, compon-ents are used as a collection of interfaces respectively objects.

IDL

interface NamingContext { body }

TTCN-3

group NamingContextInterface {type port NamingContext

procedure { ... }}

address NamingContextType ?????

For the specification of object interfaces IDL type Object is used. Theinterface types for application objects inherit from Object. Interface defin-itions contain structural information which have to be considered in theTTCN-3 configuration architecture. Furthermore, object references asso-ciated with instances of interface implementations can be passed over op-eration invocations. Since the port reference cannot be used as operationparameter or inside signature definitions respectively, another mechanismhas to be used to represent the interface reference. TTCN-2 mappings usestringified Interoperable Object References (IORs) or integers. TTCN-3does not provide special support for it but there is an address type avail-able which is used to address entities in the SUT. Therefore, Object isgenerally mapped to address in TTCN-3 and each interface gets an addresstype declared in the data part.

Interfaces can make use of inheritance from other interfaces which canalso be abstract. TTCN-3 provides no object-oriented concepts whichprovide inheritance wherefore all inherited elements have to be rolled out.Thus, they have to be handled as defined in the interface itself. In case ofmultiple inheritance elements have to be inherited only once.

Forward references of interfaces respectively ports can also be used inTTCN-3. Local interfaces require no further special mapping whereforethey can be treated as normal interfaces.

One interface can be instantiated many times but it can only be executed

83


properly if the corresponding port is connected to a component. There-fore, whenever a component gets created all corresponding ports respect-ively interfaces respectively objects are instantiated, too. Furthermore, it isnot possible to dynamically change the number of objects for a componentwherefore a new component has to be created. The instantiation locationdepends on the component which has to be matched properly by the testsystem. A further discussion of this problem can be found in the TTCN-2mappings (Mednonogov 2000; Mednonogov et al. 2000).

It does not make a difference for the mapping if requested1 or provided2

interfaces are required by the test system and SUT. Hence, TTCN-3 canbe used on client and server side without modifications to the mappingrules.

The concrete mapping of interface operations, attributes, and excep-tions are described in section 5.5. A summary of interface mapping inclus-ive operation, attribute, and exception mapping can be found in Table 5.7on page 102. General type mapping gets detailed in section 5.4 on page 85and constant mappings are described in subsection 5.3.4 on page 85.

5.3.3. Value Declaration

The type valuetype is local like a struct but contains also operations andattributes and provides inheritance like by interface (OMG 2001b, chapter5). If valuetype is used as parameter it will be passed as object-by-valuewherefore it can be seen as an interface which is passed by value. In con-trary to type interface, the IDL type valuetype has local operations thatare not used outside the object, and are therefore not relevant from thefunctional testing point of view. However, since the public attributes ofvaluetype instances are used to communicate object states, we suggest tomap the IDL valuetype types to record types in TTCN-3. Inheritance istreated by rolling it out as it is also defined for interfaces and given oper-ations are mapped to external functions. If there is only one variable forvaluetype, it can be mapped like given by the type mapping with a specialattribute, the variant attribute, for this type as described in section 5.6 onpage 102. Type valuetype was not mentioned in the TTCN-2 mappings.

The following example shows how to map valuetype and were used from(OMG 2001b, section 5.3, section 5.2.5.2).

1test system requires interface which is provided by SUT2test systems provides interface which is required by SUT

84

5.4. Data Types

IDL

valuetype StringValue string ;

valuetype EmployeeRecord {private string name;private string email;private string SSN;

factory init (in string name,in string SSN

);

};

TTCN-3

type iso8859string StringValue with {encode "IDL:valuetype and IDL:string"}

group EmployeeRecordValuetype {type record EmployeeRecord {

iso8859string name,iso8859string email,iso8859string SSN

}

external function EmployeeRecord_init(iso8859string name,iso8859string SSN );

}

It is interesting to remark that there is no language mapping definedto the non object-oriented language C and there is no intention to do so.Furthermore, support of type valuetype by the only existing ORB using C,namely ORBit, is not done or only for special cases. It is not intended toadd better support because there is no user requirement for it.

5.3.4. Constant Declaration

Constant declarations can be easily converted to TTCN-3 by use of literal(see Table 5.1) and operator mapping for floating-point and integer values(see Table 5.2).

IDL

const long number = 017; // 017 == 0xF == 15const long size = ( ( number << 3 ) % 0x1F ) & 0123;

TTCN-3

const long number := ’17’O;const long size := ( ( number << 3 ) mod ’1F’H ) and4b ’0123’O;

5.4. Data Types

IDL provides type declarations for constant (see subsection 5.3.4), ba-sic, constructor, template, and complex data types. Beside these datatypes IDL provides the object-oriented types interface (see subsection 5.3.2)

85


Table 5.2.: IDL and TTCN-3 operators for constant expressions

Operator IDL TTCN-3

Unary floating-point

positive + +

negative − −

Binary floating-point

addition + +

subtraction − −

multiplication ∗ ∗division / /

Unary integer

positive + +

negative − −

bit-complement ~ not4b

Operator IDL TTCN-3

Binary integer

addition + +

subtraction − −

multiplication ∗ ∗division / /

modulo % mod

shift left << <<

shift right >> >>

bitwise and & and4b

bitwise or | or4b

bitwise xor ˆ xor4b

and valuetype (see subsection 5.3.3) which have been discussed before.This object-oriented types cannot be mapped straight forward becausethey contain structural information which have to be considered in theTTCN-3 configuration architecture.

TTCN-3 provides more predefined types than TTCN-2, for which abetter mapping can be constructed. Nevertheless, the fixed type and theconstructed types union and any have required special treatment to getmapped properly.

A construct for naming data types and defining new types by using thekeyword typedef is provided by IDL. This can be done under TTCN-3 viathe keyword type, too.

Type Extension

To enhance readability and to provide a clear distinction, mapped IDLdata types under TTCN-3 may get the prefix IDL. Additionally, to getthe same semantic meaning under TTCN-3 as given by IDL, the typesget a variant attribute containing the source IDL type name. Therefore,a compiler or interpreter can detect the IDL dependency and can reactaccordingly like executing semantic checks. This includes encoding, too.This feature provides a flexible way of extending the TTCN-3 type system

86

5.4. Data Types

and was among others introduced to simplify the IDL mapping. Use ofthe variant attribute is discussed further in section 5.6 on page 102.

Furthermore, based on the above discussion a library of useful types(see Table 2.2 on page 26) was introduced into TTCN-3 (ETSI 2002a,appendix E), too. For instance, the IDL float types float and double havea range limitation whereas the TTCN-3 float type has no such restriction.Thus, a correct mapping would be difficult but the type system extensionsolves this problem. The same can be done for the integer types as shownbelow.

TTCN-3

type integer IDLshort with { variant "IDL:short FORMAL/01−12−01 v2.6" };type float IDLdouble with { variant "IDL:double FORMAL/01−12−01 v2.6" };

The data type mapping will be shown in the following subsections. Inorder to focus on the important aspects of a mapping and to preservereadability of code examples the variant attribute will be omitted.

5.4.1. Basic Types

Mapping IDL basic data types to TTCN-3 data types is straight forwardbecause they are similar to ASN.1 data types which are used as data typebase in TTCN-3, too (ITU-T 1997b; Open Group 2000). For example, theboolean and enumeration types are identical in IDL and TTCN-3. Never-theless, TTCN-3 provides more predefined types than TTCN-2 whereforea better mapping can be provided. Their mapping is detailed below andsummarised in Table 5.3 on page 91.

Integer and Floating-Point Types

All IDL integer and floating point types can be mapped to the TTCN-3integer and floating point types which have no size limitations. To get abetter corresponding for integers the range limitation according to the IDLspecification is used to define the IDL types in TTCN-3 more closer.

TTCN-3

type integer IDLShort ( −32768 .. 32767 );type integer IDLLong ( −2147483648 .. 2147483647 );type integer IDLLongLong ( −9223372036854775808 .. 9223372036854775807 );

type integer IDLUnsignedShort ( 0 .. 65535 );type integer IDLUnsignedLong ( 0 .. 4294967295 );type integer IDLUnsignedLongLong ( 0 .. 18446744073709551615 );

87


TTCN-2 has no float type wherefore floats could only be mapped ontothe ASN.1 real type. In TTCN-3 there is now an unlimited float typeavailable where float, double, and long double from IDL can be mappedon. However, there is still no range limitation available wherefore therange limitations have to be kept in mind. Thus, the variant attribute iselementary for mapping float types.

TTCN-3

type float IDLfloat with { variant "IEEE754 float" };type float IDLdouble with { variant "IEEE754 double" };type float IDLlongdouble with { variant "IEEE754 extended double" };

Because of this mapping the types are now available as useful types inTTCN-3 (ETSI 2002a, appendix E). The available integer types includ-ing their unsigned types are byte, short, long, and longlong and the floattypes are IEEE754float, IEEE754double, IEEE754extfloat, and IEEE754extdouble(see Table 2.2 on page 26). In the remainder the useful types are preferred.

Char and Wide Char Type

The IDL types char and wchar represent a single and wide character.3

TTCN-3 introduces the character types char and universal char whereforeIDL char and wchar can now be mapped properly on it. However, TTCN-3uses ISO/IEC 646 as character set for type char and ISO/IEC 10646 fortype universal char. Therefore, the IDL specification has to be limited toISO/IEC 646 respectively ISO/IEC 10646 or an appropriate conversionhas to be used (ISO/IEC 1990, 1993).

IDL

const char letter = ’A’;const wchar wideLetter = ’A’;

TTCN-3

const char letter := "A";const universal char wideLetter := "A";

Boolean Type

The IDL boolean type can be mapped directly to the TTCN-3 boolean type.

IDL

const boolean isValid = TRUE;

TTCN-3

const boolean isValid = true ;

3Any character set can be used for type wide char

88

5.4. Data Types

Octet Type

Type octet, an 8-bit quantity, is not mapped onto an integer type becauseit has the special feature that it will not change its internal ordering iftransfered between different system architectures. To represent it octet ismapped to octetstring.

IDL

const octet data = 0x55;

TTCN-3

const octetstring data = ‘‘55 ’ ’H

Any Type

In IDL it is possible to represent each possible IDL type with the anytype. There was no corresponding type in TTCN-3 available but based onthe following discussion an anytype was introduced into TTCN-3 (ETSI2002a, section 6.4). The TTCN-3 anytype is a shorthand for the union ofall known types in a TTCN-3 module.

One possible way is to use an union type to store all possible data types.The union type comprises all required types whereas these types have tobe known in advance. In order to avoid this restriction an union typefor all possible types in TTCN-3 used by the IDL mapping rules couldbe defined. However, it is only possible to use basic data types and welldefined constructed types wherefore no generic constructed types for set,record, union, etc. are supported. For instance, it is not possible to provideentries for all possible kinds of type set by using a generic set type. Hence,the user could define his own restricted any type in TTCN-3 by using aunion type containing only all possible types of the concrete applicationand not all thinkable types. This new any type has to be mapped to a fullany type by the test system. However, this requires a careful handling ofany types because some type definitions could be missing.

The mapping for TTCN-2 is bound to ASN.1 and therefore, it encoun-ters problems in distinguishing types which are mapped onto the sameASN.1 type (Mednonogov et al. 2000). There is no support of the anytype given but the use of the design pattern decorator is suggested if anytype is used. Another mapping provides only basic types for the any typeand leaves structured types open for further study (Li et al. 1999). Theuse of type variant as described on page 86 is not appropriate to solve theany type problem, neither. This is because of the TTCN-3 type handlingwhich makes it impossible to handle types which are not known before-

89


hand. CORBA provides use of a dynamic management of any values butit is not appropriate to use this concept for a mapping of the any type herebecause it would not be a general mapping (OMG 2001b, chapter 9).

Since data types used by the test system are usually already known atcompile time as it is now the case in TTCN-3, it is suggested to use anunion type for data that are communicated to/over the SUT by the IDL anytype. The union type must cover all data types, either basic or derived, thatare converted from the IDL specification used by the test system. An anytype for basic types could look like the one below where the type kind isstored in a separate variable.

TTCN-3 helper data type for IDL any type(1)

type record IDLAny {IDLTCKind kind,IDLAnyValueHelper value_ }

type union IDLAnyValueHelper {short short_,long long_,longlong longLong_,unsignedshort ushort_,unsignedlong ulong_,unsignedlonglong ulongLong_,

IEEE754float float_ ,IEEE754double double_,IEEE754extdouble longdouble_,

octetstring octet_,boolean boolean_,

char char_,universal char wchar_}

TTCN-3 helper data type for IDL any type(2)

type enumerated IDLTCKind {tk_null , tk_void,

tk_short , tk_ushort,tk_long, tk_ulong,tk_longlong, tk_ulonglong,

tk_float , tk_double, tk_longdouble,

tk_char, tk_wchar,tk_string , tk_wstring,

tk_octet , tk_boolean,tk_any, tk_objref ,

tk_struct , tk_union, tk_sequence,tk_enum, tk_array, tk_fixed

tk_alias , tk_except, tk_TypeCode,tk_Principal , tk_value, tk_value_box,tk_native , tk_none, tk_abstract_interface}

However, using any in an interface can nowadays be seen as a gap in agood system and interface specification. Thus, use of the any type shouldbe prevented what is also done in ASN.1 (ITU-T 1997b, appendix E.3).Therefore, the any type should not occur because, if tests via TTCN-3 areexecuted, the interfaces should be quite stable without use of the any type.Nevertheless, there are scenarios where the any type has to be used. Aquite common example is an application with a graphical user interfacewhich forwards data without looking into it.

90

5.4. Data Types

Table 5.3.: IDL to TTCN-3 mapping for basic types

IDL TTCN-2/ASN.1 TTCN-3

short, long, longlong INTEGER integer with range limitation

float, double, long double — float

boolean BOOLEAN boolean

octet OCTET STRING octetstring

char GraphicString,IA5String(SIZE(1))

char

wchar GraphicString, BMP-String(SIZE(1))

universal char

any CHOICE anytype (respectively union)

The basic type mappings are summarised in Table 5.3.

5.4.2. Constructed Types

IDL provides the three constructed types struct, union, and enum. Recurs-ive construction of types is only permitted with the sequence template type(see section 5.4.3).

There is no fundamental difference between mapping to TTCN-2 andTTCN-3 for most constructed types given because the new data types inTTCN-3 are directly introduced from ASN.1. Hence, only a closer map-ping to this new data types gets necessary. This concerns, for example,sequence, sequence of, enumerated, and choice which are used as record,record of, enumeration, and union. Hence, TTCN-2 mapping can mostlybe used for TTCN-3. Their mapping is detailed below and summarised inTable 5.4 on page 93.

Struct

Type struct is used to collect data in one place. Because of the importanceof ordering inside struct, it is always mapped to ASN.1 sequence. Thisordering is until now not mentioned in the IDL specification but it is in-directly mentioned in the CORBA standard, for instance, in the InternetInter-ORB Protocol (I IOP) specification and type code specification (OMG2001b, chapter 15). Therefore, mapping onto the new data type record inTTCN-3 is used.

91


IDL

typedef struct NC {string id ;string kind;

} NameComponent;

TTCN-3

type record NameComponent {string id ,string kind

}

Discriminated Union

Unions can store different types in one place but only one at the same time.In IDL, unions are discriminated to determine the actual type. Therefore,a record type is used, which contains two members. The first one storesthe discriminator information using an enumeration type. The secondmember is a TTCN-3 union type whose members are defined according tothe specified IDL union members.

IDL

union MyUnion switch( long ) {case 0 : boolean b;case 1 : char c;case 2 : octet o;case 3 : short s ;

};

TTCN-3

type union MyUnionType {boolean b, iso8859string c,octetstring o, short s }

type enumerated MyUnionEnumType {boolean_b, iso8859string_c,octetstring_o , short_s }

type record MyUnion {MyUnionEnumType kind,MyUnionType value_ }

Enumerations

In both languages enumerations can be used on the same way.

IDL

enum NotFoundReason {missing_node,not_context,not_object

};

TTCN-3

type enumerated NotFoundReason {missing_node,not_context,not_object

}

The constructed type mappings are summarised in Table 5.4.

92

5.4. Data Types

Table 5.4.: IDL to TTCN-3 mapping for constructed types


struct SEQUENCE record

enum ENUMERATED enumerated

union SEQUENCE record with union and enumerated

5.4.3. Template Types

IDL supports the template types sequence, string, wide string, and fixedtype. Their mapping is detailed below and summarised in Table 5.5 onpage 95.

Sequence

IDL sequence is used to provide support for one-dimensional arrays with afixed maximum size and a defined length. In contradiction to fixed arrays(see subsection 5.4.4 on page 95) only the valid sequence entries will betransmitted and the empty entries will not. Therefore, use of unboundedsequences is also possible. This makes a mapping onto arrays in TTCN-3impossible wherefore only set of and record of are available. To keep theordering of sequences the type record of has to be chosen to provide anappropriate mapping to TTCN-3.

IDL

typedef sequence<NameComponent> Name;

TTCN-3

type record of NameComponent Name;

String and Wstring

Types string and wstring are sequences of char and wchar. In TTCN-2, sev-eral different predefined character string types were defined which are allreplaced in TTCN-3 by the two types charstring and universal charstring.As character encoding charstring uses ISO/IEC 646 and universal charstringuses ISO/IEC 10646. Since the introduction of useful types the charstringmapping can be more exact by using useful type iso8859string (see Table 2.2on page 26). Therefore, string and wstring are mapped to iso8859string anduniversal charstring.

93


IDL

const string name = "My String";const wstring wideName = "My String";

TTCN-3

const iso8859string name := "My String";const universal charstring

wideName := "My String";

Fixed Type

The fixed type represents a fixed-point decimal number. There was nocorresponding type in TTCN-3 available but based on the following dis-cussion an IDLfixed useful type was introduced into TTCN-3 (ETSI 2002a,appendix E.2.3.0).

If we use a float with an extension attribute containing the digit andscale the user cannot use this information in his program. Since the sim-ilarities between TTCN-3 and C the solution of the C language mappingof IDL (OMG 1999, section 1.14) is used. It maps the type fixed to atype struct which stores the number in a char array and the digit and scalenumber in extra variables. In TTCN-3, this can be realised by a record con-taining a charstring to store the number, and two integers for the digit andscale. Hence, the user can access scale and digit, too. A record is preferredagainst a set because of the initialiser notation for records which makesthe use of fixed types under TTCN-3 more convenient. See the definitionof IDLUnsignedShort and IDLShort on page 88.

IDL

typedef fixed<12,7> Fix;

TTCN-3

type record IDLFixed {IDLUnsignedShort digits,IDLShort scale ,charstring value_

}

var IDLfixed fix :={ 12, 7, "12345.1234567" };

The template type mappings are summarised in Table 5.5.

5.4.4. Complex Types

The last kind of type declarators are the complex types array and native.Their mapping is detailed below and summarised in Table 5.6 on page 95.

1Mapping of this type was not considered.

94

5.4. Data Types

Table 5.5.: IDL to TTCN-3 mapping for template types


sequence SEQUENCE OF record of

string GraphicString, iso8859string

IA5String

wstring GraphicString, universal charstring

BMPString

fixed —1 record

Arrays

IDL array can be mapped directly to the TTCN-3 array type because theyprovide the same functionality.

IDL

typedef long NumberList[100];

TTCN-3

var long NumberList[100];

Native Types

The native type is used to allow implementation dependent types. TTCN-3provides the type address to address entitities inside a SUT. Hence, addresscan be used for mapping of native and concrete implementation is left tothe user. However, this type should not be used in service and applicationinterfaces. It is mainly designed for internal use in CORBA itself.

IDL

native MyNativeVariable;

TTCN-3

address MyNativeVariable;

The complex type mappings are summarised in Table 5.6.

Table 5.6.: IDL to TTCN-3 mapping for complex types


array SEQUENCE SIZE(n) OF array

native —1 address

1Mapping of this type was not considered.

95


5.5. Communication Declaration

The main purpose of IDL is the description of object interfaces where-fore the provided attributes and methods, in IDL called operations, aredescribed. Each operation may raise exceptions. Operations, attributes,and exceptions are the only way provided by IDL to communicate withan object. Thus, operations and attributes can only be defined in inter-faces. Exceptions can only be used by operations but can also be definedoutside of interfaces. Their mapping is detailed below and summarised inTable 5.7 on page 102.

5.5.1. Operations

Apart from attributes, operations are the main part of interface definitionsin IDL (see subsection 5.3.2) and are used, for instance, in the CORBAscheme as procedures which can be called by clients. Procedure calls ingeneral are supported by TTCN-3 by means of synchronous communic-ation operations which are used in combination with ports. In TTCN-3procedures are defined by signatures (see subsection 2.4.4). Operationsunder IDL consist of an invocation semantics by an operation attribute,return results, an identifier, a parameter list, an optional exception ex-pression, and an optional context expression. The mapping of all thisparts to TTCN-3 will be described now.

Operation Attribute

IDL supports an optional oneway attribute for operations which impliesbest-effort invocation semantics without a guarantee of delivery but witha most-once invocation semantics. Oneway operations have to provide noout parameters and the return type void. Furthermore, no raise expressionsare allowed but standard exceptions can still be raised. If no attribute isgiven the invocation semantics is at-most-once in case of an exception andexactly-once if it returns successfully.

Messages or procedures could be used for oneway operations becauseboth would be a valid mapping from IDL perspective. However, the use ofprocedure-based ports for oneway operations is recommended because theIDL specification does not guarantee that oneway calls are non-blockingor asynchronous. Furthermore, CORBA implements oneway operationsby synchronous communication, too.

96


Hence, best mapping of both kind of operations is given by use of syn-chronous communication wherefore no distinction for oneway operationsgets necessary. However, it is not the same for CORBA wherefore theIDL information in the interface repository could be used to detect one-way operations and to handle them appropriate. However, this is only forCORBA-based SUTs possible. Furthermore, the variant attribute could beused to mark oneway operations which should be preferred.

By the way, CORBA supports also the Asynchronous Method Invoca-tion (AMI) to provide non-blocking requests. This is realised by a client-side mapping which requires no or only small server side modifications.Therefore, special methods will be produced in addition to provide thenew functionality. This new methods still use the synchronous communic-ation mechanism wherefore no modifications in IDL have been necessary.However, there was a new IDL introduced called implied IDL which isgenerated from the IDL specification with the additional operations forthe client side and is used to generate the client implementation stubs.

Introduction of AMI leads to the fact that a client is also a server ifthe callback model is used. This model requires a reply handler which isinvoked by the server. Hence, mapping of IDL to TTCN-3 gets necessaryfrom client and server perspective. Therefore, operation exceptions, asdefined in subsection 5.5.3, can also be raised by the tester.

To sum up, oneway operations are best mapped to procedures andmarked as oneway operation by a variant attribute. Based on the discus-sion above the noblock attribute for procedures has been introduced intoTTCN-3 (ETSI 2002a, section 13.1) to support non-blocking procedurecalls. Use of non-blocking or blocking procedures for oneway operationsis left to the user.

Parameter Declarations

The parameter attributes in, inout, and out describe the transmission dir-ection of parameters and can be mapped directly to the communicationparameter attributes in TTCN-3 because they have exactly the same se-mantics.

The return, out, and inout parameters of operations have to be catched bya getreply statement in TTCN-3 which should be given in the call context.

97


Raises Expressions

A raise expression specifies all exceptions which can be thrown by an op-eration. It can be mapped directly to TTCN-3 because it can be indicatedby the procedure signature definition by specifying an exception. Never-theless, each operation can trigger a standard exception.

Context Expressions

A context expression provides access to local properties of the called oper-ation. These properties consist of a name and a string value. The contextexpression can be mapped by redefining the operation with the contextparameters included in the operation parameters (OMG 2001b, section4.6). This is done in a TTCN-2 mapping by introducing an additionalarray parameter (Mednonogov 2000; Mednonogov et al. 2000). The ad-ditional parameter should be of type array containing a type record for eachcontext parameter. The record itself contains two variables of type stringfor the context name and value.

An example mapping is demonstrated below. The TTCN-3 mappingpart is divided into an operation definition and usage part. The defini-tion part illustrates the mapping and the usage part is only introduced todemonstrate the usefulness of the mapping.

IDL

// not found exception is defined in section ‘‘ exception declaration ’’

string remoteProc1( in long Par11, out long Par12, inout string name1 )raises ( NotFound ) context( ‘‘ MyContext1’’ );

// oneway procedure: no return value and no inout or out allowed!!!oneway void remoteProc2( in long Par21, in long Par22, in string name2 );

TTCN-3

Operation definition

type record IDLContextElement {iso8859string name,iso8859string value_

}

type record of IDLContextElement IDLContext;

signature RemoteProcSignature1(in long Par11, out long Par12,

98


inout iso8859string name1, in IDLContext context )return iso8859stringexception( NotFoundException );

signature RemoteProcSignature2(in long Par21, in long Par22, in iso8859string name2 )

with { variant "IDL:oneway FORMAL/01−12−01 v.2.6" };

type port RemoteProcPort procedure {out RemoteProcSignature1;out RemoteProcSignature2

}

type component SUT {port RemoteProcPort PCO

}

Operation usage

// not found exception is defined in section ‘‘ exception declaration ’’

var IDLContextElement contextElement := {name := "MyContext1", value_ := "MyContextValue" };

var IDLContext idlContext := { contextElement };

template RemoteProcSignature1 RemoteProcTemplate1 := {Par11 := 0,Par12 := 1,name1 := "my name",context := idlContext

}

template RemoteProcSignature2 RemoteProcTemplate2 := {Par21 := 2,Par22 := 3,name2 := "my other name"

}

var SUT myCorbaSystem := SUT.create;connect(self :myPCO, MyCorbaSystem:PCO);myCorbaSystem.start;

myPCO.call( RemoteProcTemplate1 ) {[] myPCO.getreply(RemoteProcSignature1:{−,*,*} value *) −> value MyResult1

param(MyPar12, MyName1) sender MySender1 {}[] myPCO.catch( RemoteProcSignature1,

MyNotFoundExceptionTemplate ) {verdict .set( fail );stop;

}}

99


myPCO.call( RemoteProcTemplate2 );

// raising an exception can be done on this way but it is not used// because only the SUT should raise this exception!!!var NotFoundException myNotFoundException := {why := missing_node,rest_of_name := "noname"

}

myPCO.raise( RemoteProcSignature1, myNotFoundException );

5.5.2. Attributes

An interface attribute is like a set- and get-operation pair to access a value.If an attribute is marked as readonly, the get-operation is used only. There-fore, attribute mapping can be done by the operation mapping as describedin subsection 5.5.1 on page 96.

IDL

attribute string object_type;

TTCN-3

signature RemoteAttribGetSignature() return iso8859string ;signature RemoteAttribSetSignature( in iso8859string object_type );

type port RemoteProcPort procedure {out RemoteAttribGetSignature;out RemoteAttribSetSignature

}

type component SUT {port RemoteProcPort PCO

}

var SUT myCorbaSystem := SUT.create;connect(self :myPCO, myCorbaSystem:PCO);myCorbaSystem.start();

// getmyPCO.call() {

[] myPCO.getreply( value * ) −> value MyResult {}

// catch all exceptions[] myPCO.catch {

100


verdict .set( fail );stop;

}}

// settemplate RemoteAttribSetSignature RemoteAttribSetSignatureTemplate := {

object_type := "my name"}

myPCO.call( RemoteAttribSetSignatureTemplate );}

5.5.3. Exceptions

In IDL, exceptions are used in conjunction with operations to handle ex-ceptional conditions during an operation call. Thus, a special struct-likeexception type is provided which has to be associated with each operationthat can trigger this exception. TTCN-3 also supports the use of excep-tions with procedure calls by binding it to signature definitions. However,it does not provide a special exception type. Hence, exceptions are definedas struct by using record. TTCN-2 has no support of exceptions. Thus,it is realised by using an PCO with asynchronous communication to getexception information from the test system.

The part exception definition is shown in the following example anduse of exception binding in signature definitions and exception catching isshown in context of operation declaration in subsection 5.5.1 on page 98.

IDL

exception NotFoundException { NotFoundReason why; Name rest_of_name; };

TTCN-3

// definition of an exception typetype record NotFoundException { NotFoundReason why, Name rest_of_name }

// definition of a template for the defined exception typetemplate NotFoundException NotFoundExceptionTemplate (

NotFoundReason par1, Name name) := {why := missing_node,rest_of_name := name

}

The interface mapping inclusive operations, attributes, and exceptionsis summarised in Table 5.7.

101


Table 5.7.: IDL to TTCN-3 mapping for interface elements


operation ASP signature

attribute ASP pair signature pair

readonly ASP signature

raise expression CHOICE signature exception option

context expression — additional signature parameter

interface name space group

parameter IA5String address

communication PCO port

5.6. Names and Scoping

The name definition scheme of IDL does not collide with the name defin-ition in TTCN-3. Scoping is more restrictive in IDL than in TTCN-3wherefore the IDL scoping rules have to be mapped appropriately to allowseamless mapping. IDL uses nested scopes for modules, interfaces, struc-tures, unions, operations, and exceptions. Identifiers are scoped in types,constants, enumeration values, exceptions, interfaces, attributes, and op-erations. The hierarchical scopes in TTCN-3 are module, control partof module, function, testcase, and statement blocks within control part ofmodule, function, and testcase .

Furthermore, TTCN-3 does not support overloading of identifiers sothat no identifier name can be used more than once in a scope hierarchy.However, IDL allows redefinition of self defined types if defined inside amodule, interface, or valuetype. Hence, identifiers have to be mapped byusing their path name including all interface and valuetype names as des-ignated in IDL and TTCN-3. The use of module names is not necessarybecause they are reflected by the TTCN-3 module structure. An under-score is used as a separator and existing underscores are doubled. Use ofpath names was also suggested by the TTCN-2 mappings.

To indicate the special treatment of all TTCN-3 statements derived fromIDL, TTCN-2 mappings were using special naming schemes. This simpli-fies coding and type differentiation. TTCN-3 provides a new mechanismto attach attributes to language elements. The use of attributes makescode more readable and requires no special naming scheme. Therefore,the variant attribute can be used to indicate derivation of types from IDL

102


and special treatment for encoding by the test system. This was explicitlymentioned in section 5.4 on page 86 for data types because they require al-ways correct encoding mechanism. This is used in TTCN-3 for the usefultype IDLfixed:

TTCN-3

type record IDLfixed {unsignedshort digits ,short scale ,charstring value_ } with { variant "IDL:fixed FORMAL/01−12−01 v.2.6" };

An own naming scheme to tag all types is required. It was suggestedto use the type name and if necessary add special attributes like valuetypevia the keyword and. However, among others the discussion here led tothe introduction of the variant attribute and a naming scheme for the IDLmapping was introduced by defining the useful type IDLfixed. Hence, thenaming scheme for variants uses the word IDL, the statement type, and astandard reference with a version number as shown before.

Names of new types which are specially defined for the IDL mappingand their use in conjunction with IDL shall always begin with the wordIDL to provide better distinction.


Summary

The chapter is primarily focused on the definition of a set of OMG IDLto TTCN-3 mapping rules, in order to support adequate testing based ongiven UML class diagram specifications. The presented mapping rules havebeen used to implement a converter to achieve semi-automated develop-ment of test data specifications. To support automated generation of thedynamic part in an ATS, additional formalised behavioural descriptions,e.g. sequence diagrams, have to be considered as shown in chapter 4. Themapping is based on some recent work in Ebner (2001a, b); Ebner et al.(2002); Yin (2001); Yin et al. (2001). It is also summarised in the ETSITechnical Specification 102 219 (ETSI 2003). A concept mapping list isgiven in Table A.1 on page 121. A comparison of IDL, ASN.1, TTCN-2,and TTCN-3 data types is given in Table A.2 on page 123.

It was not always possible to provide satisfiable mappings because map-ping for interface and valuetype is not powerful enough in order to use allIDL features in a proper way. Nevertheless, this is no limitation in usage

103


but a matter of convenience. Furthermore, some mappings could not bevery exact because of lacking support in TTCN-3, for instance, double andlong double. The latter ones can only be mapped to type float which has noexact size definitions. Thus, only the variant attribute contains the map-ping information. Operations, attributes, and exceptions can be mappedwell to TTCN-3 because synchronous communication was introduced es-pecially for this purpose.

To provide a better mapping of IDL and to enhance usability of TTCN-3some elements have been especially introduced or extended as proposed bythe author:

• The variant attribute, inclusive a set of predefined variants, was in-troduced. They are used to define useful types for integers, floats,strings, fixed, etc. as shown in ETSI (2002a, appendix E) and listedin Table 2.2 on page 26.

• The anytype was especially introduced for an exact mapping.

• Non-blocking procedure calls have been added.

Implementation specific parts like variable handling if used as inoutparameters are not considered in TTCN-3 because it should be done bythe compiler or interpreter and/or the underlying test system. Neverthe-less, if IDL is not precise enough, e.g., the oneway attribute for operations,the CORBA specification was used as reference.

There was no discussion about technical implementation details likememory management, size limitations, and transmission by value or ref-erence. However, it has been proven that TTCN-2 is generally applic-able to the testing of CORBA-based systems (Li et al. 1999; Mednono-gov 2000; Mednonogov et al. 2000; Schieferdecker et al. 1998). Further-more, TTCN-3 gives support for synchronous communication whereforeimplementing test suites gets easier, too. Hence, the implementation of theabove mapping is feasible. If TTCN-3 is used to test CORBA systems, thelanguage mapping of TTCN-3 should be equivalent to the IDL languagemapping. In contrast to TTCN-2, mapping to TTCN-3 is more comfort-able and powerful.

The IDL mapping is also useful in conjunction with UML and XML. Incontext of UML the mapping is useful because many UML tools provideexporting facilities to convert data from UML models to IDL. Further-more, XMI (OMG 2003e) supports transfer of UML models and IDL byusage of XML. A mapping of IDL to WSDL respectively Simple Object Ac-cess Protocol (SOAP) and vice versa can be found in OMG (2003a, d). In

104


OMG (2003f) a description is given to create a data structure of XML doc-uments to pass it in CORBA interface operations. The SODL is an XMLIDL DTD which allows objects to be described in compatibility with IDLused in Component Object Model (COM) and CORBA. SODL is used inXML Metadata Object Persistence (XMOP) which is an object serialisa-tion mechanism.

Outlook

Future work should address an adaptation to the newest IDL standard.The support of XML by TTCN-3 gets important wherefore this directionalso has to be followed.

The presence of object-orientation was missed during developing themapping. Thus, some improvements to TTCN-3 could be made if inherit-ance and abstraction as given by object-oriented concepts gets introduced.This would improve maintenance and handling of test suites and the map-ping of IDL could be much clearer (see chapter 6).

105

6. Object-Oriented Enhancements for TTCN-3

Although TTCN-3 has reached a certain stage of maturity since its firstrelease in 2001, its language elements are still lacking support of object-orientation. It is believed that object-orientation would ease its usage andmake it more expressive and applicable. Especially in conjunction withobject-oriented languages, platforms, or models like C++ and Java, theCORBA, and the UML.

Until now, TTCN-3 is not intended to support object-orientation exceptthe support for synchronous communication for CORBA-based systems.However, object-oriented concepts have been missed during developingthe IDL to TTCN-3 mapping as described in chapter 5. Especially, inher-itance and abstraction concepts have been missed. They would improvemaintenance and handling of test suites and simplify the mapping of IDL.There is ongoing work on the integration of TTCN-3 and UML by UTP(Schieferdecker et al. 2003) and a mapping of UTP to TTCN-3 by ITU-Tstandard Z.149. The deficiency of object-orientation in TTCN-3 is alsomentioned in Schmitt (2003, page 41).

It is not intended to detail how to test object-oriented systems but thenecessities to make TTCN-3 itself object-oriented. Testing object-orientedsystems are discussed in section 2.2 and, for instance, in Binder (2000).

The remainder of this chapter is structured as follows. Firstly, TTCN-3is inspected to take stock object-oriented concepts or systems like themand where it would be useful to have those concepts. Secondly, a conceptof an object-oriented revision of TTCN-3 is suggested which is based onthe preceding inspection. Finally, a summary and an outlook are given.

6.1. Object-Orientation in TTCN-3

Proposing an object-oriented enhancement of TTCN-3 requires an inspec-tion to take stock object-oriented approaches. Furthermore, the deficiencyof object-orientation and where it would be useful have to be identified.Not directly related object-oriented concepts will be mentioned anyhowif they can still be improved. Based on the inspection an enhancement isworked out which is given in section 6.2.

107


TTCN-3 was not especially designed to support object-oriented con-cepts or to test object-oriented systems wherefore no direct support isgiven. Nevertheless, the application of testing CORBA-based platforms isexplicitly mentioned, but it is only supported in sense of communicationoperations such as procedure-based communication with the well knownparameter attributes in, inout, and out from CORBA resp. IDL.

Furthermore, TTCN-3 uses the term object (see ETSI 2002a, section5.4) and an object-oriented syntax like the well known dot notation toaccess operations, although there is no object concept given.

The used object-oriented concepts, the influence of object-oriented lan-guages, and the deficiency of object-orientation will be shown in detailbelow. Furthermore, we mention among others the exception and gotoconcept.

Scope and Identifier

Scoping is used for module, control part of modules, component types,function, altstep, testcase, and statement blocks in compound statements.However, groups and types other than component have no own scopingwherefore only a little data encapsulation is provided. Hence, structuringtest suites on a syntactical level is provided which can be used only by thetest suite user. However, group attributes are forwarded to all statementsin the group. What can be seen as a kind of inheritance. Group identifiersrequire not to be globally unique.

Nevertheless, the usage of local variables, constants, timers, and portsthat are declared in a component type definition is interesting. To usethese elements in a function, the runs on clause is required to state thatthis function can only operate in the given component. Hence, an explicitdeclaration has to be made to get access to the component scope.

Identifier shall be unique in a scope hierarchy wherefore no local vari-able with the same identifier as a global variable can be used. Hence, it isnot allowed to overwrite global variables by local variables. Identifiers forfields of structured types require not to be globally unique.

Parameters

In TTCN-3, the type of parameter passing is defined by additional attrib-utes. For this purpose, the parameter attributes in, inout, and out fromCORBA resp. IDL are used. The attribute in means passing by value resp.

108


call by value and the attributes inout and out mean passing by referenceresp. call by reference.

Attributes

The support of attributes to language elements can be seen as an exten-sion or specialisation why it is comparable to the concept of inheritancefrom a basic language element which provides this attributes. However,the concept of object-orientation is applied to types and not intended forlanguage elements wherefore only the attributes encode and variant couldbe replaced by using an object-oriented concept.

Modules and Groups

Modules are the top-level structuring element in TTCN-3 and they consistof a definition and control part.

The definition part is comparable to a class where all definitions aregiven. In the control part, test case execution order is given why it canbe seen as the main method of the module. Modules can import defini-tions from other modules which allows to provide a kind of inheritance.Nevertheless, there are no global variables, timers, etc. available. Hence,modules are like packages in Java or name spaces in C++ but on the otherhand they work like classes.

Groups are used to structure test data. To access elements in the grouphierarchy the dot notation is used. There are no language constructs avail-able to control the execution of test cases within groups.

Unfortunately, modules cannot be nested. Definitions can be combinedinto groups but a group does not define a new scope and has no se-mantic purpose except when definitions are imported by another module.Moreover, TTCN-3 assumes that the entire test execution is controlledexclusively by the control part of the current module and some auxiliaryfunctions. Thus, test cases structured by groups cannot be explicitly com-bined with their execution order. Hence, its control part seems to be tooinflexible for complex and large-scale test suites.

Test case execution inside a module can only be structured by cascadingfunction calls. Thus, for each module and group, that has to be structured,one function has to be defined to control test case execution of all test casesinside (Schmitt & Ebner 2003).

109


Data Types

Many TTCN-3 data types are based on ASN.1 data types (ITU-T 1997c)as was done before in TTCN-2. The ASN.1 data type objid uses the termobject but it can only be used to store ASN.1 object identifiers and hasnothing to do with any TTCN-3 type. Hence, it is not the general objecttype which is necessary in each object-oriented language.

The fields of the structured types record and set are referenced by the dotnotation as by objects. They can be seen as a kind of a public class typelike the well known struct type. The union type uses also the dot notationto access its fields.

There is no class type resp. object type defined in TTCN-3 and con-sequently, there are only the structured types (record, record of, set, set of,enumerated, and union) available to structure data (see ETSI 2002a, sec-tion 6.3). Furthermore, the pre-defined functions for handling and con-verting basic types are stand-alone functions which are not bound to theircorresponding types (see ETSI 2002a, appendix C). Hence, better struc-turing of data and predefined functions could be provided by usage ofclasses.

Signatures

TTCN-3 especially supports procedure-based communication to be ap-plicable for object-oriented systems. For procedure-based communica-tion, the definition of procedure signatures is required which comprisesthe blocking characteristic, parameters (see page 108), a return value, andexceptions.

Due to the requirement of TTCN-3 to support testing of CORBA-basedsystems the non-blocking characteristic was introduced. This was basedon the discussion in subsection 5.5.1 on page 96. CORBA resp. IDL allowthe definition of oneway procedures which do not block execution becausethey return immediately after invocation (see ETSI 2003, chapter 10).

Templates

Templates are used to organise and to re-use test data. They can be seen asinstances of classes which provide concrete values for sending data to theSUT or which provide matching mechanisms for testing against receiveddata. Templates provide the possibility to use a simple form of inheritanceand they can be parametrised. Furthermore, in TTCN-3 the concept ofinheritance is realised in templates only.

110


Test Configuration

TTCN-3 is used to test implementations. The object beingtested is known as the Implementation Under Test or IUT(ETSI 2002a, section 8.3).

Hence, it is common to see the SUT resp. Implementation Under Test(IUT) as an object which has to be tested. However, the model describingthe configuration is motivated by the view that is used in the CTMF andconsequently, in TTCN-2, too. The model uses components and ports toarrange tests and to describe the communication.

Components have local constants, variables, and timers and ports aredescribed by signatures. Polymorphism can be realised by usage of op-tional fields in templates to send data and by usage of matching mechan-ism to receive data. Hence, they have object-oriented characteristics butthere is no inheritance and no own scope available. There is a componentreference available in TTCN-3 but it can only be used to bind communic-ation statements to a concrete component and it is not allowed to use itas a parameter for communication operations. Ports cannot be used as aparameter, too.

TTCN-3 provides the open type address to access entities inside the SUT.The actual data representation of type address can be left open or can beset by an explicit type definition. However, it is not very convenient to useit for object references because it is not possible to directly call a methodof the referenced object. Furthermore, if an object has to be send to orreceived by the IUT it has to be masked, for instance, by a record typecontaining the values of the public variables inside the object.

Hence, usage of object references would be very useful for TTCN-3 it-self and to easier definition of ATSIs to test object-oriented systems. Con-crete problem descriptions can be seen in the mapping of IDL to TTCN-3as done in chapter 5.

Function, Altstep, and Testcase

Functions, altsteps, and testcases can have the optional attribute runs on tostate the dependency of a component. Hence, the runs on clause is a meansto separate the definition of a component and its depending functions,altsteps, and testcases. Consequently, they should be defined or at leastdeclared together as it is done with classes to state this dependency moreclearly.

111


Table 6.1.: Corresponding data types for operations in TTCN-3

Operations Corresponding Type

Configuration component

Communication port

Timer timer

Verdict component

There is no explicit polymorphism for functions, altsteps, and testcasesavailable as is the case for signatures. However, it can still be realised bythe usage of type record and templates but an explicit solution would bemore expressive and much clearer.

Altsteps provide local variables, parameters, and a kind of inheritance.Furthermore, they can be activated at the beginning of a test case and theywill automatically be used in each following altstep statement. Therefore,altsteps are very good candidates to provide an own class for it.

Program Statements

The usage of program statements is not directly related to object-orien-tation but it is also useful for the application of TTCN-3. Hence, it isdiscussed here, too.

Although exceptions can be used in signatures for procedure-based com-munication the usage of exceptions in the test cases themselves is not pos-sible. It might be that the program complexity of test cases is not that highbut nevertheless it could be useful.

The usage of label and goto makes reading of test cases more difficultand produces well known problems. Thus, it should be replaced.

Operations

All configuration, communication, timer, and test verdict operations arebound to an instance of the corresponding types (see Table 6.1). For op-eration calls the dot notation is used. Therefore, all the types can be seenas a kind of class with given methods.

Configuration The configuration operations mtc and system return a com-ponent reference wherefore they can be seen as class variables. The stand-alone operation self is bind implicitly to the component in which it is

112

6.2. Object-Oriented Revision of TTCN-3

called. Therefore, self works like the keyword this in Java and C++ whichreturns the self reference, too.

Communication The operation call can deliver replies, timeouts, and ex-ceptions. In case of non-blocking procedure-based communication theyhave to be handled in following alternative statements. For blockingprocedure-based communication, an alternative statement is directly at-tached to the call statement. In conjunction with default handling viaaltsteps, an expressive way to handle timeouts and exceptions is providedfor a test case. It is not only locally but also globally usable. However,exceptions are only available for call operations.

The feature to retrieve variable values from receive, getcall, and getreplyoperations is also interesting. In receive operations the received messagevalue and sender address can be retrieved by assigning it to variables. Thesame can be done in getcall and getreply operations for the sender addressand parameter values of a received call or reply. This is done in an optionalassignment part of the operators and looks very similar to the componentinitialisation list of constructors in C++. The intention of TTCN-3 is tokeep the necessary data only if required for further test case executionbecause many times the matching result itself is sufficient enough to makea decision.

Verdicts Each test component and test case provides a verdict object andthe test case verdict depends on the component verdicts in the test case.TTCN-3 uses the explicit term object for the component verdict but it isnot further defined and hence, left to the implementation. Furthermore,there is a type verdicttype where verdicts can be stored but the overwrit-ing rules for verdicts are not valid for it. The overwriting rules are onlyused by the setverdict operation to set local verdicts. Hence, a variable oftype verdicttype can contain any verdict at any time independent of formervalues and is mainly used to allow computation depending on verdicts.


As we could see in the inspection before, TTCN-3 provides expressiveparameter passing (see page 108) and procedure-based communicationmechanisms (see page 110). However, there is only simple support for in-heritance (see pages 109 and 110) and polymorphism (see page 110) avail-able. The structure of depending elements, like components and testcases,

113


could be improved by using classes, for instance. Furthermore, the typesystem provides no support for object-orientation, there are no hierarch-ical modules, and there are only a few matching mechanism for structuredtypes available.

The object-oriented concepts mainly discussed below are encapsulation,inheritance, and polymorphism. The main revision purposes are to im-prove handling of TTCN-3 language elements itself and mapping of SUTstructure and their communication description. Based on the precedinginspection a suggestion of a concept for an object-oriented revision ofTTCN-3 gets presented now.

6.2.1. Data Types

For data types, no support for object-orientation is given and to provideseamless integration into TTCN-3 existing types will not be touched here.We introduce classes, which can be seen in the next subsection, and anobject type to store instance references of classes. Hereby, the handlingof class instances has to be considered, especially in context of parameterpassing.

Class instances could be handled by references, pointers, or objects itselfas it is possible in C++. However, to provide a seamless integration, usingpointers is declined and references are preferred as intended by TTCN-3.The difference between a reference and an object itself is, for instance,noticeable by assignments or if used as a parameter (see page 108). Asmentioned before, objects have to be interpreted as references if used asinout or out parameter and as object itself if used as in parameter. To testthe validity of an object reference variable the literal null gets introducedwhich stands for no reference assigned. In addition, the keyword this getsintroduced to get the self reference of an object.

Furthermore, supporting corresponding classes is suggested to collectpre-defined functions and permit the usage of basic types as objects. Addi-tionally, sub-typing of basic types can also be realised by usage of inherit-ance. This concerns the types integer, float, char, universal char, verdicttype,and union. For all string types a common class string shall be defined. Anown class for handling the useful type IDLfixed is suggested, too.

6.2.2. Classes

As stated before, classes get introduced into TTCN-3 to provide encap-sulation, inheritance, and polymorphism which are basic concepts from

114


Table 6.2.: Class element accessibility by access attributes

Attribute Accessibility

private class

protected class and subclasses

public all (class, subclasses, and environment)

object-oriented languages. The new keyword class is used in defining aclass. The three concepts will be discussed in detail below.

Encapsulation

With classes, it is possible to associate data and algorithms. Thus, an ownscope and local constants, variables, and timers are provided as done bythe type component (see page 111), too. Classes combine functionalityfrom groups and types (see page 108) and could be seen as an extension ofthe type component. Furthermore, definitions of types, signature, template,function, altstep, and testcase in classes are supported. In case of altstepand testcase using the runs on clause gets redundant if a class is used ascomponent. A class can be used as component if ports are given as classattributes. Hence, the dependency between a component and their corres-ponding function, altstep, and testcase definitions gets possible as deman-ded earlier (see page 111).

All definitions and declarations inside a class can get an access attributeprivate, protected, or public (default) to define the visibility to the envir-onment and subclasses as shown in Table 6.2. Hence, type componentis a special case of class where only ports and local constants, variables,and timers are allowed and all are declared public. This is comparable totypes struct and class in C++. Access to class elements like attributes andfunctions shall be given by the dot notation (as used in C++) if the accessattributes permit it.

To a class definition itself an access attribute private (default) or publiccan be given to state the visibility to the modul environment. Privateclasses are only visible inside the modul whereas public classes can beused from other modules. Classes imported by the import statement areconsidered as defined in the module itself.

In Schmitt (2003) and Schmitt & Ebner (2003) the replacement of themodule control part by control functions was suggested. A control function

115


inside a class could be used to control execution of all defined test cases ofthe class.

Inheritance

Reuse can be achieved by inheritance where a class can inherit from otherclasses. In TTCN-3 the concept of inheritance is used by groups, modules,and templates. Inheritance for classes can supplement or even replacethese existing concepts. Class inheritance is done by the new keywordextends and a comma separated list of classes from which the class inheritselements.

Attributes can be used for classes whereby the same inheritance mechan-ism as for groups is used. The usage of classes for import statements is thesame as for other types. Nevertheless, using class inheritance and nestedmodules can make import statements obsolet. Inheritance for componentsrespectively classes enables the support of generic component types whichwould improve structuring test suites. Additionally, abstract classes areintroduced to support generic components or classes more clearly. Hence,the keyword abstract gets introduced to mark base classes which can onlybe used by inheritance and not by instantiation.


Summary

The chapter discusses improving of object-orientation in TTCN-3 to wid-en its expressiveness and applicableness. TTCN-3 provides an object-oriented approach by using operations, signatures, and templates. It usessome object-oriented syntax like the dot notation, too. However, the con-cepts have to be improved and if we take a look on data types, object-orientation is still missing.

It was shown how basic object-orientation can be seamless and expli-citly introduced to improve clarity of existing concepts and to widen thecapabilities of TTCN-3. Therefore, the new type object, the keyword this,the literal null, and classes, including class attributes, have been intro-duced.

116


Outlook

In conjunction with hierarchical modules and a control function insteadof a control part, as mentioned in Schmitt & Ebner (2003), the object-oriented revision of TTCN-3 could be given as proposal. Furthermore,the inspection and revision suggestion can be used to get a new view onTTCN-3, to use it as a basic work for the next generation of TTCN, andfor the usage of TTCN-3 together with UML.

Nevertheless, beside an explicit syntax a deeper discussion about usageof the new object-oriented context has to be worked out. Especially incontext of IDL and UML. Another further step would be a new object-oriented test description language which can be easily used in corporationwith UML.

117

7. Conclusion

This thesis treated Computer Aided Test Generation based on manualgraphical test purposes due to overcome limits of automatic test gener-ation. Test case generation based on state space exploration is helpful butproduces frequently inefficient test cases, lacks to cover specific parts, ormay not be possible because of an incomplete or missing specification.Hence, manually defined graphical test purposes by MSC are desirable.Using UML for test purpose specification provides the advantage to use awell known language and to integrate given system specifications with testspecification. In addition, given information like used types or interfacesby IDL are used for the static part of a test suite. Thus, a more completetest suite can be defined using UML and integration with automatic testgeneration is given. The industrial interest on the MSC to TTCN-3 proto-type and the ETSI Technical Specification of the IDL to TTCN-3 mappinghave shown the need of this thesis. The practicability was shown by pro-totypes which implement the mappings of MSC and IDL to TTCN-3.

An object-oriented extension of TTCN-3 was only indicated and shouldbe considered for further improvements of TTCN-3 to widen its usability.

119

A. IDL Mapping Summary

A.1. Conceptual IDL to TTCN-3 Mapping

Table A.1 lists the mapping of keywords and concepts of IDL to TTCN-3keywords or concepts. Literal mapping can be seen in Table 5.1 on page 81and operator mapping in Table 5.2 on page 86.

Table A.1.: Conceptual list of IDL mapping

IDL TTCN-3

FALSE false

Object address

TRUE true

abstract has to be rolled out

any anytype

array array

attribute get (and set) operation

boolean boolean

char iso8859char

(self defined type)

const const

context additional procedure

parameter of type record

enum enumerated

exception record

fixed IDLfixed

float IEEE754float

double IEEE754double

long double IEEE754extdouble

in in

inout inout

interface group, port

local —

long long

long long longlong

IDL TTCN-3

module module

native address

octet octetstring

oneway operation with

variant attribute

operation signature for procedure

out out

raises exception

readonly only a get operation

for the attribute

sequence record of

short short

string iso8859string

struct record

typedef type

union record, enumerated, union

unsigned long unsignedlong

unsigned long long unsignedlonglong

unsigned short unsignedshort

valuetype record

wchar universal char

wstring universal charstring

121


A.2. Comparison of IDL, ASN.1, TTCN-2, and TTCN-3 Data Types

Table A.2 lists a comparison of IDL, ASN.1, TTCN-2, and TTCN-3 datatypes and is based on the documents (Li 1998; Mednonogov 2000; Med-nonogov et al. 2000; Open Group 2000) and is also summarised in ETSI(2003).

1Mapping of this type was not considered.2superseded in ASN.1 from 1997 (ITU-T 1997b)

122

A.2. Comparison of IDL, ASN.1, TTCN-2, and TTCN-3 Data Types

Table A.2.: Comparison of IDL, ASN.1, TTCN-2, and TTCN-3 data types

IDL ASN.1 TTCN-2 TTCN-3

Object ObjectInstance IA5String address

(X.500 Distinguished name)

any ANY DEFINED BY2 or CHOICE anytype

SEQUENCEtypecode, anyValue

array SEQUENCE OF (with SEQUENCE SIZE(n) OF array

sizeConstraint subtype)

boolean BOOLEAN BOOLEAN boolean

char GraphicString GraphicString or iso8859char

IA5String(SIZE(1)) (self defined type)

enum ENUMERATED ENUMERATED enumerated

exception SPECIFIC ERRORS SEQUENCE record

fixed —1 —1 IDLfixed

float REAL —1 IEEE754float

double REAL —1 IEEE754double

long double REAL —1 IEEE754extdouble

long INTEGER INTEGER long

long long INTEGER INTEGER longlong

native —1 —1 address

octet OCTET STRING OCTET STRING (SIZE(1)) octetstring

sequence SEQUENCE OF (with SEQUENCE OF record of

optional sizeConstraintsubtype for IDL bounds)

short INTEGER INTEGER short

string GraphicString GraphicString iso8859string

struct SEQUENCE SEQUENCE record

union, switch, CHOICE SEQUENCE record, union,

case (with ASN.1 TAGS) enumerated

unsigned long INTEGER INTEGER unsignedlong

unsigned long long INTEGER INTEGER unsignedlonglong

unsigned short INTEGER INTEGER unsignedshort

valuetype —1 —1 record

wchar —1 GraphicString or universal char

BMPString(SIZE(1))

wstring —1 GraphicString universal charstring

123


A.3. Examples

A completion of all examples used in chapter 5 is given here. Some partsare used from the CORBA Naming Service with slight modifications tocover more IDL elements. The first part of the module definition partwas generated by the implemented IDL to TTCN-3 converter. The secondpart demonstrates how the first part definitions can be used for test casedefinitions.

124

A.3. Examples

A.3.1. Given IDL Specification

1 module NamingServiceExample2 {3 // ***********4 // Basic Types5 // ***********6 const long number = 017; // 017 == 0xF == 157 const long size = ( ( number << 3 ) % 0x1F ) & 0123;8 const float decimal = 15.7;9

10 const char letter = ’A’;11 const wchar wideLetter = ’A’;12

13 const boolean isValid = TRUE;14 const octet anOctet = 0x55; // limited to 8 bit15

16 const string myName = "my name";17 const wstring wideMyName = "my name";18

19

20 typedef string MyString;21

22 // *****************23 // Constructed Types24 // *****************25 typedef struct NC {26 MyString id;27 MyString kind;28 } NameComponent;29

30 union MyUnion switch( long ) {31 case 0 : boolean b;32 case 1 : char c;33 case 2 : octet o;34 case 3 : short s ;35 };36

37 enum NotFoundReason { missing_node,38 not_context,39 not_object };40

41 // **************42 // Template Types43 // **************44 typedef sequence <NameComponent> Name;45

46 typedef sequence <NameComponent> Key;47

48 typedef fixed<12,7> Fix;49

125


50 // ******************51 // Complex Declarator52 // ******************53 typedef long NumberList[100];54

55 native MyNativeVariable;56

57 // ********************58 // Valuetype Definition59 // ********************60

61 valuetype StringValue string ;62

63 valuetype EmployeeRecord {64 // note this is not a CORBA::Object65 // state definition66 private string name;67 private string email;68 private string SSN;69

70 // initializer71 factory init ( in string name, in string SSN);72 };73

74 // ********************75 // Interface Definition76 // ********************77 interface NamingContext {78 attribute string object_type;79 readonly attribute Key external_form_id;80

81 exception NotFound {82 NotFoundReason why;83 Name rest_of_name;84 };85

86 MyString bind( in Name n,87 inout Object obj,88 out Object myObj )89 raises ( NotFound )90 context ( "Hostname" );91

92 oneway void rebind( in Name n,93 in Object obj );94

95 }; // end of interface NamingContext96

97 }; // end of module

126

A.3. Examples

A.3.2. Mapped TTCN-3 Specification

Generated Part

1 // ******************************************************************2 // Generated by the IDL to TTCN−3 translator3 //4 // Copyright (c) 20035 // Institute for Informatics , University of Goettingen6 // 37083 Goettingen, Germany7 //8 // All Rights Reserved9 //

10 // ******************************************************************11

12 module NamingServiceExample() {13 const long number := ’17’O;14

15 const long size := ( ( number << 3 ) mod ’1F’H ) and4b ’0123’O;16

17 const float decimal := 15.7;18

19 const iso8859char letter := "A";20

21 const universal char wideLetter := "A";22

23 const boolean isValid := true ;24

25 const octetstring anOctet := ’55’H;26

27 const iso8859string myName := "my name";28

29 const universal charstring wideMyName := "my name";30

31 type iso8859string MyString;32

33 // struct34 type record NC {35 MyString id,36 MyString kind37 };38 type NC NameComponent;39 // end struct40

41 // union42 type union MyUnionType {43 boolean b,44 iso8859char c,45 octetstring o,46 short s47 }

127


48 type enumerated MyUnionEnumType {49 boolean_b,50 iso8859char_c,51 octetstring_o ,52 short_s53 }54 type record MyUnion {55 MyUnionEnumType kind,56 MyUnionType value57 }58 // end union59

60 // enum61 type enumerated NotFoundReason {62 missing_node,63 not_context,64 not_object65 };66 // end enum67

68 type record of NameComponent Name;69

70 type record of NameComponent Key;71

72 type IDLfixed Fix ;73 template IDLfixed FixTemplate := { 12, 7, ? };74

75 type long NumberList[ 100 ];76

77 address MyNativeVariable;78

79 group NamingContextInterface {80 signature object_type ( )81 return iso8859string ;82 signature object_type ( in iso8859string _object_type );83

84

85 signature external_form_id ( )86 return Key;87

88

89 // exception90 type record NotFound {91 NotFoundReason why,92 Name rest_of_name93 };94 template NotFound NotFoundTemplate (95 NotFoundReason _why, Name _rest_of_name ) := {96 why := _why,97 rest_of_name := _rest_of_name98 };

128

A.3. Examples

99 // end exception100

101 signature bind (102 inout Name n,103 inout address obj,104 out address myObj105 )106 return MyString107 exception( NotFound );108

109 signature rebind (110 inout Name n,111 inout address obj112 ) noblock;113

114 type port NamingContext115 procedure {116 object_type,117 external_form_id,118 bind,119 rebind120 }121 type address NamingContextObject;122 } // group NamingContextInterface123

124 } // module NamingServiceExample125

126 // ******************************************************************127 // End of generated TTCN−3 code128 // ******************************************************************

129


Test Case Example

1 module NamingServiceExample() {2

3 // somewhere has MyMTC to be defined4

5 type record IDLContextElement {6 iso8859string name,7 iso8859string value_8 }9

10 type record of IDLContextElement IDLContext;11

12 // *******************13 // Testcase Definition14 // *******************15 testcase MyNamingServiceTestCase() runs on MyMTC system CorbaSystemInterface {16

17 // examples to show how above defintions can be used inside a18 // testcase definition19

20 var CorbaSystemInterface myCorbaSystem := CorbaSystemInterface.create;21 connect( self :NamingContextPCO, myCorbaSystem:PCO );22 myCorbaSystem.start;23

24 //25 // Fixed Type26 //27 var IDLfixed fix := { 12, 7, "12345.1234567" };28

29 //30 // Array31 //32 var integer numberList[100];33

34 //35 // Native36 //37 var address MyNativeVariable;38

39

40 //41 // Procedure Calls42 //43 var iso8859string myResult1;44 var Key myResult2;45 var MyString myResult3;46 var iso8859string object , myObject, resultObject, resultMyObject;47

48 var IDLContextElement contextElement := {49 name := "Hostname",

130

A.3. Examples

50 value_ := "disen"51 }52

53 var IDLContext contextParameter := { contextElement };54

55 //56 // procedure get object_type57 //58 NamingContextPCO.call( ObjectTypeGetSignature )59 {60 [] NamingContextPCO.getreply( ObjectTypeGetSignature value * )61 −> value myResult1 {}62 }63

64 //65 // procedure set object_type66 //67 NamingContextPCO.call( ObjectTypeSetSignatureTemplate );68

69

70 //71 // procedure get external_from_id72 //73 NamingContextPCO.call( ExternalFormIdGetSignature )74 {75 [] NamingContextPCO.getreply( ExternalFormIdGetSignature value * )76 −> value MyResult2 {}77 }78

79

80 //81 // procedure bind (with template)82 //83 NamingContextPCO.call( BindTemplate( object, contextParameter ) )84 {85 [] NamingContextPCO.getreply( BindTemplate( * ) value * )86 −> value myResult387 param( resultObject, resultMYObject ) sender mySender {}88

89 [] NamingContextPCO.catch( BindSignature,90 NotFoundExceptionTemplate )91 {92 verdict .set( fail );93 stop;94 }95

96 }97

98

99 //100 // procedure bind (without template)

131


101 //102 NamingContextPCO.call(103 BindSignature:{ myName, object, myObject, contextParameter } )104 {105 [] NamingContextPCO.getreply( BindSignature:{ −, *, myObject }106 value * ) −> value myResult3107 param( resultObject, resultMYObject ) sender mySender {}108 }109

110 //111 // procedure rebind112 //113 NamingContextPCO.call( RebindSignature:{ myName, object} );//or use a template114

115

116 //117 // raising an exception118 //119

120 // this would be used to raise an exception inside of procedure bind121 // if defined by TTCN−3 (if used on server side).122 var NotFoundException myNotFoundException := {123 why := missing_node,124 rest_of_name := "noname"125 }126

127 NamingContextPCO.raise( BindSignature, myNotFoundException );128

129 } // end of testcase MyNamingServiceTestCase130

131 } // end of module

132

B. The TTCN-3 Inres Protocol Module

Below a directly defined TTCN-3 module for the Inres protocol is given(Schmitt 2003).1

1 /*2 * TTCN−3 module for the ’Inres’ protocol3 *4 * Copyright (C) 2002 Michael Schmitt <[email protected]>5 *6 * Date: 2002/09/10 18:47:377 */8

9 module TestsForInres( integer maxRepetitions, boolean testInopportuneEvents ) {10 import from ServiceUser language "ASN.1:1997" {11 type UserPDU;12 const someUserPDU;13 }14

15 group BasicDefinitions {16 type UserPDU InresSDU; // the PDU on layer n+1 becomes an SDU on layer n17

18 type enumerated InresPDUType { CR(1), CC(2), DR(3), DT(4), AK(5) };19

20 type enumerated SequenceNumber { zero(0), one(1) };21

22 type record InresPDU {23 InresPDUType iPDUType,24 SequenceNumber seqNo optional,25 InresSDU iSDU optional26 }27

28 type InresPDU MediumSDU; // the PDU on layer n becomes an SDU on layer n−129 } with { encode "PER−BASIC−UNALIGNED:1997" } // apply Packed Encoding Rules30

31 const float maxTestCaseTime := 50; // max. execution time for a single test case32 const float maxTransferTime := 30; // max. execution time for a single data transfer33

34 group CommunicationWithInitiator {35 type record ICONreq {};36 type record ICONconf {};37 type record IDATreq { InresSDU iSDU };38 type record IDISreq {};

1Copy permission was thankfully granted by Dr. Michael Schmitt.

133


39 type record IDISind {};40

41 type port InitiatorSAP message {42 out ICONreq, IDATreq, IDISreq; // sent to SUT43 in ICONconf, IDISind; // received from SUT44 }45 }46

47 group CommunicationWithMedium {48 type record MDATreq { MediumSDU mSDU };49 type record MDATind { MediumSDU mSDU };50

51 type port MediumSAP message {52 in MDATind; // received from SUT53 out MDATreq; // sent to SUT54 }55 }56

57 group CommunicationBetweenTestComponents {58 signature acknowledgementSent();59

60 type port PortAtMTC procedure {61 in acknowledgementSent;62 }63

64 type port PortAtPTC procedure {65 out acknowledgementSent;66 }67 }68

69 group ComponentDefinitions {70 type component MainTC {71 port InitiatorSAP ISAP1;72 port PortAtMTC CoordinationPTC;73 timer supervisionTimer;74 }75

76 type component ParallelTC {77 port MediumSAP MSAP2;78 port PortAtPTC CoordinationMTC;79 }80

81 type component TestSystem {82 port InitiatorSAP ISAP1;83 port MediumSAP MSAP2;84 }85 }86

87 group TemplateDefinitions {88 template IDATreq InresDataRequest( InresSDU data ) := {89 iSDU := data

134

90 }91

92 template MDATind ConnectionRequest := {93 mSDU := { iPDUType := CR, seqNo := omit, iSDU := omit }94 }95

96 template MediumSDU ConnectionConfirmation := { // this template is used with97 iPDUType := CC, seqNo := omit, iSDU := omit // template ’MediumDataRequest’98 }99

100 template MDATreq MediumDataRequest( template MediumSDU data ) := {101 mSDU := data102 }103

104 template MDATind DataTransfer( InresSDU data ) := {105 mSDU := { iPDUType := DT, seqNo := ?, iSDU := data }106 }107

108 template MDATreq DataAcknowledgement( SequenceNumber number ) := {109 mSDU := { iPDUType := AK, seqNo := number, iSDU := omit }110 }111 }112

113 altstep MTCFailure() runs on MainTC {114 [] ISAP1.receive {115 setverdict ( fail );116 stop;117 }118 [] any timer.timeout {119 setverdict ( fail );120 stop;121 }122 }123

124 altstep PTCFailure() runs on ParallelTC {125 [] MSAP2.receive {126 setverdict ( fail );127 stop;128 }129 }130

131 altstep ReceptionIDISind( verdicttype result ) runs on MainTC {132 [] ISAP1.receive( IDISind : {} ) {133 setverdict ( result );134 stop;135 }136 }137

138 function MediumAccess() runs on ParallelTC {139 var integer receipt ;140 var default def := activate ( PTCFailure() );

135


141 var MDATind indication ;142

143 MSAP2.receive( ConnectionRequest );144 receipt := 1; // first (received) connection request of the initiator145

146 MSAP2.send( MediumDataRequest( ConnectionConfirmation ) );147

148 alt {149 [ receipt <= maxRepetitions ] MSAP2.receive( ConnectionRequest ) {150 // connection confirmation got lost probably due151 // to a malfunction of the medium; resend it152 receipt := receipt + 1;153 MSAP2.send( MediumDataRequest( { CC, omit, omit } ) );154 repeat;155 }156 [ receipt > maxRepetitions ] MSAP2.receive( ConnectionRequest ) {157 // even over an unreliable medium, the initiator158 // shall not resend its requests that often159 setverdict ( fail );160 stop;161 }162 [] MSAP2.receive( DataTransfer( someUserPDU ) ) −> value indication {163 /* empty */164 }165 }166

167 MSAP2.send( DataAcknowledgement( indication.mSDU.seqNo ) );168

169 // inform the main test component that170 // the data have been received and acknowledged171 CoordinationMTC.call( acknowledgementSent : {} );172 CoordinationMTC.getreply( acknowledgementSent : {} );173

174 alt {175 [] MSAP2.receive( MDATind : { mSDU := { DR, omit, omit } } ) {176 setverdict ( pass ); // disconnection request177 }178 [] MSAP2.receive( DataTransfer( someUserPDU ) ) {// data acknowl. got lost179 setverdict ( inconc );180 }181 }182 }183

184 testcase SingleDataTransfer () runs on MainTC system TestSystem {185 var ParallelTC ptc;186 var default def1, def2;187

188 ptc := ParallelTC .create ;189

190 map( self: ISAP1, system:ISAP1 );191 map( ptc:MSAP2, system:MSAP2 );

136

192

193 connect( self :CoordinationPTC, ptc:CoordinationMTC );194

195 ptc. start ( MediumAccess() );196

197 def1 := activate ( MTCFailure() );198 def2 := activate ( ReceptionIDISind( inconc ) );199

200 ISAP1.send( ICONreq : {} ); // connection request201 ISAP1.receive( ICONconf : {} ); // connection confirmation202

203 supervisionTimer. start ( maxTransferTime ); // restrict time for data transfer204

205 ISAP1.send( InresDataRequest( someUserPDU ) ); // data transfer206

207 // delay disconnection request until ’ptc’ has received and acknowledged the data208 CoordinationPTC.getcall( acknowledgementSent : {} );209 CoordinationPTC.reply( acknowledgementSent : {} );210

211 supervisionTimer.stop; // cancel timer to avoid a timeout in the following212

213 deactivate( def2 ); // a discon. indication is no undesirable event any longer214

215 ISAP1.send( IDISreq : {} ); // disconnection request216 ISAP1.receive( IDISind : {} ); // disconnection indication217

218 all component.done;219

220 setverdict ( pass );221 }222

223 testcase DataLoss() runs on MainTC system TestSystem {224 // ...225 }226

227 control {228 var verdicttype overallVerdict := pass;229

230 overallVerdict := execute( SingleDataTransfer (), maxTestCaseTime );231

232 if ( overallVerdict == pass and testInopportuneEvents == true ) {233 overallVerdict := execute( DataLoss() );234 }235 }236 } with { encode "BER:1997" } // apply Basic Encoding Rules by default

137

Acronyms

A

AMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Method InvocationASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract Syntax Notation OneASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract Service PrimitiveATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract Test SuiteATSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract Test System Interface

C

CATG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computer Aided Test GenerationCCITT . . . . . . . . . . . . . . . . . . . . . Consultative Committee for International Telegraph

and Telephone (now ITU-T)CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . Common Object Request Broker ArchitectureCTMF . . . . . . . . . . . . . . . . . . . . . . Conformance Testing Methodology and Framework

E

ETSI . . . . . . . . . . . . . . . . . . . . . . . . . European Telecommunications Standards Institute

F

FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . First In First Out

G

GFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TTCN-3 Graphical Presentation Format

H

HMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High-Level Message Sequence Chart

I

IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Definition LanguageIEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Electrotechnical CommissionI IOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Inter-ORB ProtocolIOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interoperable Object ReferenceISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Organisation for StandardisationITU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Telecommunication UnionITU-T . . . . . . ITU – Telecommunications Standardisation Sector (formerly CCITT)IUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementation Under Test

139

Acronyms

M

MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Sequence ChartMTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Test Component

O

OMG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Management GroupORB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Request BrokerOSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Systems Interconnection

P

PCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Point of Control and ObservationPDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Data UnitPOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Portable Object AdaptorPTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parallel Test Component

R

RTSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Real Test System Interface

S

SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Access PointSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specification and Description LanguageSOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Object Access ProtocolSODL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Object Definition LanguageSUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Under Test

T

TTCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tree and Tabular Combined NotationTTCN-2 . . . . . . . . . . . . . . . . . . . . . . Tree and Tabular Combined Notation (version 2)TTCN-3 . . . . . . . . . . . . . . . . . . . . . . . . . . Testing and Test Control Notation (version 3)

U

UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unified Modeling LanguageUTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UML Testing Profile

W

WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Services Description Language

X

XMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XML Metadata InterchangeXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . eXtensible Markup Language

140

Bibliography

Amyot, D. & A. Eberlein, 2003. An Evaluation of Scenario Notationsand Construction Approaches for Telecommunication Systems Devel-opment. Telecommunications Systems, volume 24(1):pages 61–94.ISSN 1018-4864. Kluwer Academic Publishers.

Balzert, H., 1998. Lehrbuch der Software-Technik: Software-Management, Software-Qualitätssicherung, Unternehmensmodellier-ung, volume 2. Spektrum Akademie Verlag, 1 edition. ISBN 3-8274-0065-1.

Binder, R., 2000. Testing Object-Oriented Systems: Models, Patterns,and Tools. Object Technology Series. Addison-Wesley. ISBN 0-201-80938-9.

Dai, Z., J. Grabowski, & H. Neukirchen, 2002. TIMEDTTCN-3 – A Real-Time Extension for TTCN-3. In Proceedings of the IFIP TC6/WG6.114thInternational Conference on Testing of Communicating Sys-tems, (TestCom 2002), Berlin, Germany, edited by I. Schieferdecker,H. König, & A. Wolisz, pages 407–424. The International Federationfor Information Processing, IFIP, Kluwer Academic Publishers. ISBN0-7923-7695-1.

Dai, Z., J. Grabowski, & H. Neukirchen, 2003. TIMEDTTCN-3 BasedGraphical Real-Time Test Specification. In Proceedings of the IFIPTC6/WG6.1 15thInternational Conference on Testing of Communic-ating Systems, (TestCom 2003), Sophia-Antipolis, France, edited byD. Hogrefe & A. Wiles, volume 2644 of Lecture Notes in ComputerScience, (LNCS), pages 110–127. The International Federation for In-formation Processing, IFIP, Springer Verlag. ISBN 3-540-40123-7.ISSN 0302-9743.

Dai, Z. R., J. Grabowski, H. Neukirchen, & H. Pals, 2004. From Designto Test with UML – Applied to a Roaming Algorithm for BluetoothDevices. In Proceedings of the IFIP TC6/WG6.1 16thInternationalConference on Testing of Communicating Systems, (TestCom 2004),Oxford, United Kingdom, Lecture Notes in Computer Science,

141

Bibliography

(LNCS). The International Federation for Information Processing,IFIP, Springer Verlag.

Ebner, M., 2001a. A Mapping of OMG IDL to TTCN-3. SIIMTechnical Report SIIM-TR-A-01-11, Institute for Telematics, Uni-versity of Lübeck, Germany. Schriftenreihe der Institute fürInformatik\Mathematik, (SIIM).

Ebner, M., 2001b. Mapping CORBA IDL to TTCN-3 based on IDLto TTCN-2 mappings. In Proceedings of the 11th GI/ITG TechnicalMeeting on Formal Description Techniques for Distributed Systems,Bruchsal, Germany, 21.-22. June 2001. International University inGermany. URL http://www.i-u.de/fbt2001/.

Ebner, M., 2004. TTCN-3 Test Case Generation from Message SequenceCharts. In ISSRE04 Workshop on Integrated-reliability with Telecom-munications and UML Languages (ISSRE04:WITUL), 2. November2004, IRISA Rennes, France. The Institute of Electrical and ElectronicsEngineers, IEEE. The 15th IEEE International Symposium on SoftwareReliability Engineering, (accepted paper, to be appear).

Ebner, M., A. Yin, & M. Li, 2002. Definition and Utilisation of OMGIDL to TTCN-3 Mappings. In Proceedings of the IFIP TC6/WG6.114thInternational Conference on Testing of Communicating Sys-tems, (TestCom 2002), Berlin, Germany, edited by I. Schieferdecker,H. König, & A. Wolisz, pages 443–458. The International Federationfor Information Processing, IFIP, Kluwer Academic Publishers. ISBN0-7923-7695-1.

Ellsberger, J., D. Hogrefe, & A. Sarma, 1997. SDL — Formal Object-oriented Language for Communicating Systems. Prentice Hall Europe.ISBN 0-13-621384-7.

ETSI, 2001. Methods for Testing and Specification (MTS) — The Test-ing and Test Control Notation version 3 — Part 2: TTCN-3 TabularPresentation Format (TPF). European Standard ETSI ES 201 873-2 v.2.2.0, ETSI, European Telecommunications Standards Institute,Sophia-Antipolis, France.

ETSI, 2002a. Methods for Testing and Specification (MTS) — The Test-ing and Test Control Notation version 3 — Part 1: TTCN-3 Core Lan-guage. European Standard ETSI ES 201 873-1 v2.2.1, ETSI, EuropeanTelecommunications Standards Institute, Sophia-Antipolis, France.

142

http://www.i-u.de/fbt2001/

Bibliography

ETSI, 2002b. Methods for Testing and Specification (MTS) — The Test-ing and Test Control Notation version 3 — Part 3: TTCN-3 Graph-ical Presentation Format (GFT). Technical Report ETSI TR 101 873-3 v.1.1.2, ETSI, European Telecommunications Standards Institute,Sophia-Antipolis, France.

ETSI, 2003. Methods for Testing and Specification (MTS) — The IDL toTTCN-3 Mapping. Technical Specification ETSI TS 102 219 v1.1.1,ETSI, European Telecommunications Standards Institute, Sophia-Antipolis, France.

Grabowski, J., 2002. Specification Based Testing of Real-Time Distrib-uted Systems. habilitation thesis, Universität zu Lübeck, Germany.

Grabowski, J., B. Koch, M. Schmitt, & D. Hogrefe, 1999. SDL and MSCBased Test Generation for Distributed Test Architectures. In SDL ’99The next Millenium – Proceedings of the Nineth SDL Forum, editedby D. R, G. v. Bochmann, & Y. Lahav. Elsevier, Montreal, Canada.

Grabowski, J., R. Scheurer, Z. Dai, & D. Hogrefe, 1997. Applying SAM-STAG to the B-ISDN protocol SSCOP. In Proceedings of the IFIPTC6/WG6.1 10thInternational Workshop on Testing of Communic-ating Systems, (IWTCS 1997), Cheju Island, Korea, edited by M. Kim,S. Kang, & K. Hong. The International Federation for InformationProcessing, IFIP, Chapman & Hall.

Hogrefe, D., 1989. Estelle, LOTOS und SDL. Standard-Spezifikations-sprachen für verteilte System. Springer Verlag. ISBN 3-540-50477-X.

ISO/IEC, 1990. Information Technology — ISO 7-bit coded characterset for information exchange. International Standard 646, ISO, In-ternational Organisation for Standardisation and IEC, InternationalElectrotechnical Commission.

ISO/IEC, 1993. Information Technology — Universal Multiple Octet-Coded Character Set (UCS). International Standard 10646, ISO, In-ternational Organisation for Standardisation and IEC, InternationalElectrotechnical Commission.

ISO/IEC, 1994. Information Technology — Open Systems Interconnec-tion — Conformance Testing Methodology and Framework — Part 1:General Concepts. International Standard 9646-1, ISO, InternationalOrganisation for Standardisation and IEC, International Electrotech-nical Commission.

143

Bibliography

ISO/IEC, 1998a. Information Technology — 8-bit single-byte codedgraphic character sets — Part 1: Latin alphabet No. 1. InternationalStandard 8859-1, ISO, International Organisation for Standardisationand IEC, International Electrotechnical Commission.

ISO/IEC, 1998b. Information Technology — Open Systems Interconnec-tion — Conformance Testing Methodology and Framework — Part 3:The Tree and Tabular Combined Notation (Second Edition). Interna-tional Standard 9646-3, ISO, International Organisation for Standard-isation and IEC, International Electrotechnical Commission.

ISO/IEC, 1998c. Information Technology — Programming Languages —C++. International Standard 14882, ISO, International Organisationfor Standardisation and IEC, International Electrotechnical Commis-sion.

ISO/IEC, 1999. Information Technology — Open Distributed Processing— Interface Definition Language. International Standard DIS 14750,ISO, International Organisation for Standardisation and IEC, Interna-tional Electrotechnical Commission.

ITU-T, 1996. Recommendation: Message Sequence Chart (MSC). Inter-national Standard Z.120 (10/96), ITU-T, International Telecommunic-ation Union — Telecommunication Standardisation Sector SG 10.

ITU-T, 1997a. Recommendation: Information Technology — OpenDistributed Processing — Interface Definition Language (IDL). Inter-national Standard X.920, ITU-T, International TelecommunicationUnion — Telecommunication Standardisation Sector.

ITU-T, 1997b. Recommendation: Information Technology – AbstractSyntax Notation One (ASN.1): Specification of Basic Notation. In-ternational Standard X.680, ITU-T, International TelecommunicationUnion — Telecommunication Standardisation Sector.

ITU-T, 1997c. Recommendation: Information Technology – AbstractSyntax Notation One (ASN.1): Specification of Basic Notation. In-ternational Standard X.680, ITU-T, International TelecommunicationUnion — Telecommunication Standardisation Sector.

ITU-T, 1999. Recommendation: Specification and Description Language(SDL). International Standard Z.100 (11/99), ITU-T, InternationalTelecommunication Union — Telecommunication StandardisationSector SG 10.

144

Bibliography

ITU-T, 2001. Recommendation: Message Sequence Chart (MSC). Inter-national Standard Z.120 (11/99) with Corrigendum 1, ITU-T, Interna-tional Telecommunication Union — Telecommunication Standardisa-tion Sector SG 10.

Jeckle, M., C. Rupp, J. Hahn, B. Zengler, & S. Queins, 2004. UML 2glasklar. Hanser, 1 edition. ISBN 3-446-22575-7.

Kaner, C., J. Falk, & H. Nguyen, 1999. Testing Computer Software.Wiley Computer Publishing, 2 edition. ISBN 0-471-35846-0.

Kerbrat, A., T. Jéron, & R. Groz, 1999. Automated test generation fromSDL specifications. In SDL ’99 The Next Millenium, Proceedingsof the Ninth SDL Forum, Montréal, Québec, Canada, 21–25 Hune,1999, edited by R. Dssouli, G. v. Bochmann, & Y. Lahav, pages 135–151. Elsevier.

Koch, B., 2001. Test-purpose-based Test Generation for Distributed TestArchitectures. doctoral thesis, Universität zu Lübeck, Germany.

Koch, B., J. Grabowski, D. Hogrefe, & M. Schmitt, 1998. Autolink – ATool for Automatic Test Generation from SDL Specifications. In IEEEInternational Workshop on Industrial Strength Formal SpecificationTechniques (WIFT’98). Boca Raton, Florida.

Kung, D., P. Hsia, & J. Gao (editors), 1998. Testing Object-OrientedSoftware. IEEE Computer Society. ISBN 0-8186-8520-4.

Li, M., 1998. Testing Computational Interfaces of CORBA Service us-ing TTCN and CORBA. Diplomarbeit, Fachgebiet Telekommunika-tionsnetze, Fachbereich Elektrotechnik, Technische Universität Berlin,Germany.

Li, M., I. Schieferdecker, & A. Rennoch, 1999. Testing the TINA RetailerReference Points. In 4th Int. Symposium on Autonomous Decentral-ized Systems (ISADS’99), Tokyo, Japan, Mar. 1999.

McGregor, J. & D. Sykes, 2001. Practical Guide to Testing Object-Oriented Software. Object Technology Series. Addison-Wesley. ISBN0-201-32564-0.

Mednonogov, A., 2000. Calypso Gateway specification, version 0.07.Technical report, Telecommunications Software and MultimediaLaboratory, Helsinki University of Technology, Finland.

145

Bibliography

Mednonogov, A., H. Kari, O. Martikainen, & J. Malinen, 2000.Conformance Testing of CORBA Services using Tree and Tabu-lar Combined Notation. In Proceedings of the IFIP TC6/WG6.113thInternational Conference on Testing of Communicating Systems,(TestCom 2000), August 29.–September 1., 2000, Ottawa, Canada,edited by H. Ural, R. Probert, & G. Bochmann, pages 193–208. TheInternational Federation for Information Processing, IFIP, KluwerAcademic Publishers.

Mellor, S. J. & M. J. Balcer, 2002. Executable UML: A Foundation forModel-Driven Architecture. Object Technology Series. Addison-Wes-ley. ISBN 0-201-74804-5.

Miga, A., D. Amyot, F. Bordeleau, C. Cameron, & M. Woodside, 2001.Deriving Message Sequence Charts from Use Case Maps Scenario Spe-cifications. In Proceedings of the SDL 2001: Meeting UML. 10th In-ternational SDL Forum Copenhagen, Denmark, June 27–29, 2001,edited by R. Reed & J. Reed, number 2078 in Lecture Notes in Com-puter Science, (LNCS), pages 268–287. SDL Forum Society, SpringerVerlag. ISBN 3-540-42281-1.

Mulvihill, B., 2003. Generation of TTCN Test Cases from Use CaseMap Scenarios. Graduate student report, School of Information Tech-nology and Engineering, University of Ottawa, Canada. Supervisor:Daniel Amyot, URL http://www.site.uottawa.ca/~damyot/students/BryanMulvihillRep.pdf.

Myers, G., 2001. Methodisches Testen von Programmen. Oldenbourg,7 edition. ISBN 3-486-25634-3. (original title: The Art of SoftwareTesting).

Neukirchen, H., 2004. Languages, Tools and Patterns for the Specific-ation of Distributed Real-Time Tests. doctoral thesis, Georg-August-Universität Göttingen, Germany.

OMG, 1997. CORBAservices - Naming Service. Technical Reportformal/97-12-10, OMG, Object Management Group.

OMG, 1999. C Language Mapping Specification. OMG Formal Docu-ment formal/99-07-35, OMG, Object Management Group.

OMG, 2001a. Model Driven Architecture. Technical report, OMG,Object Management Group.

146

http://www.site.uottawa.ca/~damyot/students/BryanMulvihillRep.pdf

http://www.site.uottawa.ca/~damyot/students/BryanMulvihillRep.pdf

Bibliography

OMG, 2001b. The Common Object Request Broker — Architecture andSpecification. OMG Formal Document formal/01-02-01, OMG, ObjectManagement Group. Version 2.4.2.

OMG, 2003a. CORBA to WSDL/SOAP Interworking Specification.OMG Formal Document formal/03-11-02, OMG, Object ManagementGroup. Version 1.0.

OMG, 2003b. Unified Modeling Language 2.0: Superstructure. OMGFinal Adopted Specification ptc/03-08-02, OMG, Object ManagementGroup.

OMG, 2003c. Unified Modeling Language Specification. OMG FormalDocument formal/03-03-01, OMG, Object Management Group. Ver-sion 1.5.

OMG, 2003d. WSDL-SOAP to CORBA Interworking. OMG Draft Ad-opted Specification ptc/03-07-04, OMG, Object Management Group.

OMG, 2003e. XML Metadata Interchange (XMI) Specification. OMGFormal Document formal/03-05-02, OMG, Object ManagementGroup. Version 2.0.

OMG, 2003f. XML/Valuetype Language Mapping. OMG Formal Doc-ument formal/03-04-01, OMG, Object Management Group. Version1.1.

Open Group, 2000. Inter-Domain Management: Specification & Inter-action Translation. Technical Standard C802, Open Group. URLhttp://www.jidm.org.

Savoye, R., 2001. DejaGNU — The GNU Testing Framework. FreeSoftware Foundation, 1.4.1 revision 0.6.1 edition.

Schieferdecker, I., Z. Dai, J. Grabowski, & A. Rennoch, 2003. The UML2.0 Testing Profile and its Relation to TTCN-3. In Proceedings of theIFIP TC6/WG6.1 15thInternational Conference on Testing of Com-municating Systems, (TestCom 2003), Sophia-Antipolis, France, editedby D. Hogrefe & A. Wiles, volume 2644 of Lecture Notes in Com-puter Science, (LNCS), pages 79–94. The International Federation forInformation Processing, IFIP, Springer Verlag. ISBN 3-540-40123-7.ISSN 0302-9743.

147

http://www.jidm.org

Bibliography

Schieferdecker, I. & J. Grabowski, 2003. The Graphical Format ofTTCN-3 in the Context of MSC and UML. In Proceedings of the3th International Workshop on SDL and MSC (SAM 2002), Tele-communications and beyond: The Broader Applicability of SDL andMSC, Aberystwyth, UK, June 24.-26., 2002. Revised Papers, editedby E. Sherratt, volume 2599 of Lecture Notes in Computer Science,(LNCS), pages 233–252. Springer Verlag. ISBN 3-540-00877-2. ISSN0302-9743.

Schieferdecker, I., M. Li, & A. Hoffmann, 1998. Conformance Testingof TINA Service Components — The TTCN/CORBA Gateway. InProceedings of the 5th International Conference on Intelligence andServices in Networks, IS&N’98, Antwerp, Belgium, May 25–28, 1998,edited by S. Trigila, A. Mullery, M. Campolargo, H. Vanderstraeten,& M. Mampaey, volume 1430 of Lecture Notes in Computer Science,(LNCS), pages 393–408. Springer Verlag. ISBN 3-540-64598-5.

Schieferdecker, I. & B. Stepien, 2003. Automated Testing of XML/SOAPbased Web Services. In 13th Fachkonferenz der Gesellschaft für In-formatik (GI) Fachgruppe "Kommunikation in verteilten Systemen"(KiVS), Leipzig, 26.–28. Febr., 2003, edited by K. Irmscher & K. Fäh-nrich. Springer Verlag. ISBN 3-540-00365-7.

Schmitt, M., 2003. Automatic Test Generation Based on Formal Spe-cifications — Practical Procedures for Efficient State Space Explor-ation and Improved Representation of Test Cases. doctoral thesis,Georg-August-Universität Göttingen, Germany. URL http://webdoc.sub.gwdg.de/diss/2003/schmitt/schmitt.pdf.

Schmitt, M. & M. Ebner, 2003. The TTCN-3 module and template con-cepts revisited. Technical Report IFI-TB-2003-02, Institut für Inform-atik, Georg-August-Universität Göttingen, Germany. ISSN 1611-1044.

Schmitt, M., M. Ebner, & J. Grabowski, 2000. Test Generation withAutolink and TestComposer. In Proceedings of the 2nd Workshopof the SDL Forum Society on SDL and MSC (SAM’2000), Grenoble,France, June 26.–28., 2000, pages 218–232.

Yin, A., 2001. Testing Operation-Based Interfaces — Exemplified forCORBA with ADL and TTCN-3. Diplomarbeit, TelecommunicationNetwork Group, Faculty of Electrical Engineering and Computer Sci-ence, Technical University Berlin, Germany.

148

http://webdoc.sub.gwdg.de/diss/2003/schmitt/schmitt.pdf

http://webdoc.sub.gwdg.de/diss/2003/schmitt/schmitt.pdf

Bibliography

Yin, A., I. Schieferdecker, & M. Li, 2001. Mapping of IDL to TTCN-3. Technical report, Fraunhofer Institute for Open CommunicationSystems (FOKUS), Germany.

149

List of Figures

1.1. Fundamental concept of the thesis . . . . . . . . . . . . . . 2

2.1. The V process model for software development (Balzert1998, page 101) . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Test generation with TestComposer and Autolink . . . 172.3. User’s view of TTCN-3 core language, presentation form-

ats, and imported types . . . . . . . . . . . . . . . . . . . . 202.4. The Inres service and protocol . . . . . . . . . . . . . . . . 222.5. The local test method applied to Inres . . . . . . . . . . . . 232.6. Message- and blocking procedure-based communication . 282.7. Conceptual view of a typical TTCN-3 test configuration . 32

3.1. UML-based test specification . . . . . . . . . . . . . . . . 443.2. MSC document example . . . . . . . . . . . . . . . . . . . 463.3. Basic MSCs for the Inres protocol . . . . . . . . . . . . . 473.4. HMSC example . . . . . . . . . . . . . . . . . . . . . . . 523.5. The CORBA architecture . . . . . . . . . . . . . . . . . . 54

4.1. Basic MSC to TTCN-3 mapping concept . . . . . . . . . 624.2. Basic instance structure to specify test cases via MSC . . . 634.3. MSC to TTCN-3 base mapping . . . . . . . . . . . . . . 674.4. MSC to TTCN-3 alternative mapping . . . . . . . . . . . 714.5. MSC to TTCN-3 optional mapping . . . . . . . . . . . . 724.6. MSC to TTCN-3 exception mapping . . . . . . . . . . . 734.7. MSC to TTCN-3 loop mapping 1 . . . . . . . . . . . . . 734.8. MSC to TTCN-3 loop mapping 2 . . . . . . . . . . . . . 744.9. MSC to TTCN-3 mapping of HMSCs . . . . . . . . . . 75

151

List of Tables

2.1. Overview of TTCN-3 types . . . . . . . . . . . . . . . . . 252.2. Overview of TTCN-3 type variants respectively useful

types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1. Overview of IDL types . . . . . . . . . . . . . . . . . . . . 56

4.1. Conceptual list of MSC to TTCN-3 mapping . . . . . . . 77

5.1. IDL to TTCN-3 literal mapping . . . . . . . . . . . . . . 815.2. IDL and TTCN-3 operators for constant expressions . . 865.3. IDL to TTCN-3 mapping for basic types . . . . . . . . . 915.4. IDL to TTCN-3 mapping for constructed types . . . . . 935.5. IDL to TTCN-3 mapping for template types . . . . . . . 955.6. IDL to TTCN-3 mapping for complex types . . . . . . . 955.7. IDL to TTCN-3 mapping for interface elements . . . . . 102

6.1. Corresponding data types for operations in TTCN-3 . . . 1126.2. Class element accessibility by access attributes . . . . . . . 115

A.1. Conceptual list of IDL mapping . . . . . . . . . . . . . . . 121A.2. Comparison of IDL, ASN.1, TTCN-2, and TTCN-3

data types . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

153