Assignment 8: Beyond gOOD: A Simple Spreadsheet, Part 4

Due: Wed 12/04 at 8:59pm; both self-evaluations due Thu 12/05 at 9:59pm

This assignment is to be completed with the same partner as Assignment 7, unless you’ve already contacted the course staff.

In this assignment you will experience some effects of your design decisions, and practice working with implementations not written by you. Specifically, you will make your spreadsheet application work with views written by someone else.

1 Mechanics

Each group has been assigned two other groups: “providers” and “customers.” You must request code from your provider group: you have been 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.

We will email you the contact information of your providers and customers as soon as possible.

2 Code Exchange

The code you will share will be constrained to the following:

• Your model interface(s), if any.

• Your view interface(s).

• Your controller interface(s), if any.

• Your visual and editor view implementations (i.e. the JFrames and any classes you implemented in the edu.cs3500.spreadsheets.view package that they depend upon).

• A short README file that summarizes, in point form, which features of each view work. This may include a short description of your UI for the editor view and how your users can use your program (since the UI decisions may be different from yours).

• A screenshot of the UI of your editor view (the same one you submitted for Assignment 7).

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 colors or points, 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.)

3 Intended Outcomes: what you must do

There are four outcomes that you must accomplish in this assignment:

• Make the editor view 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, -provider, which will use the providers’ editor view with the rest of your code.

• 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, but break your own views. In particular, each of the -eval, -save, -gui, and edit command-line options should continue to work with your existing code.

• Write a comprehensive and constructive critique of the code given to you.

• Write a review of your experience.

4 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 edu.cs3500.spreadsheets.provider.view package, 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 to make all 4 views work, be sure to mention this in your critique and README (see below).

5 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 and courteous in your writing. In summary, write a review that you would not mind receiving and acting upon.

6 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?

7 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.)

8 Submission

Submission of this project will be divided into two parts: the code you provided others, and the code you worked on.

• For Assignment 8-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 Assignment 8:

  • 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. Again, your JAR file should support a new command-line argument (-provider) which will use the providers’ editor view with the rest of your code, and all the other command-line arguments should still work!

To create a JAR file, follow the instructions from Assignment 7.

Please submit your homework to https://handins.ccs.neu.edu/ by the deadline above, and the self-evals by their deadline.