EnergyEfficient Data Management for Sensor Networks

1
M.Sc Computing Science Software Engineering
Lecture 5
Eli Katsiri Department of Computer Science and
Information Systems Birkbeck College, University
of London Email eli_at_dcs.bbk.ac.uk Web Page
http//www.dcs.bbk.ac.uk/eli
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
• Given specific responsibility assignments
  (expressed in a textual format), we practiced
  designing interaction diagrams

3
Overview of lecture 5

• We introduce the concept of design patterns.
• The GRASP patterns
• Information Expert
• Creator
• Low Coupling
• High Cohesion
• Controller
• Design Class Diagrams (DCDs).

4
Patterns

• Patterns guide object-oriented developers in the
  creation of software.
• They codify existing tried-and-true knowledge and
  principles the more widely they are used, the
  better.
• They are expressed in a standard format
• Pattern Name
• Solution
• Problem It Solves

5
Pattern Example The Information Expert

• Pattern Name Information Expert
• Solution Assign a responsibility to the
  information expert- the class that has the
  information necessary to fulfill the
  responsibility.
• Problem It Solves What is a general principle
  of assigning responsibility to objects?
• Consequences These are the results and
  trade-offs of applying the pattern. Critical for
  evaluating design decisions in terms of
  reusability , flexibility, portability.

6
Why are patterns useful?

• Patterns are very simple to use.
• They are applicable in many contexts in fact,
  the notion of a new pattern could be considered
  an oxymoron.
• If one learns how to apply them properly, s/he
  will generate designs that are easy to
  understand, maintain and reuse.
• By referring to pattern names, designers can
  communicate easily and explain the reasons behind
  their design choices.
• Patterns provide a formal framework for
  generating good designs gt avoid hand-waving.

7
The GRASP patterns

• Information Expert
• Creator
• Low Coupling
• High Cohesion
• Controller

8
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?

9
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
10
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?
• How is Information Expert related to low coupling
  and high cohesion?

11
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?

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.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?
13
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.
14
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

15
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

16
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?

17
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
18
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)?

19
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? How to keep objects focused.

20
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
21
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

22
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?

23
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
24
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.

25
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

26
Overview of lecture 5

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

27
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
28
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?

29
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

30
Visibility

• Attribute visibility B is an attribute of A
• Parameter visibility B is a parameter of a
  method of A
• Local visibility - B is a local object in a
  method of A
• Global visibility B is in some way globally
  visible.
• For an object A to send a message to an object B,
  B must be visible to A.

31
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
32
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
33
Implementation model

• Interaction diagrams and DCDs input to code
  generation
• The Implementation Model includes
• source code for classes
• database schema
• XML/HTML pages
• etc.
• Writing code in an OO programming language (like
  Java) is not considered part of OOA/D
• Most of the creative work took place during
  OOA/D. Transition to implementation is mostly
  mechanical
• Expect deviations from the design during
  programming

34
Code changes and the iterative model
Iterative Cycles of Development
Requirements Analysis
Requirements Analysis
Design
Design
Implementation
Implementation
Time
35
Creating class definitions from DCDs

• Straightforward mapping of attribute definitions
  and method signatures. Dont forget to add
  constructors.

ProductSpec descriptionText priceMoney itemIDIt
emID
SalesLineItem quantityInteger getSubtotal()Mon
ey
Described-by
1

public class SalesLineItem private int
quantity public SalesLineItem(ProductSpec
spec, int qty) public Money getSubtotal()

36
Reference attributes

• A reference attribute is an attribute that refers
  to another object, not to a primitive type such
  as String, Number and so on.

ProductSpec descriptionText priceMoney itemIDIt
emID
SalesLineItem quantityInteger getSubtotal()Mon
ey
Described-by
1

productSpec
public class SalesLineItem private int
quantity private ProductSpec productSpec publi
c SalesLineItem(ProductSpec spec, int qty)
public Money getSubtotal()
37
Creating methods from interaction dgrms

• An interaction diagram shows messages sent in
  response to a method invocation. These are
  translated to code in this method.

enterItem(id,qty)?
2makeLineItem(spec,qty)?
Register
Sale
1specgetSpecification(id)?
Product Catalog
public void enterItem (ItemID id, int
qty)? ProductSpec spec catalog.getSpecificati
on(id) sale.makeLineItem (spec, qty)
38
Collection attributes

• Visibility to a group of objects in DCDs is often
  translated to a collection attribute in the
  Implementation Model.

Sale
SalesLineItem
Contains
1..
1
public class Sale private List lineItems
new ArrayList()
39
Order of class implementation

• The order of implementing classes depends on
  their dependencies. One possible order for the
  example below is

Sale
Register
SalesLineItem
Captures
Contains
5
4
3
1
1
1..
1
1

Looks-in
Described-by
1
1
ProductCatalog
ProductSpec
Contains
1
2
1..
1
40
Test-first programming

• Unit testing code is written before the code to
  be tested.
• Example

public class SaleTest extends TestCase
// public void testTotal() // set up the
test Money total new Money ( 7.5 ) Money
price new Money ( 2.5 ) ItemID id new
ItemID ( 1 ) ProductSpec spec new
ProductSpec ( id, price, prod 1 ) Sale sale
new Sale () // add the items sale.makeLineI
tem ( spec, 1 ) sale.makeLineItem ( spec, 2
) // verify the total is 7.5 assertEquals (
sale.getTotal(), total )
41
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?

42
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?
43
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.
44
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

45
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

46
Summary of lecture 6

• OOA/D allows a smooth transition from
  requirements to code
• During use-case realizations, we apply design
  patterns to create extensible, clear and
  maintainable object software designs.
• The Implementation model is derived from the
  Design Model in a relatively mechanical manner.
  However, the Implementation Model may deviate
  from the Design Model.
• The Design Model may be updated based on
  changes/observations made in the Implementation
  Model (reverse-engineering).

47
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).