Assignment 8: Saving the Date – Planner System, part 4
Due dates:
Code given to customers: Thursday, Apr 11
Implementation: Wednesday, Apr 17 at 8:59pm
Self-evaluation: Thursday, Apr 18 at 11:59pm
Peer-evaluation: Thursday, Apr 18 at 11:59pm
1 Purpose
In this assignment you will experience some effects of your design decisions, and practice working with implementations not written by you. Specifically, you will be integrating views implemented by your classmates.
2 Mechanics
Each group has been assigned two other groups: “providers” and “customers.” You must request code from your provider group: you will be emailed their names and email addresses. You should expect to need to email them a few times this week, as you may find issues with their code that you cannot address or repair by yourselves.
Similarly, your “customer” group will email you for your code. You are expected to spend some time supporting your customer group.1A small number of you may have your code used by two customer groups, because not everyone submitted sufficiently-completed code that could be used by other groups.
3 Code Exchange
The code you will share will be constrained to the following:
Your model interface(s), if any. This includes your main model interface, and other interfaces in the model package. It might include enums; it should not include implementation classes.
Your view interface(s). This includes all your view interfaces, features interfaces, and other interfaces in the view package.
Your controller interface(s), if any.
Your strategy interface(s), if any.
Only your interactive view implementations (i.e. the main view implementations and any other supporting classes from the view package) and your strategy implementation(s).
Your README file
The three screenshots of your GUI to show the customer what it looks like when it works.
You are not allowed to share or receive model implementations: the interfaces should be enough. You may exchange helpful implementation notes, but not actual code. If there is a need to know the implementations of certain classes from your model package and if those classes do not implement explicit interfaces, it likely means the coupling is tighter than it needs to be. If this is the case for the code that you share with your customer group, you will need to correct it and send the customers updated code. You can expect the same customer service from your provider group. (Note: you may have implemented simple value-classes, for instance to represent weekdays or requests for events, that you consider to be part of your logical interface(s). You may share those value-classes with your customers. If you aren’t sure whether a particular class has too much functionality in it to be considered a value-class, assume that it isn’t and should not be shared.)
4 Intended Outcomes: what you must do
There are four outcomes that you must accomplish in this assignment:
Make the views provided to you work with your code. You are not expected to write any tests for this. Add support for a new command line argument that launches the code with the provider’s view instead of your own. Make sure to clearly document your new command-line options in your README, so graders know how to run your program.
Retain the working features of your own views from previous assignments: i.e., you are not allowed to make changes in your code that make the providers’ code work, nor break your own views or strategies. In particular, the command-line arguments from the previous assignment should continue to work, and your view must be the default view of the program.
Write a comprehensive and constructive critique of the code given to you.
Write a review of your experience.
Additionally, update your README file to clearly document which features
of the provided views you were able to get working, and which ones you were not
—
5 Code issues
Since this assignment mixes your code with that of your providers, you may face
the situation where you have interfaces or classes with the same name, in the
same packages. Therefore, you should refactor your providers’ code to live in
the cs3500.nuplanner.provider package (subdividing into model,
view, controller and strategy packages within it as
appropriate), while retaining the package structure of all your code. You
should not change anything else about their code. Any and all edits to the
providers’ code (except the above package refactoring) must come from the
providers.
In general, if the views provided to you do not implement a feature that your views did (and your controller and model support) you are not responsible for changing the provided views to implement those features. Make sure you mention them in the critique below. Conversely if you get a view that implements optional features, you are not required to make them work with your model and controller. If required features are incomplete you can expect the provider group to make an effort to complete them, and conversely, you must make an effort to complete them for your customers. If for some reason you do not get repaired code or explanations from your providers and as a result you are not able the provided views work, be sure to mention this in your critique and README (see below).
6 Code critique
As customers of the providers’ code, you have the opportunity to praise, critique, comment upon, and suggest improvements to their code. In short, you should provide a code review of their code.
In that review, consider all the self-evaluation questions you have been asked during this course, and extrapolate from them the kinds of issues to examine. For example:
How flexible are the interfaces you were given?
How capable are the views?
How convenient was it to reuse their code?
How cleanly written and well-documented was their code?
If you needed to request changes from them, what were they and why were they needed?
Write a short (3-4 paragraph) review of their code. Your review should have the following sections: Design critique, implementation critique, documentation critique, design/code limitations and suggestions on how to address them.
Please concentrate on writing a review that is honest, but constructive. The reader should be able to understand what was wrong, and how to correct it. Please avoid simply criticizing the code given to you with no suggestions on how to make it better. Similarly avoid blanket praise: every implementation has flaws or limitations! Most importantly, please be professional in your writing. In summary, write a review that you would not mind receiving and acting upon.
Name this file PeerReview.txt, and put it in the same directory as your
README file.
7 Review of the experience
Submit a second, smaller review of your experience of this exercise. This review should include the following two aspects:
What do you wish you had done differently in your design/implementation? Did you learn any lessons from the code given to you, or the updates you had to make for your customers?
What was your experience like with your providers?
Name this file SelfReview.txt and put it in the same directory as your
README file.
8 Grading standards
For this assignment, you will be graded on
the coherence and thoroughness of your review of your providers’ code (i.e. you are not being graded on your providers’ code).
the coherence and completeness of your critique of your experience.
the quality and completeness of your final submission (i.e., the degree to which the provided views work successfully with your code).
You will not be graded (much) on the code you send to your customers. It will simply be style-checked, and worth a small portion of your overall Assignment 8 grade, to ensure that you submit something we can compare against your customers’ use of your code.
Your grade will generally not be affected by your customers’ review of your code. Your grade may be affected by your responsiveness (or lack thereof) and experience with your customers.
There will be two self-evals: a short one about the code you sent to your customers, and a longer one about the code you needed to write for this assignment. Make sure that you complete both. (Having two separate self-evals is necessary, so that you can tag lines in each submission correctly.)
9 What to submit
Submission of this project will be divided into two parts: the code you provided others, and the code you worked on.
For Hw8 – views:
Submit the final version of the files you sent your customers.
Submit a README explaining which files you changed for your customers, and why the changes were needed.
For Hw8 – code:
Submit all files necessary to make your code work (this includes your code and code from your providers).
Submit all the tests you’ve written (or completed) for assignments 5–7.
Submit your review of your providers’ code.
Submit your review of your experience.
Submit a README file summarizing which features you were able to get working successfully and which features do not work in your final submission.
Submit a JAR file (with extension
.jar) file that can run your program. Reminder: your program should now support additional command line options to launch the program with the provider’s view.
Please submit your homework to https://handins.ccs.neu.edu/ by the above deadline. Then be sure to complete your self evaluations by their due date.
1A small number of you may have your code used by two customer groups, because not everyone submitted sufficiently-completed code that could be used by other groups.