This page is about ONAP modeling design principles and guidelines for release 2+

Guidelines:

1-Initial focus on a Unified IM and TOSCA construct representation

...

Lingli Deng I agree the scope for the entire modeling stack is too broad for us to work with within Release 2  time frame. I recalled that we agreed on starting with SERVICE and RESOURCE modeling for Beijing earlier. So I suggest we could consider rephrase it as "Initial focus on a Unified IM and TOSCA construct representation on Service and Resource".

Andy Mayer:

• Initial focus of Information Model will capture Service Desc, VNF Desc models
• First doing an Information Model and then do a TOSCA representation based on the Information Model applying OASIS TOSCA Simple Profile 1.2
• The model will support the VNF requirements (e.g. scaling). The modeling team should not define the feature requirements, but rather Information Model support for defined requirements.
• Principles focus on the "what"
• Guidelines are best practices and focus on the "how" 

Image Added

2-Align terminology with ETSI (IFA11, IFA14) where appropriate

...

 Lingli Deng: Good suggestion. We should encourage mutual contribution between this community and SDOs or other OS communities as always. But the suggested efforst, although welcome and encouraged,  is not committed to this specific group, nor is the target or constraint to the practice of this specific group. Hence, I suggest removal of the entirety of this statement.

Andy Mayer: Moving these to the Principles section

[ Munish Agarwal] Identify DM for VNFD based on the SDC DM, eCOMP IM and NFV SOL001 (IFA011)
Lingli Deng This statement is duplicating the guideline Item #4.

Munish Agarwal] Identify DM for NSD based on the eCOMP  IM and NFV SOL001 (IFA014)

Lingli Deng This statement is duplicating the guideline Item #4. ]

•Try to maintain backward compatibility

...

Munish Agarwal] Define UML modelling guidelines. Take inspiration from IISOMI 514 UML Modeling Guidelines

>> See Informal Inter-SDO Open Model Initiative (IISOMI)

Lingli Deng UML is another Data Modeling language, it is not clear to me what would be the benefits of introducing another DM to represent the IM, or whether or not it would introduce undesirable constraints in defining the IM. Since it is not an urgent decision, I suggest we could leave the choice/recommendation on using it and its tools out of the current document and for further discussion.

...

• Unified Modeling Language (UML) is a standard syntax for describing the architectural design of a system
  • Object Management Group (OMG) & ISO standard
  • Originated from object-oriented software development methods
• UML includes many diagrams types to graphically represent parts of a system’s model, including
  • Structural Views: The static nature of the system using objects, attributes and relationships (e.g., information or components that must be present in the system)
  • Behavioral: The dynamic nature of the system through collaboration of objects and state changes (e.g., activities performed by the system)
    
    
• Information models are protocol agnostic; data models are protocol specific.
• Eclipse Papyrus is one open source tool for creating and editing UML content. There are many UML tools on the Market.

...

•Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.2 ( Munish Agarwal] Not clear. Consider rephrase)

•Create ONAP TOSCA profiles/templates derived from Information Model applying TOSCA 1.2 types and constructs

   -Follow the principals define in next slide

•Validate the model using the selected use cases

•Tools: Papyrus

• Andy Mayer Papyrus will be used for Information Modeling in UML

• Andy Mayer Track ONF progress on EAGLE tool support of TOSCA generation 
  

• Munish Agarwal] IM Language: UML

  Lingli Deng UML is another Data Modeling language, it is not clear to me what would be the benefits of introducing another DM to represent the IM, or whether or not it would introduce undesirable constraints in defining the IM. Since it is not an urgent decision, I suggest we could leave the choice/recommendation on using it and its tools out of the current document and for further discussion.

• Brian Hedstrom See my comment above on UML.

• Munish Agarwal] Evaluate the EAGLE work done in MEF to generate APIs from the Models

  Lingli Deng API is not in the scope for this group, I suppose.

• 
  
• Brian Hedstrom Data Models and APIs are a translation from the UML Models (interface realizations). 
  

 Principles:

Andy Mayer (moved from Guidelines Section) Identify DM for VNFD based on the SDC DM, eCOMP IM and NFV SOL001 (IFA011)

Andy Mayer (moved from Guidelines Section) Identify DM for NSD based on the eCOMP IM and NFV SOL001 (IFA014)

•New constructs
   -Best effort to use TOSCA Simple Profile 1.2 “normatives”
   -Extend/Derive from Simple Profile 1.2 “normatives”s (Munish Agarwal] Using simple profile 1.2 as basis and define new constructs taking in consideration both SOL001 and TOSCA NFV profile is the proposed way forward. Is that the correct understanding. Please clarify in either case)

...

   -DM are pruned and refactored from IM
   -Discuss extensibility guidelines to be progressed

•Properties
   -Best effort to put properties on capabilities (Not clear. Consider rephrase to clarify)

   Andy Mayer (reworded) - Include support for properties in TOSCA capability types

•Namespace
  -TBD

• Thinh Nguyenphu] In order to avoid namespaces and types name types definitions collision, it is recommended that ONAP uses the rule and guidelines as described in the OASIS TOSCA Simple YAML Profile v1.2. At minimum, ONAP describes:
  • Namespace Alias: TBD
  • Namespace Prefix: TBD
  • tosca_definitions_version:TBD
  • ONAP's types: naming convention and format

Create ONAP profiles/templates derived from IM using TOSCA 1.2 types