constraints and context

[Paul Lotz]

I have a feeling there isn't a right answer here, but I'm curious to hear some opinions:
Is it better to place a constraint on an attribute or a class containing the attribute.  (For the most part I am specifying invariant constraints on the allowed range of the parameter.  There is the practical issue that constraints defined on classes are visible on the diagram, while those on parameters are not--conveniently--visible.  On the other hand, if I move a parameter with a defined constraint to a different class I presume the constraint will move with it.)
What do you think?

[Paolo F Cantoni]

Well, one way around it might be to place the constraint on the attribute (I presume it IS an attribute level constraint) and then run a transform to automatically create a derived Class level constraint.

If you remove the constraint (say as you suggest, by moving the attribute), the next transform should delete the (derived) class level constraint.

It is, of course, another aspect of EAUI...

Paolo

[Geert Bellekens]

Paul,

We define constraints on three levels:

• Attribute level: A constraint that only deals with this specific attribute. We model this as an attribute constraint. This is the type of constraint we try to avoid as much as possible. Often this can be done by creating a new datatype that already has these constraints. (on a class level then)
• Class level: A constraint that deals with multiple attributes of this class, but does not deal with things outside the class. These types of constraints are created as class constraints.
• Inter-Class level: A constraint that deals with multiple classes. (e.g. an attribute of ClassA has to have the same value as another attribute on one of the related classes.

We tried to model this as independent constraints at first, but then we ran into trouble with that since the constraints are deleted when the diagram (some versions ago) or the package (now) gets deleted. There is no way to move the constraint to another package to avoid this.
Now we model these constraints also as a Class constraint, on the "main" class. (the class that is most involved). We then create dependencies from the other involved classes to the class containing the constraint. These dependencies have as name the name of the constraint, and as stereotype <<constraint>>
[/list]

Geert

[KP]

Another choice to consider: create a data type (classifier with the «dataType» keyword) for the attribute and put the constraint in the data type.

[Paolo F Cantoni]

Another choice to consider: create a data type (classifier with the «dataType» keyword) for the attribute and put the constraint in the data type.

But surely Neil, this should only be done if the constraint is actually on the datatype (as a whole) - and not just the particular attribute.

Paolo

[Paolo F Cantoni]

[size=18]...[/size]

• Intra-Class level: A constraint that deals with multiple classes. (e.g. an attribute of ClassA has to have the same value as another attribute on one of the related classes.

[size=18]...[/size]

Hi Geert,

I'm pretty sure that should read Inter-Class (as between classes) rather than Intra-Class (within class).

HTH,
Paolo

[KP]

Another choice to consider: create a data type (classifier with the «dataType» keyword) for the attribute and put the constraint in the data type.

But surely Neil, this should only be done if the constraint is actually on the datatype (as a whole) - and not just the particular attribute.

Paolo

If you have multiple attributes with the same set of constraints, it can be helpful to move the constraints out of the attributes and into the data type. It would remove duplication. As I said, another choice to consider.

[Paolo F Cantoni]

[size=18]...[/size]
If you have multiple attributes with the same set of constraints, it can be helpful to move the constraints out of the attributes and into the data type. It would remove duplication. As I said, another choice to consider.

I thought that WAS the definition of a Datatype Constraint.  

The datatype would, of course, be limited to that set of attributes...

Paolo

[Geert Bellekens]

Hi Geert,

I'm pretty sure that should read Inter-Class (as between classes) rather than Intra-Class (within class).

HTH,
Paolo

Yes Paolo, thank you for noticing. I've fixed that in my original reply

Geert

[son-of-sargasso]

Stick the constraint on the lowest level it will apply. EOM

bruce

AMEND:Stick the constraint on the lowest level it can be applied.

[Paolo F Cantoni]

Stick the constraint on the lowest level it will apply. EOM
bruce
AMEND:Stick the constraint on the lowest level it can be applied.

I would have thought the opposite.  Place the constraint at the highest level of universal applicability (to the contained set).

Paolo

[RoyC]

Well, you are probably both thinking the same thing - the constraint goes exactly where it applies - any higher and it would be applied to things it shouldn't, any lower and it wouldn't be applied to things it should. bruce's logic makes more sense, as in the check "is there something here it doesn't apply to? Yes... drop it lower".

[Paolo F Cantoni]

Well, you are probably both thinking the same thing [size=18]...[/size]

Yes, Roy I too thought the same that bruce and I were approaching this from the different directions.  However, the keep going higher until it no longer applies is safer and more general.

One could argue that some of the bugs we find in EA are specifically caused by constraints/requirements that should apply more universally being applied differently at lower levels.

Having determined that a constraint/requirement is pretty general, when I find "exceptions" I apply the "Show Cause" argument:  "Show cause why you should be different..."  I've found it a useful mechanism for increasing consistency in systems design.

Paolo

[Paul Lotz]

OK, this discussion has indeed been interesting so far.  Let me throw out a couple more things:

1) A book I have (OK, it's Russ Miles and Kim Hamilton, Learning UML 2.0, O'Reilly, 2006) on p. 242 gives examples of applying a constraint at:
a) the attribute level ('baseCost >= 0.0')
b) the class level ('self.baseCost >= 0.0').
As I understand it, the meaning is the same (it certainly means the same thing to me but I'm not using the constraints to build code automatically) but the maintenance may be easier one way rather than another.  EA has its own way of handling constraints with corresponding opportunities and challenges.  I see that if I put a constraint in the dialog for an attribute this has the advantage that if I move the attribute to a new class, the constraint moves with it, and the disadvantage that I have to open the dialog for the attribute and click on the proper tab in order to see the constraint.
If, on the other hand, I add the constraint at the class level, I have the advantage that the constraint appears on the diagram--a major plus for a reviewer or someone coding to the design, but the disadvantage that if I move an attribute (say I am refactoring the design, which event was actually the trigger for the original thread topic) I have to copy the corresponding constraint manually from one class to another (which requires opening multiple class properties dialogs in succession to copy and paste each constraint one at a time).

2) On that note, I wonder if it might be advantageous to give constraints more visibility in EA.  This might mean:
a) giving constraints visibility in the project view.  This might be too big a change.
b) showing constraints in a window (either in a Constraints window or as a section in another window).  EA already has a Notes window where we can easily view (and copy and paste) notes for a selected item (which can be an attribute or a class, among other things).  EA does not (to my knowledge) support the same behavior for constraints (and the Properties window applies at the class level, not the attribute level).  I think this would be quite nice functionality to have.

[Geert Bellekens]

Paul,

I think you should be careful with putting information in a place it doesn't really belong just because it is more convenient in EA.
I know, we all have to be pragmatic sometimes but still.

As for the reviewing process; I've found that it is very difficult to review a part of a model using the model only. There is too big a chance that you miss something because the model isn't linear (so there is no one way to follow to visit everything) and there could be information that needs reviewing in a lot of different places. (like constraints, scenarios, requirements, ...).
It is almost impossible to check all those places for each element that you review.

For reviewing purposes I prefer a generated document. That allows you to represent all elements in a linear way, and you can make sure that all information that needs to be reviewed is mentioned in the document.

Geert