Hello all
When we discussed this last, I think the conclusion was that we must
enforce some well-formedness rules because otherwise nsuml would
misbehave and make it impossible to load the model. Those
well-formedness rules, I would like to be enforced by the Model
subsystem. Also now, after having changed to MDR, I presume that some
things need to be enforced to be able to save.
On top of that, I consider the well-formedness rules to be
domain-specific. The separation into clear levels of UML2.0 I think
addresses this by separating the basic from the domain-specific in
levels.
In the future I would like to see domain-specific sets of plugged
critics and enforcing techniques. I mean, there is no reason to not
provide a more offensive enforcing of domain-specific well-formedness
rules, perhaps even project-defined templates.
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.
/Linus
> -----Original Message-----
> From: Michiel van der Wulp [mailto:[EMAIL PROTECTED]
> Sent: den 6 februari 2007 22:08
> To: [email protected]
> Subject: Re: [argouml-dev] Wellformedness rules - enforcing vs critics
>
> Hi All,
>
> In the issue Bob mentioned, the Well-Formedness rule in question is
the
> one
> that disallows generalizations between an Interface and a Class.
> So, Bob is in favour of preventing the user from creating such a
> generalization.
>
> However, ArgoUML does not usually enforce any well-formedness rule
from
> the
> UML standard -
> instead the critics warn you for it.
> Why? Because we do not want to outsmart the user and fail!
>
> In the future we may have a situation where drawing a generalization
> betwen
> a Interface and a Class is exactly what the user wants: i.e. when it
is
> his
> intention to transform the Interface to a Class. Then you have this
> scenario:
> 1. The user draws a generalization between an Interface and a Class.
> 2. The user converts the interface into a class (with the new function
> requested in issue 4543).
>
> IMHO, ArgoUML should allow the user to draw/create anything that can
be
> saved in a correct XMI file.
>
> On reason to allow this, is that a valid XMI from another tool may be
> loaded
> that breaks Well-Formedness rules.
>
> If this breaks e.g. code generation, then the code generation
subsystem
> needs to handle this problem.
>
>
> As an analogy for this problem, I compare this with a Java source code
> editor like Eclipse:
> You can type any char in the Java source file, as long as it can be
saved.
> If you type something abnormal, you get a (style) warning (the yellow
mark
> apears in the margin), and if the compiler will not be able to
generate
> runnabl code from it, you get a more severe message, i.e. error (with
the
> red symbol in the margin).
>
> I wish ArgoUML to work in the same way:
> You can draw/create any element in the UML project file, as long as it
can
> be saved (as XMI). If you create something abnormal, you get a
(critic)
> warning (the red mark apears below the element).
> In the current implementation, if the code generator will not be able
to
> generate runnable code from it (as is e.g. the case for an unnamed
class),
> ArgoUML simply ignores the object.
>
>
> Regards,
> Michiel
>
>
> ----- Original Message -----
> From: "Bob Tarling" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Tuesday, February 06, 2007 7:52 PM
> Subject: [argouml-dev] Wellformedness rules - enforcing vs critics
>
>
> > As Michiel points out on
> > http://argouml.tigris.org/issues/show_bug.cgi?id=4632 ArgoUML has
> > traditionally used critics to suggest design improvements.
> >
> > I think there is often a fundamental difference in a poor design and
a
> > badly formed model. Especially if we want that model to be used by
> > other tools.
> >
> > At the moment we do have some enforcement in the code. I've been
> > trying to javadoc when I find these with references to the section
in
> > the UML spec.
> >
> > I'd like to suggest that we start a section in the cookbook where we
> > document these. This will make it clear what has been agreed for
each
> > specific welformedness rule.
> >
> > I'd suggest that for each wellformedness rule that we enforce we
state
> > the rule reference in UML1.4.2, the text of that rule and where in
the
> > code this is enforced. I'd hope that as these are discovered we can
> > move any enforcement to the model subsystem.
> >
> > Regards
> >
> > Bob.
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.17.26/670 - Release Date:
> 5/02/2007
> > 14:04
> >
> >
>
> ---------------------------------------------------------------------
> 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]
