T5 : Head-controlled Music Player(disabled people)
From SoftwarePractice.org
Contents |
Team Blog
Welcome to T5 internal blog!
[[ Team5 blog:UTS 48204]]
Introduction of the Project
We are planning to do the Head-controlled Music Player Project. Some severely physically disabled people lack the use of their limbs, but still have control of their head movements. A need has been identified for a device that can allow a person with only control of their head to interact with a sound system for playing recorded music.
The vision is for this device to consist of a small, wearable accelerometer that measures the direction, tilt and acceleration of the person's head in order to derive input control commands. The wearable device communicates over wireless with the sound system to control the selection, playback, volume, and so forth, of music. The sound system contains a graphical user interface that displays the current track, a playlist, duration of track, etc. The system can play tracks in .wav and .mp3 format.
The graphical user interface also contains a separate panel that shows a visual indication of the user’s head movements, and associated commands. You need to explore what kinds of head movements make sense for this application, and what commands they will represent. For this project you will develop a software prototype for this system. You will need to use the Java Sound API. It is up to you how you design the graphical user interface and what features you provide. It is envisaged that future applications may want to reuse the head movement monitoring part of the program, and provide different mappings from head movements to commands. You will need to simulate the accelerometer inputs (unless you happen to have an accelerometer! Although interfacing to the physical device is beyond the scope of this subject.) – you can do this by providing a mouse-operated GUI that mimics the head movements with some combination of mouse actions.
Team Members
Name and Student ID
Vince Duong 10460968
Ho Tak Lau 10202962 (Andy)
Eric Hui 02052037
Jie Liu 10467532 (Jasper)
Requirements
The head-controlled music player is designed to allow disabled people who lack the use of their limbs to interact with a sound system by using their head movement.
With the use of a small, wearable device attached to the head which consist of a accelerometer, allowing the measures of direction, tilt and acceleration to derive input control commands.
Functional Requirements
1. Contains a graphical user interface (GUI) that displays the current track and its details, the playlist, and the player functions such as play/pause, volume, etc.
2. The playback of .wav and .mp3 format sound files.
3. Display of visual indication of the user’s head movement and associated commands.
4. Able to manage playlists, storing track information such as its location and name.
Non-functional requirements
Able to derive the user input controls within a reasonable time. For inputs from the graphical user interface using the mouse/keyboard, the system should response in real-time. For inputs from the head movement controller, a second of delay is acceptable since the head controller must make sure the user has completed the input operation and it takes time.
Usability requirements
The head controlled music player is focused for disabled people, however, it should still allows a user friendly interface for non-disabled people to interact with, and to assist the disabled people in managing things such as the playlists. The graphical user interface should display a interface that allows both types of user to comfortably interacting with the player.
Stakeholders
In order to develop a sucessful product, it is important to gain a greater depth and awareness of the product itself. The first step in gaining this greater understanding is identifying key stakeholders and recognising their roles and influences on the product. This essentially means that we must constantly consider and incorporate stakeholder concerns throughout the development process. Identified key stakeholders:
1) Development Team - The team must develop a product that suits the end user's needs whilst complies to certain criterias and guidelines e.g. budgets and deadlines.
2) Testing and Quality Assurance Managers - These are the people responsible for the testing of the product and assuring that the product is ready to be used by consumers. They expect that the product is useable and free from any faults.
3) End Users - These are both disabled and non-disabled users. They expect the product to meet all their needs, have a user-friendly GUI and simple installation of software.
Usage Senarios
1. Peter who is physically disabled and lacks control of his limbs loves listening to music. He has access to a head-controlled music player, which allows him to interact with the music player by the use of head movement. After opening the program, the player automatically loads his most recently accessed play list, and Peter started the music playback by moving his head which is attached to a wearable head device that consist of a accelerometer.
2. Lisa, while listening to some playback music with her head-controlled music player, decided that she would like to repeat the same song after it finishes. She goes through the menu with the head controller and chooses the repeat song option. When the song repeats, she finds it troublesome to go through the options menu again having to just adjust the volume. However, due to the lack of control options from the head controller, she knows that it would be impossible to have more advanced functions if options menu aren’t implemented.
3. Ashley, a friend of Peter, has been asked by Peter to assist him in creating and adding songs to the playlist library. Even though it is possible for Peter to manage playlists using the head controller, Peter finds that it is a lot more efficient to have someone to manage his playlists using a mouse.
4. Katie who is physically disabled, lacking any control of her limbs uses the head-controlled music player while studying. She loves the head movement control, but often has problems when she unintentionally moves her head thus accidentally fast forwarding the song. She wants to put the player on hold.
5. Jason loves listening to music, he listens to his MP3 Player during all his spare time. However, he has now grown tired of the songs currently on his playlist and wants to create a new playlist of new songs.
Project Analysis
The Head-controlled Audio Player incorporates two fundamental components: The Head Movement Measurement System (HMMS) and the Audio Player System (APS). The team is separated into two smaller groups, each responsible for each of the two components.
Head Movement Measurement System (HMMS)
Component Managers: Jie Liu (Jasper) and Ho Tak Lau (Andy)
The HMMS component is associated with the Measurement kit and GUI. The measurement kit should provide an accurate measurment of direction from user's head movement and send the signal to the APS. The measurement kit receive the signal from user's head movement and transfer to computer understanded command to the APS(e.g. Downwards->choose input; Upwards->change frame input; Turn Left->next track input; Turn Right->previous track input,etc.) These commands is further to be use as input control in the other component of our music player.
Audio Player System (APS)
Component Managers: Eric Hui and Vince Duong
The APS component of the project is associated with the GUI and the Audio Player. The player should incorporate a reliable, efficient, attractive and user-friendly GUI, providing clear visuals demonstrating the main functions, options and operations of the player. The audio player provides options for the user to select a track, control the volume and playback (play, pause, stop, FF/FW), create/delete playlists and add/delete songs. The Audio Player and GUI will communiate with each other in a way that allows the user to effectively control the audio device.
Final Implementation
Jie Liu(Jasper) :Simulator and MP3 GUI Eric: AudioOutput Andy: Playlist Vince: playlist order-repeat, forward, random
Miniature Unified Process (MUP)
The Overview of MUP
The MUP is intended to provide sudents with a simple but effective way to manage and monitor progress of a significant software development assigment, throughout the course of a semester.
The Project Plan
Inception
Week 1-2 Due date: February 26, 2007
Requirements: Team registration (Form a team) Team meeting (Discuss the team logbook, team rules and fixed group meeting time) Complete the rough plan for head-controlled music system Review the Blue J and Java language. Team meeting
Design: Team meeting (Discuss the class diagrams and scenarios ) Create the team documentation on Wiki and confirm team member’s registration. Check individual logbook and discuss the unsolved problem.(First design notes in individual logbook) Construction: None Transition: None
Analysis for Next Phase: Identify key stakeholders Identify key risks
Elaboration
Week 2-4 Due date: March 19, 2007
Requirements: Team meeting(Discuss the written class diagrams and scenarios) Prepare the problems which are from last phase. Familiar with the Blue J
Design: Create key use cases Initial class diagram of all functional elements Initial sequence diagram of important interaction Sketch out the proposed user interface Put the class diagrams, scenarios, stakeholders, etc on the wiki’s team document.
Implementation: Start coding (Experimental programming) Team meeting (Find the programming barrier and Set up the essential classes)
Testing: None
Construction
Week 5-10 Due date: May 7, 2007
Project Milestone and Project Presentation Requirements: Prepare the problems which are from last phase. Team meeting Revise the use cases
Design: Complete the sequence diagrams CRC modeling Rearrange the user cases and interfaces Filter the classes.
Implementation:
Coding the main part of program (Design Patterns I: Object design and design by contract) Team meeting Re-coding the change of the classes Coding the main part of program (Design Patterns II: Building GUI in JAVA) Prepare for the Project presentation before VC week
Testing: Correct the self code error Team meeting (Solve the common problem and neck barriers)
Transition
Week 11-13 Due date: May 28, 2007
Requirements: None
Design: None
Implementation: Test case design and coding the test system Bugs coding Polish user interfaces
Testing: Team meeting: Fix remaining bugs and Solve the common problems Prepare demonstration (Finish and double check the Project Documentation, Complete the individual logbook) Wrap up and deliver system
Essential Use Cases
Classes
CRC Cards
Class Diagrams
The implemented class interface in Head Control Part:
java.awt.event.ActionListener, java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable, java.util.EventListener, javax.accessibility.Accessible, javax.swing.RootPaneContainer, javax.swing.WindowConstants
The implemented class interface in Media Player Part:
java.awt.event.ActionListener, java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable, java.util.EventListener, javax.accessibility.Accessible, javax.swing.RootPaneContainer, javax.swing.WindowConstants
Collaboration Diagram
Sequence Diagram
Jasper: This is the sequence diagram about playlist and delelt or add songs.
Variable use
Description:The variable is use to store the information we need to use play a music or other functions
numSong[]: which is a array and declare in global, it store the path location of the .mp3 or .wma
Test Cases
Test case-1
Description: All these four methods in the AudioOutput class are using the same test case which is used to test button reaction. The check box method is using systemprint to test the on Top function.
Method(Function) Play/stop/nextTrack/previousTrack Purpose Conncect with AudioOuput Input Button Action Output Play, stop, nextTrack or previousTrack Precondition None Postcondition MessageDialog Code: public void actionPerformed(ActionEvent e) {
// adaptee.play_actionPerformed(e);
if(e.getSource()==previousTrack)
* JOptionPane.showMessageDialog(null,"previousTrack");
try{}
catch(Exception ee){}
}
Test case-2
Method(Function) JCheckBoxMenuItem Purpose Always show the panel on top Input Item selected Output Show on top and print out ”onTop” Precondition None Postcondition print out "OnTop" Code: onTop=new JCheckBoxMenuItem("Player always on top",top);
choiceMenu.add(onTop);
onTop.addItemListener(new ItemListener()
{
public void itemStateChanged(ItemEvent e)
{
if(onTop.isSelected())
top=true;
else top=false;
setAlwaysOnTop(top); //System.out.println("OnTOP");
} }
Test case 3- playList Class
Result: A blink file (Assume .txt file) is created in Hard disk.
Result: The file with same path location and name will be deleted in Hard disk forever.
Result: The file will be read per line and the music path location(s) will be stored in the global variable numSong[] array for other function use.
Result: A new music path location will write to the end of the file with a new line.
Result: The same String (music path location) will be deleted and the next music path location will shift upward one line.
Test case-4
Method(Function) playMode Purpose Allows user to choose the type of playback mode for the playlist.
Test case-5
Class AudioOutput
Test case-6
Class AudioOutput
Screen Shot
Reference
Java™ Platform, Standard Edition 6 API Specification
http://java.sun.com/javase/6/docs/api/
Java JMF Performance Package
http://java.sun.com/products/java-media/jmf/2.1.1/download.html
Eben Hewitt, 2005, JAVA GARAGE, Prentice Hall Professional Technical Reference
http://www.javaworld.com/javaworld/jw-08-1996/jw-08-event.html
Java and event handling - Java World
http://dickbaldwin.com/tocadv.htm
Richard G Baldwin, Java and JavaScript Programming
Instructor comments
Good to see your team planning here. But what about the requirements and design work? Lian 21st March
Post presentation session milestone: Stakeholders are a bit limited - think of the diversity of "end users", eg. disabled and carers. Usage scenarios are good and show empathy with different disabled users needs. Could include more on head movements. Use cases are reasonably well done (although there is no reference to whether the user controls the system with their head or through a mouse). Choice of classes is fairly good, but what is the difference between the User Input and the User I/O class? Need to have CRC cards for all your classes that appear on the class diagram. With CRC cards, make sure you get the direction of collaboration right. For a given class responsibility, you state any classes that it needs to collaborate with to fulfil that responsibility. Not the other way around. Beware of the relationships between classes - don't overuse inheritance. With sequence and collaboration diagrams, your logical thinking seems okay, but your use of the notation is not quite right. Make sure you consult with me during class time to improve this. Lian 4th April
