软件开发过程之《软件是这样炼成的》课件

软件是这样炼成的制作人：郑培泰2016年6月25日软件是这样炼成的制作人：郑培泰开篇故事

某政府要建造一座20层的办公楼，用于机关单位办公。建筑面积2万平米，投资预算1.2亿。某建筑设计研究院参与了楼房设计。某建筑公司承接了大楼的建造工程。同时，政府聘请了监理公司参与工程的监督管理。那么，整个大楼从筹划到建造完成是怎样一个流程呢？这和软件开发流程有什么相似的地方吗？Back开篇故事 某政府要建造一座20层的办公楼，用于机关单开篇故事——分析（一）政府单位：是客户，大楼这个产品的使用者。所关心的是：投资的规模楼层高度、建筑面积建造地址的选择大楼的功能要求其他需求点评：从客户那里，能了解到他们需要的是什么。是产品设计、开发的最根本依据。Back开篇故事——分析（一）政府单位：是客户，大楼这个产品的使用者开篇故事——分析（二）设计研究院：产品的设计者，主要工作：第一步：了解客户所关心的东西——客户需求点评：设计研究院分析客户需求，并将需求转化为产品设计，再将设计蓝图细化落实为施工图纸。第二步：根据客户需求进行大楼的设计选择合适的体系结构（居民楼、办公楼、教学楼）选择合适的建筑风格（中式、欧式、其他）进行楼体结构设计、外观设计、水电气管道设计、消防安全设计等，形成设计蓝图。第三步：根据设计蓝图，设计具体的施工图纸。投资的规模楼层高度、建筑面积建造地址的选择大楼的功能要求其他需求Back开篇故事——分析（二）设计研究院：产品的设计者，主要工作：第开篇故事——分析（三）建筑公司：根据施工图纸和施工规范施工完成大楼的建造。施工图纸、手册施工规范施工工具、器械建筑材料工地搭建等点评：建筑公司，相当于程序员，配置好软硬件开发环境，根据设计图、手册和编码规范，完成软件的“建造”工作。监理公司：负责施工工程的质量鉴定控制和验收工作。Back开篇故事——分析（三）建筑公司：根据施工图纸和施工规范施工完故事总结——建筑工程与软件开发流程对比图区别：Back故事总结——建筑工程与软件开发流程对比图区别：Back进入正题：《软件是这样“炼”成的》本书作者：王朔韬——研究软件企业开发过程改进和软件架构出版社：清华大学出版社主要内容：

从需求开发到软件成型交付的整个软件开发流程。全书以《投核保系统》为唯一案例，全程记录了软件开发、设计的全过程。编写特点：

“学院派”（注重理论）与“应用派”（注重应用）结合，不过分注重抽象概念的定义，结合实际案例理解为主。比如：当一个概念不容易去弄明白是什么时，就先去弄明白它能做些什么、怎么做、他的引入带来的好处，然后再去思考它是什么。Back进入正题：《软件是这样“炼”成的》本书作者：王朔韬——研究正题：《软件是这样“炼”成的》内容结构上册分三篇：软件需求开发软件架构设计（概要设计、详细设计）数据架构设计两册六篇125章，今天只讲上册。涉及三个评审一个讨论：《需求报告》评审会《概要设计》评审会《数据库设计》评审会关于详细设计的讨论Back正题：《软件是这样“炼”成的》内容结构上册分三篇：两册六篇1第一篇：软件需求开发案例驱动：《需求分析报告》评审会1.1评审会现场情形知识补充1.2面向对象概念1.3UML和绘图工具：RationalRose、Visio、SmartDraw业务调研报告1.4业务调研方式1.5内容结构：静态结构、动态结构和非业务调研需求分析报告1.6用例规划：用例图、用例描述和关系分析1.7数据字典：元数据、数据元、数据集与原始表单1.8领域类图：领域类图、非功能需求分析1.9内容结构：用例图、领域类图、非功能需求、数据字典Back第一篇：软件需求开发案例驱动：《需求分析报告》评审会1.11.1《需求分析报告》评审会——第一个评审会项目名称：投核保系统项目规模：大型金融项目产品经理：在项目合同签署10天就完成了《业务调研》和《需求分析

报告》的编写参会人员：客户代表、市场部、产品开发部、质量保证部、测试部、

评审专家顾问等PPT讲解：产品经理开始对《需求分析报告PPT》进行讲解，前

后用了 10分钟讨论意见：PPT讲解结束，大家都觉得汇报非常成功。评审专家：公司聘请的改进公司当前项目开发管理流程的顾问，向与

会的每个人提问了解情况，提出评审意见。专家评审意见：不通过为什么呢？存在的问题：需求分析报告脱离了业务调研报告，没有业务调研报告，闭门造车凭空设想没有实际意义。将组织机构图照搬为系统结构图。文档结构不清晰，逻辑混乱。对UML和面向对象分析方法一知半解，专业知识不够。领域类图抽象不完整，对领域类图的理解不够，不能为系统架构过程提供任何知道没有具体的指标，用词含糊，无法为架构师和测试人员提供测试标准。————————【现场情景】—————————点评：

该案例中，出现的问题也是很多软件开发企业存在的问题。尤其是很多中小软件企业，不注重软件开发前期的准备工作。由于工期紧张，为了节省时间往往需求调研还不够充分的情况下，就开始进入了软件设计开发阶段，造成后期编码过程中不断翻工、修改，甚至出现推到重做的情况。

所谓磨刀不误砍柴工。下面要讲的内容就是“磨刀阶段”之“业务调研阶段”，主要包括：面向对象和UML等基础知识、业务调研报告的结构和编写要求。Back1.1《需求分析报告》评审会——第一个评审会项目名称：投核保1.2面向对象的概念（一）系统分析法中最流行的方法：面向对象分析法。面向对象的建模语言：统一建模语言（UnifiedModelingLanguage，UML）——业界内认可对比较高的一种语言什么是对象？万物皆对象！比如：一辆汽车、一个人、一张成绩单、一份课程表什么是类？具有相同属性和功能的所有对象的集合。比如：交通工具、淄博人等什么面向对象？面向对象是一种对现实世界理解和抽象的方法，是计算机编程技术

发展到一定阶段后的产物。Back1.2面向对象的概念（一）系统分析法中最流行的方法：面向对1.2面向对象的概念（二）什么是接口？是一个抽象的概念，是指系统对外提供的所有服务。接口描述系统能够提供哪些服务，但不包含服务的实现细节。每个对象都是服务提供者，所以每个对象都有接口。类和接口的对比！类：Class！接口：Interface！类是对象的集合接口是服务的集合，没有实现代码接口一般需要某个类来支持他(实现它的服务细节)接口的真正用途：提供一种规范。实现这个接口的类，实际上就是满足了这个接口的规范。比如：世界上有1000种插头但只有两种插口，2孔和3孔类接口支持Back1.2面向对象的概念（二）什么是接口？是一个抽象的概念，是1.2面向对象的概念（三）面向对象的三个技术！一、封装：是一种信息隐藏技术二、继承：是类与类之间的一种关系（父类、子类关系）三、多态：是将多种不同的特殊行为进行抽象的一种能力是指将一组数据和与这组数据有关的操作放在一起，形成一个能动的实体——对象封装机制的目的就是将对象的使用者和设计者分开类层次反映了现实世界中普遍存在的一般与特殊的关系，本质是从已有的类基础上扩充、改造得到新的类。可以修改和重写父类中的方法。优点：提高软件的重用性，便于实现多态性便于系统的扩展使得语言具有根据对象的不同类型以不同方式处理通常要结合继承性一起发挥作用Back1.2面向对象的概念（三）面向对象的三个技术！一、封装：是1.2面向对象的概念（四）什么是面向对象分析技术？面向对象分析方法（Object-OrientedAnalysis，OOA），是在一个系统的开发过程中进行系统业务调查以后，按照面向对象的思想来分析问题。建模语言：UML语言UML动态模型图：包括交互图、行为图（一）交互图：时序图、协作图；（二）行为图：状态图、活动图。UML静态图：包括类图、用例图、包图、组建图、配置图面向对象软件设计一般步骤：需求分析、分析设计、编码实现、测试和维护。面向对象的基本准则：信息隐藏：通过对象的封装来实现。减少通信开销：设计中应做到子系统的各个部件之间的通信量达到最小。良好的可扩展性：继承和多态在程序设计中有很好的可扩展性。高内聚：内聚度高的模块很容易理解很容易被服用、扩展和维护低耦合：使系统中某一部分的变化对其他部分的影响降到最低，各个系统模块之间应该相互独立。Back1.2面向对象的概念（四）什么是面向对象分析技术？面向对象1.3UML介绍（一）UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言，用模型来描述系统的静态特征和动态特征。UML可以从不同的角度为系统架构进行建模，为不同的开发人员，形成不同的视图。UML的组成：图：UML中分9种（后面讲）视图：是有一个或多个图组成的对系统的抽象。分5种（后面讲）模型元素：包括事物和关系通用机制：包括修饰、注释、规格说明、通用规划和扩展机制。图是UML的重要组成部分所有的视图都可以由前述的9种基本图组成。UML图分为静态图和动态图：静态图主要包括：用例图、类图、对象图、组件图、部署图。动态图主要包括：协作图、状态图、活动图、顺序图。UML视图分五类：用例视图：从用户角度来描述系统应具有的功能，是对系统的抽象表示逻辑视图：是从系统的静态结构和动态行为角度分析如何实现系统的功能实现视图：主要供开发者使用，进程视图部署视图：主要描述系统的部署方式UML图：UM视图：事物：代表一切可以定义的东西。分为：结构事物、行为事物、分组事物2.关系：把事物联系在一起，组成有意义的结构。分为：关联关系、依赖关系、泛化关系、实现关系、聚合关系Back1.3UML介绍（一）UML是一种定义良好、易于表用例是抽象出来的用以描述人或事物具有哪些功能的概念。需求分析中用例图会用到。后面再讲.1.3UML介绍（二）

UML关系，能够很好的将用户所理解的事物符号联系起来，描述一个有意义的结构。UML中，根据不同的视图对关系进行分类，但大体一致用例关系关联关系：最直观简单的关系。UML中用实箭头表示包含关系：原有类分出的几个功能片段。基类没有了被包含类是不完整的。用虚箭头加《include》扩展关系：在原有类的基础上进行功能扩展，扩展类具有相对的独立性。基类没有了扩展类也是完整的。用虚箭头加《extend》泛化关系：表示继承关系，子例与父例相似，继承父例的所有结构、行为和关系，但表现出更特别的行为。用三角箭头表示Back用例是抽象出来的用以描述人或事物具有哪些功能的概念。需求分析1.3UML介绍（三）类关系关联关系：最一般简单的关系。UML中用实线表示泛化关系：继承关系，同用例关系。用空心箭头表示实现关系：类与接口之间最常见的关系。用虚线空心箭头表示依赖关系：一个对象的存在需要另外一个对象的存在。用虚线箭头表示。用虚线箭头表示聚合关系：整体与部分的关系，且整体与部分可分离，均具有独立的生命周期。用实线空心菱形箭头表示组合关系：整体与部分的关系，比聚合关系更强，整体与部分不可分割，其中一个部分的生命结束就代表整体的结束。用实线实心菱形箭头表示。依赖是最弱的关系。关联、组合和聚合都是依赖关系的一种。组合和聚合关系也是关联关系的一种。关联、聚合、组合，关系一次增强！Back1.3UML介绍（三）类关系关联关系：最一般简单的关系。U1.3UML介绍（四）包关系包的组成：类、接口、组件、节点、协作、用例、图，以及子包包：可以理解为文件夹，名称空间。用于将元素根据语义进行分组包的表示：UML中，包用两个矩形来表示包的关系：引入和访问依赖关系（可访问其他包，前提得先引入该包。具有传递性）、泛化关系组件：又叫构件，可以是一组接口。组件分类：三大类——配置组件、执行组件、工作产品组件。组件关系：组件关系：组件与接口的关系（分实现关系、依赖关系）、组件与组件的关系(依赖关系，同类之间的依赖关系)Back1.3UML介绍（四）包关系包的组成：类、接口、组件、节点1.3UML介绍（五）

UML机制，就是UML绘图时的辅助功能。UML机制包括修饰、注释、规格说明、通用划分和扩展机制通用机制规格说明：描述系统的细节修饰：对模型元素进行修饰，增加了模型元素的语义。比如加粗、下划线注释：是一种图形符号用来限制或给一个元素加上注释。注释用一个带有折角的矩形表示通用划分：类、对象二分法，接口、实现二分法。扩展机制UML扩展机制允许使用者自定义些自己构造型语言成分。UML扩展机制包括：构造型、约束、标记值。Back1.3UML介绍（五）UML机制，就是UML绘图时1.4业务调研方式尽量到各部门，各科室的办公现场去调研，尽量不要以召集会议的方式进行调研。尽量收齐所有业务单据、台账、报表、业务流程、规章制度等材料，以及相应的电子版材料。细节研究。用户无法面面俱到，需要我们去分析、理解和提问绘制业务流程图。在业务调研结束后，及时整理业务流程图，可以手工业务流程，现场请求客户确认。

一般是在调查问卷填写结束和面谈结束后、需要跨部门或跨职能业务流程确认时进行。

采用该方法的原因：专业差别、沟通困难，但可以将某些元素总结出来以问卷的形式针对性了解。

问卷调查的优点：能够方便快速的获取软件开发所需的信息内容（一）问卷调查（二）面谈（三）组织讨论Back1.4业务调研方式尽量到各部门，各科室的办公现场去调研，尽1.5业务调研报告的编写（一）业务调研整理静态结构整理动态结构非业务调研文档整理问卷调查面谈方式部门岗位职责描述组织讨论组织结构图文档变动性调研原始表单整理业务流程图地域性调研部门变动性调研业务流程变动性调研岗位职责变动性调研编写流程：Back1.5业务调研报告的编写（一）业务调研整理静态结构整理动态1.5业务调研报告的编写（二）业务调研报告的静态结构首先绘制单位的组织结构图。再对部门职责进行描述，一般采用表格形式。然后对每个岗位承担的职责详细描述，一般采用表格形式。最后对每个岗位职责上生成的原始资料整理，分门别类的处理。（数据字典里会用到）部门职责描述模板部门编号

部门名称

直接上级

部门性质

部门级别

编制人数

下属部门

部门职能

具备条件

Back1.5业务调研报告的编写（二）业务调研报告的静态结构首先绘1.5业务调研报告的编写（三）业务调研报告的动态结构即业务流程图，采用泳道图的方式绘制，再对各运行节点用表格进行描述。业务流程图：是物理模型。描述的是组织内各单位、人员之间的业务关系、工作顺序、业务信息流向图表。。用途：帮助系统分析人员找出不合理的流。分类：顶层业务流程图、底层业务流程图。运行节点描述模板运行节点名称办理部门办理部门

办理人及职务

办理时限

业务描述

下个运行节点是否需要跳转

跳转到第几步

跳转条件

本环节所需材料

需要打印的材料

产生的相关文书

本环节提交材料及份数（份数必须填）

相关操作

填写审批表的对应内容

是否需要历史数据对比

备注

序号关联部门名称与相关审批项目上游部门还是下游部门1

2

泳道式业务流程图Back1.5业务调研报告的编写（三）业务调研报告的动态结构即业务1.5业务调研报告的编写（四）非业务调研非业务调研其实就是在企业现有业务运行的基础上，需要对客户进行进一步沟通，了解客户在业务范围之外的一些特殊情况。客户系统的运行地域性变动部门变动性：单位内部部门的组织结调整的频繁程度业务流程变化性：组织结构内部对业务流程调整的频度岗位职责的变动性：某些岗位的工作职责的变化频率问题文件资料的变动性：文档的变化频度，比如文档格式、文档数据项、文档的使用者非业务调研是需求分析中非功能性功能需求的基础！Back1.5业务调研报告的编写（四）非业务调研非业务调研其实就是1.5业务调研报告的编写（五）业务调研报告内容格式目标组织结构（一）组织结构图（二）部门职责描述（三）岗位职责分析目标流程设计（一）分层说明（二）一层业务流程图：泳道图、运行节点描述（三）底层业务流程图：泳道图、运行节点描述表单资料整理（一）需要整理的格式文件（二）不需要整理的格式文件（三）不惜要整理的图像文件现行系统状况

当前系统建设情况、存在的问题、可重复利用的资源等，以便在此基础上进行系统建设。非业务分析（一）地域性调研：城市分布、办公区域分布、物理地址分布等（二）部门变动调研：比如新部门的增加（三）业务流程变动性调研：（四）岗位职责变化性调研：（五）文档变化性调研：特别期许（一）为了适应客户工作过程流程的灵活变化，要求系统至少能够实现业务流程定制工作。（二）无纸化办公，除签字部分。（三）自动化程度高，系统自动实现一些功能，并给出，比如，初审意见。（四）工作角色变化灵活化。为适应工作人员职责的灵活变化，系统能够根据不同的角色分配系统功能。（五）数据访问权限设置，不同职级的人员查血的信息不同Back1.5业务调研报告的编写（五）业务调研报告内容格式目标组织业务调研报告——小结回想本篇驱动案例中存在的问题。UML基础知识的了解和一份内容完整、结构清晰的《业务调研报告》，解决了案例中第1、第2和第4条问题。《业务调研报告》的编写，是为了给《需求分析报告》编写依据。《需求分析报告》不能脱离《业务调研报告》。那么如何从《业务调研报告》中挖掘需求，形成《需求分析报告》呢？Back业务调研报告——小结回想本篇驱动案例中存在的问题。Back1.6用例规划——需求分析最基础部分什么是用例？用例是系统给外部提供的可视化的功能单元。代表的一个外部功能块，不考虑内部实现过程UML表示：椭圆，下方标注用例名称用途：从外部看系统该有的功能，将客户的想法用更加容易理解的图形化样式展现出来。来源：《业务调研报告》。抽取自关键业务中的动词或动词词组。前面“用例关系”中提到过用例具有参与者，是与用例有来往的人或事物，是系统的外部实体。用例的参与者UML表示：用人形图标表示，下方为参与者名称用途：一个系统中必然有参与者，否则系统没有任何存在意义参与者与用例连接在一起，表示两者之间有信息交互参与者的存在是为了执行用例的参与者之间的关系类似于类关系。最常见的就是泛化关系——继承关系。Back1.6用例规划——需求分析最基础部分什么是用例？用例是系统什么是用例图？用例图是业务调研后，最先用来跟用户交流讨论的UML图用途：从外部看系统该有的功能，将客户的想法用更加容易理解的图形化样式展现出来。来源：《业务调研报告》，抽取自关键业务中的动词或动词词组。1.6用例规划——用例图组成：参与者、用例、用例间的关系用例描述用例图仅仅是文字说明的补充，需要结合用例描述来完成。用例描述往往会被一些系统分析员所忽略。用例描述投保书录入用例描述用例名称投保书录入用例编号301创建人黄飞虎创建时间2011年5月22日更新人黄飞虎更新时间2011年6月22日简要说明投保时录入用例主要是将投保书相关资料，包括基本信息、投保项、投被保险人健康告知，投被保险人财务告知等。录单员录入的资料来源于扫描是已经完成的头望书图像文件。录入成功后放可进入下个环节核保环节……假设前提条件投保书已经扫描并保存正确的投保书图像文件

事后条件进入核保环节优先级高使用频率随时事件流主事件流1.录单员登录成功2.系统检索已经成功扫描而未完成录入的投保书3.系统员选择要录入的投保书，系统显示投保书图像4.录单员根据图像文件，录入相应数据

4.1如果系统运行错误，按照异常处理第一条处理

4.2如果发现输入规则性错误，按异常第二条处理

4.3如果投保书要修改且要客户确认，启动问题件编写事件流5.成功保存，返回列表界面异常1.系统提示有异常，返回列表界面，并将数据库归为输入前原始状态。2.系统提示数据不符合业务规则，轻确认后重新输入。问题件编写其他事件流1.录单员选择问题件编写功能2.选择是否需要回执3.选择回执期限4.启动问题件编写用例5.先写成功后返回到事件流第5条

Back什么是用例图？用例图是业务调研后，最先用来跟用户交流讨论的U1.6用例规划——从业务流程中归纳用例将业务流程图中所有节点按属性归类，形成《运行节点分析表》软件系统的可替代性业务复杂度是否具有共享性关键业务优先等级根据节点创建用例，再将用例拆分，形成《用例拆分表》选择粗略的用例拆分成若干子用例说明拆分理由和子用例的功能用例补充，形成《用例补充表》业务流程中无相应节点创建用例用户有必须该节点才能满足用户需要系统分析员需要做用例补充。补充理由、功能描述将上述三个表整合，形成《用例汇总表》，内容包括：需求归类用例来源优先等级关联部门为所有用例寻找参与者，形成《用例参与者关系表》无参与者的用例为无效用例关系就是参与者如何与用例交互时的操作对不重要用例进行删减的最终结果，建立《系统用例最终确认表》遵循高优先级原则，删除低优先级用例不是所有的用例都要实现，这要根据用户的投资规模、商业目标、企业管理模式来确定。根据业务调研分析报告中的特别期许，建立《特别期许用例表》主要根据非业务调研的内容来确定有时需要与用户洽谈、增加投资来实现其中的功能运行节点分析表运行节点名称替代性复杂度共享性优先级可行性投保建档是复杂有高是整理编号否简单五第否扫描是复杂有高是

用例拆分表用例名称子用例名称拆分理由功能描述投保建档合法性校验需独立处理对投保书合法性校验基本信息录入需独立处理

转账授权录入需独立处理

身份证件校验需公安系统处理对身份证号码校验银行账户校验需银行系统处理对银行账号校验用例补充表用例名称补充理由功能描述业务员信息维护便于对业务工作业绩统计分析包括业务员信息的增删改查

用例汇总表用例名称需求归类来源优先级关联部门投保建档功能需求业务分析高柜员运营保险产品维护功能需求补充需求中录入室用例参与者关系表

柜员初审员档案室核保员系统管理投保建档增加查询查询查询删除修改扫描

录入查询查询删除修改用例确认表柜员业务部分

柜员初审员档案室核保员系统管理投保建档增加查询查询查询删除修改扫描

录入查询查询删除修改扫描室业务部分

柜员初审员档案室核保员系统管理扫描

扫描统计

核保业务部分

柜员初审员档案室核保员系统管理回执单录入

录入统计

特别期许用例表用例名称需求归类来源优先级关联部门元数据设计功能需求业务分析高系统管理用户权限分配功能需求业务分析高系统管理Back1.6用例规划——从业务流程中归纳用例将业务流程图中所有节1.7数据字典——需求分析中最易被忽略的部分什么是数据字典？数据字典是一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库数据字典是需求分析报告的重要组成部分数据字典的维护，一般独立于软件需求规格说明数据字典确保了数据在整个开发过程中的唯一性，指导系统架构师、数据架构师、程序员等完成架构和实施等工作与数据字典有关的概念：元数据：关于数据的数据。元数据引领好数据数据元：对象类与其某种特性构成的数据表示，可以对应多个意思。如人和年龄，构成数据元“人的年龄”。数据集：为特定的目的而收集的、具有特定主体的一组数据，是若干数据元的集合体。如姓名完全表示有姓名、昵称、化名、笔名、中文名、外文名、曾用名、曾用名使用时间等。这里所讲的数据字典与数据库设计中的数据字典概念要大。它是为所有的开发人员服务的，包括为数据库设计提供服务Back1.7数据字典——需求分析中最易被忽略的部分什么是数据字典1.7数据字典——解读业务调研，编写数据字典解读业务调研报告《业务调研报告》是系统分析和设计的唯一入口，不能脱离它编写数据字典用例规划，是根据业务调研报告中的业务流程图解读出来的而数据字典，是从业务碉堡恭的原始表单中整理出来的分析用例与原始表单关系，检查用例汇总是否有遗漏的原始表单，如有遗漏及时补充。建立《原始表单整理表》编写数据字典的编写规范，包括数据命名规范、数据集编号规范、数据项命名规范、数据项英文命名规范等，建立《系统数据字典编写规范》对应原始表单，建立《系统数据集确认表》对应数据集，对数据项进行归类整理，建立《数据集数据项列表》为所有数据项建立字典说明其定义、数据类型、标识符等。将所有的输将解释说明编排整理汇总，完成数据字典数据库的创建。原始表单整理表用例名称用例类型表单名称表单来源投保建档业务需求投保书业务员信息原始表单投保产品基本信息原始表单保险产品费率原始表单投保书基本信息原始表单投保书操作日志原始表单投保项部分原始表单转账授权数据原始表单扫描业务需求扫描图像需求补充扫描登记需求补充问题件数据需求补充问题操作日志需求补充投保书操作日志需求补充数据集确认表序号数据集名称数据集英文名称备注001投保书业务员信息数据集SalesInProposal

002缴费和领取数据集ContributionsAndReceive

003体检函数据集MedicalLetter

数据集数据项列表投保书业务员信息数据集标识符中文名称英文名称备注IN001投保书编号ProposalNumber

EM001业务员编号JobID

EM002业务员姓名ClerkName

EM003业务员部组MinistryOfGroupSales

数据项字典IN001投保书编号标识符IN001中文名称投保书编号英文名称ProposalNumber简称投保书编号定义是针对每张投保书编写的号码数据类型字符串同义名词投保单编号元数据类型元数据计量单位元值域25位Back1.7数据字典——解读业务调研，编写数据字典解读业务调研报1.8领域类图——描述的是系统中的操作对象什么是领域类？用例是系统的外部功能数据字典是对系统中的数据类型的描述领域类是用例这个系统功能的操作对象。领域模型来自业务描述中的名词以及对名词的抽象领域模型是一个分析模型，是帮助分析人员、用户认识现实业务的工具，是需求分析的产物，描述的是业务中涉及的实体及其相互之间的关系领域类包括三大要素：领域类的名称、具有的属性、对这些属性的操作表示：三格矩形图领域类图的可见性（封装属性）：分四种，private、public、protected、PackageBack1.8领域类图——描述的是系统中的操作对象什么是领域类？用1.8领域类图——领域类图设计领域类图的设计原则1.独立于实现类原则；2.弱关联原则；3.服务需求原则；4.数据结构无关原则第一步：提取领域类图整理原始表单：将原始文档表单和用例进行匹配，建立《用例与文档关系表》。将有效匹配的文档资料初选为系统中的类。补充类图：为保证数据的完整性和安全性需要添加其他的功能和用例，所以应该补充一些类图。这些就是类的雏形。类图分割：为了设计上的方便，往往需要对类进行进一步分割，进行分析设计。领域类的操作一般以用例为单位，所以结合用例和领域类进行操作对比，建立《类操作对比图》然后形成《类初选表》最后结合数据字典设计，建立《领域类图确认表》从业务调研报告中，挖掘领域类图第二步：为所有领域类，添加操作；然后为各领域类画领域类图。Back1.8领域类图——领域类图设计领域类图的设计原则1.独立于1.8关于非功能需求分析什么是非功能需求？非功能需求是指对系统提供的服务或功能的约束。系统分析员经常会忽略掉。非功能需求不像功能需求那么直观和容易理解，比较的抽象，但确实非常重要。因为它是影响软件的性能和可用性的关键所在。非功能需求关心的是整个系统的特性，比功能需求更关键。功能需求没有实现可能只是降低了系统的可用性；功能性约束没有满足，可能就会导致系统无法使用非功能需求的内容范围有：物理需求、实施需求、设计约束、可支持性、接口需求、可用性、性能、可靠性等Back采取调查问卷的方式让客户回答，建立《客户非功能需求调查问卷》，包括需求名称、关键指标、是否理解含义、具体要求等。如何获取用户的非功能需求？将不同的用户进行分类，针对不同的用户设计不同的调研内容，建立《客户非功能需求调研指标》包括客户姓名、部门、职位、关注指标等非功能需求分析的主要内容：（一）物理需求分析：是指软件运行的硬件环境要求比如：业务应用服务器，Web应用服务器，数据库服务器（二）实施需求分析：是指开发过程中，需要的实施环境和设施。比如：运行平台（操作系统），数据库工具，开发语言和工具，建模工具，绘图工具，测试工具等（三）易用性需求分析：涉及到美工和界面，人机工程，交互式设计，心理学，用户行为模式等方面。主要有三个原则：易见、易学、易用。（四）性能需求分析：如响应时间，用户数（吞吐量）（五）可靠性需求分析比如：应用服务器故障问题，数据库故障问题1.8关于非功能需求分析什么是非功能需求？非功能需求是指对1.9需求分析报告——项目的宪法需求分析报告需求分析报告是业务调研报告或可行性分析报告后的重要文档，相当于项目的宪法需求分析报告是客户合同的一部分，主要任务是描述系统要做什么，而不关心如何做。需求分析报告评审等级是项目评审中最高高级别的评审，参与人数也是最广的需求分析报告的基本依据是业务调研报告。有事还在此基础上进一步扩展，然后与客户沟通，讨论大家一致可接受的需求Back需求分析报告编写中，严禁使用形容词等描述性语言进行系统描述，特别是性能需求的分析方面，必须是可测试的数量词准确说明1.9需求分析报告——项目的宪法需求分析报告需求分析报告是1.9需求分析报告——包含哪些内容需求分析一般包含哪些内容？项目风险分析产品范围产品功能Back用户类型和特征运行环境假设和设计约束用户界面需求硬件接口软件接口通信接口系统功能需求系统非功能需求数据字典定义词汇表等前面我们学了用例图、领域类图、数据字典。就可以用在需求分析报告中。系统功能需求，一般采用用例和领域类图来描述说明数据描述数据描述一般采用领域类图结合数据字典来说明1.9需求分析报告——包含哪些内容需求分析一般包含哪些内容1.9需求分析报告——报告的编写可以分为六部分：Back1.9需求分析报告——报告的编写可以分为六部分：Back第一篇：软件需求开发（小结）《业务调研报告》是需求开发的基础，也是一整个项目开发的基础需求调研中的静态结构：公司有哪些部门、部门有哪些岗位、岗位与哪些职责、职责需要完成的文档资料需求调研的动态结构：业务流程图（泳道图）分两层，顶层业务流程图和底层业务流程图对客户原始表格资料整理，保证数据的准确性，为后期编写数据字典提供依据。解读业务调研报告，完成用例规划、完成用例描述、完成领域类图设计。所有的需求开发图都来自于对业务调研报告的准确理解之上。Back第一篇：软件需求开发（小结）《业务调研报告》是需求开发的基础第二篇：软件架构设计案例驱动：《概要设计文档》评审会2.1评审会现场情形基本概念2.2软件架构2.3体系结构、架构模式、设计模式、软件框架概要设计中的必须的几个图2.4时序图2.5活动图2.6状态图2.7包图2.8组件图2.9配置图软件架构设计2.10体系结构风格选择2.11分层设计：表示层、控制层、业务逻辑层2.12设计模式与框架选择2.13异常体系设计《概要设计文档》的编写2.14概要设计说明书编写说明2.概要设计说明书内容格式Back第二篇：软件架构设计案例驱动：《概要设计文档》评审会2.12.1《概要设计文档》评审会——第二个评审会项目名称：仍然是投核保系统项目规模：属于大型金融项目软件架构师：总结了上次需求开发的经验，这次架构设计报告评审编

写比较仔细，在正式会议之前项目组内已经进行了预先评

审，项目组各成员都填写了评审意见小组成员意见：18人填写了评审意见表，12人表示没有意见各人观点：测试经理认为架构设计对他们无关紧要；编程人员觉得概

要设计的文档与他们无关，认为详细设计文档做的太细致影

响程序员的自由发挥，还要拿出大量的时间去编写文档，浪

费时间，影响进度。评审专家：评审专家认真听取了每个人的意见后，开始看小组提交的

《概要设计说明书》。专家评审意见：还是不通过为什么呢？存在的问题：文档结构不合理内容不够全面对软件架构的基本知识缺少了解。UML五视图不全面、不规范。————————【现场情景】—————————点评：

评审没有通过的最根本原因是，缺少对软件架构知识的了解。小组成员对犯了“短视”毛病，对软件架构设计不够重视。Back2.1《概要设计文档》评审会——第二个评审会项目名称：仍然是2.2软件架构什么是软件架构？软件架构（softwarearchitecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件逻辑架构：主要任务是描述软件系统中元件之间的关系，比如用户界面，数据，外部接口等相关概念。物理架构：就是描述软件系统中元件是怎样放在硬件上的系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能。系统架构要求难度大于其他架构，对软件架构师本身技术要求非常高。架构由许多不同的架构视图来表示。这些视图本质上是以图形方式来摘要说明，主要包括:用例视图、逻辑视图、实施视图、进程视图、配置视图架构的种类？架构有哪些视图？Back2.2软件架构什么是软件架构？软件架构（software2.2软件架构——软件重用什么是软件重用软件重用就是指在多次不同的软件开发过程中重复使用相同或相近软件元素的过程。包括程序代码、测试用例。设计文档、设计过程、需求分析文档等。可靠性:安全性:可伸缩性:软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。可定制化:同样的一套软件，可根据客户群的不同和市场需求的变化进行调整。可扩展性:在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。可维护性:一是排除现有的错误，二是将新的软件需求反映到现有系统中去。客户体验:软件系统必须易于使用。市场时机:软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。架构设计的目标是什么？软件架构构建的就是语意完整、语法正确、有可重用价值的单位软件。Back2.2软件架构——软件重用什么是软件重用软件重用就是指在2.3体系结构、设计模式、软件框架——体系结构什么是体系结构？软件体系结构是具有一定形式的结构化元素，即构件的集合。包括处理构件、数据构件、连接构件。是架构设计的内容，且易于被绝大多数人所理解。处理构件：负责对数据进行加工数据构件：是被加工的信息连接构件：把体系结构的不同组件连接起来体系结构在开发过程中的重要作用？软件体系结构是构建软件大厦的蓝图。软件体系结构有很多种，不同的体系结构，构件不同风格的软件。一定要选择合适的体系结构，就像居民楼的蓝图不能用来建造学校宿舍一样。软件体系结构建模的目标：可重用性。使用软件重用技术可以减少软件开发过程中大量的重复性工作，提高软件的生产效率，降低开发成本，缩短开发周期。Back2.3体系结构、设计模式、软件框架——体系结构什么是体系2.3体系结构、设计模式、软件框架——设计模式什么是架构模式？架构模式也叫架构风格，描述软件系统里的基本的结构组织或纲要。架构模式提供一些预先定义好的子系统，指定他们的责任，并给出把他们组织在一起的法则和指南。常见架构模式有：C/S结构、B/S结构。什么是设计模式？设计模式是一套被反复使用、多数人所知晓的、经过分类编目的、代码设计经验的总结使用设计模式是为了可重用代码，让代码更容易被他人理解，保证代码的可靠性。设计模式是代码真正工程化设计模式是软件工程的基石。设计模式和体系结构的关系：体系结构是设计模式实现的指导思想。设计模式研究的是一个设计问题具体的解决方法一个体系是一种或多种设计模式和代码的混合体。Back2.3体系结构、设计模式、软件框架——设计模式什么是架构2.3体系结构、设计模式、软件框架——软件框架什么是软件框架？软件框架是一种半成品，是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构框架的作用是什么？框架由于提取了特定领域软件的共性部分，所以在此领域内新项目的开发过程中代码不需要从头编写，秩序在此框架的基础上进行二次开发和调整就能满足要求。这样可以提高软件的质量、降低成本、缩短开发时间，使开发越做越轻松，软件效益越做越好，形成一个良性循环。框架和平台是一回事吗？框架是一种半成品，需要开发人员二次开发实现具体的功能。平台的概念比较宽泛，可以是一种操作系统、一种应用服务器、一种数据库软件、一种通信中间件。所以可以这样认为，平台主要是指提供特定服务的系统软件。框架侧重于设计和开发过程，它通过调用平台提供的服务而其作用软件架构、体系结构、设计模式、软件框架之间的关系？软件架构是绘制蓝图的整个过程体系结构就是这个蓝图——指导“施工图纸”开发的思想设计模式是实现该体系结构的一种解决方法。（比如MVC是一种设计模式）软件框架是建立在体系结构基础上的半成品、模块工具。（比如Struts是为实现MVC模式而开发的框架）UML是描述架构、框架和设计模式的建模语言

Visio是UML建模工具Back2.3体系结构、设计模式、软件框架——软件框架什么是软件2.4软件架构与时序图——什么是时序图什么是时序图？时序图属于动态视图，是描述对象之间是如何互助协作的，以实现用例功能是对用例的进一步说明，描述系统内部的动态结构和内部各对象间通信关系时序图是显示对象之间交互的图，这些对象是按照时间顺序排列的。Back2.4软件架构与时序图——什么是时序图什么是时序图？时序2.4软件架构与时序图——组成元素时序图包含哪些元素？（一）对象：置于顶部，表示交互开始时对象已存在；不在顶部，交互时创建对象间的左右关系不重要，但为了图的清晰整洁：交互频繁的对象尽可能排在一起初始化真个交互活动的对象放在最左边（二）生命线：表示对象的生存时间。生命线开始，对象创建；生命线结束，对象销毁。（三）消息：对象之间的交互式通过互发消息实现的。一个对象可以请求另外的对象做事情消息是来源对象指向目标对象的。消息包括：简单消息、同步消息、异步消息简单消息：直线箭头。同步消息：实心箭头。源对象发出消息（请求），然后等待目标对象处理结果接受到回应。异步消息：单箭头。源对象发出消息后，就去干其他事情去了，不用等待回应消息。（四）激活：对象处于休眠状态，需要消息来激活。对象处于激活状态，表明该对象正在执行某个动作激活在UML时序图中用一个细长的矩形框表示，矩形的高度表示对象执行操作所经的时间。对象接收到消息是可由自己来完成，也可以调用其他对象来完成。参与者对象生命线消息激活Back2.4软件架构与时序图——组成元素时序图包含哪些元素？（2.4软件架构与时序图——时序图的用途时序图的用途领域类图、用例图是从系统功能和结构的角度来分析系统的，都是围绕着系统的外部结构进行描述的，不考虑具体实现过程时序图是从系统本质开始描述。从用例的内部结构开始描述；解释的是用例内部对象之间的关系，是对用例的细化。它按照时间顺序清晰描述了用例这个功能块中各用例之间的通信关系。时序图的创建，依托于领域类图和用例图！！Back2.4软件架构与时序图——时序图的用途时序图的用途领域类图2.4软件架构与时序图——绘制时序图时序图绘制步骤选择要绘制时序图的用例（不是所有的用例都需要绘制时序图）列出用例的事件流（事件流，展现了消息的推送过程）Back把子系统作为黑匣子，根据事件流绘制没有内部对象的时序图（简单时序图）揭开黑匣子，将每个服务替换为用例中用到的对象，然后添加相关消息（复杂的时序图）用例描述投保书录入用例描述用例名称投保书录入用例编号301创建人黄飞虎创建时间2011年5月22日更新人黄飞虎更新时间2011年6月22日简要说明投保时录入用例主要是将投保书相关资料，包括基本信息、投保项、投被保险人健康告知，投被保险人财务告知等。录单员录入的资料来源于扫描是已经完成的头望书图像文件。录入成功后放可进入下个环节核保环节……假设前提条件投保书已经扫描并保存正确的投保书图像文件

事后条件进入核保环节优先级高使用频率随时事件流主事件流1.录单员登录成功2.系统检索已经成功扫描而未完成录入的投保书3.系统员选择要录入的投保书，系统显示投保书图像4.录单员根据图像文件，录入相应数据

4.1如果系统运行错误，按照异常处理第一条处理

4.2如果发现输入规则性错误，按异常第二条处理

4.3如果投保书要修改且要客户确认，启动问题件编写事件流5.成功保存，返回列表界面异常1.系统提示有异常，返回列表界面，并将数据库归为输入前原始状态。2.系统提示数据不符合业务规则，轻确认后重新输入。问题件编写其他事件流1.录单员选择问题件编写功能2.选择是否需要回执3.选择回执期限4.启动问题件编写用例5.先写成功后返回到事件流第5条

2.4软件架构与时序图——绘制时序图时序图绘制步骤选择要绘2.5软件架构与活动图——包含哪些元素活动图的组成元素？（一）活动状态具有一个入口和至少一个外出转换用圆角矩阵表示Back（二）动作流活动之间的转化，表示两个状态或动作状态之间的关系用实线箭头表示（三）开始和结束开始：实心圆，实际是一个占位符结束：带边框的实心圆，表示流程的结束（四）动作状态动作状态是指原子的，不可中断的动作用平滑的圆角矩阵表示（五）分叉与汇合分叉：表示一个控制流被多个控制流代替，是并发的汇合：是分叉的反向，是指多个控制流合并为一个控制流（六）分支同一个出发时间，可根据不同的条件转向不同的活动，每个转移就是一个分支。在UML活动图中，分支的控制用菱形来表示。（七）对象流对象流是控制流的一种活动图中可以出现对象，对象可以作为活动的输入或输出（八）判断菱形表示判断，可以控制动作流的走向（九）泳道泳道的主要作用就是区分负责活动的对象2.5软件架构与活动图——包含哪些元素活动图的组成元素？2.4软件架构与时序图——时序图的筛选时序图的筛选前面说过，不是所有的用例都需要画时序图！那么如何筛选适合做时序图的用例呢？列出所有的用例，根据每个用例中所包含的对象的多少进行筛选。少于三个对象的可考虑不画时序图Back对象多但流程说明的步骤少，说明时序图复杂度低，也不考虑绘时序图对象少流程步骤也少，但涉及其他的用例较多，应考虑对其编写时序表根据上述三个指标，编写《时序图筛选表》时序图筛选表用例名称步骤数对象数例外系统数是否选择投保建档783是投保书校验660是投被保险人身份证件校验111否投保人银行账户校验111否业绩统计520是投标书跟踪220否回执单处理660否2.4软件架构与时序图——时序图的筛选时序图的筛选前面说过2.5软件架构与活动图——什么是活动图什么是活动图？活动图是UML中的动态视图活动图描述活动的顺序，展现的是从一个活动到另外一个活动控制流。活动图从实心圆开始，经过圆角矩形（活动）、菱形（判断）、转换线，在泳道中来回穿梭，最终到达终点。Back2.5软件架构与活动图——什么是活动图什么是活动图？活动2.5软件架构与活动图——与其他图的区别活动图与流程图的区别？流程图着重描述的是处理过程，主要的控制结构是顺序、分支、循环，每个处理过程之间有严格的顺序和时间关系。Back活动图描述的是对象活动的顺序关系、所遵循的规则，着重表现的是系统的行为，而非系统的处理过程。活动图是面向对象的，流程图是面向过程的活动图能够表示并发活动的情形，而流程图不行。时序图是针对某一个用例中对象之间的活动顺序关系的。时序图的自身特点使得他对系统的分析不够完整。无法满足条件转换、分支分叉的表述。时序图确定了用例之间对象的交互顺序，也确定了对象之间的消息（方法和参数），偏向于对象的构造活动图指明了程序中某个方法体的活动特征，在某种条件下的对象调用活动图与时序图的区别？2.5软件架构与活动图——与其他图的区别活动图与流程图的2.5软件架构与活动图——活动图的设计从业务调研报告中挖据信息，设计活动图需求分析报告，设计活动图选择要绘制活动图的用例确定活动图的层面，是顶层还是普通层确定活动图中使用的对象，用泳道分开确定活动的开始节点和终止节点将开始节点和结束节点的所有活动都找出来确定所用泳道的对象流分析分支、分叉，并绘制出来确定动作流，并绘制出来添加活动图说明表，对活动图进行补充说明（活动、参数和对象流、说明）Back2.5软件架构与活动图——活动图的设计从业务调研报告中挖2.5软件架构与活动图——活动图的筛选Back列出所有的用例来，根据用例包含的活动多少进行筛选。活动数量少的说明活动件通信简单，可以不考虑画活动图根据活动图中涉及的对象多少进行判断。如果对象多，但活动步骤少，也不一定要画活动图存在其他事件流，一般需要绘制活动图存在多个条件判断的，分支较多，有必要画活动图存在多想选择的，分叉较多，这类用例活动图绘制的优先级较高综合指标，编制《活动图筛选表》（主事件流步骤，其他事件流步骤、分支判断、分叉判断、对象数）根据需要，挑选出其中一部分用例绘制活动图。活动图的筛选和时序图类似，并不是所有的用例都需要活动图2.5软件架构与活动图——活动图的筛选Back列出所有的2.6软件架构与状态图——什么是状态图什么是活动图？状态图主要用于描述一个对象在其生命周期内的动态行为。表现为一个对象所经历的状态、引起状态转移的时间、和因状态转移而伴随的动作。可以用状态机图来建模。状态图的重点是描述控制流状态图是个动态视图Back2.6软件架构与状态图——什么是状态图什么是活动图？状态图2.6软件架构与状态图——包含哪些元素状态图的组成元素？（一）状态：指在对象的生命周期中的某个对象的条件或状态所有对象都有状态，状态是对象执行了一系列活动的结果当某个时间发生后，对象的状态将发生改变状态用圆角矩形表示，初态用实心圆点表示，终态用内嵌圆点表示Back（二）转移：是连个状态之间的诶关系，表示对象在原状态下执行一定的动作更，并在某个特定事件和条件下进入目标状态。事件标记：是转移的诱因，可以是一个信号、时间、条件变化和时间表达式警界条件：满足该条件时，事件才引发转移结果：对象状态转移后的结果（三）动作：是一个可执行的原子操作，也就是说动作是不可中断的，其执行时间使可以忽略不计的。（四）自身转移：状态可以有自身状态的转移，称为自身转移。（五）组合状态：含有子状态的状态的状态。组合状态在某个时刻可以同时达到多个子状态。（六）并发区域：状态可以分为区域。2.6软件架构与状态图——包含哪些元素状态图的组成元素？2.6软件架构与状态图——状态图的设计状态图的设计（一）确定状态图的上下文，找到要做状态图的目标对象（比如一个用例）（二）选择初始状态和终结状态初始状态和终结状态其实是个伪状态，其他的状态全是中间状态。（三）发现对象个各种状态（四）确定状态可能发生的转移（五）吧必要的动作加到状态或转移上（六）绘制状态图Back状态图的筛选方法根据用例的包含的状态的多少筛选分析用例中的所有事件，和事件对状态的改变，如果结构相对复杂，则需要单独进行分析分析用例的分支和分叉情况，越复杂越有限画状态图最后，综合所有指标编制《状态筛选表》2.6软件架构与状态图——状态图的设计状态图的设计（一）2.6软件架构与活动图——活动图的筛选Back列出所有的用例来，根据用例包含的活动多少进行筛选。活动数量少的说明活动件通信简单，可以不考虑画活动图根据活动图中涉及的对象多少进行判断。如果对象多，但活动步骤少，也不一定要画活动图存在其他事件流，一般需要绘制活动图存在多个条件判断的，分支较多，有必要画活动图存在多想选择的，分叉较多，这类用例活动图绘制的优先级较高综合指标，编制《活动图筛选表》（主事件流步骤，其他事件流步骤、分支判断、分叉判断、对象数）根据需要，挑选出其中一部分用例绘制活动图。活动图的筛选和时序图类似，并不是所有的用例都需要活动图2.6软件架构与活动图——活动图的筛选Back列出所有的2.10软件体系结构风格——体系结构的讨论（一）软件体系结构讨论的是些什么内容呢？软件体系结构讨论的是在系统中不同的独立构件存放位置的问题，以及这些构件之间的通信方式软件体系结构是高层次的抽象，并不涉及具体的技术实现设计软件体系结构是必须考虑现有的系统兼容性、安全性、可靠性，以及系统以后的扩展性、伸缩性构件是面向软件体系结构的可复用软件模块，它实现了特定的功能，符合并实现了一套接口标准构件的特点：自描述、可定制、科技城、连接机制Back什么是构件？构件分为：通信构件、处理构件、数据构件处理构件：负责业务处理通信构件：负责构件之间消息传递和通信数据构件：负责数据存储和检索2.10软件体系结构风格——体系结构的讨论（一）软件体系结2.10软件体系结构风格——体系结构的讨论（二）软件体系结构干了些什么事情呢？将系统分成若干构件，研究构件之间的关系，然后进行分类（运行构件、数据构件、连接构件）。这是体系解结构的基础在数据结构和算法的高层之上，对组件进行设计。完成组件之间的组织、通信、同步、数据存储、物理分布，最后拿出对组件设计方案的选择、评估和有效分析组件设计完成后，考虑这些组件遵循的规则、范围等考虑系统的性能（构件提供的服务、性能、特性、错误处理、共享资源使用等方面）Back它的重要作用表现在哪些方面？有利于相关人员之间的沟通系统设计的前期决策可传递的系统级抽象2.10软件体系结构风格——体系结构的讨论（二）软件体系结2.10软件体系结构风格——分类软件体系结构的分类（一）C/S风格：客户机和服务器结构，包括C/S/S结构（客户机/应用服务器/数据库服务器）。Back优缺点分析：应用服务器的运行数据负荷较轻。它将数据的