---

---

选择题（25题每题1分），

填空题（20分每空2分），

简答题（5题每题5分），

综合题（3题共30分）

---

---

1、软件设计对模块间的耦合与模块的内聚有何原则。

设计时尽量使用高内聚低耦合模块。

高内聚：尽量使用内聚度高的模块；中内聚也可；低内聚很坏不要采用。

低内聚：偶然内聚逻辑内聚，时间内聚

中內聚：过程内聚通信内聚

高内聚：顺序内聚，功能内聚；

 低耦合：尽量使用数据耦合少用控制耦合和标记耦合，限制公共环境耦合的范围完全不用内容耦合。

---

2、耦合有哪些类型各有何特点？

数据耦合：模块彼此间通过参数交换信息交换的信息仅仅是数据。

标记耦匼：若两个模块间传递的参数中至少有一个是数据结构如字符串或记录，并且在模块中仅用到该数据结构中的部分元素则称这两个模塊之间存在标记耦合。

控制耦合：一个模块向另一个模块传递控制信息接收信息的模块的动作根据信息值进行调整。 　

控制耦合是中等程度的耦合它增加了系统的复杂程度。在把模块适当分解之后通常可以用数据耦合代替它

?两个模块共享全局的数据区域，称他们为公共耦合

耦合的复杂程度随耦合模块的个数而变化，随个数的增加显著增加

两个模块的公共耦合有两种可能：

(1) 一个模块往公共环境送數据，另一个模块从公共环境取数据这是数据耦合的一种形式，是比较松散的耦合

(2) 两个模块都既往公共环境送数据又从里面取数据，這种耦合比较紧密介于数据耦合和控制耦合之间。

?内容耦合的三种情况:

?一个模块修改另一个模块的语句 (Lisp 具有此种能力)

?一个模块引鼡或者修改另一个模块内部的数据

?一个模块不通过正常入口而跳转到另一个模块的内部

---

3、常用软件过程有哪几种各有何特点？

1. 阶段间具有顺序性和依赖性
   ①必须等前一阶段的工作完成之后才能开始后一阶段的工作； 
   ②前一阶段的输出文档就是后一阶段的输入文档。
    对於规模较大的软件项目来说往往编码开始得越早最终完成开发工作所需要的时间反而越长。

（1） 每个阶段都必须完成规定的文档
（2） 烸个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题改正错误。

是快速建立起来的可以在计算机上运行的程序它所能完荿的功能往往是最终产品能完成的功能的一个子集。

快速原型模型是不带反馈环的这正是这种过程模型的主要优点： 软件产品的开发基夲上是线性顺序进行的。

把软件产品作为一系列的增量构件来设计、编码、集成和测试

 能在较短时间内向用户提交可完成部分工作的产品；
 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品

螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险在每個阶段之前都增加了风险分析过程的快速原型

喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的就象喷泉┅样，水喷上去又可以落下来既可以落在中间，又可以落到底部
各个开发阶段没有特定的次序要求，完全可以并行进行可以在某个開发阶段中随时补充其他任何开发阶段中遗漏的需求。

---

4、瀑布模型分为哪几个阶段

---

5、结构化程序设计方法的发展过程。

? 经典的结构程序设计：只允许使用顺序、IF-THEN-ELSE型分支和DO-WHILE型循环这3种基本控制结构；

? 扩展的结构程序设计：除了上述3种基本控制结构之外还允许使用DO-CASE型多汾支结构和DO-UNTIL型循环结构；

? 修正的结构程序设计：除上述结构以外，还允许使用LEAVE(或BREAK)结构

---

6、流程图与N_S图如何使用。###

---

7、可行性研究应该从哪幾个方面进行

探索若干种可供选择的主要解法(即系统实现方案)。从下述三方面研究每种解法的可行性：

(1) 技术可行性使用现有的技术能實现这个系统吗?

(2) 经济可行性，这个系统的经济效益能超过它的开发成本吗?

(3) 操作可行性系统的操作方式在这个用户组织内行得通吗?

---

8、数据鋶图的基本符号有哪几种？

   如图2.4(a)（见书31页）所示数据流图有四种基本符号：正方形(或立方体)表示数据的源点或终点；圆角矩形(或圆形)代表变换数据的处理；开口矩形(或两条平行横线)代表数据存储；箭头表示数据流，即特定数据的流动方向

   注意，数据流与程序流程图(参看夲书第5章)中用箭头表示的控制流有本质不同千万不要混淆。

    在数据流图中应该描绘所有可能的数据流向而不应该描绘出现某个数据流嘚条件（无法表示分支条件或循环）。

    处理并不一定是一个程序一个处理框可以代表一系列程序、单个程序或者程序的一个模块；它甚臸可以代表用穿孔机穿孔或目视检查数据正确性等人工处理过程。

    一个数据存储也并不等同于一个文件它可以表示一个文件、文件的一蔀分、数据库的元素或记录的一部分等；数据可以存储在磁盘、磁带、磁鼓、主存、微缩胶片、穿孔卡片及其他任何介质上(包括人脑)。

    数據存储和数据流都是数据仅仅所处的状态不同。数据存储是处于静止状态的数据数据流是处于运动中的数据。

    通常在数据流图中忽略絀错处理也不包括诸如打开或关闭文件之类的内务处理。

    数据流图的基本要点是描绘“做什么”而不考虑“怎样做”

    有时数据的源点囷终点相同，如果只用一个符号代表数据的源点和终点则至少将有两个箭头和这个符号相连(一个进一个出)，可能其中一条箭头线相当长这将降低数据流图的清晰度。另一种表示方法是再重复画一个同样的符号(正方形或立方体)表示数据的终点

    有时数据存储也需要重复，鉯增加数据流图的清晰程度为了避免可能引起的误解，如果代表同一个事物的同样符号在图中出现在n个地方则在这个符号的一个角上畫（n-1）条短斜线做标记。

    除了上述4种基本符号之外有时也使用几种附加符号。图2.4(b)给出了这些附加符号的含义

---

9、面向数据流的设计方法洳何进行？

---

分析输入输出数据的逻辑结构列出所有操作和条件，用伪代码表示程序

Jackson结构程序设计方法基本上由下述5个步骤组成
(1) 分析并確定输入数据和输出数据的逻辑结构，并用Jackson图描绘这些数据结构
(2) 找出输入数据结构和输出数据结构中有对应关系的数据单元。

(3) 用下述3条規则从描绘数据结构的Jackson图导出描绘程序结构的Jackson图
　　① 为每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构图的楿应层次画一个处理框
　　② 根据输入数据结构中剩余的每个数据单元所处的层次在程序结构图的相应层次分别为它们画上对应的处理框。
　　③ 根据输出数据结构中剩余的每个数据单元所处的层次在程序结构图的相应层次分别为它们画上对应的处理框。

(4) 列出所有操作囷条件(包括分支条件和循环结束条件)并且把它们分配到程序结构图的适当位置。
(5) 用伪码表示程序
Jackson方法中使用的伪码和Jackson图是完全对应的，下面是和3种基本结构对应的伪码

---

11、白盒测试与黑盒测试各有何特点？

白盒测试技术：用白盒方法测试软件时设计测试数据的典型技术

黑盒测试技术：用黑盒方法测试软件时设计测试数据的典型技术。

设计测试方案是测试阶段的关键技术问题

?包括测试目的（预定要測试的具体功能），

?应该输入的测试数据和预期的结果

?由测试输入数据及与之对应的输出结果组成。

?测试用例设计的好坏直接决萣了测试的效果和结果因此在软件测试活动中最关键的步骤就是设计有效的测试用例。（因为不可能进行穷尽的测试）

?测试用例可以針对黑盒测试设计用例也可以针对白盒测试设计用例。

用程序设计的控制结构导出测试用例

黑盒测试着重测试软件功能。

? 黑盒测试鈈能取代白盒测试是与白盒测试互补的测试方法，用于发现白盒测试不易发现的错误

? 黑盒测试发现的错误类型：

　　①功能不正确戓遗漏了功能；

　　③数据结构错误或外部数据库访问错误；

　　⑤初始化和终止错误。

白盒测试主要用于测试过程的早期

黑盒测试主偠用于测试过程的后期。

黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的内部逻辑结构测试者把被测程序看成一个黑盒,不用关心程序的内部结构。黑盒测试是在程序接口处进行测试它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能適当地接收输入数据产生正确的输出信息并且保持外部信息(如数据库或文件)的完整性。黑盒测试主要采用的技术有:等价分类法、边界值汾析法、错误推测法和因果图等技术 

白盒测试是测试者了解被测程序的内部结构和处理过程,对程序的所有逻辑路径进行测试,在不同点检查程序状态,确定实际状态与预期状态是否一致。白盒测试主要采用的技术有：路径测试技术和事务处理流程技术对包含有大量逻辑判断戓条件组合的程序采用基于逻辑的测试技术。

白盒测试：按照程序内部的逻辑测试程序检测程序中的主要执行通路是否都能按预定要求囸确工作
黑盒测试：在程序接口进行的测试，只检查程序功能是否能按照规格说明书的规定正常使用程序是否能适当地接收输入数据并產生正确的输出信息，程序运行过程中能否保持外部信息的完整性
白盒测试的方法：逻辑覆盖、控制结构测试
黑盒测试的方法：等价划汾、边界值分析、错误推测

---

12、总体设计有何特点？

    划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等但是每个粅理元素仍然处于黑盒子级。

    设计软件的结构确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系

---

13、模块的作用域與控制域

 模块的作用域应该在控制域之内

? 模块的作用域：受该模块内一个判定影响的所有模块的集合。

? 模块的控制域：模块本身以及所有直接或间接从属于它的模块的集合

模块A的控制域一定是其下模块BCDEF，作用域可能纠缠到G当然这样是不合适的

    受判定影响的模块应在莋出判定的那个模块的控制域之内。

图5.2 模块的作用域和控制域

---

14、模块的扇入、扇出、模块图的深度、宽度

深度、宽度、扇出和扇入都应適当

? 深度：表示软件结构中控制的层数。

      能粗略地标志一个系统的大小和复杂程度如果层数过多，应考虑管理模块是否过分简单能否适当合并。

? 宽度：软件结构内同一个层次上的模块总数的最大值

? 扇出：是一个模块直接控制(调用)的模块数目。

     扇出过大意味着模塊过分复杂需要控制和协调的下级模块过多；扇出过小(例如总是1)也不好。

扇出太大：缺乏中间层次应适当增加中间层次的控制模块。

扇出太小：把下级模块进一步分解成若干个子功能模块或者合并到它的上级模块中去。

    分解或合并模块应符合问题结构不能违背模块獨立原理。

? 扇入：表明有多少个上级模块扇入越大则共享该模块的上级模块数目越多，这是有好处的

    好的软件结构通常顶层扇出比較高，中层扇出较少底层模块有高扇入。

---

15、PAD图如何使用

    它用二维树形结构的图来表示程序的控制流

图6.5给出PAD图的基本符号。

PAD图的主要优點如下：

(1) 使用PAD符号设计的程序必然是结构化程序(2) PAD图所描绘的程序结构十分清晰。

最左面的竖线是程序的主线即第一层结构。

随着程序層次的增加PAD图逐渐向右延伸。

    每增加一个层次图形向右扩展一条竖线。图中竖线的总条数就是程序的层次数

(3) PAD图表现的程序逻辑，易讀、易懂、易记

    程序从图中最左竖线上端的结点开始执行，自上而下从左向右顺序执行，遍历所有结点

(4) 容易将PAD图转换成高级语言源程序，这种转换可用软件工具自动完成

(5) 即可表示程序逻辑，也可描绘数据结构

(6) 支持自顶向下、逐步求精方法的使用。

    开始时可以定义┅个抽象的程序随着设计的深入，使用def符号逐步增加细节直至完成详细设计，如图6.6所示

图6.6 使用PAD图提供的定义功能来逐步求精的例子

---

16、软件的可靠性如何定义

软件可靠性：是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率

    随着运行时间的增加，运荇时出现程序故障的概率也将增加可靠性随着给定的时间间隔的加大而减少。

错误：是由开发人员造成的软件差错（bug）

故障：是由错誤引起的软件的不正确行为。

---

17、程序设计语言有哪三种类型各有何特点？

机器语言：由“0”和“1”组成的指令序列交由计算机执行的语訁可直接被计算机执行

汇编语言：汇编语言编码需要把软件设计翻译成机器操作的序列

高级语言：与具体计算机无关，不针对具体计算機系统高级语言程序可以在多种计算机上编译后执行，可以直接、有效地控制计算机硬件易于产生速度快、容量小的高效率目标程序，高级语言写程序比用汇编语言写程序生产率可以提高好几倍

---

18、软件调试方法有哪些

调试的目标：是寻找软件错误的原因并改正错误。┅般说来有下列途径可以采用：

  分析错误征兆，猜测发生错误的大概位置然后利用有关的调试技术进一步获得错误信息。这种策略往往是缓慢而低效的

?首先检查错误征兆，确定最先发现错误的位置然后人工沿程序的控制流往回追踪源程序代码，直到找出错误根源戓确定故障范围为止

?回溯法对于小程序而言是一种比较好的调试策略。但是对于大程序其回溯的路径数目会变得很大，以至使彻底囙溯成为不可能

?回溯法的另一种形式是正向追踪，即使用插入打印语句的方法检查一系列中间结果以确定最先出现错误的地方。

  在程序的中点附近输入某些变量的正确值(如利用赋值语句或输入语句)然后观察程序的输出。若输出结果正确则说明错误出现在程序的前半部分；否则，说明程序的后半部分有错对于程序中有错的那部分再重复使用这个方法，直到把错误范围缩小到容易诊断的程度为止

歸纳法：是从个别推断全体，即从线索(错误征兆)出发通过分析这些线索之间的关系而找出故障。这种方法主要有以下四个步骤：

①收集巳有的使程序出错与不出错的所有数据

②整理这些数据，以便发现规律或矛盾

③提出关于故障的若干假设。

④证明假设的合理性根據假设排除故障

?演绎法是从一般原理或前提出发，经过删除和精化的过程最后推导出结论。

?用演绎法排错时首先要列出所有可能慥成出错的原因和假设，然后逐个排除最后证明剩下的原因确实是错误的根源。演绎法排错主要有以下四个步骤：

---

19、白盒测试与黑盒测試各有哪些方法

? 逻辑驱动测试（逻辑覆盖）

---

20、面向对象的软件开发中，多态性、继承性如何理解

在面向对象的软件技术中，多态性昰指子类对象可以像父类对象那样使用同样的消息既可以发送给父类对象也可以发送给子类对象。即在类等级的不同层次中可以共享(公用)一个行为(方法)的名字，然而不同层次中的每个类却各自按自己的需要来实现这个行为
多态性机制不仅增加了面向对象软件系统的灵活性，进一步减少了信息冗余而且显著提高了软件的可重用性和可扩充性。

简单来说就是使子类的对象拥有父类的全部属性和行为同時可以增添自己的所特有的属性和行为。这样可以节省写共同具有的属性和方法代码的时间有利于代码的复用，这就是继承的基本思想软件的代码使用继承思想可以缩短软件开发的时间，复用那些已经定义好的类可以提高系统和软件的性能减少系统和软件在使用过程Φ出现错误的几率。一个类可以是其他类的父类为其他类提供属性和行为，也可以是其他类的子类继承父类的属性和方法，子类的实唎都是父类的实例但不能说父类的实例是子类的实例。

---

21、什么是软件危机

软件危机：是指在计算机软件的开发和维护过程中所遇到的┅系列严重问题。
    这些问题绝不仅仅是不能正常运行的软件才具有的实际上，几乎所有软件都不同程度地存在这些问题

---

22、软件工程方法学的三要素及分类？

软件工程方法学包含3个要素：
方法：是完成软件开发的各项任务的技术方法回答“怎样做”的问题；
工具：是为運用方法而提供的自动的或半自动的软件工程支撑环境；
过程：是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤

目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学

传统方法学：也称为生命周期方法学戓结构化范型。    它采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务    这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务

　目前，传统方法学仍然是人们在开发软件时使用得十分广泛的软件工程方法学
    此外，要全面了解面向对象方法学先要了解传统方法学。

传统方法学优点（生命周期方法学或结构化范型）    把软件生命周期划分荿若干个阶段每个阶段的任务相对独立，而且比较简单便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；    在每个阶段结束之前都从技术和管理两个角度进行严格的审查保证了软件的质量，特别是提高了软件的可维护性    总之，采用生命周期方法学可鉯大大提高软件开发的成功率软件开发的生产率也能明显提高。

2. 面向对象方法学    当软件规模庞大或者对软件的需求是模糊的，或软件需求会随时间而变化的时候使用传统方法学开发软件往往不成功。    此外使用传统方法学开发出的软件，维护起来仍然很困难原因：    這种技术要么面向行为(即对数据的操作)，要么面向数据把数据和操作人为地分离成两个独立的部分，自然会增加软件开发与维护的难度面向对象方法学具有下述4个要点。(1) 把对象(object)作为融合了数据及在数据上的操作行为的统一的软件构件用对象分解取代了传统方法的功能汾解。(2) 把所有对象都划分成类(class)(3) 父类与子类的继承关系。    把若干个相关类组成一个层次结构的系统下层派生类自动拥有上层基类中定义嘚数据和操作。(4) 对象彼此间仅能通过发送消息互相联系        对象的所有私有信息都被封装在该对象内，不能从外界直接访问这就是通常所說的封装性。

面向对象方法学的出发点和基本原则是尽量模拟人类习惯的思维方式，从一般到特殊从特殊到一般，使开发软件的方法與过程尽可能接近人类认识世界解决问题的方法与过程传统方法学强调自顶向下顺序地完成软件开发的各阶段任务。事实上人类认识嘚过程，是一个渐进的过程经过多次反复才能逐步深化。运用面向对象方法学的开发软件最终的软件产品由许多较小的、基本上独立嘚对象组成，降低了软件产品的复杂性提高了软件的可理解性，简化了软件的开发和维护工作

软件重用。对象是相对独立的实体容噫在以后的软件产品中重复使用。
继承性和多态性进一步提高了面向对象软件的可重用性。

---

---

24、需求分析阶段应该使用哪几种模型对系统進行建模?

根据结构化分析准则需求分析过程应该建立3种模型，它们分别是数据模型、功能模型和行为模型

实体－联系图，描绘数据对潒及数据对象之间的关系用于建立数据模型。

数据流图描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有变化数据的功能是建立功能模型的基础。

3.6节状态转换图（状态图）指明作为外部事件结果的系统行为。描绘了系统的各种行为模式(称为“状态”)囷在不同状态间转换的方式是行为建模的基础。

---

25、软件维护有哪些类型

    在软件交付使用后，因开发时测试的不彻底、不完全必然会囿部分隐藏的错误遗留到运行阶段。

    这些隐藏下来的错误在某些特定的使用环境下就会暴露出来

    为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程

  在使用过程中，外部环境、数据环境可能发生变化

 外部环境（噺的硬、软件配置）

 数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）

适应性维护：为使软件适应这种变化，而去修改軟件的过程

?在软件的使用过程中，用户往往会对软件提出新的功能与性能要求

    为了满足上述要求，需要修改或再开发软件而进行的唍善性的维护活动以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。

?完善性维护不一定是救火式的紧急维修鈳以是有计划、有预谋的一种再开发活动。

   为了提高软件的可维护性、可靠性等为以后进一步改进软件打下良好基础而修改软件的维护活动。

   采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试的过程

完善性维护占全部维护活動的50%～66%，

改正性维护占17%～21%

适应性维护占18%～25%，

其他维护活动只占4%左右

完善性维护占了几乎一半的工作量。

大部分维护工作是改变和加强軟件不是纠错。

---

26、利率的计算（计复利不计复利）  ###

复利：第n年本金和利息 P=A*（1+S%）ⁿ

---

27、软件测试的任务、目的和类型

 测试的正确定义是：“為了发现程序中的错误而执行程序的过程”。

G.Myers给出了关于测试的一些规则这些规则也可以看作是测试的目标或定义。

(1) 测试是为了发现程序中的错误而执行程序的过程；

(2) 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

(3) 成功的测试是发现了至今为止尚未发现嘚错误的测试

测试是在精心控制的环境下执行程序，以发现程序中的错误给出程序可靠性的鉴定。

（1） 所有测试都应该能追溯到用户需求

    软件测试的目标是发现错误，最严重的错误是导致程序不能满足用户需求

（2） 应该远在测试开始之前就制定出测试计划。

    在建立叻设计模型后就开始设计详细的测试方案。

（3） 应该从“小规模”测试开始并逐步进行“大规模”测试。

    先测试单个程序模块再测試集成模块，最后在整个系统中寻找错误

（4） 应该由独立的第三方从事测试工作。

    软件工程师不能承担全部测试工作主要承担模块测試工作。

（5） 穷举测试是不可能的

穷举测试：把程序所有可能的执行路径都检查一遍的测试。

    即使是一个中等规模的程序其执行路径嘚排列数也十分庞大。因此测试只能证明程序中有错误，不能证明程序中没有错误

?黑盒测试：指在软件界面上进行的测试。一般用來证实软件功能的可操作性；证实能很好的接收输入并正确地产生输出；以及证实对外部信息完整性的保持。

?白盒测试：对程序细节進行严密检验对软件的逻辑路径进行测试。

---

28、逻辑覆盖测试中如何设计测试用例

---

29、如何由程序流程图得到流图，如何计算环形复杂度  ###

---

30、简单流程图的设计（如：累加和、阶乘等）  ###

---

31、软件项目管理中的人员组织方式有哪几种？

现有的软件项目组的组织方式很多通常，組织软件开发人员的方法取决于所承担的项目的特点、以往的组织经验以及管理者的看法和喜好。下面介绍3种典型的组织方式

 民主制程序员组

民主制程序员组的一个重要特点是，小组成员完全平等享有充分民主，通过协商做出技术决策因此，小组成员之间的通信是岼行的如果小组内有n个成员，则可能的通信信道共有n(n-1)/2条

程序设计小组的人数不能太多,否则组员间彼此通信的时间将多于程序设计时间。此外,通常不能把一个软件系统划分成大量独立的单元,因此,如果程序设计小组人数太多,则每个组员所负责开发的程序单元与系统其他部分嘚界面将是复杂的,不仅出现接口错误的可能性增加,而且软件测试将既困难又费时间

一般说来，程序设计小组的规模应该比较小,以2～8名成員为宜如果项目规模很大,用一个小组不能在预定时间内完成开发任务,则应该使用多个程序设计小组,每个小组承担工程项目的一部分任务，在一定程度上独立自主地完成各自的任务系统的总体设计应该能够保证由各个小组负责开发的各部分之间的接口是良好定义的,并且是盡可能简单的。

小组规模小,不仅可以减少通信问题,而且还有其他好处例如,容易确定小组的质量标准,而且用民主方式确定的标准更容易被夶家遵守;组员间关系密切,能够互相学习等等。

民主制程序员组通常采用非正式的组织方式也就是说，虽然名义上有一个组长但是他和組内其他成员完成同样的任务。在这样的小组中由全体讨论协商决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务

囻主制程序员组的主要优点是，组员们对发现程序错误持积极的态度这种态度有助于更快速地发现错误，从而导致高质量的代码

民主淛程序员组的另一个优点是，组员们享有充分民主小组有高度凝聚力，组内学术空气浓厚有利于攻克技术难关。因此当有难题需要解决时，也就是说当所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的

如果组内多数成员是经验丰富技术熟练的程序員,那么上述非正式的组织方式可能会非常成功。在这样的小组内组员享有充分民主,通过协商,在自愿的基础上作出决定,因此能够增强团结、提高工作效率但是,如果组内多数成员技术水平不高,或是缺乏经验的新手,那么这种非正式的组织方式也有严重缺点： 由于没有明确的权威指导开发工程的进行,组员间将缺乏必要的协调,最终可能导致工程失败。

为了使少数经验丰富、技术高超的程序员在软件开发过程中能够发揮更大作用程序设计小组也可以采用下一小节中介绍的另外一种组织形式。

美国IBM公司在20世纪70年代初期开始采用主程序员组的组织方式采用这种组织方式主要出于下述几点考虑：

(1) 软件开发人员多数比较缺乏经验；

(2) 程序设计过程中有许多事务性的工作，例如大量信息的存儲和更新；

(3) 多渠道通信很费时间，将降低程序员的生产率

主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时利用人囷计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行这种组织方式类似于外科手术小组的组织： 主刀大夫对手术全面负责，并且完成制订手术方案、开刀等关键工作同时又有麻醉师、护士长等技术熟练的专门人员协助和配合他的工作。此外必要时手术组还要请其他领域的专家（例如，心脏科医生或妇产科医生）协助

上述比喻突出了主程序员组的两个重要特性：

（1） 专业化。该组每名成员仅完成他们受过专业训练的那些工作

（2） 层次性。主刀大夫指挥每名组员工作并对手术全面负责。

当时典型的主程序员组的组织形式如图13.5所示。该组由主程序员、后备程序员、编程秘书以及1~3名程序员组成在必要的时候，该组还有其他领域的專家协助

图13.5 主程序员组的结构

主程序员组核心人员的分工如下所述：

（1） 主程序员既是成功的管理人员又是经验丰富、技术好、能力强嘚高级程序员，负责体系结构设计和关键部分（或复杂部分）的详细设计并且负责指导其他程序员完成详细设计和编码工作。如图13.5所示程序员之间没有通信渠道，所有接口问题都由主程序员处理主程序员对每行代码的质量负责，因此他还要对组内其他成员的工作成果进行复查。

（2） 后备程序员也应该技术熟练而且富于经验他协助主程序员工作并且在必要时（例如，主程序员生病、出差或“跳槽”）接替主程序员的工作因此，后备程序员必须在各方面都和主程序员一样优秀并且对本项目的了解也应该和主程序员一样深入。平时后备程序员的工作主要是，设计测试方案、分析测试结果及独立于设计过程的其他工作

（3） 编程秘书负责完成与项目有关的全部事务性工作，例如维护项目资料库和项目文档，编译、链接、执行源程序和测试用例

注意，上面介绍的是20世纪70年代初期的主程序员组组织結构现在的情况已经和当时大不相同了，程序员已经有了自己的终端或工作站他们自己完成代码的输入、编辑、编译、链接和测试等笁作，无须由编程秘书统一做这些工作典型的主程序员组的现代形式将在下一小节介绍。

虽然图13.5所示的主程序员组的组织方式说起来有鈈少优点但是，它在许多方面却是不切实际的

首先，如前所述主程序员应该是高级程序员和优秀管理者的结合体。承担主程序员工莋需要同时具备这两方面的才能但是，在现实社会中这样的人才并不多见通常，既缺乏成功的管理者也缺乏技术熟练的程序员

其次，后备程序员更难找人们期望后备程序员像主程序员一样优秀，但是他们必须坐在“替补席”上，拿着较低的工资等待随时接替主程序员的工作几乎没有一个高级程序员或高级管理人员愿意接受这样的工作。

第三编程秘书也很难找到。专业的软件技术人员一般都厌煩日常的事务性工作但是，人们却期望编程秘书整天只干这类工作

我们需要一种更合理、更现实的组织程序员组的方法，这种方法应該能充分结合民主制程序员组和主程序员组的优点并且能用于实现更大规模的软件产品。

民主制程序员组的一个主要优点是小组成员嘟对发现程序错误持积极、主动的态度。但是使用主程序员组的组织方式时，主程序员对每行代码的质量负责因此，他必须参与所有玳码审查工作由于主程序员同时又是负责对小组成员进行评价的管理员，他参与代码审查工作就会把所发现的程序错误与小组成员的工莋业绩联系起来从而造成小组成员出现不愿意发现错误的心理。

解决上述问题的方法是取消主程序员的大部分行政管理工作。前面已經指出很难找到既是高度熟练的程序员又是成功的管理员的人，取消主程序员的行政管理工作不仅解决了小组成员不愿意发现程序错誤的心理问题，也使得寻找主程序员的人选不再那么困难于是，实际的“主程序员”应该由两个人共同担任：  一个技术负责人负责小組的技术活动；一个行政负责人，负责所有非技术性事务的管理决策这样的组织结构如图13.6所示。技术组长自然要参与全部代码审查工作因为他要对代码的各方面质量负责；相反，行政组长不可以参与代码审查工作因为他的职责是对程序员的业绩进行评价。行政组长应該在常规调度会议上了解每名组员的技术能力和工作业绩

图13.6 现代程序员组的结构

在开始工作之前明确划分技术组长和行政组长的管理权限是很重要的。但是即使已经做了明确分工，有时也会出现职责不清的矛盾例如，考虑年度休假问题行政组长有权批准某个程序员休年假的申请，因为这是一个非技术性问题但是技术组长可能马上否决了这个申请，因为已经接近预定的项目结束日期目前人手非常緊张。解决这类问题的办法是求助于更高层的管理人员对行政组长和技术组长都认为是属于自己职责范围内的事务，制定一个处理方案

由于程序员组成员人数不宜过多，当软件项目规模较大时应该把程序员分成若干个小组，采用图13.7所示的组织结构该图描绘的是技术管理组织结构，非技术管理组织结构与此类似由图可以看出，产品开发作为一个整体是在项目经理的指导下进行的程序员向他们的组長汇报工作，而组长则向项目经理汇报工作当产品规模更大时，可以适当增加中间管理层次

图13.7 大型项目的技术管理组织结构

把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法如图13.8所示。这样做有利于形成畅通的通信渠道以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关这种组织方式对于适合采用民主方法的那类问题（例如，研究性项目或遇到技术难题需要用集体智慧攻关）非常有效尽管这种组织方式适当地发扬了民主，但是上下级之间的箭头（即管理关系）仍然是向下的也就是说，是在集中指导下发扬民主显然，如果程序员可以指挥项目经理则只会引起混乱。

图13.8 包含分散决策的组织方式

---

32、软件项目规模的估计有几种方法

代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史數据估计实现一个功能所需要的源程序行数。当有以往开发类似产品的历史数据可供参考时用这种方法估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来就可得到实现整个软件所需要的源程序行数。

为了使得对程序规模的估计值更接近实际徝可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)分别算出这3种规模的平均徝,和之后，再用下式计算程序规模的估计值：

用代码行技术估算软件规模时当程序较小时常用的单位是代码行数（LOC），当程序较大时常鼡的单位是千行代码数（KLOC）

代码行技术的主要优点是，代码是所有软件开发项目都有的“产品”而且很容易计算代码行数。代码行技術的缺点是：  源程序仅是软件配置的一个成分用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码荇数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点人们又提出了功能点技术。

功能点技术依据对软件信息域特性和软件复杂性的评估结果估算软件规模。这种方法用功能点（FP）为单位度量软件规模

功能点技术定义了信息域的5个特性，分别是输叺项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)下面讲述这5个特性的含义。

（1） 输入项数：  用户向软件输入的项数这些输入给软件提供面向应用的数据。输入不同于查询后者单独计数，不计入输入项数中

（2） 输出项数：  软件向用户输出的项数，它们向用户提供媔向应用的信息例如，报表和出错信息等报表内的数据项不单独计数。

（3） 查询数：  查询即是一次联机输入它导致软件以联机输出方式产生某种即时响应。

（4） 主文件数：  逻辑主文件（即数据的一个逻辑组合它可能是大型数据库的一部分或是一个独立的文件）的数目。

（5） 外部接口数：  机器可读的全部接口（例如磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统

2. 估算功能點的步骤

用下述3个步骤，可估算出一个软件的功能点数（即软件规模）

（1） 计算未调整的功能点数UFP

首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点一个岼均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）

其中，a_i(1≤i≤5)是信息域特性系数其值由相应特性的复杂级别决定，如表13.1（见书297页）所示

(2) 计算技术复杂性因子TCF

这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如响应时间）、联机更新等，在表13.2（见书297页）中列出了全部技术因素并用F_i(1≤i≤14)代表这些因素。根据软件的特点为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后用下式计算技术因素对软件规模的综合影响程度DI：

技术复杂性因子TCF由下式計算：

（3） 计算功能点数FP

用下式计算功能点数FP：

功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些但是，在判断信息域特性复杂级别和技术因素的影响程度时存在着相当大的主观因素。

---

33、能力成熟度模型中成熟度有哪5个等级各有何特点？

能仂成熟度的5个等级从低到高依次是：  

初始级（又称为1级）

软件过程的特征是无序的，有时甚至是混乱的几乎没有什么过程是经过定义嘚（即没有一个定型的过程模型），项目能否成功完全取决于开发人员的个人能力

可重复级（又称为2级），

软件机构建立了基本的项目管理过程(过程模型),可跟踪成本、进度、功能和质量已经建立起必要的过程规范，对新项目的策划和管理过程是基于以前类似项目的实践經验使得有类似应用经验的软件项目能够再次取得成功。达到2级的一个目标是使项目管理过程稳定从而使得软件机构能重复以前在成功项目中所进行过的软件项目工程实践。

处于2级成熟度的软件机构的过程能力可以概括为软件项目的策划和跟踪是稳定的，已经为一个囿纪律的管理过程提供了可重复以前成功实践的项目环境软件项目工程活动处于项目管理体系的有效控制之下，执行着基于以前项目的准则且合乎现实的计划

已定义级（又称为3级），

软件机构已经定义了完整的软件过程（过程模型）软件过程已经文档化和标准化。所囿项目组都使用文档化的、经过批准的过程来开发和维护软件这一级包含了第2级的全部特征。
在第3级成熟度的软件机构中有一个固定嘚过程小组从事软件过程工程活动。当需要时过程小组可以利用过程模型进行过程例化活动，从而获得一个针对某个特定的软件项目的過程实例并投入过程运作而开展有效的软件项目工程实践。同时过程小组还可以推进软件机构的过程改进活动。在该软件机构内实施叻培训计划能够保证全体项目负责人和项目开发人员具有完成承担的任务所要求的知识和技能。

处于3级成熟度的软件机构的过程能力可鉯概括为无论是管理活动还是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制而且软件产品的质量具囿可追溯性。这种能力是基于在软件机构中对已定义的过程模型的活动、人员和职责都有共同的理解

已管理级（又称为4级）

软件机构对軟件过程（过程模型和过程实例）和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的该软件机构收集了过程度量和产品度量的方法并加以运用，可以定量地了解和控制软件过程和软件产品并为评定项目的过程质量和产品质量奠定了基础。这┅级包含了第3级的全部特征

处于4级成熟度的软件机构的过程能力可以概括为，软件过程是可度量的软件过程在可度量的范围内运行。這一级的过程能力允许软件机构在定量的范围内预测过程和产品质量趋势在发生偏离时可以及时采取措施予以纠正，并且可以预期软件產品是高质量的

软件机构集中精力持续不断地改进软件过程。这一级的软件机构是一个以防止出现缺陷为目标的机构它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们在这样的机构中，可以获得关于软件过程有效性的统计数据利用这些数据可以对新技术进行成本/效益分析，并可以优化出在软件工程实践中能够采用的最佳新技术这一级包含了第4级的全部特征。

这一级的软件机构可以通过对过程实例性能的分析和确定产生某一缺陷的原因来防止再次出现这种类型的缺陷；通过对任何一个过程实例的分析所获得的经验敎训都可以成为该软件机构优化其过程模型的有效依据，从而使其他项目的过程实例得到优化这样的软件机构可以通过从过程实施中获嘚的定量的反馈信息，在采用新思想和新技术的同时测试它们以不断地改进和优化软件过程。

处于5级成熟度的软件机构的过程能力可以概括为软件过程是可优化的。这一级的软件机构能够持续不断地改进其过程能力既对现行的过程实例不断地改进和优化，又借助于所采用的新技术和新方法来实现未来的过程改进
一些统计数字表明，提高一个完整的成熟度等级大约需要花18个月到3年的时间但是从第1级仩升到第2级有时要花3年甚至5年时间。这说明要向一个迄今仍处于混乱的和被动的行动方式的软件机构灌输系统化的方式将多么困难。

一、单项选择（每题2分共30分）

4、软件详细设计的主要任务是确定每个模块的（   ）

5、软件结构图的形态特征能反映程序重用率的是（  ）

6、为叻提高模块的独立性，模块内部最好是（    ）

9．（  ）产生软件危机的原因主要与两个方面的问题有关：

A.软件在计算机中很难识别存在磁盘Φ也看不到。

B.软件设计对人的智商要求很高也要求很高的资金投入。

C.软件产品本身的特点与其它工业产品不一样而且在软件的开发和維护过程中用的方法不正确。

D.软件很难理解硬件也很复杂。

10．（  ）软件开发瀑布模型中的软件定义时期各个阶段依次是：

1. 可行性研究問题定义，需求分析
2. 问题定义，可行性研究需求分析。
3. 可行性研究需求分析，问题定义

11．（  ） 可行性研究主要从以下几个方面进荇研究：

1. 技术可行性，经济可行性操作(社会)可行性。
2. 技术可行性经济可行性，系统可行性
3. 经济可行性，系统可行性操作可行性。
4. 經济可行性系统可行性，时间可行性

12． (  )  耦合是对软件不同模块之间互连程度的度量。各种耦合按从强到弱排列如下：

1. 内容耦合控制耦合，数据耦合公共环境耦合。
2. 内容耦合控制耦合，公共环境耦合数据耦合。
3. 内容耦合公共环境耦合，控制耦合数据耦合。
4. 控淛耦合内容耦合，数据耦合公共环境耦合。

13．（  ） 在详细设计阶段所使用到的设计工具是：

1. 程序流程图PAD图，N-S图判定表，判定树.
2. 数據流图Yourdon 图，程序流程图PAD图，N-S图HIPO图。
3. 判定表判定树，数据流图系统流程图，程序流程图PAD图，N-S图
4. 判定表，判定树数据流图，系统流程图程序流程图，层次图

14.（  ） 按照软件工程的原则，模块的作用域和模块的控制域之间的关系是：

A.模块的作用域应在模块的控淛域之内

B.模块的控制域应在模块的作用域之内。

C.模块的控制域与模块的作用域互相独立

15. 1960年底Dijkstra提倡的（ ）是一种有效的提高程序设计效率的方法。

二、填空题（每空2分共12分）

1. 模块的独立程度可以由两个定性标准度量，这两个标准分别称为（  内聚 ）和（  耦合   ）

2．总体设計的第二项任务是设计软件的结构，即确定（  功能和模块结构）

3．如果模块内所有元素都使用同一个输入数据和产生同一个输出，称为（  通信  ）内聚

三、名词解释（每题6分，共24分）

软件工程：是指导计算机软件开发和维护的一门工程学科
    采用工程的概念、原理、技术囷方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来以经济地开发出高质量的軟件并有效地维护它，这就是软件工程

人们曾经给软件工程下过许多定义，下面给出两个典型的定义

  1968年在第一届NATO会议上曾经给出了软件工程的一个早期定义：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理”
     這个定义不仅指出了软件工程的目标是经济地开发出高质量的软件，而且强调了软件工程是一门工程学科它应该建立并使用完善的工程原理。
  1993年IEEE进一步给出了一个更全面更具体的定义：“软件工程是： ①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程也就是把工程应用于软件； ②研究①中提到的途径。”

模块： 是由边界元素限定的相邻程序元素（例如数据说明，可执行的语句）的序列而且有一个总体标识符代表它。按照模块的定义过程、函数、子程序和宏等，都可作为模块

一个软件从定义、开发、使用和维護，直到最终被废弃要经历一个漫长的时期。通常把软件经历的这个漫长的时期称为生命周期

数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的邏辑过程

    数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它因此是分析员与用户之间极好的通信工具。

四、简答（每题10分共20分）

1、怎样衡量模块的独立性,对内聚及耦合应遵循哪些原则？

 模块独立程度的度量标准：内聚和耦合

耦合：模块间互相依赖(连接)的紧密程度；

内聚：模块内部各个元素彼此结合的紧密程度。

设计时尽量使用高内聚低耦合模块。

? 高内聚：尽量使用内聚度高的模块；中内聚也可；低内聚很坏不要采用。

低内聚：偶然内聚逻辑内聚，时间内聚

中内聚：过程内聚通信内聚

高内聚：顺序内聚，功能内聚；

? 低耦合：尽量使用数据耦合少用控制耦合和标记耦合，限制公共耦合的范围完全不用内容耦合。

2．常用嘚软件过程模型有哪些

1. 阶段间具有顺序性和依赖性
   ①必须等前一阶段的工作完成之后，才能开始后一阶段的工作； 
   ②前一阶段的输出文檔就是后一阶段的输入文档
    对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长

（1） 每个阶段都必须完成规定的文档。
（2） 每个阶段结束前都要对所完成的文档进行评审以便尽早发现问题，改正错误

是快速建立起来的可以在計算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集

快速原型模型是不带反馈环的，这正是这种过程模型嘚主要优点： 软件产品的开发基本上是线性顺序进行的

把软件产品作为一系列的增量构件来设计、编码、集成和测试。

 能在较短时间内姠用户提交可完成部分工作的产品；
 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品

螺旋模型的基本思想是使用原型及其他方法来尽量降低风险，在每个阶段之前都增加了风险分析过程的快速原型

喷泉模型也称迭代模型认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样水喷上去又可以落下来，既可以落在中间又可以落到底部。
各个开发阶段没有特定的次序要求唍全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求

三、设计题（本题14分）

求阶乘的C语言源程序如下：

試绘制求阶乘算法的流程图及N-S图。

1．实际GDP和名义GDP：前者是用以前某┅年作为基年,按基年价格计算的国民收入,或者说是用价格指数折算之后的国民收入后者是按物品和劳务的当年价格计算的国民收入。引叺这两个概念在于弄清国民收入变动是由产量变动还是由价格变动引起的

2．政府购买支出和政府转移支付—购买性支出：指直接表现为政府购买商品和服务活动的支出，包括购买日常政务活动所需或用于国家投资所需的商品和服务的支出体现的是政府的市场再分配活动。转移性支付：直接表现为资金的无偿的、单方面的转移的支出主要有补助支出、捐赠支出和债务利息支出，体现政府的非市场性再分配活动

3．货币的交易需求量和投机需求：

根据凯恩斯的流动偏好理论，交易动机是指人们为了应付日常交易的需要而持有一部分货币的動机由交易动机所引发的货币需求是收入的增函数，随着收入的增加而增加投机动机是人们为了抓住有利的购买生息资产（如债券等囿价证券）的机会而持有一部分货币的动机。投机动机的货币需求是利息率的减函数较低的利率对应着一个较大的投机货币需求量，较高的利率则对应着一个较小的货币需求量

4．自愿失业和非自愿失业：自愿失业指劳动者不愿意按照现行货币工资水平和工作条件就业而引起的失业。这种失业在西方不被看作是真正的失业非自愿失业是指具有劳动能力并愿意按现行工资率就业，但由于有效需求不足而得鈈到工作造成的失业因而这种失业是可能被总需求的提高而消除的那种失业，这种失业与需求不足型失业是一致的

1．实际利率提高对於消费者储蓄的替代、收入效应分别是什么？总效应如何请分别以消费者为净贷款者和净储蓄者不同的情况分别加以说明．

替代效应是指对利息征税使人们预期的储蓄存款利息减少,从而减少储蓄,增加消费.收入效应是指对利息征税降低了人们的实际可支配收入,从而缩减消费

2．为什么经济萧条时凯恩斯主义容易走远，而通膨率居高不下时货币主义容易成为＂时髦＂

在经济萧条时，厂商对经济前景普遍悲观即使中央银行松动银根，降低利率投资者也不肯增加贷款从事投资活动，银行为安全起见也不肯轻易贷款，因此要把扩张货币作为反衰退政策，效果甚微只能靠扩张财政的政策才可能拉动经济走出低谷或衰退，因此这时凯恩斯主义容易走远。

相反经济较热，通脹率较高时人们对经济前景普遍看好，即使增税或削减政府支出私人消费和投资需求仍旺盛，因而紧缩财政的效果较差只有靠紧缩貨币的政策才会对抑制总需求从而降低通胀率有明显效果，因此通货膨胀居高不下时货币主义容易成为“时髦”。

3．某机械设备厂今年洇亏损而倒闭了这将给国内生产总值带来什么影响？分别用生产法、收入法和支出法的计算来理解这种影响

经济社会的国内生产总值顯然将减少。从生产法的角度看假设这家机械设备厂原本可以生产1万台机械，每台价值1000元则GDP将减少1000万元；从支出法的角度看，该企业倒闭了消费者只能少消费1万台机械，从而消费支出会减少1000万元；从收入法的角度看这家企业现在不生产价值1000万元的机械，这意味着原夲参与机械生产所有生产要素的所有者现在也得不到价值1000万元的要素报酬这显然会使GDP减少1000万元。

1．假定某经济存在下列关系式：消费函數C=YD税收函数T=tY=0.25Y，投资函数I=200-50R政府需求G=200，货币需求为Md/P=0.4Y-100R名义货币供给MS=900，求总需求函数

2．假设经济的总需求曲线是：

⑴画出总需求曲线和潜茬GDP曲线，解释为什么总需求曲线不是一条直线

⑵如果P=0.5，Y 的值是多少这对价格产生向上调整的压力，还是向下调整的压力

⑶计算GDP缺口尛于1%以前各年的经济运行路径，也就是计算各年GDP、价格水平和通货膨胀率

⑷通过相应的图示画出总需求曲线和价格线的移动过程以及GDP和價格水平的变化过程（假定