1
Uml Process / Organizing Use Cases
« on: February 23, 2019, 04:15:51 am »
Hello,
I've been taking a crack at loading use cases into Sparx and ran into a situation where I'd like to get guidance.
I have a number of use cases that rely on a common set of steps. Namely: checking if an object exists and checking if the requester has access to said object. I'd like to factor these steps out into their own standalone use cases so that I can include their behavior when necessary.
As a result, I created 2 use cases - "Check Authorization" and "Check Object Exists". They are each self-contained and have happy/sad paths as you would expect. In my primary use case, I "included" the auth check and exists check into the scenario steps where I expect them. All seems reasonable, however...
If I try to generate test cases or activity diagrams, this inclusion is lost. Activity diagrams no longer show branching that in the primary use case. Test cases don't generate variation.
My question is if the use of inclusion is recommended in this situation? I'm really just trying to avoid repeating alternate flow definitions and I want all the goodness that the tool can offer. How have you managed this kind of setup
Thanks,
Alejandro
I've been taking a crack at loading use cases into Sparx and ran into a situation where I'd like to get guidance.
I have a number of use cases that rely on a common set of steps. Namely: checking if an object exists and checking if the requester has access to said object. I'd like to factor these steps out into their own standalone use cases so that I can include their behavior when necessary.
As a result, I created 2 use cases - "Check Authorization" and "Check Object Exists". They are each self-contained and have happy/sad paths as you would expect. In my primary use case, I "included" the auth check and exists check into the scenario steps where I expect them. All seems reasonable, however...
If I try to generate test cases or activity diagrams, this inclusion is lost. Activity diagrams no longer show branching that in the primary use case. Test cases don't generate variation.
My question is if the use of inclusion is recommended in this situation? I'm really just trying to avoid repeating alternate flow definitions and I want all the goodness that the tool can offer. How have you managed this kind of setup
Thanks,
Alejandro