任务二：面向对象的建模 3 需求分析阶段的用例建模 用例图 活动图

3.1 用例图

引入（1）： 银行储蓄帐户管理系统 《include》 银行职员 （用户代理） 帐户管理 银行间转帐 开户 取款 银行内转帐 注销 存款 校验密码 转帐 报表生成 其它银行 帐户管理系统 客户 系统管理员 （管理人员）

引入（2）： 用例描述： 用例名 校验密码用例 简要说明 本例用来描述校验用户密码的过程 用例图 基本事件流 1.系统验证银行卡账号 2.用户输入密码 3.系统验证用户输入的密码信息 4.通过校验，进入系统 备选事件流 1.如果账号错误，给出提示，退出 2.如果输入密码错误，给出提示，退出 客户 校验密码

3.1.1 用例图

用例图 用例图主要用于对系统、子系统或类的行为进行建模。 它只说明系统实现什么功能，而不必说明如何实现。用例图表示了从系统的外部用户（即参与者）的观点看系统应具有什么功能。 每个用例图都包含： 系统边界 一组用例(UseCase） 参与者(Actor) 参与者与用例之间的交互或者关系（关联、依赖、泛化）。

用例图的建立步骤： 找出系统外部的活动者和外部系统，确定系统的边界和范围。 确定每一个活动者所希望的系统行为，把这些系统行为命名为用例。 把一些公共的系统行为分解为一批新的用例，供其它的用例引用。把一些变更的行为分解为扩展用例。 编制每一个用例的剧本。 绘制用例图。 区分主业务流和例外情况的事件流。可以把表达例外的情况的事件流的用例图画成一个单独的子用例图。 精化用例图，解决用例间的重复与冲突问题，简化用例中的对话序列。用例图可以有不同的层次，高层次系统的用例可以分解为若干个下属子系统中的子用例。 1.确定参与者和系统边界 2.确定系统用例 3.用例间的关系 4.用例说明 5.用例图 6.用例图细化 7.用例图精化

3.1.2 识别参与者

（1）参与者 参与者是直接与系统相互作用的对象（人、物、其他系统）。 参与者在系统之外，参与者是与系统交互或者使用系统的某个人或者某个物，但它不是系统的一部分； 它提供系统的输入并从系统接收有关信息；它在系统的外部并且不能控制用例。

如何识别参与者？ 可以向用户提出如下一些问题： 谁将使用系统的主要功能？ 谁将需要系统的支持来完成他们的日常任务？ 谁必须维护、管理和确保系统正常工作？ 谁将给系统提供信息、使用信息和删除信息？ 系统需要处理哪些硬件设备？ 系统使用了外部资源吗？ 系统需要与其他什么系统交互吗？ 谁或者什么对系统产生的结果感兴趣？ 一个人同时使用几种不同的规则吗？ 几个人使用相同的规则吗？ 系统使用遗留下来的应用吗？

识别参与者 参与者：直接与系统交互 旅客 旅行社 机票预定系统

识别参与者 参与者：有意义的参与 旅行社 机票预定系统 不属于系统责任 不属于系统责任 不属于系统责任

识别参与者 参与者：与系统相关的任何事物

讨论1：电梯的参与者

电梯系统 潜在乘客 工作人员 乘客

回顾：新闻发布系统 某网站的新闻发布系统的主要功能： 这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。 任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。 管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。

方法：从名词中找到参与者 识别新闻发布系统的参与者 某网站的新闻发布系统的主要功能： 这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。 任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。 管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。 新闻发布系统 管理员 游客 会员 方法：从名词中找到参与者

3.1.3 识别用例

用例 用例是外部用户（参与者）使用系统的某种特定的方法。 用例是系统提供的功能块。 用例具备如下一些特征： 说明了系统具有的一种行为模式； 说明了一个参与者与系统执行的一个相关的事务序列； 提供了一种获取系统需求的方法； 提供了一种与最终的用户和领域专家进行沟通的方法； 提供了一种测试系统的方法；

YES NO

YES NO

如何识别用例 可以提出如下一些问题： 参与者要向系统请求什么功能？ 每个参与者的特定任务是什么？ 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ 是否任何一个参与者都要向系统通知有关突发性的、外部的改变？或者必须通知参与者关于系统中的发生的事件？这些事件代表了哪些功能？ （没有牵涉到参与者的问题）系统需要哪些输入/输出？ 这些输入输出来自哪里或者到哪里去？ 哪些用例支持或维护系统？ 是否所有功能需求都被用例使用了？ 系统当前实现的主要问题是什么？

讨论1：

方法：从事件中识别用例 讨论2：新闻发布系统的业务用例图 某网站需开发一个新闻发布系统，大致需要如下功能： 这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。 任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。 管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。 1. 方法：从事件中识别用例

回顾：新闻发布系统的业务用例图 新闻发布系统 说明： 业务用例是仅从系统业务角度关注的用例，它描述的是“该实现什么业务”，而不是“系统该提供什么操作”，如“登录”。 业务用例仅包含客户“感兴趣”的内容。 业务用例所有的用例名应该让客户能看懂，如果客户看不懂，它也许就不适合作为业务用例。 浏览新闻

3.1.4 参与者与用例之间的关系

参与者与用例之间的关系 参与者与所参与的一个用例之间的通信路径 说明 记号 关联关系 说明：箭头是可选的，在使用箭头的位置，表明了由谁启动了用例。 被呼叫者 呼叫者 拨打本地电话 拨打长途电话

参与者与用例之间的交互或者关系 说明 记号 包含 关系 被包含用例是基本用例的一部分，基本用例能看到被包含用例并依赖于它的的执行结果，但二者不能相互访问其它属性 泛化 一个一般用例与一个更特殊的用例之间的关系，特殊用例可继承一般用例的特征 扩展关系 扩展的用例到基本用例的一种关系：扩展用例可以访问基本用例的所有属性，并在基本用例基础上增加新的行为 《include》 《extend》

电话订购系统用例图 电话订购 核对身份 关联 扩展 售票员 设置订单 《extend》 请求 目录 《include》 《include》 包含 提供 客户数据 产生订单 订单支付 泛化 客户 现金支付 信用卡 支付 供应订单 送货员 建立信用 主管

银行储蓄帐户管理系统 《include》 银行职员 （用户代理） 帐户管理 银行间 转帐 开户 取款 银行内 转帐 注销 存款 校验密码 报表生成 其它银行 帐户管理系统 客户 系统管理员 （管理人员） 包含 泛化

参与者之间的泛化关系

3.2 活动图 activity diagram

活动图 活动图是一种用于描述系统行为的模型视图，它可用来描述过程（业务过程、工作流、事件流等）中的活动及其迁移。 活动图是一种描述交互的方式，描述采取何种动作，做什么(对象状态改变)，何时发生(动作序列) 以及在何处发生(泳道)。 着重描述动作及其结果。

活动图的主要应用 1．描述用例的行为 活动图可建模用例的工作流，显示用例内部和用例之间的路径；它也可以向读者说明需要满足什么条件用例才会有效，以及用例完成后系统保留的条件或者状态。 2．理解工作流程 活动图可以画出描述业务工作流的活动图与领域专家进行交流，明确业务处理操作是如何进行的，将会有怎样的变化。 3．描述复杂过程的算法 在这种情况下使用的活动图不过是UML版的程序流程图，常规的顺序、分支过程在活动图中都能得到充分的表现。

活动图的基本元素 起点 终点 活动 对象 转移 泳道：说明该活动由谁来完成 决策 分岔和联结 活动名 ：对象名 活动A 活动B 活动 ：对象

例：带有泳道和对象表并发的活动图

例：带有消息接收和发送标志的活动图

回顾： 新闻管理 活动图描述了这个业务用例中，用户可能会进行的操作序列。 很多“活动”都很可能是一个备选系统用例。 活动图有个很重要的使命：从业务用例分析出系统用例。 很多“活动”都很可能是一个系统用例（当然，不是每个都是）。 例如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。

讨论：教师更新分数用例的活动图

讨论：教师更新分数用例的活动图 1． 建立活动的主路径（主要事件流） 在开始创建用例的活动图时，往往先建立一条明显的路径执行工作流，然后从该路径进行扩展。 该路径仅考虑用例的正常活动路径（登录、选择学生、加载他们的分数，修改分数，保存修改结果等活动过程）， 没有考虑任何错误和判断的路径。

讨论：教师更新分数用例的活动图 2．活动的从路径（备选事件流） 考虑用例其他可能的工作流情况。如处理错误执行的活动。

3.3 系统用例图

一个系统用例是实际使用系统的用户所进行的一个操作： 将每个业务用例都绘制出相应的活动图，从“活动”中找出备选系统用例，对备选系统用例进行合并和筛选，得到系统用例图。 “浏览新闻”不是系统用例。

用例描述

软考试题分析

2009-11试题三 注册工资支付 生成付费请求 工资系统 查看今日特价 管理菜单 菜单管理员 泛化关系

2009-11试题三 登录

2008-11试题三 2008-11 A1 A2 A4 A3 U1 U2 close U3

作者登录（login）后提交稿件和浏览稿件审阅结果。提交稿件必须在规定提交时间范围内，其过程为先输入标题和摘要、选择稿件所属主题类型、选择稿件所在位置（存储位置）。上述几步若未完成，则重复；若完成，则上传稿件至数据库中，系统发送通知。 Action3 Action4 Action2 Action1

课后任务 针对课程项目《仓库管理系统》，明确系统需求，进行需求分析。 1.需求分析 2.画出业务用例图 3.绘制活动图（为每一个业务用例） 4.绘制系统用例图 5.描述用例规约 根据模版《需求规格说明书》，完成用例建模部分（提交业务用例图、活动图、系统用例图、用例描述等） 11月25日24:00前