Does a UML use can show everything the actor can do (functionality) or everything the actor wants to do (goals)?

Question

Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:

1. Register (to create an account)
2. Browse items
3. Add items to basket
4. Checkout and pay
5. View account information
6. Edit account information etc

However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:

1. Login
2. Logout
3. Select 'electronics' department
4. Select 'vehicles' department
5. Enter delivery details etc

I would argue that things like login and logout shouldn't be in the UML use case diagram. The reason being that a user would not want to go to the on-line store just to login; they would always have another aim which would be to view / edit account information or browse and buy stuff.

Likewise, the two select 'statements' are part of the browse items use case. I wouldn't use generalisation because there could be many departments.

Finally, the enter delivery details is part of the 'checkout' or 'edit account information' use case. I would normally lump this in with the 'edit account information' use case otherwise you may as well have use cases for 'edit name', 'edit email' etc.

My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.

So, my question is as follows. Is my thinking behind this correct? Is it best to only model 'real' goals in the use case diagrams or everything that the actors can initiate?

Answer 1

Does a UML use can show everything the actor can do (functionality) or everything the actor wants to do (goals)?

It can be either - the UML spec isn't prescriptive on that front. Alistair Cockburn created a categorisation for Use Cases that indicates what level they focus on.

Having said that:

My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.

That's a very real risk. Personally I find I get most from UCs by focusing on the users and their goals. What value are they looking to get from the system?

Keeping it at that level prevents a "can't see the wood for the trees" situation - and also stops UCs becoming a complete, functional decomposition design.

hth.

Answer 2

It is not wrong to exclude some use cases from your diagram, and indeed it might be a good idea. For instance, if you are going to show your diagram to the business department, you can draw an UML model that describes the operational use cases. If you are going to hand down your diagram to the programmers, you would want to give them a complete description of what they have to implement. These are just models of your system.

When one draws a use case diagram, usually one also writes the behavior of each use case (as free-text description, pseudocode, or by using interaction diagrams).

The UML specification says that:

A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.

Login and Logout are observable to the user. While the user will not visit your site with the only goal of logging in, such use case certainly has some execution flow that you also want to describe. If you don't allow users to initiate a login by themselves, there will be use cases that include the functionality of login. A user may have also interest on logging out before leaving the site, so that no session data will remain stored in his computer.

Select 'electronics' department, Select 'vehicles' department... Why not just Select department (I suppose that they are not too different).

I would draw this and other use cases, as long as they are relevant to the model.