|
GROUP REPORT
Network Functions Virtualisation (NFV) Release 2;
Information Modeling;
UML Modeling Guidelines
Disclaimer
The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.
---------------------- Page: 1 ----------------------
2 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
Reference
RGR/NFV-IFA017ED251
Keywords
information model, NFV, UML
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:
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
If you find errors in the present document, please send your comment to one of the following services:
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 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
---------------------- Page: 2 ----------------------
3 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Overview . 7
5 UML artefact descriptions . 7
5.1 Classes . 7
5.1.1 Description . 7
5.1.2 Class notation. 7
5.1.3 Class properties . 8
5.2 Attributes in classes . 9
5.2.1 Description . 9
5.2.2 Attribute notation . 10
5.2.3 Attribute properties . 10
5.3 Relationships . 12
5.3.1 Description . 12
5.3.2 Relationship notation . 13
5.3.2.1 Association notation . 13
5.3.2.2 Generalization notation . 14
5.3.2.3 Dependency notation . 15
5.3.3 Relationship properties . 15
5.4 Interfaces . 18
5.5 Interface operations . 18
5.6 Operation parameters . 18
5.7 Notifications . 18
5.7.1 Description . 18
5.7.2 Notification notation . 18
5.7.3 Notification properties . 19
5.8 Data Types. 20
5.8.1 Description . 20
5.8.2 Type notation . 20
5.8.3 Type properties . 21
5.8.4 UML Primitive Types . 22
5.8.5 Pre-defined Data Types . 22
5.9 Qualifiers and conditions . 22
5.10 Use cases . 23
5.11 Activities . 23
5.12 State machines . 23
6 UML profile definitions . 23
6.1 UML Profile Structure . 23
6.2 Additional Properties for individual UML artefacts . 23
6.3 Additional Properties for all UML artefacts . 27
6.3.1 LifecycleState Property . 27
6.3.2 Reference property . 29
6.3.3 Example property . 30
7 Recommended Modeling Patterns . 30
ETSI
---------------------- Page: 3 ----------------------
4 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
7.1 Model Structure . 30
7.2 Use of XOR/Choice/Proxy class . 31
7.2.1 Xor constraint . 31
7.2.1.1 Description . 31
7.2.1.2 Example . 31
7.2.1.3 Name style. 31
7.2.2 "Choice" . 32
7.2.3 Proxy class Modeling. 32
7.3 UML diagram guidelines . 32
7.3.1 Recommendations . 32
7.3.2 Using colours . 32
7.3.3 Style sheets . 32
Annex A: Authors & contributors . 33
History . 34
ETSI
---------------------- Page: 4 ----------------------
5 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
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
---------------------- Page: 5 ----------------------
6 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
1 Scope
The present document defines the guidelines that have to be taken into account during the creation of a protocol-neutral
UML (Unified Modeling Language) information model.
These guidelines are informative for the general reader, but need to be followed when designing models for the ETSI
NFV Information Model.
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.
[i.1] Papyrus Eclipse UML Modeling Tool.
NOTE: Available at https://www.eclipse.org/papyrus/.
[i.2] Unified Modeling Language™ (UML ).
NOTE: Available at http://www.uml.org/.
[i.3] OMG Unified Modeling Language (OMG UML), Version 2.5.
NOTE: Available at http://www.omg.org/spec/UML/2.5/.
[i.4] Open Networking Foundation UML Modeling Guidelines V1.2, September 2016 (ONF TR-514).
[i.5] ETSI GR NFV-IFA 015: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; Report on NFV Information Model".
[i.6] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI GS NFV 003 [i.6] apply.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.6] and the following apply:
MAC Media Access Control
UCC Upper Camel Case
UML Unified Modeling Language
4 Overview
UML defines a large number of basic model elements (UML artefacts). In order to assure consistent and harmonious
information models, only a selected subset of these artefacts are used in the UML model guidelines in the present
document. The semantic of the selected artefacts is defined in [i.2].
The guidelines of each basic model artefact are divided into three parts:
1) Short description.
2) Graphical notation examples.
3) Properties.
The guidelines have been developed using the Papyrus open source UML tool [i.1].
The ONF UML Modeling Guidelines [i.4] have been used as a basis for these guidelines. The present document only
uses a subset of the guidelines defined in the ONF UML Modeling Guidelines [i.4]. The parts not used are indicated
clearly in each clause.
NOTE: The OpenInterfaceModel Profile and its stereotypes are not used by the ETSI NFV Information Model.
5 UML artefact descriptions
5.1 Classes
5.1.1 Description
Classes are used to convey a structural (often called static) representation of an entity, including properties and
attributes.
5.1.2 Class notation
Figure 5.1.2-1: Graphical Notation for classes
As highlighted in figure 5.1.2-1, a class is represented with a name compartment and an attributes compartment. It is
recommended that the name compartment contains also the assigned lifecycle stereotypes. The attributes compartment
can be set in a diagram to not expose the attributes or to expose some or all of the attributes.
In some diagrams the attributes are hidden to reduce clutter, in others only a subset of the attributes is exposed to focus
attention on those attributes. It is also possible to hide the attribute compartment of a class in the class diagrams where a
large number of classes need to be shown, as depicted in figure 5.1.2-2.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
Figure 5.1.2-2: Graphical Notation for Classes
without Attributes Compartment
It is recommended that the name compartment also show stereotypes for the class where relevant. When showing
stereotypes, the compartment may include the stereotype "OpenModelClass" (as all classes in the model have this
stereotype by default) and may also include other stereotypes.
In the general UML definition a class may have name, attribute and operation compartments, as shown in figure 5.1.2-3,
but since the structural part and the behavioural part of the model are decoupled, the operation compartment, is not used
and always hidden.
Figure 5.1.2-3: Graphical Notation for Classes with Attributes
and Deprecated Operations Compartment
5.1.3 Class properties
A class has the following properties:
• Name:
- Follows Upper Camel Case (UCC) convention. Each class in the model has a unique name. An example
of Upper Camel Case: NetworkService.
• Documentation:
- Contains a short definition. The documentation is carried in the "Applied comments" field in Papyrus as
shown on figure 5.1.3-1; i.e. the "Owned comments" field is not used. The complete documentation
should be written in a single comment; i.e. at most one "Applied comment".
Figure 5.1.3-1: Entering documentation
ETSI
---------------------- Page: 8 ----------------------
9 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
• Superclass:
- Inheritance may be used to deal with shared properties. Multiple inheritance is not supported in ETSI
NFV Information Model.
• Abstract:
- Indicates if the object class can be instantiated or is just used for inheritance; i.e. abstract classes will not
be instantiated.
• Additional properties are defined in the "OpenModelClass" stereotype which extents by default (required) the
"metaclass" Class as shown on figure 5.1.3-2.
Figure 5.1.3-2: "OpenModelClass" Stereotype
- support:
This property qualifies the support of the object class at the management interface. See definition in
clause 5.9.
- condition:
This property contains the condition for the condition-related support qualifiers.
The following class stereotype is not used for ETSI NFV Information Model:
• Choice.
The following UML defined class properties are not used:
• Is leaf (default = false).
• Is active (default = false).
• Visibility (default = public).
5.2 Attributes in classes
5.2.1 Description
Attributes contain the properties of an object class. Note that the roles of navigable association ends become an attribute
at the other associated end when this association end is owned by the classifier; see also "Role Type" property in
clause 5.3.3.
NOTE: The association end can also be owned by the association itself in which case it does not become an
attribute.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
5.2.2 Attribute notation
The notation, shown in figure 5.2.2-1, is:
• |""| : [] = .
NOTE: When no default is relevant or no default is defined, the "=" is not shown.
Figure 5.2.2-1: Graphical Notation for object class with attributes
5.2.3 Attribute properties
An attribute has the following properties:
• Name:
- Follows Lower Camel Case (LCC) and is unique across all attribute names in the inheritance tree. An
example of Lower Camel Case: virtualMemSize.
- It is recommended that all Boolean typed attribute names start with 'is' (e.g. 'isAbstract'), or a verb such
as 'has' and the whole attribute name should be composed in a way that it is possible to answer it by 'true'
or 'false'.
• Documentation:
- Contains a short definition. The documentation is carried in the "Applied comments" field in Papyrus;
i.e. the "Owned comments" field is not used. The complete documentation should be written in a single
comment; i.e. at most one "Applied comment".
• Type:
- Refers to a datatype or a basic UML type. See clause 5.5.
- If it is needed to reference another information model element (i.e. class), then an association is used (see
clause 5.3).
• Default Value:
- Provides the value that the attribute has to start with in case the value is not provided during creation, or
already defined because of a system state.
• Multiplicity (*, 1, 1.*, 0.1, …):
- Defines the number of values the attribute can simultaneously have:
* is a list attribute with 0, one or multiple values;
1 attribute has always one value;
1.* is a list attribute with at least one value;
0.1 attribute may have no or at most one value;
Default value is 1;
Other values are possible; e.g. "2.17".
ETSI
---------------------- Page: 10 ----------------------
11 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
• Additional properties are defined in the "OpenModelAttribute" stereotype which extents by default (required)
the "metaclass" Property, as shown on figure 5.2.3-1.
Figure 5.2.3-1: "OpenModelAttribute" Stereotype
- isInvariant:
This property identifies if the value of the attribute can be changed after it has been created.
- support:
This property qualifies the support of the object class at the management interface. See definition in
clause 5.9.
- condition:
This property contains the condition for the condition-related support qualifiers.
• Other properties:
- PassedByReference:
This property is only applied to attributes that have an object class defined as their type;
i.e. association member ends owned by the class which became attributes. The stereotype is applied
on a case by case basis. Figure 5.2.3-2 is showing this stereotype.
The property defines that the attribute contains only the reference (e.g. name, identifier, address) of
the referred object instance(s) when being transferred across the interface. Otherwise the attribute
contains the complete information of the object instance(s) when being transferred across the
interface.
Figure 5.2.3-2: "PassedByReference" Stereotype
ETSI
---------------------- Page: 11 ----------------------
12 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
The following properties of the OpenModelAttribute stereotype are not used:
• partOfObjectKey.
• uniqueSet.
• valueRange.
• unsigned.
• counter.
• unit.
The following UML defined attribute properties are not used:
• Ordered (default = false).
• Unique (default = true).
• Read Only (default = false).
• Is derived (default = false).
• Is derived union (default = false).
• Is leaf (default = false).
• Is static (default = false).
• Visibility (default = public).
5.3 Relationships
5.3.1 Description
Relationships are defined between classes. Relationships have relationship-ends. A relationship end specifies the role
that the class at that end performs.
ETSI
---------------------- Page: 12 ----------------------
13 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
Figure 5.3.1-1: Metaclass Diagram of used Relationships
Usage realtionships are not used in ETSI NFV Information Model.
5.3.2 Relationship notation
5.3.2.1 Association notation
The following examples show the different kinds of associations that are to be used in the model.
Figure 5.3.2.1-1 shows a bi-directional navigable association where each object class has a pointer to the other. The
association end role name becomes the name of the corresponding attribute. I.e. in the example: ClassA will have an
attribute named "_classB" pointing to ClassB and vice versa.
Figure 5.3.2.1-1: Bidirectional Association Relationship Notation
Figure 5.3.2.1-2 shows a unidirectional association (shown with an open arrow at the target class) where only the source
class has a pointer to the target class and not vice-versa.
Figure 5.3.2.1-2: Unidirectional Association Relationship Notation
ETSI
---------------------- Page: 13 ----------------------
14 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
Figure 5.3.2.1-3 shows a non-navigable association where none of the classes have a pointer to the other; i.e. such
associations are just for illustration purposes. Non-navigable associations should have a name.
Figure 5.3.2.1-3: Non-navigable Association Relationship Notation
An shared aggregation is a special type of association in which objects are assembled or configured together to create a
more complex object. Aggregation protects the integrity of an assembly of objects by defining a single point of control
called aggregate, in the object that represents the assembly. Figure 5.3.2.1-4 shows an aggregation association.
Figure 5.3.2.1-4: Aggregation Association Relationship Notation
A composite aggregation association is a strong form of aggregation that requires a part instance be included in at most
one composite at a time. If a composite is deleted, all of its parts are deleted as well; i.e. the lifecycle of all instances of
ClassB is tied to the lifecycle of the ClassA instance. Figure 5.3.2.1-5 shows a composite aggregation association.
NOTE: In the example below, ClassA names ClassB instances; defined by the "Names" stereotype that is not
used in ETSI NFV Information Model.
Figure 5.3.2.1-5: Composite Aggregation Association Relationship Notation
The "Lifecycle Aggregate" and "Extended Composite" aggregations are not used in ETSI NFV Information Model.
5.3.2.2 Generalization notation
A generalization association indicates a relationship in which one class (the child) inherits from another class (the
parent). A generalization relationship may be conditional, identified by the "Cond" stereotype. Figure 5.3.2.2-1 shows
the 2 types of generalization relationship, as well as an example.
ETSI
---------------------- Page: 14 ----------------------
15 ETSI GR NFV-IFA 017 V2.5.1 (2018-08)
Figure 5.3.2.2-1: Generalization Relationship Notation (normal, conditional and example)
5.3.2.3 Dependency notation
"A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for
their specification or implem
...