[计算机软件及应用]UML

本章学习要点： 用案图的组成 用案的类型 如何识别用案 对用例进行描述 理解用案之间的关系 绘制用例图 用案的控制流语义 3.1 用案图 1.什么是用户模型视图？ 也称为用案视图或者场景视图，它从用户的角度来描述系统功能，并指出各功能的操作者。 电话簿销售系统用案图 3.1.1系统 1.系统 是用案模型的一个组成部分,表示一台机器或一次商务活动 2.系统边界的作用 用于说明用案图的应用范围。 3.基本思路 先基本，后扩充。 3.1.2 参与者 是一个外部实体 和系统之间存在交互 充当某个特定的角色 参与者的识别 系统的主要客户是谁？ 谁从该系统获得信息？ 谁向系统提供信息？ 谁来安装该系统？ 谁来操作该系统？ 谁来关闭该系统？ 在预定的时刻，是否有事件自动发生？ 谁使用或删除系统中的信息？ 系统从何处获得信息？ 参与者的类型 1.按参与者的重要程度划分： 主要参与者 次要参与者 2.按参与者所承担的角色划分： 启动者 服务者 接受者 辅助者 3.按参与者与系统的使用关系划分： 业务参与者 系统参与者 识别主要参与者 主要参与者要从系统中获得什么服务？ 和这些服务有关的业务需求是什么？ 和这些服务有关的时间、性能需求或者其他接口需求是什么？ 识别次要参与者 该参与者给用案提供什么服务？ 和这些服务相关的时间、性能需求或者其他接口需求是什么？ 参与者承担的角色分类 启动者 服务者 接受者 辅助者(接口) 作为启动者应考虑的问题 这个参与者启动的是什么事件？ 这个事件是否和时间有关系？ 和这个参与者有关的接口需求是什么？ 作为服务者应考虑的问题 这个参与者提供什么服务？ 和这个参与者有关的接口需求是什么？ 如果承担服务者角色的参与者是另一个系统，那么这个系统的行为是否需要做适当修改以使得能够在这个用案中充当合适的角色？ 作为接收者应考虑的问题 这个参与者接受什么信息？ 和这个接受者有关的接口需求是什么？ 作为辅助者应考虑的问题 这个辅助者完成什么服务？ 为提供这种服务，是否需要给该参与者提供某种特殊的接口？ 在将来有无可能用诸如图形用户接口等方式代替这个参与者？ 选择系统参与者的参考标准 这个实体的作用主要是传递信息还是添加重要的值？ 这个参与者的定义是否为该用案提供了关键的上下文？ 这个参与者是否可以被自动化的接口替代？ 就当前的分析程度而言，所分析的重点是系统的业务需求还是特定的物理接口需求？ 参与者之间的关系 参与者之间存在泛化关系。 泛化关系的含义是把某些参与者的共同行为抽取出来表示成通用行为，且把它们描述成为抽象参与者。 参与者的描述 3.1.3用案 场景 是参与者和系统之间特定的交互序列； 用案 是外部可见的一种系统功能，是由许多成功和失败的场景的集合； 用案定义应包含的行为要素 执行用案功能的主线次序 标准行为的不同变形 一般行为下的所有异常情况及预期反应 用案的细节描述 用案的动态执行过程 由状态图、序列图、协作图或非正式的文字描述来描述。 用案的功能 由类之间的协作来实现。 用案的主要作用 可作为计划的基础 可用来捕获功能需求，是分析、设计和实现的基础 可作为软件测试的基础 由于用案描述了用户怎样使用系统，因而可以作为文档的基础 用案的类型 黑盒型用案 仅定义做什么，不定义怎么做。 简单型用案 简单语言描述用案，仅针对主要的成功场景。 非正式型用案 用若干非正式的段落描述用案，针对多个不同场景。 详细型用案 详细阐述用案，通常给出所有的步骤以及场景，并给出前置条件和后置条件等细节。 黑盒型和非黑盒型用案示例 简单型用案示例 处理销售： 一个顾客带着商品在收款处准备交费购买。出纳员使用POS终端记录所购买的每一件商品。POS系统给出所应收的总款数以及每件商品的价格细节。顾客键入支付信息，系统进行确认并记录。然后，系统更新商品的存货清单，顾客拿着系统打印出的收条并带着商品离开。 非正式型用案示例 处理退货 主要的成功场景：顾客带着商品到收款处退货。出纳员使用POS终端记录每一件被退回的商品…… 可选的场景：如果在系统中找不到商品的标识，那么就通知出纳员并建议他手工输入商品的标识码(或许商品的标识已经被损坏)；如果系统检测到和外部税金计算系统之间的通信失败，那么就…… 详细型用案示 用案UC1：处理销售 主要参与者：出纳员 受益人及其利益： 出纳员 需要精确、快速的输入，并且不出现支付错误。 顾客 需要购买并花费最小的精力得到快速的服务，并需要支持退货功能。 …… 前置条件：出纳员需要身份识别并进行授权。 后置条件：储存了销售情况，正确地计算了税金，更新了账目和存货