View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Spring 2003 Midterm Key

Q1. History

I don't care much about specific exact dates, but the student should show some knowledge of how we got here.

15 Points total, 5 per valid fact. These would be the 3 or 4 points I would use. You can use your disgression to accept other points you feel are valid facts to refute the argument. Just don't accept appeals to emotion etc.

OO is not relatively new i.e. not from nineties – Cite Simula and sketchpad from 60's.

C++ was not first OO language. Concepts in C++ from Simula, and Smalltalk greatly preceded even C with Classes (the precursor to C++).

Stroustrup influenced by Alan Kay and his concepts of objects/classes.

OO is not a fad it is a design methodology as much as a programming paradigm. Accept any type of argument about older verb-oriented methods as opposed to current noun-oriented methods.


Q2. 20 Points total, 10 per sub-question.
Part A. Man if they miss this, they definately are not coming to class or taking the quizzes.
Receiver Object Message Parameter
Transcript show 'The answer is: '
10 + 3
13 // 2
6 even
Transcript show true

Transcript result: The answer is: true

Crud, the table doesn't preserve the spacing, but I think you get the idea anyway.

2 points for correct transcript output
1 point for each correct line in the table
3 points for correct order of all lines in table

Part B.
replace: aString
^aString collect: [ :ch | (ch isVowel)
ifTrue: [ ch ]
ifFalse: [$-]. ]

1 point for method header
3 points for recognizing collect is proper collection message
2 points if code works correctly
4 points for correct block on the collect.

So if someone does not use collect (or select/do/reject) they can only get a 7/10 max even if their code works. Part of using Smalltalk is properly using the language features, not just hacking till something works. Watch out too that they use the $- and not '-' which I didn't catch on myself until I executed the code in the workspace. If they send a vowel message to the character rather than isVowel, you can mark the test, but don't count anything off. I don't expect them to know every API call for the class structure.


Q3. On the design critique, they need 5 solid comments (not trivial stuff) so each comment is worth 4 points (20 total). They may have other valid comments besides the ones I made, use your disgression and knowledge–just be sure they use real design principles and terms, not hand-waving.

1. Improper inheritance in Piece. Red and Black pieces differ only in color-not behavior, so color should just be an attribute of piece.

2. Checkers is a class with low cohesion. It does too many things. It appears to control the game, draw the board, manage the players, etc.

3. Checkers appears to have high coupling (a side effect of the low cohesion). It has knowledge of a lot of classes and starts to look like a 'god' class.

4. Square violates the Open-Closed principle. A class should be open for extension, but closed for modification. If we add a new type of piece we would need to also change the draw method in Square.

5. Interface to piece poorly designed. Specifically, should expose a standard Draw method. This would solve the design problem in #4 since now Square does not care about any kind of piece, it just calls Draw.

6. The isKing test is inadequate for proper design of Piece. It limits extensibility and shows improper inheritance. The king piece in fact has different behavior and move rules than a regular piece so most likely should be a subclass, not just a boolean test.

7. Use of delegation is good. Checkers delegates to board and player specific responsibilities. It could be argued that the abstract class BoardGame should delegate to Board since a key concept in the domain of games is that all BoardGames have a board.

8. The design also violates the Dependency Inversion Principle. All our classes rely themselves on concrete implementations rather than abstract interfaces.



Q4. 30 Points.
Part a. (5 points) Candidate classes. Did the student recognize that nouns were significant. Some candidate classes are:
pass employee park location venue staff area supervisor gates reader name address department (you get idea)
Part b. (15 points) CRC cards. (Sorry formatting gets bombed)
Pass
Responsibility Collaborator
Tell the access privledges for the holder Reader

Reader
Responsibilty Collaborator
Get pass holder Pass

Check duty status of pass holder Overall_System

Open gate if pass has proper privledges Gate

Pass
Responsibility Collaborator
Know who owns me Pass_Holder

Pass_Holder
Responsibility Collaborator
Know privledges

Overall_System
Responsibility
Know whether an employee is on duty

Gate
Responsibility
Open on proper signal

Part c. (10 Points) UML Diagram. Here I am mostly interested not in "sqiggle counts" i.e. strict syntax grading, but in how well they could correctly convert their CRC cards to a UML diagram. Obviously they will have more classes than are in the CRC cards since we only do one scenario. So only use 2 points for syntax issues and the remaining 8 points here for decent design and correct transition from CRC to the class diagram.

Uploaded Image: midterm.jpg

I know you may look at this and say, "That's not the way I would design it" and that's OK. This is not a student mind reading exercise. I tried to take the test within the students time frame. It's not fair to grade them against a design I spent 5 hours perfecting when they have 1 hour. So the point is, do they "get it". Can they do OOA/OOD at a decent level or are they hopelessly lost??



Q5. 15 Points total

6 Points (2 per item) for being able to define MVC as Model-View-Controller and to define each of these three components correctly as to their role in the paradigm.

9 Points (3 per item) is for being able to then relate how each of these things works in the simple example of Excel. For example,
The numbers in the spreadsheet form the model. They are the data that relate to the real world. The controller runs the event loop which captures the spreadsheet change and routes the appropriate message to the model. After the model handles the change it announces the change to the system. All views that are interested in that change then update themselves and display the new information.






Link to this Page