How UML constrains subsetted properties

Classes are by far the most commonly encountered UML modeling element. As most users of the language have heard hundreds of times, classes do not exist in isolation for any given object system. Classes are often related to other classes by an association element. At each end of an association is a Property element. These property elements are generally not modeled directly but exist in the UML meta-model. In the context of a class associated with another class, these Property elements correlate to attributes of the two classes. These properties can be subsets of other properties and classes. In the UML model, this would be specified by applying the subsets tagged-value along with the context for the value. This values both modelers and software tools a better clue about how the design is organized. The UML specifies constraints that must be satisfied for a Property subset to be considered valid.

The following is an illustration of what takes place when the constraints of a subsetted property are validated.



First, the subsetting property and the subsetting context are both checked for emptiness. If so, the subset is not valid. Next, the validation will iterate through each subsetting context element and each subsetting property element. It is in this iteration that the validation process will ensure that the elements of both sets conform with one another.

How Gaphor Checks Association Ends.

With the Unified Modeling Language, comes a well defined meta model. It is this meta model that defines the semantics of the modeling elements available within the UML. An important feature of this meta model is consistency enforcement. The semantic rules defined in the UML meta model not only supply the UML modeling element but also govern how those elements may be used in relation to one another. If these rules, specified by the meta model could be verified for any given UML model, it could provide a means of ensuring a consistent model. As an example UML element that has the potential to be validated for consistency, consider the two ends of an association. One end could be a subset of the opposite end. There are a couple ways that this arrangement could go wrong. There could be missing names or there could multiplicity inconsistencies. The Gaphor UML modeling tool provides a checkmetamodel plugin that is capable of validating the association ends, as well as other potential meta model issues. This plugin can be viewed by selecting "Tools", "Check UML model". Illustrated below is the dialog that will be displayed. Only errors will be displayed here so if there is no content, the current Gaphor UML model is consistent with the Gaphor UML meta model.



When the checkmetamodel plugin validates the UML model, there are three functions involved. These functions are check_associations(), check_association_ends(), and check_association_end_subsets(). The check_association_end_subsets() function is important when validating association ends. It is the only validation that actually takes place on associations. The check_associations() and check_association_ends() functions exist for infrastructure purposes. If new functionality were to be added to Gaphor association or Gaphor association end checking, it would be placed in one of these functions. As the same suggests, the check_association_end_subsets() function will make sure that any association ends that are subsets of the opposite association end are consistent with one another. There are two basic tests to make this happen. First, the plugin will make sure that a given association end that is a subset of the opposite association end, contains names that actually exist in the opposite set. There can't be a subset property which contains elements that do not exist in the referenced set. Next, all multiplicity upper bounds in the subset need to be consistent with the upper bounds of the opposite set. This will ensure a multiplicity consistency amongst association end subsets.

With Gaphor, these meta model consistency checks are especially important because the meta model is loaded into Gaphor as any other UML model would be. If the core Gaphor UML meta model fails, there isn't much hope for any models created by users. The checkmetamodel plugin also offers potential for adding additional checking functionality.

The UML meta model.

The UML meta model is an enormous tomb of a specification. All this is required to define a set of rules for what can and cannot be drawn in a UML diagram? Well, it does much more than that. There are semantics defined for every single element in the language. These semantics are by no means simplistic. Which would make sense my most people cringe at the thought of the UML meta model, or even the UML itself.

But these detailed explanations need not be daunting and boring. One approach I take is to learn one aspect of the UML form an end user perspective. This means reading documentation (not the UML specification) and creating sample diagrams in this one area; say, for example, activity diagrams. Once you have mastered the end user perspective, you can then dive into the specification. After I did this, the specification revealed several insights to my sample models. Not only that, but also made me think twice about code I had written, or code I had been planning to write.

Learning the entire UML specification upfront with no real high level modeling experience is an unrealistic goal. Rather, learn some general UML concepts and use the specification to solidify ideas and to enlighten, rather than frustrate.