Class Diagram - Aggregating over a class that has physical presence or logical presence?

Question

In the below figure, a CD shop has CD cupboards, and inside it has shelves. CDs could be rented, and class CD Copy represents the actual CDs that are rented. My question is, should I represent Shelves as aggregation of CD copies or CDs?

Answer 1

I work mostly in SysML rather than base UML, but the question and the diagram are similar. What I tell students and clients who ask this question is to use the destruction test: "If the shelf gets destroyed, do the CDs get destroyed along with it?". The way you have it designed, there is a latent assumption that it/when the store remodels and upgrades the shelves, the CDs will be retained (somehow). Someone else could argue that in a building fire, the CDs would be destroyed along with the shelf. As such, your design problem is right on the edge.

From a software point of view, if you call the destructor for the class "Shelf" do you expect it to in turn call the destructors for "CD" for each CD instance? Your current design suggests that destructor for class "Shelf" will not be designed to call the destructors for the "CD" instances. In that case, you had better have another class (perhaps "Master Inventory List") that is also keeping track of the same CDs that are on the shelf. In the case of "Master Inventory List" it might make sense for that class to have a composition relationship with the CDs. Ie: if the store goes out of business and liquidates its entire inventory, the CDs get liquidated as part of the inventory.

However, as others have mentioned, it is all up to your use case and design.

By the way, you have used an undirected aggregation relationship. What that means is that the CDs are aware of which shelf they are on. That might be handy if you are producing a store guide for customers who want to first look up the CD and then next check which shelf in the store they can find it on. However, if that is not part of your design - ie: you want the CDs to be oblivious of the shelf - you want a directed aggregation, that is the hollow diamond arrow with an arrowhead at the other end.

Answer 2

In your comments you have clarified, that this question is mostly about how apply UML correctly.

UML class (as well as object) diagrams are very close to the (potential) code. That means your class diagram should represent the static structure of your (planned) code. That is with your diagram, I would expect to find the five classes EntertainmentItem, CD, CDCopy, CDOrganizerCupboard and Shelf in your code. Where to put an aggregation depends on how you see your future code. If Shelf aggregates CDCopy I would expect code similar to this:

class Shelf {
  private Set<CDCopy> cdCopies;
  [...]
}

If Shelf aggregates CD I would expect your future code to look somewhat like this:

class Shelf {
  private MultiSet<CD> cds; 
  [...]
}

So the question how to create class diagrams is easily answered with: Draw the diagram in a way that they reflect the code best.

Which of these both variants makes more sense is hard to answer without knowing more about your use cases. Do you need to know which exact copy is on which shelf? Do you need ever need to find a certain copy and know which shelf it is on?

Answer 3

Scenario 1 : the real world shop

What you call CD corresponds either to an abstract catalogue item that describes a CD content, or an original CD (which would be kept in a safe in the back office and used only to clone new copies).

What the customer can see on the shelf and rent are CD copies, the physical media with a content. Your current model correspond to this scenario. Go for it. It allows you to have two copies of "Imitation game" and locate them on two different shelves.

Scenario 2 : the risky shop

You could also imagine that on the CD would correspond to the original CD and that these are put on the shelves. When a customer picks a CD, the cash desk operator puts the original CD aside and replaces it with a copy. This could correspond to the alternative scenario that you have not represented.

This scenario is however very a very risky one and seems highly improbable:

• no one in the audiovisual industry would expose a CD master to the public in an environment without heat control (damage risk).
• the cash desk operator could make an error and handout the original (damage and loss risk).
• the shop's staff would have extra work: find the right copy, hand it out, remit the original cd on the shelf (risk of economic inefficiencies).
• When a CD is picked, it'll be temporary unavailable for other customers until the staff puts it back on shelf (risk of missed rental opportunities).

By the way, where would the copies be stored, if this would be the model?

Scenario 3: the virtual shop

The shop could be Netflix in 1997: The CD corresponds to an abstract catalogue item that describes a CD content. The Shelf corresponds to an virtual shelf displayed in the user's browser. This could also correspond to your alternative model. When the user check out, the real CD copies are sent. But again, where would these copies be stored or real physical shelves in some warehouses and these would be missing in your model?

By the way some UML:

If a Cupboard is composed of several Shelves, the black diamond should be on the cupboard side.

If CD copies are on a shelf, the shared aggregation in your diagram is a valid option. However, keep in mind that the semantic of the shared aggregation is not defined in the UML specification. Rumbaugh even called it a "modelling placebo" (full quote here). You can therefore replace it with an ordinary association and avoid any ambiguity.

Answer 4

You modeled with the physical world in mind. This may technically be correct but it usually isn't very helpful when you are building an information system.

A shelf may be a piece of wood but that does not matter to you. To your model it is a sub-location within a cupboard. Every logical CD has a home expressed as a cupboard id and a shelf id.

Likewise you would not model a physical CD. You would model CDs as a number for the number of CDs you have (one number for each logical CD, this could be a property of logical CD). Then I would expect a client class and a rental class that represents a CD currently lent out to a client.

The hardest part about modeling is determining what matters to your purpose. Your purpose may be an exercise but even then you should have a known goal: what should this system be helpful with?