So far we have shown how classes can enter into associations with other classes. However, it is allowable — and often essential — to model a class as being associated with itself. For example, suppose we are designing a system for managing contracts, and we want to show that a contract can consist of a number of small sub-contracts. Sub-contracts have exactly the same properties as contracts. We could represent this as follows:

This example says that one object of class “Contract” consists of zero or more objects of class “Contract”. To clarify the relationship, it is customary to use role names. Where an association name describes the overall nature of the association, a role name is attached to the end of an association, and describes the role played by the object at that end. If the example above, one object plays the role of “main contract” while zero or more others play the role of “sub-contract”. Because role names are so important in these cases, some CASE tools will report an error if they are omitted.