This document specifies ONAP modeling design principles and guidelines for release 2+.
...
1- Requirements driven and prioritization per release
2- Based on existing implementation and
...
attempt to
...
maintain backward compatibility
3- Keep the distinction and consistency between Information model and its data model representation(s).
...
b) Based on the use cases, select or define the appropriate model terms if the one-to-one mapping is not possible.
5- Identify the gaps in either information modeling (in terms of information elements) or data model (in terms of types/constructs) we need to fulfill the functional/non-functional requirements derived from the use cases and prioritize per release.
...
c) Encourage efforts in other SDOs to align with ONAP IM/DM implementation with their specifications (e.g. TOSCA NFV Profile and SOL001) development.
...
6- When defining new constructs in ONAP Data model
a) Start with OASIS TOSCA Simple YAML Profile 1.
...
1
b) Make use of OASIS TOSCA Simple YAML Profile 1.
...
1 normative node types
c) If direct use of OASIS Simple YAML Profile 1.
...
1 normative node types is not possible, extend/derive from existing node types or create new ones as appropriate
d) Consider some special feature of 1.2 if needed by the use case
7- When defining new Namespace, in order to avoid namespaces and types name types definitions collision, ONAP follows the rule and guidelines as described in the OASIS TOSCA Simple YAML Profile v1.
...
1.
...
8- Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.
...
1
Open Issues
ONAP Modeling Design Principles and Guidelines Open Issues