Due Date: Wednesday, January 25 File(s) to be submitted: OneOfSet.java SUBMIT / Check Set of Possible Values (ADT design) Summary Create a generic interface named OneOfSet to help solve constraint satisfaction problems. The idea of such problems is that we know a value must be one of a limited set of values, but we don't know which value it actually is. (Think of a Sudoku puzzle.) The data structure you are designing allows the client to say what all the possible values are and then eliminate values until only one is left. When only one value is left, the problem is solved. NOTE that there is very little coding to be done for this assignment. Most of the work is in figuring out what problems might arise from each operation and deciding how to deal with them. The remainder is mostly writing javadoc comments. I expect to see some pretty long comments in the file you submit. One popular example of a constraint satisfaction problem is a Sudoku puzzle. Consider the sample puzzle below: Each little box in the puzzle is supposed to hold a number from 1 to 9 . The puzzle is to fill in the empty boxes in such a way that there are no duplicate values in any row, column, or any of the larger squares (with dark edges). By using the values that are already written into some boxes, you can reduce the number of available options for the remaining boxes. For example, the four empty boxes in the upper left large square can't be either 3,5,6,8 or 9 , because that square already has those numbers in it. Furthermore, we know the one box in the top line of that square can't be a 7 , either there's already a 7 in that row. Our data type could be used in a program that solves Sudoku problems. Each of the little boxes in the grid could be associated with a OneOfSet object that initially contains each of the numbers from 1 to 9 . The ones with actual values written in could be set to those particular values. Then we could go thru the whole grid eliminating possibilities on the related boxes. The remaining boxes could be examined, looking for ones that only have one possible value left. If found, those values could be removed from consideration in related boxes, perhaps bringing them down to only one option, and advancing toward the solution. In fact we'd need to do more work than I mentioned in order to get to the solution. But our data type would still be useful for recording our work. So here are the operations I'd like our data type to have. (In each case I give it a name, and you must use that name for that operation.) - addOption adds a single option to the available options for this object. - addOptions adds multiple options to the available options for this object. - rejectOption removes a single option from the available options for this object. - rejectOptions removes multiple options from the available options for this object. - setValue reduces the available options for this object down to one. (The particular value must be given, of course.) - optionsLeft returns all the available options for this object. (It might return an array, a List or a Set, for example.) - numOptionsLeft returns how many options are still available for this object. - isSolved returns whether this object is "solved" -- that is, whether the number of options has been reduced to exactly one. - theSolution returns the one available option for this object. (Of course it only works if the object has been solved.) - couldBe returns whether one (given) option is still available for this object. Your job is to create a generic interface for this data type. For each operation, you must: - Identify its parameters and their types. - Identify any problems that might arise with the operation. - Decide how to signal those problems to the caller. - Decide what restrictions (if any) on the data type that choice entails. - Identify or choose its return type. - Write suitable javadoc comments, including a multi-line description of the operation, the possible problems, the way those problems are signalled to the caller, and any restrictions resulting from that choice. You must also, of course, provide a suitable javadoc for the interface itself. It should summarize the purpose of the data type and restrictions (if any) on its use