设计模式与软件架构设计
设计模式与软件架构设计
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 1
议题
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
（1）面向对象软件架构设计思想
（2）使用UML进行软件架构设计
（3）设计模式的本质论
（4）设计模式与架构模式
Slide 2
面向对象本质论
—面向对象范式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 3
议题
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..功能分解模式分析
..功能分解模式如何适应需求的变化
..责任转移模式处理需求的变化
..面向对象范式
Slide 4
问题的描述
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 5
..编写代码访问存储在数据库中的几何形状的描
述，再把得到的几何形状显示出来。
解决问题步骤
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 6
..在数据库中查找几何形状的列表；
..打开形状列表；
..以某种规则将这个列表排序；
..在显示器上显示单个的几何形状；
.识别形状的具体类型
.获得形状的位置
.调用适当的函数，并传递形状的位置给它，来显示这
个形状
功能分解
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 7
..分析者将问题拆分成多个功能步骤，这些步骤组合起来就
可以解决实际的问题。
..把问题分解成小块来解决，比一次处理整个问题要简单。
功能分解带来的问题
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 8
..它不能帮助我们为未来可能发生的变化作准备。
..它不能把帮助我们的代码优雅的演变。
..变化的发生还为错误和意外结果的发生创造了机会-许多
错误都来自于代码的变化。
模块化方式处理变化
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 9
..模块化可以帮助你写出更容易理解的代码，更
容易理解的代码也更容易维护；
..模块化并不能帮助你写出能应付所有可能出现
的变化代码
内聚和耦合
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 10
..内聚度：是指程序中的操作之间联系紧密的程度。描述了
一个子程序的内部成分之间相互联系的强度。
..耦合度：是指两个子程序联系的强度。描述了一个子程序
与其他子程序之间的联系强度。
..耦合度与内聚度成反比。
..目标：蒋建具有内部完整性（强内聚）的子程序，以及小
的、直接的、可见的、灵活的与其他子程序之间的联系（
松耦合）
责任转移模式处理需求变化
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 11
..实际问题的描述：TechED2005大会上，我主讲了Report
Builder,当参加会议的听众听完我的演讲后，需要到其他的
分会场去参加其他的技术演讲，我的一种做法是：
.获得参加会议的听众的人名单；
.对于名单上的每个人：
.查找他的下一技术演讲的题目；
.查找他的下一参会的地点；
.查找到他下一分会场的路径；
.告诉他怎样去下一个地点。
不同实现方案
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 12
..为了实现上述的过程，可能需要：
.获得本会场上人的名单的方法。
.获得每个人的日程安排表的方法。
.一个程序来告诉某个人如何从我的分会场到达另外一个分会场。
.一个控制程序来为每一个人做需要的步骤。
..另外实现的方案：
.把从本会场到其他会场的路径张贴出来
.告诉所有的参会者按照张贴的路径到下一个分会场。
揭示问题的本质
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 13
..第一种方法，对每个人都指明确地指出路径，必须注意许多细节
，除了你之外的任何人对任何事情都没有责任。
..用第二种方法，你给出了一个普遍的指令，并期望每个人都能自
己知道如何完成你给出的任务。
..对比：第一种方案中你对所有事情负责，而第二种方案参会者对
他们自己的行为负责；组织方式的巨大差异。
软件开发过程的视角
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 14
..概念（conceptual）
.展示了问题领域中的概念；
.一个概念模型可以在对实现软件有很少或毫无注意的情况下勾勒出来。
..规格（Specification）
.我们只看软件的接口，而不看软件的实现。
..实现（implementation）
.置身于代码当中，使常规视角
..目标：
.一个层次（概念层次）上通信而在另一个层次（实现层次）上执行；
.请求者不知道发生了什么，只知道概念上发生了什么。
面向对象范式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..面向对象范式的核心是“对象”的概念
..所有的东西都聚焦于对象
..围绕对象-而非函数-组织代码
Slide 15
对象从不同视角观察
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 16
..概念层：一个对象是一系列责任
..规格层：一个对象是一系列可以被其他对象或
该对象自己调用的方法
..实现层：一个对象是一些代码和数据
面向对象本质论
—设计原则
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 17
面向对象的设计目标
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..可维护性
..可复用性
Slide 18
可维护性
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..现在存在的问题
.过于僵硬
.过于脆弱
.复用率低
.黏度过高
Slide 19
可维护性
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 20
..设计的目标
.可扩展性（
Extensibility）
.新的功能可以很容易地加入到系统中
.灵活性（Flexibility）
.允许代码修改平稳地发生，而不会涉及到许多其它模块
.可插入性（
Plug ability）
.可以很容易地将一个类抽出去，同时将一个可以很容易地将一个
类抽出去，同时将一个有同样接口的类加入进来。
可复用性
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..重要性
.较高的生产效率
.较高的软件质量
.恰当使用复用可以改善系统的可维护性
..传统的复用
.代码的剪贴使用
.算法的复用
.数据结构的复用
Slide 21
设计原则
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
.
“开闭”原则(OCP)
..里氏代换原则(LSP)
..依赖倒转原则(DIP)
..接口隔离原则(ISP)
..组合/聚合复用原则
(CARP)
..迪米特法则(LoD)
Slide 22
“开闭”原则(OCP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 23
.
Open-Closed Principle (OCP)
..定义
. Software entities should be open for extension, but
closed for modification.
.一个软件实体应当对扩展开放，对修改关闭
.
“抽象化”是OCP的关键
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 24
..解释
“臣启陛下臣启陛下
……降一道招安圣旨
……与它籍名在
箓……一则不动众劳师，二则收仙有道也
”（《西游记》）
“开闭”原则(OCP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 25
..对可变性的封装原则
.
Principle of Encapsulation of Variation (EVP)
.找一个可变的因素把它封装起来
.一种可变性不应当散落到代码的很多角落里，而应当
被封装在一个对象里
.一种可变性不应当与另一种可变性混合在一起
里氏代换原则(LSP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 26.
Liskov Substitution Principle (LSP)
..定义
.如果对某一类型为T1的对象o1，都有类型为T2的对象
o2，使得以T1定义的所有程序P在所有的对象o1都代
换成o2时，程序P的行为没有变化，那么类型T2是类
型T1的子类型
里氏代换原则(LSP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 27
..解释
. “白马，马也；乘白马，乘马也。骊马，马也；乘骊
马，乘马也。”（《墨子·小取》）
里氏代换原则(LSP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..解释
. “娣，美人也，爱娣，非爱美人也
…”（《墨子
·小取》）
Slide 28
依赖倒转原则(DIP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 29.
Dependency Inversion Principle (DIP)
..要依赖于抽象，不要依赖于具体
.抽象层次包含的是应用系统的商务逻辑和宏观的、对整
个系统来说重要的战略性的决定，是必然性的体现
.具体层次则含有一些次要的，与实现相关的算法和逻辑
以及战术性的决定，带有相当大的偶然性
依赖倒转原则(DIP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 30
..表述
. Abstractions should not depend upon details. Details
should depend upon abstractions.（抽象不应当依赖细
节，细节应当依赖抽象）
. Program to an interface, not a implementation.（要针
对接口编程，而不要针对实现编程）
接口隔离原则(ISP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 31.
Interface Segregation Principle (ISP)
..从一个客户角度来讲，一个类对另一个类的依赖
性应当建立在最小的接口上
..原则
.角色分割
.定制服务
合成/聚合复用原则(CARP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 32.
Composition/Aggregation Reuse Principle (CARP)
..定义
.在一个新的对象里面使用一些已有的对象，使之成为新对象的一部
分，新的对象通过向这些对象的委派达到复用已有功能的目的
..尽量使用合成/聚合，而不是继承
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 33
..一般化(Generalization)关系
..表示类与类之间的继承关系，接口与接口之间的继承关系，
类对接口的实现关系
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 34
..关联(Association) 关系
.表示类与类之间的联接，它使一个类知道另一个类的属性和方法
.关联可以是单向的，也可以是双向的
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..聚合(Aggregation)关系
.是关联的一种，是强的关联关系，是整体与个体的关系。
Slide 35
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 36
..合成(Composition)关系
.是关联关系的一种，是比聚合关系强的关联。它要求普通的聚
合关系中代表整体的对象负责代表个体的对象的生命周期。合
成关系不能共享。
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 37
..依赖(Dependency)关系
.是类与类之间的连接，依赖总是单向的。依赖表示一个类依赖
于另一个类的定义。
.通常被依赖的对象以方法的参数或返回表示。
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 38.
Law of Demeter (LoD) 又称为最少知识原则
. Least Knowledge Principle (LKP)
..表述
. only talk to your immediate friends“只与你直接的朋友们通信
”
. Don’t talk to strangers “不要与陌生人讲话
”
.每一个软件单位对其他的单位都只有最少的知识，而且局限于那
些与本单位密切相关的软件单位
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 39
..狭义迪米特法则
.如果两个类不必彼此直接通信，那么这两个类就不应当发生直
接的相互作用。如果其中一个类需要调用另一个类的某一方法
的话，可以通过第三者转发这个调用
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 40.
“朋友”的确定
.当前对象本身(this)
.以参量形式传入到当前对象方法中的对象
.当前对象的实例变量直接引用的对象
.当前对象的实例变量如果是一个聚集，那么聚集中的元
素也都是“朋友”
.当前对象所创建的对象
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..狭义迪米特法则
.与依赖倒转原则的互补使用
Slide 41
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 42
..广义迪米特法则
.封装(信息隐藏)
.模块将它所有的实现细节隐藏起来，彻底地将提供给
外界的API和自己的实现分割开来。
.模块与模块间仅通过彼此的API相互通信，而不会理会
模块内部的工件细节。
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 43
..广义迪米特法则
.控制信息过载
.在类的划分上，应当创建弱耦合的类。类之间的耦合越弱，就越
有利于复用
.在类的结构设计上，每一个类都应当尽量降低成员的访问权限
(Accessibility)
.在类的设计上，只要有可能，一个类应当设计成不变类
(Immutable)
.在对其它类的引用上，一个对象对其实例的引用应当降到最低
ICONIX 流程
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 44
最小UML建模技术
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 45
..对于大多数问题而言，只需使用20%的UML，
就可以完成80%的建模工作。
..实际中，好像总是没有足够的时间来完成建模
、分析和设计工作，总是过早地进入到编码阶
段。
..足以很好地完成软件项目工作所需的、最小的
UML和建模技术子集。
ICONIX主要元素
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 46
如何从用例到代码？
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 47
工作起点
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..假设：
.一些原型化的工作已经完成；
.确定了用户界面
.已经开始确定系统的一些场景和用例
..面向对象系统中
.代码的结构是由类定义的。
.编写代码前，必须知道所需的软件类是什么样的。
Slide 48
类图规定了代码的结构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 49
..获得一组非常详细的、设计级的（
Design-level）类图。
..设计级是指一种详细程度，这种级别的类图可以用作系统实际代码
的模板，准确地指出如何组织代码。
..面向对象软件开发中，最困难的工作之一是分配行为，这需要就每
个要建立的软件函数做出决策。
..对于每个函数必须决定将其放在那个类中。
时序图将操作分配给类
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 50
..时序图帮助你做出行为分配决策的理想工具。
..需要根据用例获得时序图
..如何跨越模糊用例与详细程度类似代码的时序图之间的
鸿沟？
健壮性图在需求与详细设计之间架起了
一座桥梁
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 51
..使用健壮性图来填充模糊、朦胧的用例与非常详细、精确的时序图
之间鸿沟。
..时序图的最上面是：特定场景涉及的一组对象
设计模式的本质论
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 52
什么是模式?
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 53
..在《在软件开发中理解和使用模式》一文中给出了这样
一个定义：模式是从解决具体问题抽象出来的，这种具
体问题在特定的上下文中重复出现。也就是说，每个具
体形式都对一种重复的问题采用重复的解决方案。
..然而，模式不仅仅是解决方案，正是因为很多人认为设
计模式仅仅是解决方案，所以才导致设计模式的滥用和
设计过度。
模式不是解决方案
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 54
..模式不是解决方案，而是在某种环境中权衡各方面利弊
的一种方案的选择，这种选择是这些利弊平衡的结果，
获得好处的同时需要付出代价，并且结果中有有利的方
面，也有不利的方面。
什么是模式?
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 55
..在模式中，问题出现在一种特定的上下文(context)(或称
为“语境”)，并且包含各种互相竞争的关切(forces)。目标
解决方案包括对这些关切的平衡，这种关切在模式中称
为“作用力”，这些作用力互相牵制。因此，模式不能简
单地看做是“特定场景的解决方案”，下面的定义更符合
模式的内在含义。
..模式是被命名的有组织的信息，它捕获了在一定语境(场
景)中包含相关作用力的问题的解决方案的本质结构和内
在含义，这种解决方案被证明是成功的。
..模式包含3个部分：相关的上下文、与上下文相关的作
用力系统和解决问题的方案。
理解设计模式的结果和代价
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 56
..在GOF的设计模式中充分讨论了模式的使用结
果，既有好的方面，也有不好的方面，即使用
模式是有代价的。
(1)对象过多
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 57
..设计模式的精髓之一是将可变部分封装为对象，带来的好处是系统
更加灵活，易于维护，但也大量增加了对象。如果不恰当地使用设
计模式，会使系统难以调试。下面几个模式比较有代表性。
.
(1)命令模式：将行为封装为对象，这样原来一个对象中的若干方法
变成了若干命令对象。如果将命令模式应用在一个
GUI用户界面上
，每一个菜单项就要生成一个命令对象，原来由一个对象完成的工
作现在可能需要十几个对象来完成。
.
(2)状态模式：将不同的状态封装为对象，原来可能是通过判断语句
完成的工作分散到各个对象中完成。由于状态是动态决定的，因此
在设计测试用例时有难度。
(2)更复杂的装配关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 58
..很多设计模式依赖对象之间的关系，因此在初
始化时需要执行相应的装配工作，需要装配对
象的模式有如下几种。
. (1)生成器模式：需要装配生成器和导航器。
. (2)桥接模式：需要将代表逻辑的对象和代表实现的
对象进行装配。
. (3)观察者模式：需要将不同的观察者对象关联在一
起。
. (4)职责链模式：需要组装整条职责链。
(3)测试难度加大
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 59
..这是前面两个结果导致的，由于对象的增多和对象间关
系的复杂，因此测试用例的设计难度增大。特别是很多
逻辑上的错误可能由装配关系不当造成，并且在编译时
很难发现。
..解决测试难度大的方法是将测试用例文档化，即绘制测
试用例的对象图。这个话题超出了本书的范围，有兴趣
的读者可参考相关书籍。
(4)程序结构复杂
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 60
..设计模式关注的是如何使软件更具可维护性，因此从结
构上已经与原始的需求完全不同。加上很多功能是通过
对象的动态组合实现的，程序的动态结构变得与静态结
构同样重要。
..从单纯的静态结构(例如类图)已经很难理解实现的方式
和最终的意图了，这也是经常是使用设计模式的代价之
一。
设计模式不能做什么
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..设计模式不是法则
..不能提高开发速度或者形象开发速度
..不是万能的
Slide 61
(1)设计模式不是法则
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 62
..模式理论的精髓之一就是模式的使用是有前提和代价的
，模式是在某种前提下，综合各方面因素后考虑得出的
结果。即在使用模式时总是要付出一定的代价，当然这
种代价是可以接受的。如果某个模式在所有场合中的使
用都是必然的，那么它就不能叫做模式了，而是一种必
须遵守的法则。例如“面向接口，而非实现编程”，是法
则而非模式。
(2)不能提高开发速度或者形象开发速度
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 63
..如果以一个开发周期作为考核标准，恐怕没有人会使用
设计模式。设计模式并不能提高目前的开发速度，至少
其关注的目标并不是开发速度。很多情况下甚至会降低
开发速度，即使是正确地选择了设计模式。
..这是因为设计模式可能会引入更多的对象和更复杂的对
象装配关系，从而使得程序有更多的动态状态，从局部
看来变得结构复杂，难以理解并且测试困难。如果仅仅
关注于形象进度，或者能够百分之百地确定需求没有变
化，那么设计模式并不是很好的选择。
(3)不是万能的
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 64
..设计模式的使用是自然而然的事情，很多情况下不使用
设计模式是因为不需要，问题还没有复杂到非用不可的
程度。我们是为了设计而使用设计模式，而不是为了使
用设计模式而设计。
..当你的项目发现有如下问题之一时，就需要考虑重构代
码，可能会有某种模式适合。
. (1)代码无法进行单元测试。
. (2)需求的变动总是导致代码的变动。
. (3)有重复代码存在。
. (4)继承层次过多。
. (5)隐藏的依赖过多。
设计模式与架构模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 65
软件顶层架构的设计
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 66
方法
结合实际需求，选取架构模式，再进行局部调整。
主要架构模式
..流程处理模式
..客户/服务器模式、
..模型—视图—控制器模式
..分层模式
软件顶层架构的设计
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 67（1）流程处理模式。
..流程处理系统以算法和数据结构为中心，其系
统功能由一系列的处理步骤构成，相邻处理步
骤用数据流通管道连接。
..流程处理模式适用于批处理方式的软件系统，
不适合交互式系统。
流程处理模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..流程处理模式具有三个
处理步骤。
..步骤都使用公共的系统
服务（例如数据库访问
服务），命令处理和命
令处理的进度、结果都
通过用户界面。
Slide 68
客户/服务器模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
（2）客户/服务器模式。
客户端负责用户输入和处
理结果的呈现，服务端
负责后台业务处理。
Slide 69
模型—视图—控制器（MVC）模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 70（3）模型
—视图—控制器模式
软件系统由模型、视图和控制
器三部分组成。
模型负责维护并保存具有持久
性的业务数据，实现业务处理功能，
并将业务数据的变化情况及时通知视
图。
视图负责呈现模型中包含的业
务数据，响应模型变化通知，更新呈
现形式，向控制器传递用户的界面动
作。
控制器负责将用户的界面动作
映射为模型中的业务处理功能并实际
调用之，然后根据模型返回的业务处
理结果选择新的视图。
MVC模式特别适合于
分布式应用软件，
尤其是Web应用系统
分层模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 71（4）分层模式
..将整个软件系统分为若干层次，最顶层直接面
向用户提供软件系统的操作界面，其余各层为
紧邻其上的层次提供服务。
..分层模式可以有效降低软件系统的耦合度，应
用普遍。
分层模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
层次划分的主要原则
..易变化的部分，如用户界面、
与业务逻辑紧密相关的部件，
置于高层
..稳定部分，如公共的技术服务
部件，置于低层；
..每层都尽量访问紧邻的下层，
避免越级访问，尤其要避免逆
向访问即，上层模块为下层模
块提供服务；
..将目标软件系统的外部接口置
入较低层次，系统其余部分对
外部系统的访问或操作通过这
些外部接口提供的服务来完成
。Slide 72
软件架构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 73
..在全面了解软件架构样式的前提下，对于具体
的应用需求而言，影响顶层架构选取的主要因
素在于分析人员的经验以及他们对每种架构样
式与当前软件项目之间匹配程度的判断。
..大型软件的顶层架构往往需要使用多种架构样
式。如，整个目标软件系统采用分层结构，在
系统的不同层次内再分别使用适宜的其他类型
的架构模式。
确立软件架构考虑的因素
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 74（1）架构中包的数量
包中软件元素过多，应对包进一步细分；如果
过少，则说明架构过早地陷入细节。
（2）架构中包之间的耦合度
包的依赖关系、连接关系应尽量简单、松散，
如，在分层结构中，通常要求某一层的软件元素
只与同层及下一层的元素存在依赖关系。
（3）软件元素的稳定性
抽取不稳定的软件元素的相对稳定部分，将不
稳定的软件元素分类聚集在少数几个包中，以提
高软件系统的可维护性。
确立软件架构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 75（4）软件元素的分类
将软件可选功能和必须实现功能的软件元素分
别置于架构的不同包或子包中。
（5）作为软件系统运行环境的物理网络拓朴
根据软件元素在分布环境中的布局，划分顶
层架构的包，使包的消息传递与物理节点的通
信相协调，顶层架构定义的通信关系支持后续
的分析和设计活动。
确立软件架构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 76（6）软件元素的安全、保密级别。
根据安全访问的权限划分顶层架构中的包或者
子包。
（7）开发团队的技术专长。
根据开发人员在问题和技术领域的专长划分顶
层架构，使得每个包的开发都能充分发挥开发人
员和团队的技术专长
（8）调整软件架构，支持并行开发。
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 1
议题
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
（1）面向对象软件架构设计思想
（2）使用UML进行软件架构设计
（3）设计模式的本质论
（4）设计模式与架构模式
Slide 2
面向对象本质论
—面向对象范式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 3
议题
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..功能分解模式分析
..功能分解模式如何适应需求的变化
..责任转移模式处理需求的变化
..面向对象范式
Slide 4
问题的描述
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 5
..编写代码访问存储在数据库中的几何形状的描
述，再把得到的几何形状显示出来。
解决问题步骤
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 6
..在数据库中查找几何形状的列表；
..打开形状列表；
..以某种规则将这个列表排序；
..在显示器上显示单个的几何形状；
.识别形状的具体类型
.获得形状的位置
.调用适当的函数，并传递形状的位置给它，来显示这
个形状
功能分解
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 7
..分析者将问题拆分成多个功能步骤，这些步骤组合起来就
可以解决实际的问题。
..把问题分解成小块来解决，比一次处理整个问题要简单。
功能分解带来的问题
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 8
..它不能帮助我们为未来可能发生的变化作准备。
..它不能把帮助我们的代码优雅的演变。
..变化的发生还为错误和意外结果的发生创造了机会-许多
错误都来自于代码的变化。
模块化方式处理变化
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 9
..模块化可以帮助你写出更容易理解的代码，更
容易理解的代码也更容易维护；
..模块化并不能帮助你写出能应付所有可能出现
的变化代码
内聚和耦合
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 10
..内聚度：是指程序中的操作之间联系紧密的程度。描述了
一个子程序的内部成分之间相互联系的强度。
..耦合度：是指两个子程序联系的强度。描述了一个子程序
与其他子程序之间的联系强度。
..耦合度与内聚度成反比。
..目标：蒋建具有内部完整性（强内聚）的子程序，以及小
的、直接的、可见的、灵活的与其他子程序之间的联系（
松耦合）
责任转移模式处理需求变化
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 11
..实际问题的描述：TechED2005大会上，我主讲了Report
Builder,当参加会议的听众听完我的演讲后，需要到其他的
分会场去参加其他的技术演讲，我的一种做法是：
.获得参加会议的听众的人名单；
.对于名单上的每个人：
.查找他的下一技术演讲的题目；
.查找他的下一参会的地点；
.查找到他下一分会场的路径；
.告诉他怎样去下一个地点。
不同实现方案
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 12
..为了实现上述的过程，可能需要：
.获得本会场上人的名单的方法。
.获得每个人的日程安排表的方法。
.一个程序来告诉某个人如何从我的分会场到达另外一个分会场。
.一个控制程序来为每一个人做需要的步骤。
..另外实现的方案：
.把从本会场到其他会场的路径张贴出来
.告诉所有的参会者按照张贴的路径到下一个分会场。
揭示问题的本质
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 13
..第一种方法，对每个人都指明确地指出路径，必须注意许多细节
，除了你之外的任何人对任何事情都没有责任。
..用第二种方法，你给出了一个普遍的指令，并期望每个人都能自
己知道如何完成你给出的任务。
..对比：第一种方案中你对所有事情负责，而第二种方案参会者对
他们自己的行为负责；组织方式的巨大差异。
软件开发过程的视角
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 14
..概念（conceptual）
.展示了问题领域中的概念；
.一个概念模型可以在对实现软件有很少或毫无注意的情况下勾勒出来。
..规格（Specification）
.我们只看软件的接口，而不看软件的实现。
..实现（implementation）
.置身于代码当中，使常规视角
..目标：
.一个层次（概念层次）上通信而在另一个层次（实现层次）上执行；
.请求者不知道发生了什么，只知道概念上发生了什么。
面向对象范式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..面向对象范式的核心是“对象”的概念
..所有的东西都聚焦于对象
..围绕对象-而非函数-组织代码
Slide 15
对象从不同视角观察
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 16
..概念层：一个对象是一系列责任
..规格层：一个对象是一系列可以被其他对象或
该对象自己调用的方法
..实现层：一个对象是一些代码和数据
面向对象本质论
—设计原则
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 17
面向对象的设计目标
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..可维护性
..可复用性
Slide 18
可维护性
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..现在存在的问题
.过于僵硬
.过于脆弱
.复用率低
.黏度过高
Slide 19
可维护性
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 20
..设计的目标
.可扩展性（
Extensibility）
.新的功能可以很容易地加入到系统中
.灵活性（Flexibility）
.允许代码修改平稳地发生，而不会涉及到许多其它模块
.可插入性（
Plug ability）
.可以很容易地将一个类抽出去，同时将一个可以很容易地将一个
类抽出去，同时将一个有同样接口的类加入进来。
可复用性
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..重要性
.较高的生产效率
.较高的软件质量
.恰当使用复用可以改善系统的可维护性
..传统的复用
.代码的剪贴使用
.算法的复用
.数据结构的复用
Slide 21
设计原则
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
.
“开闭”原则(OCP)
..里氏代换原则(LSP)
..依赖倒转原则(DIP)
..接口隔离原则(ISP)
..组合/聚合复用原则
(CARP)
..迪米特法则(LoD)
Slide 22
“开闭”原则(OCP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 23
.
Open-Closed Principle (OCP)
..定义
. Software entities should be open for extension, but
closed for modification.
.一个软件实体应当对扩展开放，对修改关闭
.
“抽象化”是OCP的关键
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 24
..解释
“臣启陛下臣启陛下
……降一道招安圣旨
……与它籍名在
箓……一则不动众劳师，二则收仙有道也
”（《西游记》）
“开闭”原则(OCP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 25
..对可变性的封装原则
.
Principle of Encapsulation of Variation (EVP)
.找一个可变的因素把它封装起来
.一种可变性不应当散落到代码的很多角落里，而应当
被封装在一个对象里
.一种可变性不应当与另一种可变性混合在一起
里氏代换原则(LSP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 26.
Liskov Substitution Principle (LSP)
..定义
.如果对某一类型为T1的对象o1，都有类型为T2的对象
o2，使得以T1定义的所有程序P在所有的对象o1都代
换成o2时，程序P的行为没有变化，那么类型T2是类
型T1的子类型
里氏代换原则(LSP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 27
..解释
. “白马，马也；乘白马，乘马也。骊马，马也；乘骊
马，乘马也。”（《墨子·小取》）
里氏代换原则(LSP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..解释
. “娣，美人也，爱娣，非爱美人也
…”（《墨子
·小取》）
Slide 28
依赖倒转原则(DIP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 29.
Dependency Inversion Principle (DIP)
..要依赖于抽象，不要依赖于具体
.抽象层次包含的是应用系统的商务逻辑和宏观的、对整
个系统来说重要的战略性的决定，是必然性的体现
.具体层次则含有一些次要的，与实现相关的算法和逻辑
以及战术性的决定，带有相当大的偶然性
依赖倒转原则(DIP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 30
..表述
. Abstractions should not depend upon details. Details
should depend upon abstractions.（抽象不应当依赖细
节，细节应当依赖抽象）
. Program to an interface, not a implementation.（要针
对接口编程，而不要针对实现编程）
接口隔离原则(ISP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 31.
Interface Segregation Principle (ISP)
..从一个客户角度来讲，一个类对另一个类的依赖
性应当建立在最小的接口上
..原则
.角色分割
.定制服务
合成/聚合复用原则(CARP)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 32.
Composition/Aggregation Reuse Principle (CARP)
..定义
.在一个新的对象里面使用一些已有的对象，使之成为新对象的一部
分，新的对象通过向这些对象的委派达到复用已有功能的目的
..尽量使用合成/聚合，而不是继承
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 33
..一般化(Generalization)关系
..表示类与类之间的继承关系，接口与接口之间的继承关系，
类对接口的实现关系
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 34
..关联(Association) 关系
.表示类与类之间的联接，它使一个类知道另一个类的属性和方法
.关联可以是单向的，也可以是双向的
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..聚合(Aggregation)关系
.是关联的一种，是强的关联关系，是整体与个体的关系。
Slide 35
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 36
..合成(Composition)关系
.是关联关系的一种，是比聚合关系强的关联。它要求普通的聚
合关系中代表整体的对象负责代表个体的对象的生命周期。合
成关系不能共享。
类图中的关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 37
..依赖(Dependency)关系
.是类与类之间的连接，依赖总是单向的。依赖表示一个类依赖
于另一个类的定义。
.通常被依赖的对象以方法的参数或返回表示。
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 38.
Law of Demeter (LoD) 又称为最少知识原则
. Least Knowledge Principle (LKP)
..表述
. only talk to your immediate friends“只与你直接的朋友们通信
”
. Don’t talk to strangers “不要与陌生人讲话
”
.每一个软件单位对其他的单位都只有最少的知识，而且局限于那
些与本单位密切相关的软件单位
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 39
..狭义迪米特法则
.如果两个类不必彼此直接通信，那么这两个类就不应当发生直
接的相互作用。如果其中一个类需要调用另一个类的某一方法
的话，可以通过第三者转发这个调用
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 40.
“朋友”的确定
.当前对象本身(this)
.以参量形式传入到当前对象方法中的对象
.当前对象的实例变量直接引用的对象
.当前对象的实例变量如果是一个聚集，那么聚集中的元
素也都是“朋友”
.当前对象所创建的对象
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..狭义迪米特法则
.与依赖倒转原则的互补使用
Slide 41
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 42
..广义迪米特法则
.封装(信息隐藏)
.模块将它所有的实现细节隐藏起来，彻底地将提供给
外界的API和自己的实现分割开来。
.模块与模块间仅通过彼此的API相互通信，而不会理会
模块内部的工件细节。
迪米特法则(LoD)
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 43
..广义迪米特法则
.控制信息过载
.在类的划分上，应当创建弱耦合的类。类之间的耦合越弱，就越
有利于复用
.在类的结构设计上，每一个类都应当尽量降低成员的访问权限
(Accessibility)
.在类的设计上，只要有可能，一个类应当设计成不变类
(Immutable)
.在对其它类的引用上，一个对象对其实例的引用应当降到最低
ICONIX 流程
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 44
最小UML建模技术
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 45
..对于大多数问题而言，只需使用20%的UML，
就可以完成80%的建模工作。
..实际中，好像总是没有足够的时间来完成建模
、分析和设计工作，总是过早地进入到编码阶
段。
..足以很好地完成软件项目工作所需的、最小的
UML和建模技术子集。
ICONIX主要元素
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 46
如何从用例到代码？
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 47
工作起点
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..假设：
.一些原型化的工作已经完成；
.确定了用户界面
.已经开始确定系统的一些场景和用例
..面向对象系统中
.代码的结构是由类定义的。
.编写代码前，必须知道所需的软件类是什么样的。
Slide 48
类图规定了代码的结构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 49
..获得一组非常详细的、设计级的（
Design-level）类图。
..设计级是指一种详细程度，这种级别的类图可以用作系统实际代码
的模板，准确地指出如何组织代码。
..面向对象软件开发中，最困难的工作之一是分配行为，这需要就每
个要建立的软件函数做出决策。
..对于每个函数必须决定将其放在那个类中。
时序图将操作分配给类
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 50
..时序图帮助你做出行为分配决策的理想工具。
..需要根据用例获得时序图
..如何跨越模糊用例与详细程度类似代码的时序图之间的
鸿沟？
健壮性图在需求与详细设计之间架起了
一座桥梁
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 51
..使用健壮性图来填充模糊、朦胧的用例与非常详细、精确的时序图
之间鸿沟。
..时序图的最上面是：特定场景涉及的一组对象
设计模式的本质论
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 52
什么是模式?
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 53
..在《在软件开发中理解和使用模式》一文中给出了这样
一个定义：模式是从解决具体问题抽象出来的，这种具
体问题在特定的上下文中重复出现。也就是说，每个具
体形式都对一种重复的问题采用重复的解决方案。
..然而，模式不仅仅是解决方案，正是因为很多人认为设
计模式仅仅是解决方案，所以才导致设计模式的滥用和
设计过度。
模式不是解决方案
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 54
..模式不是解决方案，而是在某种环境中权衡各方面利弊
的一种方案的选择，这种选择是这些利弊平衡的结果，
获得好处的同时需要付出代价，并且结果中有有利的方
面，也有不利的方面。
什么是模式?
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 55
..在模式中，问题出现在一种特定的上下文(context)(或称
为“语境”)，并且包含各种互相竞争的关切(forces)。目标
解决方案包括对这些关切的平衡，这种关切在模式中称
为“作用力”，这些作用力互相牵制。因此，模式不能简
单地看做是“特定场景的解决方案”，下面的定义更符合
模式的内在含义。
..模式是被命名的有组织的信息，它捕获了在一定语境(场
景)中包含相关作用力的问题的解决方案的本质结构和内
在含义，这种解决方案被证明是成功的。
..模式包含3个部分：相关的上下文、与上下文相关的作
用力系统和解决问题的方案。
理解设计模式的结果和代价
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 56
..在GOF的设计模式中充分讨论了模式的使用结
果，既有好的方面，也有不好的方面，即使用
模式是有代价的。
(1)对象过多
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 57
..设计模式的精髓之一是将可变部分封装为对象，带来的好处是系统
更加灵活，易于维护，但也大量增加了对象。如果不恰当地使用设
计模式，会使系统难以调试。下面几个模式比较有代表性。
.
(1)命令模式：将行为封装为对象，这样原来一个对象中的若干方法
变成了若干命令对象。如果将命令模式应用在一个
GUI用户界面上
，每一个菜单项就要生成一个命令对象，原来由一个对象完成的工
作现在可能需要十几个对象来完成。
.
(2)状态模式：将不同的状态封装为对象，原来可能是通过判断语句
完成的工作分散到各个对象中完成。由于状态是动态决定的，因此
在设计测试用例时有难度。
(2)更复杂的装配关系
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 58
..很多设计模式依赖对象之间的关系，因此在初
始化时需要执行相应的装配工作，需要装配对
象的模式有如下几种。
. (1)生成器模式：需要装配生成器和导航器。
. (2)桥接模式：需要将代表逻辑的对象和代表实现的
对象进行装配。
. (3)观察者模式：需要将不同的观察者对象关联在一
起。
. (4)职责链模式：需要组装整条职责链。
(3)测试难度加大
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 59
..这是前面两个结果导致的，由于对象的增多和对象间关
系的复杂，因此测试用例的设计难度增大。特别是很多
逻辑上的错误可能由装配关系不当造成，并且在编译时
很难发现。
..解决测试难度大的方法是将测试用例文档化，即绘制测
试用例的对象图。这个话题超出了本书的范围，有兴趣
的读者可参考相关书籍。
(4)程序结构复杂
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 60
..设计模式关注的是如何使软件更具可维护性，因此从结
构上已经与原始的需求完全不同。加上很多功能是通过
对象的动态组合实现的，程序的动态结构变得与静态结
构同样重要。
..从单纯的静态结构(例如类图)已经很难理解实现的方式
和最终的意图了，这也是经常是使用设计模式的代价之
一。
设计模式不能做什么
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..设计模式不是法则
..不能提高开发速度或者形象开发速度
..不是万能的
Slide 61
(1)设计模式不是法则
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 62
..模式理论的精髓之一就是模式的使用是有前提和代价的
，模式是在某种前提下，综合各方面因素后考虑得出的
结果。即在使用模式时总是要付出一定的代价，当然这
种代价是可以接受的。如果某个模式在所有场合中的使
用都是必然的，那么它就不能叫做模式了，而是一种必
须遵守的法则。例如“面向接口，而非实现编程”，是法
则而非模式。
(2)不能提高开发速度或者形象开发速度
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 63
..如果以一个开发周期作为考核标准，恐怕没有人会使用
设计模式。设计模式并不能提高目前的开发速度，至少
其关注的目标并不是开发速度。很多情况下甚至会降低
开发速度，即使是正确地选择了设计模式。
..这是因为设计模式可能会引入更多的对象和更复杂的对
象装配关系，从而使得程序有更多的动态状态，从局部
看来变得结构复杂，难以理解并且测试困难。如果仅仅
关注于形象进度，或者能够百分之百地确定需求没有变
化，那么设计模式并不是很好的选择。
(3)不是万能的
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 64
..设计模式的使用是自然而然的事情，很多情况下不使用
设计模式是因为不需要，问题还没有复杂到非用不可的
程度。我们是为了设计而使用设计模式，而不是为了使
用设计模式而设计。
..当你的项目发现有如下问题之一时，就需要考虑重构代
码，可能会有某种模式适合。
. (1)代码无法进行单元测试。
. (2)需求的变动总是导致代码的变动。
. (3)有重复代码存在。
. (4)继承层次过多。
. (5)隐藏的依赖过多。
设计模式与架构模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 65
软件顶层架构的设计
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 66
方法
结合实际需求，选取架构模式，再进行局部调整。
主要架构模式
..流程处理模式
..客户/服务器模式、
..模型—视图—控制器模式
..分层模式
软件顶层架构的设计
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 67（1）流程处理模式。
..流程处理系统以算法和数据结构为中心，其系
统功能由一系列的处理步骤构成，相邻处理步
骤用数据流通管道连接。
..流程处理模式适用于批处理方式的软件系统，
不适合交互式系统。
流程处理模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
..流程处理模式具有三个
处理步骤。
..步骤都使用公共的系统
服务（例如数据库访问
服务），命令处理和命
令处理的进度、结果都
通过用户界面。
Slide 68
客户/服务器模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
（2）客户/服务器模式。
客户端负责用户输入和处
理结果的呈现，服务端
负责后台业务处理。
Slide 69
模型—视图—控制器（MVC）模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 70（3）模型
—视图—控制器模式
软件系统由模型、视图和控制
器三部分组成。
模型负责维护并保存具有持久
性的业务数据，实现业务处理功能，
并将业务数据的变化情况及时通知视
图。
视图负责呈现模型中包含的业
务数据，响应模型变化通知，更新呈
现形式，向控制器传递用户的界面动
作。
控制器负责将用户的界面动作
映射为模型中的业务处理功能并实际
调用之，然后根据模型返回的业务处
理结果选择新的视图。
MVC模式特别适合于
分布式应用软件，
尤其是Web应用系统
分层模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 71（4）分层模式
..将整个软件系统分为若干层次，最顶层直接面
向用户提供软件系统的操作界面，其余各层为
紧邻其上的层次提供服务。
..分层模式可以有效降低软件系统的耦合度，应
用普遍。
分层模式
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1
层次划分的主要原则
..易变化的部分，如用户界面、
与业务逻辑紧密相关的部件，
置于高层
..稳定部分，如公共的技术服务
部件，置于低层；
..每层都尽量访问紧邻的下层，
避免越级访问，尤其要避免逆
向访问即，上层模块为下层模
块提供服务；
..将目标软件系统的外部接口置
入较低层次，系统其余部分对
外部系统的访问或操作通过这
些外部接口提供的服务来完成
。Slide 72
软件架构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 73
..在全面了解软件架构样式的前提下，对于具体
的应用需求而言，影响顶层架构选取的主要因
素在于分析人员的经验以及他们对每种架构样
式与当前软件项目之间匹配程度的判断。
..大型软件的顶层架构往往需要使用多种架构样
式。如，整个目标软件系统采用分层结构，在
系统的不同层次内再分别使用适宜的其他类型
的架构模式。
确立软件架构考虑的因素
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 74（1）架构中包的数量
包中软件元素过多，应对包进一步细分；如果
过少，则说明架构过早地陷入细节。
（2）架构中包之间的耦合度
包的依赖关系、连接关系应尽量简单、松散，
如，在分层结构中，通常要求某一层的软件元素
只与同层及下一层的元素存在依赖关系。
（3）软件元素的稳定性
抽取不稳定的软件元素的相对稳定部分，将不
稳定的软件元素分类聚集在少数几个包中，以提
高软件系统的可维护性。
确立软件架构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 75（4）软件元素的分类
将软件可选功能和必须实现功能的软件元素分
别置于架构的不同包或子包中。
（5）作为软件系统运行环境的物理网络拓朴
根据软件元素在分布环境中的布局，划分顶
层架构的包，使包的消息传递与物理节点的通
信相协调，顶层架构定义的通信关系支持后续
的分析和设计活动。
确立软件架构
.中国科学院软件所
2006 Software Engineering, 7th edition. Chapter 1 Slide 76（6）软件元素的安全、保密级别。
根据安全访问的权限划分顶层架构中的包或者
子包。
（7）开发团队的技术专长。
根据开发人员在问题和技术领域的专长划分顶
层架构，使得每个包的开发都能充分发挥开发人
员和团队的技术专长
（8）调整软件架构，支持并行开发。
浙公网安备 33010602011771号