1. SOFTWARE DESIGN
Present by : Bui, Ninh L.

2. OVERVIEW
 Design principles
 Design methods
2

3. DESIGN PRINCIPLES
3
 Abstraction
 Modularity, coupling and cohesion
 Information hiding
 Limit complexity
 Hierarchical structure

4. ABSTRACTION
 procedural abstraction: natural consequence of
stepwise refinement: name of procedure denotes
sequence of actions
4
abstraction subproblems
time

5. ABSTRACTION
 data abstraction: aimed at finding a hierarchy in
the data
5
application-oriented
data structures
simpler data
structuregeneral
data structures

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

7. 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
ok
high and best

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

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

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

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

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

13. 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
manager
Employees
display()
credit()
Clothing
customer_gender
size_range
exchange()
Appliances
Category
delivery()
service()
parts_ordering()
DIT (Appliances) =2
DIT(StoreDepartments)=1
DIT(Department)=0

14. 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) = 1
NOC(StoreDepartments)= 2
NOC(Appliances)= 0
Division
StoreDepartments
manager
Employees
display()
credit()
Clothing
customer_gender
size_range
exchange()
Appliances
Category
delivery()
service()
parts_ordering()

15. OVERVIEW
 Design principles
 Design methods
15

16. DESIGN METHODS
 Functional decomposition
 Data Flow Design (SA/SD)
 Design based on Data Structures (JSP)
 Ojbject-Oriented method
16

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

18. FUNCTIONAL DECOMPOSITION
18
bottom-up top-down

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

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

21. ENTITIES IN A DATA FLOW
DIAGRAM
 external entities
 processes
 data flows
 data stores
21

22. DESIGN BASED ON DATA
STRUCTURES
(JSP )
 JSP = Jackson Structured Programming (for
programming-in-the-small)
22

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

24. COMPOUND COMPONENTS IN JSP
24
A
B C D
sequence
B
A
*
iteration
B C D
A
o o o
selection

25. 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. 26
OOAD METHODS
 three major steps:
1 identify the objects
2 determine their attributes and services
3 determine the relationships between objects

27. 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. 28
CANDIDATE OBJECTS
 software
 library
 system
 station
 customer
 transaction
 book
 library employee
 identification card
 client
 bar code reader
 book’s code

29. 29
RELATIONSHIPS
 From the problem statement:
 employee operates station
 station has bar code reader
 bar code reader reads book copy
 bar code reader reads identification card
 Tacit knowledge:
 library owns computer
 library owns stations
 computer communicates with station
 library employs employee
 client is member of library
 client has identification card

30. RESULT: INITIAL CLASS DIAGRAM
30

31. USAGE SCENARIO ⇒ SEQUENCE
DIAGRAM
31

32. CAVEATS WHEN CHOOSING A
PARTICULAR DESIGN METHOD
 Familiarity with the problem domain
 Designer’s experience
 Available tools
 Development philosophy
32

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

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

35. THANK YOU!
35