1 Introduction

The intent is to identify a set of rules and good practises about Information model definition in ONAP.

ONAP information model is documented in Papyrus (see Using Papyrus for Modeling for more information).

IISOMI Modeling Guidelines (IISOMI TR 514) is taken as reference and extended where needed.

2 Requirements of the Information Model

An information model proposal can be posted in ONAP wiki.

An IM model proposal shall provides:

  • A class diagram showing the new classes and relations (including inheritance, aggregation and association) with any other class in ONAP IM and across any ONAP administrative domain (i.e. common, resource and service domains).
  • A inheritance diagram for each new class
  • A definition of each new IM entity by a dedicated descriptive table 

ONAP IM entities are: classes, association, data type and enumeration

2.1 OpenModelAttributes Guidelines


2.2 Requirements about ONAP Class Definition

A Class in ONAP shall have the following properties: 

  • Name: in alignment with IISOMI TR 514, Name follows Upper Camel Case style (UCC). Each class in ONAP model (and across any ONAP administrative domain, ie. common, resource and service domains) has a unique name.
    • Example: Qualified Name: Common::Location::ObjectClasses::Place
  • Documentation: in alignment with IISOMI TR 514, Contains a short definition. The documentation is carried in the “Applied comments” field in Papyrus; i.e., the “Owned comments” field shall not be used. The complete documentation should be written in a single comment; i.e., at most one “Applied comment”.
    •  Example: .....
  • Superclass(es): (Parent class)  in alignment with IISOMI TR 514, Inheritance and multiple inheritance may be used to deal with shared properties.
    • Example: Parent class: RootEntity
    • TBV: is multiple inheritance supported in ONAP ? 
  • Applied Steoreotypes: Following stereotypes needs to be identified
    •  Example:
             - Experimental
             - OpenModelClass
                   support: MANDATORY
             - Reference: From TMF SID
  • Abstract : in alignemnt with IISOMI TR 514, Indicates if the object class can be instantiated or is just used for inheritance; i.e., abstract classes will not be instantiated.
    • Example: .


Following properties are not mandatory in ONAP: 

  • Is Leaf : Indicates that the object class must not be extended (Is Leaf = true); default = false



2.2.1 Requirements about ONAP Class Attribute Definition

An attribute about a class in ONAP shall have the following properties:

  • Name
  • Type
  • Multiplicity
  • Description
  • Stereotypes


Example

2.3 Requirements about ONAP Association Definition


  • Name: in alignment with IISOMI TR 514, Name follows Upper Camel Case (UCC) style and is unique across all relationship names defined in the whole model.
    The format for associations is "<Class1Name><VerbPhrase><Class2Name>" where the verb phrase creates a sequence that is readable and meaningful. In case of a long class name, it is also allowed to use a short form of the name.
    •  Example:
  • Documentation: in alignment with IISOMI TR 514, it contains a short definition. The documentation is carried in the “Applied comments” field in Papyrus; i.e., the “Owned comments” field shall not be used. The complete documentation should be written in a single comment; i.e., at most one “Applied comment”.
  • Type: in alignment with IISOMI TR 514,The following types are used: simple association, composition association, aggregation, association, generalization, dependency, usage dependency, abstraction dependency, realization dependency.


Following properties are optional in ONAP: 

  • Navigable member end (true, false): It identifies if a  member end of an association is navigable or not (i.e. if the object class as a member end, has a pointer to the other member end). Navigability is not a property of the association but of each class taking the role of an association member end.
    • Example: A bidirectional association where each object class has a pointer to the other. A unidirectional association (open arros at the target object class) where only the source object class has a point to the target object class and not viceversa.


To be added: 

  • Aggregation (shared aggregation vs composite aggreation)  

2.4 Requirements about ONAP Datatype Definition

  • Name: Name follows Upper Camel Case (UCC) style and is unique across all relationship names defined in the whole model.
    The format for associations is "<Class1Name><VerbPhrase><Class2Name>" where the verb phrase creates a sequence that is readable and meaningful. In case of a long class name, it is also allowed to use a short form of the name.
    •  Example: Qualified Name: Common::Location::TypeDefinitions::CityQualifiers
  • Documentation: it contains a short definition. The documentation is carried in the “Applied comments” field in Papyrus; i.e., the “Owned comments” field shall not be used. The complete documentation should be written in a single comment; i.e., at most one “Applied comment”.


2.4.1 Requirements about ONAP DataType Attribute Definition

An attribute about a class in ONAP shall have the following properties:

  • Name
  • Type
  • Multiplicity
  • Description
  • Stereotypes


2.5 Requirements of Defining the Enumerations

3 Requirements of Using Gendoc

Besides the Papyrus diagrams, detailed defintions of the ONAP IM entities (i.e., class, association, data type and enumeration) are required on the model proposal wiki page.

They are usually copied from the word document generated using the Gendoc template.

The Gendoc template can be found at "GenDoc/ONAP GenDoc template.docx" in the source code, and can be used through Eclipse Gendoc plugin.


Requirements before generating a word document using the template:

1) open the template

2) edit the <param key='model_name' value='Pnf'/><drop/> line

    replacing 'Pnf' with the sub model name (e.g., 'Vnf') for which you want to generate the document

3) edit the <param key='user_path' value='D:\eclipse-workspace\ONAP_IM'/><drop/> line

    replacing 'D:\eclipse-workspace\ONAP_IM' with the actual directory path on your local disk, containing the papyrus models (i.e., the *.uml and *.notation files)

4) save the file, and use the template to generate word documents, the generated files can be found under "GenDoc_output" directory

  • No labels