Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

See also the Use Case Guidance wiki: Use case guidance from Modeling subcommittee

The following diagram illustrates the overall Modeling process.

...

The artifacts listed here, summarizes artifacts that are relevant to the modeling sub-committee

TOPICDESCRIPTIONEXAMPLE WIKI
Information Model

See above the Mx descriptions for a more detailed discussion of the development and review of the information model. The information model that contains the following:

  • Classes

  • Relationships with Multiplicity

  • Attributes with Multiplicity 

  • Definitions

  • Data Types 

Tooling - The tooling for the Information model includes Papyrus in Gerrit/GitHub repository

Note: There might be exception cases, where attributes that is not shared in an API or by the development team may not necessarily need to be modeled.


Component Data Model

See above the Mx descriptions for a more detailed discussion of the development and review of the component data model. For example, the data model could be expressed in Yang, Tosca, and Swagger. Usually, the data model would be expressed in the API. while they may, ONAP does not force that to happen. The component data model contains the following:

  • Contains objects

  • Attributes

  • Relationships (more detail than information model)

  • Mapping to Information Model 

Note: the mapping of the API/Data model to the information model may be Automatic or manual. It is expects that the development teams would provide translation/mapping to the modeling team. This would be used by the modeling sub-committee as a sanity check, but the information is "owned" by the development teams.






New Roles – Model Governance

...