3 用例建模
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例建模
1
主要内容
●用例
●用例图
●用例建模过程
●实例讨论
●用例建模风格
主要知识点
●需求技术
●用例
●用例图
●参与者
●脚本（场景）
●用例之间的关系
●用例的描述
银行业务示例
需求技术
●大约有25%项目的失败归因于需求方面的问题
●两种类型的需求
功能性需求：系统应该提供什么行为
非功能性需求：系统上的特定属性或约束
●三种需求技术
XP中的用户故事
FDD中的特性描述
RUP中的用例
XP中的用户故事
●用户故事（user story）
由用户参与编写，说明需要系统为他们做什么 简短的文字描述
●例子
FDD中的特性描述
●FDD：Feature Driven Development
特性驱动的软件开发方法
●特性（feature）描述
RUP中的用例
●RUP的基本特征
用例驱动，以软件体系结构为中心，受控的迭代式增量开发
●用例（use case）
描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员之间就系统的行为所达成的契约 在UML中，用椭圆表示，用例名用动宾结构或者主谓结构命名
用例驱动的软件开发过程●用例模型
发现功能需求，结果表现为用例图
●分析模型
通过协作图描述用例，分析结果表示为类图、包图●设计模型
这一阶段的结果有类图、对象图、包图和构件图●部署模型
结果有构件图、部署图
●测试模型
根据用例中所描述的功能构建测试模型
用例（use case）
●用例（用况，用案）
●定义
1.用例是对一个活动者(actor)使用系统的一项功能
时所进行的交互过程的一个文字描述序列
2.用例是系统、子系统或类和外部参与者交互的动
作序列的说明, 包括可选的动作序列和会出现异常的动作序列
字处理程序●用例举例
“置正文为黑体”
“创建索引”
银行业务系统
●银行业务系统
查看帐户余额
列出交易内容
划拨资金
支付帐款
买进证券
卖出证券
基于用例进行需求分析的特点
●用例从使用系统的角度描述系统中的信息●用例描述用户提出的一些可见需求, 对应一个具体的用户目标
●用例是对系统行为的描述, 属于UML的动态建模部分
UML2.2中的图
使用用例的注意点
●用例描述用户提出的一些可见的需求，用例可大可小，用例对应一个具体的用户目标
●理论上可将系统的所有用例画出来，但实际运用时，只需画出重要的、交互过程复杂的用例
●不要试图将所有的需求都以用例的形式表达
Alistair Cockburn给出的需求大纲
●系统的目的和范围
●系统中的术语表
●用例
●系统采用的技术
●开发过程中的参加人员、业务规则、系统运行所依赖的条件、安全要求、文档要求等
●法律、政治、组织机构等方面的问题
关于用例的争论
●用例分析是面向对象分析与设计的一部分？
●不管怎么样，用例是UML的一部分，确定系统的用例是面向对象开发过程的第一步
用例的实现
●用例是与实现无关（implementation-independent）的关于系统功能的描述
●在UML中，可以用协作（collaboration）来说明对用例的实现
协作的表示
在UML中，协作用虚线椭圆表示
参与者（actor）
●参与者(actor)
是指系统以外的、需要使用系统或与系统交互的事物, 包括: 人、设备、外部系统等
●其它译名有
活动者、角色、执行者、行动者等
银行业务系统中的可能参与者●客户
从系统获取信息并执行金融交易
●管理人员
开办系统的用户。获取并更新信息
●厂商
接受作为转帐支付结果的资金
●mail系统
参与者的相关说明
●参与者是虚拟的概念，可以指人，也可以指外部系统、设备等
●一个参与者可以执行多个用例
●一个用例也可以由多个参与者所使用
●尽管在用例建模时使用参与者，但参与者实际上并不是系统的一部分
参与者的表示
UML中的参与者实际上是一个版型化的类, 可以有三种表示形式
Icon形式Label形式Decoration形式
参与者的泛化关系
参与者之间可以存在泛化（generalization）关系，表示一个一般性的参与者与另一个
更为特殊的参与者之间的联系
actor
actor
generalization
参与者的获取
●可以从以下几点考虑寻找系统的参与者：
谁使用系统的主要功能
谁需要系统支持完成日常工作
谁来维护、管理系统正常工作
对系统产生的结果感兴趣的人或事务
系统需要操纵哪些硬件
需要与系统交互的其他系统有哪些