Team 8: Head-Controlled Music Player
From SoftwarePractice.org
Introduction
It has been brought to our attention that there are a number of severely physically disabled people that lack the use of their limbs, but still have control of their head movements. A need has been recognised for a device that can permit a person with only control of their head to interact with a sound system for playing recorded music.
The image behind this device is for it to consist of a small, wearable accelerometer that measures the direction, tilt and acceleration of the person’s head in order to obtain input control commands. The wearable device communicates over wireless with the sound system to control the selection, playback, volume and many more characteristics. The sound system contains a graphical user interface that displays the current track, a playlist, duration of track, etc.
The graphical user interface also contains a separate panel that shows a visual indication of the user’s head movements, and associated commands. It is also needed to explore what kinds of head movements make sense for this application, and what commands they will represent.
In order to develop a software prototype for this system, Java Sound API will need to be used. There are many ways in which we, as a group, can design the graphical user interface and what features we make available.
Team Members
- Smita Pati
- Rachelle Gharios
- Denish Ardeshna
- Jyotishko Das
Our Game Plan using the Miniature Unified Process
Weeks 2 and 3 - Requirements
It was decided what the program was required for and what it required. We evaluated all sides of needs expressed by consumers and have recognised the need to make the project very simple not only for the disabled user but also for the programmer in order to debug and maintain the system.
Use cases were identified. We, interestingly, landed up with requirements which were contradictory in nature but both were to be met. Example is which head movement was to be reconised.
Weeks 4 and 5 - Design
The basic design of the outlay of the project was decided upon, keeping firmly in mind that the program was to be kept as simple as possible both from the standpoints of programmer readability and user usage. CRC cards developed in alignment with requirements.
Weeks 6, 7 and 8 - Implementation
The actual implementation of the design is to be done using the java programming language. Research is to be done as to how we can implement interfaces and listeners and handle events.
Must be able to use java's files specific to playback of music.
Weeks 9, 10 and 11 - Testing
Test cases are to be prepared keeping in mind the use cases prepared by us earlier and thus testing is to be done extensively to cover all angles and make the program as fail proof as possible and add further improvements where possible.
Environment
Our team has unanimously decided to work on a different environment for this project. We would be using Visual J# in .NET Framework.
TESTING
Unit Testing is by NUnit in Visual J# .NET
Stakeholders
- DISABILITY ORGANISATIONS/GENERAL USERS - They would require the system
- SYSTEM DESIGNERS - Responsible for design , development as well as maintenance
- WHOLESALERS & RETAILERS - To be able to make the system available to users
- AUTHORISED REPAIR CENTRE - For repair and replacement coordinated with system designers and the organisation
- SYSTEM ADMINISTRATION - Coordinates with all other stakeholders
- END USERS NEEDS - Change, improvisations and additions to system
Scenarios
Disabled Users
- Scott, a 17 year old ,enjoys moving his head to the beat while listening to music.He gets very annoyed when the accelerometer misinterprets his head movements and skips or fast forwards a song instead of simply playing it.
- 25 year old Peter,gets bored hearing the songs in his playlist in the same order.
- Christina, a 36 year old , wants to listen to her favorite song again and again but dislikes going over the song list repeatedly.
- Adam, who is a 35year-old with an independant personality, dislikes the fact that he cannot browse and add songs to the playlist himself, he has to ask for help from others.
- All thanks to the incorporation of Windows Media Player into the head controlled music system, Sussanah ,a teenager ,is thrilled to bits due to the fact that she can even see videos of her favourite songs and not just be able to hear them!
Non-Disabled Users
- Hanna is a busy young lady of just 21 and after a hard day at the check-out counters at a supermarket, she finds it very convenient to control the music system without making use of her hands, but by simple head movements only!
- Though Mr.McKain ,a grand-dad in his early sixties,hates technology and thinks that they are a hassle to operate, he finds the music player to be easy to use. Further, due to instructions being right on the front page and explained in simple terms, he cant stop listening to his favourite country music all day long!
- As 26 year old ,Henry is very much used to playing his songs using Windows Media Player,he finds it so much easy to operate the head controlled music system , which has Windows Media Player incorporated in it.
Use-case Diagrams
This use case easily explains the fact that both users(disabled or non-disabled)are able to perform the same actions.
The key aim of our group has been to keep the design simple so that the disabled user can use it easily. Therefore we have kept the number of classes to a minimum and included most of the functionality as methods in classes.
This design, we forecast, will be helpful when updating and/or maintaining the player.
Essential Use Case
Selecting Playlist
Selecting Shuffle Option
Pause Song
Play Song
Rewind or Fast Forward Song
Head Movements and Related Mouse Movements
This tells us what the music player interprets when we either use the mouse or the head movemement.
Play Single-Click
Stop Double-Click
Skip Back Move mouse / head Left
Skip Forward Move mouse/head Right
Volume Up Move Up mouse/head
Volume Down Move Down mouse/head
GUI Interface
This is first attempt of basic design of the outlay of the project in our design interphase:
This is one of the final design we came up with by the end of the design interphase:
CRC Cards
Class Diagrams
Sequence Diagrams
Test Cases
System Test Case 1
Test Case Description
This test case contains all the information necessary to verify the testing of the file type extension.
Purpose:
This test case is divided into two parts a and b:
- The purpose of part a in the test case is to test the file type extensions of all the files imported to the HeadControlPlayer.
- The purpose of part b of the test case is to test whether the program repens a new Dialog after the user attempt to import the wrong file type.
Design Specification for the new methods of the G8HeadControlPlayer class:
Test Case 1a:
Involves testing the various file types that are imported to the media player by the users. Throughout this testing it has insured that the user is only allowed to import the specificied file type extensions. However if the user does prompy to add a file that the player does not support an error message pops up notifing the user of the wrong file type added.
Test Case 1b:
Elaborating on Test Case 1a, part b of this testing just Repens a new Dialog for the user after a wrong file type was being attempted to be added previously
System Test Case 2
Test Case Description
This test case contains all the information necessary to verify the testing of the delete button when there are no songs in the playlist to be deleted.
Purpose:
This test case is divided into two parts a and b
- The purpose of part a is to test that the delete button is set disabled if there are no songs in the playlist to delete. Otherwise the delete button becomes enabled once there are songs present in the playlist.
- The purpose of part b is to test the songIndex value. Executing the method GetNumberOfSongs is the songIndex < = 0
Design Specification for the new methods of the G8HeadControlPlayer class:
TestCase 2a:
Involves disabling the delete button, located on the bottom of the GUI, when there are no songs in the playlist to be deleted. By doing so, this prevents the program from crashing.On the otherhand the delete button is enabled again once there are songs in the playlist.
Test Case 2b:
This tests the value of the songIndex and if its less than or equal to 0 GetNumberOfSongs() is called.
System Test Case 3
Test Case Description
This test case contains all the information necessary to verify the testing of the delete button when a song in playing.
Purpose:
- The purpose of this test class is to test performance of the delete button once there are songs playing in the playlist.
Design Specification for the new methods of the G8HeadControlPlayer class:
Test Case 3:
Includes testing the ability of the program to delete a song while it is playing. Throughout this test case it was ensured that when a song is playing and the button delete is press it makes the song stop playing and delete it out of the array.
System Test Case 4
Test Case Description
This test case contains all the information necessary to verify the testing of volume, Skip track backwards, Skip track forward.
Purpose:
- The purpose behind this test case is to basically test the boudries and functionalities of volume, skip track backwards, skip track forward. in the HeadControl area
Design Specification for the new methods of the G8HeadControlPlayer class:
Test Case 4:
Involves testing the volume controlled in the Head Control area as well as it boundaries. This test case also involves testing the skipforward and skipbackward function as well as insures that the mouse is kept in the specified region.
References
- This is a specification for a two-axis accelerometer. It can measure acceleration in two orthogonal directions (X and Y). This means that you can easily derive parameters like tilt, direction and speed.
- Here is a description of how an accelerometer works:
- This publication describes the application of artificial neural networks for processing and recognising head movement commands. What is useful for this project is their set of head movements such as "forward nod" and "forward hold".
- P.B. Taylor, H.T. Nguyen, “Performance of a head-movement interface for wheelchair control”, Engineering in Medicine and Biology Society, 2003. Proceedings of the 25th Annual International Conference of the IEEE, Vol.2, 17-21 Sept. 2003, p. 1590-1593
- http://ieeexplore.ieee.org/iel5/9009/28599/01279669.pdf
- This publication describes the use of infrared sensors for detecting head movements to control a wheelchair. It is useful for their approach to understanding the possible range and mapping of head movements.
- H.V. Christensen, J.C. Garcia, “Infrared Non-Contact Head Sensor, for Control of Wheelchair Movements”, IOS Press, 2003
- http://vbn.aau.dk/fbspretrieve/529548/aaate_article.pdf
Instructor comments
Stakeholders are fine. Need to see your usage scenarios and use cases. Lian 21st March
Post presentation session milestone: Probably spent too much time on the MUP. Good set of stakeholders, but explicitly mention disabled users and non-disabled. Your scenarios are good for problematic situations, but you should also have a basic set for normal situations of use. Some of your use case descriptions contain alot of things (eg. Selecting Playlist) - make sure system responsibilities are not hidden in a too general description. CRC cards are quite good, although there is possibly too much implementation information in the description of responsibilities. Responsibilities should be written as what the class knows and does. You don't need to state whether it is an instantiable class or uses an array, etc. - this is not what goes on CRC cards. Be careful of the direction of collaboration (eg. Song should have no collaborators). For each collaborator, state what it is doing in this particular collaboration to fulfil the stated responsibility. I would like to see the mapping of head movements to commands. Lian 4th April
