SOEN 343Software Design
Section H Fall 2006
Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen343h-f06.html
Responsibilities, Principles, Patterns
RDD (Responsibility Driven Design)
GRASP PrinciplesCohesion, Coupling
Introduction to Patterns and Architecture
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.
The 9 GRASP Principles
1. Creator2. Expert3. Controller4. Low Coupling5. High Cohesion6. Polymorphism7. Pure Fabrication8. Indirection9. Protected Variations
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?
RDD Example: Apply IE
Information Expert: Give task to the object having the information to perform the task.
Example: Larman 17.11 NextGEN POS application
“Who should be responsible for knowing the grand total of a sale?”
Fig. 9.2 NextGEN Domain Model
Register
Item
Store
addressname
Sale
date time
Payment
amount
SalesLineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
0..1
1
Captured-on
conceptor domain object
association
attributes
Fig. 17.14 NextGEN Design
Sale
time
SalesLineItem
quantity
ProductDescription
descriptionpriceitemID
Described-by*
Contains
1..*
1
1
IE Example
Responsibilities
• Sale: knows sale total
• SalesLineItem: knows line item subtotal
• ProductDescription: knows product price
Fig. 17.17 NextGEN DesignSale
time...
getTotal()
SalesLineItem
quantity
getSubtotal()
ProductDescription
descriptionpriceitemID
getPrice()New method
:ProductDescription
1.1: p := getPrice()
1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] :SalesLineItem
RDD Example: Apply Creator
Larman 17.10: NextGEN example
“Who should be responsible for creating a new SalesItem instance?
Exercise!
Design Principles
Design for change
GRASP
General Responsibility Assignment Software Patterns.
• Information Expert• Creator• Low Coupling• High Cohesion• Controller (still to come, from ch17)• Polymorphism• …
Cohesion
• Measure of the degree of “relatedness” that elements within a module share.
• Degree to which the tasks performed by a single module are functionally related.
• Brain storm:– Why put procedures/methods
together within a module/class?
Levels Of Cohesion
Coupling
• Measures the degree of dependency that exists between modules.
• Brain storm:– Give examples of code
that creates coupling.
Coupling
A uses a service/method m of B
A passes on an object o returned from B.m()
A provides visibility of B to C by returning a reference to B in A.getB()
A.m( B b, …)
A calls C.m(B b …) which expects a B object
A class X in A has an attribute of type Y defined in B
Coupling
A.m() changes an attribute in B via B.setX()A.m() changes a (public) attribute in B
directly via assignmentA changes a “flag” in B (ie an attribute which
controls execution decisions in B; ie behaviour of B as seen by others)
A and B both refer to an object o, and A can change o
…
How Do I Come Up With a Design?
• Given– Product requirements.– Project plan
• How do I come up with a design?
Design – Repeat Successes
• Has a (successful) similar product been built?
• Yes, then reuse domain specific:– Architectural
• Style (e.g. client/server, database, process control)• Patterns.
– Design Patterns (& idioms).
• Use Domain model as source of inspiration.
Design – New Application Area?
• Has a (successful) similar product been built?
• No, then choose among general:– Architectural
• Style (e.g. client/server, database, process control)• Patterns.
– Design Patterns (& idioms).
• Use Domain model as source of inspiration.
Common Architectural Styles [FYI]
• Dataflow– Pipes and filters– Batch sequential
• Data-centered– Repository– Blackboard
• Virtual Machine– Interpreter– Rule-based system
• Call and Return– Main program and subroutine
– Object-oriented (& Data abstraction)
– Layered
• Independent Components– Communicating processes
– Client/server
– Event systems• Implicit invocation• Explicit invocation
Layered Architectural Style
Our focus today:
• Architectural style: Layered.
• References– Larman, Chapter 13.– Fowler, EA.
• Briefly, lets review Client-Server
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.
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]
Layered Style Characteristics
• Each layer offers services to layers above.
• Hence, layers build upon each other to provide increased functionality.
Layers: Functionality
PresentationDomain
Data Source
Functionality / services
Layers: Dependencies
PresentationDomain
Data Source
Dependencies
Laye
r D
epen
denc
ies
Exa
mpl
e
Log4J
Technical Services
Domain
Presentation
JessPersistence
POSRuleEngine
Inventory
PaymentsServiceAccess
PricingSales
TextSwing
SOAP
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
Where to Run Your Layers
• [Folwer, pp. 22-24]
Your software application
? ?
Where to Run Your Layers
EA software
Technical Services
EA Layers Refined
PresentationDomain LogicData Source
General Layering Scheme Refined
Presentation
Domain
Technical services
• Presentation• Application
• Domain (logic)• Low-level domain logic
• Technical services• Foundation.
General Layering Scheme Refined
Presentation
Domain
Technical services
• Presentation• Application
• Business services• Low-level business services
• Technical services• Low-level technical services
Layering (Larman)Presentation
(AKA Interface, UI, View)
Application(AKA Workflow, Process,Mediation, App Controller)
Domain(s)(AKA Business,
Business Services, Model)
Technical Services(AKA Technical Infrastructure,High-level Technical Services)
Foundation(AKA Core Services, Base Services,
Low-level Technical Services/Infrastructure)
Business Infrastructure(AKA Low-level Business Services)
GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, ...
handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate
data for presentation
handles application layer requests implementation of domain rules domain services (POS, Inventory)
- services may be used by just oneapplication, but there is also the possibilityof multi-application services
(relatively) high-level technical servicesand frameworks
Persistence, Security
low-level technical services, utilities,and frameworks
data structures, threads, math,file, DB, and network I/O
very general low-level business servicesused in many business domains
CurrencyConverter
•See Larman Sect 13.6