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

SOEN 343 Software Design PowerPoint PPT Presentation


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


General classification of kinds of responsibility

General Classification of Kinds of Responsibility

  • To know.

  • To do.

  • To decide.


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


Fig 9 2 nextgen domain model

Fig. 9.2 NextGEN Domain Model


Fig 17 14 nextgen design

Fig. 17.14 NextGEN Design


Ie example

IE Example

Responsibilities

  • Sale: knows sale total

  • SalesLineItem: knows line item subtotal

  • ProductDescription: knows product price


Fig 17 17 nextgen design

Fig. 17.17 NextGEN Design


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?


Levels of cohesion

Levels Of Cohesion


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 layers

Enterprise Application Layers


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


Layer dependencies example

Layer Dependencies Example


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


  • Login