9.1 The Collection Types

In object-oriented systems, the manipulation of collections (of objects) is very common. Because one-to-one associations are rare, most associations define a relationship between one object and a collection of other objects. To enable you to manipulate these collections, OCL predefines a number of types for dealing with collections, sets, and so on.

Within OCL, there are five collection types. Four of them ”the Set, OrderedSet, Bag , and Sequence types ”are concrete types and can be used in expressions. The fifth, the Collection type, is the abstract supertype of the other four and is used to define the operations common to all collection types. In this book, we refer to Set, OrderedSet, Bag, and Sequence as the collection types.

The four concrete collection types are defined as follows :

• A Set is a collection that contains instances of a valid OCL type. A set does not contain duplicate elements; any instance can be present only once. Elements in a set are not ordered.

• An OrderedSet is a set whose elements are ordered.

• A Bag is a collection that may contain duplicate elements; that is, the same instance may occur in a bag more than once. A bag is typically the result of combining navigations. This concept is introduced in Section 2.4.2 and explained further in Section 8.2. Elements in a bag are not ordered.

• A Sequence is a bag whose elements are ordered.

Note that a value of type Sequence or OrderedSet is ordered and not sorted. Each element has a sequence number, like array elements in programming languages. This does not mean that the element at a certain sequence number is in any senseless than or greater than the element before it. (See Section 9.3.3.)

In the R&L model, the following navigations in the context of LoyaltyProgram result in a collection:

 self.participants           -- Set(Customer) self.levels                 -- OrderedSet(ServiceLevel) 

9.1.1 Collection Constants

Constant sets, ordered sets, sequences, and bags can be specified by enumerating their elements. Curly brackets should surround the elements of the collection, and the elements are separated by commas. The type of the collection is written before the curly brackets, as shown in the following examples:

 Set { 1 , 2 , 5 , 88 } Set { 'apple' , 'orange', 'strawberry' } OrderedSet { 'apple' , 'orange', 'strawberry', 'pear' } Sequence { 1, 3, 45, 2, 3 } Sequence { 'ape', 'nut' } Bag {1 , 3 , 4, 3, 5 } 

Because of the usefulness of a sequence of consecutive integers, there is a special way to specify them. The elements inside the curly brackets can be replaced by an interval specification, which consists of two expressions of type Integer separated by two dots (..). This specifies a sequence of all integers between the values of the first and second integer expression, including the values of both expressions themselves :

 Sequence{ 1..(6 + 4) } Sequence{ 1..10 } -- are both identical to Sequence{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 

9.1.2 Collection Type Expressions

Occasionally, one needs to explicitly state the type of a model element; for instance, when specifying an initial value. When the type of an element is a collection, this can be indicated using the words Set, OrderedSet, Bag , or Sequence , and the type of the elements of the collection between rounded brackets, as shown in the following examples:

 Set(Customer) Sequence(Set(ProgramPartners)) OrderedSet(ServiceLevel) Bag(Burning) 

9.1.3 Collections Operations

Numerous standard operations are defined on the collection types that manipulate collections in various ways. These operations are explained in the following sections.

All operations on collections are denoted in OCL expressions using an arrow; the operation following the arrow is applied to the collection before the arrow. This practice makes it possible for the user to define operations in the model that have the same names as the standard operations. The user-defined operation is taken when it follows a dot; the standard operation is taken when it follows an arrow.

All collection types are defined as value types; that is, the value of an instance cannot be changed. Therefore, collection operations do not change a collection, but they may result in a new collection.

The following invariant, from the R&L model, uses the standard operation size , and states that the number of participants in a loyalty program must be less than 10,000:

  context  LoyaltyProgram  inv  : self.participants->size() < 10000 

9.1.4 Treating Instances as Collections

Because the OCL syntax for applying collection operations is different from that for user-defined type operations, you can use a single instance as a collection. This collection is considered to be a set with the instance as the only element. For example, in the R&L model from Figure 2-1, the following constraint results in the value of the user-defined operation isEmpty() of an instance of LoyaltyAccount:

  context  Membership  inv  : account.isEmpty() 

Conversely, the following constraint results in the value of the Set operation isEmpty , where the account is used as a collection:

  context  Membership  inv  : account->isEmpty() 

This expression evaluates to true if the link from the instance of Membership to an instance of LoyaltyAccount is empty; that is, the Membership has no attached LoyaltyAccount .

9.1.5 Collections of Collections

A special feature of OCL collections is that in most cases, collections are automatically flattened ; that is, a collection does not contain collections but only simple objects. An example is given by the following two collections. The first is a collection of collections, the second is the flattened version of the first:

 Set { Set { 1, 2 }, Set { 3, 4 }, Set { 5, 6 } } Set { 1, 2, 3, 4, 5, 6 } 

When a collection is inserted into another collection, the resulting collection is automatically flattened; the elements of the inserted collection are considered direct elements of the resulting collection. The reason for this approach is that collections of collections (and even deeper nested collections) are conceptually difficult to grasp, and are not often used in practice.

For those who do want to use nested collections, there is a way to maintain the layered structure when inserting a collection into a collection. The collectNested operation leaves the structure intact (see Sections 9.3.10 to 9.3.12 for more information). The following sections describe the collection operations.