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:
Best Answer
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:
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:
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”.