Stereotypes and Constraints



Date view Thread view Subject view Author view

John Daniels (jdaniels@cix.co.uk)
Sat, 18 Dec 1999 17:16 +0000 (GMT Standard Time)


Dear pUML, Apologies to those of you who have seen this question already (via private email). I thought I'd ask here to get a wider response. My problem concerns the relationship between stereotypes, constraints and "well-formedness rules" in UML 1.3. The spec has many well-formedness rules written, more or less, in OCL. It seems that these rules are to be interpreted at the "model" meta level; that is, they describe constraints that apply to model elements, e.g. that attributes must have unique names within a classifier. In well-formedness rules the word "self" refers to the model element, e.g. a Class, so I can write things like self.feature->... On the other hand, Constraints seem to be intended to be interpreted at the "user objects" meta level. The spec says: "An instance of a user-level model element must satisfy all of the constraints on its model element for the model to be well-formed." The word "self" appears to refer to some prototypical instance of the element. This makes sense for classifiers and some other things, such as associations, that clearly have instances. The examples of using OCL to write constraints on classes that appear in the Warmer & Kleppe book are clearly all like that. But I can attach a constraint to anything, and I don't understand what it means to attach a constraint to something that doesn't have instances, such as a package. To what does "self" then refer? Is it assumed to revert to the "model" meta level? However, that isn't my main concern. I understand UML stereotypes to be a mechanism for creating new, lightweight, kinds of model elements; a way of extending the "metamodel" meta level. I note that when I create a stereotype I am permitted to attach to it a set of constraints with the rule that when I apply the stereotype "Any constraints on the stereotype are implicitly attached to the model element." So if I create a new stereotype for Class I can define some constraints that must hold when I tag a class with that stereotype. But at what meta level are these constraints applied? It seems most useful if they apply at the "model" meta level, because then I can use them to define additional well-formedness rules. Indeed, this seems to be the way it works, because there are examples in the spec of additional well-formedness rules for some of the pre-defined stereotypes, such as ImplementationClass. Furthermore, it doesn't make sense that they should be applied at the "user objects" meta level because they can't possibly refer to specific features of the base type, since these won't be known when the stereotype is defined. But now we have an inconsistency: constraints directly attached to a Class operate at the "user objects" level, while constraints a Class gets from its stereotype operate at the "model" level. Is this how it is supposed to work? The situation is further complicated by the existence of two sets of constraints for every stereotype: one set by virtue of inheriting the association to Constraint from ModelElement, the other explicitly through the association called stereotypeConstraint. The spec seems to be silent on the use of these two sets. Can anyone explain the difference between them? Finally, can I just say that I'm interested not in how it *should* work, or how the *spec* should have been written, but in how I should interpret the spec *as it is*. Thanks, --John ========================================================================= John Daniels Syntropy Limited 2 Stambourne Way, West Wickham Kent BR4 9NF, UK Tel/fax: +44 (0)20 8777 6007


Date view Thread view Subject view Author view