Soen 343 software design
Sponsored Links
This presentation is the property of its rightful owner.
1 / 44

SOEN 343 Software Design PowerPoint PPT Presentation


  • 96 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

SOEN 343 Software Design

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 343Software 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


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

  • Creator

  • Expert

  • Controller

  • Low Coupling

  • High Cohesion

  • Polymorphism

  • Pure Fabrication

  • Indirection

  • 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


Fig. 17.14 NextGEN Design


IE Example

Responsibilities

  • Sale: knows sale total

  • SalesLineItem: knows line item subtotal

  • ProductDescription: knows product price


Fig. 17.17 NextGEN Design


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

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


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

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


Enterprise Application Layers

Presentation

Domain Logic

Data 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

Presentation

Domain

Functionality / services

Data Source


Layers: Dependencies

Presentation

Domain

Dependencies

Data Source


Layer Dependencies Example


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

  • [Folwer, pp. 22-24]

Your software application

?

?


Where to Run Your Layers

EA software

Technical Services


EA Layers Refined

Presentation

Domain Logic

Data Source


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

General Layering Scheme Refined


Layering (Larman)

  • See Larman Sect 13.6


  • Login