|
|
The following exercises, which come from the sequence diagrams within the model for our Internet Bookstore, are designed to test your ability to spot the top 10 mistakes that people make during sequence diagramming. Each page with a red label at the top contains three or four of these mistakes; your task is to write corrections on the page near the erroneous material. Following each of these pages is a page with a white label inside a black box at the top; this page contains corrected material and explanations of the top 10 rules that were violated on the previous page. Happy hunting!
On the previous diagram:
There is no Search Results object. This object would have been identified during robust-ness analysis, since we obviously aren't supposed to display the entire contents of the catalog. (Note that the case text on that diagram was incorrect as well in this regard.)
The Search Page sent a display message even though the diagram shows that the Catalog is in control.
The Catalog object invokes the displayErrorAndPrompt method on the Search Page.
On the previous diagram:
The use case test doesn't line up visually with the message arrows.
The Account object sent a display message even though the diagram shows that the Login Page is in control.
The arrow associated with the "reminder word" alternate course has a label, rather than behavior allocation in the form of a method.
On the previous diagram:
The use case text doesn't appear on the left side.
The Shipper Interface is missing; the fact that the Shipping Clerk talks directly to the Shipper means that the diagram doesn't show how the shipment gets recorded.
The Sensor object has control, even though this isn't logical for a sensor in this kind of situation.
On the previous diagram:
The second getItem method call clutters up the diagram.
The Item object sends a deleteItem message to the Shopping Cart object.
There are no destroy messages, which might indicate a hole in the designer's thinking, since the Items won't actually get deleted unless the system will be coded in a language, such as Java, that provides for automatic garbage collection).
On the previous diagram:
The use case test doesn't line up visually with the message arrows.
There is no Order Details object, which would have been identified during robustness analysis, and thus the use case text is wrong, as well.
The Order Table object invokes the displayNoOrderMessage method on the Order Tracking Page. It's a bad idea to have persistent database tables, or their proxy objects, invoking methods on the user interface.
|
|