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

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

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)

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

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

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) https://www.martinfowler.com/apsupp/roles.pdf Allows the model to scale by reducing coupling Has the same dependency direction as the inheritance relationship, supporting model modularity Abstract Concrete Refer contribution onf2016.391 Canonical

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to Extend the Core Model Tooling

Extending the CIM model in Papyrus – Steps Make sure are using the correct version of Papyrus (currently 2018-09) 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

Extending the CIM Model Examples

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.

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.

Discussion