Doubt about the structure of a use case

Question

I have the following use case:

I have three doubts, it’s them:

• Registering is a suitable name?
• In the above case it is correct to have the CRUD element?
• Manage user should be Keep user?
• This include Fetch it seems to me dispensable, should remove?

Answer 1

About your questions we will answer them in parts.

Registering is a suitable name?

In general usage case structure theory, we use verb names to determine that some task will be performed, this is not a rule, but is considered a good practice within UML.

Let’s go to the following example, we have a hypothetical scenario.

A factory has some workshop parts to be sold and needs to deliver to the customer, owner of a workshop. If you put in your diagram only "pieces" you can’t understand what it is. There is an immense amount of possible actions to make with parts, such as delivering parts, buying parts, selling parts.

As spoken up there, the ideal is to put a verb to indicate which action is happening.

So, registering, registering, registering is an ideal name

In the above case it is correct to have the CRUD element?

No, it is not correct to have the CRUD element, within the use case, we do not represent system functionalities, in a system-level way. For this there are other diagrams, as of classes, in the use case diagram we only represent the actions that an actor will do.

As shown in the previous example, we should only show in the use case diagram the actions taken by the actors, not the functionalities of these actions.

Manage user should be Keep user? I don’t understand this question, you have to see your scenario

This include Fetch seems to me dispensable, should remove? To know whether we should remove or not, we must once again enter into the use case theories.

Include

In the use case diagram, the include element is used when one functionality is totally dependent on the other, that is, it is mandatory. Explaining in a better way, let’s take an example.

Generate Invoice would be a include of Perform Sale.

The invoice can only be issued after a sale and must not be optional.

Extends

extends, is used when there is also a dependency, but this dependency is not mandatory, the functionality can occur independently of the other.

Explaining in a better way, let’s take an example

Send invoice by email would extend to carry out sale.

Tax note can be sent by email, but not mandatory.

Answering your question

It depends on your scenario, your exercise, you can’t tell for sure if you’re wrong or not.

Answer 2

Theoretical response.

You don’t have a use case, but several.

There’s nothing wrong with the name Register.

On the other hand, Login is not typically portrayed as a use case, according to the definition of a use case (bringing a concrete benefit to an actor). It can be a step of a use case. Note: some portray yes as use case or login.

It does not make sense a use case to extend a CRUD, even because I at least do not see a CRUD as something generic that can be extended.

(This is the part I’m less sure about) Seeking also seems to me to run away from something that brings a concrete benefit, but I may be wrong. In any case I believe that the idea of include is to include scenarios that are common to several use cases. I don’t see Seeking making much sense on its own.