?譚老師，您好

我現在有一個疑問，在銀行的自助終端系統進行業務建模時，客戶端（即自助終端）連接銀行中間業務平臺系統。

終端用戶可以利用自助終端進行如下操作，如終端用戶業務用例圖所示

自助終端的業務用例圖如下圖所示：

問題1)?我把所有終端用戶的請求在自助終端用例圖里都概括轉化為一個“業務請求”，您覺得這么做合適嗎？應該怎么做呢？

下面是訂購機票的業務場景圖，如下圖所示

問題2)?在這里有“終端用戶”、“自助終端”、“中間業務平臺”、“航空公司”等四個泳道，是否有多余？或者有遺漏？

問題3)?你在博客中說泳道都是在定義涉眾時所定義的Business Actor，我看您的例子里面，泳道都是人！我這里除了“終端用戶”是人外，

其它都是系統，這樣做合適否？是不是有點系統建模的意味了？

譚老師，在這里建模的時候，每遇到新的場景或新的問題，就感覺有些不知所措了，希望譚老師在百忙之中抽出時間為我指點一下。多謝！！

祝你元旦快樂，新年新氣象！！

?

我的回復:

問題一：

這樣做是可以的，相當于你從大量業務用例當中抽象出了一個大家都會使用到的業務請求用例。不過，這樣做要基于以下的幾點考慮： 1. 這個業務請求用例對于其它的業務用例來說，用例場景是一致的，也就是說它對其它業務用例來說是公用的； 2. 這個業務請求用例不依賴于某個業務用例的場景。換言之，它可以獨立出來，它的啟動、停止和執行過程不依賴于其它的業務用例； 3. 其它業務用例與它的關系是擴展或包含的關系，即其它用例擴展或包含它，而不是它來擴展或包含其它業務用例； 如果符合以上三點，那么把它抽象出來是合理的。不過，即使是合理的，我仍然建議不要在業務建模階段做這樣的抽象。原因是諸如充值、繳費這些業務用例對應于實際的業務，非常好理解，并且能夠很清楚的向業務人員和技術人員解釋。如果抽象出一個所謂業務請求用例，它就沒有與現實業務有對應關系，并且你不能夠把它的業務目標說清楚。業務請求？請求什么？返回什么？誰來請求？如何請求？，這些問題你必須把所有的其它相關業務用例都融合進來才能講清楚。對吧，因為這是一個抽象用例，必須結合實際才能解釋明白，在業務層面上太多抽象是不太合適的。你可以在概念建模階段來抽象它，也可以在系統建模時來抽象它。概念建模階段這個抽象用例可以給你提供公用的場景來分析公用的分析對象；系統建模階段則可以給你提供公共的接口分析設計來源。 問題二： 以我的業務理解，這里不缺什么內容了。判斷是否有多余或者遺漏不是從技術層面來的，而是業務層面，應該由業務專家來評判。 問題三： business actor可以是人，也可以是物。我的例子里全是人是因為我的例子是一個單一的人機交互系統，業務是人與人借助系統交互完成的。你這個系統是由系統和系統交互來完成的，所以泳道是系統完全沒有問題。你這里雖然有系統存在，但絕對不是系統建模，所謂系統建模，是要描述系統行為，而不是業務行為，對應的，泳道應當是具體的對象，并且消息應當是方法級別的。

?

?

?

轉載于:https://www.cnblogs.com/fengju/archive/2008/12/31/6173674.html

總結

以上是生活随笔為你收集整理的关于业务用例抽象问题对网友的回复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。