软件工程
2022-06-14 22:42:44 41 举报软件工程是一门专注于设计、开发和维护高质量软件系统的学科。它涵盖了从需求分析、系统设计、编码实现，到测试、部署和维护的整个软件开发生命周期。软件工程强调使用规范化的方法、工具和技术，以提高软件开发的效率和质量。这包括使用版本控制系统管理代码，采用敏捷或瀑布等开发模型，以及利用自动化测试工具进行持续集成和持续交付。此外，软件工程还关注于软件的可维护性和可扩展性，以确保软件能够适应未来的需求变化和技术发展。
作者其他创作
大纲/内容
第一章 软件
软件：计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合
程序：指令集合，满足预期特性功能和性能需求
数据：数据结构
文档：软件描述信息
软件危机：在计算机软件的开发和维护过程中所遇到的一系列严重问题。
问题：
如何开发软件，以满足不断增长，日趋复杂的需求
如何维护数量不断膨胀的软件产品
表现：
1.对软件开发成本和进度的估计常常不准确。
2.用户对“已完成”系统不满意的现象经常发生。
3.软件产品的质量往往靠不住。Bug一大堆，Patch一个接一个。
4.软件的可维护程度非常之低。
5.软件通常没有适当的文档资料。
6.软件的成本不断提高。
7.软件开发生产率的提高赶不上硬件的发展和人们需求的增长。
原因
1.软件生产本身存在着复杂性；
2.与软件开发所使用的方法和技术有关。
软件与硬件的不同：软件不会“磨损”，但会退化。
可行性研究：项目值得开发否技术可行性，经济可行性，操作可行性
技术可行性
经济可行性
操作可行性
软件应用领域
系统软件：编译器，编辑器，文本管理软件，操作系统构件，驱动程序
应用软件：独立应用程序处理商务或技术数据
工程科学软件：“数值计算”类程序
嵌入式软件：汽车的燃油控制和仪表盘显示
产品线软件：库存控制产品
Web/移动App
人工智能软件：机器人，专家系统，模式识别，人工神经网络
第二章 软件工程
定义：
(1)将工程化应用于软件中
(2)在(1)中所述方法的研究
SOA面向服务架构
定义：
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
特点：
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型
SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者更迅速、更可靠、更具重用性地架构整个业务系统
为什么选择SOA
SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。
软件工程是层次化的技术：
质量关注点是根基
过程是基础
方法是解决方法
工具是过程和方法的支持
软件过程：软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。
1.活动主要实现宽泛的目标，与应用领域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系。
2.动作（如体系结构设计）包含了主要工作产品（如体系结构设计模型）生产过程中的一系列任务。
3.任务关注小而明确的目标，能够产生实际产品（如构建一个单元测试）。
普适性活动：
软件项目跟踪和控制
风险管理
软件质量保证
正式技术评审
测量
软件配置管理
可复用管理
工作产品的准备和生产
第三章 过程结构
过程框架：沟通、策划、构建、建模、部署
线性过程流
迭代过程流
演化过程流
并行过程流
第四章 过程模型
生命周期： 软件从孕育、诞生、成长、成熟、衰亡的生存过程。
问题的定义、可行性研究、软件需求分析、系统总体设计、详细设计、编码、测试和运行、维护。
计划阶段、开发阶段和运行阶段
问题定义 — 要解决的问题是什么？
可行性研究 — 有行得通的解决办法吗？
需求分析 — 目标系统必须做什么？
总体设计（概要设计） — 怎样实现目标系统？怎么做？
详细设计（模块设计） — 怎样具体地实现系统？
编码及单元测试 — 用语言表达详细设计的结果，并对每一个模块进行测试。
综合测试 — 集成测试，验收测试
软件维护：持久地满足用户的需要。
瀑布模型（文档驱动）：阶段间具有顺序性和依赖性
优点：易于组织管理
缺陷：
1.在项目开始的时候，用户常常难以清楚地给出所有需求；用户与开发人员对需求理解存在差异。
2.实际的项目很少按照顺序模型进行。
3.缺乏灵活性：因为瀑布模型确定了需求分析的绝对重要性，但是在实践中要想获得完善的需求说明是非常困难的，导致“阻塞状态”。
4.反馈信息慢，开发周期长。
场合：图书管理系统、销售管理系统
1.当有一个稳定的产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适。
2.当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，瀑布模型也特别合适。
3.对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。
4.在质量需求高于成本需求和进度需求的时候，它尤为出色。
5.当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。
增量模型：
优点：
1.融合了线性顺序模型的基本成分和原型实现的迭代特征
2.以功能递增的方式进行软件开发；
3.能较快地产生可操作的系统；
4.在每一步递增中，均发布一个新的增量，把用户/开发者的经验结合到不断求精的产品中；
5.每个增量的开发没有必要使用相同的过程；
6.可改善测试效果和降低软件开发总成本。
缺陷：
1.增量应该相对较小，每个增量应该包含一定的系统功能。所以，很难把用户的需求映射到适当规模的增量上。
2.大多数系统需要一组在系统许多部分都会用到的基本服务。但由于增量实现前，需求不能被详细定义，所以，明确所有增量都会用到的基本服务就比较困难。
场合：字处理软件
原型模型(用户驱动)：
优点：
1.从实践中学习(Learning by doing)
2.改善通信、改善用户参与
3.使部分已知需求清晰化
4.展示描述的一致性和完整性
5.提高系统的实用性、可维护性
6.节省开发的投入、缩短整个软件的开发周期
缺陷：
1.用户有时误解了原型的角色，例如他们可能误解原型应该和真实系统一样可靠。
2.缺少项目标准，进化原型方法有点像编码修正。
3.缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制。
4.额外的花费：研究结果表明构造一个原型可能需要10%额外花费。
5.为了尽快实现原型，采用了不合适的技术，运行效率可能会受影响。
6.原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。
适用场合：人机交互/复杂的计算机图形软件
当用户定义了软件一般性目标，但是不能给出详细的输入、处理和输出要求。开发者不能确定算法的有效性，操作系统的适应性或人机交互的形式。
螺旋模型(风险驱动)：增加了风险分析，是以风险为导向的生命期模型。
活动：
1.制定计划：确定软件目标，选定实施方案，弄清项目开发的限制
2.风险分析：分析所选方案，考虑如何识别和消除风险
3.实施工程：实施软件开发
4.客户评估：评价开发工作，提出修正建议
优势：随着迭代的增加（成本的增加），风险程度随之降低
缺陷：比较复杂，需要相当的风险评估技术，且成功依赖于这种技术。
增量过程模型与原型实现模型，本质上都是迭代的。
两者区别在：增量模型强调每一个增量发布一个可操作的产品。早期的增量提供了为用户服务的功能和给用户评价的平台。
第七章 理解需求
好的需求
一致性
完整性
可理解、无二义性
可测试性
需求工程RE：
致力于不断理解需求的大量任务和技术
从软件过程看，是一个软件工程动作，开始于沟通持续到建模活动
在设计和构建之间架起桥梁
七项任务：起始、获取、细化、协商、规格说明、确认、需求管理
质量功能部署QFD
常规需求：客户陈述的目标，这些需求存在，客户就会满意
期望需求：客户没有清晰表述的需求，缺少会引起客户不满
兴奋需求：超出客户需求，存在会令人满意
开发用例
actor泛化关系
include关系
Extend关系
事件流描述
泛化关系
需求建模方法
结构化分析
数据字典：数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合
状态转换图：控制规格说明
实体-关系图：数据对象描述
数据流图：控制规格说明
面向对象分析
第八章 需求建模：基于场景的方法（用例）
需求分析
定义
用户对目标系统的功能、行为、性能、设计约束等方面的期望
产生软件工作特征的规格说明，指明软件和其他系统元素的接口，规定软件必须满足的约束
作用
定义软件范围及必须满足的约束
确定软件的功能和性能及其他系统成分的接口
建立数据模型、功能模型和行为模型
最终提供需求规格说明
UML活动图
UML泳道图
第九章 需求建模：基于类的方法（对象和类）
分析类
识别类
名词识别法
系统实体识别法
在用例中识别类
利用分解和抽象技术
类图
第十章 需求建模：行为和模式（事件和状态）
状态图
场合：某一给对象从一个主动状态到另一个主动状态的转移
顺序图
场合：一个对象到另一个对象的转移
区别： 顺序图在表示系统行为的方式上与状态图不同
顺序图通过描述类如何从一个状态移动到另一个状态来表示行为
状态图表示单个类如何根据外部事件改变其状态，而顺序图则将软件的行为显示为时间的函数。
联系：顺序图和状态图都是用于行为建模的符号。
第十一章 设计概念
软件设计
软件设计是后续开发步骤及软件维护工作的基础，如果没有设计，只能建立一个不稳定的系统结构。
质量属性
功能性
易用性
可靠性
性能
可支持性
设计概念
抽象
过程抽象：指具有明确和有限功能的指令序列（开门）
数据抽象：数据对象的数据集合（门door的属性）
过程抽象 （开）将利用数据抽象（door的属性）所包含的信息
体系结构(构建+连接件+约束)：
软件设计的目标之一是系统体系结构示意图
指系统的一个或多个结构，包括软件构件、构件的外部可见属性以及它们之间的关系
包括三部分
1.程序（模块）的结构或组织
2.构件交互的形式
3.构件所用数据的结构
关注点分离
是一个设计概念
表明任何复杂问题如果被分解为可以独立解决和优化的若干块，该复杂问题能够更容易地被处理
模块化
关注点分离最常见的表现
软件被划分为独立命名的、可处理的构件，称之为模块。
优势：
使开发工作更易于规划
可以定义和交付软件的增量
更容易实施变更
能够有效开展测试和调试
可以进行长期维护而没有严重副作用
信息屏蔽
是模块化的一个设计标准
每个模块的实现细节对于其它模块来说是隐蔽的
模块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用。
功能独立
功能独立的概念是模块化、抽象概念和信息隐蔽的直接结果。
内聚性：模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。
功能内聚：一个模块中各个部分都是完成某一具体功能必不可少的组成部分
信息内聚：完成多个功能，各个功能都在同一数据结构上操作，这个模块的所有功能都是基于同一个数据结构（符号表）
通信内聚：如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，通过数据流图来定义的
过程内聚：使用流程图做为工具设计程序时，把流程图中的某一部分划出组成模块，就得到过程内聚模块。
时间内聚：模块大多为多功能模块，但模块的各个功能的执行与时间有关，要求所有功能必须在同一时间段内执行。
逻辑内聚：这种模块把几种相关的功能组合在一起，被调用时，由传送给模块的判定参数来确定该模块应执行功能。
巧合内聚：当模块内各部分之间没有联系，或者即使有联系，也很松散，它是内聚程度最低的模块。
耦合性：模块之间的互相连接的紧密程度的度量。
非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，独立性最强。
数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数 来交换输入、输出信息的。
标记耦合：模块间通过参数传递复杂的内部数据结构（如高级语言的数组名）此数据结构的变化将使模块发生变化。
控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息
公共耦合：一组模块都访问同一个公共数据环境
内容耦合：当一个模块直接修改或操作另一个模块的数据时，或一个模块不通过正常入口转入另一个模块时
模块独立性比较强的模块应是高内聚、低耦合的模块。
求精
将软件的体系结构按自顶向下方式，对各个层次的过程细节和数据细节逐层细化，直到用程序设计语言的语句能够实现为止，从而最后确立整个的体系结构。
设计类
类型：
1.用户接口类
2.业务域类
3.过程类
4.持久类
5.系统类
良好的设计类：
1.完整性和充分性
2.原始性
3.高内聚性
4.低耦合性
第十二章 体系结构设计
体系结构概念
指系统的一个或多个结构，包括软件构件、构件的外部可见属性以及它们之间的关系
并非可运行软件，是一种表达
1.对设计在满足既定需求方面的有效性进行分析
2.在设计变更相对容易的阶段考虑体系结构可能的选择方案
3.降低与软件构建相关的风险
软件体系结构 = 构件 + 连接件 + 约束
构件:是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素 和 数据存储
连接件:是构件间建立和维护行为关联与信息传递的途径
体系结构类型
人工智能、通信、设备、金融、游戏、工业、法律...
体系结构风格
针对某种软件应用场景，应该选择与其相适应的构件，以及合理安排构件间的关系
分类
以数据为中心的体系结构
优点：知识库拓展性，解决领域问题
缺点：
场景：剪切板、数据库系统
数据流体系结构
优点：缺少构建间的耦合性，容易维护和扩展，易于分析
缺点：缺乏交互性
场景：媒体播放器，Linux shell管线
调用—返回体系结构
优点：易于完成并发任务
缺点：难以共享数据，对象间的逻辑复杂
场景：IDE
面向对象的体系结构
优点：高模块化，代码封装，代码共享易维护
缺点：对象改变需修改所有调用对象
场景：Java/C#开发系统
层次体系结构
优点：抽象化，软件重用，易扩展
缺点：方法间接调用影响性能
场景：TCP/IP协议
体系结构设计（p162）
第十三章 构建级设计
构件
是计算机软件中一个模块化的构造块
系统中模块化，可部署和可替换的部件，该部件封装了实现并对外提供一组接口。
基本设计原则（p180）
1.开闭原则
对扩展开放，对修改关闭
2.里氏替换原则：解决继承带来的问题
子类可以替换他们的基类
3.依赖倒置原则：“面向接口的编程”
依赖于抽象，而非具体实现
4.接口分离原则
多个客户专用接口比一个通用接口要好
5.发布复用等价原则
复用的粒度就是发布的粒度
6.共同封装原则
一同变更的类应该合在一起
7.共同复用原则
不能一起复用的类不能被分到一起
第十四章 用户界面设计
黄金规则
1.把控制权交给用户
2.减轻用户记忆负担
3.保持界面一致
第十五章 质量概念
概念：
用户满意度=合格的产品+好的质量+按预算和进度安排交付
Garvin质量维度：性能质量、特性质量、可靠性、符合性、耐久性、适用性、审美、感知
McCall：正确性、可靠性、效率、完整性、易用性、可维护性、灵活性、易测试性、可移植性、可复用性、互操作性
ISO9126 : 功能、可靠性、易用性、效率、可维护性、可移植性
质量和可靠性是相关的概念，但在许多方面根本不同。讨论差异？
1. 质量控制与产品在某一时间点的性能有关。
2. 质量侧重于软件对显式和隐式要求的一致性。
3. 软件质量保证是将质量保证的管理原则和设计学科映射到软件工程的适用管理和技术空间。
1. 可靠性与产品在其整个生命周期内的性能有关。
2. 可靠性侧重于软件作为时间或其他量的函数正确运行的能力。
3. 软件可靠性模型扩展了测量，使收集的缺陷数据能够外推到预计的故障率和可靠性预测中。
一个程序是否正确但仍然不可靠？
是的，程序有可能在给定的瞬间符合所有明确的功能和性能要求。因为，可靠性使用统计分析来确定软件故障发生的可能性。并且，失败的概率是在指定环境中指定时间段内的自由软件运行。
一个程序可以是正确的，但仍然没有表现出良好的质量吗？
是的，程序有可能在给定时刻符合所有明确的功能和性能要求，但在维护、与其他系统集成或可能具有硬件依赖性时表现不佳。许多程序已被拼凑在一起，因此它们可以正常工作，但如果按照 McCall 的质量因素来衡量，这些程序的质量非常低。
第十六章 质量保证
软件可靠性：
平均失效间隔时间：MTBF=MTTF+MTTR（平均失效时间，平均维护时间）
可用性=MTTF/(MTTF+MTTR)*100
第十七章 测试策略
目的
用户：通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品
软件开发者：希望测试成为表明软件产品中不存在错误的过程
自顶向下集成
优点：能够尽早发现系统主控方面的问题。
缺点：无法验证存根模块是否完全模拟了下属模块的功能。
自底向上集成
优点：驱动模块较容易编写存根模块，能够尽早查出底层涉及较复杂的算法和实际的I/O模块中的错误。
缺点：最后才能发现系统主控方面的问题。
a测试
在受控的环境中进行：由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
开发者负责记录发现的错误和使用中遇到的问题。
b测试
在开发者不能控制的环境中的“真实”应用：由软件的最终用户们在一个或多个客户场所进行。
用户记录在测试中遇到的一切问题，并定期报告给开发者。
黑白盒
白盒测试方法
1.语句覆盖（最弱）
2.判定覆盖
3.条件覆盖
4.判定/条件覆盖
5.条件组合覆盖
6.路径覆盖（最强）
黑盒测试方法
1.等价类划分
2.边界值分析
3.错误推测
4.因果图
4.综合测略
12.什么是黑盒测试法？
也称功能测试或数据驱动测试，测试时把程序看作一个不能打开的黑盆子，
在完全不考虑程序内部结构和内部特性的情况下，只根据需求规格说明书，测试
程序的功能或程序的外部特性。
在完全不考虑程序内部结构和内部特性的情况下，只根据需求规格说明书，测试
程序的功能或程序的外部特性。
15.什么是白盒测试?
分析程序的内部逻辑结构，注意选择适当的覆盖标准，设计测试用例，对主
要路径进行尽可能多的测试
要路径进行尽可能多的测试
22．面向对象软件测试基本步骤是什么？
1、测试用例模型
2、测试某些用例中的典型场景
3、类及对象模型
4、某些类测试其状态模型
独立路径（P273）
独立路径必须包含一条在定义之前不曾用到的边
环复杂度
1.边-点+2
2.判定点+1
3.区域
0 条评论
下一页
