How to split up use cases in Clean Architecture? (Dealing with use case dependencies)

Question

I am trying to understand Clean Architecture as explained by Uncle Bob.

My application requires a user to do a test. A test consists of a collection of questions that a user needs to answer. A audio file is played for every question. After the test the user is provided with a test result.

Possible use cases?

• Do a test
• Answer a question
• View test results

Questions:

• Is "answer a question" a separate use case? Or is it just part of the "do a test" use case?
• Is "view test results" a use case? Take note, result is displayed automatically after the test - it is not something the user chooses to do
• I assume "Play audio file" is not a use case as this is played automatically on every question and is handled by the app, not the user?

Answer 1

Requirements

My application requires a user to do a test. A test consists of a collection of questions that a user needs to answer. An audio file is played for every question. After the test, the user is provided with a test result.

The Use Case

Based on the requirements above, there would be only one use case: do the test. And, so far, one actor: the user.

Answer the questions and view the results would be part of the workflow of the use case.

Finally, the audio is just a implementation detail.

The Use Case documentation

Besides the diagram, the use case should be documented as well. The documentation will provide the information that can not be drawn in the diagram.

For example:

Use case: Do a test

Main actor: User

Brief:

The user do the test. Each question comes with audio and text.

Triggers: - The user select a test from the list.

Preconditions: - The test is presented to the user

Postconditions: - The test is done and closed. A result view is shown.

Workflow:

1. The system provides the user with a test.

2. The user checks the answers.

3. The user sends the answers and wait for the results.

4. The system evaluates the test.

5. The system shows the result of the eval.

Extensions

2-3:

a. Cancel the test

1. The user cancel the test

2. The system discard the test

4:

a. Repeat the test

1. The system allow the user to repeat the test

---

Note:

I have just described the only use case I saw in the question. Nevertheless, I assume that your system has some more.

Answer 2

Is "answer a question" a separate use case? Or is it just part of the "do a test" use case?

It's a step in "do a test" which could be expanded to subfunction-level use case.

Is "view test results" a use case? Take note, result is displayed automatically after the test - it is not something the user chooses to do

Same as "answer a question". Unless there is an option to log in and check results of your previous attempts.

I assume "Play audio file" is not a use case as this is played automatically on every question and is handled by the app, not the user?

Similarly it's a step in "answer a question". If needed you can expand it into yet another "System plays audio file" low level use case describing how System looks for proper file, what it does when no file found or speakers on mute etc.

Answer 3

In many techniques that uses use cases, there are commonly multiple levels of use cases, for example one definition have five levels of use cases (this is not the only use case level definitions, many projects may want to customize the levels to their particular scenario/process):

• Cloud: Very high level, involve multiple user goals, e.g. "Operate a Biospecimen Repository"
• Kite: High level, a process that takes place over several hours, days or weeks involving many steps "Find Usable Samples"
• Sea: User Goal, something the actor is trying to get done - "one person, one sitting", involves several underwater or clam level
• Underwater: Needed to accomplish user goals, typically can be used and reused - "Save as a File"
• Clam: Not usually written out in detail as a use case, "insert record into database"

Some use cases are written at a broad level, where you have user navigating a sequence of multiple pages/dialogs while others are use cases that comprise a single page/interaction only.

As commonly used, the "clam"-level use case (like play an audio file) is often not written down as they are often considered low level implementation detail. They could, however, be referenced by a higher level use case (e.g. a high level use case may require that a sound be played at the end of the test).

These high level use cases may be mapped to integration tests, while lower level use cases may be mapped to functional test. The clam level are often only subjected to a unit tests.