1. Extending and Refining the OTCC/OIMT Models
TR-512.P.3 (sketch)
Nigel Davis (building on work by Chris Hartley)

2. Presentation Goals
Discuss and develop approaches to enable parallel work on extending the CIM core model in various context

3. The need for extension and refinement….
Canonical capability – OIMT (Core)
Working in collaboration to add capability to the model (from both new insight, e.g., Software, and from OTCC work (TAPI, WT, OTIM))
Appling patterns across the model (e.g., Component-System to LTP)
Interface capability – OTCC (TAPI, WT)
Extending from core (Pruning & Refactoring (P&R), e.g., Equipment)
Refining existing interface within scope of core (e.g., recent adjustments to the Connectivity model in TAPI)
Extending beyond the core (for subsequent feedback into the core (reverse P&R), e.g., OAM)
Technology – OTCC (OTIM, TAPI, WT), OIMT (Core), vendors, network operators
Refining, applying and making available standard work from other bodies
Network structures – OIMT (Core), OTCC (TAPI, WT), network operators vendor
Expressing constrained arrangements (patterns) of occurrences of classes
Vendor specification
Technology (including proprietary extensions)
Capability (including specific device restrictions)
Application (Focussing standard on need (Pruning))
Operator specification
Application (including selection of specific interface capabilities)

4. Canonical capability – OIMT (Core)
The approach to extending the Core in 1.4 was not well defined
Improve modelling approach for future releases
Refine model structure to remove unnecessary coupling
Optimizing dependencies
Use decoration approach to better decouple models
Breaking Core into separate models
Use of sub-model unit techniques for specific temporary cases
Carefully apply Lifecycle stereotype
Lifecycle Compatibility
Minimizing impact on previous versions
Enable Parallel working
Improvements above in conjunction with sufficient process definition
Improve handling of
Urgent draft work for interface deployment
Reverse P&R from TAPI
Canonical

5. Coupling of UML Relationships between Modules must be unidirectional
Inheritance (unidirectional coupling) 1
Composition Association (unidirectional) 2
One way association (unidirectional)
Decreasing coupling
Technology Module
Core Module
UML Dependency relationship, showing technology module depends on core module
Note that coupling BETWEEN modules should be unidirectional and the direction must match the module dependency direction. Also we can’t allow module dependency loops to form.
1 Using Abstract classes designed as extension points allows us to reduce the inheritance coupling, making it suitable for use between modules.
2 We need to decide if composition associations between modules is allowed or not. Aggregation associations are just treated as normal associations.
The association end multiplicity also has an impact on coupling. Restrictive multiplicities (0..1, 1, 1..*) imply more coupling than an unrestricted multiplicity (*)
Canonical

6. The Decoration Pattern provides an alternative to Inheritance
The Decoration pattern allows inheritance to be replaced with a directed 0..1  1 association
Having a stereotype that supports <<Decorates>> helps to clarify the intent of the association
The stereotype <<Specifies>> supports decorate and more (see later).
Decoration :
Allows options to be ‘assembled’ avoiding the need for mixed subclasses (BlueGreen  Blue + Green instances)
Allows the model to scale by reducing coupling
Has the same dependency direction as the inheritance relationship, supporting model modularity
Abstract
Concrete
Refer contribution onf
Canonical

7. The ONF Core model is strongly patterned and technology agnostic
The ONF core model provides a framework for technology specific model development
It is comprised of
Key concepts such as LTP, ForwardingDomain and ProcessingConstruct
Custom network management Metamodel extensions such as primitive types and stereotypes
Standard pattern definitions
Patterns have major impact on model structure etc.
Enhancing the patterns is challenging and broadly impacting
P&R relationship from Core to TAPI/WT can protect them from immediate impact
Canonical

8. There are 8 key classes in the ONF CIM Core Model
Canonical

9. Interface capability – OTCC (TAPI, WT)
Extending from core by P&R
TAPI makes extensive use of Refactoring, WT makes lesser use of Refactoring
Refining existing Interface within scope of core
Extending beyond the core
Whilst not ideal, to achieve necessary pace this is an allowed approach
Reverse P&R must be carried out
Interface

10. Technology extensions
Utilise Core model spec approach
This is available in TAPI and being adopted by WT
Take work from external body, rearrange into appropriate spec structures
Note that the core LTP spec is being enhanced to support more complex structure
Attach specs to appropriate model class (TAPI/WT)
Whilst these specs could be used as they are, the expectation is that vendors produce their own variants that provide a clear statement of per device combination capability
Technology extensions should have a run-time dynamic application
Technology

11. Progression of Classification – Adding semantics
Thing has the common properties
Info
This is not the approach we take
Thing
Component
Equipment
Controller PC
LTP

12. Progression of sub-setting – Constraining Semantics
Thing has all possible properties.
Specific semantics relate to the specific modelled thing and are a narrowing of thing.
The definitions do NOT need to be orthogonal/disjoint although the intersections should be minimised.
Consider the LTP
Covers all aspects of termination and adaptation
Coverage includes recursive definition of encapsulated forwarding
All possible properties of termination and adaptation are within the allowed set
Specific properties are defined in specific specs. These properties are expressed in the appropriate instances.
Thing
Component PC
Equipment
Information
LTP
Controller
Canonical

13. Further thoughts
The detailed capability of a thing is expressed by decorating with parts that themselves have constrained semantics that fit within the definition of the thing
The capabilities may be expressed in terms of apparent subordinate parts where these parts can be positioned on the constrained semantic map
An LTP may have controllers within it but those controllers only emerges when the LTP is dismantled or its behaviour is expressed.
Canonical

14. Spec approach
Defines the decoration that details, for a particular case, part of the semantic space covered by the class
This allows for a dynamic extension (and reduction) of exposed capability which interplays with intent
The scheme spec describes a system structure in terms of classes of the model and in terms of constraints
The same grammar for systems of constraints would appear to apply here
The scheme spec provides the constraints on what outcomes can be requested
Specification

15. Network structures
Expressing constrained arrangements (patterns) of occurrences of classes
Occurrence is covered on Wednesday
The implications of Occurrence are covered on Thursday (spec rework)
Extension for network structure definition is essentially the same as for Technology definition
Specification

16. Operator and Vendor specification
Technology (including proprietary restrictions and extensions)
Applying P&R to the standard technology spec to get a restricted ste
Augmenting that spec with proprietary extensions
Capability (including specific device restrictions and deployment)
Adding specific rules for restricted devices and policies for deployment
Specification

17. Decorate the core framework with Technology specifics
Create a new Papyrus model (in the Core project)
Import the appropriate (CIM/TAPI/WT) model(s)
Build technology specific class structure
Use the decoration pattern to layer onto the core model and any other needed technologies
Tech 1
Tech 2
Tech 3 …
Core Model
Specification

18. TAPI ODU spec Technology
<<specify>> currently causes the tooling to do an augment
These properties will appear in the CEP when it is an ODU “Trail Termination Point”
Technology

19. Observations
The method discussed so far applies a set of predefined properties for a specific technology to the CEP
The extension is provided as part of the TAPI standard
The spec simply causes an augment and hence the specify stereotype triggers the construction of Yang augment
There is a broader set of requirements for the Spec which will be discussed under the “Spec Rework” Topic

20. Rough sketch of basic spec (for further discussion)
Specify opportunities for referencing instance include:
Augmentation (decorates… inserting attributes into class that drives the instance)
P&R allows for:
Constrained redefine of attributes
Narrow range
Becomes read only
Removal of non-mandatory attributes
Constrained restructuring of the Technology Model
Addition of ONF specific properties and stereotypes
Implied (HasSpec)
Specify
P&R
Core Model
Class
Refined Tech Spec Model
TechnologyModel
Pattern
Specific class to class relationships
Trace
Back
P&R,
Instantiate
P&R,
Occurrence
P&R,
Occurrence
Implied (HasSpec (Class-instance))
Augment
P&R
Instance
Refined Tech Spec Occurrence
Tech Model Occurrence
Application
RunTime

21. This produces a Common Protocol / Feature Structure
Decoration association used instead of inheritance
Key Component #
Key Component Port # 1 1
<<specify>>
<<specify>>
Feature Module
Port attributes for the protocol
0..1
0..1
Component Properties
Port Properties
Feature ConceptA
Protocol specific concepts
Feature ConceptC
Feature ConceptB
# the Key Components defined in the ONF CIM core model are : LTP, FC, FD, Link, Control Construct, CD and PC

22. How the Protocols / Features add up
ERPS Module
PTP Clock Module
PTP ConceptB
<<specify>>
<<specify>>
ERPS Properties
Key Component #
PTP Properties
ERPS ConceptA
ERPS ConceptB
<<specify>>
<<spcify>>
PTP ConceptA
ERPS Port Properties
Key Component Port #
PTP Port Properties
# the Key Components defined in the ONF CIM core model are : LTP, FC, FD, Link, Control Construct, CD and PC

23. How to Extend the Core Model
Tooling

24. Extending the CIM model in Papyrus – Steps
Make sure are using the correct version of Papyrus (currently )
Git…, Load Core… (can we simplify this??)
Use the supplied blank model and rename it
Import any necessary additional models
Build and relate model
If Papyrus brings up the “Enable Write” dialog
Press “Cancel” !!
Make sure associations are one-way following the defined dependencies
DO NOT subclass the core model
Pull request…
xxxxxxxx

25. Extending the CIM Model
Examples

26. How an ERPS model can be added to the ONF CIM
The ERP concepts are defined in their own module, under org.onf.model.cim.erpsG8032 .
The module dependency needs to be into the more abstract core model.
Using decoration rather than inheritance reduces the coupling into the core model.

27. How a PTP Clock model can be added to the ONF CIM
The PTP Clock concepts are defined in their own module under org.onf.model.cim.ptpClock .
The module dependency needs to be into the more abstract core model.
Using decoration rather than inheritance reduces the coupling into the core model.

28. Discussion