Reputation: 527
I'm doing a requirements analysis for a system and currently I try to write the business use cases (BUC) and make business use case diagram. I currently use the following guidelines:
When I have optional extra steps for a BUC I use an EXTEND-statement to point to the BUC where these optional steps can be found. Both the BUC that extends and the one that is extended can exist on it's own.
When I have duplicate functionality in multiple BUC's I try to extract the this and put it in a separate BUC. Then I use an INCLUDE-statement in the BUC where I extracted the functionality, to point to the BUC where this functionality can be found. The BUC in which you point to the external BUC with the INCLUDE-statement cannot work on it's own.
This all worked fine for until I arrived at the following situation:
I considered following options:
Any thoughts?
Upvotes: 1
Views: 261
Reputation: 36305
From your description you are not making a use case synthesis, but a functional decomposition. This is plain wrong. The point in use case synthesis is to focus on the added value a use case gives to its actor and not to decompose any functionality.
I strongly recommend to read Bittner/Spence and understand the basics before proceeding in the direction you are going - respectively to walk back and aim for the right target.
Upvotes: 0
Reputation: 6318
include
is used when (and only when) the included UC is run always when the main UC is run.
extend
is used when it is possible to finish the main UC without running the extending UC, but in some of alternate flows the extending UC is run as well.
So in your case you should use extend
.
It is possible to show extension points. You can use that to explain the logic (clarify that the extending UC is run always when entering the alternate flow). If the logic is more complex, you can also put it in a comment.
I'm not discussing here if your decomposition is a right approach at all (but do expect such discussion from others).
Upvotes: 2