My course notes have stated that a system should have a system class which coordinates the behaviour of all other objects in the system and should be one which is instantiated only once.

In many real life examples encountered such as a Library or a Hotel, it is clear that the Library or Hotel class would be the system class. In my system however there is no clear candidate as all the classes I currently have in my class diagram could be instantiated multiple times.

For context the system I am working on can be analogous to a website such as https://uk.pcpartpicker.com/ where a user can login, create a new build project, and then select pc parts for that build. I have modelled the following classes with justification in brackets:

  • User (details of the user must be in the system)
  • Build (it is a container for pc parts)
  • PcPart (there will be many pc parts in one build)

Clearly the system can have any number of users, who can create any number of builds, which can contain multiple pc parts.

So by the definition of a system class, none of these are good candidates.

How would I define the system class in this case?

  • Why don't you just call it the "System" class or "Application" class? Commented Jun 19, 2018 at 15:13

1 Answer 1


What's the name of the system?

You're looking for something like class PcPartPicker given the website pcpartpicker.com. This would have your main(), startService, or startApi type of method that is called once. It's meant to be what starts your program. From there, it can create the objects (i.e. PcPart) as needed depending on how the user interacts with it.

  • Thanks for the suggestion. I had a similar thought before because that makes sense to me, however, I've been told the system itself should not be modelled in the class diagram. Same as how you would not model the user of the system unless their information is somehow used by the system.
    – SimStil
    Commented Jun 19, 2018 at 14:12
  • 1
    The folks who told you that must be thinking of a higher-level system diagram. The class diagram is fairly low-level and deals with code, not higher-level modular concepts. Commented Jun 19, 2018 at 15:12
  • 1
    @SimStil: it seems someone told you "a system should have a system class", and someone else "the system itself should not be modelled in the class diagram". Either first person meant to have a class in the system which is omitted from a class diagram, or the second one had something different in mind than the first, or you are remembering some details not correctly. But instead of listening to people which are at odds with each other, think about what makes most sense to you.
    – Doc Brown
    Commented Jun 19, 2018 at 20:20
  • @SimStil unfortunately, many methodologies exist for doing it, and some are quite dogmatic. One broad approach to OO modeling of a domain says that the system object is the "root of the containment or aggregation hierarchy of domain objects." The answer here is good for this reason. Commented Jun 20, 2018 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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