I’m changing the name of my pools.
I want the pools that I’m renaming to reference a pool that I have already defined.
However, when I rename the pools using the same name of the pool I have already defined, VP is not making the association.
I confirmed this because when I look at the Model Explorer I see multiple pools with the same name.
Any help would be most welcome!
Thank you, Filipe
This is intended behaviour. Now, to get a few things cleared up: when you mention that you want the renamed pool to reference another, you’re basically referring to the Master/auxiliary views, right?
Reason I’m asking is because just like other model elements pools can also have references which you’d normally set up by clicking on the reference icon (the arrow) or by opening their specification.
So: if you want to add a new auxiliary view of an existing element then your only options are to either drag in the original from the model explorer or by creating a new element (a pool in this case), and instead of entering a name press control-space and select the original from the list which will now be displayed.
But renaming a model element will never trigger an association. That’s because if it would then this could potentially destroy existing work. Lets say you have pool A which has several tasks on it and pool B which is empty. If I were to rename A to B and it would become an auxiliary view then this would also mean that it would remove all the currently set up tasks. After all: B was empty. Which would potentially destroy A. That’s why renaming a model element will always keep it as-is.
Hope this can help.
Yes, ShelLuser has got it right that why renaming a pool shape won’t cause the pool to remap its model element, as it has big impact because the two pools are distinct model elements before, if a remap occurs just by casual renaming, a merging of model element relationships/properties/children will occur which could be undesirable.
The name to existing pool remap does work, and only works, when you name the pool after you have just created it. It is designed to work only when create because there is no risk mentioned above.
To remap a pool’s model element, simply right-click on the pool shape and select “Remap Pool” from the popup menu, then you can select any existing pools to remap to this shape.
Note that the old pool model element won’t be deleted after remap, you have to locate it in the Model Explorer or Project Browser to delete it manually.
Hope this helps.
Thank you for the clarification. The menu option to remap an artifact is really cool.
For the record I do understand well the concept of metamodeling.
Hey ShelLuser. thank you for the clarification.
Would it then be a “best practice” to declare all the pools into one specific diagram and name it for instance “Model diagram”?
This way I would know for sure where all my pool definitions are.
It could be one possible way to avoid the duplicate pool definition. Or you may create a Model and then create Pools to it as children using Model Explorer. And when you need to visualize the Pools just drag and drop from the Model Explorer to the diagram.
Thank you for the clarification.
I’m starting to converge my existing artifacts to VP best practices.
I got this alert message. Would you be so kind to share w me what’s happening over here?
To under what this alert message means, let’s first define what a master view is.
A master view is basically the view of a model element that would cause the parent-child hierarchy to change when the view’s container has been changed. Say there are two class views of the same class model element that appear in two diagrams, if you move the class’ master view to a package, the class will become child of the package. If the moved class view is not master, no change happens to the class model element.
So far you may see a master view appears in diagram only. But VP also consider the model element tree node in a Model Explorer the candidate of a master view. If you try to move a model element in Model Explorer to a different parent, you have the intention to change the parent-child hierarchy of that model element, right? When this gesture is detected but the tree node is currently not a master view, you will be prompted to assign the master view there, otherwise the change of parent-child hierarchy will be canceled. So in other words, only either the Model Explorer tree node or one diagram element can be master view at any one time.
Here is a detailed explanation about master view that worth reading to better understand this concept: Working with Master View
Hope this helps,
I’m familiar w metamodeling. Thank you for the URL. It does help to be able to know how VP manages metamodels.
As you have probably figured out, I started creating diagrams in the Project Browser. It wasn’t up until I started working w choreographies that I started to run into issues. Now I’m converting everything into Model View.