...

• 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.
    • • INFORMATION ELEMENT TEMPLATE - This is a template that would be used by the Use Case project teams to capture information that would feed into the information model and in collaboration with the modeling sub-committee would help the project team think about their information modeling work. The Use Case team's vision of the information. The we this template to drive info model work representing the info exchanges in the use case which in turn would lead to potential schema updates or API updates (data model development). The template can be found here:  Generic Information Element Template
    • 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.
    • ONAP Platform Components & 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 Teams (Project Teams) - Use Case teams are cross-functional in nature: they are composed of a leader, developers and also (indirectly) the ONAP platform members from components that need to be involved. Working towards M1, the Use case teams are defining their requirements and starting to craft a 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. This should open a dialogue between the Use Case team and the modeling to identify model impacts and where there might conceptual overlaps to help streamline the design. The Use Case teams may also be agnostic to the broader information model and contact between the modeling sub-committee and the use case teams will also raise awareness of relevant information models that the Use Case teams will need.
      • #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. The Use case teams should be identifying three things which will help the Modeling subcommittee understand better the model impacts. This will help the modeling team identify areas where model impacts will be. The Use Case teams should define their use cases in more detail ideally using the kind of information shown in this template: Proposed Functional Template for Use Cases
        
        • PRECONDITIONS - Preconditions are the Information the use cases consume.
        • POST-CONDITIONS - The post-conditions can capture the kind of information that is output from the use cases.
        • INFORMATION EXCHANGES - information exchanges capture the type of information that passes from component to component, APIs, NBI and external interfaces. This helps to identify the relevant models that give that exchanged information structure
      Architecture - Every release, the architecture sub
      • INFORMATION MODEL TEMPLATE - The information model template can be refined or started (if it was not done at M0). The template can be found here: Generic Information Element Template
  • • Architecture - Every release, the architecture sub-committee 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. The idea is that the modeling S/C leads would queue some time in one of the architecture S/C calls (as a 1-off) to discuss the information model for that release and vice versa. Another possibility would be to reserve some time on the Architecture sub-committee call either on a regular basis or when the modeling S/C team is about to accomplish an objective, or about to make a vote on something (to call for consensus). It would also be good if the Architecture lead (PTL) could identify modeling impacts and flag them as they come across them.
    • Components (PTL)- 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. Having the modeling S/C engage PTLs (or vice versa).
      
      • #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. Ideally the PTLs and component leads should be engaged by the Use Case teams. SDC & A&AI often have more high-running modeling impacts than some of the other components. The modeling team members could attend some of the component calls to raise awareness. Identifying and tracking a modeling impacting item so they aren't lost. An issue impact matrix and tracking page could be developed to track issues (and maybe a Jira ticket).
        

  
  

  • M2

    • MODELING SUBCOMMITTEE -
    • For the RELEASE Information Model these are the activities that the Modeling sub-committee is engaged in leading up to M2.
      
      • RELEASE INFORMATION MODEL (Starting Point) - The release starts with a clean release information model from the PREVIOUS release (with all of its attendant contributions). Then new contributions of the current release are considered (see below the process for handling each specific contribution). Potentially a snapshot of the papyrus model and posted into the current release. The RST documentation that only contains things in the current release or everything that is approved.
      • TERMS & CONCEPTS -
        • IISOMI STATES - The concept of IISOMI states describes the state of individual classes, attributes, and associations/relationships. IISOMI states are noted within the elements of the contribution. For example, a particular parameter might be in the experimental state while another class might be tagged as in the preliminary state. These preliminary and experimental are states that are mutually exclusive so you can't have a class/attributes with two different IISOMI states simultaneously. During the discussion phase, the elements of the contribution should be out of experimental state. The exception is that there is a state of reference that can exist with other states. Some elements within the contribution could have different IISOMI states. The webpage for the IISOMI states can be found at: Informal Inter-SDO Open Model Initiative (IISOMI)
      • DELAYED ELEMENTS OF THE RELEASE INFO-MODEL - This may happen that are out of the control the modeling S/C. Use Cases get delayed, or a discussion can't wrap up. So, there could be a corner case where, for example, one or more things (parameters/classes) in a contribution can't make the current release (it stay experimental), what would happen to the overall contribution or release information model (is it allowed to go clean). This would not stop the other parts of the contribution or the release information model from going to a clean state.  #@# Example, Dynamic parameters in the common sub-model, generates the whole model then manually edited down to the DP. if things are marked experimental it will show experimental. Keep of Track (experimental?) communicate? reviews?
      • INFORMATION MODEL FREEZE - The aggregate / release information model for the release is approved by association with the fragment/ component reviews.  Each of the fragment (contributions) are individually approved, thus there is not a "re-approval" or approval of the entire aggregate (release) information model. Editorial clean-up such as misalignments, typos, or sections that were not put in proposal, fixing the template for GenDoc.
      • RELEASE INFO MODEL DECLARED CLEAN - After component reviews have concluded and release info model freeze by the modeling S/C the info model is called the "clean model" in this phase. At this point, the Use Case teams that are developing the Data Model can be pretty certain that the information model will be usable as shown. The diagrams and model wiki pages will indicate that this is a clean model. Put into the information model for that release. Unfinished contributions are postponed or discussed further.
    • DISCUSSION OF CONTRIBUTIONS - Each contribution discussed according to following process. This is where refining of each of the contribution models occurs by the Modeling Sub-committee (S/C). The release information model is not separately tracked, composed, updated, or released in this period of time. But, rather, each individual contribution has its own Wiki. Thus, for each contribution:
      
      • CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
        • An individual model contribution is a model that will eventually be a part of the total release information model. It is generally a self-contained model which depicts a particular capability or function of the system. This contribution starts as a "input contribution" and undergoes consideration by the modeling sub-committee. Consideration means that the modeling S/C is entertains & assesses if the input contribution should be accepted into the current (or a future release) by weighing the contribution against its relevance and the available resources (modelers) in the release. If the team thinks that the contribution is not ready for the current release that contribution will be put into a lower-priority and worked if there are no other contributions to be considered as they would take higher priority. Thus, the contribution would not necessarily be rejected, but would get attention as time allows.
      • REVIEW & REFINE CONTRIBUTION - START: Contribution in Discussion State (verb Reviewing & Refine) END: Contribution in Discussion state
        • The contribution undergoes reviewing & refining during the discussion state. Reviewing & refining means that the modeling S/C is discussing the modeling, and updating the contribution based on feedback and comments from the modeling team. Each contribution can be reviewed and refined independently and concurrently with other contributions. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
      • FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Contribution in Discussion State (verb Approving/Poll) END: Contribution in Discussion state
        • (a) FINAL PRESENTATION - When the contribution has gotten to a point where the team feels that it can start to undergo the approval process, the contribution is brought one final time the modeling S/C for discussion and socialization.
        • (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a sub-team lead to the modeling team whereby final thoughts & input can be given. This final call for comments signals that the discussion is wrapping up for this contribution and will soon go to a poll.
        • (c) INITIATING POLL - After final call and no further outstanding comments exist, the contribution is brought to a poll by a sub-committee chair. A poll is created whereby modeling S/C members can give the contribution a vote of "yes" or "no". 
      • APPROVING CONTRIBUTION - START: Contribution in Discussion State Post-Poll (verb Approving) Contribution in Clean State
        • After the poll has concluded, the contribution has finished the approval process. The contribution is now considered to be in the clean state. The items that are in the IISOMI experimental state get promoted to a preliminary state. A gendoc is generated and put on the wiki page. The gendoc would be translated and published on the readthedocs site.  
      • STEREOTYPE CHECK - The entities in the model has an experimental stereotype (down to the attribute level) when they are a proposal, when approved/clean, all of the entities in that proposal bear change from experimental to preliminary. Stereotypes can be on classes, attributes, data types and relationships. It is an ISOMII add into the model, at a high-level in the model things get stereotypes. E.g. when we approved the first VES model, which has many entities and many attributes; to update all of those from experimental to preliminary was tough. A stereotype is a status marker. Preliminary is approved for development.

  ...

  • M4 (Code Freeze)

    • M4 MODELING SUBCOMMITTEE ACTIVITIES-
      • PLATFORM INFORMATION UPDATES FROM SWAGGER UPDATES - The modeling subcommittee would update the platform information model possibly due to updates in the ONAP platform swagger files. It is anticipated that no new API changes would occur at M4, but rather description updates which would then subsequently affect the corresponding platform information model.
      • DOCUMENT GENERATION-  The model editor provides a final gendoc word document which serves as the basis for what will be incorporated into the Readthedocs.  The word document is fed into tools which generate the readthedocs output (RST file). The tool to generate the Readthedocs is pandoc. This is done by the model area lead. The gerrit master model is periodically updated, and a snapshot of the eclipse/Papryus model is taken and that is called the release model. A link to the read the docs can be found here: x. A tutorial for the process can be found here: RST Document Generation Tutorial After each approval, the model editor will update the latest gendoc. The Papyrus snapshot is generated. Note: that the papyrus model includes what was/had accepted into the previous release and also anything that is still a work in progress.. Note: that the papyrus model includes what was/had accepted into the previous release and also anything that is still a work in progress.
      • NEXT RELEASE - The M0 for the next release is generally synchronized with the sign-off of the previous release. So, the modeling sub-committee is  assessing new model requirements for new requirements or use cases in the next release during this time. See above for the M0 process related to model proposals process.
    • Architecture Engagement -
      • Next Release Architecture Reviews - M0 activities; go through the modeling check points in the Architecture review of the Requirements & Use Case proposals to the Architecture Sub-committee. Identifying and looking and their M0 model and their high-level information flows that the API might be consuming or producing; and then mapping those to existing information models. If there is a gap new modeling requirements would need to be identified and also planned into the model release planning page.
    • Requirements & Use Case Engagement -
      • Next Release Requirements & Architecture Reviews - The teams working on requirements & Use Cases should include modeling check points in their presentations & proposals to the requirements sub-committee and architecture sub-committee.  Identifying and looking and their M0 model and their high-level information flows that the API might be consuming or producing; and then mapping those to existing information models. If there is a gap new modeling requirements would need to be identified and also planned into the model release planning page.
    • Platform Components (PTL) Engagement -
      • Component API changes - If there are API changes originating from the platform development that would impact the release information model, the modeling sub-committee should sync with the PTLs. 

  
  

  • RC0/RC1/RC2 (Run Time Compliance)

    • RC0/1/2 MODELING SUBCOMMITTEE ACTIVITIES-

      • NEXT RELEASE - During RC0/RC1/RC2 NEXT RELEASE - The M0 for the next release is generally synchronized with the sign-off of the previous release. So, the modeling sub-committee is  assessing new model requirements for new requirements or use cases in the next release during this time. See above for the M0 process related to model proposals process.proposals process.
    • Architecture Engagement -
      • Next Release Architecture Reviews - see above the M0 step for details on syncing.
    • Requirements & Use Case Architecture Engagement -
      • Next Release Requirements & Architecture Reviews - M0 activities; go through the modeling check points in the Architecture review of the Requirements & Use Case proposals to the Architecture Sub-committee. Identifying and looking and their M0 model and their high-level information flows that the API might be consuming or producing; and then mapping those to existing information models. If there is a gap new modeling requirements would need to be identified and also planned into the model release planning page.see above the M0 step for details on syncing.
    • Platform Components (PTL) Requirements & Use Case Engagement -
      • Next Release Requirements & Architecture Reviews - The teams working on requirements & Use Cases should include modeling check points in their presentations & proposals to the requirements sub-committee and architecture sub-committee.  Identifying and looking and their M0 model and their high-level information flows that the API might be consuming or producing; and then mapping those to existing information models. If there is a gap new modeling requirements would need to be identified and also planned into the model release planning page.
    • Platform Components (PTL) Engagement -
      • Component API changes - If there are API changes originating from the platform development that would impact the release information model, the modeling sub-committee should sync with the PTLs. 

    RC0/RC1/RC2 (Run Time Compliance)

    RC0/1/2 MODELING SUBCOMMITTEE ACTIVITIES-
    • NEXT RELEASE - During RC0/RC1/RC2 for the next release is generally synchronized with the sign-off of the previous release. So, the modeling sub-committee is  assessing new model requirements for new requirements or use cases in the next release during this time. See above for the M0 process related to model proposals process.
  • Architecture Engagement -
    • Next Release Architecture Reviews - see above the M0 step for details on syncing.
  • Requirements & Use Case Engagement -
    • Next Release Requirements & Architecture Reviews - see above the M0 step for details on syncing.
  • Platform Components (PTL) Engagement -
    • Next Release PTL engagement - see above the M0 step for details on syncing.

  ARTIFACTS

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

  ...

  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.

  • • • PTL engagement - see above the M0 step for details on syncing.

  
  

  
  

  ARTIFACTS

  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: 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

  • Information Model Roles
    

    • Internal Committers - 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. 

  ...

  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

  • 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

    toward a Model Driven Design

  • Improve Data Quality

  • Provide a basis for data model development
  • Drive integration across the platform, integration of concepts resulting in integration of APIs and data structures.
  • Provides consistency and "standardization" through the use of a common data model.

  
  

  Modeling S/C, Use Case Team and Architecture team touch points, interactions and cooperation:

  Image RemovedImage Added

  
  

  SUPPORTING DOCUMENTS

  ...