At the moment, I have defined 3 different use cases that are really just 3 steps in a business process ...
Say I have a list of people, and all these people are interested in obtaining one or more limited resources (say for example, they are seats at concerts).
Ultimately, I want to automatically and fairly allocate these people to the available seats. I have a few different algorithms I use to do this.
I am documenting a system that already exists (retrospectively), so even through the process is a little convoluted, I can't change it. The process I have to use is as follows:
1) Define a set of criteria. The criteria can be attributes of the people, or attributes of the event.
For example, any of these might be a "set" - Female people for the Rod Stewart Concert - All people for the Madonna concert - "Gold" people and "Silver People" for all Rock Concerts
2) Define an "allocation job" by doing the following: Give it a name, choose ONE of the algorithms, and choose a "set" (out of all the previously defined Sets).
3) Kick-off the allocation job you defined in Step 2. It runs in the background and you can look at the results later.
Now, any of the steps 1, 2, and 3 can be done in a single session at the computer. OR, you can do #1, save it, go away, and then come back later and do #2 and save it. Then the next day you can do number 3. Obviously there is a dependency between 1, 2, and 3 but they don't have to be done immediately one after another. #1 and #2 don't really have any business value on their own, they just sit there until someone comes along and does #3.
From a Use Case perspective, I originally had 1 and 2 as "includes" Use Cases but now I think that is wrong, because I think an "includes" should ALWAYS be included, every time you run the Use Case. And a Use Case should always be confined to a single session.
Now I am thinking:
Do 1 and 2 "extend" 3?
OR, since 1 and 2 don't really achieve anything until you do #3 ... do I write them all as a single Use Case, making all 3 steps optional?
OR, are they simply 3 different Use Cases? And there is a pre-condition on #2 that a "Set" exists, and on #3 that a "job" exists?
Write them as separate use cases. Only a use case that clearly adds value is of use to its actor. I'd say that all of the named UCs add such value and are self-standing. However, without knowing your domain I can not be sure. Maybe they form a single UC. This needs a detailed view.
Extend/include are bad design in UML (means OMG did not do a good job here). Trying to use E/I is almost always a sign of trying to use functional decomposition. But use cases are about the absolute opposite: synthesizing of functionality.
If necessary use pre and post conditions to control if a use case can be performed only after another one.
来源：https://stackoverflow.com/questions/32243605/what-is-the-best-way-to-structure-these-use-cases