《本科自考02333软件工程课后习题答案版王立福》完整版.docx
《《本科自考02333软件工程课后习题答案版王立福》完整版.docx》由会员分享，可在线阅读，更多相关《《本科自考02333软件工程课后习题答案版王立福》完整版.docx（21页珍藏版）》请在冰点文库上搜索。
《本科自考02333软件工程课后习题答案版王立福》完整版
《本科自考02333软件工程课后习题答案-2011版_王立福》完整版
《本科自考02333软件工程课后习题答案,2011版王立福》
第1章
1、解释术语
（1）软件:
软件是指计算机系统中的程序及其文档。
P16
（2）软件工程:
软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。
P15（3）软件危机:
软件生产率、软件质量远远满足不了社会发展的需求，成为社会，经济发展的制约因素，人们通常把这一现象称为“软件危机”。
P15
2、简答题
（1）简述软件开发的本质。
答:
软件开发的本质就是实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。
P19
（2）简述实施软件开发的基本途径。
答:
实施软件开发的基本途径是系统建模。
所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结构——系统模型。
P19
（3）简述何谓模型以及软件开发中所涉及的模型。
答:
模型是一个抽象。
该抽象是在意图所确定的角度和抽象层次对物理系统的一个描述，描述其中的成分和成分之间所具有的特定语义的关系，还包括对该系统边界的描述。
软件开发中所涉及的模型可分为两大类，一类称为概念模型，描述了系统是什么;另一类统称为软件模型，描述了实现概念模型的软件解决方案。
P19
（4）（简述软件开发所涉及的两大类技术。
答:
软件开发所涉及的两大类技术为:
一是求解软件的开发逻辑，二是求解软件的开发手段。
P17
第2章
1、解释术语
（1）软件需求
软件需求以一种技术形式，描述了一个产品/系统应该具有的功能、性能和其它性质。
P23
（2）功能需求
功能需求规约了系统或系统构件必须执行的功能。
P24
（3）非公能需求
非公能需求是性能、外部接口、设计约束和质量属性这4类需求的统称。
P23
（4）需求规约
需求规约是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型。
P28
2、简述需求与需求规约的基本性质。
答:
需求的基本性质:
1）必要的，该需求是用户所要求的。
2）无歧义的，该需求只能用一种方式解释。
3）可测的，该需求是可进行测试的。
4）可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。
5）可测量的，该需求是可测量的。
P23
需求规约的基本性质:
1）重要性和稳定性程度:
按需求的重要性和稳定性，对需求进行分级。
2）可修改的:
在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。
3）完整的:
没有被遗漏的需求。
4）一致的:
不存在互斥的需求。
P28
3、简述软件需求的分类。
答:
软件需求可以分为两大类:
一类是功能需求，一类是非公能需求，而非公能需求可分为性能需求，外部接口需求、设计约束和质量属性需求。
P234、举例说明功能需求和非功能需求之间的基本关系。
答:
非功能需求可作用于一个或多个功能需求，例如
功能需求1功能需求2功能需求3„„
作用于
非功能需求1非功能需求2
其中，非功能需求1作用于功能需求1和功能需求3等;非功能需求2作用于功能需求2等。
P24
5、有哪几种常用的初始需求发现技术,
答:
有5种常用的需求发现技术:
自悟、交谈、观察、小组会和提炼。
P26
6、简述需求规约的3种基本形式。
（1）非形式化的需求规约。
非形式化的需求规约即以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。
（2）半形式化的需求规约。
半形式化的需求规约即以半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约。
（3）形式化的需求规约。
形式化的需求规约即以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持。
P29
7、简述软件需求规约的内容和作用。
答:
软件需求规约的内容有:
引言、总体描述、特定需求、附录、索引。
P28
需求规约的作用可概括为以下4点:
1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
2）对于项目的其余大多数工作，需求规约是一个管理控制点。
3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。
4）需求规约是创建产品验收测试计划和用户指南的基础。
P31
8、简述需求规约在项目开发中的基本作用。
答:
需求规约的作用可概括为以下4点:
1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
2）对于项目的其余大多数工作，需求规约是一个管理控制点。
3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。
4）需求规约是创建产品验收测试计划和用户指南的基础。
P31
9、简述需求规约和项目需求的不同。
答:
需求规约和项目需求是两个不同的概念。
需求规约是软件开发组织和用户之间一份事实上的技术合同书，即关注产品需求，回答“交付给客户的产品/系统是什么”;而项目需求是客户和开发者之间有关技术合同——产品/系统需求的理解，应记录在工作陈述中或其他某一项目文档中，即关注项目工作与管理，回答“开发组要做的是什么”。
P30
第三章结构化方法
1.基本概念
需求分析:
一般来说，分析是系统地使用信息，对一个问题的估算。
软件需求分析是这一概念的特化，即系统化地使用“数据流”、“加工”、“数据存储”、“数据源”和“数据潭”等术语所表达的信息，对待建系统“是什么”给出一个估算――系统概念模型软件设计:
在需求分析的基础上，定义满足需求所需要的结构，即针对给定的问题，给出该问题的软件解决方案，确定“怎么做”的问题
数据流图:
表达功能模型的工具，即数据流图（DataflowDiagram）简称DFD图，简单的说，DFD图是一种描述数据变换的图形化工具，其中饮食的元素可以是数据流、数据存储、加工、数据源和数据潭等
变换型数据流图:
具有较明显的输入部分和变换（主加工）部分之间的界面变换部分和
输出部分之间界面的数据流图
事务型数据流图:
数据到达一个加工T，该加工T根据输入数据的值，在其后的基干动作序号（称为一个事务）中选出一个来执行
模块:
执行一个特殊任务的一个过程以及相关的数据结构
1.简答题
2.何谓模块耦合,简述模块耦合的类型。
答:
耦合是不同模块之间相互依赖程序的度量
内容耦合:
当一个模块直接修改或操作另一个模块的数据，或一个模块不通过正常入口而转入到另一个模块时，
公共耦合:
两个或两个以上的模块共同引用一个全局数据项
控制耦合一个模块通过气喘吁吁向另一个模块传递一个控制信息，接收信号的模块根据信号值进行适当的动作
标记耦合:
若一个模块A通过接口向两个模块B和C传递一个公共参数数据耦合:
模块之间通过参数来传递数据
3.何谓模块内聚,简述模块内聚的类型。
答:
指一个模块内部各成分之间相互关联程度的度量
偶然内聚:
一个模块的各成分之间基本不存在任何关系
逻辑内聚:
几个逻辑上相关的功能被放在同一个模块中
时间内聚:
一个模块完成的功能必须在同一时间内执行，但这些功能只是因为时间因素关联在一起
过程内聚:
一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行
通信内聚:
一个模块的所有成分都操作同一数据集或生成同一数据集顺序内聚:
一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入
功能内聚:
最理想的内聚，模块的所有成分对于完成单一的功能都是基本的。
功能内聚的模块对完成其功能而言是充分必要的
4.何谓模块的控制域和模块的作用域,并举例说明
控制域:
模块本身以及所有直接或间接从属于它的模块的集合。
作用域:
受该模块内的一个判定所影响的所有模块的影响
第四章面各对象方法,UML
1.基本概念
类及其属性和操作
类是一组具有相同属性、操作、关系和语义的对象的描述。
类的属性是类的一个命名特征，该特征是由该类的所有对象所共享、用于表达对象状态的数据
接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务关联及其链:
关联是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述。
链是对象之间具有特定语义关系的抽象
泛化:
活佛是一般性类目（称为超类或父类）和它的较为特殊性类目（称为子类）之间的一种关系，有时称为”isakindof”关系
聚合:
聚合是关联的一种特殊形式，表达的是一种“整体/部分”关系依赖:
依赖是一种使用关系，用于描述一个类目使用另一个类目的信息和服务2.简答题
为了表达客观事物，UML给出了哪些基本术语,
答:
为了支持抽象分析和设计中的事物，UML给出了8个基本术语，即类、接口、协作、用况、主动类、构件、制品、结点，并给出了这些基本术语的一些变体。
为了表达客观事物之间的关系，UML给出了哪些基本术语,这些术语之间是什么关系,关联、泛化、细化和依赖，以及它们的一些变体
什么是对象的构成与表示,并说明。
类是一组具有相同属性、操作、关系和语义的对象的描述。
对象是类的一个实例
什么是类图的构成成分,
答:
类图是可视化地表达系统表态结构模型的工具，通常饮食类、接口、关联、泛化和依赖
什么是顺序图的构成成分,
顺序图是一种交互图，即由一组对象以及按时序组织的对象之间的关系组成，其中还饮食这些对象之间所发送的消息
如何描述对象之间的关联语义
用况之间有哪几种关系,
在什么情况下需要建立状态图,
状态图可用于创建有关系统（或系统成分）的行为生存周期模型，表达有关系纺（或系
统成分）的一种动态结构，给出有关系统（或系统成分）在生存期间有哪些阶段、每一阶段可从事的活动以及对外所呈现的特征等方面的信息
对象操作和对象状态之间的关系是什么,
同时引入“操作”和“方法”的目的是什么,
答:
表达模型化包之间的关系
为什么使用包,如何划分包
使用UML可以从那些角度来刻画一个系统的行为,为什么,
何谓顺序图中的控制操作子,试举例说明。
为了控制交互行为描述的复杂性，以便更清晰地表达顺序图中的复杂控制，给出了个个控制操作子，选择、条件、并发、迭代操作控制子
第五章面各对象方法,RUP
1.基本概念
RUP的定义及主要特点
RUP是一种软件开发过程框架，基于面向对象符号体系给出了有关软件开发过程组织及实施的指导。
该框架体现了3个突出特征，即以用况驱动、体系结构为中心以及迭代、增量式开发
演化模型与“RUP增量、迭代开发”之间关系
RUP迭代、增量式开发是演化模型的一个变体，即规定了“大的”迭代数量,4个阶段，并规定了每次迭代的目标
初使阶段:
获得与特定腹部和平台无关的系统体系结构轮廓，以此建立产品功能范围;编制实例业务实例，从业务角度指出该项目的价值，减少项目主要的错误风险精华阶段:
通过捕获并描述系统的大部分需求，建立系统体系结构基线的第一个版本，主要包括用况模型和分析模型，减少次要的错误风险，到该阶段未，就能够估算成本、进步，并能详细地规划构造阶段
构造阶段:
通过演化，形成最终的系统体系结构基线，开发完整的系统，确保产品可以开始向客户交付，即具有初始操作能力
移交阶段:
确保有一个实在的产品发布给用户群。
期间培训用户如何使用该软件
RUP与UML之间关系
RUP与UML是一对“姐妹”，它们构成了一种特定的软件开发方法学。
其中，UML作为一种可视化建模语言，给出了表达事物和事物之间关系的基本术语，给出了多种模型的表达工具;而RUP利用这些术语定义了需求获取层、系统分析层、设计层、实现层，并给出了实现各层模型之间映射的基本活动以及相关指导
什么是特征（Teature）?
举例如何描述它。
从客户、用户、计划者、开发者想法和意愿中搜取特征，形成特征表。
特征是一个新的项及其简要描述
“按不同科目计算平均成绩”计算平均成绩:
按所学的不同科目计算每一个学生的期末考试平均成绩，给出分数段
并描述其状态（如提议、批准、合并和验证等）、实施的代价及风险、重要程度以及对其他特征的影响等
特征可作为需求，并被转换为其它制品
需求获取层及相关概念
需求获取层目标:
使用UML中的用况、参与者以及依赖等术语来抽象客观实际问题，形成系统的需求获取模型;基本术语:
用况、参与者、用于表达用况参与者之间关系的关联、用于表达况之间的包含和扩展、用于表达参与者之间关系泛化。
术语确定了系统用况模型的各种形态
需求获取模型的基本组成
使用UML中的用况、参与者以及依赖等术语来抽象客观实际问题，形成系统的需求获取模型
建造一个系统需求获取模型的活动和任务，以及各活动的输入和输出1.发现描述参与者和用况，输入:
业务模型或领域模型，补充需求，特征表;输出:
用况
模型[概述]，术语表
2.赋予用况优先级:
输入:
用况模型[概述]，补充需求，术语表;输出:
体系结构描述[用
况模型视角]
3.精华用况:
输入:
用况模型[概述]，补充需求，术语表;输出:
用况[精化]4.构造人机接口原型:
输入:
用况[精华]，用况模型[概述]，补充需求，术语表;输出:
人机接口原理
5.用况模型结构化:
输入:
用况[精华]，用况模型[概述]，补充需求，术语表;输出:
用
况模型[精化]
如何描述系统的参与者和用况,举例说明
参与者:
发现参与者与描述参与者:
1）之前已经存在业务用况模型，可依据业务模型直
接发现一些候选参与者，2）没有业务用况模型，即使存在领域模型，也需要系统分析人员与客户一起来标识系统参与者
用况是系统向它的参与者提供结果（值）的功能块，表达参与者使用系统的方式，因此一个用况可用于规约系统可执行的、与参与者进行交互的一个动作序列，包括其中一些可选动作序列，并且用况还有自己的属性
需求获取层对以后开发工作的影响,
需求分析层及相关概念
在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述，系统分析模型是系统的一种概念模型，解决系统用况模型中存在的二义性和不一致性问题，并以一种系统化的形式准确地表达用户的需求
需求分析模型的基本组成
RUP的分析如同结构化分析，其目标之一是在一个特定的抽象层上建立系统分析模型。
为此，RUP首先给出了3个术语:
分析包、分析类和用况细化，用于表达需求中“大粒度”的概念，开发人员使用这些术语可以规约系统分析中所要使用的信息分析类:
是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的，包括:
边界类、实体类、控制类
用况细化:
是一个针对一个用况，其行为可用多个分析类之间的相互作用来细化，并记为用况细化[分析]
分析包:
分析包是一种控制信息组织复杂性的机制，提供了分析制品的一种组织手段，形成了一些可管理的部分。
建造一个系统需求分析模型的活动和任务，以及各活动的输入和输出体系结构分析:
输入:
用况模型、补充需求、业务模型或领域模型、体系结构描述[用况模型];输出:
分析包[概述]、分析类[概述]、体系结构描述[分析]
细化用况:
输入:
用况模型、补充需求、业务模型或领域模型、体系结构描述[分析];输出:
用况细化[分析]、分析类[概述]
对类分析:
输入:
用况细化[分析]、分析类[概述]输出:
分析类[完成]对包进行分析:
输入:
系统体系结构描述[分析]、分析包[概述]输出:
分析类[完成]
需求分析模型对以后开发工作的影响
1）对设计中子系统的影响。
分析包一般将影响设计子系统的结构
2）对设计类的影响。
分析包可以作为类设计时的规格说明。
3）对用况细化[设计]的影响。
用况细分[分析]对用况细化[设计]有两方面影响，一个是
它们有乃至于为用况创建更精确的规格说明，另一个是当对用况进行设计时，用况细
化[分析]可作为其输入。
需求获取模型与需求分析模型之间比较
1）语言描述不同:
客户语言与开发语言
2）视图:
系统外与系统内
3）结构:
使用用况予以结构化，给出外部视角系统结构与使用衍型类结构化，给了部视
角系统结构
4）作用:
标注“系统应该做什么，不应该做什么”与可以做出开发者理解系统如何勾画、
如何设计和如何实现基础
5）问题:
可能存在冗余、不一致和冲突等问题与解决了上述问题
6）捕获系统功能，包括体系结构方面具有意义的功能与给出细化系统功能，包括在体系
结构方面具有意义的功能
7）定义一些进一步需要在分析模型中予以分析用况与定义每一个用况细化
设计层及相关概念
设计目标:
定义满足系统/产品分析模型所规约需求的软件结构
基本术语:
设计子系统、设计类、用况细化[设计]、接口、以及用于表达子系统之间关系的依赖、用于表达设计类之间关系的关联等，这些术语确定了系统设计模型的各种形态
设计模型的基本组成
设计子系统、设计类、用况细化[设计]、接口、以及用于表达子系统之间关系的依赖、用于表达设计类之间关系的关联等，这些术语确定了系统设计模型的各种形态
建造一个系统设计模型的活动和任务，以及各活动的输入与输出
体系结构设计:
输入:
用况模型、补充需求、分析模型、体系结构描述[分析模型角度];输出:
子系统[概述]、接口[概述]、设计类[概述]、部署模型[概述]、体系结构描述[设计]设计用况:
输入:
用况模型、补充需求、分析模型、部署模型;
输出:
用况[设计-实现]、设计类[概述]、子系统[概述]、接口[概述]对类设计:
输入:
用况[设计-实现]、设计类[概述]、接口[概述]、分析类[完成];输出:
设计类[完成]
设计子系统:
体系结构描述[设计]、子系统[概述]、接口[概述];输出:
子系统[完成]、
接口[完成]
如何处理需求中所捕获的非功能需求。
需求分析模型与设计模型之间的比较
第六章软件生存周期过程与管理
1.基本概念
软件测试:
有规程地发现错误的过程，其中错误（ERROR）:
与所期望的设计之间的偏差，该偏差可能产生不期望的系统行为或失效。
失效（FAILURE）:
与所规约的系统执行之间的偏差。
失效是系统故障或错误的后果。
故障（FAULT）:
导致错误或失效的不正常条件。
故障可以是偶然性的或是系统性的。
测试用例:
为了发现程序中的故障而专门设计的一组数据或脚本
测试覆盖率:
定量描述一个或一组测试的效率
2.简答题
测试过程模型，并分析这一模型在软件测试技术研究以及实践中的作用答:
软件测试是一个有程序的过程，包括测试设计、测试执行、以及测试结果比较等1.环境模型、被测模型和错误模型在软件测试中扮演了一种很重要的角色;这些模型的质
量，特别是程序模型的质量，对发现错误具有关键性的作用
2.软件测试的错误假定是，实际结果与预期结果不符，而后在此基础上可进一步分析是
什么错误
软件测试与调度的区别
答:
1）.测试从一侧面证明程序员的“失败”。
调度为了证明程序员是正确的2）.测试以已知条件开始，使用预告定义的程序且有预知的结果，不可预见的仅是程序是否通过测试
3）.测试是有计划的，并要进行测试设计。
高度是不受时间约束的
4）.测试是发现错误、改正错误、重新测试的过程。
调试是一个推理过程5）.的执行是有规程的。
调试的执行往往要求程序员进行必要推理
6）.测试经常由独立的测试组在不了解软件技术的条件下完成的。
高度必须由了解详细设计的程序员完成
7）大多数测试的执行和设计可由工具支持。
调试时，程序员能利用的工具主要是调试器
程序流程图的作用及构成
答:
着重于过程属性描述
简述语名覆盖、分支覆盖、条件组合覆盖、路径覆盖的含义及它们之间的关系答:
路径覆盖:
执行所有可能穿过程序控制流程的路径
语句覆盖:
至少执行程序中所有语句一次
分支覆盖:
至少将程序中的每一个分支执行一次
条件覆盖:
指每个判定中的所有可能的条件取值至少执行一次
条件组合覆盖:
设计足够测试，使每个判定中的所有可能的条件聚会组合至少执行一次
存在以下关系:
语句覆盖《分支覆盖《条件组合覆盖《。
。
。
路径覆盖
简术单元测试、集成测试、有效性测试的含义及它们之间的区别
答:
单元测试:
主检验软件设计的最小单元――模块。
该测试以详细设计文档为指导，测试模块内的重要控制路径。
集成测试:
是软件组装的一个系统化技术，其目标是发现与接口有关的错误有效性测试:
发现软件实现的功能与需求规格说明书不一致的错误
简述路径测试技术、事务流测技术的主要依据
答:
一个依据程序逻辑结构，一个依据软件行为描述
简述程序流程图与事务流程图之间的主要区别，并分析这些区别的主要原因答:
1）基本模型元素所表达的语义不同
2）一个事务不等同于路径测试中一条路径，可能在中间某处就完成了某一用户工作，终结了一个事务
3）.事务流程图中的分支和节点可能是一个复杂的过程
简述白盒测试技术的要点，并举例说明
答:
白盒测试技术依据程序的逻辑结构，以控制流程图作为被测对象建模工具，其中涉及过程块、分支、节点、链以及路径，并针对测试民，给出了4种覆盖策略:
语名覆盖、分支覆盖、条件组合覆盖和路径覆盖，它们之间具有偏序关系，并且可根据项目需求给出其他覆盖策略
事务流测试技术的要点，并举例说明
答:
事务流测试技术是一种功能测试技术，目前提出了很多功能测试技术，如定义域测试技术、等价类测试技术以及基于因果图的测试技术等，统称为黑盒子测试技术。
黑盒测试将被测软件看成黑盒子，只通过外部的输入和输出来发现软件中的错误，因此黑盒测试是一种基于软件规约的测试
第七章软件生存周期过程与管理
1.基本概念
软件生存周期过程:
软件生存周期是软件产品或系统的一系列相关活动的全周期。
从形成概念开妈，历经开发、交付使用、在使用中不断修订和演化，直到最后被淘汰，让位于新的软件产品
软件生存周期模型:
是一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止
过程管理:
过程规则与管理是软件项目管理的一项重要工作。
没有过程规划就淡不上过程管理乃至项目管理，没有过程管理就不可能存在有效的软件工程
2.简述软件开发中的过程类，以及它们的基本作用和它们之间的基本关系答:
分为3类
基本过程:
那些软件生产直接相关的活动集，分5个过程:
获取过程、供应过程、开发过程、运行过程和维护过程
支持过程:
有关各方面按他们的目标所从事的一系列相关支持活动集，有助于提高系统或软件产品的质量，分为:
文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程和问题解决过程等
组织过程:
与软件生产组织有关的活动集，分管理过程、基础设施过程、培训过程、改进过程
3.在ISO/IEC12207-2008中如何描述一个过程,举例说明
答:
1）.为获取方获取一个软件产品或服务，为供应方开发、运行、维护、提供和销毁一个软件产品，建立了一种软件生存周期框架，包含过程、活动和任务，并通过过程分类、过程描述，给出它们之间的内在关系
2）.为软件生存周期过程的定义、控制和改进提供了一个过程，即生存周期模型管理过程
供应过程:
为获取方提供满足所协商需求的产品或服务
软件实现过程:
软件实现过程是为了生产一个已规约系统元素，作为一个软件产品或服务而实现
软件需求分析过程:
建立系统软件部分的需求
软件体系结构设计:
为软件的实现及其可以按需求进行验
升级会员 