1. Brief update and critical issues
IISOMI Guidelines
Brief update and critical issues
November 7, 2017

2. Guidelines Overview
Brief update

3. Common Information Model
multi SDO
UML to DS Mapping Guidelines
IISOMI 531: UML to YANG Mapping Guidelines
IISOMI 515: Papyrus Guidelines
UML | YANG
IISOMI 514: UML Modeling Guidelines
Pruning/Re-factoring Process Guidelines
IISOMI
UML | XML
Guidelines
UML | JSON
guide
guide
guide
UML | TOSCA
guide
Common Information Model
pruning re-factoring a
mapping
Tooling
YANG xx b
pruning re-factoring
Technology specific
mapping
UML Models c xx
TR-512: Core Network (Forwarding, Topology, Termination, Foundation, …) …
pruning re-factoring
mapping
App specific z xx xx
Core Fragment
Specific Fragments
Purpose-specific IMs
Interface-specific Data Schemas
Interface-specific Encodings
guide
guide
guide
guide
guide
guide
guide
TR-513: Common Information Model Overview (structure, development process)

4. Guidelines Overview UML Modeling Guidelines (IISOMI 514)
Last published version  v1.2, Sept. 2016
Latest working draft  v1.3.04, Nov. 2017
Updates between v and v1.3.04
«LifecycleAggregate» aggregation added
Usage example for «LifecycleAggregate» aggregation added
Passed by reference/value defined
Realization dependency relationship added
ClassDiagramStyleSheet.css file updated
Specification Architecture figure updated

5. Guidelines Overview UML to YANG Mapping Guidelines (IISOMI 531)
Last published version  v1.0, Sept. 2016
Latest working draft  v1.1.05, Nov. 2017
Updates between v and v1.1.05
Definition of condition property fixed.
Naming Conventions Mapping enhanced.
New section on YANG Workarounds added.
Mapping of associations updated.
YANG prefix list added.
Literal name constraint added (in case of identity mapping).
Literal name style mapping updated.
Specification Architecture figure updated

6. Guidelines Overview Last published version  v1.2, Sept. 2016
Papyrus Guidelines (IISOMI 515)
Last published version  v1.2, Sept. 2016
Latest working draft  v1.3.02, Nov. 2017
Updates between v and v1.3.02
Re-added display setting constraint from version 1.1
Specification Architecture figure updated
Potential next update
Move from Papyrus Mars (1.1.x) to Papyrus Oxygen (3.x.0)

7. Guidelines Overview UML Profiles OpenModel_Profile
ProfileLifecycle_Profile
Apply Profile to Model
InterfaceModel_Profile
Style Sheets
Apply Style Sheet to Class Diagrams
Apply mandatory profile/style sheet
Apply optional profile
Prune&Refactor

8. Guidelines Overview OpenModelProfile, v0.2.13
UML Profiles
OpenModelProfile, v0.2.13
OpenInterfaceModelProfile, v0.0.8
ProfileLifecycleProfile, v0.0.4
Style sheet for class diagrams
Github repository: Profile-and-Tools/tree/ToolChain/UmlProfiles

9. Guidelines Overview Separate discussion timeslot
UML to OpenAPI Mapping Guidelines
Separate discussion timeslot

10. (that benefit from face to face discussion)
Critical Issues
(that benefit from face to face discussion)

11. Critical Issues Specification pattern  Monday P2 (Andrea)
UML Modeling Guidelines
Specification pattern  Monday P2 (Andrea)
Use of association classes  (need John Strassner?)

12. Critical Issues UML to YANG Mapping Guidelines
Mapping of Neutralized Augment Path Example and Test Models
«Specify» abstraction with condition (Example from Karthik)
Use of must Statement
Mapping Object Classes to Identities
Polluting the model with additional attributes vs use identity at all
Modeling of Instance Identifiers: YANG Keys
«LifecycleAggregate» Relationship Mapping

13. Backup

14. Conditional Specify/Augment - UML

15. Conditional Specify/Augment - YANG
module common-model {
namespace "urn:onf:params:xml:ns:yang:common-model";
prefix common-model;
container object-class-1 {
uses object-class-1;
presence "Presence indicates ...";
description "none"; }
grouping object-class-1 {
leaf attribute-1 {
type string;
description "Stereotype <RootElement>
name: String [1] = _objectClass1
multiplicity: String [1] = 1..1
description: String [0..1] = Presence indicates ..."; ……
module spec-1-model {
namespace "urn:onf:params:xml:ns:yang:spec-1-model";
prefix spec-1-model;
import common-model {
prefix common-model; }
augment "/common-model:object-class-1" {
when "common-model:attribute-1='ABC'";
uses object-class-1-spec-1;
description "none";
when "common-model:attribute-1='XYZ'";
uses object-class-1-spec-2;
grouping object-class-1-spec-1 {
leaf attribute-a-1 {
type string; ……
grouping object-class-1-spec-2 {
leaf attribute-a-2 {
type string;
description "none"; }

16. New Simple Augment Path Example

17. New Augment Path Example

18. TestModel (CommonModel and Spec1Model)

19. Specify Example module entity-model { … grouping entity-c {
leaf example-attr-1 {
type uint64; }
leaf example-attr-2 {
type boolean;
list entity {
key 'example-attr-1';
uses entity-c;
module spec-model {
grouping specification-c {
leaf example-attr-3 {
leaf example-attr-4 {
augment "/entity-module:entity" {
uses specification-c;

20. „must“ Statement Usage Example of must and error-message from YANG:
container interface { leaf ifType { type enumeration { enum ethernet; enum atm; } } leaf ifMTU { type uint32; } must ’ifType != "ethernet" or ifMTU = 1500’ { error-message "An Ethernet MTU must be 1500"; } must ’ifType != "atm" or’ + ’ (ifMTU <= and ifMTU >= 64)’ { error-message "An ATM MTU must be "; } }
Usage Example of must from draft-ietf-ccamp-mw-yang-01.txt:
augment "/if:interfaces/if:interface" { when "if:type = 'mrl:radio-link-terminal'"; …
leaf-list carrier-terminations { type if:interface-ref; must "/if:interfaces/if:interface[if:name = current()]" "/if:type = 'mrl:carrier-termination'" { description "The type of interface must be 'carrier-termination'."; } min-elements 1; description "A list of references to carrier terminations included in the radio link terminal."; }

21. Simple UML Model for Instance Identifiers

22. Reference diagram for «LifecycleAggregate» stereotype application
grouping owning-class {
... }
grouping grouping-class-a {
grouping grouping-class-b {
grouping shared-part-class {
container owning-class {
uses owning-class;
list shared-part-class {
key "name";
uses shared-part-class;
list grouping-class-b {
uses grouping-class-b
leaf-list shared-part-class {
type leafref {
path "/owning-class/shared-part-class/name";
list grouping-class-a {
uses grouping-class-a
leaf-list grouping-class-a {
path "/owning-class/grouping-class-a/name";

23. «LifecycleAggregate» Relationship Mapping Examples
grouping owning-class {
... }
grouping grouping-class-b {
grouping shared-part-class {
container owning-class {
uses owning-class;
list shared-part-class {
key "name";
uses shared-part-class;
list grouping-class-b {
uses grouping-class-b
leaf-list shared-part-class {
type leafref {
path "/owning-class/shared-part-class/name";