What does it mean when a capital M appears in an Element?


#1

the image below illustrates. I tried obtaining the image by right-clicking the element and choosing Copy as JPG but the M didn’t appear in the resulting image, so I’ve had to use a standard screen grabber.

In any case, some of my drawings have suddenly started displaying those Ms and I can’t find any reference to what they might mean.

Suggestions?

image


Quickest way to find instances of an element
Can Community transfer logical to phisical ERD?
#2

The M stands for “Master view” and it means that you have re-used the model element in another diagram. If you go to that other diagram you’ll notice that the model will show a small ‘a’ there which stands for “Auxiliary view”. Basically the ‘M’ is the default (“Master”) model element whereas the ‘a’ is the re-used copy.

This process is explained in the manual, but I can definitely see that it’s easy to overlook. Check the section about the Modeling toolset, and in specific the Model element and view section (or just follow the link).

You can hide these indicators if you want by selecting the “Model Indicator” option on the ‘View’ toolbar.


#3

Thanks for the straightforward explanation.

Supplementary question: what are the implications of an element being a “Master” or Auxiliary View?

Does it mean if I change one, I change the other? and, if so which way round? (I would guess changing the master would update the auxiliary but not t’other way round) and if I delete the Master, will the Auxiliary also disappear?


#4

Good question!

Yes, that’s exactly what it implies. See, the reasoning behind this is to give you a relatively easy way to not only create complex projects but to also keep those projects manageable. One key feature of Visual Paradigm is its information management. VP is much more than merely a modeling tool; it’s just as much a massive information management system (as I like to call it). Almost every model element can store so called “meta data”, in other words: extra information concerning that object:

Now, this is a very simple example. I have a use case and I added a description. Just trust me when I say that VP can go much deeper than this. Anyway: if I were to constantly copy this model element in other diagrams (so: a real literal copy) then things could go horribly bad if it turns out that my description needs an update. Maybe things changed or something extra is required.

When you have dozens of copies you’re now also looking at dozens of edits in order to change each and every single model element.

Well… That’s something Visual Paradigm does “a little bit” smarter :wink:

One master element (the real one) and virtual copies elsewhere (auxiliary views). Change one and everything else also gets changed. So it doesn’t matter what you change, it goes back and forth. Basically all elements behave the same.

Depends on your settings. Default behavior is to never delete a model element which still has views assigned to it. And to ask you if you really want to delete a model when deleting its view.

Simple answer: you can’t “simply” lose a model element by deleting it if you don’t want to. If you delete a master view element then you’ll keep the auxiliary view(s) available in your diagram(s). The master element isn’t even really deleted, but simply unassigned from the current diagram.

So although you won’t see it in any diagrams anymore you’d still see it in the project browser and the model explorer pane. It’s basically moved back into your “model repository”. Default behavior is to have it ‘locked’ there because of its associated views (the auxiliary views). In other words: if you try to delete the master view then Visual Paradigm will simply ignore your request because of its settings (it has views assigned to it so can’t be deleted).

Of course this behavior can be changed in the application settings.

I hope this is still easy enough to follow. The whole view concept is a little bit abstract and can be difficult to grasp at first.


#5

I hope this is still easy enough to follow. The whole view concept is a little bit abstract and can be difficult to grasp at first.

actually not that difficult. For someone familiar with object oriented programming at least, it makes perfect sense.

The only ambiguity in your description comes from:

One master element (the real one) and virtual copies elsewhere (auxiliary views). Change one and everything else also gets changed. So it doesn’t matter what you change, it goes back and forth. Basically all elements behave the same.

which isn’t quite what I’m used to with “inheritance”. In OOP, I can create classes which correspond to your “Masters” and reuse them - as sub classes - whereever I want. If I change the class, then all sub classes carry the change. However, if I add something to a sub-class it will remain exclusive to that sub-class and not carry back to the Class.

It looks like your saying that if I change the subclass (“auxiliary”) in VP, I also change the class (“Master”). Is that correct?


#6

Exactly.

Master view and auxiliary view are always the same model element and share everything.


#7

Hi Harry,

The analogy of class and subclasses is not quite appropriate for the master and auxiliary classes in VP, and thus you have your confusion. A view is just a visual presentation of a model element, and all views of a particular model element, master view or not, all point to the same model element.

Best Regards,

Antony.


#8

OK, thanks (to both of you).

Final question then.

Suppose I’ve copied a whole bunch of objects (elements) from one drawing to another for the express purpose of making minor amends in the copied version - which I don’t want mirrored in the original - how do I break the connection?

For example I might be setting up a process in Sales Ordering and Sales Invoicing. The procedures might be virtually identical but obviously the one will hold references to Orders and the other Invoices. So I copy the Orders one to a new diagram called Invoices and then change all the references. Obviously I don’t want to return to the Order version to find the references there have been changed to Invoice.

Is this, perchance, what the “Must Isolate” (right-click option) is for?

Actually; just hit another question which is related and probably more important:

So I’m looking at a “Master” and, before changing it, I’d like to see all the other instances where it’s being used as an Auxiliary so that, if necessary, I can “isolate” either the Master or the Auxiliaries. How?


#9

Just partially answered the “Isolate” question myself.

Created an element with a few lines of text
copied it.
(within same diagram.)
Could see it was a Master and Copy was auxiliary.
Could not find any way to modify either Master or Auxiliary without amending both.
That’s the link I need to break. I frequently need to do precisely that.

The only workaround I could find was NOT to copy the element but to copy its content only, then create a new element and paste in the content (which I can then modify without affecting the original)
That’s clumsy


#10

You’re right, that is annoying. Fortunately there’s also a solution here.

You can paste a copy in 2 different ways. By default only its view will be pasted, so you’re effectively creating the previously discussed auxiliary view.

But you can also paste a model element. Then you’re creating a fully new model (element) which isn’t related to the original:

diagram_paste

As you can see: click on the arrow under the paste button, in the diagram toolbar. That should do the trick. Another option is to right click in your diagram and select the option from the menu:

menu_paste

And there’s even a third option :sunglasses:

Control-V is the keyboard shortcut which you use to paste, and as mentioned it defaults to pasting a new view. And there is no keybinding for pasting an element, but… You can customize those keybindings if you want:

So:

  • Go to the Window toolbar and find the button “Application options”.
  • After you clicked that select the ‘key’ option from the list on the left.
  • When done enter the name of the function you’d like to change in the search field (I added ‘paste’). Of course you can also simply go over the list.
  • If you want to change a binding then click on the input section behind “Binding:”, I pointed an arrow to it. After you clicked this section press the keyboard combination you’d like to use. For example: control-shift-v ?
  • Make sure that there’s nothing mentioned in conflicts section, if there is then you either need to use another binding or you can choose to override it. Control-shift-v is already assigned by default, but if you never used it before then why not re-assign it?
  • Click apply, then ok and then restart Visual Paradigm.

From this moment on your new keybindings should be active.

Personally I recommend keeping the view behavior as it is and simply add a new control for pasting elements, but of course this is totally up to you. Do keep in mind that a new copy will also use up more resources (memory mostly).

Hope this helps!


#11

Hi Harry,

Besides the paste model element method ShelLuser said, you can also use the “Duplicate” command. It is essentially the same as copy + paste with model element. You can find it under the copy menu, but most likely you would access it using the default binded hotkey Ctrl + E. What is better with the duplicate command is you can also create a copy of compartment members (e.g. attributes/operations of class) which you cannot achieve with simple copy and paste.

Best Regards,

Antony.


#12

Again thanks to both.

And both options work as I need. I can live with the right click and “Paste Model Element” without changing key assignments but I actually prefer the Duplicate option because, if I’m understanding that correctly, it would enable copying and element complete with its narrative and sub-diagrams. I would probably, therefore, only use the Paste element option if it did NOT want the other details copied.

I think our work here is done!