UserScenarios.md

that are essential for the specification of a test description. Some of the details can be inferred easily, while others allow for different interpretations. 
In order to narrow down the spectrum of possible interpretations, it is recommended that guidelines and conventions are defined in advance and enforced during 
the specification of the structured test objectives. This can streamline the refinement process and pave the way for standardized refinement of structured test 
objectives into test descriptions. 

The examples are provided in the textual representation for brevity and convenience. The graphical representation can be used instead as well.

### Data

6.4.2 

TDL-TO provides different means for the use of data within a 'StructuredTestObjective'. In addition to the use of defined 'DataIntances' and 'SpecialValueUse's, 
TDL-TO provides means for the specification of literal 'Value's inline, within a 'StructuredTestObjective'.

The use of defined 'DataInstance's and 'SpecialValueUse's does not require particular handling as the same 'DataInstance's can be used in the resulting 
'TestDescription's. While the concrete syntax may be different, the underlying model elements are the same. The corresponding 'DataType's may need to be 
taken into account if a 'TestConfiguration' needs to be inferred from the 'StructuredTestObjective'. Additionally, any qualifying 'Comment's used to describe 
further details related to the context of its usage may need to be interpreted according to the existing conventions (if defined). The example in Figure 6.4.2-1 
illustrates the definition of 'DataType's and 'DataInstance's in TDL-TO. The corresponding data definitions in the textual representation of TDL are shown 
in Figure 6.4.2-2. Apart from minor syntactical differences, the underlying model structures are the same. In fact, the TOP tools enable cross referencing between 
both notations so that data definitions in TDL can be reused in TDL-TO and vice-versa.

    Package data {
      Data {
        type float;
        type position with x of type float, y of type float;
        float -22; 
        float -21; 
        position startingPosition containing x indicating value -21;
      } 	
    }
    
Figure 6.4.2-1: Predefined data example in TDL-TO

    Package data {
      Type float ;
      Type position ( x of type float , y of type float ) ;
      float -22 ;
      float -21 ;
      position startingPosition ( x = -21 ) ;
    }

Figure 6.4.2-2: Corresponding data in TDL

TDL-TO permits the use of 'LiteralValue's as a flexible way for specifying the arguments of 'EventOccurrenceSpecification's. This can be useful, especially 
at an early stage, where the data structures and contents are not fixed yet. 'LiteralValue's may contain descriptions of the structure and contents of the 
'LiteralValue'. Additionally, 'LiteralValue's may be referenced within the same 'StructuredTestObjective'. Any qualifying 'Comment's used to describe further 
details related to the context of its usage may need to be interpreted according to the existing conventions (if defined).

In order to transform 'LiteralValue's, first corresponding 'DataType's and 'DataInstance's need to be inferred. Consider the following example illustrated 
in Figure 6.4.2-3, showing a 'LiteralValue' specification within an 'EventOccurrenceSpecification'. The basic structure is the same, but there are no predefined 
'DataType's and 'DataInstance's. The inferred 'DataType's and 'DataInstance's are illustrated in Figure 6.4.2-4. The inferred 'DataElement's are prefixed 
with 'inferred_' for illustrative purposes. The contextual information may provide hints for more appropriate naming. Apart from the inference, type compatibility 
and merging needs to be considered. In this example, it is assumed that 'x' and 'y' are of the same type, otherwise distinct 'DataType's need to be inferred 
as well. If a 'StructuredDataInstance' is used only once, it is also possible to specify it as inline 'DataInstanceUse' in TDL.


<figure>
<code>
    when { 
        the Controller entity sends the start position containing 
          x indicating value 22,
          y indicating value 21
      ; 
    } then {
        the Object entity moves_to the received start position
    } 
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.2-3: Literal data in TDL-TO</b></figcaption>
</figure>


<figure>
<code>
    Package inferred_data {
      Type inferred_simple ;
      Type inferred_position ( x of type inferred_simple, y of type inferred_simple) ;
      inferred_simple 22 ;
      inferred_simple 21 ;
      inferred_position inferred_start_position ( x = 22, y = 21 ) ;
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.2-4: Inferred literal data in TDL</b></figcaption>
</figure>


In case existing 'DataInstance's are used and corresponding 'DataMapping's exist, these can be reused as well. Otherwise, the 'DataMapping's can be 
defined as part of the refinement process for both existing data specifications and data specifications inferred from inline literal data specifications.

### Configurations

6.4.3 

Similar to the use of data, TDL-TO provides different means for the specification of the entities related to an 'EventOccurrenceSpecification'. Abstract 
entities can be useful, especially at an early stage, where the 'TestConfiguration's are not fixed yet. If 'TestConfiguration's are already specified, 
the corresponding 'ComponentInstances' can be used in 'EventOccurrenceSpecification's. An example for a simple 'TestConfiguration' and corresponding 
'ComponentType's and 'GateType's specified in TDL-TO is shown in Figure 6.4.3-1. The corresponding definitions in the textual representation of TDL are 
showing in Figure 6.4.3-2. The use of defined 'ComponentInstance's does not require particular handling as the same 'TestConfiguration's can be used in 
the resulting 'TestDescription's. Apart from minor syntactical differences, the underlying model structures are the same. The TOP tools enable 
cross referencing between both notations so that definitions related to 'TestConfiguration's in TDL can be reused in TDL-TO.


<figure>
<code>
    Package base_configuration {
      import all from data;
      Configuration {
        Interface Type wireless accepts position;
        Component Type unit with gate wifi of type wireless;
        Test Configuration basic containing 
          Tester component controller of type unit 
          SUT component object of type unit
          connection between controller.wifi and object.wifi
        ; 
      }
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.3-1: Predefined configuration example in TDL-TO</b></figcaption>
</figure>


<figure>
<code>
    Package base_configuration {
      Import all from data ;
      Gate Type wireless accepts position ;
      Component Type unit having {
        gate wifi of type wireless ;
      }
      Test Configuration basic {
        create Tester controller of type unit ;
        create SUT object of type unit ;
        connect controller.wifi to object.wifi ;
      }
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.3-2: Corresponding configuration in TDL</b></figcaption>
</figure>


The use of abstract entities provides more flexibility early on, however, it requires clear guidelines and conventions for the interpretation of the abstract 
entities. An 'Entity' may be transformed into a 'ComponentInstance' or a 'GateInstance' depending on the intended interpretation. Hints and conventions regarding 
the desired interpretation of an 'Entity' can be provided in the 'Entity' definition, in the context of its use, or outside the TDL-TO specification. 
Considering the example illustrated in Figure 6.4.2-3, it can be inferred that the 'Controller' entity and the 'Object' entity have some means to interact without 
this being explicitly specified. Figure 6.4.3-3 illustrates one possible 'TestConfiguration' which can be inferred from the behaviour specification in Figure 6.4.2-3. 
First, one or more 'GateType's need to be inferred, then the corresponding 'ComponentType's and their 'GateInstance's. For simplicity, it is assumed that 'Controller' 
and 'Object' are of the same 'ComponentType', conventions may be put in place to indicate that. Alternatively, subsequent refinement may further differentiate the 
'ComponentType's where appropriate. Finally, the 'TestConfiguration' is inferred, including assigning 'ComponentInstance's with corresponding roles, as well as 
'Connection's between the inferred 'GateInstance's. In this example, the roles and 'Connections' are inferred based on the 'EventOccurrenceSpecification's and their 
context (e.g. when/then clauses, etc.). Similar to 'DataType's, compatible inferred 'TestConfiguration's, 'ComponentType's, and 'GateType's need to be identified and 
merged where applicable to avoid unnecessary duplication.


<figure>
<code>
    Package inferred_configuration {
      Import all from data 
      Gate Type inferred_gate_type accepts inferred_position ;
      Component Type inferred_component_type having {
        gate inferred_gate of type inferred_gate_type ;
      }
      Test Configuration inferred_move_object {
        create Tester Controller of type inferred_component_type ;
        create SUT Object of type inferred_component_type ;
        connect Controller.inferred_gate to Object.inferred_gate ;
      }
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.3-3: Inferred configuration in TDL</b></figcaption>
</figure>



### Behaviour

6.4.4 

Initial conditions, expected behaviour, and final conditions in TDL-TO are expressed by means of 'EventSequences'. 'EventSequences' are comprised of 
'EventOccurrenceSpecification's. This provides simple generic high-level construct with loose semantics indicated by the referenced 'Event'. The 
interpretation of the 'Event' can be indicated in the domain description and/or refined in the 'EventOccurrenceSpecification'. It is recommended to establish 
well-defined specification conventions in order to ensure consistent interpretation. TDL 'TestDescriptions' require more differentiated specification of 
behaviour, distinguishing between 'Interaction's, 'Action's, and other kinds of 'Behaviour's. While some assumptions regarding the mapping of 'Event's to 
'AtomicBehaviour's can be made intuitively, it is recommended to define explicit conventions in order to ensure consistent interpretation and transformation. 
The example in Figure 6.4.4 1 illustrates a minimal 'StructuredTestObjective' containing only the specification of the expected behaviour. Assuming the data 
and configuration related information has been inferred as illustrated in the previous examples, the corresponding 'TestDescription' inferred from the 
'StructuredTestObjective' is shown in Figure 6.4.4-2. In this scenario, the first 'EventOcurrenceSpecification' in the 'whenClause' is interpreted as an 
'Interaction' between the 'Controller' and the 'Object', the latter is assumed to be the implicit opposite entity in the 'EventOcurrenceSpecification'. 
It is recommended to make opposite entities explicit whenever possible. The second 'EventOcurrenceSpecification' in the 'thenClause' is interpreted as an 
'ActionReference'. In this case, it is also necessary to infer a definition for the action.


<figure>
<code>
    Test Purpose {   
        TP Id TP_MOVE_OBJECT_LITERAL
        Test objective "Move object to destination with literal values."
        Expected behaviour 
        ensure that {
            when { 
                the Controller entity sends the start position containing 
                  x indicating value 22,
                  y indicating value 21
              ; 
            } then {
                the Object entity moves_to the received start position
            } 
        }
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.4-1: Expected behaviour specification in TDL-TO</b></figcaption>
</figure>


<figure>
<code>
    Action move_to (position of type inferred_position);
    Test Description TD_MOVE_OBJECT_LITERAL uses configuration inferred_move_object {
      Controller.inferred_gate sends inferred_start_position to Object.inferred_gate;
      perform action move_to (position = inferred_start_position) on Object;
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.4-2: Corresponding behaviour specification in TDL</b></figcaption>
</figure>

If desired, especially when 'StructuredDataInstance's are used only once, it is also possible to specify them as inline 'DataInstanceUse's in TDL. The resulting 
'TestDescription' for the example in Figure 6.4.4-1 is shown in Figure 6.4.4 3, where instead of the 'inferred_start_position' 'DataInstance', the corresponding 
data is specified inline. Since the 'DataInstance' is used twice in this case, it results in some duplication.


<figure>
<code>
    Action move_to (position of type inferred_position);
    Test Description TD_MOVE_OBJECT_LITERAL_INLINE uses configuration inferred_move_object {
      Controller.inferred_gate sends new inferred_position (x = 22, y = 21) to Object.inferred_gate;
      perform action move_to (position = new inferred_position (x = 22, y = 21)) on Object;
    } 
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.4-3: Corresponding behaviour specification in TDL using inline data</b></figcaption>
</figure>


The steps for the derivation of 'TestDescription's from 'StructuredTestObjective's can be translated to other notations as well. Fundamentally, the process 
remains the same, starting with the data definitions, through the test configurations, and finally the behaviour specifications. The above guidelines can be 
used as a template for deriving 'TestDescription's from other kinds of documents and artifacts as a starting point.

### 6.4.5 Transformation Conventions and Assumptions

The transformation of 'LiteralValue's involves the following conventions:

 - If the 'Content' of the 'LiteralValue' is empty, the 'LiteralValue' is mapped to a 'SimpleDataType' with a 'name' corresponding to the 'name' of the 'LiteralValue'. 
   If qualifier 'Comment's are present, a 'SimpleDataInstance' is created with a 'name' corresponding to the concatenated 'bodies of the qualifier 'Comment's. 
   Alternatively, the 'name' of the 'DataType' can also be prefixed with the concatenated 'bodies of the qualifier 'Comment's. If the corresponding 'DataType' or 
   'DataInstance' exists, no action is taken.
   
 - If the 'Content' of the 'LiteralValue' is not empty, the 'LiteralValue' is mapped to a 'StructuredDataType' with a 'name' corresponding to the 'name' of the 
   'LiteralValue'. If qualifier 'Comments are present, a 'StructuredDataInstance' is created with a 'name' corresponding to the concatenated 'bodies of the qualifier 
   'Comment's. Alternatively, the 'name' of the 'DataType' can also be prefixed with the concatenated 'bodies of the qualifier 'Comment's. If the corresponding 
   'DataType' or 'DataInstance' exists, no action is taken.
   
 - Each 'Content' element of the 'LiteralValue' is mapped to a 'Member' within the corresponding 'StructuredDataType' with a 'name' corresponding to the 'name' of 
   the 'Content'. If a 'Member' with the same 'name' exists, no action is taken. The 'DataType' of the 'Member' corresponds to:
   
    -	A new 'DataType' corresponding to the 'Content' with a 'name' prefixed with the 'name' of the containing 'StructuredDataType' in case a 'Content' 
      is directly contained within the 'Content'.
      
    -	A (default) 'SimpleDataType' corresponding to the 'LiteralValue' in case a 'LiteralValue' is directly contained within the 'Content'.
    
    -	The 'DataType' corresponding to the 'dataType' of the 'DataInstanceUse' in case a 'DataReference' is directly contained within the 'Content'.
    
 - Each nested 'Content' or 'LiteralValue' element is transformed according to the conventions above.
 
For example, as shown in Figure 6.4.5-1 and Figure 6.4.5-3, for the 'EventOccurrenceSpecification' taken from [i.37], a corresponding 'StructuredDataType' is 
created for both the 'LiteralValue' 'message' and for the 'payload' 'Content' of the 'message'. The 'dataType' for the 'payload' 'Member' is then set accordingly. 
Instead, since the 'value's for the 'filterLength' and 'topic_filter' Content's correspond to 'DataReference's to defined 'DataInstance's, as shown in Figure 6.4.5-2, 
the 'dataType's for the corresponding 'Member's in the derived 'SUBSCRIBE_message_payload' 'DataType' are: set to the 'dataType's of the referenced 'DataInstance's.


<figure>
<code>
      the IUT entity receives a SUBSCRIBE message containing
        payload containing
           filterLength corresponding to TOPIC_FILTER_LEN_SEC_CVE_01,
           topic_filter corresponding to TOPIC_FILTER_LEN_SEC_CVE_01;;
      from the ATTACKER_CLIENT entity
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.5-1: 'LiteralValue's and 'DataReference's example (from [i.37])</b></figcaption>
</figure>


<figure>
<code>
      Data {
        UTF8String TOPIC_FILTER_SEC_CVE_01;  // topic filter used in TP_MQTT_BROKER_SEC_CVE_001
        Int16 TOPIC_FILTER_LEN_SEC_CVE_01;   // corresponds to lengthof(TOPIC_FILTER_SEC_CVE_01) + 1
      }
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.5-2: Corresponding 'DataInstance' definitions (from [i.37])</b></figcaption>
</figure>

<figure>
<code>
      Type SUBSCRIBE_message (
        payload of type SUBSCRIBE_message_payload
      ) ;
      Type SUBSCRIBE_message_payload (
        filterLength of type Int16 ,
        topic_filter of type UTF8String
      ) ;
</code>
<figcaption style="text-align:center"> <b>Figure 6.4.5-3: Resulting 'DataType' specifications in TDL</b></figcaption>
</figure>

For the transformation of 'EventOccurrence's into 'Behaviour's, it is necessary to first derive the corresponding 'TestConfiguration' if no 'TestConfiguration' 
is specified for the 'StructuredTestObjective'. The derivation of the 'TestConfiguration' involves the following conventions:

 - Each 'EntityReference' is transformed a 'ComponentType' and a 'GateType', where the 'GateType' accepts the 'DataType's resulting from the transformation of 
   the 'LiteralValue's specified as arguments of the 'EventOccurrence'. The 'ComponentType' contains a 'GateInstance' of the transformed 'GateType'. If the 
   'ComponentType', 'GateType', or 'GateInstance' already exists, no action is taken.
   
 - A 'TestConfiguration' is constructed with 'ComponentInstance's of the 'ComponentType's resulting from the transformation above. It is recommended to use naming 
   conventions, annotations, or other conventions to indicate the roles of the 'ComponentInstance's, otherwise the roles are set to a default value of 'Tester' 
   or 'SUT' and need to be adjusted afterwards. While opposite 'EntityReference's are optional, it is recommended that they are explicitly specified, otherwise an 
   implicit 'Tester' 'ComponentInstance' needs to be assumed and constructed. If the assumption of an implicit 'Tester' does not hold, the transformed 'TestConfiguration' 
   may need to be adjusted.
   
 - Within the 'TestConfiguration', 'Connection's need to be created between interacting 'ComponentInstance's for every 'EventOccurrence'. If a 'Connection' already 
   exists, no action is taken.
   
 - Conventions or comparison between 'TestConfiguration's are recommended to avoid duplicate identical configurations.
   Once a suitable 'TestConfiguration' is derived, 'EventOccurrence's can be transformed into 'Behaviour's. There can be different strategies, ranging from 
   transforming 'EventOccurrence's into detailed 'Interaction's, to transforming 'EventOccurrence's into abstract 'TestDescription' skeletons as containers for 
   manually specified 'Behaviour's. This may depend on the general test specification process and/or the level of detail of the structured test objective specifications. 
   Assuming detailed 'Message's as the target, the following conventions can be applied:
   
 - A 'TestDescription' using the 'TestConfiguration' resulting from the transformation above is constructed as a container for the 'Behaviour's. For traceability and 
   in general, it is recommended that the 'TestDescription' references the 'StructuredTestObjective' as its 'testObjective'.
   
 - In the simplest case, the 'TestDescription' contains one 'CompoundBehaviour' which contains the individual 'Behaviour's corresponding to the 'EventOccurrence's.
 
 - If desired, the 'CompoundBehaviour' may contain further 'CompoundBehaviour's corresponding to the structural blocks of the 'StructuredTestObjective', e.g. 
   "Initial conditions", "Expected behaviour", "when/then"-clauses, etc., so that the resulting 'TestDescription' more closely reflects the structure of the corresponding 
   'StructuredTestObjective'. The additional 'CompoundBehaviour's may be annotated to clearly specify their purpose and potentially also influence how tools represent or 
   treat the individual 'Behaviour's within the additional 'CompoundBehaviour's.
   
 - The individual 'EventOccurrence's are transformed into corresponding 'Behaviour's. In the absence of further information, it needs to be specified what the default 
   'Behaviour' should be. In general, suitable conventions and 'Annotation's are recommended to ensure easier transformation. Assuming that the target 'Behaviour' is a 
   'Message', a 'Message' is constructed with the source and target 'GateReference's corresponding to the 'EntityReference's of the 'EventOccurrence'. The assumptions 
   for the transformation of 'TestConfiguration's apply in this case as well, particularly when no opposite 'EntityReference' is specified. A 'DataUse' is then constructed 
   as the argument of the 'Message' based on the 'LiteralValue' specified as the argument of the 'EventOccurrence' and the 'DataType's resulting from the transformation above.


   
## Defining Test Descriptions

6.5 

### Overview

6.5.1

In the absence of structured test objectives or other documents which can serve as a starting point, test descriptions can be defined from scratch. The fundamental steps 
in the process involve the definition of data first, then configurations, finally the behaviour. The following examples illustrate the different steps by means of the 
graphical syntax for TDL with the help of the graphical editor.

### 6.5.2 Data and Configuration

Since the 'Generic TDL' diagram accommodates both the specification of data- and configuration-related elements, both are contemplated together. If necessary, separate 
diagrams can be created instead to capture only data-related or configuration-related elements separately. In the example shown in Figure 6.5.2-1 the one diagram approach 
is shown for conciseness and also to show a complete overview of all relevant elements in one place. On the top-left side the predefined simple data types are shown. 
In the bottom part the verdict-related types and instances are shown. On the right side behaviour-related definitions for an 'Action' and a 'TestDescription' are shown. 
Finally, in the middle part, the data types, data instances, as well as component and gate types and the test configuration are shown. The graphical editor does provide 
some more flexibility with regard to the order of creation of the different elements. However, the fundamental order remains the same - data, configuration, behaviour.
 
 

![Data and configuration specification](images/DataAndConfSpecInTdlGr.png)

Figure 6.5.2-1: Data and configuration specification in TDL using the graphical editor

### Test Behaviour and Time

6.5.3 

The 'TDL Behaviour' diagram allows the visualization and specification of the behaviour of an individual 'TestDescription'. While the 'TestDescription' itself is 
defined within a 'Generic TDL' diagram, including its name, parameters, test configuration, and test objectives, the specifics of the behaviour are shown in a separate 
'TDL Behaviour' diagram. The example shown in Figure 6.5.3-1 illustrates the behaviour of the 'TD_MOVE_OBJECT' 'TestDescription'. In addition to the basic behaviour, 
temporal properties of the behaviour are illustrated with the help of a 'TimeLabel' and a 'TimeConstraint'.
 
 ![Test behaviour in TDL using the graphical editor](images/TestBehaviourInTdlInGrFormat.png)
 
Figure 6.5.3-1: Test behaviour in TDL using the graphical editor

'TestDescriptionReference's enable the reuse of behaviour definitions. While in some other high-level test specification languages the use of so-called "data tables" 
has been gaining some popularity, TDL provides more sophisticated facilities both for the definition of data and for the reuse of behaviour. A parameterized 
'TestDescription' can be invoked multiple times with different data instances as shown in the example in Figure 6.5.3-2. In the 'TC_MOVE_AROUND' 'TestDescription', 
the 'TC_MOVE_TO' 'TestDescription is invoked four times to describe a test sequence where the 'Object' needs to move to four positions.

    Test Description TC_MOVE_TO (target_position of type inferred_position) 
    uses configuration inferred_move_object {
      Controller.inferred_gate sends parameter target_position to Object.inferred_gate;
      perform action move_to (position = parameter target_position) on Object;
    }	

    Test Description TC_MOVE_AROUND 
        uses configuration inferred_move_object {
      execute TC_MOVE_TO (target_position = start_position);
      execute TC_MOVE_TO (target_position = open_position);
      execute TC_MOVE_TO (target_position = closed_position);
      execute TC_MOVE_TO (target_position = end_position);
    }	

Figure 6.5.3-2: Test behaviour reuse in TDL using test description references


## Transforming Test Descriptions into TTCN-3 Test Cases

6.6 

### Overview

6.6.1 

One way to obtain executable test cases from TDL is to transform the test descriptions into TTCN-3 code. The standardized mapping to TTCN-3 in ETSI ES 203 119-6 [i.18] 
specifies in great detail all the peculiarities that need to be considered for the derivation of executable test cases in TTCN-3 from TDL. The basic steps remain fundamentally 
the same, involve transforming the data definitions, the configuration-related definitions, as well as the behaviour specifications. All the transformations have to take 
into account the semantic gaps between both languages, as well as the intrinsic differences in the levels of abstraction. The standardized mapping is defined for locally 
ordered test descriptions only. Thus, if totally ordered test descriptions are the starting point, these first need to be transformed into locally ordered test descriptions, 
keeping in mind the differences in semantics and the additional constraints that are imposed by locally ordered test descriptions. The prototypical implementation of the 
mapping within the TOP provides automated translation for the essential parts necessary for the transformation of TDL 'TestDescription's to TTCN-3 test cases.

### Data

6.6.2 

To illustrate the mapping of the data-related elements, consider the example in Figure 6.6.2-1. It illustrates different data definitions and data uses. The corresponding 
equivalents in TTCN-3 are shown in Figure 6.6.2-2. The mappings for data are pretty straightforward in this example. Although the use of data mappings is recommended, 
in which case the respective mapping targets are used instead, it is also possible to generate basic data definitions in case no data mappings are present. 
Annotations can be used to override assumptions.

        //data types
        Type SESSIONS (id1 of type Integer, id2 of type Integer);
        Type MSG (ses of type SESSIONS, content of type String);
    
        //data instances
        SESSIONS s1(id1 = 1, id2 = 2);
        SESSIONS s2(id1 = 11, id2 = 22); 
        MSG msg1(ses = s1, content = m1);
    
        //value data instances
        SESSIONS c_s1(id1 = 1, id2 = 2) with {VALUE;}; 
        MSG c1(ses = s1, content = c1) with {VALUE;};
    
        Component Type ct having {
            //variables
            variable v1 of type MSG with {VALUE;};
            variable v2 of type MSG;
            gate g of type gt;
        }

Figure 6.6.2-1: Test data example in TDL

        //data types
        type record SESSIONS { 
            integer id1,
            integer id2
        }
        type record MSG { 
            SESSIONS ses, 
            charstring content
        }
        
        //templates
        template SESSIONS s1 := {id1:=1, id2:=2} 
        template SESSIONS s2 := {id1:=11, id2:=22} 
        template MSG msg1 := {ses := s1, content := "m1"}
        
        //value -> constant
        const SESSIONS c_s1 := {id1:=1, id2:=2}
        const MSG c1 := {ses := c_s1, content := "c1"} 
    
        type component ct {
            //variables
            var MSG v1;
            var template MSG v2;
            port gt g;
        }
        
Figure 6.6.2-2: Test data equivalents for Figure 6.6.2-1 in TTCN-3


### Configuration

6.6.3 

With regard to test configurations, there are several concerns to address. TTCN-3 provides means for the dynamic instantiation and management of test configurations. 
The essential parts of a configuration include the main test component which plays a special role, zero or more parallel test components, as well as a unified system 
interface. There is a distinction between connecting and mapping ports and there are some restrictions with regard to these. In TDL the test configuration is defined 
upfront and remains static. TDL also provides a holistic view where the SUT can be decomposed into multiple interconnected components. The example in Figure 6.6.3-1 
illustrates a minimal test configuration in TDL. The corresponding mapping in TTCN-3 is illustrated in Figure 6.6.3-2. A unified system interface needs to be inferred 
in case there are multiple SUT components. The steps for instantiating and mapping/connecting the components are encapsulated in a function.

        Gate Type defaultGT accepts 
            ACK, PDU, PDCCH, C_RNTI, CONFIGURATION ;
    
        Component Type defaultCT having {
	        gate g of type defaultGT;
        }
    
        Test Configuration defaultTC {
	        create Tester SS of type defaultCT;
	        create SUT UE of type defaultCT ;
	        connect UE.g to SS.g ;
        }

Figure 6.6.3-1: Test configuration example in TDL

    type port defaultGT_to_map message {  
      //this is a port type for SUT-Tester connections
      inout charstring, PDCCH /* ACK, PDU, C_RNTI, CONFIGURATION ; */  
    }  
    
    type port defaultGT_to_connect message { 
      //this is a port type for Tester-Tester connections 
      inout charstring, PDCCH /* ACK, PDU, C_RNTI, CONFIGURATION ; */  
    }
    
    type component MTC_CT { 
      //component type for MTC
      //variable for the PTC(s) --TESTER component(s) in TDL
      var defaultCT TESTER_SS; 
    }
      
    type component defaultCT { 
      port defaultGT_to_map g_to_map;
      port defaultGT_to_connect g_to_connect;
    }
    
    function defaultTC() runs on MTC_CT { 
      // Test Configuration defaultTC, mappings, connections
      TESTER_SS := defaultCT.create;
      map (TESTER_SS:g_to_map,system:g_to_map);
    }

Figure 6.6.3-2: Test configuration related equivalents for Figure 6.6.3-1 in TTCN-3

###  Behaviour

6.6.4

In terms of behaviour, TTCN-3 and TDL also have different assumptions. In TTCN-3, the focus is on the test system view, where all components execute their behaviour 
concurrently and independently unless there is explicit synchronization among them. TDL aims to provide a global view with the possibility to specify both locally and 
totally ordered behaviour, with explicit or implicit synchronization respectively. For the standardized mapping to TTCN-3 only the local ordering is taken into consideration. 
User-defined mappings may also tackle the totally ordered behaviour. In the example shown in Figure 6.6.4-1 a locally ordered 'TestDescription' is illustrated. The 
corresponding mappings in TTTCN-3 are shown in Figures 6.6.4-2, 6.6.4-3, and 6.6.4-4. First, the default handling needs to be taken care of. This involves the definition 
of altsteps to handle deviations from the specified behaviour as well as quiescence, which is illustrated in Figure 6.6.4-2. Then the actual test behaviour from the 
test system's point of view is translated to a function as illustrated in Figure 6.6.4-3. Finally, in Figure 6.6.4-4 a test case is defined which takes care of activating 
the default behaviour, instantiating the test configuration, as well as starting the actual test behaviour.

    Test Description Implementation TD_7_1_3_1
      uses configuration defaultTC {
        
      SS.g sends pdcch (c_rnti=ue) to UE.g;
      SS.g sends mac_pdu to UE.g;
      UE.g sends harq_ack to SS.g with {
        test objectives : TP1 ;
      };
    
      set verdict to PASS ;
      SS.g sends pdcch (c_rnti=unknown) to UE.g;
      SS.g sends mac_pdu to UE.g;
    
      alternatively {
        UE.g sends harq_ack to SS.g ;
          set verdict to FAIL ;
      } or {
          gate SS.g is quiet for five ;
        set verdict to PASS ;
      } with {
            test objectives : TP2 ;
      }
    }

Figure 6.6.4-1: Test behaviour example in TDL

    altstep to_handle_deviations_from_TDL_description_AS () {
      [] any port.receive {
        setverdict(fail);
        mtc.stop;
      }
      //if nothing happens, a timer is started  
      //before every receive instruction 
      //and the timer is here
      //or we can leave the timeout for 
      //the execute instruction called with the optional 
      //timer parameter - but in this case 
      //the final verdict will be 'error'
    }
    
    altstep quiescence_handler_AS (timer quiescence) { 
      //for all quiescence that is not connected to a gate
      [] any port.receive{ 
         setverdict(fail);
         mtc.stop;
      }
      [] quiescence.timeout {  
         setverdict(pass);
      }
    }
Figure 6.6.4-2: Required altstep definitions in TTCN-3

    function behaviourOfTESTER_SS() runs on defaultCT {
      timer quiescence;
      activate(to_handle_deviations_from_TDL_description_AS());
     
      g_to_map.send(modifies pdcch := {c_rnti := ue}) 
      g_to_map.send(mac_pdu); 
      g_to_map.receive(harq_ack);
      setverdict(pass);
      /*Test Objective Statisfied:  TP2 */                      
      
      g_to_map.send(modifies pdcch := {c_rnti := unknown}); 
      g_to_map.send(mac_pdu);
    
      quiescence.start(five);
      alt{
        [] g_to_map.receive(harq_ack){
           setverdict(fail);
        }
        [] quiescence_handler_AS(quiescence);
        /*Test Objective Statisfied:  TP2 */                      
      }             
    }
    
Figure 6.6.4-3: Behaviour mapping for Figure 6.6.4-1 in TTCN-3

    testcase TD_7_1_3_1() runs on MTC_CT 
      system defaultCT
    {
      activate(to_handle_deviations_from_TDL_description_AS());
      defaultTC();
      TESTER_SS.start(behaviourOfTESTER_SS());   
      all component.done;
    }

Figure 6.6.4-4: Test case integrating all steps for mapping Figure 6.6.4-1 to TTCN-3