I. Design Model: Use-Case Realizations with GRASP Patterns (Larman, Ch 17) A. Use-Case Realizations (17.1) ------------------------------------------ USE-CASE REALIZATIONS (17.1) Relationships: - Use-cases suggest the system events shown in system sequence diagrams. - Details optionally given in contracts. - System events represent initial messages in interaction diagrams. - Interaction diagrams show messages sent among classes inspired by domain model. ------------------------------------------ B. Artifact comments (17.2) 1. splitting sequence diagrams per system event 2. contracts 3. caution: the requirements are not perfect 4. conceptual vs. design classes C. Use-case Realizations for the POS System (17.3) 1. makeNewSale system operation (17.4) What patterns are relevant? What things is the Register's makeNewSale method responsible for? What patterns are relevant? 2. enterItem (17.5) What do we have to do? What patterns are relevant? Who does display of output? Now how does Register's enterItem operation work? What next? Who should be responsible for knowing how to find a ProductSpecification from an itemID? What patterns apply? Who asks the ProductCatalog for the product specification? 3. endSale (17.6) What patterns apply? Who's responsible for knowing the sale total? 4. makePayment (17.7) Who handles this message? Who creates the Payment instance? How to decide between these two? Who is responsible for knowing all the logged sales and doing the logging? Who is responsible for knowing the balance? 5. startUp ------------------------------------------ THE START-UP DESIGN (17.8) Leave the initialization design for last. Record notes on that has to be done as you design the rest of the system. Common design idiom: - create an initial domain object - it's responsible for creation of other domain objects. E.g., public class Main { public static void main(String[] args) { // create initial domain objects Store store = new Store(); Register register = store.getRegister(); // start up the UI ProcessSaleJFrame frame = new ProcessSaleJFrame(register); // ... } } ------------------------------------------ What should the inital domain object be? Who gets control? how to deal with persistent storage, such as a database? What are the responsibilities of Store's create method? D. Connecting the User Interface Layer to the Domain Layer (17.9) ------------------------------------------ CONNECTING THE UI AND DOMAIN LAYERS (17.9) How does the UI get access to domain objects? - An initial method (e.g., main), creates the domain object and the UI object, and passes the domain object to the UI object - The UI retrieves the domain object from a well-known source (e.g., a factory object) How does the UI get information to display, etc.? - Ask a facade object for it - Get a domain object from the facade, and ask that directly - Register for events with domain objects How does the UI know when to do display? - Tracks state of system - Facade object tells it - Waits for events from domain objects ------------------------------------------ Which of these is better? E. Use-case realizations within the UP (17.10)