This was supposed to be a pretty straightforward exercise in the Visitor pattern. I've always felt that Visitor is a difficult pattern in that it deploys hard OO concepts in a complex environment.
Judging from the questions during office hours many students couldn't imagine why the Visitor pattern was news. I had the distinct impression that some had never really met a polymorphic callsite before.
I hope by now the students didn't get too hung up on Boundary objects. I imagined a use case that would be invoked from some actual user interaction along the lines of "Calculate mean". If they insisted on a use case that started out with fictitious boundary objects that's okay, but unnecessary.
Given the science fiction aspect to the domain please do not penalize students for making stuff up. I left the task very vague hoping that this would allow students to write very general use cases but this is not the route some of them took.
Students that proposed a use case originating from an actual user interaction cost themselves a lot of extra work in making the robustness diagram and sequence diagram. Only look at the portions to do with Visitor.
Again, just make sure that the Visitor part is right. We really don't care about the stuff the students have invented to get the Visitor kicked off.
The Visitor must send accessor messages to the objects that actually own the data, probably the quad.
We want to see iterator methods, which classes implement the iterator interface and the visitor classes and methods corresponding to the sequence diagrams.
There may be some confusion because Java, the text, and modern C++ usage (i.e. the Standard Template Libraries) are all a little different. The primary difference is that Iterator is an interface in Java whereas the modern C++ idioms use template classes. All are fine so long as they are consistent. If you run into an idiom you don't know then let me look at the paper. I hope I know all the idioms the students unearth.
| marks | Comment |
|---|---|
| 2 | Appropriate Use cases. In fact, a relatively trivial "calculate mean" should get 3. If the use case is cast as one meant to be invoked from other use cases it may mention something like "apply mean Visitor". |
| 3 | Robustness diagram corresponds to the use case -- we're only really interested in the Visitor part. It's okay if it's muddled up -- after all it's supposed to be a preliminary design step. |
| 5 |
The Sequence Diagram should clearly show how Visitor
works. Consult the diagram on page 335 of the text. They
should show methods "double dispatched" back to
the Quads from the Visitor.
|
| 5 | The Class Diagram should clearly indicate where the Iterator methods are and that they have the data they need to work with. |
| 5 | The Class Diagram should clearly indicate the Visitor classes and include the visitor methods on the Quads. There should be separate Visitors for mean and stdev unless there is a note explaining why they have been combined. (I don't think there is a good reason, but nevertheless, it's not a big deal.) The Visitors should include instance variables to store the intermediate calculations. For instance, the standard deviation visitor should have a variable to store the running total of the sum of squares. The actual math of the algorithm needn't be spelled out. An ideal solution would probably have a note referring to some stats handbook. |
| 20 | Total |
Suggested quality to marks:
| 5 | Excellent | superior grasp of the subject matter | no problems |
| 4 | few and minor problems | ||
| 3 | okay | a few more problems, none major | |
| 2 | marginal | some slight evidence that they understand. | |
| 0-1 | inadequate | little to no evidence of even a superficial understanding of what is required | |