Assignment 9: Save the Date – Planner System, part 5
Due dates:
Implementation: before your demo
Demo: schedule with instructors/TA
There is no self-eval for this assignment, though you will still submit it on the handin server. For evaluation, you will schedule a brief demo with one of the instructional staff. Available time slots will be posted on a Google document with a link on Piazza.
We prefer you complete this assignment with your partner, but if you need to work on it on your own, contact us in advance. We strongly prefer that you present your work together with your partner. If only one of you can attend, you must let us know in advance.
This assignment asks you to implement five sets of features for five levels of extra credit. The levels are dependent, and also increase in difficulty. Each level is all-or-none: either it works perfectly or it doesn’t. However there are points in each level for designing well, in addition to working correctly.
All extra-credit functionality must be well-designed and tested, to the ability of that feature to be tested. (GUI functionality is hard to test directly, but any related features interfaces or listeners must be testable and tested.) Also, all extra-credit functionality must work simultaneously: you must not have to comment code out and recompile your program in order to enable different features. You may use different command-line arguments, toggleable menu items, or other UI choices to select among your features.
1 Level 0: Changing the color of events
It can be hard to tell at a glance which events are hosted by the current user of the system view. Enable a “host” color mode where the events that the user is hosting are colored in a different color. For example, here is a schedule where the current user hosts some of the events, but not all of them
Here is an example where the current user hosts every event on their schedule.
This mode must be enableable and disableable at runtime: you should not have to restart the program to turn this coloring on and off, and this toggle must persist even if you change users. For proper design, you must not modify your rendering code directly to add these colors; it must be a separate decoration that you can add or remove.
(Hint: You may find it helpful to take the code that draws an event and put it in it’s own class. After that, how can you use a decorator to properly handle the above behavior?)
2 Level 1: Week Starting on Saturday
In this level, you will reimplement a model for a version of the planner where the week starts on a different day, Saturday. Otherwise, the planner is unchanged.
For proper design, both your regular model and your new Saturday model must implement the same model interface(s), and must coexist in your code without e.g. commenting one out and recompiling the other. As with all models, this must be decently tested. If not decently tested, then no design points will be earned.
3 Level 2: Visualizing Week Starting on Saturday
In this level, you will reimplement a visual view for the Saturday planner. This means the leftmost day is Saturday and the rightmost day is Friday. Events should be shifted accordingly visually.
Since the controller has no knowledge of the day of the week, this new view should be able to work with the controller without any modfications.
For proper design, both your regular view and your Saturday planner view must implement the same view interface(s), and must coexist in your code. You do not have to make your Saturday view work properly with your regular model, or vice versa.
4 Level 3: Strategizing Starting on Saturday
In this level, you will make your strategies work with the new Saturday model (and therefore view). The design points will involve thoroughly testing of the strategy to make sure everything works properly.
Hint: Your strategies may need to become parameterized by the type of your time representation to determine when to start and stop looking for available time slots. However, your model should not need any refactoring for the strategy to do this.
5 Evaluation
You will demo your work to the instructional staff. You must upload your final submission to Handins before your demo. Please come to your demo slot prepared. You should not have to modify your source code during the demo to demonstrate features (e.g. if you have all four levels working, but you must comment them in or out to demonstrate them, that is not acceptable). Re-running your program with different command-line options to show different levels is acceptable.
You will explain the architectural changes you made to the instructor or TA who is grading you.
You will submit your code to the handin server before you are scheduled for your demo. Please include a README file explaining which features you implemented and which files were affected, so the grader can quickly orient themselves when you arrive.
6 Grading standards
This assignment will be graded out of a total of 11 points:
1pt automated code style (earned only if you demo, no points for simply submitting something!)
Level 0: 2pts (1pt if the feature works flawlessly, 1pt if it is well designed)
Level 1: 2pts (1pt if the feature works flawlessly, 1pt if it is well designed and reasonably tested)
Level 2: 2pts (1pt if the feature works flawlessly, 1pt if it is well designed)
Level 3: 4pts (2pts if the feature works flawlessly, 2pts if it is well designed and reasonably tested)
Each of these individual grade items are all-or-none. In particular, clean code that is not properly functioning will not receive those points; likewise correctly functioning code that is poorly designed will not receive those points. As stated above, to receive credit for a feature, it must work completely. Two half-finished feature levels are worth zero points. Focus your attention on making each part of this assignment work well, rather than spreading yourselves too thin across several incomplete features.