用例模型及系统顺序图
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
多次迭代，用例分优先级，早期的需求会议集中于 最重要的用例
早期的需求会议集中于最重要的用例 后面的需求会议适应和精化核心需求，逐步稳定 发现需求和建造部分软件系统相辅相成
各阶段的对于POS system ，20 user goal level use cases中， 最复杂和具有风险的15个或更多用fully dressed format写出或重写
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
❖ Rose演示
绘图
UML用例图
❖ 用例工作主要是写文本文档，图是次要的 ❖ 初学者常先画图，世界级用例专家关注文本， ❖ 建议：在参与者目标列表同时画简单的用例
图，显示系统边界、系统和参与者的行为：
识别其他需求
识别其他需求
❖ UC对需求分析来说并不充分，还需要识别其他种类的需求
补充规约Supplementary Specification
❖ 用例、词汇表中不易捕获的需求、信息和约束
Functional， Usability， Reliability，Performance，Supportability
UML用例图-绘图的建议
❖ 防止过度图形化 ❖ 用例的重点在于书写文本，而不是图和用例
关系，不要花很多小时甚至几天讨论用例图 和用例关系
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例驱动的开发过程
❖ 需求主要记录在用例中 ❖ 用例是迭代规划重要组成部分，选择不同的
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例的提取
❖ 先发现用户的目标，再为每个目标定义用例
Goal: capture or process a sale; use case: Process Sale.
❖ 找出主要参与者、目标和用例
Handle Returns。以此深入一步调查项目的复杂度 等 使用集成字处理软件的需求分析工具，分析和编 写时投影显示 为用例编写Stakeholders and Interests lists 其他几天进一步调查，项目赞助者确定是否值得 进入细化阶段作大的调查
各阶段的需求分析
❖ Elaboration
用例是需求，主要是指示系统将要做什么的功能需求，而不是所有 需求。不是传统的特性列表。
是文本文档，不是图。 UML中的用例图只是列出用例和参与者的名 字及其关系
描述系统必须做什么（功能需求），而非如何做（设计） 指定系统外部行为 如系统将销售记录下来
而不是：系统将销售写入数据库 更不是：系统为销售生成INSERT SQL语句
早期确定目标和推测项目的范围，投影参与者-目 标-用例表 ,开始用例语境图
几小时后，大约20个用户目标被识别出。包括 Process Sale, Handle Returns, 大部分利益、复杂 度、风险用例以brief format写出（每条几分钟）
各阶段的需求分析
接着：用fully dressed format重写10%~20%用例 （核心复杂功能或高风险的），如Process Sale,
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例书写格式
❖ 三种Formality Types
brief casual fully dressed
用例类型和格式brief
❖ brief format use case:——简洁的一段摘要， 主要是成功场景
Handle Returns Main Success Scenario:顾客带着要退货的货物到达收款处，收
银员使用POS系统记录每一个要退货的货物,... Alternate Scenarios: 若信用验证失败，通知客户并要求使用其他付款方法 若系统检测到与外界计税系统通信失败，...
用例类型和格式fully dressed
❖ 最细化，包括所有步骤和变化。可有前置条 件、后置条件（成功保证）
❖ 可获得对目标、任务和需求的深入理解 ❖ 在早期需求讨论会上与system analyst, subject
matter experts, and developers协同创建 ❖ 有各种模板 ❖ Process Sale 实例分析
用例场景部分定义了迭代工作 ❖ 设计阶段主要设计对象协作和子系统来实现
用例 ❖ 用例影响用户手册的组织
❖ 10%的需求详细化后就开始建造系统的核心
❖ 需求分析交错进行，细化阶段第一次迭代结 束时，第二次需求会议，完成30%详细用例， 并接受反馈
各阶段的需求分析
❖ Inception: ❖ 两天需求分析会议和简单的用例分析
此外，细化结束时已有具有一定质量的可执行代 码
各阶段的需求分析
❖ Construction
20个迭代，每个2周，以完成系统。 细化阶段风险和核心不稳定问题都解决了以后开
始 用例和需求仍可作微量变化
例子： 初始阶段用例模型
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例的概念
❖ 增值 ❖ 用例和功能需求
❖ Process Sale: 顾客带着要购买的商品到达收 款处，收银员使用POS系统记录顾客购买的 每一个商品。系统提供总价和详细条目。顾 客输入支付信息供系统验证并记录。系统更 新库存，顾客得到收银条并带着货物离开。
用例类型和格式casual format
❖ casual format use case：非正式、随意的格式——非正式段落， 覆盖各种场景
早期的需求会议集中于最重要的用例 后面的需求会议适应和精化核心需求，逐步稳定 发现需求和建造部分软件系统相辅相成
各阶段的对于POS system ，20 user goal level use cases中， 最复杂和具有风险的15个或更多用fully dressed format写出或重写
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
❖ Rose演示
绘图
UML用例图
❖ 用例工作主要是写文本文档，图是次要的 ❖ 初学者常先画图，世界级用例专家关注文本， ❖ 建议：在参与者目标列表同时画简单的用例
图，显示系统边界、系统和参与者的行为：
识别其他需求
识别其他需求
❖ UC对需求分析来说并不充分，还需要识别其他种类的需求
补充规约Supplementary Specification
❖ 用例、词汇表中不易捕获的需求、信息和约束
Functional， Usability， Reliability，Performance，Supportability
UML用例图-绘图的建议
❖ 防止过度图形化 ❖ 用例的重点在于书写文本，而不是图和用例
关系，不要花很多小时甚至几天讨论用例图 和用例关系
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例驱动的开发过程
❖ 需求主要记录在用例中 ❖ 用例是迭代规划重要组成部分，选择不同的
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例的提取
❖ 先发现用户的目标，再为每个目标定义用例
Goal: capture or process a sale; use case: Process Sale.
❖ 找出主要参与者、目标和用例
Handle Returns。以此深入一步调查项目的复杂度 等 使用集成字处理软件的需求分析工具，分析和编 写时投影显示 为用例编写Stakeholders and Interests lists 其他几天进一步调查，项目赞助者确定是否值得 进入细化阶段作大的调查
各阶段的需求分析
❖ Elaboration
用例是需求，主要是指示系统将要做什么的功能需求，而不是所有 需求。不是传统的特性列表。
是文本文档，不是图。 UML中的用例图只是列出用例和参与者的名 字及其关系
描述系统必须做什么（功能需求），而非如何做（设计） 指定系统外部行为 如系统将销售记录下来
而不是：系统将销售写入数据库 更不是：系统为销售生成INSERT SQL语句
早期确定目标和推测项目的范围，投影参与者-目 标-用例表 ,开始用例语境图
几小时后，大约20个用户目标被识别出。包括 Process Sale, Handle Returns, 大部分利益、复杂 度、风险用例以brief format写出（每条几分钟）
各阶段的需求分析
接着：用fully dressed format重写10%~20%用例 （核心复杂功能或高风险的），如Process Sale,
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例书写格式
❖ 三种Formality Types
brief casual fully dressed
用例类型和格式brief
❖ brief format use case:——简洁的一段摘要， 主要是成功场景
Handle Returns Main Success Scenario:顾客带着要退货的货物到达收款处，收
银员使用POS系统记录每一个要退货的货物,... Alternate Scenarios: 若信用验证失败，通知客户并要求使用其他付款方法 若系统检测到与外界计税系统通信失败，...
用例类型和格式fully dressed
❖ 最细化，包括所有步骤和变化。可有前置条 件、后置条件（成功保证）
❖ 可获得对目标、任务和需求的深入理解 ❖ 在早期需求讨论会上与system analyst, subject
matter experts, and developers协同创建 ❖ 有各种模板 ❖ Process Sale 实例分析
用例场景部分定义了迭代工作 ❖ 设计阶段主要设计对象协作和子系统来实现
用例 ❖ 用例影响用户手册的组织
❖ 10%的需求详细化后就开始建造系统的核心
❖ 需求分析交错进行，细化阶段第一次迭代结 束时，第二次需求会议，完成30%详细用例， 并接受反馈
各阶段的需求分析
❖ Inception: ❖ 两天需求分析会议和简单的用例分析
此外，细化结束时已有具有一定质量的可执行代 码
各阶段的需求分析
❖ Construction
20个迭代，每个2周，以完成系统。 细化阶段风险和核心不稳定问题都解决了以后开
始 用例和需求仍可作微量变化
例子： 初始阶段用例模型
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取： 目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例的概念
❖ 增值 ❖ 用例和功能需求
❖ Process Sale: 顾客带着要购买的商品到达收 款处，收银员使用POS系统记录顾客购买的 每一个商品。系统提供总价和详细条目。顾 客输入支付信息供系统验证并记录。系统更 新库存，顾客得到收银条并带着货物离开。
用例类型和格式casual format
❖ casual format use case：非正式、随意的格式——非正式段落， 覆盖各种场景