第一章 概论
软件工程概论#
1、软件工程概念的提出其目的是倡导以工程的原理、原则和方法进行软件开发,以解决软件危机。
2、软件开发——实现问题域中的概念和处理逻辑到运行平台的概念和处理逻辑的映射。
3、软件开发本质:
不同抽象层术语之间的“映射”。
不同抽象层处理逻辑之间的“映射”。
4、实现映射的基本手段:建模
5、模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述。
6、软件系统或项的模型分类
概念模型
设计模型
实现模型
部署模型
{设计模型、实现模型、部署模型}=软件模型
7、软件工程可定义为三元组:<目标,原则,活动>
8、软件需求阶段所要完成的任务
需求获取
需求定义
需求规约:系统需求规格说明
需求验证
9、软件设计阶段包括总体设计(概要设计)和详细设计。
10、软件维护类型:
完善性维护、纠错性维护和适应性维护
11、只有高水平的软件工程管理,才能生产出高质量的软件产品。
软件过程#
1、开发逻辑是获取正确软件的关键。
2、软件生存周期:如那件产品或系统的一系列活动的全周期。
3、软件生存周期过程:
为了表述软件开发需要做“什么映射”,引入了以下三个概念:过程是活动的集合,活动是任务的集合,任务是把输入转换成输出的操作。过程->活动->任务。(大->小)
4、按**承担软件开发工作的主体**,将软件生存周期过程分为三类:
基本过程={获取过程、供应过程、开发过程(开发过程是软件开发者所从事的一系列活动)、运行过程、维护过程}
(指那些与软件生产直接相关的活动集)
支持过程
(有关各方按其目标所从事的一系列支持活动集)
组织过程
(指那谢谢与软件生产组织有关的活动集)
5、软件生存周期模型是对软件生存周期中过程、活动和任务的组织。
6、软件生存周期模型是软件过程、活动、任务的结构框架。
7、喷泉模型的特征:迭代和无缝
第三章 需求工程
1、软件是容易修改的,但修改正确是很难得。
2、最优化是系统工程所追求的目标。
3、软件需求是软件开发的工作基础。
4、瀑布模型的开发过程是一种自顶向下的开发方法,而软件构件复用的开发过程是一种自底向上的开发方法。
5、需求的定义:
一个需求是有关“要予构造”的陈述,描述了待开发产品/系统功能上的能力、性能参数或者其他性质。
6、需求的基本性质
必要性
无歧义性
可测性
可跟踪性
可测量性
7、需求分类:
功能
性能需求
外部接口需求
设计约束
质量属性
8、需求规约概念:
一个需求规约是一个软件项/产品/系统所有需求陈述的正式文档,是一个软件产品/系统的**概念模型**。
9、需求规约的基本性质:
重要性和稳定性
可修改性
完整性
一致性
10、需求规约会产生两个文档——初始测试计划和用户系统操作描述。
11、在需求分析阶段会形成确认测试的测试计划。
12、非功能需求必须依附于非功能需求而存在。
13、运行平台属于设计约束
14、与其他类型的非功能需求不同,设计约束是必须给予满足的,且对项目规划、所需的附加成本和工作产生直接影响。
15、质量属性必须要给出量化的测试目标。
第五章 结构化分析与设计
1、软件开发方法:
软件开发方法是指软件开发过程所遵循的办法和步骤。
软件开发活动的目的是有效地得到一个运行的系统及其支持文档,并满足有关的质量要求。
软件开发方法学指的是规则、方法和工具的集成。
2、结构化方法包括:结构化分析方法、结构化设计方法、结构化程序设计方法。
3、需求分析的目标:
解决需求陈述中的歧义、不一致问题。
作为开发人员和客户间技术契约的基础,并作为而后开发活动的一个基本输入。
给出问题的形式化或半形式化的描述。
4、
数据流、数据存储——支持数据抽象
加工——支持过程/功能的抽象
数据源、数据潭——支持系统边界抽象
5、数据流图(DFD)——表达系统功能模型的工具。需求分析的首要任务就是建立系统功能模型。
6、数据字典——定义数据流和数据存储
7、判定表或判定树——定义加工小说明
8、通过功能分解可以完成数据流图的细化
9、数据字典:
数据流
数据存储
数据项
10、需求分析的输出:XXX系统需求规格说明书
11、需求分析的作用:
软件开发组织和用户之间达成的共识
软件后续设计、编码、测试的基本依据
软件可行性分析的依据
12、不同的功能抽象将导致不同的结果,但应该是等价的。
13、需求验证(SRS):
正确性
无二义性
完整性
可验证性
一致性
可理解性
可修改行
可被跟踪性
可跟踪性
设计无关性
注释
14、结构化设计的目标:
依据需求规约,在一个抽象层上建立系统软件模型,包括软件体系结构(数据和程序结构),以及详细的处理算法,产生设计规格说明书。
15、总体设计包括:体系结构设计、接口设计、数据设计。
16、总体设计术语/符号:长方形方框表示模块;直线连接表示调用。
17、总体设计的具体任务是:将DFD转化为MSD。
18、总体设计的任务:
将DFD转化为MSD
精化初始模块结构图(MSD),根据穿越系统边界的数据流初步确定系统与外部的接口。
设计其中的全局数据结构和每一模块的接口。
19、所有的数据流图都可以看作变换型数据流图。
20、变换设计的基本步骤:
复审并精化系统需求模型
确定输入、变换、输出三部分之间的边界、
系统模块结构图顶层和第一层的设计
自顶向下,逐步求精
21、总体设计步骤
DFD->初始的MSD
将初始的MSD转化为最终可供详细设计使用的MSD
22、模块化的基本原则:高内聚,低耦合。
23、内容耦合的耦合性最强。
24、如果模块间必须存在耦合,就尽量使用数据耦合,少用控制耦合,限制公共耦合的范围,坚决避免使用内容耦合。
25、系统的接口设计(包括用户界面设计及与其他系统的接口设计)是由穿过系统边界的数据流定义的。
26、在设计阶段,必须根据需求把交互细节加入到用户界面设计中,包括人机交互所必须的实际显示和输入。
27、接口设计的主要内容:
模块或软件构件间的接口设计
软件与其他软硬件系统之间的接口设计
软件与用户之间的交互设计
28、详细设计的任务是定义每个模块的算法和数据格式
29、伪码的优点:PDL不仅可以作为设计工具,而且可以作为注释工具。
30、程序流程图的优点:对控制流程的描绘很直观,便于初学者掌握。
31、PAD图的优点:支持自顶向下逐步求精的结构化详细设计。
32、N-S图的优点:支持自顶向下逐步求精的结构化详细设计,并严格限制了控制从一个处理到另一个处理。
33、判定表和判定树:表达复杂的条件组合与应做的动作之间的对应关系。
34、结构化方法的基本原理:
自顶向下功能分解
数据抽象
功能/过程抽象
模块化
35、结构化方法的抽象层包括:
需求分析层
设计层
实现层
36、结构化方法看待世界的基本观点:
一切系统都是由信息流构成,每一个信息流都有自己的起点-数据源,有自己的归宿-数据潭,有驱动信息流动的加工,因此所谓信息处理主要表现为信息的流动。
第七章 面向对象
1、面向对象方法真正深远的目标是它适用于解决分析与设计期间的复杂性并实现分析与设计的复用。
2、对象之间只能通过消息传递。
3、UML作用:
弥补应用系统和运行平台之间的“距离”
建立不同抽象层次的术语空间和模型表达工具
支持多视角地建立系统模型
4、UML是一种半形式化语言
5、UML结构:静态对象结构、动态行为、系统部署
6、在类的属性定义中引入可见性,主要是为了支持信息隐蔽这一软件设计原则。
7、
类与对象——体现数据抽象
接口——体现功能缺陷
协作——体现行为结构抽象
用况——体现功能抽象
主动类——体现并发行为抽象
8、接口在形式上等价于一个没有属性、没有方法而只有抽象操作的抽象类。
9、UML八个术语:类、接口、协作、用况、主动类、构件、制品、节点。
10、 用况是对一组动作序列的描述,系统执行这些动作产生对特定的参与者一个有值的、可观察的结果。用况用于模型化系统中的行为。一个用况描述了系统的一个完整地功能需求。用况是通过协作给予细化的。、
11、协作是一组类、接口和其他元素的群体,他们共同工作以提供比各组成部分的总合更强的合作行为。
12、UML为了组织类目,控制信息组织和文档组织得复杂性而引入的术语是包。
13、如果整体类的实例和部分类的实例具有相同的生命周期,这样的聚合成为组合。
14、实例连接又称链,它表达了对象之间的静态关系。
15、在类的一个关联中,可以显示地命名该角色。
16、对于关联另一端的类的每个对象,本端的类可能有多个对象出现。
17、泛化是一般性事物(父类)和它的较为特殊种类(子类)之间的一种关系。
18、依赖是一种使用关系,用于描述一个事物使用另一个事务的信息和服务。
19、UML为不同抽象层提供了6种可对系统静态部分建模的图形工具:
类图
构件图
组合结构图
对象图
部署图
制品图
20、UML为不同抽象层提供了7种可对系统动态部分建模的图形工具:
用况图:需求模型
状态图
活动图
顺序图
通信图
交互概观图
定时图
21、类图主要用于对系统的静态视图进行建模(投影),支持表达系统的功能需求,即系统提供给最终用户的服务。
22、当用关联关系建模时,是在对相互同等的两个类建模,给定两个类之间的关联,则这两个类以某种方式相互依赖,并且常常从两边都可以导航。
23、依赖关系是使用关系,常见的依赖关系是两个类之间的连接,其中一个类只是使用另一个类作为它的操作参数。
24、泛化关系是“is-a-kind-of”关系,在对系统的词汇建模中,经常遇到结构或行为上与其他类相似的类,可以提取所有共同的结构特征和行为特征,并把它们提升到较一般的类中,特殊类继承这些特征。
25、遂于每一个关联关系都需要说明其多重性,如果不说明,则默认是*。
26、用况图通常包含6个抽象:主题、用况、参与者、依赖、泛化、关联。
注:为使用况图表达的系统更容易理解,包含注解和约束。
27、关联是操作者和用况之间的唯一关系。扩展和包含是依赖的变体。
28、用况图中的关系:关联、泛化、包含、扩展
29、参与者一般可以表达与系统交互的人、硬件或系统等,因此实质上不是软件的一部分。
30、用况图可以划分系统与外部实体的界限,是系统开发的起点。
31、顺序图是一种交互图,即由一组对象以及这些对象之间的关系(通信)组成,其中还包含这些对象之间被发送的消息。
32、从应用的角度来看,交互图是一个交互中各元素的投影。其中把这些元素的语义应用到交互图中。
33、在顺序图中,对象生命线用于表示一个对象在一个特定的时间段中的存在,一般表示为垂直的虚线。
34、同步消息的回复使用虚线枝形箭头,调用则用实心三角箭头。
35、顺序图由类角色,生命线,激活期和消息组成。
36、状态图是显示一个状态机的图,其中强调了从一个状态到另一各状态的控制流。一个状态机是一种行为,规约了一个对象在其生存期间因响应事件并作出响应而经历的状态。
第八章 面向对象分析与设计
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· DeepSeek 开源周回顾「GitHub 热点速览」
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了