Role name in association relationship - object

Question

From the UML bible, about role:
Role: A role name explains how an object participates in the relationship.
Each object needs to hold a reference to the associated object or objects. The reference is held in an attribute value within the object. When there is only one association then there is only one attribute holding a reference.
What does this sentence mean?
Can anyone please offer an example to explain it?

Answer 1

Roles:A role name explains how an object participates in the relationship.
You have two classes, Professor and Book and they are associated as in the following diagram:
The role gives a description of the association between Professor and Book. In this case Professor is the writer of the associated book.
Each object needs to hold a reference to the associated object or objects. The reference is held in an attribute value within the object.
For this I will use another example with a one to one multiplicity.
The diagram shows that Query builder has a Query (and vice versa). How is this association depicted in the code?
You have a class QueryBuilder that has an attribute of type Query named query. In code:
class QueryBuilder {
Query query;
}
And you have a class Query that has an attribute of type QueryBuilder named qbuilder
In code:
class Query {
QueryBuilder qbuilder;
}
The attribute (query for class QueryBuilder and qbuilder for class Query) is the reference to the associated object
When there is only one association then there is only one attribute holding a reference
In the previous example, there was one association, so we had one attribute (field) in the class to keep the reference of the associated object.
In the following diagram Acount has two associations with BookItem.
So, in class Account we will have two fields, one field for each association.
class Account {
BookItem[] borrowed;
BookItem[] reserved;
}
Note that these associations are one to many, so the fields that we have for the associations are arrays that can keep more than one BookItems.
Here you can find a good article where I borrowed most examples for this answer.
EDIT: Explanation of the association between Author and Book.
The line that connects Author and Book in the diagram is the visualization of the association. This is a bidirectional association, which means that Author one or more Book objects (the books written by the author) but also Book has one or more Author objects (because book can have more than one author). An association with multiplicity many (one or more) is usually implemented with a collection or an array. Class Author has a field that can be a collection or array of Book. The diagram does not provide the name of this fields.
The first diagram that associates Professor with Book provides also the names of these fields. Professor has a field with the name textbook to keep its Book objects. Book has a field with the name author to keep its Author objects. The type of these fields is not provided by the diagram. The field textbook could be declared as anything from the following:
Book[] textbook;
or
Set<Book> textbook;
or
List<Book> textbook;
or
Collection<Book> textbook;
Also the visibility of the fields is not provided (could be default, private or public).
There is a very good reason why this information is omitted from the class diagram: The author of the diagram did not consider it important for the message he wants to communicate with the diagram. We must not forget that UML diagrams are used to help understanding of a system by visualizing some of its aspects. Usually we create more than one diagrams in order to provide different perspectives of a system. In most cases the most important element of information is the relationship between the classes. So the implementation details are often omitted. Note there there are a lot of implementation details regarding the Book-Author association that are omitted from these diagrams. How to force that Book will always have at least one Author or how to ensure that if a Book has an Author then also the Author has this Book are among the details that are omitted.

Answer 2

As a programmer of UML to Code generators, I do not recommend association names as "implicite" role-names and therefore properties dependent to the additional reading direction (in this way "Professor--Book" is the better sample than "Account--BookItem" above). For bi-directional properties the association-name would help only in one direction (and is often easier explained in prosa way by Business Analysts).
DO always set the concrete role-name at each relevant Association-End to make it clear in what way the other end sees the relationship (and can manifest 1:1 in code)!
However the association-name may become the AssociationClass name of an n:n relationship where the reading direction would be in both ways the same. Like:
Bank[0..]--Contract(AssociationClass)--[0..]Person