The following diagram illustrates the overall Modeling process.

it shows the basic stages of a release, going from M0 (release kickoff) through M3 (API Freeze).

it illustrates 5 stages that the Modeling team is concerned with, the High Level model requirements, to the model plan work, to refining the information model, to model launch and then to model freeze.

The following diagram shows the Information and Data Model co-evolution and interaction flow:

There are three tracks one for the modeling S/C, the Use Case teams, and for API.

The modeling S/C before M0 kickoff, it working to define the high level information model requirements, then creating the input model before M1.

After M1, the modeling S/C works to refine the information model leading up to M2, and then the model is frozen going into M2.

After the model is launched, and frozen, the clean model can potentially be tweaks if necessary from refinements or updates from the use case teams.

Meanwhile, the Use Case teams are creating a Data Model which is based on the information model.

The data model also goes through four phases, from initial requirements assessment, to input data model, discussion data model, and finally the clean data model.

The clean data model serves as input to create the API.

The following diagram shows the modeling process in more detail:

Modeling Sub-Committee Process

• MO

  • Modeling team does MODEL PLANNING. The planning develops into “High Level Info-model Requirements”. These High level info-model requirements fall into 3 categories:
    
    • #1: NEW USE CASES - items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates).
    • #2: REFINING EXISTING MODEL - There are also Existing high level info-model requirements and the current release is focused on continuing or refining the model. Existing in a component that hasn't made it to the information model. Previously at design build-level that needs to be added into information model. For example, a need might have arisen in development but wasn't formalized. Long-lead, multi-release items might fall into this category. coded previously but no Use Case.
    • #3: FORWARD LOOKING WORK (FLW) - Forward thinking requirement. For example, suppose there were a very large use case/requirement or project that is expected to come down the pipe, but if no advanced modeling work were done on it, it wouldn't make the current release. Thus, a model might be proposed in advance of the actual use case/requirement.
  • Use Case Team (evaluating U/C proposals) presents their modeling needs. Each of the Use Case teams needs to come to the modeling S/C meetings to present their expected modeling needs and open a dialogue about potential model impacts so that they can be developed. Describing the the pre/post conditions, defining the overall definition.
  • Architecture understanding reference model. Modeling S/C members should be aware of any updates to the current release's reference model so that potential can be known.
  • PTL - High level release scope from PTLs (understand from ONAP components what updates)
  • PTL - Joint PTL sync meeting

• M1

  • Modeling team The info-model plan is established by the modeling team which summarizes the modeling requirements for a release. The model planning follows a template that is worked by the team. Info-model updates begin. An example template for R6 (Frankfurt) can be seen at this Wiki: ONAP R6 Modeling High Level Requirements.
    • #1: MODELING REQUIREMENTS - A description of each of the modeling requirements are described in more detail. This can be contributed from the modeling team, PTLs or the Use Case teams.
    • #2: USE CASE RELEVANCE - The relevance of use cases are identified and Use Case teams can give a more detailed explanation for use case requirements and how they tie to the high-level requirements. This allows for experts in the Info-model team to identify what fields of the existing info model could be enhanced and become aware of where the impacts are. 
    • #3: IMPACTED PROJECTS - The impacted projects from the info-model requirements (e.g. SO, VID, SDC etc) are identified. The tie-in from the ONAP platform components to the high level-modeling requirements are described.
    • #4: OVERLAPPING PROPOSALS - Overlapping info-model impacts from different use cases or forward looking work (FLW) are identified.
    • #5: MODEL REUSE - Finding Overlap from different use case and requirement proposals that are evaluated will lead to identifying where model reuse can occur. By the end of the Model overlap analysis overlapping areas will either cause overlaps to be merged or altered.
    • #6: OWNER - The owner(s) for the item are identified. The owners might be PTLs, Modeling subcommittee, or Use Case team.
    • #7: PRIORITY - A priority is identified for the info model requirements. these are general given by service providers or modeling subcommittee. A suggested High/Medium/Low is sufficient at this stage.
    • #8: LOWER PRIORITY - Lower priority requirements are generally considered as "nice to haves". Low priority requirements are captured in the info-model plan and are documented.
    • #9: DOCUMENTATION AFTER IMPLEMENTATION - Some modeling requirements are related to documenting implementation after the fact. When the model plan is established, this category of info-model requirements are identified and described in the info-model plan.
    • #10: FORWARD LOOKING WORK (FLW) - FLW is another class of requirements which are intended to recognize future needs.
      
  • Use Case - Working towards M1, the Use case teams are defining their requirements and starting to think about their Data Model.
    • #1: SOCIALIZATION - The model team should become aware of the use cases for the current release. Use Case teams are expected to make presentations to the modeling sub-committee for use cases that may impact the information model.
    • #2: DATA MODEL - Because the information model feeds the data models, the Use Case teams should take into account the new updates in the information model as a basis for their data model.
  • Architecture - Every release, the architecture team refines the functional architecture, creates new flow updates, and may update component architectures.
    
    • #1: SOCIALIZATION - Modeling team becomes aware of the new functional architecture and component architecture changes for the current release. Architecture should become aware of new modeling concepts. Cross-fertilization of new requirements, use cases and how they might impact model or how the model impact the upcoming proposed architecture changes.
  • Components - Each of the ONAP platform components (e.g. A&AI, SO, Controllers, SDC etc) may be impacted by new modeling changes and new use cases.
    
    • #1: COMMITMENT & TRACKING - The data model eventually serves as the basis for API changes and development. Platform components need to update APIs based on new requirements, use cases and features. Requests to components need to be tracked & commitment by the PTLs and components.
      

• M2

  • Functionality Freeze

  • Add “Infomodel Freeze” (Approval)

  • Add “Data Model Freeze” (Approval)

  • Note:  Feed to Data Dictionary??

• M3

  • API Freeze

  • Add “Infomodel Final”

  • Add “Component Data Model Final” (Approval – Design Level Compliance)

• M4

  • Code Freeze

  • Kickoff Information Model Requirements for Next Release

• RCx

  • Runtime Compliance

• Observations

  • Establishes and Evolves a Common Model

  • Project (Component) Team Involvement in Modeling Solution

  • Governance of Common Model and Corresponding Component Models

  • Update possible in M3 and M4 (bug fixes) per exception process

Artifacts

• Information Model Artifact Contains

  • Classes

  • Relationships with Multiplicity

  • Important Attributes with Multiplicity 

  • Definitions

  • Data Types 

  • Feed to Data Dictionary

  • Tooling - Papyrus with GitHub

• Component Data Model Artifacts (Implementation Specific)

  • Component Data Model

    • Contains objects, attributes, & relationships (more detail than information model)

  • Mapping to Information Model

  • Feed to Data Dictionary?

• API Artifacts

  • API Model

  • Mapping to Information Model

New Roles – Model Governance

• Information Model

  • 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

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:

SUPPORTING DOCUMENTS