Master views and modifying class associations and generalizations

[dennisk]

I have a model that includes a (relatively) large number of classes, divided into a number of packages. Each package generally has an overview diagram, but I started out with a top-level scratchpad diagram to brainstorm my model. I now have a great deal of trouble reassigning associations and generalizations in my diagrams, because it appears that the Master View concept has assignment of master view to my elements scattered across many views.

Is it possible to deactivate this Master View concept so that associations can be reassigned from any view? Or can I bulk assign the master view for all elements in a package to the package overview diagram so there’s an easy way to find and update associations?

This seems particularly awkward when an association crosses packages, since there may be no higher-level diagram that is the master view for both classes the association connects, and thus no shared master view diagram that allows the association to be modified. I have only been able to delete the association and recreate it on the current diagram, which risks losing details on the association because all attributes need to be recreated.

Have I misunderstood the concept, or missed any easier methods of managing these elements?

Thanks!

[antony]

Hi Dennis,

How about just select all in the current diagram, right-click on the selection and select Selection > Set as Master View from the popup menu? That way you can ensure all diagram elements in the current diagram become master views of their associated model elements.

Hope this helps,

Antony.

[amm]

@antony
This did the trick, thank you.

I still don’t get why users should deal with master/non master views in the first place.

As far as software architects care, all the views of an entity should give them the opportunity to make changes that are then reflected to all the other views. Users always operates on one view at the time, so I don’t see why the current view couldn’t be considered the master one by default.

In other words:

• Visual Paradigm can detect and alert the user that the modified view is not the master one
• The user can then activate an option to make the view as the master one

That’s an annoying, mechanical and manual operation: Visual Paradigm could just activate it, silently, instead of interrupting the users’ thought flow.

[amm]

Another really confusing behavior regarding master view is that the master view seems not to be mandatory at all; in fact, it’s possible to delete it, while keeping all the auxiliary views alive: Visual Paradigm won’t even try to prevent this.
This means that a shape can be represented in more than one view without having any master view defined; yet, any of the auxiliary views can be promoted to be the master one.
I personally find this pretty confusing.

[antony]

Hi amm,

The introduction of master and auxiliary view is to avoid accidental updating of parent-child hierarchy when working in diagram level. Since in VP parent-child relationship can be easily altered when containment of views are changed that involves master views, which may not be desirable when there are many views that after arranging shapes in a diagram (especially a complex one), user may find the model element hierarchy accidentally changed. But I do agree with you that this mechanism may seem too sophisticated and could be made more intuitive. We would consider to enhance this feature, thank you very much for your suggestions.

Yes, a master view is not mandatory, but the deletion of master view of a model element will be warned to the user, so we assume he knows what he is doing. This is to leave some flexibility to users who really want no master view at all, and choose to explicitly update parent-child hierarchy in the Model Explorer. This is a rather advanced use case and we are sorry that it confuses you.

Best Regards,

Antony.