設計源於需求卻高於需求。 《軟體方法》上冊（五章）所表述的邏輯： 願景 業務建模 需求 分析 設計 1. 願景： 明白軟體的意義是什麼，幫助或者提高了現有系統的那些方面，減少了那些成本。 利潤 = 需求 - 設計 這個公式成立的前提是需求都已經實現，不同的設計會花費不同的成本。但看完上篇，我覺得應該 ...
設計源於需求卻高於需求。 《軟體方法》上冊（五章）所表述的邏輯： 願景 ------ 業務建模 ------ 需求 ------ 分析 ------ 設計 1. 願景： 明白軟體的意義是什麼，幫助或者提高了現有系統的那些方面，減少了那些成本。 利潤 = 需求 - 設計 這個公式成立的前提是需求都已經實現，不同的設計會花費不同的成本。但看完上篇，我覺得應該改一改： 利潤 = 業務 - 設計。 整個軟體製作的過程中，真正的價值和輸出是業務，對業務有什麼幫助、提高或者減少業務成本。從業務的分析、願景再到需求的分析之間有一定的距離和不同的理解方式，這一點也很重要。 2. 業務建模：研究 業務用例和業務對象。 業務建模主要是研究這個組織，描述現在的業務事實，劃分業務的邊界，分析出各個參與方的現象及狀況。 反過來給組織一個購買系統的理由，給系統賦予實際的價值。 註：業務和需求分析是兩個方面，業務註重對現實的描述，需求是針對於系統的分析。業務不一定和需求是一一對應的關係。業務是現實的描述，一般是不會變化的；但需求可以用不同的方式實現，並且從不同的角度出發看業務時，看到的需求也是不一樣的。 3. 需求 ： 研究系統系。統執行者，是指系統外與該系統發生功能性交互的其他系統。 系統用例，系統為執行者提供的、渉眾可以接受的價值。 系統用例的粒度，從業務的角度出發去思考這個問題，用例就是為了給系統的執行者用。
- 第一章 建模和UML
1. 該章主要講軟體方法的價值和思路，然後確定本書的觀點：建模和軟體開發完美的工作流【業務建模-需求-分析-設計】
2. 各個義務模塊思考的焦點不一樣，從上到下是有嚴格先後順序的。
- 第二章 願景
1. 回答問題，“在老大看來，為什麼要引進這樣的系統？” 2. WHO的問題：分析清楚相關的涉方，涉及到的組織和系統，利益相關方。 3. WHY的問題：為什麼要做這些，現在遇到的問題是什麼，系統需要提高那一部分，或者減少那一部分的開銷。 4. 設定可度量的目標，量化系統的指標和價值。 5. 分析利益相關方，從不同的涉方去看待系統，明確系統的定位。
- 第三章 業務建模 之 業務用例圖
1. 中心思想：軟體是組織的零件。書中認為組織和人都可以當做是一個系統，而有沒有軟體組織都可以進行下去。所以軟體就是組織的零件，在業務建模和描述業務的過程中找到組織的弱點，可以改進的地方和可以用系統來代替的地方。然後確定系統的作用，進而分析和設計系統。 2. 用例分析對象是現存的組織，分析流程： 選定要改進的組織--組織的業務用例圖 3. 選定要改進的組織： a). 分析現有的業務組織，列出現有相關業務的參與方； b). 通過願景的分析，將涉方畫在一個圈裡作為研究對象， 這裡的涉方有可能是系統，也有可能是組織，也有可能是一個人； c). 從客戶的角度分析現有各個組織的功能，可以利用時序圖和用例圖分析，搞清楚面對客戶和提供某一項服務時，各個系統之間的協作狀況； d). 尋找可以改進的地方和系統的價值所在，在時序圖的分析完成之後可以觀察時序圖，找到系統所要實現的業務模塊。 4. 組織業務用例： a). 業務的執行者：選定要改進的組織之後需要分析系統所承擔的業務。第一就是要找到業務的執行者，業務的執行者可以是其他的組織，個人。【肯定是相關組織，業務的分析都是從組織層面的分析】 b). 業務工人和業務實體。業務工人不是系統的執行者，不能和組織內的人混淆，是在組織中的人肉系統。業務執行者喝業務工人，一個在系統的外部一個在系統的內部。但這種的關係隨著業務的邊界有可能變化，如果包含在業務邊界內部，就是業務工人，如果在業務系統的外部就有可能是業務的執行者。業務實體也是在業務邊界以內充當著一定的職能，有可能是從業務工人中分離出來的機器，比如銀行業務員和點鈔機，銀行業務員就是業務工人，點鈔機就是業務實體，點鈔機一定程度承擔和業務工人的一部分責任，是從業務工人中分離出來的。 c). 業務用例圖： 通過業務時序圖來抽象系統的用例，將業務的時序圖簡化為用系統零件代替。用新流程替代舊流程，明確業務執行者對相關的組織的期望是什麼，是具體對哪個組織的期望。 5. 業務用例的分析目的：明確系統的價值和系統對外提供的功能，以及系統會不會達到第一點所提到的願景。
- 第四章 業務建模 之 業務序列圖
1. 中心思想： 在業務用例分析清楚以後，開始描述業務用例的實現，系統所承擔的業務流程是怎麼樣的，以便之後推導出有待開發的系統用例圖是什麼樣的。 2. 業務流程描述的方法： a). 文本； b). 活動圖，泳道圖，分清楚各個業務組織之間的邊界； c). 序列圖，時序圖：只涉及相關的組織和人，分析清楚交互的動作是什麼，交互的內容是什麼。 3. 業務序列圖的要點： a). 序列圖中的箭頭消息代表責任而不是數據流，代表承擔的功能業務是什麼； b). 重點聚焦於系統之間的協作是什麼，系統之間的交互是怎樣的； c). 只需要關心核心模塊的相關的分析； c). 可以把時間作為系統的特殊業務實體。 4. 業務建模的步驟： 現狀業務序列圖----改進業務序列圖 a). 現狀業務序列圖： 現狀不是純手工，現狀不是規範，根據業務序列圖要點畫出現狀業務序列圖，瞭解認識現狀，但不能以要分析的業務系統為中心拼湊。 b). 改進業務序列圖： 分析清楚現狀之後尋找業務改進的地方。思考的點：信息化、模塊劃分、職責劃分、流程簡化、信息流改善、封裝領域邏輯。【阿布思考法：假設有充足的資源解決問題，得到一個完美方案；用手上現有的資源得到一個完美的方案】
- 第五章 需求 之 系統用例
1. 需求研究的對象是系統，業務研究的對象是組織。他們之間的研究對象不一樣，分析的目的不同。 2. 系統執行者：在所研究的系統之外，能夠與該系統發生功能性交互的其他系統。 a). 特點是：系統外、交互、功能性交互、系統。系統外：通過業務用例和業務序列圖的分析，明確系統的邊界，系統邊界之外的都是系統外。交互：系統的執行者除了是系統之外的還必須與系統發生交互，也通過業務用例分析的涉眾來明確是否與系統發生交互。功能性交互：系統的執行者喝系統之間發生的交互是系統的功能性需求，從系統執行者來看是執行的利益點。系統：系統可以是一個人肉系統，也可以是一個非人智能系統，甚至是一個特別的外部系統（時間）。 b). 如何識別系統的執行者：通過業務建模，識別系統的交互對象。從業務的序列圖種映射系統的執行者。 c). 用例的主執行者和輔助執行者：箭頭的指向是主動的訪問和消息。從用例指向的外部執行者就是輔助執行者。 3. 系統用例：系統能夠為執行者提供的、涉眾可以接受的價值。從執行者出發，是執行者的利益訴求點；從系統出發，是系統對相關組織的價值意義。用例思考的過程就是發現價值的過程，從兩方面考慮，業務執行者的利益訴求點是什麼，系統能夠提供的功能是什麼。 a). 用例的粒度問題：把握住用例是面向系統，提供給執行者的用例，需要滿足執行者的訴求點。 b). 用例是執行者的動作，並不是面向資料庫的CURD。用於和動詞也必須是執行者能夠理解的，在業務序列圖種的交互動作。 c). 如何識別系統用例：在業務序列圖中，從外部指向系統的交互消息，可以映射為該系統的用例。需要明確系統的邊界在哪裡。 4. 需求分析中的系統用例可以直接由業務的分析而來，通過業務用例分析，到業務序列圖，然後從業務序列圖映射到系統的用例。
- 總結
面向對象是一種方法論，怎麼去認識真實的世界，是一種思想理論。 UML是用面向對象的思想，分析真實世界的工具和交流的語言，將真實世界翻譯成與軟體行業交互的語言。《軟體方法》中講述了怎麼去按照面向對象的思想，用UML分析真實世界，指導幫助開發軟體的方法。
