CSE 132 (Spring 2010)
Lab W: Weasley Clock

You will extend the weasley model to include some security concerns and make it ready for use to drive a Weasley Clock.



The design you developed for Studio W was driven by the Main class in terms of the methods you needed. You were mostly able to determine the methods' functionality based on their names and on the code in Main.

However, while the user story seemed OK at first, most of you discovered there were certain areas of functionality that were unmentioned in the story. These dark corners (cue the spooky music) of the specification included at least the following:

Unit-testing problem resolution

There is a unit test WeasleyTest you will find by updating your personal repo. Run it. The unit tests may emit messages that are coded by a problem letter. The explanations are below:
The .equals(Object) method must be defined for your objects, especially Person and Location. These should be based on the equal-ness of their contains Strings. These methods can be automatically generated by eclipse.
The .hashCode() method must be defined for your objects, especially Person and Location. These must honor the contact that if two objects .equal each other, then their hashCode()s must be the same.
What happens if a person is mapped to place never before identified to the model? Is that location now in its known set of locations?
Objects of different types should never equal each other. If you autogenerate the .equals(Object) method the code that is emitted will handle this properly.
Unless you have good reason (and if so, change the test and explain this to a TA), a Person should have some location, even if that location is "Lost" or "Unknown". Recall the Weasley clock in the books and movies always had some notion of where its people were located.
What about a person who has never before been identified to the model? Unless you have good reason (explain yourself), then such people also might not map to null. This test is to make you think about this corner case.

Security issues

The model as it stands now should reveal the Location of any Person no matter who is asking for the information. For the time you have left in lab, consider how you might evolve the model to take account of who is asking. You might consider the following, keeping in mind that eventually a request to the model can contain the screenname of the requestor, which suffices to authenticate the sender of the request.

Last modified 08:59:25 CDT 03 June 2010 by Ron K. Cytron