Designing a class diagram using n-ary association

Question

I have a scenario involving three classes: Planner, Agent (a sales agent), and Client. Here's the scenario:

The Planner class has a list of clients, and the planner selects a client from the list and associates an agent with that client. The agent then visits the client to sell products. Additionally, a Sale Operation class needs to be created to store extra information about the sale, such as the products sold.

I'm currently stuck between two possible solutions for designing the class relationships. Here are the two solutions I have considered:

Solution 1: In this solution, I have a direct association between Planner and Agent, and a direct association between Agent and Sale Operation. However, I don't have a direct association between Planner and Client, as I simply fetch a list of clients and then assign an agent to a selected client. Here's the diagram for Solution 1:

The problem I encountered with Solution 1 is that it lacks a direct association between Planner and Client. The relationship is more indirect, as the Planner class only has a list of clients and assigns an agent to a selected client.

In this solution, I removed the association between Planner and Client, and instead, I added an association between Planner and Agent, considering that a Planner assigns an agent. However, this introduces a many-to-many relationship between Planner and Agent, requiring the addition of a third class.

Here's the diagram for Solution 2:

While Solution 2 establishes an association between Planner and Agent, it creates a many-to-many relationship between these classes, necessitating the introduction of a third class.

Edit: Additional solution

Solution 3:

after reading the comments and proposed solutions, i added this solution ( and removed the n-air association as its not UML ) class of sale isn't created until the planner assigns an agent, and every sale operation has a client in its attribute ( that the planner chose before assigning an agent )

I would appreciate guidance on selecting the most appropriate solution or any alternative suggestions that would best represent the relationships between Planner, Agent, Client, and Sale Operation, considering the scenario outlined above.

Answer 1

Analysis of the initial solutions

Unfortunately, none of the solutions capture the semantics needed for your problem, as the time dimension was missed:

The Planner class has a list of clients, and the planner selects a client from the list and associates an agent with that client.

This means that you may for example have a Planner instance, that at one moment in time has 10 Client in its list, but 5 of them have no Agent assigned yet (perhaps because your system's purpose it to help make these assignements?). This kills solution 2.

The diagram of solution 1 is by the way not UML compliant: in the n-ary association there should be a multiplicity only at the ends and not on the side of the diamond.

Let's suppose you got solution 1 diagramme right. In this case the client would be associated with a planner only if there's a sale, because your n-ary association is an association class. This kills solution 1, because not all the assignments lead to a sale.

You need to reconsider the model, taking into account the time perspective.

Edit: additional solution 3

The additional solution is similar to the n-ary one. It has the advantage of being clearer about multiplicities.

From the model semantics I understand that what you call "sale" is in fact a "sales lead" or a "sale opportunity" in sales terminology.

Still missing in the model is the fact that each planner has a list of clients. There is one solution which is using solution 3 and add the missing association.

Answer 2

The Planner class has a list of clients, and the planner selects a client from the list and associates an agent with that client. The agent then visits the client to sell products. Additionally, a Sale Operation class needs to be created to store extra information about the sale, such as the products sold.

Your narrative implies that there are six classes: Planner, Client, Agent, ClientVisit, Sale, Product.

You need to modify and extend your version 1 model by

1. detaching your Sale class from the ternary association and, instead, attach a ClientVisit class to it (however, this merges assignments with client visits, so if it's not important to record both client visits and sales, then better call the ternary association "Assignment");
2. Associate your Sale class with Client and Agent (and Product ).

This changed model allows agents and clients that are not yet assigned, and it allows later sales for some of the assignments/visits.