Alan 2020-5-14 12:41
各位同學，對于1.3 1.6 在需求規約這樣寫
系統請求A系統處理XXX，
系統等待B系統發送分析結果
這樣合理不？ 還是要拆成1.6拆成另一個用例，但是使用者對引入系統的期望是回報xxx結果，拆成兩個用例不大恰當
UMLChina潘加宇
所有的消息，往下追究，都是異步的，難道1.1就不需要時間嗎，也可以分兩截來畫。
關鍵是厘清楚從涉衆的視角看，哪些是“不這樣不行”，哪些是“這樣也行”。
如果涉衆認為系統做完1.3，就可以告一段落了，不必再等待，不這樣不行！那就是按照圖上畫。
如果如果涉衆認為系統必須做到1.7才算告一段落，不這樣不行！1.4-1.6是不存在的，因為涉衆不在意。
如果如果涉衆認為系統必須做到1.7才算告一段落，開發團隊設想了一個1.4-1.6的實作方案……想也沒用，因為做需求的時候，開發團隊必須被殺光，系統是外包給外星人做的。
另外業務序列圖上的消息的抽象級别是：“系統之間的協作”，比“對象之間的協作”要大，很可能業務序列圖上的一條消息，就映射某系統的一個用例，然後在分析設計時演化出該系統内對象之間調用的很多條消息。
“系統等待”這樣的語句如果描述的是意念，那就不要寫，除非“等待”是系統必須做的行為（以後可能映射成wait（10000）之類的代碼）。寫清楚外面告訴系統什麼，系統做什麼，系統告訴外面什麼。
圖畫得不錯，自學能畫得這樣，有一定的水準了
Alan 2020-5-14 15:32
了解，謝謝潘老師，我再消化下，涉衆希望是到1.7 這步， 1.4-1.6 畫出來，是之看看答疑裡說錄影機拍到什麼就畫什麼，但是陷入了先實作的細節
UMLChina潘加宇
序列圖一開始照這樣畫也行了，但映射的系統用例就是一個
Alan
嗯嗯，我覺得用例應該一個，書上說箭頭指向系統的就是系統的用例，是以我在這裡就有疑問，沒處理過這種情況
UMLChina潘加宇
對的，序列圖也改過來更好
Alan
雖然A不能響應，但是調用A時，其實是有期待的，這裡應該有擴充？
UMLChina潘加宇
你是說用例規約裡？調用外系統肯定有擴充，因為外系統是不受控制的
Alan
是的，說的是用例規約，在軟體方法的P214 , 如果不從外系統那裡得到任何結果，這個外系統就不是輔執行， 嚴格來說，是不能從A系統得到結果。但涉衆期望在這裡能得到結果
UMLChina潘加宇
有結果啊，這個結果就是對方接收了1.3，擴充條件是：A無響應，而不是A搞不定
Alan
我知道我的問題了， 因為系統調用A後，得不到響應，這個是實作，寫需求時不要考慮實作
UMLChina潘加宇
這裡面還是一樣的，期待到什麼目标。
系統已經發出消息，例如：系統播放一段聲音給外面某人聽，外面這個人聽不聽得到，系統不想管也管不着。
另一種：
系統發出消息，并感覺到外系統已經收到
Alan 2020-5-14 15:59
并感覺到外系統已經收到-----嗯，這裡的感覺外系統已經收到，并不是說要A系統回一個消息包，隻要能感覺外系統即可, 怎麼實作，是開發人員的事
Alan 2020-5-15 9:35
如果如果涉衆認為系統必須做到1.7才算告一段落，不這樣不行！1.4-1.6是不存在的，因為涉衆不在意。----我鄱了下書，這個說法可能不大恰當，業務用例由組織中各個系統的協作完成，要如實反映有哪些系統參與了這個業務用例片斷的實作
沒有1.4，業務用例不能實作，不這樣不行，同時也為下一次改進提供了“現狀”
把1.6修改成虛線，表示消息通知，就像A叫B借錢給C，B->是虛線。這樣修改是否更恰當
UMLChina潘加宇
你這個圖如果說的是現狀的情況，這樣如實描述是對的。外星人來了，也不更改現狀就是如此的事實。
把握好抽象級别就行了