UML Domain model - how to model multiple roles of association between two entities?

Question

Suppose there is a scenario of Users having Tasks. Each User can either be a Watcher or Worker of a Task.

Furthermore, a Worker can file the hours he has worked on a given Task.

Would the following diagram be correct? I have looked around at domain models and I have not seen one with the two associations (works on, watches). Is it acceptable?

EDIT: What about this scenario? An User can make an Offer to another user. A possible way of modelling it is shown on the following diagram.

However, in that diagram it would seem possible for a user to make the offer to himself. Is it possible to model some constraints in, or is this handled further down the development line?

Answer 1

It is in principle correct, this is how you model multiple relationships between two classes.

As for the constraints, UML makes use of OCL (Object Constraint Language), so you can say that the associations are exclusive (xor - exclusive or).

Also note that it is generally a good idea to name the end roles of the associations.

Regarding one of the comments saying

There are no UML police to flag you down for being "unacceptable".

It is like saying: there's no code police to flag you down for writing shitty code.

You create diagrams to convey information (for school project anyway), if you diverge from standards or best practices you make it harder for other people to understand your diagrams.

And just like there are linters (jslint, ...) that check your code for common problems, for models there are model validations that do the same thing.

Also models, just like code, aren't set in stone so don't be afraid to modify them when you find a better way to express your domain.

Update

As Jim aptly pointed out, you usually do stuff not as a User (or Person), but as a Role. E.g. when you are student and you are filling a form, nobody cares that you are human, but that you are a Student. Typically a Person will also have several different roles (you could be a Student and a TA, a Professor, etc.)

Separating it in this way makes the domain much clearer as you are concerned only with the Roles, and not the people implementing them.

Answer 2

On the first model, there's not much to add after Peter's excellent and very interesting answer.

However your second diagram (in the edit section) does seem to give a true and fair view of the narative. From the strict 1 to 1 relationships, I'd understand that every user makes exactly one offer to one other user, and every user receives exactly one offer from another user:

• "A user can make an offer to another user" implies a cardinality of 0..1 or *, not 1.
• From this we understand implicitly that not all users need to receive an offer, i.e. also a cardinality of 0..1 or *
• This can be debated, but "an offer" doesn't in my opinion mean at "at most one offer", so the upper bounds of cardinality shouldn't be * and not 1 to show that every user may make several offers and receive several offers.

As you can see, you can add constraints to the schema to increase expressivity. This is done in an annotation between { } . But you can choose the most suitable syntax. Here an example with the full expressivity of natural language (as suggested by Martin Fowler in his "UML distilled") but you can of course use the more formal OCL, making it {self.offerer<>self.offeree}.

Answer 3

I see @Peter updated his answer before I could post this answer, but I will post this anyway to show you some other tricks.

In general, it is perfectly valid to have multiple associations between the same two classes. However, I don't think it's a good idea here.

You say you want to build a [problem] domain model. I'm glad to hear that! A problem domain model is very important, as I explain in the last paragraph here. One thing to point out is that you want to build a durable model that transcends a system you can conceive. In the problem domain, there is no "User". There are, however, Roles that People play. For example, you mentioned Watcher and Worker. Hopefully these are concepts your customer already has in the "meat world".

In the model you posted, you have no place to hang the hours worked or progress made. You might try an exercise. If you had no computer, how would your customer track these things? They often have (or had) a way, and it was probably pretty optimal for a manual system.

Here is how I would model my understanding of your problem domain:

Some things to note:

• A Person plays any number of Roles.
• A Role is with respect to exactly one Task and one Person. A Watcher watches exactly one Task, a Worker is assigned to exactly one Task, and any kind of Role is played by exactly one Person.
• A Role is abstract, and its subclasses are {complete}, meaning there can be no valid instance of a Role without also being an instance of a subclass.
• A Task is watched by any number of Watchers and may be assigned to one Worker at a time. There is a constraint saying {person is not a watcher}. (You can show the OCL for that, but few people will understand it.)
• I have added a Progress concept as a way of logging progress on a Task. A Worker makes Progress on one Task. Each bit of Progress has a Description and a Duration. Note that I have not committed to any computational way of representing a Description or a Duration. The designer of a system for this will be free to derive a Duration from start and end times, or ask the user to self-report.