UML需求建模-用例描述.ppt

优点：销售登录后，可以访问所有允许访问的系统功能 缺点：假如你想向系统增加一些新的用例，你必须改变这一用例，从维护的角度看，容易忘记对登录进行更改；另外，如果采用这种方式，登录必须了解系统所有其他模块的知识。 优点：登录的用例只描述了登录，别无其他内容。 缺点：客户每次做不同的动作之前都必须登录，时间长了这会是一个很烦人的问题。 优点：客户登录一次后，就获得了对系统其他部分的访问。当你需要添加一个新的用例时，在登录添加一个扩展点就够了，你不需要对它作任何改变。 缺点：需要评审文档的人员描述清楚，别人很难清楚他们的关系，尤其是那些非开发人员 如果要使用该用例，则只要在其他用例中包含一个前置条件，在用户登录有效后才能执行，如书上例子 优点：登录的用例只描述了登录，别无其他内容。图标文本清晰、简单易懂，系统灵活性得到提高。现在订购货物不需要登录去执行，只需要是有效用户即可。执行登录是获得有效用户的一种方法，但是也有其他验证方法 描述指导原则：以系统或参与者能够监测到的某事物作为条件 5.系统显示总值并计算税金 5a.系统检测到与外部的税金计算系统的通信故障 方式1 5b. 外部的税金计算系统工作不正常 方式2 ？ 推测 扩展处理也可以包含一系列步骤： 3-6a.顾客要求收银员从已输入的商品中去掉一个商品 1.收银员输入商品标识并将其删除 2.系统显示更新后的累加值 扩展 3－6b.顾客要求取消销售交易 1.收银员在系统中取消销售交易 2.系统开始新的销售 3－6c.收银员延迟销售交易 1.系统记录销售交易信息，使其能够在任何登录中恢复操作 2.系统显示用来恢复销售交易的“延迟票据”，包括商品项目和销售交易ID 其它的一些扩展 顾客声称他们符合打折条件 顾客要求兑换账户积分 顾客要求其它的支付方式 顾客要求使用优惠券 顾客索要赠品票据 特殊要求 特殊要求：如果有一些与此用例有关的非功能需求（象质量属性或约束条件），那么将它们和用例记录在一起。 在大型平板显示器上的触摸屏界面。文本信息要能够在1米之外看清 90%的信用卡授权机构的响应应该在30秒收到 …… FURPS+模型 技术和数据的变化列表 技术和数据的变化列表：系统通常有一些技术上的变化是关于“应该怎么做”，而不是“应该做什么”，需要在用例中将这种变化记录下来。 “这个POS系统必须支持信用卡帐号的读卡器输入和键盘输入” 注意：这一部分不应包含用来表述不同情况下不同行为的多个步骤，如果有必要，将这些步骤记录在“扩展”部分 需求建模 * 用例规格说明力图简洁，限制在几页的篇幅内。用例规格说明的目的是紧凑地说明用例的事件流。如果篇幅太大，那么用例要做的事情就会过多，或者在编写用例时可能使你在不重要的可选流上花费过多的精力。 文本形式的用例规格说明具有许多优点： 简单易用，不需要CASE工具的支持。 不需要了解有关软件开发方法学的知识。 不需要培训。 便于携带。 可以在任何时间任何地点编写用例。 以顾客能够理解的自然语言描述用例。 需求建模 * 文本形式的用例规格说明所具有的上述优点使之成为与非技术人员(例如顾客、业务发起人)打交道时的一种理想描述形式。 用文本形式描述用例也有一个严重的缺陷。这样描述的用例与其他所有文本形式的规格说明一样：规格说明越来越复杂时，其中的各种条目之间的关系和信息交互将变得难以理解。 解决的办法：用UML顺序图描述用例 这也正是用UML顺序图描述用例的长处所在。 需求建模 * 用例之间的关系 包含（include） 用例不仅仅与参与者之间存在交互关系，一个用例还可以与其他用例存在关系。 假设你正在开发一个与开车旅行有关的用例。为了讨论的方便，假设“Take Trip(旅行)”是一个用例，它的流包括旅行规划、为汽车加油、驶往目的地、观光和驾车返回。这个用例可能包含多个可选的场景。 在你开发其他用例的过程中，你会发现有一个活动在每个场景中都会出现，那就是“Fuel Vehcile(为汽车加油)”。 需求建模 * 为汽车加油的动作在每个用例中是相同的。这种公共的行为可以用一种特殊的关联表示，如图所示，在一个带箭头的虚线上附加一个“include”标记。 旅行 为汽车加油 需求建模 * 包含(include)关联的含义是包含用例(include use case，如图中的Fuel Vehicle)嵌入在基用例(base use case，如图中的Take Trip)的流中。 包含用例是可重用的用例——多个用例的公共用例。 尽管包含用例是公共用例，但它同样是强制性的。 在这个例子中，如果没有它的包含用例Fuel Vehicle，则基用例Take Trip是不完整的。在基用例的场景中，当基用例的执行到达包含用例的包含点(inclusion