Tanager
Use Case Model
Version 1.3 – Inception 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 |
Revised with comments from Dr. Leaven’s follow-up 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 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 Adminsitrator
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 palylist 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.
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. Brief Format
The
Music Listener tells the Tanager product to power off. The Tanager system responds by saving the
system state to non-volatile memory and powering down the system. This use case ends when the system has
powered down.
2.3. 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. 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. Casual Format
The Music Listener tells the system to play the downloaded songs. The system responds by playing the downloaded music files in the order dictated by the playlist. This use case ends when the system begins playing the downloaded music files.
Alternative Scenarios:
If the Tanager system is in a paused state (the Music Listener had previously paused the music playback), the system responds by restarting the music at the point at which it was paused. This use case ends when the system begins playing the downloaded music files.
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.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. The Playlist Administrator chooses to cancel the operation rather than providing a file name.
1. The system returns to the last known state.
4a. 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 the last known state.
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
