[答疑]欄位列表裡要不要多加一個微訊號
- 2019 年 10 月 6 日
- 筆記
evegao 2019-6-24 12:15
欄位列表的定義和是什麼？什麼類型的欄位應該列入到欄位列表裡呢？
例如 微信app 內有很多應用，例如紅包，轉帳面對面。微信支付用戶-發起轉賬。發起者的微訊號 是不用列入到欄位列表裡面的嗎？那個 這個用戶身份如何描述呢
UMLChina潘加宇:
如實描述即可。在某一次交互中，外系統需要告訴系統什麼，系統需要記住什麼，系統需要告訴外系統什麼
jeri:
1.助理請求開始創建公開課
按現有的寫法是，這個請求需要給umlchina業務系統提交什麼欄位?
1.用戶標識 長度:11位, 類型：數字+字母
evegao的疑問是類似為何umlchina業務系統不需要知道用戶身份，是誰都可以創建？
UMLChina潘加宇:
如實描述即可，攝像機應該拍到啥就是啥。UMLChina系統不需要驗證身份，小偷撿到我們的電腦也可以用。微信支付也是一樣的，攝像機可能拍到需要輸密碼，其他應該不用輸入的。
jeri:
人肉系統是輸入了密碼，但是微信支付系統需要知道哪個用戶，不然不知道是哪個用戶轉賬-----上面提問的是指這個問題
UMLChina潘加宇:
對。這就是你們幾位思想上的糊塗點。仔細再想想。這個地方糊塗的話，估計一大片用例規約都需要改了。
沒拍到人肉系統提交用戶名，但照樣可以轉賬，是怎麼回事呢？想想不就知道了嘛。
就像那個笑話一樣，普通的雨傘對準獅子，結果啪的一下，獅子胸口炸出彈孔，莫非雨傘里有子彈？
UMLChina潘加宇:
我針對之前的問題再詳細回答一下：
jiwei 2019-3-11 17:15
潘老師，欄位列表應該寫那些內容這個怎麼判斷？是寫執行者輸入的，還是說要把系統為了體驗讓一些內容系統自動提交的欄位也要寫。
例如：付款的時候需要用戶輸入支付密碼，並且要讓用戶選擇是銀行卡還是付款還是零錢，那欄位列表是只需要寫支付密碼，還是說支付密碼、零錢、用戶的微訊號這三個都需要
UMLChina潘加宇: 先去掉"自動"這種不嚴謹的用語。
這也是很多人普遍存在的問題，沒事找事。
第一句都已經說清楚了:
付款的時候需要用戶輸入支付密碼（資訊1），並且要讓用戶選擇是銀行卡還是付款還是零錢（資訊2）。
事實已經說得明明白白了吧，下面又來了一句：
那欄位列表是只需要寫支付密碼，還是說支付密碼、零錢、用戶的微訊號這三個都需要。
如果可以隨意加1個，加2個可以不，加3個呢，把資料庫裡面所有的欄位都加上去怎麼樣呢？
圖1
如圖1，左邊需要輸入的資訊更少，比右邊更好用。那為什麼我們的需求人員會自殘，硬要把圖1左邊的聰明系統寫成右邊的笨系統呢？
原因可能是：
（1）需求人員不相信系統那麼聰明，懷疑自己看到的圖1左側不是真相，設想右側才是真相。
這個需要需求人員去醫院檢查了。
（2）需求人員了解圖1左側是真相，但由於摻雜了設計導致混淆了"系統"的邊界。
圖2
如圖2所示，猜想系統可能的實現是Client（也就是那個移動設備上的app了）上會保存有一個SessionID之類的東西，這個SessionID是之前登錄時Server分配的。每次交互，Client需要向Server那邊發送的請求里要加上這個SessionID（應該不是發送微訊號）。
因為app和執行者在同一個物理位置，執行者的手指和app的介面親密接觸，會感覺這兩者是一體的，而Server物理位置在遠方。需求人員在思考的時候，以物理位置為依據，不知不覺把系統邊界往後移了一段。由藍色線移到綠色線。
圖3
《軟體方法》裡面也強調了，系統邊界是責任邊界，不是物理邊界。"系統"就是"要履行的責任的總和"，不管物理上它長得怎麼樣。
需求人員必須把"系統"這個"責任總和"當成一個整體來思考，不要沒事找事去操心提供"責任總和"的這個"系統"內部怎麼分割。
（3）需求人員知道左側是真相，也沒搞錯系統邊界，但害怕要是請求步驟的欄位列表裡不加微訊號（或SessionID），用例規約里體現不出來"系統里要保存微訊號（或SessionID）這個數據"，導致無法指導設計人員做設計（請複習《軟體方法》第1章第1道測試題）。所以，為了體諒設計人員的難處，故意加上去。
如果用例規約里真的需要出現這個微訊號（或SessionID），即使這個用例的這個請求步驟的欄位列表裡沒有，也可能會出現在其他請求、驗證、改變或回應步驟的欄位列表、業務規則里，或者其他用例的用例規約里。
如果用例規約里不需要出現這個微訊號（或SessionID），那應該是好事啊！說明微訊號（或SessionID）不屬於"不這樣不行"，設計人員愛想什麼辦法記住當前的會話狀態都可以（SessionID當然也可以）。
另外再說一句，清晰表達系統應承擔的責任即可，不能保證的不要寫。前面提到UMLChina那個不用輸密碼的例子，其實微信也差不多，例如歹徒脅迫張三告知密碼，歹徒操作；張三輸完密碼之後就被歹徒捅了一刀死翹翹了，歹徒撿起手機完成最後的確認……系統並沒有承諾外面執行者一定就是那個人，只是會盡量做一些事情來靠近。
（2）和（3）說明，一旦需求人員操心設計，就會出現各種需求怪胎。