Here's my perspective
yes you can get down this rabbit hole but there's a better way.
You are mixing what the user wants to achieve with how the system does it. This is the typical pitfall of functional decomposition. Very non-UML and very non-object oriented. It leads to very large, complicated and less useful models.
My approach would be: neither is a good use case. The use case should show WHO wants to check authorization and object existence and WHY they want to check it. In other words, what are they trying to achieve?
The mechanics of HOW the system achieves the user goals should be completely out of the use case model. The mechanics should be described in sequence diagrams, because the lifelines will guide you directly to define a good, simple and efficient class diagram.
Activity diagrams are of very little value because they show procedural logic without reference to the objects or their classes. So you don't get much benefit from them. Activity diagrams are useful to define class methods and user interfaces. If you need to describe complex object transformations, statecharts are much better.
End of rant: use case models (and package diagrams) are deceptively simple and easy to draw. But it takes a few years of practice to use them correctly (system architecture, implementation approach, project management, vendor management, testing....). Just keep practicing and eventually you'll get it!
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
