Download ppt - SOEN 343 Software Design

Transcript
Page 1: SOEN 343 Software Design

SOEN 343Software Design

Section H Fall 2006

Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

Page 2: SOEN 343 Software Design

Responsibilities, Principles, Patterns

RDD (Responsibility Driven Design)

GRASP PrinciplesCohesion, Coupling

Introduction to Patterns and Architecture

Page 3: SOEN 343 Software Design

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.

Page 4: SOEN 343 Software Design

The 9 GRASP Principles

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

Page 5: SOEN 343 Software Design

Object Responsibilities

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

Page 6: SOEN 343 Software Design

General Classification of Kinds of Responsibility

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

Page 7: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

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

Page 8: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

Kind of responsibility for:

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

Page 9: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

Kind of responsibility for:

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

Page 10: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

Kind of responsibility for:

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

Page 11: SOEN 343 Software Design

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?”

Page 12: SOEN 343 Software Design

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

Page 13: SOEN 343 Software Design

Fig. 17.14 NextGEN Design

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Page 14: SOEN 343 Software Design

IE Example

Responsibilities

• Sale: knows sale total

• SalesLineItem: knows line item subtotal

• ProductDescription: knows product price

Page 15: SOEN 343 Software Design

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

Page 16: SOEN 343 Software Design

RDD Example: Apply Creator

Larman 17.10: NextGEN example

“Who should be responsible for creating a new SalesItem instance?

Exercise!

Page 17: SOEN 343 Software Design

Design Principles

Design for change

Page 18: SOEN 343 Software Design

GRASP

General Responsibility Assignment Software Patterns.

• Information Expert• Creator• Low Coupling• High Cohesion• Controller (still to come, from ch17)• Polymorphism• …

Page 19: SOEN 343 Software Design

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?

Page 20: SOEN 343 Software Design

Levels Of Cohesion

Page 21: SOEN 343 Software Design

Coupling

• Measures the degree of dependency that exists between modules.

• Brain storm:– Give examples of code

that creates coupling.

Page 22: SOEN 343 Software Design

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

Page 23: SOEN 343 Software Design

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

Page 24: SOEN 343 Software Design

How Do I Come Up With a Design?

• Given– Product requirements.– Project plan

• How do I come up with a design?

Page 25: SOEN 343 Software 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.

Page 26: SOEN 343 Software Design

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.

Page 27: SOEN 343 Software Design

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

Page 28: SOEN 343 Software Design

Layered Architectural Style

Our focus today:

• Architectural style: Layered.

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

• Briefly, lets review Client-Server

Page 29: SOEN 343 Software Design

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]

Page 30: SOEN 343 Software Design

Enterprise Application Layers

Calculate taxesAuthorizepayments

Database

Page 31: SOEN 343 Software Design

Enterprise Application Layers

PresentationDomain LogicData Source

Page 32: SOEN 343 Software Design

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.

Page 33: SOEN 343 Software Design

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]

Page 34: SOEN 343 Software Design

Layered Style Characteristics

• Each layer offers services to layers above.

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

Page 35: SOEN 343 Software Design

Layers: Functionality

PresentationDomain

Data Source

Functionality / services

Page 36: SOEN 343 Software Design

Layers: Dependencies

PresentationDomain

Data Source

Dependencies

Page 37: SOEN 343 Software Design

Laye

r D

epen

denc

ies

Exa

mpl

e

Log4J

Technical Services

Domain

Presentation

JessPersistence

POSRuleEngine

Inventory

PaymentsServiceAccess

PricingSales

TextSwing

SOAP

Page 38: SOEN 343 Software Design

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

Page 39: SOEN 343 Software Design

Where to Run Your Layers

• [Folwer, pp. 22-24]

Your software application

? ?

Page 40: SOEN 343 Software Design

Where to Run Your Layers

EA software

Technical Services

Page 41: SOEN 343 Software Design

EA Layers Refined

PresentationDomain LogicData Source

Page 42: SOEN 343 Software Design

General Layering Scheme Refined

Presentation

Domain

Technical services

• Presentation• Application

• Domain (logic)• Low-level domain logic

• Technical services• Foundation.

Page 43: SOEN 343 Software Design

General Layering Scheme Refined

Presentation

Domain

Technical services

• Presentation• Application

• Business services• Low-level business services

• Technical services• Low-level technical services

Page 44: SOEN 343 Software Design

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


Recommended