软件工程基础（WHUT）-复习习题整理

m0_75257028

已于 2024-06-25 11:22:02 修改

阅读量15

点赞数

文章标签：软件工程

于 2024-06-15 00:00:18 首次发布

本文链接：https://blog.csdn.net/m0_75257028/article/details/139692044

版权

软件工程复习：

第一章概述

软件工程概述

知识点：

软件及其特性、软件危机
1. 软件：程序+数据+文档
  - 程序：计算机可以接受的一系列指令，运行时可以提供所要求的功能和性能。
  - 数据：使得程序能够适当地操作信息的数据结构。
  - 文档：描述程序的研制过程、方法和使用的图文资料。
2. 软件特性：
  - 复杂性：（有很多的组成部分）
  - 一致性：（必须遵从人为的惯例并适应已有的技术和系统，软件需要随接口的不同而改变，随时间的推移而变化，而这些变化是不同的人设计的结果，许多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。）
  - 可变性：（它需要随着应用、硬件、用户和社会等各种因素的变化而不断的被修改和扩展。）
  - 不可见性：（软件是客观世界空间和计算机空间之间的一种逻辑实体，不具有物理的形体特征。）
3. 软件危机：在计算机软件的开发和维护过程中所遇到的一系列严重问题
  1. 表现：
    1. 对软件开发成本和进度的估计常常很不准确
    2. 用户对“已完成的“软件系统不满意的现象经常发生
    3. 软件产品的质量往往靠不住
    4. 软件常常是不可维护的
    5. 软件通常没有适当的文档资料
    6. 软件成本在计算机系统总成本中所占的比例逐年上升
    7. 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势
  2. 原因：
    1. 软件本身独有的特点确实给开发和维护带来了困难
    2. 与软件开发和维护的许多错误认识和做法的形成有关
    3. 程序只是完整软件的一个组成部分
    4. 轻视是一个最大的错误
  3. 解决方法：
    - 软件开发需要解放思想
    - 软件开发需要借鉴前人成果
    - 软件开发应该发明和使用更好的软件工具
    - 软件开发需要推广实践经验
软件工程的基本要素、基本目标
1. 基本要素：软件工程以关注软件质量为目标，包括过程、方法和工具三要素
  1. 过程：支持软件开发各个环节的控制和管理
  2. 方法：完成软件开发任务的技术手段
  3. 工具：为软件开发方法提供自动的或半自动的软件支撑环境
2. 基本目标：x6
  1. 达到要求的软件功能
  2. 取得较好的软件性能
  3. 开发出高质量的软件
  4. 付出较低的开发成本
  5. 需要较低的维护设备
  6. 能按时完成开发工作，及时交付使用。
软件工程基本原理
1. 基本原理：x7
  - 用分阶段的生命周期计划严格管理
  - 坚持进行阶段评审
  - 实行严格的产品控制
  - 采用现代程序设计技术
  - 结果应能清楚地审查
  - 开发小组的人员应少而精
  - 不断改进软件工程实践的必要性

软件工程是将系统化的、规范的、可定量的方法应用于软件的开发、运行和维护的过程。

随堂测验1

单元测验1

第二章软件过程

知识点：

软件过程模型：
1. 软件过程基本活动
  - 分析、设计、实现、测试、维护
2. 几大模型的识别（了解优缺点、适用范围）
  1. 瀑布模型：（线性）
    - 优点：
      - 以预测性为原则以文档驱动开发过程以过程控制为核心
      - 开发阶段严格按照线性方式进行，每一个阶段具有相关的里程碑和交付产品，且需要确认和验证。
    - 缺点：
      - 各个阶段的划分完全固定，阶段之间产生大量的文档
      - 开发过程中间，很难响应用户的变更要求
      - 早期的错误，要等到开发后期的测试阶段才能发现
    - 适用范围：
      - 软件需求在开发初期即被完整地确定，用户的需求非常清楚全面，且在开发过程中没有或很少变化
      - 开发工作对用户参与的要求很低
      - 用户的使用环境非常稳定
      - 开发人员对软件的应用领域很熟悉
  2. 喷泉模型：
    - 关键词：顺序化、固定次序、在前一阶段的基础上
  3. 统一过程模型
    - 特点：
      - 用例和风险驱动，以架构为中心、迭代并且增量
      - 由 UML 方法和工具支持
      - 每个阶段是个小型的瀑布模型
    - 过程：初始、细化、构造、交付
    - 优点：及时发现缺点/节约成本
  4. 增量模型：（非整体开发模型）（先核心）
    - 关键词：模块化、分批次
    - 特点：
      - 增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
      - 运用增量模型的软件开发过程是递增式的过程。
      - 相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。
    - 适用场景：项目在既定的商业要求期限之前不可能找到足够的开发人员的情况。
  5. 迭代模型：
    - 关键词：适用需求、
    - 适用场景：适应用户需求变化
  6. 快速原型模型：（原型化模型）（先结构）
    - 关键词：尽快看到软件的概貌
    - 快速原型模型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。
    - 适用场景：
      - 用户需求不清、需求经常变化的情况。
      - 当系统规模不是很大也不太复杂时，采用该方法比较好。
  7. 螺旋模型：
    - 关键词：风险驱动、风险大
  8. 敏捷（Agile）开发模型：
    - 高度迭代、增量开发
  9. 可转换模型：
    - 适合嵌入式系统，可转换性高、安全性要求高
    - 比如，ABS防抱死系统
    - 可转换模型是将数学方法用于 开发无错误的计算机系统、定义计算机系统的规格说明、验证计算机系统的正确性
3. 敏捷开发（基本原则、敏捷宣言）
  1. 基本原则：
  2. 敏捷宣言：
    - 个体交互胜过过程和工具
      - 人是获得成功的最为重要的因素。
    - 可以工作的软件胜过面面俱到的文档
      - 文档需适度
    - 客户合作胜过合同谈判
      - 双赢比输赢更好
    - 响应变化胜过遵循计划
      - 为下两周做详细的计划
      - 为下三个月做粗略的计划
      - 以后就做极为粗糙的计划

模型选择：

需求明确->瀑布模型
开发时间
- 开发时间短 ->敏捷开发
- 开发时间长/团队规模大->统一过程模型
风险（人员风险分析（跳槽）/技术风险分析（不成熟）.....）
项目开发进度
- 持续稳定（按进度 ->敏捷/迭代/增量
- 取决于不同阶段的进度（不稳定 ->传统的、大型开发的模型
用户参与度
- 参与度高->敏捷开发

随堂测验2

随堂测验3

单元测验2

第三章软件需求

知识点

需求获取

需求的定义
1. 需求是对外可见的系统特征
需求的分类

软件需求其实就是系统必须完成的事，以及必须具备的品质。从大的方面来说可以分为：（1）业务需求：是指反映组织机构或客户对系统、产品高层次的目标要求，即要达到的总目标。（2）用户需求：是指用户使用产品必须要完成什么任务，怎样完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，然后建立从用户角度的需求。（3）系统需求：是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束。

(4) 软件设计规约：

其中系统需求又细化分为功能需求、非功能需求、设计约束： a、功能需求：指软件产品的功能特性

b、非功能需求（性能需求）：指在功能性需求满足情况下的进一步的要求。产品必须具备的性能或品质，例如：可靠性。稳定性、容错性。 c、设计约束：也称之为限制条件、补充规约，通常是对解决方案的一些约束说明。比如安全限制、运行环境要求等。

从管理的维度上看，又可以分为：（1）基本需求：用户明确说明要做的需求；（2）期望需求 ：用户没有明确说明，但是觉得你应该考虑的到需求；（3）兴奋需求：用户没有提出也没有觉得要做的需求（一般的我们不考虑）；
需求获取技术
- 面谈：
- 调查问卷：
- 建模技术：不同角度的抽象，（目标）用图形化的手段描述现实世界的问题。
- 亲身实践：观察
- 文档分析：
- 情景分析：将业务具体化，（目标）要清楚地定义用户参与完成的业务实践的步骤；
- 原型技术：需求确认，帮助用户可视化功能（目标）明确那些含糊不确定的需求；简化需求的文档，确认需求；能够尽快地获得用户和客户的反馈；
拓：
2. 需求过程包括：需求抽取、需求分析、需求规约、需求管理、需求验证
  1. 需求抽取：
    - 界面：原型与概念建模
    - 信息：面谈、文档分析
    - 业务逻辑：面谈、直接观察法
3. 使用跟踪表有助于识别、控制和跟踪需求的变化
4. 组织需求评审的最好方法是使用问题列表检查每一个需求
5. 需求规格说明描述了计算机系统的功能、性能及其约束
6. 在项目初始阶段，开发任务的目标是理解基本问题、确定所需的解决方案、确定需要解决方案的人员
7. 下面的( )将造成需求获取困难的问题：范围(scope)、理解(understanding)、易变性(Volatility)
8. 需求：
  1. 可靠性需求
    - 定义：系统在一定条件下，一定时间内无故障执行其所需功能的能力。
    - 区分：通常涉及到系统的故障率、恢复时间、数据的完整性等。
  2. 可用性需求
    - 定义：系统易于使用、学习、准备执行指定任务的能力，以及用户认为系统的满意度。
    - 区分：关注用户与系统交互的便利性和满意度，如响应时间、界面设计等。
  3. 出错处理需求
    - 定义：当系统出现故障或异常情况时，系统应如何响应和处理。
    - 区分：包括错误检测、错误报告、错误恢复和错误预防等方面。
  4. 接口需求
    - 定义：系统与其外部环境（如用户、其他系统、硬件等）之间的交互方式。
    - 区分：涉及到用户界面、网络通信协议、数据交换格式等。
  5. 约束
    - 定义：限制系统设计或实现的条件或因素。
    - 区分：可以是技术约束（如硬件限制、技术选择等），也可以是业务约束（如法规要求、政策限制等）。
  6. 逆向需求
    - 定义：明确系统不应做什么或不应具有哪些功能或特性的需求。
    - 区分：与正面需求相反，通常用于避免系统出现某些不希望的行为或结果。
  7. 将来可能提出的需求
    - 定义：目前尚未明确，但预计将来可能会提出的需求。
    - 区分：这类需求通常较为模糊，需要在系统设计时考虑到一定的灵活性和可扩展性。可以通过需求变更管理、迭代开发和版本控制等方式来管理这类需求。

随堂测验4-需求的定义

随堂测验5-需求的分类

随堂测验6-需求获取技术

随堂测验7

单元测验3

课后作业

第四章面向对象分析与设计

知识点：

面向对象分析与设计

对象可接受的消息通常被定义为该方法的一组“方法”。（或则说是，函数、操作、过程、子程序）

对象接口

接口是一个软件对象所能提供的所有功能属性（服务）的集合。
接口中的方法定义了服务对象所能实现的各种“服务”。
这些方法（或服务）的产生以及命名，都必须遵循使用该服务的客户对象的需求。

面向对象的分析 OOA
面向对象程序设计OOP

系统边界是指一个系统所包含的所有系统成分，与系统以外各种事物的分界线；

用例建模
1. 用例图绘制（actor-goal lists、参与者、用例、系统、用例之间的关系-包含&扩展&泛化）
  1. actor-goal lists:
  2. 用例规约包括：用例编号、用例名称、用例简述、参与者、前置条件、触发器、后置条件、基本事件流、扩展事件流、特殊需求、扩展点
  3. 参与者：与系统交互的人或外部系统
  4. 用例:系统为参与者提供的有价值的服务功能
  5. 系统:指待开发的任何事物，包括软件、硬件或则过程。建模时需先确立系统边界
  6. 参与者与用例之间的关系：
    - 关联
  7. 用例之间的关系
    1. 包含：“《include》”由 ‘包含用例名’ 指向 ‘被保护用例名’
      - 多个用例有共享行为时，共享行为单独创建用例，被相关用例“包含”
    2. 拓展：
      - 将特殊的、例外的部分定义为拓展用例
    3. 泛化：
2. 类图建模
  1. 类的定义
  2. 类图的绘制，包括类的表示、类的关联关系（聚合、组合、继承）、多重性
    1. 类的表示
    2. 类的关系：
      1. 类的关联关系
        
        聚合:
        
        表示整体与部分之间的关系
        
        使用一条带有空心菱形的实线来表示，菱形指向整体类
        
        组合:
        
        表示整体与部分之间的关系，部分完全不能脱离整体
        
        使用一条带有实心菱形的实线来表示，菱形同样指向整体类
      2. 类的泛化关系
        
        是一种继承关系，它表示一般与特殊的关系
        
        泛化关系用带空心三角箭头的实线表示，箭头从子类指向父类
      3. 类的依赖关系
        
        一个类的功能或任务需要另一个类来协助完成。这种依赖关系通常是偶然的、临时的、且相对较弱。
        
        依赖关系用带箭头虚线表示，箭头指向被依赖类
      4. 类的实现关系
        
        一个类实现了一个或多个接口定义的方法
        
        实现关系用带空心三角箭头的虚线表示，箭头从类指向实现的接口。
    3. 多重性
  3. CRC分拣法（找出类-定义类的职责-给出类与类之间的交互关系）
3. 顺序图建模
  1. 顺序图绘制（元素的表示：对象的命名、消息的类型及表示……）
4. 状态图建模
  1. 状态图绘制（包括状态的表示、迁移、触发事件、activity/action）
  2. 状态、对象状态空间、组合状态
5. OO的设计原则：SOLID各个原则及其含义

拓：

UML中的静态视图包括：类图、包图、对象图；

随堂测验8-测试4-1-OOAD&用例图T

随堂测验8-测试4-2-类图

随堂测验9-测试4-3-顺序图&状态图T

单元测验4

课后作业-用例建模

课后作业-类图建模X

课后作业-顺序图建模

第五章软件系统测试

知识点

模型-视图-控制器结构
- 把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）
- 视图：用户看到的界面，视图负责显示数据
- 模型：负责处理大部分数据逻辑，比如数据库操作等。
- 控制器：接收用户的输入，连接模型和视图，确保数据在两者之间正确传递
仓库体系结构
- 帮助我们快速找到需要的数据，并进行分析。
- 仓库体系结构（Repository Architecture）是一种以数据为中心的体系结构，适合于数据由一个模块产生而由其他模块使用的情形。
客户机/服务器结构（C/S）
- 两层结构：
  - 前端是客户机，负责用户界面显示、数据输入和接收返回结果；
  - 后端是服务器，负责数据库的管理和查询。
- 三层结构：
  - 随着中间件技术的成熟而兴起，包括表示层、业务逻辑层和数据存储层。它具有良好的开放性、可扩充性和可管理性
事件驱动结构
- 适用于构建响应更灵敏、更易于维护和扩展的分布式应用程序。
- 当你做了某件事（比如点击一个按钮或输入一段文字），这就像是一个“事件”发生了。软件会立刻注意到这个“事件”，并做出相应的反应，比如打开一个新的窗口或显示一些信息。这种方式使得软件更加灵活和响应迅速。
管道过滤器:
1. 把系统任务分成若干连续的处理步骤，这些步骤由通过系统的数据流连接，一个步骤的输出是下一个步骤的输入。

单元测验5

第六章软件编码与实现

知识点

编写规范（注释、命名、语句）

单元测验6

第七章软件测试

知识点

软件缺陷：
- items：
  - 失效（failure）：一个系统不能执行所要求的功能、偏差
  - 故障（fault）：编码过程中，存在于软件中的静态缺陷（代码上）
  - 错误（error）：中间步骤/中间变量与你设计的运行模式不同
  - 缺陷（defect）
  - 过失（mistake）
  - 异常（anomaly）
- 缺陷的集群性：80/20原则，80%的软件错误存在于20%的代码行中
软件测试类型：
1. 测试对象角度：单元测试、集成测试、系统测试、验收测试
  - 单元测试：
    1. 检查各个程序模块是否有错误，能发现编码和详细设计的错误。
    2. 单元测试（Unit Testing）是对软件基本组成单元进行的测试，其测试对象是软件设计的最小单位（模块或者类）。
    3. 单元测试一般由编写代码的开发人员执行，用于检测被测代码的功能是否正确。
  - 集成测试：
    1. 集成测试（Integration Testing）是在单元测试的基础上，将所有模块按照总体设计的要求组装成为子系统或系统进行的测试。
    2. 测试模块（子系统）接口，发现总体设计和需求说明的错误。
  - 系统测试：
    1. 功能测试（Functional Testing）是在已知产品所应具有的功能基础上，从用户角度来进行功能验证，以确认每个功能是否都能正常使用。
    2. 性能测试（Performance Testing）是在实际或模拟实际的运行环境下，针对非功能特性所进行的测试，包括压力测试、容量测试、安全测试和可靠性测试等。
  - 验收测试：
    1. 验收测试（Acceptance Testing）是在软件产品完成了系统测试之后、产品发布之前进行的软件测试活动，其目的是验证软件的功能和性能是否能够满足用户所期望的要求。
2. 测试技术角度：黑盒测试、白盒测试
  - 黑盒测试
    
    黑盒测试：将测试对象看做一个黑盒子，完全不考虑程序内部的逻辑结构和内部特性，只是依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
    - 等价类划分：
      
      等价类划分是将输入域划分成尽可能少的若干子域，在划分中要求每个子域两两互不相交，每个子域称为一个等价类。
      - eg:
    - 边界值分析
      - 最小边界是1，最大边界是99，这两个是合法边界的极限，必须测试，然后在测试超出边界的，如：0和100，这样测完说明参数设置的范围正确且没有超出
  - 白盒测试
    - 白盒测试：把测试对象看做一个透明的盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。
    - 逻辑覆盖语句（语句、判定、条件、判定条件、条件组合）
3. 程序执行角度：静态测试、动态测试
  - 静态测试：通过人工分析或程序正确性证明的方式来确认程序正确性。
  - 动态测试：通过动态分析和程序测试等方式检查程序执行状态，以确认是否有问题。
4. 人工干预角度：手工测试、自动化测试
  - 手工测试：测试人员根据测试大纲中所描述的测试步骤和方法，手工地输入测试数据并记录测试结果。
  - 自动化测试：相对于手工测试而言，主要是通过所开发的软件测试工具或脚本等手段，按照测试工程师的预定计划对软件产品进行的自动测试。

单元测验7

随堂测验-软件缺陷

m0_75257028

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
软件工程基础（WHUT）-复习习题整理

面向对象分析与设计对象可接受的消息通常被定义为该方法的一组“方法”。（或则说是，函数、操作、过程、子程序）对象接口接口是一个软件对象所能提供的所有功能属性（服务）的集合。接口中的方法定义了服务对象所能实现的各种“服务”。这些方法（或服务）的产生以及命名，都必须遵循使用该服务的客户对象的需求。面向对象的分析 OOA面向对象程序设计OOP系统边界是指一个系统所包含的所有系统成分，与系统以外各种事物的分界线；用例建模。
复制链接

扫一扫