内容发布更新时间 : 2024/12/22 13:46:13星期一 下面是文章的全部内容请认真阅读。

参与者：发现参与者与描述参与者：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)大多数测试的执行和设计可由工具支持。调试时，程序员能利用的工具主要是调试器

程序流程图的作用及构成 答：着重于过程属性描述

简述语名覆盖、分支覆盖、条件组合覆盖、路径覆盖的含义及它们之间的关系 答：路径覆盖：执行所有可能穿过程序控制流程的路径 语句覆盖：至少执行程序中所有语句一次 分支覆盖：至少将程序中的每一个分支执行一次

条件覆盖：指每个判定中的所有可能的条件取值至少执行一次