Transcript 幻灯片 1 - Nanjing University

Computing and SE II
Chapter 9: Design Methods and Design Models
Er-Yu Ding
Software Institute, NJU
Main Contents
1. Design Methods
2. Structured Design
3. OO Design
1. Design Methods
• Ad-hoc
• Structured
• OO
1. Design Methods
——Ad-hoc
•
Small Scale Designs
–
–
–
–
•
Come up with a block diagram
Place chips on board
Wire parts and components
Hope or Pray it works
Large Scale Designs
–
–
–
–
–
–
–
–
Partition Design
Develop Library
Configure Design
Test Partial Design
Develop More Libraries
Configure More Designs
...
Complete Design
1. Design Methods
——Structured Design
• Fundamentals of a Discipline of
Computer Program and Systems Design
• Purpose
– Make methodical the process of designing
software systems
• Mainly business systems
• Approach
– Defines properties of a good
procedural(module) design
– Defines a step-by-step method for
transforming a data flow graph into a
1. Design Methods
——Object-Oriented Design
• Designing systems using self-contained
objects and object classes
• Direct mapping of concepts in the
problem domain to software units and
their interfaces
– Viewing the world as objects is more natural
since it is closer to the way humans think
• Objects are more stable than functions…
• Supports information hiding, data
abstraction, and encapsulation
2. Structured Design
• Based on structured analysis
• Methods
– Top-Down
– Bottom-Up
– Mixed
• Principles
– Functional Decomposition (Divide and
conquer)
– Modularity and Information hiding
• Low coupling
• High internal cohesion
2. Structured Design
• Top-Down
– Refine Specification successively
– Decompose each component into small
Components
– Lowest-level primitive components
– Over-sold methodology - only works with
plenty of experience
– Suitable for small new design system
• In practice, large systems design is never truly
top-down. Some branches are designed before
others. Designers reuse experience (and
sometimes components) during the design
2. Structured Design
• Bottom-Up
– Build-up from primitive components
– Combined to form more complex
components
– Risk wrong interpretation of
specifications
– Mostly used for legacy system
reengineering or enterprise application
integration
2. Structural Design
• Mixed
– Mostly top-down, but also bits of
bottom-up
– Reality: need to know both top level and
bottom level constraints
– Suitable for large systems design
2. Structured Design
—— Review: Sturctured Analysis Model
Function
Data Object
description
ERD
Data
DFD
Process
specification
(PSPEC)
Data dictionary
STD
Behavior
Control Specification (CSPEC)
2. Structured Design
——Structured Design Models
Function
Data Object
description
Structured
Chart
ERD
Data
Data dictionary
Flow Chart
Decision Table
PDL
STD
Behavior
For Design
Flow Chart
Decision Table
PDL
2. Structured Design
—— Transform Analysis
Central
Transform
Customer
4.3
Process
Payment
cheque,
bill stub
4.1
Read
Payment
account,
amount
4.4
Update
Balance
edited
payment
Afferent
Flow
payment
Payments
account,
amount
payment
4.2
Edit
Payment
4.6
Insert
Payment
4.5
Update
Open To
Buy
account,
amount
account,
Efferent amount Accounts
Flow
Modularity and Information hiding!!!!
2. Structured Design
—— Structure Charts
Input
(Afferent Flow)
Process
Central Transform)
Output
(Efferent Flow)
Control
Input
Process
Output
2. Structured Design
—— Structure Charts Notation
Modules
Library modules
Module call
Data
Flag
2. Structured Design
—— Structure Charts Process Payment Control
Example
Payment
Error
Payment
Payment
Get Payment
Payment
Process
Today
Write Payment
Process Payment
Payment
Raw
Payment
Payment
Error
Raw
Payment
Read
Record
Edit
Record
Payment
Payment
Update
Account
Insert
Payment
Event
2. Structured Design
—— Flow Chart
add a condition Z,
if true, exit the program
a
x1
b
x2
x3
d
f
e
x4
g
x5
c
2. Structured Design
—— Decision Table
Rule s
Condit ions
regular cust omer
1
2
3
4
T
T
gold cust omer
Rule s
no discount
apply 8 percent discount
apply 15 percent discount
apply addit ional x percent discount
6
T
T
F
T
T T
silver cust omer
special discount
5
F
T
F
T
2. Structured Design
—— Program Design Language (PDL)
if condition x
then process a;
else process b;
endif
if-then-else
PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
2. Structured Design
——Phases of data design
• Conceptual ERD
• Logical ERD
2. Structured Design
——Phases of data design
• Physical ERD
2. Structured Design
——STD for Analysis
b eh avio r w it h in t h e
st at e b u ild in g Jo b Dat a
2. Structured Design
——STD for Design
d at aIn p u t In co mp let e
buildingJobDat a
ent r y/ r eadJobDat a ( )
exit / displayJobDat a ( )
do/ checkConsist ency( )
include/ dat aInput
d at aIn p u t Co mp let ed [ all d at a
it ems co n sist en t ] / d isp layUserOp t io n s
comput ingJobCost
ent r y/ comput eJob
exit / save t ot alJobCost
j o b Co st Accep t ed [ cu st o mer is au t h o rized ] /
g et Elect ro n icSig n at u re
f or mingJob
ent r y/ buildJob
exit / save WOnumber
do/
submit t ingJob
ent r y/ submit Job
exit / init iat eJob
do/ place on JobQueue
j o b Su b mit t ed[ all au t h o rizat io n s acq u ired ] /
p rin t Wo rkOrd er
3. OO Design
• Object-oriented analysis, design and
programming are related but distinct
– OOA is concerned with developing an object
model of the application domain
– OOD is concerned with developing an
object-oriented system model to implement
requirements
– OOP is concerned with realising an OOD
using an OO programming language such as
Java or C++
•
3. OO Design
——Object Oriented
Concepts:Programming
– Programs are organized into cooperating
collections of objects
– Object: entity that encapsulates state
and behavior. An instance of a class
– Interface or protocol: set of messages to
which it will respond
– Response can be a message or routine,
or delegation of the message to another
object
3. OO Design
—— OOP Models
•
3. OO Design
—— Object-Oriented
Examines requirements
from
the
Analysis
perspective of the classes and objects
found in the vocabulary of the
problem domain
• Yields black-box objects that are
derived from the problem domain
• Scenarios can be used to determine
necessary object behavior
3. OO Design
—— OO Analysis Model - UML
Function
Class diagram
Object diagram
Use case diagram
Activity diagram
Data
Object
Behavior
State-chart diagram
Interaction diagram
3. OO Design
—— Object-Oriented Design
• Object focus shifts to the solution
domain
– Objects, their semantics, and
relationships are identified
– Implementation and iteration occur
– Quality and principles are focused
• Jacobsen says “when details of the
implementation begin to show, it’s
OOD”
• In my practice: OOA is preliminary
3. OO Design
——OOD Models
For Design
Data
Function
Class diagram
Compone
nt diagram
Package
Component
diagram
Activity diagram
Behavior
Object
State-chart diagram
Interaction diagram
Deployment diagram
Deployment
3. OO Design
——Class Diagram for Design
3. OO Design
——Activity Diagram for Diagram
ent er password
and user ID
valid passwor ds/ ID
v alidat e at t ribut es
input
ac c es s PaperDB (weight )
invalid passwor ds/ ID
ret urns bas eCos t perPage
select major f unct ion
prompt f or reent ry
paperCos t perPage =
bas eCos t perPage
ot her f unct ions
m ay also be
select ed
input t r ies r em ain
select surveillance
no input
t r ies r em ain
t hum bnail views
s iz e = B
paperCos t perPage =
paperCos t perPage * 1 . 2
s iz e = C
paperCos t perPage =
paperCos t perPage * 1 . 4
s iz e = D
paperCos t perPage =
paperCos t perPage * 1 . 6
select a specif ic cam er a
select specif ic
camera - t humbnails
select camera icon
Analysis Design
c olor is c us t om
view camera out put
in labelled window
c olor is s t andard
prompt f or
anot her view
exit t his f unct ion
ret urns
( paperCos t perPage )
see anot her cam er a
paperCos t perPage =
paperCos t perPage * 1 . 1 4
3. OO Design
——Sequence Diagram for
Analysis
Analysis
3. OO Design
——Sequence Diagram for
Design
3. OO Design
—— Component Model
• Defines the large-scale pieces of the
system. Each of these pieces will
contain smaller objects and will
organize and orchestrate their
behaviour
• Logical
– Package Diagram
• Physical
– Component Diagram
3. OO Design
——Package Diagram
3. OO Design
——Package Diagram
«subsystem»
Data collection
«subsystem»
Data display
Observer
Satellite
Comms
Weather
station
«subsystem»
Data archiving
Data
Data
storage
storage
Data
integ ration
Map store
Map
display
Map
printer
Map
Balloon
«subsystem»
Data processing
Data
checking
User
User
inter
interface
face
Data store
3. OO Design
—— Component Diagram
• Captures the physical structure of the
Implementation
• Built as part of architectural
specification
• Purpose
– Organize source code
– Construct an executable release
– Specify a physical database
3. OO Design
—— Component Diagram
3. OO Design
——Deployment Diagram
• Captures the topology of a system’s hardware
• Built as part of architectural specification
• Purpose
– Specify the distribution of components
– Identify performance bottlenecks
• Developed by architects, networking engineers,
and system engineers
• Configuration of:
– Run-time processing elements
– Software components, processes, and objects that
live on them.
– What about Remote Components?
3. OO Design
——Deployment Diagram
3. OO Design
——Deployment Diagram
The End
• Next Lecture
– HCI Design