COMP 6471 Software Design Methodologies

1
COMP 6471Software Design Methodologies

• Winter 2006
• Dr Greg Butler
• http//www.cs.concordia.ca/gregb/home/comp647-w20
  06.html

2
The 9 GRASP Principles

1. Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Polymorphism
7. Pure Fabrication
8. Indirection
9. Protected Variations

3
Principle Information Expert

• Assign a responsibility to the object that has
  the information necessary to fulfill it.
• That which has the information, does the work.
• Eg, Which object knows whether a user has
  permission to access a given document?

4
Principle Creator

• What object creates an X?
• Choose an object C, such that
• C contains or aggregates X
• C closely uses X
• C has the initializing data for X
• The more, the better.
• Eg, Which object creates a session, user,
  project, document?

5
Principle Creator

• What object creates a Command?

6
Principle Controller

• What object in the domain (or application
  coordination layer) receives requests for work
  from the UI layer?
• Solution Choose a class whose name suggests
• The overall system, device, or subsystem
• A kind of Façade class
• Or, represents the use case scenario or session

7
Principle Controller

• Eg, What object receives a request to logon and
  begin a session?
• Eg, What object receives the request to perform a
  command?
• Guideline Normally, a controller should delegate
  to other objects the work that needs to be done
  it coordinates or controls the activity. It does
  not do much work itself.

8
Principle Polymorphism

• How to handle alternatives based on type
• How to create pluggable software components
• Assign responsibility for the behaviour to a
  polymorphic operation in the superclass-subclass
  hierarchy.
• Clearly generalization and polymorphism handles
  the situation where behaviour varies by type.
• To create pluggable components adopt a
  client-server relationship, then vary server
  using polymorphism each server subclass is a
  pluggable component.

9
Principle Polymorphism

• Implies that your code should never have switchs
  or conditional logic that tests the type of an
  object!
• Eg, in CUWME where is polymorphism used?
• Command class
• Composite pattern Document class
• Role is using RBAC1

10
Principle Pure Fabrication

• When assigning responsibilities to an existing
  object would violate cohesion or coupling or
• Assign a highly cohesive set of responsibilities
  to an artificial (or convenience) class that does
  not represent a problem domain concept
  something made up to support high cohesion, low
  coupling, and reuse.
• Pure because it is a clean design (high
  cohesion, low coupling)
• Fabrication because it is made up, invented,
  imagined

11
Principle Pure Fabrication

• Eg, controller objects are pure fabrication
• So the Controller Principle is a special case of
  Pure Fabrication Principle
• Eg, PersistentStorage class is an example of Pure
  Fabrication

12
Principle Pure Fabrication

• Design of objects can be divided into two groups
• Representational decomposition
• Ie those related to representation of entities
  and their components, such as Sale, Vehicle,
  Document,
• While these generally are in the problem domain,
  sometimes we have design representations that
  group them eg DOM tree of a document is pure
  fabrication
• Behavioural decomposition
• Ie those related to representation of a process
  or algorithm. This includes controller classes
  for use cases, Command class, Strategy class, etc
• These are generally not in the problem domain
  model, and are mostly pure fabrication.

13
Principle Indirection

• How to avoid direct coupling
• How to de-couple objects
• Assign the responsibility to an intermediate
  object to mediate between other components or
  services so that they are not directly coupled.
• Eg, Adaptor class to de-couple dependency on an
  explicit third-party interface.
• Eg, Façade classes to de-couple external objects
  from objects internal to the component.
• Eg, uses in CUWME?

14
Principle Indirection

• Most problems in computer science can be solved
  by adding another layer of indirection. David
  Wheeler
• Most problems in performance can be solved by
  removing another layer of indirection!

15
Principle Protected Variations

• How to design objects so that variations or
  instability in these elements does not have an
  undesirable impact on other elements?
• Identify points of predicted variation or
  instability Assign responsibilities to create a
  stable interface around them.
• Eg, information hiding
• Eg, Polymorphism Principle Allowing pluggable
  components using polymorphism of servers in a
  client-server relationship
• Cf, anticipated changes

16
Principle Protected Variations

• Core mechanisms for Protected Variations
• Data encapsulation
• Interfaces
• Polymorphism
• Indirection
• Standards (eg APIs like JDBC)
• Note that these include virtual machines hiding
  OS, DB, network, etc

17
Principle Protected Variations

• Other mechanisms for Protected Variations
• Data-driven designs
• Callback (eg Observer, Listener), service lookup
• Interpreter-driven designs
• Reflection or meta-level designs
• Structure hiding designs, such as composite
  pattern with iterator and visitor pattern for
  accessing and traversing the structure

18
Principle Protected Variations

• Two kinds of change
• Variation point
• Variations in the existing current system or
  requirements that must be supported in this
  system.
• Evolution point
• Speculative points of variation that may arise in
  the future, but which are not present in the
  existing requirements.

19
Principle Protected Variations

• Examples in CUWME?

20
Principle Low Coupling

• Assign responsibilities so that coupling remains
  low.
• Definition Coupling is a measure of how strongly
  one element
• is connected to,
• has knowledge of, or
• relies on
• other elements.
• An element with low coupling is not dependent on
  too many other elements.
• too many is context-dependent

21
Principle Low Coupling

• Low coupling is an evaluative principle that can
  always be applied to evaluate alternative designs.

22
Principle Low Coupling

• Forms of coupling
• TypeX has an attribute that refers to a TypeY
  instance
• A TypeX object calls on services of a TypeY
  object
• TypeX has a method that references an instance of
  TypeY, or TypeY itself (ie as parameter, local
  variable, or return object)
• TypeX is a direct or indirect subclass of TypeY
• TypeY is an interface, and TypeX implements that
  interface.

23
Principle High Cohesion

• Assign responsibilities so that cohesion remains
  high.
• Definition (Functional) cohesion is a measure of
  how strongly related and focused the
  responsibilities of an element are.
• High cohesion is an evaluative principle that can
  always be applied to evaluate alternative designs.

24
Principle Modularity Low Coupling High
Cohesion

• Modularity is the property of a system that has
  been decomposed into a set of cohesive and
  loosely coupled modules. Booch 1994