[全程建模]extend关系的深入讨论分析

最新推荐文章于 2024-05-25 14:45:11 发布

piperzero

最新推荐文章于 2024-05-25 14:45:11 发布

阅读量77

点赞数

文章标签：面试

有人说， extend 关系如果和 if-else 类似，如果是这样的话，那么 if 后面的条件中就是多个内容，非常之多，而不能用简单的 if-else 就能表示清楚。

卡恩 NO.1 21:59:53

卡恩 NO.1 22:00:28

原来扩展用例是一种 if -else 关系，就是某个条件分枝，而不是我原来理解的可有可无的东西

青润 22:01:20

扩展用例不是 if else 关系。只是在这里正好符合。

卡恩 NO.1 22:02:03

额。。面试我的淘宝技术人说是 if-else ，比如另外附加了某个条件，就是作为他们的扩展用力

青润 22:02:09

extend 关系，表示的是后者对前者不是必须的，也就是前者发生，后者不一定必须发生。仅此而已，如果是 if else 那这个条件会非常多，不是简单的一个条件。

青润 22:02:21

呵呵，那个人的理解也有问题。

卡恩 NO.1 22:02:37

extend 关系，表示的是后者对前者不是必须的，也就是前者发生，后者不一定必须发生。我也是这么理解的

卡恩 NO.1 22:02:41

我给他举例子

青润 22:02:42

taobao 里面的人应该没有比我对 uml 的理解更深入的了。

青润 22:03:31

他的理解是有问题的，或者说，有些片面。

Destroyer 22:03:47

卡恩 NO.1 22:03:56

说：比如我和你在电话面试，这时候我手机就有通话功能，如果这时候别人一个电话打过来给我，我可以选择接或者不接，这个就似乎一个扩展用例，因为即使我不接也不影响通话这个用例

卡恩 NO.1 22:04:15

他说是 if-else

青润 22:05:13

是的，这个说法的确是 extend 的一种。

但是，还有别的可能，比如你无意间按错了键，也造成了接电话的事实。

或者，你正在接听的电话突然断掉，手机自动转接了新的来电。这都可能造成这个新用例的执行。

青润 22:05:36

而不是简单的你这个人主观是否接这个电话。他的条件是多样性的，不是一个条件必然结果。

卡恩 NO.1 22:07:03

大象里说他可以表示出一个复杂用例的各个“分支”

青润 22:07:23

这句话没有错误，但是表现不出这个关系的存在。

青润 22:09:32

卡恩 NO.1 22:00:28

原来扩展用例是一种 if -else 关系，就是某个条件分枝，而不是我原来理解的可有可无的东西

针对你的这后半句话， extend 关系不是可有可无的东西，不能如此理解。

青润 22:12:04

对于你给的那张图来说，有一个问题，这个客户就是不想建立自己的档案，即使第一次也不想建立，这种情况是存在的，也发生过。

所以，他那个说明标签表达的业务内容本身就存在一个不完善的地方。

在这里，应该是提醒用户建立个人档案，而用户是否会接受建立个人档案要要看用户的选择。

这样的业务过程才是完整的，才是为用户考虑过的。

卡恩 NO.1 22:14:20

想请教下青润，我觉得包含或者扩展用例的用例粒度很可能和基本用例不一致，比如以 ATM 为边界，有取钱和转账业务用例，而他们可以归纳出密码验证的包含用例来，但是包含用例属于系统用例了，和取钱和转账的粒度不同，也出现在业务模型中么？

青润 22:17:04

这个要看用户方的业务描述。

如果用户要求的取钱和转帐业务是在用户输入密码后，而不是先选择业务后输入密码，那就会出现不同。

如果是输入密码后，选择取钱还是转帐，那么这个输入密码就必须独立出来。

如果是先选择业务，后输入密码，那就不需要独立出来了。

因为在部分 atm 上面，如果是存钱，就可以不输入密码，甚至输入错误也可以存钱成功，具体的可以去看广发银行的 atm 就是如此实现的。

卡恩 NO.1 22:19:13

如果是输入密码后，选择取钱还是转帐，那么这个输入密码就必须独立出来。

这里的输入密码是取钱和转账业务用例实现场景中的一个步骤，独立出来的话其粒度和取钱转账是不同的

青润 22:21:13

我说的是用户的业务要求。

atm 的业务实现有所不同，各个银行要求也不一样。

有些 atm 是插卡后先输入密码，而有些是先选择业务。

广发银行的可存钱的 atm ，他的开始的密码输入就是一个过场，你即使输入错误，也可以进入，关键看你下一步的业务操作选择。

青润 22:22:16

我那句话是说，要求必须输入密码而且密码正确后才能进行后续业务选择的时候，这个密码验证就必须独立出来，密码验证用例和后面的所有业务用例之间的关系就是 extend ，而绝不是 include 。

破碎虚空 22:22:40

在 ATM 边界里面不可能有密码输入业务用例 . 没有人会为了 " 密码输入 " 而去 ATM

卡恩 NO.1 22:23:19

哈哈，虚空把大象搬出来了

青润 22:23:23

密码的人，有可能。

任何都有可能。

还有可能他刚输入密码，就接到一个紧急电话，然后就离开了。

青润 22:23:40

所以，这个独立出来，是完全有可能的，而不是不可能。

破碎虚空 22:24:05

密码的人的目标是为了盗钱 .

青润 22:24:59

不管是为了什么，你不能忽视这个密码验证本身是一个独立用例存在的。

例子刚才举过了

破碎虚空 22:25:58

是的 . 我这觉得这是个边界问题 .

青润 22:27:10

对于 atm 来说，无论你如何划分业务边界，都会有这个现象出现。

除非你设置先选择业务，然后输入密码。

否则，都会让密码验证独立成为一个单独的业务用例出现。

卡恩 NO.1 22:28:08

呼叫谭老师。。。。出来

破碎虚空 22:28:29

piperzero

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
[全程建模]extend关系的深入讨论分析

&lt;!-- [if !mso]&gt;&lt;style&gt;v/:* {behavior:url(#default#VML);}o/:* {behavior:url(#default#VML);}w/:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}&lt;/style&gt;...
复制链接

扫一扫