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.


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
Image 1, not able to add figures yet:(
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
Image 2, not able to add figures yet:(
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:
enter image description here

  • 2
    I agree that it's too technical. A use case diagram shows the interaction of a user with the system. The underlying implementation is not important. Your use case should stay the same regardless of the source of information. If you want to include the error case, make a description of your usecases with main success and failure scenarios. But even then, I would just handle any system failure as "show error message to user".
    – SBI
    Commented Feb 15, 2017 at 14:43
  • Wouldn't it be redudant to include steps like 1.the applications opens database connection 2. the applications sends the data 2. the database stores the data in all three use cases? @SBI Or should I just say application stores data in database Commented Feb 15, 2017 at 14:47
  • Could you specify what kind of content UC_07 would have? Are there some actual business rules in it?
    Commented Feb 15, 2017 at 14:49
  • @CodeEqualsLife A use case description isn't where that information belongs. It's not something the user actively does with the application, but something the application does on input of the user. You'd need a second use case diagram detailing the systems internal use cases with the UI and Controller/Model as actors. However, that's usually not really the point of a use case diagram. If you really want to detail those interactions, go for an activity diagram, or maybe a sequence diagram.
    – SBI
    Commented Feb 15, 2017 at 14:49
  • 3
    Concerning the edit: Just don't mention the database. "are stored." The essence of the requirement is that data can be saved and restored. For all intents and purposes of the user, it could be printed out and put in a filer. The database (which one, which version, how it's hosted etc.) belongs in a different document and is essentially irrelevant to any of the business requirements.
    – SBI
    Commented Feb 15, 2017 at 15:38

3 Answers 3


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.


  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:


  1. 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”.

  • 1
    I would go as far as leaving out the database entirely. "As a User, I want to see a warning when data is not available". That way, even if we should change the implementation from a database to say, a rest service, the use cases stay valid all the same. Unless of course we're working on a database interface, but that would be a different story anyway.
    – SBI
    Commented Feb 15, 2017 at 15:06
  • I'm confused about the fact that the costumer wants the data to be stored so I'm tempted to include this in my use case diagram. I understand the "too technical" arguments, but doesn't omitting the whole "save data in database" aspect result in an "incomplete" use case diagram because in "real" the data is stored in the database but it won't be mentioned anywhere in the use case diagram then? @SBI Commented Feb 15, 2017 at 15:17
  • 1
    @CodeEqualsLife "As a User, I want to save my data (/ work / item)". Nobody cares about where that data is stored. That's why we build applications, because they are a more suitable abstraction than direct DB access.
    – SBI
    Commented Feb 15, 2017 at 15:21
  • @SBI I added a use case description to my question what I mean is should I omit the red bold text or not? Commented Feb 15, 2017 at 15:32

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.

  • As an addition: I like to only include information in a use case diagram that I would include in a how-to / the user documentation. If a user doesn't care or won't understand, it shouldn't be part of a use case diagram or description. I know that's a fairly loose metric, but it's helped me stay inside a sensible scope.
    – SBI
    Commented Feb 15, 2017 at 14:55
  • Thankyou, should the three use cases end with "the application stores the data in the database"? Because the storage of the data is a requirement. Commented Feb 15, 2017 at 14:57
  • 1
    Use case diagrams represent who or what uses a system and the nature of those interactions. So technical details as to when the data is stored should really sit outside of this.
    – Robbie Dee
    Commented Feb 16, 2017 at 8:39

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.

  • I agree that opening database connection and handling erros are probably to in depth for a use case diagram. Should omitting UC_07 and adding "the data is stored in the database" to UC_02-4 be too in depth too? because an important requirement stated by the costumer is the storage in a database I feel like omitting the database part (so just: "data is stored") will be actually ommit information which was given in the requirements? Commented Feb 15, 2017 at 19:54
  • @CodeEqualsLife I don't think the word "database" is too technical. From the functional point of view it's important to make clear that the system will store the data. If there are other requirements concerning a "database", then it's probably best to literally mention the database in the use cases as well.
    Commented Feb 15, 2017 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.