User Tools

Site Tools


mbse:sysml_v2_transition:model_conversion_approach

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
mbse:sysml_v2_transition:model_conversion_approach [2024/03/14 21:27]
fsalvatore [2 Additional Steps Outside of the Model Conversion Process]
mbse:sysml_v2_transition:model_conversion_approach [2024/03/23 14:07] (current)
fsalvatore [SysML v1 to SysML v2 Model Conversion Process]
Line 4: Line 4:
 ===== SysML v1 to SysML v2 Model Conversion Process ===== ===== SysML v1 to SysML v2 Model Conversion Process =====
  
-[[https://​www.de-bok.org/​asset/​c4161c0fc1f559d18703c1e0b81052481b9a6775|Download]]+[[https://​www.de-bok.org/​asset/​5bd90f82fab101bdf093103f76ce74ec5411300e|Download]]
  
  
Line 40: Line 40:
  
  
-===== Other Considerations in the Model Conversion Process ===== +===== Other Considerations in the Model Conversion Process ===== 
-=== 2.1 Whether to Convert ​ ===+=== 1 Whether to Convert ​ ===
 Before making the conversion, a project may want to evaluate the cost of converting a SysML v1 model to a SysML v2 model versus the cost of developing a new SysML v2 model from scratch. It may be more cost-effective to start from scratch if the SysML v1 model was not maintained, or if its scope of the SysML v1 model is not consistent with the current effort. analysis, test plans, and others. Before making the conversion, a project may want to evaluate the cost of converting a SysML v1 model to a SysML v2 model versus the cost of developing a new SysML v2 model from scratch. It may be more cost-effective to start from scratch if the SysML v1 model was not maintained, or if its scope of the SysML v1 model is not consistent with the current effort. analysis, test plans, and others.
  
-=== 2.2 Incremental Model Conversion ===+=== 2 Incremental Model Conversion ===
 Projects should perform the conversion process incrementally rather than as a one-time process. As part of the pre-processing,​ the SysML v1 model can be partitioned to reduce the coupling between the parts of the model that will be incrementally transformed. For example, the model can be partitioned into packages that contain the structure, behavior, and requirements and further partitioned into mission, system, and subsystem levels. The incremental conversion process may first transform the structure, then transform the behavior, and then transform the requirements. Projects should perform the conversion process incrementally rather than as a one-time process. As part of the pre-processing,​ the SysML v1 model can be partitioned to reduce the coupling between the parts of the model that will be incrementally transformed. For example, the model can be partitioned into packages that contain the structure, behavior, and requirements and further partitioned into mission, system, and subsystem levels. The incremental conversion process may first transform the structure, then transform the behavior, and then transform the requirements.
  
-=== 2.3 One-Way Transformation ===+=== 3 One-Way Transformation ===
 The transformation occurs in a one-way direction from SysML v1 to SysML v2. There is no standard to transform a SysML v2 model to a SysML v1 model because many of the capabilities in SysML v2 are not supported in SysML v1. For example, SysML v1 supports a block decomposition but does not support a SysML v2 part decomposition. The transformation occurs in a one-way direction from SysML v1 to SysML v2. There is no standard to transform a SysML v2 model to a SysML v1 model because many of the capabilities in SysML v2 are not supported in SysML v1. For example, SysML v1 supports a block decomposition but does not support a SysML v2 part decomposition.
  
-=== 2.4 Classified Models ===+=== 4 Classified Models ===
 The transformation of a classified SysML v1 model should preserve all classification markings in the SysML v2 model. A standard security extension should be applied that leverages the metadata capability in SysML v2. A project should define a process to ensure all markings are properly applied and includes manual inspection of the model. The same classification procedures that apply to the SysML v1 model should apply to the SysML v2 model. ​ The transformation of a classified SysML v1 model should preserve all classification markings in the SysML v2 model. A standard security extension should be applied that leverages the metadata capability in SysML v2. A project should define a process to ensure all markings are properly applied and includes manual inspection of the model. The same classification procedures that apply to the SysML v1 model should apply to the SysML v2 model. ​
  
-=== 2.5 Configuration Management ===+=== 5 Configuration Management ===
 Projects can apply the SysML v2 API configuration management services to the SysML v2 models beginning with the initial transformation. Typical branch and merge concepts can be used to manage updates to the model. The configuration management of the SysML v2 model should be incorporated into the broader life cycle management environment using workflow or issue management applications such as Jira. Projects can apply the SysML v2 API configuration management services to the SysML v2 models beginning with the initial transformation. Typical branch and merge concepts can be used to manage updates to the model. The configuration management of the SysML v2 model should be incorporated into the broader life cycle management environment using workflow or issue management applications such as Jira.
- 
- 
- 
-===== 3 Other Considerations in the Model Conversion Process ==== 
-=== 3.1 Incremental model conversion ===  
-The conversion process should be performed incrementally rather than converting the entire model in a one-time batch process. As part of the pre-processing,​ the SysML v1 model can be partitioned to minimize coupling and enable incremental transformation. For example, the model can be partitioned into packages that contain the structure, behavior, and re-quirements and further partitioned into mission, system, and subsystem levels. The incremental conversion process can first transform the structure, then transform the behavior, and then transform the requirements. 
- 
-=== 3.2 One-way transformation === 
-It should be noted that the transformation is currently one-way from SysML v1 to SysML v2, and that there is no standard transformation specification to transform a SysML v2 model to a SysML v1 model. This is because many of the capabilities in SysML v2 are not supported in SysML v1. For example, SysML v1 supports a block decomposition but does not support a SysML v2 part decomposition. 
- 
-=== 3.3 Security classification considerations === 
-The transformation of a classified SysML v1 model should preserve all classification markings in the SysML v2 model. A standard security extension should be applied that leverages the metadata capability in SysML v2. A well-defined process should be es-tablished to ensure all markings are properly applied. This should include manual inspection of the model. The same classification procedures that apply to the SysML v1 model should apply to the SysML v2 model and must be adhered to.  
- 
-=== 3.4 Configuration management considerations === 
-The SysML v2 API configuration management services can be leveraged to manage the configuration of the SysML v2 models beginning with the initial transformation. Typical branch and merge concepts can be used to manage updates to the model. The configuration management of the SysML v2 model should be managed in the broader context of the overall engineering ecosystem that typically involves a product lifecycle management environment and workflow/​issue management applications such as Jira.  
  
mbse/sysml_v2_transition/model_conversion_approach.1710466044.txt.gz · Last modified: 2024/03/14 21:27 by fsalvatore