database as distinct operations in the Use Case diagram

Question

I'm working on analyzing an application for skin disease diagnosis using AI. Here's the scenario:

• User Interaction: The user logs in to the application, uploads or captures an image of their skin condition.
• Diagnosis Process: The AI model then diagnoses the condition based on the image. I’ve represented the AI model as an 'actor' in the system, treating it as an external model.
• Result and Feedback: After the initial diagnosis, questions are retrieved from the database based on the predicted condition to verify the diagnosis. If the initial diagnosis isn't accurate, the user is prompted to consult a doctor. If it's correct, they see a summary of the diagnosis with guidance and treatment recommendations.

Should I represent the retrieval of questions or treatments from the database as distinct operations in the diagram?

I will attach the diagram and would appreciate your guidance and tips.

Answer 1

Sorry if I will not answer what you want to hear and if I might sound somewhat blunt.

This use-case diagram presents a detailed functional decomposition of your system. While the UML specs are neutral about this, all leading use-case authors strongly advise against functional decomposition, as this leads to complex diagrams that are very difficult to understand, and often imply some sequencing expressed with dependencies, which is ambiguous.

Use-cases shall be independent of the internal structure of the system, according to the UML specs. Therefore, if you use an database, it should not affect the use-cases, and in principle not even as an external actor.

Use-cases should focus on actor goals or subgoals. If you want to describe the details of how these goals are addressed, you'd better go for an activity diagram.

By the way, about login see here.

Answer 2

Echoing @Chirstophe's answer. Although your current diagram fits on a single page really no one is going top be interested in login, account management etc.

You should split it into the key use cases for your system and give them a whole diagram each. This will allow you to expand on them while also keeping them concise and business goal orientated.

Regarding your direct question, whether to include the DB. Although it can often be a detail I think you should include it here as the stored information seems to directly affect your business ideas.

1. Show what patient data is retained. Likely to have legal ramifications
2. Show how the data is fed back into any AI models and learning - this is key to your idea.
3. Show if the patient can browse other stored info, ie "treatment and tips" and how this differs from the AI generated diagnosis

As it is Your diagram could almost be for a totally offline, no stored data system. Which would be qualitatively different from an online lots of stored data system.