案例(詳細):用戶在Android應用程序中選擇一些文件,並將SOAP請求發送到WebService以將選定的文件設置爲收藏夾。設置收藏夾:以下用例圖正確嗎?
案例(有幾句話):用戶要設置一些文件爲收藏
序列圖: User-->FileBrowser-->WebService-->DbManager-->Database
那麼,是下圖正確的還是我失去了一些東西?
案例(詳細):用戶在Android應用程序中選擇一些文件,並將SOAP請求發送到WebService以將選定的文件設置爲收藏夾。設置收藏夾:以下用例圖正確嗎?
案例(有幾句話):用戶要設置一些文件爲收藏
序列圖: User-->FileBrowser-->WebService-->DbManager-->Database
那麼,是下圖正確的還是我失去了一些東西?
你的圖看起來不錯。但是,我從其他問題中注意到,您現在正在混合業務和技術方面。如果你想爲業務做一個用例綜合(這是最常見的應用),你不能開始混合技術方面。說了這些之後,Login並不是一個商業用例。一個用例在短期內描述了一個參與者在應用時獲得的附加價值。在業務層面上,登錄只是一個約束,因爲它沒有增加任何價值。
作爲一個建議:
只有在這之後開始技術設計。您可以在技術級別使用用例,您可以將登錄用例描述爲身份驗證子系統的一部分。
如果您不包含某種系統,而用戶和服務器不在這個系統之外?我的老師總是評論涉及這個系統。 列出系統外的所有用戶。用例可以作爲答案:「系統會做什麼?」。外部用戶/系統使用的是數據庫嗎?在這種情況下,最好將它表示爲一個獨立的演員。
也許是在使用casediagram之前編寫完整用例的想法。
兩件事情沒有按照UML:
建議:
是的,顯示正在考慮的系統(SUC)作爲邊界是正面的。仔細看,這些用例位於SUC的邊界上,因爲它們代表了演員與SUC之間的通信。但將UCs放在SUC邊界內也是很常見的。 –