1.(i)

The right diagram is the better one.  For some discussion, see lecture 14 from last year:
http://www.cs.cornell.edu/Courses/cs5150/2011fa/syllabus.html

For scoring this one we gave some points for choosing the right diagram and some for writing a sensible justification.


1.(ii)

The problem with the diagram is that it does not indicate how the state of the shopping cart is maintained.  The simplest way to fix the diagram is to join the two boxes on the right.

For scoring, we gave a substantial amount of partial credit for observing that the state of the shopping cart was the important issue.

As indicated in lecture, we made a mistake in scoring this question.  There is a 'loop' construct in sequence diagrams that is appropriate in this case, but for which we did not give credit.


2.

There were many acceptable answers for this question some are:
Project 1:
- Informal design review with peers
- Small-scale user testing
- Competitive analysis
- Seeking UI/UX expert opinion
- Focus groups

Project 2:
- Large-scale user testing
- Lab-based measurements
- Competitive analysis

For scoring, we binned answers into "good" and "okay".  For full credit you needed two good answers for both parts.


3. Concurrency

For isolation, the order should be
1) Processes
2) Threads
3) Event handlers

For transactions, the order should be
1) Event handlers
2) Threads
3) Processes

The scoring went like this:
1) The isolation part was worth more than transactions
2) Each correct ordering relationship (e.g. Processes above Threads) was worth some number of points.
3) In both parts, getting the first one first was the most important.

The two most controversial ordering relationships:
1) isolation, threads before event handlers.  The reason for this is that event handlers can prevent other event handlers from running by hogging the CPU.  In (preemptive) multithreading systems, this kind of starvation cannot occur.
2) transaction, threads before processes.  The reason for this is that there are usually richer and more reliable primitives (mutexes, semaphores, 'synchronized' blocks) for synchronizing between threads, compared to processes.