|
|
The following exercises, taken from the domain model for our Internet Bookstore, are designed to test your ability to spot the top 10 mistakes that people make during domain modeling. (The full domain model is presented at the end of the chapter and also in Appendix.) 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:
The cBinaryTree class is a parameterized class (also known as a template class within the UML). There's no good reason to start defining an implementation construct such as a binary tree at this stage of modeling.
The cLoginMgr class has an operation named verifyPassword. It's too early to make decisions about which operations go on which classes, and besides, chances are good that the operation belongs on the Account class anyway.
The name of the class we just discussed was not intuitively obvious.
On the previous diagram:
The name of the cSessionBeanShpngCart class indicated that the modeler decided to represent the concept of a shopping cart using a session Enterprise Java Bean (EJB). Robustness analysis, which we'll discuss in Chapter 5, is the appropriate stage to start exploring how to map classes to things such as beans.
A class that represents a shopping cart should be called Shopping Cart.
The class we've been discussing had a composition relationship with the Order class. The modeler committed to the idea that an Order disappears when the shopping cart object to which it belongs is destroyed. This may or not make sense in the long run, but it's certainly too soon to be thinking along those lines.
On the previous diagram:
The presence of the foreignInventoryDBKey attribute indicates that the modeler is looking ahead toward a relational database. (Note also that classes in your domain model shouldn't have attributes yet, and they certainly shouldn't have operations.)
The Order class has operations assigned to it.
The association between Account and Billing Info has a multiplicity.
On the previous diagram:
The presence of attributes named "price," "quantityOnHand," and "publisher," all of which probably belong in associated classes, indicates that the modeler is likely to have mapped an existing Order table directly to the Order class. (Also, as we mentioned for Exercise 3, classes in your domain model shouldn't have attributes yet.)
The Purchase Order class uses the Vector construct from Java.
The modeler has chosen to use the Proxy design pattern; domain modeling is too early to be making this decision.
On the previous diagram:
The Customer Review class has an operation.
The association between Item and Shopping Cart is a composition, but it's too early to know whether this makes sense as opposed to an ordinary aggregation.
The stereotypes on the Order and Candidate Order classes indicate a premature decision as to the layers to which the classes belong.
|
|