Project 4: ADT Specification Solution

You must write an abstract data type as a Java interface.
We have given you the names of several abstract methods that the data structure would need to support. You must specify them in the Javadoc comments above each method.
You should consider all possible corner cases in your specification, and describe what the class should do in all cases. A client that reads your ADT should know all the things that could go wrong, and how each will be handled.
Error cases should be unambigous to the client, and they should always know which specific error was encountered. For some corner cases, you will need to make a design decision regarding the best way to handle them. You have the freedom to make these decisions any way you wish, as long as you are consistent, thorough, and clear in your descriptions.
Remember that you document parameters by using the @param name command; return values with @return, and exceptions with @throws name.
The methods  
There are 8 methods. 1 has been done for you, as an example of the kind of specification we are looking for. So you must do the remaining 7. You will be adding parameters, return types, and exceptions to throw to each. Each one has a short description in StreamingRadio.java, so read those.
    • addSong
    • removeSong
    • addToStation
    • removeFromStation
    • rateSong
    • clearRating
        ◦ we’ve specified this one for you.
        ◦ you can change its specification, if you need to make it work better with your other methods.
    • predictRating
    • suggestSong
Notes  
    • You can assume that the set of users and the set of radio stations are fixed.
        ◦ That way, you do not need to include operations to change these collections.
    • When coming up with exceptions, you can use the standard Java exceptions where they make sense.
        ◦ If none of them fit, you are free to create your own exception classes.
        ◦ Follow the template of the exception classes we gave in projects 1 and 3.
    • Remember, you are specifying the interface to the client.
        ◦ The implementors will use this interface, but they will come up with their own implementation.

Testing  
Well, you’re not writing any code, but you are writing documentation, and your interface should compile with javac. You won’t be able to run it, of course ;)
Use this command to produce the HTML documentation:
javadoc -html5 -d doc *.java
If your documentation parses fine, it will produce a file in doc/ named index.html which you can open to view it.
If you are using a version of Java older than 1.9, upgrade. If you can’t, use this command: javadoc -d doc *.java

Grading Rubric  
    • [5]: Submission
        ◦ Incorrectly submitted projects will lose all 5 points.
        ◦ Please follow the submission directions carefully. There’s no reason not to.
        ◦ It’s 5 free points, people.
    • [5]: compiles with javac
    • [10]: produces documentation with javadoc
    • [8]: addSong
    • [8]: removeSong
    • [12]: addToStation
    • [12]: removeFromStation
    • [12]: rateSong
    • [14]: predictRating
    • [14]: suggestSong

Submission  
You will submit a ZIP file named username_proj4.zip where username is your Pitt username.
Do not put a folder in the zip file, just the following file(s):
    • All the java files
    • DO NOT include the doc/ directory
Do not submit any IDE project files.
Submit to the Box folder at this link. Drag your zip file into your browser to upload. If you can see your file, you uploaded it correctly!
You can also re-upload if you made a mistake and need to fix it.