这里是几个常见的uml设计错误，文中也是实例，因此隐去了相关信息，图中遮挡的部分是完全一样的两个字，你可以把它考虑成任何东西。
一个朋友
17:29:39
青润兄，周末的时候让你指教的地方有没有看
青润
17:30:21
还没有看，这几天比较累，等下应该会有时间了。
一个朋友
17:32:06
好的，拜托了。
青润
17:32:29
过会儿给你消息。
一个朋友
17:33:16
thanks
青润
17:56:44
这个拆分，貌似有点过度细化了，如果业务不是很复杂没有必要，有发布必然有人看，uc改成一个，右侧的use关系修改为查看，左侧的修改为发布，这个是权限控制的东西，没必要在这里细分uc的方式来区分。
青润
17:57:30
use关系一般可以不标出
一个朋友
17:57:46
恩，但可能是接口呢？
一个朋友
17:57:52
就是另外的系统。
青润
17:59:01
那就是具体业务问题，我只是在说一般情况下，你们的深入业务，我就不了解了，我只帮看看看是否规则。
关于uc的细化，你现在没有书，我也没法发给你了，等将来你看了书，按照上面的方式进行细化，就可以做的很好了，我书上给了量化的uc标准。
一个朋友
17:59:14
en
青润
18:00:15
另外，uc的箭头一般不是空心三角箭头，这个估计是vs的问题，如果真的想用好uml还是换个uml tool比较好。
一个朋友
18:00:50
在界面上导出excel，打印这些，我看网上有些人用extends,有些人用includes.而我看到的一本书一会用includes,一会用extends.这个怎么回事？
一个朋友
18:01:17
extends的方向，网上也说法不一。
青润
18:01:36
这个区分是没有必要的，如果前一个uc过大，就直接拆分用后面的uc即可，这种划分方式增加了uc数量，但实际上属于重复定义。
青润
18:02:20
extend我的解释就是最标准的，和uml concept上是完全一致的。
很多半瓶子水乱解释是不负责任的做法。
青润
18:03:43
另外，即使发生刚才那张图上的内容，也应该是extend关系，include关系是前者发生，后者必然发生，而不是有选择的，所以，include关系不是一个可以随便对多个，如果后面有多个，那么这些多个uc也应该使顺序都发生的，这个就和extend正好是相反的关系
青润
18:04:41
基本问题就这么多，业务问题，我就没法看了，那涉及到的内容太多，另外，我的惯例是不帮助解决公司内的事务，只解释纯粹的使用问题。
一个朋友
18:04:50
恩，我理解一下.
青润
18:10:56
ok
