《软件工程导论》第五版 张海藩 编著 总结文档格式.docx
《《软件工程导论》第五版 张海藩 编著 总结文档格式.docx》由会员分享，可在线阅读，更多相关《《软件工程导论》第五版 张海藩 编著 总结文档格式.docx（23页珍藏版）》请在冰豆网上搜索。
原型模型（软件产品的开发是线性顺序进行的，本质是快速，用途是获知用户的真正需求，一旦需求确定，原型将被抛弃）。
其核心都是将软件开发划分为：
分析、设计、编码、测试和维护。
v∙软件生存周期划分为以下几个阶段：
可行性研究与计划、需求分析、总体设计、详细设计、实现、组装测试、确认测试、使用和维护。
v∙软件过程：
是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤
v∙软件工程方法学：
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称范型
v∙软件工程过程是软件生存周期中各个可能的过程，这些过程可进一步划分成为了提供或获得软件产品或服务，或是为了完成软件工程项目需要完成的有关软件工程活动，每一项活动又可分解为一些软件工程任务。
标准定义了21个过程分属三类：
基本过程（include获取、供应、开发、运作、维护过程）、支持过程和组织过程。
v∙软件工程三要素：
方法、工具和过程。
v∙软件工程管理
目的：
为了按照进度及预算完成软件计划，实现预期的经济和社会效益。
内容：
成本估算、进度安排、人员组织、质量保证、配置管理等等。
怎么强调软件工程管理的极其重要性都不会过分
Ø
∙Unit2
∙可行性研究
任务和目的：
用最小的代价在尽可能短的时间内确定问题是否能够在一定规模之内解决。
（确定这一问题是否存在值得去做的解）
过程和步骤：
实质：
进行一次大大压缩简化了的系统分析和设计过程，也就是在较高层次上以抽象方式进行的系统分析和设计过程。
技术和工具：
DFD+DD
∙主要内容
（1）澄清问题定义
——规模、约束和限制
（2）导出新系统的逻辑模型
（3）导出若干个供选择的物理解法（物理模型），并分别研究它们的可能行：
∙数据流图符号
Example：
∙数据流图的基本目的是
利用它作为交流信息的工具，另一个主要目的是作为分析和设计的工具。
∙数据字典是关于数据信息的集合，也就是对数据流图中包含的所有元素的定义的集合，它是通过对数据元素和数据结构的定义，来描述数据流和数据存储的逻辑内容的。
∙数据流和数据字典共同构成系统的逻辑模型。
∙数据字典的内容：
数据流、数据元素、数据存储、处理
∙数据字典最重要的用途是作为分析阶段的工具。
v∙Unit3
v∙需求分析：
精确地定义系统必须做什么，也就是对目标系统提出完整、准确、清晰、具体的要求。
——为目标系统提出精确的逻辑模型。
任务：
确定对系统的综合要求，包括功能需求、性能需求、可靠性和可用性需求、运行要求、将来可能提出的要求。
过程：
处理逻辑的分解：
自顶向下逐步分解直到每个处理逻辑已是不可再分的“功能单元”为止。
书写文档：
软件需求规格说明
工具：
状态图、IPO图、层次方框图、Warnier图
v∙结构化分析设计技术是70年代中期由E.Yourdon等人提出来的一种面向数据流的方法；
要求系统的开发工作在结构化和模块化的基础上进行，它系统的运用了描述模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解，直到找出满足要求的可实现的软件。
在这个方法里，“抽象”，“分解”，“模块化”，“结构化”是它的主要手段；
面向数据传递、变换所形成的数据流（Dataflow）和数据流程图（DFD）是它的主要依据。
这个方法的关键工作是：
画分层的DFD和确定数据定义与加工策略。
v∙Yourdon方法（对应的瀑布模型）的缺陷:
其实Yourdon方法是建立在三个假设之上的：
假设1：
所有的需求都是可以预先定义的；
假设2：
需求在较长一段时间内是不变的（相对稳定的）；
假设3：
运用所提供的工具可以做到项目参与者之间清晰、准确、有效的沟通。
这三个假设往往是很难成立的：
“逻辑模型”的精确描述依赖于“自顶向下的求精过程”，而“自顶向下的求精过程”的顺利进行又依赖于精确的“逻辑模型”，这二个问题互相缠绕依赖而构成方法学上的“死锁”。
v∙原型法（原型模型）：
原型就是模型的意思（原型=模型），它指的是模拟某种产品的原始模型。
运用原型的策略：
抛弃策略&
附加策略
对原型的逐步求精过程是一个迭代过程
相对于Yourdon方法来说原型法是一个非线性的系统开发方法。
不再强调高质量的阶段性文档。
v∙螺旋模型：
沿螺线自内向外每旋转一圈便开发出一个更为完善的软件版本
v∙Yourdon方法适合于“预先指定的系统”；
v∙原型法适合于“用户驱动的系统”。
v∙通常用“范式”定义消除数据冗余程度。
第一范式数据冗余程度最大，第五范式数据冗余程度最小。
v∙状态转换图：
状态时可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，它规定了系统对事件的响应方式。
一张状态图有一个初态和0至多个终态。
事件：
在某个特定时刻引起系统做动作和（或）状态转换的控制信息。
v∙验证软件需求的正确性：
一致性、完整性、现实性、有效性
∙Unit4
∙总体设计：
确定系统的具体物理实现方案（系统结构设计），确定组成每一个程序的模块，以及模块间的关系（软件结构设计）。
软件结构设计（过程设计是详细设计阶段的任务）
设想供选择的方案
选取合理方案（每份方案有
系统流程图、组成系统的物理元素清单、成本/效益分析、实现这个系统的进度计划
4份资料）等9步（P92）
∙在软件开发早期阶段考虑测试问题，能促使软件设计人员在设计时注意提高软件的可测试性。
∙总体设计阶段书写的文档：
系统说明、用户手册、测试计划、详细的实现计划、数据库设计结果。
∙总体设计过程中，推荐最佳方案后进入“软件结构”设计：
设计出组成这个系统的所有程序、文件和数据库，以及它们之间的联系。
软件结构：
由模块组成的层次系统。
模块：
数据说明、可执行语句等程序。
∙C/S（Client/Server）结构是软件系统体系结构
∙“结构化设计”概括地说就是：
用一组标准的工具和准则来确定系统应该由哪些模块、用什么方式联结在一起，才能构成一个最好的软件结构。
∙模块化就是把程序划分成若干个模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。
∙模块:
具有四种属性的一组程序语句称为一个模块，这四种属性分别是：
输入和输出、逻辑功能、运行程序、内部数据。
（前两个是模块外部属性，后两个是内部属性，总体设计完成外部属性设计、详细设计完成内部属性设计）
∙软件结构图中，模块用一矩形表示。
∙模块间调用：
用→连接
∙开发具有独立功能而且和其它模块之间没有过多相互作用的模块，可以做到模块独立。
∙影响模块独立的因素：
耦合（不同模块间互联程度）
内聚（同一模块内各元素紧密程度）
∙力争高内聚、低耦合。
∙5种耦合形式：
数据耦合、控制耦合、特征耦合、公共耦合、内容耦合（从左到右耦合程度递增）
最弱的耦合是非直接耦合
∙7种内聚形式：
功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚（从左到右程度依次递减）
∙模块的扇出与扇入：
模块的扇出是指一个模块拥有的直接下级模块的个数。
模块的扇入是指一个模块的直接上级模块的个数。
模块的扇出系数应控制在7以内，尽可能的加大模块的扇入系数。
∙作用域应该是控制域的子集；
∙模块的控制域和作用域：
模块的控制域（控制范围）：
是指这个模块本身以及所有直接或间接从属于它的模块的集合。
模块的作用域（判断作用范围）：
是指受该模块内一个判断影响的所有模块的集合。
（也就是该模块内存在着判断调用语句，而所有受到该判断逻辑影响的模块，就是该模块的作用域。
）
作用域应该是控制域的子集；
理想的是作用域都是直接下属模块。
∙数据流类型——数据在DFD中流径特征
变换流：
进入系统中的数据所流经的路径几乎是一样的。
事务流：
进入系统中的数据所流经的路径不完全是一样的。
∙
∙事务中心往往包含多个处理逻辑。
∙“事务”是指一组输入数据。
v∙Unit5
v∙详细设计:
目的:
完成模块的过程设计
（为SC中每个模块确定采用的算法和块内数据结构，用某种选定的表达工具给出详细清晰的描述。
模块的逻辑设计（模块的过程描述）
主要内容：
1）为每个模块确定采用的算法
2）确定每个模块使用的内部数据结构
3）确定模块的接口细节
4）制定模块的测试计划
完成模块的“内部属性”设计，即给出系统中各个模块的“运行程序”和“内部数据”；
由此可见详细设计的结果基本上决定了最终软件的质量。
详细设计的目标更重要的是便于维护。
1.程序流程图（流程图）
2.N-S图（盒图）
3.PAD图（问题分析图）
4.伪代码和PDL语言
v∙逻辑设计应遵循的理念：
1.从效率第一到清晰第一
2.结构化的控制结构：
结构化程序设计=仅使用单入口单出口的三种基本控制结构
3.逐步细化的实现方法
[例]
在一组数中找出其中的最大数
分别用程序流程图、N-S图和PAD图描述
用“结构化”保证程序的清晰易读，用“逐步细化”实现程序的正确可靠，它们导致了一条自然的结论：
模块的逻辑设计必须用结构化程序设计的原理来指导。
（结构化分析设计在详细设计阶段）
v∙Yourdon方法的技术途径：
DFD→DFD+DD→SC→PDL
v∙Yourdon方法在分析阶段，我们用DFD来表示软件的逻辑模型；
在设计阶段，又按照数据流类型，分别用变换分析或事务分析将它们转换成相应的软件结构。
v∙面向数据结构设计方法的根据和基本思想：
算法和数据结构是程序设计中不可分割的侧面，算法的结构依赖于它要处理的数据结构。
只要事先知道一个问题的数据结构，就可以由此导出它的程序结构。
v∙基于数据流还是基于数据结构的出发点不同，最终目标也不同。
SADT（结构化分析设计工具）方法的目标是得出软件的最终SC图，它把注意力集中在模块的合理划分上；
面向数据结构的设计则要求得出程序的过程性描述，并不明确也提出软件应该先分成模块等概念。
v∙SADT方法：
DFD
->
SC（软件结构图）->
模块的过程性描述（PDL等）
|<
-------总体设计------->
|
--------详细设计------->
|
Jackson方法（面向数据结构）：
数据结构
程序结构->
程序的过程性描述（伪代码等）
-----总体设计----->
----------详细设计--------->
v∙程序复杂程度的定量度量：
1.程序图（流图）（用任何方法表示的详细设计结果都可以变换成程序图）
流程图中的各种处理框均简化成一个结点
2.环域复杂度
程序的结构复杂度可用强连通的有向图中线性无关环的个数来度量
V（G）=
判定结点数
+
1
∙Unit6
∙编码（也称实现）
把模块的过程性描述翻译为用该语言书写的源程序（或源代码）。
∙编码的风格
1.程序要清晰直观，不要过于巧妙
2.用一定的原则指导控制结构的使用（避免使用容易引起混淆的结构和语句）
3.有规律地使用GOTO语句
不得不把效率的考虑放在首位的时候，而结构化程序又不能满足时间要求时，就可用GOTO语句来减少重复的代码段；
4.实现源程序的文档化（软件=程序+文档）<
有意义的变量名称、适当注释、标准的书写格式>
v∙Unit7：
v∙软件测试：
定义：
程序测试是为了发现错误而执行程序的过程。
纠错（调试）是为了确定错误的性质，并且加以纠正。
v∙软件测试包括机器测试（动态测试）（黑盒测试&
白盒测试）和人工测试（代码复审）（代码走查+会审+办公桌检查）
程序编译通过后，应该先人工测试（发现逻辑错误）后机器测试（在设定的测试数据上执行被测程序）.
v∙动态测试是一个包括：
①设计“测试用例”→②执行被测程序→③分析测试结果并发现错误的过程。
（①设计“测试用例”是最关键）
测试用例＝{
输入数据
期望结果
}
按照在设计“测试用例”时，是否涉及程序的内部结构，把动态测试分为：
白盒测试：
从程序的内部逻辑入手，按照一定原则设计测试用例。
黑盒测试：
仅以程序外部功能为依据来设计测试用例。
检查程序是否完成应做的和是否做了不该做的。
（按规格说明书的规定）
v∙软件测试的的步骤：
[见笔记本上图]
单元测试：
在编码阶段完成；
以模块为单位，（主要白盒）发现的往往是编码和详细设计的错误
综合测试：
（模块组装测试、集成测试）以软件的设计信息为依据，主要用黑盒，发现设计错误，也可能发现需求说明错误。
确认测试（验收测试）：
以软件的需求信息为依据，用黑盒，发现需求说明书中的错误，验证软件的有效性
系统测试：
指整个计算机系统（包括软件与硬件）的测试。
v∙代码复审
1.代码会审：
开会逐句朗读和讲解程序，精力集中于发现错误，会后改正错误
2.走查：
与会者扮演“计算机”的角色
3.办公桌检查：
一个人参加的代码会审
v∙黑盒测试方法：
v∙等价分类法：
按测试结果“等价”把被测程序的输入域划分为若干个等价类，每一个等价类都选择一例“测试用例”，与“应做的事情”相对应的是“有效等价类”，而与“不应该做的事情”相对应的称之为“无效等价类”。
设计等价类的测试用例分为两步：
1.划分等价类并给出定义；
2.选择测试用例的原则：
有效等价类的测试用例尽量公用；
无效等价类必须每类一例。
[例]某城市的电话号码……[看笔记]
v∙边界值分析法（边值法）
v∙错误猜测法（猜错法）
v∙因果图法
v∙白盒测试方法：
[见笔记]
合理的白盒测试，就是要选取足够的测试用例，以实现对源程序比较充分的覆盖。
v∙逻辑覆盖法：
（按照由低到高对程序逻辑覆盖程度的顺序）
语句覆盖：
每条语句至少执行一次；
判定覆盖：
不仅每条语句至少执行一次，而且每一分支至少执行一次；
条件覆盖：
不仅语句覆盖，而且每个条件均按“真”、“假”两种结果至少执行一次；
条件组合覆盖：
不仅语句覆盖，而且每个条件的所有可能组合都至少执行一次。
v∙路径覆盖法：
（按照由低到高对程序逻辑覆盖程度）
结点覆盖：
每个结点走一次；
相当于语句覆盖
边覆盖：
每条边走一次；
相当于判定覆盖
路径覆盖：
每条路径走一次；
（不需要考虑程序的循环）
∙Unit8
∙面向对象基本原理：
使描述问题的问题空间和在计算机上解决问题的解空间在结构上尽可能一致。
∙基本概念：
（1）对象：
由数据以及可以施加在这些数据上的操作（或服务、方法、处理）所构成的统一体，它是面向对象软件的基本模块。
（2）类：
对具有相同数据和相同操作的一组相似对象的定义（抽象）。
（3）不同的对象彼此之间只能通过消息相互作用、相互联系
（4）继承:
处于下一层次上的派生类自动继承了位于上一层次基类的属性（数据）和行为（操作）
∙面向对象就是既使用对象又使用类和继承等机制，而对象之间仅能通过传递消息实现彼此间的通信。
∙UML
用视图来表示被建模系统的各个方面，它把软件模型分成5个视图，每一个视图代表完整系统的一个特定方面。
每一个视图又由一种或多种模型图构成。
1．
用例视图：
用来支持需求分析，也就是说系统将提供的功能是在用例视图中描述的。
2．
逻辑视图：
定义系统的实现逻辑,重点关注的是系统的静态结构（类、对象及它们之间的关系）,也描述系统内部的动态协作关系。
它的模型图包括类图、对象图、状态图、顺序图、协作图及活动图等。
3．
组件视图：
描述系统的实现模块及它们之间的依赖关系。
组件是不同类型的代码模块，通过代码模块的结构和依赖关系来表示。
4．
部署视图：
描述软件系统在计算机硬件系统和网络上的安装、分发和分布情况。
5．
实现视图：
描述组成软件系统的各个物理部件。
∙UML由三部分组成：
基本构造块、规则和公用机制
定义了二类模型元素的图形表示：
一类模型元素用于表示模型中的某个概念，一类模型元素用于表示模型元素之间的关系
∙
面向对象建模：
对象模型——“谁做？
”（类图）
动态模型——“什么时候做？
”（状态图）
功能模型——“做什么？
”（用例图）
这三种模型都是必不可少的，对象模型是最核心的。
在面向对象分析中，构造出完全独立于实现的应用域模型；
在面向对象设计中，把求解域的结构逐渐加入到模型中；
在实现阶段，把应用域和求解域的结构进行编码和验证。
∙OO方法：
OOA→OOD→OOP→OOT
是一个逐渐扩充模型的过程，其间无需转换概念和表示，开发活动之间基本做到了平滑无缝过渡；
∙对象模型：
类与类之间一般有四种关系：
关联、泛化（继承）、依赖和细化。
1.
关联：
表示两个类的“对象”之间存在某种语义上的联系。
2.
聚集：
聚集是关联的特例，它表示类与类之间的关系是整体与部分的关系。
3.
泛化（继承）：
泛化关系指的是类与类之间是“一般
---
特殊”的关系。
4.
依赖和细化：
依赖关系是指一个模型元素依赖于另一个独立的模型元素，细化关系是指一个模型元素细化成了另一个模型元素。
∙动态模型：
描述了对象模型中对象的生命周期过程，即对象的状态，我们把一个触发行为称为一个事件。
动态模型就是通过描述对象的状态、触发状态转换的事件、以及对象的行为来描述软件系统的动态行为（行为模型）。
∙功能模型：
UML提供用例图来表示功能模型，并称之为用例模型。
功能模型也可用SADT中的一组DFD来表示。
（也是需求分析阶段）
一幅用例图包含的模型元素有：
系统、行为者、用例和用例之间的关系。
一个用例是系统的一个完整的功能，通过关联与行为者连接，关联指出一个用例与哪些行为者交互，这种交互是双向的。
用例是一个类，用例的实例是系统的一种实际使用方法，我们称之为脚本。
用例之间的关系主要有二种：
扩展关系和使用关系。
创建用例模型的工作包括：
定义系统、寻找行为者和用例、描述用例、定义用例之间的关系，并确认用例模型。
v∙Unit9：
v∙面向对象分析（Object-Oriented
Analysis,简称OOA）的关键就是识别出对象与类，并分析它们之间的关系，最终建立对象模型、动态模型和功能模型。
图：
参照当前系统建立目标系统
v∙通过划分“主题”把一个复杂系统的对象模型分解成几个不同的概念范畴。
v∙
∙软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
∙维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。
∙进行维护的原因：
改正程序中的错误和缺陷；
改进设计以适应新的软、硬件环境;
增加新的应用范围；
为了将来的维护工作。
∙维护分为以下几类：
改正性维护；
适应性维护；
完善性维护；
预防性维护
--------------------------------------------------------------------------------------------------------------------------------------
∙未涵盖进来的内容：
∙需求分析目的：
确定目标系统必须具备哪些功能
∙总体设计的主要任务：
一.制定几种可能的实现方案；
二.设计程序的体系结构
∙详细设计（模块设计）任务：
设计出程序的详细规格说明
∙集成测试和验收测试：
集成测试（组装测试）：
根据设计的软件结构
验收测试：
按照规格说明书的规定，由用户参与下对目标系统进行验收的测试
∙通过对软件测试结果的分析可以预测软件的可靠性。
∙传统软件工程方法学的软件过程，可以用瀑布模型来描述
∙瀑布模型的特点：
阶段间具有顺序性和依赖性、推迟实现的观点
清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。
∙瀑布模型带反馈环，发现前面阶段的错误时，沿反馈线回头修改
∙快速原型模型不带反馈环，软件产品开发是线性顺序进行的，用途是获知用户的需求
∙增量模型（渐增模型）：
把软件产品分解成增量构件。
原则：
当把新构件集成到原有构件时，所形成的产品必须是可测试的。
它能在较短时间内向用户提交可完成部分工作的产品。
要求开始实现各个构件前就全部完成的需求分析、规格说明、总体设计。
∙螺旋模型的基本思想：
使用原形及其他方法来尽量降低风险。
可以看作每个阶段前都加了风险分析的快速原型模型。
螺旋模型是风险驱动型的。
∙喷泉模型体现了面向对象开发过程迭代和无缝的特性。
∙采用先行
升级会员 