Soen 343 software design
Download
1 / 44

SOEN 343 Software Design - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

SOEN 343 Software Design. Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html. Responsibilities, Principles, Patterns. RDD (Responsibility Driven Design) GRASP Principles Cohesion, Coupling Introduction to Patterns and Architecture.

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

PowerPoint Slideshow about ' SOEN 343 Software Design' - presley


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


Responsibilities principles patterns
Responsibilities, Principles, Patterns

RDD (Responsibility Driven Design)

GRASP Principles

Cohesion, Coupling

Introduction to Patterns and Architecture


Responsibility driven design rdd
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
The 9 GRASP Principles

  • Creator

  • Expert

  • Controller

  • Low Coupling

  • High Cohesion

  • Polymorphism

  • Pure Fabrication

  • Indirection

  • Protected Variations


Object responsibilities
Object Responsibilities

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



Responsibilities a boat metaphor
Responsibilities – A Boat Metaphor

  • What kind of responsibilities do each of the following “objects” have: …

    • To know.

    • To do.

    • To decide.


Responsibilities a boat metaphor1
Responsibilities – A Boat Metaphor

Kind of responsibility for:

  • Captain

    • To know?

    • To do?

    • To decide?


Responsibilities a boat metaphor2
Responsibilities – A Boat Metaphor

Kind of responsibility for:

  • Navigator.

    • To know?

    • To do?

    • To decide?


Responsibilities a boat metaphor3
Responsibilities – A Boat Metaphor

Kind of responsibility for:

  • Compass.

    • To know?

    • To do?

    • To decide?


Rdd example apply ie
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?”




Ie example
IE Example

Responsibilities

  • Sale: knows sale total

  • SalesLineItem: knows line item subtotal

  • ProductDescription: knows product price



Rdd example apply creator
RDD Example: Apply Creator

Larman 17.10: NextGEN example

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

Exercise!


Design principles
Design Principles

Design for change


Grasp
GRASP

General Responsibility Assignment Software Patterns.

  • Information Expert

  • Creator

  • Low Coupling

  • High Cohesion

  • Controller (still to come, from ch17)

  • Polymorphism


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



Coupling
Coupling

  • Measures the degree of dependency that exists between modules.

  • Brain storm:

    • Give examples of code that creates coupling.


Coupling1
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


Coupling2
Coupling

A.m() changes an attribute in B via B.setX()

A.m() changes a (public) attribute in B directly via assignment

A 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
How Do I Come Up With a Design?

  • Given

    • Product requirements.

    • Project plan

  • How do I come up with a design?


Design repeat successes
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
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

Common Architectural Styles [FYI]


Layered architectural style
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
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 layers1
Enterprise Application Layers

Presentation

Domain Logic

Data Source


Layering general scheme
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
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
Layered Style Characteristics

  • Each layer offers services to layers above.

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


Layers functionality
Layers: Functionality

Presentation

Domain

Functionality / services

Data Source


Layers dependencies
Layers: Dependencies

Presentation

Domain

Dependencies

Data Source



Layering pure style

Not permitted in pure style

Layering – Pure Style

  • Pure style: components are permitted to use services of other components in

    • same layer.

    • layer immediately below.


Where to run your layers
Where to Run Your Layers

  • [Folwer, pp. 22-24]

Your software application

?

?


Where to run your layers1
Where to Run Your Layers

EA software

Technical Services


Ea layers refined
EA Layers Refined

Presentation

Domain Logic

Data Source


General layering scheme refined

Presentation

Domain

Technical services

Presentation

Application

Domain (logic)

Low-level domain logic

Technical services

Foundation.

General Layering Scheme Refined


General layering scheme refined1

Presentation

Domain

Technical services

Presentation

Application

Business services

Low-level business services

Technical services

Low-level technical services

General Layering Scheme Refined


Layering larman
Layering (Larman)

  • See Larman Sect 13.6


ad