Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Uffe

Pages: 1 ... 10 11 [12] 13 14 ... 21
Suggestions and Requests / Code Template Framework: add @sort to %list%
« on: December 09, 2009, 07:44:01 pm »

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.



Suggestions and Requests / Model Transform: Optional Diagram Creation
« on: November 18, 2009, 07:02:12 pm »

I work with MDA Transforms a lot, and while the auto-generated diagrams are often useful, other times they are not.

Since diagram creation and layout accounts for a significant proportion of resource usage during a transform, I'd like a "Create Logical Diagrams" tickbox in the Model Transformation dialog.



Suggestions and Requests / Element Properties: Link End
« on: August 19, 2009, 10:16:40 pm »

The Link tab of the Properties dialog could do with an indication of which end of the link the element is at, source or target.



The Code Template Framework allows access to Class constraints only, but Attributes, Connectors and Packages can all have constraints too.

I suggest the following:
  • Rename the macros constraint* -> classConstraint*
  • Add attConstraint*
  • Add connectorConstraint*
  • Add packageConstraint*
  • Remove connectorSourceConstraint and connectorDestConstraint (connectorSourceElem* and connectorDestElem* should take care of those)
To me personally, the attConstraint* ones are the highest priority.



Suggestions and Requests / Package: Set As Namespace Leaf
« on: August 06, 2009, 06:08:23 pm »

This feature is intended to improve the display of foreign elements (ie elements from a different package) in a diagram, primarily within large models with recurring package structures.

Let's say you have a model along these lines:
+-- Software Modules
|   +-- Blarg (*)
|   |   +-- Actors
|   |   +-- Use Cases
|   +-- Honk (*)
|   |   +-- Actors
|   |   +-- Use Cases

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.



Suggestions and Requests / Unique Element Names within Package
« on: August 11, 2009, 04:20:47 pm »
Hey everyone,

This feature takes off from a discussion regarding namespaces and uniqueness of element names that came up in

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.



Suggestions and Requests / Select Type Dialog: Language Types
« on: August 03, 2009, 08:25:31 pm »

Loving the Select Type dialog in 7.5.846.

Would like to suggest the following addition: add a root node to the tree for the element's specified Language, which contains the Language's built-in types. So you'd see something like:

+ My Model Root Node 1
|  +--- My Model Root Node 1 View 1A
+ My Model Root Node 2
|  +--- My Model Root Node 2 View 2A
|  +--- My Model Root Node 2 View 2B
+ Built-In Java Types
|  +--- boolean
|  +--- byte
|  +--- char


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.



Suggestions and Requests / Subversion Credentials
« on: July 15, 2009, 03:51:19 am »

When working with Subversion, EA assumes that the user logs into the repository using some other mechanism, and hangs during check-out if this hasn't been done.

The hang is obviously a bug, but the feature I'd like added is a way to enter your Subversion credentials for EA to supply to the server.


Suggestions and Requests / Users and Groups vs Authors and Roles
« on: July 11, 2009, 04:34:36 am »
Hey there!

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. Cool
What 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.



Suggestions and Requests / Attribute Feature Visibility
« on: July 07, 2009, 02:43:50 am »
Hey all,

I'd like the ability to see Attribute Tags and Attribute Constraints in diagrams. Is there a way to do this or should I chuck in a feature request?



Suggestions and Requests / Diagrams in Reverse Engineering
« on: May 08, 2009, 12:57:11 am »

To my mind this is almost a bug, but let's rather call it a feature request.

When reverse-engineering code you get the option of creating a logical diagram per Package. That's cool.

Except there are some languages which in EA are implemented using Classes where you would expect a Package. Two perfect examples: IDL (<<idlModule>> is a Class) and Ada (<<adapackage>> is a Class).

Checking the Logical Diagram box thus results in diagrams that are frickin' huge and of no use to man or beast.

Would it be possible to get the reverse-engineering thing to create the diagrams inside the outer Classes instead for languages like these?



Suggestions and Requests / Advanced Element Searches
« on: May 01, 2009, 05:30:05 pm »
Hi all,

EA is a great modelling tool, but in order to boost productivity even further I'd like to see more higher-order functions in there to help you with maintenance, rather than development, of your models. The company I work for has a couple hundred programmers and product lifecycles which run for decades, so maintenance is the big issue for us.
Here are some suggestions.

Find Externally Connected Elements
Searches a package for elements which have a connector to an element outside the package.
Options: External Target, External Source, Both.
This would help you keep track of what is a purely subsystem-internal concern and what affects other parts of the system.

Find Unused Elements
Searches a package for elements which have no connectors at all, and which are not used as types in attributes, operation parameters, etc.
This is similar to dead code elimination and helps you get rid of things that have been rendered obsolete by the ravages of time.

Find Unconnected Elements
Searches a diagram for elements which have no visible connectors to anything else in the same diagram.
This helps keep your diagrams clean when you make changes in the model.



Suggestions and Requests / Diagram - Lock Elements
« on: May 01, 2009, 06:37:50 pm »
Hi again,

I'd also like a Lock Elements function in the diagrams, especially wrt Connectors.
This would allow you to alter the layout, but not to make any semantic changes such as moving connectors from one element to another, etc.


Suggestions and Requests / Diagram - Lock Layout
« on: May 01, 2009, 06:20:22 pm »

I'd like a Diagram - Lock Layout function. This would lock the layout of the diagram, but still allow you to draw connectors, add elements, etc.
The only restriction it would impose would be that you couldn't move elements around.

This would be convenient for drawing large numbers of Dependencies when documenting legacy designs.



Well, title says it all really. Would like Select All / Select None in the Diagram - Visible Relations dialog.



Pages: 1 ... 10 11 [12] 13 14 ... 21