简体   繁体   中英

Use Case Diagram which relationship to use

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 enter image description here

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 (ie 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".

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM