Tanager
Use Case Model
Version 2.4 – Elaboration Phase 1 Draft
Revision History
|
Date |
Version |
Description |
Author |
|
14 Nov, 2005 |
1.0 - Inception Draft |
Initial revision. This specification will be refined and expanded during the life of the project. |
Bob Lavey |
|
01 Dec, 2005 |
1.1 – Inception Draft |
Revised with comments from Dr. Leaven’s review. |
Bob Lavey |
|
13 Dec, 2005 |
1.2 – Inception Draft |
Revised with comments from Dr. Leaven’s follow-up review. |
Bob Lavey |
|
30 Jan, 2006 |
1.3 – Inception Draft |
Revised with comments from Dr. Leaven’s follow-up review. |
Bob Lavey |
|
13 Dec, 2005 |
2.0 – Elaboration Phase 1 Draft |
|
Bob Lavey |
|
14 Sep, 2006 |
2.1 – Elaboration Phase 1 Draft |
Added Fully-Dressed Power Off Use Case. |
Bob Lavey |
|
12 Oct 2006 |
2.2 – Elaboration Phase 1 Draft |
Added Fully-Dressed Use Cases for Play Music and Pause Music. |
Bob Lavey |
|
22 Oct 2006 |
2.3 – Elaboration Phase 1 Draft |
Revised with comments from Dr. Leaven’s review. |
Bob Lavey |
|
24 Oct 2006 |
Revised with comments from Dr. Leaven’s review. |
Bob Lavey |
Table of Contents
1.3. Definitions,
Acronyms, and Abbreviations
2.4. Select
Sequential Playlist
2.9. Skip
to the Previous Song
Use Case Model
1. Introduction
1.1. Purpose
This document provides the use case descriptions for the Tanager project. Using the process described in Larman’s Applying UML and Patterns (66), use cases are first filled in with a brief description, then are further refined into a Casual format, and are finally refined into a Fully-Dressed format.
1.2. Scope
This document describes the use cases for the Tanager project.
1.3. Definitions, Acronyms, and Abbreviations
A complete list of definitions, acronyms, and abbreviations can be found in the Tanager Glossary.
1.1. References
Larman,
Craig. 2005. Applying UML and Patterns.
1.2.
Overview
This document will summarize the goals and use of the software-based Tanager project by its users. It will describe how the users will use the system, and how they expect the system to behave.
2. Use Cases
2.1. Power On
2.1.1. Fully- Dressed Format
2.1.1.1. Brief Description
This use case describes the user turning on the system.
2.1.1.2. Scope
The Tanager system.
2.1.1.3. Level
User-goal.
2.1.1.4. Primary Actor
Music Listener.
2.1.1.5. Stakeholders and Interests
2.1.1.5.1. Music Listener
The Music Listener wants the system to boot up without errors and without crashing the computer it’s running on; for the system to restart at the last known state, if the system can find a valid last known state; and for the system to be in a state where it can accept commands to play music.
2.1.1.5.2. Playlist Administrator
The Playlist Administrator wants the system to boot up without errors and without crashing the computer it’s running on; for the system to restart at the last known state, if the system can find a valid last known state; and for the system to be in a state where it can accept commands to manipulate the playlist of downloaded songs.
2.1.1.6. Preconditions
None.
2.1.1.7. Postconditions (Success Guarantee)
The system has booted up and is available for the user to interact with, and the system state has been saved to non-volatile memory.
2.1.1.8. Main Success Scenario
1. The user tells the system to power on.
2. The system checks its non-volatile memory to determine its last known state, finds a valid last known state, and initializes itself to that last known state.
3. The system saves its current state to non-volatile memory.
4. The system tells the user is it ready to accept commands.
2.1.1.9. Extensions
2a. No valid last known state is found in non-volatile memory.
1. The system does not find a valid last known state in its non-volatile memory, so it initializes to a default state.
2.1.1.10. Special Requirements
None.
2.1.1.11. Frequency of Occurrence
Once per use of the Tanager system.
2.1.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.2. Power Off
2.2.1. Fully- Dressed Format
2.2.1.1. Brief Description
This use case describes the user turning off the system.
2.2.1.2. Scope
The Tanager system.
2.2.1.3. Level
User-goal.
2.2.1.4. Primary Actor
Music Listener.
2.2.1.5. Stakeholders and Interests
2.2.1.5.1. Music Listener
The Music Listener wants the system to shut down without errors and without crashing the computer it’s running on and for the system to save its state, so it can restart in the same state it was in when it was shut down.
2.2.1.5.2. Playlist Administrator
The Playlist Administrator wants the system to shut down without errors and without crashing the computer it’s running on and for the system to save the current list of downloaded songs.
2.2.1.6. Preconditions
The system has been previously booted up.
2.2.1.7. Postconditions (Success Guarantee)
The system has shut down, and the system state has been saved to non-volatile memory.
2.2.1.8. Main Success Scenario
1. The user tells the system to power off.
2. The system saves its current state to non-volatile memory.
3. The system saves its playlist to non-volatile memory.
4. The system powers itself off.
2.2.1.9. Extensions
None.
2.2.1.10. Special Requirements
None.
2.2.1.11. Frequency of Occurrence
Once per use of the Tanager system.
2.2.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.3. Select Random Playlist
2.3.1. Brief Format
The Music Listener tells the system to rebuild the playlist in random order. The Tanager system responds by saving the Music Listener’s choice and rebuilding the playlist in random order. This use case ends when the playlist has been rebuilt.
2.4. Select Sequential Playlist
2.4.1. Brief Format
The Music Listener tells the system to rebuild the playlist in the order in which the songs were downloaded. The Tanager system responds by saving the Music Listener’s choice and rebuilding the playlist in the order in which the songs were downloaded. This use case ends when the playlist has been rebuilt.
2.5. Play Music
2.5.1. Fully- Dressed Format
2.5.1.1. Brief Description
This use case describes the user playing downloaded songs on the system.
2.5.1.2. Scope
The Tanager system.
2.5.1.3. Level
User-goal.
2.5.1.4. Primary Actor
Music Listener.
2.5.1.5. Stakeholders and Interests
2.5.1.5.1. Music Listener
The Music Listener wants the system to play downloaded songs in the order dictated by the selected playlist without errors and without crashing the computer it’s running on.
2.5.1.6. Preconditions
The system has been previously booted up and one or more songs have been downloaded.
2.5.1.7. Postconditions (Success Guarantee)
The downloaded songs are playing in the order dictated by the currently-selected playlist.
2.5.1.8. Main Success Scenario
1. The user tells the system to play music.
2. The system checks that it is not in a paused state, and it begins playing the currently-selected playlist from the beginning.
2.5.1.9. Extensions
2a. If the system is in a paused state (the Music Listener had previously paused the music playback).
1. The system begins playing the currently-selected playlist from the point at which it was paused.
2.5.1.10. Special Requirements
None.
2.5.1.11. Frequency of Occurrence
Every time the user wants to play songs using the Tanager system.
2.5.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.6. Pause Music
2.6.1. Brief Format
The Music Listener tells the system to pause playing downloaded music. The Tanager system responds by stopping the music and saving the position at which the music stops playing. This use case ends when the system has saved the position at which the music stopped playing.
2.6.2. Fully- Dressed Format
2.6.2.1. Brief Description
This use case describes the user pausing music playback on the system.
2.6.2.2. Scope
The Tanager system.
2.6.2.3. Level
User-goal.
2.6.2.4. Primary Actor
Music Listener.
2.6.2.5. Stakeholders and Interests
2.6.2.5.1. Music Listener
The Music Listener wants the system to pause music playback without errors and without crashing the computer it’s running on, and they want to be able to restart music playback from the point at which it was paused.
2.6.2.6. Preconditions
The system is playing downloaded music.
2.6.2.7. Postconditions (Success Guarantee)
Music playback has been paused.
2.6.2.8. Main Success Scenario
1. The user tells the system to pause music playback.
2. The system stops playing and saves the point at which playback stopped.
2.6.2.9. Extensions
None.
2.6.2.10. Special Requirements
None.
2.6.2.11. Frequency of Occurrence
Every time the user wants to pause music playback.
2.6.2.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.7. Skip to the Next Song
2.7.1. Brief Format
The Music Listener tells the system to skip over the rest of the current song and start playing the next song. The Tanager system responds by stopping the current song and playing the next song in the order dictated by the current playlist. This use case ends when the system begins playing the next song.
2.8. Restart the Current Song
2.8.1. Brief Format
The Music Listener tells the system to restart the current song. The Tanager system responds by stopping the current song and restarting it from the beginning. This use case ends when the system begins playing the beginning of the current song.
2.9. Skip to the Previous Song
2.9.1. Brief Format
The Music Listener tells the system to skip the rest of the current song and start playing the previous song. The Tanager system responds by stopping the current song and playing the previous song in the order dictated by the current playlist. This use case ends when the system begins playing the previous song.
2.10. Volume Adjustments
2.10.1. Brief Format
The Music Listener tells the system to increase or decrease the volume of the music. The Tanager system responds by using the requested setting for played music and saving the new volume setting to non-volatile memory. This use case ends when the new volume setting has been saved.
2.11. Download a Song
2.11.1. Fully- Dressed Format
2.11.1.1. Brief Description
This use case describes the Playlist Administrator downloading a song.
2.11.1.2. Scope
The Tanager system.
2.11.1.3. Level
User-goal.
2.11.1.4. Primary Actor
Playlist Administrator.
2.11.1.5. Stakeholders and Interests
The Playlist Administrator wants to be able to access the Download a Song menu item, select their song, and have the system download it without crashing or hanging. They also want the system to rebuild the playlist with the new song and save the new system state.
2.11.1.6. Preconditions
The Playlist Administrator has executed the Power On use case.
2.11.1.7. Postconditions (Success Guarantee)
The selected song has been processed, the playlist has been rebuilt, and the system state has been saved to non-volatile memory.
2.11.1.8. Main Success Scenario
1. The Playlist Administrator tells the system they want to download a song.
2. The Tanager system queries the Playlist Administrator for the name of the music file they want to download
3. The Playlist Administrator tells the system the name of the music file
4. The system verifies the music file exists, adds the song to the playlist, and saves the system state to non-volatile memory.
2.11.1.9. Extensions
3a. If the Playlist Administrator chooses to cancel the operation rather than providing a file name.
1. The system returns to the last known state.
4a. If the system cannot find the file with the file name given by the Playlist Administrator.
1. The system informs the Playlist Administrator that the file name is invalid and returns to step 2.
2.11.1.10.Special Requirements
None.
2.11.1.11.Frequency of Occurrence
This use case is executed each time the Playlist Administrator has a new music file to be downloaded to the Tanager system.
2.11.1.12.Open Issues
|
Issue |
Owner |
Status |
|
Do we need to verify any characteristics of the music file when it’s downloaded? Should we verify it’s playable, for example? |
Bob Lavey |
Open |
|
|
|
|
|
|
|
|
2.12. Delete a Song
2.12.1. Brief Format
The Playlist Administrator tells the system they want to delete a downloaded song. The system responds by asking the Playlist Administrator for the name of the song to be deleted, deleting the song, rebuilding the playlist, and saving the system state to non-volatile memory. This use case ends when the system state has been saved to non-volatile memory.
3. Use Case Context Diagram
