2. Suppose you are writing software for a radio station that manages its playlis

Question

2. Suppose you are writing software for a radio station that manages its playlist. The program will generate candidate playlists from record library automatically and station personnel can then check and modify them. Disc jockeys must also be able to change playlists when they are used because what is actually played is often different from what is planned. The playlist are then used to generate reports for paying royalties. You must decide what sort of data structure to use to store playlists. Make a choice and write a design rationale. Your rationale should explain the factors that went into your decision, the design alternatives that you considered, your evaluation of your design decisions, and the reasoning for your final choice. (22 points)

Explanation / Answer

The problem at hand demands a three-tier solution:

To store the record library, we could arrange the records by their labels using:

Thus, though arranging the records by their labels would be useful while calculating royalties, for the purpose of playing them (which is more frequent) it would be unnecessarily heavy on time or space. From this perspective, we choose to store the records as tuples such as (index, track_name, track_location, label). Now, this can be achieved by means of:

In case we have ratings or genres and that would affect how frequently a record is played, we could extend our structure/design to include those factors. But, as of now, we are assuming that the radio station has no bias. After all, while more popular songs help achieve listener attention, it is less popular songs that motivate listeners keep coming back; songs they wouldn’t discover if not for the station.

That said, choosing records for a playlist is pretty simple. We could just use any random number generator to generate a bunch of indices and choose the relevant songs. Even in the extended structures, it would simply be a matter of sorting the array based on genre or ratings and then limit the random number generation to the range in question.

To store the generated playlist, we could go for a basic linked list since it would be sufficient to store the indices of the chosen records. While playing, the software could retrieve the records from the track_location of the particular index in the array or database. We could use an array instead of a linked list, but a linked list is more in line with our intentions here.

Finally, in order to enable calculation of royalties for different labels, we could use a hash table. In the hash table, we store different labels and the number of times each of their records is played. We define a hash function such that, there is no collision between the labels. The function could be as simple as some way of adding up the alphabets in the name or the year of inception, etc. Now, each time a record by a certain label is played, the hash function is used to locate the relevant label and increment the number of times its records are played.

While, we could use an array of tuples to store the labels and count too, that would require us to:

Thus we conclude that our chosen data structures and design will serve the purpose better than any other.

Related Questions

Navigate

• Browse (All)
• Browse 2
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.