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]
