$24
• Motivation
Imagine that you are starting a streaming video business. Partnerships have been estab-lished to provide you with video content, and you will stream that content to users. You plan to use your knowledge of what movies and television shows your users like/dislike to make e ective suggestions for new videos that they will like.
In this assignment, you will consider such a streaming video service. You will be design-ing an abstract data type (ADT) that stores the service’s video library and users’ like/dislike of videos. This ADT represents a data structure that will be used by both client applications and for administrative uses (e.g., adding new videos to the library).
Once you complete this ADT, you could provide it to the programmers of the client applications, and they will be able to develop applications based on this speci cation (much like you were tasked with doing in the Groceries portion of A1). On the other hand, you can also distribute the ADT to the engineers in charge of implementing the functionality of the data structure (much like you did with Set in A1). Thus, these two parties can work in parallel on their respective components, which can work together by virtue of both following the \contract" that your ADT provides. As you make the various design decisions along the way, consider what functionality the client programmers will need, what information they’ll expect to receive back, etc.; in addition, consider what inputs the implementers will need in order to carry out the various operations.
• Provided les
First, carefully read the provided les. You can nd these les on Pitt Box in a folder named cs445-a4-abc123, where abc123 is your Pitt username.
The StreamingVideo interface is a skeleton of your ADT. Many details will need to be lled in (see Tasks).
The User, Video, TvEpisode, TvSeries, and Film interfaces are provided as types for your methods’ parameters and/or return types. You do not need to modify these les, but you can assume that they’d be implemented moving forward.
The doc/ directory contains Javadoc-style documentation of the provided code (open index.html).
1
• Tasks
You must write an abstract data type as a Java interface. You will need to declare several abstract methods that the data structure would need to support. You should consider all possible corner cases in your speci cation, 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 speci c 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.
Note: You will not be implementing this data structure. You do not need to consider implementation-level details, since you are only writing the ADT. This means that you must specify the full set of details that a client needs to know in order to use the data structure, but not the details of how the operations will be carried out or how the data will be organized in memory. These implementation details should be left up to the implementers, so that they can produce their part of the code in the best way possible and not be over-constrained by the speci cation.
3.1 Helper types
When developing your ADT, you can assume the following types exist.
User: Represents a user.
Video: Represents a video.
Film: A subtype of Video, this represents a lm/movie.
TvEpisode: A subtype of Video, this represents an episode of a television series.
TvSeries: Represents a series/collection of TvEpisodes.
You do not need to make any assumptions, nor write any code, regarding the details of these data structures. They are provided to help you specify (parameter and return) types correctly. Interfaces representing these types are provided, but do not declare any methods, since their details are not needed in this assignment. You can assume that these interfaces (and their implementations) would be developed separately.
3.2 Abstract methods to declare
You will need to declare each of the following abstract methods in your StreamingVideo interface.
addVideo: Adds a new video to the system.
removeVideo: Removes an existing video from the system.
2
addToSeries: Adds an existing television episode to an existing television series.
removeFromSeries: Removes a television episode from a television series.
rateVideo: Sets an existing user’s rating for an existing video, as a number of stars from 1 to 5.
clearRating: Clears a user’s rating on a video.
predictRating: Predicts the rating that a user will assign to a particular video (that they have not yet rated). The predicted rating will be a number of stars from 1 to 5.
suggestVideo: Suggests a video for a user that they are predicted to like.
You can assume that the set of users and the set of television series are xed (e.g., at initialization) and thus you do not need to include operations to change these collections.
You will be completing the interface StreamingVideo, a template of which is included in the provided code. We have completed clearRating for you as an example to help you get started. You are allowed to modify this method for consistency with the others, if you take a di erent approach than that presented. The other abstract methods are initially declared as void methods with no parameters; you need to expand each declaration to specify a return type and parameters, as necessary. You also need to include a detailed comment for each abstract method describing its e ect, its input parameters, its return value, any corner cases that the client may need to consider, any exceptions the method may throw (including a description of the circumstances under which this will happen), and so on.
Note: If you cannot nd an existing exception that is appropriate for a par-ticular corner case, you may create your own (perhaps by following the format of InvalidExpressionException from A2 or SetFullException from A1).
You should include enough details that a client could use this data structure without ever being surprised or not knowing what will happen, even though they haven’t seen the implementation. Finally, you should use Javadoc-style comments where appropriate, so that running javadoc on your code will produce a readable documentation page without generating any errors or warnings. You do not need to use advanced features of Javadoc, but you should include @param, @return, and @throws comments as in our example code from class and the textbook.
A documentation page for the initial StreamingVideo interface is included in the provided code. This was generated using the following command:
javadoc -html5 -d doc cs445/a4/*.java
Note here that ‘cs445/a4/*.java’ speci es that all Java les within cs445/a4/ should be processed, and ‘-d doc’ speci es that the Javadoc output should be created in a directory named doc. On Java 9 or above, including -html5 is used to build HTML 5 documentation and avoid a warning about HTML versions, but you should omit it on older versions.
3
Finally, to test if your interface is well-formed, you should compile it using javac from the command line. You must include your code in the cs445.a4 package. You will not be able to run your program, because you will not be writing any executable code, much less a main method. It should, however, compile successfully.
• Grading
Your grade will be assigned based on whether the code is in the correct form and compiles successfully (10%); whether Javadoc generates documentation correctly (12%); and your speci cation of each of the required abstract methods: addVideo (8%), removeVideo (8%), addToSeries (12%), removeFromSeries (12%), rateVideo (12%), predictRating (14%), and suggestVideo (12%).
• Submission
Upload your java les in the provided Box directory as edits or additions to the provided code.
All programs will be tested on the command line, so if you use an IDE to develop your program, you must export the java les from the IDE and ensure that they compile and generate Javadoc documentation from the command line. Do not submit the IDE’s project les.
Your project is due at 11:59 PM on Monday, November 18. You should upload your progress frequently, even far in advance of this deadline: No late submissions will be accepted.
4