Assignment 9: From gOOD to Excellent

Due: by Wed 12/12 via a scheduled demo with instructors

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 several sets of features for several tiers of extra credit. These features are mostly independent, i.e. you can choose to attempt any subset of them in any order. Each feature is all-or-none: either it works perfectly or it doesn’t. However there are points in each feature for designing well, in addition to working correctly.

If you want to attempt another feature for extra credit, you must discuss it with a professor first. Every suggested feature in this assignment has impacts on all of your model, view and controller; any suggestion you make must do the same.

All of these changes are to be made using your own code (from Assignment 7). If you had not finished Assignment 7 functionality at that time, but finished it during Assignment 8, you may use the latter code.

1 Supporting column references

In commercial spreadsheet software, we can write formulas that refer to entire columns of data, no matter how many items are in them. For instance, =(SUM A:B) should add up all the values in columns A and B. Formulas like this should recompute any time any value in their columns gets changed.

Supporting this feature requires

• Adding a new form of reference to your model

• Adding new dependency checking to your model, to detect cycles and/or invalidations

• Avoiding any hard-coded limits on the number of rows in your spreadsheet

2 Supporting multiple worksheets in a workbook

Commercial spreadsheets support multiple worksheets within a single workbook. Each worksheet has a name, and contains its own set of cells and values. The key feature that makes worksheets useful is the ability to cross-reference between cells of multiple sheets.

Supporting this feature requires

• Extending your model with a notion of Workbooks and giving Worksheets names

• Extending your model (and the file reader and writer, if needed) to support references between worksheets, and detect cycles and invalidations as needed

• Extending your view and/or controller to display multiple tables somehow. Most commercial software uses a tabbed display; you may do something similar.

3 Graphing content

Commercial spreadsheets allow users to select a region of data and turn it into a graph — a line-graph, bar chart, pie chart, etc. As the data is updated, the graph updates to match.

Supporting this feature requires

• Constructing one or more new views to render different kind(s) of graphs

• Extending your model to store graphs somewhere within the worksheet (and updating the file reader and writer to match)

• Ensuring that the view is up-to-date as cells are modified or reevaluated

4 Allowing resizable cells

Commercial spreadsheets allow the user to resize individual columns or rows of the display, and to persist those changes as the files are saved and reloaded.

Supporting this feature requires

• Enhancing your view (and possibly controller) to allow the user to resize rows and columns

• Enhancing your model to store this data (and enhancing the file reader and writer to recognize it)

5 “Smart” copy/paste

Commercial spreadsheets allow the user to select a cell and “drag” the selection to any direction, to “smart-copy” the data from that cell into the new cells. The smarts come from automatically updating any references in the cell contents. Suppose the user drags the cell down by one: then the spreadsheet should add one to any references’ rows. This allows the user to easily “do the same thing” to all the rows in a table, once they’ve gotten it correct in a single row. Analogous automatic changes should occur in the other three directions. Of course, some references should not change; we call those references absolute. Clicking and dragging as the interaction mechanism is not required for this feature.

Supporting this feature requires

• Allowing the user to select a cell, “copy” it, and “paste it” somewhere else

• If the destination is in the same row or column as the source, then automatically update any references from the source to include whatever offset is needed

• Extend your notion of references to include absolute references (and the file reader and writer as needed). These are notated with a dollar sign on the row, column or both. For example, A$1 means “Currently column A, but absolutely row 1”. Copying this reference one column to the right would produce B$1, but copying it up or down would produce A$1 unchanged. Similarly, $B10 means “Absolutely column B, but currently row 10”. Copying this reference up or down would modify the row, but copying it left or right would leave it unchanged. Finally, you can have completely absolute references like $C$5, which do not change no matter where they are copied to.

6 Evaluation

You will demo your work to the instructional staff. 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 multiple features working, but you must comment them in or out to demonstrate them, that is not acceptable). If you have done multiple features, be prepared to show the two features you think you’ve implemented the best.

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.

7 Grading standards

This assignment will be graded out of a total of 7 points:

• 1pt automated code style

• 1pt (per feature): does the feature work flawlessly?

• 2pts (per feature): is the code well-designed, flexible, and thoroughly tested?

Each of these individual grade items are awarded either fully or not at all. 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 features 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. The grading only has room for two flawless features (3 points per feature), so when you present your work, present your best-implemented features.

Note: the assignment being graded out of 7 points does not necessarily mean that the extra credit is worth 7% of your final grade. It will likely be worth 4 points, possibly a bit more depending on how the overall grade distribution works out. We will announce on Piazza what the final worth of the extra credit will be, once we know it.