GRASP PATTERNS - PowerPoint PPT Presentation

Loading...

PPT – GRASP PATTERNS PowerPoint presentation | free to download - id: 52412c-YmIxO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

GRASP PATTERNS

Description:

Title: Project management Last modified by: john lin Created Date: 12/8/1995 5:21:36 PM Document presentation format: Other titles: Times Zapf Dingbats ... – PowerPoint PPT presentation

Number of Views:75
Avg rating:3.0/5.0
Slides: 57
Provided by: readPudnC1
Learn more at: http://read.pudn.com
Category:

less

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

Title: GRASP PATTERNS


1
GRASP PATTERNS
NOTES
2
Design withGRASP Patterns
3
Object Design
  • The rough steps followed so far include
  • Define requirements and model with use cases
  • Create domain model (conceptual class diag.)
  • Now to design objects we need to
  • Add methods to the classes and define messaging
    between objects to fulfill the requirements
  • But that last step isnt trivial!

4
GRASP Patterns
  • GRASP patterns help define normal ways that
    objects interact with each other
  • GRASP is Larmans term General Responsibility
    Assignment Software Patterns
  • Well cover five of the patterns in the text
  • For all 23 standard patterns, see Erich Gammas
    classic Design Patterns (ISBN 0201633612 or
    0201634988)

5
Responsibilities
  • The responsibilities for an object describe what
    behavior it needs to fulfill
  • Doing
  • Create an object
  • Perform a calculation
  • Start action in another object
  • Control activities in other objects
  • Sale is responsible for creating SalesLineItem

6
Responsibilities
  • Knowing
  • About private encapsulated data
  • About related objects
  • About things it can calculate or derive
  • Sale is responsible for knowing its total
  • Most knowing responsibilities are apparent from
    the attributes and associations of the object

7
Responsibilities
  • Translating responsibilities into classes and
    methods depends on how detailed or general the
    responsibilities are
  • Methods are often implemented to fulfill
    responsibilities

8
Getters and Setters
  • Detailed object methods often include a lot of
    getters and setters
  • Getters get some value for the outside world,
    e.g. getTotal (a knowing responsibility)
  • Setters set some value like assignment
    statements, e.g. setSecurityLevel (a doing
    responsibility)

9
Responsibilities, Methods related
10
Defining Patterns
  • Patterns capture well established best
    practices for design
  • Some are very low level others are
    architectural
  • Each Pattern is defined by its Name, a summary of
    the Patterns Solution, and a description of the
    Problem it solves

11
Defining Patterns
  • Patterns are not always the best solution
  • Good pattern descriptions include when the
    pattern may not apply, or the pros and cons of
    the pattern

12
The First Five GRASP Patterns
  • Information Expert
  • Creator
  • High Cohesion
  • Low Coupling
  • Controller

13
Information Expert
  • Problem what is the general principle of
    assigning responsibilities to objects?
  • Solution assign responsibility to the
    Information Expert the class which has the
    information needed to fulfill the
    responsibilityor Whoever has the data is
    responsible for managing and sharing it!

14
Information Expert
  • The domain model should inspire expansion into
    design classes which will handle all of the data
    and use it to meet requirements
  • A key step is that we have to make up the classes
    we think well need, based on the system
    characteristics, and see if they can work
    correctly

15
Information Expert
  • So if we have a class called Sale (like Shipment
    in the homework assignments), one responsibility
    might be to provide the total cost of the Sale
  • We know from a typical invoice that a Sale might
    consists of a bunch of line items, so we might
    call their class SalesLineItem

16
Information Expert
  • Each SalesLineItem may have a quantity
  • And each SalesLineItem needs someplace safe to
    store its description and price, so well put
    that in a ProductSpecification
  • After defining the associations and multiplicity,
    we get Figure 16.3 (p. 222), shown on the next
    slide

17
Information Expert
18
Information Expert
  • So at the highest level, we need to get the total
    cost from Sale
  • But in order to get that, we need the subtotal of
    each line item so get that from the information
    expert for each line item

19
Information Expert
  • So each SalesLineItem can get the subtotal of
    that line and the Sale will get those
    subtotals
  • But each line item needs the price of each item
    get from ProductDescription

20
Information Expert
  • Omitting variable assignments we haveWhere
    each object is responsible for providing the data
    it owns

21
Information Expert
  • The class diagram becomes

22
Information Expert
  • Information Expert is used very frequently in
    object design
  • May not be suitable when coupling or cohesion
    dictate otherwise (see later)

23
Creator
  • Problem Who is responsible for creating a new
    instance of a class?
  • Solution Let B create instances of A if
  • B aggregates (is made up of) A
  • B contains (holds) A objects
  • B records instance of A objects
  • B closely uses A objects
  • B has data needed when A is created

24
Creator
  • Creation of objects is also a very common
    activity
  • In the previous example, Sale aggregates
    (contains) many SalesLineItem objects (one object
    per line in the Sale), hence is makes sense for
    Sale to be a Creator of SalesLineItem instances

25
Creator
  • Hence a responsibility of the system is that a
    Sale needs a method to makeLineItem
  • If you want add X (quantity) widgets to a
    shopping cart, then Sale adds them to the cart

26
Creator
  • The sequence diagram would be

27
Creator
  • If the creation of an object is very complex,
    then the Factory pattern would be better (see Ch.
    23)

28
Low Coupling
  • Problem How can we support low dependency among
    classes, low impact of changes, and increase
    reuse of classes?
  • Solution Assign responsibilities so that
    coupling remains low
  • Coupling describes the extent of interconnection
    among classes

29
Low Coupling
  • Notice that some coupling is needed otherwise
    the classes dont interact
  • Too much coupling means that changes to one
    class might have unexpected changes elsewhere
  • Related to visibility how many other objects
    does each one need to see?

30
Stair Object Structure
31
Fork Object Structure
32
Low Coupling
  • The Stair structure is generally preferred where
    possible
  • Might have to use Fork structure if
  • The sequence of operations may change, and/or
  • New operations may be needed frequently
  • Subclasses are, by definition, high levels of
    coupling between objects

33
Low Coupling
  • Particularly avoid high coupling for objects
    which may change interface, implementation, or
    existence frequently
  • Desire for low coupling may conflict with Expert
    or High Cohesion patterns
  • No firm measure of what level of coupling is
    good

34
High Cohesion
  • Problem how do you keep complexity manageable?
  • Solution Assign responsibilities so that
    cohesion remains high
  • Cohesion is a measure of how closely related an
    objects responsibilities are
  • High cohesion means a closely related set of
    narrowly defined responsibilities

35
High Cohesion
  • In other words, dont make an object do too much
    work!
  • Low cohesion generally results from remaining too
    abstract when defining responsibilities
  • Per Booch, high cohesion is when the elements of
    a class all work together to produce some
    well-bounded behavior

36
High Cohesion
  • An object which has a kitchen-sink function (it
    catches all the functions except the kitchen
    sink) generally has very low cohesion
  • A single complex function can result in low
    cohesion
  • Moderate cohesion would have similar, but not
    closely related, functions together

37
High Cohesion
  • High cohesion classes have some responsibilities
    in one set of functions, and use other objects to
    accomplish them
  • Modular design is a similar concept as low
    coupling and high cohesion
  • Conversely, high coupling and low cohesion often
    appear together

38
High Cohesion
  • Deliberately violating high cohesion is rare
  • Might have to do it
  • To isolate related functions (rare)
  • To distribute object to different servers
  • To manage an external interface

39
Controller
  • Problem who is responsible for handling external
    input system events?
  • Solution assign the responsibility to a
    Controller object
  • Façade controller represents the entire subsystem
    or interface
  • Session controller handles an entire use case
    where some events may occur

40
Controller
  • An input system event is some event from an
    external actor (human or not)
  • The Controller object is responsible for deciding
    what to do with the input system event

41
Controller
  • So the Controller pattern applies to both
    management of external system interfaces (capture
    the entire interface in a single controller
    class), and managing inputs from user interfaces
  • User interface controllers generally end with
    ltgtHandler, ltgtCoordinator, or ltgtSession, where ltgt
    ltUse Case Namegt

42
Controller
  • Note that user interfaces (e.g. windows, views,
    or documents) are NOT part of the Controllers
    job those belong to an object at the Interface
    (or Presentation) Layer
  • Controller acts as a façade between interface and
    the application
  • Controllers DELEGATE work to other objects they
    dont do it themselves

43
BCE Objects
  • We can break objects into three major types for
    many purposes
  • Boundary objects (user interface window, buttons,
    etc.)
  • Control objects (controllers who make decisions,
    here also called use case handlers)
  • Entity objects (persistent objects which contain
    data)

44
BCE Objects
  • These might be correlated to the kinds of
    computers involved in processing them
  • User interface might be at a PC level (e.g. web
    browser)
  • Controller objects might run on an application
    server (captures logic, e.g. web server)
  • Entity objects might run on a database server
    (stores data)

45
Façade Controller
  • Façade controllers hide an entire system or
    subsystem under one class, such as Register or
    System
  • Avoid except for simple external systems
  • Works well if only a few events to manage
    otherwise may need use case controllers to break
    down system functions into smaller sets (p. 241)

46
Façade Controller
47
Avoiding Bloated Controllers
  • Even a façade controller should generally have
    more than one class
  • Beware of controllers which perform work without
    calling another class
  • Controllers should have few or no attributes
  • Fix bloat by adding more controller classes,
    and/or redesign to delegate more work

48
Use Case Realization
  • Every scenario in a use case can become a use
    case realization, which shows how the design
    model meets the requirements for that use case
  • Use Case Realization is UP term, not UML
  • Interaction diagrams help express Use Case
    Realization

49
Use Case Realization
  • Use case suggests system events shown in system
    sequence diagram
  • Effect of operations may be documented in
    operation contracts
  • Events represent messages which initiate
    interaction diagrams
  • Interaction diagrams describe communication
    between classes

50
Interaction Diagrams
  • Recall the collaboration diagrams are specific to
    one use case
  • Sequence diagrams generally show one scenario
    for one use case might show extensions
  • Operations contracts describe the conditions for
    one event in one use case

51
Models Dont Start Perfect
  • Expect that early requirements, and the initial
    domain model (conceptual class diagram) will not
    be perfect
  • But that doesnt mean do them poorly!
  • Maintain contact with customer and subject
    experts to keep improving models
  • Conceptual classes inspire design classes
  • But many additional classes likely needed

52
Model-View Separation
  • Non-GUI objects should not be involved in output
    tasks
  • This reinforces the Boundary/Control/Entity
    object distinction earlier
  • Controllers should know the information to be
    displayed in output, but actual output is a
    boundary objects purpose

53
More UML Notation
  • Constraints are tagged with curly brackets . An
    algorithm may be shown if needed.
  • Notes are in text boxes which also have the upper
    right corner dog-eared

lt- Constraint
lt- Note
54
Object Constraint Language
  • UML supports using a formal Object Constraint
    Language (OCL) to show constraints on execution
    of messages
  • http//www.omg.org/docs/ad/97-08-08.pdf
  • A newer version of the OCL is under development
    as of July 2003
  • Any notation may be used, however

55
Iteration 2
  • The texts second iteration assumes that in
    iteration 1 everything was done through
    development of the design class diagram, and
    major architecturally important parts of the
    system have been coded and tested
  • Iteration 2 is refining the design through
    additional patterns (which we arent covering)

56
Iteration 2
  • Iteration 2 also adds more scenarios to the
    foundation already established
  • Additional lower priority use cases may be fully
    defined
  • The system sequence diagram may be expanded to
    include external systems
About PowerShow.com