Bài Giảng Phân tích thiết kế hướng đối tượng (phần 4)

Tham khảo tài liệu ''bài giảng phân tích thiết kế hướng đối tượng (phần 4)'', công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Contracts and UML interaction diagrams Lecture Hoa Sen University Agenda  System sequence diagram  Operation Contract  On to Object design – Interaction diagrams  Sequence diagrams  Communication diagrams Hoa Sen University System Sequence Diagram Sample UP Artifact Relationships Domain Model Sale Business Modeling Sales LineItem * date quantity Vision Use-Case Model Process Sale Process Sale use case names Cashier Requirements Use Case Diagram Customer arrives Cashier makes new sale parameters and return value details Use Case Text Glossary system events : System Operation: enterItem(…) Post-conditions: - : Cashier system operations make NewSale() Supplementary Specification enterItem (id, quantity) System Sequence Diagrams Operation Contracts starting events to design for : Register Design Design Model : ProductCatalog : Sale enterItem (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity ) Hoa Sen University What is System Sequence Diagram  A diagram that shows, for ONE particular scenario of a use case, the events that external actors generate, their order, and INTER-system events (not detailed method calls between objects)  Describe what a system does without explaining why Hoa Sen University System sequence diagram system as black box the name could be "NextGenPOS" but "System" keeps it simple the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML external actor to system Process Sale Scenario :System : Cashier makeNewSale a UML loop interaction frame, with a boolean guard expression loop [ more items ] enterItem(itemID, quantity) description, total endSale return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned total with taxes makePayment(amount) a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism change due, receipt Hoa Sen University Use Cases and SSDs Process Sale Scenario : Cashier :System makeNewSale Simple cash-only Process Sale scenario: Customer arrives at a POS checkout with goods and/or services to purchase Cashier starts a new sale Cashier enters item identifier System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done System presents total with taxes calculated Cashier tells Customer the total, and asks for payment Customer pays and System handles payment loop [ more items ] enterItem(itemID, quantity) description, total endSale total with taxes makePayment(amount) change due, receipt Hoa Sen University Choosing events and operation name  System events should be expressed at the abstract level of intention rather than in terms of the physical input device :System : Cashier better name enterItem(itemID, quantity) scan(itemID, quantity) worse name Hoa Sen University Iterative and Evolutionary SSDs  Do not create SSDs for all scenarios (remember agile style)  SSDs are part of the Use-Case Model – Visualization of the interactions implied in the use cases scenarios Hoa Sen University Operation Contract Sample UP Artifact Relationships Domain Model Sale Business Modeling * date Sales LineItem quantity Vision Use-Case Model Process Sale Process Sale use case names Cashier Requirements Use Case Diagram Customer arrives Cashier enters item identifier system events ideas for the postconditions the domain objects, attributes, and associations that undergo changes Operation: enterItem(…) Post-conditions: - Design requirements that must be satisfied by the software : System : Cashier system operations make NewSale() Supplementary Specification enterItem (id, quantity) System Sequence Diagrams Operation Contracts starting events to design for, and more detailed requirements that must be satisfied by the software Glossary Use Case Text : Register Design Model : ProductCatalog : Sale enterItem (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity ) Hoa Sen University Example Contract  Contract CO2: enterItem     Operation: enterItem(itemID: ItemID, quantity: integer) Cross References: Use Cases: Process Sale Preconditions: There is a sale underway Postconditions: – – – – A SalesLineItem instance sli was created (instance creation) sli was associated with the current Sale (association formed) sli.quantity became quantity (attribute modification) sli was associated with a ProductDescription, based on itemID match (association formed) Hoa Sen University 10 Design: enterItem  Contract CO2: enterItem  Operation: enterItem(itemID : ItemID, quantity : integer)  Cross References: Use Cases: Process Sale  Preconditions: There is an underway sale  Postconditions: – – – – A SalesLineItem instance sli was created (instance creation) sli was associated with the current Sale (association formed) sli.quantity became quantity (attribute modification) sli was associated with a ProductDescription, based on itemID match (association formed) Hoa Sen University 22 Design enterItem  Choosing controller class  Display item description and price (ignore at this stage)  Create a new SalesLineItem  Finding a ProductDescription  Visibility to ProductCatalog  Temporary and persistent storage – We can defer database design and use temporary memory object instead Hoa Sen University 23 Design enterItem by Creator by Controller enterItem(id, qty) :Register 2: makeLineItem(desc, qty) 1: desc = getProductDesc(id) :Sale 2.1: create(desc, qty) :Product Catalog by Expert sl: SalesLineItem 1.1: desc = get(id) 2.2: add(sl) : Map lineItems : List Hoa Sen University add the newly created SalesLineItem instance to the List 24 Partial Design Class Diagram ProductDescription ProductCatalog catalog descriptions description : Text {Map} price : Money * itemID: ItemID getProductDesc( ) description Sale Register enterItem( ) isComplete : Boolean time : DateTime currentSale makeLineItem( ) Hoa Sen University lineItems {ordered} * SalesLineItem quantity : Integer 25 Design endSale «method» public void getTotal() { int tot = 0; for each SalesLineItem, sli tot = tot + sli.getSubtotal(); return tot } tot = getTotal :Sale *[ i = n]: st = getSubtotal lineItems[ i ] : SalesLineItem 1.1: pr = getPrice :ProductDescription Hoa Sen University 26 Design makePayment      Contract CO4: makePayment Operation: makePayment( amount: Money ) Cross References: Use Cases: Process Sale Preconditions: There is an underway sale Postconditions: – – – – A Payment instance p was created (instance creation) p.amountTendered became amount (attribute modification) p was associated with the current Sale (association formed) The current Sale was associated with the Store (association formed); (to add it to the historical log of completed sales) Hoa Sen University 27 Design makePayment  Creating payment by Controller makePayment(cashTendered) by Creator and Low Coupling :Register 1: makePayment(cashTendered) :Sale 1.1: create(cashTendered) :Payment Hoa Sen University 28 Design makePayment Sale  Logging a sale Sale * Logs-completed * Logs-completed 1 Store SalesLedger addSale(s : Sale) addSale(s : Sale) Store is responsible for knowing and adding completed Sales Acceptable in early development cycles if the Store has few responsibilities Hoa Sen University SalesLedger is responsible for knowing and adding completed Sales Suitable when the design grows and the Store becomes uncohesive 29 Design makePayment note that the Sale instance is named 's' so that it can be referenced as a parameter in messages and 2.1 makePayment(cashTendered) :Register 1: makePayment(cashTendered) 2: addSale(s) s :Sale 1.1: create(cashTendered) by Expert :Payment :Store 2.1: add(s) completedSales: List Hoa Sen University 30 Design makePayment  Calculating the balance – Who is responsible for knowing the balance?  To calculate, sale total and payment tendered are required  Sale and Payment are partial Experts  Consider coupling… – Sale already has visibility into Payment – Payment does not have visibility into Sale – Giving Sale primary responsibility doesn’t increase overall coupling Hoa Sen University 31 getBalance design { bal = pmt.amount - s.total } bal = getBalance s :Sale 1: amt = getAmount pmt: Payment 2: t = getTotal Hoa Sen University 32 Object Design: startUp  Initial system operation  Delay until all other system operations have been considered – What objects need to be there through out the use case – What associations need to be there through out the use case  Create a set of domain objects that need to be there to support the use case execution  Find a suitable initial object and request that object to create a set of other objects  Do the initialization design last Hoa Sen University 33 Create Initial Domain Object public class Main { public static void main( String[] args ) { // Store is the initial domain object // The Store creates some other domain objects Store store = new Store(); Register register = store.getRegister(); ProcessSaleJFrame frame = new ProcessSaleJFrame( register ); } } Hoa Sen University 34 Designing Store.create()  Create: Store, Register, ProductCatalog,ProductSpecifications  Associate: ProductCatalog with ProductSpecifications; Store with ProductCatalog; Store with Register; Register with ProductCatalog Hoa Sen University 35 Designing Store.create() pass a reference to the ProductCatalog to the Register, so that it has permanent visibility to it create 2: create(pc) :Store by Creator :Register create an empty collection object 1: create 1.1: create pc: ProductCatalog 1.2.2*: put(id, pd) descriptions: Map 1.2.1*: create(id, price, description) 1.2: loadProdSpecs() the * in sequence number indicates the message occurs in a repeating section Hoa Sen University pd: ProductDescription 36