CAIE AS and A Level CS revision - Unit 12 (2nd)

【点此返回复习要点目录】

如遇到公式加载异常，请刷新页面！

Unit 12 Software Development 软件开发

12.1 Program Development Life cycle 程序开发生命周期

• 大纲要求

12.1.1 Show understanding of the purpose of a development life cycle 表现出对开发生命周期目的的理解

• Program Development Life cycle：程序开发生命周期。对程序进行开发需要经过多个阶段，包括analysis分析、design设计、coding编码、testing测试、maintenance维护等过程。当维护无法实现当前问题的解决时，将重新进行分析，由此构成开发闭环。如下图所示：

• • Analysis：分析阶段。在该阶段，程序员需要明确编写的程序用于解决哪类问题，寻找出一种或多种解决方案，并对这些方案进行比较。寻找解决方案时，可以选择自下而上，由一个小问题出发，推广到整个问题，也可以选择自上而下，通过结构型语言或流程图将问题逐步拆解。
  • Design：设计阶段。为解决方案中的步骤挑选合适的程序解决方法，比如采用何种数据类型、何种数据结构、使用哪些变量等。
  • Coding：编码阶段。使用高级语言对设计好的方案进行编程。在编程前需要权衡各种语言的优缺点，选择最适合的语言进行编程。在编程前可以进行伪代码的编写，然后将伪代码换成程序代码。
  • Testing：测试阶段。写好的程序可能存在错误无法运行，或者虽然运行但给出错误结果，这都需要在一遍遍的测试中发现并纠正。
  • Maintenance：维护阶段。程序已经正常投入使用，但随着使用又会发现新的问题需要修正，则需要进行维护。

12.1.2 Show understanding of the need for different development life cycles depending on the program being developed 了解不同开发生命周期的需求，具体取决于正在开发的程序

Including: waterfall, iterative, rapid application development (RAD) 包括：瀑布式、迭代式、快速应用开发（RAD）

• 根据正在开发的程序的特点，可以选择不同的开发生命周期模式。常见的模式如下：
  • Waterfall model：瀑布式模型。进行完一个阶段后再进入下一个阶段，在进入下一阶段时发现还缺少相关内容，则需要返回上一阶段进行补充。示意图如下图所示。

• • • 瀑布式模型的好处：
• 阶段明确，易于理解。
• 每个阶段都是连续的，且都有特定的结果，易于管理。
• 适用于要求和开发过程清晰的小型项目。
  • • 瀑布式模型的缺点：
• 直到生命周期的后期才生成软件，不利于尽早识别潜在的问题，也不利于测试。
• 不适用于复杂的、长期的和面向对象的项目。
• 无法适应不断变化的需求。
• 很难衡量各个阶段过程中的进度。

• • Iterative model：迭代模型。该模型从一个小问题的解决出发，一步步扩展解决范围，直到达成解决最终问题。示意图如下图所示：

• • • 迭代模型的好处：
• 在开发的早期阶段就有了系统的working model工作模型，更容易发现功能或设计缺陷，便于及时纠正错误。
• 一些工作功能可以在生命周期的早期快速开发。
• 早期就能获得一定成果且可以定期更新。软件提早生产，便于客户评估和反馈。
• 可以并行开发，进度可控，风险可控（比如先攻克难点）。
• 修改程序需求或使用范围的成本更低。
• 一小部分程序的调试更加容易。
• 每次扩展后都能够生成可供使用的程序，且能够不断学习和积累经验，从上一次扩展中识别到的问题可用于下一次扩展。
• 更适合大型和关键任务项目。
  • • 迭代模型的缺点：
• 只有大型软件开发项目才能更好地受益。（因为小型软件很难再细分。）
• 可能会出现设计问题，因为并非所有需求都能在开发生命周期开始时想到。
• 有时候进行扩展时也会涉及到整个程序的修改。

• • Rapid Application Development (RAD) model：快速应用开发模型，注重快速拿出成果。程序的每个组成部分都通过反复的用户测试来满足需求，然后将组成部分拼起来形成最终的产品，以达到快速出成果的效果。示意图如下图所示：

• • • RAD模型的好处：
• 可以适应不断变化的要求。
• 进展可控。
• 短时间内就能提高开发效率，减少开发时间。
• 提高组件的再利用。
• 可进行快速初步审查。
• 鼓励客户反馈。
• 从一开始就不断以组合形式呈现，避免了后期才组合而导致的一系列问题。
  • • RAD模型的缺点：
• 只有能够模块化的系统才能使用 RAD 构建。
• 需要熟练的开发人员。
• 适用于基于组件和可扩展的系统。
• 需要用户参与整个生命周期。
• 适用于需要短开发时长的项目。

12.1.3 Describe the principles, benefits and drawbacks of each type of life cycle 描述每种生命周期的原理、优点和缺点

• 【参考12.1.2】。

12.1.4 Show understanding of the analysis, design, coding, testing and maintenance stages in the program development life cycle 了解程序开发生命周期中的分析、设计、编码、测试和维护阶段

• 【参考12.1.1】。

12.2 Program Design 程序设计

• 大纲要求

12.2.1 Use a structure chart to decompose a problem into sub-tasks and express the parameters passed between the various modules / procedures / functions which are part of the algorithm design 使用结构图将问题分解为子任务，表达算法设计的各个模块/程序/函数之间传递的参数

Describe the purpose of a structure chart 描述结构图的用途
Construct a structure chart for a given problem 针对给定问题构建结构图
Derive equivalent pseudocode from a structure chart 从结构图中导出等效伪代码

• structure chart：结构图，用于表示各个模块之间关系的图像。
  • 结构图中常见的符号说明：
    • 方形：独立的一个模块。
    • 线段：模块之间存在关系。
    • 由下向上指的箭头：将参数从低级别的模块传递到高级别的模块。
    • 由上向下指的箭头：将参数从高级别的模块传递到低级别的模块。
    • 尾部空心的箭头：普通数值传递。
    • 尾部实心的箭头：布尔值传递。（用于标记）
    • 菱形：选择结构。
    • 弧状箭头：循环结构。
    • 双向箭头：数值在模块中会发生更新。

• • 顺序执行的结构图示意图：

• • 选择结构的结构图示意图：

• • 循环结构的结构图示意图：

12.2.2 Show understanding of the purpose of state-transition diagrams to document an algorithm 理解状态转移图记录算法的目的

• state-transition diagram：状态转移图，指描述程序输入数值后的状态变化的图像。
  • 程序可看作是finite state machine（FSM）有限状态机，即给出一个输入值后能够使得程序从一种状态变为另一种状态。描述状态变化的表称为state-transition table状态转移表，描述状态变化的图像称为称为state-transition diagram状态转移图。
  • 状态转移图中常见的符号说明：
    • 圆形：状态。
    • 双圈圆形：final state最终状态（或称halting state中止状态）。
    • Start与实心尾部箭头：由指向的状态作为初始状态。
    • 箭头：由尾部的状态变为箭头所指的状态。
    • 环状箭头：状态未发生变化。
    • 单数值：输入值。
    • 数值|数值：竖线前面是输入值，竖线后面是输出值。
  • 输入值后的状态转移图示意图：

• • • 图中表示由S1状态为初始。
    • 当状态为S1时，输入a则S1状态不变；输入b则S1状态变为S2状态。
    • 当状态为S2时，输入a则S1状态变为S2状态；输入b则S2状态不变。

• • 带有输出值的状态转移图示意图：

• • • 图中表示由S1状态为初始。
    • 当状态为S1时，输入a则S1状态不变，输出e；输入b则S1状态变为S2状态，输出c。
    • 当状态为S2时，输入a则S1状态变为S2状态，输出d；输入b则S2状态不变，输出f。

12.3 Program Testing and maintenance 程序测试与维护

• 大纲要求

12.3.1 Show understanding of ways of exposing and avoiding faults in programs 理解发现和避免程序中错误的方法

• 程序出现错误的常见原因：
  • 程序员编写代码时出错。
  • 未正确制定requirement specification需求规约（指对系统需求的规范化描述）。
  • 软件设计师在进行程序设计时出错。
  • 用户界面设计不佳，导致用户出现误操作。
  • 计算机硬件故障。

• 发现程序错误的途径：
  • 最终用户向开发者报告。（该途径容易对开发者声誉造成影响）
  • 开发过程中进行内部testing测试。（可通过IDE界面提示、运行时提示或反复检查等方式查找错误并修改）

• 避免程序中出现错误的方法：
  • 使用已经测试过的程序设计方法，比如结构化编程或面向对象设计。
  • 使用合适的标识符表、数据结构和标准算法。
  • 使用程序库内已经测试过的模块或对象。

12.3.2 Locate and identify the different types of errors 定位和识别不同类型的错误

syntax errors 语法错误
logic errors 逻辑错误
run-time errors 运行时错误

• syntax errors：语法错误，指在编写代码时因为没有遵循高级语言的语法规则而导致的错误。在IDE界面上会使用波浪线画出可能的语法错误并给出说明，不过有些语法错误可能只会在编译或解释时才会注意到。
  • 注意：如果一个程序成功编译或解释，则此时已经不存在语法错误了。
• logic errors：逻辑错误，指在程序设计中出现的逻辑问题，导致程序并没有按照预定的运行方式进行。
  • 注意：本错误仅在运行时才有可能被发现，但如果运行时并没有调用到错误的代码，可能也不会被发现。需要仔细检查和反复调试。
• run-time errors：运行时错误，指导致程序在运行过程中出现crash崩溃或freeze死循环的错误。
  • 注意：本错误仅在运行时才有可能被发现，但如果运行时并没有调用到错误的代码，可能也不会被发现。需要仔细检查和反复调试。

12.3.3 Correct identified errors 更正已识别的错误

• 如果是syntax error语法错误，则根据IDE界面、编译器或解释器的提示进行修改，直到错误提示消失。
• 如果是logic error逻辑错误或运行时错误，则需要仔细检查和反复调试，以使程序按照预定方式运行。

12.3.4 Show understanding of the methods of testing available and select appropriate data for a given method 了解可用的测试方法并为给定方法选择适当的数据

Including dry run, walkthrough, white-box, black-box, integration, alpha, beta, acceptance, stub 包括dry run、walkthrough、white-box、black-box、integration、alpha、beta、acceptance、stub

• Dry run testing（Walkthrough testing）：试运行测试，又称遍历测试，指通过trace table追踪表和变量值观测来判断程序中是否存在问题的测试。
  • 测试方式：测试人员利用追踪表，每执行一步就记录下所有的变量值，以检查变量值的变化情况是否符合预期。如果不符合，则排查相关错误。追踪表如下图所示：

• White-box testing：白盒测试，指查看程序输出结果是否符合预期，整个过程可以看到源代码的测试。
  • 测试方式：测试人员可以看到源代码，并根据源代码的逻辑结构设计测试数据，每条路径都应至少测试一次。输入数据，根据输出结果判断程序是否按照预期向下执行。如果出现与预期不符的情况则排查错误。
• Black-box testing：黑盒测试，指查看程序输出结果是否符合预期，但整个过程中看不到源代码的测试。
  • 测试方式：测试人员根据程序的实际作用说明来设计测试数据，其间看不到源代码，并计算出预期结果。然后调用程序，输入测试数据，看输出的数据是否和预计的相符。如果不相符，则其中的代码一定有问题，需要进行修改。
• Integration testing：整合测试，指将众多模块汇总在一起时进行的测试。一般来说，此时各个模块已经通过了单独测试，内部没有问题，但组合在一起时却可能出错。
  • 测试方式：通常以incremental testing增量测试的形式展开，在原有程序的基础上增加一个新模块后运行程序，看是否存在错误。如果存在问题则排查该模块。
• Alpha testing：alpha测试，指软件在发布给用户之前，由软件测试人员在内部进行的测试。
• Beta testing：beta测试，指软件发布给潜在用户，潜在用户们在他们的计算机上运行，并将遇到的问题反馈给软件设计者，以便设计者对软件进行修改。
• Acceptance testing：验收测试，指为特定用户编写的软件在交给对方时进行的测试。软件的接收方需要检测设计好的软件是否满足他们的要求，以及其中是否存在运行问题。如果有问题则反馈给软件设计者，要求其修改。
• Stub testing：存根测试，主要用于测试相关模块是否被正常调用。在具体程序开始编写之前，可以通过存根测试来检测模块的设计是否合理、是否按照预期设想进行调用，避免在写完后进行大规模调整。如下图所示：
  • 测试方式：通过在每个模块中放入一个输出语句以证实该模块被调用。当主程序调用了该模块时，则会输出相应的语句。

12.3.5 Show understanding of the need for a test strategy and test plan and their likely contents 表现出对测试策略和测试计划的需求及其可能内容的理解

• test strategy and test plan：测试策略与测试计划。软件测试时，需要制定合适且详尽的测试策略与计划，确保涵盖尽可能多的运行路径和结果，找到尽可能多的问题。
  • 注意：大型项目和程序很可能无法做到一点错误没有，但同样需要严格测试，找到尽可能多的问题。

12.3.6 Choose appropriate test data for a test plan 为测试计划选择合适的测试数据

Including normal, abnormal and extreme/boundary 包括正常、异常和极端/边界

• 常见的测试值包括以下三类设计：
  • Normal data：正常值。该数值是很普通的数值，用于验证在大多数情况下程序运行是否正常。
  • Abnormal data：异常值，也称为错误值。该数值不符合输入或运行要求，程序应当不接受该数值。
  • Extreme data (boundary data)：极限值，也称为边缘值。该数值是介于normal和abnormal边界线上的数值。这些数值可以检验软件是否考虑到了特殊情况的处理。
    • 注意：一些特殊情况下的值也应当考虑。

12.3.7 Show understanding of the need for continuing maintenance of a system and the differences between each type of maintenance 了解系统持续维护的必要性以及每种维护类型之间的差异

Including perfective, adaptive, corrective 包括完善型、适应型、矫正型

• Perfective maintenance：完善性维护，指程序运行良好但仍有改进空间的维护。
  • 必要性：通过一些细节的改进，能够使得程序能够更加有效率地运行。
• Adaptive maintenance：适应性维护，指为程序增加一些最初设计时没有的功能的维护。
  • 必要性：很多程序不可能从一开始就涵盖所有的功能，随着时间推移，用户对程序有了更多要求，需要通过适应性维护逐渐添加进去。
• Corrective maintenance：修正性维护，指修正程序错误的维护。
  • 必要性：程序的有些地方可能不常使用，或者有些错误不明显，在发现错误后需要通过修正性维护尽快纠正，以减少用户的损失。

12.3.8 Analyse an existing program and make amendments to enhance functionality 分析现有程序并进行修改以增强功能

• 【参考Unit 12】。