1. Task 13 Scope – Model Structure (L=ChrisH)
Purpose – look at the current ONF CIM structure and produce recommendations and document architectural patterns / guidelines for future work
Specifically – look at improving the model modularity and managing dependencies
Includes – producing an action plan for any recommended model changes
Excludes – actually changing the model
External Dependencies – None, but his work may impact other items.
Assumptions – That the model can be refactored at a later date when these guidelines are approved by the team.
Risks - None known at this stage

2. Team Members Leader - Chris Hartley chrhartl@cisco.com Members
Nigel Davis

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

4. Background
As the ONF CIM matures and expands in scope and size, we need to make sure that we have the correct architectural underpinnings to enable future scalability
We need a model that : (adapted from [Martin])
Isn’t hard to change
Isn’t fragile (fragility causes changes to cascade)
Isn’t overly complex
Doesn’t contain large amounts of repetition
Allows modular reuse
Has clear concepts that are easy to understand
Also see

5. Required Actions
Create model modules and implement proper module dependency rules and auditing (tool support ?) Modules are a crucial boundary concept as we need to be able to enforce rules on groups of artefacts within a model. Our model must not degenerate into a monolith
Also model modularity will help in extending and maintaining our models as it enables model autonomy. Note that some modularity may emerge as we progress, requiring some model refactoring
Annotate the model with stereotypes that help in ensuring the model adheres to sensible design rules (for example limiting which artefacts can be referenced outside of a module and in what ways)
Document typical model patterns to be used to manage coupling between modules (including defining any supporting stereotypes to be used)

6. Clean up model paths
Paths should not contain spaces or any characters other than a-zA-Z
They should use lower camel case
They should start with org.onf.cim, so CoreCommonDataTypes::AddressRelatedTypes::MacAddress would become org.onf.cim.core.common.dataTypes.address.MacAddress
Update the model guidelines document !

7. Clean up folder structure
We need to move away from folders for objectClasses, Associations, TypeDefinitions and Diagrams as this is causing too much entity clumping
Before
After

8. After
Before

9. org.onf.cim.core.network.link.LinkHasLinkPorts
Before
After

10. Spec first level
After
Before

11. LTP Spec
After
After

12. Break the model into smaller modules ?
Is there any dependency checking within a module ?

13. Put Associations in the correct package
If the Association is one way navigable
Put it in the same package as the non-navigable end (the end that can navigate to the other end)
If the Association is both way navigable
Put it in the same package as one of the ends (prefer composite or aggregate ends)
Use a validation tool to find any misplaced associations
could possibly get the tool to auto move anything it can

14. Mistral Packages Example