河北工业大学软件工程期末复习.docx
《河北工业大学软件工程期末复习.docx》由会员分享，可在线阅读，更多相关《河北工业大学软件工程期末复习.docx（23页珍藏版）》请在冰豆网上搜索。
河北工业大学软件工程期末复习
软件工程期末复习总结
第一讲概述（选择U填空U简答）
1.1软件工程的研究内容
软件工程要考虑专业软件开发所需要的理论、方法和工具----工程技术问题
软件工程要考虑如何有效的在软件开发中利用有限的成本资源----工程管理的问题
1.2什么是软件？
软件包括：
---软件的内涵
1能够提供客户所需功能与性能的计算机程序；
2使程序能够适当的操作信息的数据结构；
3用以描述程序开发过程及使用的文档。
软件产品可以为一个特定的用户设计开发，也可以为某一类通用的市场设计开发。
软件产品可以分成：
L通用软件（GenericSoftware）1厂二二、
:
二汎桂荻J
>定制软件（BespokeSoftware）：
、—”
一个新的软件并不一定是全新开发，可以由现有软件或可复用软件成分配置形成。
1.3什么是软件工程？
软件工程是涉及软件生产各个方面的一门工程学科
软件工程涉及软件生命周期的各个方面，从软件需求的确定到软件退役。
软件工程：
（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过
程，即将工程化应用于软件；
（2）研究
（1）中的方法.
——IEEE[IEE93]
1.4什么是成功的软件项目
一个成功软件项目的三个要素包括：
按时交付不超预算满足用户要求。
1.5软件过程与软件生命周期的相关概念
软件过程是指开发或制作软件产品的一系列活动及其成果
所有的软件过程中都包括四个基本活动：
（填空）
1.描述（Specification）-系统应该提供的功能及其开发约束；
2.开发（Development）-软件产品的生产过程；
3.有效性验证（Validation）-检验软件产品是否满足了客户的需要；
4.进化（Evolution）-按照用户的变更要求不断的改进软件。
软件生命周期是软件过程的另一种形象描述，通常包括需求定义、分析与描述、软件设计、
实现、测试、维护与退役等活动。
1.6什么是优良软件的属性？
P8（填空U选择）
优良的软件应能交付相应的功能与性能，而且应具有良好的可维护性、可依赖性、有效性
和可用性：
（选择题，考法内涵匹配）
可维护性（Maintainability）
Softwaremustevolvetomeetchangingneeds;
可依赖性（Dependability）
Softwaremustbetrustworthy;
有效性（Efficiency）
Softwareshouldnotmakewastefuluseofsystemresources;
可接受性（Acceptability）
Softwaremustbeacceptedbytheusersforwhichitwasdesigned.Thismeansitmustbeunderstandable,usableandcompatiblewithothersystems.
1产品特性
描述
可維护性
敦件必须能髒不斷进化以满足客户的需求变化，这足软件产品履根木的特性，因为工作环境是不断变化的，软件也必然蓦跟着变化・
可依赖性
软件可依疲性啊括一系列特性.包括可靠性、保裤性、住全性.可靠的软件在系统失畋曲情况下.也不会导致人员伤亡和经济损失.
有效性
软件不要浪费内存和处理器等系统资源，因而有敕性应包括响应时间.处理时间.内存利用率等方面.
可用性
可用性就是用户不用特殊地勢力就能操柞n这就姦味着，轶件必须具备相惬的用户界面利充分的说明立档。
第二讲软件过程（画法+特点+结构+缺点+适用场合）
2.1瀑布模型（顺序模型）（特点：
变更少）（画法+特点+结构+缺点+适用场合）
1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护
（中文解释）
瀑布模型的缺点和适用情况
这种模型生硬的把一个软件过程划分成几个界限清晰的阶段，而且这些阶段前后有严格的顺序，这导致它很难对用户的需求变更做出及时的调整；
因此，瀑布模型只适合需求非常清楚和需求变更被严格限制的情况下。
实际的软件开发过程中，几乎没有多少业务系统具有稳定的需求。
瀑布模型反映了工程设计的基本思想。
2.2进化式开发模型（画法+特点+结构+缺点+适用场合）
基本思想：
通过开发系统原型和用户反复交互，以明确需求，使系统在不断调整与修改中得以进化成熟。
又叫做原型式开发方法。
两种基本类型:
探索式开发；抛弃式原型法
并存活动
2.2进化式开发模型问题
缺乏过程可见性；系统结构通常会很差
需要一些特别的技术（如原型快速开发技术），通常与主流技术不兼容•
适用情况
适合中小规模的交互系统；
可用于大型系统的局部开发（如系统界面），可以和瀑布模型混合使用；
生命周期较短的系统
2.3基于过程反复的过程模型
对于大型项目而言，系统需求的变更是无法避免的，因此开发过程的反复是软件开发的必过程反复可以和任何一种一般过程模型结合使用。
两种支持过程反复的过程模型：
增量式开发；
螺旋式开发。
2.3增量式开发
在这种开发方式中，系统不是作为一个整体交付，而是被分解成若干个增量，每个增量交付系统的部分功能。
用户的需求按优先级排队，优先级最高的需求被放入最早交付的增量中。
这样，优先级最高的系统功能就得到最多的测试，系统的可靠性较高。
由于每个增量可以交付部分系统功能，因此软件可以较早的交付用户使用（部分功能）早期交付的增量可以作为后期增量的原型帮助后期需求的确定；
项目总体的失败率较低；
优先级最高的系统功能得到最多的测试。
螺旋式开发
这种模型用螺旋线表示软件过程，而不是采用一系列活动及活动间的反馈；螺旋中的每个回路表示软件过程中的一个阶段；
这种模型充分考虑了软件开发所面临的风险，并贯穿软件过程始终。
螺旋线划分成四部分
目标设置、风险评估和规避、开发与有效性验证、规划
2.4基于构件的软件工程
软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素（通常称为可复用构件、组件或软部件）的过程。
软构件是标准的、可以互换的、经过装配可随时使用的软件模块。
在UML中，软构件被定义为系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现并暴露一系列的接口。
软件复用的意义
软件复用的出发点是使软件系统的开发不再“一切从零开始”，能够充分利用已有的知识和
经验。
软件复用能够在软件开发中避免重复劳动，充分利用已有的开发成果，，提高开发效率，降
低开发成本。
软件复用还可以避免全新开发可能引入的错误，从而提高软件的开发质量。
构件的基本概念
构件是为组装服务的！
软件构件是指可以独立生产、获取和部署的、可以被组装到一个功能性系统中去的可执行单丿元。
软构件是标准的、可以互换的、经过装配可随时使用的软件模块。
基于构件的软件工程
'•组件分析•卜需求修订•
・基于复用的系统设计
系统验证—
开发弓集成」
需求描述
VS
第三讲需求工程（概念+综合分析（面向对象建模UML分析））
3.1需求工程过程
需求工程过程并不具有唯一的模型，在所有的过程中都会涉及一些共同的活动，
Feadbilityreport
；需求管
它们是：
可行性研究（必不可少）；需求导出与分析；需求描述；需求有效性验证理。
（填空U选择）
可行性研究要决定被提议的系统是否值得去做。
进行可行性研究包括信息评估、信息汇总和书写报告三部分工作。
3.3需求的两个不同层次的描述
用户需求
从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明。
系统需求
系统需求是一种结构化文档，要运用一些专业的模型详细的描述系统的功能及其约束。
系统需求文档有时也称为功能描述，应该是精确的，它可以成为双方之间合同的重要内容，同时作为开发工作的依据
3.4功能需求与非功能需求
功能需求
对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的描述。
某些情况下还要包括系统不应做什么。
非功能需求（全局的）
对系统提供服务或功能时收到的约束进行描述。
如时间约束、开发过程约束和标准等。
领域需求
这种需求来自于系统的应用领域，反映领域特征。
可能是功能需求也可能是非功能需求。
功能性需求与非功能性需求相比较，非功能需求往往更为关键，因为非功能需求表示的是系统的整体特征，而功能性需求描述的则是局部功能。
（参看课本例子加强理解）
功能需求
功能需求描述系统所应提供的功能或服务。
取决于待开发软件的类型、未来的用户以及开发的系统类型。
功能性的用户需求只需要对系统应提供的服务进行高层一般描述，对于系统需求，则应该详细的描述系统功能、输入输出及异常。
非功能性需求
非功能需求不直接和功能相关，但定义了实现系统功能受到的约束与系统特性。
如可靠性、响应时间、存储空间、I/O设备能力等。
CASE
非功能需求还常与系统的开发过程有关，表现为过程需求。
如设计必须实用的特定工具集、设计语言和开发方法。
领域需求
领域需求来自于应用领域，描述的是反映领域特点的系统特性与特征。
领域需求可能是新的功能需求，也可能是对现有需求的约束或定义一个特别的计算。
领域需求非常重要，如果领域需求不能满足，可能会使整个系统无法运转。
需求的全面性和一致性
原则上，功能性需求描述应该具备全面性和一致性。
全面性：
包括了所有用户要求的服务。
一致性：
在系统服务的描述中没有冲突和矛盾
需求的两个不同层次的描述
用户需求：
用户需求是从用户角度来描述的系统功能需求与非功能需求，这样的描述可以使不具备专业技术知识的用户能够看明白。
用户需求使用任何人都看得懂的自然语言、图表和直观的图形来描述。
系统需求：
相对于用户需求，系统需求是对系统功能、服务及约束的更详尽的描述。
系统需求是系统实现的基本依据，会被写入合同中。
因此系统需求是一个完全的、一致的系统描述，是设计的起点。
系统需求可以用系统模型来定义与说明。
3.7需求导出与分析
这个阶段在可行性研究之后进行，通常与需求描述交叉进行。
需求导出的过程活动包括：
需求发现、需求的分类与组织、优先排序和冲突解决、需求文档化。
需求的发现与识别是整个过程中最为关键的活动，负责收集目标系统级现存系统的相关信息并从这些信息中提炼出用户需求和系统需求。
信息的来源包括已有的文件，系统的信息持有者（stakeholders）以及相近系统的规约描
述。
需求要从多个视点进行分析
视点用来表述不同角度的需求来源（信息持有者、其它相关系统及领域）。
每一个视点代表
系统需求的一个子集。
从多视点对系统进行分析是十分重要的，因为没有那一种单一的途径能够诠释整个系统需
求
视点的类型：
交互者视点、间接视点、领域视点
3.8结构化分析（SA建模（概念）
结构化分析方法是一种面向数据流的系统建模技术，它从数据加工的角度对系统进行规格描述；
SA帮助分析者理解系统的功能，并采用模型与用户进行交流；不同的模型从不同的角度对系统进行描述。
结构化分析建模
结构化分析方法建立的分析模型结构如下图：
象。
围绕着这个核心的有三种图：
实体一关系图（ERD描述数据对象及数据对象之间的关系；数
据流图（DFD描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能
（子功能）；状态一迁移图（STD描述系统对外部事件如何响应，如何动作。
因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。
（考试用英文）
3.9UML与面向对象分析方法（分析+设计+面向对象建模）
3.9.1理解UML
UML是一种标准的图形化建模语言，它为不同领域的人们提供一种统一的交流标准，这种标
准使得系统构造者能够用标准的、易于理解的方式建立能表达出他们想象力的系统蓝图，
并使客户、分析员、设计人员、程序员和系统其它涉及者能够相互理解和达成一致，从而能够有效地共享和交流设计结果。
3.9.3需求导出工作流程
用适动圏验证用例
在分析的星础上精化用例囹
5RS
'分祈用例场景发血更參细节
--
恙述域櫃型中关谨抽象之间的
濾用如用剛场呈中得到的时象圉
J未验证域模型
需求精化工作流程
要求掌握:
1）用例图的画法；
2）用例表（用例规约描述）的基本结构及描述方法;
3）活动图的画法
4）用CRC分析法确定关键抽象类的过程；
5）用类模型表示关键抽象。
3.10需求有效性验证
需求有效性验证的目的是检验需求描述是否正确地反映了客户的意愿。
（判断）
好的需求对软件系统的开发效率及软件质量起着至关重要的作用。
一个错误发现的越晚,修改它所付出的代价就越大。
Fixingarequirementserrorafterdeliverymaycostupto100timesthecostoffixinganimplementationerror.
阶段
需求分析
软件i殳计
程序编码
单元测试
验收测试
维护|
相对修宾代价
0,1^0,2
0.5
1
2
5
20
需求检查
对需求文档中定义的需求要进行多种检查，这些检查包括：
有效性，Doesthesystemprovidethefunctionswhichbestsupportthecustomer
sneeds?
一致性，Arethereanyrequirementsconflicts?
完备性，Areallfunctionsrequiredbythecustomerincluded?
现实性，Cantherequirementsbeimplementedgivenavailablebudgetandtechnology?
可检查性，Cantherequirementsbechecked?
需求有效性检验技术
需求评审
Systematicmanualanalysisoftherequirements.
建立原型
Usinganexecutablemodelofthesystemtocheckrequirements.
测试用例生成
Developingtestsforrequirementstochecktestability.
第四讲设计工程
4.1软件工程中的设计
设计是一个把问题转换成解决方案的创造性过程；
设计解决的是“如何实现系统”的问题；
从工程管理的角度，软件设计可以分成概要设计（总体设计、系统设计）与细节设计（详细设计）
4.2设计概念
4.2.1模块化
模块化的思想，即把软件划分为可独立命名和编址的构件，每个构件称为一个模块，每个模块完成一个子功能，当把所有模块组装到一起成为一个整体时，便可以完成指定的功能。
模块组成系统或子系统。
“一个复杂问题分割成若干个容易解决、容易管理的小问题后更易于求解”，模块化正是以
此为依据把系统划分成若干个模块，各个击破。
（分而治之）
4.2.2信息隐藏与独立性
信息隐藏原理告诉我们，模块应该设计得使其所含信息（过程和数据）对于那些不需要这些信息的模块来说不可访问；每个模块只完成一个相对独立的特定功能；模块之间仅交换那些为完成系统功能必须交换的信息，即模块应该功能独立的。
采用信息隐藏原理指导模块设计有很多好处：
1）它支持模块的并行开发；
2）减少测试和后期维护的工作量。
因为测试和维护阶段不可避免地要修改设计和代码，模块对大多数数据和过程处理细节的隐藏可以减少错误向外传播。
3）整个系统扩充功能只需“插入”新模块，原有的多数模块无须改动。
模块独立性（Independency）
模块独立性的概念是模块化、抽象和信息隐藏概念的直接产物，模块独立性是通过开发具有单一功能和与其他模块没有过多交互作用的模块来达到的。
独立性好的模块对其它的模块依赖性小，修改时对其它模块的影响小，易于修改和扩充，因此有良好的可维护性。
模块独立性可用两个定性准则来度量：
耦合性（coupling）和内聚性（cohesion）。
耦合是模块之间相对独立性的量度，而内聚则是模块功能相对强度的量度。
模块的内聚性越强，耦合性越弱，独立性越强。
4.3体系结构设计
体系结构（architecture,又称架构）设计的任务是要识别出组成系统的子系统并建立子系
统的控制和通信框架。
体系结构设计是联系需求描述与其他设计活动的桥梁。
系统的组成
系统的组成反映的是系统组织所采用的基本策略。
三种应用广泛的组成类型：
数据中心体系结构（容器模型）；
客户/服务器体系结构；
抽象机或分层体系结构。
4.3.1数据中心体系结构（容器）
数据中心体系结构（容器模型）的基本特点：
所有共享数据放到一个中心数据库（容器）中，所有子系统都能从中存取数据；
当系统中存在大量的数据共享时，数据中心（容器）模型是最为常用的体系结构风格。
432客户/服务器体系结构
客户/服务器模型是一个分布式系统模型，数据和加工过程在多个处理器之间分配；
这种模型的主要组成：
一组为其它子系统提供服务的单机服务器；
一组向服务器请求服务的客户机；
连接客户机与服务器的网络。
4.3.3分层（抽象机）体系结构
这种模型把系统组织成一系列的层次（抽象机），每一层提供一组服务；
这种模型支持增量式的开发，不同层次的服务可以单独交付；
层与层之间以接口相联系，一个接口发生改变，只有毗邻的层会受到影响；
4.4控制模型
控制模型考虑子系统之间的控制流，这是分解模型不考虑的问题。
对控制流建模有两种一般性的方法：
集中式控制
一个子系统专门负责控制，控制其他子系统的启动与停止。
基于事件的控制
不将控制信息集中在一个子系统内，每个子系统都能够接受来自系统外部的事件并作出响应。
4.5架构设计的5视图法
4.6面向对象设计基本设计原则（选择）
开关原则（OCP）:
“一个模块（构件）应该对外延具有开放性，对修改具有封闭性”
Liskov替换原则（LSP）:
“子类可以替换它们的基类”。
依赖倒置原则（DIP）:
“依赖于抽象，而非具体实现“。
接口分离原则（ISP）:
“多个用户专用接口比一个通用接口要好”。
发布复用等价性原则（REP）:
“复用的粒度就是发布的粒度”。
共同封装原则（CCP）:
“一同变更的类应该合在一起”。
共同复用的原则（CRP）:
“不能一起复用的类不能被分到一组”。
4.7从分析到设计的转换一一鲁棒性分析
鲁棒性分析是这样一个过程，它采用鲁棒图引导我们从用例转换为支持用例实现的职责模
鲁棒性分析
鲁棒性分析的输入：
一个用例
这个用例的用例场景
这个用例的活动图（如果可以用到）
域模型（domainmodel）
鲁棒性分析的输出：
通过一个UML序列图和一些设计组件：
边界、服务、实体组件，得出用鲁棒图表示的
设计模型。
鲁棒性分析建立设计模型的过程
1.选择一个适当的用例。
2.把一个参与者放到协作图里面。
3.分析这个用例（活动图）。
对于用例的每一个动作：
a.确定并增加边界组件
b.确定并增加服务组件
c.确定并增加实体组件
d.画出这些组件间的关联
e.把每个组件都贴上用来满足用例交互的动作标签
4.把协作图转换成序列图（可选）（画法）
TheoMandel提出了界面设计的三条“黄金规则”：
置于用户控制之下；减少用户的记忆负担；
保持界面一致。
4.10错误消息
错误消息的设计对界面设计的成败是非常关键的。
设计很差的错误消息会导致用户对整个
系统反感。
错误消息应该是礼貌的、简明的、一致的和建设性的。
4.11帮助系统设计
软件帮助系统不能是用户手册的简单复制，应该有一个合理的组织与结构，应该为用户提供不同的入口。
第五讲软件实现与验证
5.1程序设计与调试
程序设计的任务是把设计转换成程序以及在程序中去除错误，包括编程与调试两个过程。
通常，程序员要对自己开发的程序进行测试，这时程序中的一些明显的错误会暴露出来并被根除，这个过程叫调试。
5.2验证和有效性确认（Verification&Validation）
验证：
“Arewebuildingtheproductright?
”.
检查软件是否符合它的规格描述。
有效性确认：
“Arewebuildingtherightproduct?
”.
检查软件是否满足客户的期待。
5.3验证和有效性确认过程的两种基本方法：
软件审查
通过对系统的各种静态成果，如需求文档、设计文档、源代码，进行检查和分析发现问题。
Maybesupplementbytool-baseddocumentandcodeanalysis
软件测试（概念）简答
通过使用测试数据执行系统，检查运行结果来发现问题。
（简单答法）
Thesystemisexecutedwithtestdataanditsoperationalbehaviourisobserved
5.4程序测试与静态审查
测试的目的是为了揭示程序中存在错误，而不是没有错误。
（判断）---记住：
发现错误
按照测试的不同目标可以把测试分成有效性测试与缺陷测试。
静态审查无法检验软件是否可用，也不能检验非功能需求，因此程序测试是必不可少的，
是起决定性作用的V&V技术。
在V&V过程中，程序测试和静态审查通常是结合在一起使用的。
测试和调试
测试和调试是不同的过程，通常交叉进行。
检验和有效性验证的目的是确定系统中存在缺陷；
调试考虑的是定位和修改缺陷。
5.5V&V规划（理解）
仔细的规划能够使程序检查和测试的工作得到更多的回报。
V&V过程的规划应该从开发过程的早期就开始。
V&V规划应该明确的说明静态检查与测试任务与分工。
测试规划主要是制定测试过程标准，而不是描述测试本身。
测试阶段
组件测试
测试单个的程序组件；
通常由程序开发者完成（除了要求特别高的系统）；
这个阶段的测试大多依靠测试者的经验。
系统测试
测试由组件整合成的子系统和系统；
有专门的测试团队进行测试；
测试要依据需求规格说明进行。
5.8集成测试
集成测试包括把组件集成为系统和对合成的系统进行
测试，以发现组件集成过程带来的问题，集成方式可以分
为：
自顶向下集成
从主控模块开始，沿着控制层次结构逐步向下，利用深度优先或广度优先的方式将从属于主控模块的其他模块集成到系统结构中。
自底向上集成
从原子模块开始，从底层把模块逐步向上集成为更大规模的子系统和系统。
Ml
增量集成测试
为了简化测试中错误定位的问题，可以采用增量集成的方法。
5.9测试用例设计
测试用例
升级会员 