software design
DESCRIPTION
TRANSCRIPT
![Page 1: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/1.jpg)
SOFTWARE DESIGN
Present by : Bui, Ninh L.
![Page 2: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/2.jpg)
OVERVIEW
Design principles
Design methods
2
![Page 3: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/3.jpg)
DESIGN PRINCIPLES
3
Abstraction
Modularity, coupling and cohesion
Information hiding
Limit complexity
Hierarchical structure
![Page 4: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/4.jpg)
ABSTRACTION
procedural abstraction: natural consequence of stepwise refinement: name of procedure denotes sequence of actions
4
abstraction subproblems
time
![Page 5: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/5.jpg)
ABSTRACTION
data abstraction: aimed at finding a hierarchy in the data
5
application-orienteddata structures
simpler datastructuregeneral
data structures
![Page 6: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/6.jpg)
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
![Page 7: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/7.jpg)
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
![Page 8: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/8.jpg)
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.
![Page 9: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/9.jpg)
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
![Page 10: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/10.jpg)
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
![Page 11: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/11.jpg)
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
![Page 12: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/12.jpg)
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
![Page 13: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/13.jpg)
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
![Page 14: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/14.jpg)
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()
![Page 15: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/15.jpg)
OVERVIEW
Design principles
Design methods
15
![Page 16: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/16.jpg)
DESIGN METHODS
Functional decomposition
Data Flow Design (SA/SD)
Design based on Data Structures (JSP)
Ojbject-Oriented method
16
![Page 17: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/17.jpg)
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
![Page 18: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/18.jpg)
FUNCTIONAL DECOMPOSITION
18
bottom-up top-down
![Page 19: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/19.jpg)
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
![Page 20: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/20.jpg)
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
![Page 21: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/21.jpg)
ENTITIES IN A DATA FLOW DIAGRAM
external entities
processes
data flows
data stores
21
![Page 22: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/22.jpg)
DESIGN BASED ON DATA STRUCTURES(JSP )
JSP = Jackson Structured Programming (for programming-in-the-small)
22
![Page 23: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/23.jpg)
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
![Page 24: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/24.jpg)
COMPOUND COMPONENTS IN JSP
24
A
B C D
sequence
B
A
*
iteration
B C D
A
o o o
selection
![Page 25: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/25.jpg)
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
![Page 26: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/26.jpg)
26
OOAD METHODS
three major steps:
1 identify the objects
2 determine their attributes and services
3 determine the relationships between objects
![Page 27: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/27.jpg)
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.
![Page 28: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/28.jpg)
28
CANDIDATE OBJECTS software library system station customer transaction book library employee identification card client bar code reader book’s code
![Page 29: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/29.jpg)
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
![Page 30: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/30.jpg)
RESULT: INITIAL CLASS DIAGRAM
30
![Page 31: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/31.jpg)
USAGE SCENARIO SEQUENCE DIAGRAM
31
![Page 32: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/32.jpg)
CAVEATS WHEN CHOOSING A PARTICULAR DESIGN METHOD
Familiarity with the problem domain
Designer’s experience
Available tools
Development philosophy
32
![Page 33: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/33.jpg)
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
![Page 34: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/34.jpg)
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
![Page 35: Software Design](https://reader034.vdocument.in/reader034/viewer/2022051609/5465eb40af7959642f8b46f1/html5/thumbnails/35.jpg)
THANK YOU!
35