Are repeat, forward, rewind and stop extending usecases of the base usecase "Play Music" in a music player?

Question

I am confused in a scenerio, where i have a music player that has a music playlist. I need help on the following usecase of the music player.

Title :        Play the music playlist
Precondition:  Playlist not empty
.
.
.
Mainflow:

1) User adds music to a playlist.
2) User chooses the play option.
3) System plays the playlist.

Extensions:
.
.
.

Now the music player shows the user the options of:

a) Pause

b) Play

c) Step forward to the next song

d) Step back to the previous song

e) Repeat

Are the above options extending usecases of the main usecase mentioned above?, or are they just standalone usecases on their own without any relationship to the base usecase("Play the music playlist") above or which if any from the above have extend relationship with the base usecase. What makes me think they are extending usecases is that they add optional behaviour to the base usecase, for instance the user can press the repeat, forward or rewind button and then start to continue with the base usecase "Play the music playlist".On the other hand what makes me suspicious is that the options can be triggered even after the base usecase has been executed fully, for example even after the system has started playing the music playlist the user can choose all the above mentioned options (Repeat, Play, Pause, Forward, Rewind )

Answer 1

First, the precondition "Playlist not empty" does not seem to match your main flow: if your use case includes the operation of adding music to a playlist, one can actually start with an empty playlist. I would probably keep the precondition, but strip the first point from your main flow description.

But lets focus on your question. To my experience, use case modeling (for describing real scenarios, not just some artificial exercises), should just identify main usage scenarios and not dive too deep into the details, at least not at the diagram level.

If I imagine a real music player device, I can imagine immediately four different, "interesting" scenarios:

1. listening to music

2. downloading or storing music files (if it has some internal storage)

3. managing playlists

4. recording music, if it has recording capabilities

Note these headlines describe disjoint sets of activities. In a use case diagram for a player, I would not draw more than these four topics as bubbles for exactly these scenarios. All other things like how you actually operate the device, may occur in some verbal description at a lower level of detail, but not as bubbles like "use case extension" or "use case includes". Not because these bubbles are inherently wrong, but because it is not worth the effort to maintain that level of detail in a use case diagram. Don't forget use case diagrams are just a high level communication tool, not a low level programming tool.

If you look at the four use cases I scetched above, it becomes pretty obvious that "Pause", "Play", "Forward/Backward", "Repeat" are just details of the first use case, since they clearly do not belong to any of the other three. The best place for them is IMHO somewhere in the verbal description of use case #1.

However, if for exercising purposes, you feel urged to draw them in a diagram as "use case extensions", then go ahead, but for real software modeling I would avoid this, for the reasons mentioned above.

Answer 2

By considering your Mainflow, I am thinking the options will come under different mainflows:

1. User adds music to playlist : Repeat
2. User choose the play option : Forward and Backward
3. System plays the playlist: Play, Pause