Use case diagram (UML): Should database storage be an sub use case (in this diagram)?

Question

Application background

A short description of what the application should do
I'm developing an application which analyses DNA sequences. The user will load a certain file containing a DNA sequence. Then the user can click on a button to search for ORFs (parts of the DNA sequence with specific features). These ORFs can then be BLASTed (searching annotation about these sequences in a public database). One important requirement was that the DNA sequence (loaded by the user), the ORFs (found by the application) and the result form the BLAST will be saved in a database.

---

Process

I will first describe what I did and why I changed some things to clarify why the diagram is as it is now. I'm just new in using UML and every comment is welcome.
Use case diagram version 1.0

I doubted about "saying" that the databse is an actor, based in this question I decided that the databse is just for storage and I omitted it. resulting in the final version of my diagram.
Use case diagram version 1.1

I spoke to some people about UC_07, some would argue that this would be "too technical". However my vision is that extracting this common step clearly shows the limitations of the the application; while the database is not running (due to an error e.g.) all the three use cases (2,3,4) would be afflicted by this.

---

Question Should UC_07 be an seperate (sub) use case or not? Further as described above (the database isn't an actor if it's just used for storage), however how could UC_07 be described if the database can't be seen as an actor? Because in general it will look something like: 1. The application opens the database connection 2. The application sends the data 2. The database stores the data

Other suggestion/improvements about the use case diagram are also really appreciated

---

EDIT because of comments under the answer of Amon
Let's suppose I decide to ommit UC_07 should I mention the data storage in the databse in the UC_2-4 or not:

Answer 1

The use case diagram gives us an overview of requirements, and illustrates how various actors interact via the system.

There are many ways to actually capture use cases. An important one is single-sentence user stories. For example: “As a User, I want to search ORFs”. This is a valid use case. Now you are proposing a use case like “As a User, I want to save data in the database”. That may be a valid use case but it really does not seem like it.

This is clearer if we use a tabular use case format. Here, we explicitly list the steps that the user performs, and how the system responds. For example:

Search ORFs

Precondition: A file is loaded.

Primary Actor: User

Trigger: The User clicks on the “search” button.

Scenario:

1. The User enters an ORF into the search box and submits the search.
2. The System displays a list of all matching sequences in the loaded file.

Postcondition: The system can receive the next search query.

Some steps in this scenario might be so complex that they are described in another use case that would then be included. But a use case is always an Actor–System interaction. If you have a “save data in database” use case where the user clicks on a “save to DB” button then you might have a real use case. Otherwise, the database is just an implementation detail.

That the database seems to be important to your users could mean that you haven't actually captured all use cases. You mention the constraint that the database must be running in order for those use cases to work – that is a precondition, or perhaps an exception scenario. We could extend the above detailed use case with an alternative flow:

Exceptions:

2. If the database is offline or returns an error, the System displays an error message to the User.

If a “the database is offline” check is common to many use cases, you can extract that common step into a shared use case. E.g. for web applications, we would extract the “user is logged in” check to a separate use case instead of repeating that in each use case.

What is the user interest here? They don't want to enter a search if it can't be answered. So the use case actually is “As a User, I want to see a warning when the database is down” or “As a User, I want to be prevented from searching when the database is down”.

Answer 2

I would argue that UC_07 perhaps isn't needed at all if it forms part of the system overall.

Also a lot of your use cases read like a sequence of steps which more properly belong in a sequence diagram. But it really depends how many UML diagrams you're using.

You could also make a case for removing start and close applications as this is a given if you're using the application itself.

Answer 3

Use cases and use case models are for describing some aspects of the functional requirements of a system. As such they should concentrate on what the system is supposed to do from the business point of view. Especially they should not be about how the system works internally, which is a matter of software design.

Technical stuff like opening database connections and handling unexpected errors mostly belong to the domain of design rather than requirements.