Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:
However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:
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?
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.