1. Task 58 Scope – Occurrence Pattern
Purpose – To better document the occurrence pattern and when it applies
Specifically –Includes –
Excludes – none
External Dependencies – none
Assumptions – none
Risks – none

2. Team Members
Leader - Members
???

3. IPR Declaration Is there any IPR associated with this presentation NO
NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on Cisco or any other company. The requirements are subject to change in form and numerical value after more study. Cisco specifically reserves the right to add to, amend, or withdraw statements contained herein.
THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

4. Occurrence Pattern
To date it has been a pattern in the specification Layer only, but this may change as we find more ways to use it
It appears when projecting some operational layer composite associations to their specification equivalent
The issue is that in the operational layer, the composed class may have a mix of parent contextual and parent independent attributes
For example in “chassis contains slot” the slot number is chassis contextual, the slot type (PCI, PCI-Express, ISA, VESA) is not
The parent specific attributes go in the occurrence spec class
Could we call it the “composed reference” pattern ?

5. Where we have seen / used it to date (see later slides)
LTP and Port Spec
Equipment and Holder Spec
Soft Property and Soft Template (Spec)

6. Mapping Non Composites
Typically the spec layer is less restrictive than the operational layer
Association multiplicities more expansive
Bothway association navigability x’ y’ y x
Typical Operational to Specification multiplicity projections
x’, y’ *
1..*
Assoc Class or intermediate class
x, y
0..1 1
1..* * or * – * x’ y’ x y

7. Mapping Composites We need to decide when mapping the composite 1 to xy
We need to decide when mapping the composite 1 to x
Is it completely shared ? If so than x can be 1..* with no composite
If it’s a composite, then we can’t use a many multiplicity, so we need to split out the composite parent part from the shared part 1
0..1 or * or 1..* 1 y’ * 1 y’ *
1..* y
0..1 1 1 y

8. Is this pattern recognized elsewhere ?
Not that I have seen
“Policy-Level Specifications in REA Enterprise Information Systems” lists some specification level patterns, but doesn’t consider composites at all. It does have a section “Policy-Level Associations”

9. Current Uses of the pattern

10. LP Spec Model was the first
This is a double occurrence pattern because of the component – port pattern
LP Spec # #
LtpSpecLpEntry is critical to get the result we need
1..* 1
LP Spec Reference in LTP Spec
LP Spec Reference in LTP Spec
Refer also Network Graph Patterns Revisited.pptx

11. Equipment / Holder Spec
“Prototypical” Chassis #
It seems to make sense when mapping composite associations into the Spec layer to do this.
The general pattern of changing assoc end multiplicities from one to many can give odd results

12. And again for Physical Connector#

13. Soft Template to a Soft Model
Here a Template can’t define its own attributes, it can only reference existing attribute definitions
Soft-soft pattern #

14. Soft Template with locked model value
@ - In this case we have either
a normal attribute value, or
a (readonly) reference to a profile value
Soft Template with locked model value
Note that now profile / template and the normal model are intertwined so they effectively become a single model (still splits along operational / knowledge lines) @ #

15. So is this just the Occurrence Pattern ?
Replacing
Some variant of (1..* or *, navigability, composite or not)
with