软件工程期末

第二章

需求的分类:
  • 功能需求
  • 非功能需求
    易用性、观感、性能、安全、文化、操作需求
  • 限制条件(工期、资源等限制,与系统无关的约束)

  • 功能需求
  • 性能需求
  • 可靠性与可用性需求
  • 出错处理需求
  • 接口需求
  • 约束

需求建模模型

  • 数据流图:以图形方式来表达数据在系统中的流动、变换过程
  • 数据字典:对数据流图中数据流、加工等各个元素的定义及说明,是数据流图的重要补充
  • E-R图:系统中实体及实体间的关系
  • 状态转换图:描述系统对外部事件的响应及状态变化

需求分析

开发人员进行调研与分析,将用户非形式的需求表述转化为完整的需求定义
主要任务:确定系统的需求,包括功能需求与非功能需求



第四章

模块概念

接口 + 功能 + 逻辑 + 状态
模块的输入输出
模块实现的功能
模块内部逻辑
模块外部运行环境

模块独立性 ⭐

把软件划分为模块时遵守的准则,也是判断模块构造是否合理的标准
模块只完成一个特定的独立功能,且与其他模块的关系简单

为什么模块独立性很重要??

  • 模块化的软件易于开发、测试、维护
  • 修改设计、程序的工作量小,错误的传播范围小

内聚

内聚概念
功能内聚模块中所有元素聚合在一起都是为了实现一个具体任务
顺序内聚上一个模块的输出是下一个模块的输入,模块功能较小,连接紧密
通信内聚模块内部的各个任务使用同一个输入/输出数据
过程内聚按特定次序执行的一组任务划分到一个模块中模块功能较大,连接不够紧密
时间内聚需要同时执行的动作组合在一个模块中
逻辑内聚分支,由传递的参数决定该模块完成哪个功能
偶然内聚块内各部分互不相关

耦合

耦合概念
非直接耦合两模块无直接关系
数据耦合一模块调用另一模块,调用的输入、输出均为简单变量**(通过同一变量传递信息)**
特征耦合(标记)一模块调用另一模块,输入或输出为数据结构**(通过同一数据结构传递信息)**
控制耦合一模块通过控制信号来选择调用底层模块 (通过控制信号传递信息)
外部耦合两个模块访问同一个全局变量
公共耦合两个模块访问同一个全局数据结构、公共内存区、共享通信区
内容耦合1、一个模块直接访问另一个模块的内部数据 2、一个模块不通过正常入口转到另一个模块 3、一个模块有多个入口 4、两个模块的程序有重叠部分

软件设计8条规则

  1. 设计过程可预测与评估
  2. 设计模型是可跟踪的
  3. 设计应重视资源重用
  4. 设计应表现一致性与集成性
  5. 设计不是编码,编码不是设计
  6. 设计应考虑软件的容错性及异常处理的能力
  7. 设计应适应扩展及变更

软件程序结构设计的启发式设计准则(模块结构图的设计规则)

  1. 提高模块独立性,做到高内聚低耦合
  2. 模块规模适中
  3. 适当的扇入扇出
  4. 作用域在控制域内
    控制域:模块本身及其所有可供调用的下级模块
    作用域:接受我发送的控制信息而影响自身判断的模块
  5. 定义功能可预测的模块
  6. 设计入口单出口的模块

第五章

变换流与事务流的区别

  • 变换流
    具有明显的输入、变换和输出界面的数据流图
  • 事务流
    数据沿输入通路到达事务中心后,根据输入数据的类型在若干动作序列中选出一个来执行

第六章

面向对象

面向对象的概念

对象 + 类 + 继承 + 通信

面向对象的特点

  • 抽象
  • 封装
  • 共享

类图

描述系统的结构

一组具有相同数据结构与相同操作的对象的集合

四种类间关系

关联
泛化

父类子类关系
动物—狗—猫

组合 is a part of (同生共死)
聚合 is a member of

软件开发小组 — 人

依赖 ---->

带箭头的虚线
对于类A和类B,若出现下面情况,称为类A依赖类B:

    1.类A中某个方法的形参是类B类型。

    2.类A中某个方法的返回类型是类B类型。

    3.类A中某个方法中的局部变量是类B类型。

用例图

3种用例间的关系

  • 包含
    使用情况:

          (1)如果两个以上用例有重复的功能,则可以将重复的功能分解到另一个用例中。其他用例可以和这个用例建立包含关系。
    
          (2)一个用例的功能太多时,可以用包含关系创建多个子用例。
      ![在这里插入图片描述](https://img-blog.csdnimg.cn/a51fe3e4e9ca453d9b9db4bba81a4e9d.png)
    
  • 扩展
    把新行为插入到已有用例,类似于特殊情况处理
    扩展用例是基础用例在某些条件下触发的

  • 泛化
    子用例将继承基用例的所有行为,也就是任何使用基用例的地方都可以使用子用例来代替
    在这里插入图片描述

包含与扩展的区别

扩展用例只有在基本用例满足某种条件的时候才会执行。

包含关系中基本用例的基本流执行时,包含用例一定会执行。

UML

UML Unified Modeling Language的简称,是统一建模语言,它不是一种方法,而是一种建模语言。
它统一了面向对象建模的基本概念、图形符号,为人们建立便于交流的共同语言

2类9种模型图

静态图
  • 用例图:描述系统的功能,及系统中各用例间的关系及用户与用例的交互
  • 类图:描述系统中的类,及类之间的关系
  • 对象图:系统对象及对象间的关系
  • 构件图:构建类型的组织及各构件之间的关系
  • 部署图:软硬件的物理架构 / 软硬件间的物理关系 / 系统运行时的结构
动态图
  • 状态图:系统响应外部行为而进行的状态变换

  • 协作图:强调对象间的消息传递情况/交互关系
    管理员结账例子在这里插入图片描述

  • 顺序图:强调按照时间顺序发生的对象交互行为


协作图与顺序图的区别在这里插入图片描述

  • 活动图:侧重描述活动之间的控制流
    在这里插入图片描述

用例模型

若干幅用例图构成

  • 定义系统
  • 找出角色与用例
  • 描述用例
  • 用例的加工
  • 验证模型

第十章

系统的设计目标

  • 可靠性
  • 容错性
  • 安全性
  • 可修改性

5类软件设计准则

  • 性能
    对系统速度及空间的需求
  • 可靠性
    减少系统崩溃及随后造成的危害所做的努力程度
  • 成本
    开发、配置、管理的成本
  • 维护
    运行后再修改系统的困难程度
  • 最终用户准则
    用户是否能在系统上完成所需任务
    用户使用系统的容易程度

OCL 对象约束语言

利用OCL去描述一个约束
允许在单个模型元素和模型元组上对约束进行形式化说明的语言


不变式:整个对象生命周期内都需要满足的约束
前置:执行操作前需满足的约束
后置:执行操作后需满足的条件


第10章

软件维护的概念

软件在运行中改正错误或需要添加新需求而修改软件的活动

  1. 软件的维护总是针对某一种软件产品在软件生命周期内所进行的活动
  2. 卖软件就是卖服务
  3. 软件维护的时间是有限度的

为什么软件维护困难

种种原因

  1. 读懂他人的程序很难
  2. 文档太差
  3. 修改后可能会产生新的错误
  4. 维护工作很枯燥,没人愿意做

软件维护的4种分类

- 完善性维护 60%
扩展新需求
- 适应性维护 25%
软件运行的软硬件环境变化,需要维护使软件适应新的运行环境
如:操作系统由Linux换为Windows、系统配置信息的更改、软件使用对象变化??
- 纠错性维护 20%
改正软件出现的错误、缺陷
- 预防性维护 5%
提高软件的可靠性及可维护性,减少以后的维护工作量
常用方法:软件再工程

软件维护3种副作用

代码的副作用

对代码的修改容易使程序混乱、结构不清晰、可读性变差

数据的副作用

轻易修改数据结构会使

文档的副作用

对软件的任何修改都应在相应技术文档中反映出来(软件修改后要及时更新文档

第11章

软件测试的目的

以最低的代价尽可能多地找出软件中潜在的错误与缺陷

软件测试的16条原则

  1. 尽早地、不断地测试
  2. 严格执行测试计划
  3. 妥善保存测试计划、测试用例、出错统计及分析报告,为后期维护的方便
  4. 设计好的测试用例
  5. 适时地结束测试
  6. 避免程序员测试自己编写的程序

软件测试的分类

按测试策略分类

测试测试对象文档依据
单元测试单元模块详细设计文档
集成测试组装后的程序模块
确认测试可运行的目标系统需求说明书
系统测试检测软件与系统中其他元素是否协调(对整个系统的测试,将硬件、软件、操作人员看作一个整体,检验它是否有不符合系统说明书的地方)需求说明书
验收测试部署软件之前的最后一个测试,确保软件准备就绪

按测试方法

  1. 静态测试(人工检测)
    不运行被测程序本身,仅对各阶段的文档进行静态审查
    对需求分析、设计说明书、源程序进行结构分析、流程分析来发现错误
  2. 动态测试
    在计算机上运行被测代码,输入测试用例后观察其运行情况、分析测试结果
    • 黑盒测试
      完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试
      只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息

      • 等价类划分法
      • 边界值分析法
    • 白盒测试
      全面了解程序内部逻辑结构、对所有逻辑路径进行测试

      • 基本路径测试

        • 代码语句编号
        • 画出控制流图
        • 环形复杂度的计算:
          • 边-节点+2
          • 分支节点数+1
          • 区域数+1
        • 找出独立路径(至少包含一条在定义该路径前不曾用过的边)
        • 设计测试用例, 测试每条独立路径
      • 逻辑覆盖

覆盖
语句覆盖每个语句至少执行一次
判断覆盖每个判断的所有分支至少执行一次
条件覆盖每个判定中所有条件的可能取值
判定/条件覆盖判定覆盖+条件覆盖 每个判定中所有条件的可能取值,每个判断本身的所有可能结果至少执行一次
条件组合覆盖每个判定中所有条件的组合

黑盒测试与白盒测试的比较:PPT P65

  • 0
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
软件工程期末试卷CSND是一份用于测试学生在软件工程领域知识和技能的考试试卷。CSND是指著名的技术社区CSDN(中国软件开发者联盟)所推出的软件工程试卷。这份试卷采用了多种题型,包括选择题、填空题和编程题等,旨在全面考察学生对软件工程概念、原理和实践的理解和运用能力。 在这份试卷中,学生可能会面对一些与软件生命周期相关的问题,如需求分析、设计、编码、测试、维护等。此外,也可能会涉及到软件质量保证、软件项目管理、软件开发方法学等方面的知识点。 对于学生来说,参加这份试卷的考试需要具备扎实的软件工程基础知识,并能够熟练运用所学的理论和实践技能来解决实际问题。还需要适应考试的时间紧张和题目的难度,能够快速准确地给出答案,并对自己的答案进行合理的解释和论证。 作为一名学生,参加这份试卷的考试对于提升自己的软件工程能力和应试能力都有很大的帮助。通过认真复习和准备,可以提前了解可能出现的知识点和题型,有针对性地进行练习和训练,从而提高自己的解题能力和答题效率。 总之,软件工程期末试卷CSDN是一种考察学生软件工程知识和技能的评估工具,对学生而言是一次重要的考试机会。通过充分准备和积极参与,可以帮助学生提升软件工程水平,为未来的工作和研究打下坚实的基础。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值