Opposing views on the UML {xor} constraint

During my last lecture week at Oxford, a debate arose over the interpretation of the xor constraint within UML class diagrams. We were divided over two differing opinions, but were unable to reach consensus on which was correct. I’ll put forward the two views and give my opinion on the matter, but would be interested to hear if anyone knows the correct way to interpret this constraint.

This is the class diagram I’ll use as a reference for the opinions explained below. I’ve deliberately used simple names for the classes to avoid misinterpretation, as I’ve found that people often get distracted by the “real world” application of the diagram rather than the semantics of the notation – which is what we’re really trying to understand here.


Opinion A: the xor constraint applies to the association
In this case, we say that the xor constraint applies to the association itself, which means that the multiplicity of the association remains in effect. In other words, one of the following must be true (but not both):

  • EITHER: An object of type A may be associated to zero or more objects of type B
  • OR: An object of type A may be associated to zero or more objects to type C

Opinion B: the xor constraint applies to the link (the association instance)
In this case, we say that the xor constraint applies to the link between the objects, which means that the multiplicity specified on the association is effectively ignored. Regardless of the multiplicity specified on the association, the xor constraint requires that one of the following must be true (but not both):

  • EITHER: An object of type A must be associated to exactly one object of type B
  • OR: An object of type A must be associated to exactly one object of type C

According to UML 2 Toolkit (OMG Press), page 108:

The xor constraint specifies that objects of a class may participate in, at most, one of the associations at a time.

From what I can tell, this appears to support Opinion A above, which is also what I believe. This quote appears to be further reinforced on page 303.

It seems unnecessarily restrictive to apply the xor constraint to the links, as this substantially limits the usefulness of the constraint. In addition, Opinion A allows for the modelling of Opinion B by using the xor constraint with multiplicities of 1. So, given that Opinion A may be used to model a much wider range of possibilities, I don’t see how Opinion B would be very useful. Opinion B also opens the model to miscommunication, as the multiplicities would no longer make sense and should be disallowed when the association is used with the xor constraint.

That said, this is simply my opinion based on what I feel is logical. I don’t actually know for a fact which is correct. I completely understand why holders of Opinion B see it their way – I just don’t see how such strict semantics would be useful in this case.

Does anyone else have a different opinion on this? Or perhaps know the correct answer?

Advertisements

6 Comments on “Opposing views on the UML {xor} constraint”

  1. Tony Yunnie says:

    Hi Stuart, a very interesting question! Like you my immediate response was option A. After reading you blog a little of me could see why some people might support option B.

    I went to look for a definitive answer. I thought that would be easy – was I wrong or what! I went through half a dozen UML books I have and through a number OF BOOKS online. I found examples identical to the example you used but none gave a detailed explanation of what it meant or else they used examples that would always have a one to one relationship which didn’t clarify between options A and B.

    I then went to the UML Spec at the OMG – no joy. Thereafter I tried to access the Booch, et al book; ‘The Unified Modeling Language Reference Manual’ on Google books but it’s not available.

    The UML gives users the option of using free format constraints or using the OCL – Object Constraint Language. I tried the OCL Spec on the OMG website. OCL defines XOR as:
    xor (b : Boolean) : Boolean True if either self or b is true, but not both. post: (self or b) and not (self = b)
    Not wildly useful!

    So, in short I couldn’t find a clear answer, however a number of books seemed to suggest that an object of ‘Type A’ (using your example), can be associated with one or more object of Type B or of Type C.
    The book, ‘Instant UML’ by Pierre-Alain Muller on page 80, states the following, ‘The constraint {exclusive or} indicates that, for a given object (a Type A object in your example) only a single association among a group of associations is valid. No mention that it can only be associated with a single object from the particular ‘single association’.

    The book, ‘Developing Software with UML’ by Bernd Oestereich has a diagram similar to yours with an ‘{or} constraint and then uses OCL text constraints to explain the diagram. The diagram contains three classes, BusinessPartner, Enterprise and PrivatePerson with the constraint across the last two. The constraint reads as follows:
    BusinessPartner
    Self.PrivatePerson notEmpty implies
    Self.Enterprise–>isEmpty
    Self.PrivatePerson isEmpty implies
    Self.Enterprise–>notEmpty

    Once again there is no suggestion that the ‘notEmpty’ set is restricted to a single object. I found a couple of books on Google Books that had similar examples.

    The book, ‘UML Toolkit’ by Eriksson and Penker was the most clear, it read as follows on page 233, ‘A contract (an object of Type A in your example) can be owned by one or many Persons or by one or many Companies’ (objects of Types B or C in your example – I added the emphasis on ‘or’).

    If we relook at the OCL definition of XOR it would seem to agree with the books mentioned above. ‘;True if either self or b is true, but not both. post: (self or b) and not (self = b)’. There is no constraint on the number of self or b.

    The one downside of the UML constraint notation is that it is not clear to which end of the association the constraint applies. There are other notations, such as ORM, that address this weakness.

    I’m comfortable that your Option A is correct and will continue explaining the XOR constraint this way when I do any modelling or teach OO Design.

    Tony Yunnie.

    • Tony… that is an exceptionally well researched answer! I’m glad I wasn’t the only one that struggled to find something definitive. It does seem that there is more support for Opinion A than for Opinion B.

      It sounds like the students of your OO Design course are quite fortunate to have a lecturer that’s passionate enough about the subject to research it this well!

  2. […] the XOR constraint. Thinking this would make a nice UML Tip nugget, I tried to dig deeper into this obscure little creature. Lets have a look at four diagrams […]

  3. Gordy says:

    hi Stuart,

    Thanks for the post-I was just wondering that myself. I’m guessing the discussion arose in OOD? (I’m a fellow Oxford softeng student).

    Maybe bump into you on a course.

    Cheers

    Gordy

    • Hi Gordy

      Yes, that’s exactly where it came up. If we’re on the same course sometime, be sure to come say hi. My upcoming courses are around concurrency – both CDS (in November) & MCH (in March).

      Cheers