Use Case Diagram which relationship to use

Question

I have a use case "manage login and security" (MA01) which is described as follows: As a user I want to be able to navigate to the login & security screen in myaccount to be able to manage my credentials.

There is another use case called "Manage account details" (MA03) which is described as follows: As a user I want to manage my access data (email, password).

There are many more use cases like the second one. There are more use cases which are more and more specific. So for example the use case "change email" (MA03 001) which is a possible use case for managing the account details.

How do I show that in a use case diagram?

Is this a generalization relationship between the use cases? The first is very general and wants to manage the login and security; the other use case is more specific and wants to manage the account details. Workflow of use case manage login and security looks like this

Answer 1

There are various opinions on how to apply the use-case technique. Your team seems to have an unfamiliar approach, but I won't comment on that. You have use cases and detailed flow descriptions and now you want to create a use case diagram to get a visual overview of these use cases. The question is which relationships to use between the use cases in the diagram. I will summarize the available relationship types and when to use them. Finally, I will draw conclusions about which relationships are applicable in the examples you have provided.

«include»

If the flow of use case UC1 contains a step that says "Now execute UC2" or "Perform UC2" or whatever, then the use case diagram should have an «include» relationship between UC1 and UC2, with the arrow pointing from UC1 to UC2.

Side note: Many people interpret UML such, that the «include» relationship only exists if UC1 always executes UC2, but in my opinion, it also exists if UC1 executes UC2 only under certain conditions.

«extend»

If the flow of use case UC1 contains an extension point EX1 (i.e. a point in the flow where UC1 can be extended, without any reference to a use case that contains the extension) and use case UC2 specifies steps to be inserted at extension point EX1 in UC1, then the use case diagram should have an «extend» relationship between UC1 and UC2, with the arrow pointing from UC2 to UC1. In the use case diagram, you may also mention the names of the extension points. If you want details about this, please refer to the UML 2.5.1 specification, chapters 18.1.4 and 18.1.5.

generalization

If UC1 and UC2 are similar, but UC1 is more general than UC2 and UC2 is more specific than UC1, then the use case diagram may have a generalization relationship between UC1 and UC2, with the arrow pointing from UC2 to UC1. For example, UC1 is "Buy a product" and UC2 is "Buy a food product". The description of UC2 says how it differs from UC1, but UC1 does not have any reference to more specific use cases. If UC1 shall not be executed on its own, but only the more specific use cases, then UC1 shall be marked as {abstract}.

Conclusion

There may be a generalization from use case MA03 "Manage account details" to MA01 "Manage login and security", but only if all account details can be regarded as login and security details and MA01 does not refer to MA03.

The relationship between MA03 and MA03.001 depends on how the flows of these use cases are specified. Please refer to the descriptions above to determine which relationship applies here.

There shall be an «include» relationship from use case "Display Login & Security" to use case "Set password", because the former use case says, at step 3: "Perform process UC-MA11 - Set password".

Answer 2

The description of Display login & security in the history of your post corresponds indeed to the step by step description of a very detailed use-case at sub-function level. Although UML allows to do such a functional decomposition, it is not recommended, as it leads to cluttered use-case diagrams with little added value compared to the tabular description that you already have.

I think Admiraal's answer provides all the necessary information if you want to pursue this way. I'd just add that Change email is in no way a specialization of Manage account details, since you cannot use the former as a substitue for the latter, it's just a part of it.

It appears however, the wording of your question (e.g. "workflow") and of your UC description (e.g. "action", "perform process UC-MA11-Set password") suggests that you're not really modelling use-cases but that you're rather modelling activities. For this an activity diagram would be much more suitable and value adding than an UC, because it allows you to show the successive steps, the sequencing of steps, and the call of activities ("processes") that can be specified in more detail in another diagram. In this case, you'd keep as use-case only the highest level of your current UC modeling, which may then more probably look as user goals.