当前位置：文档之家 › 软件工程 (8)

软件工程 (8)

  • 格式：pptx
  • 大小：1.92 MB
  • 文档页数：273

下载文档原格式

  / 17

合集下载

软件工程 第八章 面向对象的设计方法

软件工程 第八章 面向对象的设计方法

第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。

如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

为完成这一转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。

实现方案用UML交互图表示。

（2）设计技术支撑设施。

在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。

这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。

例如，数据的持久存储服务、安全控制服务和远程访问服务等。

在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。

（3）设计用户界面。

（4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。

此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。

面向对象的软件设计过程如图8-1-1所示。

图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、协作图）适于用例实现方案的表示。

因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。

该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。

一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。

在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。

顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。

软件工程自考题模拟8

软件工程自考题模拟8

软件工程自考题模拟8(总分：100.00，做题时间：90分钟)一、单项选择题(总题数：20，分数：40.00)1.下列关于需求规约的作用说法错误的是______（分数：2.00）A.需求规约是软件开发者和客户之间一份相关的技术合同书√B.对于项目的其余大多数工作，需求规约是一个管理控制点C.对于产品/系统的设计，需求规约是一个正式的，受控的起始点D.需求规约是创建产品验收测试计划和用户指南的基础解析：[考点] 本题主要考查的知识点为需求规约的作用。

需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现，并不是客户与开发者之间的相关技术合同。

2.下列描述中，不属于程序流程图优点的是______（分数：2.00）A.历史最悠久，使用最广泛B.容易表示数据结构√C.支持程序的三种基本控制结构D.直观清晰，易于使用解析：[考点] 本题主要考查的知识点为程序流程图。

程序流程图是一种历史最悠久，使用最广泛的设计工具，对控制流程的描绘直观，便于初学者掌握。

在程序流程图中，使用顺序、选择和循环三种基本控制结构。

但是它不是一种逐步求精的工具，也不易表示数据结构。

3.数据字典是软件需求分析阶段所采用的最重要工具之一，其最基本的功能是______（分数：2.00）A.数据定义√B.数据通讯C.数据库设计D.数据维护解析：4.以下说法错误的是______（分数：2.00）A.组合是聚合的一种特殊形式B.在一个组合中，一个链所连接的对象构成的任何元组，必须都属于同一个整体类的对象C.在一个组合中，组合末端的多重性可以超过1 √D.如果整体类的实例和部分类的实例具有相同的生命周期，那么这样的聚合称为组合解析：5.不属于在单元测试期间需要考虑的模块特征的是______（分数：2.00）A.模块接口B.局部数据结构C.重要的执行路径D.测试用例√解析：6.调试的目的是为了______（分数：2.00）A.证明软件符合设计要求√B.发现软件中的错误和缺陷C.改善软件的功能和性能D.发掘软件的潜在能力解析：[考点] 本题主要考查的知识点为调试。

软件工程课件之第8章维护第6版张海潘编著

软件工程课件之第8章维护第6版张海潘编著
(1) 必须描述如何使用这个系统，没有这种描述时即 使是最简单的系统也无法使用； (2) 必须描述怎样安装和管理这个系统； (3) 必须描述系统需求和设计； (4) 必须描述系统的实现和测试，以便使系统成为可 维护的。
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例

软件工程心得体会8篇

软件工程心得体会8篇

软件工程心得体会8篇（经典版）编制人：__________________审核人：__________________审批人：__________________编制单位：__________________编制时间：____年____月____日序言下载提示：该文档是本店铺精心编制而成的，希望大家下载后，能够帮助大家解决实际问题。

文档下载后可定制修改，请根据实际需要进行调整和使用，谢谢!并且，本店铺为大家提供各种类型的经典范文，如工作总结、工作计划、调研报告、演讲致辞、合同协议、条据文书、规章制度、教学资料、作文大全、其他范文等等，想了解不同范文格式和写法，敬请关注!Download tips: This document is carefully compiled by this editor. I hope that after you download it, it can help you solve practical problems. The document can be customized and modified after downloading, please adjust and use it according to actual needs, thank you!Moreover, our store provides various types of classic sample essays, such as work summaries, work plans, research reports, speeches, contract agreements, documents, rules and regulations, teaching materials, complete essays, and other sample essays. If you would like to learn about different sample formats and writing methods, please pay attention!软件工程心得体会8篇心得体会让我明白了自我反思的重要性，只有不断反思才能不断进步，生活是一本永不停歇的教科书，在其中我们可以通过不断的尝试和反思，积累丰富的心得体会，本店铺今天就为您带来了软件工程心得体会8篇，相信一定会对你有所帮助。

软件工程课件(全)

软件工程课件(全)

03
识别项目中的关键路径，确保项目按计划进 行
04
及时调整项目计划，应对项目变更和不确定 性
风险管理策略制定
识别项目中的潜在风险， 包括技术风险、市场风险、 资源风险等
制定相应的风险应对策略 和措施，如风险规避、减 轻、转移和接受等
评估风险的概率和影响程 度，制定风险优先级列表
监控风险状态，及时调整 风险管理计划
质量改进
根据质量评估结果，制定相应的改进措施， 如优化性能、增强安全性等。
经验教训总结
对测试过程中遇到的问题进行总结，形成经 验教训，为后续项目提供参考。
06
项目管理与团队协作
项目计划制定与监控
01 制定详细的项目计划，包括项目目标、范围 、时间表、资源需求、成本估算等
02 设立项目里程碑，对项目进度进行阶段性监 控
开发方向。
持续集成和测试
03
迭代增量模型强调持续集成和测试的重要性，以确保每个迭代
周期都能交付高质量的软件产品。
03
需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领 域专家等进行沟通，收集原始
需求。
需求分类
将收集到的需求按照功能、性 能、安全、易用性等方面进行 分类。
需求筛选
去除重复、模糊、不切实际的 需求，确保需求的准确性和可 行性。
处理变更请求
根据实际情况，决定是否接受变更请求，并 制定相应的实施计划。
跟踪和验证变更
对实施的变更进行跟踪和验证，确保变更的 正确性和完整性。
04
系统设计与实现
系统架构设计
分层架构
将系统划分为表示层、业务逻辑层和数据访问层，实现高内聚、 低耦合的设计。

软件工程 第8章 软件维护

软件工程 第8章 软件维护

8.4.2 软件可维护性的度量
3. 可测试性 4. 可修改性 5. 可移植性 6. 效率 7. 可使用性 8. 间接度量可维护性的方法
8.4.2 软件可维护性的度量
8. 间接度量可维护性的方法
(1) 了解问题的时间； (2) 行政管理拖延的时间； (3) 收集维护工具的时间； (4) 分析问题的时间； (5) 改变规格说明的时间； (6) 具体的改错或修改的时间； (7) 局部测试时间； (8) 整体测试时间； (9) 维护重审时间； (10) 总体恢复时间。

8.4 软件的可维护性
8.4.1 影响可维护性的因素 软件的可维护性可以简单定义为：纠正软件系统出现 的错误和缺陷,以满足新的要求, 能够被理解、被校正、 被修改或被改善的难易程度。可维护性不但与采用的 分析设计方法和开发人员的技术熟练程度有关，更重 要的是与软件项目的管理技术关系密切。软件的可维 护性成为软件开发阶段各个时期的关键目标。
8.1 软件维护的种类
完善性维护 50％
预防性维护5％
改正性维护 20％
适应性维护 25％
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明，有代表性的软件开发组织用于校正性 维护、适应性维护、完善性维护及预防性维护的费用 占其开发总金额的70％至80％。 很多软件机构被束缚在维护工作上，这是软件维护所 带来的无形支出。

8.2.3 非结构化维护

无说明或者文档资料太少由于没有采用定义良好的软 件项目管理过程来开发软件，软件项目管理的缺陷导 致的叫“非结构化维护”,这会使软件维护付出较高的 代价.
8.2.4 结构化维护

存在完整的软件系列文档，那么维护任务就从分析设 计文件开始，确定软件的重要结构特性、功能特性和 接口特性，确定所要求的修改或校正可能产生的影响， 并且计划采用何种维护处理方法，修改设计并进行复 审，编制出新的源程序，利用文档中的信息进行回归 测试，然后重新交付软件。这种维护过程就叫做“结 构化维护”

软件工程第8章详细设计

stop
WHILE Q
F
G N
例2:以下是两个程序流程图，试用PAD图表示。
开始 在工资档案中读一条记录
是文件结束位置吗?Y
N 计 算 工 资 档 案 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 发 放 表 中 查 找 职 工 号 与 num 相 同 的 记 录
五种基本控制结构：
示例
程序流程图的规定符号
1）顺序型结构 顺序结构由带箭头的控制线依次连接几个处理方框构成。
处理1 处理2 处理n
…
例题
2） 选择型结构 选择型结构是流程图中最为常用的结构，其结构构造有两种，一种是条件选择结构又称为IF-
THEN-ELSE结构，使用菱形表现逻辑判定条件，条件结果决定选择两个处理方框中的一个。
种条件组合相对应的动作。
所有条件
条件组合矩阵
所有可能的 动作列表
与每种条件组合 所对应的动作表
国内乘客 头等舱 残疾乘客 行李≤30kg
免费 (W-30)*2 (W-30)*3 (W-30)*4 (W-30)*6 (W-30)*8 (W-30)*12
TTTTFFFF
TFTFTFTF
FFTTFFTT
TF F F F F F F F
找到了吗?
N
显示错误
Y 计 算 各 项 奖 金 总 和 并 存 入 bonus
应 发 工 资 ＝ pay＋ bonus
读下一条记录
结束
在工资档案中读一条记录
是文件结束位置吗?
计 算 工 资 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 表 中 查 职 工 号 与 num 相 同 的 记 录

软件工程名词解释

1．软件测试(第8 章) 2．静态测试(第8 章) 3．动态测试(第8 章) 4．黑盒测试(第8 章) 5．白盒测试(第8 章) 6．语句覆盖(第6 章) 7．判定覆盖(第6 章) 8．条件覆盖(第6 章) 9．判定/条件覆盖(第6 章) 10．条件组合覆盖(第6 章) 11．路径覆盖(第6 章) 12．测试用例(第8 章) 13．驱动模块(第6 章) 14．桩模块(第6 章) 15．单元测试(第8 章) 16．集成测试(第8 章) 17．确认测试(第8 章) 18．渐增式测试(第8 章) 19．非渐增式测试(第8 章) 20．调试(第9 章) 21．人的因素的含义(第11 章) 22．基线(第12 章) 23．软件配置管理(第12 章24．软件配置项(第12 章) 25. 软件概要设计(第5 章) 26. 模块(第5 章) 27. 模块化(第5 章) 28. 抽象(第5 章) 29. 信息隐蔽(第5 章) 30. 模块独立性(第5 章) 31. 耦合性(第5 章) 32. 无直接耦合(第5 章) 33. 数据耦合(第5 章) 34. 标记耦合(第5 章) 35. 控制耦合(第5 章) 36. 公共耦合(第5 章) 37. 内容耦合(第5 章) 38. 内聚性(第5 章) 39. 偶然内聚(第5 章) 40. 逻辑内聚(第5 章) 41. 时间内聚(第5 章) 42. 通信内聚(第5 章) 43. 顺序内聚(第5 章) 44. 功能内聚(第5 章) 45. 软件结构图(第5 章) 46. 结构化设计(第5 章) 47. 变换流(第6 章) 48. 事务流(第6 章) 49. JSP (第6 章) 50. JSD (第6 章)答案：1. 软件测试指为了发现软件中的错误而执行软件的过程。

它的目标是尽可能多地发现软件中存在的错误，将测试结果作为纠错的依据。

2. 静态测试指被测试的程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。

《软件工程》判断题汇总及答案

判断题：1.软件就是程序，编写软件的关键是编写程序。

2.可行性研究阶段要进行一次大大压缩简化了的系统分析和设计的过程。

3.需求管理主要是对需求变化的管理，及如何有效控制和适应需求的变化。

4.数据流图表示了软件系统对数据的算法处理过程，即系统的物理模型。

5.需求分析的主要方法有SD法、OOA法及HIPO法等。

6.没有Do-case、Do-until形结构，就不能实现某些结构化程序，从而降低了程序的运行效率。

7.用面向对象方法分析、设计、实现软件，仍属线性的瀑布开发模型。

8.文档是影响软件可维护性的决定因素。

9.软件是指用程序设计语言（如PASCAL ,C,VISUAL BASIC 等）编写的程序，软件开发实际上就是编写程序代码。

10. 软件模块之间的耦合性越弱越好。

11. 软件开发小组的组成人员的素质应该好，而人数则不宜过多。

12. 总体设计的基本目的就是回答："概括地说，系统应该如何实现？"这个问题。

13. 文档只起备忘录的作用，可以在软件开发完成后再整理生成。

14. 结构化软件开发的方法的工作模型是螺旋模型。

15. 总体设计的基本目的就是回答："概括地说，系统应该如何实现？"这个问题。

16. 瀑布模型的最大优点是将软件开发的各个阶段划分得十分清晰。

1．N 2.Y 3. Y 4.N 5.N 6.Y 7.N 8.Y9.N 10.Y 11.Y 12. Y 13. N 14.N 15.Y 16.Y判断题：1.在面向对象的软件开发方法中，每个类都存在其相应的对象，类是对象的实例，对象是生成类的模板。

2.过程描述语言可以用于描述软件的系统结构。

3.继承性是父类和子类之间共享数据结构和消息的机制，这是类之间的一种关系。

4.快速原型模型可以有效地适应用户需求的动态变化。

5.在面向对象的需求分析方法中，建立动态模型是最主要的任务。

6.集成测试主要由用户来完成。

7.确认测试计划应该在可行性研究阶段制定8.白盒测试无需考虑模块内部的执行过程和程序结构，只要了解模块的功能即可。

软件工程概论_8_面向对象需求分析


• 一.面向对象分析模型的组成结构 • 二.面向对象分析模型描述工具 • 三.面向对象分析的基本过程
• 四. 面向对象分析方法
• 五. 小结
一.面向对象分析模型的组成结构
数据模型
属性、操作、协作者
功能模型
类/对象 模型
对象关系模型
使用实例
对象-行为模型
行为模型
二.面向对象分析模型描述工具
1. 用例图
2．面向对象建模 （1）建模与模型 建模是将问题域的解空间定义成一种模型，以帮助系统分析 人员更好地理解问题。 模型是为了理解问题而对问题所做出的一种抽象，而且是对 问题的一种无歧义的描述。模型由一组图示符号和组织这些 符号的规则组成。利用它们来定义和描述问题域中的术语和 概念。 建模的目的主要是为了减少复杂性。 （2）面向对象模型
2) 面向对象分析的五个层次 面向对象分析由五个主要活动组成，即确定类-＆-对象、识别 结构、识别主题、定义属性和定义服务(方法)。对于一个复杂 问题的面向对象的模型可用五个层次表示：类-＆-对象层、结 构层，主题层、属性层和服务层，见图3.3.8。
主题层 subject level 类-＆-对象层object 结构层 structure 属性层 attribute 服务层 serves
•使用具有确切含义的名词。
• 尽量使用能表示类的含义的日常用语作名字，不要使用空洞的或含 义模糊的词作名字。例如，“库房”比“房屋”或“存物场所”更确切。
•必要时用名词短语作名字。
• 为使名字的含义更准确，必要时用形容词加名词或其他形式的名词 短语作名字。例如，“最小的领土单元”、“储藏室”、“公司员工”等 都是比较恰当的名字。
签定保险单 销售统计
客户
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第8章 用例驱动
第8章 用例驱动
8.1 用例驱动开发概述 8.2 为什么使用用例 8.3 确定客户需要什么 8.4 需求工作流 8.5 领域模型 8.6 业务模型 8.7 补充需求 8.8 初始需求 8.9 初始需求：考勤系统实例研究 8.10 继续需求流：考勤系统实例研究 8.11 修订需求：考勤系统实例研究 8.12 测试工作流：考勤系统实例研究 8.13 需求规格说明书 8.14 小结 习题８
第8章 用例驱动
知识点 需求工作流，领域模型，业务模型，建模技术。
难点 如何将理论与实践结合。
基于工作过程的教学任务 通过本章学习，了解为什么使用用例，学习用例驱动开
发的基本概念；确定客户需要什么，掌握需求工作流的基本 过程；理解领域模型、业务模型对需求的作用，掌握相关的 建模技术；以考勤系统为例，全面展示需求工作流的工作过 程；了解考勤系统的测试工作流。
第8章 用例驱动
8.1 用例驱动开发概述
在需求工作流中，开发者必须确定什么样的软件是客户 想要的。因此，需求捕获有两个目标：发现真正的需求，并 以适合于用户、客户和开发人员的方式加以描述。“真正的 需求”是指在实现时可以给用户带来预期价值的需求，但是， 很多客户不知道他们需要什么．
第8章 用例驱动
第8章 用例驱动
需求 分析 设计 实现 测试
用例模型 分析模型 设计模型 实施模型 实现模型 测试模型
图8-1 统一过程从需求到测试的一系列工作流
第8章 用例驱动
用例常用于捕获软件系统(尤其是基于构件的系统)的需 求。用例不只是捕获需求的工具，还能够驱动整个开发过程。 在寻找和确定类、子系统和接口时，在寻找并确定测试用例 时，在规划开发迭代和系统集成时，用例都将作为主要输入。 对每次迭代，用例驱动完成一整套工作流(从需求捕获，经 过分析、设计和实现，最后到测试)，并将这些不同的工作 流集成在一起。
第8章 用例驱动
开发人员设计类和用例实现，以便更充分地应用相关的 产品和技术(如对象请求代理、图形用户界面、构造工具和 数据库管理系统等)来实现系统。根据子系统对设计类进行 分组，并定义子系统间的接口。开发人员还要进一步建立实 施模型，其中包括定义在计算节点上的系统的物理结构，以 验证用例能够实现并能在节点上运行。
第8章 用例驱动
设计模型具有下面的特点： 设计模型是有层次的，也包括跨层次的关系，这些关 系在UML中很常见：关联、泛化和依赖等； 用例实现是协作的构造型，协作表示类元在做某件事 情(如实现用例)时如何参与和扮演角色； 设计模型是实现的蓝图，设计模型的子系统和实现模 型的构件之间存在直接的映射关系。
“以适合于用户、客户和开发人员的方式”主要是指对需求 的最后描述必须能够让用户和客户理解，但是，即便客户真 正了解他们需要什么，也有可能很难精确地把其想法传达给 开发者，因为大多数客户的计算机知识不如开发团队的成员。 这也是需求工作流的难点之一。
第8章 用例驱动
系统通常有多种用户，每种用户都是一个参与者，参与 者使用系统与用例进行交互，用例是系统向参与者提供某些 有价值结果而执行的动作序列，即某种功能，参与者和用例 构成用例模型。
在分析和设计期间，用例模型经分析模型转化为设计模 型。简单地说，分析模型和设计模型都是由类元(Classifier) 和说明如何实现用例的集合组成的。类元是一种描述行为和 结构特征的模型元素，它具有属性和操作，可以用状态图描 述，有的还可以实例化、参与协作等。类元的种类包括类、 行为、构件、数据类型、接口、节点、信号、子系统以及用 例。其中，类是最常见的类元。
பைடு நூலகம்
第8章 用例驱动
统一过程(UP)的核心思想是用例驱动、以构架为中心的 迭代和增量开发。图8-1描述了统一过程中的一系列工作流 和模型。从机器解释的角度看，实现模型是最形式化的，而 用例模型的形式化成分最少。也就是说，部分实现模型可以 通过编译和连接成为可执行代码，而用例模型主要用自然语 言来描述。
第8章 用例驱动
开发人员以用例模型为输入来创建分析模型。用例模型 中的每个用例都实现为分析模型中的用例实现，用例和用例 实现的依赖性支持需求和分析之间的无缝可跟踪性。通过对 用例进行处理，开发人员可以确定参与实现用例的类，例如， “取款”用例可以通过分析“取款”类、“账户”类、“分 配”类及其他无需在此标识的类来实现。开发人员将用例中 定义的职责分配为类的职责，因此“账户”类包括诸如“从 账户上提取一定数额的现金”的职责。这样，就可以得到一 个类的集合，合在一起就能实现用户所需的用例。
第8章 用例驱动
8.2 为什么使用用例
在软件开发中，很常见的问题是许多客户不知道他们需 要什么，进一步来讲，即便客户真正了解他们需要什么，也 有可能很难精确地把这些想法传达给开发者，因为大多数客 户的计算机知识不如开发团队的成员。对开发人员来说，对 软件产品及其功能进行形象化描述已经很难了，对并不精通 软件工程的客户来说则更加困难。
第8章 用例驱动
分析模型也是一种模型，是需求的详细规格说明，可作 为设计模型的切入点。分析模型可能是暂时的，只存在于前 几次迭代中，然而，在某些情况下，尤其对于大型、复杂系 统，分析模型会存在于系统的整个生命周期。这种情况下， 分析模型的用例实现与设计模型中相应的用例实现之间存在 一种无缝的跟踪依赖关系，分析模型中每个元素都可以从实 现它的设计模型元素中跟踪到。
开发人员把设计好的类实现为实现模型中的构件(源代 码)集合，能够产生(即编译和连接)如DLL、JavaBeans和 ActiveX等可执行代码，用例有助于开发人员确定实现和集 成构件的次序。
第8章 用例驱动
在测试工作流期间，测试人员验证系统确实能够实现用 例描述的功能并满足系统需求。测试模型包含测试用例，测 试用例是测试数据集，定义了输入、运行条件和结果的集合。 许多测试用例直接从用例得到。因此，在测试用例和相应的 用例之间存在跟踪依赖关系，这意味着测试人员将验证系统 能够做用户需要的事，即能够执行用例。