Object Design Examples with GRASP - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Object Design Examples with GRASP

Description:

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
Category:

less

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

Title: Object Design Examples with GRASP


1
Chapter 18
  • Object Design Examples with GRASP

2
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.

3
Fig. 18.2 Communication diagrams and system
operations
4
Fig. 18.3 Sequence diagrams and system operations
5
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).

6
Use Case Realizations for the NextGen POS
Iteration
  • 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.

7
Fig. 18.5 Applying the GRASP Controller pattern
8
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
    created.
  • 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).

9
Fig. 18.6 Sale and the collection creation
10
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.

11
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
    ProductDescriptions.
  • Visibility to ProductCatalog
  • Who should send the getProductDescription message
    to ProductCatalog?
  • Register has visibility to ProductCatalog.

12
Fig. 18.7 The enterItem interaction diagram
13
Fig. 18.8 Partial DCD related to enterItem design
14
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.

15
Fig. 18.9 Completion of item entry
16
Calculating the Sale Total
  • No design class currently knows sale total.
  • Ensure total is known design display of total
    later.
  • 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.

17
Fig. 18.10 Sale.getTotal interaction diagram
18
Fig. 18.11 Showing a method in a note symbol
19
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.

20
Fig. 18.13 Register.makePayment interaction
diagram
21
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
    finances.
  • Could add SalesLedger class to Domain Model as
    well as Design Model, especially if Store becomes
    incohesive.

22
Fig. 18.14 Two alternatives for logging sales
23
Fig. 18.15 Logging a completed sale
24
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
    increase.

25
Fig. 18.16 Sale.getBalance interaction diagram
26
Fig. 18.17 Design Class Diagram for iteration 1
27
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).

28
Fig. 18.18 How do we show a running total after
enterItem?
29
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
    Sale.
  • 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.

30
Fig. 18.19 Connecting UI to domain layer by
reference
31
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.
  • 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).

32
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 )
  • . . .

33
Fig. 18.20 Initialization in the Domain Layer
34
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,
    coordinating),
  • 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

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