Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Exercise Solutions (Unrestricted)

Chapters 1 2 3 4 5 6 7 8 9 11 12

Chapter 5

Question 5.4
"We would typically call up yesterday's menu. We would check with Chef to see if any particular stock items need using up via any particular dishes. I guess that maybe the system could help us with alerts as to any expensive stock approaching its use-by date. We would amend the menu to remove dishes not on offer today and to add the new dishes like the stock-using dishes and any other dishes that the manager or Chef have planned."

(You) "Would you type up the details of each new dish?"

"Well I guess there might be totally new dishes; but mostly we would want to call up some kind of overall dish list, where the typical price, description, etc. was already entered. Sometimes we would have to amend the defaults – for expensive ingredients whose prices fluctuate wildly, for example."

(You) "And would you be changing yesterday's menu to become today's? Or would you be leaving yesterday's menu on record and creating today's from it?"

"Oh, we would definitely want to keep a record of previously used menus; we'd simply be using yesterday's as a typical starting point. I imagine there would be times, though, when we'd create a menu completely from scratch."


Given the above dialog, what extra questions would you have asked if you had actually been there?

  • How are the dishes assigned to menu sections and departments?
  • Might you create dishes by copying old dishes?
  • Might the system help you find the dishes that use particular ingredients?

[This question, of course, is an open question. Those were just the questions I'd have liked to have asked. You may have others. JD]

[As noted in question 3, the last one is doubtful. Sadly, sociology and the accounting considerations tell us "never volunteer" unless it improves your chance of success, and your system's chance of success. JD]

Question 5.5
Rewrite the following requirements of POIROT and ALICE to be clearer and more precise. They don't necessarily have to be correct. In other words, your job is to make them less ambiguous, you won't necessarily have the information to make them more correct.

  • "The system must accept crimes."
    "The system must register the details of a reported crime, typically including, but not limited to, the name and address of the person reporting the crime, and the date and time the reporter reported the crime."
  • "Match fingerprints."
    The system must locate and identify all recorded fingerprints available within the [censored] database list with greater than 9 points of similarity, listing the databases that were accessed and the accessible databases that were not searched.
  • "Produce bills."
    The system must compute the current bill for a selected order, part of order or group of orders.


Question 5.7
You have limited time (as ever). Using your own knowledge of staying at hotels (or using your imagination), write up two important and illustrative use case scenarios for POLLY, the hotel system development mentioned in Exercise 3.3.

Use case name:
   Successfully checking in having already booked but not having preselected room
Use case reference number:
Initiating event:
  Guest succeeds in attracting the attention of a member of staff serving on reception.
Key outputs: Room entry card produced and room door programmed
Key state changes:
  Guest and room status updated
  The receptionist is enters the guest's family name into the system, no booking reference number being available (as is typically the case).
  The system successfully locates and displays the booking.
  The receptionist confirms the recorded departure date with the guest. In this instance it is correct.
  The receptionist asks the system to suggest a room, given the party size (one in this instance), length of stay, smoking preference and discount given (the bigger the discount the worse the room.)
  The receptionist (in this instance) OKs the system's room suggestion.
  The receptionist asks the guest if a newspaper or an alarm call is required.
  Both are requested and the receptionist informs the system.
  The system updates the room's status to "occupied" and also records the guest to booking allocation.
  The system updates the occupancy's status to "checked in".
  The system prompts the receptionist to prime the key-creating system (put a key-card in the reader/writer in this instance).
  The system transmits sufficient information to the key-creating system, which report successful key creation and door programming.

[If the book's primary focus were requirements, we could of course go deeper into all of this. We could look at Cockburn's forms for use cases. We could consider goals instead of outputs and state changes. We could specify preconditions. We could enumerate stakeholder interests.
One thing I thoroughly disagree with, at the moment, and using use cases the way I use them -- to illustrate and enliven the requirements rather than attempting the impossible by attempting to make use cases constitute the whole of the requirements -- is putting in branches and alternatives. A use case should not be yet another flowchart in yet another form.
Something, however, that I do thoroughly agree with is factoring out sub use cases when things are starting to settle down, relating use cases via the includes (or "calls") relationships and being very sparing with the much more confusing and fragile UML extends and generalizes relationships amongst use cases. JD]

Use case name:
   Successfully checking out on the morning of departure
Use case reference number:
Initiating event:
  Guest reaches the head of the checking-out queue at long last.
Key outputs: Invoice and room door programmed
Key state changes:
  Guest and room status updated, and payment recorded
  The receptionist identifies the room and confirms the guest's identity (in this instance with their name).
  The receptionist adds the missing mini-bar items the guest has consumed.
  The receptionist requests an invoice printout.
  The receptionist confirms the invoice with the guest. In this instance it is deemed correct.
  The receptionist informs the system that the room is vacated.
  The system updates the room's status to "dirty" and the occupancy's status to "checked out".
  The receptionist informs the system that payment has been successful, when (s)he has determined that to be the case.
  The system updates the occupancy's status to "paid".
  The system transmits sufficient information to the key-creating system that the room's door can be reprogrammed if necessary.

[As we have limited time, we have been careful to choose critically important and highly illustrative use cases. JD]


Question 5.9
Think about and write up a SWOT (strengths, weaknesses, opportunities and threats – essentially an enhanced version of pros and cons) analysis of prototyping as a technique in software engineering.

SWOT analysis of Prototyping
Strengths Weaknesses
A cost-effective exploration technique
Software prototypes can easily [and mistakenly JD] be made to look like a finished product
Software prototypes resist being thrown away
The term "prototype" has perhaps lost its connotation of "mock-up" in software engineering
Software prototyping gets confused with staged delivery
 - in the minds of management
 - and in the minds of developers
Software prototypes were (are?) one of our "silver bullets"
Opportunities Threats
Validating crucial design decisions/possibilities
Answering crucial questions
Evaluating crucial technologies
Customer getting wrong impression of progress
Management getting wrong impression of progress
Developers getting wrong impression of progress
Surreptitious mutation into version 0.9 or version 1
Prototypes particularly GUI/VB becoming design drivers (RAP/RAD)

[As you're possibly aware, your author is skeptical about RAP/RAD -- rapid application prototyping/development -- and methods that involve "rapid" promises, or snake oil or silver bullets. VB (visual basic) is a great way to develop, or mock-up, interfaces; but screen mechanisms are a poor design driver and a poor place to put application logic. JD]