当前位置：首页 > wzjs >正文

免费可以做旅游海报的网站今天新闻头条最新消息

wzjs 2025/8/20 22:23:08

免费可以做旅游海报的网站,今天新闻头条最新消息,青岛网站建设网站设计,最新网站建设方案UML用例建模面向业务实现或者系统功能，每一个用例实现一个完整的业务或者功能。而一个完整的用例也可能有一些不是必需的附加功能，或者在该用例已经实现后需要添加一些新功能，此时可以通过UML提供的扩展用例机制描述类似这样的场景。例如对…

UML用例建模面向业务实现或者系统功能，每一个用例实现一个完整的业务或者功能。而一个完整的用例也可能有一些不是必需的附加功能，或者在该用例已经实现后需要添加一些新功能，此时可以通过UML提供的扩展用例机制描述类似这样的场景。

例如对于银行储蓄业务，最基本也是最核心的用例便是“取钱”与“存钱”，当业务办理完成后，通常储户还可以对当前服务进行评价，对服务进行评价不是必须的环节，它是这两个用例的可选活动，不进行评价并不影响用例“取钱”和“存钱”的目标实现。对服务进行评价这个活动可以单独建模为用例“评价服务”。用例“评价服务”不能单独存在，它必须依附于用例“取钱”与“存钱”，它们之间通过由用例“评价服务”指向用例“取钱”和“存钱”的虚线箭头连接，并且在虚线上标示“«extend»”，表明用例“评价服务”是一个扩展用例，它扩展于基本用例“取钱”和“存钱”，如图 1所示。

图 1 扩展用例描述方法

在图 1中，可以看到基本用例“取钱”和“存钱”中还展示了“扩展点（extension points）”，这是构建扩展用例的一个可选项，即对一个基本用例进行扩展时可以在基本用例中标明扩展点，所谓扩展点就是基本用例调用扩展用例的位置，可以看作是基本用例中某一点的一个分支。

从基本用例的视角出发，扩展用例是可选的，但在什么样的条件下会选择执行扩展用例呢？如果扩展用例的名称本身不足以表明执行条件，那么就需要在建模时通过为扩展关系指定约束的方式指明扩展用例的执行条件。例如对于上例，扩展用例“评价服务”执行的条件是“储户在服务完成后选择对服务进行评价”，该条件可以通过为扩展关系（即带«extend»标示的虚线箭头）添加注释的方式进行说明，如图 2所示。在通常情况下，扩展用例触发的条件可能是基本用例状态的改变。

图 2 为扩展关系添加约束条件

理想情况下扩展用例用于扩展与基本用例有关联的那些非关键的活动，但在实际建模活动中，扩展用例也经常用来描述一个活动流程中不同的分支。例如，在某个模型中有“付款”这个用例，完全基于面向对象思想建模应当使用泛化关系建立各用例之间的关系（详见《泛化用例》），如图 3所示。

图 3 使用泛化建模

在实际建模活动中，有可能最初的模型由于建模时间较早或其他什么原因，“付款”的场景只有使用“现金支付”一种途径，因而在建模时仅构建用例“付款”（或者“现金支付”），且该用例实现使用现金付款的流程。而后继在系统升级改造时，要求支持刷卡和扫码支付，此时多数建模者会选择通过扩展原有用例的方式来实现功能扩展与升级，如图 4所示。

图 4 扩展取代泛化建模

在上图中，用例“刷卡支付”和“扫码支付”依然建模为抽象用例（通过使用斜体的用例名称表示），并由其他具体用例实现，这当然是正确的建模方式。但是假如很不幸，最初的模型其实经历了两次升级，第一次升级的时点国内还没有普及信用卡，大家只有借记卡，同时扫码支付也只有支付宝提供支付，因而此次升级的任务是将仅支持现金付款升级为支持“刷借记卡支付”和“扫支付宝支付”，并且建模者没有预料到信用卡和其他支持扫码支付应用的出现，因而在此次升级中直接使用扩展用例进行升级；而第二次升级时，则要进一步支持“刷信用卡支付”和“扫微信支付”，基于第一次升级的选择，这一次继续使用扩展用例或许不算有错。升级完成的用例图如图 5所示。