這里是幾個常見的uml設計錯誤，文中也是實例，因此隱去了相關信息，圖中遮擋的部分是完全一樣的兩個字，你可以把它考慮成任何東西。

一個朋友
17:29:39
青潤兄，周末的時候讓你指教的地方有沒有看
青潤
17:30:21
還沒有看，這幾天比較累，等下應該會有時間了。
一個朋友
17:32:06
好的，拜托了。
青潤
17:32:29
過會兒給你消息。
一個朋友
17:33:16
thanks
青潤
17:56:44

這個拆分，貌似有點過度細化了，如果業(yè)務不是很復雜沒有必要，有發(fā)布必然有人看，uc改成一個，右側的use關系修改為查看，左側的修改為發(fā)布，這個是權限控制的東西，沒必要在這里細分uc的方式來區(qū)分。
青潤
17:57:30
use關系一般可以不標出
一個朋友
17:57:46
恩，但可能是接口呢？
一個朋友
17:57:52
就是另外的系統(tǒng)。
青潤
17:59:01
那就是具體業(yè)務問題，我只是在說一般情況下，你們的深入業(yè)務，我就不了解了，我只幫看看看是否規(guī)則。
關于uc的細化，你現在沒有書，我也沒法發(fā)給你了，等將來你看了書，按照上面的方式進行細化，就可以做的很好了，我書上給了量化的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

這個區(qū)分是沒有必要的，如果前一個uc過大，就直接拆分用后面的uc即可，這種劃分方式增加了uc數量，但實際上屬于重復定義。
青潤
18:02:20
extend我的解釋就是最標準的，和uml concept上是完全一致的。
很多半瓶子水亂解釋是不負責任的做法。
青潤
18:03:43
另外，即使發(fā)生剛才那張圖上的內容，也應該是extend關系，include關系是前者發(fā)生，后者必然發(fā)生，而不是有選擇的，所以，include關系不是一個可以隨便對多個，如果后面有多個，那么這些多個uc也應該使順序都發(fā)生的，這個就和extend正好是相反的關系
青潤
18:04:41
基本問題就這么多，業(yè)務問題，我就沒法看了，那涉及到的內容太多，另外，我的慣例是不幫助解決公司內的事務，只解釋純粹的使用問題。
一個朋友
18:04:50
恩，我理解一下.
青潤
18:10:56
ok

[全程建模]幾個常見的UML設計錯誤