PROJECT Documentation - Group A7
From SoftwarePractice.org
Contents |
Project Description
The application that our project team have been commissioned to develop is a Digital Music Sampler (DMS). The function of this device is to digitally record ("sample") musical instruments or other sound sources and then allow these recorded sounds to be played back.
Our project team have defined the key elements of this device as being:
- Graphical Interface
- Menu
- Keyboard
- Control panel
- Program settings
- Volume control
- Instrument control
- Pitch control
Project Team
The members that are responsible for the development of the Digital Music Sampler Project.
- Pervin Rajah
- Karlo Diamante
- Rodney Morrison
- David Klempfner
Project Stakeholders
The following groups are identified as being directly responsible for the overall outcome of the project.
- Developers
- Designs, codes, implements, tests and maintains the program
- User
- Able to play musical notes
- Able to record musical notes
- Able to play musical notes with different instruments
- Able to change pitch of musical notes
- Able to play back recording 'profile' using different program settings
Functional Requirements
Our project team have analysed the essential requirements as requested by the user. These essential requirements will form the foundation for the development of a system model.
The essential user requirements:
- Playback Function
- Pitch Function
- Record Function
- Trim Function
Usage Scenarios
These scenarios provide an informal description of a particular activity associated with the functionality of the system. The usage scenarios outline the system operation from the stakeholder's point of view.
Scenario 1
Mary wants to play 'Mary had a little lamb' using the predefined instrument 'xylophone'. She does this by pressing the buttons on the keyboard that corresponds to the notes she wants. As the buttons are pressed the corresponding tones are played back in the sound of a xylophone.
Scenario 2
Tom wanted to digitally record musical notes from his xylophone. Once they were recorded, he used the recording of those notes to play a melody using the program by pressing the corresponding keys for the tones he wanted.
Scenario 3
Jerry is interested in hearing 'Good Riddance' in different pitches. He loads the set of notes and plays it on the default pitch setting. He changes the pitch setting by sliding the pitch slider to "+2" and plays it again. The song plays with a higher pitch. He then slides the pitch slider to "-1" and plays it again, the song plays with a lower pitch.
Essential Use Cases
The functional requirements determine the main goals of the system from the users perspective. These requirements have been further analysed and were captured in the following use cases.
Use Case 1 - Playing Notes
Use Case 2 - Recording Voices
Use Case 3 - Changing the Pitch
Use Case 4 - Trimming Recorded Voice
UML Diagrams
Use Case Diagram
The following use case diagrams determine the specification of high level user goals that the system must carry out. These goals are recognised as the major functional requirements of the system.
|
Playback  |
Record  |
|
Pitch  |
Trim  |
Class Diagram
The overall structure of the program has been designed to ensure that the collaboration of the classes and attributes are optimised to improve system functionality. The diagram below describes the structure of the program by displaying the program's classes, their attributes, and the relationships between the classes.
Sequence Diagram
The major functional requirements of the program are demonstrated using specifications of simple runtime scenarios. For each runtime scenario the interaction of system objects over time is graphically demonstrated in the following UML sequence diagrams.
|
Playback  |
Record  |
|
Pitch  |
Trim  |
Graphical User Interface
The development of the program interface has evolved through a number of versions. Illustrated below are the two main development stages of the GUI Design.
Digital Music Sampler V1.0 Beta
Digital Music Sampler Final Version
System Testing
System testing is carried out on the overall program through the interaction between the user and the program interface. The tests are formulated to cover system integration with regard to the system's compliance with its specified requirements. The testing process requires no explicit knowledge of the inner design of the code or logic.
Playback Function
Record Function
Pitch Function
Trim Function
Unit Testing
The unit testing process has been implemented to ensure that the collaboration of the classes and attributes are responsive to internal program tasks. The unit tests are developed to ensure that the outputs from the interaction of program classes and their attributes produce the required results from a given input.
Unit Test 1 - RecordManager.captureAudio()
| Test ID: | T01.Rec |
| Method: | testRecordNewSounds() |
| Purpose: | Tests the recording function of the program |
| Input: | None |
| Output: | ByteArrayOutputStream RecordManager.out[] |
| Precondition: | RecordManager.recordState == true |
| Postcondition: | RecordManager.recordState == false && RecordManager.out[] != null |
Unit Test 2 - RecordManager.playAudio()
| Test ID: | T02.PlayRec |
| Method: | testPlayRecordedSounds() |
| Purpose: | Tests the playback of recorded sounds |
| Input: | int Keys.keyNum |
| Output: | ByteArrayInputStream RecordManager.input[] |
| Precondition: | RecordManager.recordState == false |
| Postcondition: | RecordManager.recordState == true && RecordManager.input[] != null |
Unit Test 3 - RecordManager.setRecordState()
| Test ID: | T03.RecState |
| Method: | testRecordState() |
| Purpose: | Tests the changing of the recordState of the program |
| Input: | boolean state |
| Output: | none |
| Precondition: | none |
| Postcondition: | RecordManager.recordState == state |
Unit Test 4 - Controls.volSlider()
| Test ID: | T04.Vol |
| Method: | testVolume() |
| Purpose: | Tests the volume of played notes |
| Input: | int Controls.volumeSlider.getValue() |
| Output: | none |
| Precondition: | none |
| Postcondition: | Controls.ms.getCurrentChannel().velocity = Controls.volumeSlider.getValue() + 15 |
Unit Test 5 - Controls.pitchSlider
| Test ID: | T05.Pitch |
| Method: | testPitch() |
| Purpose: | Tests the pitch of played notes |
| Input: | int Controls.pitchSlider.getValue() |
| Output: | none |
| Precondition: | none |
| Postcondition: | Keys.pitchNum = 12 * Controls.pitchSlider.getValue() |
Appendix
Test Case Development
Instructor comments
Your use case diagram needs to match your use cases... I would think your usage scenarios could be elaborated on more.
Use case #1 seems fine. #2 seems a little redundant from step 14. I don't quite understand #3. Remember that use cases, UML models, and so on are NOT the main goal of all this. The goal is understanding. Some explanatory text would certainly help.
(JohnR 21st Aug 06)
Has anything happened here since the Inception phase? JohnR 11:00, 9 September 2006 (UTC) For example, where is the sequence diagram ????? --Dawsonj 08:50, 8 October 2006 (UTC)
Have to say you done an excellent job --Dawsonj 11:15, 25 November 2006 (UTC)
