Object Design Examples with GRASP - PowerPoint PPT Presentation


PPT – Object Design Examples with GRASP PowerPoint presentation | free to download - id: 7bba4-ZDc1Z


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Object Design Examples with GRASP


Register must pass along quantity to Sale, which creates SalesLineItem (with ... Controller: again, use Register. ... Add a getTotal message to Register. ... – PowerPoint PPT presentation

Number of Views:43
Avg rating:3.0/5.0
Slides: 36
Provided by: dmitri7
Learn more at: http://www.augustana.ab.ca


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Object Design Examples with GRASP

Chapter 18
  • Object Design Examples with GRASP

Use Case Realization
  • A use-case realization describes how a
    particular use case is realized within the Design
    Model, in terms of collaborating objects. RUP
  • Usually restricted to one or more scenarios.
  • System operations in SSDs become the starting
    messages entering Controllers for domain layer
    interaction diagrams.
  • Draw a different interaction diagram for each
    system operation message.

Fig. 18.2 Communication diagrams and system
Fig. 18.3 Sequence diagrams and system operations
Use Case Realizations and Other Artifacts
  • Use cases prime input to realizations.
  • Also Supplementary Specifications, Glossary,
    operation contracts, prototypes, etc.
  • Involve the customer frequently.
  • Domain model inspires some software objects
    (e.g., Sale), but not all.
  • Discover new concepts previously missed.
  • Ignore some concepts previously identified.
  • Make up software classes unrelated to Domain
    Model (e.g., a controller class).

Use Case Realizations for the NextGen POS
  • Initialization During OO design, consider the
    Start Up use case last.
  • Start with the Process Sale use case, which has
    the following system operations
  • makeNewSale
  • enterItem
  • endSale
  • makePayment
  • Choose the controller class.

Fig. 18.5 Applying the GRASP Controller pattern
Creating a New Sale
  • GRASP Creator pattern assign the responsibility
    for creation of an object to a class that
    aggregates, contains, or records the object to be
  • Register records (registers) a Sale.
  • A collection (initially empty) must be created to
    hold SalesLineItem instances.
  • By Creator, Sale should create the empty
    collection (multiobject).

Fig. 18.6 Sale and the collection creation
Designing the enterItem System Operation
  • Controller again, use Register.
  • Display item description and price
  • Model-View Separation it is not the
    responsibility of non-UI objects to display.
  • As long as information to be displayed is known,
    ignore the design of display for now.
  • Creator a Sale contains SalesLineItems.
  • Register must pass along quantity to Sale, which
    creates SalesLineItem (with quantity as
    parameter) and adds it to its collection.

Design of enterItem, continued
  • Finding a ProductDescription
  • Who should be responsible for knowing a
    ProductDescription, based on an itemID match?
  • Expert ProductCatalog knows all the
  • Visibility to ProductCatalog
  • Who should send the getProductDescription message
    to ProductCatalog?
  • Register has visibility to ProductCatalog.

Fig. 18.7 The enterItem interaction diagram
Fig. 18.8 Partial DCD related to enterItem design
Designing the endSale System Operation
  • Controller again, use Register.
  • Setting Sale.isComplete attribute true (as per
    operation contract postcondition)
  • Expert Sale owns and maintains the isComplete
    attribute, so Register should send becomeComplete
    message to Sale.

Fig. 18.9 Completion of item entry
Calculating the Sale Total
  • No design class currently knows sale total.
  • Ensure total is known design display of total
  • Expert Sale should be responsible for knowing
    its total.
  • Interaction diagram for getTotal
  • getTotal is not a system operation inter-action
    diagram can start with any message
  • Details of calculations can be illustrated by
    attaching algorithms or constraints.

Fig. 18.10 Sale.getTotal interaction diagram
Fig. 18.11 Showing a method in a note symbol
Designing the makePayment System Operation
  • Creator Who records, aggregates, most closely
    uses, or contains a Payment?
  • Register logically records a payment in the
    real-world domain.
  • Sale will closely use a payment.
  • Expert Register receives makePayment system
    operation message, so it knows amount tendered.
  • When there are design alternatives, consider
    cohesion and coupling.

Fig. 18.13 Register.makePayment interaction
Logging a Sale
  • Who is responsible for knowing all the logged
    sales and doing the logging?
  • Low representational gap
  • Store should know all logged sales related to
  • Could add SalesLedger class to Domain Model as
    well as Design Model, especially if Store becomes

Fig. 18.14 Two alternatives for logging sales
Fig. 18.15 Logging a completed sale
Calculating the Balance
  • Process Sale use case System presents receipt.
  • Implies that balance due from a payment will be
    displayed and printed on the receipt.
  • We arent concerned right now with printing and
    displaying, but with knowing the balance.
  • Sale and Payment are partial Experts.
  • Low Coupling Sale already has visibility to
    Payment as its creator, so coupling doesnt

Fig. 18.16 Sale.getBalance interaction diagram
Fig. 18.17 Design Class Diagram for iteration 1
Connecting the UI Layer to the Domain Layer
  • Common designs for objects in the UI layer to
    obtain visibility to domain layer
  • An initializer object (e.g., Factory) called from
    the application starting method (Java main)
    creates both a UI and a domain object and passes
    the domain object to the UI.
  • A UI object retrieves the domain object from a
    well-known source (e.g., from a factory object
    that is responsible for creating domain objects).

Fig. 18.18 How do we show a running total after
Showing a Running Total after enterItem Message
  • Design alternatives
  • Add a getTotal message to Register.
  • UI sends getTotal message to Register, which
    delegates to Sale.
  • Low Coupling UI knows only Register object.
  • Cohesion Register becomes less cohesive.
  • UI asks for a reference to current Sale object.
  • When it requires the total (or other
    information), it directly sends messages to the
  • Coupling to Sale is not a major problem, because
    it is a stable object, integral to the design.
  • We will consider another alternative in Chap. 26.

Fig. 18.19 Connecting UI to domain layer by
Initialization and the Start Up Use Case
  • Start Up use case implicit or explicit
  • Guideline Do the initialization design last.
  • Common design idiom Create an initial domain
    object the first software domain object
  • Created by Java main method or a Factory object
    called from main.
  • Responsible for creating direct child domain
    objects (e.g., Store creates Register object and
    passes it to new UI object JFrame).

Creating the Initial Domain Object
  • public class Main
  • public static void main( String args )
  • // Store is the initial domain object.
  • Store store new Store()
  • // Store creates other domain objects.
  • Register register store.getRegister()
  • // Only the startup class knows about UI.
  • ProcessSaleJFrame frame
  • new ProcessSaleJFrame( register )
  • . . .

Fig. 18.20 Initialization in the Domain Layer
Command-Query Separation Principle
  • The Command-Query Separation Principle (CQS)
    Every method should either be
  • A command method that
  • performs an action (e.g., updating,
  • often has side effects (e.g., changes state of
    objects), and
  • is void (has no return value), or
  • A query that
  • returns data to the caller, and
  • has no side effects (does not permanently change
    the state of any objects). Meyer88

Fig. 18.25 CQS roll is separate from
About PowerShow.com