SSD9: Software Specification, Testing, and

Maintenance
 Unit 5. Object-Oriented Design (OOD)
 5.1 OOD Principles
 5.2 OOD Practice 1
 5.2.1 Sequence Diagrams in UML
 5.2.2 Collaboration Diagrams in UML
 5.2.3 Detailed Class Diagrams in UML
 5.3 OOD Practice 2
 5.3.1 Client-Object Diagrams in UML
 5.3.2 Specifying Modular Interfaces
 5.3.3 Detailed Design Specification
 5.3.4 Formal Design Review
 Assessments
 Multiple-Choice Quiz 5
 From last phase , we get ……
  object-oriented analysis ( produce)
 preliminary class model
 dynamic model
  (as its input) object-oriented design
 What we will do in object-oriented design phase
 the preliminary class model is refined in a detailed class
diagram,
 the precise dynamic behavior of the system is specified in a
set of interaction diagrams.
 The system‘s behavior is partitioned into modules (objects
and methods) during the architectural design （体系结构设
计） ,
 the details of individual objects and methods are specified in
the detailed design.
 The final milestone in the design process is the design review,
 verifies that the design is internally coherent and reflects the system
requirements as captured by the analysis specifications.
 5.1 OOD Principles
 5.1.1 Cohesion and Coupling
 5.1.2 Approaches to Software Design
 5.1.3 The Role of Architectural Design
 5.1.4 Detailed Design
 5.1.5 Design Testing
 5.1.1 Cohesion and Coupling
 One of the main activities of software design is to
 partition the functionalities identified in the requirements specification and
analysis phases into specific software modules.
 In traditional structured programming,
 a software module might correspond to a particular function or program in
a particular language.
 In object-oriented programming
 a module most often corresponds to an object, or perhaps a method
associated with a particular object.
 Many different ways to partition a system into modules
 Software engineers consider two important characteristics of
the modules
 Cohesion
 coupling
 Concepts
 Modularity 模块化
 Cohesion 内聚
 Coupling 耦合
 In the early history of programming
 most programs
 consisted of a single block of code with numerous sections;
 Besides: sequential program execution. 顺序执行
 Have: program control was transferred from section to
section with goto statements goto 跳转
 Such early systems suffered from being difficult to
understand and maintain.
 软件规 模较小，没有 明确的划分 模块
 Modularity
 In modern approaches to programming (OOP)
 partitioning a software system into separate modules
 Why partitioning them? Any advantages?
 several important advantages ， to improve……
 understandability:
 system code are
 grouped together according to function
 stored separately,

 then easier to understand what each part of the system does.

 testability:
 Software that is partitioned into modules
 be tested both at the modular level and at the system level
 making it easier to isolate the cause of system failures.
 maintainability:
 it is much simpler to remove, replace, or rewrite a particular
part of the system's functionality, with minimal impact on the
other parts of the system.
 examples
 The examples show how difficult it would be to
understand or extend a computer hardware design
 if its logic was partitioned into three chips consisting of
AND, OR, and NOT gates
 instead of partitioning the logic into functional modules, such
as Registers, ALU, and shifter.
Textbook p.131
 模块的独立性

 模块（ Module, 又称“组件” ）

 具有如下三个基本属性 :
 功能：描述该模块实现什么功能
 逻辑 ：描述模块内部怎么做

 状态 ：该模块使用时的环境和条件
 模块的独立性
 在描述一个模块时，还必须按模块的外
部特性与内部特性分别描述
 模块的外部特性
 模块的模块名
 参数表 （其中的输入参数和输出参数
）
 以及给程序以至整个系统造成的影响

 模块的内部特性
 完成其功能的程序代码和仅供该模
 模块的独立 性

 模块独立性 , 是指软件系统中每个模
块只涉及软件要求的具体的子功能 , 而
和软件系统中其它的模块的接口是简单
的
 例如 , 若一个模块只具有单一的功能
且与其它模块没有太多的联系 , 则称
此模块具有模块独立性
 一般采用两个准则度量模块独立性。
即模块间 耦合 和模块 内聚
 模块的独立性

 耦合是模块之间的互相连接的紧密程
度的度量。
 内聚是模块功能强度 ( 一个模块内部
各个元素彼此结合的紧密程度 ) 的度量
。
 模块独立性比较强的模块应是高内聚
低耦合的模块。
 Cohesion
 The term cohesion is used to
 refer to the degree of similarity or interaction among the
action carried out by a particular module.
 high cohesion
 a set of operations that are logically grouped together.
 the operations in a module with operate on similar data
 low cohesion
 completely independent （完全无关） functions are
grouped together in an arbitrary manner.
 the operations in a module operate on different kinds of data
elements.
different types of cohesion
 Informational cohesion
 informational cohesion
 if a module performs a number of actions,
 each with its own entry point
 independent code for each action
 all performed on the same data structure.
 Informational cohesion
 The concept of informational cohesion seem very
familiar, why?
 it meet the essence of objects in an object-oriented framework.
 E.g.,
 properly implemented classes in Java have all the
characteristics of informational cohesion:
 the actions are the object methods;
 each action (method) has its own entry point (method signature)
and independent code (method definition);
 the methods typically operate on the same data structure (the
class variables inside the object).
 Functional cohesion
 functional cohesion
 A module that performs exactly one action or achieves a
single goal
 Functional cohesion
 is also a very important type of modularity, for it describes
modules that are so tightly cohesive that they can be reused
anywhere.
 E.g.,
 global subroutines that are called by many different programs
 disk I/O system calls.
 slow trend towards for informational cohesion
 It is important to note that the evolution of object-
oriented technology did not happen overnight with
the introduction of a particular object-oriented
language;
 in fact, there has been a slow trend towards
programming languages with better built-in support
for informational cohesion, which is a property of
software design (rather than a particular
programming language).
 Read your textbook ！ (p.137 fig 7.7. )
 模块内聚

c
 功能内聚 (Functional Cohesion)

 一个模块中各个部分都是完成某一具体

功能必不可少的组成部分，
 或者说该模块中所有部分都是为了完成

一项具体功能而协同工作，紧密联系，
不可分割的。
 则称该模块为功能内聚模块。
 信息内聚 (Informational Cohesion)

 这种模块完成多个功能，各个功能都在
同一数据结构上操作，每一项功能有一
个唯一的入口点。
 这个模块将根据不同的要求，确定该执
行哪一个功能。
 由于这个模块的所有功能都是基于同一
个数据结构
 则称它是一个信息内聚模块。
信息内聚实例
 信息内聚 (Informational Cohesion)

 信息内聚模块可以看成是多个功能内聚

模块的组合，并且达到信息的隐蔽。
 即把某个数据结构、资源或设备隐蔽在

一个模块内，不为别的模块所知晓。
 联想一下类的定义……
 通信内聚 (Communication Cohesion)

 如果一个模块内各功能部分都使用了

相同的输入数据，或产生了相同的输
出数据，则称之为通信内聚模块。
 通常，通信内聚模块是通过数据流图

来定义的。
 过程内聚（ Procedural Cohesion ）

 使用流程图做为工具设计程序时，把

流程图中的某一部分划出组成模块，
就得到过程内聚模块。
 例如
 把流程图中的循环部分、判定部分、

计算部分分成三个模块，这三个模块
都是过程内聚模块。
 旋转信号

读 确定
旋转 加/ 箭头指
信号 减速 示
SPS
∆SPS 产生
燃料流 收集 上箭头
传感器信 加 /减
和求 速 示
号 平均
水平线
SPS
读和 下箭头
校核 转换
成
rpm
燃 流 转/
分 计算
rpm 里程 英里 产生
计算 计算 里程
gph mph, 示 示
超速 超速值
gph 值 发出
mph
mph 铃声
计算 铃声
燃料 产生
消耗 mph
mpg 示
mph 示
产生
mpg
示 mpg 示
 时间内聚（ Classical Cohesion ）

 时间内聚又称为经典内聚。这种模块

大多为多功能模块，但模块的各个功
能的执行与时间有关，通常要求所有
功能必须在同一时间段内执行。
 例如
 初始化模块, 申请各类运行资源
 终止模块，释放资源
 逻辑内 聚（ Logical Cohesion ）

这种模块把几种
相关的功能组合
在一起，每次被
调用时，由传送
给模块的判定参
数来确定该模块
应执行哪一种功
能。
 巧合内 聚（ Coincidental Cohesion ）

( 偶然内聚 ) 。当模块内各
 巧合内聚
部分之间没有联系，或者即使有联系
，这种联系也
很松散，
则称这种模
块为巧合内
聚模块，它
是内聚程度
最低的模块。
 Coupling
 The term coupling is used to
 refer to the degree of interaction between two modules.
 In the earlier history of programming
 it was quite common for modules to modify data or even
program statements inside other modules.
 In modern terms
 this would be equivalent to a method in one Java class changing
the program code inside another method in a different class —
at run time!
 when memory was at a premium( 内存少 ) and
processors were very slow( 处理器 慢 )
 this content coupling may have some advantages
 But, it resulted in programs that were difficult (if not
impossible) to understand, debug, and modify over time.
 Other types of coupling
 Common coupling:
 Two modules can both access and modify a global data structure.
 Control coupling:
 The results of one module influence the subsequent actions
(control decisions) of another module.
 Stamp coupling:
 A complex data structure is passed from one module to another,
but the called module only utilizes some subset of the data passed
to it.
 Data coupling:
 All arguments passed to a called module are either simple data
types or complex data structures where all the data elements are
utilized.
 Two modules exhibit a low degree of coupling if they are not
coupled at all, or if only data coupling exists between them.
 Data coupling can be thought of as the simplest way for two
modules to share data, in a manner that is easier to
understand, debug, and modify over time.
 All other kinds of coupling are less desirable to some degree.
 Common-coupled modules are hard to debug because it can be
difficult to determine the cause of corruption in the global data
structure.
 Control-coupled modules are difficult to debug or extend
because changes in one module can have unforeseen
consequences in another module.
 In addition, stamp-coupled modules are hard to understand
because not all the data passed between modules is actually
needed.
模块间的耦合
 非直接耦合 (Nondirect Coupling)

两个模块之间没有直接关系，它们
之
间的联系完全是通过主模块的控制
和
调用来实现的。
非直接耦合的
模块独立性最
强。
 数据耦 合 (Data Coupling)

一个模块访问另一个模块时，彼此之间
是通过简单数据参数 ( 是个简单变量 ,
不是控制参数、公共数据结构或外部变
量 ) 来交换输入、输出信息的。
属松散耦合。 计算 顾客帐单
借款数
利息 借 金
时间 还 额

计算借还金额
 标记耦合 (Stamp Coupling)

一组模块通过参数表传递记录信息，就
是标记耦合。这个记录是某一数据结构
的子结构，而不是简单变量。
模块之间具有相同的数据结构
计算客 户电话费

通话记 录 结果
记录
基 实

础 际

费 费
 控制耦合 (Control Coupling)

如果一个模块
通过传送开关
标志、名字等
控制信息，
明显地控制选
择另一模块的
功能，就是控
制耦合。
 外部耦 合（ External Coupling ）

一组模块都访问同一全局简单变量而不
是同一全局数据结构，而且不是通过参
数表传递该全局变量的信息，则称之为
外部耦合。
 公共耦合（ Common Coupling ）

 若一组模块都访问同一个公共数据环境
，则它们之间的耦合就称为公共耦合。
 公共的数据环境可以是
 全局数据结构
 共享的通信区
 内存的公共覆盖区等
 公共耦合（ Common Coupling ）

 公共耦合的复杂程度随耦合模块的个数
增加而显著增加。若只是两模块间有公
共数据环境，则公共耦合有两种情况。
松散公共耦合和紧密公共耦合。
 内容耦合 (Content Coupling)

 如果发生下列情形，两个模块之间就发
生了内容耦合
 (1) 一个模块直接访问另一个模块的内
部数据 ;
 (2) 一个模块不通过正常入口转到另一
模块内部 ;
 (3) 两个模块有一部分程序代码重迭
( 只可能出现在汇编语言中 );
 (4) 一个模块有多个入口。
P.141
 5.1.2 Approaches to Software Design
 Action-Oriented Design
 Data-Oriented Design
 Object-Oriented Design
 two main aspects of software systems
 two main aspects of software systems:
 the actions they perform and
 the data on which they operate.
 So  the two traditional ways of software design
 action-oriented design
 the emphasis is on the actions performed by the software
 design activities ： defining the system's modules

 data-flow analysis, 不要被名字混淆 . 面向功能的！非面向数

据
 data-oriented design.
 the primary focus is on the structure of the data to be represented
in the system.
 most software designs have equal emphasis on actions and
objects
 In fact : most software designs have equal emphasis
on actions and objects
 With the exception of pure database systems
 Only emphasizing one over the other will run the risk
of introducing a design flaw in the aspect of the
system
 Object-oriented design reduces this risk by
 considering both actions and data with equal emphasis
 In an object definition : methods and fields receive equal status.
 Action-Oriented Design
 In an action-oriented approach, the focus is on
 analyzing the processing steps and
 partitioning them into a sequence of actions (modules)
 with high cohesion and low coupling.
 This approach is most appropriate for those cases
for which the flow of data through the system is the
most important way to view the operation of the
software.
 Following examples not the most important way, why?
 Database
 rule-based

 transaction processing systems

 Action-Oriented Design
 There are two main techniques for action-oriented
design
 Data flow analysis
 Transaction analysis
 Data flow analysis
  creates a data flow diagram
 showing all the processing steps plus their input and output.
  identifies the highest point of abstraction of both the
input and the output
 the boundaries between internal and external representations of the data
 draws two vertical lines separating the input, processing, and output
stages.
  according to where these boundaries are drawn, The
processing steps are partitioned into input, transform, and
output modules.
 This technique is applied recursively ( 递归应用 ) to each of the three
initial modules, which are further decomposed 进一步分解 .
  continues until the modules
 perform a single function or
 a group of functions with very high cohesion.
p.313
Example:word counter
 Transaction analysis
 In a transaction processing system, a large number
of very similar requests must be handled that differ
only in the details of their content.
 an automated teller machine ， a typical example of a
transaction processing system.
 transaction analysis
 not focusing on defining input, processing, and output
modules,
 But focuses on identifying the analysis and dispatch
modules.
 The analysis module determines the type of the incoming
transaction and passes this information to the dispatch
module
 The dispatch module performs the appropriate transaction.
 面向数据流的设计方法
 数据流的类型
 变换流 (Transform Flow)
 事务流 (Transaction Flow)
 变换流

信息从外部世界进
入系统 ;
系统进行加工处理 ; 输入流 输出流
处理后的数据以外 外部 表
部世界的形式离开 示

系统 . 信息 变换 流

内部表示

时间
Transform
Flow
 事物流

事务中
接收输入数据 ; 心
事务
经事务中心分析确 …
定活动通路 ;
执行每条通路 , 产生 活动通 路
T …
输出 .

…
结构化设计 (SD-Structured Design) 的过
程

精化数据流
图
“ 事物” “ 变换 ”
流 型
区分事物中心 区分 入和
和数据接收通 出分支
路
映射成事务结 映射成变换结
构 构
用启发式设计
规则精化软件
结构
导出接口描述 变换分
事物分析 析
和
全程数据结构
复 查

详细设计
 变换分析

b g h
a e f
d
c i
j

Transform mapping

x1

x2 x3 x4

b c d e f g i

a h j
 变换分析

typical “decision
making” modules
main
program
controller

input processing output

controller controller controller

typical “worker”
modules
 变换分析 – 实例
■ 例 : 汽车数字化仪表板系统的设计 .
功能要求 :P.96
通过模 - 数转换实现传感器和微处理机
接口 ;
在发光二极管面板上显示数据 ;
指示每小时英里数 (mph), 行驶的里程 , 每
加仑油行驶的英里数 (mpg) 等 ;
指示加速或减速 ;
如果车速超过 55mph , 则发出警告铃声 .
 例 : 汽车数字化仪表板系统的设
计
第 1 步 : 复查基本系统模型 .
确保系统的输入数据和输出数据符合实际要求 .

第 2 步 : 复查并精化 DFD 图 .
分析需求分析阶段得到的 DFD;
进行必要的精化 , 使 DFD 图中每一个处理都能表示一个
适当规模的相对独立的子功能 .
结果如图 5.11 所示 .

第 3 步 : 确定 DFD 图的特征
变换流特征 ?
事务流特征 ?
本系统为变换流
 例 : 汽车数字化仪表板系统的设计
旋转信号

读 确定
旋转 加/ 箭头指
信号 减速 示
SPS
∆SPS 产生
燃料流 收集 上箭头
传感器信 加 /减
和求 速 示
号 平均
水平线
SPS
读和 下箭头
校核 转换
成
rpm
燃 流 转/
分 计算
rpm 里程 英里 产生
计算 计算 里程
gph mph, 示 示
超速 超速值
gph 值 发出
mph
mph 铃声
计算 铃声
燃料 产生
消耗 mph
mpg 示
mph 示
产生
mpg
示 mpg 示
 例 : 汽车数字化仪表板系统的设计

第 4 步 : 确定输入流和输出流边界 , 找出变换中心 .
旋转信号
读 确定
旋转 加/ 箭头指
信号 减速 示
SPS
燃料流 ∆SPS 产生 上箭头
收集
传感器信 加 /减
和求
号 速 示 水平线
平均
SPS
读和 下箭头
校核 转换
成
rpm
燃 流 转/
计算
分
•输入 rpm 里程 英里 产生
计算 计算 里程
gph mph, 示 示
超速 超速值
gph 值 发出
mph
mph 铃声
计算 铃声
燃料 产生
•处理 消耗
mpg
mph
示
mph 示
产生 •输出
mpg
示 mpg 示
 例 : 汽车数字化仪表板系统的设计

第 5 步 : 进行第一级分解 .
系统由一个主控模块和三个子模块组成
输入模块 : 接收传感器信号
处理模块 : 进行数据转换
输出模块 : 驱动仪表板
数字仪表板控制模块

接收传感器信号 数据转换控制 驱动仪表板

? ? ?
 例 : 汽车数字化仪表板系统的设计

第 6 步 : 进行第二级分解 .
将 DFD 图中的每一个处理映射成一个适当的模块 .
旋转信号
读 确定
旋转 加/ 箭头指
信号 减速 示
燃料流
SPS
∆SPS 接收传感器信
收集
传感器信 和求 号
号 平均
SPS
读和
校核 转换 转换成 计算
成
转/
rpm rpm gph
燃 流
分
rpm
计算 计算
gph mph, 收集 sps 读燃料
超速
gph 值 流
mph
计算
燃料 读旋转信
消耗
号
 例 : 汽车数字化仪表板系统的设计

确定
加/ 箭头指
减速 示
∆SPS
收集
和求
平均
SPS
数据转换控制
转换
成
rpm
转/
分 计算
rpm 里程 英里 确定 计 计 计算
计算
mph,
加速 算 算 里 程
超速 超速值
/ 减 mph mpg
值
mph
mph 速
计算
燃料
消耗
mpg
 例 : 汽车数字化仪表板系统的设计

箭头指
示
产生 上箭头
加 /减
速 示 水平线

下箭头 驱动仪表板

英里 产生
里程 加速 显 显 显 发
示 示
超速值 /减 示 示 示 出
mph
发出
铃声
速 mpg mph 里 铃
铃声
显示 程 声
产生
mph
mpg
示
mph 示
产生
mpg
示 mpg 示
发光二极管显
示
 例 : 汽车数字化仪表板系统的设计

 第二级分解后得到的软件结构 .
数字仪表板控
制

接收传感器信 数据转换控制 驱动仪表板

号

转换成 计算 确 计 计 计算 加 显 显 显 发
rpm gph 定 算 算 里程 速 / 示 示 示 出
加 mph mpg 减 mpg mph 里 铃
速/ 速 程 声
收集 sps 读燃料
减 显
流 速 示
读旋转信 发光二极管显
号 示
 例 : 汽车数字化仪表板系统的设计

第 7 步 应用设计原理和启发式规则对设计结果进
行修改 .
 设提高内聚会 , 降低耦合 .
 易于实现、易于测试、易于维护 .

第 8 步 为每一个模块写一个简要说明 .
描述模块的接口信息 ;
描述模块内部的信息 ;
描述模块加工过程 , 包括主要判定点及任务等；
描述对约束和特殊特点的简短讨论 .
 例 : 汽车数字化仪表板系统的设计

数字仪表板控
制

接收传感器信 数据转换控制 驱动仪表板

号

转换成 计算 计 计 计算 显 显 显 发
rpm gph
算 算 里程 示 示 示 出
mph mpg mpg mph 里 铃
收集 sps 读燃料 程 声
流 加
确定加
速/
读旋转信 速 /减 发光二
减
号 速 极管显
速
显 示
 事务 分析

 第 1 步 : 复审基本系统模型 .
 第 2 步 : 复审并精化 DFD 图 .
 第 3 步 : 确定 DFD 图是变换流特征还是事务流
特征 .
 第 4 步 : 识别事务中心和每一条动作通路 .
incoming flow action path
T
 e f
 第 5 步：将 DFD a
b
d

图映射成软件结构 t
g
i
h k
. l j
m
n

x1 Mapping
b t

a x2 x3 x4

d e f g h x3.1 l m n

i j
k
 example

II M

S II S

A B C I A B C

…
…

…
…
事务分析 的映射方法
 事务 型系统结构图

 它接受一项事务，根据事务处理的特点和性
质，选择分派一个适当的处理单元，然后给
出结果。
 在事务型系统结构图中
 事务中心模块按所接受的事务的类型，选
择某一事务处理模块执行。
 各事务处理模块并列。

 每个事务处理模块可能要调用若干个操作
模块，而操作模块又可能调用若干个细节
模块。
 设计优化
 软件结构设计完成后 , 应对其优化 .
 首先应保证使系统能工作 .
 先让它转起来 .
 然后再优化其结构 , 使之更完美 .
 再让它快起来 .
 Data-Oriented Design
 In data-oriented design, the modular architecture of
a system is based on the structure of the data that it
processes.
 The best-known technique for data-oriented design
is the Jackson Method
 Historically, action-oriented design has been much
more widely used than data-oriented design.
 Current trend away from both of these traditional
methods towards object-oriented design （极受追
捧， fans 众多）
 data-oriented design has largely fallen out of use.
( 少人问 津 )
 Jackson System Development(JSD)

与 SD 的由 DFD 导出结构设计不同， JSD 是以数

据结构 (data structure) 为基础设计每个模块的处理过程
1。、 Jackson Diagram: 注意：
层次方框图 H
A A A 中的方框表示
S
I 模块，而 JD 中
Bo Co
的方框代表几
B C B* 个语句构成的
A=
S 简单操作；
A= B
B C
A=B
C
H 表现调用关
系，而 JD 表现
组成关系。
 Jackson System Development(JSD)

2 、 Jackson 方法：
例：一个正文文件由若干个记录组成，
每个记录是一个字符串。要求统计每个记录
中空格字符的个数，以及文件中空格字符的
总个数。要求的输出数据格式是：每复制一
行输入字符串之后，另起一行印出这个字符
串中的空格数，最后印出文件中空格的总个
数。
 Jackson System
Development(JSD)

第 1 步：用 Jackson 图描述 I\O 的数据

结构 输入 输出

正文文件 输出表 格

字符串 * 表格体 空格总 数

I I
字符 * 串信息 *
S

空格 O
非空格 O
字符 串 空格 数

第 2 步：在两个图中指出有直接因果关系 (causality) 、
可以同时处理的单元（重复的次序，次数均相同）
 输入 输出 JSD
正文文 件 输出表 格

字符串 * 表格体 空格总 数

I I
字符 * 串信息 *
S
?
空格 O
非空格 O
字符串 空格数

?
经过程序处理由正文文件得到 每处理输入中一个字符串后
输 出表格。 就得到输出中一个串信息， 二 者
重复次序和次数均相同。
字符不与多字符组成的字符串 单个空格不能决定空格数 。
对应。
 第 3 步： Data structure Program
structure
把有对应关系的单元合为一个处理框，画在相应的层次
中（不同层以低层为准）
输入 输出 统计空格

正文文件 输出 表格

I 程序体 印总数

字符串 * 表格 体 空格 总数 I
处理字 符串
I I *
字符 * 串信 息 *
S 印字符 分析字符 *
分析 字符串 印空格
串 数
I
空格 O
非空格 O
字符 串 空格 数 分析字符 *
S
注：顺序执行的处理中不允许混
有重复执行或选择执行的处 处理空格 处理非 空格
理。 o o
• 第 4 步：列 出 所 有 操 作 条 件 ， 并 分 配 到 上 幅 程
序结构图中
第 5 步：用 Pseudocode 表示程序。
 JSD 方法
 该方法 在设计比较简 单的数据处 理系统时特别
方便， 当设计比较复 杂的程序时 常常遇到输入
数据可 能有错、条件 不能预先测 试、数据结构
冲突等 问题。
 为了克 服上述困难， 把该方法用 到更广阔的领
域，需 要采用一系列 比较复杂的 辅助技术。
 Warnier 方法
 Warnier 方法又称 LCP 法 (Logically Constructing Program) ，与
Jackson 方法类似，也是从数据结构出发设计程序，但是该方法的逻
辑更严格。
 分析和确定输入数据和输出数据的逻辑结构，并用 Warnier 图描绘这些数
据结构
 主要依据输入数据结构到处程序结构，并用 Warnier 图描绘程序的处理层
次
 画出程序流程图并自上而下依次给每一个处理框编序号
 分类写出伪码指令
 输入和输出准备
 分支和分支准备
 计算
 输出和输出准备
 子程序调用
 把前一步中的分类写出的指令按序号排序，从而得出描述处理过程的伪码
 Warnier 方法
例：假设要设计一个系统用来定期产生有关顾客帐目的
报表，输入文件中每个顾客有一个头记录，后接若干个
事务记录。
活动号
顾 顾客姓 名 旧余额
客
号 0000001 张 山 5000. 00
代码
0000001 001 300. 00 01 （存 / 取）
0000001 002 1000. 00 02

0000002 李 士 20000. 00

0000003 王 武 7500. 00
…… …… …… 数量
 Warnier 方法
输出报表如下
：顾客号 顾客姓 名 活动号 支出数 存入数

新余额 0000001 张 三 001 300. 00

002 1000. 00
旧余额
5000. 00 5700. 00 300. 00 1000. 00 存入总 数

0000002 李 士 支出总数
20000. 00 20000. 00

0000003 王 武 001 2500. 00

…… …… ……
 Warnier 方法

第 1 步：用 Warnier Diagram 描述 I\O 的数据结构

图中第 4 第 5 层只有在一个顾客有事务活动时
（支出或存入）才出现。
第 2 步： Data Structure → Program Structure 。
第 3 步：将上图对应转换为程序流程图，并将每个处理框编号。
第 4 步： Pseudocode 分类。分 析每个处理框 应该做的 动作并用伪码 表示这些
动作。得 到分类指令表 。
 Warnier 方法
第 5 步：将前一步分类指令表中有同样处理框标识
（序号）的指令归为一组，基本上按照“输
入－处理－输出”的顺序组织这些指令，并
例如： 010 按处理序号排序
－读
若文件没有结束
040 －顾客号送访问顾客号
－旧余额送工作区
……
 Object-Oriented Design
 In OOD ， equal emphasis is given to designing
 both the data in the system
 and the actions of the system.
  OOA  identifing classes  OOD  defining objects
 Since object definition in a language （ Java ） supports high
cohesion and low coupling, the object-oriented approach has
“built-in” support for the more desirable characteristics in
modular design. 与生俱来的优势
 four steps of The object-oriented design approach -1
 Construct interaction diagrams.
 creates a sequence diagram or a collaboration diagram for each of
the use case scenarios defined during the analysis phase.
 Construct a detailed class diagram.
 during the analysis phase : The preliminary class diagram created
 include a full list of methods (including their signatures and return
types) and data members (including their types).
 Additional classes and relationships are added where necessary.
 four steps of The object-oriented design approach -2
 Construct a client-object relation diagram.
 arranges the classes in a diagram that emphasizes their
hierarchical relationship
 this corresponds to the notion of a control flow diagram (CFD) in
structured analysis.
 Complete a detailed design.
 specifies for each method
 the algorithms to be implemented,
 internal variables and data structures

 How to ， discuss later……

 5.1.3 The Role of Architectural Design
 architectural design of the system 系统架构设计
 Regardless of the technique is used
 action-oriented
 data-oriented
 OO
 the result of design : the modules of a software system
 we call it . architecture
 architectural design
 plays role in the overall creation of the software system.
 In fact, architectural design is just the first step in design;
 followed by the detailed design phase and the design-testing phase.
 Architectural design is also important during the implementation and
integration phases, why?.
 a good architectural design
 the important characteristics (modularity, cohesion,
and coupling )  motivate a good architectural
design.
 a good architectural design also promotes
 understandability,
 faster debugging, and
 straightforward maintenance and extension
 all of which are extremely important cost factors in the
overall software life cycle.
 architectural design is used in the following ways:
 During detailed design:
 each of the modules identified in the architectural design is
specified in detail, including
 its algorithm(s) : represented by a pseudo-code
 definitions of its signature(s)

 data members

 This step cannot proceed until an architectural design has been

completed. architectural design finish  detailed design begin
 architectural design is used in the following ways:
 During design testing:
 architectural design  software structures  use case scenarios
 an important vehicle for design testing
 a simulated walk-through of the system's operation.
 Such testing is impossible without a representation of the
individual modules and their interrelationship (coupling). 没有功
能模块划分就无法进行用例测试！
 architectural design is used in the following ways:
 During implementation and integration:
 architectural design is a key element in planning the
implementation and integration of the system‘s modules. 它定义
了模块之间的连接与相关约束
 All of the methods …… rely on a detailed architecture design
(modules) as input
 top-down
 bottom-up

 sandwich integration
 For more information
 PPT 介绍， 一会儿就 来！
 教学信 息网站上有电 子书下载
 http://c4se.51.net/
 5.1.4 Detailed Design
 During the detailed design phase
 the designer  considers each module identified in the
architectural design  produces the following specifications:
 Module interfaces

 Module algorithms

 Module data structures

 Module interfaces:
 Module interfaces:
 All the names, arguments, and argument
types of the modules are specified in detail.
 In OO system

specifying for each object in the detailed

class diagram
the signatures for the object constructor
and for all the object methods.
 Module algorithms
 Module algorithms
 The actual algorithms to be used in implementing
each module are specified concretely.
 Algorithms can be specified using
 prose descriptions (bad)
 but since natural language is notoriously ambiguous
 semi-formal language (better)
 pseudocode. (better)

 In an OO system , each object ’s

 constructors

 methods.
An example of pseudocode fig. 13.12.
 Module data structures
 Module data structures
 If a module requires temporary storage or any kind of internal
data structure, these must be specified concretely.
 each internal variable or data structure

 name

 type

 initial value

 In an OO system, specifying

 all the class variables for a particular object

 all the internal variables and data structures inside each

method
 用 java 设计时 的一 个方法
  detailed design is complete  defining all the
information required by the programmer( 实现 小组
)
 E.g.,A common way of for object-oriented Java
programs
 writing down the detailed design in skeletal class files for each
object, including
 class variable declarations
 constructor and method signatures

 placing Algorithm specifications in each method body in the

form of comments.
 The advantages of this approach
 For experienced designers (senior programmers)
 predefine the structure and content of the objects to be written
 For junior programmers （软 件蓝 领）
 free to concentrate on creating excellent code for individual
modules
 Not struggling with the complexities of a global system design
 And also 保证设计 正确 、完善 !
 When an excellent detailed design is constructed in advance
 implementation stage proceeds in a rapid, straightforward
manner
 fewer faults are discovered during system integration and
testing.
 5.1.5 Design Testing
 Design testing has two main goals:
 To verify that the design incorporates all the functional
specifications from the requirements and analysis phases;
 To ensure correctness of design
 But, how to do?
 cross-reference elements of design and analysis
 cross-reference elements of design and analysis
 link
 each of the processing steps identified in the analysis phase (data
flow diagrams ， doc ， table)
 to
 modules specified in the architectural design.
 可以使 用编号 、索 引、超 级链 接 ( HTML ) 等
 it is useful to cross-reference （交 叉引 用）
 the elements of the design
 those aspects of analysis
 those aspects of the requirements
 In the case of object-oriented design
 Check :
 all of the use cases identified must correspond to some sequence
of actions provided by the objects and their methods
 Any changes to the class diagram must be documented
 it must be verified that 修改 后立即 验证 ！
 both the detailed class diagram
 And the detailed design support the use case scenarios defined
during the analysis phase
 CASE tools will help you!
 Some computer-aided software engineering
(CASE) tools support a direct mapping between
specifications and design
 Rational Rose.
 5.2 OOD Practice 1
 5.2.1 Sequence Diagrams in UML
 5.2.2 Collaboration Diagrams in UML
 5.2.3 Detailed Class Diagrams in UML

 Assessments
 Exercise 5
 5.2.1 Sequence Diagrams in UML
 The first step in OOD is the creation of an
interaction diagram for each use case scenario.
 UML supports two types of interaction diagrams .
Both kinds of diagrams depict the system's objects
and the messages passed between them.
 sequence diagrams （顺序图）
 emphasize the chronological sequence( 时间顺序 ) of
messages
 important for understanding the order in which certain events
occur in a software system
 collaboration diagrams （协作图）
 emphasize the relationships between objects
 important for understanding the structure of the software
system
 UML sequence diagrams
 labeled, parallel vertical lines represented :
 External agents ( 外部行动者 , the user) and all of the objects in the
system
 labeled arrows :
 Messages from an agent to an object, or from object to object
 drawn from the agent or calling object to (  )the called object.
 Labels include increasing ordinal numbers representing the
chronological sequencing of messages.
 Note ：
 Messages are generally arranged in the vertical dimension
 the earliest message appearing from the top to bottom. 从上到下垂直
方向 , 符合阅读习惯
 it is possible to "read" the sequence diagram from top to bottom to
discern the chronological ordering of messages.
example of a sequence diagram for a C/S architecture
sequence diagram for one use case scenario associated with
the ElevatorController case study.
 5.2.2 Collaboration Diagrams in UML
 We now know sequence diagrams
 present the chronological sequencing of messages.
 Whereas, collaboration diagrams
 emphasize the relationships between objects.
 The UML collaboration diagram
 labeled stick figures (same in use case diagrams)
 represented Agents ( 行动者 , the user)
 labeled rectangles
 represented Objects
 solid, undirected line linking the rectangles
 represented Coupling between two objects
 implies that one object passes one or more messages to
another
 labeled, directed lines with arrow
 represented Individual messages
 arrow pointing in the direction of (  ) the object that is
called or invoked.
 include ordinal numbers that denote the chronological
ordering of the messages.
 A simple example collaboration diagram
 Shown below is a partial collaboration diagram for
the simple client-server architecture
 Explain of the example
 example represents the same scenario
 collaboration diagrams are equivalent to sequence
diagrams.
 用哪一 种好？
 sequence diagrams,
 collaboration diagrams, or
 both.
 以什么 标准？
 The decision depends on which is more important
 whether the chronological ordering of messages
 or the overall structure of the object interactions
 5.2.3 Detailed Class Diagrams in UML
  the interaction diagrams are constructed in OOD
phase
  create a detailed class diagram that refines (and
finalizes) the proposed classes for the system.
 Recall that the OOA phase produces a preliminary
class diagram
 indicates the classes, attributes, and relations,
 but does not give any detail regarding the class methods. 只
有些方法名
 The basic task in the detailed class diagram
 The task : associate the messages with particular
classes
 Messages 可以理解为类中被调用的方法！
 An action or a message can be associated with 关联
到谁？
 either a class ( 服务提供者 )
 or a client that sends a message to an object of that class. 给
该类的一个对象发消息的 client （服务使用者）
 3 techniques for deciding how to associate messages
with classes -1
 Information hiding （或封 装） :
 Because the state variables of a class should be declared
private or protected
 actions on state variables must be local to the class where
they are declared. 同一个类中定义对其的操作（方法）
 3 techniques for deciding how to associate messages
with classes - 2
 Reduced redundancy: 消除冗 余
 if an action is invoked by a number of different clients of a
particular object
对每个不同客户，都定义一个方法来调用该操作吗？
 have a single copy of that action implemented as a method of
the object. 当然只用定义一个方法了
 The alternative (a separate copy of an identical method in
each client class) is redundant, adds to the complexity of the
code, and decreases the modularity and extensibility of the
code. 所以，不要这样做！
 3 techniques for deciding how to associate messages
with classes - 3
 Responsibility-driven design: 对象 各司其职！
 According to the principle of informational cohesion （信息
内聚）
 modules that group together all actions on a set of data
elements have high cohesion
 a design that promotes informational cohesion is preferred.
 the action associated with a message to be implemented as a
method of the object that receives the message, 接收消息的
对象增加方法处理消息
 it is the responsibility of that object to operate on the data
involved in the activity.
 5.3 OOD Practice 2
 5.3.1 Client-Object Diagrams in UML
 5.3.2 Specifying Modular Interfaces
 5.3.3 Detailed Design Specification
 5.3.4 Formal Design Review

 Assessments
 Exercise 6
 5.3.1 Client-Object Diagrams in UML
  detailed class diagram has been created
  the final step in architectural design in the
object-oriented approach is to create a client-object
diagram.
 The client-object diagram
 Use UML notation to draw all the classes and client-
object relations
 An object C that sends a message to object O is a
client of O.
 This simple diagram contains just two elements
 Classes:
 labeled rectangles represent Classes
 Same as sequence diagrams and collaboration diagrams;
 Relations:
 unlabeled, directed lines represent Client-object relations
 draw from the client C to the object O
 arrows point from clients to() objects C

O
 Then ……
  the client-object diagram has been created
  identify the objects that are not invoked by any clients.
想一下，为什么要找它们，它们是什么呢？
 These top-level objects represent the possible entry points
into the entire product.
 If only a single top-level object
 a main method is defined in it
 the object is instantiated when the program is first called.
 If more than one top-level object
 create a single top-level object
 create a client-object relation with the multiple existing top-level objects
 the Java interpreter only a single top-level class as the entry point.
 An example of a client-object diagram
 This diagram illustrates two top-level modules
(clients) that are not clients of any other objects.
 In a Java implementation
 Add a class to instantiate both of these top-level objects.
 This class is in a top-level "session" or "user interface"
object.
client-object diagram of ElevatorController
 5.3.2 Specifying Modular Interfaces
 The detailed class diagram
 specifies enough information about the product's modular
structure (including method signatures)
 for a programmer to begin implementation of classes based
on the detailed class diagram. 程序员的设计编码依据
 Modules In Java
 the modular interfaces contain the following
information:
 Class variable definitions:
 The names and types of any class variables contained by the
class
 Constructor signatures:
 The names and types of any arguments of the object
constructor for the class
 Method signatures: for each,
 The name and its return type
 arguments names and its types
 specify the modular interfaces
 before full implementation begins, a recommended
coding convention is to
 create a skeletal class file for each class. Contains:
 only the information (Class variable definitions, Constructor
signatures, Method signatures )
 does not actually implement the program statements in the
body of the constructor or other class methods.
 Writing skeletal class files for the classes in the
detailed class diagram is also an excellent way to
validate the class diagram. 以后可 以利用工具 生
产类代 码
 When writing the Java method signatures into the class files,
it often becomes apparent when some element of the design
is missing or incorrect. 便于检漏查错！
 5.3.3 Detailed Design Specification
 In detailed design phase, design results described in
the specification of each module’s
 the interface,
 algorithm, and
 data structures.
 In OOD, the interface and data structures are
specified in the detailed class diagram and the
skeletal class files
 the algorithm description, must be included for
each of the methods in the modular interface in the
form , 用注释形式写 在 skeletal class files 中
 a prose description 普通文本
 pseudo-code definition. 伪代码
 How to do with a complex methods?
 To long , difficult to read
 for a programmer a text description or full pseudo-code in
the skeletal class file may make the file,
 But, Must show all details
 we stress that the detailed design should present all the
important design information to the programmer in a
conveniently organized manner — a principle that favors
placing the algorithm specifications directly into the skeletal
class files.
 An appropriate compromise (when the methods are
really a complex one) 这样来 解决……
 store the algorithm description itself in a separate file.
 place a pointer to the algorithm specification inside the
skeletal class file
 Some tools
 The Java Development Kit (JDK) distributed by
Sun Microsystems includes an automatic
documentation generation facility called javadoc (
http://java.sun.com/j2se/javadoc/index.html).
 Demo , JDK API Spec.
 Some tools
 The javadoc tool extracts comments written in the "doc"
format from Java source files. It places them in a user-
specified destination directory, creating a set of HTML
pages that, depending on the options given by the user,
describes public and protected classes, interfaces,
constructors, methods, and fields. javadoc is targeted for use
with APIs, but it can be used for other purposes as well. Doc
comments begin with a short description of what the item to
which the comment pertains does. More text formatted with
a restricted number of HTML tags can be added. Then there
are a number of different tags, identified by an at sign ( @ )
as their first character, for different types of items (for
example, class and interface tags, field tags, constructor and
method tags).
 An example of a class doc comment

/**
* A class representing a window on the screen.
* For example:
*
* Window win = new Window(parent);
* win.show();
*
*
* @author Sami Shaio
* @version %I%, %G%
* @see java.awt.BaseWindow
* @see java.awt.Button
*/
class Window extends BaseWindow {
...
}
 An example of a field doc comment
/**
* The X-coordinate of the window.
*
* @see window#1
*/
int x = 1263732;
 An example of a method doc comment
/**
* Returns the character at the specified
* index. An index ranges from 0 to length() - 1.
*
* @param index the index of the desired
* character.
* @return the desired character.
* @exception StringIndexOutOfRangeException
* if the index is not in the range
* 0 to length()-1.
* @see java.lang.Character#charValue()
*/
public char charAt(int index) { ... }
 If the designer takes care to format the skeletal class files
and method descriptions using the javadoc syntax and
tagging conventions, then javadoc can be used to generate
automatically, full class documentation in HTML format.
 While it can be time-consuming to format comments using
the javadoc syntax, the cross-referenced HTML produced
by the tool is a very powerful source of documentation that
would require much more effort to produce from scratch.
 The compelling characteristic of javadoc is that it allows the
designer or programmer to produce HTML documentation
"for free" from the detailed design specification (in the form
of skeletal class files), even before the methods are
implemented.
 5.3.4 Formal Design Review
 The final milestone and validation step in the design
process is the formal design review. 正式的 设计审
查
 The entire product design include
 the sequence diagrams,
 collaboration diagrams,
 detailed class diagram,
 client-object diagram,
 modular interface specification, and
 detailed design specification
 All must be reviewed
 for their consistency with each other
 for their conformity to the original functional requirements
 In formal design review
 the designer might meet with 谁来参加评 审？
 The programmers selected to implement the product, …• 
 The engineer who performed the original requirements
analysis and specification  • …
 A typical formal review is scheduled at a time
 all of the relevant specification documents and diagrams can
be distributed to all participants well in advance.
 The design review should focus on the following activities:
 Match the design to the requirements.
 All of the use cases and use case scenarios identified during
OOA should be reviewed to verify
 the final design includes appropriate classes and messages
(method calls) that model all the events sketched in the scenarios.
设计出对象交互符合用例情形描述的内容
 Manually tracing through the sequence diagrams and/or
collaboration diagrams is an appropriate technique for this
activity.
 The design review should focus on the following activities:
 Verify completeness of the detailed class diagram and detailed
design.
 Sometimes simpler methods (such as get and set accessors for class
variables) are overlooked. 倒容易被忘掉
 During the design review, it is important to verify the completeness of the
class diagram and detailed design, so no methods (however small or trivial)
are overlooked.
 Are the actions in the sequence/collaboration diagrams associated with the
right classes—according to the principles of
 information hiding,
 reduced redundancy, and
 responsibility-driven design
 Are the algorithm descriptions in the detailed design complete, precise, and
unambiguous?
 The programmers should attend the design review and verify that the
detailed design contains all of the information required for implementation
to begin. 是不是足够信息指导编码实现，没有遗漏
 The design review should focus on the following activities:
 Evaluate the architectural design.
 Do the proposed modules exhibit the right degree of cohesion
and coupling?
 Are there any instances of coupling that should be re-designed
to avoid unnecessary common coupling, control coupling, or
stamp coupling?
 通过 问这 些问题 来做设 计审 查！
 take enough time
 It is critical to take enough time to conduct a
detailed, exhaustive review of the design. 详尽 的审
核
 the formal design review represents the official
“hand-off” of the design specification to the
implementation team 通过评 审的设计将移 交给
实现小 组
 The design review is typically the best (and
sometimes the last!) opportunity for the
implementation team to work with the design team
to refine the design before implementation begins.