In UML the term MultiObject is used to denote set of instances -- a collection.



Such as

                                          _________________
        __________                        :______________ : 
       :         : 1 *:st := getSubtotal():             : :
-------:  :Sale  :------------------------:SalesLineItem:_:
       :_________:                       *:_____________:

SaleLineItem box - is a double box whic indicates multi object(collection)



Example: a list object containing many SalesLineItem objects



* -- is multipilicty marker which indicates message is beig sent to each element of the collection rathen than being repeatedly sent to the collection object itself



I hope this helps.

In my opinion, like standard Objects, or better interfaces (Map, Set, List).

I think, it's always better to specify the type of elements that should be present in the collection, to make casting easier.

This is actually easy and straight forward, yet it does lead to another
other interesting issue.

Like any "type," collections are captured in operation signatures
(and hence as messages). For example:

+-----+                                 +-----+
|  A  |                                 |  B  |
+-----+                                 +-----+
   |   getItems() : Collection             |
   |-------------------------------------->|
   |                                       |
   |  appendItems( others : Collection )   |
   |-------------------------------------->|
   |                                       |
   |                                       |
   |                                       |

Collections are just another type of class.
Since there is no special way to visually indicate a return
type in these diagrams, having collections returned is
no different.

There is an alternate way to represent object instances in
interaction diagram with multiplicities greater than one.
Putting an astrisk in the upper right hand corner of the object
instance icon indicates multiple instances (a suitable icon might
also be subistutied. If you choose this representation, however
it is not clear what the container class is, and what messages
are allowed at the design level. (most likely this is the root of
your question).

+---------------+               +--------------+
|               |               |            * |
|  : LineItems  |---------------|  : LineItem  |
+---------------+               +--------------+

Personally I will only use this type of representation when
building analysis level models, and where my point is mostly to
get the concepts across as opposed to creating an implementable
design.

This does lead to another other interesing question. How
do you model a specific collection type in a structural
diagram (i.e. class diagram)?

Lets suppose that the class B is a container of items
of class C. The class B uses a Vector to contain the instances
of C. In the class diagram you would model this with a type
associated with the role name that B uses reference the C
instances. The role type appears after the role name separated
by a colon.

+-----+        items : Vector   +-----+
|  B  |------------------------>|  C  |
+-----+                  0..n   +-----+