软件工程 Software Engeering

Presentation on theme: "软件工程 Software Engeering"— Presentation transcript:

1 软件工程 Software Engeering
淮海工学院计算机工程学院 Depart of Computer Science， Huaihai Institute of Technology Spring 2008

2 教材、参考书 教材 《软件工程导论》，张海藩编著，清华大学出版社，2004.9
《软件工程导论学习辅导》，张海藩编著，清华大学出版社，2004.9 参考书 《软件工程》，齐治昌 谭庆平 宁洪编著，高等教育出版社。 《软件工程自考应试指导》，刘海岩等编著，南京大学出版社。 《软件工程学实验》，周苏等编著，科学出版社，2005.4 《软件工程（英文版·第7版）》，Ian Sommerville,机械工业出版社，

3 软件工程课程说明 软件工程涉及： 软件工程不涉及： 软件工程着力于解决软件危机，即软件经常不能按时按质地交付使用
软件生命周期(定义、设计、编码、测试、发布、维护、淘汰)各阶段的任务与内容 软件开发生产中有关工艺、模式、方法和工具的管理与技术问题 软件工程不涉及： 程序语言的内容 软件编程 软件工程着力于解决软件危机，即软件经常不能按时按质地交付使用

4 与其它软件专业课的区别 (1) 立足于系统的整体。 (2) 讲授系统分析、系统设计、 测试及维护的理论和方法。
(3) 构筑一个软件系统，实践 软件开发全过程。

5 “软件工程”课程教学与实践的目标 转变对软件开发的认识： 上升 程序 系统 转变思维定式： 程序员 系统工程师 (系统分析员) 工程化训练

6 软件工程与一般工程的差异 软件是逻辑产品而不是实物产品 软件的功能依赖于硬件和软件的运行环境以及人们对它的操作 软件设计的复杂性
软件特征： 功能的多样性 实现的多样性 能见度低 软件结构合理性差 智力密集及知识产权保护

7 内容安排 第一章 软件工程学概述 第二章 可行性研究 第三章 需求分析 第四章 总体设计 第五章 详细设计 第六章 实现 第七章 测试

8 第八章 维护 第九章 面向对象方法学引论 第十章 面向对象分析 第十一章 面向对象设计 第十二章 面向对象实现 第十三章 软件项目管理

9 学习目标 了解软件产生软件危机的原因和消除软件危机的途径； 掌握软件生命周期的概念与生命周期中各阶段划分；
熟练掌握软件过程模型或生命周期模型中典型的几个模型——瀑布模型、原型模型、增量模型和螺旋模型。

10 软件工程发展的大事记 1968.10 NATO在德国南部的Gamisch会议上首次提出“软件工程”
1976 IEEE 成立标准委员会，“软件工程”成为计算机科学专业的一门课程 1987 ISO/IEC成立标准委员会，“软件工程”成为一个专业 1993 IEEE CS/ACM 成立联合委员会 1998 美国德州首次发布“软件工程师”执照; 开始执行软件工程知识体项目

11 软件的特点 软件是程序及其有关的文件与数据的集合。 软件的开发周期大大长于生产周期。 软件不像硬件一样会磨损，但会过时。
软件很容易复制，因此具有复杂的知识产 权问题。 软件是计算机系统产品的灵魂。 随着计算机系统的普及，软件的复杂性与 重要性与日俱增。 1. 许多人对软件有不全面的认识：: 认为是计算机程序 (例如：原码和/或可执行码), 认为是数据结构 (例如：数据库结构), 以及 认为是用户操作使用说明 2. 不能及时提交高质量软件的主要原因是缺乏可重用的软件成分库 可重用的软件成分库太少 不愿意使用老的软件成分 开发软件是一种艺术创造 3. 软件已经成为事业是否成功的关键所在。事业的成功与失败往往取决于是 否能够及时地开发高质量的软件。 用户要求快速地提供高质量的软件。

12 产品的包换期不一定要很长，只要能够超过产品的成熟期就可以了。
软件与硬件产品的故障率 实际曲线 使用初期 磨损期 修改 故障率 硬件一般都有一个磨损期，在此期间硬件的故障率很高。 硬件产品还有一个 成熟期. 在这个产品的初始使用期内，故障率较高，越过这个期间产品就很少有故障。 注意 产品的包换期不一定要很长，只要能够超过产品的成熟期就可以了。 软件产品也有初期故障率高的问题， 一般通过软件的更新可以解决大部分问题，. 增强功能的软件更新往往会带来新的问题，可以通过图上的断裂点表现出来。 软件更新时会引入一些新的潜在故障，使得软件不可靠，如果开发者不能保证软件的开发质量，往往会出现越改问题越多的现象，甚至最后不得不抛弃这个软件，重新开发。 理想曲线 时间 时间 硬件故障率分布曲线 软件故障率分布曲线

13 软件应用领域 软件应用于所有需要 人类智能的领域 实时软件 科学与工程计算 系统软件 人工智能 应用软件 个人计算机软件 操作系统 编译器
系统控制 嵌入软件 个人计算机软件 所有用于个人计算机的软件 科学与工程计算 仿真 计算机辅助设计 人工智能 专家系统 人工神经网络 系统软件 操作系统 编译器 编辑器 应用软件 企业管理 教育应用

14 按软件规模进行划分： 类别 参加人员数 研制期限 源程序行数 微型 1 1～4周 0.5k 小型 1 1～6月 1k～2k
类别 参加人员数 研制期限 源程序行数 微型 ～4周 k 小型 ～6月 k～2k 中型 ～ ～2年 k～50k 大型 ～ ～3年 k～100k 甚大型 100～ ～5年 1M(=1000k) 极大型 ～ ～10年 1M～10M

15 软件的发展 面向对象 C/S结构 网络环境 开发工具 合作开发 分布式系统 分布计算 多用户 嵌入式 并行计算 实时性 数据仓库 数据库
商品软件 批处理 分发量小 专用软件 1. 早期特征 (到 1970):  大型价格昂贵的计算机  程序短小，编写费力  内存容量、速度、输入输出不足  单用户、批处理的操作系统  个体式的程序编写方法 2. 中期特征(1970 to 1990):  实时软件  形成开发人员小组  出现软件开发的工业标准  关注软件开发的工程方法  多用户操作系统 3. 后期特征(1980 to 1990):  个人计算机大量涌现，使用更加方便  出现大型软件企业  大规模的程序和大型软件系统  计算机通讯与网络普及  软件的规模与功能越来越大 第四代 第三代 第二代 第一代

16 处在十字路口的中国软件产业 主权大国必须建立基于自主技术的、 完整的软件产业体系。 软件本国提供率：中国1/3左右，美国97%
“印度模式”还是“中国模式” 软件人才结构不合理，缺乏中高级软 件人才； 软件人员缺乏软件工程化的概念。

17 印度模式与中国国情 是一种劳动密集型的“来料加工”模式，这有利于发挥中国的优势，充分利用更多的、具有一技之长的劳动力；
其次，它是一种标准的工厂式作业模式，比较适应全球制造业向中国转移的需要，有利于带动软件产业的普遍发展； 再次，与印度一样，长期看来，中国的软件业应该是具有国际竞争力的，其标志之一就在于大量的经过专门训练的软件人才的使用成本相对较低； 此外，印度模式是一种开放的外向型模式，它代表了全球化的方向，也代表了中国未来在这方面的发展趋势

18 软件发展趋势 并行计算提高计算速度 面向对象的软件开发方法 软件框架（ frameworks） 用于处理大型软件系统 图形接口越来越强
人工智能和神经网络技术 高级程序设计语言 专用工具软件 开放资源软件(Open Source Software) 所有的趋势中有一个共同关心的问题：如何保证软件的质量 目前软件界认为以下两点非常重要：: 优良的软件开发工艺（process） 各种工艺中的技术革新 只有技术而没有工艺是不行 的, 它只能造成而不是解决问题和风险.

19 第1章 软件工程学概述 1.1 软件危机 软件危机的出现：60年代中期到70年代中期，许多软件最终成为不可维护的，这就是软件危机.
1.1 软件危机 软件危机的出现：60年代中期到70年代中期，许多软件最终成为不可维护的，这就是软件危机. 软件工程就是为解决软件危机问题而出现的。1968年，正式提出并使用“软件工程”的概念。

20 1.1.1 什么是软件危机？ 对软件开发成本和进度的估计常常很不准确。 用户对为他们开发的软件往往不满意。 软件产品的质量往往靠不住。
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。包括： 对软件开发成本和进度的估计常常很不准确。 用户对为他们开发的软件往往不满意。 软件产品的质量往往靠不住。 软件常常是不可维护的。 关于软件开发的历史数据很少，因此我们很难根据软件开发的历史数据来制定 新的软件开发项目的计划 用户的需求往往自己也说不清楚，而且不断地发生变化，因此软件往往很难满 足用户的需求。 到目前为止，还没有一个严格的定量的软件质量指标，这就使得很难测量软件 的质量。 维护往往成为软件生命周期中耗费最多困难最大的阶段。

21 1.1.1 什么是软件危机？ 软件通常没有适当的文档资料。 软件成本在计算机系统总成本中所占的比例逐年上升。 软件开发生产率提高的速度太慢。
以上的这些问题能够解决吗?

22 1.1.2 产生软件危机的原因 不能用象硬件替换部件的方式修复软件的故 障 软件质量是一个牵涉到人的因素的问题
软件项目管理者往往没有软件开发的经验 软件开发者往往没有经过正规的工程训练 编程人员不愿意将软件开发的艺术过程转化 为工程过程

23 • Exchange2000和 Windows2000开发人员结构
例 •Windows95有1000万行代码 • Windows2000有5000万行代码， 3000多个工程师，几百个小团队。 • Exchange2000和 Windows2000开发人员结构 Exchange2000 Windows2000 项目经理 25人 约250人 开发人员 140人 约1700人 测试人员 350人 约3200人

24 对软件的常见误解 用户的误解 开发人员的误解 管理者的误解

25 用户的误解 现实 误解 软件需求不明确是造成软件开发费用增加和延时交货的主要原因. 先对软件需求做一般的说明，以后再逐步明确就可以了.
软件开发费用随着开发阶段的后移而大大增加. 误解 先对软件需求做一般的说明，以后再逐步明确就可以了. 需求本身就是不断变化的，软件容易改变可以很快调整适应这种变化. 软件开发 费用 1x 1.5-6x 60-100x 设计阶段 开发阶段 维护阶段

26 开发人员的误解 误解 现实 一个软件的50%-70% 的工作量耗在软件交付使用以后. 对于某些错误,软件审查比软件测试更加有效.
一个完整的软件要包括程序、各种文件和各种数据. 误解 一旦程序开发完毕工作正常，我的任务就完成了 在程序工作之前，无法顾及软件的质量问题. 对于一个成功的项目来说，唯一能够提供的就是可以工作的程序.

27 管理者的误解 现实 误解 书上已经有各种软件开发的标准，拿来用就是了. 已经有足够的软件开发工具可供使用.
书上是有各种软件开发的标准，但不是过时就是不适用. 软件工具不是一拿来就能用的. “项目后期增加程序员会使项目的完成更加推后." -- Brooks 误解 书上已经有各种软件开发的标准，拿来用就是了. 已经有足够的软件开发工具可供使用. 一旦项目的程序员不够可以随时增加.

28 1.1.3 解决软件危机的途径 推广使用在实践中总结出来的开发软件的成功的技术和方法。 开发和使用更好的软件工具。
总之，为了解决软件危机，既要有技术措施，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究更好地开发和维护计算机软件地一门新兴学科。

29 1.2 软件工程 IEEE std 定义为:应用一种系统的、科学严格的、定量的方法来开发、运行和维护软件; 也就是说将工程的方法用于开发软件. Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料. Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法.

30 1.2.1软件工程的本质特性 关注大型程序的构造 中心问题是控制复杂性 软件经常变化 开发效率非常重要 和谐地合作是开发软件的关键
有效地支持它的用户 具有一种文化背景的人替另一种文化背景的人创造产品

31 1.2.2软件工程的基本原理 用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查
开发小组成员应少而精 承认不断改进软件工程实践地必要性

32 1.2.3 软件工程方法学 软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。
软件工程方法学 软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。 所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。在软件工程领域中，这两个术语的含义基本相同。

33 1.2.3软件工程方法学 传统方法学 面向对象方法学

34 1.3软件生命周期 生命周期方法学 从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。 软件定义 问题定义：要解决的问题是什么？ 可行性研究：有可行的解决办法吗？ 需求分析：为解决问题，目标系统必须做什么？

35 1.3软件生命周期 软件设计 软件维护 总体设计：概括地说，应如何解决该问题？ 详细设计：应怎样具体实现这个系统？
编码和单元测试：编写代码，测试模块 综合测试：通过测试，使软件达到要求 软件维护 软件维护：通过各种维护活动使系统持久地满足用户地需要

36 软件开发的过程 制定开发计划 编码与测试 软件项目划分 编码 软件需求定义 软件测试计划与方法 编写软件需求说明 生产，销售与维护
制定软件测试计划与方法 数据结构与数据字典 用户文件 软件设计 编写软件设计说明 编码与测试 编码 软件测试计划与方法 生产，销售与维护 用户手册 维护服务 软件配置的各个成分如何建立? 软件配置的各个成分 一般要经过设计、审核以及复审等阶段才能建立，各个成 分经常处于变化的状态中，特别是随着软件更新换代速率的增加，软件配置成分 的变化更快，特别需要专门的管理与控制的工具。 软件配置的各个成分 是由 软件配置控制 来管理的， 它要对各个成分的版本归档 管理，既要便于跟踪还要便于修改。 软件配置成分 的控制要贯穿软件开发的整个周期 。

37 1.4 软件过程 软件设计 软件维护 总体设计：概括地说，应如何解决该问题？ 详细设计：应怎样具体实现这个系统？
1.4 软件过程 软件设计 总体设计：概括地说，应如何解决该问题？ 详细设计：应怎样具体实现这个系统？ 编码和单元测试：编写代码，测试模块 综合测试：通过测试，使软件达到要求 软件维护 软件维护：通过各种维护活动使系统持久地满足用户地需要

38 1.4 软件开发模型 软件开发模型（又称为软件生存周期模型） —软件项目开发和维护的总体过程思路的框架。
1.4 软件开发模型 软件开发模型（又称为软件生存周期模型） —软件项目开发和维护的总体过程思路的框架。 它指出了软件开发过程各阶段之间的关系和顺序，是软件开发过程的概括。它为软件开发过程提供原则和方法，并为软件工程管理提供里程碑和进度表。因此，软件开发模型也是软件工程的重要内容。

39 1.4 软件开发模型 软件开发模型的几种类型： 以软件需求完全确定为基础的瀑布模型；
1.4 软件开发模型 软件开发模型的几种类型： 以软件需求完全确定为基础的瀑布模型； 在开发初期仅给出基本需求的渐进式模型，如原型模型、螺旋模型、喷泉模型等； 以形式化开发方法为基础的变换模型、基于四代技术的模型； 基于知识的智能模型等等。 在实际开发时，应根据项目的特点和现有的条件选取合适的模型，也可以把几种模型组合起来使用以便充分利用各模型的优点。

40 1.4.1 瀑布模型 瀑布模型（waterfall model）是由W. Royce于1970年提出来的。又称为软件生存周期模型。
瀑布模型 瀑布模型（waterfall model）是由W. Royce于1970年提出来的。又称为软件生存周期模型。 瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。因此，它是一种以文档作为驱动的模型。

41 1.4.1 瀑布模型 问题定义 可行性研究 特点： 1.阶段间具有顺序性和依赖性 需求分析 2.推迟实现的观点 3.质量保证的观点 总体设计
详细设计 编码与单元测试 综合测试 软件维护 特点： 1.阶段间具有顺序性和依赖性 2.推迟实现的观点 3.质量保证的观点

42 瀑布模型优点 提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。

43 瀑布模型缺点 1）在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。
2）在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。 3）作为整体开发的瀑布模型，由于不支持产品的演化，缺乏灵活性，对开发过程中很难发现的错误，只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。

44 瀑布模型适应场合 瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。

45 原型模型 原型模型（prototyping model）的基本框架是软件开发人员根据用户提出的软件基本需求快速开发一个原型，以便向用户展示软件系统应有的部分或全部功能和性能，在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据此改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。软件需求确定后，便可进行设计，编码、测试等以后的各个开发步骤。

46 图1-4-2 使用原型确定需求的过程 开始 需求的采集和细化 停止 快速设计 产品样品 (需求确认) 对原型加工 (需求精确化) 建造原型
用户评价原型 图 使用原型确定需求的过程

47 快速原型的开发途径有三种： 1）仅模拟软件系统的人机界面和人机交互方式。 2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能。
3）利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能。 总之，建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见部分，如人机界面、数据的输入方式和输出格式等。

48 原型模型的适应场合 原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架。
它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。

49 螺旋模型 螺旋模型（spiral model）是B. Boehm于1988年提出的。它综合了瀑布模型和原型模型的优点，即将两者结合，并加入了风险分析机制。螺旋模型的基本框架如图1-4-3所示。

50 图1-4-3 螺旋模型 编码 成本 计划： 明确目标、约束条件 选择方案 风险分析 构造原型 顺时针为进展方向 风险分析 实现计划 风险分析
开发计划 风险分析 可操作 的原型 需求精化计划 风险分析 原型3 原型2 生命周期计划 需求计划 原型1 评审 决策 建模 模拟 操作概念 评价 需求评价 软件需求 验收测试计划 软件产品 设计 详细 设计 需求确认 组装测试计划 设计验证与确认 单元 测试 编码 组装 测试 验收 测试 用户评价；阶段评审 实现 工程实现 图 螺旋模型

51 1.4.3 螺旋模型 螺旋模型的每一个周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。 1．计划（需求定义）
螺旋模型 螺旋模型的每一个周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。 1．计划（需求定义） 第一周期开始利用需求分析技术理解应用领域，获取初步用户需求，制定项目开发计划（即整个软件生命周期计划）和需求分析计划。经过一个周期后，根据用户和开发人员对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开发的目标、约束条件，并据此制定新一轮的软件开发计划。

52 螺旋模型 2．风险分析 根据本轮制定的开发计划，进行风险分析，评估可选方案，并构造原型进一步分析风险，给出消除或减少风险的途径。此时根据风险分析的结果决策项目是否继续。所以，螺旋模型是一个风险驱动的模型。 3．工程实现 利用构造的原型进行需求建模或进行系统模拟，…，直至实现软件系统。

53 螺旋模型 4．用户评价与阶段评审 将原型提交用户使用并征求改进意见。开发人员应在用户的密切配合下进一步完善用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确认等。 螺旋模型从第一个周期的计划开始，一个周期、一个周期地不断迭代，直到整个软件系统开发完成。

54 螺旋模型的优点 支持用户需求的动态变化。这就要求构造的原型的总体结构、算法、程序、测试方案应具有良好的可扩充性和可修改性。也支持软件系统的可维护性，每次维护过程只是沿螺旋模型继续多走一两个周期。 原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。

55 螺旋模型的优点 螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。
螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。

56 螺旋模型的缺点和适应场合 缺点： ①如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；
②使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。 适应场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。

57 增量模型 增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。 开发字处理软件使用增量模型： 第一个增量构件往往实现软件的基本需求。 第二个增量构件提供更完善的编辑和文档生成功能； 第三个增量构件实现拼写和语法检查功能； 第四个增量构件完成高级的页面排版功能。

58 图1.5 增量模型

59 采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。显然，能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点。

60 增量模型的另一个优点是，逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。

61 从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。

62 图1.6 风险更大的增量模型

63 小结 软件的复杂性与重要性与日俱增 为了保证软件的质量和降低制造成本需要一套行之有效的工程方法
目前的软件工程不够成熟，还需要各界人士共同努力 软件质量保证的关键因素是高质量的人才与现代化的管理 开发软件的企业应该根据自己的特点选择适合自己的软件工程方法

64 作业 P22第1、3、6、7题。 预习2.1～2.6。

65 下课了。。。 追求 休息