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

• Architecture 41 Views
• Examples, Larman ch 39
• GRASP Principles
• Polymorphism
• Protected Variations
• EA Domain Logic patterns
• EA Data Source patterns

3
Architecture

• deals with the top-level structure.
• Components
• Interrelationships

4
Documentation of Architectures

• Architecture Document
• View A
• View B
• View C
• View X
• Beyond Views

5
41 View Model of Arch.

• By Philippe Kruchten Kruchten95
• Rational Unified Process.

6
41 View Model of Arch.
Implementation/
Deployment/
7
41 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/
8
41 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/
9
Logical View Fig. 39.1
10
Deployment View Fig. 39.2
11
Process View Fig. 39.3
12
Process View Fig. 39.4
13
GRASP

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

• Polymorphism.
• Pure Fabrication.
• Indirection.
• Protected Variations.

14
GRASP Polymorphism Principle (done)

• Larman
• When related alternatives or behaviors vary be
  type (class), assign responsibility for the
  behaviorusing polymorphic operationsto the
  types for which the behavior varies.

15
GRASP Protected Variations

• ProblemHow to design objects, subsystems, and
  systems so that the variations or instability in
  these elements does not have an undesireable
  impact on other elements?
• SolutionIdentify points of predicted variation
  or instability assign responsibility to create a
  stable interface around them.

16
Core PV Mechanisms

• Encapsulation.
• Interfaces.
• Polymorphism.
• Indirection,
• (Note we are speaking of mechanisms, not
  principles)

17
PV Pick Your Battles

• Beware not to try to overly future-proof your
  designs.
• Actually, this is true of any principle

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

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

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

23
Organizing the Domain Logic

• Key architectural decisions, whichinfluence
  structure of other layers.
• Pure, hybrid patterns.

24
Pure Domain Logic Patterns

• Two main alternatives
• Transaction Script
• Domain Model

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

26
Choosing a Domain Logic Pattern

• Which one to choose?
• Influenced by the complexity of domain logic.

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

28
TS ? DM, Easy of Refactoring?

• Easier to refactor TS ? DM than DM ? TS.

29
Transaction Script (done)
30
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.

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

32
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 Fowlers PEAA)

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

34
E.g. RR for SS Conceptual Model
35
E.g. TS Calculating Revenue Recognitions
36
E.g. Domain Model Calculating Revenue
Recognitions
37
E.g. Enhancement e.g. New Revenue Recognition
Strategy

• Transaction Script
• New conditional, or
• New subroutine.
• Domain Model
• Create new Rev. Recog. Strategy class.

38
Data Source 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
39
Data Source Patterns

• Pure patterns.
• Hybrid patterns.

40
Pure Data Source Patterns

• Gateways (previously covered)
• Row Data Gateway (RDG)
• Table Data Gateway (TDG)
• Data Mapper
• To be explained in a few slides.

41
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

42
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

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

44
Table Data Gateway
PersGradeTDG
- PersGradeTDG() find(name) ResultSet
findInRange(fg,tg) ResultSet
insert(name,grade) void update(name,grade)
void delete(name) void
45
Hybrid Data Source Patterns

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

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

47
Active Record (Row Data Gateway)
PersGradeAR
name String grade int PersGradeAR(name,
g) find(name) // like RDG // Can also have
domain logic getRank()
48
Table Module

• Similar to Active Record
• Table Module TDG plus domain logic

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

50
Data Mapper Example (Tasks)
51
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.

52
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
53
Recall the Greeting EA

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

54
Review Question

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

55
Evaluating a Design

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

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

57
Greeting EA Evolution What if

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

58
Comparing Design Solutions
Property Soln 1 Soln 2 Soln 3
Correct ? ? ?
Intent clear
Simplest
Acc. Change
Cohesion
Coupling