1. OO Methodology Elaboration Phase Iteration 1- Part 3

2. 2 Table of Contents Use-case model: System Sequence Diagrams Domain Model: Visualizing Concepts Domain Model: Adding Associations Domain Model: Adding Attributes Use-Case Model: Adding Detail with Operation Contracts From Requirements to Design Interaction Diagram Notations GRASP: Designing Objects with Responsibilities Design Model: Use-case Realizations Design Model: Determining Visibility Design Model: Creating Design Class Diagrams Implementation Model

3. 3 Design Model: Use-Case Realizations Objectives –design use-case realizations –apply the GRASP patterns to assign responsibilities to classes –use the UML interaction diagram notation to illustrate the design of objects Use-case realization –describes how a particular use case is realized within the design model, in terms of collaborating objects [RUP] –UML interaction diagrams are a common language to illustrate use-case realization –principles and patterns of object design such as GRASP should be applied during the design work Relationship between UP artifacts –Use case suggests system events –SSDs identify system operations –System operation contracts detail the effect of system events –System events represent messages that initiate interaction diagrams –Domain model inspires the software classes –Interaction diagrams involve message interaction between software objects

4. 4 Interaction Diagrams and Use-case Realizations Consider Process Sale –makeNewSale, enterItem, endSale, makePayment Collaboration diagram –a different collaboration diagram to handle each system event

5. 5 Interaction Diagrams and Use-case Realizations Sequence Diagrams

6. 6 Contracts and Use-Cases Operation: enterItem(itemID: ItemID, quantity:Integer) Cross references: Process Sale Preconditions:There is a sale underway Postconditions: - A SelesLineIterm instance sli was created - sli was associated with the current Sale - sli.quantity became quantity - sli was associated with a ProductSpecification, based on itemID match

7. 7 Use-Case Realization: NextGen POS Object Design : makeNewSale –choosing the controller (Controller) Facade controller : Register  Use-case controller : ProcessSaleHandler –creating a New Sale Register records Sale (Creator) –creating a Collection of SalesLineItems Sale creates it (Creator)

8. 8 Object Design: enterItem Choosing controller class –Register (Controller) enterItem(id,qty) Displaying Item description and price –it is not the responsibility of non-UI objects Creating a New SalesLineItem –Sale is an appropriate candidate (Creator) makeLineItem() Finding a ProductSpecification –who should be responsible for finding a ProductSpecification? –who knows about all the ProductSpecification obejcts? –ProductCatalog contains ProductionSpecifications –ProductCatalog is candidate for lookup responsibility getSpecification() Visibility to a ProductCatalog –Who sends getSpecification() to ProductCatalog? –Register delegates creation of SalesLineItem to Sale –How does Register know ProductCatalog? the permanent connection between two should be initiated at startUp use case –add this requirement into task lists for design of startUp

9. 9 Object Design: enterItem Retrieving ProductSpecification from a Database –will be discussed later Message to Multiobjects –generic collection operations such as find and add

10. 10 Object Design: endSale Choosing the controller class –Register (Controller) Setting the Sale.isComplete attribute –who responsible for setting it? –Sale (Expert)

11. 11 Object Design: endSale UML Notation to show constraints, Notes, and Algorithms

12. 12 Object Design: endSale Calculating the Sale Total –In Step 5 in the use case, a total is presented. Who should be responsible for knowing its total? –Information required to calculate Total subtotals of all the sales line-items (Sale by Expert) a subtotal = lineitem quantity * price lineitem quantity (SalesLineItem by Expert) price (ProductSpecification by Expert) –Sale is a good candidate (Expert) getTotal() –SalesLineItem should be responsible for knowing a subtotal getSubTotal() –ProductSpecification is responsible for knowing the price getPrice() getTotal() is not system operation. Who sends the message ?  Most likely, it will be an object in UI layer

13. 13 Object Design: endSale Algorithms and Notes

14. 14 Object Design: makePayment Choosing a controller – Register Creating the Payment –Register records the Payment (High Coupling) –Sale will closely use a Payment (Low Coupling)

15. 15 Object Design: makePayment Logging a Sale –who is responsible for knowing all the logged sales, and doing the logging? in the Domain model, Store knows all the logged sales alternative : SalesLedger (High Cohesion) –added to the Domain Model

16. 16 Object Design: makePayment

17. 17 Object Design: makePayment Calculating the Balance –Process Sale use case implies that the balance due from a payment be printed on a receipt –Who responsible for knowing the balance? required information –Sale Total (Sale by Expert) –Cash Tendered (Payment by Expert) consider low coupling and high cohesion –Payment is already visible to Sale –Sale supports low coupling

18. 18 Object Design: startUp Use Case Most systems have a Start Up use case and some initial system operations related to the starting up of the application When to create the Start-Up design? –Delay the development of an interaction diagram for it until after all other system operations (under development in the iteration) have been considered –The initialization activities can be discovered during the development of interaction diagrams of other operations e.g. when considering enterItem, we assumes that Register and ProductCatalog have been created and ProductCatalog is visible to Register How applications start up? –Common design idiom is to create an initial domain object –The IDO, once created, is responsible for the creation of its direct child domain objects e.g. If Store is chosen as the IDO, it may be responsible for creating a Register object –Choose as an IDO a class at or near the root of the containment or aggregation hierarchy of domain objects e.g. Store or Register is a good candidate Where the IDO is created? –depends on the object technology chosen main method in a Java application

19. 19 Object Design: startUp Use Case Choosing IDO –Store is chosen, Register(Low Cohesion) Creating a Store –tasks of creation and initialization derive from the needs of the prior design work Store, Register, ProductCatalog, ProductSpecification need to be created (from prior design work for ProcessSale) ProductCaltalog need to be associated with ProductSpecification Store needs to be associated with ProductCatalog Store needs to be associated with Register Register needs to be associated with ProductCatalog (enterItem)

20. 20 Connecting the UI Layer to the Domain Layer Common design idiom –object in the UI layer obtain visibility to objects in the domain layer –In java public static void main(String[] args) { Store store = new Store(); Register register = Store.getRegister(); ProcessSaleJFrame frame = new ProcessSaleJFrame(register); }

21. 21 Connecting the UI Layer to the Domain Layer How does the UI show the running total? –Solution 1) Add getTotal() to Register and UI sends getTotal() to the Register, which forwards it to the Sale low coupling, but Register less cohesive –Solution 2) UI asks for a reference to the current sale object, and then it directly sends getTotal() to the Sale high coupling, but Sale object would be stabilized

22. 22 UP Artifacts and Process Context

23. 23 Design Model: Creating Design Class Diagrams A design class diagram(DCD) illustrates the specifications for software classes and interfaces –classes, associations, attributes –interfaces –methods –attribute type information –navigability –dependencies –generalization Domain Model and Design Class Diagram

24. 24 Creating a NextGen POS DCD Identifying Software Classes –Some of concepts such as Cashier class in Domain Model are not included Adding Attributes Adding Method Names –analyzing interaction diagrams –Method Issues Create operations (new) Accessing (get/set) operations Methods to multiobjects (find) Usually these three kinds of methods are omitted in the DCD Multiobject(containers) does not show up in DCD

25. 25 Creating a NextGen POS DCD Adding type information –types of attributes –method parameter and return types –optional (depends on the audience)

26. 26 Creating a NextGen POS DCD Adding Associations and Navigability –Navigability is identified from interaction diagrams A sends a message to B A creates an instance B A needs to maintain a connection to B –Looks-in association between Register and ProductCatalog is newly added

27. 27 Creating a NextGen POS DCD Adding dependency relationships –the dependency relationship is useful to depict non-attribute visibility between classes parameter, local, global

28. 28 UP Artifact Relationships

29. 29 Implementation Model