ONAP Modeling Design Principles and Guidelines (20171023)

This document specifies ONAP modeling design principles and guidelines for release 2+.

The Principles section focuses on "what" foundations need to be followed as part of the ONAP Modeling effort, while the Guidelines section focuses on the plan for "how" to achieve the goals described in the Principles section and identifies best practices that may be applied.

Principles

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

a)  DM can represent the semantics of the IM. DM does not need to match exactly the IM.

b)  DM are pruned and refactored from IM.

4- The Information Models and Data Models from this effort should be applied across ONAP projects.

5- The modeling subcommittee should not define the feature requirements, but take feature requirements derived from use cases or architecture or implementation projects as input.

6- Actively pursue participation from stakeholder projects in the modeling effort.

Guidelines

1- Initially focus on a Unified Information Model in UML and its TOSCA construct representation for Service and Resource

2-   Use Eclipse Papyrus as the UML modeling tool for this activity

3-   Recommend new item on the M3 API Freeze Checklist to identify and describe mapping of API information elements to the ONAP Unified Information Model and related Data Models.

4   Best effort to align terminology with ETSI (IFA011 and IFA014) where appropriate.

a)  Establish a mapping between equivalent terms between ONAP and ETSI NFV ISG and identify the differences.

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.

a)  Initial round should be based on SDC Data Model and OpenECOMP (ONAP) Information Model

b)   Identify existing constructs defined in other SDO specification (e.g. TOSCA NFV Profile and SOL001

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

b)  Make use of OASIS TOSCA Simple YAML Profile 1.2 normative node types

c)  If direct use of OASIS Simple YAML Profile 1.2 normative node types  is not possible, extend/derive from existing node types or create new ones as appropriate

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

8-  Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.2