---

---

1.题型

软件工程：

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

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

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

综合题（3题，共30分）

---

---

2.知识点

知识点：

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

详见50124总体设计

 

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

 

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

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

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

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

 

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

 

 

---

2、耦合有哪些类型，各有何特点/strong>

详见50124总体设计

 

耦合的类型

nbsp;        内容耦合　　强

nbsp;        公共耦合　　|

nbsp;        控制耦合　　|

nbsp;        标记耦合　　↓

nbsp;        数据耦合　　弱

 

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

 

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

 

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

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

 

公共耦合：

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

要使用全局变量

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

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

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

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

 

内容耦合

容耦合的三种情况:

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

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

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

 

 

 

---

3、常用软件过程有哪几种，各有何特点/strong>

详见5011软件工程_软件工程学概述

#1瀑布模型

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

3. 质量保证的观点
    每个阶段都应坚持两个重要做法：
（1） 每个阶段都必须完成规定的文档。
（2） 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

 

#2快速原型模型

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

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

 

#3增量模型

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

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

维护时期反馈环很小。

 

#4 螺旋模型

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

 

#5喷泉模型

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

优点：
提高开发效率
缩短开发周期

缺点：难于管理

 

---

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

详见5011软件工程_软件工程学概述

 

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

 

 

 

---

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

 

详见50124总体设计

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

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

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

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

      宽度越大系统越复杂。对宽度影响最大的因素是模块的扇出。

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

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

    通常是3或4(上限是5～9)。

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

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

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

 

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

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

    系统的模块结构呈现为“葫芦形”。

 

 

图6.5 PAD图的基本符号

 

PAD图的主要优点如下：

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

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

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

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

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

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

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

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

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

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

 

示例

 

 

---

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

详见50126实现

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

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

按照IEEE的规定

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

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

 

---

17、程序设计语言有哪三种类型，各有何特点/strong>

详见50126实现

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

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

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

 

---

18、软件调试方法有哪些/strong>

 

详见50126实现

 

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

探法

溯法

分查找法

纳法

绎法

 

1.试探法

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

 

2. 回溯法

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

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

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

 

3.对分查找法

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

 

4.归纳法

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

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

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

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

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

 

5.演绎法

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

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

    ①设想所有可能产生错误的原因。

    ②利用已有的数据排除不正确的假设。

    ③精化剩下的假设。

    ④证明假设的合理性，根据假设排除故障。

 

 

---

19、白盒测试与黑盒测试各有哪些方法/strong>

 

详见50126实现

 

白盒测试的主要方法

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

基本路径测试

 

黑盒测试技术：

价划分

界值分析

 

 

---

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

 

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

继承性

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

 

 

---

21、什么是软件危机/strong>

 

详见5011软件工程_软件工程学概述

 

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

 

 

---

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

 

详见5011软件工程_软件工程学概述

 

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

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

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

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

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

    
2. 面向对象方法学
    当软件规模庞大，或者对软件的需求是模糊的，或软件需求会随时间而变化的时候，使用传统方法学开发软件往往不成功。
    此外，使用传统方法学开发出的软件，维护起来仍然很困难。
原因：
    这种技术要么面向行为(即对数据的操作)，要么面向数据，把数据和操作人为地分离成两个独立的部分，自然会增加软件开发与维护的难度。

面向对象方法学具有下述4个要点。
(1) 把对象(object)作为融合了数据及在数据上的操作行为的统一的软件构件。用对象分解取代了传统方法的功能分解。
(2) 把所有对象都划分成类(class)。
(3) 父类与子类的继承关系。
    把若干个相关类组成一个层次结构的系统，下层派生类自动拥有上层基类中定义的数据和操作。
(4) 对象彼此间仅能通过发送消息互相联系。
        对象的所有私有信息都被封装在该对象内，不能从外界直接访问，这就是通常所说的封装性。

 

 

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

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

 

---

23、实体联系图如何绘制nbsp; ###

详见50123需求分析 3.4

 

 

---

24、需求分析阶段应该使用哪几种模型对系统进行建模/strong>

 

详见50123需求分析

 

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

数据模型

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

功能模型

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

行为模型

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

 

 

---

25、软件维护有哪些类型/strong>

 

详见50127维护

 

四种维护类型：

 改正性维护

 适应性维护

 完善性维护

  预防性维护

 

1.改正性维护

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

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

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

 

2.适应性维护

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

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

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

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

 

3.完善性维护

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

善性维护：

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

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

 

4.预防性维护

防性维护：

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

防性维护的定义：

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

 

国外的统计数字表明：

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

改正性维护占17%～21%，

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

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

 

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

可见：

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

 

 

---

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

 P本金和利息

 S利率

 n年

 R利息

非复利：第n年本金和利息 P=A*S%*n+A

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

 

 

---

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

 

详见50126实现

 

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

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

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

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

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

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

软件测试准则

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

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

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

    在完成需求模型时，就着手制定测试计划，

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

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

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

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

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

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

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

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

类型

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

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

 

---

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

 

详见50126实现 7.6.1

 

 

---

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

 

详见50125详细设计  6.5

 

 

---

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

 

详见50125详细设计

 

图13.5 主程序员组的结构

 

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

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

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

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

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

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

首先，如前所述，主程序员应该是高级程序员和优秀管理者的结合体

来源：weixin_30835923