软件工程全书知识点笔记

Chapter 1-概论

计算机软件指计算机系统中的程序及其文档

软件危机

许多软件项目不能满足客户的要求

许多软件项目超出预算和时间安排

软件危机的表现

  • 对软件开发成本和进度的估计常常很不正确

  • 用户对已完成的软件系统不满意的现象经常发生

  • 软件产品的质量往往靠不住

  • 软件常常是不可维护的

  • 软件通常没有适当的文档资料

  • 软件成本在计算机系统总成本中所占的比例逐年上升

  • 软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势

软件危机的原因

  • 软件是逻辑产品,开发进度、成本难以估计

  • 缺乏或不完整、不一致的文档给维护带来困难

  • 用户对软件需求的描述往往不够精确,有遗漏,有二义

  • 软件开发人员对需求的理解与用户的本来愿望有差异

  • 大型软件项目需多人协同完成,缺乏管理经验

  • 开发人员不能有效地、独立自主地处理大型软件的全部关系

  • 缺乏有力的方法学和工具的支持

  • 软件项目的特殊性和人类智力的局限性

克服软件危机的途径

  • 消除错误的概念和做法

  • 推广使用成功的开发技术和方法

  • 使用软件工具和软件工程支持环境

  • 加强软件管理

能力成熟度模型CMM

  • 1级__初始级

  • 2级__可重复级

  • 3级__已定义级

  • 4级__已管理级

  • 5级__优化级

软件过程模型

  • 瀑布模型(waterfall model)**

  • 演化模型(evolutionary model)

    • 增量模型(incremental model)
    • 原型模型(prototyping model)
    • 螺旋模型(spiral model)
  • 喷泉模型(water fountain model)

  • 基于构件的开发模型(component-based development model)

  • 形式方法模型(formal methods model)

增量模型特别适用于:

  • 需求经常变化的软件开发

  • 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发

增量模型能有计划地管理技术风险,如早期增量版本中避免采用尚未成熟的技术

螺旋模型指引的软件项目开发沿着螺线自内向外旋转,每旋转一圈,表示开发出一个更为完善的新软件版本

Chapter 2-系统工程

基于计算机的系统

  • 所谓基于计算机的系统是指:通过处理信息来完成某些预定义目标而组织在一起的元素的集合

  • 组成基于计算机系统的元素主要有:软件、硬件、人员、数据库、文档和规程(Procedure)

可行性分析

经济可行性分析:经济可行性主要进行成本效益分析,从经济角度,确定系统是否值得开发

技术可行性分析:技术可行性主要根据系统的功能、性能、约束条件等,分析在现有资源和技术条件下系统能否实现,技术可行性分析通常包括风险分析、资源分析和技术分析

法律可行性分析

Chapter 3-需求工程

软件需求工程细分为: 需求获取 需求分析与协商 系统建模 需求规约 需求验证 需求管理 六个阶段

  • 单主机结构

  • C/S(Client/Server)结构

  • B/S(Browser/Server)结构

五种基本控制结构

  • 顺序型
  • 选择型
  • 循环型
    • 先判定型循环(DO-WHILE)
    • 后判定型循环(DO-UNTIL)
    • 多情况选择型(CASE)

Chapter 5-结构化分析与设计

数据流图

基本元素:

  • 数据流沿着输入通路到达一个事务中心,事务中心根据输入数据的类型在若干条动作通路(action path)中选出一条来执行,具有这种特征的信息流称为事务流

  • 事务中心的任务是:

    • 接收事务(输入数据)

    • 分析每个事务以确定它的类型

    • 根据事务类型选取一条动作通路

Chapter 8-面向对象建模

用况建模

创建用况模型的步骤包括:

1.定义系统

2.确定执行者

3.确定用况

4.描述用况

5.定义用况间的关系

6.确认模型

类和对象建模

类和对象模型的基本模型元素有类、对象以及它们之间的关系。系统中的类和对象模型描述了系统的静态结构,在 UML 中用类图和对象图来表示

动态建模

动态建模用来描述系统的动态行为,显示对象在系统运行期间不同时刻的动态交互。UML 中用状态机图、活动图、顺序图、通信图和协作图来建立动态模型

  • 状态机图

    状态机图通常是对类描述的补充,它说明该类的对象所有可能的状态,以及哪些事件将导致状态的改变。状态机图描述了对象的动态行为,是一种对象生存周期的模型

  • 活动图

    • 活动图可看作一种特殊形式的状态机,用于对计算流程和工作流建模。活动图的状态表示计算过程中所处的各种状态
    • 活动图用来描述完成一个操作所需要的活动,或者是一个用况实例(场景)的活动
    • 活动图使用状态机图的符 表示,活动图中的状态称为动作状态,用圆角矩形表示,动作状态之间的迁移用箭头表示,迁移上可以附加警戒条件、发送子句和动作表达式
    • 与状态机图不同的是,活动图中动作状态之间的迁移不是靠事件触发的,当动作状态中的活动完成时迁移就被触发
  • 顺序图

    顺序图用来描述对象间的交互行为,它关注于消息的顺序,即对象间消息的发送和接收的顺序。顺序图还揭示了一个特定场景的交互,即系统执行期间发生在某时间点的对象之间的特定交互。它适合于描述实时系统中的时间特性和时间约束

    顺序图有两个坐标,垂直坐标表示时间(从上到下),水平坐标表示一组对象(用对象框表示)

  • 通信图

物理体系结构建模

构件图

构件图显示构件类型的定义、内部结构和依赖。构件是系统设计的模块化部分,它给出一组外部的接口,而隐藏了它的实现。在系统中满足相同接口的构件可以自由地替换

构件的接口有二种:

供应接口(provided interface): 供应接口声明该构件为其他请求者提供某种服务

请求接口(required interface): 请求接口声明该构件请求其他供应者为其提供某种服务,以完成其功能需求

部署图

Chapter 9-基于构件的软件开发

长期以来的软件开发状况

  • 多数软件都是针对某个具体的应用系统从头进行开发的

  • 导致:出现了大量的同类软件重复开发,造成大量人力、财力的浪费,而且软件的质量也不高

构件的要素

  • 规格说明:建立在接口概念之上,作为服务提供方与客户方之间的契约

  • 一个或多个实现

  • 受约束的构件标准

  • 包装方法

  • 部署方法

3C构件模型

  • 概念(concept):关于“构件做什么”的抽象描述,可以通过概念去理解构件的功能。概念包括接口规约和语义描述两部分,语义描述和每个操作相关联(至少表示为前后置谓词形式)

  • 内容( content):概念的具体实现,描述构件如何完成概念所刻画的功能

  • 周境( context):描述构件和外围环境在概念级和内容级的关系,刻画构件的应用环境,为构件的选用和适应性修改提供指导

Chapter 10-敏捷软件开发

敏捷方法的基本观点

  • 强调适应性而不是可预测性

    • 经典软件开发方法:通过控制变化实现软件开发的可预测性
    • 敏捷软件开发方法:变化是不可避免的,应该通过改善管理实践和工程实践来更好地适应变化
  • 强调人在项目中的关键作用

    • 敏捷软件开发认为人不是可以互相替换的“编程部件”,而是具有创造力的个体,成功的软件开发活动依赖于人的主观能动性
  • 强调“刚刚好”(Just enough)

  • 在保证软件开发有成功产出的前提下,尽量减少开发过程中的活动和制品的方法,即开发中的活动及制品既不要太多也不要太少

Chapter 11-人机界面设计

Chapter 12-程序设计语言和编码

Chapter 13-软件测试

软件测试的目的

Glen Myers 给出的软件测试目的:

  • 测试是一个为了发现错误而执行程序的过程

  • 一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例

  • 一个成功的测试是指揭示了迄今为至尚未发现的错误的测试

软件测试的原则

Davis 提出了一组指导软件测试的基本原则:

  • 所有的测试都应可追溯到客户需求

  • 应该在测试工作真正开始前的较长时间就进行测试计划

  • Pareto原则:测试中发现的 80% 的错误可能来自于 20% 的程序代码

  • **测试应从 “小规模” 开始,逐步转向 “大规模” **

  • 穷举测试是不可能的

  • 为了达到最有效的测试,应由独立的第三方来承担测试

白盒测试与黑盒测试

  • 白盒测试(又称为结构测试)把测试对象看作一个透明的盒子,测试人员根据程序内部的逻辑结构及有关信息设计测试用例,检查程序中所有逻辑路径是否都按预定的要求正确地工作

  • 白盒测试主要用于对模块的测试,包括:

    • 程序模块中的所有独立路径至少执行一次

    • 对所有逻辑判定的取值(”真“ 与 ”假“)都至少测试一次

    • 在上下边界及可操作范围内运行所有循环

    • 测试内部数据结构的有效性等

  • 黑盒测试(又称行为测试)把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能需求

  • 黑盒测试可用于各种测试,它试图发现以下类型的错误:

    • 不正确或遗漏的功能

    • 接口错误,如输入/输出参数的个数、类型等

    • 数据结构错误或外部信息(如外部数据库)访问错误

    • 性能错误

    • 初始化和终止错误

  • 常见的白盒测试方法

    • 逻辑覆盖测试
    • 基本路径覆盖测试
    • 数据流测试
    • 循环测试
  • 主要的黑盒测试方法

    • 等价类划分

    • 边界值分析

    • 比较测试

    • 错误猜测

    • 因果图

测试策略

一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试

  • 单元测试是针对程序中的模块或构件,主要揭露编码阶段产生的错误

  • 集成测试针对集成的软件系统,主要揭露设计阶段产生的错误

  • 确认测试是根据软件需求规约对集成的软件进行确认,主要揭露不符合需求规约的错误

  • 对于基于计算机系统中的软件,还需将它集成到基于计算机系统中,并进行系统测试,以揭露不符合系统工程中对软件要求的错误

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2020年5月13日
下一篇 2020年5月13日

相关推荐