Multiple toolboxes per diagram profile

[Paolo F Cantoni]

I'm dealing with people who don't necessarily want to model in the first place.  Any friction is too much friction.

The best thing then is to make some standard patterns and include them in your toolkit.  It's always payed off for me.

Indeed, but I want the ability globally rename elements of the pattern as they are instantiated.  NOT possible, it seems  (without custom automation).  Otherwise, the pattern will be stuffed up.

Paolo

[Uffe]

I seem to be able to cross-reference MDGs (for example, MDG2 uses a stereotype definition from MDG1 and can place it on its Toolbox, also it can use it in its (MDG2) QuickLinker.  Is that by design or EAUI in our favour?  It seems to be very useful and I'd like to know if I can rely on it.

I'm pretty sure you're safe there.

It is perfectly possible to refer to profiles in other MDG Technologies from a toolbox, notably UML and SysML as exemplified in the help. The toolbox simply doesn't know or care which MDG Technology the profile resides in.

The references to element/connector types in toolboxes are on the form MyProfile::MyStereotype (the MDG Technology is not part of this identifier), and that's exactly how they're written to the MDG Technology XML file. (If you reference a pattern, that's referenced as MyMdgTech::MyPattern.)

In other words, they don't get resolved into whatever internal format EA uses during creation of the file. The resolution happens later, either when the MDG Technology is loaded, or even on demand each time the user opens the toolbox.

Which it is doesn't matter. The point is that this is clearly by design and not an accident: this is how MDG Technologies work.

I'm not entirely sure when it comes to quick linker definitions, since those are stored within a profile and the stereotypes are referenced without the MyProfile:: prefix. I can't recall setting up a quick linker that uses elements from different profiles, and the help doesn't list any such example. But again, if it works it's most likely intended to.

Cheers,


/Uffe

[qwerty]

I just tried the QL and you can create foreign MDG links in your own MDG. Try adding the following lines

Code: [Select]

Class,,Class,,,,,Dependency,DataAssociation,to,da,,TRUE,,,,,,,,,,
Class,,Class,,,,,Dependency,BPMN2.0::DataAssociation,to,dab,,TRUE,,,,,,,,,,
The "da" will create a MDG-local DataAssociation and the "dab" one for BPMN (which will have the according TVs).

q.

[smitasam]

My thought for the technologies was simpler.
One technology that defines the stereotypes and base toolboxes.
Additional technologies can then be defined for each role that define additional common toolbox pages that are available regardless of what diagram is open.

[qwerty]

The advantage of using MDG is that it relates diagram and toolbox (which really makes a lot of sense). Throwing that away seems to be a bit silly.

q.

[Paolo F Cantoni]

The advantage of using MDG is that it relates diagram and toolbox (which really makes a lot of sense). Throwing that away seems to be a bit silly.

q.

I'm actually thinking along an enhancement of smitasam's idea...

One technology that defines the stereotypes and other generic objects.
Then in folders below the base, each role has an MDG that uses the base MDG to define the toolboxes.  

Since the diagram specification  in the base MDG defines the name of the toolbox to be activated, then each role based MDG defines that toolbox!  Since you shouldn't be loading more than the base and 1 role at a time, we can get away with it...  (I think).  Haven't tried it out yet, but I think it should work.  Anyone see why it won't?

Paolo

[qwerty]

 Anyone see why it won't?

Paolo

That should work, but only from a guess. You need to give it a try. It's probably legal, but tricky. So the side effects might wipe out the advantages. I guess that one could bring in some nice ideas into MDG. But from experience I seem to know that the chefs will spoil the broth.

q.

[Uffe]

The advantage of using MDG is that it relates diagram and toolbox (which really makes a lot of sense). Throwing that away seems to be a bit silly.

q.

I'm actually thinking along an enhancement of smitasam's idea...

One technology that defines the stereotypes and other generic objects.
Then in folders below the base, each role has an MDG that uses the base MDG to define the toolboxes.  

Since the diagram specification  in the base MDG defines the name of the toolbox to be activated, then each role based MDG defines that toolbox!  Since you shouldn't be loading more than the base and 1 role at a time, we can get away with it...  (I think).  Haven't tried it out yet, but I think it should work.  Anyone see why it won't?

No, I'm pretty sure it will. For additional safety, you could set them up in different directories and get the different roles to configure their EA client accordingly. But that's a bit of the old ding dong, tweet-tweet.

/U

[Paolo F Cantoni]

It does seem to work, but only if one is referenced (not active, but there is only one folder reference in the list) at a time.

I can't explain the behaviour of EA when more than one of the subfolders is referenced, but I just put it down to EAUI.

I guess I can use it going forward.

Paolo