Add Papyrus functionality to migrate all model entries when using a dynamically path-mapped model

[J17359]

Issue and tracking information

Developer's time Estimated effort to fix (hours):

Developer's Actual time spent on fix (hours)

Issue reporter to provide a detailed description of the issue in the space below

Using dynamic path-mapping requires

1. manually setting the dynamic path-mapping string for the model dependency
2. importing the model dependency within the target model
3. changing the affected legacy target model entry types to point to the appropriate href location in the model dependency

It would be useful if there was an option to repair the type href locations for all legacy model entry types that would now rely on an imported dynamically path-mapped model. Such a functionality would accelerate the progress of the SNA 2.X porting initiative and would make it easier for developers to introduce new dynamically path-mapped models in the future.

[ysroh]

@J17359 Here is the use case I am thinking of. Please let me know if you want me to support other use cases.

1. A user will bring all models into the workspace including one that will be pathmapped and all dependent models. This will ensure all references are intact so refactoring can be done without confusion.
2. A user will open the model that will be pathmapped and set the string for the Pathmap field.
3. A dialog will be prompted to ask the user to proceed with the refactoring of all references in the dependent models.
4. If yes, all references of the dependent models will be refactored to use the pathmap instead of the workspace references.

Optionally, I can also add a context menu to the reference list in the References property section of the model to allow users to refactor a reference URI to another URI(pathmap). This option can be useful if the dependent models are brought into the workspace after the pathmapping is already done. However, I am not really sure if you need this option or not.

Let me know if you have any comments on this. Otherwise, I will go ahead and implement this.

[emammoser]

@ysroh I like this approach, however, the way that we use ICMs doesn't necessarily line up with this use-case, although I definitely see some benefit to this. Let me try to lay out a 3 project example where every Model (ModelA, ModelB, ModelC) all depend on a single model (ModelDependOnMe). The way we use ICMs now, each project would have their own copy of ModelDependOnMe (that should be the exact same file when compared). So, Lets imagine we have a workspace where 2 of the 3 projects are currently in the workspace.

• ProjectA_and_DependOnMe
  • ModelA
  • ModelDependOnMe
• ProjectB
  • ModelB
  • ModelDependOnMe

When we make the model in "ProjectA_and_DependOnMe/ModelDependOnMe" pathmapped, we would need to update ModelA (your use case covers this), but we also want to be able to update ModelB. ModelB currently points to "ProjectB/ModelDependOnMe". Additionally, if we have a ProjectC that isn't in the workspace but looks almost identical to ProjectB, except with a ModelC instead of a ModelB, we want the ability to bring that ProjectC in at some later point and update ModelC to point to the pathmapped model. Once all dependent models are set to look at the pathmapped version of ModelDependOnMe, the project local versions can be deleted. So what I propose would be the following steps.

1. A user will open the model that will be pathmapped and set the string for the pathmap field
2. A user will open a model that depends on an equivalent version of the model that has been pathmapped and select some new menu option/button for "Change Resource Reference to Pathmapped Reference", where they would then choose a reference in the model, say "platform:/resource/WeatherExample/ModelFiles/WeatherExample_ICM.uml" and then select a pathmapped model in the workspace, say "pathmap://WEATHEREXAMPLE_ICM/WeatherExample_ICM.uml"

[ysroh]

@j26151 I see. Since I am almost done with the automatic refactoring solution I will implement the hybrid mode where automatic refactoring is done for models already imported into the workspace and also add a menu to refactor references to Pathamp URI at a later time.

[emammoser]

@ysroh Great, the hybrid solution sounds like the best way to solve all of our use cases in the most efficient way.

[ysroh]

Fix committed.

You can change the Pathmap value by clicking on the new edit button.

You can set the Pathamap value in the dialog. Automatic refactoring will be done on all models in the workspace.

For manual refactoring, a context menu is added to the referenced model section.

Let me know if there is any issue with this feature.

[emammoser]

One question before I test this out. The automatic refactoring, is this prompted? In other words, after making a model pathmapped, does it automatically refactor all depending models or does the user get a prompt saying "Would you like to refactor models that depend on this model"? We would prefer if the user is prompted over it automatically happening. Otherwise, I can see situations in the future where users complain that it ruins something in there model because stuff is happening automatically behind the scenes.

[ysroh]

@j26151 Sure. I will add a confirmation dialog so users can skip the automatic refactoring. It will be ready tomorrow morning.

[ysroh]

@j26151 Fix merged. Let me know if there are any other comments.

[emammoser]

This looks good to me. We can close this issue now. Thank you.

[ysroh]

Thanks