南京工业大学2024软件工程复习指导

复习要点

注意，关于页数大写为英语教材，小写为中文教材

课程目标

注意：全部都是大题，没有概念题，概念也是揉到这个大题里面的啊，可能是6到7个大题，每个大题里面有有小题

第一章 概述

1. 好的软件有哪些属性P8上方，p5上方

可接受性、可依赖性信息安全性、效率、可维护性（采用那种模型可以比较好的来具备这些属性）

1. 什么是软件工程这个活动

2. 什么样的模型更好去维护？为什么？（偏开放性）

   敏捷开发模型：

   优势：敏捷模型强调快速迭代、持续交付和响应变化。在每次迭代结束后，都会产出可工作的软件，这有助于及时收集反馈并调整方向。由于其高度的灵活性和重视代码质量、测试驱动开发的实践，敏捷团队能够更容易地应对需求变更和进行维护工作。
   为什么：持续的代码重构、短周期的迭代以及强调团队协作和沟通，使得系统维护和进化更加容易。

   迭代增量模型：(即增量式开发)

   优势：迭代增量模型将软件开发过程分为多个小的迭代周期，每个迭代都会完成一部分功能的开发、测试和集成。这种逐步构建的方式使得每个增量都可以视为一个可维护的版本，便于逐步完善和修复问题。
   为什么：分阶段逐步交付和测试减少了大规模系统一次性构建的风险，便于逐步优化和调整，同时保持了系统的可维护性。
   持续集成/持续部署（CI/CD）：

   优势：虽然不是传统意义上的软件开发模型，但CI/CD是一种实践，它强调代码频繁提交、自动构建、测试和部署。这种自动化流程减少了人为错误，确保软件始终处于可部署状态，便于快速修复问题和部署新功能。
   为什么：快速的反馈循环和自动化测试帮助团队迅速识别并解决问题，持续的部署能力使得维护和升级过程更加顺畅。

3. UML模型是掌握的重点

第二章 软件过程

计划驱动和敏捷过程？

1. 四个通用的最基本的软件工程活动，P30,p19

软件规格说明、开发、确认（验证）、演化

1. 几种典型的通用软件过程模型

瀑布、增量式开发、集成和配置

他们是什么？

他们的特点优势适合什么缺陷

1. 瀑布模型的5个阶段：p22上方 计划、分析、设计、编程、测试和维护

   1. 优点：可强迫开发人员采用规范的方法；严格规定了各阶段必须提交的文档；要求每个阶段结束后，都要进行严格的评审
   2. 缺点：缺乏灵活性
   3. 适用于：嵌入式、关键性、大型

2. 增量式开发，具体过程的活动的组织形式。p23图2.2

   1. 优点：p24
   2. 缺点：p24
   3. 适用于：

3. 集成和配置 p25

   1. 优点：p26
   2. 缺点：p26
   3. 适用于：多为软件/构件复用的场景

2.3 软件演化2.2.4 p30。知道什么是软件性质变更change，应对变更的两种模型

2.3.1原型开发

2.3.2 的增量式交付

要掌握：结构、接口、构件、数据库的概念

(可能会和后面的软件测试结合起来，“如何测试：接口、构件？” 这就需要我们掌握这个的概念是什么)

题目大概是，给出软件或者模型，让你去匹配认为哪种适合，并给出合理的解释

或者使用哪种开发过程会比较好（开发过程p？）

更多的考察是为什么

如何设计测试用例是必考的一个内容。（主要的考察还是第八章）

第三章敏捷开发

如果一个软件开发起来比较复杂，就可以采取敏捷开发的手段来进行软件开发

why:

答：复杂的软件对于可维护性的要求比较高，使用敏捷开发维护起来比较简单。

敏捷开发中一个代表性的方法——极限编程（概念，优缺点）

1. 敏捷开发的概念、应用场景和优缺点

   1. 敏捷开发：其核心价值观强调个体与交互重于流程和工具、可工作的软件重于详尽的文档、客户合作重于合同谈判、响应变化重于遵循计划

   2. 优点：

      1. 快速响应变化：通过短周期迭代，能迅速适应市场或客户需求的变化。
      2. 提高产品质量：频繁的测试和用户反馈循环有助于及早发现并解决问题。
      3. 增强团队合作：强调团队成员间的沟通与协作，提升工作效率和士气。
      4. 持续交付价值：每个迭代都能产出可工作的软件，为用户提供即时价值。

   3. 缺点：

      1. 缺乏长期规划：过于关注短期迭代可能忽视项目的整体长远规划。
      2. 管理挑战：对团队自我管理和跨功能协作要求高，不适合所有类型的团队。
      3. 文档可能不足：强调可工作的软件而非详尽文档，可能导致后期维护困难。
      4. 过度灵活的风险：若缺乏明确的方向和边界，过度追求灵活性可能导致项目目标模糊不清。

   4. 应用场景：

      1. 需求频繁变更的项目：当客户需求不明确或经常发生变化时，敏捷开发能够快速适应这些变化

         2. 创新性项目：对于探索性较强的项目，敏捷方法允许团队在不确定的环境中逐步明确方向，通过小步快跑的方式降低风险。

         3. 跨功能团队合作：敏捷强调团队成员之间的紧密协作，包括开发人员、测试人员、产品经理和用户代表等，适合需要多方面专家共同参与的项目。

         4. 互联网和软件开发：特别是Web应用、移动应用等快速迭代的产品，敏捷开发能够快速推出新功能并收集市场反馈。

2. 核心，结合了增量式开发和增量式交付的优点

3. 敏捷开发的基本原则，p41. 极限编程的具体的实践活动 p42

4. p43 图3.5 故事场景描述需求

5. 要知道变更本身是什么含义，和重构refactor p44的关系

6. 要知道怎么去设计测试用例。

   1. 给一个软件
   2. 掌握什么是黑盒测试，什么是白盒测试

第四章需求工程

  1. 给一个明确的软件，去提炼功能性需求和非功能性需求
  2. 系统需求？用户需求？p61
  3. 功能性需求和非功能性需求：p62。三种非功能性需求的类型p64 图4.3 
  4. 故事场景描述需求比如：p72 图4.9 4.10
  5. 描述需求 结构化的模板的方式 p75 图4.13
  6. 还有一个是4.4.3用例模型p77，结合第五章系统模型。。。。需求导出的形式来讲这个用力模型的
  7. 还有个性能需求 performance 
  8. 需求验证 p80

第五章 系统模型

一些名词：

interface 交互 component组件 diagram图 scope范围 constraint约束

  1. UML 统一建模语言
     1. 上下文模型 context models
     2. 交互模型 interaction
     3. 结构模型 structural
     4. 行为模型 behavioral
  2. UML图要掌握，对于 有并发或者分支要怎么处理，还有要有起始节点和终止节点
  3. 绘制图时的一些元素
     1. 节点
     2. 边
  4. 对于绘制类图的时候，只需要做到分析层次

1. 区分，活动模型和这个状态模型别搞混了（图示前者为状态图，后者为活动图）

   

2. UML的几种关系p95

   1. 关联

   2. 聚合

   3. 组合

   4. 泛化（继承的反义词）

   5. 实现

   6. 依赖

      

图例：

Sequence diagram 顺序图：p91 p92

Use Case 用例图：p91

object diagram类图：p94

State diagram 状态图：p98

component diagram 组件图

deployment 展开图 collaboration 协作图

第六章 体系结构模型

  1. 什么是**4+1视图** p109  **逻辑、物理、部署、进程 视图。**
  2. 6.3几种典型的体系结构模式。
     1. MVC模式 ：Model View Controller	
     2. 层模式（所有的功能按层来组织的）
        - 层模式是一种将软件系统划分为若干个水平层的架构方式，每层都具有特定的职责，并且层与层之间通过定义良好的接口相互通信。典型的层次包括：
          - **表示层**：用户界面和用户交互。
          - **业务逻辑层**：处理业务规则和逻辑。
          - **数据访问层**：与数据库或其他持久化存储交互。
          - 可能还包括服务层、基础设施层等。这种模式有利于团队分工合作，提高系统的可维护性和可测试性，但过多的层可能会增加调用延迟。
     3. 仓库模型（6.3.2） 有中心数据库，所有的数据放在中心仓库里面，子系统彼此之间没有直接的联系，只通过中心仓库来获取数据
        - 核心是一个中心数据库或数据仓库，所有子系统都不直接相互通信，而是通过这个中心仓库交换数据。这种模式简化了子系统之间的直接依赖，使得数据一致性得以维护，并且方便了数据的集中管理和分析。但它可能增加数据访问的复杂度和对中心仓库的依赖性，对仓库的性能和可用性要求较高
     4. 管道过滤器（6.3.4）
        - 数据通过一系列的处理单元（过滤器）流动，每个过滤器负责执行特定的数据转换或处理任务。数据通过管道（通常是队列或缓冲区）从一个过滤器传输到下一个。每个过滤器都是独立的，可以独立开发和测试，这使得系统易于扩展和修改。这种模式适用于数据处理流水线、ETL（提取、转换、加载）作业等场景，它的优点在于高度解耦和模块化，但可能因为过多的中间数据存储导致性能损失。
  3. 题目，p122，t6,理解什么是4+1视图，逻辑视图，进程视图掌握一下。（后者这两个就是4+1视图的一部分）

第七章 设计与实现

以一个事例来反映出一个面向对象的设计过程

1. 使用UML来建立面向对象的设计

2. 理解7.1 p126页 这 面向对象设计的活动有哪些？有这五个，这5个活动 的含义？

3. p129 7.1.3 给一个需要设计的系统，能够识别出来对象类

4. p132 序列图 状态图，另外7.1.2p128 页 体系结构图

5. 业务流模型也就是活动图？

   活动图描述活动的顺序，展现从一个活动到另一个活动的控制流。 活动图在本质上是一种流程图。

6. 习题p144 t7.6

第八章 软件测试

1. 测试的几个阶段，p149 图8.3软件测试过程。共三个阶段：

   开发测试 ->发布测试->用户测试

2. 审查和测试的概念与使用场景p148

   • 审查是静态的：代码审查、设计审查、需求审查、测试用例审查
   • 测试是动态的：单元测试、集成测试、系统测试、验收测试、性能测试、安全测试

3. 开发测试

   1. 单元测试 p150

      1. 如何选择测试用例

      2. 黑盒测试方法 等价类划分Partition （有哪些数据属于同一个类）

         将软件视为一个“黑盒子”，仅关注软件的输入数据和输出结果，验证软件功能是否符合需求规格说明书的规定

         等价类通常被分为有效等价类和无效等价类：

         • 有效等价类：指符合软件需求规范的输入数据集合，即那些应该能让软件正常工作的输入。
         • 无效等价类：指不符合软件需求规范的输入数据集合，例如超出范围的值、非法格式的数据等，这些输入应当导致软件以预期的方式（如错误提示）响应

      3. 白盒测试方法的路径测试（结构性测试，根据结构，要做一个路径的覆盖，对于每一个路径设计一个测试用例要求能够覆盖这个路径）

         白盒测试方法中的路径测试是一种结构测试技术，它侧重于通过分析程序的内部结构来设计测试用例，以覆盖程序的所有可能执行路径.确保程序的每一条可执行语句至少被执行一次.

         环路复杂度（Cyclomatic Complexity, V(G)）: 计算控制流图的环路复杂度，这是程序独立路径数量的一个上界。环路复杂度可以通过公式 V(G) = E - N + 2 计算得出，其中E是边的数量，N是节点的数量，P是连通图中的独立节点或终端节点的数量。

      4. 如何去设计上面两个测试用例

   2. 组件测试（构件测试）p153

      1. 把若干个已经测试的单元程序结合起来
      2. 单元程序如果出现问题的话，主要可能出现在单元程序之间，或者说已测程序之间的这个交互
      3. 也要知道如何进行组件测试
      4. （要知道组件测试和接口测试的关系）

   3. 系统测试 p155

      旨在全面验证已完成的系统（包括软件、硬件、网络以及任何外部系统或组件）是否能够满足预定的需求和规范

      包括：功能、性能、安全性、兼容性、压测、回复测试、用户验收、文档测试等

4. 发布测试(Realease Testing)p159

5. 用户测试 p161

6. 测试用例的概念

   是为验证软件系统中的某个具体功能、性能或其它特性是否符合预定需求而精心设计的一套详细的测试方案。测试用例的核心在于它定义了一组明确的测试条件或场景，包括：

   1. 测试目标：明确指出测试用例旨在验证的具体需求或功能点。
   2. 前置条件：执行测试前系统必须处于的状态或需满足的条件。
   3. 输入数据：为测试执行提供的具体数据值或操作序列。
   4. 测试步骤：详细说明执行测试的具体操作流程。
   5. 预期结果：基于需求规格，预先设定的正确输出或系统行为。
   6. 测试环境：描述执行测试所需的软硬件环境和配置。
   7. 测试脚本（可选）：自动化测试中使用的程序代码，用于自动执行测试步骤并验证预期结果。

   测试用例的设计方法主要包括黑盒测试和白盒测试：

   • 黑盒测试：关注软件的外部行为，不考虑内部结构，从用户视角出发设计测试用例。
   • 白盒测试：深入了解软件内部工作原理，根据代码结构和逻辑路径设计测试用例。

   编写测试用例的目的是为了系统化和标准化测试过程，确保软件的每个功能都经过全面且一致的检验，帮助识别和定位问题，提高测试效率和软件质量。测试用例也是测试文档的一部分，它们应当易于理解、维护，并能覆盖所有的需求和边缘情况，以减少测试遗漏，确保软件产品的可靠性。

7. 开发测试 p149 8.1

对于非功能性需求，性能测试Performance testing

1. 同时 8.1.2 p151 选择测试用例方法。掌握等价划分的方法。

2. 发布测试里面的 基于场景测试8.3.2、性能测试8.3.3 p161

当然，让我们以一个简单的登录功能为例来说明黑盒测试中的等价类划分方法。

需求描述：
假设一个网站的登录功能要求用户输入用户名和密码。用户名必须是非空的，且长度在5到15个字符之间。密码必须包含至少一个大写字母、一个小写字母、一个数字，并且长度在8到16个字符之间。

等价类划分：

对于用户名：

1. 有效等价类：

   • 输入长度为5到15个字符的任意字符串（不包括特殊字符，因为具体规则未提及特殊字符，但通常会有限制）。

2. 无效等价类：

   • 空字符串（不符合非空要求）。
   • 小于5个字符的字符串。
   • 超过15个字符的字符串。

对于密码：

1. 有效等价类：

   • 密码长度为8到16个字符，同时包含至少一个大写字母、一个小写字母和一个数字的组合。

2. 无效等价类：

   • 空字符串或少于8个字符的字符串。
   • 超过16个字符的字符串。
   • 缺少大写字母的任何长度合规字符串。
   • 缺少小写字母的任何长度合规字符串。
   • 缺少数字的任何长度合规字符串。
   • 只包含字母或只包含数字的合规长度字符串（不满足混合要求）。

测试用例设计：

基于上述等价类，我们可以设计以下测试用例：

1. 用户名有效等价类测试： 输入一个长度为5的合法字符串作为用户名尝试登录。
2. 用户名无效等价类测试： 输入一个空字符串尝试登录，验证系统是否拒绝登录。
3. 密码有效等价类测试： 输入一个符合所有要求（长度、大写字母、小写字母、数字）的密码尝试登录。
4. 密码无效等价类测试： 输入一个长度为7的密码（少于最小长度要求）尝试登录，验证系统是否拒绝登录。
5. 组合测试： 输入有效用户名和无效密码，以及无效用户名和有效密码，观察系统的响应。

通过这些测试用例，我们能够有效地覆盖各种可能的输入情况，确保登录功能的健壮性，而无需对每一种可能的输入值进行测试，从而提高了测试的效率。

第九章软件演化

(线下没讲这章？)

1. 了解三种维护、软件再工程的概念：
   1. 三种维护 p176： 修正、适应、完善
   2. 软件再工程 p179、逆向工程的概念，有这个概念就可以。

第22章 项目管理

1. p432 可能的风险（要分析出来可能要面临的风险以及原因）

第23章 成本估算

这一章要做好注释，有很多生词

1. p458 cocomoⅡ 成本估算模型（有四个子模型，知道什么时候用哪一个子模型）
   1. Application composition 应用组合模型
   2. Early design model 早期设计模型
   3. Reuse model复用模型
   4. Post-architecture model后体系结构模型

要知道

1. 要知道这个方法（肯定要考的）
2. 习题 23.8 23.9 p406
3. 学了几个公式，PE EV，关于软件成本，一定会考察的\

T23.8

T23.9

17届题目

好的，我会帮助你完成这份软件工程题目。我们一步一步来解决每个问题。以下是对各个题目的解答：

1. 微信首页模块的需求建模和用例描述

用例模型：p77 画小人那个

• 参与者：
  • 用户
• 用例：
  • 查看消息
  • 发送消息
  • 查看好友列表
  • 查看朋友圈
  • 设置

用例描述：

用例名称：查看消息

参与者：用户

前置条件：用户已登录微信并处于首页界面

基本事件流：

1. 用户打开微信首页。
2. 系统展示最近消息列表。
3. 用户点击某条消息。
4. 系统展示该消息的详细内容。

后置条件：用户查看了消息的详细内容。

2. 通过“手机联系人”添加通讯录朋友功能需求

结构化模板描述：p75

• 功能名称：通过手机联系人添加通讯录朋友
• 输入：用户点击“手机联系人”按钮
• 处理：
  1. 系统获取用户的手机联系人列表。
  2. 系统展示手机联系人列表。
  3. 用户选择要添加的联系人。
  4. 系统发送好友请求。
• 输出：显示“好友请求已发送”的消息
• 假设：用户已授权微信访问手机联系人
• 约束：若联系人已是微信好友，系统提示“该联系人已是您的好友”

3. 为“朋友圈”功能设计若干个类，并给出属性和操作

也就是类图的设计

类设计：

• 类名：朋友圈

  • 属性：
    • 动态ID
    • 发布者ID
    • 内容
    • 图片
    • 发布时间
  • 操作：
    • 发布动态()
    • 查看动态()
    • 删除动态()

• 类名：用户

  • 属性：
    • 用户ID
    • 用户名
    • 头像
  • 操作：
    • 查看用户信息()
    • 编辑用户信息()

4. 发朋友圈过程的活动图

开始 -> 点击照相机 -> [选择图片/文字] -> 输入内容 -> 点击发送 -> 发布动态 -> 结束

5. 微信首页测试脚本

测试脚本（场景）：

• 场景：用户登录微信并访问首页
  • 步骤：
    1. 打开微信应用。
    2. 输入账号和密码进行登录。
    3. 检查是否成功进入首页。
    4. 查看消息列表是否显示。
    5. 点击某条消息，检查是否显示详细内容。
    6. 返回首页，检查好友列表是否显示。
    7. 点击“朋友圈”，检查是否进入朋友圈页面。

6. 微信首页模块任务依赖表及条形图

任务依赖表：

• 需求分析 -> 设计 -> 编码 -> 测试

条形图：

|----------------需求分析----------------|
            |----------------设计----------------|
                          |----------------编码----------------|
                                        |----------------测试----------------|

7. 项目建议的软件过程模型及理由

推荐模型：增量模型

理由：

1. 需求的逐步细化：微信的功能复杂，可以通过逐步细化需求，分阶段实现，便于管理。

2. 风险降低：分阶段进行开发和测试，可以及时发现和修复问题，降低风险。

3. 灵活性：可以根据用户反馈进行调整和优化，增加用户满意度。

推荐模型: 敏捷开发模型

• 理由1: 快速响应市场变化，适应社交软件高频迭代的需求。
• 理由2: 强调团队协作和用户反馈循环，提升产品贴合度。
• 理由3: 通过短周期迭代，降低项目风险，提高灵活性。
• 理由4: 支持持续集成和测试，保证软件质量。

一些图例补充

条形图：

顺序图（序列图）

**活动图 **

银行取钱