bits Modelling and Mapping

[bzeuner]

The current "bits" modeling and mapping has two issues:

1. It is not possible to define a separate data type that can be used by many attributes.
2. OpenInterfaceModelAttribute::bitsDefinition does not allow to add a description.

Proposed solution:

1. Define a new Primitive Type Bits
2. Remove defaultValue from BitsDefinition
3. Add optional description to BitsDefinition
4. Remove BITS from Encoding

The usage would then be as follows:

Question: The YANG bit statement has in addition if-feature, reference and status. Should we also add these properties to the BitsDefinition?

What do you think?

[bzeuner]

We discussed the issue at the OTIM call July 10. The reference and status sub-statements of the YANG bit statement are already covered by the current UML Profiles. The if-feature sub-statement is added via the support/condition pattern; see the updated BitDefinition below:

[bzeuner]

IISOMI UML to YANG Mapping call August 1: The bitsDefinition property should not be part of every attribute since it is only required for Bits typed attributes. Using the BitDefinition data type directly as the type of the Bits typed attribute doesn’t work because it is not possible to provide attribute values in class definitions. Using an enumeration containing a literal for each bit also doesn’t work because the literals of the enumeration are defined as exclusive or whereas the bits exist all at the same time. It was agreed to mark the modeling and mapping of Bits typed attributes as “preliminary” in the guideline documents.

[bzeuner]

Alternative modeling proposal from Scott:

UML:

Stereotype:

myBits Default value:

Position Description in Stereotype:

[bzeuner]

Scott's proposal assumes that the type of the bits typed attribute (myBits) is always defined in a separate data type (MyBitsType) since the Bits stereotype is only extending the DataType metaclass.

Is it also possible to define in YANG a bits typed leaf without a separate typedef like shown below?

grouping bits-using-class {
    leaf my-bits {
        type bits {
            bit disable-nagle {
                position 0;
            }
            bit auto-sense-speed {
                position 1;
            }
            bit ten-mb-only {
                position 2;
            }
        }
        default “auto-sense-speed”;
    }
}

If Yes, we could define that the mapping tool should always create a typedef for each bits typed leaf.

[samans]

All information is available in either solution. Depends on whether you want all the information stored in the attributes of a stereotype, or if you want explicit datatypes created that can be shown on a class diagram. The tooling will not care, since it is just a matter of the tool understanding where to get the information that will be generated for YANG.

For Bernd's option: I would want to be able to see the values of the attributes for the stereotype on the class diagram. Also, I am not a fan of having an attribute called "defaultValue" when we should use OCL for such things. If we don't care about OCL, then the tool just needs to know how to map the defaultValue to the default value syntax of the target language.

[bzeuner]

@samans : I agree with your justification. It provides more information about the bit set in class diagrams:

[bzeuner]

IISOMI Infrastructure Sub-team call August 31: A summary of the two alternative (preliminary) solutions defined in the UML Modeling Guidelines is provided in iisomi2018.BZ.007.01_Bits_Modeling-Mapping.docx. Agreement: It was agreed to go forward with solution 2; i.e., the modeling proposed above by @samans.