UserScenarios.md

# User guides 

TDL and TOP can be used in different ways. Depending on the specific goals, different parts of TDL and TOP may be relevant for a given usage scenario. For different starting points and end goals, the following common use cases may come into question:

 - [Selected TOP user scenarios](UserScenarios.md#selected-top-user-scenarios)
 
    - [User control of the analysis level](UserScenarios.md#sec-user-control-of-the-analysislevel)
    - [Textual modelling](UserScenarios.md#sec-textual-modelling)
    - [TDL Wizards and Perspective](UserScenarios.md#sec-tdl-wizards-and-perspective)
    - [Graphical modelling](UserScenarios.md#sec-graphical-modelling)
    - [Importing protocol specifications](UserScenarios.md#sec-importing-protocol-specifications)
        - [Using TDL with OpenAPI™ Specifications](UserScenarios.md#sec-using-tdl-with-openapi-specifications)
        - [Using TDL with ASN.1 Specifications](UserScenarios.md#sec-using-tdl-with-asn-specifications)
        - [Using TDL with YANG Specifications](UserScenarios.md#sec-using-tdl-with-yang-specifications)>
    - [Creating test objectives based on TDL meta-model](UserScenarios.md#sec-creating-test-objectives-based-on-tdl-meta-model)
        - [Unified Definition of Test Puposes and Test Descriptions](UserScenarios.md#unified-definition-of-test-purposes-and-test-descriptions)
    - [Generate TD from TO](UserScenarios.md#sec-generate-td-from-to)
    - [Export to Word](UserScenarios.md#sec-export-to-word)
    - [Conversion to TTCN-3](UserScenarios.md#sec-conversion-to-tttn3)
 - [Defining Structured Test Objectives](UserScenarios.md#sec-defining-structured-test-objectives)
 - [Defining Test Descriptions](UserScenarios.md#sec-defining-test-descriptions)
 

 
 
 
 


[Defining structured test objectives (or test purposes) with the help of TDL-TO.]

- Transforming existing structured test objectives in TDL-TO into TDL test descriptions.

- Defining test descriptions with the help of TDL.

- Transforming existing test descriptions in TDL into TTCN-3 test cases.

- Transforming existing test descriptions in TDL into a target execution language (see clause 9).

- Using existing interface specifications in OpenAPI™ with TDL (see clause 8.2).

- Using existing protocol specifications in ASN.1 with TDL (see clause 8.3).

## Selected TOP user scenarios <a name="selected-top-user-scenarios"></a>

6.2 

### 6.2.1	Overview

This clause describes a set of user scenarios that illustrate just how the features of the TOP tools can be used for specific testing tasks.



### 6.2.2	User control of the analysis level <a name="sec-user-control-of-the-analysislevel"></a>

<a name="uc1-openclose"></a>
1. **Usage scenario:** The user saves and re-opens an incomplete TDL specification. The incomplete specification and associated analysis results are maintained.

2. **Usage scenario:** Incompatible assignment of types, e.g. assignment of a boolean value to integer type or exceeding the limit of a restricted list type (collection).  

3. **Usage scenario:** The user may set the level of analysis performed by TOP tool when developing the TDL test model. 

From the TDL toolbar shown in [Figure TDL toolbar](#figure-TDL-toolbar) the analysis level of the specification can be set.

<figure style="margin-left:auto; margin-right:auto; width:20%"><a id="figure-TDL-toolbar"></a>
  <img src="images/TdlToolbar.png" alt="TDL toolbar">
  <figcaption style="text-align:center; font-weight:bold">Figure: TDL toolbar</figcaption>
</figure>


The left "V" button sets the constraint validation to be automatically performed when editing the model. The selection mode is shown by marking the button with a darker 
shade when constraint validation is active. The rightmost "V" button causes the model to be analysed for syntactical errors. Errors are shown in the editor and in the problem view. 
Alternatively these settings can be controlled from the TDL menu shown in [Figure TDL Menu items](#figure-tdl-menu-items).


<figure style="margin-left:auto; margin-right:auto; width:20%"><a id="figure-tdl-menu-items" ></a>
  <img src="images/TdlMenuList.png" alt="TDL Menu items">
  <figcaption style="text-align:center; font-weight:bold">Figure: TDL Menu items</figcaption>
</figure>


### Textual modelling <a name="sec-textual-modelling"></a>

6.2.3 


1.	**Usage scenario:** Refactoring and renaming  

Reuse of existing TDL specification for which a slight modification is needed to use it in a context. E.g. a package containing TDL type definitions or configuration declarations may be re-used in a specific test specification context. To increase the readability the TDL TOP tool refactoring features may be used.
To use the rename feature, select an instance of an element and from the options when right-click on the mouse select option "Rename Element" (alternatively use key shortcut Alt + Shift + R). Type in the new element name in the dialog box.


<figure style="margin-left:auto; margin-right:auto; width:30%">
<img src="images/RenameDialog.png" alt="Rename dialog">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.3-1: Rename dialog box</figcaption>   
</figure>


In case the selected element is local to a single file the rename feature is executed inline without the Rename Element dialog.

<ol start=2>
<li> <b>Usage scenario:</b> Code formatting and syntax highlighting</li>
</ol>

The syntax coloring can be set from the "Syntax Coloring" dialog box: Open the "Window" menu and select "Preferences". Select the TDL tool used, ("TDLan2", "TDLtx", or "TDLtxi"), expand the subitems and select "Syntax Coloring".


<figure style="margin-left:auto; margin-right:auto; width:70%">
<img src="images/SyntaxColoring.png" alt="Code formatting settings">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.3-2: Code formatting settings dialog box</figcaption>   
</figure>


In the code formatting dialog box the preferences for different syntax elements can be set, see Figure 6.2.3-2.

<ol start=3>
  <li>  <b>Usage scenario:</b> Syntax auto complete</li>
</ol>

To use the syntax auto complete feature type in an initial part of a keyword or model element, press "Ctrl + Space", and the syntax auto complete options available in the context are displayed.


<figure style="margin-left:auto; margin-right:auto; width:70%">
<img src="images/SyntaxAutoCompletion.png" alt="Syntax auto complete">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.3-3: Syntax auto complete example</figcaption>   
</figure>


Press "Enter" and the selected text is inserted.

<ol start=4>
  <li> <b>Usage scenario:</b> Validation results presentation </li>
</ol>

The TOP tools support syntax check for the textual and graphical notations defined in the TDL standard. Syntax errors are indicated in the Problems view as well as in the editor as shown in Figure 6.2.3-4.


<figure style="margin-left:auto; margin-right:auto; width:70%">
<img src="images/syntaxerror.png" alt="Syntax error presentation">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.3-4: Syntax error presentation</figcaption>   
</figure>


The TOP tool offers semantic constraints check of a TDL specification. When this check is to be performed can be controlled from the TDL tool bar or the TDL menu item list. 
Either the check is performed when the "Validate TDL model" is selected or the check is performed automatically when the TDL model is updated, if the "Automatically validate 
TDL model" is selected. In Figure 6.2.3-5 an example of a semantics check is illustrated.


<figure style="margin-left:auto; margin-right:auto; width:70%">
<img src="images/ValidationView.png" alt="Constraint error presentation">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.3-5: Constraint error presentation</figcaption>   
</figure>


<ol start=5>
  <li> <b>Usage scenario:</b> Templates - usage and definition </li>
</ol>  
  
For each of the notations supported by the TOP tools the specific editor provides templates available in the context of the cursor position. The templates available at a given 
cursor position are shown when "Ctrl + Space" are pressed. When a template is selected pressing "Enter" inserts the template and allows for parameters to be modified.
An example of templates available in the context of a configuration specification is shown in Figure 6.2.3-6.


<figure style="margin-left:auto; margin-right:auto; width:70%">
<img src="images/TemplatesInContext.png" alt="Templates available in a configuration specification context">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.3-6: Templates available in a configuration specification context</figcaption>   
</figure>


The user may define additional templates for the different editors available in the TOP tool. The template editor is accessed via the "Window" menu item, option "Preferences". 
From the Preferences dialog box the specific TOP editor can be selected and user-defined templates be created. Figure 6.2.3-7 illustrates a list of templates defined for the 
TDLtx editor.


<figure style="margin-left:auto; margin-right:auto; width:70%">
<img src="images/TDLtxTemplates.png" alt="Template dialog box">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.3-7: Template dialog box</figcaption>   
</figure>


### 6.2.4 TDL Wizards and Perspective  <a name="sec-tdl-wizards-and-perspective"></a>

Wizards provide support to create functional TDL project either with textual or graphical models according to user choice:
1.	**User scenario:** Create new TDL project
2.	**User scenario:** Reference to predefined model elements
3.	**User scenario:** Using predefined skeletons
4.	**User scenario:** Importing interface specifications

In order to create a new TDL specification:- Select from File menu item New and in the submenu select "Project". In the dialog box "Select a wizard", select the wanted 
TDL project, e.g. TDLtx for a textual TDL specification.


<figure style="margin-left:auto; margin-right:auto; width:50%">
<img src="images/NewProjectSelectWizard_TextualProject.png" alt="Wizard selection dialog box">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.4-1: Wizard selection dialog box</figcaption>   
</figure>


Press "Next" and in the dialog box specify a name of the project to be create. If the default location is not to be used, uncheck the "Use default location" and specify 
the location of the project.


<figure style="margin-left:auto; margin-right:auto; width:50%">
<img src="images/NewProjectTextualProjectName.png" alt="Creating a new template TDL project">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.4-2: Creating a new template TDL project</figcaption>   
</figure>


Select "Next" to open the dialog box for select among parameterized TDL textual project templates.


<figure style="margin-left:auto; margin-right:auto; width:50%">
<img src="images/NewProjectSelectTemplate.png" alt="Create new TDL project with support for OpenAPI">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.4-3: Create new TDL project with support for OpenAPI</figcaption>   
</figure>



Select template "TDLtx" and press "Next" to get further options to configure the TDL project.


<figure style="margin-left:auto; margin-right:auto; width:50%">
<img src="images/NewProjectSelectBasicTDLtxProject.png" alt="Create new TDL project with advanced options features">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.4-4: Create new TDL project using the advanced options features</figcaption>   
</figure>



In this dialog box the additional properties of the project may be configured.
If "Advanced" option is set the following options can be selected: 

- The name of path of the project files
- The imported packages
- The name of the project package, default is "Main"

### 6.2.5 Graphical modelling  <a name="sec-graphical-modelling"></a>

1. **User scenario:** The TOP tool should provide ways to manage diagrams of model elements (create, delete, rename, open).
2. **User scenario:** Visual representation of all model elements should be implemented according to specification.
3. **User scenario:** All model elements and features should be editable either directly on the diagram or via property view.
4. **User scenario:** Negative validation results should be indicated graphically and linked to problem reports.

To define a TDL model using the graphical editor of the TOP tools, select menu "File" and in the menu select "New "and in the sub-menu list select "TDL project" or 
use shortcut "Alt-Shift-N". The dialog box shown in Figure 6.2.5-1 appears and a project name can be specified.


<figure style="margin-left:auto; margin-right:auto; width:50%">
<img src="images/TDLgrNewProj.png" alt="Create new TDL graphical project">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.5-1: Create a new TDL project using the graphical editor</figcaption>   
</figure>



When the "Finish" button is selected the project is created. In the "Project Explorer " select the project, press the right mouse button, and select option 
"Create Representation" and the dialog box shown in Figure 6.2.5-2 allow to create a new diagram.


<figure style="margin-left:auto; margin-right:auto; width:50%">
<img src="images/TDLgrNewRepresentation.png" alt="Create new TDL graphical diagram">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.5-2: Create a new diagram</figcaption>   
</figure>


There are two types of diagrams to create:
 
- "Generic TDL" diagram used to specify the package structure, test descriptions, configurations and data;
- "TDL Behaviour" diagram that defines the behaviour of a test description.

Select the type of diagram to be created, assign a name to the diagram, and press "Finish" to create the diagram.

NOTE:	Initially it is only possible to create a "Generic TDL" diagram as to create a "TDL Behaviour" diagram at least one test description is needed.

The editors for the two types of diagrams provides access to all graphical elements of the TDL language. The textual parameters can be edited either directly in the graphical 
element or in the Properties View of a selected element. In Figure 6.2.5-3 the editor for "Generic TDL " diagrams is shown. 

<figure style="margin-left:auto; margin-right:auto; width:50%">
<img src="images/GenericTdlGrEditor.png" alt="Generic TDL diagram editor">
<figcaption style="text-align:center; font-weight:bold">Figure 6.2.5-3: Generic TDL diagram editor</figcaption>   
</figure>



Both diagram editors have a pane with all the elements that can be used in the diagram. From the top tool bar a number of general edit functions are available, e.g. select 
all elements, show and hide elements. Also from the top tool bar the export diagram as an image file is available. The "Properties" view of the editor allows to define the 
textual parameters of a selected graphical element.

### 6.2.6 Importing protocol specifications  <a name="sec-importing-protocol-specifications"></a>

The TOP tools support importing external data specifications to TDL data representations with mapping information to the original data specifications. All importers for the 
external use the "Translate Input to TDL Model" from the "TDL" menu or alternatively the >T> icon on the TDL tool bar. The generated TDL file depends on the type of project 
the external specification is imported to. The naming convention for the TDL file generated is the original file name extended with "-generated" and with extension according 
to the importing TDL model type.

1. **Usage scenario:** Importing OpenAPI specifications according to ETSI EG 203 647 [i.32].

For OpenAPI specifications the TOP tools currently supports:
- Importing of data definitions under components/schemas.
- Data mappings to the base OpenAPI definition for traceability.
- Data mappings to the target (Java) data implementation derived from the OpenAPI definitions for executability.


#### 8.2 Using TDL with OpenAPI™ Specifications  <a name="sec-using-tdl-with-openapi-specifications"></a>

### 8.2.1	Overview

The OpenAPI™ Specification [i.31] (previously known as the Swagger Specification) is a notation for the specification of interfaces for RESTful web services. 
In addition to data-related information, OpenAPITM specifications also include paths to identify resources by means of URLs, along with applicable operations, 
and corresponding request and response specifications. While these can be used to derive skeletons for structured test objectives and test descriptions as 
outlined in ETSI EG 203 647 [i.32], within the present document, the focus is solely on data-related information. Further information and guidelines regarding 
the use of OpenAPI™ for specification and testing at ETSI can be found in ETSI EG 203 647 [i.32].

In addition to a set of primitive data types, OpenAPI™ provides means for defining structured data types. The specification is an extension of the JSON schema 
[i.33]. Data type schemas may be defined inline or in a schemas object which enables reuse of those definitions. In the present document, only the latter is 
considered. Future editions may add guidelines for inline data definitions as well.


The built-in primitive  types in OpenAPI™ are mapped to TDL according to the conventions in Table 8.2.1-1. The mapping relies on a TDL library of predefined types and constraints. 
As OpenAPI™ specifications may include format specifications for types, a generic constraint (OpenAPIFormat) with corresponding quantifiers may be used to capture this 
information in the derived TDL data model. Non-standard formats may be present in an OpenAPITM specification as well. The generic constraint can be used for such formats as well.




<table style="margin-left:auto; margin-right:auto">
<caption style="font-weight:bold"> Table 8.2.1-1: OpenAPI™ Built-in Type Mapping </caption>
<tr>
  <th>OpenAPI™</th>  <th>Type in TDL</th>  <th>Constraints</th>  <th>Formats and Patterns</th>
</tr>
<tr>
  <td> integer </td> <td> integer </td>  <td> OpenAPIFormat </td> <td>  int32, int64 </td>
</tr>
<tr>
  <td> number </td> <td> String </td>  <td> OpenAPIFormat </td> <td> float, double </td>
</tr>
<tr>
  <td> string </td> <td> String </td>  <td> OpenAPIFormat </td> <td> e-mail, password </td>
</tr>
<tr>
  <td> boolean </td> <td> Boolean </td>  <td>             </td> <td>              </td>
</tr>
</table>




A structured type in OpenAPI™ is either an 'array' with member type declaration ('items' object) or an 'object' with a set of properties ('properties' object). Consequently, the transformation of OpenAPI™ data types into TDL data types involves the following conventions:
-  If the data type corresponds to one of the primitive data types within the OpenAPI™ library as indicated in Table 8.2.1-1, the 'Type' is mapped to the corresponding 'SimpleDataType' from Table 8.2.1-1.

- If the data type is an 'object', it is mapped to a 'StructuredDataType' with a 'name' corresponding to the name of the OpenAPI™ data type. 

- If the data type is an 'array', it is mapped to a 'CollectionDataType' with a 'name' corresponding to the name of the OpenAPI™ data type. The data type indicated in the 'items' object is mapped to the corresponding 'DataType' as the 'itemType' of the 'CollectionDataType'. If 'minItems' and 'maxItems' are specified for the 'array', the corresponding predefined constraints need to be added to the 'CollectionDataType'.

- Each item in the 'properties' object of the 'object' object is mapped to a 'Member' within the corresponding 'StructuredDataType' with a 'name' 
  corresponding to the property. If a 'Member' with the same 'name' exists, no action is taken. All 'Members are to be marked as optional, except for 
  'Member's corresponding to properties which are listed in the 'required' array of the 'object'. The 'dataType' of the 'Member' corresponds to:
  
    - A new 'DataType' corresponding to the 'type' of the property with a 'name' prefixed with the 'name' of the containing 'StructuredDataType' 
      in case a property is of 'type' 'object'.
      
    - A 'SimpleDataType' corresponding to the 'type' of the property in case the 'SimpleDataType' is one of the predefined 'DataType's within the 
      OpenAPI™ library as indicated in Table 8.2.1-1. 
      
- Nested 'objects are transformed according to the conventions above.

- If the property contains an 'enum' array, it is mapped to an 'EnumDataType' with a 'name' corresponding to the name of the property. The items contained in the 'enum' array 
  are mapped to 'SimpleDataInstance's of the 'EnumDataType' that are contained in the 'EnumDataType'. 
  
- Corresponding 'DataElementMapping's are created for the defined data types. 'DataElementMapping's for 'DataType's derived from anonymous (inline) data types are not created. 
  The 'DataElementMapping's may include target platform mappings in addition to the source mappings to the OpenAPI™ specifications.
  
### 8.2.2 Examples

As an example consider the OpenAPI™ snippet shown in Figure 8.2.2-1 and the derived TDL data type model snippet showing in Figure 8.2.2-2. Corresponding 
'StructuredDataType's are created for both the 'Library' and 'LibraryBook' data types, as well as for the nested anonymous 'object's and 'array's, which 
 are prefixed with 'Library___' and 'LibraryBook___' accordingly. This would also apply to additional anonymous 'object's and 'array's nested further within 
 the 'object's. The 'dataType's for the corresponding 'Member's are then set accordingly. Finally, both source and target (for Java in this example) 
 'DataElementMapping's are provided.
 
<figure>
<code>
    
    components:
      schemas:
        LibraryBook:
          type: object
          properties:
            title:
          type: string
            authors:
              type: array
              items:
                type: string
            reviewers:
              type: array
              items:
                type: string
        Library:
          type: object
          properties:
            address:
              type: string
            books:
              type: array
              items:
                $ref: '#/components/schemas/LibraryBook'
</code>
<figcaption style="text-align:center"> <b>Figure 8.2.2-1: OpenAPI™ example including nested anonymous data types</b></figcaption>
</figure>


<figure>
<code>
    
    Type LibraryBook (
        String title,
        LibraryBook___authors authors,
        LibraryBook___reviewers reviewers
    )
    Collection LibraryBook___authors of String
    Collection LibraryBook___reviewers of String
    
    Type Library (
        String address,
        Library___books books
    )
    Collection Library___books of LibraryBook
    
    Use "mapping_conventions.yaml" as SOURCE_MAPPING
    Use "generated/java" as TARGET_MAPPING
    Map LibraryBook to "#/components/schemas/LibraryBook" 
      in SOURCE_MAPPING as LibraryBook_SOURCE_MAPPING
    Map LibraryBook to "LibraryBook" 
      in TARGET_MAPPING as LibraryBook_TARGET_MAPPING
    Map Library to "#/components/schemas/Library" 
      in SOURCE_MAPPING as Library_SOURCE_MAPPING
    Map Library to "Library" 
      in TARGET_MAPPING as Library_TARGET_MAPPING
</code>
<figcaption style="text-align:center"> <b>Figure 8.2.2-2: Corresponding flattened TDL definitions for Figure 8.2.2-1</b></figcaption>
</figure>



<ol start=2>
  <li> <b>Usage scenario:</b> Importing RESTCONF and YANG specifications.</li>
</ol>

The TOP tools support for importing RESTCONF and YANG data specifications is offered by the conversion of JSON specifications. For YANG data specifications this means 
that they have to be converted to JSON specifications.

<ol start=3>
  <li> <b>Usage scenario:</b> Importing ASN.1 specifications.</li>
</ol>


ASN.1 data specifications can be converted to a TDL data model. Further details on how to use TDL with ASN.1 data specifications are defined in 
**clause 8.3 of the present document**.

 #### Using TDL with ASN.1 Specifications <a name="sec-using-tdl-with-asn-specifications"></a>

8.3

### Overview

8.3.1 

ASN.1 (Abstract Syntax Notation One) Recommendation ITU T X.680 [i.34] is a standardized language for the specification of data types and data structures. As the name implies, the specifications are abstract and therefore independent of a specific target platform. The specifications provide the information about the structure and encoding of the data which can be processed by generators or compilers to produce data type implementations for the desired target language and platform, including codecs for encoding and decoding the data for transmission. While TDL is not concerned with the encoding and decoding at the specification level, in many cases the test execution platform needs to include codes for the operationalisation of the tests. 

When ASN.1 specifications are imported in TDL, the level of detail may vary from the bare essentials, including the data types only, to including additional constraints, and even encoding information (where applicable). The additional information can be utilised for early validation of the TDL specifications. While it is also possible to specify constant values in ASN.1, these are not covered in the guidelines at present.

ASN.1 includes a set of built-in types, some of which are mapped to TDL according to the conventions in Table 8.3.1-1. The mapping relies on a TDL library of predefined types and constraints. The generic constraints (ASN1String, ASN1DateTime, ASN1Real, ASN1ObjectIdentifier) may be used to provide additional patterns for the contents of data instances of the corresponding data types to facilitate validation. Alternatively, a tool may implement implicit validation based on the underlying types.


<table style="margin-left:auto; margin-right:auto">
<caption> <b>Table8.3.1-1: ASN.1 Built-in Type Mapping </b></caption>

<tr>
<th>ASN.1 Type</th>  <th>Type in TDL</th>  <th>Constraints</th>  <th> Patterns</th> <th> Examples </th>
</tr>
<tr>
  <td> <b>BITSTRING</b> </td>  <td> BITSTRING </td>  <td> ASN1String </td> <td> [0|1]+'B </td> <td> "1101'B", also "Named BITS" () </td>
</tr>
<tr>
  <td> <b>OCTETSTRING</b> </td>  <td> OCTETSTRING </td>  <td> ASN1String </td> <td>  [A-F|0-9]+'H  </td> <td> "A3B2'H", "10010'B" </td>
</tr>
<tr>
  <td> <b>BMPString</b> </td>  <td> BMPString </td>  <td> ASN1String </td> <td> 16 bit Character </td> <td> </td>
</tr>
<tr>
  <td> </b>IA5String</b> </td>  <td> IA5String </td>  <td> ASN1String </td> <td>  8 bit ASCII </td>  <td> "Hallo" </td>
</tr>
<tr>
  <td> <b>GeneralString</b> </td>  <td> GeneralString </td>  <td> ASN1String </td> <td>  all graphic/character sets, <br> SPACE, DELETE </td> <td> </td>
</tr>
<tr>
  <td> <b>NumericString</b> </td>  <td> NumericString </td>  <td> ASN1String </td> <td>  [0-9, SPACE]+  </td> <td> "34 8" </td>
</tr>
<tr>
  <td> <b>PrintableString</b> </td>  <td> PrintableString </td>  <td> ASN1String </td> <td>  [a-z,A-Z,'()+,-.?:/=,SPACE]  </td> <td "Black, Blue + Brown" </td>
</tr>
<tr>
  <td> <b>TeletexString</b> </td>  <td> TeletexString </td>  <td> ASN1String </td> <td>  CCITT T.101 </td> <td> </td>
</tr>
<tr>
  <td> <b>T61String</b> </td>  <td> T61String </td>  <td> ASN1String </td> <td>  CCITT T.101 </td>  <td>  </td>
</tr>
<tr>
  <td> <b>UniversalString</b> </td>  <td> UniversalString </td>  <td> ASN1String </td> <td> ISO10646 </td>  <td>   </td>
</tr>
<tr>
  <td> <b>UTF8String</b> </td>  <td> UTF8String </td>  <td> ASN1String </td> <td> ASCII + Control </td> <td>    </td>
</tr>
<tr>
  <td> <b>VideotexString</b> </td>  <td> VideotexString </td>  <td> ASN1String </td> <td> CCITT T.100, T.101 </td> <td>    </td>
</tr>
<tr>
  <td> <b>VisibleString</b> and <br> <b>ISO646String</b> </td>  <td> VisibleString </td>  <td> ASN1String </td> <td> ASCII Printing </td> <td>    </td>
</tr>
<tr>
  <td> <b>UTCTime</b>  </td>  <td> UTCTime  </td> <td> ASN1DateTime </td>  <td> YYMMDDhhmm[ss]Z </td> <td>  "991231235959+0200"  </td>
</tr>
<tr>
  <td> <b>GeneralizedTime</b> </td> <td> GeneralizedTime </td> <td> ASN1DateTime </td>  <td> YYYYMMDDHH[MM[SS[.fff]]]Z <br> (ISO 8601 [i.38]) </td> <td> "20200425175522.214+0200"  </td>
</tr>
<tr>
  <td> <b>DATE</b>  </td> <td> Date </td> <td> ASN1DateTime </td>   <td> YYYY-MM-DD </td> <td> "1636-09-18"  </td>
</tr>
<tr>
  <td> <b>TIME-OF-DAY</b>  </td> <td> TimeOfDay </td> <td> ASN1DateTime </td>   <td> HH:mm:ss </td> <td> "18:30:23"  </td>
</tr>
<tr>
  <td> <b>DATE-TIME</b>  </td>  <td> DateTime </td>  <td> ASN1DateTime </td>   <td> YYYY-MM-DDThh:mm:ss </td> <td> "2000-11-22T18:30:23"  </td>
</tr>
<tr>
  <td> <b>INTEGER</b> </td> <td> Integer </td>   <td>  </td>    <td>  </td>   <td>  </td>
</tr>
<tr>
  <td> <b>REAL</b> </td> <td> String </td>  <td> ASN1Real  </td>   <td>  </td>  <td>  </td>
</tr>
<tr>
  <td> <b>BOOLEAN</b> </td> <td> Boolean </td>   <td>  </td>   <td>  </td>  <td>  </td>
</tr>
<tr>
  <td> <b>NULL</b> </td> <td> Null </td>   <td>  </td>   <td>  </td>  <td>  </td>
</tr>
<tr>
  <td> <b>OBJECT IDENTIFIER</b> </td> <td> ObjectIdentifier </td>   <td> ASN1ObjectIdentifier </td>   <td>  </td> <td> id-ssp OBJECT IDENTIFIER ::= { itu-t (0)  <br> identified-organization (4) etsi (0) <br>  smart-secure-platform (3666) part1 (1) } </td>
</tr>

<tr>
  <td> <b>RELATIVE OBJECT IDENTIFIER<b> </td> <td> ObjectIdentifier </td>   <td> ASN1ObjectIdentifier </td>   <td>  </td> <td> Relative_id_ssp RELATIVE-OID ::= <br> { smart-secure-platform (3666) part1 (1) } </td>
</tr>
 
</table>



The transformation of ASN.1 data types into TDL data types involves the following conventions:

- If the data type corresponds to one of the predefined 'DataType's within the ASN.1 library as indicated in Table 8.3.1-1, the ASN.1 'Type' is mapped 
to the corresponding TDL 'SimpleDataType' from Table 8.3.1-1. For the supported ASN.1 types the following additional restrictions apply:
 
    -	NULL type is only used in the scope of a Choice type where if there is no information, the corresponding alternative is activated.

-	If the ASN.1 data type is a 'SequenceType', a 'SetType', or a 'ChoiceType', it is mapped to a 'StructuredDataType' with a 'name' corresponding to the name of the ASN.1 data type. In the case of 'ChoiceType', a 'Constraint' with the predefined 'union' 'ConstraintType' is applied to the corresponding 'StructuredDataType', and all 'Members are marked as optional.

  If the ASN.1 data type is a 'SequenceOfType' or a 'SetOfType', it is mapped to a 'CollectionDataType' with a 'name' corresponding to the name of the ASN.1 data type. The 'Type' indicated for the 'SequenceOfType' or 'SetOfType' is mapped to the corresponding 'DataType' as the 'itemType' of the 'CollectionDataType'.
  
- Each 'ComponentType' in the 'ComponentTypeList' of the 'SequenceType', 'SetType', or 'ChoiceType' is mapped to a 'Member' within the corresponding 'StructuredDataType' with a 'name' corresponding to the 'identifier' of the 'ComponentType'. 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 'Type' of the 'ComponentType' with a 'name' prefixed with the 'name' of the containing 'StructuredDataType' in case a 'ComponentType' is directly contained within another 'ComponentType'.
     
    - A 'SimpleDataType' corresponding to the 'Type' of the 'ComponentType' in case the 'SimpleDataType' is one of the predefined 'DataType's within the ASN.1 library as indicated in Table 8.3.1-1. 

 - Nested 'ComponentType's are transformed according to the conventions above.
 
- If the ASN.1 data type is an 'EnumeratedType', it is mapped to an 'EnumDataType' with a 'name' corresponding to the name of the ASN.1 data type. The contained 'EnumerationItem's are mapped to 'SimpleDataInstance's of the 'EnumDataType' that are contained in the 'EnumDataType'. There are no guidelines for 'NamedNumber's at present. 

- Corresponding 'DataElementMapping's are created for the defined data types. 'DataElementMapping's for 'DataType's derived from anonymous (inline) data types are not created. The   'DataElementMapping's may include target platform mappings in addition to the source mappings to the ASN.1 specifications.

For the following built-in types not mentioned in Table 8.3.1-1, the transformations to TDL types are done as follows:

- UnrestrictedCharacterStringType: Replace the CHARACTER STRING type with its associated type obtained by expanding inner subtyping in the associated type of the CHARACTER STRING type (see clause 44.5 of Recommendation ITU-T X.680 [i.34]) to the corresponding TDL type.

- EmbeddedPDVType: Replace any EMBEDDED PDV type with its associated type obtained by expanding inner subtyping in the associated type of the EMBEDDED PDV type (see clause 36.5 of Recommendation ITU-T X.680 [i.34]) to the corresponding TDL type.

- ExternalType: replace the EXTERNAL type with its associated type obtained by expanding inner subtyping in the associated type of the EXTERNAL type (see clause 37.5 of Recommendation ITU-T X.680 [i.34]) to the corresponding TDL type.

- InstanceOfType: Replace the INSTANCE OF type with its associated type obtained by substituting INSTANCE OF DefinedObjectClass by its associated ASN.1 type (see clause C.7 of Recommendation ITU T X.681 [i.36]) and map all ASN.1 types to their TDL types according to Table 8.3.1-1. 


### Examples

8.3.2 

For example, as shown in Figure 8.3.2-1 and Figure 8.3.2-2, for the 'NodeDescriptor' and related type definitions taken from [i.35], a corresponding 'StructuredDataType' is created, 
including derived 'DataType's for the nested 'aNode' anonymous 'ContentType', as well as the 'aLink', 'aFile', and 'aDirectory' anonymous 'ContentType's nested further within the 
'aNode' 'ContentType'. The 'dataType's for the corresponding 'Members are then set accordingly. The 'DataType' for the 'NodeIdentity' type as well as the derived 'DataType' for the 
'aNode' 'Member' are assigned a 'Constraint' with the 'union' 'ConstraintType'.


<figure>
<code>
    
    NodeDescriptor ::= SEQUENCE
    {
        aNodeName NodeName,  -- Node name
        aShortName UUID,  -- Short node name
        aNode CHOICE
        {
            aLink SEQUENCE
            {
                aLinkedFileIdentity NodeIdentity,  -- Identity of the linked SSP file
                aLinkedFileSize FileSize  -- Size of the linked SSP file
            },
            aFile SEQUENCE
            {
                aFileSize FileSize  -- Size of the SSP file
            },
            aDirectory SEQUENCE
            {
            }
        },
        aMetaData SEQUENCE OF MetaDatum OPTIONAL,  -- Optional meta data
        aACL SET OF AccessControl OPTIONAL  -- Access Control List attribute
    }
    
    /* Node identity */
    NodeName ::= UTF8String (SIZE(1..16))  -- node name encoded in UTF-8
    NodeReference ::= SEQUENCE (SIZE(1..6)) OF NodeName  -- pathname and node name
    
    NodeIdentity ::= CHOICE
    {
        aShortName UUID,  -- UUID of file reference using absolute pathname
        aNodeReference NodeReference  -- Node reference
    }
</code>
<figcaption style="text-align:center"> <b>Figure 8.3.2-1: ASN.1 example including nested anonymous data types (excerpt from [i.35])</b></figcaption>
</figure>


<figure>
<code>
     
      Type NodeDescriptor (
        aNodeName of type NodeName,
        aShortName of type UUID ,
        aNode of type NodeDescriptor___aNode ,
        optional aMetaData of type NodeDescriptor___aMetaData ,
        optional aACL of type NodeDescriptor___aACL
      );
      Type NodeDescriptor___aNode { union } (
        aLink of type NodeDescriptor___aNode___aLink,
        aFile of type NodeDescriptor___aNode___aFile ,
        aDirectory of type NodeDescriptor___aNode___aDirectory
      );
     
      Collection NodeDescriptor___aMetaData of type MetaDatum;
      Collection NodeDescriptor___aACL of type AccessControl;
      
      Type NodeIdentity { union } (
        aShortName of type UUID,
        aNodeReference of type NodeReference
      );
      Collection NodeReference of type NodeName;
      Type NodeDescriptor___aNode___aLink (
        aLinkedFileIdentity of type NodeIdentity,
        aLinkedFileSize of type FileSize
      );
      Type NodeDescriptor___aNode___aFile (
        aFileSize of type FileSize
      );
</code>
<figcaption style="text-align:center"> <b>Figure 8.3.2-2: Corresponding TDL definitions (excerpt) for Figure 8.3.2-1</b></figcaption>
</figure>


As an example consider the ASN.1 snippet shown in Figure 8.3.2-3 and the derived TDL data type model snippet showing in Figure 8.3.2-4. Corresponding 'StructuredDataType's are 
created for both the 'Library' and 'Document' data types, as well as for the nested anonymous 'ContentType's, which are prefixed with 'Library___' and 'Document___' accordingly. 
This would also apply to additional anonymous 'ContentType's nested further within the 'ContentType's. The 'dataType's for the corresponding 'Members are then set accordingly. 
The derived 'DataType' 'Document___number' for the 'number' 'ContentType' of type 'CHOICE' is assigned a 'Constraint' with the 'union' 'ConstraintType'. Default values are not 
present in the derived TDL data model, as TDL does not support default values for type definitions. However, a data type implementation in the target platform may include default 
values. In TDL it is possible to define a data instance which provides default values which can be overridden when the data instance is used. Finally, source 'DataElementMapping's 
are provided.


<figure>
<code>
    
     Library ::= SEQUENCE {
       address   UTF8String DEFAULT "Sophia-Antipolis, France", 
       documents SEQUENCE OF Document
     }
    
    Document ::= SEQUENCE {
       title     UTF8String (SIZE(1..128)),
       status    ENUMERATED {draft, published, historical},
       authors   SEQUENCE OF UTF8String,
       number    CHOICE { 
          es     INTEGER,  
          eg     INTEGER,
          tr     INTEGER  
       }  OPTIONAL,
       updated   DATE
    }
</code>
<figcaption style="text-align:center"> <b>Figure 8.3.2-3: ASN.1 example including nested anonymous data types</b></figcaption>
</figure>


<figure>
<code>
    
    Type Library (
      address of type UTF8String,
      documents of type Library___documents
    );
    Type Document (
      title of type UTF8String,
      status of type Document___status ,
      authors of type Document___authors ,
      optional number of type Document___number ,
      updated of type Date
    );
    Collection Library___documents of type Document;
    Collection Document___authors of type UTF8String;
    Type Document___number { union } (
      es of type Integer,
      eg of type Integer ,
      tr of type Integer
    );
    Enumerated Document___status {
      Document___status draft;
      Document___status published;
      Document___status historical;
    }
    Use "example-1-library.asn" as SOURCE_MAPPING;
    Map Library to "Library" in SOURCE_MAPPING as Library_MAPPING;
    Map Document to "Document" in SOURCE_MAPPING as Document_MAPPING;
</code>
<figcaption style="text-align:center"> <b>Figure 8.3.2-4: Corresponding flattened TDL definitions (excerpt) for Figure 8.3.2-3</b></figcaption>
</figure>

#### Using TDL with YANG Specifications <a name="sec-using-tdl-with-yang-specifications"></a>

*TBD*

### Creating test objectives based on TDL meta-model <a name="sec-creating-test-objectives-based-on-tdl-meta-model"></a> 

6.2.7 

1. **User scenario:** Use the core TDL syntax for specifying test objectives.

The TOP tool editors for the standardised textual syntax in ETSI ES 203 119-8 [i.20] support the extended syntax for structured test objectives in ETSI ES 203 119-4 [i.16]. Details on how to use one of the TOP tool textual editors to define structured test objectives are described in **clause 6.7 of the present document**.



#### Unified Definition of Test Puposes and Test Descriptions <a name="unified-definition-of-test-purposes-and-test-descriptions"></a>

6.7

### Overview

6.7.1 

With the standardised textual notation for TDL, a new unified syntax was also introduced to allow specifying test purpose-like test descriptions. 
Using this notation, users can start from a more abstract test purpose, and gradually add to the necessary details to reach executable specifications, 
all while using the same concepts and constructs, without the need to switch and transform between different notations. To achieve this, users can start 
with a template provided by the specialised syntax for 'Test Purpose Description's, which contains the necessary behaviour blocks and compartments, which 
reflect the structure of a 'Structured Test Objective'. While the structure is near identical, the contents are specified as TDL 'Behaviour's rather than 
TDL-TO 'EventOccurrence's. Thus, only the notation for 'Behaviour's is available and data and configuration definitions need to be available. However, 
the configuration and behaviour specifications can be simplified at first, e.g. by using 'Inline Action's which can be refined into more specific 
'Behaviour's such as 'Message's over time.   


<figure>
<code>
    
    Objective TO_MOVE_OBJECT_UNIFIED {
        Description: "Move object to destination with unified test purpose description."
    }
    
    Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
        Objective: TO_MOVE_OBJECT_UNIFIED
        Configuration: basic
        Expected behaviour 
        ensure that {
            when { 
                perform action: "the Controller sends the starting position" 
            } then {
                perform action: "the Object moves to the requested position"
            } 
        }
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.7.1-1: Unified definition of test purposes and test descriptions</b></figcaption>
</figure>


<figure>
<code>
    
    Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
      Objective: TO_MOVE_OBJECT_UNIFIED
      Configuration: basic
      Expected behaviour 
      ensure that {
          when { 
              perform action: "the Controller sends the starting position" 
              controller::wifi sends "x=21, y=21" to object::wifi
          } then {
              perform action: "the Object moves to the requested position"
              controller::wifi receives "x=21, y=21" from object::wifi
          } 
      }
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.7.1-2: Unified definition of test purposes and test descriptions with refinements</b></figcaption>
</figure>


<figure>
<code>
    
    Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
      Objective: TO_MOVE_OBJECT_UNIFIED
      Configuration: basic
      Expected behaviour 
      ensure that {
          when { 
              perform action: "the Controller sends the starting position" 
              controller::wifi sends position (x = 21, y = 21) to object::wifi
          } then {
              perform action: "the Object moves to the requested position"
              controller::wifi receives position (x = 21, y = 21) from object::wifi
          } 
      }
    }
</code>
<figcaption style="text-align:center"> <b>Figure 6.7.1-3: Unified definition of test purposes and test descriptions with further refinements</b></figcaption>
</figure>


As shown in Figure 6.7.1-1, the test objective is specified separately and referenced within the test purpose description. The test purpose description itself references a 
test confederation and has the familiar expected behaviour pattern with the when and then blocks. For simplicity, stimulus and response can be initially specified as inline 
actions. In this case, the action descriptions are expressed in plain text. At a later stage, the behaviour can be further refined, for example by using message exchanges, 
but without yet defining and using any the data types, as shown in Figure 6.7.1-2. Eventually, when the data types are known and defined, they can be used as subsequent 
refinement of the behaviour, as shown in Figure 6.7.1-3. Finally, they might even be defined as parameters, as the test purpose description gradually includes sufficient 
detail to become executable.

<figure>
<code>
    
    Objective: TO_MOVE_OBJECT_UNIFIED
    Test Description TP_MOVE_OBJECT_UNIFIED uses basic {
      @Expected behaviour
      {
          @when
          {
              perform action : "the Controller sends the starting position"
              controller::wifi sends position ( x = 21, y = 21 ) to object::wifi
          }
          @then
          {
              perform action : "the Object moves to the requested position"
              object::wifi sends position ( x = 21, y = 21 ) to controller::wifi
          }
      }
    }
</code>	
<figcaption style="text-align:center"> <b>Figure 6.7.1-4: Representation of Figure 6.7.1-3 using the generic test description syntax</b></figcaption>
</figure>

As the unified notation is simply using annotated blocks with specialised syntax, the same structure can also be expressed by using the generic syntax for test descriptions, 
as shown in Figure 6.7.1-4. As the test purpose gradually becomes more detailed and more formalised, the annotated blocks could also eventually be dropped or extended with 
further annotations. Using this approach, there is no need for transformations between different notations and different conceptual representations. Is that the same model 
elements are used to express the full spectrum between more abstract and more concrete behaviour specifications. The level of detail can be refined over time as further 
information becomes available.









<ol start=2>
  <li> <b>User scenario:</b> Templates for TO backed by TD, also for constituent parts.</li>
</ol>

The TOP tool textual editors provides context sensitive templates for specification of structured test objectives. Further details on how to use templates are described 
in **clause 6.2.3. of the present document**.

<ol id="UC_TemplateLibraryForBasiConfigs" start=3>
  <li> <b>User scenario:</b> Template library for basic configurations and types.</li>
</ol>

The extended syntax for structured test objectives allows for more complete test purpose specification requiring, e.g. configuration specification. For these elements the TOP tool editors provide a template library is available from the template collection of the editors.



### Generate TD from TO <a name="sec-generate-td-from-to"></a>

6.2.8 

Lossless conversion of TDL test objectives to test descriptions is generally not possible due to conceptual differences between the formalisms. Some of the discrepancies may be overcome by annotating source (and target) models with appropriate information.

1. **User scenario:** Means to include predefined annotations with TDL models to help guide the conversion process. 

2. **User scenario:** Support for TO to TDL conversion according to element annotations or default (non-functional) mappings for cases where annotations are not provided.  

3. **User scenario:** Generated test descriptions contain references to test objectives from which they originate.  

As the conversion cannot be completely automated the process on how manual steps can support the transformation are defined in **clause 6.4 of the present document**. The TOP tools currently supports:

- Transforming of inline data descriptions within EventOccurrences into corresponding data types.
- Generation of TestConfigurations based on the EventSequences within the Structured Test Objective.
- Generation of TestDescription skeletons based on the EventSequences within the Structured Test Objective with references to it.
- Importing of the base package and imported packages.

### Export to Word <a name="sec-export-to-word"></a>

6.2.9 

An essential use case for TDL is its application in producing test specifications, which requires the conversion of models to printable format such as Microsoft Word:

1. **User scenario:** Export TDL diagrams as images.

2. **User scenario:** Export textual TDL test descriptions to be part of a Word document.

3. **User scenario:** Export test objectives as parts of a Word document.

The TOP tool graphical editors provide a function to export the current diagram as an image in the format of the users choice. The function is available via the "camera" button 
shown in Figure 6.2.5-3.
Textual TDL code can be copied from the TDL editors.

The TOP tools provides a TDL-TO converter for Test Objectives to the Word table format. The TDL-TO converter supports both Structured Test Objectives defined in the example syntax and new the standardised notation. Template files allow to define the layout of the generated Word document. In **clause 5.3.3 in the present document** more information on the TDL-TO converter is defined.

### Conversion to TTCN-3 <a name="sec-conversion-to-tttn3"></a>

6.2.10 

1. **User scenario:** Conversion of TDL models to TTCN-3 test suites 

The TOP tools support generation of TTCN-3 according to ES 203 119-6 [i.18]. To use this feature use the T3 button in the TDL tool bar or the TDL Menu item "Transform TDL model to TTCN-3" 
with the model to be transformed open. In **clause 6.6 of the present document** further information on the translation can be found.



## Defining Structured Test Objectives  <a name="sec-defining-structured-test-objectives"></a>

6.3 

### Overview

6.3.1 

TDL Structured Test Objective (TDL-TO) may be used in several ways in the test developments process. The process illustrated in this clause is based on the 
test development process defined in ETSI EG 203 130 (V1.1.1) [i.21]. The TDL-TO specifies a refinement of a 'TestObjective' and defines a formal description of 
a test objective, that may be the basis for a transformation to a TDL test description.

Developing a test specification from a base standard the first step after identifying the requirements to be tested, is to define the test objectives. 
The entities and events to check the test objectives may then be specified and finally arguments of events (data values) and timing constraints may be 
specified. The context in which the required behaviour executes is defined in the test configuration.

Then the parts of a complete TDL-TO specification are:

- Domain part.
- Data.
- Configuration.
- Test purpose behaviour.

The domain, data, and configuration parts are common to a set of test purpose behaviour descriptions, while each test purpose behaviour is specific 
to a single test objective. Test purpose behaviours are typically grouped based on different criteria, e.g. test for normal behaviour and test for 
invalid behaviour to form a test suite structure. In TDL-TO this structuring is supported by grouping of test purpose behaviours. To further structure 
a TDL-TO specification, the domain, data, configuration and test purpose behaviours may be also separated using the TDL package concept, to support 
re-use of basic data definitions and configurations.

### Domain part of TDL-TO

6.3.1 

The domain part of a TDL-TO specification defines the PICS elements, entities, and events relevant for a set of TDL TOs.


<figure>
<code>
    
     Domain {
            pics:
               - NONE
            ;
            entities:
                - EPC_PCRF_A
                - EPC_PCRF_B
                - EPC_PGW_A
                - EPC_PGW_B
                - EPC_MME_A
                - EPC_MME_B