...

1. each node from edgerules has to be present in OXM
2. ?

OXM Class Definitions to EdgeRules Classes

The OXM schema definition contains both a "plural" and a "singular" form of each class like the example below, which describes:

• VRFs (plural)
• VRF (singular)

        <java-type name="Vrfs">
            <xml-root-element name="vrfs"/>
            <java-attributes>
                <xml-element container-type="java.util.ArrayList" java-attribute="vrf" name="vrf" type="inventory.aai.onap.org.v16.Vrf"/>
            </java-attributes>
            <xml-properties>
            </xml-properties>
        </java-type>

        <java-type name="Vrf">
            <xml-root-element name="vrf"/>
...
            <xml-properties>
...
            </xml-properties>
        </java-type>

The EdgeRules only refer to the singular form of the classes, but also contain a "multiplicity" that allows for "many" objects to be in the relationship, like the example below, which describes:

• "many VRFs belongs To one PNF"

{
	"from": "vrf",
	"to": "pnf",
	"label": "org.onap.relationships.inventory.BelongsTo",
	"direction": "OUT",
	"multiplicity": "MANY2ONE",
	"contains-other-v": "!${direction}",
	"delete-other-v": "!${direction}",
	"SVC-INFRA": "NONE",
	"prevent-delete": "NONE",
	"default": "true",
	"description":"A vrf belongs to a pnf."
},

Errors and Warnings

1. if the multiplicity is defined as "ONE2ONE", then attempts to add more than one object to either side of the relationship will result in an error
2. if the multiplicity is defined as "MANY2ONE", then attempts to add more than one object of the "to" class will result in an error
3. if the multiplicity is defined as "ONE2MANY", then attempts to add more than one object of the "from" class will result in an error

All relationships are mostly optional, so in the UML model:

• the cardinality for "ONE" should actually be "0..1"
• the cardinality for "MANY" should actually be "0..n"

Thus, an incorrectly restrictive EdgeRule multiplicity is detected through exhaustive testing of all the data combinations, but redundant "MANY2MANY" EdgeRule multiplicity is detected through audit and inspection.

OXM Containment to TREE EdgeRules

In the OXM schema definition, the containment relationship looks like the example below, which describes:

...

These OXM containments must be matched by "TREE" EdgeRules like the example below, which describes:

• "PNF contains other vertex VRF"
• "when deleting PNF, also delete other vertex VRF"

{
	"from": "vrf",
	"to": "pnf",
	"label": "org.onap.relationships.inventory.BelongsTo",
	"direction": "OUT",
	"multiplicity": "MANY2ONE",
	"contains-other-v": "!${direction}",
	"delete-other-v": "!${direction}",
	"SVC-INFRA": "NONE",
	"prevent-delete": "NONE",
	"default": "true",
	"description":"A vrf belongs to a pnf."
},

The "TREE" EdgeRule is defined by the properties:

• "contains-other-v", which indicates that "one vertex contains the other vertex"
• "delete-other-v", which indicates that "when one vertex is deleted, also delete the other vertex"

in other words, it is a "composition" relationship in a UML model.

The convention is to use the label "BelongsTo" as in "VRF belongs to PNF", however, this text has no particular significance in terms of the code behaviour of the system. There are examples of other labels being used instead of "BelongsTo".

Errors and Warnings

1. if an OXM containment is defined in the schema, but the "TREE" EdgeRule is not defined, then there will be a run-time error in the system when attempting to PUT data involving those classes of objects
2. if the OXM containment is removed from the schema, but the "TREE" EdgeRule is not removed, then the EdgeRule becomes redundant but does not trigger any warnings or errors in the system

Thus, missing EdgeRules are detected through exhaustive testing of all the data combinations, but redundant EdgeRules are detected through audit and inspection.

OXM Relationships to COUSIN EdgeRules

1. uni-directional navigation
   1. tbc with examples
2. bi-directional navigation
   1. tbc with examples

tbc