程序代写代做代考 gui database algorithm JamminGo

JamminGo
Requirements:

Functional Requirements:
 Play music

 Navigate playlist

 After playlist ends go to next folder or random song

 Recommendations

 Multi-level filtering (search)

 Sorting

 Arbitrary tags

 Replay Gain

 Equalizer

 Gapless playback

 Lots of filetypes

 Streaming services

o Internet radio

o Pandora

o Plug-in architecture for more

 Bluetooth support

o Button recognition

o Auto start on connection

o Auto stop on disconnection

 Random/Shuffled playback

Non-functional Requirements
 Low latency (<50 ms response rate)  Usable while distracted/moving o Large buttons (Finger to thumb sized buttons on a 4in screen) o Simple interface (<6 buttons per screen) o High contrast  Small executable size (<50 MB)  Small memory size (<100 MB)  Buffering to support gapless playback and internet streaming (15-30s buffer)  Relevant recommendations  No major memory leaks (<200 MB RAM usage after 7 days of constant playback)  Infrequent crashes (<1 crash per 7 days of constant playback) Lists plenty of user features, and pertinent non-functional requirements. Includes details on non- functional requirements, which will make validation possible. No contradictory or impossible requirements, realistic non-functional requirements. Architecture: Design Patterns: Model-View-Controller: Supports a GUI with a clean separation from the backend audio processing. Client-Server: Connect the app to internet radio servers. Pipe & Filter: Allows music list to be filtered repeatedly. Allows music to be sent through multiple modifications (Replay Gain, Equalizer) before output. Singleton: Single instances of the audio buffer, and settings. Memento: Make a storable copy of the settings. Façade: Produce a consistent interface for the plug-in architecture. Iterator: Provide methods for iterating through a playlist. Lists several design patterns and describes how they will be applied. Required Systems/Relationships/Levels of Abstraction: Model View Controller Now Playing LibraryPlaylistEqualizer OptionsStreaming Recomme nded File Info A u d io B u ff e r In p u t P a rs e r Library Playing Taps Swipes Bluetooth Figure 1: High Level System Architecture Audio Buffer Input Parser File ReaderNetwork Streaming Service Audio Playback System Audio Filters Audio Queue Figure 2: Audio Decoding and Playback Architecture Includes two different levels of abstraction for the system. Each level of abstraction includes its own systems and relationships. The high-level view also gives some insight into its components. Would be nice to show even more perspectives. Interfaces: Programmatic Interface: Database Files Services GetAllFiles() GetAllServices() GetInfo(Item) GetFileName(Item) Filter(List, Criteria) Playlist Items ListInfo() GetInfo(Index) Append(Item) Insert(Item, Index) Remove(Index) Move(Index, Index) View Controller Audio Queue Figure 3: Class Diagram for the Database and Playlist Simple class diagram that shows the interfaces that the media database and the playlist provide to other parts of the program. Functions include a description of their required parameters. Would be nice to show additional classes—perhaps in a different area of the program. User Interface: Scrolling Title – If Artist, Album, Oth Denver – Take Me H Bach – Air on a G Str rosmith – Dream On Beatles – Sgt. Pepper Beatles – Hey Jude Jensen – Run Rabbit Matchbox 20 – A. CLANNAD – 潮鳴り Final Fantasy – Prelu Figure 4 Now Playing Window Figure 5: Playlist Window User interface that matches the non-functional requirements. Two screens should be considered the bare minimum, unless the program doesn’t rely heavily on a UI. Testing & Verification: Functional requirements: 1. Unit testing can handle most parts, use mock objects for initial tests. 2. Automated nightly builds with integration testing. 3. Automatically create random “music” files to automatically test nightly builds. 4. Use non-development personnel (CEO, janitor) for black box testing. 5. Test on developer owned and common devices with personal music collections. (Alpha test) 6. Limited beta test with friends/family/enthusiasts. 7. Large scale beta test with paying customers (guinea pigs). Non-functional requirements 1. Add timing to automated testing for latency. 2. Check package size and execution size. 3. Design buffer to be large enough to hold >15s of data, even for high-resolution audio types.

4. Use non-development personnel (janitor, CEO) to check the simplicity of the UI.

5. Listen for recommendation complaints or accolades from the peanut gallery.

6. Add memory usage tracking to the automated tests.

7. Add crash tracking to the automated tests.

8. Run profiling tools weekly to catch latency and memory hotspots early.

Testing and validation procedures are extensive and multi-pronged. They appear likely to catch most

bugs and other problems before release. Non-functional requirements are easily verified thanks to the

details on the original requirements.

Development Strategies:
The core of the system should be designed ahead of time to ensure low latency interaction and

playback. So, we will use a plan-oriented strategy at the beginning while we are focusing on the audio

engine. Most of the other parts can be built using an iterative strategy. Adding audio sources (filetypes

and streaming), tag support and filtering can be done in small chunks, and in whatever order we want.

The GUI will likely need multiple iterations, so it would also work well with an iterative development

strategy.

Modern development tools will be helpful for eliminating bugs early on. We will also use pair

programming to help catch algorithmic issues early on. Design by contract will work very well for a lot of

the non-core parts. This will ensure that we have strict expectations for what they do, so we know they

will interface with other parts with a minimum of fuss.

Development strategy displays a good understanding of the issues likely to arise during the project and

chooses a core development strategy to match. Other tools and approaches are also brought in to

smooth the development process. Not every method or tool will work for every project, but adding more

of them and increased explanation of why they are applicable would improve this further.