UML Class Diagrams - Understanding Which Fields are Necessary and When To Have Public Fields

Question

I'm currently working on a UML class diagram for an application which is supposed to be like 'Duolingo'.

I am struggling on how to model a many to many relationship. So, I imagine that you have many users which can take many courses (different languages that they wish to learn). For this reason I have decided to create a courseProgress class to model this many to many relationship.

What I was wondering is, do I need to store the userID and courseID in my courseProgress class? I think I'm getting mixed up here with how keys may be used in a database.

See below diagram:

Am I along the right tracks?

Also, I was wondering when exactly you would use private and public fields. Because to me it seems that you would always want all fields to be private and just use getters and setters to always access these fields?

N.B in the above diagram the fields are public as I have not yet changed them to private

In the diagram above, should I have the userID field and courseID field or should I have a user field of type User and course field of type Course?

Answer 1

You are indeed on the right track. The additional class CourseProgress helps you to better represent the many-to-many association between User and Course. An alternative could have been the use of an association class.

The choice between public, protected or private properties depends on your class design and how you want to expose this information in the object model. This is far too broad to be explained here. To simplify, if the properties are data that could be changed by other objects without any consequence, then you could let it public. If however some properties can only be changed according to some rules with pre-conditions, invariants or post-conditions to be guaranteed, you'd better control the change via a method and thus make the property proteted or private.

Whether or not to indicate the identifiers of the associated classes (i.e. courseId, UserId) depend on the purpose of your diagram.

Typically, for a domain model or a design model, you wouldn't add the properties for representing the classes you are associated with. This is an implementation detail of the association. Usually, you'd rather use the association end to indicate how the instance of the related class would be called.

For an implementation model (example for one-to-many or many-to-many), you may want to show this detail to allow an unambiguous mapping with database tables.