软件工程考点Word下载.docx

软件工程考点Word下载.docx

《软件工程考点Word下载.docx》由会员分享，可在线阅读，更多相关《软件工程考点Word下载.docx（8页珍藏版）》请在冰豆网上搜索。

②软件工程的中心课题是控制复杂性

③软件经常变化

④开发软件的效率非常重要

⑤和谐地合作是开发软件的关键

⑥软件必须有效地支持它的用户

⑦在软件工程领域中通常由具有一种文化背景的人替另一种文化背景的人创造产品

3、软件工程的7条基本原理

①用分阶段的生命周期计划严格管理

②坚持进行阶段评审

③实行严格的产品控制

④采用现代程序设计技术

⑤结果应能清楚地审查

⑥开发小组的人员应该少而精

⑦承认不断改进软件工程实践的必要性

4、软件工程方法学

软件工程方法学包含3个要素：

方法、工具和过程。

1传统方法学：

传统方法学也称为生命周期方法学或结构化范型。

它采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的应用。

2面向对象方法学：

面向对象方法学具有下述4个要点

（1）把对象作为融合了数据及在数据上的操作行为的统一的软件构件

（2）把所有对象都划分成类

（3）按照父类（或称为基类）与子类（或称为派生类）的关系，把若干个相关类组成一个层次结构的系统（也称为类等级）

（4）对象彼此间仅能通过发送消息互相联系

快速原型模型（优缺点）

概念：

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

优点：

快速原型模型是不带反馈环的。

软件产品的开发基本上是线性顺序进行的。

原因：

①原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求。

②开发人员通过建立原型系统已经学到了许多东西，所以在设计和编码阶段发生错误的可能性小。

缺点：

①为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。

②为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。

③开发过程不便于管理。

第七章

测试步骤P151

1模块测试（单元测试）：

目的是保证每个模块作为一个单元能正确运行。

在这个测试步骤中所发现的往往是编码和详细设计的错误。

（单元）

2子系统测试：

把经过单元测试的模块放在一起形成一个子系统来测试。

模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。

（局部）

3系统测试：

把经过测试的子系统装配成一个完整的系统来测试。

在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。

在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。

无论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。

（集成）

4验收测试（确认测试）：

验收测试的目的是验证系统确实能够满足用户的需求，在这个测试步骤中发现的往往是系统需求说明书中的错误。

（用户参与）

5平行运行：

同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。

这样做的具体目的如下：

（新旧共存）

（1）可以在准生产环境中运行新系统而又不冒风险

（2）用户能由一段熟悉新系统的时间

（3）可以验证用户指南和使用手册之类的文档

（4）能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标

自底向上集成

（详见书P158）

测试概念（黑盒测试着重测试软件功能）P171

1、黑盒测试力图发现下述类型的错误：

（1）功能不正确或遗漏了功能

（2）界面错误

（3）数据结构错误或外部数据库访问错误

（4）性能错误

（5）初始化和终止错误

2、等价划分法

（1）划分等价类（划分出等价类以后，根据等价类设计预测方案时主要使用下面两个步骤）

（2）设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖位置

（3）设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止

3、边界值分析法

按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值的数据作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。

4、错误推测法

错误推测法在很大程度上靠直觉和经验进行。

它的基本思想是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案。

第八章

可维护性复审

1、“可维护性要做点什么”

在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；

应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面

在正是和非正式的设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；

设计中应该对将来可能修改的部分预作准备

代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素

在设计和编码过程中应该尽量使用可重用的软件构件，如果需要开发新的构件，也应该注意提高构件的可重用性。

2、提高可维护性的方法

①建立明确的软件质量目标和优先级

②使用提高软件质量的技术和工具

③进行明确的质量保证审查

④选择可维护的程序设计语言

⑤修改程序的文档

3、在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。

--维护应该针对整个软件配置，不应该只修改源程序代码。

当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果--每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。

不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。

---用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。

如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用用户因为受挫折而产生不满

4、决定软件可维护性的因素：

可理解性、可测试性、可修改性、可移植性、可重用性

5、文档是影响软件可维护性的决定因素。

分用户文档与系统文档

第十章

画事件跟踪图

事件跟踪图有助于画状态图。

它把事件序列以及事件与对象的关系，形象、清晰地表示出来。

事件跟踪图实质上是扩充的脚本，是简化的UML顺序图。

在事件跟踪图中，一条竖线代表一个对象，每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接收对象。

时间从上向下递增

第十二章

1、代码重用

一种是本项目内的代码重用，另一种是新项目重用旧项目的代码

2、准则

1提高方法的内聚：

一个方法（即服务）应该只完成单个功能，否则把它分解成几个更小的方法

2减小方法的规模：

把规模过大的方法（代码长度超过一页纸）分解成几个更小的方法

3保持方法的一致性：

功能相似的方法应该有一致的名字、参数特征、返回值类型、使用条件及出错条件等

4把策略与现实分开：

（1）策略方法：

负责做出决策，提供变元，并且管理全局资源

应该检查系统运行状态，并处理出错情况，它们并不直接完成计算或实现复杂的算法。

策略方法通常紧密依赖于具体应用，这类方法比较容易编写，也比较容易理解

（2）实现方法：

负责完成具体操作，但却并不做出是否执行这个操作的决定，也不知道为什么执行这个操作

仅仅针对具体数据完成特定处理，通常用于实现复杂的算法。

实现方法并不制定决策，也不管理全局资源，如果在执行过程中发现错误，它们应该只返回执行状态而不对错误采取行动。

由于实现方法是自含式算法，相对独立于具体应用，因此，在其他应用系统中也可能重用它们。

PS：

为提高可重用性，在编程时不要把策略和实现放在同一个方法中，应该把算法的核心部分放在一个单独的具体实现方法中

5全面覆盖

6尽量不使用全局信息

7利用继承机制

（1）调用子过程

（2）分解因子

（3）使用委托

（4）把代码封装在类中

课程管理系统用例图、类图：

测试用例

第七章PPT85-106页P98报表题考的概率很大