UML-04-用例图-新.ppt

可视化建模与UML 教学安排 一、基础部分 专题一：UML概述 专题二：面向对象基础与UML的组成 二、UML模型图 专题三：类图、对象图、包图 专题四：用例图 ★讨论课 专题五：交互图（顺序图、协作图） 专题六：状态图 专题七：活动图 专题八：部署图与配置图 ★讨论课 三、提升部分 专题九：统一过程和迭代开发 专题十：正向工程与逆向工程 四、答辩 主要内容 什么是用例图（Use Case Diagram） 用例图的应用 用例图的组成 用例建模技术 什么是用例图(use case diagram) 在UML中，一个用例模型由若干个用例图(use case diagram)描述。用例图是显示一组用例、参与者以及它们之间关系的图。 用例图的应用 用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发过程而言，用例图是至关重要的。 用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。 让用户参与前期的系统分析与设计。 Use Case 对开发的意义 大学信息系统的一个用例图 用例图的组成 用例（Use Case） 参与者（Actor） 关系(Relationship) 什么是参与者 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。 参与者可能是人、另外一个系统、时间的流逝等。 什么是用例 用例（use case）是对一组动作序列的描述，系统执行这些动作序列来为参与者产生一个可观察的结果值。 它有如下一些特点： 用例描述了用户提出的一些可见的需求； 用例可大可小； 用例对应一个具体的用户目标 用例建模技术 识别参与者 识别用例 识别用例间的关系 用例阐述 识别参与者的方法 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 思考题：识别参与者 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； Example 例：图书管理系统的参与者： 借阅者（Borrower） 图书管理员（Librarian） 参与者的泛化 参与者之间也可以象类一样存在泛化或者依赖关系。 识别用例的方法 每个参与者的任务是什么 由参与者将要创建、存储、改变、删除或读取系统中的信息吗 什么用例会创建、存储、改变、删除、或读取这个信息 参与者需要通知系统外部的变化吗 需要通知参与者系统中正在发生的事情吗 什么用例将支持和维护系统 所有的功能需求都能被用例执行吗 识别用例的注意事项 注意事项： 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 要点：用例止于系统边界 用例的命名 执行者视角： （状语）动词+（定语+ ）宾语 要点：用例的粒度(1) 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度(2) 把步骤当用例 把系统活动当用例 要点：用例的粒度(2) “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 要点：用例的粒度(3) 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 Example 例：图书馆管理系统的用例： 借书（Borrow book） 还书（Return Book） 预定书刊（Reserve Title） 取消预定（cancel Reservation） 维护借阅者信息（Maintain Borrower Info） 维护书目信息（Maintain Title Info） 维护物理书刊信息（Maintain Book Info） 登录（Log In） 识别用例间的关系 包含（Include） 即在一个用例中重用另一个用例中的步骤。 扩展关系（extend） 扩展用例是在原用例的基础上增加新的步骤序列形成的。 原用例被称为基用例（base use case）。扩展只能发生在基用例的序列中的某个具体制定点上，这个点叫做扩展点（extension points）。 扩展关系 V