PingBack from http://www.artofbam.com/wordpress/?p=5739

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.

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?