SOEN 6011 Software Engineering Processes

1
SOEN 6011Software Engineering Processes

• Section SS Fall 2007
• Dr Greg Butler
• http//www.cs.concordia.ca/gregb/home/soen6011-f2
  007.html

2
Week 7

• Responsibility-Driven Design
• Layer Architecture
• Model-View-Control
• Fowlers EAA Patterns
• Anatomy of a web site
• Controller, Command patterns
• Front Controller
• Data Management patterns
• Domain and DataMapper

3
What is Design?

• Developing a blueprint (plan) for a mechanism
  that performs the required task,
• taking into account all the constraints,
• making trade-offs between constraints when they
  are in conflict.

4
What is OO Analysis and Design

• Object-Oriented Design
• Design of software objects
• Responsibilities
• Collaborations
• Design patterns
• Visualized in the UP Design Model

• Object-Oriented Analysis
• Important domain concepts or objects?
• Vocabulary?
• Visualized in the UP Domain Model

5
Evolutionary Design

• What is the probability that a S/W design will
  need to be updated?
• Change is inevitable, evolutionary design
  recognizes this.
• As software is changed, generally it becomes more
  complex unless effort is made to keep it simple.

6
Prerequisites to Successful Evolutionary Design?

• Testing
• lots of automated testing.
• Refactoring
• keeping the design simple.
• Continuous integration
• Actually, testing is a prerequisite to
  refactoring.

7
Responsibility-Driven Design (RDD)

• Detailed object design is usually done from the
  point of view of the metaphor of
• Objects have responsibilities
• Objects collaborate
• Responsibilities are an abstraction.
• The responsibility for persistence.
• Large-grained responsibility.
• The responsibility for the sales tax calculation.
• More fine-grained responsibility.

8
Object Responsibilities

• A responsibility is an obligation of an object in
  terms of its behavior.

9
General Classification of Kinds of Responsibility

• To know.
• To do.
• To decide.

10
Responsibilities A Boat Metaphor

• What kind of responsibilities do each of the
  following objects have
• To know.
• To do.
• To decide.

11
Responsibilities A Boat Metaphor

• Kind of responsibility for
• Captain
• To know?
• To do?
• To decide?

12
Responsibilities A Boat Metaphor

• Kind of responsibility for
• Navigator.
• To know?
• To do?
• To decide?

13
Responsibilities A Boat Metaphor

• Kind of responsibility for
• Compass.
• To know?
• To do?
• To decide?

14
Important Concepts

• Model
• Abstraction hiding (unimportant) details
• Eg, cover of Larmans book
• GRASP Principle
• for assigning responsibility
• Design pattern
• Solution to design problem in context
• Eg, Command pattern

15
The 9 GRASP Principles

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

16
Can you pick out a good design?

• What is a good design?
• Satisfies user needs.
• Is a simple as possible. Kent Beck
• Runs all tests
• Reveals intention.
• No duplication.
• Fewest number of classes or methods
• can you smell bad design choices?

17
Overview of Patterns
18
Layered Architectural Style

• Our focus today
• Architectural style Layered.
• References
• Larman, Chapter 13.
• Fowler, EA.
• Briefly, lets review Client-Server

19
Layered Style Characteristics

• Each layer offers services to layers above.
• Hence, layers build upon each other to provide
  increased functionality.

20
Layering Pure Style

• Pure style components are permitted to use
  services of other components in
• same layer.
• layer immediately below.

21
Client-Server (Two-tiered System)

• most people see tier as implying a physical
  separation. Client-server systems are often
  described as two-tier systems Fowler,p19

22
Enterprise Application Layers
23
Enterprise Application Layers
Presentation
Domain Logic
Data Source
24
Layering General Scheme

• Layers
• Presentation / Application.
• UI.
• Generally thin.
• (Term application can be misleading. It does
  not mean )
• Domain / Business Logic.
• Core system functionality.
• Technical Services.

25
General Layering Scheme Refined

• Presentation
• Domain
• Technical services

• Presentation
• Application
• Domain (logic)
• Low-level domain logic
• Technical services
• Foundation.

26
Typical Software Architecture Layers
27
Typical Software Architecture Layers (Simplified)
28
Layer Dependencies Example
29
Domain Logic (Layer)

• also referred to as business logic. It
  involves calculations based on inputs and stored
  data, validation of any data that comes in from
  the presentation, and figuring out exactly what
  data source logic to dispatch Fowler, p.20

30
Logical Architecture Layers Partitions
31
Fowlers EA Patterns
Template View
Page Controller
Presentation
Front Controller
Transform View
Domain Model
Transaction Script
Domain
Table Module
Active Record
Data Mapper
Row Data Gateway
Table Data Gateway
Data Source
32
Enterprise Applications Patterns

• Assignments (and some lectures) are about
  building web-based systems for enterprise
  applications
• Involve
• Presentation on the web
• Business Logic and Business Objects
• Data storage and access
• use book of Martin Fowler, Patterns of
  Enterprise Application Architecture

33
Design Model
34
Model-View Separation Principle (MVC) UI layer
has views Domain layer has model
35
Model-View-Control Architecture (MVC)

• MVC is an acronym for Model View Controller
• It represents a software design pattern developed
  at Xerox PARC in 1978 (!)
• It explains a method of separating the visual,
  interaction and data components.
• Very popular, used extensively in Java and other
  languages

36
Model-View-Control Architecture (MVC)

• Model
• maintains the state and data of the application -
  the XML document
• View
• A rendering of the XML document
• Controller
• The user interface presented to the user to
  manipulate the application

37
Why use MVC

• Makes it very easy to have multiple different
  displays of the same information.
• For example a graph and a table could both
  display and edit the same data.
• Essentially provides greater control over the UI
  and its behaviour.

38
MVC Model

• The Model contains the data
• Has methods to access and possibly update its
  contents.
• Often, it implements an interface which defines
  the allowed model interactions.
• Implementing an interface enables models to be
  pulled out and replaced without programming
  changes.

39
MVC Controller

• Users interact with the controller.
• It interprets mouse movement, clicks, keystrokes,
  etc
• Communicates those activities to the model eg
  delete row, insert row, etc
• Its interaction with the model indirectly causes
  the View(s) to update

40
MVC View

• The View provides a visual representation of the
  model.
• There can be multiple views displaying the model
  at any one time.
• For example, a companies finances over time could
  be represented as a table and a graph.
• These are just two different views of the same
  data.
• When the model is updated, all Views are informed
  and given a chance to update themselves.

41
Jacobsons Objectory Design Objects
42
Jacobsons Objectory Design Objects

• Robustness model has
• Entity objects
• Boundary (interface objects)
• Control objects
• Essentially UML collaboration (communication)
  diagram

43
Jacobsons Robustness Analysis Bridges
Analysis-Design Gap
44
PATTERN Controller

• What object in the domain (or application
  coordination layer) receives requests for work
  from the UI layer?

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

46
PATTERN Controller (Larman 17.13)

• Problem What object in the domain (or
  application coordination layer) receives requests
  for work from the UI layer?
• System operations (see SSD) major input events
  to the system
• The controller is the first object beyond the UI
  layer that is responsible for receiving or
  handling a system operations message.
• Note that UI objects delegate system operation
  request to a controller.

47
PATTERN Controller (Larman 17.13)

• Solution Assign the responsibility to a class
  representing one of the following choices
• A façade controller, which represents
• the overall system
• A root object
• A device that the software is running within, or
• A major subsystem
• A use case or session controller which represents
  a use case scenario in which the system operation
  occurs

48
Fig. 17.21
49
Data Source Patterns
Template View
Page Controller
Presentation
Front Controller
Transform View
Domain Model
Transaction Script
Domain
Active Record
Row Data Gateway
Data Mapper
Data Source
Table Data Gateway
50
Row Data Gateway

• An object that acts as a single record in the
  data source
• There is one instance per row
• Fowler RDG combines two roles
• Class Finder with find(id)Gateway method
• which returns the object
• Class Gateway which is the object
• Our PersGradeRDG (next slide) combines

51
Row Data Gateway
PersGradeRDG
- name String - grade int
PersGradeRDG(name, grade) find(name)
PersGradeRDG insert() void update()
void delete() void getters and setters
52
Row Data Gateway Find Code
53
Row Data Gateway

• Code sample for Fowlers PersonRDG
• Note find method is static
• it is class method

54
GetByLastName Example

• Simple web application to
• Input a students last name
• Fetch database record
• Output students full name

55
GetByLastName

• Will look at
• Row Data Gateway
• PageController
• Transaction Script

56
Row Data Gateway

• StudInfoRDG
• Represents record in DB of student
• StudInfoFinder
• Finds student record based on lastName
• Returns the StudInfoRDG
• Locates DB using DBRegistry

57
Enterprise Application Patterns
Template View
Page Controller
Presentation
Front Controller
Transform View
Domain Model
Transaction Script
Domain
Active Record
Row Data Gateway
Data Mapper
Data Source
Table Data Gateway
58
Transaction Script

• Fowler A TS organizes the business logic
  primarily as a single procedure where each
  procedure handles a single request from the
  presentation.
• The TS may make calls directly to the DB or
  through a thin DB wrapper.
• Think of a script fora use case or business
  transaction.
• Implementation can be
• shared among subroutines.
• Subroutines can be used by more than one script

59
Transaction Script

• is essentially a procedure that takes the
• input from the presentation,
• processes it with validations and calculations,
• stores data in the database,
• (invokes any operations from other systems, and)
• replies with more data to the presentation
  perhaps doing more calculation to help organize
  and format the reply data.
• (Fowler)

60
GetByLastName

• Will look at
• Row Data Gateway
• PageController
• Transaction Script

61
Do-it-all Transaction Script

• A TS that does all the work itself
• Without a Finder
• Without a RDG
• Directly calls DB

62
Do-it-all Servlet or Script, Class

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

63
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")

64
Controller Patterns
Template View
Page Controller
Presentation
Front Controller
Transform View
Domain Model
Transaction Script
Domain
Active Record
Row Data Gateway
Data Mapper
Data Source
Table Data Gateway
65
Page Controller

• Fowler
• A Page Controller is an object that handles a
  request for a specific page or action on a web
  site.
• There is one input controller for each logical
  page of the web site.
• Page Controller
• handles the http get and post
• Decides which model and view to use

66
Page Controller

• Responsibilities
• Decode the URL, extract any form data, decide
  action
• Create and invoke any model objects
• All relevant data from the html request should be
  passed to the model, so the model does not need
  any connection to html request
• Determine which view should display the result
  page
• Forward model information to it
• Helper objects can be created/used to perform
  tasks that are shared

67
Page Controller

• Fowler Example
• display info about a recording artist
• ActionServlet implements common forward task
• ArtistController implements doGet()
• Checks artist name is ok
• Creates a new ArtistHelper object with Artist as
  attribute
• Adds helper information to html request
• Forwards request to Artist.jsp
• Artist.jsp is a TemplateView which gets
  information to display from helper object (which
  it gets from request)

68
Page Controller
69
GetByLastName

• Will look at
• Row Data Gateway
• PageController
• Transaction Script

70
Page Controller

• SOEN EA sample
• display info about a student
• PageController implements doGet()
• Delegates to transaction script
• Note
• does not follow Fowlers use of .jsp
• delegates rather than forwards
• no explicit helper object
• (really StudInfoRDG is helper)

71
Domain Logic Patterns
Presentation
Template View
Page Controller
Front Controller
Transform View
Transaction Script
Domain Model
Domain
Active Record
Table Module
Data Mapper
Table Data Gateway
Row Data Gateway
Data Source
72
Domain Logic (Layer)

• also referred to as business logic. It
  involves calculations based on inputs and stored
  data, validation of any data that comes in from
  the presentation, and figuring out exactly what
  data source logic to dispatch p.20

73
Pure Domain Logic Patterns

• Two main alternatives
• Transaction Script
• Domain Model

74
Hybrid Domain Logic

• Hybrid (Domain Data Source) alternatives
• Active Record
• Table Module
• To be discussed a little later.
• For now, focus on the pure Domain Logic patterns.

75
Choosing Between TS DM

• Application is simple access to data sources
• ? Transaction Script, (or Active Record, Table
  Module)
• Significant amount of business logic
• ? Domain Model
• TS is simpler
• Easier and quicker to develop and maintain.
• But can lead to duplication in logic / code.

76
Domain Model (EA Pattern)

• Fowler An object model of the domain that
  incorporates both behaviour and data.
• A DM creates a web of interconnected objects,
  where each object represents some meaningful
  individual, whether as large as a corporation or
  as small as a single line in an order form.

77
Domain Model (EA Pattern)

• Realization (via design classes) of UML Domain
  Model (conceptual classes).
• E.g. person, book, shopping cart, task, sales
  line item,
• Domain Model classes contain
• Logic for handling validations and calculations.
• E.g. a shipment object
• calculate the shipping charge for a delivery.
• Can still have routines for actions (e.g.
  checkout)
• but they quickly delegate to method in Domain
  Model.

78
Hybrid Data Source Patterns

• Active Record RDG Domain Logic.
• Table Module TDG Domain Logic.
• TDG like module that processes ResultSets.

79
Active Record

• Fowler An object that wraps a row in a database
  table or view, encapsulates the database access,
  and holds domain logic on that data.
• An AR object carries both data and behaviour.
• The essence of an AR is a Domain Model in which
  the classes match very closely the record
  structure of the underlying database.

80
Active Record (Row Data Gateway)
PersGradeAR
name String grade int PersGradeAR(name,
g) find(name) // like RDG // Can also have
domain logic getRank()
81
Data Mappers

• Acts as an intermediary between Domain Models and
  the database.
• Allows Domain Models and Data Source classes to
  be independent of each other
• E.g.

82
Data Mapper Example (Tasks)
83
Data Mapper Layer

• Can either
• Access the database itself, or
• Make use of a Table Data Gateway.
• Does not contain Domain Logic.
• When it uses a TDG, the Data Mapper can be placed
  in the (lower) Domain layer.
• E.g.

84
Enterprise Application Patterns (v1.3)
Template View
Page Controller
Presentation
Front Controller
Transform View
Domain Model
Transaction Script
Domain
Data Mapper
Active Record
Table Module
Table Data Gateway
Row Data Gateway
Data Source