uml面向对象的分析和设计.pptVIP

* * * * * * * * * * * * * * * * 事实上，基础用例没有扩展也是完整的，一个扩展用例反而改变了基础用例的事件流。扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */180 3．用例的描述 用例通常用正文来描述,也可用活动图来描述 。应包含： 用例的目的 用例是如何启动的：哪个执行者在什么情况下启动用例的执行？ 执行者和用例之间的消息流：用例与执行者之间交换什么消息或事件来通知对方改变或恢复信息？描述系统与执行者之间的主消息流是什么？以及系统中哪些实体被使用或修改？ 用例中可供选择的流：用例中的活动可根据条件或异常（exception）有选择地执行。 如何通过给执行者一个值来结束用例 */180 执行者的简要描述 客户：向公司订购商品的人 客户代表：公司处理客户请求的雇员 用例的简要描述 订购货物：客户创建一个新的请求商品的订单，并付费 取消订单：客户取消一个已经存在的订单 用例的详细描述 前置条件和后置条件 前置条件和后置条件表示用例开始和结束的条件 事件流（flow of events） 它是从执行者的角度看，列出用例的各个步骤。 */180 用例名称：订购货物 参与的执行者：客户、客户代表 前置条件：一个合法的客户已经登录到这个系统 事件流： 当客户选择订购货物时，用例开始 客户输入他的姓名和地址 如果客户只输入邮编，系统将给出州和城市名 当客户输入产品代码 a.系统给出产品描述和价格 b.系统往客户订单中添加该物品的价格 循环结束 客户输入信用卡支付信息 客户选择提交 */180 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统转发支付信息。如果客户提交的信息不正确，系统将提示客户修改。 当支付确认后，订单就被标记上已经确认，同时返回给客户一个订单ID，用例也就结束了。如果支付没有被确认，系统将提示客户改正支付信息或者取消。若客户修改信息，就回到第5步；若取消，用例结束。 后置条件：如果订单没有被取消，它将保存在系统中，并做上标记 其他需求 在用例中还可描述一些非功能性需求，如可用性、安全性、可维护性、负载、性能、自动防故障、数据需求等。 特殊需求： 系统必须在一秒内响应客户的输入 */180 事件流可分为两部分： 基本路径 基本路径是运转正常时的路径，是一系列没有分支和选择的简单陈述句 可选路径 可选路径是指不同于基本路径而允许不同的事件序列的路径。 对于明显有可能随时发生的事情来说，可选路径非常有效。 */180 订购货物用例的基本路径： 事件流： 基本路径 当客户选择订购货物时，用例开始 客户输入他的姓名和地址 当客户输入产品代码时 a. 系统给出产品描述和价格 b. 系统往客户订单中添加该物品的价格 循环结束 客户输入信用卡支付信息 客户选择提交 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统转发支付信息 当支付确认后，订单就被标记上已经确认，同时返回给客户一个订单ID，用例结束 */180 如果在订购货物用例中，客户可以在提交订单前随时取消订单，其可选路径如下： 可选路径： 在选择提交前的任何时候，客户都可选择cancel。这次订购没有被保存，用例结束。 在基本路径第6步，如果有任何不正确的信息，系统提示客户去修改这些信息。 在基本路径第7步，若支付没有被确认，系统将提示客户改正支付信息或者取消。若客户选择修改信息，就回到基本路径第4步；若选择取消，用例结束。 */180 4．确定用例之间的关系 关系 说明 记号 关联 执行者与他所参与的一个用例之间的通信路径 扩展 扩展的用例到基本用例的一种关系，它指出扩展的用例所定义的行为如何插入到基本用例所定义的行为中。扩展的用例通过模块化方式增量地修改基本用例 包含 从基本用例到另一个用例（称为包含用例）的一种关系，它指出包含用例定义的行为被包含在基本用例所定义的行为中。基本用例能看到包含用例，并依赖于执行包含用例后的结果，但两者相互间不能访问其它属性 用例泛化 一个一般用例与一个更特殊的用例之间的关系，特殊用例可继承一般用例的特征 《extend》 《include》 */180 泛化：同一业务目的的不同技术实现 包含：提取公共交互，提高复用 扩展：“冻结”基用例以保持稳定 扩展、包含、泛化区别： 目的不同，包含反映聚合