软件设计与体系结构期末复习

第 1 章

软件设计的能力要求

软件作为数字经济的核心产业，正在引领社会进行快速变革。程序员作为软件这一新兴

产业的技术工人受到社会的广泛关注。与传统产业工人相比，程序员从事的任务更加具有创

造性和复杂性。当前，为了建设与传统产业类似的软件生产流水线达到高效率完成软件开发

任务的目标，软件开发任务正在被不断细分。这客观上要求软件开发团队成员必须拥有与自

己岗位匹配的专业技能，通过分工和协作完成软件开发任务。本章就带领大家了解程序员的

职业成长之路以及与软件设计类岗位匹配的能力要求。

1.1 程序员的职业成长

1.1.1

软件从业人员岗位分类

很多同学在入行之前，实际上处于一个懵懵懂懂的状态。看到别人做 Java ，自己也去

做 Java 。看到别人说 PHP 是世界最好的语言，于是自己也投 PHP 职位的简历。这样是不行

的，可能浪费几年时间之后才发现这个职位不适合自己，到时候回头就比较晚了。那么，软

件从业人员的岗位有哪些呢？

1. 岗位名称：项目经理

岗位类型：管理

岗位职责描述：

(1) 完成项目的整体组织与实施，协调与控制；

(2) 对项目的各种风险进行评估，制定相应规避和控制措施；

(3) 制定项目的主体计划和各类子计划（时间规划、成本规划、资源规划、测试规划）

等；

(4) 实时掌握项目的各种计划执行情况，控制项目的进度，分析、解决项目中的各种问

题；

(5) 组织、实施对项目的各阶段成果物进行评审；

(6) 组织项目各个阶段会议、客户沟通会议、技术会议、评审会议等；

(7) 保持和客户的需求沟通、商务沟通，处理和解决与客户之间各种分歧；

(8) 保持组织内的上下级之间的沟通，及时向项目干系人通报项目的进展情况、风险状

况、当前课题等；

(9) 组织本项目课题的预研、项目业务、技术的培训等；

(10)对项目中的各种资源（人员、软件等）进行管理。

2.

岗位名称：需求分析师

岗位类型：业务

岗位职责描述：

(1) 负责对客户需求进行调研及分析，能够与客户迅速建立沟通；

(2) 获取用户的目的、想法，将业务需求转化为软件系统需求，编写以准确逻辑分析

为基础的详细需求规格说明书；

(3) 协助项目经理、系统架构师、系统分析师.开发人员理解需求；

(4) 系统规划，与产品人员进行前期调研和产品设计工作，编写调研报告和项目解决

方案；

(5) 配合测试人员完成测试计划.测试用例.测试报告的编写；

(6) 能熟练使用 Axure/Viio/Word/Excel/PPT/Xmind 等软件编写需求分析文档及设计

界面原型、画流程图等；

(7) 系统知识库体系的积淀与整理，最佳实践的总结与分析，组织培训等。

3.

岗位名称：设计工程师

岗位类型：设计

岗位职责描述：

(1) 负责系统架构的整体规划；

(2) 对开发模型、开发方法、开发平台、数据组织结构等进行决策；

(3) 对系统的运行环境、软件、数据库支持等进行规划决策；

(4) 对系统的子系统/模块划分，功能设计、接口设计、网络结构、数据库等进行决

策；

(5) 对系统的进程、并发、异常处理等运行期属性进行决策；

(6) 对系统的用户交互、客户满意度等属性进行决策；

(7) 对系统的可扩展性、可维护性、安全性、健壮性等质量属性进行决策；

(8) 负责系统的功能设计；

(9) 对程序员进行功能设计的说明和培训；

(10)对程序员开发中进行技术指导；

(11)对开发模型、开发方法、开发平台、数据组织结构等进行决策；

(12)对系统的运行环境、软件、数据库支持等进行规划决策；

(13)对系统的子系统/模块划分，功能设计、接口设计、网络结构、数据库等进行决

策，

(14)对每个模块进行算法设计，用某种图形等形式将每个模块的详细算法描述出来；

(15)负责系统详细设计 ⽅ 案和具体设计的制定、审核；

(16)对软件详细设计方案和相关技术文档进行撰写。

4.

岗位名称：数据库工程师

岗位类型：设计/开发

岗位职责描述：

(1) 数据库的日常管理维护，包括数据库的备份、恢复、数据整理、日志分析、解决

突发和疑难问题；

(2) 数据库性能分析及其优化，及时发现需要改进的数据库查询及其其他执行代码；

(3) 进行数据库的安装与部署，保证符合数据库安装部署的合理性、高效性； 3

(4) 进行数据库设计，数据库对象的开发，指导并审查开发人员业务数据层（DAO、数

据连接、连接池、事务处理等）的构建工作；

(5) 负责有关数据库技术文档的编写、数据库技术预研、数据库技术培训；

(6) 协助软件工程师进行数据库产品选型、采购决策等。

(7) 协助项目经理完成项目的配置管理工作。

(8) 参加设计类、数据库操作类培训。

5.

岗位名称：开发工程师

岗位类型：开发

岗位职责描述：

(1) 根据系统设计的要求进行系统功能的编码、代码 review 等；

(2) 负责系统的单体测试工作，参与系统的集成测试、系统测试、验收测试；

(3) 系统用户手册、安装运行手册等开发文档的编写；

(4) 经常了解用户的意见和需求，不断完善软件功能，达到用户满意；

(5) 定期参加部门和项目组织的人员培训；

(6) 协助项目经理进行项目小组的管理（制作小组工作计划、进行进度控制、工作评

审等）；（中高级程序员职责）；

(7) 参加研发类培训。

6.

岗位名称：测试工程师

岗位类型：测试

岗位职责描述：

(1) 负责对系统进行测试内容的整体规划；

(2) 依据项目主体计划，制定测试详细计划；

(3) 编写有效的系统测试用例并执行测试；

(4) 负责进行测试数据准备、测试环境搭建、测试结果的分析、评审等；

(5) 指导开发/测试人员进行项目的单体测试、集成测试、系统测试工作；

(6) 安装、部署、维护测试工具。

(7) 对测试团队成员进行测试理论知识、测试技能、测试工具的培训；

(8) 参加测试类培训。

7.

岗位名称：培训专员

岗位类型：支持

岗位职责描述：

(1) 负责公司内部新员工入职培训；

(2) 整理、汇总、归档各类培训资料，协助编制培训教材；

(3) 组织实施培训需求调查，制订年/季/月度培训计划；

(4) 组织实施培训，跟踪培训效果反馈，并建立和完善培训档案；

(5) 发掘公司内部培训资源，协助上级领导建立内部培训讲师队伍；

(6) 协调与外部培训供应商间的关系，维护培训渠道和培训资源。 4

1.1.2

程序员的进阶之路

对于程序员来说，刚入行的话，可能对这个行业还没那么熟悉，这个阶段建议先关注如

何写出好代码，学习别人的设计思路，重视规范和流程，并注重培养好的工作习惯。等工作

几年对这个领域有一定的理解后，就必须考虑长远的职业规划。

1.对于程序员职业路线规划，给出一个参考，如图 1.1 所示，定义为四个阶段：

(1) 20 岁——30 岁

在 25-30 岁之间，从入行开始就是埋头苦干。主要心思就是要专注于不断提升自己的

技术能力和学习能力，自身技术能力体系的构建与成熟是这个阶段的关键。这个阶段的优势

在于人生是最富有冲劲的，对于技术的新鲜感也是最佳的，因此非常适合学习新技术，不断

在开发当中，解决各种技术问题。在这一阶段，有一些程序员就会在项目管理、产品设计或

者团队协调上表现出超越其他人的潜质，这就具有了一定的复合能力。

(2) 30 岁——35 岁

过了 30 岁以后，作为程序员若还对技术不断地钻研，那么基本上就进入到高级程序员

这个层面。对于任何一家软件企业，高程都是不可或缺的资源。随着软件应用的规模化和企

业复杂的领域问题，程序员不仅在技术能力上要有更高的追求，技术之外的一些能力需要适

时地培养。这个阶段程序员要特别注意：客户关系与沟通、技术文档方案与商业活动支持、

需求业务上的深度理解等方面的锻炼和提升。而且这种复合能力也会越来越重要。

(3) 35 岁——40 岁

继续沿着主线走，程序员到了 35～40 岁之间，几乎都要面临一个问题，如何转型？尤

其在国内的技术环境，这个过程可以说是必经之路。其实转型的选择也很简单：技术线、管

理线、创业和其他。

(4) 40 岁以后

这个阶段，如果你还在主线上，更适合自己出来创业，但也不是绝对的，即便留在企

业，也可以形成一种独特的合作方式，可将其称为合作创业，也就是企业与你之间是一种默

契的合作关系，你中我有，我中有你，关键在于你有相对自由的时间，既能达到自己的目

标，还能照顾到企业的发展，这种模式对于技术人员是最好的一种方式。 2.作为程序员，在开发岗位上做了几年，特别是 30 多岁，就要为转型做准备。既然有

了选择，就会有人纠结，不知道如何抉择。为了解决这个问题，有必要分析程序员职业的发

展方向到底有哪些，分别需要具备怎样的能力。图 1.2 给出程序员的职业发展方向。

(1) 技术

技术线上，有两个方向：架构师和技术专家。

架构师他的侧重点是在“广”上，他主要负责技术的整体和架构，在业务上，需要有

很深的理解，有丰富的经验。在技术上，能够广泛涉略，掌握更多的技术知识。其次，架构

师还需要三点必备能力：其一，需要有极强的执行力，能够快速的给出合理的方案，推动技

术落地；其二，需要有极强的判断力，能够准确的找到复杂系统的疑难问题所在；最后，还

需要有极强的创新力，能够创造新的解决方案，解决现有技术难题。

技术专家他的侧重点是在“专”上，这个就很好理解，就是在某个领域能够深入，能

够熟悉其背后运行原理。所以从高级开发成长为技术专家，主要是扩展领域内的技术宽度，

提升领域内的技术深度。因为领域也不是特别窄的一个面，而是包含多个技术面。在每个技

术面中，同样包含了很多技术点，这些技术都是知识盲区，所以需要提升技术深度。

(2) 管理

管理也分为了两个方向，技术管理和职业管理。顾名思义，技术管理更加倾向于技

术，而职业管理完全抛开了技术，纯粹的商业方向。

技术管理，这个方向是程序员最自然的选择。然后走上慢慢进阶的路线，从技术经理

岗到技术总监，然后到成为技术副总裁，相当于 CTO。技术管理需要在业务上有较深的理

解，在技术上能够根据技术发展趋势，进行技术规划。

职业管理，职业管理者往往更加关心于整体产品业务的团队，不限于技术团队。比如

某个事业部的总裁，或者是某个业务部的总裁。他的移动性更加强，能力更加通用。

(3) 创业

创业这个方向上，一般是作为技术合伙人来参与，如果想要自己的创业公司能够成

功，必须是全能型创业团队，在技术、产品、营销等方面不能有明显的短板。 创业是一个非

常艰辛的过程，要想创业成功，需要跨越很多障碍。

(4) 其他

其他，可以是转岗（如转产品、销售等），自由职业，转行等。

5 6

转产品经理，程序员转产品经理，需要做到技术思维到产品思维的转换。技术思维角

度是从功能开始，而产品思维的角度是从业务开始。从技术思维的角度关注一个需求时候，

总是先关注一个需求如何去实现，即 HOW；而从产品思维上来关注一个需求时候，应该多问

一下 WHY，为什么需要这个需求，多思考为什么，从而找到需求或问题的本质。

自由职业， 自由职业者或者叫小老板。很多程序员所谓的创业，其实不过是自由职业，

一个人搞定产品或者销售；即使有一个小团队，自己也是团队的顶梁柱。自由职业的风险和

收益都很高，如果你的产品和服务卖不出去，那你的生活会变得艰辛，但如果你的切入点正

确，而且具备相应的能力，那么年入百万也不多。

条条大路通罗马，找准自己的定位，选择适合自己的职业路线，持续努力和积累，人生

终将绽放光芒。

1.2 软件设计的能力要求

1.2.1

软件设计岗位分类

软件设计师包括软件设计工程师和软件架构工程师。

软件设计工程师应对系统结构所使用的软件技术非常了解，自身具备良好编程技巧，才

能成为优秀的软件设计工程师。软件设计工程师的职责是把结构模型对应到实现模型上，从

概念到实现期间规划和组合模型的优劣是决定软件设计工程师好坏的标准。

而软件架构师是程序员技术方向的最终归属，也是成长链中最神圣的一环。架构设计师

彻底摆脱了语言的束缚，知道软件发展趋势。他们会开发新一代产品或者制定新一代产品的

方案，软件架构设计是面向未来的。

1. 软件设计工程师

软件设计工程师是指能根据软件开发项目管理和软件工程的要求，按照系统总体设计

规格说明书进行软件设计，编写程序设计规格说明书等相应的文档的实用性人才。还能够组

织和指导程序员编写、调试程序，并对软件进行优化和集成测试，开发出符合系统总体设计

要求的高质量软件。

软件设计工程师的工作与软件开发工程师对比，区别在于编码模块的重点和难点方

面。软件设计工程师不仅仅要做编码工作，更要多与文档打交道。软件开发工程师更多的是

需要把设计实现。

软件设计师的工作，受到系统架构师的影响。当系统架构师决定了整个系统架构后，

软件设计师会试着实作一个系统原型。系统原型的目的，在于验证系统架构师提出的架构。

当架构过于复杂，或开发成本过高时，软件设计师必需要求系统架构师，修改提出的架构，

因为在实务上，由于成本、技术等关系，是无法在经济的状况下达成。

软件设计师，必需对软件技术十分专长，也必需对客户的需求有一定程度的了解。在

系统原型中，软件设计师会作多个程式范型(Program Pattern)，每个程式范型，对应到一

种客户需求的程式类型。系统原型开发成功后，后续的团队，就可以使用完成的程式范型，

快速地将客户的需求，转化为系统程式。

“软件设计师”的概念，它与电子、机械、建筑行业的设计师有着同样的职责，可以 7

只输出一种经过严格约束，并有着明显业务领域特色的设计说明与流程，而交给别人去实

现，达到了很高的软件生产效率。

2. 软件架构工程师

架构师(Architecture 是目前很多软件企业最急需的人才,也是一个软件企业中薪水最

高的技术人才。换句话说,架构师是企业的人力资本,与人力资源相比其能够通过架构、创新

使企业获得新的产品、新的市场和新的技术体系。那么什么是架构师？

软件架构工程师，通俗的说就是设计师或结构设计者，这些定义如果用在建筑学上，

则是很容易理解的。在软件工程领域中，软件架构师实际上就是软件项目的总体设计师，是

软件组织新产品的开发与集成、新技术体系的构建者。

小时候到河中玩耍,经常干的事就是造桥,步骤如下:1、在沙滩上画图;2、选择形状好

看、大小适合的石头;3、搭建拱桥。其中我们挑出来画图的那位小孩就是传说中的“架构

师”了。与建筑学类似,如果软件系统没有一个好的架构是不可能成为成功的软件系统的。

没有图纸的建筑工地、没有设计的造桥工程都是不可以想象的混乱世界。建筑工程如是,软

件工程中也是。

软件架构师在整个软件开发过程中都起着重要作用，并随着开发进程的推进而其职责

或关注点不断地变化。在需求阶段，软件架构师主要负责理解和管理非功能性系统需求，比

如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。此外，架构师还要经常

审查客户和市场人员所提出的需求，确认开发团队所提出的设计;在需求越来越明确后，架

构师的关注点开始转移到组织开发团队成员和开发过程的定义上;在软件设计阶段，架构师

负责对整个软件架构、关键构件、接口的设计。在编码阶段，架构师则成为程序员的顾问，

并且经常性地要举行一些技术研讨会、技术培训班等;随着软件开始测试、集成和交付，集

成和测试支持将成为软件架构师的工作重点;在软件维护开始时，软件架构师就要开始为下

一版本的产品是否应该增加新的功能模块进行决策。

综上所述，软件架构师的作用主要体现在三个方面：

(1)行业应用架构。行业架构师往往是行业专家，了解行业应用需求，其架构行为主要

是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局。

(2)应用系统技术体系架构。技术架构师往往是技术高手中的高手，掌握各类技术架

构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、

灵活性、跨平台性等。

(3)规范架构。规范架构师是通过多年磨砺或常年苦思顿悟后，把某一类架构抽象成一

套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范

和技术规范两类。

由于国内合格、胜任的软件架构师极为少见,直接导致了我国民族软件产业水平的落

后。在未来以信息产业为主导的社会,信息产业水平的低下将直接影响国家核心竞争力。

1.2.2

软件设计岗位的技术要求

软件产品的设计对于整个软件开发过程至关重要，而软件设计师的素质和技能更是决

定软件产品成败的关键。优秀的软件设计师需要具备哪些素质和技能，才能在激烈的市场竞

争中脱颖而出，成为一名优秀的软件设计师。

1.2.3

软件设计岗位的非技术要求

作为软件设计师，除了技术要求之外，还有一些非技术要求是非常重要的。

1.沟通能力和团队合作精神：设计师需要与项目经理、开发团队和业务部门进行有效

的沟通和协作，确保设计方案符合需求和目标。

2.解决问题的能力：需要创新思维，在面对复杂的技术挑战时能够提出合理的解决方

案。另外，软件设计岗位还要求设计师具备良好的分析能力和逻辑思维能力。他们需要能够

理解业务需求，并将其转化为可行的软件设计方案。同时，在设计过程中，他们需要进行系

统性的分析和评估，以确保设计的可扩展性、可维护性和安全性。

3.执行能力：确保和项目组内成员按时推进任务，保证项目的顺利执行。

4.持续学习和自我提升的意识：技术的发展日新月异，设计师需要不断跟进最新的软

件开发技术和行业趋势，保持自身的竞争力和适应能力。 1

第 2 章 软件开发生命周期中的软件设计

软件设计是软件开发任务中的一项重要内容。本章将在软件开发生命周期的全局视角下重新审视

软件设计的工作内容、工作流程及其相对应的工作文档，感悟软件设计工作的重要性。同时，从问题

建模的角度讲述软件开发生命周期及其常见模型，在实际的软件开发生命周期模型中思考软件设计任

务与其他任务之间的关系。

2.1 软件开发生命周期

2.1.1

软件开发生命周期

软件开发生命周期 (Software Development Life Cycle ， SDLC) 包含了软件从开始到结束的不同阶段。

它定义了一种用于提高待开发软件质量和效率的过程。因此， SDLC 旨在通过最少的资源，交付出高质

量的软件。

软件生命周期由软件定义、软件开发和运行维护 ( 也称为软件维护 ) 三个时期组成，每个时期又进一

步划分成若干个阶段。

软件定义时期的任务是 : 确定软件开发工程必须完成的总目标 ; 确定工程的可行性 ; 导出实现工程目

标应该采用的策略及系统必须完成的功能 ; 估计完成该项工程需要的资源和成本 , 并且制定工程进度表。

软件定义时期通常进一步划分成三个阶段，即问题定义、可行性研究和需求分析。

开发时期的主要任务是具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组成：

总体设计、详细设计、编码和单元测试、综合测试。其中前两个阶段又称为软件设计 , 后两个阶段又称

为软件实现。

维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误

时应该加以改正 ; 当环境改变时应该修改软件以适应新的环境 ; 当用户有新需求时应该及时改进软件以

满足用户的新需求。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩

和简化了的定义和开发过程。

2.1.2

软件开发生命周期阶段任务

下面简要介绍软件生命周期每个阶段的基本任务：

1.问题定义

问题定义阶段必须回答的关键问题是 : “要解决的问题是什么 ? ”，需求分析师通过对客户的访问调

查，写出关于问题性质、工程目标和工程规模的书面报告 , 经过讨论和必要的修改之后这份报告应该得

到客户的确认。

2.可行性研究

这个阶段要回答的关键问题是 : “对于上一个阶段所确定的问题有行得通的解决办法吗 ? ”为了回答

这个问题，需求分析师需要进行一次大大压缩和简化了的软件分析和设计过程，也就是在较抽象的高

层次上进行的软件分析和设计过程。可行性研究的结果是客户给出是否继续进行这项工程的重要依据，

一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去，项目经理判断及时终止

不值得投资的工程项目 , 可以避免更大的浪费。

3.需求分析

该阶段的任务不是具体的解决问题，而是准确地确定“软件系统必须做什么”，需求分析师确定软

件系统必须具备哪些功能。面向对象分析方法通常用领域模型分析，领域分析活动：定义被调查的领

域，相关的设计、规约、代码、政策、标准、规程等项，对领域中提取的项，划分种类并提取模式，

命名并且分层。分析得出系统用例图、领域模型等。这个阶段最后要生成用户确认的需求规格说明书，

来准确完整地体现用户的需求。

4.总体设计

这个阶段要回答的关键问题是 : “概括的说，应该怎样实现目标系统 ? ”，总体设计就是设计工程师

根据需求分析阶段确定的功能，设计软件系统的架构。在系统架构设计中，需要对系统的逻辑架构、

数据架构、开发架构、运行架构、和物理架构等方面进行设计。 2

5.详细设计

总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是设计工程

师把解法具体化，也就是回答下面这个关键问题 : “应该怎样具体地实现这个系统呢 ? ”这个阶段的任务

还不是编写程序，而是设计出程序的详细规格说明。要对每个类进行具体描述，包括属性和方法的详

细类图，还有对象序列图、对象通信图、对象状态图等。

6.编码和单元测试

该阶段把每个模块的控制结构转换成计算机可接受的程序代码，即开发工程师写成以某些特定设

计语言表示的“源程序”。

7 .综合测试

测试是保证软件质量的重要手段，其主要方式是测试工程师在设计测试用例的基础上检验软件的

各个组成部分。测试分为 : 单元测试、集成测试、系统测试、验收测试等。

8.软件维护

软件维护是软件生存周期中时间最长的阶段。已交付的软件投入正式使用后，便进入软件维护阶

段，它可以持续几年甚至几十年。

2.2 软件开发生命周期模型

模型是对生命周期各阶段的一个建模，以便高效率、高质量完成软件开发任务，主要研究各阶段

以及各任务之间的关系。下面介绍两种典型的生命周期模型包括瀑布模型和敏捷模型。

2.2.1

瀑布模型

瀑布模型（ Waterfall Model ） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，

从问题定义、可行性研究、需求分析开始，直到软件测试和维护，每个阶段都会产生循环反馈，因此，

如果有信息未被覆盖或者发现了问题，那么最好 “ 返回 ” 上一个阶段并进行适当的修改，项目开发进程

从一个阶段 “ 流动 ” 到下一个阶段，这也是瀑布模型名称的由来。瀑布模型将软件开发任务分成软件定

义阶段、软件开发阶段、软件维护阶段。其中，软件设计瀑布模型如图 2.1 所示。

瀑布模型的优点：

1 ）为项目提供了按阶段划分的检查点。

2 ）当前一阶段完成后，您只需要去关注后续阶段。

瀑布模型的缺点：

1 ）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2 ）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风

险。

3 ）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4 ）瀑布模型最大的缺点是难以快速响应用户需求的变化。

2.2.2

敏捷模型

敏捷开发是一种从九十年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变

化的需求的一种软件开发能力。敏捷开发的总体目标是通过“尽可能早地，持续地对有价值的软件的

交付”使客户满意。通过软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或

改变需求。

优点：敏捷开发的高适应性，以人为本的特性。更加灵活并且更加充分的利用了每个开发者的 3

优势，调动了每个人的工作热情。

缺点：由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过

程中出现很大的困难。 ( 所有在大部分项目管理软件中加入文档管理功能 , 来弥补改缺点 ) 。它过于强调

了人的自我管理。对团队的每个人都要求很高，如果团队成员缺乏能动性，就难以管理。

敏捷模型通常有以下几种：

1 ）并列争求法 (Scrum)

2 ）极限编程 (UP)

3 ）水晶法 (Crystal)

4 ）自适应软件开发 (ASD)

5 ）敏捷统一过程 (AUP)

下面以并列争求法 (Scrum) 为例进行讲述。 Scrum 的英文意思是橄榄球运动的一个专业术语，表示

“争球”的动作；把一个开发流程的名字取名为 Scrum ，相当于大家像打橄榄球一样迅速、富有战斗

激情。 Scrum 使用迭代的方法，其中，把每 30 天一次的迭代称为一个 " 冲刺 " ，并按需求的优先级来实

现产品。多个自组织和自洽的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就

像橄榄球中的 " 并列争球 " 。 Scrum 开发流程中的三大角色 :

1) 产品负责人（ Product Owner ）主要负责确定产品的功能和达到要求的标准，指定软件的发布日

期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

2) 流程管理员（ Scrum Master ）主要负责整个 Scrum 流程在项目中的顺利实施和进行，以及清除挡

在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

3) 开发团队（ Scrum Team ）主要负责软件产品在 Scrum 规定流程下进行开发工作，人数控制在 5~10

人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有

一定的表达能力；成员可以采用任何工作方式，只要能达到 Sprint 的目标。

scrum 的具体开发流程：

1) 我们首先需要确定一个 Product Backlog （产品需求列表），这个是由 PO 负责的；

2) 有了 Product Backlog 列表，我们需要通过 Sprint Planning Meeting （ Sprint 计划会议）来从中挑

选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是 1~4 个星期，然后把这个 Story 进行

细化，形成一个 Sprint Backlog ；

3)Sprint Backlog 是由 Scrum Team 去完成的，每个成员根据 Sprint Backlog 再细化成更小的任务（细

到每个任务的工作量在 2 天内能完成）；

4) 在 Scrum Team 完成计划会议上选出的 Sprint Backlog 过程中，需要进行 Daily Scrum Meeting （每

日站立会议），每次会议控制在 15 分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天

完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人

回答完成后，要走到黑板前更新自己的 Sprint burn down （ Sprint 燃尽图）；

5) 做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。

6) 当一个 Story 完成，也就是 Sprint Backlog 被完成，也就表示一次 Sprint 完成，这时，我们要进

行 Srpint Review Meeting （演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老

板也参加），每一个 Scrum Team 的成员都要向他们演示自己完成的软件产品。

7) 最后就是 Sprint Retrospective Meeting （回顾会议），也称为总结会议，以轮流发言方式进行，每

个人都要发言，总结并讨论改进的地方，放入下一轮 Sprint 的产品需求中。

敏捷过程的典型方法很多，每一种方法基于一套原则，这些原则实现了敏捷方法所称的理念 ( 敏捷

宣言 ) 。

2.3 软件设计

2.3.1

软件设计的流程和内容

软件设计的流程是指从软件需求规格说明书出发，进行软件的总体设计和详细设计。总体设计根

据需求分析阶段确定的功能、质量、约束和开发原则提炼设计需求，提出软件的总体架构。在总体架

构设计中，需要对软件的逻辑架构、数据架构、开发架构、运行架构、和物理架构等方面进行设计。

具体如下：

1.逻辑架构设计：逻辑设计内容包括：识别功能模块、规划功能块的接口、明确功能块之间的使

用关系和使用机制。

2.开发架构设计：开发设计内容包括：确定程序单元以及程序单元的组织结构，程序单元包括源

文件、配置文件、程序库、框架、目标单元等；程序单元组织包括 project 划分、 project 目录结构、编

译依赖关系等。设计程序运行时的环境：包括操作系统、中间件、服务配置等，以确保系统的可移植

性、可配置性、可扩展性等。 4

3.运行架构设计：运行设计内容包括：设计控制流，包括进程、线程、服务程序等运行时概念，

以及相关的并发、同步、通信等问题；设计系统启动与停机，包括系统的启动和停机流程、启动和停

机时的依赖关系、启动和停机的状态检查等，以确保系统的可靠性和稳定性。

4.物理架构设计：确定物理节点和物理节点的拓扑结构，拓扑结构明确物理节点的关系。设计硬

件联网方案，包括网络的拓扑结构、交换机的选型、网卡的配置、防火墙的设置等，以确保网络的稳

定性、可扩展性和安全性。

5.数据架构设计：软件系统需要存储大量的数据，因此需要进行数据库设计，内容包括，数据存

储设计，确定数据的存储方案，包括确定数据库类型、文件存储格式、数据备份和恢复策略等；数据

模型设计，设计数据模型，包括实体、属性、关系等，以及相关的数据更新操作。

软件总体设计完成后进行软件详细设计，详细设计是将架构设计的各个组件的功能进行详细的分

解设计，以确保各个模块之间的协调运作。

2.3.2 软件设计的文档

软件设计文档作为软件开发团队的沟通、理解、知识共享的手段,具有非常重要的意义。从软件的

生命周期看，软件设计工作需要形成两份设计文档，一是概要设计文档，二是详细设计文档。

概要设计文档至少应该包括以下几个方面的内容：

1)

总体架构

2)

逻辑架构视图

3)

开发架构视图

4)

运行架构视图

5)

物理架构视图

6)

数据架构视图

详细设计文档主要针对概要设计中的每一部分进行细化，包括类的内部设计、关键数据结构、关

键算法、类间的详细交互等内容。

2.4 需求建模案例

该节内容是以学生李昕达开发的“万家商城”项目系统为例进行需求分析。“万家商城”系统软

件功能结构图如图2.2所示

2.4.1

功能需求

用户（前台系统）：

1. 登录注册功能模块

用户之前未使用过该系统，需要在注册界面输入账号，密码以及确认密码，点击完成注册进入系

统验证，系统要验证账号和密码输入是否合法，两次密码输入是否一致，

验证成功即成功注册。之

后用户便可以进行登录，在登录界面输入自己注册的账号和密码，点击登录进入系统验证，系统验证

则通过数据库查看账号是否存在，输入密码是否正确，可以匹配到数据的账号即可完成登录。若用户

担心密码泄露，在知道原密码情况下需要修改原来的密码，点击修改密码按钮进入相关界面，输入需

要修改的账号，原密码，新密码以及确认密码，点击确认修改后系统开始验证，系统要判断账号是否

存在，输入原密码是否正确，验证输入的新密码是否合法，两次输入的新密码是否一致，上述要求 均符合即可完成修改。

2. 管理个人信息功能模块

查看和修改个人资料：在首页点击个人资料可以跳转到个人资料界面，个人资料界面需要呈现用

户个人信息，比如电话号码，收货地址，邮箱，性别等。点击个人信息下方的修改，可以让用户在个

人资料界面修改自己的个人信息，提交后系统验证内容是否合法，验证通过，数据库将修改的内容覆

盖原先的内容。

查看收藏夹、加入 / 取消收藏商品：点击首页的收藏按钮可以跳转到收藏界面，在该页面可查看到

收藏的商品；用户也可以在浏览到自己喜欢的商品时，点击加入收藏将商品添加到自己的收藏夹中，

后台在相应的数据库中添加该商品信息；用户在收藏夹中。可以点击取消收藏按钮，删除原来收藏的

商品，数据库删除相关表格中该商品的信息。

3. 购物车管理功能模块

在首页设置一个购物车按钮，然后跳转到购物车界面，调取数据库数据并在页面呈现用户的购物

车内容；同时用户可以在购物车界面中，修改购物车中每个商品购买数量，以及删除已选中的商品，

系统根据用户的操作，对后台的数据库等信息进行修改删除，完成修改或删除购物车信息；除此之外，

点击核算按钮，系统会将购物车内出现的商品按相应的价格进行计算并将价格显示出来。

4. 订单处理功能模块

用户在购物车界面选择好商品之后，完成对订单的提交，系统后台会将提交的订单信息加入到数

据库当中；在我的订单界面当中我们可以查看到所有订单，点击订单详情，我们可以查看到订单的收

货地址、收货人、订单号等信息；对不需要的订单我们可以点击退货，后台会将所选中的订单在后台

数据库进行删除；除此之外我们在已完成的订单当中点击评价跳转到评价界面，提交输入的评价内容，

后台将内容添加到数据库中，完成对订单的评价。

管理员（后台系统）：

1. 登录功能模块

管理员在登录界面输入自己已有的账号和密码，点击登录进入系统验证，系统验证则通过系统的

数据库查看账号是否存在，输入密码是否正确，可以匹配到后台数据的账号才能登录。若管理员担心

密码泄露，需要修改原来的密码，点击修改密码进入相关界面，输入需要修改的账号，原密码，新密

码以及确认密码，点击确认修改后系统开始验证，系统要判断账号是否存在，输入原密码是否正确，

验证输入的新密码是否合法，两次输入的新密码是否一致，上述要求均符合即可完成修改。

2. 后台用户信息管理功能模块

后台管理员拥有管理商城用户的所有权限，在员工信息管理功能中，管理员进入员工个人信息界

面可以查看到后台任何用户的个人信息，比如用户的账号，密码，邮箱，收货地址等等，用户忘记密

码时可以联系管理员在后台界面修改自己的密码；用户需要注销账户时，联系管理员，后台管理员会

在后台用户管理界面中点击删除按钮，删除掉后台相应的账号所有信息。

3. 后台商品管理系统功能模块

后台管理员可以在后台管理商品界面，在查询框输入需要查询的物品信息，后台根据数据库的筛

选，在界面呈现查询结果；对于商城新的需要上架的商品，在商品信息界面点击添加按钮，提交新商

品的信息完成添加；对于需要修改的商品，可以点击修改按钮，修改相关内容并提交，即可完成对后

台数据的修改；后台管理员也可以在商品信息界面点击删除按钮，从后台删除掉已经断货或者淘汰的

商品。

2.4.2 其他要求

1 ）平台系统应搭建在多台服务器上，可以使系统高效稳定的运行，提高软件的负载量，可以解决

一些高并发问题，尽量保证系统的接口调用时间小于 300ms ，一年内服务断开不得超过 3 次，每次不

得超过 3s ，保证用户使用体验感。

2 ）该平台系统适配 windows 系统，并可以在 win7 、 win10 、 win11 系统正常运行。

3 ）界面应布局清晰合理、护眼、按钮位置恰当、各项功能排列整齐，各类信息采用分页显示，满

足用户基本的浏览需求，给用户良好的视觉体验。例如，在用户个人信息界面需要给用户一种层次分

明的效果，让用户可以快速找到需要的信息。

4 ）该商城系统在城市中用户较多，需要可以支撑大量数据的并发处理，可以满足大量用户同时在

线，保证系统可以快速响应用户的请求。

5 ）该商城系统采用模块开发，模块结构更清晰明，并对功能细化，每个模块之间更加独立，使每

个模块的改动对其他模块影响较小，方便各个模块进行相应的功能扩展。例如，对于商城系统的 “ 购物

车管理功能 ” 模块的改动几乎不会影响 “ 订单处理功能 ” 模块。

6 ）系统应具备基本的安全特性，该平台系统对数据库中的用户密码、订单等隐私信息进行了加密

处理，防止非法用户进入系统后台盗取用户信息，同时，该系统采取相关措施，防止用户越权访问防

止非法用户盗取后台信息，以免对商城造成不必要的损失。

5 7） 该商城系统以模块划分，便于各个功能的独立实现，每个各功能相对独立，便于后期扩展功能，

以及后期测试维护，所以该系统对前期开发预算较大，后期测试维护预较低。

8 ）该商城系统可以部署在多台服务器上，负载量可以支撑城市的大型商城，主要适用人群是城市

的青少年和中年人群，可以满足大多数用户的使用，但是目前只有中文语言，所以在国内的受众人群

很多，不适合向外发展客户。

9 ）由于该系统的各个模块相对独立，像 “ 登录注册 ” 模块、 “ 购物车管理 ” 模块、 “ 订单处理 ” 订单模

块之间相对独立，便于他们各个模块的功能扩展，可以在未来给更多的用户提供便利，未来发展较好，

但是由于目前语言限制，只能受众于国内群体。

10 ）该系统中设置了 junit 单元测试，各功能模块相对独立，便于后期维护且成本较低。

第 3 章

软件设计的驱动因素

本章介绍驱动软件设计的因素。需求驱动设计，需求不仅包括软件的功能需求，还包括

软件的质量需求、约束和原则。

3.1 软件设计的驱动力

3.1.1

软件的功能需求

不同的角色有不同的需求。软件开发涉及到不同的角色，比如软件的投资者、终端用户、设

计人员、编码人员、测试人员以及维护人员等。因此，在软件开发中将不同角色的需求定义为需

求的不同层次。如图 3.1 所示，软件的需求往往可以根据层次不同，一般可以划分为业务需求、

用户需求、系统需求。业务需求是一个组织的高层需求，描述了组织的负责人想要通过软件达到

的高层目标，也被称为组织级需求。用户需求是终端用户能够使用软件完成什么样的任务，也被

称为用户级需求，用例是描述用户需求的一种有效方法。系统需求包含了系统的功能需求和质量

需求，定义了系统如何满足用户需求和业务需求。功能需求定义了系统能够完成什么样的任务。

质量需求定义了系统完成任务的好坏程度。当然，需要说明的是系统既可以是一个纯软件也可以

是一个纯硬件或软硬件的结合体，本书在没有特殊说明时，一般指的是一个纯软件。

一个软件的功能需求定义了软件必须实现的功能，这些功能为用户完成业务提供支撑，是组

织达成高层目标的重要保证。这些需求必须在软件需求规格说明书中加以详细描述供项目组其他

人员使用。对功能需求的描述必须做到清晰、简单、无歧义。以下是一个关于网上交易系统的正 2

例和反例。

（ 1 ）正例：当用户提交一个新订单时必须给商家发送一封确认邮件。

（ 2 ）反例：当用户提交一个新订单时必须给商家发送一条确认消息。

功能需求是系统初始结构设计的重要输入，影响系统的结构分解。比如 Java 的虚拟机具有

以下两个功能：

（ 1 ）装载字节码到内存。

（ 2 ）执行内存中的字节码。

如图 3.2 所示，是根据 Java 虚拟机的功能需求对 Java 虚拟机系统的初始结构的设计。

3.1.2

软件的质量需求

软件的质量需求反映了所提供的功能质量，如性能、可伸缩性、可用性以及安全性等。这些

需求对软件的设计会产生巨大影响，向已有的软件中加入高性能、高可用等质量需求是非常困难。

因此，软件在设计时必须充分考虑软件的质量需求。下面以一个前后端分离的登录子系统为例说

明有无质量需求时设计决策的变化。

假设登录子系统的功能是通过用户名和口令验证一个已注册用户的合法性，其结构设计如图

3.3 所示。如果仅考虑功能的满足，软件仅需要接收用户输入的用户名和口令，然后将这些信息

传递给后台的登录服务由登录服务与数据存储交互完成合法性验证。然而，如果考虑安全性质量 3

需求，需要考虑的因素就会增加，比如：用户口令自身的安全、用户电脑的安全、传输链路的安

全以及数据存储的安全等。

3.1.3

约束

软件开发总是受到现实条件的约束。与功能需求、质量需求共同驱动、塑造、影响软件

的设计决策。以下列出关于软件开发过程中常见的约束类型。

（ 1 ）技术约束

在开发软件的时候，经常会碰到一些与技术相关的约束：



技术白名单：许多软件开发公司或软件客户所在组织都制定了开发软件可使用的技

术白名单，对于使用不在白名单中的技术由严格的审批流程。这样做的好处一是可

以避免版权纠纷，二是可以避免技术风险。



软件运行环境：一般来讲，软件需求规格说明书中均规定了软件的运行环境，比如：

硬件平台、操作系统、数据库等。



软件开发环境：有些用户为了后期维护方便，规定了软件的开发环境，比如：必须

采用 Java 语言等。



技术成熟度：有的组织喜欢尝鲜，愿意采用一些有风险的尖端技术，而有的组织却

很保守，不愿意采用未经长时间验证的新技术。

（ 2 ）人的约束

软件开发来自人的最常见约束包括：



你的软件开发团队规模。



你的软件开发团队拥有的技术能力。



你的软件开发团队吸收新技术的能力。

（ 3 ）交付时间

交付时间是软件设计人员必须重点考虑的因素。交付时间直接影响软件的技术选型等设

计决策。

（ 4 ）预算约束

软件的用户总是规定软件开发投入的成本，不可能无限制投入。预算投入的大小也会影

响到软件设计决策。

（ 5 ）政治约束

你所在组织可能受到政治影响而制定一些约束条件。比如：中美贸易就可能会影响软件

技术选型决策。

约束尽管是强制的，是软件设计人员所不愿接受的，但往往初心是好的。比如：限制使

用 Java 语言开发的一方面降低了创造力，另一方面却避免了软件设计人员对使用其他开发语 4

言的技术评估。学会倾听约束能够有效帮助软件设计人员设计软件。相反，不能很好理解和

接受这些约束对于软件设计人员而言是有风险的。

3.1.4

原则

约束通常来自于外部是外部强加于软件设计人员的。然而，原则则是软件设计人员需要

主动选择。这些原则通常都用于确保构建的软件的一致性。

（ 1 ）与软件编码、测试相关的软件构建原则



编码标准和规范。比如：采用阿里的 Java 语言编码规范。



测试的自动化。比如：要求代码的自动化测试达到 80% 以上。



静态分析工具。比如：软件在提交前必须经过安全漏洞检测。

（ 2 ）软件设计的原则



分层原则。比如：软件系统整体结构应该被分为用户界面层、业务层、数据层等。



高内聚低耦合。比如：在划分软件模块时需要遵守高内聚低耦合。

 SOLID 原则。比如：采用面向对象设计时就应该遵循 单一职责、开闭原则、里氏替

换、接口隔离以及依赖反转五个 原则。

3.2 软件的质量需求

3.2.1

常见的软件质量需求

质量需求规定了软件提供的功能的服务质量，它直接驱动软件设计进行迭代优化。常见

的质量需求包括：

（ 1 ）性能

性能通常指响应时间或延迟。响应时间是指从用户发出请求到响应所用的时间，比如用

户点击登录到系统返回登录成功或失败的时间。延迟是指数据从 A 到 B 的时间，比如网络延

迟是数据从源点到终点所耗费的时间。

（ 2 ）可伸缩性

可伸缩性是软件应对所处理任务数量增加的能力，通常用单位时间内处理的请求数量来

度量软件的可伸缩性。

（ 3 ）可用性

可用性是软件的正常运行时间，通常用“ 9 ”来度量软件的可用性。比如： 99.9% 的可用

性意味着留给维护、故障的时间每天只有 1 分钟。

（ 4 ）安全性

安全性是软件保护数据的能力，通常安全属性来度量软件的安全性，比如：保密性、完

整性、不可否认性。 OWASP 是一个学习安全的好起点。

（ 5 ）灾难恢复

灾难恢复包括了旨在防止或尽量减少灾难性事件造成的数据丢失和业务中断的最佳实

践，涵盖了从设备故障和局部停电到网络攻击、民事紧急情况、犯罪或军事攻击以及自然灾

害 5

（ 6 ）可访问性

可访问性指软件能够被使用的能力，比如如何让视觉障碍用户正常使用软件。

（7）监测

监测指软件对外输出的可用于观测软件是否处于正常运行状态的数据。比如：Java 平台

的 JMX 等。

（8）管理

通常当监测到软件处于预警状态时，给维护人员提供的软件管理功能以保证软件处于长

时间正常运行状态的质量需求。

（9）审计

审计质量需求通常需要软件记录软件的数据或行为发生变化的事件日志。这些日志通常

需要记录变化由谁做出、什么时间做出以及为什么做出等信息。

（10）灵活性

灵活性通常指完成多个任务或以不同方式执行单个任务的能力。在信息化软件开发中，

业务规则的定制就属于软件的灵活性质量需求。

（11）可扩展性

可扩展性度量软件为了做一些现在不能做而未来要做的任务而做修改成本，修改成本越

低意味者软件的可扩展性越好。常见的 SOLID 原则就是为了保证软件的可扩展性。

（12）可维护性

可维护性用于度量运行期的软件持续满足用户需求的能力。比如：一个数据采集软件会

将采集到的数据写入一个文件夹，那么随着时间的推移，该文件夹的数据就会越来越多，软

件就必须给维护人员提供一种机制让用户维护这些数据，确保软件持续运行。

（13）法律法规

有些行业需要接受法律法规的严格监管，因此软件需要提供一些机制满足监管需求。比

如：涉及金融的软件必须遵守反洗钱的规定。

（14）国际化

国际化是指软件以多种语言交付软件中可见元素的能力。随着全球化进程的不断推进，

软件越来越不能再以单一语言进行交付。

（15）本地化

本地化是指以最符合最终用户习惯的方式展现软件，比如：数字、货币、日期等不同种

族的用户往往有着不同的需求。

3.2.2

软件质量需求的挖掘过程

软件的用户通常很少直接表达质量需求，即使表达了也不像功能需求那样清晰。因此，

软件的质量需求需要挖掘。通常的挖掘过程包括捕捉和提炼：

（1）捕捉 6

一般情况下，软件的用户更多的关注软件的功能需求，很少表达软件的质量需求，软件

设计人员必须主动出击，自己捕捉。比如：需要去咨询业务人员软件的可用性需求，尽管你

可能得到的是 100% 可用的回答，但你已经收集到了一些有用的信息。

（2）提炼

软件需求规格说明书中功能需求占据了文档的绝大部分，留给质量需求的细节却很

少，需要进一步提炼。比如：在一份软件需求规格说明书包含了以下关于质量需求的表述。



性能：软件必须要快。



安全性：软件必须安全。



可用性：软件的运行时间应该达到 100% 。

尽管以上的表述不清晰难测试，但至少可以开展新的讨论。比如针对软件的可用性你

可以进一步咨询。



你能忍受的软件停机时间是多少？



如果软件在朝九晚五的正常工作时间内出现故障会发生什么？



如果软件在正常工作时间之外出现故障会发生什么？

理论上有些质量需求是可以测试的。比如：



软件平均应该支持多少并发用户？



多长的响应时间可以接受？



针对高安全性明确需要保护的对象是谁，安全属性是什么？

软件质量需求挖掘的最大挑战在于难以划分质量需求的优先级且每一个质量需求都不可

或缺且百分之百需要满足。因此，在具体实践时应该将质量需求与软件的开发成本一起讨论。

比如：



软件设计人员：“你需要一个正常运行时间未 100% 的软件。构建这个软件必须通

过大量冗余来消除每一个故障点，这需要花费很高的成本，外加一些故障自动转移

工作，总成本可能要 100 万元人民币。当然，我们也可以构建一个成本低的软件，

但发生故障时需要手动重启，这个成本大约是 10 万元人民币。



用户：“哦，那我选择后一种方案吧。“

本章小结

事实上，从软件需求规格说明书中提炼影响软件设计的功能需求、质量需求、约束和原

则是比较复杂的。但是，只要反复阅读本章的内容并在实际项目中多实践，就总能找到一些

适合于自己的方法。 第 4 章 软件设计的思维方法

软件设计需要抽象现实问题形成软件系统的顶层结构，并通过层层分解完成软件各层次

的子系统设计，并再次组合优化各子系统形成符合功能需求以及质量需求的软件。本章主要

介绍层次思维、分解思维、系统思维、隔离思维、复用思维和抽象思维等软件设计活动中常

用的思维方法。

4.1 层次思维

4.1.1

层次思维方法

层次思维是解决复杂问题的一种思维方式，通过把复杂问题分为多个层次，每个层次聚

焦某一方面问题的思路将复杂问题转换为若干简单问题求解。如图 4-1-1 所示，网络通信的

复杂问题就被分为 TCP/IP 四层模型，每个层次仅仅负责通信的一个方面。模型中各层的作

用如下：

1) 应用层负责与用户的交互，常见的协议有 HTTP 、 FTP 等。

2) 传输层负责数据传输，常见的协议有 TCP 、 UDP 。

3) 网络层负责数据包的路径选择，常见的协议有 IP 、 ICMP 和 IGMP 协议。

4) 链路层处理网络连接的硬件部分，包括硬件的设备驱动、网络适配器等物理可见部

分，常见的协议有 ARP 、 RARP 协议。

利用 TCP/IP 协议族进行网络通信时，会通过分层顺序与对方的计算机进行通信。发送

端从应用层往下走，接收端则往应用层往上走。如图 4-1-2 所示，展示了一个字符串“你好”

的传输过程。发送端通过应用层、传输层、网络层、链路层逐层封装数据包，到达接收端后

从链路层、网络层、传输层、应用层逐层拆封数据包。