Question 1

           An on-line book seller has the following policy in regard to fulfilling orders for one or more copies of one or more
  books:

            First a clerk walks through the warehouse looking for each item in turn, and places the appropriate number in
            a large  plastic basket.  If any item cannot be supplied at all or cannot be supplied in the requisite amount, the
            order goes into a waiting state pending the filling of the tray with appropriate incoming stock. 

  When the tray is filled with all the books that the order specifies, the order then goes for packing, addressing and
  the application of the appropriate postage in the form of stamps or franking of the parcel. 

  At some point the ready-to-go parcel is removed from the dispatching room and is placed, along with any other
  ready-to-go parcels in a van that drives off out of the front gates of the warehouse complex.

  Represent the above description with a state diagram, explaining all your notation.  If you feel that anything
  is missing in the above description, then make an intelligent assumption that can be clarified with the domain
  representatives at the next meeting.

Text in italics below would not necessarily be expected in the answer in the exam.  I took the opportunity to amplify one or two things. 

Answer: 

Consider the diagram above.  It shows a number of states in which the order can be. 

The top left rounded squares is the state it's in while a clerk is running to and fro along the passageways among the warehouse shelves looking for products in the amounts required to fulfil the order.  Each time he/she finds an item in the requisite amount, he/she adds it to the tray in which this particular order.  If there's a shortage of items to fulfil the order then the order goes into the state shown in the bottom left.  There it waits for deliveries into the warehouse of fresh stock relevant to the order.  The state on the top right is where the order is being weighed, wrapped, stamped and addressed or simply waiting as a fully prepared parcel after those things have been done.   The state on the bottom right is the state the order is in when the associated parcel has left the warehouse on its journey to its destination.  There's still a representation of the order in the company's computer system, but the goods associated with it have departed. 

The states are connected by labelled unbroken open arrowed lines representing transitions from state to state.  Each label is of the form

Event[Guard]/Action

Generically one or more of these three parts of a label may be missing.  In this case study there are missing parts to some of the labels but, as it happens, there is no example of all three parts being missing. 

If two states, c and d, as shown above, are connected by a transition label marked e[g]/a, then, this is read as:  while in the state c, if event e occurs, provided that the condition g is true, then a transition to d occurs and also the action a takes place. 

Note that if the guard is untrue, then neither the transition nor and action take place.  The guard g may be a boolean combination of several guards using boolean operators such as &&, meaning AND and || meaning OR.  If there's no event on the label, then the transition, if allowed by the guard, takes place when the activity associated with the state is complete.  Activities associated with the state are shown in the middle of the state's rounded rectangle, with the syntax do/activity. 

The first transition in the first diagram above is from the the start state, a pseudo-state represented by a solid black circle.  There is an imaginary activity associated with this state which when finished allows the transition into the first real state.  The transition is accompanied by the action get first item. 

When the activity associated with the checking state is done, then a transition is made according to which guard is true.  Notice that the guards in this case form a complete set, i.e. there must be no overlap of the conditions and the conditions must cover all the possibilities so that precisely one transition can be taken.  If the transition back into the checking state is taken, then another item is checked and, possibly, so on, repeatedly. 

Note that the waiting state must have en event associated with it to allow transition out of it.  This is because there's no activity associated with it, the completion of which would allow transition away from the state. 

In principle the diagram seems to suggest that the transition from the dispatching to the delivered states could occur so that the procedure of initiating delivery, involving weighing, parcelling etc could be rudely interrupted by the Delivered event.  There is, however, an extra constraint here, not shown on the diagram, that ensures that the transition to dispatched can only occur when the activity associated with the dispatching state is complete.  There is, indeed, a way of adding labels to UML diagrams to shown such constraints, one that isn't used her.  Suffice it to say here, that it's common sense that this constraint exists. 

The above answer represents most of the theory of state diagrams.  For completeness, I add the following here:

If an object in a particular state responds to an event with an action that does not cause a transition, you can show this by putting text in the form eventName/actionName in the state box. 

Activities are associated with states
Actions are associated with transitions
Each is implemented by an object invoking a member method of its own class.  In an interaction diagram this corresponds to a line from one object flipping back on to itself. 

Events on the other hand, whether or not they result in a transition, are implemented though a method invocation coming from another object.  In an interaction diagram, this corresponds to a line from one object to another. 

Question 2

        Explain a technique or techniques whereby a system of classes can have responsibilities allocated to them so as
 to play by invoking each other’s methods, a balanced part in providing a solution to a particular use case or
 scenario. 

  You may wish to refer to your work, so far, in designing the lorry loading system, or to some other example. 

One way in which this can be done is through the use of CRC (class responsibility collaboration) cards.  Whereas class diagrams show attributes and operations, CRC cards show responsibilities.  Thus it might be the responsibility of an account object to show its bottom line balance.  Whether this is done by the account object algebraically summing its debits and credits (an operation) or keeping a record of such (an attribute) isn't important.  Generally there's shouldn't be any more than three or four responsibilities.  Too  many of these suggests that there should be a wrapping up of some of these responsibilities into a higher level responsibility or a factoring out among more classes. 

The cards can be moved around the literal desktop or held up in the air has developers try to work out what each should do and pencil in responsibilities and collaborating classes on to the cards. 

It is much quicker to use CRC cards for exploring alternative ways of implementing a scenario than it is to draw interaction diagrams on a white board and then rub them out again.  CRC cards can be used to highlight cluttered classes that do a lot of the work in carrying out a scenario and leave the other classes to be little more than dumb data holders.