Child pages
  • Contributions

 

 

cid:image003.png@01D47AB3.2CCAF460

 

 

 

 

 

 

 

 

 

 

 


ONF Document Type: Technical Recommendation

ONF Document Name: Core Information Model version 1.5
 

Disclaimer

THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.

Any marks and brands contained herein are the property of their respective owners.

 

Open Networking Foundation
1000 El Camino Real, Suite 100, Menlo Park, CA 94025
www.opennetworking.org

©2018 Open Networking Foundation. All rights reserved.

 

Open Networking Foundation, the ONF symbol, and OpenFlow are registered trademarks of the Open Networking Foundation, in the United States and/or in other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners.   

 

Important note

This Technical Recommendations has been approved by the Project TST, but has not been approved by the ONF board.  This Technical Recommendation is an update to a previously released TR specification, but it has been approved under the ONF publishing guidelines for 'Informational' publications that allow Project technical steering teams (TSTs) to authorize publication of Informational documents.  The designation of '-info' at the end of the document ID also reflects that the project team (not the ONF board) approved this TR.

 


Table of Content s

Disclaimer

Important note

Document History

1 Introduction

1.1 References

1.2 Definitions

1.3 Conventions

1.4 Viewing UML diagrams

1.5 Understanding the figures

2 Introduction to Party

3 Party model detail

3.1 Party Model

3.1.1 AsymmetricPartyRoleRelationship

3.1.2 OrganizationUnit

3.1.3 Party

3.1.4 PartyRole

3.1.5 PartyRoleAddressContact

3.1.6 PartyRoleContactMethod

3.1.7 PartyRoleEmailContact

3.1.8 PartyRolePhoneContact

3.1.9 PartyRoleRelationship

3.1.10 ......................................................................... PartyRoleRelationshipType

3.1.11 ........................................................................................... PartyRoleType

3.1.12 ...................................................................................................... Person

3.1.13 ................................................................. SymmetricPartyRoleRelationship

3.2 Further detail

4 Party model examples

4.1 Employee

4.2 Customer Contact

4.3 Device Owner

List of Figures

Figure 3-1 Party Model

Figure 3 2 Party Model

Figure 3 3 Party Linkage to the CIM Core model

Figure 4 1 Organization Hierarchy subclasses

Figure 4 2 Organization Hierarchy Example

Figure 4 3 Customer Contact Subclasses

Figure 4 4 Customer Contact Example

Figure 4 5 Device Owner Subclass

Figure 4 6 Device Owner Example

Document History

Version

Date

Description of Change

1.0

December 2019

Initial Version


1        Introduction [A1]

This document is an addendum to the TR-512 ONF Core Information Model and forms part of the description of the ONF-CIM. For general overview material and references to the other parts refer to TR-512.1 .

1.1      References

For a full list of references see TR-512.1 .

1.2      Definitions

For a full list of definition see TR-512.1 .

1.3      Conventions

See TR-512.1 for an explanation of:

  • UML conventions
  • Lifecycle Stereotypes
  • Diagram symbol set

1.4      Viewing UML diagrams

Some of the UML diagrams are very dense. To view them either zoom (sometimes to 400%) or open the associated image file (and zoom appropriately) or open the corresponding UML diagram via Papyrus (for each figure with a UML diagram the UML model diagram name is provided under the figure or within the figure).

1.5      Understanding the figures

Figures showing fragments of the model using standard UML symbols as well as figures illustrating application of the model are provided throughout this document. Many of the application-oriented figures also provide UML class diagrams for the corresponding model fragments (see TR-512.1 for diagram symbol sets). All UML diagrams depict a subset of the relationships between the classes, such as inheritance (i.e. specialization), association relationships (such as aggregation and composition), and conditional features or capabilities. Some UML diagrams also show further details of the individual classes, such as their attributes and the data types used by the attributes.

2        Introduction to Party

The focus of this document is on concepts relating to "who".

This topic is a common one and there are a number of good models that can be leveraged.

Recording information about a person will be useful, but in business, many interactions are done via legal (company) entities.

Our model will need to link the company organization to the people it employs and who interact on its behalf.

The common modelling term used for both person and organization is party, which will be used throughout this document.

One approach that could be used in a model is just to add person name and company / department name attributes spread throughout the model as required. The problem is that name is often not a good identifier (someone might get married and hence change their name for instance) and then updating the data will become very complex.

The best approach is to factor out all party related information into a separate set of classes and to reference it from the rest of the model as required, and this is the approach taken in this document.

Note also that this document doesn't propose a full, robust enterprise grade party model as it is targeted at supporting a network management environment only.

 

A data dictionary that sets out the details of all classes, data types and attributes is also provided ( TR-512.DD ).


3        Party model detail

 

PartyRelationship – an abstract class that contains attributes common to both symmetric and asymmetric relationships.

PartyRoleRelationship  - allows the PartyRoles to be related. So that an employer can be related to its employees and a mother to her children. Note that this is used instead of a recursive composite style relationship. [DN2]

 

 

 

[DN3]

 

 

CoreModel diagram: Party

Figure 3 - 1 Party Model

 

 

Figure 3 2 Party Model

 

3.1      Party Model

….

3.1.1      AsymmetricPartyRoleRelationship

Qualified Name: Party::AsymmetricPartyRoleRelationship

An abstract class used when a relationship contains two roles, such as "parent-child".
Concrete subclasses should be created as required

This class is abstract.

 

Inherits properties from:

  • PartyRoleRelationship

This class is Experimental.

Table 1 : Attributes for AsymmetricPartyRoleRelationship

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_toPartyRole

  Experimental

 

  See referenced class

 

_fromPartyRole

  Experimental

 

  See referenced class

 

 

 

3.1.2      OrganizationUnit

Qualified Name: Party::OrganizationUnit

Represents a company entity or a unit within that entity (even if it doesn't have separate legal status).
The type attribute is used to classify what is being represented.

 

Inherits properties from:

  • Party

This class is Experimental.

Table 2 : Attributes for OrganizationUnit

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

type

  Experimental

 

  To be provided

 

 

 

3.1.3      Party

Qualified Name: Party::Party

An abstract class that allows us to link to either Person or OrganizationUnit.

This class is abstract.

 

Inherits properties from:

  • GlobalClass

This class is Experimental.

Table 3 : Attributes for Party

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_partyRole

  Experimental

 

  See referenced class

 

 

 

3.1.4      PartyRole

Qualified Name: Party::PartyRole

Represents party contextual behavior, allowing the core concept to be reused in different situations.
For example a person may be a butcher in the context of work, a daughter, wife and mother in the context of family.
An Organization unit may be an employer in the context of its employees a supplier to its customer and a customer to its suppliers (in the context of a given transaction).

This class is abstract.

 

Inherits properties from:

  • LocalClass

This class is Experimental.

Table 4 : Attributes for PartyRole

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_partyRoleContactMethod

  Experimental

 

  See referenced class

 

_partyRoleType

  Experimental

 

  See referenced class

 

 

 

3.1.5      PartyRoleAddressContact

Qualified Name: Party::PartyRoleAddressContact

Represents the information needed to contact someone via mail or to visit them.
Note that some addresses (such as post boxes) are only for mail and some addresses are used for both mail and geographic locations.
For geographic locations the address may be linked to geographic coordinates in the Location model.

 

Inherits properties from:

  • PartyRoleContactMethod

This class is Experimental.

Table 5 : Attributes for PartyRoleAddressContact

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

isPostalAddress

  Experimental

 

  To be provided

 

isStreetAddress

  Experimental

 

  To be provided

 

_location

  Experimental

 

  See referenced class

 

 

 

3.1.6      PartyRoleContactMethod

Qualified Name: Party::PartyRoleContactMethod

An abstract class decoupling the different types of contact information.
Note that we link to PartyRole, not Party as this allows for contextual contact methods.

This class is abstract.

 

Inherits properties from:

  • LocalClass

This class is Experimental.

 

3.1.7      PartyRoleEmailContact

Qualified Name: Party::PartyRoleEmailContact

Represents the information needed to contact someone by email.

 

Inherits properties from:

  • PartyRoleContactMethod

This class is Experimental.

Table 6 : Attributes for PartyRoleEmailContact

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

emailAddress

  Experimental

 

  To be provided

 

 

 

3.1.8      PartyRolePhoneContact

Qualified Name: Party::PartyRolePhoneContact

Represents the information needed to contact someone via phone.
Note that the information here is very basic and can be extended if needed, such as by adding country information.

 

Inherits properties from:

  • PartyRoleContactMethod

This class is Experimental.

Table 7 : Attributes for PartyRolePhoneContact

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

phoneNumber

  Experimental

 

  To be provided

 

 

 

3.1.9      PartyRoleRelationship

Qualified Name: Party::PartyRoleRelationship

An abstract class that contains attributes common to both symmetric and asymmetric relationships.
Allows the PartyRoles to be related.
So that an employer can be related to its employees and a mother to her children.
Note that this is used instead of a recursive composite style relationship.

This class is abstract.

 

Inherits properties from:

  • GlobalClass

This class is Experimental.

Table 8 : Attributes for PartyRoleRelationship

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_partyRoleRelationshipType

  Experimental

 

  See referenced class

 

 

 

3.1.10 PartyRoleRelationshipType

Qualified Name: Party::PartyRoleRelationshipType

To be provided

This class is Experimental.

 

3.1.11 PartyRoleType

Qualified Name: Party::PartyRoleType

To be provided

This class is Experimental.

 

3.1.12 Person

Qualified Name: Party::Person

Represents an individual, independent of any roles that they may play.

 

Inherits properties from:

  • Party

This class is Experimental.

 

3.1.13 SymmetricPartyRoleRelationship

Qualified Name: Party::SymmetricPartyRoleRelationship

Used when a relationship contains one role, such as "sister", this avoids having to create a releationship like "sister-sister".
Note that this class is concrete, unlike AsymmetricPartyRoleRelationship which is abstract.

 

Inherits properties from:

  • PartyRoleRelationship

This class is Experimental.

Table 9 : Attributes for SymmetricPartyRoleRelationship

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_partyRole

  Experimental

 

  See referenced class

 

_party

 

  See referenced class

 

 

 


3.2      Further detail

To link the Party model into the CIM core, it makes sense to decouple the network function classes from the Party model. The network functions deliberately don't have an abstract parent (for modularity reasons) which means that the best approach is to link the inventory model to the Party model via ConstraintDomain. This decouples the two modules (reducing the number of associations) and allows inventory items to be grouped before relating them to a Party, reducing the number of association instances to be managed and also giving much more sensible semantics.

 

Figure 3 3 Party Linkage to the CIM Core model


4        Party model examples

4.1      Employee

To show an Organization hierarchy, we will add the following subclasses to the main model.

 

Figure 4 1 Organization Hierarchy subclasses

This enables us to build an organization hierarchy and attach employees where required in the hierarchy, as shown in the instance diagram below.

Figure 4 2 Organization Hierarchy Example

 


4.2      Customer Contact

To support customer contacts, we will extend the base model with classes that cover those we have contractual relationships with.

Figure 4 3 Customer Contact Subclasses

John Swan is a customer of ours and we have both email and phone contact details for him.

Figure 4 4 Customer Contact Example


4.3      Device Owner

Our data center hosts equipment owned by various Tenants.

Adding an owner role will allow the model to represent ownership of Equipment assets.

Figure 4 5 Device Owner Subclass

A ConstraintDomain is created to group all the devices for a given tenant and it is then related to the PartyRole.

Figure 4 6 Device Owner Example


End of Document

 

 

 

 


[A1] To the reviewer

-           Hypertext document references “TR-512…” will not work at this point (as they reference the .pdf files that have not yet been generated).

-           There are some comments in some documents please consider the comments as you review.

-           If you have proposals to change text (typos or small rewordings for grammar errors), please modify the text with change tracking enabled.

If you have major concerns or questions or general comments please use word comments (like this)

[DN2] Two comments and one class only… I changed PartyRelationship to PartyRoleRelationship and used both comments.

[DN3] Your original diagram