LTP Port and Spec enhancements for “2.0” Nigel Davis (Ciena) 20180614

Adding port to LTP The LTP represents the effects of functionality related to termination and adaptation of signal protocols The functionality represented by the LTP is of significant variety and complexity It encapsulates/abstracts that complexity and exposes the effects via its attributes and associations (as do all classes that represent functionality) The effect of the functionality encapsulated is described in the LTP Spec (currently to a limited degree) The LTP spec is a degenerate description system The system described is an abstraction of the complex system actually realizing the LTP The description is intended to be sufficient to allow full understand of the capability and to interpret the visible controls and visible effects (attributes) A description system (I need a better name for this) is equivalent to the functional schematic of an integrated circuit in that it explains the arrangement of meaningful macro-functions but does not describe the actual underlying system The properties of the LPs that the LTP is composed of provide the dynamic values to be understood in terms of the specific invariant spec for the LTP The LTP model is a degenerate form of the Component-Port pattern where associations are used to express port role The absence of the port complicates the model and makes full specification more awkward …

Component-Port Pattern Component-System Pattern Rule Patterns Recap with comments in red

Component-Port pattern Most of the associations on this diagram should be to LtpPort The current model has many cases of Component-Port where the Port provides access to the capability of the Component The Components considered are functional (but the same pattern applies to physical things) All Components are asymmetric in nature such that different capability is exposed at different Ports (such that the Ports essentially have roles in the context of the apparent internal structure of the Component) In some narrow cases we can ignore the asymmetry and fold the Ports away TMF IG1118 distinguished between four very distinct Port types where the most “interesting” currently are Operations and Application We need to continue to develop this area

Component-System Patterns LTP is a component with ports It is described in terms of a system of Components LPs, TerminationSpecs etc Some of the ports on spec components are SystemBoundaryPorts and hence Ports on the LTP The Component-System pattern appears to underpin all models of capability The System is NOT simply: An aggregation, a collection, of bits in a bag A UML Composition which allows from no more than an owned collection The System is an assembly of interconnected Components where the specific interconnection is critical consideration The Component is a bounded context which exposes underlying capability via its Ports Not shown here… the Capability of a Component can be represented in the form of an apparent System We should continue to develop this area

Component-System Pattern – Refactoring We currently appear to use several different refactorings of the Component-System pattern The figures show two progressions from the full pattern to the most basic form Further figures that show how the capabilities are exposed may help explain the pattern Remove SystemBoundaryPort Remove System Remove Port Remove Port Remove System The LTP uses the most degenerate form but is associated to from parts of the model that use ports… so the overall model is a hybrid of refactoring degrees

Strengthening the Component-Port This provides a sketch of the LTP and LP ports The LTP is a Component that is a System of Components, LPs. The LTP and LP ports are not exposed directly There appear to be several cases that would benefit from LTP/LP port exposure However, exposure of a generalized Port appear to complicate the model It is proposed that: The LTP class and the LP class have LtpPort and LpPort added The Spec model be enhanced to deal with ports Changes to add Ports be considered as a 2.0 release considering the significance of the change We work to make 1.n and 2.n compatible 

Rule Patterns As shown, but not discussed, in the previous slides Associations are interrelated In the Class model the associations appear to form loops but in some cases in the instance models these are Loops, but in other cases they are Spirals. Some of the Spirals are LockStep so as one go instance Spiral progresses, so does another The association instances are represented via attributes and it is these attributes that that are constrained Some constraints are influenced by other attributes that are not explicit representatives of associations Raw UML is silent in this area of complexity The only UML mechanism that appears to allow the necessary capability/access is the Constraint Constraints represented in OCL has been shown to be complex and OCL is a very narrow specialist area Alternative constraint languages may be less opaque but stating that patterns per case is complex and error prone It is proposed that a “DSL” of labelled Constraint patterns be developed and that these drive OCL etc

LTP with ports New model sketch

First cut LTP with Port (showing primary context) Note that the view mapping function should describe the inter-view relationship.

Expressing Capability and Needs Pruning and Refactoring Recap

Unification It is assumed that expression of Capability and of Need can be of the same form The focus here will be on Capability Currently, capability is expressed via specific spec structures, one for each the key class, LTP, FC etc., in the model A spec may include several cases of use of one of the spec elements In addition, there are scheme/system specs that express the capability of systems of key classes But considering, from a fundamental perspective, the arbitrary position of the class boundary, it would seem to be the case that system specs and key class spec should be of the same structure and hence the structure should be unified It would seem that the Component-System pattern should be a basis for the unified structure

Class to spec to instance Spec for class X Spec case S of class X Instance 1 of case S of class X P&R Part Type A Part Type B Part Type A.c Part Type B.w Part Type A. (c) Part Type B.1 (w) Part Type A.d Part Type B.y Part Type A.1 (d) Part Type B.1 (y) The spec pattern is expanded for each case to have the necessary occurences of each part, interconnected within the constraints of the Spec structure The Spec case is then instantiated for each occurrence of the case Instance 2 of case S of class X Part Type A.2 (c) Part Type B.2 (w) Part Type A.2 (d) Part Type B.2 (y)

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.

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

But… An approach is to develop a generalized Component spec using the Component-System pattern where a particular usage is developed by P&R of the pattern to give necessary constrained parts This method would allow the generation of a scheme/system spec structure and an LTP spec structure But as noted earlier, the LTP can be derived from the Component- System pattern by appropriate application of P&R The challenge is what are the classes and what are the constraints, or, as noted earlier, can we simply consider a class as a representation of constraints

Proposal Construct a generalized Component-System spec Apply this via repeated P&R to yield a refined LTP and System/Scheme spec etc In the process, loosen the LTP/LP spec to support photonics Part of this needs to be done in 1.4.n/1.5.n to enable description of the Photonic network LTPs etc but there will need to be further work in 2.0 to fully rationalize this and to deal with LtpPort and LpPort Explore restarting the P&R tooling and use of it to assist this work, especially in the 2.0 time frame.

LTP spec considerations

Current LTP Spec for 1.4 and 2.n The Diagram shows the 1.3.1 spec For photonics in 1.4 we need to add an “FC” to the LTP spec instead of the Connection Spec This will need ports and its own spec It appears that LP recursion and Termination recursion would make sense Adding ports and recursion sufficiently is essentially applying the Component-System pattern In 2.n it is probably valuable to refactor the LTP spec to be a full generalized Component-System spec with constraints on what components can be used.

Questions? Thank you 