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
TOPIC | DESCRIPTION | EXAMPLE 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:
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:
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
...