I found a definition for association in UML as below. An "association" in UML is defined as a kind of relationship between classes,which represents
The subject of Semantics is sense. If one thing has something that is connected by sense to another thing, it is the semantic relationship. That definition is terribly wide. And, applied to UML relationship, incorrect. It is incorrect for two reasons.
First, UML covers not only Class-Instance languages, such as Java or C++, but pure object languages with heredity created by Prototypes as well. And this second variant is not covered by your definition at all.
Second, in UML you can have class A connected to class B through some complex AssociationClass, that is shown by a box with arrows, not arrow only. And it still will be named an association and it IS a semantic relationship, too. But a the semantic relationship goes from A to B through two classes, it is still a semantic relationship, but it is not an association in UML.
If you are trying to be deep in subject, better read the UML documentation: "An Association classifies a set of tuples representing links between typed instances." (UML 2.5, pharagraph 11.5.1). Notice: ANY link between two instances can be shown as an association. Maybe the book you are reading is wholely not so bad, but in the very place that you have cited the author merely tries to use pretty words not understanding their meaning and not even trying to be understandable to readers and to be CORRECT.
An association represents a semantic relationship according to the UML specs.
A semantic relationship is a relationship about meanings that has itself a meaning.
This term is borrowed to linguistics and related disciplines, where words are mapped to their meaning, and the relation of words is analysed in view of this mapping. But before getting to abstract, a picture is worth 1000 words:
So, applying this elements of UML (modelling language) instead of English words (natural language): if you'd have the classes Car
and Driver
, you CAN model the semantic relationship as an association between the two classes.
There can also be a semantic relationship between some Driver
and their Spouse
meaning that you CAN also model such an association. But this is not mandatory. Fortunately! because otherwise by transitivity you'd quickly have the rest of the world in your model ;-)
If it is relevant for your application domain you may of course show this association as well (e.g. you're working in an insurance company where the prices depends on how many family members have a driving license). And you may even want to make explicit the indirect relation of Spouse
and Car
, by using the notation for derived association with the leading /.
Not all relationships are of semantic nature. You can for example have dependencies, which can express a technical relationship. For example, if you use the factory design pattern, a DriverFactory
will «create»
the Driver
. This has on its own no meaning: It's just a relationship in the domain of the representations. On the other side, you may want to give it a meaning and let the factory keep trace of the drivers created, even if it makes only sense in the meaning of your abstract design and not in the real world. You then CAN make it an association if it helps.
Ultimately, you have a some room for interpretation when you want to see an association and when not. Use it sparsely however, if you want your model to remain helpful.
For the records, I can only draw rectangles, and I'm grateful to this public domain contributor for the nice car and driver and to 18f for its advice on inclusive communication.