GRASP: Designing Objects With Responsibilities - PowerPoint PPT Presentation

Loading...

PPT – GRASP: Designing Objects With Responsibilities PowerPoint presentation | free to view - id: 6f881e-ZGVkM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

GRASP: Designing Objects With Responsibilities

Description:

GRASP: Designing Objects With Responsibilities Chapter 17 Applying UML and Patterns-Craig Larman – PowerPoint PPT presentation

Number of Views:109
Avg rating:3.0/5.0
Slides: 92
Provided by: George663
Category:

less

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

Title: GRASP: Designing Objects With Responsibilities


1
GRASP Designing Objects With Responsibilities
  • Chapter 17
  • Applying UML and Patterns
  • -Craig Larman

2
Designing Objects With Responsibilities
  • Identify requirements, create a domain model and
    define dynamic behaviour , define messages to
    meet requirements , add methods to the software
    classes
  • Too Simple!
  • How do we assign responsibilities to classes?
  • What methods belong where?

3
Object Design Input
  • Use case text
  • Defining the behavior
  • System sequence diagram
  • Identifying the system operation messages
  • The operation contract
  • Stating events to design for, and detailed
    post-condition to satisfy
  • Supplementary specification
  • Defines non-functional goals
  • Glossary
  • Data format, data related with UI and database
  • Domain model
  • initial attempt of software object in the domain
    layer of software architecture

4
Fig. 17.1 UP artifacts influencing OO design
5
Responsability Driven Design-RDD
  • Design of behavior implies assigning
    responsibilities to software classes.
  • Responsibilities are assigned to classes of
    objects during object design.
  • Responsibility is a contract or obligation of a
    class
  • What must a class know? knowing
    responsibility
  • What must a class do? doing responsibility

6
Doing Responsability
  • What must a class do? doing responsibility
  • Take action (create an object, do a calculation)
  • Initiate action in other objects
  • Control/coordinate actions in other objects
  • Doing responsibilities are implemented by means
    of methods
  • Methods fulfill responsibilities alone or
    through collaboration with other objects and
    methods.
  • Ex A Sale is responsible for creating
    SalesLineItems (doing)

7
Responsibilities and methods create
Sale objects are given a responsibility to create
Payments. The responsibility is invoked with a
makePayment message
8
knowing responsibility
  • What must a class know? knowing
    responsibility
  • Private encapsulated data
  • Related objects
  • Things it can derive or calculate
  • Knowing responsibilities are related to
    attributes, associations in the domain model.
  • Domain model illustrates attributes and
    associations gt inspires the knowing
    responsibilities.
  • Ex a Sale is responsible for knowing its
    total (knowing)

9
Responsibilities and attribute
10
RDD and Collaboration
Responsibilities are implemented by methods Some
methods act alone and do a task Some collaborate
with other objects to fulfill their
responsibility. Example Sale class has
getTotal() method, the getTotal() collaborates
with SalesLineItem objects to get the subtotal
through getSubtotal() methods
11
Software pattern
  • What is a software pattern?
  • A design pattern is a general reusable and
  • proven solution to a commonly occurring
  • problem in software design.
  • Craig Larman a pattern is a named
  • problem/solution pair that can be applied in
  • new contexts, with advice on how to apply it in
  • novel situations

12
Well-known Pattern Families
GRASP General Responsibility Assignment
Software Patterns Describe fundamental principles
for assigning responsibilities to classes and for
designing interactions between classes GoF Gang
of Four Design Patterns 23 pattrens Well cover
with GRASP
13
GRASP Patterns
  • 9 GRASP patterns , but we start with the first
    five
  • Information Expert
  • Creator
  • Controller
  • Low Coupling
  • High Cohesion
  • Polymorphism
  • Pure Fabrication.
  • Indirection.
  • Dont Talk to Strangers

14
Creator
15
Creator principle
  • Problem Who creates an A object
  • Solution Assign class B the responsibility to
    create an instance of class A if one of these is
    true
  • B contains or aggregate A
  • B records A
  • B closely uses A
  • B has the Initializing data for A

16
Creator principle
  • B has the Initializing data for A that will
    be passed to A when it is created.
  • Often initiation is done using a constructor with
    parameters.
  • e.g. a Payment instance, when
    created
  • needs to be initialized with the
    Sale total.
  • Sale class knows Sale total. Good candidate for
    creating Payment is Sale.
  • If more than one of the above applies, prefer a
    class B which aggregates or contains A.

17
Creator Pattern in Monoply
18
Problem Who should create a
SalesLineItem?
19
(No Transcript)
20
Creating a SalesLineItem
Sale objects are given a responsibility to
create SaleLineItem. The responsibility is
invoked with a makeLineItem message
21
Creating a SalesLineItem
22
Why Catalog is reating a Book ?
23
Information Expert
24
Information Expert
  • Problem What is a basic principle by which to
    assign responsibilities to objects?
  • Solution (advice ) Assign a responsibility to
    the information expert , that is the class with
    the information necessary to fulfill the
    responsibility.
  • Objects do things related to the information
    they have.

25
Applying Expert in POS Application
  • Start assigning responsibilities by clearly
    stating the responsibility.
  • Who should be responsible for knowing
    the grand total of a sale?

26
Who should be responsible for knowing/getting
the grand total of a sale?
27
Who responsible for knowing the grand total of
a sale?
28
Partial interaction and class diagrams
  • Add a Sale class to the Design Model.
  • Express responsibility of knowing the total of a
    sale with the method named getTotal.
  • What information do we need to know to determine
    the line item subtotal?
  • Sale knows about neighbours (associations),
    SaleLineitems who is responsible for knowing its
    subtotal

29
SalesLineItem is Expert for Subtotal
  • How does the SalesLineItem find out the product
    price?
  • SaleLineItem knows about neighbours (
    ProductDescription) to get the price.

30
ProductDescription is Expert for Price
Partial information experts collaborate to
fulfill the responsibility.
31
Another Example
32
Low Coupling Principle
33
Low Coupling Principle
Problem How to support low dependency, Low
change impact, and increased reuse? Solution
Assign responsibilities so that coupling remains
low. Use this principle to evaluate alternatives.
Coupling is a measure of how strongly one class is connected to, has knowledge of, or relies upon other classes.
34
What is a coupling ?
  • Coupling between classes is dependency of one
    class on another class
  • Common form of coupling from Class A to Class B
    are
  • Class A has an attribute (data member or instance
    variable) that refers to a Class B instance, or
    Class B itself.

35
What is a coupling ?
  • Common form of coupling from Class A to Class B
    are
  • Class A has a method which references an instance
    of Class B, or Class B itself, by any means.
    These typically include a parameter or local
    variable of type Class B, or the object returned
    from a message being an instance of Class B.

36
What is a coupling (continued) ?
  • Common form of coupling from Class A to Class B
    are
  • Class A is a direct or indirect subclass of Class
    B.
  • Class B is an interface, and Class A implements
    that interface.

37
Common Forms of Coupling in OO Languages
  • Type X has an attribute (data member, instance
    variable) that refers to type Y or an instance of
    Y.
  • An object of type X calls on services of a type Y
    object.
  • Type X has a method that references an instance
    of type Y (e.g., parameter, local variable,
    object returned from a method).
  • Type X is a subclass of type Y.
  • Type X implements the interface Y.

38
Low Coupling - POS Case Study
  • What class should be responsible for creating a
    Payment instance and associating it with the
    Sale?
  • Register?
  • Sale?
  • Creator pattern suggests Register should create
    the Payment.
  • A register records a payment in the real world.

39
What if Register creates Payment
  • Register is coupled to both Sale and Payment.

40
What if Sale creates Payment ?
  • Assuming that the Sale must eventually be coupled
    to knowledge of a Payment, having Sale create the
    Payment does not increase coupling.
  • NB Low Coupling and Creator may suggest
    different solutions.

41
Controller Pattern
42
Controller Pattern
UI layer does not contain any business
logic Problem How to connect UI layer to the
business logic layer? Solution If a program
receive events from external sources other than
its graphical interface, add an event class to
decouple the event source(s) from the
objects that actually handle the events.
43
Controller Pattern
  • What first object beyond the UI layer receives
    and coordinates (controls) a system operation
    message?
  • Solution Assign the responsibility to a class
    that represents one of the following options

44
Options for Control Responsibility
  • Represents the overall system or a root object.
  • e.g., an object called System or Register
  • Suitable when there are not too many system
    events or when UI cannot choose between multiple
    controllers.
  • A controller for each use case
  • e.g. processSaleHandler

45
Controller choices ?
Controllers
  • Register (POS Terminal) is a specialized device
    with software running on it.
  • ProcessSaleHandler represents a receiver of all
    system events of a use case scenario.

46
What should be Controller for enterItem?
47
Bad Design
48
Good Design
Controller should delegate the work that needs to
be done to other objects.
49
Use Case Controller
  • A use case controller handles system events for a
    single use case.
  • Can maintain information about the state of the
    use case.
  • Different controller for each use case.
  • Not a domain object, but artificial construct to
    support the system.
  • Use when there are many system events.
  • Factors handling into separate classes.

50
Controller
51
Controller Benefits
Increased potential for reuse Ensures that the
application logic is not handled in the interface
layer. Thus, the external event raisers are
independent of internal event handlers Plug
Play interfaces Since the interface is not bound
to the controllers, it can be replaced or updated
without much impact Verifying the reasoning of
the use case Allows us to verify that the system
operations occur in a logical sequence. For
example makePayment() is not called before
endSale()
52
High Cohesion
53
High Cohesion
  • A class with low cohesion does too much unrelated
    work and are
  • Hard to comprehend
  • Hard to reuse.
  • Hard to maintain.
  • Delicate and constantly affected by change

Cohesion is a measure of how strongly related the
responsibilities of an element (classes,
subsystems) are.
54
High Cohesion
  • Problem
  • How to keep complexity manageable?
  • Solution
  • Assign a responsibility so that cohesion remains
    high

55
Reduced cohesion of Register(creator pattern)
  • Low cohesion
  • Register is taking part of the responsibility for
    fulfilling makePayment operation and many other
    unrelated responsibility ( 50 system operations
    all received by Register).then it will become
    burden with tasks and become incohesive

56
Better solutionHigher Cohesion and Lower Coupling
  • Solution
  • Delegate the payment creation responsibility to
    Sale to support high cohesion

57
Conclusion
  • Like Low Coupling, High Cohesion is a principle
    to keep in mind during all design decisions
  • It is important to evaluate design constantly
    with respect to GRASP principles, regardless of
    the design result.

58
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

59
Object Design Examples with GRASP
  • Chapter 18
  • Applying UML and Patterns
  • Craig Larman

60
(No Transcript)
61
Use-Case Realizations
  • UML interaction diagrams are used to illustrate
    use-case realizations.
  • Design operations of the SSD
  • Principles and Patterns can be applied during
    this design work.
  • Which object has which responsibility?

62
Domain Model and Use-Case Realization
  • Some of the software objects that interact via
    messages in the interaction diagrams are inspired
    from the Domain Model.
  • The existing domain model is not likely to be
    perfect. Errors and omissions are to be expected.
  • You will discover new conceptual classes that
    were previously missed, ignore conceptual classes
    that were previously identified, and do likewise
    with associations and attributes.

63
Interaction Diagrams
  • Your System Sequence Diagram list the system
    events.
  • Create a separate diagram for each system
    operation(all events of the use case) under
    development in the current iterative step.
  • If the diagram gets complex, split it into
    smaller diagrams.

64
Multiple Sequence Diagrams (
  • Multiple sequence diagrams and system event
    message handling.

65
Use-case Realizations for NextGen Iteration
  • Explore the choices and decisions made while
    designing a use-case realization, with objects
    based on the GRASP patterns.
  • No magic in the creation of well designed IDs.
  • Construction of IDs is made on justifiable
    principles.

66
System Operations of POS Application
67
Interaction Diagrams and System Events
  • In the current iteration of PoS application, we
    are considering two use-cases and their
    associated system events
  • Process Sale
  • makeNewSale
  • enterItem
  • endSale
  • makePayment
  • Start Up !!!!!!!
  • startUp

68
Object Design Contract
  • Name makeNewSale()
  • Responsibilities Make a new sale for a cashier
    to request to start a new sale, after a customer
    has arrived with things to buy.
  • Cross-References Use Cases Process Sale
  • Pre-Conditions None
  • Post-Conditions A sale instance was created.
  • The sale instance was associated with the
    register . Attributes of the sale instance were
    initialized.

69
Choosing the Controller Class
  • Our design choice involves choosing the
    controller for the system operation message
  • Here are some choices
  • Represents the overall system, device, or
    subsystem Register,
  • Represents a handler of all system events of a
    use-case scenario ProcessSaleHandler.
  • From those choices, we choose the register as our
    controller

70
Creating a New Sale
  • A software sale object must be created, and the
    GRASP creator pattern suggests assigning the
    responsibility for creation to a class that
    aggregates, contains, or records the object to be
    created.
  • The register is a good choice to create the sale
    object by the creator pattern.

71
Creating a New Sale
72
Object Design enterItem
  • Name enterItem(itemID itemID,quantity
    integer)
  • Responsibilities Enter sale of an item and add
    it to the sale. Display the item description and
    price.
  • Cross References Use-Cases ProcessSale.
  • Pre-Conditions There is an underway sale.

73
Object Design enterItem
  • Post-Conditions
  • sli was associated with current sale.(association
    formed)
  • sli.quantity became quantity.(attribute
    modification)
  • sli was associated with a ProductSpecification,
    based on itemID match.(association formed), that
    is also should find its ProductSpecification

74
Creating a new SalesLineItem
  • The contract post condition indicate a
    responsibility to create a SalesLineItem
    instance.
  • A Sale contains SalesLineItem objects.
  • By creator pattern, the sale is an appropriate
    candidate for creating Lineitems.
  • GRASP creator pattern
  • Assign the responsibility for creation to a class
    that aggregates, contains or records.

75
Finding a product specification
  • The SalesLineItem needs to be associated with the
    ProductSpecification that matches the incoming
    itemID.
  • Who should be responsible for looking up the
    ProductSpecification based on the itemID match?
  • By the Expert pattern, ProductCatalog is a good
    candidate for the responsibility, since it
    logically contains all the ProductSpecifications.

76
Visibility to a product catalog
  • Who should send the Specification message to the
    ProductCatalog to ask for a ProductSpecification?
  • Assumption A Register and a ProductCatalog
    instances were created during the initial Start
    Up use-case, and there is a permanent connection
    between them.
  • Based on this assumption, then it is possible to
    the Register to send the specification message
    (using reference to productCatalog) to the
    ProductCatalog.

77
(No Transcript)
78
Object Design endSale Contract
  • Name endSale()
  • Responsibilities Record that it is the end of
    entry of sale items, and display sale total.
  • Cross References Use Cases Process Sale
  • Exceptions If a sale is not underway, indicate
    that it was an error.
  • Pre-Conditions There is an underway sale.
  • Post-Conditions sale.isComplete became true.

79
Choosing the Controller Class
  • Based on the Controller Pattern, as for
    enterItem, we will continue to use register as a
    controller.

80
Setting the Sale.isComplete attribute
  • We will continue to use register as a controller
  • The contract post-condition state
  • Sale.isComplete became true.
  • As always, Expert should be the first pattern
    considered unless it is a controller or creation
    problem (which is not).
  • Who should be responsible for setting the
    Sale.isComplete attribute of the Sale to true.
  • By Expert, it should be the Sale itself.

81
Communication Diagram endSale
  • Setting the Sale.isComplete attribute (2)

82
Constraints and Notes
83
Object DesignmakePayment
  • Choosing the Controller Class
  • Based on the Controller GRASP pattern, as for
    enterItem, we will continue to use Register as a
    controller.
  • It is common to use the same controller
    throughout a use case.

84
Creating the Payment
  • Register makePayment Communication diagram

85
Logging the Sale
  • Who should be responsible for knowing the
    complete sale.

86
Logging a completed sale
  • Perhaps we did not think of a sale ledger early,
    but now we have.
  • If it is not chosen, it would be ideally added to
    the domain model as well.
  • Fortunately, iterative development provides a
    life-cycle for continual change.
  • This kind of discovery and change during design
    work is to be expected.

87
Logging a Completed Sale
88
Calculating the Balance
  • Who is responsible for knowing the balance?
  • To calculate the balance, the Sale and Payment
    cash tendered are required.
  • Therefore, Sale and Payment are partial experts
    for solving the problem.

89
Calculating the Balance
90
(No Transcript)
91
Questions ?
About PowerShow.com