Design Model - GRASP: Designing Objects With Responsibilities - PowerPoint PPT Presentation

Loading...

PPT – Design Model - GRASP: Designing Objects With Responsibilities PowerPoint presentation | free to view - id: 544ac4-NTdjY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Design Model - GRASP: Designing Objects With Responsibilities

Description:

Design Model - GRASP: Designing Objects With Responsibilities Objectives Define patterns Learn to apply five of the GRASP patterns Patterns and Frameworks Pattern ... – PowerPoint PPT presentation

Number of Views:680
Avg rating:3.0/5.0
Slides: 50
Provided by: Qian97
Category:

less

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

Title: Design Model - GRASP: Designing Objects With Responsibilities


1
Design Model - GRASP Designing ObjectsWith
Responsibilities
2
Objectives
  • Define patterns
  • Learn to apply five of the GRASP patterns

3
Patterns and Frameworks
  • Pattern
  • Provides a common solution to a common problem in
    a context
  • Analysis/Design Pattern
  • Provides a solution to a narrowly scoped
    technical problem
  • Provides a fragment of a solution, or a piece of
    the puzzle
  • Framework
  • Defines the general approach to solving the
    problem
  • Provides a skeletal solution, whose details may
    be analysis/design patterns

4
What Is a Design Pattern?
  • A design pattern provides a scheme for refining
    the subsystems or components of a software
    system, or the relationships between them. It
    describes a commonly-recurring structure of
    communicating components that solves a general
    design problem within a particular context.
  • Erich Gamma et al. 1994. Design PatternsElements
    of Reusable Object-Oriented Software

5
Patterns
  • A pattern is a named problem/solution pair that
    can be applied in new context, with advice on how
    to apply it in novel situations and discussion of
    its trade-offs
  • Patterns are general principles and idiomatic
    solutions which are summarized from those
    experienced object-oriented developers during
    work, and they are used to guide others in the
    creation of software.
  • Primitive examples from OOP
  • Model - View - Controller (MVC)
  • Object - Attribute - Value (OAV)
  • GRASP (Larman)
  • Gang of Four (GoF Gamma, et. al.)

6
Examples of Pattern Usage
Pattern Example
Command (behavioral pattern) Issue a request to an object without knowing anything about the operation requested or the receiver of the request for example, the response to a menu item, an undo request, the processing of a time-out
Abstract factory (creational pattern) Create GUI objects (buttons, scrollbars, windows, etc.) independent of the underlying OS the application can be easily ported to different environments
Proxy (structural pattern) Handle distributed objects in a way that is transparent to the client objects (remote proxy) Load a large graphical object or any entity object costly to create/initialize only when needed (on demand) and in a transparent way (virtual proxy)
Observer (behavioral pattern) When the state of an object changes, the dependent objects are notified. The changed object is independent of the observers. Note The MVC architectural pattern is an extension of the Observer design pattern
7
Detailing the Command Pattern
menu
1
1
MenuItem
1
1
Command
0..
0..
Menu
- label String
Process()
items
cmd
Clicked()
cmd.Process()
8
Detailing the Command Pattern (continued)
menu
1
1
MenuItem
0..
0..
Menu
- label String
items
Clicked()
cmd.Process()
9
Detailing the Command Pattern (continued)
1. OpenCommand( )
Initialization
2. AddItem("Open...",ocmd)
3. MenuItem("Open...", ocmd)
3. AskUser( )
4. DoOpen( )
The user selects the Open menu item
1. Clicked( )
2. Process( )
theMenuItem
cmd
Command
A user
10
Detailing the Command Pattern (continued)
menu
1
1
MenuItem
Menu
0..
0..
- label String
items
AddItem(s String, c Command)
Clicked()
MenuItem(s String, c Command)
cmd
1
Command
Process()
11
Detailing the Command Pattern (continued)
gui
Menu
MenuItem
com
Command
12
Representing Design Patterns in UML
  • A design pattern is a parameterized
    collaboration

The parameters (stereotype ltltrolegtgt) of the
collaboration
ltltrolegtgt
Client
ltltrolegtgt
ConcreteCommand
Process()
ltltrolegtgt
Invoker
Command
Process()
13
Introduction to Object Design Process
  • Object design
  • After identifying your requirements and creating
    a domain model, then add methods to the software
    classes, and define the messaging between the
    objects to fulfill the requirements.
  • The heart of developing an object-oriented system
    is to decide
  • what methods belong where, and
  • how the objects should interact is terribly
    important and anything but trivial

14
Whats GRASP pattern
  • GRASP - General Responsibility Assignment
    Software Patterns
  • This approach to understanding and using design
    principles is based on patterns of assigning
    responsibilities
  • The GRASP patterns are a learning aid to help one
    understand essential object design, and apply
    design reasoning in a methodical, rational,
    explainable way

15
Whats responsibility
  • Responsibility
  • A contract or obligation of a class
  • Type of Responsibility
  • Doing
  • Doing something itself, such as creating an
    object or doing a calculation
  • Initiating action in other objects
  • Controlling and coordinating activities in other
    objects.
  • Knowing
  • Knowing about private encapsulated data
  • Knowing about related objects
  • Knowing about things it can derive or calculate

16
Responsibilities, Methods and Interaction Diagrams
  • Methods implements responsibilities
  • Responsibilities are implemented using methods
    that either act alone or collaborate with other
    methods and objects
  • Responsibilities and methods are related and
    shown in interaction diagram

17
Basic GRASP Patterns
  • Expert
  • Creator
  • Controller
  • High Cohesion
  • Low Coupling

18
Pattern 1 Information Expert
  • Solution
  • Assign a responsibility to the information expert
    - the class that has the information necessary to
    fulfill the responsibility.
  • Problem
  • What is a general principle of assigning
    responsibilities to objects?
  • The most commonly used pattern

19
Case Study Apply Expert Pattern in the design of
POS
  • What do we have to start the design

20
Continue
  • Next, we need to design how to get the grand
    total of a sale
  • Question
  • Who (which class) should handle this?
  • Answer
  • the one who knows about all the SalesLineltem
    instances of a sale and the sum of their
    subtotals. So, the Sale instance is the answer

21
Continue
  • Q What information is needed to determine the
    line item subtotal?
  • A SalesLineltem.quantity and ProductSpecification
    .price are needed.
  • The SalesLineltem knows its quantity and its
    associated ProductSpecification therefore, by
    Expert, SalesLineltem should determine the
    subtotal it is the information expert

22
Continue
  • In the last step, to fulfill the responsibility
    of getting its subtotal, a Sales- Lineltem needs
    to know the product price.
  • Q Who should handle this?
  • A The ProductSpecification is an information
    expert on answering its price therefore, a
    message must be sent to it asking for its price.

23
Discuss Expert Pattern
  • The main idea - give responsibility to
    individuals who have the information necessary to
    fulfill a task
  • Do It Myself
  • The fulfillment of a responsibility often
    requires information that is spread across
    different classes of objects. This implies that
    there are many "partial information experts who
    will collaborate in the task
  • Contraindications
  • There are situations where a solution suggested
    by Expert is undesirable, usually because of
    problems in coupling and cohesion
  • Benefits
  • Information encapsulation is maintained
  • Class definitions are easier to understand and
    maintain

24
Pattern 2 Creator
  • Solution
  • Assign class B the responsibility to create an
    instance of class A if one or more of the
    following is true
  • B aggregates A objects
  • B contains A objects
  • B records instances of A objects
  • B closely uses A objects
  • B has the initializing data that will be passed
    to A when it is created
  • Problem
  • Who should be responsible for creating a new
    instance of some class?

25
Case Study Apply Create Pattern in POS

26
Continue
Q Who should be responsible for creating a
SalesLineltem instance? A Sale - since it
aggregates many SalesLineItem instances It
requires a makeLineItem method be defined in Sale
27
Discussion of Creator
  • Creator pattern is used to find a creator that
    needs to be connected to the created object in
    any event
  • Creator suggests that the enclosing container or
    recorder class is a good candidate for the
    responsibility of creating the thing contained or
    recorded
  • Sometimes a creator is found by looking for the
    class that has the initializing data that will be
    passed in during creation
  • For example, Sale ? Payment
  • Low coupling (described next) is supported, which
    implies lower maintenance dependencies and higher
    opportunities for reuse
  • Contraindications
  • If creation requires significant complexity, We
    should delegate creation to a helper class called
    a Factory

28
Pattern 3 Low Coupling
  • Solution
  • Assign a responsibility so that coupling remains
    low.
  • Problem
  • How to support low dependency, low change impact,
    and increased reuse?
  • Coupling is a measure of how strongly one element
    is connected to, has knowledge of, or relies on
    other elements.
  • A class with high (or strong) coupling relies on
    many other classes will cause the following
    problems
  • Changes in related classes force local changes.
  • Harder to understand in isolation.
  • Harder to reuse because its use requires the
    additional presence of the classes on which it is
    dependent

29
Case Study Apply Low Coupling in POS
  • Design 1 The Register class couples the Payment
    class. The Sale class couples the payment class
  • Design 2 The Sale class couples the payment
    class
  • Which one is better?
  • Purely from the point of view of coupling,
    Design 2 is preferable because overall lower
    coupling is maintained.

30
Discussion of Low Coupling
  • Low Coupling is a principle to keep in mind
    during all design decisions it is an underlying
    goal to continually consider
  • In object-oriented languages such as C, Java,
    and C, common forms of coupling from TypeX to
    TypeY include
  • TypeX has an attribute (data member or instance
    variable) that refers to a TypeY instance, or
    TypeY itself
  • A TypeX object calls on services of a TypeY
    object
  • TypeX has a method that references an instance of
    TypeY, or TypeY itself, by any means. These
    typically include a parameter or local variable
    of type
  • TypeY, or the object returned from a message
    being an instance of TypeY
  • TypeX is a direct or indirect subclass of TypeY
  • TypeY is an interface, and TypeX implements that
    interface

31
Continue
  • Benefits
  • not affected by changes in other components
  • simple to understand in isolation
  • convenient to reuse

32
Be careful of Inheritance
  • A subclass is strongly coupled to its superclass.
    Be careful since it is such a strong form of
    coupling
  • For example, suppose that objects need to be
    stored persistently in a relational or object
    database. In this case it is a relatively common
    design to create an abstract superclass called
    PersistentObject from which other classes derive
  • Disadvantage
  • It highly couples domain objects to a particular
    technical service and mixes different
    architectural concerns
  • Advantage
  • Automatic inheritance of persistence behavior

33
Pattern 4 High Cohesion
  • Solution
  • Assign a responsibility so that cohesion remains
    high
  • Problem
  • How to keep complexity manageable?
  • Cohesion is a measure of how strongly related and
    focused the responsibilities of an element
    (classes, subsystems) are
  • A class with low cohesion does many unrelated
    things, or does too much work
  • They suffer from the following problems
  • hard to understand
  • hard to reuse
  • hard to maintain
  • delicate constantly effected by change

34
Benefits of High Cohesion
  • Clarity and ease of comprehension of the design
    is increased.
  • Maintenance and enhancements are simplified.
  • Low coupling is often supported.
  • The fine grain of highly related functionality
    supports increased reuse because a cohesive class
    can be used for a very specific purpose.

35
Case Study Apply High Cohesion in POS
  • Low Cohesion (Register has payment
    responsibility, and many other unrelated
    responsibility)
  • The second design supports both high cohesion and
    low coupling, it is desirable.

36
Discussion of High Cohesion
  • In practice, consideration of cohesion should not
    isolate from other responsibilities and other
    principles such as Expert and Low Coupling
  • Like Low Coupling, High Cohesion is a principle
    to keep in mind during all design decisions
  • How we design a class with high cohesion?
  • Assign a class with a relatively small number of
    methods, with highly related functionality, and
    does not do too much work. It collaborates with
    other objects to share the effort if the task is
    large
  • Contraindications
  • Grouping responsibilities or code into one class
    or component to simplify maintenance and
    development
  • Distributed server objects

37
Pattern 5 Controller
  • Solution
  • Assign the responsibility for receiving or
    handling a system event message to a class
    representing one of the following choices
  • Represents the overall system, device, or
    subsystem (facade controller).
  • Represents a use case scenario within which the
    system event occurs
  • Problem
  • Who should be responsible for handling an input
    system event?

38
Benefits of using controller
  • A controller supports the reuse of the logic and
    pluggable interfaces
  • It ensures that application logic is not handled
    in the interface layer. Because an
    interface-as-controller design (it is bound to a
    particular interface) reduces the opportunity to
    reuse logic in future applications
  • Reason about the state of the use case - It is
    sometimes necessary to ensure that system
    operations occur in a legal sequence

39
Case Study Apply Controller in POS
  • There are several system operations (triggered by
    system events)
  • endSale()
  • enterItem()
  • makeNewSale()
  • makePayment()

40
Continue
  • Design Question Who should handle incoming
    system events?
  • Answer By Controller pattern, we use a
    controller class to handle all system events

41
Continue Type of Controllers
  • The controller is a kind of facade into the
    domain layer from the interface layer
  • Two Types of Controller
  • Facade Controller - Represents the overall
    "system," device, or subsystem Register,
    POSSystem
  • Use-Case Controller - Represents a receiver or
    handler of all system events of a use case
    scenario ProcessSaleHandler

42
Choice of Controller Type
  • Facade controllers are suitable when
  • there are not "too many" system events, or
  • it is not possible for the user interface (UI) to
    redirect system event messages to alternating
    controllers, such as in a message processing
    system
  • Choose Use-Case controller if a facade controller
    leads to designs with low cohesion or high
    coupling, typically when the facade controller
    has excessive responsibilities.
  • A use-case controller is a good choice when there
    are many system events across different processes

43
Avoid Bloated Controllers
  • Poorly designed, a controller class will have low
    cohesion - unfocused and handling too many areas
    of responsibility
  • this is called a bloated controller
  • Signs of bloating include
  • There is only a single controller (facade
    controller) class receiving all system events in
    the system, and there are many of them
  • The controller itself performs many of the tasks
    to fulfill the system event. This usually
    involves a violation of Information Expert and
    High Cohesion.
  • A controller has many attributes, and maintains
    significant information about the system or
    domain, which should have been distributed to
    other objects, or duplicates information found
    elsewhere
  • In this case, we can
  • Add more controllers (use-case controllers)
  • Design the controller so that it delegates the
    fulfillment of each system operation
    responsibility on to other objects

44
Interface Layer Should not Handle System Events
  • Assigning the responsibility for system
    operations to objects in the application or
    domain layerusing the Controller pattern rather
    than the interface layer supports increased reuse
    potential

45
Controller Class(es) in POS
46
Middle-Term Exam Produce Analysis Model for the
Payroll Application
47
Mid-term Exam Analysis Model
  • Given the following
  • Use-Case Model, especially the use-case flows of
    events
  • Payroll Requirements, Use-Case Model section
  • Key abstractions/classes
  • Architectural Analysis section
  • The Supplementary Specification
  • Payroll Requirements, Supplementary Specification
    section

48
Mid-term Exam Analysis Model
  • Identify the following for a particular use case
  • The analysis classes, along with their
  • Brief descriptions
  • Stereotypes
  • Responsibilities
  • Produce the following for all the use cases
  • The collaborations needed to implement the use
    case
  • Use-Case Realization - Interaction diagram for
    the use-case flows of events

49
Mid-term Exam Analysis Model
  • Analysis class attributes and relationships
  • VOPC class diagram, containing the analysis
    classes, their stereotypes, responsibilities,
    attributes, and relationships
  • Due Date 14th May 800 am
About PowerShow.com