Drawing Smart Pointers in UML

Question

Is there a generally accepted way of depicting objects held by a shared pointer (boost::shared_ptr or std::shared_ptr) in a UML class diagram? In particular, should one use and empty or full diamond like aggregation or composition?

Answer 1

I am not aware of an overall consensus on how to model smart pointers as relations.

A black diamond means controlling life time, a white diamond means not controlling life time, so you could agree locally to use black diamonds for unique_ptr, all black diamonds for shared_ptr and white diamond for weak_ptr.

If you really want to model smart_ptr, I would suggest adding a property class to the relation:

0
|  /----------------\
+--+ shared pointer |
|  \----------------/
V

Answer 2

Your UML class model should be abstract and devoid of language idioms.

In practice you could create a stereotype of the relationship for each type of smart points which includes OCL constraints. I'm not familiar enough with the specific semantics of each sub type of smart pointer to give your details but the OCL Specification should help.

Answer 3

UML is meant for the design of a solution more than for specifying concrete implementations. This is why there is no one-to-one relation between most C++ language/library features and UML.

But UML is as agnostic on its use as on programming languages. So here some hints:

• A shared_ptr<T> means that several objects can point to a same instance of T, and that this instance is destroyed if no object points anymore to it. This corresponds in UML to the situation of a simple association, except that UML says nothing about garbage collection.

• The smart pointer guarantees efficient access at run time. You could therefore use a navigable association (open arrow head on the T side). A better option would be to use the dot-notation to show the ownership of the association end (a small dot on the T side, an owned end is alway navigable, so the open arrow head would then be redundant).

• Some people would claim that shared_ptr<T> implements shared aggregation and should be modeled with a hollow diamond at the opposite side to T. We can neither deny nor confirm such claims: UML 2.5.1 does not define any special semantic for shared aggregation. So it is not wrong to use it, but it remains ambiguous:

  Shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.

• Some people would suggest to annotate the association or the aggregation with a self-defined stereotype «shared_ptr». I would strongly advise against this extremely ambiguous practice: an association has two ends and the fact that shared_ptr is used at one end doesn't imply that it is also used in the opposite end (where it could be weak_ptr, unique_ptr, or even nothing at all)

• All of the above would apply indifferently to raw pointers and shared pointers. The only remaining way to differentiate the link in one direction only, would be to use a constraint for the property or role (at association end) as Martin suggests. These can fortunately be expressed in plain text and do not have to be valid OCL. So a {shared} or a {shared_ptr} as shortcut to mean that the property/association { must be implemented with a shared pointer } seems perfectly acceptable. But if is not a widely used practice.

Last but not least, even if a composite aggregation is not very likely, it cannot be completely excluded either: your code could use shared_ptr but nevertheless make sure by other means that the object is in reality used in one place only at any given time. This gives me the opportunity to come back to my initial statement: use UML to explain your design intent rather than to slavishly and painfully document some code ;-)