Hi Richard,
1) Don't know. I never use Set Active.
2) That is correct. However, if you want your adapted toolboxes to appear with the standard diagrams (as opposed to your own diagram types), you have to "override default toolboxes" (see help).
3) To each his own, but here's what I use.
MDG Technology development is always in its own project. Depending on the situation there may be one project per technology, or several technologies can share. Really the biggest decider is the number of document templates, because there's just no way of structuring them.
My basic setup has a root node with the same name as the technology, with three views for the different type of profile. So:
[Name of MDG Technology]
- "Profiles"
- "Toolboxes"
- "Diagrams"
Each view has one or more «profile» packages. I use the following naming scheme:
- Profiles (actual UML profiles, that is): abbreviated names, in camel case with whitespaces replaced by underscores
- Toolboxes: Longer, more descriptive names, with some hierarchical naming if there are more than two or three; spaces allowed
- Diagram sets: short names but no abbreviations; whitespeces replaced by dashes
These rules are based on what EA shows where in the GUI, and work pretty well. Using dashes in one case and underscores in another makes things more consistent (hi, Paolo!) and helps you see what's in which XML file.
In true EA style, the diagram type doesn't matter: when EA sees the "profile" stereotype, it ignores its regular mechanism for opening the right toolbox and instead opens the profile toolbox regardless of diagram type.
I use this as a simple way of keeping track in the project: packages for actual UML profiles get class diagrams, toolbox profiles get component diagrams and diagram set profiles get deployment diagrams.
I don't use the profile helpers much, but if I did I still wouldn't add a package level for them. They're just a convenience to take some of the drudgery out of technology building, they don't add anything you can't do yourself. Put another way, they don't exist in the MDG Technology metamodel.
On disk I create a top level directory with the same name as the root node, then three subdirectories "Profiles", "Toolboxes" and "Diagrams". This is useful because the MDG Technology wizard stores the three directories in the registry, and also it doesn't check to make sure you don't add a toolbox to the diagram section, in which case the generation works but the resulting technology is borked.
So that's my basic setup. I also like to place any scripts and above all search definitions in document artifacts, to make sure they're stored with the rest of the source data and not just on a file in my home directory.
For the record: I don't have OCD. I just used to build military command and control systems for a living.
/Uffe
