Transcript soen343-week9

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
Architecture
• … deals with the top-level structure.
– Components
– Interrelationships
Documentation of Architectures
• Architecture Document =
View A +
View B +
View C + …
View X +
“Beyond Views”
“4+1” View Model of Arch.
• By Philippe Kruchten [Kruchten95]
• Rational Unified Process.
“4+1” View Model of Arch.
Implementation/
Deployment/
“4+1” View Model of Arch.
•
Logical View
– The object model of the system
Implementation/
•
Process View
– The behavioural model of the system
•
•
Implementation View
Deployment/
– The software components, libraries,
packages, etc
Deployment View
– How software maps to hardware
“4+1” View Model of Arch.
• Use Case View
Implementation/
– The scenarios of the system
– Ties everything together
• Allows tracing of other views for verification
Deployment/
– Note that scenarios can cover non-functional
requirements too
Logical View
Fig. 39.1
UI
Swing
ProcessSale
Frame
Domain
Sales
Register
Pricing
Sale
ServiceAccess
Payments
Services
Factory
CreditPayment
POSRuleEngine
Inventory
«interface»
IInventoryAdapter
Taxes
«interface»
ITaxCalculatorAdapter
POSRuleEngineFacade
Technical Services
Persistence
Log4J
DBFacade
Jess
«interface»
ICreditAuthorization
ServiceAdapter
SOAP
Deployment View
«server»
: Dell PowerEdge 3600
{ OS=Red Hat Enterprise Linux 4 }
«server»
: GenericServer
«system»
CreditPayment
Authorizer
«database»
: PostgreSQL 10
«artifact»
Product Tables
SQL over TCP
«terminal»
: POSTerminal
{ JVM = Sun Hotspot Client 2.0 }
ol
oc
rot P
p
C
A
VIS ver T
o
custom protocols
on top of TCP
«artifact»
NextGenClient.jar
«server»
: Dell PowerEdge 3600
{ OS=Red Hat Enterprise Linux 4 }
«artifact»
GoodAsGoldTaxCalculator.exe
SOAP over HTTP
«server»
: GenericServer
«ERP»
: SAP
Fig. 39.2
inventory
and
accounting
Process View
Data Flow Scenario for
Process Sale Use Case
«datastore»
Products
NextGen POS
Fig. 39.3
Tax Calculator
Payment
Authorization
Enter Items
Sale
Calc Taxes
Request Payment
Authorization
Request
«datastore»
Inventory
Reply
Update ERP
«datastore»
Accounting
Authorize
Payment
Process View
Fig. 39.4
1
: UI::
Swing::
Process
SaleJFrame
: Domain::
Sales::
Register
: Domain::
Products::
Product
Catalog
s:
Domain::
Sales::
Sale
:Cashier
enterItem
(id, qty)
enterItem
(id, qty)
: Domain::
POSRuleEngine::
POSRuleEngine
Facade
1
: TechServices::
Persistence::
PersistenceFacade
«subsystem»
: TechServices
::Jess
desc =
getProduct
Desc(id)
desc = getObject(...,id)
makeLineItem(desc, qty)
x = isInvalid
(lineItem, sale)
onPropertyEvent(s, "sale.total", total)
someJessCalls(lineItem, sale)
GRASP
•
•
•
•
•
Information Expert.
Creator.
High Cohesion.
Low Coupling.
Controller.
•
•
•
•
Polymorphism.
Pure Fabrication.
Indirection.
Protected
Variations.
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
• 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
•
•
•
•
Encapsulation.
Interfaces.
Polymorphism.
Indirection, …
(Note: we are speaking of mechanisms,
not principles)
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
• Consider a single
servlet which offers
the greeting “Hello”.
• Refactor it with the
goal of applying PV
and separate
concerns.
GreetingServlet
#doGet(in req, in resp)
Applying PV to Web EA
•
Greeting example with successively
refined design solutions:
1. Start from design of 1 servlet class whose
purpose is to offer a greeting.
2. 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?
3. Separate V and C by using JSP for V.
Data Source Domain Presentation
EA Patterns
Page Controller
Template View
Front Controller
Transform View
Transaction Script
Active Record
Domain Model
Table Module
Data Mapper
Row Data Gateway
Table Data Gateway
Data Source Domain
Presentation
Domain Logic Patterns
Transaction Script
Table Module
Active Record
Table Data Gateway
Row Data Gateway
Page Controller
Template View
Front Controller
Transform View
Domain Model
Data Mapper
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
• Key architectural decisions, which
influence structure of other layers.
• Pure, hybrid patterns.
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 a Domain Logic
Pattern
• Which one to choose?
– Influenced by the complexity of domain logic.
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?
• Easier to refactor
TS  DM
than
DM  TS.
Transaction Script (done)
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.
[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
• Company named SimpleSoft
• Sells S/W:
– Word processor,
– Database,
– Spreadsheet.
• Contract: covers only one product.
• Revenue recognition varies per product.
[E.g.] RR for SS: Conceptual
Model
[E.g.] TS: Calculating Revenue
Recognitions
[E.g.] Domain Model:
Calculating Revenue
Recognitions
[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 Domain
Presentation
Data Source Patterns
Transaction Script
Table Module
Active Record
Table Data Gateway
Row Data Gateway
Page Controller
Template View
Front Controller
Transform View
Domain Model
Data Mapper
Data Source Patterns
• Pure patterns.
• Hybrid 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)
• 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 (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
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 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
• Active Record = RDG + Domain Logic.
• Table Module ≈ TDG + Domain Logic.
– TDG like module that processes ResultSets.
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)
PersGradeAR
name : String
grade : int
PersGradeAR(name, g)
find(name)
… // like RDG
// Can also have domain logic
getRank()
Table Module
• Similar to Active Record
• Table Module = TDG plus domain logic
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. …
Domain Presentation
Data Source
Enterprise Application Patterns (v1.3)
Page Controller
Template View
Front Controller
Transform View
Domain Model
Transaction Script
Data Mapper
Active Record
Table Module
Row Data Gateway
Table Data Gateway
Recall the Greeting EA
• A single servlet which
offers the greeting
“Hello”.
• We refactored it,
offering two
alternative designs.
GreetingServlet
#doGet(in req, in resp)
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
• Which is a better 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 …
• Support a personalized greeting.
• Change “look” of output (e.g. bold the
name).
• Get full name from db.
Comparing Design Solutions
Property
Sol’n 1
Sol’n 2
Sol’n 3
Correct



Intent clear
Simplest
Acc.
Change
Cohesion
Coupling