Hi All,
OK, I think we agree about the following.
WFR = Well-Formedness Rule.
1. Critics have to warn for WFR violations (a critic for every WFR would be
ideal).
2. Generally, ArgoUML does not enforce WFRs, except in certain cases.
3. In such cases (where we enforce a WFR) we have to
a. document this case, and
b. be consistent about it.
4. Even if a WFR is enforced, ArgoUML should still be able to deal with a
model that breaks it (since we can load a XMI that breaks the WFR).
Issue 4632 is a case where ArgoUML breaks point 3b above.
Regards,
Michiel
----- Original Message -----
From: "Bob Tarling" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, February 07, 2007 10:05 AM
Subject: Re: [argouml-dev] Wellformedness rules - enforcing vs critics
On 07/02/07, Tom Morris <[EMAIL PROTECTED]> wrote:
I'd prefer to see stuff like this documented in the code to which it
applies
(if there's more than one place, that's a different problem). The
cookbook
is too large and too rarely consulted for this kind of design
information.
It'll never get seen there.
The logic is currently in more than one place and that's partly why I
suggested this.
- So that it is commonly understood that there is no blanket rule that
we never enforce any well-formedness rule.
- So that when we upgrade to UML2.x we have a single place to go find
what rules we enforce and check if they are still relevant
I'd be just as happy if we can find the scattered rules and move them
into some specialist methods in the model facade (or even have the
model implementation enforce as in
http://argouml.tigris.org/issues/show_bug.cgi?id=4632)
The problem with enforcing rules strictly and immediately is that it
doesn't
allow the user to create partial models which invalid or models which are
inconsistent during the process of changing them. The flip side of that
is
that defering resolution of the issue increases the likelihood that it
will
never get addresses. It's a balancing act and I'm not sure there's any
one
good solution.
I'm not suggesting we add any more enforcement now and I wouldn't do
so in future without some discussion.
But the same goes for removal of any enforcement that is currently
there. I'd want a consensus before any existing enforcement is
removed.
But what about where it is half implemented as in the current state
shown by http://argouml.tigris.org/issues/show_bug.cgi?id=4632
To my mind that is an enforcement that we current implement but there
is a bug in that implementation. So the bug should be fixed.
The implementation should not be removed until we have some common
agreement on that so in the meantime it should be fixed to work as
intended.
Again I'm talking about the general principle here as there is also
inconsistency in the rule that if class A generalizes call B then the
opposite can't be true. You can't draw this on a diagram as the
diagram enforces that rule but you can break this rule creating the
generalization using the explorer context menu.
For any issues like this I think we should fix first to work as was
intended by the person who put that rule in and have the product
working consistently.
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.29/673 - Release Date: 6/02/2007
17:52
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
