Compartilhar via

Containment and deletion

  • Artigo

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

  • Anonymous
    October 06, 2007
    PingBack from http://www.artofbam.com/wordpress/?p=5739

  • Anonymous
    October 11, 2007
    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.

  • Anonymous
    October 11, 2007
    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.

  • Anonymous
    October 12, 2007
    The comment has been removed