Tanager
Use Case Model
Version 2.6 – Elaboration Phase 2
Revision History
|
Date |
Version |
Description |
Author |
|
14 Nov, 2005 |
1.0 - Inception Phase |
Initial revision. This specification will be refined and expanded during the life of the project. |
Bob Lavey |
|
01 Dec, 2005 |
1.1 – Inception Phase |
Revised with comments from Dr. Leavens’ review. |
Bob Lavey |
|
13 Dec, 2005 |
1.2 – Inception Phase |
Revised with comments from Dr. Leavens’ follow-up review. |
Bob Lavey |
|
30 Jan, 2006 |
1.3 – Inception Phase |
Revised with comments from Dr. Leavens’ follow-up review. |
Bob Lavey |
|
13 Dec, 2005 |
2.0 – Elaboration Phase 1 |
|
Bob Lavey |
|
14 Sep, 2006 |
2.1 – Elaboration Phase 1 |
Added Fully-Dressed Power Off Use Case. |
Bob Lavey |
|
12 Oct 2006 |
2.2 – Elaboration Phase 1 |
Added Fully-Dressed Use Cases for Play Music and Pause Music. |
Bob Lavey |
|
27 Oct 2006 |
2.3 – Elaboration Phase 1 |
Revised with comments from Dr. Leavens’ review. |
Bob Lavey |
|
24 Oct 2006 |
2.4 – Elaboration Phase 1 |
Revised with comments from Dr. Leavens’ review. |
Bob Lavey |
|
03 Dec 2006 |
2.5 – Elaboration Phase 2 |
Added Fully-Dressed Use Cases for Stop Music, View Playlist, Delete a Song, and Volume Adjustments. |
Bob Lavey |
|
10 Jan 2007 |
Updated based on comments from Dr. Leavens’ review. |
Bob Lavey |
Table of Contents
1.3. Definitions,
Acronyms, and Abbreviations
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; 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; 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 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 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. Play Music
2.4.1. Fully- Dressed Format
2.4.1.1. Brief Description
This use case describes the user playing downloaded songs on the system.
2.4.1.2. Scope
The Tanager system.
2.4.1.3. Level
User-goal.
2.4.1.4. Primary Actor
Music Listener.
2.4.1.5. Stakeholders and Interests
2.4.1.5.1. Music Listener
The Music Listener wants the system to play downloaded songs in the order dictated by the selected playlist.
2.4.1.6. Preconditions
The system has been previously booted up and one or more songs have been downloaded.
2.4.1.7. Postconditions (Success Guarantee)
The downloaded songs are playing in the order dictated by the currently-selected playlist.
2.4.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.4.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.4.1.10. Special Requirements
None.
2.4.1.11. Frequency of Occurrence
Every time the user wants to play songs using the Tanager system.
2.4.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.5. Pause Music
2.5.1. Fully- Dressed Format
2.5.1.1. Brief Description
This use case describes the user pausing music playback 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 pause music playback, and they want to be able to restart music playback from the point at which it was paused.
2.5.1.6. Preconditions
The system is playing downloaded music.
2.5.1.7. Postconditions (Success Guarantee)
Music playback has been paused.
2.5.1.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.5.1.9. Extensions
None.
2.5.1.10. Special Requirements
None.
2.5.1.11. Frequency of Occurrence
Every time the user wants to pause music playback.
2.5.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.6. Stop Music
2.6.1. Fully- Dressed Format
2.6.1.1. Brief Description
This use case describes the user stopping music playback on the system.
2.6.1.2. Scope
The Tanager system.
2.6.1.3. Level
User-goal.
2.6.1.4. Primary Actor
Music Listener.
2.6.1.5. Stakeholders and Interests
2.6.1.5.1. Music Listener
The Music Listener wants the system to stop music playback.
2.6.1.6. Preconditions
The system is playing downloaded music.
2.6.1.7. Postconditions (Success Guarantee)
Music playback has been stopped.
2.6.1.8. Main Success Scenario
1. The user tells the system to stop music playback.
2. The system stops playing.
2.6.1.9. Extensions
None.
2.6.1.10. Special Requirements
None.
2.6.1.11. Frequency of Occurrence
Every time the user wants to stop music playback.
2.6.1.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. Fully- Dressed Format
2.10.1.1. Brief Description
This use case describes the Music Listener adjusting the volume of the playing song. The volume ranges from 0 to 20 and is incremented and decremented by 1 with each user request. If the user requests that the volume be adjusted higher than 20, the volume will snap back to 20. Similarly, if the user requests that the volume be adjusted lower than 0, the volume will snap back to 0.
2.10.1.2. Scope
The Tanager system.
2.10.1.3. Level
User-goal.
2.10.1.4. Primary Actor
Music Listener.
2.10.1.5. Stakeholders and Interests
The Music Listener wants to be able to adjust the volume of playing songs.
2.10.1.6. Preconditions
The system is playing a song.
2.10.1.7. Postconditions (Success Guarantee)
The volume level has been increased or decreased and has been saved to non-volatile memory. The new volume level will be used for the remainder of the currently-playing song and for all subsequent songs that are played until the user again executes this use case.
2.10.1.8. Main Success Scenario
1. The Music Listener requests the current volume setting from the system.
2. The Music Listener modifies the volume setting and tells the system the new volume setting.
3. The Tanager system verifies the volume setting is between 0 and 0 and saves the new volume level to non-volatile memory.
2.10.1.9. Extensions
3a. If the new volume setting is greater than 20.
1. The system snaps the volume setting to 20.
3b. If the new volume setting is less than 0.
4. The system snaps the volume setting to 0.
2.10.1.10.Special Requirements
None.
2.10.1.11.Frequency of Occurrence
This use case is executed each time the Music Listener wants to change the volume level.
2.10.1.12.Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
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. 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 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. Fully- Dressed Format
2.12.1.1. Brief Description
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.
2.12.1.2. Scope
The Tanager system.
2.12.1.3. Level
User-goal.
2.12.1.4. Primary Actor
Playlist Administrator.
2.12.1.5. Stakeholders and Interests
The Playlist Administrator wants to be able to delete a song from the current playlist.
2.12.1.6. Preconditions
The system is playing a song.
2.12.1.7. Postconditions (Success Guarantee)
The song selected by the Playlist Administrator has been deleted.
2.12.1.8. Main Success Scenario
1. The Playlist Administrator tells the system they want to delete a song.
2. The system builds a list of all the songs in the current playlist and provides that list to the Playlist Administrator.
3. The Playlist Administrator tells the system which song they want to delete from the play list.
4. The system deletes the chosen song from the playlist, rebuilds the playlist, and saves the system state to non-volatile memory.
2.12.1.9. Extensions
3a. If the Playlist Administrator chose the currently-playing song.
1. The system informs the Playlist Administrator that the currently-playing song cannot be deleted and returns to step 2.
3b. If the system is paused, and the Playlist Administrator chose the paused song.
1. The system informs the Playlist Administrator that the paused song cannot be deleted and returns to step 2.
2.12.1.10.Special Requirements
None.
2.12.1.11.Frequency of Occurrence
This use case is executed each time the Playlist Administrator wants to delete a song.
2.12.1.12.Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.13. View Playlist
2.13.1. Fully- Dressed Format
2.13.1.1. Brief Description
This use case describes the user viewing the currently-selected playlist.
2.13.1.2. Scope
The Tanager system.
2.13.1.3. Level
User-goal.
2.13.1.4. Primary Actor
Playlist Administrator.
2.13.1.5. Stakeholders and Interests
2.13.1.5.1. Playlist Administrator
The Playlist Administrator wants the system to provide the complete list of downloaded songs in the order dictated by the currently-selected playlist.
2.13.1.6. Preconditions
The system is playing powered on and is idle, paused, or playing music.
2.13.1.7. Postconditions (Success Guarantee)
The playlist has been displayed.
2.13.1.8. Main Success Scenario
1. The user asks the system to provide the playlist.
2. The system returns a list of all the downloaded songs ordered by the current playlist.
2.13.1.9. Extensions
None.
2.13.1.10.Special Requirements
None.
2.13.1.11.Frequency of Occurrence
Every time the user wants to display the playlist.
2.13.1.12.Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
3. Use Case Context Diagram
