Connie's Convenience Store - About Peter Coad
Connie's Convenience Store - About Peter Coad
Connie's Convenience Store - About Peter Coad
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
20 Connie’s <strong>Convenience</strong> <strong>Store</strong> Applying Patterns: Select and Organize Problem-Domain Objects<br />
Apply the participant-transaction pattern (Figure 1–9):<br />
Cashier<br />
Register<br />
Figure 1–9: Cashier, register-session.<br />
Note: the connecting lines are object connections. An object connection is a graphical<br />
attribute, showing that one object knows about some number of other objects.<br />
Note: the markings at the end of each object connection are called object connection<br />
constraints; each constraint is placed next to each object, expressing what it knows<br />
about other objects. Here, a session knows one cashier and one register; a cashier object<br />
knows some number of session objects; a register object knows some number of session<br />
objects, too (Figures 1–10 and 11):<br />
Cashier Session<br />
Figure 1–10: An object connection with a constrant.<br />
Cashier<br />
n<br />
n<br />
n<br />
Session<br />
Session<br />
Figure 1–11: What an object connection and its constraint represents.<br />
Another note: this is just the opposite of the entity-relationship convention for what<br />
that approach calls “multiplicities.” Why? There is a good reason for this. (Actually, the<br />
credit for this goes to our clients and seminar participants. They asked us again and<br />
again: if you’re constraining a session, why are you marking it on the other end of the<br />
line? That got us thinking. And it helped us to change.) You see, entity-relationship<br />
markings reflect “table think”: one row here keys to some number of rows there. Some<br />
1<br />
1