I also think the it-is-not-able-to-attach-to-a-model-element way of
enforcing this is confusing. It would be better with a pop-up explaining
why.

Once again this depends. I don't think there's a blanket rule, we just
need to apply common sense depending an the rule itself.

For trying to attach a generalization between a Class and an Interface
I think it's quite reasonable to reject without explanation. To anyone
with basic UML knowledge it should be quite obvious why this was
rejected, its a connection that never makes sense under any condition.

For connections that could make sense under some conditions but are
being rejected because that condition isn't valid we need another
approach.

For example we currently enforce that class A can't extend class B if
class B already extends class A.

It sounds on the face of it quite reasonable but I did once think I'd
hit a bug because ArgoUML wouldn't let me draw a generalization and I
couldn't work out why. It took me quite some time to realize that
there was a generalization not shown on the diagram that was the cause
of this rejection.

I have previously argued about losing enforcement of that rule but
backed down after a while. Markus seemed quite insistent on keeping
it. I'm not sure why but I suspect it may have been to prevent
problems in code generation.

I'd like to see the enforcement of this move into the model subsystem
but we need some way of immediate feedback to the user for rejection
of items such as this. Any suggestions on what that feedback should be
and how to achieve it?

Possibly isValidConnection should be deprecated in favour of a similar
method that returns some Object instead of boolean. The model
subsystem can then provide information back to the caller if that
seems appropriate.

If the GUI receives such a response how should it react? Maybe blink
the edge a couple of times with a popup tooltip?

Bob.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to