Drawing from TR-512.7 Nigel Davis 20190430 Spec Model Rework Drawing from TR-512.7 Nigel Davis 20190430

Presentation Goals To highlight some key aspects of the spec model and discuss/propose enhancements

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

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

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

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 used in TAPI so far applies a set of predefined properties for a specific technology to the CEP 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

All classes and structures need specs Canonical

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

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

Rough sketch of target (for further discussion) Specify opportunities for referencing instance include: Augmentation (decorates… inserting attributes into class that drives the instance) Constraint on core properties (redefine of core attributes for instance) Constraint on behaviour Invariant per occurrence of type (maintained in spec for type) 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 HasSpec Definition Augment Specify P&R P&R Core Model Spec Model Refined Tech Model TechnologyModel Pattern Specific class to class relationships Trace Back Trace Back P&R, Instantiate P&R, Occurrence P&R, Occurrence P&R, Occurrence HasSpec (Class-instance) P&R P&R DesignTime Instance Specific Spec Model Occurrence Refined Tech Model Occurrence Tech Model Occurrence Application RunTime Definition Augment Definition Augment P&R RunTime DesignTime P&R ProprietaryTech Model Occurrence Profile Occurrence Specific rules and constraints P&R RunTime HasProfile (Class-Instance)

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

Rough sketch of Basic Profile (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 Disjoint OR ReadOnly Related Augment P&R Profile Instance Refined Tech Spec Occurrence RunTime HasProfile (Class-Instance)

Progressing the Specs Generalized model pattern Generalized realization form Discussion

Terminology (rough) Object: An entity that represents what is perceived as a single thing. The thing may have influence over other things. Conceptual object: Presents the notion of a single thing. It represents the opportunity to express the current, absolute, specific, singular value for each of the exposed properties of the thing. It may express the opportunity to change properties of the thing, The properties apply to aspects within the spatial instance of the thing that the object represents. The values of exposed properties may influence the behaviour of other things. There can be versions of the conceptual object representing the thing at different points in time (history or speculative future) Implementation object: Presents the façade to an apparent single thing. It expresses/exposes the current, absolute, specific, singular value for each of the exposed properties of the thing and allows modification as appropriate. The properties apply to aspects within the spatial instance of the thing that the object represents. The implementation object is an ongoing (time instance by time instance) representation of the current state of only one spatial instance of thing. A traditional object: varies through time, does not imply definition applied to any other visible entities, is precise in terms of absolute values, has no recursive definition depth Entity: A thing. Hence an object is a thing that represents another single thing. Thing: What is perceived as a thing is actually an assembly of smaller things viewed from a particular perspective. Class: An entity that carries the bounding definition (of the semantic volume) of a classification of things, including definitions of properties (i.e., name, type and ranges etc.). As the class is an entity, it can itself be considered from one perspective as an object. A class also defined entities and, as an object is an entity, an object can be defined by a class. As a class is an object, an object is defined by an object that takes a defining role. A traditional class: is time invariant, applies definition to a number of entities, is precise in terms of ranges, applies constraints to one level of recursive depth Relationship role: Two things can be related. When related, one thing takes a role with respect to the other in the context of the relationship. Constraint: May be applied to restrict the range of possible configuration values. Constraint Continuum: A constraint reduces possibilities. The tightest of constraints allows only one possibility. Precision: A statement of measurement precision exposes a range within which a stated value is uncertain (where the precise value cannot be measures, is unknown nor is undeclared) Precision Continuum: Precision states the accuracy and hence reduces the possible realities that the measure represents. The tightest precision allows only one possibility Precision-Constraint Uniformity: The definition of precision and of constraint appear to be the same uniform representation of ranges and opportunities. Class-Object duality: An entity is a single thing (implementation object) that can both represent an apparent single thing (conceptual object) as well as define other things (class). Both in representing a single thing and in defining other things it can both have absolute, specific, singular values and have value ranges. In all three aspects (implementation object, conceptual object and class) it can vary in time The key dimensions appear to be: time, number, precision, definition indirection, influence

Terminology (rough) Occurrence: Pattern Case: Instance of a situation. Augmentation: The process of merging definition elements (properties etc.) from one definition into another definition Specify: The process of defining properties, of providing fixed values for properties, of defining rules etc. Specification: A structure of entities that are Class-Instance Dualities that apply t Visibility: Whether a property of an instance can be observed or not Profile pattern: The common structure and characteristics that relate to all cases of flexible constraint of specified entities of a class Specification pattern: The common structure and characteristic that relate to defining of the occurrence of a form of a class where the occurrence is instantiated Combinations Profile Class: An entity that carries the definition of a profile Profile Instance: Often called a Template Specification Class Specification Occurrence

Q&A