soen 343 software design n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SOEN 343 Software Design PowerPoint Presentation
Download Presentation
SOEN 343 Software Design

Loading in 2 Seconds...

play fullscreen
1 / 58

SOEN 343 Software Design - PowerPoint PPT Presentation


  • 77 Views
  • Uploaded on

SOEN 343 Software Design. Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html. Outline. Architecture 4+1 Views Examples, Larman ch 39 GRASP Principles Polymorphism Protected Variations EA Domain Logic patterns EA Data Source patterns.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

SOEN 343 Software Design


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
soen 343 software design

SOEN 343Software Design

Section H Fall 2006

Dr Greg Butler

http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

outline
Outline
  • Architecture 4+1 Views
    • Examples, Larman ch 39
  • GRASP Principles
    • Polymorphism
    • Protected Variations
  • EA Domain Logic patterns
  • EA Data Source patterns
architecture
Architecture
  • … deals with the top-level structure.
    • Components
    • Interrelationships
documentation of architectures
Documentation of Architectures
  • Architecture Document =

View A +

View B +

View C + …

View X +

“Beyond Views”

4 1 view model of arch
“4+1” View Model of Arch.
  • By Philippe Kruchten [Kruchten95]
  • Rational Unified Process.
4 1 view model of arch1
“4+1” View Model of Arch.

Implementation/

Deployment/

4 1 view model of arch2
“4+1” View Model of Arch.
  • Logical View
    • The object model of the system
  • Process View
    • The behavioural model of the system
  • Implementation View
    • The software components, libraries, packages, etc
  • Deployment View
    • How software maps to hardware

Implementation/

Deployment/

4 1 view model of arch3
“4+1” View Model of Arch.
  • Use Case View
    • The scenarios of the system
    • Ties everything together
      • Allows tracing of other views for verification
    • Note that scenarios can cover non-functional requirements too

Implementation/

Deployment/

grasp
Information Expert.

Creator.

High Cohesion.

Low Coupling.

Controller.

Polymorphism.

Pure Fabrication.

Indirection.

Protected Variations.

GRASP
grasp polymorphism principle done
GRASP: Polymorphism Principle (done)

Larman:

  • When related alternatives or behaviors vary be type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies.
grasp protected variations
GRASP Protected Variations
  • Problem:How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesireable impact on other elements?
  • Solution:Identify points of predicted variation or instability; assign responsibility to create a stable interface around them.
core pv mechanisms
Core PV Mechanisms
  • Encapsulation.
  • Interfaces.
  • Polymorphism.
  • Indirection, …

(Note: we are speaking of mechanisms, not principles)

pv pick your battles
PV: Pick Your Battles
  • Beware not to try to overly “future-proof” your designs.
  • Actually, this is true of any principle …
applying pv to web ea
Applying PV to Web EA
  • Consider a single servlet which offers the greeting “Hello”.
  • Refactor it with the goal of applying PV and separate concerns.
applying pv to web ea1
Applying PV to Web EA
  • Greeting example with successively refined design solutions:
    • Start from design of 1 servlet class whose purpose is to offer a greeting.
    • Factor out domain logic to create design with:
      • Servlet in Application layer.
      • A class in Domain Logic layer to be responsible for domain logic.
      • How are the responsibilities of MVC distributed now?
    • Separate V and C by using JSP for V.
ea patterns
EA Patterns

Page Controller

Template View

Presentation

Front Controller

Transform View

Domain Model

Transaction Script

Domain

Table Module

Active Record

Data Mapper

Table Data Gateway

Row Data Gateway

Data Source

domain logic patterns
Domain Logic Patterns

Presentation

Page Controller

Template View

Front Controller

Transform View

Transaction Script

Domain Model

Domain

Active Record

Table Module

Table Data Gateway

Data Mapper

Row Data Gateway

Data Source

domain logic layer
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
organizing the domain logic
Organizing the Domain Logic
  • Key architectural decisions, whichinfluence structure of other layers.
  • Pure, hybrid patterns.
pure domain logic patterns
Pure Domain Logic Patterns
  • Two main alternatives:
    • Transaction Script
    • Domain Model
hybrid domain logic
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 a domain logic pattern
Choosing a Domain Logic Pattern
  • Which one to choose?
    • Influenced by the complexity of domain logic.
choosing between ts dm
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.
ts dm easy of refactoring
TS  DM, Easy of Refactoring?
  • Easier to refactor TS  DM than DM  TS.
domain model ea pattern
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 pattern1
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.
example revenue recognition rr
[Example] Revenue Recognition (RR)
  • Revenue recognition is a common problem in business systems.
    • when you can actually count the money you receive on your books.
  • E.g. selling a S/W package $120 today
    • Book $40 today,
    • $40 in 30 days,
    • $40 in 60 days.
  • (Taken from Fowler’s PEAA)
e g rr for simplesoft
[E.g.] RR for SimpleSoft
  • Company named SimpleSoft
  • Sells S/W:
    • Word processor,
    • Database,
    • Spreadsheet.
  • Contract: covers only one product.
  • Revenue recognition varies per product.
e g enhancement e g new revenue recognition strategy
[E.g.] Enhancement: e.g. New Revenue Recognition Strategy
  • Transaction Script:
    • New conditional, or
    • New subroutine.
  • Domain Model:
    • Create new Rev. Recog. Strategy class.
data source patterns
Data Source Patterns

Presentation

Page Controller

Template View

Front Controller

Transform View

Transaction Script

Domain Model

Domain

Active Record

Table Module

Table Data Gateway

Data Mapper

Row Data Gateway

Data Source

data source patterns1
Data Source Patterns
  • Pure patterns.
  • Hybrid patterns.
pure data source patterns
Pure Data Source Patterns
  • Gateways (previously covered)
    • Row Data Gateway (RDG)
    • Table Data Gateway (TDG)
  • Data Mapper
    • To be explained in a few slides.
row data gateway done
Row Data Gateway (done)
  • 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 combines
row data gateway done1
Row Data Gateway (done)
  • StudInfoRDG
    • Represents record in DB of student
  • StudInfoFinder
    • Finds student record based on lastName
    • Returns the StudInfoRDG
    • Locates DB using DBRegistry
table data gateway
Table Data Gateway

Fowler: An object that acts as a gateway to a database table. One instance handles all the rows in the table.

A TDG hides all the SQL for accessing a single DB table or DB view: selects, updates, deletes.

table data gateway1
Table Data Gateway

PersGradeTDG

- PersGradeTDG()

+ find(name) : ResultSet

+ findInRange(fg,tg) : ResultSet

+ insert(name,grade) : void

+ update(name,grade) : void

+ delete(name) : void

hybrid data source patterns
Hybrid Data Source Patterns
  • Active Record = RDG + Domain Logic.
  • Table Module ≈ TDG + Domain Logic.
    • TDG like module that processes ResultSets.
active record
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.

active record row data gateway
Active Record (Row Data Gateway)

PersGradeAR

name : String

grade : int

PersGradeAR(name, g)

find(name)

… // like RDG

// Can also have domain logic

getRank()

table module
Table Module
  • Similar to Active Record
  • Table Module = TDG plus domain logic
data mappers
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 layer
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. …
enterprise application patterns v1 3
Enterprise Application Patterns (v1.3)

Page Controller

Template View

Presentation

Front Controller

Transform View

Domain Model

Transaction Script

Domain

Data Mapper

Table Module

Active Record

Row Data Gateway

Table Data Gateway

Data Source

recall the greeting ea
Recall the Greeting EA
  • A single servlet which offers the greeting “Hello”.
  • We refactored it, offering two alternative designs.
review question
Review Question
  • On a blank sheet of paper …
  • Provide three class diagrams corresponding to the three design solutions of the Greeting EA.
evaluating a design
Evaluating a Design
  • Which is a better design?
  • What is a good design?
what is a good design
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.
greeting ea evolution what if
Greeting EA Evolution … What if …
  • Support a personalized greeting.
  • Change “look” of output (e.g. bold the name).
  • Get full name from db.