《軟體方法》閱讀筆記（二）
業務建模的步驟2
：組織的業務用例圖，在乙個用例圖中，首先要找到業務的執行者，業務執行者的定義是：在組織之外和組織互動的人群或組織；在這裡，舉例說明，通過銀行，儲戶來存錢，儲戶是業務執行者；企業來貸款，企業是業務執行者；業務執行者在用例圖中的圖示是乙個小人，頭上有一道斜槓，他實際上是乙個執行者的構造型
<>
的圖形表示；有乙個概念很容易和業務執行者混淆，就是業務工人，屬於組織之內的人肉系統。業務執行者和業務工人的區別是，乙個在組織外面，乙個在組織裡面，乙個是組織不可替換的，乙個是組織可以替換掉的零件；業務工人可以被新的業務工人替換，但是更多的可能是被新的業務實體
entity
替換，業務實體就是組織中的非人系統；
我們開發系統的目的在於讓工作人員的工作簡便，這種就是責任轉移；責任轉移的思想對識別待開發系統的需求很有幫助。開發人員說：「我在開發乙個新系統。」其實說的就是「我在開發乙個新的業務實體，取代現有工人或業務實體的一些責任。」所以我們需要畫好現狀的業務序列圖，然後把待開發的系統作為乙個新的業務實體空降到序列圖，尋找改進點，得到該業務實體的責任，就可以直接對映到待開發系統的用例；
業務用例指業務執行者希望通過和組織互動達到的，而且組織能提供的價值。業務用例代表組織的本質價值，很難改變，變化的是業務用例的實現；例如：病人來醫院**，不是乙個業務用例，病人來醫院看病，才是，病人來醫院的價值和期望是看病而不是**，病人對於醫院的期望是看病，對於**室的期望才是**；業務用例有幾個要點：（1
）業務執行者（系統之外）；（
2）業務用例表達的是組織的本質價值；
業務建模中最繁重的工作是--------
描述業務用例的實現，即為業務流程，描述業務流程的手段有：（
1）文字（
2）活**（
3）序列圖（序列圖使用物件導向的思想來描述業務流程，把業務流程看做是一系列業務物件之間為了完成業務用例而執行的協作）。
其中描述業務流程的技能最好選擇序列圖，理由：
（1）活**只關注人，序列圖把人當做系統；
（2）活**表示動作，序列圖強迫思考動作背後的目的；
（3）活**更「靈活」，序列圖更不「靈活」；
軟體開發的目的就是要改進當前的現實，可能是引進乙個新系統，也可能是公升級現有的系統，在現在的社會中，很明顯，待改進的當前現實不只有業務工人，還有大量的業務實體，這些業務實體封裝了許多最開始位於業務工人中的邏輯，將來和新系統互動的系統（也就是新系統的執行者），有可能只有一部分是人，另外一部分是業務實體；使用活**來描述業務流程的時候，開發人員往往只關注人或部門的活動，忽略了業務實體的責任；
軟體需求模式閱讀筆記二
閱讀的章節是需求模式概念，使用和編寫需求模式。加上之前讀的兩章，這四章是準備，是解釋性的章節。需求模式概念解釋了需求模式存在的必要性。系統千千萬萬，但是所有的系統需求本質上彼此相似，所以，引入此概念來描述需求模式的每乙個需求應該怎麼定義。需求模式可以使用已經定義好的，他們都有自己的使用方式，也可以自...
《軟體需求模式》閱讀筆記（二）
前面了解到什麼事需求的 接下來就應該學習如何使用和編寫需求模式。我們不僅到了解需求模式的含義，更要學會在什麼情況下使用需求模式。在定義系統期間，有兩種場合使用需求模式 1.當定義需求時，看是否存在乙個模式可以指導如何定義這種需求。2.當考慮系統需求是否完全時，瀏覽主題覆蓋的整套模式 看是否有遺漏，或...
軟體需求模式閱讀筆記二
上次一次說完了整本書的前四章，主要感覺前四章是乙個整體，前提是可以一次性消化，後面幾章雖然也緊密聯絡，但是沒發一下分析帶過不能草草了之。接下來到整本書第二部分，需求模式目錄。就是分別介紹了37種需求模式，這些模式的主題在所有的商業系統中反覆出現。對大部分通用的被優先介紹，而怪異不常用的將被放在最後。...