Understanding Containment vs. Composition.

We naturally tend to think of containers in terms of composition, like a car being a container for wheels and chassis and engine… But that’s not all that containers can be used for.  Good modelers need to distinguish the structure of the product being modeled from the structure of the information about the product being modeled.  UML/SysML Packages are generic containers, and we use these containers to organize the information in the model.  An object can be contained in one and only one container, but can be used (or composed) just about anywhere.   In fact, using Packages to represent the physical structure of the product being modeled is a very bad idea, from an object-oriented perspective!

Consider a Russian doll… a larger doll that has a slightly smaller doll inside it, identical except for its size.  The smaller doll has an even smaller one inside it, etcetera.   The “inside-ness” relationship of one doll to another should be considered composition, just as a car is composed of chassis, driveline, and engine.  Now, this could be modeled as a series of packages, each containing a “doll” block and another package, which in turn contains another “doll” block and another package, etc.  One would then have to set up a separate composition relationship between each of the “doll” blocks on a bdd.  On the other hand, to emphasize the “sameness” of the dolls, the doll “system” could be modeled as a single “doll” block, with a composition relationship to itself.  The “doll” Block would have a “size” parameter which would be recursively re-specified by the whole-part composition relationship.  Clearly, this is a much more compact approach.  Now if all the dolls need to look like Boris Yeltzin, the modeler only has to change one block!

A very compelling feature of SysML models is that they can simultaneously support multiple hierarchies. The product structure hierarchy, the product function hierarchy and the model packaging structure may be completely different within a single model!  This is part of the power of Object Oriented thinking.

Composition vs. Containment is a common issue for even experienced modelers. The containment relationship is depicted using a crosshair notation, but it is seldom seen on diagrams.  More commonly, containment is shown by graphical nesting.  Here’s an example of both notations:


Containment is the basis for package structure in the model browser.  Blocks and Requirements can also have containment relationships, but modelers are advised to exercise caution when using them.  It is wise to use only Packages when generic containers are needed.  Containment carries with it the concept of “ownership”, and it plays a role in change management.  Changing a model element generally requires write access to its container, i.e. The package that contains it.  Containment also determines where the model element “lives” in the model, or its Namespace.  UML/SysML requires that a model element name be unique, but only within its namespace.  Any element within the model can thus be uniquely identified by its namespace (path) and its name.  A Qualified Namespace is a specific way of identifying the namespace within the model, and is written with double colons thus: ACME Surveillance Systems Inc::Products::Cameras::Behavior, referring specifically to the Behavior Package in the diagram above. Every model element in the Behavior package will need to have a unique name.

It is this containment relationship is the basis for the Package hierarchy that every modeling tool depicts in the browser window.  Once again, this is NOT composition… It doesn’t represent “inside-ness” or assembly structure of the product we are modeling, but rather a filing structure for all of the related product information.  We should be free to reorganize the filing structure of this information without having to modify how the product is assembled!


Here are some alternative approaches to package/containment structures.  These are really just alternative “filing systems” for the model information.  Single user models benefit from a very simple package structure, as seen on the left.  When the model gets more complex, with multiple levels of abstraction, the package structure may morph more towards the middle.  As more modelers get involved with the same model, the issue of containment/ownership will become increasingly important, and the structure may eventually migrate more toward the right.


Composition, on the other hand is a way of representing a whole/part relationship.  It is shown as a black diamond relationship on a bdd.  This was covered earlier in the definition and use topic.  Composition role names on the bdd correspond to part/action names on the ibd/act.  The following are some groundrules have proven useful for composition:

Groundrules for Product Structural hierarchy

  • Treat every block as reusable
  • Put them in a package structure where modelers can find them… based on what they are, not how they are used
  • Build ibd’s from blocks in the browser (drag & drop).  Autorender the bdds after the ibds have been built.
  • Untyped parts are poor modeling form
  • Put FlowSpecifications or InterfaceBlocks in the hierarchy too

Groundrules for Functional hierarchy

  • Treat every activity as reusable
  • Build act’s (activity diagrams) from activities in the browser.  Then build the bdds.  Most tools won’t auto-render bdds, so this will be a little more work.
  • Maintain a Data/Info Model for typing items and messages
  • Enforce all data types in one convenient containment hierarchy/package structure.  This is your data dictionary.

Leave a Reply

Your email address will not be published. Required fields are marked *