Model Aspect Mechanisms

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.

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

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

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 https://modeling-languages.com/ocl-tutorial/

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)

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

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

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

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

Important Examples

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 https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

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

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

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.