6

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
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

Community
  • 1
CodeEqualsLife
  • 63
  • 1
  • 1
  • 5
  • 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 Feb 15 '17 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 – CodeEqualsLife Feb 15 '17 at 14:47
  • Could you specify what kind of content UC_07 would have? Are there some actual business rules in it? – COME FROM Feb 15 '17 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 Feb 15 '17 at 14:49
  • I do not think the Stick Men belong here. That's for the user stuff mostly. And yeah, I know that doesn't sound technical or Project Managey, but they are Stick Men Actors. – johnny Feb 15 '17 at 15:03
  • 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 Feb 15 '17 at 15:38
  • Thankyou! that part is clear now but in UC_05 use case "show stored data" it's unavoidable (in my opinion) to say "the application retrieves the data stored in the database" or am I wrong here too? @SBI – CodeEqualsLife Feb 15 '17 at 15:44
  • Same thing. "Data is retrieved". The requirement and use case isn't affected by the storage method. If we continue my analogy, an assistant could go grab the filer and bring you the printed piece of paper. Imagine payment at the grocery store. You can pay with a credit card or with cash or trade in a goat. It doesn't matter as long as both sides of the exchange are content with the deal. Same here. User gets data, user is happy. – SBI Feb 15 '17 at 15:51
  • I'm not sure if saying "data is retrieved" is sufficient as said by amnon: "use case where the user clicks on a 'save to DB' button then you might have a real use case" @SBI Which will lead to a description like: 1. the user clicks retrieve data 2. de data is retrieved from the database (in a simplistic form)? – CodeEqualsLife Feb 15 '17 at 19:46
  • But what is the additional value from that statement? You gain nothing by specifying the data source. Try to remind yourself of what use cases are concerned with. To me, that is just one statement. "User retrieves data". Nothing more is needed. The system should be completely transparent except for user input because the user is the only concern of a use case diagram. – SBI Feb 15 '17 at 20:37

3 Answers3

5

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.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • 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 Feb 15 '17 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. – CodeEqualsLife Feb 15 '17 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 Feb 16 '17 at 08:39
5

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:

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

amon
  • 132,749
  • 27
  • 279
  • 375
  • 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 Feb 15 '17 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 – CodeEqualsLife Feb 15 '17 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 Feb 15 '17 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? – CodeEqualsLife Feb 15 '17 at 15:32
2

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.

COME FROM
  • 2,666
  • 15
  • 15
  • 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? – CodeEqualsLife Feb 15 '17 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. – COME FROM Feb 15 '17 at 20:41