I'm trying to learn to create use case diagrams and would appreciate some pointers. The sample problem is to create a use case diagram for a seller in an online magazine selling site, I only have to worry about the 1 actor. Actions include selling a magazine, viewing listed magazines, a secure login, etc. Do the actions such as selling a magazine, updating seller info, and more come before the login? Does the order matter? The textbook I am using does not have great examples. I've attached a pic of something I threw together quickly just as a visual representation.

Thanks in advance.

EDIT: Just realized that I have the include arrows backward... sorry about that

enter image description here

2 Answers 2


In addition to @Christophe answer.

The order doesn't matter. It's not the goal of this diagram to communicate procedures, activity or data flow. It's all about what your system can do, the actors of the system and the allowed interaction between the two. That's it.

I would tho suggest grouping up the use cases around namespaces. For example, draw a rectangle named Account Management and move inside all the use cases involving the user's account management (CreateAccount, DeleteAccount, UpdateAccount, UpgradeAccount, ...). Then draw another rectangle named Store Management and put use cases involving the maintenance of the store. Finally, draw another rectangle named Store and put use cases involving Store's features (SellMagazines, BuyMagazines, SubscribeMagazine).

Then draw two actors, Customer and Seller (even if they are essentially the same person, they interact with the system with different "roles"). Put one on the right and one on the left. Finally link actors with use cases.

Namespaces give context. Where use cases happen and, at the same time, illustrate the boundaries for each actor. They also allow you to draw twice or more a use case. For example, you might draw two SearchMagazines, one inside Store Management and another inside Store. By doing so, you stress the idea that both actors can search magazines, but they do it in different ways due to the context (the rules can be different for each role).

Finally, I would remove all those include and extends. Instead, I would draw additional diagrams where I could zoom in and focus on specific contexts or use cases accordingly to their complexity. From a generic overview of the system down to concrete views of the use cases I find they need more details.


Syntactically and semantically this diagram is correct except that all «include» are inverted, and one of the «extend» also (it’s Email buyer that extends Sell magazine and not the contrary).

The diagram shows however a functional decomposition of the real use cases (i.e. the goals of the user) which is not desirable, as it leads to overcomplex diagrams. Use cases should focus on “what” the system offers to the user or “why” the user wants to use it. So I recommend to simplify, and leave details such as login, email buyer, etc. to activity diagrams that document how a use case will “work”.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.