Software Design Document

Introduction

Purpose

This system is to give a free application for anyone to use by going through their web browser, causing them not to not have an installer and such. Also, current DJ'ing software costs anything starting around 100 dollars (some are even $300-$500).

System Overview

The overall design will consist of a server running a database while a client is initiated via browser on one or more computers (different instances of the client, not all will be the same client running at the same time).

Generally, all queries made to the server will be done only through the client. These queries can include (but aren't limited to) uploading media, managing media, streaming media and recording this media.

Supporting Materials

None at the moment.

Provide references to useful resources here. This includes printed and online works.

Definitions and Acronyms

Volume Mixing Process of switching from one song to another by lowering the volume of the song that's currently playing while raising the volume of the song wanting to be introduced. This is a very classic technique of mixing and is very common with any given DJ.

Mixing Switching from one song to another

DJ Set A list of songs that a DJ plays. This can be predetermined or it can be done on-the-fly.

Design Considerations

The things to be remembered include some of the Assumptions (e.g. Flash can play two mp3s at one time), Constraints (e.g. mp3 legalities and constraints of this project only covering one school year) and the System Environment (e.g. Computers running the client(s) and/or server).

Give an overview of important aspects uncovered during the specification and design phases that should be remembered.

Assumptions

  • Flash can play two mp3s at one time.

  • Streaming can occur while playing a different song in Flash.

  • If Flash is unable to perform these tasks, there will be a language that will allow this on a web page.

What are important underlying assumptions your project depends on.

Constraints

  • This current idea of the project wouldn't legally be allowed to be on the internet (mp3 reasons and such)

  • Since this project is only for this school year, it wouldn't be a full-blown DJ mixer. Some things like special effects (e.g. flanger, delay, echo, reverb-adder, loop-based mixing) would be out of the realistic scope of this project.

  • Some browsers do not allow Flash-based operations, so this project is limited to the audience that have Flash-enabled browsers.

What are the constraints the impact the design and implementation of this project.

System Environment

Client: Flash-based browser (on any given OS). Since it will be Flash, Adobe Flash CS 4 or 5 will be used.

Server: Ubuntu distro of Linux running MySQL (or some other media database-friendly language and programming environment).

This includes software, OS’s, hardware used or interacted with. It also includes social, physical, legal, and cultural environmental factors that impact system design and use.

Design Methodology

(Optional) - Summarize the approach that will be used to create and evolve the designs for this system. Cover any processes, conventions, policies, techniques or other issues which will guide design work.

Risks and Volatile Areas

Severity (highest to lowest) :

    • This project will not work in the end. Very unlikely but possible if more work comes out of my assumptions than assumed.

    • Flash OR HTML5 will not meet all of my needs, and learning a new language for this project would be completely un-ideal. Somewhat possible, but unlikely.

    • The server will not like streaming while organizing other media files, which will render this project useless. After research, this will not be likely.

    • A regular TCP/IP connection accepting streamed audio while accessing other media files through both the client and the server fails. This will be difficult, but unlikely it will fail.

What risks can be identified. It is a good idea to order the risks, and rate each according to likelihood and severity.

Also identify area where change is likely, both due to uncertainly, and external factors.

Architecture

This section should provide a high-level overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components. Don't go into too much detail about the individual components themselves (there is a subsequent section for detailed component descriptions). The main purpose here is to gain a general understanding of how and why the system was decomposed, and how the individual parts work together to provide the desired functionality.

Provide or reference a detailed description and diagrams of the architecture.

Overview

This will be split into two halves: The server and the client.

This section provides a high level overview of the structural and functional decomposition of the system. . Include information on the major responsibilities and roles the system (or portions) must play.

Subsystem, Component, or Module 1 …N

Within the Server:

Database – This holds the client information, the actual media that is to be stored, and the information to communicate with the client.

Within the Client:

Mixer – This is the main part of the project. The mixer will be streaming media from the server and will be played and manipulated by the end user.

Search/Sort – This feature will display all of the available media to the user while playing/mixing media.

Uploader – This will allow the user to upload new media while playing/mixing media.

If a particular component is one that merits a more detailed discussion than what was presented in the System Architecture section, provide that more detailed discussion in a subsection of the System Architecture section (or it may even be more appropriate to describe the component in its own design document). If necessary, describe how the component was further divided into subcomponents, and the relationships and interactions between the subcomponents (similar to what was done for top-level components in the System Architecture section).

Note that this design will likely be hierarchical, with sub components being broken up into sub-sub-components. This will be a living process as the project evolves. Try to cover as much as you can now,

Strategy 1…N

For the Search/Sort, I originally did not think of this project more like a media player, but more like a solid mixing program without any emphasis on media library capabilities.

Some of the items I have rejected include:

Youtube player – This item would allow the user to search for songs via Youtube and then stream them directly to the mixer and mix them into the actual sets. Although this idea would catch on very easily and could become widely popular, legalities came to mind and the fact that this might be too much work for the project.

Recording a set – Would a allow the user to save the set they mixed into .ogg or .mp3 format (most likely .ogg since .mp3 has copyright protection and other various legalities). This was rejected for the obvious legal issues and this too was deemed too much work for this project's scope.

Database Schema

Tables, Fields and Relationships

Provide a description of any tables, fields and relationships that need to be created for the design.

Databases

Just one database will be needed, and this will have all of the needed data onto it.

Describe the Databases, and include ER diagrams

Tables

The two tables that would be needed are the media storage and the client information. The media storage will store all of the media that has been uploaded by a certain user. The client information will include authorizations and a unique ID that will link the two tables together (so only that client can access the media he or she uploaded).

List any tables that will be needed, for each one including table name, table description, and related tables.

Fields(s)

List any fields that will be needed, for each one including table name, table description, and related tables.

Table Name

Field Name

Data Type

Allow Nulls

Field Description

MEDIA

TITLE

String

N

Song title

MEDIA

ARTIST

STRING

N

Song artist

MEDIA

BPM

INT

N

Song tempo (speed)

MEDIA

USER_ID

INT

N

User ID that song was uploaded with

CLIENT

USER_ID

INT

N

Unique ID given with registration

CLIENT

USERNAME

STRING

N

User's username

CLIENT

PASSWORD

STRING

N

User's password

      1. Fields Change(s)

This will be used if you are modifying existing Databases, or as the system evolves. For each field change (such as data types, required/not required, or renaming), please complete a row of the following table. (Insert additional rows as needed.)



  1. Detailed System Design

This section provides low-level design descriptions that directly support construction of modules. Normally this section would be split into separate documents for different areas of the design.

Most components described in the
System Architecture
section will require a more detailed discussion. Other lower-level components and subcomponents may need to be described as well. Each subsection of this section will refer to or contain a detailed description of a system software component. The discussion provided should cover the following software component attributes:

Component 1 - Search

Classification

Module

The kind of component, such as a subsystem, module, class, package, function, file, etc. ....

Definition

Searches for upload media within the client. This will be done with a search bar above the media library window.

The specific purpose and semantic meaning of the component. This may need to refer back to the requirements specification.

Responsibilities

Search will look at all of the media contents a user has uploaded, so this serves as an organizer of sorts to the user (especially the case in where a user uploads a large amount of media files).

The primary responsibilities and/or behavior of this component. What does this component accomplish? What roles does it play? What kinds of services does it provide to its clients? For some components, this may need to refer back to the requirements specification.

Constraints

The only constraint I can think of would be for the user wouldn't be able to search for newly uploaded media (unless the client constantly would refresh itself).

Any relevant assumptions, limitations, or constraints for this component. This should include constraints on timing, storage, or component state, and might include rules for interacting with this component (encompassing preconditions, postconditions, invariants, other constraints on input or output values and local or global values, data formats and data access, synchronization, exceptions, etc.)

Composition

There aren't any sub-components with this module.

A description of the use and meaning of the subcomponents that are a part of this component.

Uses/Interactions

This module is used by the actual client, and it communicates with the server (and database).

A description of this components collaborations with other components. What other components is this entity used by? What other components does this entity use (this would include any side-effects this entity might have on other parts of the system)? This concerns the method of interaction as well as the interaction itself. Object-oriented designs should include a description of any known or anticipated subclasses, superclasses, and metaclasses.

Resources

Some of the resources used would include the media library and the database (to search for the desired media item or items).


A description of any and all resources that are managed, affected, or needed by this entity. Resources are entities external to the design such as memory, processors, printers, databases, or a software library. This should include a discussion of any possible race conditions and/or deadlock situations, and how they might be resolved.

Processing

Since the search will have to be able to search by either Title, Artist, or BPM, a linear search will have to be done. This isn't much of a problem because I cannot foresee someone uploading more than 500 media files.

A description of precisely how this components goes about performing the duties necessary to fulfill its responsibilities. This should encompass a description of any algorithms used; changes of state; relevant time or space complexity; concurrency; methods of creation, initialization, and cleanup; and handling of exceptional conditions.

Interface/Exports

After a search has been performed, that user will be allowed to select that song to either be put into a playlist or into one of the mixing tracks (side A or B). All of this is to be done while the user is able to play media.

The set of services (resources, data, types, constants, subroutines, and exceptions) that are provided by this component. The precise definition or declaration of each such element should be present, along with comments or annotations describing the meanings of values, parameters, etc. .... For each service element described, include (or provide a reference) in its discussion a description of its important software component attributes (Classification, Definition, Responsibilities, Constraints, Composition, Uses, Resources, Processing, and Interface).

Component 2 - Sort

Classification

Module

Definition

This allows the user to sort a media file within the playlist or client. There will be multiple instances of this component in the media library. All of this will be able to be run while songs are streaming and mixing.

Responsibilities

With a large playlist, this will allow easier readability and better organization of files.

Constraints

Some of the fields may not transfer over from the mp3/ogg information, so error messages may come up or the sorting function may not work properly.

Composition

There are no sub-components with this module.

Uses/Interactions

This interacts with the playlist module and is used within the client.

Resources

Resources include use of the media library, playlist, and search functions.

Processing

Sort will sort media files by Title, Artist, or BPM (beats per minute). A bubble sort or some other simple algorithm will be used (depending on what field is desired to be sorted).

Interface/Exports

This sort will only be able to interact with the media library and use after a search has been performed

Component 3 - Mixing

Classification

Function/Module

Definition

This will allow the user to play, pause, stop and mix media files. There will be two decks, the A side and the B side. In order to load one of these sides with a media file, a user will have to use the playlist manager or Managing Media component to put the file into the track. While this process is going, the server will communicate with the client to stream this media (so not all library media streams over).

Responsibilities

Mixing is the main part of this project. This takes first priority of this system, and will have to be able to run while doing any other desired actions within the client.

This really is the one component that will have to be

Constraints

This will only work properly with a fast enough internet connection (streaming will be the bottleneck of this feature).

Composition

Sub-components include playing, pausing, stopping and volume control within the media. These lower controls have to all complete for this project and will have to work properly for this project to be successful.

Uses/Interactions

Mixing interacts with the database (server overall) and media library.

Resources

Resources include the use of streaming from the server and use of the media library.

Processing

The mixing aspect will stream from the server via TCP, and be used in a browser that is to be built with Adobe Flash.

Interface/Exports

The interface will be done with Adobe Flash, and can be accessed on a browser that meets these requirements.

Component 4 - Upload

Classification

Module

Definition

Uploading lets the user transfer desired media files from the local hard drive to the server.

Responsibilities

Uploading will have to be done while media is playing in the client. An option to upload before mixing is a “must” so bulk uploading is possible and isn't constricted on a faster internet connection.

Constraints

Uploading will only be allowed while a good (and fast enough) internet connection is used. Also, there will only be allowed to play mp3 or ogg media files.

Composition

There are no sub-components for this module.

Uses/Interactions

This interacts with the server and database.

Resources

Resources include the use of the database and the use of a valid internet connection.

Processing

Uploading will be performed by transferring the media to the server via TCP/IP or FTP. All of the media information will be parsed into the database during this process.

Interface/Exports

This will be within the client, and will be able to upload multiple files at one time (within HTML).

Component 5 – Managing Media

Classification

Function

Definition

To ease the process of dealing with multiple media files, this will allow the user to use the certain functions within the other modules and will allow those specified modules to communicate with each other.

Responsibilities

This function is the glue that holds all of the other modules together and will allow seamless functionality with all modules and functions. A closer look into it will show that this function will give access to multiple components at one time, like Search and Sort. After a search has been done, a sort will be able to be done on the search results. At any given point these media objects will be able to be put into a media playlist or be put into one of the “decks.”

Constraints

Because of this function, not all desired modules could be included into this project.

Composition

Since this molds all of the other media managing elements, this will be using and interconnected with the Search, Sort, Playlist and Mixing components.

Uses/Interactions

Users will be able to view, search and sort media files in this window. With a click of the mouse will allow a media file to be uploaded into the mixer, delete from the server or be put into a playlist.

Resources

This will be using Sort, Search, Playlist and the overall client (along with the server to feed the media file information).

Processing

This will be within the client only and will be done in Flash. Where this function truly shines will be with its interactions with all of the other modules.

To make the explaining of all of the other components, this component exists to “talk” from one component to another. Otherwise, the mixing component will have to have elements from Search, Sort and Playlist within it because it would have to have shared functions between themselves. Developing this instance would be foolish and wouldn’t be efficient to the overall project.

Interface/Exports

The interface will be done in flash and will be able to be viewed in a flash-enabled browser.

Component 6 - Playlist

Classification

Module

Definition

Playlist will group media files and will give the feel of a “DJ set.” These groupings will be similar to the workings of a Windows Media Playlist. Files will be joined up into one actual file, which will have its own window below the mixing decks.

The playlist will not be able to be saved, and is mainly used to group what songs a user desires to play during that time (instead of using the media library to play tracks).

Responsibilities

This handles all of the media groupings after all of the media has been shown to the user.

Constraints

A playlist may not be able to be saved since the user will be constantly adding or removing files from his/her collection.

Composition

This uses the Managing Media function, along with the Mixing module (to be placed into Mixing).

With the managing media functions, this includes search and sort so the user is able to search through a playlist or sort the media items by certain characteristics (i.e. BPM, Title, Artist).

Uses/Interactions

This will interact with the mixer, and will be connected to search, sort and the media management function.

Resources

It will be using the media manager.

Processing

This will be displayed in Flash and will display only the needed information that is stored in the server.

Interface/Exports

The interface will be displayed in a Flash-enabled browser.

-- DerrickMeyer - 2011-02-14

Topic revision: r1 - 2011-02-14 - DerrickMeyer
 
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback