Tanager
Use Case Model
Version 3.4 – Elaboration Phase
Table of Contents
1.3. Definitions,
Acronyms, and Abbreviations
2.9. Skip
to the Previous Song
5. UI
Use Case Context Diagram
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. Diagrams
All diagrams in this document were generated using Gentleware’s Poseidon for UML tool.
1.2. References
Fowler, Martin. 2004. UML Distilled.
Larman, Craig. 2005. Applying UML and Patterns.
Poseidon for UML. 2005.
Gentleware AG. 20 January, 2007 <http://www.gentleware.com/uml-software-pe.html>.
1.3.
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
Every time the user initiates a session with the Tanager system: once or twice daily.
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 saved the system state and the playlist to non-volatile memory and is ready to exit.
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 informs the user it is ready to exit.
2.2.1.9. Extensions
None.
2.2.1.10. Special Requirements
None.
2.2.1.11. Frequency of Occurrence
Every time the user terminates a session with the Tanager system: once or twice daily.
2.2.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.3. Select Playlist Order
2.3.1. Fully- Dressed Format
2.3.1.1. Brief Description
This use case describes the user selecting a playlist order.
2.3.1.2. Scope
The Tanager system.
2.3.1.3. Level
User-goal.
2.3.1.4. Primary Actor
Playlist Administrator.
2.3.1.5. Stakeholders and Interests
2.3.1.5.1. Playlist Administrator
The Playlist Administrator wants the system to rebuild the playlist in the order specified and to remember this choice across power cycles.
2.3.1.6. Preconditions
The system has been previously booted up.
2.3.1.7. Postconditions (Success Guarantee)
The system has rebuilt the playlist in the order specified by the user and has saved the playlist to non-volatile memory.
2.3.1.8. Main Success Scenario
1. The user tells the system they to rebuild the playlist using the specified ordering.
2. The system rebuilds the playlist in specified order.
3. The system saves its playlist to non-volatile memory.
2.3.1.9. Extensions
None.
2.3.1.10. Special Requirements
None.
2.3.1.11. Frequency of Occurrence
Each time the user wishes to play music in a different order: several times per week.
2.3.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
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.
3. When the playing song ends, the system gets the next song in the playlist and plays it.
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.
3a. If there are no more songs in the playlist.
1. The system returns to an Idle state.
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: several times each day.
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: several times each day.
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: several times each day.
2.6.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.7. Skip to the Next Song
2.7.1. Fully- Dressed Format
2.7.1.1. Brief Description
This use case describes the Music Listener skipping to the next song.
2.7.1.2. Scope
The Tanager system.
2.7.1.3. Level
User-goal.
2.7.1.4. Primary Actor
Music Listener.
2.7.1.5. Stakeholders and Interests
The Music Listener wants to be able to stop playing the current song and skip to the next song.
2.7.1.6. Preconditions
The system is playing a song.
2.7.1.7. Postconditions (Success Guarantee)
The song that had been playing has stopped and the next song (in the current playlist’s order) has started playing.
2.7.1.8. Main Success Scenario
1. The Music Listener requests that the system skip to the next song.
2. The Tanager system stops playing the current song.
1. The system retrieves the next song in the playlist and begins playing it.
2.7.1.9. Extensions
3a. If there are no more songs in the playlist.
1. The system returns to an Idle state.
2.7.1.10. Special Requirements
None.
2.7.1.11. Frequency of Occurrence
This use case is executed each time the Music Listener wants to skip to the next song: once or twice each day.
2.7.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.8. Restart the Current Song
2.8.1. Fully- Dressed Format
2.8.1.1. Brief Description
This use case describes the Music Listener restarting the current song.
2.8.1.2. Scope
The Tanager system.
2.8.1.3. Level
User-goal.
2.8.1.4. Primary Actor
Music Listener.
2.8.1.5. Stakeholders and Interests
The Music Listener wants to be able to restart the current song from the beginning.
2.8.1.6. Preconditions
The system is playing a song.
2.8.1.7. Postconditions (Success Guarantee)
The song that had been playing has restarted at the beginning.
2.8.1.8. Main Success Scenario
1. The Music Listener requests that the system restart the current song.
2. The Tanager system restarts the current song from the beginning.
2.8.1.9. Extensions
None.
2.8.1.10. Special Requirements
None.
2.8.1.11. Frequency of Occurrence
This use case is executed each time the Music Listener wants to restart the current song: once or twice each day.
2.8.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
2.9. Skip to the Previous Song
2.9.1. Fully- Dressed Format
2.9.1.1. Brief Description
This use case describes the Music Listener skipping to the previous song.
2.9.1.2. Scope
The Tanager system.
2.9.1.3. Level
User-goal.
2.9.1.4. Primary Actor
Music Listener.
2.9.1.5. Stakeholders and Interests
The Music Listener wants to be able to stop playing the current song and skip to the previous song.
2.9.1.6. Preconditions
The system is playing a song.
2.9.1.7. Postconditions (Success Guarantee)
The song that had been playing has stopped and the previous song (in the current playlist’s order) has started playing.
2.9.1.8. Main Success Scenario
1. The Music Listener requests that the system skip to the previous song.
2. The Tanager system stops playing the current song.
3. The system retrieves the previous song in the playlist and begins playing it.
2.9.1.9. Extensions
3a. If the song that had been playing is the first song in the playlist.
1. The system begins playing the first song in the playlist.
2.9.1.10. Special Requirements
None.
2.9.1.11. Frequency of Occurrence
This use case is executed each time the Music Listener wants to skip to the previous song: once or twice each day.
2.9.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
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 20 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.
1. 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: once or twice each day.
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 download a song to the system. 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 and they provide the path and filename of the song.
2. 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
2a. 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.
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: this will occur very often when the user first begins using Tanager, but it will taper off to once or twice each week as their playlist become more mature.
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 retrieves a list of all the songs in the current playlist, chooses the song to delete from that list, and tells the system which song they want to delete. The system responds by 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 retrieves a list of all the songs in the current playlist from the system.
2. The Playlist Administrator tells the system which song they want to delete from the playlist.
3. 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.
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.
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: less than once per week.
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 retrieving 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 retrieved.
2.13.1.8. Main Success Scenario
1. The Playlist Administrator requests the playlist from the system.
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 view the playlist: once or twice each day
2.13.1.12.Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
3. Use Case Context Diagram
4. UI Use Cases
4.1. Enter Menus
4.1.1. Fully- Dressed Format
4.1.1.1. Brief Description
This use case describes the user entering the menus.
4.1.1.2. Scope
The Tanager UI.
4.1.1.3. Level
User-goal.
4.1.1.4. Primary Actor
Playlist Administrator.
4.1.1.5. Stakeholders and Interests
4.1.1.5.1. Playlist Administrator
The Playlist Administrator wants the UI to display the main menu.
4.1.1.5.2. Music Listener
The Music Listener wants the UI to display the main menu.
4.1.1.6. Preconditions
The system is playing powered on and is not displaying a menu.
4.1.1.7. Postconditions (Success Guarantee)
The UI has displayed the main menu.
4.1.1.8. Main Success Scenario
1. The user presses the menu button on the UI to enter the menus.
2. The UI displays the main menu.
4.1.1.9. Extensions
None.
4.1.1.10. Special Requirements
None.
4.1.1.11. Frequency of Occurrence
Every time the user wants to enter the menus: once or twice each day.
4.1.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
4.2. Exit Menus
4.2.1. Fully- Dressed Format
4.2.1.1. Brief Description
This use case describes the user exiting the menus.
4.2.1.2. Scope
The Tanager UI.
4.2.1.3. Level
User-goal.
4.2.1.4. Primary Actor
Playlist Administrator.
4.2.1.5. Stakeholders and Interests
4.2.1.5.1. Playlist Administrator
The Playlist Administrator wants the UI to exit the menus.
4.2.1.5.2. Music Listener
The Music Listener wants the UI to exit the menus.
4.2.1.6. Preconditions
The UI is displaying a menu.
4.2.1.7. Postconditions (Success Guarantee)
The UI is no longer displaying a menu.
4.2.1.8. Main Success Scenario
1. The user presses the menu button the exit the menus.
2. The UI responds by exiting the menus.
4.2.1.9. Extensions
None.
4.2.1.10. Special Requirements
None.
4.2.1.11. Frequency of Occurrence
Every time the user wants to exit the menus: once or twice each day.
4.2.1.12. Open Issues
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|
5. UI Use Case Context Diagram
6. 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 |
2.6 – Elaboration Phase 2 |
Updated based on comments from Dr. Leavens’ review. |
Bob Lavey |
|
29 Dec 2006 |
3.0 – Elaboration Phase 3 |
Added Fully-Dressed Use Cases for Enter Menus and Exit Menus. |
Bob Lavey |
|
11 Jan 2007 |
3.1 – Elaboration Phase 3 |
Merged out from version 2.6 - Updated based on comments from Dr. Leavens’ review. |
Bob Lavey |
|
12 Jan 2007 |
3.2 – Elaboration Phase 3 |
Modified nearly all of the use cases to remove UI-isms. |
Bob Lavey |
|
15 Jan 2007 |
3.3 – Elaboration Phase 3 |
Added Fully-Dressed Use Cases for Select Playlist Order, Restart Current Song, Skip to Next Song, and Skip to Previous Song. |
Bob Lavey |
|
19 Jan 2007 |
Updated based on Dr. Leavens’ review. Moved Enter Menus and Exit Menus to the new UI Use Case section. |
Bob Lavey |