I was triggered by the following sentences:
"The traditional way of explaining object analysis involves identifying nouns and verbs in the requirements documents and using them as the initial objects and methods' p-189
And
"Eventually, after months working with shipping experts through many iterations, we evolved a quite different model. It was less obvious to a lay person, but much more relevant to the experts. It was refocused on the business of delivering cargo.....The shipping container all but disappeared'"

It is related to the 'Cargo' example. In fact, I have worked on a case which also aimed at the 'Shipping business'. However, our team didn't come across the problem with the 'shipping container'. This was mainly because we used a business process modeling methodology before making a model of the system in UML, called DEMO (Dynamic Essential Modeling of Organizations). Personally I think this method is very helpful in getting a good (UML) domain model, when the domain relates to business processes (eg the cargo example, not the PCB example), because it focuses on communication and essential transactions, without introducing a large gap between analysis and design (there are also some researches going on to formalize the transition from the DEMO model to the UML model). My personal opinion is that applying this method helps you to get the 'big picture' at the right conceptual level (a message-tread on 25-6-2003 in this group). The following link is a document which describes the added value of the DEMO method to UML. Maybe it's interesting to read and helpful in domain modeling....

http://www.demo.nl/documents/2001-EMMSAD-1.pdf

kind regards,
ChristiaanDesBouvrie

BusinessProcessModeling is mentioned on: ThreadView