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

2. 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 …

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

4. 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

5. 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

6. 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

7. 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 

8. 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

9. LTP with ports
New model sketch

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

11. Expressing Capability and Needs Pruning and Refactoring
Recap

12. 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

13. 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)

14. 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.

15. 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

16. 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

17. 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.

18. LTP spec considerations

19. Current LTP Spec for 1.4 and 2.n
The Diagram shows the 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.

20. Questions?
Thank you 