北京-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
好的。不客氣。