F4

From SoftwarePractice.org

F4 Broadcaster Project

Digital Broadcasting System

Contents 1 Introduction: 1.1 System Overview: 1.2 System Context: 1.3 Scope: 2 Architecture Analysis: 2.1 Stakeholder Analysis: 2.1.1 Analysis 2.1.2 Narratives 2.2 Contextual factor 2.3 Customer Needs: 3 Usage Narratives 3.1 Quality Narratives 3.2 Announcer 3.3 Technical Engineer 4 Conceptual Architecture: 4.1 Initial Conceptual Architecture 4.2 Elaborated Conceptual Architecture 4.3 Component Responsibilities 4.4 Data Model 4.5 Use-Case Maps 5 Execution Architecture: 5.1 Description 5.2 Client Side 5.3 Server Side 5.4 Deployment View 5.5 Usecase-Maps 6 Implementation Architecture: 6.1 Components 6.2 Applications components 6.3 Infrastructure components 6.4 Third Party Components 6.5 Initial Project Architecture 7 Anticipated Issues (After Milestone 2) 8 Conclusion:

Introduction:

Radio is still the most powerful method of disseminating news and educational material to disadvantaged groups and in areas with high poverty, scant technological infrastructure, and/or instability. But while radio is extremely effective, the tools available to most community stations are very limited in function. The F4-Broadcaster project addresses this by giving a end-to-end solution for managing a radio station by using standard personal computers.

System Overview:

Radio and Audio Technologies Ltd (RAT) is an established provider of digital audio technology to the recording and broadcasting industries. Up until now, their equipment has been integrated with many other brands of equipment in any given installation, but RAT is now seeking to produce a breakthrough product for smaller radio stations, a complete "off-the-shelf" digital broadcasting studio.

System Context:

These days it is common for institutions to have radio stations, as is also for townships, from small rural communities to town centers and obviously metropolitan areas, to have a radio station. After all even at the top the University of Technology, Sydney sits a radio station.

The purpose of the RAT Broadcasting System is to offer a complete solution to any and all types of radio stations. Although primarily this system is designed for smaller establishments there is no limitations to its implementation.

Scope:

The scope of this RAT Broadcasting System project is to provide an "off-the-shelf" cost-effective solution for small radio station operators. To reduce the cost of setting up a radio station studio, the expensive equipment that make up the command and control systems, used to configure most of the operations of the studio, will be replaced by a software system capable of being run on a standard personal computer. This may be further extended by remote-client software and a web-based interface to allow access and control of the radio station to be carried out even when nobody is physically at the studio.

Architecture Analysis:

Stakeholder Analysis:

Analysis

Contextual factor

Technological: What kind of technology is needed to implement the system and wheather it is readily available.

Users: The users of the system are going to have to be trained up inorder to use the system effectively.

Developers: How long will it take the developers to design and create the system and at what cost.

Organisational: How much will it cost to integrate the new system into the existing infrastructure.

Advertisers: How will advertising affect the use of the system and what benefits will it offer to the organisation.

Customer Needs:

Usage Narratives

Request Track and Broadcast in Studio

DJ Gary runs the local radio station 2HOT.77.9. DJ Gary works on the popular weekday breakfast show. His job consists of selecting music to play and taking calls on his various talkback sessions.

DJ Gary is a seasoned Dj and has been DJ'ing for 20 years. But he is abit of a conservative when it comes to new technology. Gary doesnt like to stray to much from conventional setups and prefers being able to physicaly manipulate the controls.

On occasion, listeners call up to request a song to be played. DJ Gary must switch between the appropriate audio sources (studio microphone, stock audio clips, listener telephone call, music playback) seamlessly in order to maintain a professional and easy listening experience to the audience.

Select Input and Store the Media into Media Storage

DJ Gary had an exclusive interview with an up and coming rock band which brought about some insightful as well as humorous moments. The radio station producer would like to be able to take the recording of the interview and put it into a media storage medium so that snippets can be replayed during the evening radio show, and possibly be made available for download as a podcast from the radio station's website.

Access to Media database through Web Interface

Sally Lee, the manager of the radio station, was away sick in bed this morning and was unable to complete her review of the morning breakfast show as part of her end of year report. It is already evening and her report is due tomorrow morning.

Fortunately she remembers that thanks to the new media storage database she can access and download a recording of the breakfast show from that morning and listen to it at her leisure. Working from her laptop while still in bed, she uses the internet to login to the web interface of the new radio station software system and download a copy of the recording.

Quality Narratives

Announcer

DJ Gary runs the local radio station 2HOT.77.9. DJ Gary works on the popular weekday breakfast show. His job consists of selecting music to play and taking calls on his various talkback sessions.

2HOT.77.9 requires a multi-channel bridge system between taking calls and setting the next audio track to be broadcast. They would also require isolating different media, so while the current broadcast is playing a track Gary can take calls simultaneously off-air, whilst storing all the on-air and off-air audio into digital storage.

Gary would also like to take on air requests and play the request from an external input, to be broadcast.

Technical Engineer

Barry is a technical engineer for KWER 102.7. His job consists of maintaining operations and maintanence of the RAT broadcasting system. He is on call 24 hours a day, seven days a week. This is necessary inorder for him to be able to fix any errors that may arise, so that the station remains live.

To make his job more managable he would like to be able to login to the system remotely via a website so that he can run routine tests and check the status of the system away from the studio.

Conceptual Architecture:

Initial Conceptual Architecture

This section would define key concepts on the Digital Board-casting system narrative.

1. Key Concepts Definition:

Radio and Audio Technologies Ltd (RAT) is an established provider of digital audio technology to the recording and broadcasting industries. Up until now, their equipment has been integrated with many other brands of equipment in any given installation, but RAT is now seeking to produce a breakthrough product for smaller radio stations, a complete "off-the-shelf" digital broadcasting studio.

Based on discussions with potential customers, RAT has decided that the system consists of two parts. The first is a digital audio processing system, configurable with from 8 to 24 audio channels.

Each channel selects from a range of sources, including CD players, microphones and voice (telephone) circuits, and digital storage media, and is able to perform a standard set of audio processing functions, such as parametric equalization, gain, and panning between two output channels. Additional processing, such as compression and noise reduction, needs to be able to be “patched" into specific input or output channels, with the number of such processing modules determined by the amount of processing power the customer buys.

The second part is the command and control system, which the operator uses to configure most of the operation of the studio. This comes in different flavours, with the lowest-cost option being fully virtual, with all controls implemented on standard PC hardware. Although many recording studios won't buy digital processing unless it has knobs on it, RAT figures that for this product, cash-pressed radio stations will accept touch-screens as a compromise. However, RAT's standard user interface hardware will also be available for customers that can afford it. They expect to produce a mixture of configurations with varying degrees of physical hardware and screens for display and visualization.

As always, RAT want to make sure that this product lives up to the reputation they have established for themselves, that of good-sounding digital equipment that does the job and doesn't break. They need the product to be competitive, but any corners that are cut that cause the product to fail while “live" will severely damage their other markets as well. They are also acutely aware that customer expectations include 24-hour remote access to the system, both through a web interface and a more sophisticated interface that allows a subset of the full RAT control, editing, and signal processing functionality. They have hired you to lead the architectural team for the rest of the Inception phase and the Elaboration phase of this project, with a commitment to keeping you on as project leader(s) if Construction goes ahead.

As a last-minute wrinkle, RAT inform you the day before delivering the contract that they also want to re-use significant elements of this new architecture across a whole new product line, which includes digital audio storage and processing for the film industry, and storage and analysis of security (audio) tapes in large complex installations such as banks and airports.

2. Candidate Components:

Digital audio processing system --------------OK ===>Processing System

8 to 24 audio channels -----------------------OK ===> Channels Manager

Range of sources -----------------------------External inputs

Audio processing functions -------------------Ditto

Additional processing ------------------OK ===> Additional Audio Function

Command and control system ---------------OK ===> Command & Control System

Operator uses --------------------------------Stakeholder

Studio Interface -----------------------------OK

Standard PC hardware -------------------------External system

Touch-screens --------------------------------External system

Web interface ------- ------------------------Web UI

Sophisticated interface ----------------------Ditto

Authentication -------------------------------OK

Authentication Database ----------------------OK

Signal processing---------------------------OK ===> Signal Transmitter

Digital audio storage ----------------------- OK ===>Media Storage

Encrypted storage ----------------------------OK

Analysis of security (audio) tapes -----------Redundant

The very high-level Architecture

The radio station digital broadcasting studio is represented by the studio component. This component can be interacted with remotely over the internet which is represented as an external system. Digital audio and recordings are stored in a media storage database for archival purposes and can be retrieved for playback, this is represented by the storage component. The output of the radio station's studio can be broadcast over a conventional radio tower or over the internet, represented in this diagram as another external system.

Conceptual Architecture version-1:

The original studio component is expanded into four more components. A command and control system component, processing system, channel selection and additional audio function components.

Conceptual Architecture version-2:

The processing system becomes hub to the other studio components while the command and control system component still remains the main control component. The web interface is elaborated to include authentication and user management through an authentication data components.

Elaborated Conceptual Architecture

Refining Conceptual Architecture:

The “System Controller ” component from previous Conceptual Architecture versions is identified as a Blob, therefore, this component is split into two other components with different responsibilities. These components are “Authentication” and ”Operator”.

There is also a Command Cluster in previous Architecture version. “System Processor” and “Additional Audition Function” should be combined into a single component as “ Audio Editor”.

Here is final version of Conceptual Architecture:

Component Responsibilities

1. Studio Interface: This component is a User presentation component that is responsible for providing the user with interacting with “Command & Control System”. In this component, there are major responsibilities, such as:

• Visualizes system’s functionalities
• Send request to real-time components and performs feedbacks.

2. Web Interface: This is a User presentation component. This component is responsible for providing user to interact remotely with real-time components.

• Request authenticated information
• Provides full control, editing and signal processing functionality.

3. Authentication: This component is a real-time response that would interact with Web Interface in order to complete responsibility of authenticating a user:

• Verifies user’s details such as username and password
• Decides permission to access to System

4. Operator : this component is a real-time response, responsible for:

• Connect and interact with User presentation and Persistent storage components
• Gets information and respond requests
• Manages and operates real-time functional components
• Manages audio data in Persistent storage component

5. Audio Editor : is a real-time response

• Configures Input Audio Channels
• Edits raw audio data and compresses to MP3 files
• Stores and retrieves audio files to/from persistent component.

6. Channels Manager:

• Manages 8-24 audio channels.
• Imports raw audio data and arranges them to Input audio channels
• Passes these Input audio channels on to real-time components.
• Get edited audio files and arranges them into Output channels, then exports ready audio files to real-time component.

7. Signal Transmitter:

• Transfer digital audio into analog signal to broadcast.

8. Media Storage: This component has responsibilities same as the Persistent Storage component.

• Stores processed audio files

9. Authentication Data:

• Stores user’s details

Data Model

This Data Model defines on the nature of data passed between commponents defined in Conceptual Architecture, specially it emphasises on persistent data components.

Use-Case Maps

Those are main events which extracted from Usage Narrative:

In this use case the radio announcer takes a caller, to do this he uses the channel manager to select the telephone audio input so that the caller can be heard on air. The caller requests a track which the radio announcer retrieves from the media storage database. The radio announcer uses the the channel manager again to switch audio sources to the digital audio track and plays the song requested.

In this use case the operator logs into the system through a website. The operator supplies his username and password details through a web interface which is authenticated against a database of authorized users. If their credentials are accepted, access to the operator component is granted and control of the radio studio is available remotely.

Execution Architecture:

Description

The execution architecture describes what the system will look like and how it will behave during run-time. The concurrency view shows two (possibly more) different threads or processes operating “simultaneously” within the system. This section will outline the components of both server-side and client-side and describe how they interact with the system.

The server-side application is the RAT Broadcasting System, it resides in the studio and is accessed through a web interface (client-side).

The execution architecture uses a “Pipe-and-Filter Architecture”. This seemed appropriate since the input is passed through various components each modifying the input and producing a new output. In this case:

• the pump is the data source
• the pipe is the connector
• and the filter are the components

Client Side

Web Interface provides a client side access point into the RAT Broadcasting System. It allows the user to login into the system from any location with a standard internet connection. The web interface is HTTP based and utilises JSP to communicate with the server.

Database holds the login information for registered users. The Web Interface queries the database, if login is valid the connection is transferred to the RAT Broadcasting System Control Panel. The Database can only be accessed through the web server. No login procedure is required when in studio, since it is assumed anyone with access to the studio has access to the system.

The Control Panel is the central component of the system. It allows access to the rest of the functions, but client side some of its features are reduced.

The Audio System is a collection three components; the Audio Editor, Media Storage and the Playback System. This component provides all the audio manipulation and importation functions. It allows the client to select an audio input and pass it on to the Transmitter.

The Transmitter converts the digital audio signal into an analogue audio signal to be transmitted to the masses.

Server Side

The Interface consists of two variations. One is the standard control interface, it is hardware based. The other interface is a software based touch screen interface. These two variations exist, so the system can accommodate both large and small stations with different budgets. The interface provides access to the control panel.

The Control Panel provides access to all lower level components.

The Playlist Editor allows the user to create and manage multiple playlists.

The Audio System is a collection three components; the Audio Editor, Media Storage and the Playback System. This component provides all the audio manipulation and importation functions. It allows the client to select an audio input and pass it on to the Transmitter.

The Transmitter converts the digital audio signal into an analogue audio signal to be transmitted to the masses.

Deployment View

Usecase-Maps

Main events etracted from Usage Narrative are:

1. Create playlist and set scheduler 2. Edit nad playback audio 3. playback direct audio 4. access via web and broadcast

Implementation Architecture:

This is Implementation Architecture which is about how the Broadcasting System is constructed.It contains components which are defined as application and infrastructure component, such as audio process, digital store, web server and others.

Initial Implementation Architecture

Complete Implementation Architecture

Components

• Web Server connects to the web interface, it receives input and passes it on to the MySQL component.

• MySQL accepts authentication parameters via a socket. Processes the parameters and grants access to command control panel, if valid.

• Audio Process Components contains the Control Panel and the Audio Processing Functions. This is where all the processing of messages and inputs occurs. Audio is imported and exported out of the system. Encrypted and standard Storage connects to this component.

• Encrypted Component, here sensitive data is encrypted prior to storage. Data is also decrypted as it is retrieved (if it is in an encrypted state).

Applications components

A. Source-Code Package:

• Control Panel Package: This package contains all java class of main control panel of the system. Playback system component.

• Playlist Manager Package: it contains java classes to handle making and processing function of Playlist Manager Component which defined in Conceptual Architecture.

• Scheduler Package: it contains java classes to handle function of Scheduler Component which defined in Conceptual Architecture.

• ID3 Tag Package: It contains java class to use for creating and modifying information tags of MP3 files.

B. Files:

• User_db.sql : this is a SQL script used to initial table data structure in database.
• Studio.jnlp: a file to configure Java Web Start in Apache Server.

Infrastructure components

• extLib Package: This contains all necessary external Java Library to run main application.
• Audacity: This is a off the self software used as Audio Editor Component in this designed system.
• Apache Sever: This is Sever supported Java Technologies.
• Sound Interface: This is hardware to capture audio stream and export to external audio devices such as Speaker, Transmitter and Broadcasting devices.
• JDBC/ MySQL driver: It provides communication between application and external database.

Third Party Components

Some audio processing functions are based on off-the-shelf products. The product used is Audacity, this has been incorporated to manipulate audio files. Writing these components was too difficult and complex to be done in the project time frame.

All other code was custom written. We utilized the Java Media Framework (JMF) API, to aid in the construction of other key audio functions. We used the JMF API as it was easy to understand and there was an adequate amount of resource files.

---

Initial Project Architecture

This diagram below describes techniques and programing languages that would be used to build each components defined in Execution Architecture. These components would built seperately by appropriate techniques, then they would put together to become a completed system.

Anticipated Issues (After Milestone 2)

1. Reliability and Robustness

• The ability to function 24/7
• The ability to recover from unexpected errors

2. Upgrades

• Patching the system with new audio CODECs to support more media formats.

3. Scalability

• What is the maximum number of simultaneous connections.
• How to determine the maximum number of connection slots.

Conclusion:

The execution of several stages such as stakeholder analysis, implementation architecture, conceptual architecture and execution architecture give an general overview and preparation for further developement . The main components of the system have been identified in conceptual architecture and labeled on the stereotypes to give an overview of a complex system. In this stage. use case maps are also used to show the responsibilities of each component when an event is taken.

In execution architectural, concurrent systems were defined in order to bring an clear understanding of how the system will be executed. However, an execution architecture diagram will also be provided to give a visual explanation.

Finally, Implementation Architecture defines how the system is constructed with many components which involves in the construction of the system are related to infrastructure and application part.

Several issues have been raised for the next milestone during the execution of these stages. However, These issues will be discussed and investigated further in next part.