SOFTWARE DESIGN

Present by : Bui, Ninh L.

OVERVIEW

Design principles

Design methods

2

DESIGN PRINCIPLES

3

Abstraction

Modularity, coupling and cohesion

Information hiding

Limit complexity

Hierarchical structure

ABSTRACTION

procedural abstraction: natural consequence of stepwise refinement: name of procedure denotes sequence of actions

4

abstraction subproblems

time

ABSTRACTION

data abstraction: aimed at finding a hierarchy in the data

5

application-orienteddata structures

simpler datastructuregeneral

data structures

MODULARITY

structural criteria which tell us something about individual modules and their interconnections

cohesion and coupling

cohesion: the glue that keeps a module together

coupling: the strength of the connection between modules 6

TYPES OF COHESION

7

coincidental cohesion

logical cohesion temporal cohesion communicational cohesion procedural cohesion sequential cohesion functional cohesion

lowest and worst by far

still not bad at all still not bad at all not bad at all still ok okhigh and best

EXAMPLE FOR COHESION

Staff

Checkemail()

Sendemail()

Emailvalidate()

Printletter()

8

Staff

Salary

Emailaddr

Setsalary(newsalary)

Getsalary()

Setemailaddr(newemail)

Getemailaddr()

Example of Low Cohesion:Example of high Cohesion:

Cohesion refers to what the class (or module) will do. Low cohesion would mean that the class does a great variety of actions and is not focused on what it should do. High cohesion would then mean that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class.

TYPES OF COUPLING

9

Data coupling

Stamp coupling

Control coupling

External coupling

Common coupling

Content coupling

loose and best

still very good

ok

ok

very bad

tight and worst

INFORMATION HIDING

10

each module has a secret design involves a series of decision: for each

such decision, wonder who needs to know and who can be kept in the dark

information hiding is strongly related to abstraction: if you hide something, the user may

abstract from that fact coupling: the secret decreases coupling between a

module and its environment cohesion: the secret is what binds the parts of the

module together

COMPLEXITY

measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …)

use these numbers as a criterion to assess a design, or to guide the design

interpretation: higher value higher complexity more effort required (= worse design)

two kinds: intra-modular: inside one module inter-modular: between modules

11

OBJECT-ORIENTED METRICS

12

WMC: Weighted Methods per Class

DIT: Depth of Inheritance Tree

NOC: Number Of Children

CBO: Coupling Between Object Classes

RFC: Response For a Class

LCOM: Lack of Cohesion of a Method

DEPTH OF CLASS IN INHERITANCE TREE

DIT = distance of class to root of its inheritance tree DIT is somewhat language-dependent widely accepted heuristic: strive for a forest of classes, a

collection of inheritance trees of medium height

13

Department

StoreDepartments

managerEmployees

display()credit()

Clothing

customer_gendersize_range

exchange()

Appliances

Category

delivery()service()parts_ordering()

DIT (Appliances) =2 DIT(StoreDepartments)=1DIT(Department)=0

NUMBER OF CHILDREN

14

NOC: counts immediate descendants higher values NOC are considered bad:

possibly improper abstraction of the parent class

also suggests that class is to be used in a variety of settings

NOC(Division) = 1NOC(StoreDepartments)= 2NOC(Appliances)= 0

Division

StoreDepartments

managerEmployees

display()credit()

Clothing

customer_gendersize_range

exchange()

Appliances

Category

delivery()service()parts_ordering()

OVERVIEW

Design principles

Design methods

15

DESIGN METHODS

Functional decomposition

Data Flow Design (SA/SD)

Design based on Data Structures (JSP)

Ojbject-Oriented method

16

SAMPLE OF DESIGN METHODS

17

Decision tables E-R Flowcharts FSM JSD JSP LCP Meta IV NoteCards OBJ

OOD PDL Petri Nets SA/SD SA/WM SADT SSADM Statecharts

FUNCTIONAL DECOMPOSITION

18

bottom-up top-down

FUNCTIONAL DECOMPOSITION (CNT’D)

Extremes: bottom-up and top-down Not used as such; design is not purely

rational: clients do not know what they want changes influence earlier decisions people make errors projects do not start from scratch

Rather, design has a yo-yo character We can only fake a rational design process

19

DATA FLOW DESIGN

Yourdon and Constantine (early 70s)

nowadays version: two-step process: Structured Analysis (SA), resulting in a logical

design, drawn as a set of data flow diagrams Structured Design (SD) transforming the logical

design into a program structure drawn as a set of structure charts

20

ENTITIES IN A DATA FLOW DIAGRAM

external entities

processes

data flows

data stores

21

DESIGN BASED ON DATA STRUCTURES(JSP )

JSP = Jackson Structured Programming (for programming-in-the-small)

22

JSP

basic idea: good program reflects structure of its input and output

program can be derived almost mechanically from a description of the input and output

input and output are depicted in a structure diagram and/or in structured text/schematic logic (a kind of pseudocode)

three basic compound forms: sequence, iteration, and selection)

23

COMPOUND COMPONENTS IN JSP

24

A

B C D

sequence

B

A

*

iteration

B C D

A

o o o

selection

DIFFERENCE BETWEEN JSP AND OTHER METHODS

Functional decomposition, data flow design: Problem structure functional structure program structure

JSP: Problem structure data structure program structure

25

26

OOAD METHODS

three major steps:

1 identify the objects

2 determine their attributes and services

3 determine the relationships between objects

27

(PART OF) PROBLEM STATEMENT

Design the software to support the operation of

a public library. The system has a number of

stations for customer transactions. These

stations are operated by library employees.

When a book is borrowed, the identification card

of the client is read. Next, the station’s bar code

reader reads the book’s code. When a book is

returned, the identification card isnot needed

and only the book’s code needs to be read.

28

CANDIDATE OBJECTS software library system station customer transaction book library employee identification card client bar code reader book’s code

29

RELATIONSHIPS

From the problem statement:employee operates stationstation has bar code readerbar code reader reads book copybar code reader reads identification card

Tacit knowledge: library owns computer library owns stationscomputer communicates with station library employs employeeclient is member of libraryclient has identification card

RESULT: INITIAL CLASS DIAGRAM

30

USAGE SCENARIO SEQUENCE DIAGRAM

31

CAVEATS WHEN CHOOSING A PARTICULAR DESIGN METHOD

Familiarity with the problem domain

Designer’s experience

Available tools

Development philosophy

32

DESIGN PATTERN

33

Provides solution to a recurring problem Balances set of opposing forces Documents well-prove design experience Abstraction above the level of a single component Provides common vocabulary and understanding Are a means of documentation Supports construction of software with defined

properties

EXAMPLE DESIGN PATTERN: PROXY

Context: Client needs services from other component,

direct access may not be the best approach Problem:

We do not want hard-code access Solution:

Communication via a representative, the Proxy

34

THANK YOU!

35