1. Model Aspect Mechanisms

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

3. Common Mechanisms
This pack looks at mechanisms that can be used to deal with common aspects of a model
It then looks at the situations that each is suitable for

4. Inherit From ‘Top’
In a model that has every class inherit from a ‘Top’ or ‘Root’ class then attributes can be added to any/every class by adding them to ‘Top’
In practice, this is a really bad option as it tightly couples all the classes together (a monolith)
Also if there are classes say with an existing ‘description’ attribute say of type ShortString. Then if someone adds ‘description’ to ‘Top’ of type LongString then we have a clash
Also this is a brute force approach as it adds attributes that may not be appropriate
So, not recommended for any situation

5. OCL The issue is that OCL doesn’t really simplify the model
It adds complexity for modelers who should be focusing on intent, not on trying to write ‘code’ in the model
It adds complexity for the generators that have to decode the OCL and perhaps even to try and decipher the intent from the OCL
context Rental::newRental(id:Integer, price:Real, startingDate:Date,
endingDate:Date, customer:Customer, carRegNum:String, pickupBranch: Branch, dropOffBranch: Branch)
pre: customer.licenseExpDate>endingDate
post: Rental.allInstances->one(r | r.oclIsNew() and
r.oclIsTypeOf(Rental) and r.endingDate=endingDate and r.startingDate=startingDate
and r.driver=customer and r.pickupBranch=pickupBranch and r.dropOffBranch=dropOffBranch
and r.car=Car.allInstances()->any(c | c.regNum=carRegNum))
Example from

6. UML Primitive (Metamodel)
This allows new definitions to be added and used where appropriate
Appropriate for ‘opaque’ simple types (no internal structure) without identity
Useful when generating to a target language (e.g. Yang) that has the primitive
For example macAddress, ipAddress (perhaps)

7. Model Datatype Define in a common package(s) so they can be reused
Use when the type is not simple (has internal structure) and there is no identity
For example Quantity, Money, IpAddress (perhaps)
May map to a target language (e.g. Yang) that has the definition in a common package

8. Stereotype (Metamodel)
May be used in combination with the previous options
Use the stereotype as additional information when generating to a target language
For example the UML concept of Integer can be mapped to target languages like XML that have int, short and long types defined by adding stereotypes to Integer type attributes with <<16bit>>, <<32bit>> and <<64bit>> modifiers
For example a generator can add an identifier to an Entity based on a <<GlobalIdentity>> or <<LocalIdentity>> stereotype
For example a directive like <<YangRoot>> can be added to the model to greatly simplify generator logic

9. Factored out Concept This makes sense when the concept has identity
For example Location and Party concepts
This is also the only option if you want to create a “viewpoint”, such as Location

10. Relies on specific Generator support
Summary
Solution
Supports Identity
Implement in
Relies on specific Generator support
Complexity Supported
UML Primitive N
Metamodel Y
Very small
Model Datatype
Model
Small
Stereotype
Small #
Factored out Concept
Large
# - the amount of complexity added to the model is small, but in conjunction with the generator algorithms, very sophisticated results are possible

11. Important Examples

12. IP Address
The solution here is not 100% clear and depends on how IP address is to be treated
One option is to use a primitive shared by both IPV4 and IPV6
Another is to use a primitive wrapped by a datatype which also includes an Enum stating the type of address – which could also include VPN …
Note that IANA defines a number of address families, but a single address solution probably doesn’t make sense

13. Identity
This is so fundamental that it really needs to be supported by the underlying infrastructure / platform
The solution needs to be able to support different needs for different parts of an implementation – for example Java identity via .equals() vs relational database identity via primary key and languages like Yang and SNMP/MIB which uses oids for identity and so using a stereotype seems to make the most sense

14. Note (attachment)
The need is to be able to attach a ‘file’ to some records
We could define a primitive ‘note’ but this seems excessive, but we may need a ‘blob’ primitive type, giving us an attribute like “notes:blob[*]”
A datatype ‘Note’ may be useful to wrap the ‘blob’ primitive with some metadata such as file-name, size, type giving us “notes:Note[*]”
A key question is does the note have identity and if so how is it calculated ? Or do we just consider it as a ‘binary string’ ?
One option may be to base identity on a hash of the file contents (e.g. using SHA-1). Then if the same file is attached many times then it is only stored once. This is similar to how Git works. For example a SHA-1 hash can be represented as ASCII like “L9ThxnotKPzthJ7hu3bnORuT6xI=”
This concept of identity is different from our standard one, so a stereotype such as <<HashIdentity>> may be useful for the generator to store the blobs in a separate table with the hash as the primary key and replace the blob attribute type with a string for the hash

15. Time Period & Temporal Expression
TimePeriod makes sense as a Datatype (start and end time primitives)
Temporal Expression though needs to have identity so it can be referenced and reused and also so its parts can be linked together. This means that it requires a factored out concept model.