用户模型UseCaseModeling.ppt

Hwadee Use Case Modeling Overview 课程介绍 为什么使用用例 识别主角和用例 用例模型 用例规格说明 问题和反馈 课程介绍 关于本次课程 课程目标 预备知识 目标听众 日程表 词汇表 课程目标 理解主角和用例； 掌握用例建模方法。 预备知识 了解UML； 了解面向对象基础知识。 目标听众 软件开发人员； 日程表 共计:0.5 天 详细安排 词汇表 Actor：主角 Use Case：用例 为什么使用用例 掌握方法才能不断复制成功 象他？ 软件开发的难点 开发过程解析 业务-目前的现实是什么？ 前景-希望系统达到什么目的？ 用例-谁“用”软件？用来做什么？做的细节？ 类图-软件内部需要哪些成分？ 顺序图-这些成分怎样合作来完成用例？ 设计-如何用选择的平台来实现分析？ 需求-石头问题 我要一块石头… 差不多，但我要小一点的… 很好，不过我要蓝色的… 啊，没有那么小… 咳，还是原来那块好了… 难捕获、易变 需求问题-对策 难捕获--?从用户视角看问题 易变--?合理的结构 识别主角和用例 用例-基于用户目标的需求组织形式 用例-有层次的组织形式 用例（取款） 路径（正常取款） 步骤（系统验证取款金额合法） 补充规约（取款金额必须是100的整数倍） 使用用例探索需求 以用例为核心来组织需求 识别Actor 识别Actor-要点 系统外-必须与系统交互； 系统边界-系统责任边界，不是物理边界； 系统边界-直接和系统交互； 有意义交互-属于目标系统的责任； 任何事物-人、外部系统、外部因素、时间。 系统外，必须和他交互 边界、接口 责任的边界，非物理边界 直接与系统交互 有意义的交互 任何事物 识别Actor-讨论与练习 识别Actor思路 谁使用系统的主要功能； 谁改变系统的数据； 谁从系统获取信息； 谁需要系统的支持完成日常工作任务； 谁负责维护、管理并保持系统正常运行； 系统需要和哪些外部系统交互； 谁（或什么）对系统的运行结果感兴趣； 有没有自动发生的事件。 识别Actor 慢慢清理-不丢用例 关键在边界，不在数量 责任类似或重叠 主Actor完成任务时可能需要辅助Actor 识别用例 用例的基本定义 RUP:用例实现是系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果，一个用例定义一组用例实例。 执行者通过系统达到某个目标。 用例要点 价值结果—〉有意义的目标； 系统执行—〉价值结果由系统生成； 执行者可见—〉业务语言，用户观点； 一组用例实例—〉用例的粒度。 有意义的目标 有没有意义，涉众说了算。 价值结果由系统生成 价值结果由系统生成 业务语言而非技术语言 用户观点而非系统观点 用例命名 动宾结构 慎用弱动词弱名词 弱动词： 进行，使用，复制，加载，重复； 弱名词： 数据，报表，表格，表单，系统； 用例的粒度 用例的粒度-最常犯错误 把步骤当成用例 把系统活动当成用例 用例的粒度-四轮马车 用例的粒度-四轮马车 用例的粒度-四轮马车 用例的粒度-四轮马车 用例粒度-用例实质 如果确实是CRUD 灵活处理CRUD 讨论与练习 检查用例 形式检查 [执行者]使用系统来[用例]。 内容检查 几种情况的讨论-怎么处理登录 几种情况的讨论-几个登录 几种情况的讨论-什么时候开始结束 注意 现在还在外面，不要急着乱塞东西！ 核心！=卖点，稍安勿躁！ 题外话-为什么总是急于加入细节 用例模型 用例模型-概念 是根据用例来说明系统需求的模型。 用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。 用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。 建模方法 模型工具 Rose Together 其他 模型语言 UML 创建Actors和Use Cases 查找actors和use cases 前面已经介绍 在Rational Rose的Use Case View中创建Actors和Use Cases 简单描述use cases 在Rational Rose中对每一个Use Case进行简单描述（通过Class Specification窗口的Documentation栏） 建立Actor之间的关系 Actor之间的泛化(Generalization)关系 如果actor A继承actor B,则actor A能够同actor B的所有用例通信，执行它的功能 允许多重继承（不建议，不容易理解） 这样能够识别是否多个actor必须共同与一个use case通信 描述Use Case之间的依赖关系 Extend 扩展 如果基本用例的一部分是可选的，或对于