soen 6011 software engineering processes

SOEN 6011Software Engineering Processes

Section SS Fall 2007

Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

Week 7• Responsibility-Driven Design

• Layer Architecture

• Model-View-Control

• Fowler’s EAA Patterns– Anatomy of a web site– Controller, Command patterns– Front Controller– Data Management patterns– Domain and DataMapper

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.

What is OO Analysis and Design• Object-Oriented

Analysis

– Important domain concepts or objects?

– Vocabulary?

– Visualized in the UP Domain Model

• Object-Oriented Design

– Design of software objects

– Responsibilities– Collaborations

– Design patterns

– Visualized in the UP Design Model

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.

Prerequisites to Successful Evolutionary Design?

• Testing– … lots of automated testing.

• Refactoring– … keeping the design simple.

• Continuous integration

• Actually, testing is a prerequisite to refactoring.

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.

Object Responsibilities

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

General Classification of Kinds of Responsibility

– To know.– To do.– To decide.

Responsibilities – A Boat Metaphor

• What kind of responsibilities do each of the following “objects” have: …– To know.– To do.– To decide.

Responsibilities – A Boat Metaphor

Kind of responsibility for:

• Captain– To know?– To do?– To decide?

Responsibilities – A Boat Metaphor

Kind of responsibility for:

• Navigator.– To know?– To do?– To decide?

Responsibilities – A Boat Metaphor

Kind of responsibility for:

• Compass.– To know?– To do?– To decide?

Important Concepts

Model• Abstraction hiding (unimportant) details• Eg, cover of Larman’s book

GRASP Principle• for assigning responsibility

Design pattern• Solution to design problem in context• Eg, Command pattern

The 9 GRASP Principles

1. Creator2. Expert3. Controller4. Low Coupling5. High Cohesion6. Polymorphism7. Pure Fabrication8. Indirection9. Protected Variations

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?

•Present solutions to common software problems arising within a certain context

Overview of Patterns

•Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs

The Proxy Pattern

1 1Proxy

service

Service

service

AbstractService

service

Client

•Help resolve key software design forces

•Flexibility•Extensibility•Dependability•Predictability•Scalability•Efficiency

•Generally codify expert knowledge of design strategies, constraints & “best practices”

Layered Architectural Style

Our focus today:

• Architectural style: Layered.

• References– Larman, Chapter 13.– Fowler, EA.

• Briefly, lets review Client-Server

Layered Style Characteristics

• Each layer offers services to layers above.

• Hence, layers build upon each other to provide increased functionality.

Layering – Pure Style

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

Not permitted in pure style

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]

Enterprise Application Layers

Calculate taxesAuthorizepayments

Database

Enterprise Application Layers

PresentationDomain LogicData Source

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.

General Layering Scheme Refined

Presentation

Domain

Technical services

• Presentation• Application

• Domain (logic)• Low-level domain logic

• Technical services• Foundation.

Typical Software Architecture Layers

UI(AKA Presentation, View)

Application(AKA Workflow, Process,Mediation, App Controller)

Domain(AKA Business,

Application Logic, Model)

Technical Services(AKA Technical Infrastructure, High-level Technical Services)

Foundation(AKA Core Services, Base Services,

Low-level Technical Services/Infrastructure)

width implies range of applicability

GUI windowsreportsspeech interfaceHTML, XML, XSLT, JSP, Javascript, ...

handles presentation layer requestsworkflowsession statewindow/page transitionsconsolidation/transformation of disparate data for presentation

handles application layer requestsimplementation of domain rulesdomain services (POS, Inventory)- services may be used by just one application, but there is also the possibility of multi-application services

(relatively) high-level technical services and frameworks Persistence, Security

low-level technical services, utilities, and frameworksdata structures, threads, math, file, DB, and network I/O

moreapp

specific

depe

nden

cy

Business Infrastructure(AKA Low-level Business Services)

very general low-level business services used in many business domainsCurrencyConverter

Typical Software Architecture Layers (Simplified)

Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

Laye

r D

epen

denc

ies

Exa

mpl

e

Log4J

Technical Services

Domain

Presentation

JessPersistence

POSRuleEngine

Inventory

PaymentsServiceAccess

PricingSales

TextSwing

SOAP

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]

Logical Architecture – Layers & Partitions

Persistence Security Logging

Technical Services

POS Inventory Tax

Domain

Vertical Layers

Horizontal Partitions

Dom

ain

Data

Sou

rce

Transaction Script Domain Model

Data Mapper

Row Data Gateway

Front Controller

Template View

Transform View

Page Controller

Pres

enta

tion

Active Record

Fowler’s EA Patterns

Table Module

Table Data Gateway

Enterprise Applications Patterns

Assignments (and some lectures) are about building web-based systems for enterprise applications

InvolvePresentation on the webBusiness Logic and Business ObjectsData storage and access

use book of Martin Fowler, “Patterns of Enterprise Application Architecture”

Design Model

: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

Vision Glossary

The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.

Domain Model

**

SupplementarySpecification

Use-Case Model

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductSpec(...)...

1 1class diagrams(a static view)

interaction diagrams(a dynamic view)

UIpackage diagramsof the logical architecture(a static view) Domain

Tech Services

Design Model

Model-View Separation Principle (MVC)

UI layer has viewsDomain layer has model

Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

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

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

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 it’s behaviour.

MVC Model

• The “Model” contains the data

• Has methods to access and possibly update it’s 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.

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

• It’s interaction with the model indirectly causes the View(s) to update

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.

Jacobson’s Objectory Design Objects

Jacobson’s Objectory Design Objects

Robustness model has

• Entity objects

• Boundary (interface objects)

• Control objects

Essentially UML collaboration (communication) diagram

Jacobson’s Robustness Analysis Bridges Analysis-Design Gap

PATTERN: Controller

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

???

Presentation

ApplicationLogic

Video Store

Record Rental

Video ID

...

...

...

... ...

Clerk

rent(videoID)

Now what happens?

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

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.

PATTERN: Controller (Larman 17.13)

Solution: Assign the responsibility to a class representing one of the following choices:

• A façade controller, which represents1. the overall system

2. A root object

3. A device that the software is running within, or

4. A major subsystem

• A use case or session controller which represents a use case scenario in which the system operation occurs

Fig. 17.21

Which class of object should be responsible for receiving this system event message?

It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from the interface layer.

actionPerformed( actionEvent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty)

UI Layer

Domain Layer

system operation message

Dom

ain

Data

Sou

rce

Table Data Gateway

Transaction Script Domain Model

Data MapperRow Data Gateway

Active Record

Front Controller

Template View

Transform View

Page Controller

Pres

enta

tion Data Source Patterns

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 rolesClass …Finder with find(id):Gateway method

which returns the ‘object’

Class …Gateway which is the ‘object’

• Our PersGradeRDG (next slide) combines

Row Data Gateway

PersGradeRDG- name : String

- grade : int

+ PersGradeRDG(name, grade)

+ find(name) : PersGradeRDG

+ insert() : void

+ update() : void

+ delete() : void

+ … getters and setters …

Row Data Gateway: Find Code

Row Data Gateway

• Code sample for Fowler’s PersonRDG

• Note ‘find’ method is static– it is class method

GetByLastName Example

Simple web application toInput a student’s last name

Fetch database record

Output student’s full name

GetByLastName

Will look atRow Data Gateway

PageController

Transaction Script

Row Data Gateway

• StudInfoRDG– Represents record in DB of student

• StudInfoFinder– Finds student record based on lastName– Returns the StudInfoRDG– Locates DB using DBRegistry

Dom

ain

Data

Sou

rce

Table Data Gateway

Transaction Script Domain Model

Data MapperRow Data Gateway

Front Controller

Template View

Transform View

Page Controller

Pres

enta

tion

Active Record

Enterprise Application Patterns

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 for:a use case or business transaction.

Implementation can be– shared among subroutines.– Subroutines can be used by more than one script

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)

GetByLastName

Will look atRow Data Gateway

PageController

Transaction Script

Do-it-all Transaction Script

A TS that does all the work itselfWithout a Finder

Without a RDG

Directly calls DB

Do-it-all Servlet or Script, Class

public class DoItAll extends javax.servlet.http.HttpServlet

{protected void doGet(

HttpServletRequest request,HttpServletResponse response)throws ... //

{…}

}

Do-it-all Transaction Script, doGet()

String lastName = request.getParameter(“…"); Connection dbc = DbRegistry.getDbConnection();String findSql = "SELECT * from … where LastName = ?”;PreparedStatement dbQuery = dbc.prepareStatement(findSql);

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("<h1>Hello "+firstName+" "+lastName+"</h1>");

Dom

ain

Data

Sou

rce

Table Data Gateway

Transaction Script Domain Model

Data MapperRow Data Gateway

Active Record

Front Controller

Template View

Transform View

Page Controller

Pres

enta

tion Controller Patterns

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

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

Page ControllerFowler 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)

Page Controller

GetByLastName

Will look atRow Data Gateway

PageController

Transaction Script

Page ControllerSOEN EA sample:display info about a student

– PageController implements doGet()• Delegates to transaction script

Note:does not follow Fowler’s use of .jspdelegates rather than forwardsno explicit helper object

(really StudInfoRDG is helper)

Dom

ain

Data

Sou

rce

Transaction Script

Active Record

Front Controller

Template ViewPage Controller

Pres

enta

tion

Domain Logic Patterns

Domain Model

Data Mapper

Transform View

Table Data Gateway

Table Module

Row Data Gateway

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

Pure Domain Logic Patterns

• Two main alternatives:– Transaction Script– Domain Model

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.

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.

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.

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.

Hybrid Data Source Patterns

• Active Record = RDG + Domain Logic.

• Table Module ≈ TDG + Domain Logic.– TDG like module that processes ResultSets.

Active RecordFowler: 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.

Active Record (Row Data Gateway)

PersGradeARname : String

grade : int

PersGradeAR(name, g)

find(name)

… // like RDG

// Can also have domain logic

getRank()

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. …

Data Mapper Example (Tasks)

«Domain Model»Task

- id : long- isDone : boolean- title : String

+ Task ( )+ Task ( [in] aTitle : String )+ getId ( ) : long+ getTitle ( ) : String+ isDone ( ) : boolean+ setId ( [in] anId : long ) : void+ setIsDone ( [in] b : boolean ) : void

TaskMapper

- TaskMapper ( )+ find ( [in] id : long ) : Task+ findAll ( ) : List+ insert ( [in] task : Task ) : void+ update ( [in] task : Task ) : void+ delete ( [in] task : Task ) : void

DBMS

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. …

Dom

ain

Data

Sou

rce

Table Data Gateway

Transaction Script Domain Model

Data Mapper

Row Data Gateway

Front Controller

Template View

Transform View

Page Controller

Pres

enta

tion

Active Record

Enterprise Application Patterns (v1.3)

Table Module