Connie's Convenience Store - About Peter Coad

More documents

Recommendations

Info

42 Connie’s Convenience Store Establishing Responsibilities for Problem-Domain Objects #58. “Describe Attributes with establishing responsibilities / a Template” Strategy what I know (descriptions) • Describe each attribute, using a template as your guide. description legal values (range; limit; enumeration of values) unit of measure data type tolerance required (yes or no) get/set constraints how to get a default value from another source, in the event a custom value is not known applicable states (for state-dependent attributes) traceability codes (to a requesting document, if any). You might choose to write this in natural language; you might choose to write this in a formal specification language (like Object-Z, if you’re a “zed-head”). Or you might just want to sketch it out with programming language syntax. You may as well get in the habit of writing down some short descriptions. And you may even find some additional attributes and services along the way. (Ah! Some immediate gratification from doing this grunt work. That would be nice. Read on.) Work out some attribute descriptions for item’s attributes. Begin with number and description: – number: an identifying number, uniquely assigned by Connie’s required: yes – description: a name for the item (it may be a brand name) required: yes length = 20 characters – taxable: an indication whether or not this item is taxable enumeration of values: yes or no default: yes. 3 Hmmm. Something seems suspicious here. #61. “Yes/No Attribute” Strategy establishing responsibilities / what I know (consider and challenge) • Attribute has values “yes or no?” The attribute name itself may be a value for some other attribute name Example: taxable (yes or no); change to tax status (taxable, tax-exempt, resale). Why bother: added detail now, added ease of change in the future. 3 You’ll see very few attribute or service descriptions like this in this book. Writing descriptions is pretty straightforward. Reading them is unbelievably boring (and that’s not something for this book). Nevertheless, for some systems and organizations, detailed attribute (and service) descriptions are required writing. So be it.
Establishing Responsibilities for Problem-Domain Objects Connie’s Convenience Store 43 “Taxable” is a “yes/no” attribute, that is, it has the value “yes” or “no.” Check it out. “Taxable” is the name of a value: an item is “taxable” or “nontaxable.” Using a value as an attribute name is boring; it’s a “yes/no” kind of thing. Moreover, using a value as an attribute is unwise; as soon as you’ve got additional values, you’re in trouble; at that point, your object model will become more complex than it needs to be. Think about what happens at a store you visited recently. Are all items taxed at the same rate? Or do special taxes apply to certain categories of items? That’s it! Some categories of items may be taxable, while others are not. Instead of taxable, what an item object really needs to know is its tax category. Model that “need to know” with an object connection to tax category. Carefully examining each attribute does pay off. And writing attribute descriptions certainly gets one to consider that kind of detail. Based upon the added insight, here’s what item looks like now (Figure 1–27): Item number description shortDescription Figure 1–27: Item: “what I know.” Establish responsibilities: “who I know.” Who does an item object know? It knows: – UPC (zero or more). – price (zero or more). – tax category (zero or more). – sale line item (zero or more). Yes, each UPC, price, and tax category object knows its items. A sale line item knows its item, too (Figure 1-28). Establish responsibilities: “what I do.” Why do you need this abstraction, an item object? Certainly one reason is to remember the values of the attributes of an item. Yet there is a far more important reason why you might add an item object. And that reason is to capture some system dynamics. What does the system really need to do regarding its items? Hopefully, an item is something more than just a data holder. Look for something more than that. What can this abstraction do for you? Apply the “do it myself” strategy. Here it is again (it’s important):
Page 1 and 2: GETTING STARTED 1 Connie’s Conven
Page 3 and 4: Identifying System Purpose and Feat
Page 5 and 6: Selecting Objects Connie’s Conven
Page 7 and 8: Selecting Problem-Domain Objects Co
Page 19 and 20: Applying Patterns: Select and Organ
Page 29 and 30: Establishing Responsibilities for P
Page 41: Establishing Responsibilities for P
Page 55 and 56: Applying Patterns: Establish Proble
Page 61 and 62: Working Out Problem-Domain Dynamics
Page 63 and 64: Working Out Problem-Domain Dynamics
Page 65 and 66: Scenario: sale calculates its total
Page 67 and 68: Selecting Human-Interaction objects
Page 69 and 70: Establishing Human Interaction Resp
Page 71 and 72: Establishing Human Interaction Resp
Page 73 and 74: Working Out Human-Interaction Dynam
Page 75 and 76: Scenario: actual cashier logs on. S
Page 77 and 78: Scenario: sell item. Receipt SaleLi
Page 79 and 80: Scenario: get payment by check Rece
Page 81 and 82: Selecting System-Interaction Object
Page 83 and 84: Establishing System-Interaction Res
Page 85 and 86: Working Out System-Interaction Dyna
Page 87 and 88: Selecting Data-Management Objects a
Page 89 and 90: Working Out Data-Management Dynamic
Page 91 and 92: Progress at This Point Connie’s C
Page 93 and 94:
Progress at This Point Connie’s C
Page 95:
Wrap Up Connie’s Convenience Stor
show all

Connie's Convenience Store - About Peter Coad

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?