If you want to disclose the details of the implementation, you could go for something as developed as:

The key of this design is to disclose that vector is a templated class, and that it is instantiated by binding the template parameter T
to the class Foo
. To put Foo
in the picture, you could either just show it at the instantiation level, but I preferred to show some kind of relation with T
. I used here a realization, since T
implicitly defines in the C++ semantic an interface for the template parameter, and Foo
is expected to implement this (implicit) interface. I also used composition, since C++ vectors are by value, and the vector owns the lifecycle of its elements.
Unfortunately, this makes the design look more complex than it is in reality. Moreover it doesn't show the full reality of a std::vector
that has a second template parameter Allocator
. Last but not least, to be fully transparent, you should use a qualified composition, with a std::vector::size_type
qualifier (to document that there is an indexed access possible). You'd end-up with a very complex diagram.
I therefore recommend to consider a simplified approach. Since everybody knows what a std::vector
is, you may use the more compact (and still legit) form of a direct binding, assuming that the template details are defined elsewhere:

This is very close to your implementation and stays very readable. However, you could simplify one step further: is vector
a fundamental design choice? Or is it just one practical way to implement a one-to-many composition? If the real intent is just that Demo
may be composed of several Foo
you could be as simple as:

Here you would let to the implementer to chose the best way to implement the composition instead of graving the implementation choice in the marble of your model.