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?

enter image description here

  • The first thing to know is that this is ultimately up to you, you are the modeler - you are the authority, since you're making the software. In a university setting, a professor might say a design is wrong, in the real world, no one can really tell you that you're wrong. How "right" or "wrong" you are will be ultimately decided by how well the software is performing its job. A design that better matches the needs of the real world usage is "more correct". 1/2 Nov 5, 2021 at 20:22
  • That said, a business will generally be more interested in tracking an actual instances (copies) of a physical product, with the more abstract CD being a more of a catalogization thing. So it probably makes more for the shelves to contain CD Copies; now there might be a rule that all copies of the same CD go on the same shelf, so you might be tempted to connect to CD, but that rule might easily change. Furthermore, the model doesn't have to follow the real-world physical structure; you may decide, for example, that it's enough for a shelf to be a string property on CD Copy. Up to you. 2/2 Nov 5, 2021 at 20:22
  • 1
    P.S. Could you also clarify your question further - you mentioned generalization in the title, which suggests to me that it has something to do with your concerns, but you didn't describe how it comes into play in the text of the question itself. What is it about it that bothers you? Also, why you have it in there (what's the motivation)? Nov 5, 2021 at 20:26
  • It is not clear whether this a question about diagramming or software design? If it is the former, the answer is simple: The diagram should reflect the software design. If it is the latter, we would need more information about your specific use cases to give you a meaningful answer.
    – Helena
    Nov 5, 2021 at 21:05
  • Thanks all for comments. I changed the title of question, hope it is more accurate now. The figure above is part of a bigger figure. My question is mainly regarding the correct application of UML standards while working with diagrams. @FilipMilovanović, you mentioned "be a rule that all copies of the same CD go on the same shelf, ..." that seems very interesting. Could you elaborate? I am not experienced in UML.
    – Melanie A
    Nov 6, 2021 at 4:03

4 Answers 4


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.


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?


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.


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?

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.