Direction of the association arrow in UML class diagrams

On this webpage which shows how to draw a class diagram, wh开发者_运维百科y is the arrow for association pointing from order to customer, and not from customer to order?

UML Tutorial - Class Diagrams

---

The arrows describe navigability.

• Navigable end is indicated by an open arrowhead on the end of an association
• Not navigable end is indicated with a small x on the end of an association
• No adornment on the end of an association means unspecified navigability

Taken from: http://www.uml-diagrams.org/association.html

---

Its because an order "has a" reference to a customer.

In a database, this would be a foreign key in the order-table, which stores the customer-id.

In code, you would store a reference to the associated customer object in an order object. So the order is pointing to the customer and not vice-versa.

---

This might help:

UML Class Diagrams: Guidelines: http://msdn.microsoft.com/en-us/library/dd409416%28VS.100%29.aspx

Properties of an Association

Is Navigable: If true for only one role, an arrow appears in the navigable direction. The association can be read in this direction. You can use this to indicate navigability of links and database relations in the software.

Properties of Associations in UML Class Diagrams: http://msdn.microsoft.com/en-us/library/dd323862%28VS.100%29.aspx

If one role is navigable and the other is not, an arrow appears (7) on the association in the navigable direction.

---

The arrows describe the ways you can navigate. So in this diagram you can go from order to customer. And for the other way: no arrow means NOT "not navigable", but "no comment". There is no definite right way to do it.

---

Association ends have a boolean navigability property in UML. In this case, the navigability in the direction order to customer is set to true while the navigation in the direction customer to order is set to false.

With this, the designer of the model expresses that orders now who is the customer associated with the order but customers do not have direct access to their orders.

If we look at the Java code for this model, navigability it is easier to understand. For this example, this navigability means that Order has an attribute of type Customer but Customer has no collection attribute to store his/her orders

---

Possibly because an order is associated with a customer? These kind of things can be seen as working either way, or sometimes both.

---

It's a dependency, which is a special weak type of association. It means that for an order to exist, there must exist a customer at some point in time. There may be some point in the lifecycle of "order" where this requirement is not enforced.