Containment and deletion

An old chestnut came up recently: the relationship between “containment” and “cascade delete”.  Somebody said that this is something inherent in real things and trotted out an old example: a Car has Wheels and when the Car is deleted, so are the Wheels.

The UML specification is full of this kind of nonsense.  The verb “delete” does not apply to cars, boats, wheels, or propellers. You can’t delete a car any more than you can conjugate it or grow it. The only thing that “delete” might act on is a software entity that models a car.  Such statements do not represent the semantics of real things; they represent modelling choices.  Only computer scientists are capable of thinking otherwise.

Comments (4)

  1. Bran Selic says:

    I agree that some of the examples in the UML spec are ill advised, and in particular the one cited by Steve. The mistake in this case is to use an example from the physical world to illustrate a concept that was intended to model phenomena from the world of executing software (which is what UML is intended to model). In their desire to explain the concept of structure succinctly, the authors (mistakenly) resorted to an example from everyday experience.

    However, it may have escaped many folks’ attention — including possibly Steve’s — that UML does have a provision for modeling containment which does not imply deletion semantics. Namely, the parts in a composite UML structured class model the slots of an actual instance. These slots can be filled in one of two ways: with entities (objects) that are created and owned by the container itself or by entities which are owned by other objects. In the latter case, we can talk about importing or, if you prefer, reference semantics. The distinguishing feature here is that the imported objects filling the slots will not be destroyed when the container is destroyed.

    Unfortunately, this type of distinction was not very well explained in the UML spec. In contrast, the SysML profile added a semantic refinement to distinguish which slots in a structured class are reference slots and which ones are “value” slots.

    Hope this helps.

  2. Hi Bran – good to hear from you!  Your comment refers to UML v2 of course.  I was not arguing that composition should not imply deletion semantics: after all you can always give the children a new parent before doing the deletion if you want.  Your explanation describes modelling choices made in UML and SysML, which we could debate from many perspectives, but NOT from the perspective of whether the real world is really like that.

  3. Bran Selic says:

    I think we are in agreement. UML was intended to model phenomena encountered in the specification and execution of software programs. Using UML to model anything else outside that domain is problematic at best. (This is why the example of the vehicle and the wheel was such a poor choice to illustrate the corresponding UML semantics.)

    The real world, of course, is a far more complex place and no single modeling language or combination of languages will do it justice. Of course, as builders of engineering systems, we still have to rely on models and modeling languages, which, by their very nature, reduce the complexity of the real world. This leads to an interesting question: how much scope should I put into a (modeling) language? If I seek a broad scope, my accuracy will suffer. On the other hand, if I narrow my scope down, the accuracy will improve, but the tradeoff is that I will likely need multiple languages to describe a practical engineering system, which then leads to numerous fragmentation and consistency problems.

    We don’t really have a general understanding of how to make this tradeoff in specific cases. All we know is that extremes at either end don’t work too well (although we cannot even tell when we have reached an extreme). it’s a fascinating topic that, in my opinion, needs some extensive research. Any PhD candidates out there?