I confess this is my modeling pet peeve. If you’ve worked with me in the past, you have probably suffered my strong complaints if I ever saw an arrow in an association end.
An arrow signals that the association is navigable in that specific direction. Let’s see an example. In the following figure, we’re saying that Employee and Department are related via an association and that this association is navigable in the Employee-to-Department direction and not in the Department-to-Employee one. An association with neither end marked by navigability arrows means that the association is navigable in both directions.
The definition of Navigability in the UML standard is expressed as:
Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient – UML standard
Note the emphasis on navigability as a technical detail. And this is exactly why I claim that domain models / conceptual schemas (i.e. models that aim to represent the general knowledge the system needs to know) should NOT include any navigability information. Navigability is a not conceptual primitive but a design one used to express a design decision (in this case, how the access from employee objects to department objects, and vice-versa, will be implemented).
As Antoni Olivé (the king of conceptual modeling 🙂 ) puts it: Conceptually, relationship types (i.e. associations) are navigable in all directions. It’s a different discussion whether later, for efficiency reasons, you decide to only implement one navigability direction depending on a number of factors, such as the underlying storage technology, most frequent queries to the system, number of objects of each type,…At that point, yes, please, add all the arrows you want. Just not before. Or at least don’t show them to me!
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Thanks, Jordi, for just coming out and saying it…directional associations are just, well, wrong-headed. I’m new(ish) to your newsletter so I hadn’t seen your earlier rants but I’m glad to be in such good company. Bidirectional Associations Forever!
Welcome to the club of the good modelers 🙂
Hi Jordi,
Nice trick about association direction!
By the way, speaking of conceptual modeling, cardinality should also be removed: either obvious, or too general, or not always true. My opinion: better not to show it.
Also how true: beware of UML as it’s not intended to model pure concepts.
Hi Vincent
While I fully agree with omitting navigation direction from conceptual models, I oppose your proposal to also omit cardinality. I see this a unnecessarily dumbing down conceptual models. Cardinality matters a lot to the domain and should be determined at this level — it‘s not just a design detail. Example: it should matter to you that you are the only one to whom a given mobile number is assigned. It doesn’t just make the tech folk‘s live easier or save resources.
Hi Oliver,
Taking the example of a mobile number: 1) it may be mine, 2) it maybe mine shared with my wife on her own account because she doesn’t want to give hers (real life here!), 3) it may be mine that I share with my daughter who is too young to have her own number but also have an account (associated with my email also).
So even if it matches more than 80% of cases, a phone number should not be taken as a unique identifier of a person. Lot of other real life examples if you think of it: a car doesn’t generally have 4 wheels as there is at least a 5th one for emergency etc.
I don’t even talk about implementation details.
Hi Vincent
Thank you for this interesting set of examples which lead me straight to why I think cardinalities are essential.
One of the key goals of a conceptual model is clarity of concept. By covering three different conceptual cases (as per your examples) with one and the same conceptual model, you weaken its effectiveness. If your telephony company wants to do a contract with you (and with you only) as the owner of a given mobile number and as the responsible for the contents that are downloaded to or provided from your end of the connection, then the cardinality must be 1. The model then expresses THIS concept and the mobile mobile number SHOULD be a unique identifier.
If, on the other hand, your conceptual model should convey the fact that more than one person may be reachable through this mobile number, then the cardinality should be greater than 1. (But then: should it be “n”? Or just 2?). This is now a different concept. I believe those two examples should be covered by two separate conceptual relationships between the mobile number and the people “linked” to it. Needless to say that the cardinalities of those two relations are different.
Don’t get me wrong: of course you *can* cover mulitple usage scenarios with one and the same conceptual model but you invariably give up clarity of concept.
You’re right: these examples are different kinds of relationship between person and mobile number.
Let me add another: my father died some years ago and I had to terminated one if his mobile contract with a phone company. It ended up with me telling his birth date to the guy on the other side of my phone call as if I was my father so the company could manage I want to close my contract. What a poor user experience! I also remember the times, some decades ago, when having two phones was like be two different persons: even worse!
So desirable user experience, and real cases in real life, tell that there is a relation between person and mobile number which may be related to many variants. And probably more to come with intensive usage.
The question is: are these variants at “concept” level or at a more detailed level? I think that at concept level we should keep some high level posture. And that such models should aim giving a vision more than specification of a way to implement the vision.
But I agree with you: all is about what the model is made for.
A similar issue I have with cardinality is when I talk about recursive associations, for instance a hasParent association. Technically speaking, a person has always at least a (biological) parent but in our system this won’t be the case as at some point we will have people for which we won’t be storing the parent in our database or we would end up with an infinite database
Hi Jordi
From a conceptual point of view, in your example, hasParent should 2 — especially biologically speaking. And it should be called just *parents*. Or better, conceptually everyone has a *mother* and a *father*, thus again two relations, however, one or both may be truly unknown, even in the age of gene databases.
And even better: implementing this faithfully (a.k.a. domain-driven design) will remove your infinite-database dilemma.