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)
Allows modular reuse
Is not overly complex
Doesn’t contain large amounts of repetition
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.
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. Supporting Slides

7. Validation to Design Rules and Metrics
In trying to determine the ‘goodness’ of a model, it will be useful to have
A ‘validator’ that can validate ONF CIM specific rules. This is especially important where we have extended the UML metamodel (e.g. via Stereotypes) and a standard UML tool won’t have any rules to enforce
A ‘metrics’ reporter (such as ) that can highlight not errors, but things that look unusual (for example an inheritance tree 20 levels deep may not be an ‘error’ but it should be highlighted for investigation and possible re-design)
See also csse.usc.edu/GSAW/gsaw2003/s8e/in.pdf

8. These concepts all relate
‘Usability’
From

9. Second principle of OOD
“Favour object composition over class inheritance” [GoF], p.20)
To avoid confusion (such as thinking this means to use composition associations instead of inheritance), we will rephrase this as “Favour assembling objects over class inheritance”
Object composition is often implemented in code using method delegation
Subclassing is often called ‘white-box reuse” and object assembly as ‘black-box reuse”

10. Coupling of UML Relationships
Inheritance (unidirectional coupling)
Composition Association (bidirectional)
Bothway Association (bidirectional)
One way association (unidirectional)
Decreasing coupling
Note that we only want unidirectional coupling BETWEEN modules.
Using Abstract classes designed as extension points allows us to reduce the inheritance coupling, making it suitable for use between modules.
We need to decide if composition associations between modules is allowed or not.
Aggregation associations are just treated as normal associations.

11. A note on Reduced Coupling
In the ONF CIM, we are defining a model to be used to define a management interface
The proposed dependency rules can be thought of as defining a MINIMUM set of required dependencies, that allow us to maintain and grow these interface definitions
It would be folly to define a maximally dependent model and have implementers needing to chose which dependencies to remove
An implementation can add reverse dependencies as they retrieve data via the management interface and then discard any surplus dependencies when writing to the management interface For example in a relational database, foreign key references are created based on association multiplicity which may not match the defined association navigability – perhaps even resulting in a dependency reversal

12. Additional Stereotypes will help to audit the model design
Some additional stereotype based restrictions may help us to manage the use of the model.
For example we could implement restrictions like these outside of a module
NoXtrnImplement
NoXtrnExtend
NoXtrnInstantiate
NoXtrnOverride
NoXtrnReference
Or the default could be to have all of these disallowed, unless enabled using
XtrnImplement …
From

13. Package Design Principles
Package dependencies must be unidirectional and must form a directed graph (no loops)
This means that the only possible interactions between any given pair of modules A & B, where A depends on B, are :
A can use as attribute types any Datatypes and Enums in B
A can one-way associate to any entity in B, AB
A can subclass any Entity or Datatype in B

14. Concepts from DDD Layered Architecture Entities vs Value Objects
Modules
Aggregates
Bounded Context
Shared Kernel
Core Domain Segregated Core / Abstract Core
Knowledge Level (constrains and describes the operational layer)
Domain Events (added later)

15. DDD Aggregates
This concept was only touched on in the original DDD book, but has turned out to be important and has been expanded on in later works [Vernon]
Aggregates are proposed as a consistency scope boundary (Model and Module are too big, Artefact level is too small) to manage ACID transactions
Using Aggregates also helps to implement an Event sourcing architecture, where changes to an Aggregate instance can be sent as events, avoiding the need to continually poll the management interface
Aggregate definitions will help us manage dependencies within a module – for example to limit the size of composition trees

16. Identity and Identifiers
Implementing the Entity concept requires a proper corresponding identifier implementation

17. Model Structure - Extremes
Neither of these theoretical extremes is useful in practice
Full Mesh N*(N-1)/2 possible links
Network Diameter = 1
Star N possible links
Network Diameter = 2
Note that the lines represent general relationships, not specific UML ones

18. Model Structure – Hybrid (Mesh of Stars)
Network Diameter = 3
Note that the lines represent general relationships, not specific UML ones

19. Model Structure – More Realistic (Mesh of Meshes)
Network Diameter = 5 ?
Note that the lines represent general relationships, not specific UML ones

20. The Model as a Graph
If the model can be exported as a graph (.gml) file, then a standard graph analysis package can analyse it