1

I wanted to ask if this is a valid class diagram: enter image description here

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). If the multiplicity on the vehicle side were 0..1 it would be OK. Is this logic correct?
Additionally, if this logic is correct, how would I model a situation where I have two types of cars, and each one has a certain amount of wheels? (without resorting to inheritance).
Thanks

Edit: I think the following is correct:
enter image description here
by not forcing the wheel to belong to 2 vehicles at the same time. A {nand} might be helpful, but maybe it isn't needed because it is implicitly implied by the composition relations.

  • Are Truck and SportCar really two different entities? Are not they both Vehicles? What makes'em different? The number of wheels (attributes)? The behaviours (functions)? Are you trying to model objects following ERM semantics and premises? (something you should not) – Laiv Feb 28 at 13:41
0

Yes, you're right. This diagram is logically incorrect.

Just seeing multiplicity might not be enough though. You should add a constraint in a form of dashed line joining the two relationships end described as {xor} if your wheel has to be a part of either of the cars or {nand} if it may also be completely detached.

  • kind of selfish of me to accept the answer that says I'm right but oh well. I added my 2 cents as an edit in the original post. Thanks – erap129 Mar 1 at 8:05
2

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 SportsCar and 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 SportsCar, and Truck, meaning that any Wheel can belong to a single SportsCar or 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 0..* to 4 (or 2 for bikes).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.