一.软件项目管理
1）软件项目管理
软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设的范围内有效地利用人力、资源、技术和工具，使软件系统或产品按照原定的计划和质量要求如期完成。
软件项目管理设计的范围： 有效的软件项目管理集中在4个P上，
即人员（Person）、产品（Product）、过程（Procedure）和项目（Project）
1.软件规模估算
代码行技术：
代码行技术是比较简单的定量 估算软件规模的方法。这种方法依据++以往开发类似产品的经验和历史数据，++估计实现一个功能所需要的源程序行数。当有以往开发类似产品的历史数据可供参考时，用这种方法估计出的数值还是比较准确的。
把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。 为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值之后，再用下式计算程序规模的估计值：
用代码行技术估算软件规模时，当程序较小时常用的单位是代码行数（LOC），当程序较大时常用的单位是千行代码数（KLOC）。
2.软件项目估算
利用一定的估算方法估算开发软件所需的成本、时间和工作量。
成本估算方法： 常见的成本估算方法有自顶向下估算法、自底向上估算法、差别估算法、专家估算法、类推估算法、算式估算法。
成本估算模型：（1）Putnam模型：动态多变量模型，是假设在软件开发的整个生存周期中工作量的特定分布
（2）COCOMO模型：是最精确、最易于使用的成本估算模型之一。
基本COCOMO模型对整个软件系统进行估算；
中级COCOMO模型将软件系统模型分为系统和部件两个层次；
详细COCOMO模型将软件系统分为系统、子系统和模块3个层次。
3.软件项目风险分析
1. 风险识别： 风险识别试图系统化地确定对项目计划的威胁。风险识别的一个方法是建立风险条目检查表，用于识别一些常见的、已知的、可预测的风险，比如产品规模、商业影响、客户特性、过程定义、开发环境等。
2. 风险预测： 预测风险发生的可能性或概率，以及风险发生所产生的后果。
3. 风险评估： 定义风险参照标准，评估风险、风险发生的概率、风险产生的影响。
4. 风险控制： 一个有效的策略必须考虑：风险避免、风险监控、风险管理及意外事件计划 。对风险采取主动规避，才是最好的风险控制。
4.进度管理
确保软件项目在规定的时间内按期完成。
一个软件项目通常可以分成多个子项目和任务，有些任务可以并行开发，有些必须等另一些任务完成后才能进行。每个任务都需要一定的资源，包括人、时间等，项目管理者的任务就是定义所有项目任务以及它们之间的依赖关系，制定项目的进度安排，规划每个任务所需的工作量和持续时间，并不断跟踪项目执行情况，及时调整。
常见的进度安排的图形化方法有甘特（Gantt）图和计划评审技术（PERT）图。**Gantt图：**用水平线段表示任务的工作阶段；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务所需的时间。
Gantt 图也有 3 个主要缺点：
（1）不能显式地描绘各项作业彼此间的依赖关系。
（2）进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象。
（3）计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。
5.工程网络
当把一个工程项目分解成许多子任务，并且它们彼此间的依赖关系又比较复杂时，仅仅用 Gantt 图作为安排进度的工具是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。
工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖关系。因此，工程网络是系统分析和系统设计的强有力的工具。
在工程网络中用箭头表示作业 （例如，刮旧漆，刷新漆，清理等），用圆圈表示事件 （一项作业开始或结束）。++注意，事件仅仅是可以明确定义的时间点，它并不消耗时间和资源。++作业通常既消耗资源又需要持续一定时间。
图中表示刮第 1 面墙上旧漆的作业开始于事件 1，结束于事件 2。用开始事件和结束事件的编号标识一个作业，因此"刮第 1 面墙上旧漆"是作业 1---2。在工程网络中的一个事件，如果既有箭头进入又有箭头离开，则它既是某些作业的结束又是另一些作业的开始。例如，事件2既是作业1---2（刮第1面墙上的旧漆）的结束，又是作业2---3（刮第2面墙上旧漆）和作业2---4（给第1面墙刷新漆）的开始。也就是说，只有第1面墙上的旧漆刮完之后，才能开始刮第2面墙上旧漆和给第1面墙刷新漆这两个作业。因此，工程网络显式地表示了作业之间的依赖关系。
虚线箭头表示虚拟作业，也就是事实上并不存在的作业。引入虚拟作业是为了显式地表示作业之间的依赖关系。例如，事件4既是给第1面墙刷新漆结束，又是给第2面墙刷新漆开始（作业4---6）。但是，在开始给第2面墙刷新漆之前，不仅必须已经给第1面墙刷完了新漆，而且第2面墙上的旧漆也必须已经刮净（事件3）。也就是说，在事件3和事件4之间有依赖关系，或者说在作业2---3（刮第2面墙上旧漆）和作业4---6（给第2面墙刷新漆）之间有依赖关系，虚拟作业3---4明确地表示了这种依赖关系。（先2---3，后4---6）
注意，虚拟作业既不消耗资源也不需要时间。
估算工程进度：画出工程网络之后，系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。 首先，把每个作业估计需要使用的时间写在表示该项作业的箭头上方。注意，箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间。 其次，为每个事件计算下述两个统计数字：最早时刻EET和最迟时刻LET。
事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。
计算最早时刻EET使用下述3条简单规则：
（1）考虑进入 该事件的所有作业 （包括虚作业）
（2）对于每个作业都计算它的持续时间与起始事件的 EET 之和
（3）选取上述和数中的最大值作为该事件的最早时刻 EET
事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。按照惯例，最后一个事件（工程结束）的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。
计算最迟时刻LET使用下述3条规则：
（1）考虑离开 该事件的所有作业 （看该作业后面的箭头个数）
（2）从每个作业的结束事件的最迟时刻中减去该作业的持续时间
（3）选取上述差数中的最小值作为该事件的最迟时刻LET。
求EET： 事件2只有一个作业（作业1---2）进入，就是说，仅当作业1---2完成时 事件2才能发生，因此事件2的最早时刻就是作业1---2最早可能完成的时刻。定义事件1的最早时刻为零，据估计，作业1---2的持续时间为2小时，也就是说，作业1---2最早可能完成的时刻为2，因此，事件2的最早时刻为2。同样，只有一个作业（作业2---3）进入事件3，这个作业的持续时间为4小时，所以事件3的最早时刻为2+4=6。**事件4有两个作业（2---4和3---4）进入，**只有这两个作业都完成之后，事件4才能出现（事件4代表上述两个作业的结束）。已知事件2的最早时刻为2，作业2---4的持续时间为3小时；事件3的最早时刻为6，作业3---4（这是一个虚拟作业）的持续时间为0，按照上述3条规则，可以算出事件4的最早时刻为max{5，6}=6
按照这种方法，不难沿着工程网络从左至右顺序算出每个事件的最早时刻，计算结果标在图1中（每个圆圈内右上角的数字）。
**求LET：**事件11的最迟时刻和最早时刻相同，都是23。逆作业流方向接下来应该计算事件10的最迟时刻，离开这个事件的只有作业10---11，该作业的持续时间为2小时，它的结束事件（事件11）的LET为23，因此，事件10的最迟时刻为 23 - 2 = 21。 类似地，事件9的最迟时刻为 20，事件8的最迟时刻为 min{21 - 6, 20 - 0} = 15 ，图中每个圆圈内右下角的数字就是该事件的最迟时刻。
【关键路径】图中有几个事件的最早时刻和最迟时刻相同 ，这些事件定义了关键路径，在图中关键路径用粗线箭头表示。关键路径上的事件（关键事件）必须准时发生 ，组成关键路径的作业（关键作业）的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。 工程项目的管理人员应该密切注视关键作业的进展情况，如果关键事件出现的时间比预计的时间晚，则会使最终完成项目的时间拖后；如果希望缩短工期，只有往关键作业中增加资源才会有效果。
【机动时间】不在关键路径上的作业有一定程度的机动余地------实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。一个作业可以有的全部机动时间等于它的结束事件的最迟时刻 减去它的开始事件的最早时刻 ，再减去这个作业的持续时间：
机动时间 = 结束的LET - 开始的EET - 持续时间
工程网络中每个作业的机动时间写在代表该项作业的箭头下面的括号里。 在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。图中清理前三面墙窗户的作业都有相当多机动时间，也就是说，这些作业可以晚些开始或者持续时间长一些（少用一些资源），并不影响竣工时间。此外，刮第3、第4面墙上旧漆和给第1面墙刷新漆的作业也都有机动时间，而且这后三项作业的机动时间之和大于清理前三面墙窗户需要用的工作时间。因此，有可能仅用10名工人在同样时间内（23小时）完成旧木板房刷漆工程。
6.软件项目的组织
通过软件项目的组织，尽早落实责任，减少交流障碍，责权明确。可按软件项目对人员分组：需求分析组、设计组、编码组、测试组、维护组、质量保证组等。现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和喜好。
民主制程序员组：民主制程序员组的一个重要特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。因此，小组成员之间的通信是平行的，如果小组内有 n 个成员，则可能的通信信道共有 n(n-1)/2 条。 一般说来，程序设计小组的规模应该比较小，以2～8名成员为宜。如果项目规模很大，用一个小组不能在预定时间内完成开发任务，则应该使用多个程序设计小组，每个小组承担工程项目的一部分任务，在一定程度上独立自主地完成各自的任务。
主程序员组：采用这种组织方式主要出于下述几点考虑：
（1）软件开发人员多数比较缺乏经验
（2）程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新
（3）多渠道通信很费时间，将降低程序员的生产率。 主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。
这种组织方式类似于外科手术小组的组织：主刀大夫对手术全面负责，并且完成制订手术方案、开刀等关键工作，同时又有麻醉师、护士长等技术熟练的专门人员协助和配合他的工作。此外，必要时手术组还要请其他领域的专家（例如，心脏科医生或妇产科医生）协助。
现代程序员组：实际的 "主程序员" 应该由两个人共同担任：一个技术负责人，负责小组的技术活动；一个行政负责人，负责所有非技术性事务的管理决策。技术组长自然要参与全部代码审查工作，因为他要对代码的各方面质量负责；相反，行政组长不可以参与代码审查工作，因为他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工作业绩。
7.软件质量管理
为保证软件系统或产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的软件。软件必须满足用户规定的需求；软件应遵循规定标准所定义的一系列开发准则。
**1. 软件质量保证：**软件必须满足用户规定的需求；软件应遵循规定标准所定义的一系列开发准则；软件还应该满足某些隐含需求。软件质量保证包括以下7个主要活动：采用的技术方法和工具、进行正式的技术评审、测试软件、标准的实施、控制变更、技术与管理上的度量、记录和保存报告。
2. 软件评审：（1）设计质量的评审： 总体设计思想与设计方针、需求规格说明、概要设计；保密措施、操作特性、性能的实施情况；可靠性、修改性、可移植性、可扩充性、可测试性、复用性。 **（2）程序质量的评审：**功能结构、模块结构、处理过程结构。
3. 软件容错技术： 提高软件质量和可靠性的技术可分两类：一是避开错误；二是容错技术 。 **容错：**在一定程度上，对自身错误的作用具有屏蔽能力，能从错误状态自动恢复到正常状态，即使在发生错误时仍然能在一定程度上完成预期的功能。**实现容错的主要手段是冗余。**冗余是指对于实现系统规定功能是多余的那部分资源，包括硬件、软件、信息和时间。由于加入了这些资源，有可能使系统的可靠性得到较大的提高。
8.软件配置管理（SCM）
软件配置管理（SCM）的主要目标是标识变更、控制变更， 确保变更正确地实现、报告有关变更。比如配置数据库可以分为以下三类：开发库、受控库、产品库。
2）软件评审
软件评审是在软件的生命周期内所实施的对软件本身的评审，是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。
**软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。**因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致我们开发结果不可控。
1.评审目标
发现任何形式表现的软件功能、逻辑或实现方面的错误
通过评审验证软件的需求
保证软件按预先定义的标准表示
已获得的软件是以统一的方式开发的
使项目更容易管理
2.评审过程
- 召开评审会议：一般应有公司评审委员会组织，会前每个参加者做好准备
**2. 会议结束后必需有结果性东西：**接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品
- 评审报告与记录：所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告
3.评审的内容
1. 计划的评审： 主要是关注的核心在于估计是否准确 ；人员安排是否合理；以上两个方面如果合理，项目的进度就不会出很大的问题
2. 需求的评审： 主要关注需求来源、需求的准确性、需求的完整性避免产生二义性；最好让测试人员和客户参加，以便让各角色达成共识
3. 总体设计的评审： 总体设计评审中，最好将已经评审通过的需求文档从配置管理库中提出，对照总体设计是否和需求一致；另外，技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性
4. 代码评审： 项目组内进行代码审核，主要关注代码的格式、整体逻辑、变量的命名、程序注释等表面的属性，至于运行质量应当放在单元测试中解决
5. 管理性的评审： 管理性的评审一般放在里程碑、项目结束后进行。准备的资料包括前期工作的总结，是否按照计划执行、出现的问题的数目、解决了多少、未解决的问题是否对后期有影响等。
4.评审的组织与管理
1. 内部评审： 内部评审是由承办方组织的评审
**2. 外部评审：**外部评审是由交办方组织的评审，特殊情况下，交办方可委托其他单位代理组织外部评审。
二.系统分析
1）系统分析
系统分析是指把要解决的问题作为一个系统，对系统要素进行综合分析，找出解决问题的可行方案的方法。
1.系统分析的主要任务
系统分析的主要任务是将在系统详细调查中所得到的文档资料集中到一起，对组织内部整体管理状况和信息处理过程进行分析。它侧重于从业务全过程的角度进行分析。
分析的主要内容是：
①业务和数据的流程是否通畅，是否合理；
②数据、业务过程和实现管理功能之间的关系；
③老系统管理模式改革和新系统管理方法的实现是否具有可行性等等。
2.系统分析的目的
系统分析的目的是将用户的需求及其解决方法确定下来，这些需要确定的结果包括：
①开发者关于现有组织管理状况的了解；
②用户对信息系统功能的需求；
③数据和业务流程；
④管理功能和管理数据指标体系；
⑤新系统拟改动和新增的管理模型等。
系统分析所确定的内容是今后系统设计、系统实现的基础。
3.系统分析的原则
1. 统一性原则： 按照国家税务总局的出口退税的法规政策，兼顾各地业务处理的特殊性，制定统一的出口退税业务规范
2. 适用性原则： 系统提供灵活的设置，保证各地在不违反基本退税流程规范的前提下，适应其手段和操作方法的不同。另外，本系统应是一个不断提高完善的系统，系统要能够进行不断的发展，同时能最大限度地适应未来的业务发展的需要
3. 易用性原则： 本系统使用人员范围广，使用人员的计算机水平层次不一，有的基层单位计算机使用水平较低，很多地方缺少计算机专业人员，系统应尽可能的操作简便，维护简单。 4. 可靠性原则： 由于操作失误出现的故障，重新使用时，系统应有自举功能，一时的设备故障，系统应可进行恢复，不破坏数据的一致性和完整性
5. 安全性原则： 系统的用户根据业务的需要，具有不同的安全级别及操作权限，系统要充分发挥操作系统、数据库、应用软件三层安全保证措施，以保证数据的安全性。系统内部重要业务操作均留有痕迹
6. 健壮性原则： 本系统接受大量的外部数据，系统应对错误的数据和结构，不合理的数据进行识别，拒绝接受错误数据和结构不合理数据
7. 易二次开发、易维护性原则： 采用封装技巧，建立稳定的底层工具，核心技术文档随系统发布等手段，使具有基本技术水平的系统维护人员可以在一定程度上对系统进行较复杂的维护及一般性扩充。
4.系统分析的主要工作步骤
对当前系统进行详细调查，收集数据
建立当前系统的逻辑模型
对现状进行分析，提出改进意见和新系统应达到的目标
建立新系统的逻辑模型
编写系统方案说明书
2）结构化分析方法
结构化分析方法（StructuredAnalysis，SA） 是面向数据流的需求分析方法，适用于分析大型数据处理。
采用自顶向下、逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。SA方法的分析结果由以下几部分组成： 一套分层的数据流图、一本数据词典、一组小说明和补充材料。
1.数据流图
**数据流图（Data Flow Diagram，DFD）**用来描述数据流从输入到输出的变换流程。它以图形的方式描绘数据在系统中流动和处理的过程，它只反映系统必须完成的逻辑功能，所以是一种功能模型。
（1）数据流：由一组固定成分的数据组成，表示数据的流向
（2）加工：描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流
（3）数据存储：用来表示暂时存储的数据，每个数据存储都有一个名字
（4）外部实体：是指存在于软件系统之外的人员或组织。
2.数据字典
数据流图仅描述了系统的"分解"，但没有对图中各成分进行说明。
数据字典就是用来定义数据流图中的各个成分的含义的。
数据字典有4类条目，包括数据流、数据项、数据存储和基本加工
3.加工逻辑的描述
用来说明DFD中的数据加工的加工细节，表达"做什么"，而不是"怎样做"。
描述工具有结构化语言、判定表和判定树。
三.系统设计
1）软件设计的内容
1.概要设计
概要设计的基本任务：
（1）设计软件系统总体结构：采用某种设计方法，将一个复杂的系统按功能划分模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口；评价模块结构的质量
（2）数据结构及数据库设计，数据结构的设计：细化数据的结构特性，包括数据组成、操作约束、数据之间的关系
（3）数据库的设计
（4）编写概要设计文档，概要设计说明书、数据库设计说明书、用户手册以及修订测试计划（5）评审
2.详细设计
详细设计的基本任务：
（1）对每个模块进行详细的算法设计
（2）对模块内的数据结构进行设计
（3）对数据库进行物理设计
（4）其他设计。比如代码设计、用户界面设计、输入输出格式设计
（5）编写详细设计说明书
（6）评审
2）软件设计的基本原则
软件设计时需要遵循抽象、模块化、信息隐蔽和模块独立原则。
在划分软件系统模块时，应尽量做到高内聚低耦合。
1.模块化
将一个待开发的软件分解成若干个小的简单的部分------模块，每个模块可独立地开发、测试，最后组装成完整的程序。
这是一种复杂问题"分而治之"的原则，模块化的目的是使程序的结构清晰，容易阅读，容易理解，容易测试，容易修改。
2.抽象化
一种设计技术，抽出事物本质的共同特性而暂不考虑它的细节。
3.信息隐蔽
将每个程序的成分隐蔽或封装在一个单一的设计模块中，定义每一个模块时尽可能少地显露其内部的处理，可以提高软件的可修改性、可测试性和可移植性。
4.模块独立
每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简单。衡量度量标准有两个：模块间的耦合和模块的内聚度。模块独立性强必须做到**高内聚低耦合**。
一般模块之间可能的连接方式有七种，构成耦合性的七种类型。
它们之间的关系为**（独立性由强到弱，耦合性越来越强）** ：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。
3）面向对象分析与设计
（1）对象： 一组属性以及这组属性上的专用操作的封装体，通常由对象名、属性和操作这3个部分组成
**（2）类：**一组具有相同属性和相同操作的对象的集合。一个类中的每个对象都是这个类的一个实例（Instance）
（3）继承： 在某个类的层次关联中不同的类共享属性和操作的一种机制。一个父类可以有多个子类，这些子类都是父类的特例。父类描述了这些子类的公共属性的操作，子类中还可以定义它自己的属性和操作，可以定义和被继承类相同方法名称的方法，构成方法的重载或覆盖。
一个子类只有唯一的一个父类，这种继承称为单一继承。
一个子类有多个父类，可以从多个父类中继承特性，这种继承称为多重继承。
（4）消息： 对象间通信的手段、一个对象通过向另一对象发送消息来请求其服务。消息只告诉接收对象需要完成什么操作，但并不能指示接收者怎样完成操作。消息完全由接收者解释，接收者独立决定采用什么方法来完成所需的操作
**（5）多态性：**同一个操作作用不同的对象可以有不同的解释，产生不同的执行结果
（6）继承性是 面向对象程序设计语言不同于其他语言的主要特点，是否建立了丰富的类库是衡量一个面向对象程序设计语言成熟与否的重要标志之一
（7）在面向对象的软件工程中，一个组件（component）包含了一些协作的类的集合。
四.系统架构
当前，管理信息系统主要有三种典型技术架构：
（1）C/S 架构（Client/Server：客户/服务器架构）
（2）B/S 架构（Browser/Server：浏览器/服务器架构）
（3）混合架构
1）C/S架构
1.两层C/S架构
由客户机、数据库服务器两层构成。其特点是客户端计算机（即客户机）要安装特定的客户端软件，业界称这种客户机为"胖客户机"或"胖客户端"，服务器指数据库服务器，其上运行数据库管理系统并驻留数据库。
工作原理： 在两层C/S架构中，用户界面由客户端提供 ，客户端软件通过与服务器上的DBMS通信取得数据库中的数据显示在用户界面上，或将用户输入的数据传递回服务器存于数据库中。数据库服务器负责数据存储和数据操纵。 业务逻辑 （比如计算某笔订单的金额总计）可能由客户端 （由客户端软件）处理，也可能由数据库服务器 （由数据库中的程序比如存储过程）处理。
比如，可能由数据库服务器先算出订单金额总计，再将总计返回给客户端显示出来，也可能数据库服务器只是把订单所订的各项产品的数量、单价数据返回客户端，由客户端程序自行计算订单总计。
两层C/S架构系统存在的问题： 两层C/S架构的系统中，由于处理业务逻辑的程序代码分散在客户端和数据服务器中，没有实现集中管理，这就产生一些问题。比如：
**①难以重用和共享业务逻辑代码，**特别是难以重用和共享分散在客户端的业务逻辑代码；
②数据库服务器承担的负荷较高，可能导致性能降低；
**③程序修改困难，**缺乏灵活性。
2.三层 C/S 架构
三层 C/S 架构系统：由客户机、应用服务器、数据库服务器三层构成（也称之为表示层、业务逻辑层、数据层）。 三层 C/S 架构的客户端计算机（即客户机）也要安装特定的客户端软件，也是"胖客户机"或"胖客户端"，三层 C/S 架构系统也需要数据库服务器，但相对于两层 C/S 架构多了一个应用服务器层 ，大多数业务逻辑代码以业务组件或 Web 服务（Web Service）的形式驻留于应用服务器上。 业务组件和 Web 服务是一种程序，它们实现业务逻辑，可以被不同的程序调用，从而实现业务逻辑的共享和重用。
3.三层 C/S 架构的特点
**1.业务逻辑代码以组件的形式集中存放在应用服务器中，**实现了业务逻辑的集中维护，业务逻辑可以非常方便地被不同的程序重用和共享。 由于数据库服务器不再处理业务逻辑（或处理得较少），降低了负荷。
现在，计算负荷被数据库服务器和应用服务器所分担，提高了系统性能。
2.由于业务逻辑和显示界面（显示逻辑）分离 ，使得业务逻辑的修改和显示逻辑的修改不会互相干扰，方便了程序修改，提高了程序灵活性。
三层 C/S 架构系统工作原理举例：①若客户端 （实际是客户端软件）要显示某笔订单的金额总计，它首先向应用服务器（实际是向应用服务器中的某个业务组件）发出获取订单金额的要求。
②应用服务器再向数据库服务器（实际是数据库管理系统）请求获取该订单所订产品数据。
③数据库管理系统 从数据库中找到这些产品数据后（包括单价、数量）返回给应用服务器。
④应用服务器 （实际是应用服务器中的某个业务组件）执行计算订单总额的业务逻辑，算出订单总额后发回给客户端。
⑤客户端 软件就可以将总额信息显示在界面上供用户查看。
2） B/S架构
随着 Internet 技术的普及，在传统的 C/S 架构之外，业界又发展出一种新的系统技术架构，即 B/S 架构，其最主要的特点是客户机无需安装特定的客户端软件 ，只需要浏览器就可以（一般操作系统都预装了浏览器）。
所以，这种客户端被称为**"瘦客户机"或"瘦客户端"**。B/S 架构的系统又可以分为三层和四层两种常见的形式。
1.三层 B/S 架构
由客户机、Web 服务器、数据库服务器三层构成 。 在这种结构中，用户开发的系统分成两部分，一部分是数据库 ，部署在数据库服务器上，另一部分是 Web 服务器端程序（其形式可能是 ASP 页、JSP 页、PHP 页、ASPX 页等）或静态 HTML 页，部署在 Web 服务器上，置于 Web 服务器软件的管理之下。
工作原理： Web 服务器 （实际是 Web 服务器软件）接受客户端 （这里是浏览器）的 http 请求 ，调用 Web 服务器端程序，这些程序可能会向数据库服务器发 出数据请求，获得数据后，可能执行一些业务逻辑 ，然后将数据以一定的格式动态生成一个 html 格式的页面 （这就是用户界面）返回 Web 服务器软件，Web 服务器软件 再将该页面返回给**客户端浏览器，**供用户查看。（当然，如果浏览器客户端只是请求一个静态 html 页，Web 服务器就简单找到该页返回给浏览器，而无需和数据库服务器交互）
特点： 可以看出，这里界面逻辑（形成 html 页面）在 Web 服务器 处完成，而业务逻辑 可能在数据库服务器（由数据库中的程序比如存储过程）、也可能在 Web 服务器（由 Web 服务器端程序）处理，这种分散处理业务逻辑的缺点与两层 C/S 架构一样：①难以重用和共享业务逻辑代码。
②数据库服务器承担的负荷较高。
③程序修改困难，缺乏灵活性。
2.四层 B/S 架构
由客户机、Web 服务器、应用服务器、数据库服务器四层构成。
3.C/S 与 B/S 架构的比较
C/S 的缺点：
（1）C/S 架构的系统由于需要将客户端软件部署到每一台客户机**，部署麻烦**，部署成本高，特别是当用户数很多时，这个缺陷尤其明显
（2）C/S 架构的系统客户端程序要升级更新时，需要更新每一台客户机，更新麻烦，升级更新的成本高。
（3）C/S 架构的系统管理和维护客户端的成本也较高。比如，客户机若感染了病毒或出现了其它故障，导致客户端软件损坏，就需要重新安装客户端软件。
B/S 架构的优点：（1）系统都安装在各种服务器上，客户端是零部署，无需安装客户端软件
（2）系统升级更新也都发生在服务器端，不影响客户端
（3）B/S 架构的系统无需管理和维护特定的客户端软件。
B/S 架构的缺点：（1）用户界面的响应速度 通常不比如 C/S 架构的系统。因为应用程序的大部分逻辑和状态位于服务器上，所以瘦客户端会频繁地向服务器发送处理请求，然后必须等待响应到达，用户才能继续使用该应用程序，这使得应用程序的响应速度通常要比胖客户端应用程序（C/S 架构）慢 ，因此，B/S 架构不太适合用户交互很多的情况，不适合需要频繁输入大量数据的情况，也不适合需要在多个窗口频繁导航的情况。
（2）B/S 架构**难以实现一些常用的应用程序功能。**比如拖放、撤消------重复以及上下文相关帮助等，而 C/S 架构则很容易实现这些功能。
（3）B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理能力
（4）B/S体系结构的系统扩展能力差 ，安全性难以控制
（5）B/S体系结构的数据提交一般以页面为单位 ，数据的动态交互性不强，不利于在线事务处理（OLTP）应用。
五.三层架构与 MVC
1）三层架构
三层架构是指在业务和技术的发展过程中，系统中不同职责的部分被定义在不同的层次，每一层负责的功能更加具体化。 三层架构通常包括表示层、业务逻辑层和数据访问层，层与层之间互相连接、互相协作，构成一个整体，并且层的内部可以被替换成其他可以工作的部分，但对整体的影响不大。
区分层次的目的即为了"高内聚低耦合"的思想。
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。
以 Web 应用程序为例：
1.早期 是将所有的表示逻辑、业务逻辑和数据访问逻辑放在一起，这就是一层架构。
2.后来 随着 java、.NET 等高级语言的发展，提供了越来越方便的数据访问机制，比如 java 的 JDBC 和 .NET 的 ADO.NET。这时数据访问部分被分离开来，形成了二层架构。
3.再后来，随着面向对象设计、企业架构模式等理念的不断发展，表示逻辑和业务逻辑也被分离开来，形成了现在的三层架构。
三层架构的具体内容如下：**1.表示层（界面层）：**用户使用应用程序时，看到的、听见的、输入的或者交互的部分。
**2.业务逻辑层：**根据用户输入的信息，进行逻辑计算或者业务处理的部分。
3.数据访问层： 关注有效地操作原始数据的部分，比如将数据存储到存储介质（比如数据库、文件系统）及从存储介质中读取数据等。
虽然程序被分成了三层，但只是逻辑上的分层 ，并不是物理上的分层。也就是说，对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。
2）MVC架构
MVC全名是Model View Controller ，是模型（model）---视图（view）---控制器（controller）的缩写 ，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面 ，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
三层架构和 MVC 的区别： MVC（模型 Model--视图 View--控制器 Controller）是一种架构模式，可以用它来创建在域对象和 UI 表示层对象之间的区分。
同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。
1.在三层架构中没有定义 Controller 的概念，这是最不同的地方。
2.而 MVC 也没有把业务的逻辑访问看成两个层，这是采用三层架构或 MVC 搭建程序最主要的区别。
3. 当然了，在三层中也提到了 Model，但是三层架构中 Model 的概念与 MVC 中 Model 的概念是不一样的，"三层"中典型的 Model 层是由业务逻辑与访问数据组成的。而 MVC 里，则是以实体类构成的。
M 即 Model（模型层）， 主要负责处理业务逻辑 以及数据库的交互。V 即 View（视图层）， 主要负责显示数据和提交数据。
C 即 Controller（控制层）， 主要是永作辅助捕获请求并控制请求转发。
三层：UI 界面层、BLL 业务逻辑层、DAL 数据访问层。（1）三层是基于业务逻辑来分的，而 MVC 是基于页面来分的。
（2）MVC 模式是一种复合设计模式，一种解决方案。
（3）三层是种软件架构，通过接口实现编程。
（4）三层模式是体系结构模式，MVC 是设计模式。
（5）三层模式又可归于部署模式，MVC 可归于表示模式。