[全程建模]關於Actor與外部系統的對話

北京-FireSpider 男2013/2/4 20:45:25

青潤老師線上嗎？

北京-FireSpider 男 2013/2/4 20:51:30

 被動的Actor好像真的存在呀。在邱鬱惠的《系統分析師UML用例實戰》的第47頁有一個例子：購物網站中有一個用例“刷卡結賬”，它有一個被動的Actor，是“信用卡系統”。

青潤  21:59:21

呵呵，邱的做法也是錯誤的。

我看過她的那本書，裡面在這方面，確實錯了。

北京-FireSpider 男  22:00:21

這個問題值得關注，因為涉及對外介面這一塊。

哪比如“列印”用例需要連線到“印表機裝置”，應該如何表示呢？

青潤  22:01:14

這些都屬於外部系統

只需要通過系統表示即可。

至於這些系統內部如何執行，是不需要考慮的，因為這不是你要開發的部分。

北京-FireSpider 男  22:01:47

畫成一個方框？

對

青潤  22:02:42

系統本來就分為外部和內部，內部還要分為各個實施階段，也就會出現本次開發需要實現的，和不需要實現的。

不需要實現的部分與外部系統是同等的表示方式。

如果不是這樣表示，難道你也要把這些uc表示成actor麼？

北京-FireSpider 男  22:03:23

嗯，畫成Actor感覺是挺怪異的。

但，如果一個用例是一個WebService的方法，是需要外部系統主動呼叫的。哪這個外部系統作為主動呼叫方，可以畫成Actor嗎？

青潤  22:04:21

我從02年開始就一直強調actor必須是可以主動發起行為的，因此資料庫，時鐘等都不是actor。

另外，還有一個很多人都犯的錯誤，那就是對actor上進行類設計。

那也不是actor，因為這也只是外部的介面呼叫，如果不是介面呼叫，那就不是外部系統了。

如果外部系統可以通過非介面對你的系統中的方法進行呼叫操作，那你的系統就會出現嚴重的安全隱患，或者屬於被操控。

青潤  22:05:21

這在系統設計中是完全不能容忍的。

北京-FireSpider 男  22:07:55

主動發起系統行為的，通常是人，但也可以是系統，還可以是裝置的按鈕等。

青潤  22:08:11

裝置的按鈕，也是人去操作的。

如果是時間控制器，那也是人進行的設定，然後才能啟動，所以，一切非主動行為者，都不能定義為actor

北京-FireSpider 男  22:08:34

嗯

但如果是一個遠端系統的話，就不是了。

青潤  22:09:04

那就是介面，也同樣不是actor

北京-FireSpider 男  22:09:46

比如，一個C# Remoting伺服器在執行時暴漏了Rometing的介面，客戶端通過介面來呼叫他的功能。

青潤  22:10:31

無論任何一種，你都可以找到actor的存在，如果找不到，那就肯定是系統設計中出現了問題，或者沒有調研清楚需求。這一點，不容置疑。

北京-FireSpider 男  22:11:57

不過，要是通過關注客戶端的的人，是不是有點太間接了？

青潤  22:12:19

這是個原則，不是說可以談判的，對於系統，必須弄清楚原委，否則，肯定會出現設計問題。

如果你找不到實際的actor，那就會出現問題，或者隱藏的actor出現。

北京-FireSpider 男  22:12:51

主要是，不知道哦客戶端的系統是怎麼開發的，人觸發的操作經過多少個介面呼叫以後，才呼叫到伺服器端介面的。

青潤  22:13:32

你自己思考一下你假設得這個過程，這個過程如果出現了這麼多的介面呼叫，是否違反了系統設計原則？

北京-FireSpider 男  22:15:31

我想想

青潤  22:16:53

嗯。考慮一下OOAD的設計原則，然後再來思考你剛才提出的這些問題。

北京-FireSpider 男  22:19:01

好的

先謝謝老師，我思考思考。

青潤  22:19:25

好的。不客氣。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE