ETSI TR 103 119 V1.1.1 (2018-02)

TECHNICAL REPORT
Methods for Testing and Specification (MTS);
The Test Description Language (TDL);
Reference Implementation
2 ETSI TR 103 119 V1.1.1 (2018-02)

Reference
DTR/MTS-103119REFV1.1.1
Keywords
MBT
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 119 V1.1.1 (2018-02)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Basic Principles . 7
4.1 Introduction . 7
4.2 Implementation Scope . 7
4.3 Document Structure . 8
5 Graphical Representation Viewer . 8
5.1 Scope and Requirements . 8
5.2 Architecture and Technology Foundation . 9
5.2.1 Diagram Viewer . 9
5.2.2 Structured Test Objective Representatio n . 10
5.3 Implemented Facilities . 11
5.3.1 Creating Models . 11
5.3.2 Viewing Models . 15
5.3.3 Exporting Structured Test Objectives . 23
5.3.4 Validating Models . 25
5.4 Usage Instructions . 26
5.4.1 Development Environment . 26
5.4.2 End-user Instructions . 27
6 UML Profile Editor . 28
6.1 Architecture and Technology Foundation . 28
6.2 Implemented Facilities . 28
6.2.1 Applying the Profile. 28
6.2.2 Hints for the Transforming UP4TDL Models into TDL Models . 29
6.2.3 Editing models with the Model Explorer . 30
6.2.4 Editing models with TDL-specific properties from the 'TDL property view' . 30
6.2.5 Editing models with TDL-specific diagrams . 30
Annex A (informative): Technical Realization of the Reference Implementation. 35
History . 36

ETSI
4 ETSI TR 103 119 V1.1.1 (2018-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Methods for Testing and Specification
(MTS).
TM TM TM TM TM TM TM TM
NOTE: Eclipse , Xtext , Sirius , EMF , Papyrus , GMF , Epsilon , EVL are the trade names of a
TM TM TM TM
product supplied by the Eclipse Foundation. OMG®, XMI , UML , OCL , MOF are the trade
names of a product supplied by Object Management Group®. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of the
product named.
The present document is complementary to the multi-part deliverable covering the Test Description Language as
identified below:
ETSI ES 203 119-1: "Abstract Syntax and Associated Semantics";
ETSI ES 203 119-2: "Graphical Syntax";
ETSI ES 203 119-3: "Exchange Format";
ETSI ES 203 119-4: "Structured Test Objective Specification (Extension)".
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
5 ETSI TR 103 119 V1.1.1 (2018-02)
1 Scope
The present document summarizes technical aspects related to the reference implementation of TDL. It describes both
the implementation details needed for further development and integration of the tools as well as gives usage
instructions for end users.
Following tools and components are covered in the present document:
• implementation of the TDL meta-model;
• viewer for the graphical representation format of TDL;
• various TDL model editors;
• facilities for checking the semantic validity of models according to the constraints specified in the TDL meta-
model;
• implementation of the UML profile for TDL; and
• editor supporting the creation and manipulation of UML models applying the UML profile for TDL.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
TM
[i.1] Eclipse Foundation : Eclipse IDE Website (last visited 30.03.2016).
NOTE: Available at https://eclipse.org.
TM TM
[i.2] Eclipse Foundation : Eclipse Xtext Website (last visited 30.03.2016).
NOTE: Available at https://eclipse.org/Xtext/index.html.
TM TM
[i.3] Eclipse Foundation : Eclipse Sirius Website (last visited 30.03.2016).
NOTE: Available at http://www.eclipse.org/sirius/index.html.
TM TM
[i.4] Eclipse Foundation : Eclipse Modeling Framework (EMF ) Website (last visited 30.03.2016).
NOTE: Available at http://www.eclipse.org/modeling/emf/.
TM TM
[i.5] Eclipse Foundation : Eclipse Papyrus Modeling Environment Website (last visited
30.03.2016).
NOTE: Available at https://www.eclipse.org/papyrus/.
ETSI
6 ETSI TR 103 119 V1.1.1 (2018-02)
TM TM
[i.6] Eclipse Foundation : UML Profiles Repository Website (last visited 30.03.2016).
NOTE: Available at https://projects.eclipse.org/projects/modeling.upr.
TM TM
[i.7] Eclipse Foundation : Graphical Modeling Framework (GMF ) Website (last visited
30.03.2016).
NOTE: Available at http://www.eclipse.org/modeling/gmp/.
TM
[i.8] "Object Constraint LanguageTM (OMG® OCL ), Version 2.4", formal/2014-02-03.
NOTE: Available at http://www.omg.org/spec/OCL/2.4/.
TM TM
[i.9] Eclipse Foundation : Eclipse OCL Website (last visited 30.03.2016).
NOTE: Available at https://projects.eclipse.org/projects/modeling.mdt.ocl.
[i.10] Plutext Pty Ltd: Docx4j Website (last visited 30.03.2016).
NOTE: Available at http://www.docx4java.org/trac/docx4j.
TM TM
[i.11] "OMG® XML Metadata Interchange (XMI ) Specification", Version 2.4.2, formal/
2014-04-04.
NOTE: Available at http://www.omg.org/spec/MOF/2.4.2/.
TM TM TM
[i.12] Eclipse Foundation : Epsilon Validation Language (EVL ) Website (last visited 30.03.2016).
NOTE: Available at http://www.eclipse.org/epsilon/doc/evl/.
[i.13] ETSI ES 203 119-1 (V1.3.1): "Methods for Testing and Specification (MTS); The Test
Description Language (TDL); Part 1: Abstract Syntax and Associated Semantics".
[i.14] ETSI ES 203 119-2 (V1.2.1): "Methods for Testing and Specification (MTS); The Test
Description Language (TDL); Part 2: Graphical Syntax".
[i.15] ETSI ES 203 119-3 (V1.2.1): "Methods for Testing and Specification (MTS); The Test
Description Language (TDL); Part 3: Exchange Format".
[i.16] ETSI ES 203 119-4 (V1.2.1): "Methods for Testing and Specification (MTS); The Test
Description Language (TDL); Part 4: Structured Test Objective Specification (Extension)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
abstract syntax: graph structure representing a TDL specification in an independent form of any particular encoding
concrete syntax: particular representation of a TDL specification, encoded in a textual, graphical, tabular or any other
format suitable for the users of this language
meta-model: modelling elements representing the abstract syntax of a language
system under test (SUT): role of a component within a test configuration whose behaviour is validated when executing
a test description
TDL model: instance of the TDL meta-model
TDL specification: representation of a TDL model given in a concrete syntax
ETSI
7 ETSI TR 103 119 V1.1.1 (2018-02)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
EBNF Extended Backus-Naur Form
EMF Eclipse Modelling Framework
EVL Epsilon Validation Language
GMF Graphical Modelling Framework
MBT Model-Based Testing
MOF Meta-Object Facility
OCL Object Constraint Language
OMG Object Management Group®
SUT System Under Test
TDL Test Description Language
UML Unified Modelling Language
URI Unified Resource Identifier
XMI XML Metadata Interchange
XML eXtensible Markup Language
4 Basic Principles
4.1 Introduction
To accelerate the adoption of TDL, a reference implementation of TDL is provided in order to lower the barrier to entry
for both users and tool vendors in getting started with using TDL. The reference implementation comprises graphical
and textual editors, as well as validation facilities. In addition, the UML profile for TDL and supporting editing
facilities are implemented in order to enable application of TDL in UML-based working environments and model-based
testing approaches.
4.2 Implementation Scope
The implementation scope includes a graphical viewer according to ETSI ES 203 119-2 [i.14] based on the Eclipse
platform [i.1] and related technologies, covering essential constructs related to test configurations and test behaviour
specification. For creating and manipulating models, a textual editor for ETSI ES 203 119-1 [i.13], annex B is
implemented based on the Eclipse platform and related technologies. The applicability of general purpose model editing
facilities provided by the Eclipse platform and related technologies is discussed.
For tools that need to import and export TDL models according to ETSI ES 203 119-3 [i.15], corresponding facilities
are implemented based on the Eclipse platform and related technologies. These facilities can be used to transform
textual representations based on ETSI ES 203 119-1 [i.13] into XMI [i.11] serializations according to ETSI
ES 203 119-3 [i.15] and can be integrated in custom tooling that builds on the Eclipse platform.
An implementation of ETSI ES 203 119-4 [i.16] includes a dedicated textual editor for structured test objectives, which
can be integrated in the textual editor for TDL. The implementation also includes facilities for exporting structured test
objectives to Word documents using customisable tabular templates.
An implementation of the UML profile for TDL includes a specification of the TDL UML profile abstract syntax
according to the mapping from the TDL meta-model to TDL stereotypes and UML meta-classes in ETSI
ES 203 119-1 [i.13], annex C. It is integrated with the open source UML modelling environment Eclipse Papyrus [i.5]
as an open TDL UML profile reference implementation platform. It will be published on the open source "Eclipse UML
Profiles Repository" project [i.6].
ETSI
8 ETSI TR 103 119 V1.1.1 (2018-02)

Figure 4.2.1: TDL tool infrastructure
An overview of the context of the reference implementation is shown in Figure 4.2.1. The TDL exchange format
specified in ETSI ES 203 119-3 [i.15] serves as a bridge between the different tool components. Textual editors enable
the creation and manipulation of TDL models. The graphical viewer is used to visualize TDL models as diagrams.
Documentation generation, in particular for structured test objectives, can be plugged in to produce Word documents
for presenting parts of a TDL model in a format suitable for standardization documents.
The complete implementation will be published on an open-source portal serving as a central hub for the TDL
community.
4.3 Document Structure
The present document contains two main technical clauses focusing on relevant technical details. The Graphical
Representation Viewer implementing ETSI ES 203 119-2 [i.14], as well as related facilities implementing ETSI
ES 203 119-1 [i.13], ETSI ES 203 119-3 [i.15] and ETSI ES 203 119-4 [i.16] are described in clause 5. The UML
Profile Editor implementing annex C of ETSI ES 203 119-1 [i.13] is described in clause 6.
5 Graphical Representation Viewer
5.1 Scope and Requirements
TDL graphical viewer implementation has two major requirements. The main objective is to provide means to visualize
TDL models according to the graphical notation. The second objective is to facilitate layout of diagrams in a way that is
suitable for documentation. For the second purpose, it is essential to provide graphical editing capabilities. Although
often provided by modelling frameworks, the ability to graphically edit the underlying models (that is, to create new
elements and set their properties) is not considered relevant for this implementation.
Eclipse provides several graphical modelling tools to help build editors. Sirius [i.3] was chosen for its declarative
approach that provides separation between meta-model mappings and implementations of graphical elements. With the
existence of predefined common graphical elements such as containers and connectors, the effort of implementing
graphical editor with custom syntax in Sirius is only spent on the parts that diverge from those common elements.
ETSI
9 ETSI TR 103 119 V1.1.1 (2018-02)
Another area that requires custom implementation is the layout of graphical elements. This covers both the absolute
placement of nodes on the diagram as well as the size and internal contents of each node. Due to rather hierarchical
nature of the TDL graphical syntax, several additional base graphical elements are introduced. Some peculiar
limitations of Sirius have also been identified prior to the implementation, which also need appropriate workarounds.
The goal of implementing diagram layout is to automate diagram creation to the extent that the sizes and contents of
graphical elements are adjusted by layout algorithms while the absolute placement of diagram elements is solved by
using built in layout implementations. This will guarantee minimal user interaction with diagram editor for achieving
desired layouts.
Diagram export for documentation purposes is provided by the framework. The viewer implementation will add
complimentary export to Word document format.
Due to the peculiarities and intended use of structured test objectives, it was determined that instead of graphical shapes
that can be exported as images, the graphical representation are realized as tables exported in a Word document
according to user-defined templates. These tables can then be manipulated further as necessary to fit in within an
existing document.
5.2 Architecture and Technology Foundation
5.2.1 Diagram Viewer
TDL viewer is built on Eclipse platform to benefit from its wide range of modelling tools. The main Eclipse projects
that are used as basis for this implementation are shown in Figure 5.2.1. Sirius is a technology that allows declarative
creation of graphical editors that work with EMF models. It uses GMF [i.7] to create visual diagram elements and link
those to model objects. Model management and serialization is done by EMF [i.4].
Eclipse platform
EMF
TDL (XF)
TDL Ecore
Sirius
Diagram
Diagram
specification
GMF
TDL viewer
Image
NOTE: Components with grey background are part of the implementation that is covered by the present
document.
Figure 5.2.1: Dependencies and data flows of TDL viewer
Every EMF model is based on a meta-model that is defined in terms of meta-modelling system named Ecore. TDL
meta-model in UML format was converted to Ecore meta-model (TDL Ecore) using Papyrus UML and EMF facilities.
Furthermore, Java code for the TDL meta-model was generated based on the TDL meta-model.
Sirius creates diagram editors by interpreting diagram specification files. These files contain TDL meta-model
references in the form of Java or OCL [i.8] queries. OCL support is provided by the Eclipse OCL project [i.9], Java
queries are references to classes that are part of the TDL viewer source code. Diagram specifications also contain
definitions of Sirius specific styles that are applied to model objects when rendering them on diagrams. Since the TDL
viewer requires customized shapes, it has dependencies on both the Sirius API and the Eclipse GMF. Several extensions
to GMF classes have been implemented in Sirius in order to configure shapes according to the customized styles. GMF
facilities are then used to export diagrams as images.
ETSI
10 ETSI TR 103 119 V1.1.1 (2018-02)
Some of the labels in the graphical shapes, in particular labels related to data specification and data use have a complex
structure. For their realization, facilities provided by Xtext [i.2] are used to serialize model fragments related to data use
as text according to an annotated EBNF grammar derived from the formal label specifications in ETSI
ES 203 119-2 [i.14].
5.2.2 Structured Test Objective Representation
Structured test objectives are exported as tables in a Word document according to user-defined templates. The export
relies on facilities provided by Xtext as well as the Docx4j library [i.10] providing API for manipulating Word
documents. The exporting facilities take a Word document containing one or more templates in the form of tables with
placeholders and a TDL model containing one or more structured test objectives as input. The user has to provide the
name of the desired template as an additional input. For every structured test objective, the selected template is copied
into a new empty document and the placeholders are replaced by the content serialized from the corresponding TDL
element according to the Xtext mappings in a similar manner as the labels for the diagram viewer. The representation
process is sketched on Figure 5.2.2. The generated tables in the new Word document can be further manipulated or
merged into an existing document containing additional information. Additional templates may be defined by users to
suit specific needs.
Figure 5.2.2: Structured test objective representation process
ETSI
11 ETSI TR 103 119 V1.1.1 (2018-02)
5.3 Implemented Facilities
5.3.1 Creating Models
Overview
Model instances are the primary artefacts for TDL. They carry the semantic information. In a modelling environment
there are various means for creating, viewing, and manipulating model instances of a particular meta-model.
Comprehensive modelling environments typically provide generic model facilities that enable working with model
instances of arbitrary meta-models, provided the meta-model is known. Generic model facilities provide sufficient
capabilities for performing basic tasks on model instances. However, due to their generic nature, they are cumbersome
to work with, lack of support for certain features that are not expressed in the meta-model directly (unless customized),
and do not provide domain-specific features such as syntactical customization beyond basic adaptations.
Custom syntax implementations address some of the shortcomings of generic model editors. Such implementations
enable the specification of a customized representation of a model instance in a format that is tailored to a specific
group of users. There may be multiple custom syntax implementations mapped to the same meta-model, serving
different stakeholders or even different purposes for the same stakeholder. Custom syntax implementations may cover
only a subset of the meta-model, restricting the access to certain features that are not relevant for specific stakeholders
or purposes. Modelling environments provide platforms for the realization of custom syntax implementations. Custom
syntax implementations may rely on secondary artefacts that store the concrete representation of the TDL model
instance.
TDL model instances may be produced automatically by tools. The exchange format for TDL enables the
interoperability of tools producing model instances and tools for manipulating model instances.
Generic Model Editors
The EMF provides facilities for generating basic tree editors for a given meta-model, which can then be customized to
an extent while still remaining within the tree editor paradigm. In addition, the EMF also provides generic reflective
model editors which provide quick access to model instances of any meta-model. An example of such an editor for TDL
is shown in Figure 5.3.1. The example includes a tree-based editor for manipulating the overall structure of a model on
top and a detailed property view for manipulating individual properties on the bottom.
Extensions to the EMF such as MoDisco include additional generic facilities such as the MoDisco model browser which
provides faceted browsing and editing of model instances. Faceted browsing provides filtering by type, as well as deep
navigation across references. In addition, MoDisco also includes tabular views on different parts of the model for a
quick overview across multiple dimensions. An example for a TDL model is illustrated in Figure 5.3.2. The example
includes a faceted browser on the top for navigating and manipulating the overall structure of a model, as well as
individual properties of model elements. On the left side of the faceted browser, model elements can be filtered by type.
Below the faceted browser, a tabular viewer provides more compact representation of multiple model elements at the
same level in a model tree, such as the behaviour elements of a block. The property view on the bottom part of the
example still allows the manipulation of properties of selected model elements.
ETSI
12 ETSI TR 103 119 V1.1.1 (2018-02)

Figure 5.3.1: Example of reflective model editor
ETSI
13 ETSI TR 103 119 V1.1.1 (2018-02)

Figure 5.3.2: Example of MoDisco facetted model browser
Textual Editor
Xtext provides facilities for the automatic generation of a default textual syntax closely resembling the structure of the
meta-model. It serves as the base for further refinements resulting in customized syntax definitions. Due to it being
automatically generated, it is very similar in structure to the meta-model. As a consequence, it is also rather
cumbersome to write actual test descriptions in the default syntax notation.
ETSI
14 ETSI TR 103 119 V1.1.1 (2018-02)
The reference implementation includes a customized textual syntax that implements the example syntax from annex B
of ETSI ES 203 119-1 [i.13]. Apart from the grammar specification, it also includes further customizations in the
scoping and linking facilities for handling gate references, as well as enhanced semantic syntax highlighting which
provides customisable styles for identifiers based on their type and usage. An example of the customized editor is
shown in Figure 5.3.3. It features a textual representation of a test description as well as linked tree-based editor
showing the same model instance in the tree-based paradigm. Current version of the grammar specification and the
additional customizations can be found in annex A of the present document as part of the 'org.etsi.mts.tdl.TDLan2*'
projects.
Figure 5.3.3: Example of customized textual editor for TDL
Similar to the editor for TDL, the reference implementation also includes a customized textual syntax that is tailored for
the specification of structured test objectives. It implements the example syntax from annex B of ETSI
ES 203 119-4 [i.16]. It also includes further customizations in the scoping and linking facilities for handling gate
references, as well as enhanced semantic syntax highlighting, in a similar manner as the editor for TDL. An example of
the customized editor is shown in Figure 5.3.4. It features a textual representation of a structured test objective. Current
version of the grammar specification and the additional customizations can be found in annex A of the present
document as part of the 'org.etsi.mts.tdl.TPLan2*' projects.
Associated tooling provides means for the transformation between different syntax notations and model representations.
Model instances in one notation can be transformed automatically into XMI representations and/or other textual or
graphical syntax representations. This tooling integrates the APIs from different platforms for task specific automation.
A current version of this tooling and detailed technical information can be found in annex A as part of the
'org.etsi.mts.tdl.tools.*' projects.
ETSI
15 ETSI TR 103 119 V1.1.1 (2018-02)

Figure 5.3.4: Example of customized textual editor for structured test objectives
Import and Export
The TDL reference implementation relies largely on the import and export facilities provided by the EMF. By default,
the EMF does not activate the GUID support for XMI which is prescribed in ETSI ES 203 119-3 [i.15]. The TDL meta-
model implementation needs to be adapted to activate the GUID support for model elements. The necessary adaptation
involves selecting the correct resource type (XMI) in the generator model and activating the GUID support by
overriding the corresponding method in the TDL resource implementation. The relevant modifications can be found in
the 'org.etsi.mts.tdl.model' project within annex A.
5.3.2 Viewing Models
Principles of building model diagrams
The GMF framework that TDL viewer is built upon follows the Model-View-Controller architecture. The model is an
instance of TDL meta-model. The view is comprised of the shapes displayed on the diagram. The controller takes care
of creating figures based on model objects and their associations: cross-references and containments. In GMF,
controllers are called 'editparts'.
The major part of the diagram viewer implementation consists of defining the corresponding 'editparts'. In case of
Sirius, these are not implemented directly but rather defined in terms of mappings. A mapping is a relation between a
certain model object and a shape. Sirius interprets each mapping and uses appropriate 'editpart' as a controller providing
mapping configuration data.
Mappings can be defined as nodes, edges, or containers (and some additional items specific to sequence diagrams).
Each mapping includes a reference to the meta-class of the model object that it applies to as well as the query that is
used to lookup objects from the model based on the current context object. Similar to models and diagrams, mappings
are also hierarchical. Edge mappings also define the queries that determine the corresponding shapes its endpoints
connect to.
ETSI
16 ETSI TR 103 119 V1.1.1 (2018-02)
Sirius diagrams
Sirius provides several diagram kinds that can be configured by providing diagram-specific model-object mappings. For
TDL, the generic diagram and the sequence diagram are of particular interest.
Generic diagrams contain nodes and connections between the nodes with no specific constraints on their layout.
Composite nodes containing other nodes are also supported, but only a few limited layout options are available for inner
node placement: free-form and table (lines of text).
Sequence diagrams contain vertical parallel lines known as lifelines. Lifelines have headers with labels. Nodes and
connectors between the lifelines - the fragments - are laid out as a horizontal stack. Nodes may cover any number of
lifelines, connectors may only be drawn between two lifelines. Composite nodes containing sub-fragments (called
combined fragments) are also supported.
Sirius editors are defined in configuration files known as viewpoint specifications. The TDL viewpoint specification
defines a single viewpoint that contains two diagram descriptions named "TDL Behaviour" and "Generic TDL".
TDL Behaviour is a sequence diagram description. The root object of such diagrams is an instance of 'TestDescription'.
The diagram description also defines the visual order of elements both horizontally and vertically. The vertical ordering
contains behaviours recursively included in the 'TestDescription' as they occur semantically. The horizontal ordering
contains 'GateReference's that are defined in the 'TestConfiguration' associated with the diagram's 'TestDescription'
instance.
Generic TDL is a generic diagram description. The root object of such diagrams is an instance of 'Package'. There is no
predefined order of objects defined for this diagram kind.
Sirius diagram customization
The Sirius diagram specification model does not provide enough flexibility in terms of configuring all possible layouts
required by the TDL graphical syntax. The diagrams are rendered by interpreting predefined configuration elements that
do not have any extension mechanisms built in. Thus, some simple and composite figures need to be customized at a
lower level.
The Sirius diagram rendering is built on top of the GMF runtime. Thus, it is possible to customize Sirius diagrams by
means of extension points provided by GMF. The 'org.eclipse.gmf.runtime.diagram.ui.editpartProviders' extension
point allows the replacement of default Sirius 'editparts' with customized 'editparts' dynamically, depending on which
model object is being rendered, and depending on which diagram it is being rendered on. Classes defined in the
extensions use mapping identifiers from the diagram specification to decide whether and which custom 'editparts'
should be provided for the rendering of a diagram. All other mappings will rely on the default 'editparts' provided by the
Sirius implementation.
Implemented EditParts
All of the 'editpart' implementations are located in the 'org.etsi.mts.tdl.graphical.sirius.part' package.
The 'MultipartContainerCompartmentEditPart' extends GMF's 'ListCompartmentEditPart'. This class adds grid layout
that allows contained shapes to fill the available area within the container. It also removes all borders from contained
shapes in order to get rid of shadows and places horizontal lines between the contained shapes instead. Lastly, it
removes the ability of being dragged and selected from the contained shapes in order to facilitate moving the whole
compartment shape as one. The mapping that uses this 'editpart' has to be a container.

Figure 5.3.5: Example of 'MultipartContainerCompartmentEditPart'
ETSI
17 ETSI TR 103 119 V1.1.1 (2018-02)
The 'NodeListWithHeaderEditPart' extends the 'AbstractDiagramListEditPart' from the Sirius API. It is intended to be
used as within a 'MultipartContainerCompartmentEditPart' and provides functionality that allows the container to
control its drag and selection handling. It removes all line borders from the contained shapes and replaces the borders
with margins. The mapping that uses this 'editpart' has to be a container with list presentation style. The first label of the
figure is the label of that container's style. The children of that mapping have to be nodes with square style.

Figure 5.3.6: Example of 'NodeListWithHeaderEditPart'
The 'TopLevelNodeListWithHeaderEditPart' extends the 'NodeListWithHeaderEditPart' and adds the ability to be
included directly on the diagram or inside a container with free-form presentation style. It also fixes a bug in the
'AbstractDiagramElementContainerEditPart.reInitFigure()' method.

Figure 5.3.7: Example of 'NodeListWithHeaderEditPart'
The 'EditPartConfiguration' is used to specify additional style and layout properties supported by some custom
'editparts'. It is used, for example, to draw double border for specified edit parts using a 'TwoLineMarginBorder'.

Figure 5.3.8: Example of 'TopLevelImageNodeListWithHeaderEditPart'
The 'NodeContainerEditPart' extends the 'AbstractDiagramContainerEditPart' provided by the Sirius API. The default
container is modified by disabling standalone selection and dragging and delegating those functions to the parent. All
borders are removed from the shape. It is intended to be used as a child of 'MultipartContainerCompartmentEditPart'.
ETSI
18 ETSI TR 103 119 V1.1.1 (2018-02)

Figure 5.3.9: Example of 'NodeContainerEditPart'
The 'InteractionUseConfiguringEditPart' extends the 'AbstractNotSelectableShapeNodeEditPart' provided by the Sirius
API. The class modifies the default interaction use shape by setting custom layout to it. The custom layout stretches the
container's children to fill the available vertical space and leaves sufficient margin to the top for the label of the
container. If the interaction use mapping has image style then the image background is made opaque.
This class is mapped to (an abstract) sub-mapping of interaction use. That mapping does not need to have a style as it
will not be visible. The first label of the interaction use is the label of the container. The rest of the labels are sub-nodes
with square styles.
Figure 5.3.10: Example of 'InteractionUseConfiguringEditPart'
The 'MultiPartLabelEditPart' extends the 'TopLevelNodeListWithHeaderEditPart' and adds the ability to place labels
horizontally in a row. This allows mappings that define different fonts for different parts of labels.

Figure 5.3.11: Example of 'MultiPartLabelEditPart'
The 'CombinedFragmentLabelEditPart' extends the 'MultiPartLabelEditPart' to inherit support for mixed font labels. It
overrides the default layout behaviour via a 'LayoutListener' from the 'Draw2d' API and places the shape always to the
upper right corner of a combined fragment block.
ETSI
19 ETSI TR 103 119 V1.1.1 (2018-02)

Figure 5.3.12: Example of 'CombinedFragmentLabelEditPart'
The 'InteractionDecoratorProvider' is contributed via the 'org.eclipse.gmf.runtime.diagram.ui.decoratorProviders'
extension point in order to draw special rotatable shapes at the ends of connectors. This class is configured to work
specifically with 'Interaction's.

Figure 5.3.13: Example of 'InteractionDecoratorProvider'
Implemented layouts
All layout implementations are located in the 'org.etsi.mts.tdl.graphical.sirius.layout' package.
The 'SequenceDiagramFreeformLayoutProvider' overrides the default placement of elements on the diagram layer. It
also fixes the layout of shapes modified by the 'InteractionUseConfiguringEditPart' that would otherwise be cropped to
the default size and would not trigger the layout of contents on container resize. It is contributed via the
'org.eclipse.sirius.diagram.ui.layoutProvider' extension point and its use is triggered by the arrange command.

Figure 5.3.14: Example of custom figure placement: node with attachment

Figure 5.3.15: Example of custom figure placement: under-lapping container
The layout customizations are implemented via the diagram 'arrange' mechanism, which is normally triggered only
when the user invokes the 'arrange' command. Additional triggers are implemented in order to facilitate the automatic
diagram creation upon user creating and updating the model. The 'RefreshExtensionProvider' is contributed via the
'org.eclipse.sirius.refreshExtensionProvider' extension point. It invokes the 'arrange' command when model is modified
and subsequently reloaded into the diagram editor. The 'LayoutEditPolicyProvider' is contributed via
'org.eclipse.gmf.runtime.diagram.ui.editpolicyProviders' extension point and it invokes the arrange command when a
'GateReference' or 'ComponentInstance' shape is moved by the user in order to keep the under-lapping shape properly
aligned.
ETSI
20 ETSI TR 103 119 V1.1.1 (2018-02)
Viewer specific meta-model
The Sirius sequence diagram configuration sets implicit requirements on the structure of the meta-model that is used in
mapping definitions. The TDL meta-model does not comply with these requirements in all cases. For example, the
mappings of combined fragments tend to fail at runtime when the begin and end occurrence objects (as understood by
Sirius) are the same. Since TDL does not define occurrences at all, some adaptation is needed to provide these
occurrence objects. Sirius and the underlying framework require that model objects used in diagrams are defined by
meta-model. Extending the TDL meta-model with pure fabrications, just to facilitate viewer implementations, would be
a bad practice. Therefore, a separate domain-agnostic meta-model
...