1 / 123

Software Design CS 406 Software Engineering I Fall 2001

Software Design CS 406 Software Engineering I Fall 2001 Aditya P. Mathur Last update: October 2, 2001 Organization Part I: Design principles and process Part II: OO Design Part III: Design Patterns Part IV: Special topics Learning Objectives

benjamin
Télécharger la présentation

Software Design CS 406 Software Engineering I Fall 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software DesignCS 406 Software Engineering IFall 2001 Aditya P. Mathur Last update: October 2, 2001

  2. Organization Part I: Design principles and process Part II: OO Design Part III: Design Patterns Part IV: Special topics Software Design

  3. Learning Objectives • To learn notations for representing a design. • To understand and be able to apply the basic principles of software design. (GRASP patterns). • To learn techniques and tools for Object- Oriented Design. • Interaction diagrams • Class diagrams • State diagrams Software Design

  4. Class model Object behavior model Design state model Models during the Design Phase Static structure diagrams Interaction Diagrams: Collaboration diagrams Sequence diagrams Contracts for methods and operations State diagrams for classes Software Design

  5. 1: message2() message1() 2: message3() A collaboration diagram :classAinstance :classBinstance message1() is sent to an instance of class A. message2() and message3() are sent, in that order, by an instance of class A to an instance of class B. One diagram for each system event. Software Design

  6. :classAinstance :classBinstance message1() message2() message3() Focus of control, activation box, optional A sequence diagram May be used for multiple events. Software Design

  7. direction of message first internal message 1: makePayment(cashTendered) makePayment(cashTendered) :POST :Sale first message 1.1: create(cashTendered) link line instance of a class parameter Collaboration diagram:makepayment() :Payment Note: Post is Register in the second edition of Larman. Software Design

  8. Making collaboration diagrams • Design a system of interacting objects to fulfill the tasks....this is the tough part of design! • One diagram for each system operation in the current development cycle, e.g. for makepayment(). • If the diagram gets complex, split into smaller diagrams. Software Design

  9. :Sale s1:Sale Sale class object or instance named object Classes and Objects Software Design

  10. msg1() addPayment(cashTendered) link line Links :Post :Sale Link illustrates client/server relationship. Software Design

  11. msg1() 1: message1() 2: message2() 3: message3() :Post :Sale all messages flow on the same link Messages Software Design

  12. msg1() 1: addPayment(amount:Money) :Post :Sale parameters shown within parentheses; types may also be shown Parameters Software Design

  13. return value type msg1() :Post :Sale return value name Return values 1: tot:=total(): int Software Design

  14. Messages to “self” or “this” msg1() :Post 1: clear() Software Design

  15. msg1() 1*: li = nextLineItem: SalesLineItem :Post :Sale Iteration iteration, no recurrence values Software Design

  16. 1*: [i:= 1..10] li = nextLineItem: SalesLineItem :Post :Sale Iteration with recurrence msg1() iteration clause Software Design

  17. msg1() 1*: [i:= 1..10] msg2() :A :myB: B 2*: [i:= 1..10] msg3() :myC: C Iteration clause: Multiple messages msg1() { for i:= 1 to 10 { myB.msg2(); myC.meg3(); } } equal iteration clauses Software Design

  18. msg1() 1: create(cashier) :Post :Sale <<create>> 1: make(cashier) Creation new created instance create message with optional parameter for initialization. Note that use of the name create is a UML convention. Software Design

  19. Languages and create C++ Automatic allocation, or new() operator followed by constructor call. Java new() operator followed by a constructor call. Software Design

  20. first message not numbered second third (nested) msg1() 1: msg2() 1.1: msg3() 2.1: msg5() 2: msg4() fifth (nested) fourth Message sequence numbering :classA :classB :classC Software Design

  21. msg1() 1*: [new sale] create() 1.1: create() conditional message with test Conditional message :Post :Sale :SalesLineItem Software Design

  22. Unconditional after either msg2 or msg4 1a and 1b are mutually exclusive :ClassE 2: msg6() 1a: [test_1] msg2() msg1() :ClassA :ClassB 1b: [nottest_1] msg4() 1a.1: msg3() 1b.1: msg5() :ClassD :ClassC Mutually exclusive conditional messages Software Design

  23. sales:Sale A multiobject or a collection of instances, e.g. a List of Sales. Collections Software Design

  24. Message sent to a Multiobject. msg1() 1*: s:=size(): int :Sale :SalesLineItem The two *’s imply iteration over all elements. Messages to Multiobjects * Software Design

  25. Message sent to an element. msg1() 1: el:=create() :Sale sl:SalesLineItem :SalesLineItem 2: addElement(el) Message sent to a collection. Messages to multiobjects and an element [1] Software Design

  26. Design Guidelines • OO system consists of interacting objects. • How does one determine the assignment of responsibilities to various objects? • There is no unique assignment and hence “good” and “poor” designs, “beautiful” and “ugly” designs, “efficient” and “inefficient” designs. • Design guidelines assist in the derivation of a good design. Software Design

  27. GRASP Patterns • GRASP: General Responsibility Assignment Software Patterns • These are best considered as design guidelines and principles. These could also be considered as “thought patterns” useful in software design. Software Design

  28. Guidelines and principles • We first consider three useful guidelines: • Expert • Creator • Controller and two widely applicable principles: • High cohesion • Low coupling Software Design

  29. Product Catalog Payment Item Manager Customer POS Store Cashier Sale date time address name amount Product Specification Sales LineItem description price itemID quantity POS: Partial Domain Model Contains 1 1…* 1 Used-by * 1 Describes 1..* * Contained-in Stocks 1 1 * 1 Houses Captured-on * Started-by 1 1 Paid-by 1 1 1 1 1 Initiated-by 1 1 Records-sale-on 1 Software Design

  30. Expert • Question: How does one assign responsibilities ? • Answer: Assign a responsibility to an information expert, i.e. to a class that has the information needed to fulfill that responsibility. Software Design

  31. Sale date time Contains 1…* Product Specification Sales LineItem Described by * description price UPC quantity Expert: Example [1] In POS, some class needs to know the grand total of a sale. Who should be responsible for knowing the grand total of a sale ? Software Design

  32. Expert: Example [2] • From the model, identify the class that contains the information needed to obtain the grand total. • Information needed to obtain the grand total: • Knowledge of all SaleItems • Sum of their subtotals • Only a Sale object possesses this knowledge. • Sale being the information expert, we assign this responsibility to Sale. Software Design

  33. 1: t:=getTotal() Sale New method added to the Sale class. The class itself is derived from the domain model. date time getTotal Partial collaboration diagram [1] :Sale Software Design

  34. Expert: Example [3] • What information is needed to determine subtotal? • We need: • Quantity of each SalesLineItem and its price. • Quantity is available with SalesLineItem and price with ProductSpecification. • Hence SalesLineItem is assigned the responsibility to compute the subtotal. Software Design

  35. 1: t:=total() 1*: st=getSubtotal() :Sale * Sale :SalesLineItem date time 2.1: p:=getPrice() SalesLineItem ProductSpecification :ProductSpecification getTotal() quantity description price itemID getSubtotal() getPrice() Partial collaboration diagram [2] Software Design

  36. Responsibility Class Sale Knows sale total SalesLineItem Knows line item subtotal. ProductSpecification Knows the price of a product Summary: Example [4] Software Design

  37. Expert: Discussion • Expert guideline used often. • Fulfillment of a responsibility often requires interaction amongst several objects (3 in our example). There are many semi-expertswho collaborate in performing a task. • Use of the Expert guideline allows us to retain encapsulation of information. • It often leads to “lightweight” classes collaborating to fulfill a responsibility. Software Design

  38. Expert: Disadvantages • On some occasions the Expert guideline might not suggest a desirable solution. • Example: Who should save Sale in a database ? • As all the information to be saved is in the Sale class, it should be responsible for saving the information. • This implies that the Sale class must know about handling databases. Adding database related methods to sale class will make it in-cohesive. • It also violates the “separation of concerns” principle. Software Design

  39. Expert: Benefits • Objects use their own information to fulfill tasks, hence encapsulation is maintained. • This leads to low coupling. • Behavior is distributed across cohesive and lightweight classes. Software Design

  40. Creator [1] • Question: Who should be responsible for creating an instance of a class ? • Answer: Assign to B the responsibility to create an object of class A if the following is true: Software Design

  41. Creator [2] • B aggregates objects of type A. • B contains objects of type A. • B records instances of objects of type A. • B closely uses objects of type A. • B has the data passed to A when A is created. Implication: B is an expert in the creation of A. Software Design

  42. Sale date time Contains 1…* Product Specification Sales LineItem Described by * description price itemID quantity Creator: Example [1] Who should be responsible for creating a SalesLineItem? Software Design

  43. Creator: Example [2] • Salecontains many SalesLineItem objects. • This implies that Sale is a good candidate for creating a SalesLineItem. • This leads to the following collaboration diagram. Software Design

  44. :POST :Sale makeLineItem(quantity) create(quantity) :SalesLineItem Sequence diagram for the creation of SalesLineItem Software Design

  45. makeLineItem(quantity) 1: create(quantity) Sale date time makeLineItem() total() New method added to the Sale class. Partial collaboration diagram :Sale :SalesLineItem Software Design

  46. Creator: Discussion • Creator guides the assignment of responsibility of creating objects. • Creator suggests that the enclosing container or aggregate class is a good candidate for the creation of the object contained. Software Design

  47. Controller [1] • Question: Who should be responsible for handling system events ? Recall that a system event is a high level event, an external event, generated by a system actor. • Answer: Assign a responsibility to handle a system event to a controller. Software Design

  48. Controller [2] • A controller is a non-user interface object that handles system events. Here is a list of controllers: • Façade controller: Represents the overall system, device, or business. • Use case controller: Represents an artificial handler of all events of a use case. Software Design

  49. Controller [3] • window, applet, view, document do not qualify as controllers. They typically receive system events and delegate them to a controller. • System event examples: • Pressing the “end of sale” button. • Request Spell Check. • Request Engine Start. Software Design

  50. System operations System endSale() enterItem() makePayment() During system behavior analysis, system operations are assigned to the class System. It does not imply that the class named System performs these during design. Instead, during design, a controller class is assigned to perform these operations. Software Design

More Related