多帮项目实战

多帮项目实战目录第一章 项目团队 21.1 项目经理 41.2 需求分析师 41.3 架构设计师 41.4 开发工程师 51.5 测试工程师 51.6 质量工程师 5第二章 需求描述 62.1 一句话总述 72.2 目标用户 72.3 功能需求 82.4 非功能需求 82.5 项目约束 9第三章 需求分析 93.1 角色特征 93.2 场景分析 103.3 业务流程分析 113.4 数据流分析 123.5 需求优先级 143.6 用户界面 15第四章 系统框架 184.1 基本框架 184.1 框架内容 184.2 系统分层 204.3 框架选择与演进 204.4 关键技术 214.5 数据表设计 214.6 模块分解 224.7 拆分原则 22第五章 常见模块设计 235.1 异常设计 23第六章 迭代开发 26项目团队由于软件本身的复杂性，现在开发软件基本上都是以团队的方式来开发软件。团队成员各司其职，在项目经理的带领下完成软件的开发、测试和交付。什么是项目团队？简单地说就是项目以怎样的方式组建团队，软件开发项目团队的基本团队模型如下：团队在项目经理的带领下，各角色之间协调工作，为项目的成功而努力！各角色的基本职责如下：项目经理：整体协调项目，编制计划及保证计划执行，推动项目成功。需求分析师：分析系统需求，保证系统需求既满足客户要求。架构设计师：同时保证技术可行性；指导项目技术方案及系统架构设计。程序员：细化系统设计，并编码实现设计。测试工程师：测试系统，保证系统满足需求。质量工程师，保证开发过程按照既定的要求进行，保证工作产品符合既定的规范。基本团队有两大特点： 1.一个团队总有一个负责人，这个人就是项目经理。 2.期望各专业角色协调工作，并能各自发挥所长，完成各自的项目任务。但实际情况会是这样的吗？ 项目经理会埋怨手下能力不够、不主动报告工作、不主动承担责任。 项目组成员会埋怨项目经理不够强，只会叫他干活，不授权，更加不会传授知识。实际项目团队中项目经理身兼多职,很多项目大多没有专职的系统分析师和软件架构师，项目经理兼任需求分析与软件设计的工作，有的还需要负责编码的工作。项目经理要做的事情太多了，往往没有办法专注项目管理，项目计划相关的文档能免则免，项目设计文档能少则少，但是这样很容易导致项目失败。项目经理项目经理就是项目的主要负责人，项目能否按时按质量交付的关键人物，能力要求很高。其主要职责如下：1．参与客户沟通、项目需求调研分析并维持良好的客户关系；2．负责制订软件开发项目的计划，实施整个项目的管理；3．参与项目需求分析、关键技术、系统框架和核心模块的设计及规划；4．根据项目开发进度进行任务分配和协调；5．按照项目计划，保质完成项目编码、文档及测试工作；6.确保项目质量，满足客户的需求；需求分析师需求分析师就是负责需求的分析和澄清，保证做出来的是客户想要的。能力懂技术，懂行业知识，沟通能力强。1．协助需求分析师进行需求调研并维持良好的客户关系；2．分析、解析《用户需求说明书》，将系统需求整理成《软件需求规格说明书》；3．负责解决《软件需求规格说明书》被评审后发现的问题；4．协助架构设计师进行架构设计，并协助其完成《系统架构说明书》。架构设计师系统架构师是软件项目的总体设计师，是产品的开发与集成、技术体系的构建者。系统架构师是在技术上对所有重要事情做出决定的人。1.负责软件整体架构和非功能性需求。比如性能、可靠性、可测试性等。2.协助需求分析师完成《用户需求说明书》、《需求变更说明书》。3.确认开发团队所提出的设计，并协助其完成《数据库设计说明书》。4．对整个软件架构、关键构件、接口的设计；5．负责重点代码检查；解决关键技术问题、技术培训；6．支持软件测试、集成和交付；开发工程师1．参与客户沟通、项目需求调研分析；2．参与项目需求分析,研究项目技术细节，进行模块的详细设计；3．根据公司要求规范，编写相应的技术文档；编制项目文档；4．开发相应的软件模块；根据需要及时修改、完善软件；5．根据任务分解完成软件编码工作，配合测试工程师进行软件测试工作； 测试工程师主要职责确保软件可用满足用户的需求，核心思想要站在客户的角度测试软件。1.搭建软件测试环境。2.根据需求做测试设计和写测试用例。3.执行测试用例。4.准确定位问题，并提交BUG单。5.跟踪问题修改情况，推动问题及时合理地解决。6.做自动化测试，编写脚本，执行，分析，输出报告。7.做性能测试，编写脚本，执行，分析，调优，输出报告。质量工程师质量保证工程师，保证开发过程按照既定的要求进行，保证工作产品符合既定的规范。以独立审查的方式监控软件生产任务的执行，用过程质量确保产品质量。1.制定项目质量保证计划：在项目开发的各个阶段具体什么措施确保过程的质量。2.进行项目审查，内容包括：需求说明书、项目开发计划、测试计划、测试报告。3.进行项目审计，识别开发中与质量保证计划中规定的标准和过程不相符时，影响到项目的及时高质量完成时，要及时召开项目审计会议。4.进行系统测试，确保软件产品符合质量要求，满足客户需求。5.进行错误预防，提供历史和当前数据，让团队了解项目所处的状态和存在的弱点。需求描述 先看看“需求的故事”。其中的主要问题： 1.客户也没有完全表达清楚自己想要的。 2.项目经理对客户的需求没有完全理解，存在偏差。 3.项目经理和分析师在澄清过程中也存在偏差。那么如何把需求描述清楚，传递清楚，就需要一定的技能和规范。一句话总述描述方法：什么样的人在什么样的情况下按照什么样的流程做什么样的事。说明：1.“什么样的人”： 表示角色。2.“什么样的情况”： 表示场景。3.“按照什么样的流程”：表示流程。4.“做什么样的事”： 表示功能。如果客户的需求能按照这种模式来描述自己的需求，那么这样的需求就比较清楚。客户需求描述： 本项目需要建立一个题库项目：包含题目的录入（并且包含题目的分析和答案），题目的审核，试卷的生成（按照题目的知识范围（java，sql，框架，项目，题目的难度，初级，中级，高级），题目的类型（选择题，回答题，编程题）），答题（不会的反复答题，直到把题目都答对了，才能再次生成新的试卷，初级做3套，才能做中级，中级做三套才能做高级）。分析答题人员的技能，给出建议。用户或者管理员发布题目，用户生成试卷，用户解答试卷，系统自动判题，用户通过系统分析自己的技能水平。用户使用此系统提高自己的技能。并发限制100人,同时可以容纳300人。目标用户这个项目谁是最终的用户？列出主要用户。1、列出主要用户 以角色的方式列举出来：例如：●

患者、医生

护士。●

家长、老师、学生。●

乘客、飞行员、空姐。也可以是其他的角度考虑：●

当地客户、外地游客●

购物者，浏览者当前项目的主要用户：即将毕业的大学生，提供本系统能提升自己的技能进而就好业。功能需求把项目中的功能点描述出来：（1）用户管理：用户注册、用户登录。（2）题目管理：增加、审核、发布、去重。（3）类型管理：增加、启用是否。（4）试卷管理：生成、解答，分析。（5）分析管理：用户技能能力趋势，用户技能建议。（6）用户业务管理：试卷（历史试卷，未答完(提交)的试卷，删除未答完）题目（审核通过的题目，未审核通过的题目，删除未通过的）技能分析：从java、SQL、框架，项目维度给出建议。非功能需求非功能需求一般是指：可靠性、易用性、效率、维护性等。可靠性具体包括：•成熟性：软件故障引起失效的频度。 •容错性：软件出现故障并维持在规定的性能水平的能力。 •易恢复性：问题发生后重建其性能水平并恢复受影响数据的能力。易用性具体包括：•易理解性：用户为认知逻辑概念所花的努力的程度。•易学习性：用户为学习软件应用所花的努力的程度。•易操作性：用户为操作使用软件所花的努力的程度。这类非功能需求是与UI设计有着直接关系，可归纳为界面友好性;性能具体包括：•时间相关：软件执行功能时的响应和处理的时间和吞吐量。•资源相关：软件执行其功能时所使用的资源数量及其使用时间。维护性具体包括：•易分析性：诊断缺陷或者失效原因及为判定待修改的部分所需的努力。•易改变性：在进行修改排除错误或者适应环境变化所需的努力。•稳定性：在修改所造成的未预料结果的风险所需的努力。•易测试性：在确认已修改软件所需的努力。非功能需求每个软件都具备的，做好非功能需求成本很高，对架构师、开发人员要求也很高。项目约束一般情况下项目的需求很越来越多，主要是客户不断在改需求，也可能是设计人员自己想当然的增加需求，可能会导致在既定的人员、时间、成本下不能完成项交付，导致项目失败。项目的约束就是要建立项目的范围和边界，这里主要是指哪些需求可以不做，或者用户变更需求的内容或者次数。需求分析

一切围绕着用户，以用户为中心，了解用户的需求，采集用户的特征信息，并倾听他们的想法或与他们需求的和使用方式内容相关问题。角色特征 列出每角色的关键特征：应包含以下方面： 经验和专业知识、价值观、技术水平、用户的岗位或级别、人口信息（年龄等）经验和专业知识：考虑用户在知识领域和网站操作经验和专业知识。 例如：对于电子商务（某宝）网站来说：经常购买的人： 可能对交易网站非常熟悉，仅仅满足能够顺利完成交易还不是最终的目的，客户想 找到同比商品最廉价、信用最高的商品。偶尔购买的人： 可能对交易网站不是很熟悉，仅仅想满足如何能够快速购买所需商品。技术水平 会快速网络搜索？ 对常用软件很熟悉? 电脑、互联网、论坛、微博都很熟悉？用户的岗位或级别： 普通员工？做具体的事情。 项目经理？管理项目进度和质量。 中层主管？项目的价值。 高层主要？项目的投入产出。人口信息（年龄等） 年龄可能对你的软件有所影响。如果是特定年龄的话，如青少年，那么年龄影响设计风格和写作风格。如果是年轻女性、老人，对软件的设计有很大的影响（主要是易用性）。场景分析场景描述，场景主要包括4种主要的类型：正常的使用场景，备选的用例场景，异常的用例场景，假定推测可能的场景。用场景法来分析需求是指模拟特定场景发生的事情，通过事件来触发某个动作的发生,预估事件的最终结果,从而用来分析需求。我们通常以正常的使用场景分析开始，然后再着手其他的场景分析。看个具体的例子：假定我们有个电商项目，项目中有个支付模块：需求描述是：方便用户网上支付。那么就要考虑各种支付方式，例如：支付宝，微信，银行App等等，现在的每种支付方式就是一种场景，就需要分析是否支持每种场景。正常的推荐的支付方式是哪种?备选的支付方式是什么？出现问题后怎么解决？还有其他什么可能？把这些都列举出来，逐个跟用户澄清，给用户推荐最实用的的方式。业务流程分析业务是指企业管理中必要且逻辑上相关的、为了完成某种管理功能的一系列相关的活动。在项目调研时,

通过了解组织结构和业务功能,

我们对项目的主要业务有了一个大概的认识。但由此我们得到的对业务的认识是静态的,

是由组织部门映射到业务的。而实际的业务是流动的,

我们称之为业务流程。1.先用文字描述一个用户在项目中的实际的操作流程：a.用户小明进入项目主页，先进行注册，注册成功后进入登录业务，登录成功后生成试卷，再解答试卷，再分析自己的技能如何。b.小明遇到了好的题目，登录后直接把题目增加到题库，之后等待系统审核，审核通过后，就可能就可以生成试卷。c.小明可以管理自己做过的试卷（删除），也可以管理自己增加的题目（更新，但不能删除）。2.画成业务流程图：visio：业务流程图是一本用图形方式来反映实际业务处理过程的“流水帐”。绘制出这本流水帐对于开发者理顺和优化业务过程是很有帮助的。业务流程图的符号简单明了,

易于阅读和理解业务流程。绘制流程图的目的是为了分析业务流程,

在对现有业务流程进行分析的基础上进行业务流程重组,

产生新的更为合理的业务流程。通过除去不必要的、多余的业务环节;

合并重复的环节;增补缺少的必须的环节;

确定计算机系统要处理的环节等重要步骤,

在绘制流程图的过程中可以发现问题,

分析不足,

改进业务处理过程。业务流程图就是用一些规定的符号及连线来表示某个具体务处理过程。业务流程图的绘制是根据系统详细调查过程中所得的资料,

按业务实际处理过程,

用规定的符号将它们绘制在同一张图上。它的绘制无严格的规则,

只需简明扼要地如实反映实际业务过程。在绘制过程中一般也遵循“自顶向下”的原则。数据流分析数据流程图是对业务流程的进一步抽象与概括。抽象性表现在它完全舍去了具体的物质,

只剩下数据的流动、加工处理和存储;

概括性表现在它可以把各种不同业务处理过程联系起来,形成一个整体。数据流程图主要是对信息流的描述。

数据流程图还要配合数据字典的说明,

对系统的逻辑模型进行完整和详细的描述。数据流程分析主要包括对信息的流动、传递、处理、存储等的分析。数据流程分析的目的就是要发现和解决数据流通中的问题,

这些问题有:

数据流程不畅,

前后数据不匹配,

数据处理过程不合理等。通过对这些问题的解决形成一个通畅的数据流程作为今后新系统的数据流程。数据流程图比起业务流程图更为抽象,

它舍弃了业务流程图中的一些物理实体,

更接近于信息系统的逻辑模型。对于较简单的业务,

我们可以省略其业务流程图直接绘制数据流程图。数据流程图的绘制方法较为复杂,

它是按照“自顶向下,

逐层求精”的方法进行的,

也就是将整个系统当成一个处理功能,画出它和周围实体的数据联系过程,

即一个粗略的数据流程图(

顶层数据流程图),然后逐层向下分析,

直到把系统分解为详细的低层次的数据流程图。业务流程图和数据流程图的联系1.

业务流程图和数据流程图都是从流程的角度动态地去考察分析对象,

都是用图形符号抽象地表示调查结果。2.

数据和业务的联系具体表现在:

数据流是伴随着业务过程而产生的,

它是业务过程的衍生物;数据资料基本上也是按组织结构或业务过程收集的;

在数据汇总时,

我们也是以业务流程为单位,将同一业务的不同处理步骤中的数据加以集中;

数据流程图的绘制遵照业务处理的全过程。3.

数据流程图和业务流程图存在一定的对应关系。由业务流程图可以导出相应的数据流程图。有两种思路:

一种是先按业务流程图理出的业务流程顺序,

然后将相应调查过程中所掌握的数据、表单分离出来,

接下来考查数据的流向,

加工处理过程和存储,

把它们串起来就绘制成一完整的数据流程图;

另一种是从业务流程中分离出处理过程,

再考查每一个处理过程的输入数据与输出数据,

将业务过程中所有的处理过程的输入、输出数据流进行有机的集成就形成了一个完整的数据流程图。需求优先级1、首先明确自己项目的现阶段的主要目标是什么？一个产品在每个阶段的重点是不同的，提升用户体验、用户数、提升转化付费率……明确了这个目标，然后再看你收到的那些需求，评估对每一个现阶段目标的贡献程度。2、判断功能之间的依赖和对用户的影响只有把注册功能做了，用户才能登陆，才能做具体的业务。所以注册、登陆需要先比具体的业务先实现。有些功能对用户非常重要，例如当一个网站数据量很大，找个信息不好找，那么站内搜索，或者智能导航都得优先先做，才能方便用户使用。3、评估技术实现难度和成本所有的需求，最后都要设计成为功能，每个功能的技术实力不同，千万不要想当然觉得都可以实现的，有时候真的很难。这个功能咱们能不能实现？能实现的话，需要多少人多长时间？有没有其他实现的建议或者方案？这些都需要考虑的。综合以上因素就可以对需求进行排序。输出一个表格化的排序结果。用户界面数据流图一端是页面，一端是数据实体，那么下来就需要考虑页面的设计。1.根据业务特征，先在网上找类似的网页，先学习他们的设计出来的页面。2.分析他们各自的特点，思考他们为什么这么设计，对用户有什么帮助。3.先画草图跟用户进行澄清，草图主要是布局图，其中的元素基本上都是示意。4.跟用户确认差不多了，来下确认网站风格，就是CSS。5.风格确认之后，提供各种js动态效果，我们推荐的某些具体的效果。6.然后在用Hbuilder进行开发。注意：UI的设计其实很难的，要考虑因素特别多，一般大的项目都有专业的UI设计师。系统框架基本框架框架是软件的主体，它不负责任何业务逻辑部分的内容，但它决定了整个软件的整体结构。框架的主要职责是维护软件系统架构，并将构件组织起来，维护构件之间的关系，控制构件的创建、清除与调用。构件封装了所有的业务逻辑，而框架则为构件运行提供了活动环境，另所有的构件形成一个有机的整体。目前名气最大的框架结构就是MVC。MVC全名是ModelViewController，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个构件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。MVC分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。框架内容MVC是一个框架模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是JSP

servlet

+

javabean的模式。视图视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，例如jsp.MVC好处是它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。模型模型表示企业数据和业务规则。在MVC的三个部件中，被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。控制器控制器接受用户的输入并调用模型和视图去完成用户的需求，所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。框架和设计模式的区别大家很容易把框架模式和设计模式混淆，认为MVC是一种设计模式。实际上它们完全是不同的概念。

框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。框架通常是代码重用，而设计模式是设计重用，架构则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用。在软件开发过程中有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块;代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模式是软件的小实践。系统分层一个项目一般都可以分为5层架构：表现层、控制层、服务层、数据访问层和数据库五层架构。表现层：就是web页面（html,jsp）。一般只是显示，不做业务处理，可以有简单的逻辑，只能用EL和JSTL表达式来完成，强烈不建议在jsp中写java代码或者sql。控制层：就是你的请求从页面传到后台后具体控制他的由谁来处理。服务层：一般就是业务逻辑的处理，所有的具体的业务都是在这里处理。数据实体：一般用来存传递的数据，是POJO，但一般用xxxBean来表达。数据访问层：数据库中的数据到数据实体之间的相互映射。数据库：提供数据的增删改查。框架选择与演进使用Web开发框架，可以帮助开发者提高Web开发工作的质量和效率，大大减少开发工作量。但是目前互联网中充斥着各种各样的Web开发框架，这些框架都可以为开发者的项目提供各种功能扩展，如何选择成为了棘手的问题。所有框架必须是免费使用的，并且最好是开源的。此外，使用这些框架进行开发时，无需使用专有IDE、应用服务器或数据库。在从如下方面对框架进行评估：学习难度、针对简单任务的开发效率、针对复杂、特殊任务的开发效率、依赖jar包的管理、代码性能/安全优化调整的能力、在企业市场中的认同度、开发的复杂性进行评估。目前企业对spring、spingmvc比较认可。现在的mybatis、hibernate几乎一样，他们之间相互学习，基本上没有太大的区别。目前企业内部：新项目基本上都采用spring+springmvc和mybatis，但是我们不能一上来就是SSM框架，应该从基本框架进行演进。学习顺序：1.jsp+servlet+jdbc+mysql2.jsp+servlet+mybatis+mysql3.jsp+servlet+spring+jdbc+mysql4.jsp+servlet+spring+mybaits+mysql5.jsp+spring+springmvc+mybaits+mysql关键技术对于一些复杂的技术，要求很高的技术，必须先进性技术验证。写个简单的例子验证在技术上是否可以实现。如果搞不定需要重新更换技术方案。千万不要到了最后才说实现不了，那大家估计都得熬夜了。数据表设计梳理业务流程，根据业务流梳理数据流，在分析数据实体，找数据实体之间的关系；根据数据实体设计数据表，根据关系建立实体表之间的关系；考虑数据表设计三范式；建立主外键和索引，如果需要还可以考虑视图。模块分解拆分原则一般一个项目都需要拆分为多个模块进行开发，那如何拆分？要注意哪些问题？介绍几个拆分的基本原则：1、业务优先：每个项目天然会按业务功能分成多个模块，每个模块又包含许多业务相关的功能，在拆分时，我们就可以优先考虑按照业务边界进行切割，切割完成后再针对每个模块进行拆解，循序渐进，逐渐迭代深入，最终完成系统的拆解。2、循序渐进：拆分过程中包含两个非常重要的工作：拆分和聚合。二者缺一不可，并且二者是并行进行的，一定要边拆分边聚合。每一步拆分完成都要保证项目的功能是完整的。3、兼顾技术：系统不能为了拆分而拆分，需要结合技术。拆分过程中需要坚持一个基本原则：高内聚、低耦合。拆分的实际工作就是解耦。常见模块设计异常设计一、异常处理的一般原则

1、能处理就早处理，抛出不去还不能处理的就想法消化掉或者转换为RuntimeException处理。因为对于一个应用系统来说，抛出大量异常是有问题的，应该从程序开发角度尽可能的控制异常发生的可能。2、对于检查异常，如果不能行之有效的处理，还不如转换为RuntimeException抛出。这样也让上层的代码有选择的余地――可处理也可不处理。3、对于一个应用系统来说，应该有自己的一套异常处理框架，这样当异常发生时，也能得到统一的处理风格，将优雅的异常信息反馈给用户。二、异常的转化与异常链

1、异常转化的原理

所谓的异常转化就是将一种异常转换另一种新的异常，也许这种新的异常更能准确表达程序发生异常。

在Java中有个概念就是异常原因，异常原因导致当前抛出异常的那个异常对象，几乎所有带异常原因的异常构造方法都使用Throwable类型做参数，这也就为异常的转化提供了直接的支持，因为任何形式的异常和错误都是Throwable的子类。比如将SQLException转换为另外一个新的异常DAOException，可以这么写：

先自定义一个异常DAOException：

publicclassDAOExceptionextendsRuntimeException{

//(省略了部分代码)

publicDAOException(Stringmessage,Throwablecause){

super(message,cause);

}

}

比如有一个SQLException类型的异常对象e，要转换为DAOException，可以这么写：

DAOExceptiondaoEx=newDAOException(“SQL异常”,e);

异常转化是针对所有继承Throwable超类的类而言的，从编程的语法角度讲，其子类之间都可以相互转换。但是，从合理性和系统设计角度考虑，可将异常分为三类：Error、Exception、RuntimeException，笔者认为，合理的转化关系图应该如图2：

为什么要这么做呢？异常的处理存在着一套哲学思想：对于一个应用系统来说，系统所发生的任何异常或者错误对操作用户来说都是系统"运行时"异常，都是这个应用系统内部的异常。这也是异常转化和应用系统异常框架设计的指导原则。在系统中大量处理非检查异常的负面影响很多，最重要的一个方面就是代码可读性降低，程序编写复杂，异常处理的代码也很苍白无力。因此，很有必要将这些检查异常Exception和错误Error转换为RuntimeException异常，让程序员根据情况来决定是否捕获和处理所发生的异常。

图中的三条线标识转换的方向，分三种情况：

①：Error到Exception：将错误转换为异常，并继续抛出。例如SpringWEB框架中，将org.springframework.web.servlet.DispatcherServlet的doDispatch()方法中，将捕获的错误转化为一个NestedServletException异常。这样做的目的是为了最大限度挽回因错误发生带来的负面影响。因为一个Error常常是很严重的错误，可能会引起系统挂起。

②：Exception到RuntimeException：将检查异常转换为RuntimeException可以让程序代码变得更优雅，让开发人员集中经理设计更合理的程序代码，反过来也增加了系统发生异常的可能性。

③：Error到RuntimeException：目的还是一样的。把所有的异常和错误转化为不检查异常，这样可以让代码更为简洁，还有利于对错误和异常信息的统一处理。

1、异常链

异常链顾名思义就是将异常发生的原因一个传一个串起来，即把底层的异常信息传给上层，这样逐层抛出。JavaAPI文档中给出了一个简单的模型：

try{

lowLevelOp();

}catch(LowLevelExceptionle){

throw(HighLevelException)

newHighLevelException().initCaus