M'Sc Computing Science Software Engineering Lecture 5

1
M.Sc Computing Science Software Engineering
Lecture 5

• Niki Trigoni
• Department of Computer Science
• and Information Systems
• Birkbeck College, University of London
• Email niki_at_dcs.bbk.ac.uk
• Web Page http//www.dcs.bbk.ac.uk/niki

2
Review of lecture 4

• We introduced interaction diagrams (collaboration
  and sequence diagrams) and their notation
• We discussed the notion of responsibilities and
  what it means to assign a responsibility to an
  object
• We showed how interaction diagrams reflect
  responsibility assignment decisions
• We introduced the concept of design patterns.
• Given specific responsibility assignments
  (expressed in a textual format), we practiced
  designing interaction diagrams

3
Overview of lecture 5

• The GRASP patterns
• Information Expert
• Creator
• Low Coupling
• High Cohesion
• Controller
• Design Class Diagrams (DCDs).

4
The Information Expert pattern

• Pattern Name Information Expert
• Solution Assign a responsibility to the
  information expert, i.e. the class that has the
  information necessary to fulfill the
  responsibility.
• Problem It Solves What is a general principle
  of assigning responsibility to objects?

5
Information Expert example

• Which classes are responsible for evaluating the
  total of a sale, the subtotal of a SalesLineItem,
  the price of a product?

Sales LineItem quantity
Sale date time
ProductSpec description price itemID
Contains
Described-by
1
1
1..

tgetTotal()
1stgetSubtotal()
SalesLineItem
Sale

1.1pgetPrice()
ProductSpec
6
Discussion about the Information Expert

• The Information Expert is the most widely used
  guiding principle in object design.
• Information is spread across many classes gt
  partial information experts that collaborate
• Software objects are alive (animated), they can
  do things based on the information they hold.
• Contraindication of using the Information Expert
  Who should be responsible for saving a Sale to
  the database?
• The Information Expert may not be applicable when
  it violates the basic architectural principle
  design or a separation of major system concerns
• How is Information Expert related to low coupling
  and high cohesion?

7
The Creator pattern

• Pattern Name 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
• B is a creator of A objects. If more than one
  option applies, prefer a class B which aggregates
  or contains class A.
• Problem It Solves What is a general principle
  of assigning responsibility to objects?

8
Creator example

• Which class should be responsible for creating a
  new SalesLineItem?

Sales LineItem quantity
Sale date time
ProductSpec description price itemID
Contains
Described-by
1
1
1..

makeLineIteml()
1.create(qty)
SalesLineItem
Sale
9
Discussion about the Creator

• Goal find the creator of objects of a class
• Guideline look for relationships like
  aggregates, contains, records etc. The enclosing
  aggregator, container or recorder is a good
  candidate for creating the object aggregated,
  contained or recorded.
• The creator may be chosen as the class that knows
  initializing data for the creation operation.
  Which other pattern does this remind you of?
• How does the Creator pattern achieve low
  coupling?
• Contraindications of applying the Creator
  pattern creation operation is complex (recycled
  instances, uncertainty about the class of the
  created object)

10
The Low Coupling pattern

• Pattern Name Low Coupling
• Solution Assign a responsibility so that
  coupling remains low.
• Problem It Solves How to support low
  dependency, low change impact, and increased
  reuse?

11
Low coupling example

• Who should be responsible for creating a Payment
  and associating it with a Sale?

Payment amount
Sale date time
Register
Paid-by
Captures
1
1
1
1
makePayment()
1.create()
pPayment
Register
2addPayment(p)
Sale
Is this the best possible design? How many
objects are related to (coupled with) the
Register object? Can we achieve lower coupling?
12
Low coupling example

• Who should be responsible for creating a Payment
  and associating it with a Sale?

Payment amount
Sale date time
Register
Paid-by
Captures
1
1
1
1
makePayment()
1.makePayment()
Sale
Register
1.1. create()
Payment
Register is now coupled with objects of one class
(Sale). If the class Payment is modified, only
Sale will be affected. This design is preferred
because it provides lower coupling between
classes.
13
Discussion about Low Coupling

• Common forms of coupling from TypeX to TypeY
  include
• TypeX has an attribute that refers to a TypeY
  instance
• TypeX calls on services of a TypeY object
• TypeX has a method that references an instance of
  TypeY, or TypeY itself
• TypeX is a direct or indirect subclass of TypeY
• TypeY is an interface, and TypeX implements that
  inteface
• Low coupling supports the design of classes that
  are more independent gt reduces impact of change

14
Discussion about Low Coupling

• Classes that are inherently generic and are
  reused in many places must have a particularly
  low degree of coupling
• Contraindication It is safe to couple a class to
  stable classes (e.g. classes in Java libraries)
• Coupling becomes problematic when unstable
  elements (classes) are involved. What does it
  mean for a class to be unstable?
• Benefits of low coupling
• Easy maintenance
• Classes easy to understand
• Software reuse

15
The High Cohesion pattern

• Pattern Name High Cohesion
• Solution Assign a responsibility so that
  cohesion remains high.
• Problem It Solves How to keep complexity
  manageable?

16
High cohesion example

• Who should be responsible for creating a Payment
  and associating it with a Sale? Comment on the
  level of cohesion of Register in the two
  diagrams. Is Register at risk of becoming
  incohesive in the future and why?

makePayment()
1.create()
pPayment
Register
2addPayment(p)
Sale
makePayment()
1.makePayment()
Sale
Register
1.1. create()
Payment
17
Discussion about High Cohesion

• A class with high cohesion has a relatively small
  number of methods, with highly related
  functionality, and does not do too much work.
• Benefits of high cohesion
• Easy maintenance
• Classes easy to understand
• Software reuse
• Coupling and cohesion viewed together gt modular
  design
• Modularity is the property of a system that has
  been decomposed into a set of cohesive and
  loosely coupled modules Booch94
• Contraindications maintenance by one person,
  remote communication

18
The Controller pattern

• Pattern Name 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, often named
  ltUseCasegtHandler, ltUseCasegt Coordinator, or
  ltUseCasegtSession (use-case or session
  controller)
• Problem It Solves Who should be responsible for
  handling an input system event?

19
Controller example

• Who should be responsible of handling external
  system events (e.g. enterItem)? Which of the
  following interaction diagrams is preferred?

enterItem(it, qty)
Register
enterItem(it, qty)
ProcessSaleHandler
20
Discussion about the Controller

• The Controller pattern provides guidance about
  which object will handle external events.
• If all system events of a use case are handled in
  the same class, it is possible to identify
  out-of-sequence system events.
• Common defect in the design of controllers too
  much responsibility
• A controller delegates work to other objects. It
  plays the role of a coordinator, but does not
  actually do the work.
• System operations should be handled at the domain
  layer by controllers, not at the interface layer
  by GUI objects.

21
Discussion about the Controller

• How to choose between facade and use-case
  controllers
• Facade controller Suitable when there are few
  system events.
• Use-case controller Suitable when there are many
  system events and the facade controller would
  have become too large and incohesive.
• Benefits
• Reuse of domain layer software, by plugging
  different interfaces
• Control of out-of-sequence system operations

22
Overview of lecture 5

• The GRASP patterns
• Information Expert
• Creator
• Low Coupling
• High Cohesion
• Controller
• Design Class Diagrams (DCDs)

23
Design Class Diagrams (DCDs)

• DCDs, Design Class Diagrams, provide a static
  view of the Design Model
• DCDs are created in parallel with Interaction
  diagrams
• Example DCD

Sale date time isCompleteBoolean makeLineItem()
Register enterItem()
Captures
1
1
24
Design Class Diagrams (DCDs)

• DCDs illustrate
• Classes and interfaces
• Associations (and navigability)
• Attributes and often their types
• Methods, their parameters, and often parameter
  and method result types
• How are DCDs different from class diagrams of the
  Domain Model?
• How are DCDs different from interaction diagrams?

25
How to generate DCDs

• Identify software classes by looking at the
  Interaction diagrams or the Domain Model class
  diagrams. Some of the classes in the Domain Model
  may be omitted.
• Add attributes based on the attributes of the
  classes in the Domain Model (or the attributes of
  objects in the Interaction diagrams). In the
  Design Model, additional attributes may be added
  (that are not defined in the Domain Model). Types
  of attributes may also be added.
• Add methods by analyzing the Interaction
  diagrams. If a message is sent to an instance of
  a class A, then class A in a DCD must define a
  method with the same name.
• Add associations by drawing inspiration from the
  Domain Model and considering visibility between
  objects

26
Methods in DCDs

• Creation messages are not translated to methods
  in a DCD.
• Accessor and mutator methods (getAttribute,
  setAttribute) are also omitted.
• Messages to multiobjects must be interpreted with
  caution.
• How do we distinguish between messages directed
  to a multiobject (container) and messages
  directed to each individual contained object (in
  an Interaction diagram)?
• How does this difference affect how we add
  methods in a DCD?

Example???
27
Associations in DCDs

• Associations in DCDs are formed based on
  attribute visibility
• Navigability arrows indicate attribute visibility
  from the source to the destination class.
  Attributes pointing to visible objects are
  usually omitted.

Sale date time isCompleteBoolean makeLineItem()
Register currentSaleSale enterItem()
Captures
(Can be omitted)
1
1
28
Dependency relationships in DCDs

• Dependency relationships indicate non-attribute
  visibility and are illustrated with dashed arrow
  lines.

Sale dateDate timeTime isCompleteBoolean makeL
ineItem()
Register enterItem()
Captures
1
1
1
Looks-in
1
ProductSpec descriptionText priceMoney specIdIn
teger
ProductCatalog getSpec ()
Contains
1..
1
29
Summary of lecture 5

• The Information Expert pattern suggests that
  responsibilities should be assigned to objects
  that contain relevant information.
• The Creator pattern suggests that the creator of
  an object is usually an object that contains, or
  aggregates it.
• The Low Coupling pattern suggests that
  interdependency between classes should remain
  low.
• The High Cohesion pattern suggests that
  responsibilities of a certain class must be
  highly related.
• The Controller pattern indicates which class will
  handle external system events.
• Unlike interaction diagrams, class diagrams
  provide a static view of the Design Model. Like
  interaction diagrams, they clearly reflect
  responsibility assignment (through methods).