Please provide comments on this wiki page by 7 DEC 2018

Draft of the recommended new "Practice Area" for Information and Data Modeling for the M3 Deliverables for API Freeze Milestone Checklist Template.


Practice AreaCheckpointYes/NoEvidencesHow to?

Information and Data Modeling

Has the Project team completed Use Cases and Feature Requirements demonstrating an existing Use Case that describe the information exchanges among ONAP Components?

YES/NO

If Yes, please provide link to the specific Use Cases / Feature Requirements and associated Sequence Diagrams.

Describe the interactions and behavior of each Information Exchange with Use Case / Feature Requirements and Sequence Diagrams.

Has the Project team completed a Data Model for all Shared Information (e.g., APIs, API Payload, Shared Design Model)?

YES/NO

If Yes, please provide link to the Data Model.

Data Models (e.g., JSON, YANG, etc.) that define the data exchanged or shared.

Has the Project team mapped the data elements in the Data Models into the ONAP Common Information Model?

YES/NO

If Yes, please provide link to the Data Element Mapping.

Mapping to understand how the data elements relate to the ONAP Common Information Model. (see: Modeling sub-committee)

Has the Project team reviewed the Data Models and Use Case artifacts with the Modeling Sub-Committee?


YES/NO

If Yes, please provide link to the review findings.

Modeling walkthrough to understand how each project contributes to the ONAP Common Information Model. Modeling Sub-Committee to organize the walkthrough

Is there a plan to address the findings of the Information / Data Modeling review?

YES/NO

If Yes, please provide link to the plan.

The plan could be as simple as a Jira issue to track the resolution of findings or a documented plan within the wiki.



  • No labels

4 Comments

  1. John Strassner

    This is a good start. I have the following comments:

    1. We should strive for model-driven APIs. This means that the Common Information Model should be used to generate a data model that is associated with applicable APIs (i.e., one Info Model generates one Data Model for a particular technology (e.g., RDBMS vs. YANG vs. NoSQL), and that Data Model is then used to generate APIs). The existing wording ("Has the Project team completed a Data Model for each API?) gives the impression that the APIs (and associated data models) are siloed.
    2. "Has the Project team mapped the API data elements into the ONAP Common Information Model?" is backwards! There is only one information model; there MAY be multiple data models.
    3. "Modeling walkthrough to understand how each project contributes to the ONAP Common Information Model. Modeling Sub-Committee to organize the walkthrough" sounds like we are building data models specific to projects, and then trying to integrate into a common info model. This won't work.

  2. Michela Bevilacqua

    Good step ahead!  I agree about striving for a model driven approach and I suggest to define multiple checkpoints with different level of ambitions.

    In the specific the following checkpoints "Has the Project team completed a Data Model for each API? Has the Project team mapped the API data elements into the ONAP Common Information Model? " can be extended with additional checkpoints as:

    Has the project team automatically generate API from a Data model by a tool ? YES/NO provide reference (we should also consider the case to provide recommended tools)

    Is the data model generated by the Common Information Model ? A tool has been used ?

    and (where applicable) Has the project team used the common TOSCA constructs ? (according to ONAP modeling design guidelines, TOSCA constructs will be defined starting from Service and Resource)

    I see the need to provide a versioned common information model in Papyrus, available in github for Beijing release.

     

  3. Weitao Gao

    I think this checklist is very useful for API freeze.
    here i have some question/suggestion.

    1. I would suggest merge "Has the Project team completed API specific Use Cases that describe the information exchanges supported by each API?" and "Has the Project team completed a Data Model for each API?" to "Has the project team provide the detail of each API?". Such as each project should provider the swagger file for each api before API freeze for other project.
    2. I'm confusing about the "ONAP common information Model", Does Modeling subcommittee will deliver this in R2+ release?

  4. Xu Yang

    Suggested checkpoints for design-time model:

    Practice AreaCheckpointYes/NoEvidencesHow to?
    design-time modelHas the Project team mapped the data model into the ONAP Common Information Model?YES/NOIf yes, please provide link to the information model mapping.Mapping to understand how the design-time data model is related to the information model, and check whether they are aligned.
    Has the Project team completed a Data Model for design time?YES/NOIf yes, please provide link to the data model.
    Has the Project team reviewed the Data Models with the Modeling Sub-Committee?YES/NOIf yes, please provide link to the review findings.Check whether the data model is aligned with the data model specs as defined by the modeling subcommittee, and whether the findings identified before have been addressed.