SOEN 343 Software Design

1
SOEN 343Software Design

• Section H Fall 2006
• Dr Greg Butler
• http//www.cs.concordia.ca/gregb/home/soen343h-f0
  6.html

2
Outline

• Week 9 lectures Evaluate Good Design
• Page Controller and Front Controller
• Note Command Pattern
• Web EA Do-It-All TS Re-design
• GRASP Principles
• Pure Fabrication
• Indirection

3
Recall the Greeting EA

• A single servlet which offers the greeting
  Hello.
• We refactored it, offering two alternative
  designs.

4
Review Question

• On a blank sheet of paper
• Provide three class diagrams corresponding to the
  three design solutions of the Greeting EA.

5
Evaluating a Design

• Which is a better design?
• What is a good design?

6
What is a good design?

• Satisfies user needs, requirements.
• Reveals intent.
• Is a simple as possible.
• Minimizes cost of likely changes.
• And
• High cohesion.
• Low coupling.

7
Greeting EA Evolution What if

• Support a personalized greeting.
• Change look of output (e.g. bold the name).
• Get full name from db.

8
Comparing Design Solutions
Property Soln 1 Soln 2 Soln 3
Correct ? ? ?
Intent clear
Simplest
Acc. Change
Cohesion
Coupling
9
GRASP Controller

• Who handles a system event?
• E.g. List Movies
• Main choices assign to a design entity
  representing
• Overall system, or subsystem (façade
  controller).
• A Use Case scenario(often named, e.g.
  ListMovieHandler).

10
GRASP Controller

• Who handles a system event?
• E.g. List Movies
• Main choices assign to a design entity
  representing
• Overall system, or subsystem (façade
  controller).
• A Use Case scenario(often named, e.g.
  ListMovieHandler).

11
Controller Patterns
Template View
Page Controller
Presentation
Front Controller
Transform View
Domain Model
Transaction Script
Domain
Data Mapper
Active Record
Table Module
Data Mapper
Table Data Gateway
Row Data Gateway
Data Source
Table Data Gateway
12
Page Controller (done)
13
Front Controller

• Fowler A controller that handles all requests
  for a web site.
• The Front Controller consolidates all request
  handling by channeling requests through a single
  handler object. This object can carry out common
  behaviour which can be modified at runtime with
  decorators. This handler then dispatches to
  command objects for behaviour particular to a
  request.

14
Front Controller

• GoF design pattern Command
• Use a Command object to encapsulate the steps
  that are executed by a command.
• CommanddoIt() executes command
• Allows CommandunDoIt() etc
• GoF design pattern Decorator
• Decoratorm() adds additional behaviour, but
  delegates to real Objectm() for real behaviour
• Eg, logging command execution before/after
  executing command

15
Page vs Front Controller Differences in URL

• Page Controllers for A1
• http/stu.cs/343A1/ViewTaskList
• http/stu.cs/343A1/AddTask
• http/stu.cs/343A1/RemoveAllTasks
• Front Controller for A1
• Base URL http/stu.cs/343A1/frontController
• /frontController?commandViewTaskList
• /frontController?commandAddTaskGradetitleabc
  

16
Front Controller
17
Front Controller
18
Front Controller (Fowler)Command (GoF) Patterns
FrontCommand
init ( )
processRequest ( )
ViewStudInfoCommand
RemoveStudentCommand
processRequest ( )
processRequest ( )
19
Front Controller Sequence Diagram
20
Front Controller ProcessRequest
21
Front Controller (contd)
22
Front Controller Advantages?
23
Web EA Redesign Exercise

• Refactoring a DoItAll Servlet, let me count the
  ways

24
Do-it-all Servlet or Script
Do-it-allServlet or Script
Presentation
Domain
Data Source
25
Do-it-all Servlet or Script, Class

• public class DoItAll extends javax.servlet.http.Ht
  tpServlet
• protected void doGet(
• HttpServletRequest request,
• HttpServletResponse response)
• throws ... //

26
Redesigning This Application

• Redesign DoItAll so as to increase the class
  cohesion.
• Create new classes. Which EA patterns would you
  use?
• Distribute the doGet() method code (given on the
  next slide) into the new classes. Identify which
  lines would go into which classes.

27
Do-it-all Transaction Script, doGet()

• String lastName request.getParameter(")
• Connection dbc DbRegistry.getDbConnection()
• String findSql "SELECT from where LastName
  ?
• PreparedStatement dbQuery dbc.prepareStatement(f
  indSql)
• dbQuery.setString(1, lastName)
• ResultSet rs dbQuery.executeQuery()
• rs.next()
• String firstName rs.getString("FirstName")
• lastName lastName.toUpperCase()
• PrintWriter out response.getWriter()
• response.setContentType("text/html")
• out.println("lth1gtHello "firstName"
  "lastName"lt/h1gt")

28
Do-it-all Servlet Redesign Separating Concerns

• The next few slides show ways in which we can
  separate concerns i.e. distribute the
  functionality of the do-it-all script into
  separate classes.
• Combinations other than the ones shown are
  possible.

29
Redesigning Do-it-all (2 classes) 1
Do-it-all
Presentation
Domain
Data Source
Note
30
Redesigning Do-it-all (3 classes) 3
Do-it-all
Presentation
Domain
Data Source
31
Redesigning Do-it-all (4 classes) 4
Do-it-all
Presentation
Domain
Data Source
32
Redesigning Do-it-all Adding (5 classes) 5
Do-it-all
Presentation
Domain
Data Source
33
Redesigning Do-it-all Adding 5b
Do-it-all
Presentation
Domain
Data Source
34
Redesigning Do-it-all (5 classes) 5c
Do-it-all
Presentation
Domain

• Is there anything wrong with this design? (Hint
  consider the dependencies and the layering style.)

Data Source
35
Redesigning Do-it-all (6 classes) 6
Do-it-all
Presentation
Domain
Data Source
36
Pure Fabrication

• Problem Existing objects, ie domain objects, are
  not appropriate to have the responsibility
• Solution suggested by Information Expert not
  appropriate
• Might violate high cohesion, low coupling
• Solution Fabricate (ie create, make up) a new
  object to hold the responsibility

37
GRASP Pure Fabrication

• Assign a highly cohesive set of responsibilities
  to an artificial or convenience class that does
  not represent a problem domain conceptsomething
  made up, to support high cohesion, low coupling,
  and reuse.
• Can you think of an example from EA?

38
GRASP Pure Fabrication

• Design of objects
• Representational decomposition
• Behavorial decomposition
• Its OK for OO software to have objects
  representing behaviour, ie use case, process,
  function, strategy, TS
• But do not overdo it
• All GoF design patterns are Pure Fabrications

39
Indirection

• Problem How to assign responsibility to avoid
  direct coupling? How to de-couple objects?
• Solution Assign responsibility to an
  intermediatory object to mediate between the two
  components
• Example Adapter pattern
• Intermediatory to external tax calculators

40
Fig. 25.10
41
Indirection

• Most problems in computer science can be solved
  by another level of indirection