SSD9: Software Specification, Testing, and Maintenance
Unit 5. Object-Oriented Design (OOD)
5.1 OOD Principles 5.2 OOD Practice 1
5.3 OOD Practice 2
5.2.1 Sequence Diagrams in UML 5.2.2 Collaboration Diagrams in UML 5.2.3 Detailed Class Diagrams in UML 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
In traditional structured programming,
a software module might correspond to a particular function or program in a particular language.
In object-oriented programming
partition the functionalities identified in the requirements specification and analysis phases into specific software modules.
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,
testability:
then easier to understand what each part of the system does. 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
high cohesion
refer to the degree of similarity or interaction among the action carried out by a particular module. 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 objectoriented 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
燃 流 计算 gph gph 计算 燃料 消耗
rpm
计算 mph, 超速 值 mph
mpg 产生 mpg 示
计算 里程
英里
产生 里程 示
超速值 发出 铃声
mph 产生 mph 示
mpg 示
mph 示
铃声
示
时间内聚（ Classical Cohesion ） 时间内聚又称为经典内聚。这种模块
大多为多功能模块，但模块的各个功 能的执行与时间有关，通常要求所有 功能必须在同一时间段内执行。 例如 初始化模块
, 申请各类运行资源 终止模块，释放资源
逻辑内 聚（ Logical Cohesion ）
这种模块把几种 相关的功能组合 在一起，每次被 调用时，由传送 给模块的判定参 数来确定该模块 应执行哪一种功 能。
巧合内 聚（ Coincidental Cohesion ）
( 偶然内聚 ) 。当模块内各 部分之间没有联系，或者即使有联系 ，这种联系也 很松散， 则称这种模 块为巧合内 聚模块，它 是内聚程度 最低的模块。
巧合内聚
Coupling
The term coupling is used to
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
refer to the degree of interaction between two modules.
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:
Control coupling:
The results of one module influence the subsequent actions (control decisions) of another module.
Stamp coupling:
Two modules can both access and modify a global data structure.
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)
如果发生下列情形，两个模块之间就发
生了内容耦合 一个模块直接访问另一个模块的内 部数据 ; (2) 一个模块不通过正常入口转到另一 模块内部 ; (3) 两个模块有一部分程序代码重迭 ( 只可能出现在汇编语言中 ); (4) 一个模块有多个入口。 (1)
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
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.
showing all the processing steps plus their input and output.
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
a
f
e
d
h
g i
c
j
Transform mapping
x1 x2 b
c a
x4
x3 d
e
f
g
i
h
j
变换分析 typical “decision making” modules main program controller
input controller
processing controller
output controller
typical “worker” modules
变换分析 – 实例 ■ 例 : 汽车数字化仪表板系统的设计 . 功能要求 :P.96 通过模 - 数转换实现传感器和微处理机 接口 ; 在发光二极管面板上显示数据 ; 指示每小时英里数 (mph), 行驶的里程 , 每 加仑油行驶的英里数 (mpg) 等 ; 指示加速或减速 ; 如果车速超过 55mph , 则发出警告铃声 .
例 : 汽车数字化仪表板系统的设 计 第 1 步 : 复查基本系统模型 . 确保系统的输入数据和输出数据符合实际要求 .
第 2 步 : 复查并精化 DFD 图 . 分析需求分析阶段得到的 DFD; 进行必要的精化 , 使 DFD 图中每一个处理都能表示一个 适当规模的相对独立的子功能 . 结果如图 5.11 所示 .
第 3 步 : 确定 DFD 图的特征 变换流特征 ? 事务流特征 ? 本系统为变换流
例 : 汽车数字化仪表板系统的设计 旋转信号 读 旋转 信号
确定 加/ 减速
SPS
燃料流 传感器信 号
∆SPS
收集 和求 平均
箭头指 示 产生 加 /减 速 示
上箭头 水平线
SPS
读和 校核
下箭头
转换 成 转/ 分 rpm
燃 流 计算 gph gph 计算 燃料 消耗
rpm
计算 mph, 超速 值 mph
mpg 产生 mpg 示
计算 里程
英里
产生 里程 示
超速值 发出 铃声
mph 产生 mph 示
mpg 示
mph 示
铃声
示
例 : 汽车数字化仪表板系统的设计 第 4 步 : 确定输入流和输出流边界 , 找出变换中心 . 旋转信号 读 旋转 信号 燃料流 传感器信 号
SPS 收集 和求 平均
读和 校核
箭头指 示 产生 加 /减 速 示
•输入 计算 gph gph 计算 燃料 消耗
上箭头 水平线
SPS
下箭头
转换 成 rpm 转/ 计算 分 rpm 里程
燃 流
•处理
确定 加/ 减速 ∆SPS
计算 mph, 超速 值 mph
mpg 产生 mpg 示
英里
超速值
产生 里程 示
发出 铃声
mph 产生 mph 示
mpg 示
mph 示
示
铃声
•输出
例 : 汽车数字化仪表板系统的设计 第 5 步 : 进行第一级分解 . 系统由一个主控模块和三个子模块组成 输入模块 : 接收传感器信号 处理模块 : 进行数据转换 输出模块 : 驱动仪表板 数字仪表板控制模块
接收传感器信号
数据转换控制
驱动仪表板
?
?
?
例 : 汽车数字化仪表板系统的设计 第 6 步 : 进行第二级分解 . 将 DFD 图中的每一个处理映射成一个适当的模块 . 旋转信号 读 旋转 信号 燃料流 传感器信 号
确定 加/ 减速 ∆SPS
SPS 收集 和求 平均
读和 校核
SPS 转换 成 rpm 转/ 分 rpm
燃 流 计算 gph gph 计算 燃料 消耗
计算 mph, 超速 值 mph
箭头指 示
接收传感器信 号 转换成 rpm
计算 gph
收集 sps
读燃料 流
读旋转信 号
例 : 汽车数字化仪表板系统的设计
收集 和求 平均
确定 加/ 减速 ∆SPS
箭头指 示
数据转换控制
SPS 转换 成 rpm 转/ 计算 分 rpm 里程 计算 mph, 超速 值 mph
计算 燃料 消耗
mpg
超速值 mph
英里
确定 计 计 计算 加速 算 算 里 程 / 减 mph mpg 速
例 : 汽车数字化仪表板系统的设计 箭头指 示 产生 加 /减 速 示
上箭头 水平线 下箭头
英里 超速值 发出 铃声
mph
mpg 产生 mpg 示
产生 里程 示
产生 mph 示
mpg 示
铃声
示
驱动仪表板
加速 显 显 /减 示 示 速 mpg mph 显示
显 示 里 程
mph 示
发光二极管显 示
发 出 铃 声
例 : 汽车数字化仪表板系统的设计
第二级分解后得到的软件结构 . 数字仪表板控 制 接收传感器信 号
转换成 rpm
计算 gph
收集 sps
读燃料 流
读旋转信 号
数据转换控制
驱动仪表板
确 计 计 计算 加 显 显 定 算 算 里程 速 / 示 示 加 mph mpg 减 mpg mph 速/ 速 减 显 速 示
显 示 里 程
发光二极管显 示
发 出 铃 声
例 : 汽车数字化仪表板系统的设计
第 7 步 应用设计原理和启发式规则对设计结果进 行修改 .
设提高内聚会 , 降低耦合 . 易于实现、易于测试、易于维护 .
第 8 步 为每一个模块写一个简要说明 . 描述模块的接口信息 ; 描述模块内部的信息 ; 描述模块加工过程 , 包括主要判定点及任务等； 描述对约束和特殊特点的简短讨论 .
例 : 汽车数字化仪表板系统的设计
数字仪表板控 制 接收传感器信 号 转换成 rpm
计算 gph
收集 sps
读燃料 流
读旋转信 号
驱动仪表板
数据转换控制
计 计 计算 算 算 里程 mph mpg 确定加 速 /减 速
显 显 显 示 示 示 mpg mph 里 程 加 速/ 减 速 显
发光二 极管显 示
发 出 铃 声
事务 分析
第 1 步 : 复审基本系统模型 .
第 2 步 : 复审并精化 DFD 图 .
第 3 步 : 确定 DFD 图是变换流特征还是事务流 特征 .
第 4 步 : 识别事务中心和每一条动作通路 . incoming flow
T
action path
第 5 步：将 DFD 图映射成软件结构 .
a
e
d
b t
i
g
h
l n
Mapping t
b a
x3
x2 d
e
f
g
x4
h
x3.1 i
j k
l
m
k j
m x1
f
n
example
I II
M
S
A
B
C …
I
C
…
B
S
…
A
II
…
…
…
事务分析 的映射方法
事务 型系统结构图
它接受一项事务，根据事务处理的特点和性 质，选择分派一个适当的处理单元，然后给 出结果。 在事务型系统结构图中
事务中心模块按所接受的事务的类型，选
择某一事务处理模块执行。 各事务处理模块并列。 每个事务处理模块可能要调用若干个操作 模块，而操作模块又可能调用若干个细节 模块。
设计优化
软件结构设计完成后 , 应对其优化 .
首先应保证使系统能工作 .
先让它转起来 .
然后再优化其结构 , 使之更完美 .
再让它快起来 .
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: A
A
A S
B
A=
C B C
Bo
A=
I Co
B*
S B
C
A=B
层次方框图 H 中的方框表示 模块，而 JD 中 的方框代表几 个语句构成的 简单操作； H 表现调用关 系，而 JD 表现 组成关系。
Jackson System Development(JSD) 2 、 Jackson 方法：
例：一个正文文件由若干个记录组成， 每个记录是一个字符串。要求统计每个记录 中空格字符的个数，以及文件中空格字符的 总个数。要求的输出数据格式是：每复制一 行输入字符串之后，另起一行印出这个字符 串中的空格数，最后印出文件中空格的总个 数。
Jackson System Development(JSD) 第 1 步：用 Jackson 图描述 I\O 的数据 输出 输入 结构 输出表 格
正文文件 I 字符串 *
表格体
I 字符 *
I 串信息 *
空格总 数
S 空格
O
非空格
O
字符 串
空格 数
第 2 步：在两个图中指出有直接因果关系 (causality) 、 可以同时处理的单元（重复的次序，次数均相同）
输入
输出
正文文 件
输出表 格
JSD
I
字符串
*
表格体
I
字符
I
*
串信息
S
空格
O
非空格
空格总 数
*
? 字符串
O
?
经过程序处理由正文文件得到 输 出表格。 字符不与多字符组成的字符串 对应。
空格数
每处理输入中一个字符串后 就得到输出中一个串信息， 二 者 重复次序和次数均相同。 单个空格不能决定空格数 。
第 3 步： Data structure
Program
structure 把有对应关系的单元合为一个处理框，画在相应的层次 中（不同层以低层为准） 输入
输出
正文文件
输出 表格
统计空格
程序体
I
字符串 *
表格 体
I
O
非空格
处理字 符串 *
串信 息 * 印字符 串
S
空格
I
空格 总数
I
字符 *
印总数
O
字符 串
空格 数
注：顺序执行的处理中不允许混 有重复执行或选择执行的处 理。
分析字符 分析 字符串 *
印空格 数
I
分析字符 * 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
旧余额
5000. 00
5700. 00
0000002
李 士
存入数
1000. 00 300. 00
1000. 00
支出总数
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)
For junior programmers （软 件蓝 领）
predefine the structure and content of the objects to be written 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
to
each of the processing steps identified in the analysis phase (data flow diagrams ， doc ， table) 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 :
labeled arrows :
External agents ( 外部行动者 , the user) and all of the objects in the system 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)
labeled rectangles
represented Objects
solid, undirected line linking the rectangles
represented Agents ( 行动者 , the user)
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 clientobject 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:
Constructor signatures:
The names and types of any class variables contained by the class 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
But, Must show all details
for a programmer a text description or full pseudo-code in the skeletal class file may make the file, 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 userspecified 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.