Phone companies have a feature called three-way calling. This allows a caller who initiates a call to add another caller to the conversation. In this assignment you will extend this feature to allow "multi-way calling". In this proposed feature any caller who is currently part of the conversation can add any number of additional phones to the call.
For this assignment, you will write classes that model an extension of the phone three-way calling feature. A computer program that models a process is usually called a simulation in computer science. This assignment is just a fraction of a complete simulation. (There is a large simulation example in section 8.2 of the text, but please don't imagine that we're going to try to build something as complete as that example. Our simulation is much simpler and does not incorporate the randomness in the text's example -- and besides, you're writing only part of the program.)
What you should learn from this assignment includes the use and implementation of a standard data structure. The next section discusses just which data structure is required. The assignment will also give you practice working with specifications, testing and documentation.
In order for all this to succeed, you must follow the specifications precisely. It is common even for quite experienced programmers to find that they have neglected some point of a specification and that their "obviously correct" program does not work properly. For beginners, reading carefully does not come naturally, and one thing you will learn from this assignment is that you do have to read parts of the handout more than once.
You will also learn that specifications never achieve complete precision; sometimes you'll need to ask us for further details, and sometimes you'll need to make an intelligent extrapolation on your own.
This assignment will also extend your experience with good programming practices, in the form of JUnit testing and Javadoc documentation.
Currently phone companies have a three-way calling feature. That restricts the number of phones that can be part of a conversation. Yes, some companies have conference calls but this can only be done after booking a session time and involving a representative of the phone company who coordinates the call. There is no way for any subscriber to involve more than three phones in a call. The problem is to implement multi-way calling without involving the company, where any phone already part of the conversation can add more phones to the conversation.
In this assignment there will be several different implementations of the feature, different strategies for managing the phones in the call. There are two implementations handling the maximum number of phones that can handled as part of a single conversation. One implementation has a maximum number of participants in the conversation. Another has no limit to the number in the conversation. There are two different implementations for handing hang ups. One implementation terminates (removes) all phones that joined the conversation after the phone being hung up. Another implementation terminates the phone being hung up and all phones it brought into the conversation directly (but not phones brought in indirectly).
In assignment 1 you will implement the different management strategies and the different strategies for handling hang ups.
You will need to download the Phone class, the
Stack
interface, the Strategy interface and the fragments of
the Strategy1 and Strategy2 classes that we
provide.
There are also sample toString formats
you will need to compare with your toString formats to make
sure they match exactly (otherwise the automarker will give you zero).
SearchableStack adds a search method, a
find
method and size
method.
boolean search(E o) returns
whether any object in the stack matches o.
E find(E o) removes and returns the
object that matches o in the stack
int size() returns the number
of objects
stored.
ArraySearchableStack classArraySearchableStack class implements the
SearchableStack interface
using an array of a fixed size.
ArrayListSearchableStack classArrayListSearchableStack class implements the
SearchableStack
interface
using an ArrayList so there is no fixed size.
Strategy interfaceStrategy interface has three methods:
makeCall(Phone fromPhone Phone toPhone)
checks whether the fromPhone is part of the current
conversation,
checks whether the toPhone is not part of the current
conversation.
and if so adds the toPhone to the conversation.
hangUp(Phone) hangs up this phone depending on the strategy
used.
toString() returns a string representation of the
conversation.
See
an
example on the assignment web site.
Strategy1 classStrategy1 class implements the Strategy
interface. When a
phone is hung up the phone hung up and all phones above in the
stack of phones are hung up (removed).
Strategy2 classStrategy2 class implements the Strategy
interface. When a
phone is hung up the phone hung up and any phones added to the
conversation directly by this phone are hung up (removed).
Other phones added to the conversation after the hung up phone (in the
stack above the hung up phone but not added to the conversation directly
by the hung up phone) are not removed.
For Assignment 1, you must write
the ArraySearchableStack class, the
ArrayListSearchableStack class, the
Strategy1 class and the Strategy2 class.
Submit them in files called
ArraySearchableStack.java,
ArrayListSearchableStack.java,
Strategy1.java and Strategy2.java.
You may also
add extra classes needed to support the required classes;
these support classes should be in their own separate .java
files, and of course those files must also be submitted.
Do not submit the Stack interface, the
Strategy
interface, the SearchableStack interface or the Phone
class.
You must also prepare test classes using JUnit for the four classes you submitted above. You should haveJUnit tests for all the public methods in those classes. Submit your JUnit test classes.
For all your methods, there must be appropriate Javadoc documentation as well as appropriate comments within the methods. Your marks will depend on documentation and other aspects of style as well as on the success or failure of your program code itself.
Your test cases should cover extreme correct and incorrect values, as well as the obvious "middle of the road" values.
Test basic methods before complicated ones.
Test simple objects before objects that include or contain the simple objects.
Don't test too many things in a single test case.
Be careful testing static variables (which you should avoid anyway).
Write your test cases early. It's easier to think of test cases when you can remember the troubles you had writing the code, and the process of writing and running tests can also help you to write the code if you do it early.
Re-read the specifications before deciding you're finished with a class. Check the spelling and capitalization of your class names. Check method signatures especially: parameter types and return types, and the spelling of the method name must match exactly. If these don't match the description in the assignment handout your program will not compile and run correctly and the automarker will give a mark of zero.
Write your Javadoc documentation before writing the method it describes. Change it if you realize you've misunderstood. Don't leave documentation to the end, when you no longer remember your code.
Make sure your class names are spelled exactly right, agreeing with the spelling in this handout -- including capitalization -- and make sure your file names match the class names.
Start with the simple operations and the operations that facilitate testing. You may want to restrict the functionality of a class and once the limited version is working add more methods.
Feel free to use private "helper" methods as needed. Document them in the same way you would document public methods.
The expectations in CSC 148H/A48H are much the same as in CSC 108H/A08H: comments explaining complicated code, well-chosen names for variables and methods, clear indentation and spacing, etc. In particular, we expect you to follow the capitalization conventions: variableName, methodName, ClassName, PUBLIC_STATIC_FINAL_NAME.
We are likely to use CheckStyle to look for stylistic difficulties in your code, and it would be sensible for you to do that yourself before submitting your work.
Automarking: 40%
Style and design: 20%
Documentation: 20%
Test cases: 20%