軟體方法閱讀筆記（三）

標籤：

 業務建模映射出系統用例的識別方法：在業務順序圖表中，從外部指向所研究系統的訊息可以映射為該系統的用例。  
  識別系統用例的注意事項：
  一、主執行者和輔執行者：主執行者從執行者指向用例，而輔執行者從用例指向執行者，主執行者發起用例的互動，輔執行者在互動過程中被動參與進來。情境：主執行者要執行用例，需要輔執行者的幫忙。
  二、切勿把到輔執行者的箭頭誤解為資料傳送的方向。
  三、主輔執行者是針對某個用例來說的，一個系統在這個用例中充當主執行者，也可以在另一個用例中充當輔執行者。一般說來，輔執行者是人肉系統的情況比較少，更多時候是另一個非人智能系統。
  四、用例是涉眾願意“購買”的、對系統的一種“用法”，只要涉眾願意“購買”，當然是越多越好。
  五、需求是不考慮“複用“的，如果在考慮”複用“，要緊惕自己是不是已經轉換到了設計視角來思考問題。
  六、針對不同執行者、不同商務程序，系統提供的價值可大可小，無論大小均是用例。
  七、用例的命名。用例命名採用"動賓結構"，賓語前可以加定語，把一句話的主語砍掉，剩下的可以做用例的名字。  
  常見錯誤：踏實研究商務程序，做好業務建模，盡量從業務順序圖表中映射出系統用例，這樣的系統用例是不會騙人的。
  一、把步驟當作用例。Include（包含）關係的目的是為了複用在多個用例中重複出現的步驟集合，形狀往往是多個大用例Include一個小用例。
  二、CRUD問題。把資料庫的各個表名加上新增、檢索、修改、刪除就得到了用例的名字或者把四種操作合并稱為“XX管理”。
  三、玩弄“複用”：用例的執行者不同，背後的涉眾利益也有差別，不能簡單的合并複用為某一個操作。
  四、多個主執行者指向同一個用例。如果使用案例圖已完成，對於這種錯誤的修改，可以通過泛化出抽象的執行者或者分成幾個不同的用例的方法來修改。後一種更常見。
  五、玩弄”層次“。切勿偷換"研究對象"，也切勿”把願景當系統功能“。
  六、玩弄”子系統“：用例很多時可以將用例分包，但用例包是在系統的外部對系統功能所做的劃分，而子系統則是根據內部組件的耦合和內聚切割得到。
  七：模糊的價值：系統往往無法承諾執行者預期的價值時，則該價值不是執行者的用例。主執行者執行用例時，若是需要輔執行者提供即時的協助後才能進行，則用例正確，否則用例錯誤。  
  關於“XX管理”的用例：這種用例無法從商務程序中映射，但系統需要它們來支撐。也只有對於這種支撐的管理基本資料的用例，才用“XX管理”來打掃戰場。"XX管理"這樣的用例往往是給管理員管理基本資料用的，而且都是千篇一律。
  軟體工程的“底層”：怎樣才能使這段代碼更容易維護和擴充？這段代碼達到的功能和效能對涉眾意味著什嗎？

        2). 系統用例規約：也就是以用例方式組織的需求規約，我們需要通過書寫用例規約把用例背後封裝的各種相關需求表達出來，並用類圖展示用例的各項內容。
     用例包含的內容：
     a. 前置條件和後置條件：用例通過前置條件、後置條件以契約的形式表達需求。可以想象成：在滿足前置條件的開始，按照說明的路徑步驟走，就能達到後置條件。    
        後置條件分類：最小後置和成功後置。最小後置指在用例失敗的情況下也要滿足的約束，而成功後置指用例成功時系統需要滿足的約束。     
        前置、後置條件的要求：
        一、前置條件、後置條件必須是系統能檢測的。
        二、前置條件必須是用例開始前系統能檢測的。
        三、前置後置條件是約束，不是動作。
        四、前置後置條件要有系統的味道。
        五、登入的問題：登入不是用例，不能從登入擴充出產看訂單等功能，擴充的正真意思是分支。正確的做法應該是把登入變成被其他用例包含的被包含用例，在寫用例規約的時候發現下單、查單等用例都有登入步驟，為節省工作量把這些形成一個小目標的步驟集合分離出一個只能被其他用例包含的用例。如：會員登入中，加括弧的登入表示這是一個被包含用例，他的步驟和約束在另外的地方描述。

        涉眾利益的要求：前置條件是起點，後置條件是終點，這中間的最要的內容就是涉眾利益，即：某類人擔心什麼、希望什麼，若沒有涉眾利益很難得到正確的需求。認識到需求由涉眾利益的平衡和衝突決定，可以協助我們直入需求的核心。
        一、如何尋找涉眾：定位用例涉眾的情境：如果系統的這個用例做不好，誰或者哪個系統會遭殃？誰會擔心自己的直接利益受侵害？
            從執行者觸發尋找涉眾：若果執行者是人，其便為用例涉眾。否則，執行者沒有利益主張，不算涉眾，但是要留意其背後可能的涉眾。
     從“上遊”尋找涉眾：執行者使用系統做某個用例，需要一些資源，這些資源的提供者可能是涉眾。
     從“下遊”尋找涉眾：執行者使用系統做某個用例，會產生後果，這個後果所影響到的人也是涉眾。
     從“資訊的主人”尋找涉眾：用例用到的相關資訊所涉及的某些人（也可能其不知道這個系統的存在）的利益受系統好壞的影響。隨著策略環境變化、組織需要調整，原有良好的系統確實要改變，這才是真的需求變更。
     從“給涉眾排位”尋找主要涉眾：涉眾排位是否準確，直接影響了需求的內容，開發人員別只盯住了“使用者”而忽略了前排涉眾。並沒有一定的排位準則，只能根據所改進組織的特點歸納總結。
     “親兄弟，明算賬”：在描述涉眾利益時，要把不同涉眾關注的不同利益體現出來。在列出涉眾利益後，在照顧前排涉眾利益的同時，也要爭取兼顧和平衡其他涉眾的利益。涉眾利益放在用例規約裡可以體現出不同涉眾針對不同用例有不同利益的特點。
     “基本路徑”：我們需要寫出能夠平衡各方涉眾利益的路徑、步驟和補充約束。用例需要有一條基本路徑，若干條擴充路徑，首先把基本路徑單獨分離先寫出來，因其代表用例核心價值的路徑。
         書寫路徑步驟的要點：
         1.) 按照互動四步曲書寫：執行者和系統一個個回合進行互動，直到達成目的。每回合步驟分為兩類：請求、回應（有的回合可能沒有驗證和改變），其中括弧表示操作在系統內。
         2.) 使用主動語句理清責任：把動作的責任人放在主語的位置，用Cockburn的話就是“球在哪裡”。
         3.) 主語只能是主執行者或系統。寫需求時要把系統當作一個黑箱，僅描述它對外提供的功能和效能，而系統如何構造不屬於需求描述的範圍。
         4.) 使用核心域的概念：路徑步驟是功能需求，應該使用核心域的概念來描述，也就是說，要說“人話”。應該避免“技術”、“業務”等名詞，而換用“核心域”、“非核心域”來代替。
         5.) 不要涉及互動設計的細節：避免把介面細節帶入到需求中。“人有眼鏡”不是需求，需求是“人能看”。
             需求的判斷標準：需求是問“不這樣行嗎”，而不是“這樣行嗎”。需求確實需要寫的細，是需要將需求（問題）寫的細，而不是將設計（解決方案）寫的細。

 

軟體方法閱讀筆記（三）