This is a static structure diagram (class diagram), meaning it depicts static relationships between peaces of source code, not the state at runtime. The fact that both
Truck reference (depend on) the
Wheel class does not mean that they both contain the same instance(s) in the corresponding runtime object diagram. In fact, because the relationships is composition (filled diamond), by it's semantics they cannot contain the same instance (at least not observably - if the wheels are immutable, you can share them internally, and this will not be visible to client code; the important part is that they logically do not appear shared from the perspective of client code). The composition relationships also indicates that each vehicle "owns" the contained wheel instances and manages their lifetime (they exist and are destroyed together, or it appears to be that way to client code).
I tend to think not, because it forces a certain wheel to belong to two vehicles at the same time (because of the 1 multiplicity)
So, in light of the above, it does not - on the contrary. Also, I might be wrong, but I have a feeling that you are misinterpreting the multiplicity - here,
1 is the multiplicity of
Truck, meaning that any
Wheel can belong to a single
Truck, not the other way around. So the multiplicity of 1 on the right side prevents the wheels to be shared (between different instances of the same vehicle class, and the fact that it's composition prevents sharing between instances of different vehicle classes).
how would I model a situation where I have two types of cars, and each one has a certain amount of wheels?
Just set the wheel multiplicity on the left (next to
Wheel) to a fixed number. Currently, it reads "A
SportsCar can have 0 or more wheels.", and "A
Truck can have 0 or more wheels". Change
2 for bikes).