Software Engineering
软 件 工 程
李 宣 东
南京大学计算机科学与技术系
http://cs.nju.edu.cn/people/lixuandong/softE.html
Contents
• Conventional Methods for Software
Engineering
传统软件工程方法
• Object-Oriented Software Engineering
面向对象软件工程
• Software Process, Management, and
Quality
软件过程、管理与质量
Reference 参考文献
• Roger S. Pressman
Software Engineering: A Practitioner’s Approach
McGraw-Hill
1982(1/e), 1987(2/e), 1992(3/e)
1997(4/e), 2001(5/e)
• «可视化面向对象建模技术»
刘超 张莉 编著
北京航空航天大学出版社
• http://moon.nju.edu.cn
Conventional Methods for Software Engineering
What
How
Do it
Test
Use
Conventional Methods for Software Engineering
System
engineering
系统定义
Analysis
分析
Design
设计
Code
编码
Testing
测试
Maintenance
维护
Basic Concepts 基本概念
Software is
• instructions (computer programs) that when
executed provide desired function and
performance,
• data structures that enable the programs to
adequately manipulate information, and
• documents that describe the operation and
use of the programs.
Basic Concepts
软件
计算机系统中的程序及其有关文件。
• 程序
计算任务中的处理对象和处理规则的描
述。
• 文件
为了便于了解程序所需的资料说明。
Basic Concepts
Software Characteristics
• Software is developed or engineering, it is not manufactured in
the classical sense.
软件是由开发或工程化而形成的，而不是传统意义上由制造
产生的。
• Software doesn’t “wear out”.
软件不会“磨损”。
• Although the industry is moving toward component-based
assembly, most software continues to be custom build.
大多数软件是自定的，而不是通过已有的构件组装起来的。
Basic Concepts
Software Applications
•
•
•
•
•
•
•
•
Systems software
Real-time software
Business software
Engineering and scientific software
Embedded software
Personal computer software
Web-based software
Artificial intelligence software
Basic Concepts
Generic Category for Software：
• 系统软件
• 支撑软件（中间件middleware）
• 应用软件
Basic Concepts
应用软件
应用软件
支撑软件
中间件
支撑软件
系统软件
系统软件
硬件平台
硬件平台
Basic Concepts
Evolution of Software 软件的发展过程
• 第一阶段：从第一台计算机上的第一个程序的出现到
实用的高级程序设计语言出现之前（1946-1956）；
• 第二阶段：从实用的高级程序设计语言出现到软件工
程出现之前（1956-1968）；
• 第三阶段：软件工程（1968- ）。
Basic Concepts
Software crisis 软件危机
• 供求关系失调
• 开发费用失控，进度拖延
• 可靠性差
• 难以维护
Basic Concepts
产生软件危机的原因
• 软件本身的特点
• 管理人员的错误观点
• 用户的错误观点
• 软件开发人员的错误观点
Basic Concepts
产生软件危机的原因（软件本身的特点）
•
•
•
•
软件开发进展情况较难衡量
软件开发质量难以评价
管理和控制软件开发过程相当困难
软件没有“磨损”概念，软件维护通常意味着
该进或修改原来的设计
Basic Concepts
产生软件危机的原因（管理人员的错误观
点）
• We already have a book that’s full of standards and
procedures for building software, won’t that providemy
people with everything they need to know?
我们 已经有了关于开发软件的标准和规范的书籍，难
道它们不能给人们提供所有其需要知道的信息吗？
Basic Concepts
产生软件危机的原因（管理人员的错误观
点）
• My people have state-of-the-art software development
tools, after all, we buy them the newest computers.
我们已经有了很好很多的软件开发工具，而且，我们
拥有最新的计算机。
• If we get behind schedule, we can add more programmers
and catch up.
如果我们已经落后于计划，可以增加更多的程序员来
赶上进度。
Basic Concepts
产生软件危机的原因（用户的错误观点）
• A general statement of objectives is sufficient to begin
writing programs - we can fill in the details later.
有一个对目标的概括描述就足以着手编写程序了，许
多细节可以在以后再补充。
• Project requirements continually change, but change can
be easily accmodated because software is flexible.
用户对软件的要求不断变化，然而软件是柔软而灵活
的，可以轻易地改动。
Basic Concepts
产生软件危机的原因（软件开发人员的
错误观点）
• Once we write the program and get it to work, our job is
done.
所谓软件开发就是编写程序并设法使它运行。
• Until I get the program “running” I have noway of
assessing its quality.
在程序真正运行之前，没有办法评估其质量。
Basic Concepts
产生软件危机的原因（软件开发人员的错
误观点）
• The only deliverable work product for a successful project
is the working program.
一个成功项目唯一应该提交的就是可运行的程序。
• Software engineering will make us create voluminous and
unnecessary documentation and will invariably slow us
down.
软件工程就是建立庞大无用的文档，这必将降低我们
的软件开发效率。
Basic Concepts
产生软件危机的原因（共有的错误观点）
• 软件投入生产性运行以后需要的维护工作并不
多，而且维护是一件很容易做的简单工作。
Basic Concepts
Software Engineering
• The establishment and use of sound engineering
principles in order to obtain economically
software that is reliable and works efficiently on
real machines. (NATO Science Committee)
Basic Concepts
软件工程
• 应用计算机科学、数学及管理科学等原理，以
工程化原则、方法解决软件问题的工程。其中，
计算机科学、数学用于构造模型与算法，工程
科学用于制定规范、设计范型、降低成本及确
定权衡，管理科学用于计划、资源、质量、成
本等管理。（大百科全书）
Basic Concepts
软件工程的基本内容：
• 软件设计方法论
• 软件工具
• 软件工程标准和规范
• 软件工程管理
• 软件工程理论
Basic Concepts
软件工程的基本原理：
• 严格按照计划进行管理
• 坚持进行阶段评审
• 实行严格的产品控制
• 采用现代的程序技术
• 结果要能清晰地审计
• 开发小组人员素质要好，数量不宜多
• 要承认不断改善软件工程实践的必要性
Basic Concepts
Software Life Cycle 软件生存期（Software
Process 软件过程）模型：
软件生存期是软件产品或系统一系
列相关活动的全周期。从形成概念开始，
经过研制，交付使用，在使用中不断增
补修订，直到最后被淘汰，让位于新的
软件产品的过程。对软件生存期的不同
划分，形成了不同的软件生存期模型。
Basic Concepts
Waterfall Model
System
engineering
系统定义
Analysis
分析
Design
设计
强调阶段的划分
Code
及其顺序性、各阶段工作
编码
及其文档的完备性，是一种
严格线性的、按阶段顺序的、逐步
细化的开发模式。
Testing
测试
Maintenance
维护
Basic Concepts
瀑布式软件生存期模型把软件开发
过程划分成若干阶段，每个阶段的任务
相对独立，便于不同人员分工协作，从
而降低了整个软件开发工程的困难程度。
在软件生存期的每个阶段都采用科学的
管理技术和良好的方法与技术，而且每
个阶段结束之前，都从技术和管理两个
角度进行严格的审查，经确认之后才开
始下一阶段的工作。
Basic Concepts
瀑布式模型的特点：
• 结构简单明了；历史较长、应用面广泛、
为广大软件工作者所熟悉；已有与之配
套的一组十分成熟的开发方法和丰富的
支撑工具。
• 确定了需求分析的绝对重要性，但是在
实践中要想获得完善的需求说明是非常
困难的；反馈信息慢。
Basic Concepts
Software Quality Factors 软件质量要素：
• Correctness 正确性：软件产品准确执行软件规格说明
中所规定的能力。
• Robustness 健壮性：在异常条件下软件仍能运行的能
力。
• Reliability 可靠性：软件在给定的时间内和规定的环境
条件下，按规格说明的规定成功地运行的概率。可靠
性理解为正确性和健壮性之和。
System Engineering
What is it?
Before software can be engineered, the “system” in
which it resides must be understood. To accomplish
this,
• the overall objective of the system must be determined;
• the role of hardware, software, people, database, procedures, and other
system elements must be identified;
• and operational requirements must be elicited, analyzed, specified,
modeled, validated, and managed.
These activities are the foundation of system
engineering.
System Engineering
Who does it?
• A system engineer works to understand system
requirements by working with the customer, future
users, and other stakeholders.
System Engineering
Why is it important?
• There is an old saying：“You cannot see the forest for the
trees.”In this context, the “forest”is the system, and the
trees are the technology elements (include software) that
are required to realize the system. If you rush to build
technology elements before you understand the system,
you will undoubtedly make mistakes that will disappoint
your customer. Before you worry about the trees,
understand the forest.
System Engineering
What are the steps?
• Objectives and more detailed operational requirements are
identified by eliciting information from the customer.
• Requirements are analyzed to assess their clarity,
completeness, and consistency.
• A specification, often incorporating a system model, is
created and then validated by both practitioners and
customers.
• System requirements are managed to ensure that changes
are properly controlled.
System Engineering
What is the work product?
• A effective representation of the system must be produced
as a consequence of system engineering. This can be a
prototype, a specification or even a symbolic model, but it
must communicate the operational, functional, and
behavioral characteristics of the system to be built and
provide insight into the system architecture.
System Engineering
How do I ensure that I have done it right?
• Perform requirements engineering steps, including
requirements elicitation, that lead to a solid specification.
Then review all system engineering work products for
clarity, completeness, and consistency. As important,
expect changes to the system requirements and manage
them using solid SCM (Software Configuration
Management).
System Engineering
• Instead of concentrating solely on software,
system engineering focuses on a variety of
elements, analyzing, designing, and
organizing those elements into a system that
can be a product, a service, or a technology
for the transformation of information or
control.
System Engineering
Computer - Based Systems
• A set or arrangement of elements that are organized to
accomplish some predefined goal by processing
information.
System Engineering
Computer - Based Systems
•
•
•
•
•
•
Software
Hardware
People
Database
Documentation
Procedures
System Engineering
Business or
product domain
World view
Domain of interest
Domain view
System element
Element view
Detailed view
System Engineering
System engineering hierarchy
• The world view (WV) is composed of a set of domain (Di),
which can be system or system of systems in its own right.
WV = {D1, D2, D3, …, Dn}
• Each domain is composed of specific element (Ej) each of
which serves some role in accomplishing the objective and goals
of the domain or component.
Di = {E1, E2, E3, …, Em}
• Each element is implemented by specifying the technical
componets (Ck) that achieve the necessary function for an
element.
Ej = {C1, C2, C3, …, Ck}
System Engineering
• System Modeling
• System Simulations
System Engineering
System engineering is a modeling process:
• Define the processes that serve the needs of the view under
consideration.
• Represent the behavior of the processes and the
assumptions on which the behavior is based.
• Explicitly define both exogenous and endogenous input to
the model.
• Represent all linkages (including output) that will enable
the engineer to better understand the view.
System Engineering
To construct a system model, the engineer
should consider a number of restraining factors:
•
•
•
•
•
Assumptions
Simplifications
Limitations
Constraints
Preferences
System Engineering
System Simulation
• Many computer -based systems interact by the real
world in a reactive fashion.
• Real-time and embedded systems often fall into
the reactive systems category.
System Engineering
System engineering process:
• Business process engineering
The system engineering process is called business process engineering
when the engineering work focuses on a business enterprise.
• Product engineering
The system engineering process is called product engineering when a
product is to be built.
System Engineering
Business process engineering
• The goal of business process engineering is to define
architectures that will enable a business to use information
effectively.
• Three different architectures must be analyzed and
designed within the context of business objectives and
goals:
- data architecture
- application architecture
- technology infrastructure
System Engineering
Business process engineering
• The data architecture provides a framework for the
information needs of a business or business function.
• The application architecture encompasses those elements
of a system that transform objects within the data
architecture for some business purpose.
• The technology infrastructure provides the foundation for
the data and application architectures.
System Engineering
The enterprise
Business area
Information
strategy planning
(world view)
Business
area analysis
(domain view)
A business area
Processing requirement
Information
system
Business system
design
(element view)
Construction
&
integration
(detailed view)
Software
engineer
System Engineering
Product engineering
• The goal of product engineering is to translate the
customer’s desire for a set of defined capability into a
working product.
• To achieve this goal, product engineering must derive
architecture and infrastructure.
• The architecture encompasses four distinct system
components: software, hardware, data (databases), and
people.
• A support infrastructure is established and includes the
technology to tie the components together and the
information that is used to support the components.
System Engineering
The complete product
Capabilities
Hardware
Function
Component
engineering
(domain view)
Software
Processing requirements
Data
Requirements
engineering
(world view)
Behavior
Analysis & design
modeling
(element view)
Program
component
Construction
&
integration
(detailed view)
Software
engineer
System Engineering
Product engineering
• System Analysis
• Identification of Need
• Feasibility Study
Economic feasibility
Technical feasibility
Legal feasibility
Alternatives
• Economic Analysis
• Technology Analysis
System Engineering
Requirements engineering
• The outcome of the system engineering process is the
specification of a computer-based system or product at the
different levels.
• But the challenge facing system engineers (and software
engineers) is profound: How can we ensure that we have
specified a system that properly meets the customer’s
needs and satisfies the customer’s expectations? There is
no foolproof answer to this difficult question, but a solid
requirements engineering process is the best solution we
currently have.
System Engineering
Requirements engineering
• Requirements engineering provides the appropriate
mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a
reasonable solution, specifying the solution unambiguously,
validating the specification, and managing the
requirements as they are transformed into an operational
system.
System Engineering
Requirements engineering process
•
•
•
•
•
•
requirements elicitation
requirements analysis and negotiation
requirements specification
system modeling
requirements validation
requirements management
System Engineering
How to model systems
• Every computer-based system can be modeled as an
information transform using an input-processing-output
template.
• To develop the system model, a system model template is
used. The system engineer allocates system elements to
each of five processing regions within the template:
- user interface
- input
- system function and control
- output
- maintenance and self test
System Engineering
User interface processing
Input
processing
Process and control
functions
Maintenance and self-test
System model template
Output
processing
System Engineering
System specification
• Introduction
A. Scope and purpose of Document
B. Overview
1. Objectives
2. Constraints
• Functional and Data Descriptions
A. System architecture
1. System context diagram
2. SCD Description
System Engineering
System specification
• Subsystem Descriptions
A. Architecture Diagram Specification for Subsystem n
B. Architecture Dictionary
C. Architecture Interconnect Diagrams and Description
• System Modeling and Simulation Results
A. System Model Used for Simulation
B. Simulation Results
C. Special Performance Issues
• Project Issues
A. Projecte Development Costs
B. Project Schedule
• Appendices
Software Requirements Analysis
• Software requirements engineering is a process of
discovery, refinement, modeling, and specification.
• Both the software engineer and customer take an
active role in software requirements engineering.
Software Requirements Analysis
• Requirements analysis is a software engineering
task that bridges the gap between system level
requirements engineering and software design.
System
engineering
Software
requirements
analysis
Software
design
Software Requirements Analysis
• Requirements engineering activities result in the
specification of software’s operational
characteristics (function, data, and behavior),
indicate software’s interface with other system
elements, and establish constraints that software
must meet.
Software Requirements Analysis
• In requirements analysis and specification,
communication content is very high, chance for
misinterpretation or misinformation abound, and
ambiguity is probable.
• “I know you believe you understood what you
think I said, but I am not sure you realize that what
you heard is not what I meant.”
“我知道你相信你明白了你认为我所说的是什么，
但是我不能肯定你是否意识到你听到的并不是我
所指的意思 ...…。”
Software Requirements Analysis
Software requirements analysis may be divided
into five areas of effort:
•
•
•
•
•
Problem recognition
evaluation and synthesis
modeling
specification
review
Software Requirements Analysis
Requirements elicitation for software:
•
•
•
•
Initiating the Process
Facilitated Application Specification Techniques
Quality Function Deployment
Use Cases
Software Requirements Analysis
Analysis Principles:
• The information domain of a problem must be represented and
understood.
• The functions that the software is to perform must be defined.
• The behavior of the software (as a consequence of external
events) must be represented.
• The models that depict information, function, and behavior must
be partitioned in a manner that uncovers detail in a layered (or
hierarchical) fashion.
• The analysis process should move from essential information
toward implementation detail.
Software Requirements Analysis
Guiding principles for requirements engineering
• Understand the problem before you begin to create the
analysis model.
• Develop prototypes that enable a user to understand how
human/machine interaction will occur.
• Record the origin of and the reason for every requirements.
• Rank requirements
• work to eliminate ambiguity.
Software Requirements Analysis
软件需求分析人员应该具备的特征：
• 善于领会一些抽象的概念，重新整理使
之成为各种逻辑成分，并根据各种逻辑
成分综合出问题的解决办法；
• 善于从各种相互冲突或混淆的原始资料
中吸取恰当的论据；
• 能够理解用户的环境及领域知识；
Software Requirements Analysis
软件需求分析人员应该具备的特征：
• 具备把系统的硬件和软件部分应用于用
户环境的能力；
• 具备良好的书面和口头形式进行讨论和
交换意见的能力；
• 具有“既能看到树木，又能看到森林”
的能力。
Software Requirements Analysis
How to analyze software requirements?
• Analyzing the information domain
• Modeling
• Partitioning
Software Requirements Analysis
Key to understanding of software requirements
• All software applications can be collectively
called data processing. Interestingly, this term
contains a key to our understanding of software
requirements.
• Software is built to process data, to transform data
from one form to another; that is, to accept input,
manipulate it in some way, and produce output.
This fundamental statement of objective is true for
all software we build.
Software Requirements Analysis
The information domain
• information content ant relationships
• information flow
• information structure
Software Requirements Analysis
The information domain
• Information content represents the individual data and
control objects that constitute some larger collection of
information transformed by the software. Data and control
objects can be related to other data and control objects, and
during analysis of the information domain these
relationships should be defined.
• Information flow represents the in manner in which data
and control change as each moves through a system.
• Information structure represents the internal organization
of various data and control items.
Software Requirements Analysis
The analysis model must achieve three
primary objectives:
• to describe what the customer requires
• to establish a basis for the creation of a software
• to define a set of requirements that can be
validated once software is built.
Software Requirements Analysis
Analysis Modeling
• Data modeling
• Functional modeling
• Behavioral modeling
Software Requirements Analysis
The structure of
the analysis model
Entity
relationship
diagram
Data flow
diagram
Data
dictionary
State-transition
diagram
Control specification
Software Requirements Analysis
Data Dictionary
• a repository that contains descriptions of of data
objects consumed or produced by the software.
Software Requirements Analysis
Entity Relation Diagram (ERD)
• The ERD depicts relationships between data
objects.
• The ERD is the notation that is used to conduct
the data modeling activity.
• The attributes of each data object noted in the
ERD can be described using a data object
description.
Software Requirements Analysis
Data Flow Diagram (DFD)
• The DFD serves two purposes: (1) to provide an indication
of how data are transformed as they move through the
system and (2) to depict the functions (and subfunctions)
that transform the data flow.
• The DFD provides additional information that is used
during the analysis of information domain and serves as a
basis for modeling function.
• A description of each function presented in the DFD is
contained in a process specification (PSPEC).
Software Requirements Analysis
State Transition Diagram (STD)
• The STD indicates how the system behaves as a
consequence of external events. To accomplish this, the
STD represents the various modes of behavior (called
states) of the system and the manner in which transitions
are made from state to state.
• The STD serves as the basis for behavioral modeling.
• Additional information about the control aspects of the
software is contained in the control specification (CSPEC).
Software Requirements Analysis
Data modeling
• What are the primary data objects to be processed by the
system:
• What is the composition of each data object and what
attributes describe the object?
• Where do the objects currently reside?
• What are the relationships between each object and other
objects?
• What are the relationships between the objects and the
processes that transform them?
Software Requirements Analysis
Entity Relation Diagram (ERD)
• Data objects: A data object is a representation of almost
any composite information that must be understood by
software.
• Attributes: define the properties of a data object and take
on one of three different characteristics: (1) name an
instance of the data object, (2)describe the instance, and (3)
make reference to another instance in another table.
• Relationships: Data objects are connected to one another in
different ways.
Software Requirements Analysis
manufacturer
A simple ERD
builds
car
Software Requirements Analysis
Functional modeling
• Information is transformed as its flows through a
computer-based system.
• The system accepts input in a variety of forms;
applies hardware, software, and human elements
to transform it; and produces output in a variety of
form.
Software Requirements Analysis
Fundamental system model
• 软件系统的全部功能被表示成一个单一的信息变换过程：
input1
output1
input2
.
.
.
inputn
Software System
(information transformer) .
.
.
output2
outputn
Software Requirements Analysis
Basic DFD Notation
• External entity: A producer or consumer of information
that resides outside the bounds of the system to be modeled.
• Process: A transformer of information that resides within
the bounds of the system to be modeled.
• Data object: the arrowhead indicates the direction of data
folw.
• Data store: A repository of data that is to be stored for use
by one or more process.
Software Requirements Analysis
例：病员监视系统
基本模型
病员
病情信号
请求提出报告
护士
病员
监视
系统
报告
护士
警告信号
病历数据
病员病历
Software Requirements Analysis
病员
病员的病情界限
病情信号
本地
监视
病员数据
警告信号
护士
护士
请求报告
中央
监视
经过整理后的病员数据
报告
产生
更新
病历
病员病历
Software Requirements Analysis
病员数据
分解
病情信号
病员病情界限
脉搏
体温
检查是
否超出
界限
血压
警告信号
产生警告
信号
时钟
日期时间
整理病员
数据
整理后的病员
数据
Software Requirements Analysis
Behavior modeling
• States
• Transitions
• Events
Software Requirements Analysis
Full and start
Invoke manage-copying
Copies done
Invoke read-op-input
Making
copies
Reading
commands
Idle
Invoke read-op-input
Empty
Invoke reload paper
Jammed
Invoke perform problem-diagnosis
Diagnosing
problem
Full
Invoke read-op-input
Reloading
paper
Not jammed
Invoke read-op-input
Software Requirements Analysis
Structured Analysis
• Creating an entity/relationship diagram
•
•
•
•
Creating a data flow model
Control specification
Process specification
Creating a data dictionary
Software Requirements Analysis
The Software Requirements Specification
• Introduction
A. System reference
B. Overall description
C. Software project constraints
• Information Description
A. Information content representation
B. Information flow representation (1. Data flow 2. Control flow)
Software Requirements Analysis
The Software Requirements Specification
• Functional Description
A. Functional partitioning
B. Functional description
1. Processing narrative
2. Restrictions/limitations
3. Performance requirements
4. Design constraints
5. Supporting diagrams
C. Control Description
1. Control specification
2. Design constraints
Software Requirements Analysis
The Software Requirements Specification
• Behavioral Description
A. System states
B. Events and actions
• Validation and Criteria
A. Performance bounds
B. Classes of tests
C. Expected software response
D. Special considerations
• Bibliography
• Appendix
Software Requirements Analysis
Specification Review
• Complete
• Consistent
• Accurate
Design
• Software design sits at the technical kernel of software
engineering and is applied regardless of the software
process model that is used.
• Beginning once software requirements have been analyzed
and specified, software design is the first of three technical
activities - design, code generation, and test - that are
required to build and verify the software.
• The importance of software design can be started with a
single word - quality. Design provides us with
representations of software that can be assessed for quality.
Design
The design model
Componentlevel design
Interface design
Architectural design
Data design
Design
• The data design transforms the information domain model
created during analysis into the data structures that will be
required to implement the software.
• The architectural design defines the relationship between
major structural element of software.
• The interface design describes how the software
communicates within itself, with systems that interoperate
with it, and with humans who use it.
• The component-level design transforms structural elements
of software architecture into a procedural description of
software components.
Design
Design process goal:
• The design must implement all of the explicit requirements
contained in the analysis model, and it must accommodate
all of the implicit requirements desired by the customer.
• The design must be a readable, understandable guide for
those who generate code and for those who test and
subsequently maintain the software.
• The design should provide a complete picture of the
software, addressing the data, functional, and behavioral
domain from an implementation perspective.
Design
Abstraction
• Abstraction permits one to concentrate on a
problem at some level of generalization without
regard to irrelevant low level details.
Design
Refinement
• Refinement is actually a process of elaboration. We
begin with a statement of function (or description of
information) that is defined at a high level of
abstraction. That is, the statement describes function
or information conceptually but provides no
information about the internal workings of the
function or the internal structure the information.
Refinement causes the designer to elaborate on the
original statement, provide more and more details as
each successive refinement (elaboration) occurs.
Design
Abstraction and Refinement
• Abstraction and refinement are complementary
concepts. Abstraction enables a designer to specify
procedure and data and yet suppress low-level
details. Refinement helps the designer reveal lowlevel details as design progresses. Both concepts
aid the designer in creating a complete design
model as the design evolves.
Design
Modularity （模块化）
• Software is divided into separately named and
addressable components, often called modules
（模块）, that are integrated to satisfy problem
requirements.
Design
模块：
• 模块是数据说明、可执行语句等程序对
象的集合，是单独命名的并且可以通过
名字来访问，例如过程、函数、子程序、
宏、module等。
Design
Argument for modularity：
• C(x) be a function that defines the perceived
complexity of a problem x.
• E(x) be a function that defines the effort required
to solve a problem x.
• For two problems, p1 and p2，
if C(p1) > C(p2), then E(p1) > E(p2)
• C(p1 + p2) > C(p1) + C(p2)
• E(p1 + p2) > E(p1) + E(p2)
Design
Total software cost
Region of minimum cost
Cost to integrate
Cost or effort
M
Cost/module
Number of modules
Design
How do we define an appropriate module of a given size?
•
•
•
•
•
Modular decomposability
Modular composability
Modular understandability
Modular continuity
Modular protection
Design
Software Architecture
• Software architecture is the hierarchical structure of
program components (modules), the manner in which these
components interact, and the structure of data that are used
by the components.
• One goal of software design is to derive an architectural
rendering of a system. This rending serves as framework
from which more detailed design activities are conducted.
Design
Software Architecture
• Control hierarchy
• Structured Partitioning
Design
Fan-out
Depth
Fan-in
Width
Design
Data Structure
• Data structure is a representation of the logical
relationship among individual elements of data.
• Data structure dictates the organization, methods
of access, degree of associativity, and processing
alternatives for information.
Design
Software Procedure
• Software architecture (program structure) defines control
hierarchy without regard to the sequence of processing and
decisions.
• Software procedure focuses on the processing details of
each module individually.
• Procedure must provide a precise specification of
processing, including sequence of events, exect decision
points, repetitive operations and even data organization
and structure.
Design
Information Hiding
• Modules should be specified and designed so that
information (procedure and data) contained within
a module is inaccessible to other modules that
have no need for such information.
Design
Effective modular design:
Function independence (模块功能独立性)
• The concept of function independence is a direct outgrowth
of modularity and the concepts of abstraction and
information hiding.
• We should design software so that each module addresses a
specific subfunction of requirements and has a simple
interface when viewed from other parts of the program
structure.
Design
模块功能独立性：
• 模块独立是指开发具有独立功能而且和其它模
块之间没有过多的相互作用的模块。
模块功能独立的意义：
• 功能分割，简化接口，易于多人合作开发同一
软件；
• 独立的模块易于测试和维护。
Design
qualitative criteria for measuring independence:
• Cohesion (内聚性)
• Coupling (耦合性)
Design
Cohesion
• Cohesion is a natural extension of the information hiding
concept.
• A cohesive module performs a single task within a
software procedure, requiring little interaction with
procedures being performed in other parts of a program.
Stated simply, a cohesive module should (ideally) do just
one thing.
• We always strive for high cohesion, although the midrange of the spectrum is often acceptable.
Design
Spectrum for cohesion:
• Coincidentally cohesion (偶然内聚)：一组任务关系松散（低）
• Logically cohesion (逻辑内聚)：一组任务在逻辑上同属一类，
例如均为输出（低）
• temporal (时间内聚)：一组任务必须在同一段时间内执行（低）
• Communicational cohesion (信息内聚)：模块内所有元素都引
用相同的输入或输出数据集合（中）
• Sequential cohesion (顺序内聚)：模块中的每个元素都是与同
一功能紧密相关，一个元素的输出是下一个元素的输入（高）
• Functional cohesion (功能内聚)：一个模块完成一个且仅完成
一个功能（高）
Design
Coupling
• Coupling is a measure of interconnection among modules
in a software structure.
• Coupling depends on the interface complexity between
modules, the point at which entry or reference is made to a
module, and what data pass across the interface.
• In software, we strive for lowest possible coupling.
Design
Spectrum for coupling:
• No direct coupling (无任何连接)：两个模块中的每一个都能独
立地工作而不需要另一个的存在（最低耦合）。
• Data coupling (数据耦合)：两个模块彼此通过参数交换信息，
且交换的仅仅是数据（低耦合）。
• Control coupling (控制耦合)：两个模块之间传递的信息有控制
成分（中耦合）。
Design
Spectrum for coupling:
• Common coupling (公共环境耦合)：两个或多个模块通过一个
公共环境相互作用：
1. 一个存数据，一个取数据（低耦合）；
2. 都存取数据（低--中之间）。
• Content coupling (内容耦合)：
1. 一个模块访问另一个模块的内部数据；
2. 两个模块有一部分程序代码重叠；
3. 一个模块不通过正常入口而转移的另一个的内部；
4. 一个模块有多个入口（意味着该模块有多个功能）。
Design
关于耦合性和内聚性的设计原则：
• 力争尽可能弱的耦合性：尽量使用数据
耦合，少用控制耦合，限制公共环境耦
合的范围，完全不用内容耦合
• 力争尽可能高的内聚性：力争尽可能高
的内聚性，并能识别出低内聚性
Design
Design heuristics for effective modularity：
• Evaluate the “first iteration” of the program structure to
reduce coupling and improve cohesion. 改进软件结构，提高
模块内聚性，降低模块耦合性。
• Attempt to minimize structures with high fan-out; strive
for fan-in as depth increases. 尽量减少高扇出结构的数目，随
着深度的增加争取更多的扇入。扇出过大意味着模块过分复杂，
需要控制和协调过多的下级模块。一般来说，顶层扇出高，中间
扇出少，低层高扇入。
Design
Design heuristics for effective modularity：
• Keep the scope of effect of a module within the scope of
control of that module. 模块的作用范围保持在该模块的控制范
围内。模块的作用范围是指该模块中一个判断所影响的所有其它
模块；模块的控制范围指该模块本身以及所有直接或间接从属于
它的模块。
• Evaluate module interfaces to reduce complexity and
redundancy. 力争降低模块接口的复杂程度。模块接口的复杂性
是引起软件错误的一个主要原因。接口设计应该使得信息传递简
单并且与模块的功能一致。
Design
Design heuristics for effective modularity：
• Strive for “controlled entry” modules by avoiding
“pathological connections.” 设计单入口单出口的模块。避免
内容耦合，易于理解和维护。
• Define modules whose function is predictable. 模块的功能
应该可以预测。相同的输入应该有相同的输出，否则难以理解、
测试和维护。
Design
• Data design
• Architectural design
• Interface design
• Component design
Design
Data design
• Data design creates a model of data and/or information that
is represented at a high level of abstraction. This data
model is then refined into progressively more
implementation-specific representations that can be
processed by the computer-based system.
Design
Data design
• Data structure: At the program component level, the design
of data structures and associated algorithms required to
manipulate them is essential to the creation of high-quality
applications.
• Database: At the application level, the translation of a data
model into a database is pivotal to achieving the business
objectives of a system.
• Data warehouse: At the business level, the collection of
information stored in disparate databases and reorganized into a
“data warehouse” enables data mining or knowledge discovery
that can have an impact on the success of the business itself.
Design
Architectural design
• Architectural styles
• Mapping requirements into a software architecture
Design
Architectural styles
•
•
•
•
•
Data-centered architectures
Data-flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures
Design
Mapping requirements into a software architecture
• The call and return architecture.
• Structured design (data flow-oriented design
method)
Design
Structured design provides a convenient transition
from a data flow diagram to software architecture:
•
•
•
•
•
the type of information flow is established;
flow boundaries are indicated;
the DFD is mapped into program structure;
control hierarchy is defined;
resultant structure is refined using design measures and
heuristics; and
• the architectural description is refined and elaborated.
Design
Transform flow (变换流)：
• 信息沿输入通路进入系统，同时由外部
形式变换成内部形式。进入系统的信息
通过变换中心，经过加工处理以后再沿
着输出通路变换成外部形式离开系统。
Design
External representation
Incoming flow
Outgoing flow
(外部表示)
(输入流)
(输出流)
Transform flow
(变换中心)
Information (信息)
Internal representation
(内部表示)
Time(时间)
Design
Transaction flow (事务流)：
• 事务流的特点是数据沿着接收通路把外
部世界的信息转换成一个事务项，然后，
计算该事务项的值，根据它的值激励起
多条活动通路中的一条数据流。发出多
条通路的信息流中枢被称为“事务中
心”。
Design
Transaction (事务)
Transaction center
T
(事务中心)
Action paths
(活动通路)
Design
Transform mapping (变换型映射)
• Step 1. Review the fundamental system model.
(复查基本系统模型)
• Step 2. Review and refine data flow diagrams for the
software. (复查并精化数据流图)
• Step 3. Determine whether the DFD has transform or
transaction flow characteristics. (确定数据流图具有变换
特性还是事务特性)
• Step 4. Isolate the transform center by specifying incoming
and outgoing flow boundaries. (确定输入流和输出流的
边界，从而孤立出变换中心)
Design
Transform mapping (变换型映射)
• Step 5. Perform “first-level factoring”
(完成“第一级分解”)
软件结构代表对控制的自顶向下的分配，所谓分解就是分配
控制的过程。
对于变换流，数据图将被映射成一个特殊的软件结构，这个
结构控制输入、变换和输出信息等处理过程：位于软件结构最顶
层的控制模块Cm协调下述从属的控制功能：
（1）输入信息处理控制模块Ca，协调对所有输入数据的接收；
（2）变换中心控制模块Ct，管理对内部形式的数据的所有操作；
（3）输出信息控制模块Ce，协调输出信息的产生过程。
Design
Cm
Ca
Ct
Ce
Design
Transform mapping (变换型映射)
• Step 6. Perform “second-level factoring”
(完成“第二级分解”)
把数据流图中的每一个处理映射成软件结构中一个适当的模
块：从变换中心的边界开始沿着输入通路向外移动，把输入通路
中每个处理映射成软件结构中Ca控制下的一个低层模块；然后沿
输出通路向外移动，把输出通路中每个处理映射成直接或间接受
Ce控制的一个低层模块；最后把变换中心内的每个处理映射成受
Ct控制的一个模块。
Design
D
A
Cm
C
Ca
B
C
B
D
A
Design
Transform mapping (变换型映射)
• Step 7. Refine the first-iteration architecture using
design heuristics for improved software quality.
(使用设计度量和启发式规则对得到的软件结构进一步
精化)
Design
Transaction mapping (事务型映射)
• Step 1. Review the fundamental system model.
(复查基本系统模型)
• Step 2. Review and refine data flow diagrams for the
software. (复查并精化数据流图)
• Step 3. Determine whether the DFD has transform or
transaction flow characteristics. (确定数据流图具有变换
特性还是事务特性)
• Identify the transaction center and the flow characteristics
along each of the action paths. (确定事务中心和每个活动
通路的流程特征)
Design
Transaction mapping (事务型映射)
• Step 5. Map the DFD in a program structure amenable to
transaction processing. (把数据流图映射成一个适合于事
务处理的软件结构)
• Step 6. Factor and refine the transaction structure and the
structure of each action path. (对事务中心的结构和每个
活动通路的结构进行分解、合并和改进)
• Step 7. Refine the first-iteration architecture using design
heuristics for improved software quality. (使用设计度
量和启发式规则对得到的软件结构进一步精化)
Design
总控
接收通路
调度
A-CTL
B-CTL C-CTL
D
D
E
F
E
C通路
G
B通路
F
G
A通路
Design
Interface design focuses on three areas:
• the design of interfaces between software
components;
• the design of interface between the software and
other nonhuman producers and consumers (other
external entities);
• the design of the interface between a human (the
user) and the computer.
Design
User interface design
• Place the user in control.
• Reduce the user’s memory load.
• Make the interface consistent.
Design
Principles for user interface design
• Define interaction modes in a way that does not force a
user into unnecessary or undesired actions.
• Provide for flexible interaction.
• Allow user interaction to be interruptible and undoable.
• Streamline interaction as skill levels advance and allow the
interaction to be customized.
• Hide technical internals from the casual user.
• Design for direct interaction with objects that appear on the
screen.
Design
Principles for user interface design
•
•
•
•
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a real
world.
• Disclose information in a progressive fashion.
Design
Principles for user interface design
• Allow the user to put the current task into a meaningful
context.
• Maintain consistency across a family of applications.
• If past interactive models have created user expectations,
do not make changes unless there is a compelling reason to
do so.
Design
Component-level design
• Component-level design transforms structural elements of
software architecture into a procedural description of
software components.
• It is possible to represent the component-level design using
a programming language. An alternative approach is to
represent the procedural design using some intermediate
representation that can be translated easily into source code
Design
Foundations of component-level design
(Structured programming)
• Structured constructs were proposed to limit the procedural
design of software to a small number of predictable
operations.
• The structured constructs as sequence （顺序）, condition
（选择）, and repetition （重复）.
• The use of the structured constructs reduces program
complexity and thereby enhances readability, testability,
and maintainability.
Design
Design notation for component-level design
(详细设计工具)
• 对软件开发人员来说，提高软件开发效率
• 对软件测试和维护人员来说，提供摆脱繁琐的
程序代码，了解模块程序结构的途径
Design
详细设计工具：
• Graphical design notation (图形工具)
将过程细节用图来表示，在图中，逻辑结构用具体
的图形表示
• Tabular design notation (列表工具)
利用表来表示过程细节，表列出了各种操作和相应
的条件
• Program design language (语言工具)
用类语言（伪码）表示过程的细节，很接近编程语
言
Design
Graphical design notation (图形工具)：
• Flowchart (流程图)
• Box diagram (方块图)
• Problem analysis diagram (PAD图)
Design
流程图
• 方框表示处理步
• 菱形表示逻辑判断
• 箭头表示控制流
注意：用流程图表示过程细节时，要注
意不要乱用箭头，否则会使结构不清晰
Design
N
C1
Y
C2
Y
C3
Y
N
N
S1
N
C5
S2
Y
S3
N
S5
S4
C4
Y
Design
流程图的主要缺点：
• 流程图本质上不是逐步求精的好工具，它诱
使程序员过早地考虑程序的控制流程，而不
去考虑程序的全局结构。
• 流程图中用箭头代表控制流，因此程序员不
受任何约束，可以完全不顾结构程序设计的
精神，随意转移控制。
• 流程图不易表示数据结构。
Design
方块图（N-S图）
• 研制方块图的目的是：既要制定一种图形工具，
又不允许它违反结构化原则。
• 方块图具有以下特点：
（1）功能域（即某一具体构造的功能范围）有明确的规
定，并且很只观地从图形表示中看出来；
（2）想随意分支或转移是不可能的；
（3）局部数据和全程数据的作用域可以很容易确定；
（4）容易表示出递归结构。
Design
第一个任务
F
第二个任务
ELSE
部分
第三个任务
顺序
条件
T
THEN
部分
IF-THEN-ELSE分支
CASE条件
值1 值2
…...
值n
CASE1
部分
CASE分支
循环条件
Do - Until
部分
Do - While
部分
A
循环条件
循环
调用子程序A
Design
C1
N C2
Y
N C3
Y
S1
C5
N
S2
S3
S4
C4
S5
Y
Design
PAD图（Problem Analysis Diagram）
P1
P1
C
X= L2
P2
P2
P1
L1
Ln
P2
.
.
.
Pn
顺序
选择
CASE型选择
Design
WHILE C
P
def
定义
UNTIL C
循环
P
语句标号
Design
P1
P6
P2
UNTIL C2
P3
def
C
P2
C1
P8
P4
P5
UNTIL C3
P10
P9
P7
Design
S1
C3
WHILE C1
C2
S2
UNTIL C4
C5
S3
S5
S4
Design
PAD图的特点：
• 使用表示结构化控制结构的PAD符号所设计出
的程序必然是结构化程序。
• PAD图所描述的程序结构十分清晰，图中最左
面的竖线是程序的主线，即第一层结构，随着
程序层次的增加，PAD图逐渐向右延伸，每增
加一个层次，图形向右扩展一条竖线，PAD图
中的竖线的总条数就是程序的层次数。
Design
PAD图的特点：
• 用PAD图表现程序逻辑，易读、易懂、易记，
PAD图是二维树形结构的图形，程序从图中最
左竖线上端的结点开始执行，自上而下，从左
向右顺序执行，遍历所有结点。
• 容易将PAD图转换成高级语言源程序，这种转
换可用软件工具自动完成。
Design
PAD图的特点：
• 既可以用于表示程序逻辑，也可用于描述数据
结构。
• PAD图的符号具有支持自顶向下、逐步求精方
法的作用。开始时设计者可以定义一个抽象的
程序，随着设计工作的深入而用def符号逐步增
加细节，直至完成详细设计。
Design
语言工具--PDL(Program Design Language)
• PDL具有严格的关键字外部语法，用于定义控
制结构和数据结构；另一方面，PDL表示实际
操作和条件的内容语法通常又是灵活自由的以
便可以适应各种工程项目的需要。
• 一般说来PDL是一种“混合”语言，它使用一
种语言（通常是某种自然语言）的词汇，同时
却使用另一种语言（某种结构化的程序设计语
言）的语法。
Design
PDL应当具有以下特征：
• 关键字应有固定语法，以便提供全部结构化构造、数
据说明和模块化特性，并且使结构清晰和易读性好；
• 一种自然语言的自由文法，用来描述处理特点；
• 应有数据说明机制，应该包括既简单的数据结构（标
量与数组），又包括复杂的数据结构（链表或层次结
构）；
• 应有子程序定义与调用方法，用来表示各种方式的接
口描述。
Design
设计工具应具有的属性：
模块性、简明性、便于编辑、机器可读性、
易维护性、强行结构化、自动处理、
数据表示、逻辑验证、编程能力
Design
Design specification
Ⅰ. Scope
A. System objectives
B. Major software requirements
C. Design constraints, limits
Design
Design specification
Ⅱ. Data design
A. Data objects and resultant data structures
B. File and database structures
1. External file structure
a. Logical structure
b. Logical record description
c. Access method
2. Global data
3. File and data cross reference
Design
Design specification
Ⅲ. Architectural design
A. Review of data and control flow
B. Derived program structure
Ⅳ. Interface design
A. Human-machine interface specification
B. Human-machine interface design rules
C. External interface design
1. Interface to external data
2. Interface to external systems or devices
D. Internal interface design rules
Design
Design specification
Ⅴ. Procedural Design
for each module:
A. Processing narrative
B. Interface description
C. Design language description
D. Modules used
E. Internal data structures
F. Comments/restrictions/limitations
Design
Design specification
Ⅵ. Requirements cross-reference
Ⅶ. Test provisions
A. Test guideline
B. Integration strategy
C. Special consideration
Ⅷ. Special Notes
Ⅸ. Appendix
Design
Design review (设计的复审)
• 软件的设计由管理方面的代表、技术开发方面的代表
和其他有关人员（诸如用户、质量保障和软件支持者
等）共同进行复审。
• 对设计进行复审的明显好处是可以比较早地发现软件
的缺陷，从而可以使每个缺陷在进行编程、测试和交
付之前予以纠正，从而显著地降低随后的开发阶段和
维护阶段的费用。
• 设计复审包括正规的审查、非正规的审查和检查三种
方式。
Design
设计复审的标准：
•
•
•
•
•
•
•
•
•
•
易追溯性 该软件设计包括了软件需求规格说明的所有要求了吗？该软
件的每个部件与某个具体的软件要求有关吗？
风险 实现该设计会有很大风险吗？也就是说，没有技术性的突破该设
计也能完成吗？
实用性 该软件对软件要求所确定的问题是一种实用的解决办法吗？
易维护性 该设计是否将导致一个便于维护的系统？
质量 该设计具备一个“好”的软件应有的质量特征吗？
接口 外部和内部的接口已经规定得足够明确了吗？
技术清晰度 该设计的表达方式是否使它便于转化成程序？
选择方案 考虑了其他设计方案了吗？采用什么标准来选择最后方案呢？
限制 软件限制是否现实？与要求相符合吗？
某些具体的问题 该软件便于人控制机器吗？便于测试吗？与其他系统
部分相适应吗？有足够的文档吗？
Design
正规的复审
• 通常是为了评价软件的结构和接口；
• 这种类型的复审的特点在于：设计人员和复审
人员都要认真的准备；有相当多的复审者参加，
他们对该软件研制项目有不同程度的兴趣；
• 管理方面和技术方面站得高，视野开阔；
• 提供正式的设计文档；
• 由通知到开会的时间间隔至少有两个星期。
Design
非正规的复审
所谓非正规的复审指的是从临时通知的碰
头会到有关同事参加的比较有组织的复审这整
个范围而言的，一般由通知到开会的时间间隔
只有二至三天。
Design
设计的检查
• 检查具有正规的复审和非正规的复审两方面的
特点；
• 从复审的形式与内容上看，检查方法是相当正
规的--有专门的职责、活动安排、交付的文档、
核对表以及管理办法等等，一切都是事先规定
好的；
• 然而，涉及到的人员以及他们的相互联系则是
比较随便的，通常都以小组进行活动。
Code Generation (编码)
程序设计语言的性能和程序的编码
风格，在很大程度上影响着软件的质量
和维护性能。
• 程序设计语言性能的讨论
• 程序设计语言的分类与选择
• 程序编码风格 (Code Style)
Code Generation
程序设计语言性能的讨论
• 软件心理学观点
（1）一致性：表示语言使用符号的兼容程度、约束条件
及语法和语义上的例外等等。
（2）歧义性：歧义性导致程序员对程序理解的混乱。
（3）简洁性：对用该语言编程的程序员必须记忆的信息
量的衡量。
（4）局部性和线性：人们的记忆和辨别能力分为联想和
顺序两个方面。联想能使我们整体地记住和辨别某件
东西。顺序记忆能从回忆序列中找出一个元素。局部
性是语言的联想性；线性是语言的顺序性。
Code Generation
程序设计语言性能的讨论
• 工程观点
（1）使设计易于代码翻译；
（2）编译程序的功效；
（3）源代码的可移植性；
（4）开发工具的可利用性；
（5）源代码的可维护性。
• 技术性能观点
（1）复杂数据结构 （2）实时系统 （3）特殊应用领域
Code Generation
程序设计语言的分类
（按语言抽象级别分类）
• 低级语言：机器语言，汇编语言
• 高级语言：与机器无关，实现性语言
• 甚高级语言：高抽象级，有用以描述功
能的成分
Code Generation
程序设计语言的分类
（按应用领域分类）
• 通用语言
• 专用语言
Code Generation
程序设计语言的分类
（按语言成分性质分类）
• 顺序语言：只含顺序成分
• 并发语言：含有并发成分
• 分布式语言：考虑了分布式计算要求
• 网络语言：考虑了网络计算要求
Code Generation
程序设计语言的分类
（按作用方式分类）
• 命令式语言：不论其描述“做什么”还
是“怎样做”，相应描述的组成部分是
命令式的，先做什么、后做什么都规定
好了明确的次序。
• 作用式语言：从相应的描述中不能明显
看出其组成部分执行的先后次序。
Code Generation
程序设计语言的分类
（按描述级别分类）
• 功能性语言
• 设计性语言
• 实现性语言
Code Generation
程序设计语言的分类
（按模拟客观世界的角度分类）
• 对象式语言（面向对象语言）
• 非对象式语言
Code Generation
程序设计语言的分类
（按其它方式分类）
• 函数式语言
• 逻辑式语言
Code Generation
一般而言，衡量某种程序语言是否适合于
特定的项目，应考虑下面一些因素：
•
•
•
•
•
•
•
应用领域
算法和计算复杂性
软件运行环境
用户需求中关于性能方面的需要
数据结构的复杂性
软件开发人员的知识水平
可用的编译系统
Code Generation
• 编码风格(Code Style)在很大程度上影响
着程序的易读性、易测试性和易维护性，
鉴于软件的绝大部分成本消耗在测试和
维护阶段，提倡好的编码风格，努力提
高易测试性和易维护性极其重要。
• 好的编码风格是在不影响性能的前提下，
有效地编排和组织程序，以提高易读性
和易维护性。
Code Generation
为了编制出清晰、紧凑、高效的程
序，一般应依次考虑下列原则：
（1）编制易于修改和维护的代码
（2）编制易于测试的代码
（3）必须将编程和编文档的工作统一起来
（4）编程中采用统一的标准和约定，降低程序复杂性
（5）限定每一层的副作用，减少耦合度
（6）尽可能地复用
Code Generation
编码风格(Code Style)包括以下三个方面：
• 代码文件 (Code Documentation)
• 数据说明 (Data Declaration)
• 语句结构 (Statement Construction)
Code Generation
代码文件
• 恰当的标识符
• 适当的注解
序言性注解
功能性注解
• 良好的程序视觉组织
Code Generation
数据说明的简单原则：
• 数据说明的次序应该标准化；
• 当多个变量同时被说明时，应当按字母顺序排
列这些变量；
• 若设计时使用了一个复杂的数据结构，则应该
用注解说明用程序设计语言实现它的特点和方
法。
Code Generation
语句结构要保持尽可能的简单，应遵循以下原则：
• 程序要清晰直观，不要过于巧妙；
• 用一定的原则指导控制结构的使用；
（1）不用空THEN语句；
（2）避免THEN--IF结构形式；
（3）不要嵌套太深；
（4）避免不必要的转移；
（5）有原则地使用GOTO；
（6）采用标准的结构形式弥补语言的不足。
• 使用括号清晰地表示逻辑表达式和算术表达式；
• 利用加空白或易读的符号来清晰地表示语句的内容；
• 心理换位“如果这个程序不是我写的，我能看懂它吗？”
Code Generation
程序设计支撑环境
现在编程过程大多在一组CASE工具
的支持下进行，这组工具辅助完成编辑、
编译、调试、项目管理等一系列任务，
这组工具有机集成在一起形成程序设计
支撑环境。
Code Generation
程序设计支撑环境应该具备的特性：
• 通用性：适用于不同的语言、不同的应用领域和开发方法；
• 适应性：通过开关设置，能配制出不同需要的程序设计支撑环境
实例；
• 开放性：能方便地增加新工具；
• 支持复用：能支持可复用模块的存储、索引和查找；
• 自控性：保证自身操作的正确与协调；
• 自带数据库：提供数据库机制，存储、管理已开发的软件产品；
• 保证质量：有助于提高所开发软件的质量；
• 吸引用户：用户愿意使用；
• 具有市场竞争力：能真正提高软件生产力。
Testing
• Software testing is a critical element of software quality
assurance and represents the ultimate review of
specification, design, and code generation.
• The importance of software testing and its implications
with respect to software quality cannot be overemphasized.
• It is not unusual for a software development organization
to expend between 30 and 40 percent of total project effort
on testing. In the extreme, testing of human-rated software
can cost three to five times as much as all other software
engineering steps combined!
Testing
• In fact, testing is the one step in the
software process that could be viewed as
destructive rather than constructive.
Testing
Testing Objectives
• Testing is a process of executing a program with the intent
of finding an error.
• A good test case is one that has a high probability of
finding an as-yet-undiscovered error.
• A successful test is one that uncovers an as-yetundiscovered error.
Testing
Testing Principles
• All tests should be traceable to customer requirements.
• Tests should be planned long before testing begins.
• The Pareto principle applies to software testing.
(测试发现错误中的80%很可能起源于程序模块中的20%)
• Testing should begin “in the small” and progress toward
testing “in the large.”
• Exhaustive testing is not possible.
• To be most effective, testing should be conducted by an
independent third party.
Testing
Testability
•
•
•
•
•
•
•
Operability
Observability
Controllability
Decomposability
Simplicity
Stability
Understandability
Testing
A engineered product can be tested in one of
two ways:
• Knowing the specified function that a product has been
designed to perform, tests can be conducted that
demonstrate each function is fully operational while at the
same time searching for errors in each function. (Blackbox testing)
• Knowing the internal workings of a product, test can be
conducted to ensure that “all gears mesh,” that is internal
operations are performed according to specifications and
all internal components have been adequately exercised.
(White-box testing)
Testing
Black-box testing (黑箱测试、功能测试)
• When computer software is considered, black-box testing
alludes to test that are conducted at the software interface.
• Although they are designed to uncover errors, black-box
test are used to demonstrate that software functions are
operational, that input is properly accepted and output is
correctly produced, and that the integrity of external
information is maintained.
• A black-box test examines some fundamental aspect of a
system with little regard for the internal logical structure of
the software.
Testing
穷尽功能测试
例：一个程序需3个整型的输入数据，若计
算机的字长为16位，则每个数据可能取
的值有2 个，3个数的排练组合共有
2  2  2 = 2  3  10 （种）
若每执行一次需1毫秒，则需1万年。
16
16
16
16
48
14
Testing
White-box testing (白箱测试、结构测试)
• White-box testing of software is predicated on
close examination of procedural detail.
• Logical paths through the software are tested by
providing test cases that exercise specific sets of
conditions and/or loops.
• The “status of the program” may be examined at
various points to determine if the expected or
asserted status corresponds to the actual status.
Testing
穷尽结构测试
例：一段程序对嵌套的IF语句执行20次，共有5 10 条通
路，若每执行一次需1毫秒，则需3000年。
20
14
Testing
Test case design
测试用例设计的基本目标是确定一组测试数据，
其发现一个或一类错误的概率极高。
• White-box testing methods
• Black-box testing methods
Testing
Test case design (White-box testing Methods)
Using white-box testing methods, the software
engineer can derive test cases that
• (1) guarantee that all independent paths within a module
have been exercised at least once,
• (2) exercise all logical decisions on their true and false
sides,
• (3) execute all loops at their boundaries and within their
operational bounds, and
• (4) exercise internal data structures to ensure their validity.
Testing
逻辑覆盖
• 语句覆盖
• 判定覆盖
• 条件覆盖
• 判定/条件覆盖
• 条件组合覆盖
• 路径覆盖
Testing
现给出如下程序，
#include(stdio.h);
main(){
float A, B, X;
scanf(“%f %f %f”, &A, &B, &X);
if (A>1)&&(B==0) X=X/A;
if (A==2)||(X>1) X=X+1;
printf(“%f”, X)}
设计该程序的测试数据以分别满足语句覆盖、判定覆
盖、条件覆盖、条件组合覆盖和路径覆概的逻辑覆盖
标准。
Testing
语句覆盖：选取足够多的测试数据，使被测试
程序中每个语句至少执行一次。
为使每个语句都执行一次，
程序的执行路径应是sacbed：
A=2, B=0, X=4
s
入口
a
(A>1)&&(B==0）
c
X = X /A
e
b
问题：若把b点的判定错写为
(A==2)||(X<1)
(A==2)||(X>1）
d 返回
X=X+1
Testing
判定覆盖：选取足够多的测试数据，使被测试
程序中不仅每个语句至少执行一次，而且每个
判定的每种可能的结果都至少执行一次。
s 入口
a
能够分别覆盖路径sacbed和sabd或(A>1)&&(B==0）
sacbd和sabed的两组测试数据，都满
b
足判定覆盖标准：
(A==2)||(X>1）
（1）A=3, B=0, X=3 (sacbd)
（2）A=2, B=1, X=1 (sabed)
d 返回
c
X = X /A
e
X=X+1
Testing
条件覆盖：选取足够多的测试数据，使被测试
程序中不仅每个语句至少执行一次，而且每个
判定表达式中的每个条件都取到各种可能的结
s 入口
果。
a
在a点：A>1, A1, B=0, B≠0；
在b点：A=2, A ≠2, X>1, X 1。
(A>1)&&(B==0）
b
(A==2)||(X>1）
（1）A=2, B=0, X=4 (sacbed)
（2）A=1, B=1, X=1 (sabd)
d 返回
c
X = X /A
e
X=X+1
Testing
判定/条件覆盖：选取足够多的测试数据，使得判
定表达式中的每个条件都取到各种可能的结果，
而且每个判定表达式也都取到各种可能的结果。
s
入口
a
（1）A=2, B=0, X=4 (sacbed)
（2）A=1, B=1, X=1 (sabd)
(A>1)&&(B==0）
b
(A==2)||(X>1）
d 返回
c
X = X /A
e
X=X+1
Testing
条件组合覆盖：选取足够多的测试数据，使得判
定表达式中条件的各种可能组合都至少出现一次。
有八种可能的条件组合：
（1）A>1, B=0；（2）A>1, B ≠0；
（3）A 1, B=0；（4） A 1, B ≠0；
（5）A=2, X>1；（6）A=2, X 1；
（7） A ≠ 2, X>1；（8）A ≠ 2, X 1。
测试数据：
（1）A=2, B=0, X=4 (sacbed, 1,5)
（2）A=2, B=1, X=1 (sabed, 2,6)
（3）A=1, B=0, X=2 (sabed, 3,7)
（4）A=1, B=1, X=1 (sabd, 4,8)
s
入口
c
a
(A>1)&&(B==0）
b
(A==2)||(X>1）
d 返回
X = X /A
e
X=X+1
Testing
路径覆盖：选取足够多的测试数据，使得程序的
每条可能路径都至少执行一次（若程序图中有环，
则每个环至少经过一次）。
s
入口
a
(A>1)&&(B==0）
测试数据：
（1）A=1, B=1, X=1 (sabd)
（2）A=1, B=1, X=2 (sabed)
（3）A=3, B=0, X=1 (sacbd)
（4）A=2, B=0, X=4 (sacbed)
b
(A==2)||(X>1）
d 返回
c
X = X /A
e
X=X+1
Testing
Test case design (Black-box testing)
Black-box testing attempts to find errors in the
following categories:
•
•
•
•
(1) incorrect or missing functions,
(2) interface errors,
(3) errors in data structures or external database access,
(4) behavior or performance errors, and
• (5) initialization and termination errors.
Testing
Test case design (Black-box testing)
Test are designed to answer the following questions:
•
•
•
•
•
How is functional validity tested?
How is the system behavior and performance tested?
Is the systems particularly sensitive to certain input values?
How are the boundaries of a data class isolated?
What effect will specific combinations of data have on
system operation?
Testing
Test case design (Black-box testing)
• Equivalence partitioning （等价划分）
• Boundary value analysis （边界值分析）
Testing
等价划分
• 等价划分是用黑箱法设计测试用例的一种技术。
• 穷尽的黑箱测试需要使用所有的有效和无效输入数据
来测试系统，通常这是不现实的。因此只能选取小量
有代表性的输入数据，以期用较小的代价暴露较多的
程序错误。
• 如果把所有可能的输入数据划分成若干个等价类，则
可以合理地作出下述假定：每类中的一个典型值在测
试中的作用与这一类中所有其他值的作用相同。因此，
可以从每个等价类中只取一组数据作为测试数据。这
样选取的测试数据最有代表性，最可能发现程序中的
错误。
Testing
使用等价划分法设计测试用例的关键在于划分输入数据
的等价类，以下是有助于等价类划分的启发式规则：
（1）若规定了输入数据的个数，则类似地可以划分出一个有效的等价类和
两个无效的等价类；
（2）若规定了输入值的范围，则要划分出一个有效的等价类（输入值在此
范围），两个无效的等价类（输入值小于最小值或大于最大值）；
（3）若规定了输入数据的一组值，而且程序对不同输入值做不同的处理，
则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类
（任意一个不允许的输入值）；
（4）若规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类
（符合规则）和若干个无效的等价类（从不同角度违反规则）；
（5）若规定了输入数据为整型，则可以划分出正整数、零和负整数三个有
效的等价类；
（6）若程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。
Testing
边界值分析
• 从实践中总结出的经验表明，处理边界情况时
程序最容易发生错误。例如，许多程序错误出
现在下标、数据结构和循环等的边界附近。因
此设计使程序运行在边界附近的测试用例，暴
露程序错误的可能性更大一些。
Testing
测试用例设计策略
• 用黑箱法设计基本的测试数据，再用白
箱法补充一些必要的测试数据。在任何
情况下都应该使用边界值分析方法。
Testing
Testing Strategies
•
•
•
•
Unit testing (Code)
Integration testing (Design)
Validation testing (Requirements)
System testing (System engineering)
Testing
Unit testing (单元测试)
• Unit testing focuses verification effort on the smallest unit
of software unit of software design - the software
component or module.
单元测试集中检验软件设计中最小单元--模块。
• Using the component-level design description, important
control paths are tested to uncover errors within the
boundary of the module.
根据详细设计的说明，应测试重要的控制路径，力求在模块范围
内发现错误。
Testing
Unit testing
• The relative complexity of tests and uncovered errors is
limited by the constrained scope established for unit testing.
由于测试范围有限，测试不会太复杂，所能发现的 错误也是有限
的。
• The unit test is white-box oriented, and the step can
conducted in parallel for multiple components.
单元测试总是采用白箱测试方法，而且可以多个模块并行进行。
• Unit testing is normally considered as an adjunct to the
coding step.
单元测试和编码属于软件开发的同一阶段。
Testing
Content of unit testing
•
•
•
•
•
Interface
Local data structures
Boundary conditions
Independent paths
Error handling paths
Testing
Driver
Interface
local data structures
Boundary conditions
Independent paths
Error handling paths
Module
to be
tested
Stub
Unit test
environment
Stub
Test cases
RESULTS
Testing
Unit testing environment
• Because a component is not a stand-alone program, driver
and stub software must be developed for each unit test.
• A driver (驱动模块) is nothing more than “main program”
that accepts test case data, passes such data to the
component (to be tested), and prints relevant results.
• Stubs (承接模块) serve to replace modules that are
subordinate (called by) the component to be tested. A stub
uses the subordinate module’s interface, may do minimal
data manipulation, prints verification of entry, and returns
control to the module undergoing testing.
Testing
Unit testing environment
• Drivers and stubs represent overhead. That is both are
software that must be written (formal design is not
commonly applied) but that is not delivered with the final
software product.
• Unit testing is simplified when a component with high
cohension is designed. When only on function is addressed
by a component, the number of test cases is reduced and
errors can be more easily predicted and uncovered.
Testing
Integration testing (组装测试)
• Integration testing is a systematic technique for
constructing the program structure while at the
same time conducting tests to uncover errors
associated with interfacing.
在把经过单元测试的模块按照设计要求组装起来的过
程中进行测试，重点查找与接口有关的错误。
Testing
The errors associated with interfacing contain：
• Data can be lost across an interface.
数据穿过接口时可能丢失。
• One module can have an inadvertent, adverse affect on another.
某个模块对另一个模块可能产生不利的影响。
• Subfunctions, when combined, may not produce the desired major
function.
把子功能组合起来可能不产生预期的主功能。
• Individually acceptable imprecision may be magnified to unacceptable
levels.
个别原可以接受的误差可能累计到不能接受的程度。
• Global data structures can present problems.
全程数据结构可能有问题。
Testing
Integration testing ways
• Top-down integration testing
(自顶向下组装测试方法)
• Bottom-up integration testing
(自底向上组装测试方法)
Testing
Integration testing ways
• Top-down integration testing
(自顶向下组装测试方法)
• Bottom-up integration testing
(自底向上组装测试方法)
Testing
Top-down integration testing
• Top-down integration testing is an incremental approach to
construction of program structure. Modules are integrated
by moving downward through the control hierarchy,
beginning with the main control module (main program).
Modules subordinate to the main control module are
incorporated into the structure in either a depth-first or
breadth-first manner.
自顶向下组装测试方法：按照控制的结构，从主控模块（主程序）
开始，向下逐个把模块连接起来进行测试。把附属于主控模块的
子模块孙模块等等组装起来的方式有两种，先纵深组装法和先横
宽组装法。
Testing
Testing process for top-down integration:
• The main control module is used as a test driver and stubs
are substituted for all components directly subordinate to
the main control module.
主控模块用做为测试驱动模块，直接附属于主控模块的各个模块
全部用承接模块代替。
• Depending on the integration approach selected (ie. Depth
or breadth first), subordinate stubs are replaced one at a
time with actual components.
按照所选的组装法（先纵深或先横宽）每次用一个真模块取代一
个附属的承接模块。
Testing
Testing process for top-down integration:
• Tests are conducted as each component is integrated.
在装入每个真模块后进行一次测试。
• On completion of each set of tests, another stub is replaced
with the real component.
做完每一次测试后再用一个真模块代替另一个承接模块。
• Regression testing may be conducted to ensure that new
errors have not been introduced.
必要时进行回归测试（即重新再做过去的全部或部分测试）以保
证新加的模块没有引起新的错误。
Testing
Bottom-up integration testing
• Bottom-up integration testing begins construction and
testing with atomic modules (i.e., components at the lowest
levels in the program structure). Because components are
integrated from the bottom up, processing required for
components subordinate to a given level is always
available and the need for sub is eliminated.
自底向上组装测试方法：按照控制结构，从最基本的模块（即在
软件结构中最低层的模块）开始进行组装及测试。正是因为是从
最低层进行组装，在逐步处理以上层次的模块时所需要的子模块
总是可以得到的，所以不再需要承接模块了。
Testing
Testing process for bottom-up integration:
• Low-level components are combined into clusters that
perform a specific software subfunction.
把低层模块组合起来形成某个特定的软件子功能簇。
• A driver is written to coordinate test case input and output.
编写一个驱动模块以安排测试数据的输入输出。
• The cluster is tested.
对簇进行测试。
• Drivers are removed and clusters are combined moving
upward in the program structure.
拆去各个小簇的驱动模块，把几个小簇合并成大簇，重复以上步
骤。
Testing
Regression testing (回归测试)
• In the context of an integration test strategy,
regression testing is the re-execution of some
subset of tests that have been conducted to ensure
that changes have not propagated unintended side
effects.
Testing
组装测试方法比较
• 自顶向下组装法：不需要驱动模块；能够在测试阶段
早期验证系统的主要功能，早期发现接口错误；需要
较多的承接模块，可能遇到与之相联系的测试困难；
低层关键模块中的错误发现较晚。
• 自底向上组装法：不需要承接模块；需要较多的驱动
模块；在最后一个模块装入之前，软件实体并不存在。
• 一般使用两种方法的结合，测试阶段早期采用自顶向
下组装法，后期采用自底向上组装法，很多情况下二
者可以同时进行。
Testing
Integration test documentation
• An overall plan for integration of the software and
a description of specific tests are documented in a
test specification.
• This document contains a test plan, and a test
procedure, is a work product of the software
process, and becomes part of the software
configuration.
Testing
Test specification（测试说明书）
1. 测试范围
2. 测试计划
• 测试方面（把测试划分为几个方面，分别测试软件的各种特性）
• 进度
• 额外软件（驱动模块和承接模块）
• 环境与资源
3. 测试步骤
• 第n测试阶段的说明：组装的次序；测试目的和应测的模块；专用
的工具或技术；额外软件的说明；测试用例数据。
• 第n测试阶段的预期结果
4. 实际测试结果
5. 参考资料
6. 附录
Testing
Validation testing (有效性测试)软件有效性：当软件的
•
•
•
•
•
功能和性能如同用户合理期待的那样，则软件是有效的。
问题：怎样算是合理的期望（需求说明）；谁是公断人（测试人
员）。
方法：黑箱测试法。
标准：全部的功能要求都得到满足；全部的性能要求都达到了；
文档是正确的并且便于使用；其它要求也达到了（包括易维护性、
易移植性、兼容性、出错自动恢复等）。
可能出现的结果：功能与性能与技术要求一致；发现与技术要求
不一致的地方（与用户协商）。
软件系列文件复审：确认软件系列文件的各个部分都已做好，已
经编目，并有必要的细节说明，作为以后维护阶段的基本资料。
Testing
System testing (系统测试)
• Software is only one element of a large computer-based
system.
软件仅仅是基于计算机的系统的一个组成部分。
• Software is incorporated with other system elements, and a
series of system integration and validation tests are
conducted.
系统测试是指把软件与系统的其他要素合并，并进行一系列的系
统组装及有效性测试。
Testing
System testing
• System tests fall outside the scope of the software process and are not
conducted by solely by software engineering. However, steps taken
during software design and testing can greatly improve the probability
of successful software integration in the larger system.
系统测试已经落到了软件工程范畴之外，并且极少由软件开发者
承担，但是在软件设计和测试阶段所进行的工作将有助于成功地
把软件合并到更大的系统之中。
• A classic system testing problem is “finger-pointing”. This occurs
when an error is uncovered, and each system element developer
blames the other for the problem.
典型的系统测试问题是“相互指责”，当发现了一个错误以后，
各个系统部分的开发者都职责别人的部分有毛病。
Testing
What software engineers do in system testing:
• design error-handling paths that test all information coming from other
elements of the system;
安排出错处理路径，以测试从系统的其他部分传来的全部信息；
• conduct a series of tests that simulate bad data or other potential errors
at software interface; 进行一系列测试，模仿在软件接口处出现的
“坏的数据”或其他可能的错误；
• record the results of tests to use as “evidence” if finger-pointing does
occur. 把测试结果记录下来，如果出现互相指责的情况时，就可
以提出确实的根据；
• participate in planning and design of system tests to ensure that
software is adequately tested.参与系统测试计划与设计，以保证充
分地测试软件系统。
Testing
Criteria for Completion of Testing
• 只有当测试充分度十分接近100%时，才能使测
试发现错误的能力得到发挥。
Testing
Verification and Validation
• Software testing is one element of a broader topic that is
often referred to as verification and validation (V&V).
• Verification refers to the set of activities that ensure that
software correctly implements a specific function.
• Validation refers to a different set of activities that ensure
that the software that has been bulit is traceable to
customer requirements.
Testing
Verification and Validation
• Verification: “Are we building the product right?”
Validation:
“Are we building the right product?”
• The definition of V&V encompasses many of the activities
that we have referred as software quality assurance (SQA).
• Although testing plays an extremely important role in V&V,
many other activities are also necessary.
Testing
Debugging ( An ART)
• Debugging occurs as a consequence of successful testing.
That is, when a test case uncovers an error, debugging is
the process that results in the removal of the error.
• Although debugging can and should be an orderly process,
it is still very much an art.
• The external manifestation of an error and the internal
cause of the error may have no obvious relationship to one
another.
• The poorly understood mental process that connects a
symptom to a cause is debugging.
Testing
Test
cases
Results
Execution of cases
Additional
tests
Regression
tests
Suspected
causes
Corrections
The Debugging Process
Debugging
Identified
causes
Maintenance
• Any work done to change a software system after
it is in operation is considered to be maintenance.
• 55% - 80% of software budget is spent on
maintenance.
• Maintenance is more difficult than development
for software system, and requires more creative
works.
Maintenance
• Corrective maintenance （矫正性维护）
• Adaptive maintenance （适应性维护）
• Perfective maintenance （完善性维护）
• Preventive maintenance （预防性维护）
Maintenance
影响软件维护的因素：
• 系统的大小
• 系统的年龄
• 结构的合理性
• 应用类型和任务难度
• 其它（程序设计语言，数据库等）
Maintenance
软件维护的步骤：
• 理解现有系统
• 修改现有系统
• 重新确认系统
Maintenance
软件维护的步骤：
•
•
•
•
•
•
•
检查用户的需求和说明书；
同用户和开发者进行商讨；
检查程序和文档；
确定程序错误的位置和性质；
研究程序的修改可行性和修改可能引起的副作用；
对改变部分进行编码；
修改程序文档和程序库。
Maintenance
修改程序的原则：
•
•
•
•
不损害程序的质量；
保持程序风格的一致性和功能的完整性；
应有利于将来程序的改变；
对用户没有不利的影响。
Summary for Waterfall Model
•
•
•
•
概念上讲直观地描述了软件开发的全貌。
已经存在许多经验和成功的实例。
缺乏足够的描述能力。
模型假设了一个近乎正确的过程，当出
现了问题时，解决它们就很困难。