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.
A RoleName refers to an SQL role. A role in a database is uniquely identified by its role name.
Roles:A role name explains how an object participates in the relationship. 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.
An association end names is a name that uniquely identifies one end of an association. It specifies a role of an object of a class which it plays in the association. An association end names is written next to the association line near the class that plays the role.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With