You've heard me say several times in q&a/discussion sessions that in a UML class diagram you should not duplicate information between association ends and attributes. E.g., if class Order is associated with class Customer (the association being navigable from Order to Customer, with multiplicity 1 at the Customer end, and using the default rolename, i.e. the lower-cased version of the classname, in this case customer, at the Customer end, for simplicity), that association expresses that relationship between Order and Customer. You do not need to also show an attribute customer : Customer inside the rectangle of class Order. Indeed you should not: if you do, and then you use a code generator on your class diagram, you are quite likely to end up with duplication, e.g. a generated Java class Order would be quite likely to have two, identical, Java attributes of type Customer, potentially leading to bugs and confusion.
For developing UML class diagrams the following convention works well. If some property of a class has a type which is a class in the class diagram, show that using an association. If it has a type which is not a class in the class diagram - it is a basic type, or a class from a class library, or even a class from a different part of the system, not represented in this class diagram - then show it using an attribute. For example, if our class Order has an identifier id of type String, we will show that in an attribute compartment of Order, in the usual way, id : String.
But in what sense are the attribute id and the association end customer the same kind of thing, from the point of view of Order? We've touched on one important sense in which they are the same - they correspond to the same kind of implementing code. In both cases, we will want the eventual Java class Order to have a Java attribute of the appropriate type - String for id, Customer for customer. Strictly speaking, we want this provided the class Order owns the association end at the Customer end of the association - see notes on part C of the 2024 lab assessment; but the association being navigable from Order to Customer usually goes along with that.
In the UML standard, any Classifier (for example, any Class, since in UML a Class is a Classifier) may have Propertys (as shown in Fig 9.1). More specifically - see Fig 9.10 - any Class may have Propertys, and these include both the attributes of the class, and any association ends that the class owns (this usually means, the far end of any navigable association starting at the class). That is, in terms of the UML metamodel, attributes and association ends are the same thing - they're both Propertys, and not even different kinds of Propertys. It's better to think about association ends, and attributes, in class diagrams, as being two different ways to notate the same relationship between a class and its properties; we have conventions about when to use which notation, as mentioned above, but that is "just a matter of concrete syntax".
Be sure not to confuse your metalevels here, especially if you go reading the UML standard about this! Examples usually help to keep your head straight. In our example, using OCL to express the situation, we have
Order.ownedAttribute -> includes(customer) and Order.ownedAttribute -> includes(id)Note that it wouldn't make sense to write Order.customer, because here Order is an identifier of type Class and classes don't have customers! (Order has property customer, of type Customer; Class has property ownedAttribute...which just to be really confusing is a property of type Property...) We could of course write something like
context Order inv: self.customer -> size() = 1if we want to express that any valid object of class Order has exactly one object linked to it by property customer. Here Order functions as a type for the identifier self.