如何在 Uml 用例图中显示工具栏

Question

I am new to object oriented design and I wanted to do my first ever UML use case Diagram on a simple application which contains toolbar on the top left corner. The toolbar is called files and when the user clicks on it,a drop down menu is opened with options to open a slide,save slide,make new slide and exit the application.
My question is, am I doing it correct with Use-Case inheritance(Generalization) ?
This is my diagram.

Answer 1

I am sorry to disapoint you, but I have to tell you that this practice is just plain wrong:

• From the point of view of the semantics , the use-case specialization means that Open presentation is a special form of Check file , and Save file as well, and that the actor could use them interchangeably and independently. But this cannot be what you mean: exiting a presentation is at best a sub-part of checking a file

• From the point of view of the purpose , a use-case should represent a user goal. It's part of the problem space, ie what the user wants to achieve. It's not part of the solution space, ie how the user will achieve it. A toolbar is not a goal: it's a user-interface element.

• From the engineering practice perspective, use-case should not be used for user-interface design. It's not my own statement, but that of Jacobson, Booch and Rumbaugh, the founding fathers of UML:

  The problem is that the [use-case] descriptions often contain implicit decisions about user-interfaces. Later, when the user interface designers suggest suitable user-interfaces for the use-case , they may be limited by those decisions.
  in The unified software development process , page 164

So in conclusion, it's a bad idea to start use-cases from the user-interface. It locks you into your own design and ignores the user experience. You should focus instead only on the user needs. THe same use-case could then be used whether you'll implement it using a GUI interface, a chatbot interface, or aa voice-based interface.

Answer 2

While drawing Use Case diagram, one thing you should focus on is, the actual meaning of it and the purpose of drawing it.

A Use Case refers to what the users in respect of their type are able to do in your System... Anything inside the boundary is what system is capable of doing or what it can provide as a service to its users.

While naming the use cases, you should only use verbs and actions, for example:

1- Login | 2- Submit a Request | 3- Update Profile Description

You should avoid any nouns in them.

There are several relationships that exist in a Use Case Diagram among use cases, and a relationship among actors and use cases of the system, And They are as follows:

Association: the only relationship that can exist between an actor and a use case; Which says the actor is initiator of this use case, or is the one who is caple of operating the use case.

In the example above, User is caple of loggin in and submitting a complaint.

Include: Use Cases can include one or more use cases. When a use case includes another use case, it means the included use case or use cases happen all the time and are part of the initial use case.

Paying fees is included, because user has to pay the fees in signing up process, it has to be done, and it's part of the baseline path of the scenario.

Extend: When a use case is not happening all the time, and is part of your alternative path ( Alternative path of the complete scnario for this use case ), the use case should be extended to the base use case.

Forget password is extended to Login use case, because it doesn't happen all the time, and it's part of a alternative path of Login scenario.

Generalization: When there exist several different ways that a use case can be performed and completed, we use generalization. The inheritent use cases should all be of the same type as the inherited use case.

Submitting a complaint can be done in several different ways, in this case, we need to seprate each use case and inherit from from the submit a complaint use case which includes paying fees, this shows that, paying fees is a part of every type of complaint which is submitted.