Is this usage of extend relationship in a use case diagram correct?

Question

I am developing a mobile application for image search

This is my use case diagram

Actor =Smartphone user

System = client-side application

The query is pre-treated in the client-side before being sent to the server (for example the vocal query is transformed to textual query)

should I add this use case to my diagram ?

I think it is may be an extended use cqse like this

Answer 1

First " As a general advice":

"Do not waste your time by by asking "should I add this?". Because you are the only guy who can say this? Just ask yourself : Showing or adding this to your diagram , what kind of benefit you will get?

Modeling means that showing important concepts hiding details. You are the the one who will identify what is important and what is detail.Because you will implement the system and make your hand dirty.

Secondly " Techically"

Extends means that "executing the use case/ scenario" is optional or conditional.

So if "pretreat a query" [ I do not know what it means. Whatever it is ] is executed optionally based on a condition [ suppose that when x condition is true at "make a query" use case, then "pretreat query" use case/scenario will be executed], it is technically true using extends relationship. So you can make your own judgement.

Lastly : Techically correct does not mean that it is right to do.

Whenever possible try not use "include" or "extends" relationships. They make your use cases and diagrams more complex.

Firstly write use your use cases as a text Then if you find "same scenarios" [ repating] in your use cases extract them as a separate use cases. Use "include" to attach those common use cases/scenarios to main use cases/scenarios. Use extend "relationship" whenever you find/discover new important scenarios optionally executed by main use cases.

My Personal Ideas:

For me you should even not to show "Make Query" in your diagram.[ of course while writing use cases if all of those 3 use cases make query same way , write this as an separate use case and then include the main use case scenarios text this, using include relationship is time saving . And there is nothing wrong with this. Be careful i say "while writing use cases as text"].

The main question is "should I show it in my use case diagram". So you should ask, who will read my use case diagrams? or why i create such a diagrams? Based on your context make your own judgement. Be pragmatic.

More Info:

Use cases are "text stories" of some actor using a system to achieve goals. In your situation your actor is Smartphone User.

So ask yourself what user wanted to do with your system?

1. Take Picture. [ sound reasonable ]

2. Type Keyboard [sound not good] : Why he/she type keyboard?What is her/his main goal? Maybe you mean search for a pic...In that case "Typing Keyboard" is not a good candidate for use case. To search a pic, he will probably write with keyboard pic name. But Typing Keyboard is not his/her main goal: it is part of-step of "Search Pic by Text" use case.

3. Speak? Why he speak? To record his voice?Or search pic with voice. Again main goal? I assume that you mean user can search pics by voice.[ Search by Voice use case]
4. Make Query: Query is "developer" term. Of course when you implement your system you make queries to database. But use cases are not for development. They are for capturing user requirements. But if in your use cases you do same steps in many use cases for "query" according to user point of view, using it in an "include" relationship is OKEY

5. Treat query :[ transform a vocal query to a textual query ] So it is not a use case. It may be part of-step of "Search By Voice": When you write your "Search by Voice" Use case text:

   Main Scenario:

   1. Smartphone User tell the picture name to search by voice.
   2. Image Search Application record this voice and generate a textual query.
   3. Image Search Application execute this query.
   4. Image Search Application show result of query

   ...

   Alternative Scenarios

   2 a) Image Search Application can not recognize voice: .....

   For me even this add unnecessarry technological details: We may not mention step 2. Just say: "Image Search Application search for a pic whose name is given by voice" . Generating textual query from voice is implementation detail.How you will do it. But use cases focus is "What user will able to do with your app".

Do not forget Use Cases are not diagrams: Use Case diagrams are just good for giving your system main features overview visually. Use Cases are "text stories".

So there are many ways to show them in use case diagrams:

As a rule use minimum extend, include , generalization relationships in your use case diagrams.Do not waste much time on identifying relationships in use cases.

For good,free Use Case resource Check Craig Larman's free chapter from his popular book:

Use Case Primer

Answer 2

First of all I would use <<include>> instead of <<extend>. `<<extend>> defines supplementary and optional behavior to the extended use case, and the extended use case does not require this behavior for it to work. On the other hand, <<include>> displays behavior that is added to the including use case. Furthermore, since this behavior is part of what you do in the make query use case; Just describe it in the description of the make query use case.