Hi Linus
I'm not sure what you're suggesting to be honest. I'm not sure if it's
the explanation or whether you've stepped across my boundaries of
knowledge.
However it does sound complex and I don't see the complexity has the
benefit. Sounds like a big hammer for a small nut.
I'd prefer we fix what we have and keep the logic in one place and do
that as soon as possible. We can then concentrate on other bugs and
major issues (undo, sequence diagrams, completing UML1.4 panels,
moving to UML2, concurrent development, separation of subsystem etc) I
think they will keep us busy enough for quite some time.
Bob
On 08/02/07, Linus Tolke <[EMAIL PROTECTED]> wrote:
Hello Bob!
Let me suggest a slightly more general approach to this.
Let me introduce UML Profiles into this. Say that we support UML
Profiles. Each UML Profile is a set of constraints (and some other stuff
like new Figs for some model elements).
What if we let the user decide, for each profile, if it is to be either:
* Disabled
* Enabled as critics (i.e. every violation of the constraint shows up as
a ToDoItem, sortable by profile).
* Strictly enforced (i.e. it is not possible to have a model that
violates the profile).
Now, the first two I guess are simple enough to implement. We need some
interface into the critics verification mechanism.
Having said that I now would like to that the same UML Profile
implementation can also be changed to Strictly enforced. That means that
I want the same interface to be used both by the Strictly enforced
mechanism and the As critics mechanism.
Once that is done, we could also have two versions of the Strictly
enforced mode if you want. A "terse mode" where the user is just stopped
from doing it as you suggest below and one "explaining mode" where the
user gets a popup stating the name of the profile(s), the name of the
constraint(s) violated and possibly also wizards for helping to resolve
this. One resolution that will always work is to change the UML Profile
back to "Enabled as critics".
I think the big challenge with this is designing the interface to an UML
Profile and making it possible to load available UML Profiles. I hope
you, or someone (Venu perhaps), feels up to such a challenge.
There is also the challenge of generating tools from the UML Profiles
that are useful in working with a model adhering to a specific model but
I think that is a second step.
If we haven't solved this in the next couple of months, I think I will
suggest this for this year's Google Summer of Code, provided that we are
welcome back.
/Linus
> -----Original Message-----
> From: Bob Tarling [mailto:[EMAIL PROTECTED]
> Sent: den 7 februari 2007 21:37
> To: [email protected]
> Subject: Re: [argouml-dev] Wellformedness rules - enforcing vs critics
>
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
