目录
前言：
一、定义问题与归结模型
问题分析
1．在问题定义上达成共识
2．理解问题的本质
（1）因果鱼骨图。
（2）帕累托图。
3．确定项目干系人和用户
4．定义系统的边界
二、 问题定义
1.目标
2．功能需求
3．非功能需求
（1）观感需求：
（2）易用性需求：
（3）性能需求：
（4）可操作性需求：
（5）可维护性和可移植性需求：
（6）安全性需求：
（7）文化和政策需求：
（8）法律需求：
三、需求分析与软件设计
需求分析的任务与过程
（1）问题识别：
（2）分析与综合：
1．需求的分类
2．需求工程
3．需求分析方法
四、 如何进行系统设计
五、软件设计的任务与活动
1.软件设计的两个阶段从工程管理角度，软件设计可以分为两个步骤：
2．主要的设计方法比较
六、结构化分析与设计
1 结构化分析
1．结构化分析的工作步骤
2．数据流图
3.细化记录 DFD 部件
八、结构化设计
1．概要设计与详细设计的主要任务
2．结构图
3．程序流程图和盒图
1．信息隐蔽原则
2．模块独立性原则
十、面向对象的分析与设计
1．对象和类
（1）实体类：
（2）控制类：
（3）边界类：
2．继承与泛化
3．多态与重载
4．模板类
5．消息和消息通信
十一、面向对象分析
1．OOA/OOD 方法
2．Booch 方法
3．OMT 方法
4.OOSE 方法
十二、统一建模语言
1．UML 是什么
2．UML 的结构
3．用例图基础
4．类图和对象图基础
前言：
对于架构设计师而言，如何进行系统设计是其“看家本领”，而设计是在对系统进行分析的
基础上进行的，否则，设计就是“无米之炊”。从软件开发项目中的角色分配来看，系统架
构设计师应该在信息系统项目管理师的协调下，与系统分析师协同工作。
一、定义问题与归结模型
软件系统的目的是为了解决问题，因此在建模之初最重要的步骤是对问题的分析与定义，
并在此基础上归结模型，这样才能够获得切实有效的模型。定义问题的过程包括：理解真实
世界中的问题和用户的需要，并提出满足这些需要的解决方案的过程。
问题分析
问题分析的目标就是在开发之前对要解决的问题有一个更透彻的理解。为了达到这一目
标，通常需要经过在问题定义上达成共识，理解问题的本质，确定项目干系人和用户，定义
系统的边界和确定系统实现的约束这五个步骤。
1．在问题定义上达成共识
要检验大家是否在问题的定义上达成了共识，最简单的方法就是把问题写出来，看看是
否能够获得大家的认可。而要使得这个过程更加有效，应该将问题用标准化的格式写出来，
根据 UP 的建议，应该包括以下几个方面的要素。
问题概述：用简短的几句话，将所理解的问题本质描述出来；
影响：说明该问题将会对哪些项目干系人（Stakeholder，风险承担者）产生影响；
结果：确定问题对项目干系人和商业活动会产生什么样的影响；
优点：概要性地提出解决方案，并列举出该解决方案的主要优点。
在问题定义上达成共识，就能够有效地将开发团队的理解与用户的需求达成一致，这样
就能够使得整个系统的开发沿着合理的方向发展。
2．理解问题的本质
每一句描述都会夹杂着叙述者的个人理解和判断，因此透过表面深入本质，理解问题背
后的问题，是问题分析阶段一个十分关键的任务。其中一种技术是“根本原因”分析，这是
一种提示问题或其表象的根本原因的系统化方法。在实际的应用中，常使用因果鱼骨图和帕
累托图两种方法。
（1）因果鱼骨图。
因果鱼骨图是一种有效的探寻问题根源的技术，它通过直观的图形
找出问题或现象的所有潜在原因，从而追踪出问题的根源。它能够帮助人们将问题的原因而
放在首位，提供了一种运用集体智慧解决问题的方法。在使用时，通常按照以下步骤进行。
将问题简明扼要地写在右边的方框里；
确定问题潜在原因的主要类别，将它们连到鱼的脊骨上；
用头脑风暴法寻找原因并归类。图 8-1 是鱼骨图的一个示例。
（2）帕累托图。
帕累托图是采用直方图的形式，根据问题的相对频率或大小从高往低降序排列，帮助设
计师将精力集中在重要的问题上。它为 80%的问题找到关键的 20%的原因，它可以一目了
然地显示出各个问题的相对重要程度，有助于预防在解决了一些问题后，却使另外一些问题
变得更糟的现象发生。在使用时，通常按照以下步骤进行。
明确问题：也就是前面达成共识的问题定义；
找出问题的各种可能原因：通常可以利用头脑风暴来收集意见，并通过参考以往积累的资料
和运营的数据来综合分析；
选择评价标准和考察期限：最常用的评价标准包括频率（占总原因的百分比）和费用（产生
的影响），而考察的期限则应具有相应问题的代表性，并不是越长越好；
收集各种原因发生的频率及费用数据；
将原因按照发生的频率或费用从大到小排列起来；
将原因排在横轴上，频率或费用排列在纵轴上，形成如图 8-2 所示的结果。
这样就能够将造成问题的关键原因捕获出来，以便指导设计出更符合需要、更能够解
决问题的解决方案。
3．确定项目干系人和用户
要想有效地解决问题，必须了解用户和其他相关的项目干系人（任何将从新系统或应用
的实现中受到实质性影响的人）的需要。不同的项目干系人通常对问题有不同的看法和不同
的需要，这些在解决问题时必须加以考虑。事实上，许多项目干系人就是系统的用户，这一
部分通常是易于识别的；但还有一部分项目干系人是系统的间接用户，甚至只是受系统影响
的商业结果，这一部分不易识别，但十分重要。
在寻找项目干系人时，可以思考：系统的用户是谁？系统的客户（购买者）是谁？还有
哪些人会受到系统输出的影响？系统完成并投入使用后，有谁会对它进行评估？还有没有其
他系统内部或外部的客户，他们的需要有没有必要去考虑？系统将来由谁来维护？
4．定义系统的边界
系统的边界是指解决方案系统和现实世界之间的边界。在系统边界中，信息以输入和输
出的形式流入系统并由系统流向系统外的用户，所有和系统的交互都是通过系统和外界的接
口进行的。在定义系统的边界时，将世界分为两个部分：系统及与系统进行交互的事物。要
描述系统的边界有两种方法：一种是结构化分析中的“上下文范围图”，另一种则是面向对
象分析中的“用例模型”。
（1）上下文范围图。也就是数据流图中的顶层图，它是一个反映领域信息的模型，能
够清晰地显示出系统的工作职责和相邻系统的职责起止之处，从而让读者能够从宏观的层面
去了解系统。图 8-3 就是一个描述“证券经纪人系统”的上下文范围图。
（2）用例模型。用例模型则通过引入参与者来描述“和系统进行交互的事物”，只要识
别了参与者，自然而然系统的界限就确定下来了。在寻找参与者时，可以思考以下问题：谁
会对系统提供信息？谁会在系统中使用信息？谁会从系统中删除信息？谁将操作系统？系
统将会在哪里被使用？系统从哪里得到信息？哪些外部系统要和系统进行交互？
然后，再根据每个参与者的功能需求，识别出代表系统功能的用例，从而界定系统的边
界。而关于用例模型的更多细节
5．确定系统实现的约束
由于各种因素的存在，会对解决方案的选择造成一定的限制，称这种限制为约束。每条
约束都将影响到最后的解决方案的形成，甚至会影响是否能够提出解决方案。
在考虑约束时，首先应该考察到不同的约束源，其中包括进度、投资收益、人员、设备
预算、环境、操作系统、数据库、主机和客户机系统、技术问题、行政问题、已有软件、公
司总体战略和程序、工具和语言的选择、人员及其他资源限制等。
二、 问题定义
通过对问题进行细致周密的分析，就可以对其进行综合的定义。对于一个问题的完整定
义，通常应包括目标、功能需求和非功能需求三个方面。
1.目标
目标是指构建系统的原因，它是最高层次的用户需求，是业务上的需要，而功能、性能
需求则必须是以某种形式对该目标做出贡献。在描述目标时，应该注意以下几个方面。
优势：目标应该不仅仅是解决问题，还要提供业务上的优势；
度量：不仅要说明业务的优势，而且还必须提供度量这种优势的标准；
合理性：要确保完成解决方案所需的工作量少于所获得的业务优势，这才是合理的解决方案；
可行性：要探寻能够满足度量标准的解决方案；
可达成性：对于组织而言，是否具备获取该系统的技能，构建完成后是否能够操作它。
例如，表 8-1 就是一个很好的目标描述的例子。
2．功能需求
功能需求是用来指明系统必须做的事情，只有这些行为的存在，才有系统存在的价值。
功能需求应该源于业务需求，它只与问题域相关，与解决方案域无关。也就是说，功能需求
是在与用户或某个业务人员交谈时，他们所描述的内容是为了完成他们某部分的工作而必须
做的事情。而在设计解决方案时，会遇到一些限制条件，这些东西也是“系统需求” 的一
部分，不过应该是设计约束或非功能需求形式指定。
在规定功能需求时要注意其详细程度。由于这些需求是业务需求，因此应该由业务人员
来验证。也就是说，用户应该能够指明系统要达到有用的程度，功能是否已经足够；考虑到
工作的成果，它的功能是否正确。另外，在描述功能需求时，应该注意需求的二义性。而二
义性主要体现在以下几个方面。
（1）同名异义的词：在自然语言中存在许多同名但异义的词语，应该谨慎地排除它们
带来的影响。
（2）代词：在需求描述中，代词经常会产生指代不明的现象，应该尽量避免使用，而
是换成主语及宾语。
希赛教育专家提示：在检查功能需求的二义性时，一种有效的方法是大声地朗读出来，
大家一起边听边进行讨论，这样可以不断地优化。
3．非功能需求
非功能需求是系统必须具备的属性，这些属性可以看作是一些使产品具有吸引力、易用、
快速或可靠的特征或属性。非功能需求并不改变产品的功能，它是为工作赋予特征的。在识
别功能需求和非功能需求时，有一种十分有用的思维模式：功能需求是以动词为特征的，而
非功能性需求则是以副词为特征的。非功能需求主要包括以下几种。
（1）观感需求：
即产品外观的精神实质，也就是与用户界面的观感相关的一组属性；
（2）易用性需求：
也就是产品的易用性程度，以及特殊的可用性考虑，通常包括用户
的接受率、因为引入该产品而提高的生产效率、错误率、特殊人群的可用性等指标；
（3）性能需求：
也就是关于功能实现要求有多快、多可靠、多少处理量及多精确的约
束。例如：速度、精度、安全性、容量、值范围、吞吐量、资源使用效率、可靠性（平均无
故障时间）、可用性（不停机时间）、可扩展性等；
（4）可操作性需求：
衡量产品的操作环境，以及对该操作环境必须考虑的问题；
（5）可维护性和可移植性需求：
期望的改变，以及完成改变允许的时间；
（6）安全性需求：
产品的安全保密性，通常体现为保密性、完整性和可获得性；
（7）文化和政策需求：
由产品的开发者和使用者所带来的特别需求；
（8）法律需求：
哪些法律和标准适用于本产品。
三、需求分析与软件设计
需求分析是软件生命周期中相当重要的一个阶段。根据 Standish Group 对 23000 个项
目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只
有约 26%的项目获得成功。需求分析工作在整个软件开发生命周期中有着十分重要的意义。
而在这些高达 74%的不成功项目中，有约 60%的失败是源于需求问题，也就是差不多有一
半的项目都遇到了这个问题，这一可怕的现象引起人们对需求分析的高度重视。需求分析阶
段的主要任务是通过开发人员与用户之间的广泛交流，不断澄清一些模糊的概念，最终形成
一个完整的、清晰的、一致的需求说明。
而当明确了用户的需求之后，下一步的任务就是对未来的软件系统进行设计，它是确定
系统实现的关键工作。需求分析和设计的方法对软件开发过程而言是十分重要的，因此必须
扎实地掌握它。
需求分析与软件设计是软件生存期中最重要的两个步骤，需求分析解决的是“做什么”
的问题，系统设计则是解决“怎么做”的问题。
需求分析的任务与过程
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其
他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。用一句话
概括就是：需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。需求分析的
实现步骤通常包括：获取当前系统的物理模型，抽象出当前系统的逻辑模型，建立目标系统
的逻辑模型三个部分。具体来说，需求分析阶段的工作可以分成 4 个方面：
（1）问题识别：
用于发现需求、描述需求，主要包括功能需求、性能需求、环境需求、
可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，
以此来预先估计以后系统可能达到的目标。
（2）分析与综合：
也就是对问题进行分析，然后在此基础上整合出解决方案。这个步
骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法（Structured Analysis，SA），
面向数据结构的 Jackson 方法，面向对象的分析方法（Object Oriented Analysis，OOA）， 以
及用于建立动态模型的状态迁移图和 Petri 网。
（3）编制需求分析的文档：也就是对已经确定的需求进行文档化描述，该文档通常称
为“需求规格说明书”。
（4）需求分析与评审：它是需求分析工作的最后一步，主要是对功能的正确性、完整
性和清晰性，以及其他需求给予评价。
1．需求的分类
什么是软件的需求呢？软件需求就是系统必须完成的事及必须具备的品质。具体来说，
软件需求包括功能需求、非功能需求和设计约束三方面内容。各种需求的概念示意图如图
8-4 所示。
功能需求：是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须
执行的动作。
非功能需求：是指产品必须具备的属性或品质，如性能、响应时间、可靠性、容错性、
扩展性等。
设计约束：也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必
须采用国有自主知识版权的数据库系统，必须在 UNIX 操作系统之下运行等。
除了这三种需求之外，还有业务需求、用户需求、系统需求这三个处于不同层面的概念，
充分地理解这样的模型才能够更加清晰地理清需求的脉络。
业务需求（Business Requirement）：是指反映组织机构或客户对系统、产品高层次的目
标要求，通常问题定义本身就是业务需求。
用户需求（User Requirement）：是指描述用户使用产品必须要完成什么任务，怎么完成
的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从
而建立从用户角度出发的需求。
系统需求（System Requirement）：是从系统的角度来说明软件的需求，它包括用特性说
明的功能需求、质量属性、非功能需求及设计约束。
分析师经常围绕着“功能需求”来展开工作，而功能需求大部分都是从“系统需求” 的
角度来分析与理解的，也就是用“开发人员”的视角来理解需求。但要想真正地得到完整的
需求，仅戴上“开发人员”的眼镜是不够的，还需要“领域专家”的眼镜，要从更高的角度
来理解需求，这就是“业务需求”；同时还应该更好地深入用户，了解他们的使用场景，了
解他们的想法，这就是“用户需求”。这是一个理解层次的问题，并不仅仅是简单的概念。
2．需求工程
需求工程就是包括创建和维护系统需求文档所必需的一切活动的过程，主要包括需求
开发和需求管理两大工作。
（1）需求开发：包括需求捕获、需求分析、编写规格说明书和需求验证 4 个阶段。在
这个阶段需要完成确定产品所期望的用户类型、获取每种用户类型的需求、了解实际用户任
务和目标及这些任务所支持的业务需求、分析源于用户的信息、对需求进行优先级分类、将
所收集的需求编写成为软件规格说明书和需求分析模型、对需求进行评审等工作。
（2）需求管理：通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。
这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句
话说，需求开发是努力更清晰、更明确地掌握客户对系统的需求；而需求管理则是对需求的
变化进行管理的过程。
3．需求分析方法
需求分析的方法可谓种类繁多，不过如果按照分解方式的不同，可以很容易地划分出几
种类型。本节先从分析方法发展的历史，对其建立一个概要性的认识，在本章的后面几节中
将详细说明最具有代表性的结构化分析与设计、面向对象分析与设计两种方法。
（1）结构化分析方法：最初的分析方法都不成体系，而且通常都只包括一些笼统的告
诫 ，在 20 世纪 70 年代分析技术发展的分水岭终于出现了。这时人们开始尝试使用标准化
的方法，开发和推出各种名为“结构化分析”的方法论，而 Tom DeMacro 则是这个领域最
有代表性和权威性的专家。
（2）软系统方法：这是一个过渡性的方法论，并未真正流行过，它的出现只是证明了
结构化分析方法的一些不足。因为结构化分析方法采用的相对形式化的模型不仅与社会观格
格不入，而且在解决“不确定性”时显得十分无力。最有代表性的软系统方法是 Checkland
方法。
（3）面向对象分析方法：在 20 世纪 90 年代，结构化方法的不足在面对多变的商业
世界时，显得更加苍白无力，这就催使了 OOA 的迅速发展。
（4）面向问题域的分析（Problem Domain Oriented Analysis，PDOA）：现在又发现面向
对象分析方法也存在着很多的不足，应运而生了一些新的方法论，PDOA 就是其中一种。不
过现在还在研究阶段，并未广泛应用。
四、 如何进行系统设计
当设计者拿到一个需求，他如何开展系统设计呢？许多想进入系统分析与设计的年轻人
以为自己知道了面向对象、统一建模语言、设计模式等新鲜深奥的名词就可以进行设计了，
可是掌握工具和技能绝不是成为优秀设计者的充分条件，甚至也不是必要条件。遗憾的是这
里没有捷径，只有设计者在实践中不断学习和总结。而在实践中，系统设计与其说是在设计，
不如说是在选择和妥协。
妥协，就是在各个系统目标之间找到一个平衡点。系统目标包括但不限制于功能、性
能、健壮性、开发周期、交付日期等。不幸的是，这些目标往往是矛盾的，提高软件性能直
接意味着开发周期的增加、交付日期的推迟，盲目地增加功能可能导致性能降低，维护成本
提高。软件设计者的难题在于在如此众多的目标之间找到这个平衡点，并且明确知道如何设
计能实现这个平衡，既可以让投资者觉得在预算之内，又能让用户相对满意。可行性分析阶
段应该已经论述了这样一个平衡点，可是如果设计者发现没有这样一个平衡点，如同没有一
个设计者能让人骑着自行车到月球上去，那么设计者只能提出放弃某个方面的过度要求，否
则系统要遭受必然失败的命运。更多的情况是没有经验的设计者不知道是否存在这些平衡点，
更不知道如何利用合理的设计及有效的工具来达到平衡。因此设计者需要了解可以解决问题
的各种方案，并清楚知道各个方案的效果、成本、缺点，以及这些方案的区别，并在各种方
案中进行选择。而这些，不是一个人能在一两天了解的。
没有一个设计者会完全重新开始设计一个系统，他们总参考多个与目标系统相类似的系
统，再从中进行甄别、取舍和补充来作为新系统的设计。人们发现一个优秀的设计者似乎能
在听完需求后就立即构想出目标系统的框架，这并不是因为他聪明或者比不知所措的设计者
新手多一个脑袋，而是因为他在平时已经了解大量的系统，对各种设计的优缺点、局限性也
了然于胸，能够把以前的设计根据需要再次使用。所以要成为优秀的设计者，了解、掌握、
消化、总结前人和自己以前的设计成果是最好的方法，这似乎也是唯一的方法。
设计者的苦恼有时候和编程人员一样。计算机系统的发展如此迅速，解决方案也越来越
多，如同编程语言的发展，同时，随着人类社会的进步，投资者和客户也提出了越来越高的
要求，这又需要设计者不断学习、创造新的方案。
但系统设计也并非没有规律可以遵循，如同幸福的家庭都很相似，不幸的家庭各有各的
不幸，人们在实践中发现优秀的系统设计一般在以下几个方面都很出色。
（1）组件的独立性。审视自己设计的系统，是否做到了高内聚、低耦合？
（2）例外的识别和处理。谁能保证系统使用者都精确按照使用说明书使用？
（3）防错和容错。当网络中断、数据库崩溃这样的灾难性事件发生时，系统也跟着崩
溃吗？
而且，更幸运的是，也有一些技术能够改进系统设计，这些方法包括：降低复杂性、通
过合约进行设计、原型化设计、错误树分析等。
五、软件设计的任务与活动
软件设计(又叫系统设计 xxk)是一个把软件需求变换成软件表示的过程。最初这种表示
只是描绘出软件的总体框架，然后再进一步细化，并在此框架中填入细节。
1.软件设计的两个阶段从工程管理角度，软件设计可以分为两个步骤：
（1）概要设计：也称为高层设计，将软件需求转化为数据结构和软件的系统结构。例
如，如果采用结构化设计，则将从宏观的角度将软件划分成各个组成模块，并确定模块的功
能及模块之间的调用关系。
（2）详细设计：也称为低层设计，将对结构表示进行细化，得到详细的数据结构与算
法。同样的，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。
2．主要的设计方法比较
在结构化设计风行的时代，主流的设计方法还包括 Jackson 方法和 Parnas 方法。结构
化方法侧重于“模块相对独立且功能单一，使模块间联系弱、模块内联系强”；而 Jackson 方
法则是从数据结构导出模块结构；Parnas 方法的主要思想则是将可能引起变化的因素隐藏
在有关模块内部，使这些因素变化时的影响范围受到限制，它只提供了重要的设计准则，但
没有规定出具体的工作步骤。
而近年来，对象技术凭借其对数据的高效封装及良好的消息机制，实现了高内聚、低耦
合的系统设计，成了现代软件设计的主流方法学。
六、结构化分析与设计
结构化分析与设计方法是一种面向数据流的需求分析和设计方法，它适用于分析和设计
大型数据处理系统，是一种简单、实用的方法，曾获得广泛的应用。
1 结构化分析
结构化分析方法的基本思想是自顶向下逐层分解。分解和抽象是人们控制问题复杂性的
两种基本手段。对于一个复杂的问题，人们很难一下子考虑问题的所有方面和全部细节，通
常可以把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题，经过多
次逐层分解，每个最底层的问题都是足够简单、容易解决的，于是复杂的问题也就迎刃而解
了。这个过程就是分解过程。
结构化分析与面向对象分析方法之间的最大差别是：结构化分析方法把系统看作一个过
程的集合体，包括人完成的和电脑完成的；而面向对象方法则把系统看成一个相互影响的对
象集。结构化分析方法的特点是利用数据流图来帮助人们理解问题，对问题进行分析。
结构化分析一般包括以下工具：数据流图（Data Flow Diagram，DFD）、数据字典（Data
Dictionary，DD）、结构化语言、判定表、判定树。在接下来的部分将对它们一一做简单介绍。
结构化系统分析方法从总体上来看是一种强烈依赖数据流图的自顶向下的建模方法。它
不仅是需求分析技术，也是完成需求规格化的有效技术手段。
1．结构化分析的工作步骤
在介绍具体的结构化分析方法之前，先对如何进行结构化分析做一个总结性描述，以帮
助大家更好地应用该方法。
（1）研究“物质环境”。首先，应画出当前系统（可能是非计算机系统，或是半计算机
系统）的数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，以及经历了哪
些处理过程。在这个数据流图中，可以包括一些非计算机系统中数据流及处理的命名，例如
部门名、岗位名、报表名等。这个过程可以帮助分析员有效地理解业务环境，在与用户的充
分沟通与交流中完成。
（2）建立系统逻辑模型。当物理模型建立完成之后，接下来的工作就是画出相对于真
实系统的等价逻辑数据流图。在前一步骤建立的数据流图的基础上，将所有自然数据流都转
成等价的逻辑流，例如，将现实世界的报表存储在计算机系统中的文件里；又如将现实世界
中“送往总经理办公室”改为“报送报表”。
（3）划清人机界限。最后，确定在系统逻辑模型中，哪些将采用自动化完成，哪些仍
然保留手工操作。这样，就可以清晰地划清系统的范围。
2．数据流图
DFD 是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输
出、处理（过程）、数据存储。由于从 DFD 中可以很容易地看出系统紧密结合的各个部分，
而且整个图形模式只有 5 个符号需要记忆，所以深受分析人员的喜爱，因而广为流行。
如图 8-5 所示，DFD 中包括以下几个基本元素。
l 过程：也称为加工(处理)，一步步地执行指令，完成输入到输出的转换。
l 外部实体：也称为源/宿，系统之外的数据源或目的。
l 数据存储：也称为文件，存放数据的地方，一般是以文件、数据库等形式出现。
l 数据流：从一处到另一处的数据流向，如从输入或输出到一个过程的数据流。
l 实时连接：当过程执行时，外部实体与过程之间的来回通信。
不同的参考书籍中关于 DFD 的符号可能有些不一样，其中加工、
外部实体、数据存储和数据流是公共的部分。
（1）数据流图的层次。正如前面提到的，结构化分析的思路是依赖于数据流图进行自
顶而下的分析。这也是因为系统通常比较复杂，很难在一张图上将所有的数据流和加工描述
清楚。因此，数据流图提供一种表现系统高层和低层概念的机制。也就是先绘制一张较高层
次的数据流图，然后在此基础上，对其中的过程（处理）进行分解，分解成为若干独立的、
低层次的、详细的数据流图，而且可以这样逐一地分解下去，直至系统被清晰地描述出来。
数据流图的层次如图 8-6 所示。
（2）Context 图。Context 图，也就是系统上下文范围关系图。这是描述系统最高层结
构的 DFD 图。它的特点是，将整个待开发的系统表示为一个过程，将所有的外部实体和进
出系统的数据流都画在一张图中。图 8-7 就是一个 Context 图的例子。
Context 图用来描述系统有什么输入、输出数据流，与哪些外部实体直接相关，可以把
整个系统的范围勾画出来。
（3）逐级分解。当完成了 Context 图的建模之后，就可以在此基础上进行进一步的分
解。以图 8-7 为例，进行再分解，在对原有流程了解的基础上，可以得到如图 8-8 所示的
结果。
图 8-8 是在 Context 图的基础上做的第一次分解，而在 Context 图中只有一个过程，
那就是系统，将其编号为 0。而接下来对 Context 图进行的分解，其实就是对这个编号为 0
的过程进行更细化的描述，在这里引入了新的过程、数据存储，为了能够区分其位置的级别，
在这层次上的过程将以 1、2、3 为序列进行编号。
由于这是对过程 0 的分解，因此也称之为 DFD 0 层图。而可以根据需要对 DFD 0 层
图上的过程（编号为 1、2、3）进行类似的分解，那么就称之为 DFD 1 层图，在 DFD 1 层
图中引入的新过程，其编号规则就是 1.1，1.2…，以及 2.1，2.2…，以此类推，直到完成
分析工作。
另外，这里存在一个很关键的要点，那就是 DFD 0 层图是 Context 图的细化，因此所
有的输入和输出应该与 Context 图完全一致，否则就说明存在着错误。
（4）如何画 DFD。DFD 的绘制是一个自顶向下、由外到里的过程，通常按照以下几个
步骤进行。
l 画系统的输入和输出：就是在图的边缘标出系统的输入、输出数据流。这一步其实是决
定研究的内容和系统的范围。在画的时候，可以先将尽可能多的输入、输出画出来，然
后再删除多余的，增加遗漏的。
l 画数据流图的内部：将系统的输入、输出用一系列的处理连接起来，可以从输入数据流
画向输出数据流，也可以从中间画出去。
l 为每一个数据流命名：命名的好坏与数据流图的可理解性密切相关，应避免使用空洞的
名字。
l 为加工命名：注意应该使用动宾短语。
l 不考虑初始化和终点，暂不考虑出错路径等细节，不画控制流和控制信息。
3.细化记录 DFD 部件
为了更好地描述 DFD 的部件，结构化分析方法还引入了数据字典、结构化语言及决策树、
决策表等方法。通过使用这些工具，能对数据流图中描述不够清晰的地方进行有效的补充。
其其中数据字典应用最为广泛，下面将详细说明数据字典的相关使用方法。
数据字典技术是一种很实用、有效的表达数据格式的手段。它是对所有与系统相关的 数
据元素的一个有组织的列表和精确严格的定义，使得用户和系统分析员对于输入、输出、 存
储成分和中间计算机有共同的理解。通常数据字典的每一个条目中包括以下信息。
① 名称：数据或控制项、数据存储或外部实体的主要名称，如果有别名的还应该将别
名列出来。
② 何处使用/如何使用：使用数据或控制项的加工列表，以及如何使用。
③ 内容描述：说明该条目的内容组成，通常采用以下符号进行说明。
=：由…构成。
+：和，代表顺序连接的关系。
[ | ]：或，代表从中选择一个。
{}*：n 次重复。
（）：代表可选的数据项。
*…*：表示特定限制的注释。
④ 补充信息：关于数据类型、默认值、限制等信息。
下面就是一个数据字典的实例：
客户基本信息=客户编号+客户名称+身份证号码+手机+家庭电话
客户编号 = {0…9}8
客户名称 = {字}4
身份证号码 = [{0…9}15|{0…9}18]
手机 = [{0…9}11|{0…9}12]
家庭电话 =（区号）+本地号区号 = {0…9}4
本地号 = [{0…9}7|{0…9}8]
八、结构化设计
结构化设计包括架构设计、接口设计、数据设计和过程设计等任务。它是一种面向数据
流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶而下、逐步求精和模
块化的过程。
1．概要设计与详细设计的主要任务
概要设计阶段的主要任务是设计软件的结构、确定系统是由哪些模块组成，以及每个模
块之间的关系。它采用结构图（包括模块、调用、数据）来描述程序的结构，此外还可以使
用层次图和 HIPO（层次图加输入/处理/输出图）。
整个过程主要包括：复查基本系统模型、复查并精化数据流图、确定数据流图的信息流
类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析、根据软件设计原
则对得到的软件结构图进一步优化。
详细设计阶段的主要任务则是确定应该如何具体地实现所要求的系统，得出对目标系统
的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。常使用的
工具包括程序流程图 PFD、盒图 NS、问题分析图 PAD、程序设计语言 PDL。
2．结构图
如图 8-9 所示，结构图的基本成分包括模块、调用（模块之间的调用关系）和数据（模
块间传递及处理数据信息）。
结构图是在需求分析阶段产生的数据流图的基础上进行进一步的设计。它将 DFD 图中
的信息流分为两种类型。
变换流：信息首先沿着输入通路进入系统，并将其转换为内部表示，然后通过变换中心
（加工）的处理，再沿着输出转换为外部形式离开系统。具有这种特性的加工流就是变换流。
事务流：信息首先沿着输入通路进入系统，事务中心根据输入信息的类型在若干个动作
序列（活动流）中选择一个执行，这种信息流称为事务流。
3．程序流程图和盒图
程序流程图和盒图都是用来描述程序的细节逻辑的，其符号如图 8-10 所示。
程序流程图的特点是简单、直观、易学，但它的缺点也正是由于其随意性而使得画出来
的流程图容易成为非结构化的流程图。而盒图正是为了解决这一问题设计的，它是一种符合
结构化程序设计原则的图形描述工具。
盒图的主要特点是功能域明确、无法任意转移控制、容易确定全局数据和局部数据的作
用域、容易表示嵌套关系、可以表示模块的层次结构。但它也带来了一个副作用，那就是修
改相对比较困难。
4．PAD 和 PDL
PAD 是问题分析图的缩写，它符合自顶向下、逐步求精的原则，也符合结构化程序设
计的思想，它最大的特点在于能够很方便地转换为程序语言的源程序代码。
PDL 则是语言描述工具的缩写，它和高级程序语言很相似，也包括数据说明部分和过程
部分，还可以带注解等成分，但它是不可执行的。PDL 是一种形式化语言，其控制结构的描
述是确定的，但内部的描述语法是不确定的。PDL 通常也被称为伪码。
九、 模块设计
在结构化方法中，模块化是一个很重要的概念，它是将一个待开发的软件分解成为若干
个小的简单部分——模块，每个模块可以独立地开发、测试。这是一种复杂问题的“分而治
之”原则，其目的是使程序的结构清晰、易于测试与修改。
具体来说，模块是指执行某一特定任务的数据结构和程序代码。通常将模块的接口和功
能定义为其外部特性，将模块的局部数据和实现该模块的程序代码称为内部特性。而在模块
设计时，最重要的原则就是实现信息隐蔽和模块独立。模块经常具有连续性，也就意味着作
用于系统的小变动将导致行为上的小变化，同时规模说明的小变动也将影响到一小部分模块。
1．信息隐蔽原则
信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单
一的设计模块中，并且尽可能少地暴露其内部的处理。通常将难的决策、可能修改的决策、
数据结构的内部连接以及对它所做的操作细节、内部特征码、与计算机硬件有关的细
节等隐蔽起来。通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性，它也是现代
软件设计的一个关键性原则。
2．模块独立性原则
模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系最
简单。保持模块的高度独立性，也是设计过程中的一个很重要的原则。通常用耦合（模块之
间联系的紧密程度）和内聚（模块内部各元素之间联系的紧密程度）两个标准来衡量，设计
的目标是高内聚、低耦合。
模块的内聚类型通常可以分为 7 种，根据内聚度从高到低排序，如表 8-2 所示。
与此相对应的，模块的耦合性类型通常也分为 7 种，根据耦合度从低到高排序，如表
8-3 所示。
除了满足以上两大基本原则之外，通常在模块分解时还需要注意：保持模块的大小适中，
尽可能减少调用的深度，直接调用该模块的个数应该尽量大，但调用其他模块的个数则不宜
过大；保证模块是单入口、单出口的；模块的作用域应该在控制域之内；功能应该是可预测
的。
十、面向对象的分析与设计
面向对象方法是一种非常实用的软件开发方法，它一出现就受到软件技术人员的青睐，
现已成为计算机科学研究的一个重要领域，并逐渐成为软件开发的一种主要方法。面向对象
方法以客观世界中的对象为中心，其分析和设计思想符合人们的思维方式，分析和设计的结
构与客观世界的实际比较接近，容易被人们接受。在面向对象方法中，分析和设计的界面并
不明显，它们采用相同的符号表示，能够方便地从分析阶段平滑地过渡到设计阶段。此外，
在现实生活中，用户的需求经常会发生变化，但客观世界的对象及对象间的关系比较稳定，
因此用面向对象方法分析和设计的结构也相对比较稳定。
面向对象的基本概念
1．对象和类
对象是系统中用来描述客观事物的一个实体，它由对象标识（名称）、属性（状态、数
据、成员变量）和服务（操作、行为、方法）三个要素组成，它们被封装为一个整体，以接
口的形式对外提供服务。
在现实世界中，每个实体都是对象，如学生、书籍、收音机等；每个对象都有它的操作，
例如书籍的页数，收音机的频道、按钮等属性，以及收音机的切换频道等操作。
而类则是对具有相同属性和服务的一个或一组对象的抽象。类与对象是抽象描述和具体
实例的关系，一个具体的对象被称为类的一个实例。在系统设计过程中，类可以分为三种类
型，分别是实体类、边界类和控制类。
（1）实体类：
实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的
信息，例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。实体类通
常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都
需要。
实体类是对用户来说最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，
在用例模型向领域模型的转化中，一个参与者一般对应于实体类。通常可以从 SRS 中的那
些与数据库表（需要持久存储）对应的名词着手来找寻实体类。通常情况下，实体类一定有
属性，但不一定有操作。
（2）控制类：
控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名
词”或“名词+动词”）转化来的名词，例如，用例“身份验证”可以对应于一个控制类“身
份验证器”，它提供了与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的
控制行为进行建模，控制对象（控制类的实例）通常控制其他对象，因此，它们的行为具有
协调性。
控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系
统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。
通常情况下，控制类没有属性，但一定有方法。
（3）边界类：
边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与
外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接
口。要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，
边界类使参与者能与系统交互。边界类是一种用于对系统外部环境与其内部运作之间的交互
进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，
在系统设计时，产生的报表都可以作为边界类来处理。
边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更（例如，
与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分
造成影响。通常情况下，边界类可以既有属性也有方法。
2．继承与泛化
继承是面向对象方法中重要的概念，用来说明特殊类（子类）与一般类（父类）的关系，
而通常用泛化来说明一般类与特殊类的关系，也就是说它们是一对多关系。
如图 8-11 所示，“交通工具”是“自行车”和“小轿车”的泛化；“自行车”和“小轿
车”从“交通工具”中继承。
3．多态与重载
多态（即多种形式）性是指一般类中定义的属性或服务被特殊类继承后，可以具有不同
的数据类型或表现出不同的行为，通常是使用重载和改写两项技术来实现的。一般有 4 种不
同形式的多态，如表 8-4 所示。
图---------------------------------------------
注 1：重载也称为过载、重置；
注 2：参数多态和包含多态称为通用多态，重载多态和强制多态称为特定多态。
虽然重载和改写都是在多种潜在的函数体中，选择和调用某一个函
数或方法并对其进行执行，但它们的本质区别在于：重载是编译时执行的（静态绑定），而
改写则是运行时选择的（动态绑定）。
4．模板类
也称为类属类，它用来实现参数多态机制。一个类属类是关于一组类的一个特性抽象，
它强调的是这些类的成员特征中与具体类型无关的那些部分，而用变元来表示与具体类型有
关的那些部分。
5．消息和消息通信
消息就是向对象发出的服务请求，它通常包括提供服务的对象标识、消息名、输入信息
和回答信息。消息通信则是面向对象方法学中的一个重要原则，它与对象的封装原则密不可
分，为对象间提供了唯一合法的动态联系的途径。
十一、面向对象分析
面向对象分析的目标是开发一系列模型，这些模型描述计算机软件，当它工作时以满足
一组客户定义的需求。对象技术的流行，演化出了数十种不同的 OOA 方法，每个方法都引
入了一个产品或系统分析的过程、一组过程演化的模型及使软件工程师能够以一致的方式创
建每个模型的符号体系。其中比较流行的方法包括 OMT、OOA、OOSE、Booch 方法等，而
OMT、OOSE、Booch 最后则统一成为 UML。
1．OOA/OOD 方法
这是由 Peter Coad 和 Edward Yourdon 提出的，OOA 模型中包括主题、对象类、结构、
属性和服务 5 个层次，需经过标识对象类、标识结构与关联（包括继承、聚合、组合、实
例化等）、划分主题、定义属性、定义服务 5 个步骤来完成整个分析工作。
OOD 中将继续贯穿 OOA 中的 5 个层次和 5 个活动，它由人机交互部件、问题域部件、
任务管理部件、数据管理部件 4 个部分组成，其主要的活动就是这 4 个部件的设计工作。
设计问题域部分：OOA 的结果恰好是 OOD 的问题域部件，分析的结果在 OOD 中可以被
改动或增补，但基于问题域的总体组织框架是长时间稳定的；
设计人机交互部件：人机交互部件在上述结果中加入人机交互的设计和交互的细节，包括窗
口和输出报告的设计。可以用原型来帮助实际交互机制进行开发和选择；
设计任务管理部分：这部分主要是识别事件驱动任务，识别时钟驱动任务，识别优先任务和
关键任务，识别协调者，审查每个任务并定义每个任务。
设计数据管理部分：数据管理部分提供了在数据管理系统中存储和检索对象的基本结构，其
目的是隔离数据管理方法对其他部分的影响。
2．Booch 方法
Booch 认为软件开发是一个螺旋上升的过程，每个周期中包括标识类和对象、确定类和
对象的含义、标识关系、说明每个类的接口和实现 4 个步骤。它的模型中主要包括如表 8-5
所示的几种图形。
Booch 方法的开发过程是一个迭代的、渐进式的系统开发过程，它可以分为宏过程和微
过程两类。宏过程用于控制微过程，是覆盖几个月或几周所进行的活动，它包括负责建立核
心需求的概念化，为所期望的行为建立模型的分析，建立架构的设计，形成实现的进化，以
及管理软件交付使用的维护等 5 个主要活动。
而微过程则基本上代表了开发人员的日常活动，它由 4 个重要、没有顺序关系的步骤
组成：在给定的抽象层次上识别出类和对象，识别出这些类和对象的语义，识别出类间和对
象间的关系，实现类和对象。
3．OMT 方法
OMT 是对象建模技术的缩写，它是由 Jam Rambaugh 及其同事合作开发的，它主要用
于分析、系统设计和对象设计。包括对象模型（静态的、结构化的系统的“数据”性质，通
常采用类图）、动态模型（瞬时的、行为化的系统“控制”性质，通常使用状态图）和功能
模型（表示变化的系统的“功能”性质，通常使用数据流图）。OMT 方法的三大模型如表 8-6
所示。
4.OOSE 方法
OOSE 是面向对象软件工程的缩写，它是由 Ivar Jacobson 提出的。它在 OMT 的基础
上，对功能模型进行了补充，提出了“用例”的概念，最终取代数据流图进行需求分析和建
立功能模型。
十二、统一建模语言
统一建模语言（Unified Modeling Language，UML）是用于系统的可视化建模语言，它将
OMT、OOSE 和 Booch 方法中的建模语言和方法有机地融合在一起，是国际统一的软件建
模标准。虽然它源于 OO 软件系统建模领域，但由于其内建了大量扩展机制，也可以应用
于更多的领域中，例如工作流程、业务领域等。
1．UML 是什么
UML 是一种语言：UML 在软件领域中的地位与价值就像“1、2、3、+、 、…”等符号在
数学领域中的地位一样。它为软件开发人员之间提供了一种用于交流的词汇表和一种用于软
件蓝图的标准语言。
UML 是一种可视化语言：UML 只是一组图形符号，它的每个符号都有明确语义，是一种直
观、可视化的语言。
UML 是一种可用于详细描述的语言：UML 所建的模型是精确的、无歧义和完整的，因此适
合于对所有重要的分析、设计和实现决策进行详细描述。
UML 是一种构造语言：UML 虽然不是一种可视化的编程语言，但其与各种编程语言直接相
连，而且有较好的映射关系，这种映射允许进行正向工程、逆向工程。
UML 是一种文档化语言：它适合于建立系统架构及其所有的细节文档。
2．UML 的结构
UML 由构造块、公共机制和架构三个部分组成。
（1）构造块。构造块也就是基本的 UML 建模元素（事物）、关系和图。
建模元素：包括结构事物（类、接口、协作、用例、活动类、组件、节点等）、行为事物（交
互、状态机）、分组事物（包）、注释事物。
关系：包括关联关系、依赖关系、泛化关系、实现关系。
图 ：UML 2.0 包括 14 种不同的图，分为表示系统静态结构的静态模型（包括类图、对象图、
包图、构件图、部署图、制品图），以及表示系统动态结构的动态模型（包括对象图、用例
图、顺序图、通信图、定时图、状态图、活动图、交互概览图）。
（2）公共机制。公共机制是指达到特定目标的公共 UML 方法，主要包括规格说明、
修饰、公共分类和扩展机制 4 种。
规格说明：规格说明是元素语义的文本描述，它是模型的重要组成部分。
修饰：UML 为每一个模型元素设置了一个简单的记号，还可以通过修饰来表达更多的信息。
公共分类：包括类元与实体（类元表示概念，而实体表示具体的实体）、接口和实现（接口
用来定义契约，而实现就是具体的内容）两组公共分类。
扩展机制：包括约束（添加新规则来扩展元素的语义）、构造型（用于定义新的 UML
建模元素）、标记值（添加新的特殊信息来扩展模型元素的规格说明）。
（3）架构。UML 对系统架构的定义是：系统的组织结构，包括系统分解的组成部分、
它们的关联性、交互、机制和指导原则，这些提供系统设计的信息。而具体来说，就是指 5
个系统视图。
逻辑视图：以问题域的语汇组成的类和对象集合。
进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例。
实现视图：对组成基于系统的物理代码的文件和组件进行建模。
部署视图：把组件物理地部署到一组物理的、可计算的节点上。
用例视图：最基本的需求分析模型。
3．用例图基础
用例是什么呢？Ivar Jacobson 是这样描述的：“用例实例是在系统中执行的一系列动作，
这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。”首先，从定义
中得知用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用
系统的一个实际的、特定的场景。其次，可以知道，用例应该给参与者带来可见的价值，这
点很关键。最后，用例是在系统中的。
而用例模型描述的是外部参与者所理解的系统功能。用例模型用于需求分析阶段，它的
建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。图
8-12 就是一个用例图的例子。
椭圆圈圈就是”用例”
（1）参与者。参与者代表与系统接口的任何事物或人，它是指代表某一种特定功能的
角色，因此，参与者都是虚拟的概念。在 UML 中，用一个小人表示参与者。
图 8-12 中的“图书管理员”就是参与者。对于该系统来说，可能可以充当图书管理员
角色的有多个人，由于他们对系统均起着相同的作用，扮演相同的角色，因此只用一个参与
者来表示。切忌不要为每一个可能与系统交互的真人画出一个参与者。
（2）用例。用例是对系统行为的动态描述，它可以促进设计人员、开发人员与用户的
沟通，理解正确的需求，还可以划分系统与外部实体的界限，是系统设计的起点。在识别出
参与者之后，可以使用下列问题帮助识别用例。
每个参与者的任务是什么？
有参与者将要创建、存储、修改、删除或读取系统中的信息吗？
什么用例会创建、存储、修改、删除或读取这个信息？
参与者需要通知系统外部的突然变化吗？
需要通知参与者系统中正在发生的事情吗？
什么用例将支持和维护系统？
所有的功能需求都对应到用例中了吗？
系统需要何种输入/输出？输入从何处来？输出到何处？
当前运行系统的主要问题是什么？
（3）包含和扩展。两个用例之间的关系可以主要概括为两种情况。一种是用于重用的
包含关系，用构造型<<include>>或者<<use>>表示；另一种是用于分离出不同的行为，用构
造型<<extend>>表示。
包含关系：当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一
个组件来实现某一个用例的部分功能是很重要的事时，应该使用包含关系来表示。所提取出
来的公共行为称为抽象用例。包含关系的例子如图 8-13 所示。
扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发
生多种事情。可以将这个用例分为一个主用例和一个或多个辅用例，描述可能更加清晰。扩
展关系的例子如图 8-14 所示。
补充. .（4）通信关联。通信关联表示的是参与者和用例之间的关系，或用例与用例之间
的关系。箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受
者，箭尾所指方是对话的主动发起者。如果不想强调对话中的主动与被动关系，可以使用不
带箭头的关联实线。在用例模型中，信息流不是由通信关联来表示的，该信息流是默认存在
的，并且是双向的，它与箭头所指的方向没有关系。
此处介绍的包含和扩展关系属于用例之间所特有的关系，因为用例也是
UML 的一种结构事物，因此，事物之间的 4 种基本关系对用例也是适用的。
4．类图和对象图基础
在面向对象建模技术中，将客观世界的实体映射为对象，并归纳成一个个类。类、对象
和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统，其类模型和
对象模型揭示了系统的结构。在 UML 中，类和对象模型分别由类图和对象图表示。类图技
术是 OO 方法的核心。图 8-15 是一个类图的实例。
（1）类和对象。对象与人们对客观世界的理解相关。人们通常用对象描述客观世界中
某个具体的实体。所谓类是对一类具有相同特征的对象的描述。而对象是类的实例。在 UML
中，类的可视化表示为一个划分成三个格子的长方形（下面两个格子可省略）。图 8-15 中，
“书籍”、“借阅记录”等都是一个类。
类的获取和命名：最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语，应明
确、无歧义，以利于开发人员与用户之间的相互理解和交流。
类的属性：中间的格子包含类的属性，用以描述该类对象的共同特点。该项可省略。图 8-15
中“书籍”类有“书名”、“书号”等属性。UML 规定类的属性的语法为： “可见性 属性
名：类型 = 默认值 {约束特性}”。
可见性包括 Public、Private 和 Protected，分别用+、-、#号表示。
类型表示该属性的种类：它可以是基本数据类型，例如整数、实数、布尔型等，也可以
是用户自定义的类型。一般它由所涉及的程序设计语言确定。约束特性则是用户对该属性性
质的一个约束说明。例如“{只读}”说明该属性是只读属性。
类的操作（Operation）：该项可省略。操作用于修改、检索类的属性或执行某些动作。操作
通常也被称为功能，但是它们被约束在类的内部，只能作用到该类的对象上。操作名、返回
类型和参数表组成操作界面。UML 规定操作的语法为：“可见性：操作名（参数表）：返回
类型 {约束特性}”。
类图描述了类和类之间的静态关系。定义了类之后，就可以定义类之间的各种关系了。
（2）类之间的关系。在建立抽象模型时，会发现很少有类会单独存在，大多数都将会
以某种方式互相协作，因此还需要描述这些类之间的关系。关系是事物间的连接，在面向对
象建模中，有 4 个很重要的关系。
① 依赖关系。有两个元素 X、Y，如果修改元素 X 的定义可能会引起对另一个元素 Y 的
定义的修改，则称元素 Y 依赖于元素 X。在 UML 中，使用带箭头的虚线表示依赖关系。
在类中，依赖由多种原因引起，如：一个类向另一个类发消息；一个类是另一个类的数
据成员；一个类是另一个类的某个操作参数。如果一个类的界面改变，它发出的任何消息可
能不再合法。
② 泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父
类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而
父类则是子类的泛化。在 UML 中，使用带空心箭头的实线表示，箭头指向父类。
在 UML 中，对泛化关系有 3 个要求：
子类应与父类完全一致，父类所具有的关联、属性和操作，子类都应具有。
子类中除了与父类一致的信息外，还包括额外的信息。
可以使用子父类实例的地方，也可以使用子类实例。
③ 关联关系。关联表示两个类之间存在某种语义上的联系。例如，一个人为一家公司
工作，一家公司有许多办公室。就认为人和公司、公司和办公室之间存在某种语义上的联系。
关联关系提供了通信的路径，它是所有关系中最通用的、语义最弱的。在 UML 中，用
一条实线来表示关联关系。
聚合关系：聚合是一种特殊形式的关联。聚合表示类之间的关系是整体与部分的关系。例如
一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘，就是聚合的一个例子。在 UML
中，用一个带空心菱形的实线表示，空心菱形指向的是代表“整体”的类。
组合关系：如果聚合关系中的表示“部分”的类的存在，与表示“整体”的类有着紧密的关
系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示。在 UML 中，
用带有实心菱形的实线表示，菱形指向的是代表“整体”的类。
聚合关系是指部分与整体的生命周期可以不相同，而组合关系则是
指部分与整体的生命周期是相同的。
④ 实现关系。实现关系是用来规定接口和实现接口的类或组件之间的关系的。接口是
操作的集合，这些操作用于规定类或组件的服务。在 UML 中，用一个带空心箭头的虚线表
示。
（3）多重性问题。重复度又称多重性，多重性表示为一个整数范围 n…m，整数 n 定
义所连接的最少对象的数目，而 m 则为最多对象数（当不知道确切的最大数时，最大数用
*号表示）。最常见的多重性有：0…1；0…*；1…1；1…*；*。
多重性是用来说明关联的两个类之间的数量关系的，例如：
书与借书记录之间的关系，就应该是 1 对 0…1 的关系，也就是一本书可以有 0 个或 1 个
借书记录。
经理与员工之间的关系，则应为 1 对 0…*的关系，也就是一个经理可以领导 0 个或多个
员工。
学生与选修课程之间的关系，就可以表示为 0…*对 1…*的关系，也就是一个学生可以选择
1 门或多门课程，而一门课程可以有 0 个或多个学生选修。
（4）类图。对于软件系统，其类模型和对象模型类图描述类和类之间的静态关系。与
数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图是定义其他图的
基础。
（5）对象图。UML 中对象图与类图具有相同的表示形式。对象图可以看作是类图的一
个实例。对象是类的实例；对象之间的链（Link）是类之间的关联的实例。对象与类的图形
表示相似，均为划分成两个格子的长方形（下面的格子可省略）。上面的格子是对象名，对
象名下有下画线；下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复
杂类图的一个实例。
5．交互图基础
交互图是表示各组对象如何依某种行为进行协作的模型。通常可以使用一个交互图来表
示和说明一个用例的行为。在 UML 中，包括 3 种不同形式的交互图，强调对象交互行为
顺序的顺序图，强调对象协作的通信图（UML1.X 版本中称为“协作图”），强调消息的具体
时间的定时图，它们之间没有什么本质不同，只是排版不尽相同而已。
（1）顺序图。顺序图用来描述对象之间动态的交互关系，着重体现对象间消息传递的
时间顺序。顺序图允许直观地表示出对象的生存期，在生存期内，对象可以对输入消息做出
响应，并且可以发送信息。图 8-16 是一个顺序图的示例。
如图 8-16 所示，顺序图存在两个轴，水平轴表示不同的对象，即图中的 Client、Factory、
Product 等；而垂直轴表示时间，表示对象及类的生命周期。
对象间的通信通过在对象的生命线间画消息来表示。消息的箭头指明消息的类型。顺序
图中的消息可以是信号、操作调用或类似于 C++中的 RPC（Remote Procedure Calls）和 Java
中的 RMI（Remote Method Invocation）。当收到消息时，接收对象立即开始执行活动，即对
象被激活了。通过在对象生命线上显示一个细长矩形框来表示激活。
消息可以用消息名及参数来标识，消息也可带有顺序号。消息还可带有条件表达式，表
示分支或决定是否发送消息。如果用于表示分支，则每个分支是相互排斥的，即在某一时刻
仅可发送分支中的一个消息。
（2）通信图。通信图用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图
和通信图都用来描述对象间的交互关系，但侧重点不一样。顺序图着重体现交互的时间顺序，
通信图则着重体现交互对象间的静态链接关系。图 8-17 就是与图 8-16 相对应的通信图，
可以从图 8-17 中很明显地发现它与顺序图之间的异同点。
（3）定时图。如果要表示的交互具有很强的时间特性（例如，现实生活中的电子工程、
实时控制等系统中），在 UML 1.X 中是无法有效地表示出来的。而在 UML 2.0 中引入了一
种新的交互图来解决这类问题，这就是着重表示定时约束的定时图。
根据 UML 的定义，定时图实际上是一种特殊形式的顺序图（即一种变化），它与顺序图
的区别主要体现在以下几个方面。
坐标轴交换了位置，改为从左到右来表示时间的推移。
用生命线的“凹下凸起”来表示状态的变化，每个水平位置代表一种不同的状态，状态的顺
序可以有意义、也可以没有意义。
生命线可以跟在一根线后面，在这根线上显示一些不同的状态值。
可以显示一个度量时间值的标尺，用刻度来表示时间间隔。
图 8-18 是一个定时图的实际例子，其中小黑点加曲线表示的是注释。它用来表示一个
电子门禁系统的控制逻辑，该门禁系统包括门（物理的门）、智能读卡器（读取用户的智能
卡信息）、处理器（用来处理是否开门的判断）。
在这个例子中，它所表示的意思是一开始读卡器是启用的（等用户来刷卡）、处理器是
空闲的（没有验证的请求）、门是关的；接着，当用户刷卡时，读卡器就进入了“等待校验”
的状态，并发一个消息给处理器，处理器就进入了校验状态。如果校验通过，就发送一个“禁
用”消息给读卡器（因为门开的时候，读卡器就可以不工作），使读卡器进入禁用状态；并
且自己转入启用状态，这时门的状态变成了“开”。而门“开”了 30 秒钟（根据时间刻度
得知）之后，处理器将会把它再次“关”上，并且发送一个“启用”消息给读卡器（门关了，
读卡器开始重新工作），这时读卡器再次进入启用状态，而处理器已经又回到了空闲状态。
从上面的例子中，不难看出定时图所包含的图元并不多，主要包括生命线、状态、状态
变迁、消息、时间刻度，可以根据自身的需要来使用它。
6．状态图基础状态图
用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术
都用状态图表示单个对象在其生命周期中的行为。一个状态图包括一系列的状态及状态之间
的转移。图 8-19 是一个数码冲印店的订单状态图实例。
状态图包括以下部分。
状态：又称为中间状态，用圆角矩形框表示；
初始状态：又称为初态，用一个黑色的实心圆圈表示，在一张状态图中只能够有一个初
始状态；
结束状态：又称为终态，在黑色的实心圆圈外面套上一个空心圆，在一张状态图中可能
有多个结束状态；
状态转移：用箭头说明状态的转移情况，并用文字说明引发这个状态变化的相应事件是
什么。
一个状态也可能被细分为多个子状态，那么如果将这些子状态都描绘出来的话，那这个
状态就是复合状态。
状态图适合用于表述在不同用例之间的对象行为，但并不适合用于表述包括若干用例协
作的对象行为。通常不会需要对系统中的每一个类绘制相应的状态图，而通常会在业务流程、
控制对象、用户界面的设计方面使用状态图。
7．活动图基础
活动图的应用非常广泛，它既可用来描述操作（类的方法）的行为，也可以描述用例和
对象内部的工作过程。活动图是由状态图变化而来的，它们各自用于不同的目的。活动图依
据对象状态的变化来捕获动作（将要执行的工作或活动）与动作的结果。活动图中一个活动
结束后将立即进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。
（1）基本活动图。图 8-20 给出了一个基本活动图的例子。
如图 8-20 所示，活动图与状态图类似，包括了初始状态、终止状态，以及中间的活动
状态，每个活动之间，也就是一种状态的变迁。在活动图中，还引入了以下几个概念。
判定：说明基于某些表达式的选择性路径，在 UML 中使用菱形表示。
分支与组合：由于活动图建模时，经常会遇到并发流，因此在 UML 中引入了如上图 8-20 所
示的粗线来表示分支和组合。
（2）带泳道的活动图。在前面说明的基本活动图中，虽然能够描述系统发生了什么，
但没有说明该项活动由谁来完成。而针对 OOP 而言，这就意味着活动图没有描述出各个活
动由哪个类来完成。要想解决这个问题，可以通过泳道来解决这一问题。它将活动图的逻辑
描述与顺序图、协作图的责任描述结合起来。图 8-21 是一个使用了泳道的例子。
（3）对象流。在活动图中可以出现对象。对象可以作为活动的输入或输出，对象与活
动间的输入/输出关系由虚线箭头来表示。如果仅表示对象受到某一活动的影响，则可用不
带箭头的虚线来连接对象与活动。
（4）信号。在活动图中可以表示信号的发送与接收，分别用发送和接收标识来表示。
发送和接收标识也可与对象相连，用于表示消息的发送者和接收者。
8．构件图基础
构件图是面向对象系统的物理方面进行建模要用的两种图之一。它可以有效地显示一组
构件，以及它们之间的关系。构件图中通常包括构件、接口及各种关系。图 8-22 就是一个
构件图的例子。
通常构件指的是源代码文件、二进制代码文件和可执行文件等。而构件图就是用来显示
编译、链接或执行时构件之间的依赖关系的。例如，在图 8-22 中，就是说明 QueryClient.exe
将通过调用 QueryServer.exe 来完成相应的功能，而 QueryServer.exe 则需要 Find.exe 的支
持， Find.exe 在实现时调用了 Query.dll。
通常来说，可以使用构件图完成以下工作。
对源代码进行建模：这样可以清晰地表示出各个不同源程序文件之间的关系。
对可执行体的发布建模：如图 8-22 所示，将清晰地表示出各个可执行文件、DLL 文件
之间的关系。
对物理数据库建模：用来表示各种类型的数据库、表之间的关系。
对可调整的系统建模：例如对应用了负载均衡、故障恢复等系统的建模。
在绘制构件图时，应该注意侧重于描述系统的静态实现视图的一个方面，图形不要过于
简化，应该为构件图取一个直观的名称，在绘制时避免产生线的交叉。
9．部署图基础
部署图，也称为实施图，它和构件图一样，是面向对象系统的物理方面建模的两种图之
一。构件图是说明构件之间的逻辑关系，而部署图则是在此基础上更进一步地描述系统硬件
的物理拓扑结构及在此结构上执行的软件。部署图可以显示计算结点的拓扑结构和通信路径、
结点上运行的软件构件，常用于帮助理解分布式系统。
图 8-23 就是与图 8-22 对应的部署图，这样的图示可以使系统的安装、部署更为简单。
在部署图中，通常包括以下一些关键的组成部分。
（1）节点和连接。节点代表一个物理设备及其上运行的软件系统，如一台 UNIX 主机、
一个 PC 终端、一台打印机、一个传感器等。
如图 8-23 所示，“客户端：个人 PC”和“服务器”就是两个节点。在 UML 中，使用
一个立方体表示一个节点，节点名放在左上角。节点之间的连线表示系统之间进行交互的通
信路径，在 UML 中被称为连接。通信类型则放在连接旁边的“《》”之间，表示所用的通信
协议或网络类型。
（2）构件和接口。在部署图中，构件代表可执行的物理代码模块，如一个可执行程序。
逻辑上它可以与类图中的包或类对应。例如，在图 8-23 中，“服务器”结点中包含
“QueryServer.exe”、“Find.exe”和“Query.dll”3 个构件。
在面向对象方法中，类和构件等元素并不是所有的属性和操作都对外可见。它们对外提
供了可见操作和属性，称之为类和构件的接口。界面可以表示为一头是小圆圈的直线。在图
8-23 中，“Query.dll”构件提供了一个“查询”接口。
8.5 用户界面设计
接口设计主要包括三个方面的内容：一是设计软件构件间的接口；二是设计模块和其他
非人的信息生产者和消费者（如外部实体）的接口；三是人（如用户）和计算机间界面设计。
软件构件间接口的设计与架构的设计紧密相关，而设计模块和外部实体的接口则与详细
设计相关，人机界面接口是相当容易被忽视的环节，在此就对其重点内容进行一个概要性描
述。
8.5.1 用户界面设计的原则
用户界面设计必须考虑软件使用者的体力和脑力，根据 Theo Mandel 的总结，设计时
必须遵从三个黄金法则。
置用户于控制之下：具体来说就是以不强迫用户进入不必要的或不希望的动作的方式来
定义交互模式、提供灵活的交互、允许用户交互可以被中断和撤销、当技能级别增长时可以
使交互流水化并允许定制交互、使用户隔离内部技术细节、 设计应允许用户和出现在
屏幕上的对象直接交互。
减少用户的记忆负担：具体来说就是减少对短期记忆的要求、建立有意义的默认、定义
直觉性的捷径、界面的视觉布局应该基于对真实世界的隐喻、以不断进展的方式提示信息。
保持界面的一致：具体来说，就是允许用户将当前任务放入有意义的语境、在应用系列
内保持一致性，如果过去的交互模型已经建立了用户期望，除非有不得已的理由，否则不要
改变它。
除此之外，还应该考虑表 8-7 所示的设计原则。
8.5.2 用户界面设计过程
用户界面的设计过程也应该是迭代的，它通常包括 4 个不同的框架活动，如图 8-24
所示。
（1）用户、任务和环境分析：着重于分析将和系统交互的用户的特点。记录下技术级
别、业务理解及对新系统的一般感悟，并定义不同的用户类别。然后对用户将要完成什么样
的任务进行详细的标识和描述。最后对用户的物理工作环境进行了解与分析。
（2）界面设计：主要包括建立任务的目标和意图，为每个目标或意图制定特定的动作
序列，按在界面上执行的方式对动作序列进行规约，指明系统状态，定义控制机制，指明控
制机制如何影响系统状态，指明用户如何通过界面上的信息来解释系统状态。
（3）实现：就是根据界面设计进行实现，前期可以通过原型工具来快速实现，减少返
工的工作量。
（4）界面确认：界面实现后就可以进行一些定性和定量的数据收集，以进行界面的评
估，以调整界面的设计。
8.6 工作流设计
工作流技术的发展，经过多年的努力，取得了一定的成果。但在实际应用中，应用的企
业还是较少，应用的范围窄，效果不理想。
流程的设计是对设计者更高的挑战，现实中对计算机所管理的流程需要灵活的定义、方
便的路径修改、容易使用，可是这几个目标是矛盾的。更严重的是，如何分析现实中的流程
本身就是个困难的问题，更不用谈如何来设计实现了。流程设计的主要困难实际上也就是软
件的主要困难：现实复杂性。
任何对现实的描述（图形也罢，文字也罢）都是不完美的，“不识庐山真面目”是设计
面临的共同难题。设计者不得不意识到所有的流程模型都是对现实的简化，计算机只根据确
定的信息作判断，而现实中的流程存在大量的不确定性，虽然计算机专家们自信地告诉企业
管理者这是管理的问题，信誓旦旦地保证可以用计算机系统来“完善”企业的管理，但他们
似乎没有意识到企业管理已经发展了几百年，而计算机还没有百年的历史。
人们常常抱怨计算机系统的流程设计太过刻板，因为许多时候，标准流程是先于应用构
造的且由一些集中的权威强制执行的，所以这种刻板性是不可避免的。同时，对参与者而言
缺乏自由度导致工作流管理系统显得很不友好。结果是它们经常被忽略或绕过，甚至最终被
放弃。
另外的困难是：对于流程处理，不但名称众多，例如，动态模型、工作流等，而且对流
程的定义也是千姿百态。面对这些困难，设计者无疑需要巨大的勇气来进行流程设计。
8.6.1 工作流设计概述
限于篇幅，这里只列出工作流管理联盟对于工作流的定义：“工作流是一类能够完全或
者部分自动执行的经营过程，根据一系列过程规则、文档、信息或任务在不同的执行者之间
传递、执行”。
（1）工作流。简单地说，工作流是现实中的具体工作从开始到结束过程的抽象和概括。
这个过程包括了众多因素：任务顺序、路线规则、时间时限约束等。
（2）流程定义。流程定义是指对业务过程的形式化表示，它定义了过程运行中的活动
和所涉及的各种信息。这些信息包括过程的开始和完成条件、构成过程的活动及进行活动间
导航的规则、用户所需要完成的任务、可能被调用的应用、工作流间的引用关系，以及工作
流数据的定义。这个定义的过程可能是由设计者用纸和笔来完成的，但越来越多的设计者倾
向于使用流程定义工具来完成这个工作。
（3）流程实例。也常常称为工作，是一个流程定义的运行实例。例如客户的一次订购
过程，客服中心受理的一次客户投诉过程等。
（4）工作流管理系统。和数据库管理系统类似，是一个软件系统。这个程序存储流程
的定义，按照所使用的流程定义来触发流程状态的改变，推动流程的运转。这个推动的依据
常常称为工作流引擎。
（5）流程定义工具。同样是一套软件系统，这个软件和工作流管理系统的关系就如同
数据库设计工具和数据库管理系统的关系一样。它可能是独立的软件，也可能是工作流管理
系统的一部分。如前所说，设计者常常使用流程定义工具来完成流程定义的工作。它提供一
些常用的工作流元素素材，以提高设计者的效率。
（6）参与者。回答业务流程中“谁”这个问题。它可以是具体的人或者角色（企业内部
有特别共同作用的多个人），也可以是自动化系统，甚至是其他系统。
（7）活动。活动是流程定义中的一个元素，一次活动可能改变流程处理数据的内容、
流程的状态，并可能将流程推动到其他活动中去。活动可以由人来完成，也可以是系统自动
的处理过程，典型的自动处理是当活动超过了这个活动可以容忍的时限时，自动过程将向流
程定义中指定的参与者发出一条消息。
（8）活动所有者。参与者之一，他有权决定该活动是否结束，当他决定活动结束时，
将活动推动到其他活动中，可能是下一个活动，也可能是前一个活动。
（9）工作所有者。工作所有者是有权整体控制流程实例执行过程的参与者。
（10）工作项。代表流程实例中活动的参与者将要执行的工作。
要分析现实中的处理流程，必须首先描述目标系统的流程，这个过程也可以称为建模。
流程是个复杂的事务，必须从多方面才可以描述一个流程，包括：“谁”，流程的参与者；“什
么”，参与者做什么工作；“何时”，工作完成的时间限制，还需要说明工作的数据流和完成
工作的控制流。人们认为自然语言在描述如此复杂的事务时容易引起歧义，所以人们定义了
一些形式化语言试图在自然语言中挑选一个子集，这个子集既可以真正描述流程，又能够摆
脱自然语言的复杂和多变，实际上想在人和机器在理解处理流程上架起一座桥梁，如同其他
计算机语言及后来发展的统一建模语言一样，这些形式化的语言也称为“工作流定义语言”。
同样，为了描述实际中的处理流程，人们也想到了图形的方式。有限状态自动机是一种
分析状态和改变状态的良好工具，这种方法需要完全列出流程中所有状态及这些状态的组合，
当处理流程变得庞大时，自动机所对应的状态图膨胀得太厉害。由于 Petri 网有严格的数学
基础和图形化的规范语义，在描述离散事件动态系统方面的能力已经得到公认，具有较强的
模型分析能力，在工作流的描述和分析中已经是人们广泛采用的一种方法。虽然有人认为图
形并非工作流的最佳表示方法，但由于图形的直观性，大多数设计者都愿意采用图形的描述
方式。有关有限状态自动机和 Petri 网的论述请参考其他书籍。
8.6.2 工作流管理系统
根据工作流管理联盟（Workflow Management Coalition，WFMC）的定义，工作流管理
系统是一种“在工作流形式化表示的驱动下，通过软件的执行而完成工作流定义、管理及执
行的系统”，其主要目标是对业务过程中各活动发生的先后次序及与活动相关的相应人力或
信息资源的调用进行管理，而实现业务过程的自动化。
如同关系数据库一样，现在已经出现了专门的工作流管理系统，这些系统经过专门的设
计，从不同的角度负责解决设计者在流程设计中遇到的共同问题：节点定义、路径选择、数
据流动等。不幸的是，和关系数据库共同基于关系代数、支持标准的 SQL 不同，这些工作
流管理系统基于不同的数学模型，提供完全不同的接口。所以这些工作流管理系统各具特色，
但在通用性和其他系统相互协作上的不足使得这些系统的应用受到了限制。
WFMC 给出了包含六个基本模块的参考模型，这六个模块被认为是工作流管理系统的
最基本组成，这个参考模型同时包括了这些模块之间的接口标准。
（1）流程定义工具。这部分软件提供图形化或者其他方式的界面给设计者。由设计者
将实际工作流程进行抽象，并将设计者提交的流程定义转换为形式化语言描述，提供给计算
机工作流执行服务进行流程实例处理的依据。
（2）工作流执行服务。这个服务程序是工作流管理系统的核心，它使用一种或者多种
数据流引擎，对流程定义进行解释，激活有效的流程实例，推动流程实例在不同的活动中运
转。和客户应用程序、其他工作流服务执行程序及其他应用程序进行交互，从而完成流程实
例的创建、执行和管理工作。同时这部分软件为每个用户维护一个活动列表，告诉用户当前
必须处理的任务。如果有必要，还可以通过电子邮件甚至是短消息的形式提醒用户任务的到
达。
（3）其他工作流执行服务。大型的企业工作流应用，往往包括多个工作流管理系统。
这就需要这些工作流管理系统之间进行有效的交互，避免画地为牢、信息孤岛的现象出现。
（4）客户应用程序。这是给最终用户的界面，用户通过使用这部分软件对工作流的数
据进行必要的处理，如果用户是当前活动的拥有者，还可通过客户应用程序改变流程实例的
活动，将流程实例推动到另外一个活动中。
（5）被调用应用程序。这常常是对工作流所携带数据的处理程序，用得很多的是电子
文档的处理程序。它们由工作流执行服务在流程实例的执行过程中调用，向最终用户展示待
处理数据。在流程定义中应该定义这些应用程序的信息，包括名称、调用方式、参数等。
（6）管理和监控工具。如同数据库管理系统或多或少地提供一些方式告诉管理员当前
数据库的使用状态一样，工作流管理系统也应该提供对流程实例的状态查询、挂起、恢复、
销毁等操作，同时提供系统参数、系统运行情况统计等数据。
看到这里，没有处理流程设计经验的设计者一定已经云里雾里了。确实，流程设计是系
统设计中最困难的一部分，它的复杂性直接来源于现实世界的复杂性。而且直到现在，人们
对流程的设计，仍然是在探索之中。
8.7 简单分布式计算机应用系统的设计
网络极大地扩展了计算机的应用范围，同时，由于升级到更强的服务器的费用常常远远
高于购买多台档次稍低的机器，更何况虽然计算机有了长足的发展，可是单台计算机的功能
仍然十分有限，利用联网的计算机协同工作，共同完成复杂的工作成为相对成本较低的选择，
而且可以完成单台计算机所无法完成的任务。分布式系统使得这一目标成为可能。另外，网
络本质上并不可靠，特别是远程通信，分布式系统还带来了并发和同步的问题。
分布式系统可以由两种完全不同的方式来进行协同和合作，第一种是基于实例的协作。
这种方式所有的实例都处理自己范围内的数据，这些对象实例的地位是相同的，当一个对象
实例必须要处理不属于它自己范围的数据时，它必须和数据归宿的对象实例通信，请求另外
一个对象实例进行处理。请求对象实例可以启动对象、调用远程对象的方法，以及停止运
行远程实例。基于实例的协作具有良好的灵活性，但由于实例之间的紧密联系复杂的交互模
型，使得开发成本提高，而且，由于实例必须能够通过网络找到，所以通信协议必须包括实
例的生存周期管理，这使得基于实例的协作大多只限于统一的网络，对于复杂的跨平台的系
统就难以应付。所以基于实例的协作适用于比较小范围内网络情况良好的环境中，这种环
境常常被称为近连接。这种情况下对对象的生存周期管理所带来不寻常的网络流量是可以容
忍的。
使用基于实例的协作常常使用被称为“代理”的方法，某个对象实例需要调用远程对象
时，它可以只和代理打交道，由代理完成和远程对象实例的通信工作：创建远程对象，提交
请求、得到结果，然后把结果提交给调用的对象实例。这样，这个对象实例甚至可以不知道
自己使用了远程对象。当远程对象被替换掉（升级）时，对本地代码也没有什么需要修改的
地方。
另外一种方式是基于服务的协作，该方法试图解决基于实例的协作的困难。它只提供远
程对象的接口，用户可以调用这些方法，却无法远程创建和销毁远程对象实例。这样减少了
交互，简化了编程，而且使得跨平台协作成为可能。同样由于只提供接口，这种协作方式使
得对象间的会话状态难以确定，而且通信的数据类型也将有所限制，基本上很难使用自定义
的类型。基于服务的协作适用于跨平台的网络，网络响应较慢的情况，这种环境常称为远连
接，这时，简化交互性更为重要，而频繁的网络交换数据会带来难以容忍的延时。
基于服务的协作往往采用分层次的结构，高层次的应用依赖于低层次的对象，而低层次
对象实例的实现细节则没有必要暴露给高层次对象，这种安排使得高层次的实现不受低层次
如何实现的影响，同时，当低层次服务修改时，高层次的服务也不应该受到影响。
设计者在进行设计时，通常会倾向于比较细致的设计，对象往往提供了大量的操作和方
法，响应许多不同的消息，以增加达到系统的灵活性、可维护性等。这在单个系统中没有什
么问题，当考虑分布式系统的设计时，这种细致的设计所带来对对象方法的大量调用会比较
严重地影响性能，所以在分布式系统中，倾向于使用大粒度的设计方式，往往在一个方法中
包含了许多参数，每个方法基本上代表了一个独立的功能。当然这样的设计使得参数的传递
变得复杂，当需要修改参数时，需要对比较大范围的一段过程代码进行修改，而不是像小粒
度设计一样，只需要修改少量的代码。
8.8 系统运行环境的集成与设计
在设计一个新的系统时，设计者必须考虑目标系统的运行环境问题，人们往往认为软件
应该能够在任何环境中运行，常常看到这样的系统，硬件已经升级了多次，而软件还是原来
的软件。软件的运行环境是指系统运行的设备、操作系统和网络配置。
本节给出软件运行的几个典型环境，设计者可以从这几种典型环境中选择适合自己的目
标系统的环境，也可以将这些典型环境做一些组合，来满足自己设计的系统的特殊要求。
1．集中式系统
早期的计算机系统没有什么可以选择的，除了集中式系统。所有的操作都集中于一台主
机中，而操作员必须在主机的附近操作，结果也在附近给出。这种系统仍然广泛地应用于批
处理应用系统及更大的分布式系统的一部分。集中式系统常见于银行、保险、证券行业，它
们含有大规模的处理应用。而现在流行的电子商务又给大型处理机注入了新的活力，人们发
现电子商务要面对大量的事务，需要大型处理机来处理。但是，实践中很少单独使用集中式
系统，因为大量的系统需要处理在地理上分布得很远的连接请求，这些请求有的需要实时响
应，并可能要发送到其他某个地方的一个集中式系统。所以，在现代的系统中，集中式系统
通常是某个分布式系统的一个环节。
集中式系统由以下几个部分组成。
（1）单计算机结构：这种结构简单、容易维护，但是处理能力受到限制。
（2）集群结构：由多个计算机组成，这些计算机具有类似的硬件平台、操作系统等。
通常采用负载均衡、资源共享等方式实现更大的处理能力和容量。
（3）多计算机结构：由多个计算机组成，这些计算机之间操作环境可能不同。适用于
当系统可以分解成多个不同的子系统时。
2．分布式系统
在 7.9 节中，已经简单介绍了分布式系统。分布式系统由于网络的普遍延伸，费用的不
断降低而越来越成为大型系统的首选环境。分布式系统必须基于网络，这个网络可以是在一
个地域内的局域网，也可以是跨越不同城市乃至国家的广域网。对比集中式的计算机环境，
分布式系统有着多种多样的形式。这也给设计者在确定系统运行环境时带来一定的烦恼。
3．C/S 结构
系统由提供服务的服务器和发起请求、接受结果的客户机构成。这种结构是一种可以使
用很多方式实现的通用结构模型。并非只限于数据库的 C/S 结构，典型的还有网络打印服
务系统，现在流行的网络游戏也显然是基于这种结构的。
4．多层结构
这种结构是 C/S 结构的扩展，典型的分为由存储数据的数据库服务器作为数据层、实
现商业规则的程序作为逻辑层、管理用户输入输出的视图层所组成的三层结构。当系统更复
杂时，可以再增加其他层次构成多层结构。
多层结构形式复杂，功能多样。实现多层结构常常需要来实现不同层次间通信的专门程
序——管件，也称为中间件。中间件大多数实现远程程序调用、对象请求调度等功能。
现代企业级的计算机系统大量地基于分布式结构。支持分布式系统的软件也曾经如同雨
后春笋。系统如何分层、如何处理分布带来的同步等问题也就同样在考验设计者。
5.Internet、Intranet 和 Extranet
Internet 是全球的网络集合，使用通用的 TCP/IP 协议来相互连接。Internet 提供电子
邮件、文件传输、远程登录等服务。Intranet 是私有网络，只限于内部使用，也使用 TCP/IP
协议。Extranet 是一个扩展的 Intranet。它包括企业之外的和企业密切相关合作的其他企业。
Extranet 允许分离的组织交换信息并进行合作，这样就形成了一个虚拟组织。现在的 VPN
技术允许在公用网络上架构只对组织内部开发服务。
Web 同样基于 C/S 结构，实际上 Web 接口是一个通用的接口，不是只能使用浏览器
的协议，它同样能够在普通的程序中使用。Internet 和 Web 已经给设计者提供了一个非常
富有吸引力的选择方案。它的优势在于：它们已经成为网络的事实上的标准，支持它们的软
件已经广泛地存在于全世界的计算机中，而且通信费用已经下降到很有竞争力的水平。从某
种程度上来说，企业可以把 Internet 当作自己廉价的广域网。没有它们，电子商务还是水
中月。
当然，事物有相反的一面，当设计者试图采用 Internet 时，必须考虑其不利的一面。
Internet 的安全性过去是，现在是，以后仍然是设计者头痛的问题。其他诸如可靠性、系统
吞吐量、不断发展的技术和标准都是影响系统选择它们作为运行环境的不利因素。 设
计者应该根据目标系统的实际需要来选择不同的运行环境。不过，已经有越来越多的公司提
供支持 Internet 和电子商务的接口。
8.9 系统过渡计划
当新系统似乎开发完毕，要取代原来的系统时，系统过渡就是设计者不得不面对的问题。
这个问题，不幸的是，比许多人想象得要复杂，和软件开发一样，存在着许多冲突和限制。
例如，费用、客户关系、后勤保证和风险等。设计者需要考虑的问题也很多，其中比较重要
的几个问题是：
如果同时运行两个系统，会给客户造成多大的开销；
如果直接运行新系统，客户面对的风险有多大；
对新系统试运行时的查错和纠错，以及出现严重错误而导致停止运行时的应急措施；
客户运行新系统将面临的不利因素有哪些；
人员的培训。
使用不同的系统过渡方案意味着不同的风险，不同的费用及不同的复杂度。
1．直接过渡
这是一种快速的系统过渡方式，当新系统运行时，立即关闭原来的系统。这种过渡方式
非常简单，没有后勤保障的问题，也不要消耗很多资源。同时，它也意味着大风险，目标系
统的特性决定了风险的大小。设计者主要要权衡当新系统失败时，系统停止运行或者勉强运
行给客户带来的损失有多大。由于这种过渡方式简单而费用低廉，对于可以容忍停机一段时
间的系统的实践者，可以采用这种方式。
2．并行过渡
设计者采用并行过渡方式，让新系统和旧系统在一段时间里同时运行，通过这样的旧系
统作为新系统的备份，可以大大降低系统过渡的风险。可是并行过渡显然比直接过渡要消耗
更多的资源：现有的硬件资源必须保证能同时跑两套系统，这常常意味着增加服务器和额外
的存储空间，需要增加人员来同时使用两套系统，或者增加现有员工的工作量，让他们同时
操作两套系统。这种方式同时也增加了管理和后勤保障的复杂度。据统计，并行过渡时期的
开销是旧系统单独运行时的 2.5～3 倍。
设计者还会发现有些系统无法使用并行过渡的方式，主要是客户没有足够的资源来维持
两个系统同时运行，另外一种情况是新、旧系统差别太大，旧系统的数据无法为新系统采用。
当客户无法使用并行过渡，又想尽可能地减少风险，设计者可以使用部分并行过渡的策略，
使并行的开销减少到客户能够接受的范围内。
3．阶段过渡
通常在系统非常复杂、过于庞大以至于无法一次性进行过渡时采用，也适用于分阶段开
发的系统。设计者需要设计一系列步骤和过程来完成整个系统的过渡，这种过渡方式和系统
的复杂程度相关，随着系统的不同往往有很大的不同。和并行过渡一样，阶段过渡也能够减
少风险，显然局部的失败要比全体的失败更容易接受，带来的损失更小。阶段过渡也带来了
复杂性，有时候比并行过渡更加复杂。