我如何设计 UML 用例图

Question

I am trying to design a use case diagram for the following scenario.

I have a society that is distributing goods to clients based on their orders. These clients can be administrations, companies, or private individuals. Depending on what the client is I want to know more or less of their info (name, number etc)

The use cases are different depending on whether the client is:

1. English
2. English and have used this service for more than 3 years
3. Foreign

For example:

• The 1) English clients' orders are accepted only if they pay a small fee in advance.

• The 2) English clients that have used the service for 3 years don't have to pay this fee but need to get approbation from a different actor (an Agent in this case)

• The 3) Foreign clients' orders are always accepted no matter what.

This right here is where I run into trouble and need help with.

The orders from nglish clients that have a criminal record are always denied UNLESS they are an administration.

What are the most optimal actor choices here? I thought of going with English client , and Foreign clients but I don't know how to include the "Unless the client is an administration" in the use case.

Answer 1

The use case diagram is not the right place to put this information. As correctly pointed out by @Christophe, a use-case represents a goal for a user who is going to interact with the system to achieve the goal .

This means that there is only one single use case in your scenario: "Order Goods" . However, it has a set of preconditions . You could list them as structured plain text. Since there is quite some complexity behind each of them, I recommend to put them into a separate decision chart. Then you have a nice clean separation of the diagram scopes, and they remain easily readable.

Sidenote: There could be a second one "distribute ordered goods" executed by a 2nd actor who is an employee who does fulfillment / routing / dispatching.

Answer 2

Actors in UML use-cases are classifiers. To decide about which actors to create requires to understand the actors their goals and behaviours and how they differ in the interaction with the system.

First of all, you need to clarify the super-ambiguous requirements:

• " English client ": is this a client with English nationality? Is it a client that lives permanently in the UK? Is this a client with an address in the UK? Is it a client with a +44 phone number?
• " Foreign client ": same kind of questions + can you define for sure the difference between Ensglish and Foreign? For example: what with bi-nationals? what with people having two addresses one being abroad?
• " Using this service more than three years ": what with a foreign customer who uses the service for 3 years and then settles in the UK?
• Since you deliver goods, you might also need to consider a delivery address. What with an English client ordering on a foreign address or vis-versa ?
• " criminal record ": the criminal record might change over time: is it provided at each purchase? or is it part of the customer registration process ? In the latter case, is there a need to periodically renew this information ?

Use-cases should in principle be goal oriented. So a use-case represents a goal for a user who is going to interact with the system to achieve the goal. Use-cases are not meant to describe the detailed sequence of your process (if client is this, do that, etc...) and neither are actors meant for that purpose.

You should therefore consider reformulating the use-cases to represent how the actors would perceive them. If needed you may consider the status of the actor that could explain that an actor behaves very differently. Typically in your case, I could imagine :

• New client: a new client may want to provide details (address, identification) or evidence that they are entitled to buy (criminal record - I suppose your activity is regulated if you request such details)
• Public administration: behavior of administration in purchase is anyway different because of public procurement and legal constraints.
• Privately owned company: behavior is different since it can involve several persons,
• Private individual

The need to pay an advance fee seem to depend on the address, nationality, history. It's more related to the process (it's a part of it) than an independent goal for an actor. So I would neither show this as a use-case nor make different actors for this purpose.

The reason to deny an order is not something that is not relevant for the customer (no customer has a goal go get a purchase denied!). It's relevant to you and your system and is a consequence of the registration process. So no need to have a dedicated actor for that.