mbse:sysml_v2_transition:frequently_asked_question_faq_s
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
mbse:sysml_v2_transition:frequently_asked_question_faq_s [2024/01/26 19:59] fsalvatore |
mbse:sysml_v2_transition:frequently_asked_question_faq_s [2024/05/07 12:42] (current) fsalvatore [Frequently Asked Question (FAQ's)] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | [[http://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition|[Click Here]]] to return to the SysML v1 to SysML v2 Transition Guidance Home Page | + | [[http://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition|[Click Here]]] to return to the INCOSE SysML v1 to SysML v2 Transition Guidance Activity Team Home Page |
| // | // | ||
| // | // | ||
| - | ===== Frequently Asked Question (FAQ's) ===== | + | ===== Frequently Asked Question (FAQ's) ===== |
| + | |||
| + | [[https://www.de-bok.org/asset/3b8de9f20f1b734efb4b958465259ccb39fa7c1a|Download]] | ||
| SysML v2 is the next generation systems modeling language that overcomes many limitations of its predecessor, SysML v1. It is a powerful tool for model-based systems engineering (MBSE) and allows for the representation of various system aspects such as structure, behavior, requirements, analysis cases, verification cases, and traceability. SysML v2 also introduces a new metamodel based on formal semantics, a complementary textual syntax, and a standardized API for model access. The transition from SysML v1 to SysML v2 offers significant potential improvements and potential risks to all organizations and careful planning must be executed for a successful transition. | SysML v2 is the next generation systems modeling language that overcomes many limitations of its predecessor, SysML v1. It is a powerful tool for model-based systems engineering (MBSE) and allows for the representation of various system aspects such as structure, behavior, requirements, analysis cases, verification cases, and traceability. SysML v2 also introduces a new metamodel based on formal semantics, a complementary textual syntax, and a standardized API for model access. The transition from SysML v1 to SysML v2 offers significant potential improvements and potential risks to all organizations and careful planning must be executed for a successful transition. | ||
| Line 14: | Line 16: | ||
| **Model Conversion:** The process for converting a baseline SysML v1 model to a baseline SysML v2 model that includes pre-processing the SysML v1 model, transforming the SysML v1 model to a SysML v2 model, post-processing the SysML v2 model, validating the SysML v2 model, and assessing the impact on other artifacts generated or derived from the model.\\ | **Model Conversion:** The process for converting a baseline SysML v1 model to a baseline SysML v2 model that includes pre-processing the SysML v1 model, transforming the SysML v1 model to a SysML v2 model, post-processing the SysML v2 model, validating the SysML v2 model, and assessing the impact on other artifacts generated or derived from the model.\\ | ||
| \\ | \\ | ||
| - | **Transform:** A step in the model conversion process which translates a conformant SysML v1 model to a conformant SysML v2 model. | + | **Transform:** A step in the model conversion process which translates a conformant SysML v1 model to a conformant SysML v2 model.// |
| - | //\\ \\ | + | ===== ---- ===== |
| ^ Section ^ Question ^ Response ^ | ^ Section ^ Question ^ Response ^ | ||
| Line 34: | Line 36: | ||
| | 3.4| When will open source vendors develop SysML v2 capabilities?| There is already an open-source reference implementation that was originally used to develop and validate the SysML v2 specification. It is anticipated that this implementation will be maintained in an open-source environment which may encourage other open-source tools to integrate with it.| | | 3.4| When will open source vendors develop SysML v2 capabilities?| There is already an open-source reference implementation that was originally used to develop and validate the SysML v2 specification. It is anticipated that this implementation will be maintained in an open-source environment which may encourage other open-source tools to integrate with it.| | ||
| |**4.0**| **Who is impacted by the transition from SysML v1 to SysML v2?**|| | |**4.0**| **Who is impacted by the transition from SysML v1 to SysML v2?**|| | ||
| - | | 4.1| Who are the primary and secondary stakeholders impacted by the transition from SysML v1 to SysML v2?| Current DoD programs that are using SysML v1 and the organizations supporting them are the primary stakeholders. The program stakeholders include the government and contractor systems modeling teams and other members of the program that use these models directly. The organizational stakeholders include the improvement teams responsible for defining and implementing digital engineering and MBSE across the organization.\\ \\Secondary stakeholders include other disciplines who may be impacted by SysML v2, such as other discipline engineers who may interact with the SysML v2 model and contribute to or use the information from the model.| | + | | 4.1| Who are the primary and secondary stakeholders impacted by the transition from SysML v1 to SysML v2?| Current DoD programs that are using SysML v1 and the organizations supporting them are the primary stakeholders. The program stakeholders include the government and contractor systems modeling teams and other members of the program that use these models directly. The organizational stakeholders include the improvement teams responsible for defining and implementing digital engineering and MBSE across the organization.\\ \\ Secondary stakeholders include other disciplines who may be impacted by SysML v2, such as other discipline engineers who may interact with the SysML v2 model and contribute to or use the information from the model.| |
| | 4.2| How is each stakeholder impacted by the transition?| Some of the primary stakeholders include the leadership responsible for planning and executing the SysML v1 to SysML v2 transition at the organizational level, the leadership responsible for planning and executing the SysML v1 to SysML v2 transition on a particular project, and the modeling practitioner who contributes to the systems modeling effort. The organization will update the organizational infrastructure that include the MBSE methods, tools and environment, reference models, and training that is used by the projects. The project will then adapt the organizational infrastructure including the methods and tools, and ensure the proper training is provided to the practitioners. The modeling practitioner will require training in the use of the language, methods, processes, and tools and apply their MBSE skills on the project to develop the system model. Other consumers of the model such as other engineering disciplines will require training to interpret and interact with the models.| | | 4.2| How is each stakeholder impacted by the transition?| Some of the primary stakeholders include the leadership responsible for planning and executing the SysML v1 to SysML v2 transition at the organizational level, the leadership responsible for planning and executing the SysML v1 to SysML v2 transition on a particular project, and the modeling practitioner who contributes to the systems modeling effort. The organization will update the organizational infrastructure that include the MBSE methods, tools and environment, reference models, and training that is used by the projects. The project will then adapt the organizational infrastructure including the methods and tools, and ensure the proper training is provided to the practitioners. The modeling practitioner will require training in the use of the language, methods, processes, and tools and apply their MBSE skills on the project to develop the system model. Other consumers of the model such as other engineering disciplines will require training to interpret and interact with the models.| | ||
| | 4.3| What vendors are implementing SysML v2 and when are they expected to have their initial tools available?| Several vendors have made public announcements regarding their intentions to support SysML v2. The OMG announcement regarding the approval of the SysML v2 beta specifications includes public statements from some of the large and small vendors that intend to support SysML v2 in various ways. The announcement can be found at https://www.omg.org/news/releases/pr2023/07-10-23.htm . It is recommended that you follow-up with the vendors to understand the specific capabilities they intend to provide and their roadmaps for providing these capabilities.| | | 4.3| What vendors are implementing SysML v2 and when are they expected to have their initial tools available?| Several vendors have made public announcements regarding their intentions to support SysML v2. The OMG announcement regarding the approval of the SysML v2 beta specifications includes public statements from some of the large and small vendors that intend to support SysML v2 in various ways. The announcement can be found at https://www.omg.org/news/releases/pr2023/07-10-23.htm . It is recommended that you follow-up with the vendors to understand the specific capabilities they intend to provide and their roadmaps for providing these capabilities.| | ||
| Line 41: | Line 43: | ||
| |** 5.0**| **How does a program and/or organization or other stakeholder transition from SysML v1 to SysML v2?**|| | |** 5.0**| **How does a program and/or organization or other stakeholder transition from SysML v1 to SysML v2?**|| | ||
| | 5.1| What is the proposed process for transitioning from SysML v1 to SysML v2?| The SysML v1 to SysML v2 transition process should begin with establishing a Transition Team that is responsible for the transition strategy and plans and for executing the plans. This team should be integrated with other teams that are working related digital engineering initiatives. The plan should include pilot projects to both assess the impact of SysML v2 on the modeling practices and validate the new or modified modeling practices. The plan should also include updates to the modeling infrastructure including the modeling guidelines, patterns, methodologies, tools and environments, training, and reference models. In addition, the plan should include activities to deploy this modeling capability to projects. | | | 5.1| What is the proposed process for transitioning from SysML v1 to SysML v2?| The SysML v1 to SysML v2 transition process should begin with establishing a Transition Team that is responsible for the transition strategy and plans and for executing the plans. This team should be integrated with other teams that are working related digital engineering initiatives. The plan should include pilot projects to both assess the impact of SysML v2 on the modeling practices and validate the new or modified modeling practices. The plan should also include updates to the modeling infrastructure including the modeling guidelines, patterns, methodologies, tools and environments, training, and reference models. In addition, the plan should include activities to deploy this modeling capability to projects. | | ||
| - | | 5.2| What is the recommended process to convert a baseline SysML v1 model to a baseline SysML v2 model?| The SysML v1 to SysML v2 model conversion process can include preprocessing the SysML v1 model (refer to response in section 5.8), transforming the SysML v1 model to the SysML v2 model (refer to response in sections 5.3, 5.4, 5.5, and 5.6), post-processing the SysML v2 model (refer to response in section 5.9), and then validating that the SysML v2 model is consistent with the intent of the original SysML v1 baseline model (refer to response in section 5.10). It is also important to assess the impact of the changes to the baseline model on other artifacts that are dependent on the model such as documentation generated or derived from the model. This can include specifications, architecture description documentation, requirements traceability reports, test plans, etc.\\ \\Refer to the paper entitled ‘SysML v1 to SysML v2 Conversion Model Approach’ at https://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition:model_conversion_approach for detailed guidance on the conversion process and an example model that the conversion process was applied to.| | + | | 5.2| What is the recommended process to convert a baseline SysML v1 model to a baseline SysML v2 model?| The SysML v1 to SysML v2 model conversion process can include preprocessing the SysML v1 model (refer to response in section 5.8), transforming the SysML v1 model to the SysML v2 model (refer to response in sections 5.3, 5.4, 5.5, and 5.6), post-processing the SysML v2 model (refer to response in section 5.9), and then validating that the SysML v2 model is consistent with the intent of the original SysML v1 baseline model (refer to response in section 5.10). It is also important to assess the impact of the changes to the baseline model on other artifacts that are dependent on the model such as documentation generated or derived from the model. This can include specifications, architecture description documentation, requirements traceability reports, test plans, etc. \\ \\ Refer to the paper entitled ‘SysML v1 to SysML v2 Conversion Model Approach’ at https://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition:model_conversion_approach for detailed guidance on the conversion process and an example model that the conversion process was applied to.| |
| | 5.3| How do you transform a SysML v1 model to a SysML v2 model?| A SysML v1 model can be transformed to a SysML v2 model using a tool that can perform the SysML v1 to SysML v2 transformation specification. The transformation requires that the SysML v1 model be conformant to the SysML v1 specification to be transformed to a conformant SysML v2 model. The transformation may be done incrementally.| | | 5.3| How do you transform a SysML v1 model to a SysML v2 model?| A SysML v1 model can be transformed to a SysML v2 model using a tool that can perform the SysML v1 to SysML v2 transformation specification. The transformation requires that the SysML v1 model be conformant to the SysML v1 specification to be transformed to a conformant SysML v2 model. The transformation may be done incrementally.| | ||
| | 5.4| What are common defects when transforming a SysML v1 model to a SysML v2 model?| A common defect that is anticipated to occur when transforming a SysML v1 model to a SysML v2 model will result from non-standard extensions and customizations in the SysML v1 model. Other issues may result from circular dependencies in the SysML v1 model that may limit the ability to transform the model. In addition, ambiguities, and redundancies in the SysML v1 model will continue to persist in the transformed model until explicitly addressed as part of the pre-processing or post-processing. Other common issues will be identified as the community gains experience with the transformation.| | | 5.4| What are common defects when transforming a SysML v1 model to a SysML v2 model?| A common defect that is anticipated to occur when transforming a SysML v1 model to a SysML v2 model will result from non-standard extensions and customizations in the SysML v1 model. Other issues may result from circular dependencies in the SysML v1 model that may limit the ability to transform the model. In addition, ambiguities, and redundancies in the SysML v1 model will continue to persist in the transformed model until explicitly addressed as part of the pre-processing or post-processing. Other common issues will be identified as the community gains experience with the transformation.| | ||
| Line 47: | Line 49: | ||
| | 5.6| What steps should be taken to validate that the transformation was successful?| The tool should generate validation errors and warnings to indicate what aspects of the transformation were not successful. In addition a manual inspection should be performed to compare the SysML v2 model with the SysML v1 model. | | | 5.6| What steps should be taken to validate that the transformation was successful?| The tool should generate validation errors and warnings to indicate what aspects of the transformation were not successful. In addition a manual inspection should be performed to compare the SysML v2 model with the SysML v1 model. | | ||
| | 5.7| Can you transform part of a SysML v2 model?| It is anticipated that the SysML v1 model can be partitioned to minimize coupling between different parts of the model and enable incremental transformation. For example, the model can be partitioned into packages that contain the structure, behavior, and requirements. This partitioning can apply at the mission, system, and subsystem level. The transformation can then be applied to each package individually to support incremental transformation and validation.| | | 5.7| Can you transform part of a SysML v2 model?| It is anticipated that the SysML v1 model can be partitioned to minimize coupling between different parts of the model and enable incremental transformation. For example, the model can be partitioned into packages that contain the structure, behavior, and requirements. This partitioning can apply at the mission, system, and subsystem level. The transformation can then be applied to each package individually to support incremental transformation and validation.| | ||
| - | | 5.8| How can existing SysML v1 models be pre-processed so that they will more readily transform to SysML v2?| The pre-processing of the model should ensure that SysML v1 model conforms to the SysML v1 specification as a precondition for the transformation. Any tool specific extensions and other tool customizations may need to be removed. Model validation errors should be addressed to ensure the model is well-formed. In addition, standard modeling conventions such as naming conventions should be applied, and ambiguities and redundancies should be minimized.\\ \\There are certain features of SysML v1 such as adjunct properties and deep history states that have no explicit mapping to SysML v2. Part of the pre-processing could be to remove or assess the impact of the transformation on these features and note that they may need to be addressed in the post-processing. Any circular dependencies should be identified to determine if and how they may impact the transformation and addressed accordingly. Finally, it may make sense to repartition the model if it is desired transform the model incrementally.\\ \\Refer to the example in the response to section 5.2 for additional guidance.| | + | | 5.8| How can existing SysML v1 models be pre-processed so that they will more readily transform to SysML v2?| The pre-processing of the model should ensure that SysML v1 model conforms to the SysML v1 specification as a precondition for the transformation. Any tool specific extensions and other tool customizations may need to be removed. Model validation errors should be addressed to ensure the model is well-formed. In addition, standard modeling conventions such as naming conventions should be applied, and ambiguities and redundancies should be minimized.\\ \\ There are certain features of SysML v1 such as adjunct properties and deep history states that have no explicit mapping to SysML v2. Part of the pre-processing could be to remove or assess the impact of the transformation on these features and note that they may need to be addressed in the post-processing. Any circular dependencies should be identified to determine if and how they may impact the transformation and addressed accordingly. Finally, it may make sense to repartition the model if it is desired transform the model incrementally.\\ \\ Refer to the example in the response to section 5.2 for additional guidance.| |
| | 5.9| What steps should be taken to post-process the transformed SysML v2 model?| The transformed SysML v2 model may need to be refactored to fully leverage the SysML v2 capabilities. As an example, it may be worthwhile to reorganize and refactor the SysML v2 model to leverage the ability to decompose parts directly in a parts tree. This is more straightforward than SysML v1 which requires decomposing a block into part properties, then typing the part property by a block, and then further decomposing the block into its part properties. This decomposition applies to all other aspects of the language including actions and requirements. \\ \\ Refer to the example in the response to section 5.2 for additional guidance.| | | 5.9| What steps should be taken to post-process the transformed SysML v2 model?| The transformed SysML v2 model may need to be refactored to fully leverage the SysML v2 capabilities. As an example, it may be worthwhile to reorganize and refactor the SysML v2 model to leverage the ability to decompose parts directly in a parts tree. This is more straightforward than SysML v1 which requires decomposing a block into part properties, then typing the part property by a block, and then further decomposing the block into its part properties. This decomposition applies to all other aspects of the language including actions and requirements. \\ \\ Refer to the example in the response to section 5.2 for additional guidance.| | ||
| | 5.10| How does one validate that a SysML v2 model accurately reflects the original SysML v1 model?| A way to validate that a SysML v2 model accurately reflects the original SysML v1 model is to compare the two models. This may include reproducing selected views of the SysML v2 model such as a system hierarchy and carefully comparing it with the system hierarchy in a SysML v1 model. It is anticipated that tool vendors may be able to generate automated comparison reports to assist in the inspection. Comparing execution and analysis results from the SysML v2 model with the corresponding execution and analysis results of the SysML v1 model may also assist in the validation.| | | 5.10| How does one validate that a SysML v2 model accurately reflects the original SysML v1 model?| A way to validate that a SysML v2 model accurately reflects the original SysML v1 model is to compare the two models. This may include reproducing selected views of the SysML v2 model such as a system hierarchy and carefully comparing it with the system hierarchy in a SysML v1 model. It is anticipated that tool vendors may be able to generate automated comparison reports to assist in the inspection. Comparing execution and analysis results from the SysML v2 model with the corresponding execution and analysis results of the SysML v1 model may also assist in the validation.| | ||
| Line 69: | Line 71: | ||
| | 6.6| What storage considerations should be made when transforming a model from SysML v1 to SysML v2?| The model will often be stored on a server versus a client. The server should be properly sized to accommodate the modeling storage and performance needs. Cloud services facilitate flexible access to the needed resources.| | | 6.6| What storage considerations should be made when transforming a model from SysML v1 to SysML v2?| The model will often be stored on a server versus a client. The server should be properly sized to accommodate the modeling storage and performance needs. Cloud services facilitate flexible access to the needed resources.| | ||
| | 6.7| What training is available for SysML v2?| There is open-source training that was developed as part of the SysML v2 Submission Team (SST). Request access to this group at https://groups.google.com/g/sysml-v2-release. More training resources should become available over time that will be provided by consultants, tool vendors, and academia.| | | 6.7| What training is available for SysML v2?| There is open-source training that was developed as part of the SysML v2 Submission Team (SST). Request access to this group at https://groups.google.com/g/sysml-v2-release. More training resources should become available over time that will be provided by consultants, tool vendors, and academia.| | ||
| - | | 6.8| How does a SysML v2 model interact with a UML-based model including a SysML v1 model, a UML model, and a UAF v1 model?| There are different strategies to enable the interaction between a SysML v2 model and any other UML-based model including SysML v1 models, UML models, and UAF v1 models. The general tool integration strategy that was referred to in response to section 5.15is applicable. The strategy should consider the level of coupling between the SysML v2 model and the other model and whether the SysML v2 model and/or the other model are anticipated to undergo significant and frequent change or be relatively static.\\ \\A typical use case for interacting with a UAF v1 model is that the UAF model describes a system of systems model that is elaborated by a SysML v2 model. In this case, the SysML v2 model is dependent on the UAF model. A way for these two models to interact is to use the SysML v2 API and its external relationship service to establish and maintain dependency relationships between selected elements in the SysML v2 model and selected elements in the UAF model. When UAF v2 becomes available, the UAF v1 model can be converted to a UAF v2 model. The SysML v2 model and the UAF model should be able to interact through the SysML v2 API, or the SysML v2 model can treat the UAF v2 model as a project usage.\\ \\A typical use case for interacting with a UML model is that the SysML model is the source of the software requirements and UML is used to model the software design. In this case, the UML model is dependent on the SysML v2 model. A similar approach can be used as described above for interacting with a UAF model. The SysML v2 API and its external relationship service can be used to establish and maintain dependency relationships between elements in the UML and elements in the SysML v2 model.\\ \\There are additional approaches to enable the interaction between a SysML v1 model and a SysML v2 model beyond the use of the API and its external relationship service as described above. If the SysML v1 model is not anticipated to change, then the SysML v1 model can be converted to a SysML v2 model where it can be further elaborated. If the SysML v1 model is subject to further change, the converted SysML v2 model can be treated as a project usage for the SysML v2 model under development. The SysML v1 model can be updated and periodically converted to SysML v2. Branch and merge techniques would be used to manage updates to the project usage, and the impact on the SysML v2 model under development. | | + | | 6.8| How does a SysML v2 model interact with a UML-based model including a SysML v1 model, a UML model, and a UAF v1 model?| There are different strategies to enable the interaction between a SysML v2 model and any other UML-based model including SysML v1 models, UML models, and UAF v1 models. The general tool integration strategy that was referred to in response to section 5.15is applicable. The strategy should consider the level of coupling between the SysML v2 model and the other model and whether the SysML v2 model and/or the other model are anticipated to undergo significant and frequent change or be relatively static.\\ \\ A typical use case for interacting with a UAF v1 model is that the UAF model describes a system of systems model that is elaborated by a SysML v2 model. In this case, the SysML v2 model is dependent on the UAF model. A way for these two models to interact is to use the SysML v2 API and its external relationship service to establish and maintain dependency relationships between selected elements in the SysML v2 model and selected elements in the UAF model. When UAF v2 becomes available, the UAF v1 model can be converted to a UAF v2 model. The SysML v2 model and the UAF model should be able to interact through the SysML v2 API, or the SysML v2 model can treat the UAF v2 model as a project usage.\\ \\ A typical use case for interacting with a UML model is that the SysML model is the source of the software requirements and UML is used to model the software design. In this case, the UML model is dependent on the SysML v2 model. A similar approach can be used as described above for interacting with a UAF model. The SysML v2 API and its external relationship service can be used to establish and maintain dependency relationships between elements in the UML and elements in the SysML v2 model.\\ \\ There are additional approaches to enable the interaction between a SysML v1 model and a SysML v2 model beyond the use of the API and its external relationship service as described above. If the SysML v1 model is not anticipated to change, then the SysML v1 model can be converted to a SysML v2 model where it can be further elaborated. If the SysML v1 model is subject to further change, the converted SysML v2 model can be treated as a project usage for the SysML v2 model under development. The SysML v1 model can be updated and periodically converted to SysML v2. Branch and merge techniques would be used to manage updates to the project usage, and the impact on the SysML v2 model under development. | |
| | 6.9| How do you integrate a SysML v2-based UAFML with SysML v2 models? | Refer to the response in Section 6.8.| | | 6.9| How do you integrate a SysML v2-based UAFML with SysML v2 models? | Refer to the response in Section 6.8.| | ||
| - | | 6.10| What is the impact of SysML v2 transition on integrating MBSE with model-based software engineering (UML)?| This is partially dependent on the methodology. One methodological approach is to treat the SysML v2 model as a source of the software requirements where the software modeling tool would access the SysML v2 model through the SysML v2 API. There may be additional opportunities beginning with pilot projects to explore how to improve integration with model-based software development by using SysML v2 and leveraging the SysML v2 textual notation.\\ \\Refer to response in section 6.8.| | + | | 6.10| What is the impact of SysML v2 transition on integrating MBSE with model-based software engineering (UML)? |This is partially dependent on the methodology. One methodological approach is to treat the SysML v2 model as a source of the software requirements where the software modeling tool would access the SysML v2 model through the SysML v2 API. There may be additional opportunities beginning with pilot projects to explore how to improve integration with model-based software development by using SysML v2 and leveraging the SysML v2 textual notation.\\ \\ Refer to response in section 6.8.| |
| | 6.11| What is the impact of transitioning from a SysML v1-based UAFML to SysML-v2-based UAFML? | This will be dependent on the approach to how UAF v2 extends SysML v2. In particular, if UAF is specified as a SysML v2 model library, the UAF v1 to UAV v2 transformation could potentially directly leverage the SysML v1 to SysML v2 transformation. The transition from UAF v1 to UAF v2 would be similar to the transition from SysML v1 to SysML v2 enabling UAF to leverage much of what is developed and learned from the SysML v2 transition.| | | 6.11| What is the impact of transitioning from a SysML v1-based UAFML to SysML-v2-based UAFML? | This will be dependent on the approach to how UAF v2 extends SysML v2. In particular, if UAF is specified as a SysML v2 model library, the UAF v1 to UAV v2 transformation could potentially directly leverage the SysML v1 to SysML v2 transformation. The transition from UAF v1 to UAF v2 would be similar to the transition from SysML v1 to SysML v2 enabling UAF to leverage much of what is developed and learned from the SysML v2 transition.| | ||
| | 6.12| Can a view of the SysML v2 model be delivered versus delivering the entire model?| Yes. A view of the model is a specific model element that exposes a subset of the model. The API query capability can be used to generate the view and be specified as a deliverable.| | | 6.12| Can a view of the SysML v2 model be delivered versus delivering the entire model?| Yes. A view of the model is a specific model element that exposes a subset of the model. The API query capability can be used to generate the view and be specified as a deliverable.| | ||
| |** 7**| **What are the mechanisms to access and provide SysML v2 guidance information?**|| | |** 7**| **What are the mechanisms to access and provide SysML v2 guidance information?**|| | ||
| - | | 7.1| What is the forum for asking questions and providing feedback on the transition to SysML v2?| The SysML v1 to SysML v2 Transition Guide Project is providing guidance on the OMG Wiki at https://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition. In addition, the Digital Engineering Body of Knowledge (DEBoK) https://www.de-bok.org/ contains all downloadable SysML v1 to SysML v2 transition guidance products.| | + | | 7.1| What is the forum for asking questions and providing feedback on the transition to SysML v2?| The SysML v1 to SysML v2 Transition Guide Project is providing guidance on the OMG Wiki at https://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition.\\ \\ In addition, the Digital Engineering Body of Knowledge (DEBoK) https://www.de-bok.org/ contains all downloadable SysML v1 to SysML v2 transition guidance products.| |
| - | | 7.2| Where can I get examples of SysML v2 models?| There are example models developed by the SysML v2 Submission Team (SST) that are available in the open-source git repository. Also, other examples are being developed by the SysML v1 to SysML v2 Transition Guide Project some of which will be made publicly available. \\ \\Refer to the example in the response in section 7.1 for additional guidance.\\ \\Also refer to the response in section 5.2 for additional guidance. Also reference section 7.2 on how to contribute.| | + | | 7.2| Where can I get examples of SysML v2 models?| There are example models developed by the SysML v2 Submission Team (SST) that are available in the open-source git repository. Also, other examples are being developed by the SysML v1 to SysML v2 Transition Guide Project some of which will be made publicly available.\\ \\ Refer to the example in the response in section 7.1 for additional guidance.\\ \\ Also refer to the response in section 5.2 for additional guidance. Also reference section 7.2 on how to contribute.| |
| | 7.3| How can I access and contribute to reusable asset repositories for SysML v2 including example SysML v2 models?| Submit to the SysML v1 to SysML v2 Transition Guide Project.\\ \\ Refer to section 7.1.| | | 7.3| How can I access and contribute to reusable asset repositories for SysML v2 including example SysML v2 models?| Submit to the SysML v1 to SysML v2 Transition Guide Project.\\ \\ Refer to section 7.1.| | ||
mbse/sysml_v2_transition/frequently_asked_question_faq_s.1706317179.txt.gz · Last modified: 2024/01/26 19:59 by fsalvatore
Page Tools
