...
| 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
Information Model Roles
Internal Committers
Internal Approvers
Impacted Project (Component) Approvers
Impacted API Approvers
Architecture Group Approvers
Component Data Models
Internal Committers
Modeling Team Approvers
Architecture Approvers
Impacted API Approvers
API Definitions
Modeling Team Approvers
Impacted Project (Component) Approvers
- Architecture Approvers
- Model sub-committee members with commit rights which will commit the papyrus model into Gerrit/Git. Typically the modeling area leads.
Information Sub-committee - The modeling sub-committee members which approve a model.
Project technical leads - PTLs with impacted components who should be involved, advise, and give feedback for information model changes
API developers - The developers who have Impacted API who should be involved, advise, and give feedback for information model changes
Architecture S/C - Members of the architecture sub-committee who should be involved, advise, and give feedback for the information model changes.
Component Data Model Role
Internal Committers - Project members with commit rights who will commit the use case/requirements work.
Modeling Team - Modeling sub-committee members
Architecture - Members of the architecture sub-committee who should be involved, advise, and give feedback for the data model changes.
Impacted API - Developers who have Impacted API who should be involved, advise, and give feedback for data model changes
API Definitions Role
Modeling Team - Modeling sub-committee members
Impacted Project (Component) - PTLs with impacted components who should be involved, advise, and give feedback for API changes
Architecture - Members of the architecture sub-committee who should be involved, advise, and give feedback for the API changes.
Benefits
Establishment and Evolution of a Common Model (Model Consistency)
Continue Move Toward a Model Driven Design
Improve Data Quality
Modeling S/C, Use Case Team and Architecture team touch points, interactions and cooperation:
...