ETSI GS ENI 019 V3.1.1 (2023-06)

Experiential Networked Intelligence (ENI); Representing, Inferring, and Proving Knowledge in ENI

DGS/ENI-0029_ENI_Models

General Information

• Status: Not Published
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Completion
• Due Date: 22-Jun-2023
• Completion Date: 15-Jun-2023

Standards Content (Sample)

GROUP SPECIFICATION
Experiential Networked Intelligence (ENI);
Representing, Inferring, and Proving Knowledge in ENI
Disclaimer
The present document has been produced and approved by the Experiential Networked Intelligence (ENI) 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.

2 ETSI GS ENI 019 V3.1.1 (2023-06)

Reference
DGS/ENI-0029_ENI_Models
Keywords
data models, information model, ontology,
semantic reasoning
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2023.
All rights reserved.
ETSI
3 ETSI GS ENI 019 V3.1.1 (2023-06)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Representing, Inferring, and Proving Knowledge in ENI . 10
4.1 Introduction . 10
4.2 Definitions . 10
4.2.1 Information Model . 10
4.2.2 Data Model . 10
4.2.3 Ontology . 10
4.3 Information Model Usage in ENI . 10
4.3.1 Purpose . 10
4.3.2 Use of an Information Model as a Blueprint for Entity Definitions . 11
4.3.3 Use of an Information Model to Define a Lexicon and Grammar . 12
4.4 Data Model Usage in ENI . 12
4.4.1 Purpose . 12
4.4.2 Use of a Data Model as a Blueprint for System Data . 12
4.4.3 Derivation of Data Models from an Information Model . 12
4.5 Ontology Usage in ENI . 14
4.5.1 Introduction. 14
4.5.2 Use of Ontologies to Enable Formal Reasoning and Learning . 14
4.6 Model Augmentation . 14
4.6.1 Introduction. 14
4.6.2 Augmentation of an Information Model using Ontologies . 15
4.6.3 Augmentation of Data Models Using Ontologies . 15
4.7 Synchronizing and Reconciling Modelled Data . 15
4.8 Securing Modelled Data . 15
4.9 Decision-Making . 15
4.9.1 Introduction. 15
4.9.2 Control Loops . 15
4.9.3 Traditional Learning and Reasoning . 16
4.9.4 Semantic Learning and Reasoning . 16
4.9.5 Cognitive Learning and Reasoning . 16
4.10 Model-Driven DSLs . 16
4.10.1 Introduction. 16
4.10.2 Constructing Model-Driven DSLs . 16
4.11 Model-Driven APIs . 16
5 ENI Information Model . 16
5.1 Introduction . 16
5.2 The Design of the ENI Extended Core Model. 16
5.2.1 Introduction. 16
5.2.2 The MCM (MEF Core Model) . 17
5.2.2.1 Introduction . 17
5.2.2.2 Naming Rules . 17
5.2.2.3 MCM Superstructure . 18
5.2.2.3.1 Overview . 18
5.2.2.3.2 MCMRootEntity . 19
ETSI
4 ETSI GS ENI 019 V3.1.1 (2023-06)
5.2.2.4 MCMEntity Hierarchy . 20
5.2.2.4.1 Overview . 20
5.2.2.4.2 MCMEntity . 20
5.2.2.4.3 MCMUnManagedEntity Hierarchy . 23
5.2.2.4.4 MCMManagedEntity Hierarchy . 24
5.2.2.4.5 MCMDefinition Hierarchy . 27
5.2.2.4.6 MCMPolicyObject . 32
5.2.2.4.7 MCMProduct Hierarchy . 32
5.2.2.4.8 MCMService Hierarchy . 34
5.2.2.4.9 MCMResource Hierarchy. 36
5.2.2.4.10 MCMServiceEndpoint . 41
5.2.2.4.11 MCMParty . 42
5.2.2.4.12 MCMDomain Hierarchy. 46
5.2.2.4.13 MCMBusinessObject Hierarchy . 50
5.2.2.5 MCMInformationResource Hierarchy . 52
5.2.2.5.1 Overview . 52
5.2.2.5.2 MCMInformationResource Class Definition. 53
5.2.2.5.3 Attribute Definition . 53
5.2.2.5.4 Operation Definition . 53
5.2.2.5.5 Relationship Definition . 54
5.2.2.5.6 MCMInformationResource Subclasses . 55
5.2.2.6 MCMMetaData Hierarchy . 56
5.2.2.6.1 Overview . 56
5.2.2.6.2 MCMMetaData Class Definition . 56
5.2.2.6.3 Attribute Definition . 57
5.2.2.6.4 Operation Definition . 57
5.2.2.6.5 Relationship Definition . 57
5.2.2.6.6 MCMMetaData Subclasses . 57
5.2.3 ENI Extensions to the MCM. 63
5.2.3.1 Introduction . 63
5.2.3.2 Naming Rules . 63
5.2.3.3 Events . 63
5.2.3.3.1 Introduction . 63
5.2.3.3.2 ENIEvent Class Definition . 64
5.2.3.3.3 Attribute Definition . 64
5.2.3.3.4 Operation Definition . 65
5.2.3.3.5 Relationship Definition . 66
5.2.3.3.6 ENIEvent Subclasses . 66
5.2.3.4 Behaviour . 70
5.2.3.4.1 Introduction . 70
5.2.3.4.2 ENIBehavior Class Definition . 71
5.2.3.4.3 Attribute Definition . 71
5.2.3.4.4 Operation Definition . 71
5.2.3.4.5 Relationship Definition . 72
5.2.3.4.6 ENIBehavior Subclasses. 73
5.2.3.5 Identity . 74
5.2.3.5.1 Introduction . 74
5.2.3.5.2 ENIIdentity Class Definition . 75
5.2.3.5.3 Attribute Definition . 75
5.2.3.5.4 Operation Definition . 75
5.2.3.5.5 Relationship Definition . 76
5.2.3.5.6 ENIIdentityProvider Class Definition . 76
5.2.3.5.7 Attribute Definition . 76
5.2.3.5.8 Operation Definition . 76
5.2.3.5.9 Relationship Definition . 76
5.2.3.5.10 ENIIdentity Subclasses . 77
5.2.4 ENI Extended Core Model . 78
5.3 Models that Inherit from the ENI Extended Core Model . 78
5.3.1 Introduction. 78
5.3.2 Policy Model . 78
5.3.2.1 Introduction . 78
5.3.2.2 Purpose . 78
ETSI
5 ETSI GS ENI 019 V3.1.1 (2023-06)
5.3.2.3 Extensions to the PDO Model . 79
5.3.2.4 MEF Types of Policies . 79
5.3.2.4.1 Introduction . 79
5.3.2.4.2 Imperative Policies . 79
5.3.2.4.3 Declarative Policies . 79
5.3.2.4.4 Intent Policies . 80
5.3.2.5 MEF Policy Model Naming Rules . 80
5.3.2.6 MEF Policy Hierarchy . 80
5.3.2.6.1 Overview . 80
5.3.2.6.2 MPMPolicyStructure Overview . 81
5.3.2.6.3 MPMPolicyStructure Class Definition . 82
5.3.2.6.4 MPMPolicyStructure Subclasses . 87
5.3.2.6.5 MPMPolicyComponentStructure Class Hierarchy . 92
5.3.2.6.6 MPMPolicyComponentStructure Class Definition . 93
5.3.2.6.7 MPMPolicyComponentStructure Subclasses . 93
5.3.2.7 ENI Extensions to the MPM . 122
5.3.2.7.1 Introduction . 122
5.3.2.7.2 Naming Rules . 123
5.3.2.7.3 ENI Policy Statement Extensions . 123
5.3.2.7.4 ENI Policy Clause Extensions . 127
5.3.2.8 ENI Extended Policy Model . 130
6 ENI Data Models . 130
6.1 Introduction . 130
6.2 ENI Technology-Neutral Data Model . 130
6.3 ENI Technology-Specific Data Models . 130
7 Requirements . 131
7.1 Information Model Requirements . 131
7.2 Data Model Requirements . 131
7.3 Ontology Requirements . 131
8 Future Work . 131
8.1 Open Issues for the Present Document . 131
8.2 Issues for Future Study . 131
History . 134

ETSI
6 ETSI GS ENI 019 V3.1.1 (2023-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Experiential Networked
Intelligence (ENI).
Modal verbs terminology
In the present document "shall", "shall not", "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
7 ETSI GS ENI 019 V3.1.1 (2023-06)
1 Scope
The purpose of the present document is to define the ENI information model. The present document will also provide at
least two different examples of how to derive technology-specific data models from the ENI information model.
Finally, it will explain how ontologies can be incorporated to augment, enhance, and specify meaning and different
relationships between modelled entities. This latter is critical to provide semantic reasoning. The present document is
specific to and enhances the current ENI System Architecture.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ETSI GS ENI 001 (V3.1.1): "Experiential Networked Intelligence (ENI); ENI use cases".
[2] ETSI GS ENI 002 (V3.1.1): "Experiential Networked Intelligence (ENI); ENI requirements".
[3] ETSI GS ENI 005 (V3.1.1): "Experiential Networked Intelligence (ENI); System Architecture".
[4] MEF 78.1: "MEF Core Model (MCM)", Strassner J., editor, July 2020.
[5] MEF 95: "MEF Policy Driven Orchestration", Strassner J., editor, July 2021.
[6] OMG: "OMG Meta Object Facility (MOF) Core Specification", version 2.5.1, October 2019.
[7] MEF 95.0.1: "Amendment to MEF 95: Policy Driven Orchestration", October 2022.
[8] The Semantic Versioning specification.
[9] NIST SP 1800-161: "Cybersecurity Supply Chain Risk Management Practices for Federal
Information Systems and Organizations", May 2022.
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] Strassner. J.: "Knowledge Representation, Processing, and Governance in the FOCALE
Autonomic Architecture", book chapter, 2011, Elsevier.
[i.2] Strassner, J.: "Policy-Based Network Management", Morgan Kaufman, ISBN 978-1558608597,
September 2003.
ETSI
8 ETSI GS ENI 019 V3.1.1 (2023-06)
[i.3] Strassner, J., de Souza, J.N., Raymer, D., Samudrala, S., Davy, S., Barrett, K.: "The Design of a
Novel Context-Aware Policy Model to Support Machine-Based Learning and Reasoning", Journal
of Cluster Computing, Vol 12, Issue 1, pages 17-43, March, 2009.
[i.4] Strassner, J., van der Meer, S., O'Sullivan, D., and Dobson, S.: "The Use of Context-Aware
Policies and Ontologies to Facilitate Business-Aware Network Management", Journal of Network
and Systems Management 17(3), pages 255-284, 2009.
[i.5] ETSI GR ENI 016 (V2.1.1): "Experiential Networked Intelligence (ENI); Functional Concepts for
Modular System Operation".
[i.6] Liskov, B.H., Wing, J.M.: "A Behavioral Notion of subtyping", ACM Transactions on
Programming languages and Systems 16 (6): 1811 - 1841, 1994.
[i.7] Gamma, E., Helm, R. Johnson, R., Vlissides, J.: "Design Patterns: Elements of Reusable Object-
Oriented Software", Addison-Wesley, Nov, 1994. ISBN 978-0201633610.
[i.8] Bäumer, D. Riehle, W. Siberski, M. Wulf: "The Role Object Pattern", Proceedings of the 1997
Conference on Object-Oriented Programming Systems, Languages and Applications
(OOPSLA '97), ACM Press, 1997, Pages 218-228.
[i.9] ETSI TR 102 748 (V1.1.1): "Electromagnetic compatibility and Radio spectrum Matters (ERM);
Impact of the trend towards flexibility in spectrum usage on the principles for drafting Harmonized
Standards and the ETSI work programme for Harmonized Standards".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS ENI 005 [3] and the following apply:
behaviour: way in which a set of objects function
NOTE: This includes how the object reacts in a particular situation given one or more events.
camelCase: naming convention in which the first letter of each word in a compound word is capitalized, except for the
first word
NOTE: This is also called lowerCamelCase.
formal: study of (typically linguistic) meaning of an object by constructing formal mathematical models of that object
and its attributes and relationships:
• formal grammar: set of structural rules that define how to form valid strings from a language's alphabet that
obey the syntax of the language
• formal semantics: set of tools that define grammatical meaning in a language
identity: the set of data and information that allow an object to be disambiguated from all other objects in a system,
including objects of the same type:
• digital identity: set of data and information used by a computer system to represent an actor, such as a person,
device, or application
• contextual identity: digital identity of an object for a particular context
ETSI
9 ETSI GS ENI 019 V3.1.1 (2023-06)
inheritance: defining the characteristics and behaviour of an entity on another entity
NOTE 1: The following definition of inheritance is from ETSI TR 102 748 [i.9]: "typical property related to the
concept of classes: when building a new derived class it will inherit properties from one or more
previously-defined base classes, while possibly allowing for redefining or adding new properties". The
ENI Information Model does not allow redefinition of properties, as this breaks information
encapsulation. See ETSI GR ENI 016 [i.5], clause 4.1.2.
• class-based inheritance: defining the characteristics and behaviour of a subclass on a superclass
NOTE 2: Class-based inheritance defines a subclass of a superclass as a class that keeps all of the characteristics
and behaviour of its superclass, and refines that definition in one or more of the following ways:
1) the subclass changes the class from abstract to concrete;
2) the subclass adds one or more attributes, operations, constraints, and/or relationships to its
definition.
• multiple inheritance: object or class may inherit characteristics and/or behaviour from more than one
superclass
NOTE 3: This style of inheritance is not used in ENI.
• single inheritance: object or class shall inherit characteristics and/or behaviour from only one superclass
model element: classes, attributes, operations, constraints, relationships and stereotypes used in constructing a model
override: changing of an attribute or operation implementation by a subclass that is already provided by its superclasses
NOTE: The ENI information model does not use overriding, because this alters the semantics of the class.
PascalCase: naming convention in which the first letter of all words in a compound word is capitalized
NOTE: This is also called UpperCamelCase.
refine: addition of attributes, operations, constraints, and/or relationships to an inherited class
NOTE: Refinement is only added to the semantics of the class. Refinement is not used to delete or override
attributes, operations, constraints, and/or relationships that it inherits.
semantics: study of the meaning of something (e.g. a sentence or a relationship in a model)
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
ASCII American Standard Code for Information Interchange
DSL Domain Specific Language
ECA Event-Condition-Action
ID IDentification
IP Internet Protocol
LDAP Lightweight Directory Access Protocol
MAC Media Access Control
MBM MEF Business Model
MCM MEF Core Model
MEF MEF (a standards body)
MIME Multipurpose Internet Mail Extension
MPM MEF Policy Model
ETSI
10 ETSI GS ENI 019 V3.1.1 (2023-06)
NFV Network Functions Virtualisation
OCL Object Constraint Language
ONF Open Networking Foundation
PDO Policy Driven Orchestration
POC Proof Of Concept
RDBMS Relational Database Management System
RMM Remote Monitoring and Management
SDO Standards Defining Organisation
SNMP Simple Network Management Protocols
SQL Structured Query Language
TMF TeleManagement Forum
TTL Time-To-Live
UML Unified Modeling Language
YANG Yet Another Next Generation
4 Representing, Inferring, and Proving Knowledge in
ENI
4.1 Introduction
A model is a representation of the entities of a system, including their relationships and dependencies, using an
established set of rules and concepts. It is a vital part of a larger knowledge management infrastructure, which includes
a set of interoperable hardware, software, and other artifacts, along with a set of standardized procedures to use them for
various tasks. Models include information and data models, as well as ontologies, as described in the subclauses below.
Artifacts include the representation and storage of data, information, knowledge, and wisdom (see ETSI
GR ENI 016 [i.5], clause 4.4), as well as inferences made by the ENI System (see ETSI GR ENI 016 [i.5], clause 4.5
and ETSI GS ENI 005 [3], clauses 6.3.4, 6.3.6 and 6.3.7).
4.2 Definitions
4.2.1 Information Model
An information model is a representation of concepts of interest to an environment in a form that is independent of data
repository, data definition language, query language, implementation language, and protocol. The purpose of an
information model is to represent facts in a technology-neutral manner.
4.2.2 Data Model
A data model is a representation of concepts of interest to an environment in a form that is dependent on data
repository, data definition language, query language, implementation language, and/or protocol. The purpose of a data
model is to represent facts in a technology-specific manner.
4.2.3 Ontology
An ontology is a language, consisting of a vocabulary and a set of primitives, that enable the semantic characteristics of
a domain to be modelled. The purpose of an ontology is to represent facts and meaning in a technology-neutral manner.
4.3 Information Model Usage in ENI
4.3.1 Purpose
The purpose of an Information Model is to define and manage objects and their relationships at a conceptual level,
independent of any specific implementations or protocols used to transport the data. ETSI GR ENI 016 [i.5] provides a
set of important principles for designing modular systems.
ETSI
11 ETSI GS ENI 019 V3.1.1 (2023-06)
Application interoperability requires a set of consensual high level patterns for the creation, manipulation, and use of
descriptive, machine understandable information. In particular, it is not enough to define data with a simple MIME type
(or its equivalent), as this does not provide needed semantics or metadata. The ENI information model defines a rich
metadata hierarchy (see clause 5.2 of the present document) and relationships that enable any class to optionally have
metadata attached to it. Examples include both descriptive (e.g. best current practices) and prescriptive (e.g. minimum
version of an object, or valid time interval of a policy) information [4].
An Information Model provides a standardized framework for organizing data. Its structure encourages reusability and
facilitates searching.
NOTE 1: Metadata may also provide advanced functionality by defining additional metadata information to search
on.
MEF 78.1 [4] and ETSI GR ENI 016 [i.5] provide an overview of the MEF Core Model (MCM) and a set of design
principles that use modelling, respectively. Key requirements in this approach follow (see clause 7.1 for more detailed
information):
• Inheritance: The ENI information model shall use single inheritance. This simplifies implementation, as not
all systems are able to implement multiple inheritance (MEF 78.1 [4]).
• Overriding attributes: The ENI information model shall not override an inherited attribute or operation. This
is because the semantics of the object containing the overridden attribute or operation are now changed
(MEF 78.1 [4]).
• Information Hiding: Information hiding prevents implementation details from being unnecessarily exposed.
This makes the design more robust, since implementations details are hidden behind a stable interface that
does not change. It also supports modular decomposition of a system into smaller, reusable components. The
ENI information model shall use information hiding to ensure that clients of an object do not have to change
when the implementation of an object changes. An important corollary is that different model elements can be
developed independently and do not have to know how other software entities work (ETSI GR ENI 016 [i.5]).
• Encapsulation: Encapsulation is an implementation mechanism that defines the boundaries of a model
element (e.g. a class is a collection of attributes, operations, and relationships that are part of a single object)
(ETSI GR ENI 016 [i.5]).
• Single Responsibility: Classes should be designed having one responsibility; this means that the only reason
for a class to change is if its responsibility changes (ETSI GR ENI 016 [i.5]).
• Liskov Substitution: Subclasses should be able to be substituted for superclasses without affecting the
behaviour of the system (ETSI GR ENI 016 [i.5]).
• Loose Coupling: Each element of a loosely coupled system should depend on as little knowledge as possible
of other elements. This means that classes should not depend on other classes. Rather, different types of
associations should be used to realize those dependencies (ETSI GR ENI 016 [i.5]).
NOTE 2: Many models use class attributes to contain values of one or more attributes of one or more other classes.
EXAMPLE: A Person class may contain one or more phone number attributes. This violates loose coupling. A
better design is to define a relationship between the Person class and a ContactInfo class. This
way, if one or more phone numbers change, the Person class is not affected.
• Design by Contract: Software entities whose behaviour needs
...