Download - Software Design
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