Topics - Uffe

I'd like an item added to the Edit Menu: Copy Name. This copies the name of the selected element (or connector, or feature) into the clipboard.Normally, you can do this by F2 - Ctrl-C - Esc (edit name, copy, cancel edit); however, if the element is locked editing is prohibited.

And please don't tell me not to use such long element names that I can't type them in somewhere else. *I* know that. It's these other bozos...

I can select an element in a diagram and via its context menu (or by pressing Alt-G) Find it in the Project Browser.I'd like to be able to do that with the diagram itself, through its context menu or by pressing Alt-G when nothing in the diagram is selected.Helpful when modelling in several different branches of a large model. Plus it'd take you guys like five minutes to implement.

Here's a GUI feature I'd like: select one or more elements in a diagram, right-click, choose "Select Connected."This causes the GUI to add to the current selection all (previously non-selected) elements in the diagram which are connected to one of the elements in the original selection.Great for moving things around in a complex diagram with hand-drawn layout.Cheers,

The code generation control macro %list% could use a @sort argument. Things often need to appear in a resulting file in a strict order, defined by the contents of the elements.

The argument should be the name of a macro to be applied in context when the %list% is executed. Examples:%list="Class" @sort="className"%%list="Operation" @sort="opAlias"%%list="Attribute" @sort="attInitial"%%list="Namespace" @sort="packageTag:%qt%MyTag%qt%"%

It should also be possible to specify a reverse sort by adding an additional argument @reverse="True".

Not specifying a @sort argument results in the model default order (which can still be reversed).

This functionality would be immensely useful for some of the stuff we do over here.

Ignore the (*) for now.Let's say in one of my Honk use cases I wish to include a use case from Blarg.When presented in Honk's diagram, this use case will be labelled "(From Use Cases)".Since I am using a recurring package structure, this label isn't very helpful: EA displays only the immediate parent package of the foreign element, and that package name occurs in dozens or hundreds of different software modules.

I propose adding an option "Set As Namespace Leaf" to a package. In the structure above, assume I have applied this flag to the (*) packages.

When displaying a use case symbol from Blarg - Use Cases in a diagram in Honk - Use Cases, EA would then label it "(From Blarg)".In other words, EA searches upwards in the package hierarchy and uses the name of the first package it finds with the "Namespace Leaf" flag set.If the search hits the root node with no "Namespace Leaf" package found, EA uses the name of the element's immediate parent package (ie today's behaviour).

In a use case diagram in Honk - Use Cases, an actor from Honk - Use Cases should be labelled "(From Actors)".This is achieved by EA performing the "Namespace Leaf" package search twice, once from the element and once from the diagram.If the first hit in both searches is the same package, ie the element and diagram have the same nearest "Namespace Leaf" package, the immediate parent package name is displayed (again, as today).

This way, Honk actors will be labelled "(From Actors)" in the Honk use case diagrams.In the same Honk use case diagrams, use cases from Blarg - Use Cases will be labelled "(From Blarg)".Let's say that one of my Honk actors generalizes a Blarg actor. In the Honk actor diagram the Blarg actor will be labelled "(From Blarg"), while in a Blarg use case diagram, the same actor will be labelled "(From Actors)".

The package symbol in the project browser should be different when the package is a "Namespace Leaf."Finally, "Namespace Root" is a code engineering concept, while "Namespace Leaf" is a purely visual one. Therefore the option shouldn't go in the same place as "Set As Namespace Root," and perhaps the name "Namespace Leaf" is a bad one.

EA does not enforce unique element names within a package, and I'm pretty sure it cannot do so and remain UML compliant. The standard only says that an element must have a name, it doesn't say anything about uniqueness.

However, names within a context do need to be unique in order for the model to be properly understood - either by a person or by a compiler.

So I propose adding an Object option, "Warn about duplicate element names", which would flash a confirmation dialog whenever you tried to give an element a name that another element in the same context already has, ie element in package, class in outer class, etc.This would apply to name entry during create/rename, as well as when moving an element from one context to another. You wouldn't want it during imports, although perhaps it might be useful to see a list of such offending elements in the import output.

In addition, a model validation rule should be added to check for uniqueness of element names within each context.

The language-specific node would have to be context-sensitive of course, just like the quick type selector drop-down in the Attribute Properties dialog, and you wouldn't be allowed to Add New in this branch.

This would also help fix a bug in the current implementation: if your attribute is of a built-in type and you open up the Select Type dialog, a (non-builtin) element is highlighted in the tree, indicating the wrong type for the attribute.

Users (User Security) can be imported from an Active Directory. Cool.Authors (Reference Data) can be imported from an Active Directory. Cool.What I'd like is the ability to synch Authors to Users, if User Security is enabled.This way, I can keep Authors synched to Users regardless of whether I have an AD in play, plus if I do have an AD I only need to import users into EA in one place.

Groups (User Security) define access to EA functionality. Cool.Roles (Reference Data) define project roles. CoolWhat I'd like is the ability to associate one or more Groups to a Role, if User Security is enabled.This way, the Roles take on an actual meaning within an EA project.