1、開發過程：
（1）到底要解決什麼業務問題？－－業務建模
（2）為了解決業務問題，所開發系統應提供什麼功能和效能？－－需求
（3）為了提供功能，系統內部應該有什麼樣的業務核心機制？－－分析
（4）為了滿足效能，系統的核心機制如何用選定技術實現？－－設計
2、啟動：
（1）願景
a)願景：在老大看來，為什麼要開發這個系統？（2）涉眾b)願景必須來自「老大」，老大即是最有權利的涉眾
c)必須指出度量指標，度量聚焦於價值
a)誰關心這個系統？會涉及到他的什麼利益？（3）投入：願意花多少錢，允許多少時間b)探索系統的需求，就是探索涉眾利益之間的最佳平衡點
（4）風險：客戶參與少；沒有度量方式；技術風險；重要人物反對；以前曾被取消過……
3、業務建模：
（1）作用：描述現實，幫助發現軟體需求
（2）系統需求不斷變化的根源：沒有把系統放在業務中來看，系統需求不符合業務需求
（3）第一步：選定業務單元
a)願景波及的需要改進的業務單元（4）第二步：識別業務執行者b)使得大多數可能的系統使用者成為業務工人
c)涉及多個小單元時應尋找更大的單元
d)用例觀點－－把業務看成對外提供價值的價值流
e)以業務用例驅動改進－從外部認識組織的本質價值
a)在業務之外和業務互動的人或組織（5）第三步：識別業務用例b)業務執行者在業務外面，業務工人在業務裡面
a)關鍵：業務為業務執行者提供哪些價值？（6）第四步：詳述業務用例b)業務流程就是業務用例的實現
c)業務裡發生的一切都是為業務執行者提供價值
d)業務用例只針對業務執行者，內部活動不是業務用例
e)別忘了：支撐性業務流程背後的「管理型」業務用例
a)描述形式：文字、活**、序列圖（7）第五步：建立業務物件模型b)活**往往只表現事件，序列圖表現責任和協作，主要採用序列圖
c)業務序列圖——用物件導向的思想來看業務流程
d)序列圖中訊息的名字－－代表責任和目的
e)序列圖中訊息的方向－－代表責任不代表資料
f)尋找改進點：涉及到資訊的流動嗎？物流能變成資訊流嗎？包含的業務邏輯能封裝到系統裡嗎？涉及到什麼業務物件？需要系統管理起來嗎？
g)「阿布」思考法：先假設自己不受任何資源限制來設計系統，然後考慮自己的資源限制來獲得折中方案
a)用類圖勾勒出現實中的人、事物、關係4、需求：（1）難點：難捕獲、易變b)從業務模型到系統模型
（2）用例：從使用者視角看問題；合理的結構。可解決上述問題。
（3）識別系統執行者
a)系統執行者：在系統之外，透過系統邊界與系統進行有意義互動的任何事物（4）識別系統用例b)系統外：互動的功能需求
c)有多少個執行者，代表有多少個介面
d)責任的邊界，不是物理的邊界
e)直接與系統互動
f)執行者與重要無關
g)有意義的互動
h)任何事物
i)思考：誰使用系統的主要功能？誰改變系統的資料？誰從系統獲取資訊？誰需要系統的支援以完成日常工作任務？誰負責維護、管理並保持系統正常執行？系統需要應付（處理）哪些硬裝置？系統需要和哪些外部系統互動？誰（或什麼）對系統執行產生的結果感興趣？有沒有自動發生的事件？
j)區分主執行者與輔執行者，區分系統執行者與業務執行者
a)用例例項是在系統中執行的一系列動作，這些動作將生成特定執行者可見的價值結果。乙個用例定義一組用例例項。通俗一些就是執行者通過系統達到某個目標。（5）書寫系統用例文件 （6）通過關係整理用例b)用例要點：價值結果——>有意義的目標；系統執行——>價值結果由系統生成；執行者可見——>業務語言，使用者觀點；一組用例例項——>用例的粒度
c)用例命名：慎用弱動詞弱名詞
d)只要能寫出符合需求標準的路徑、步驟，都可以作為用例，用例不存在「粒度問題」
e)最常犯錯誤－－把步驟當作用例
f)需求是不「復用」的，「復用」的是業務和設計
g)到底哪一種更合適，完全取決於涉眾的看法
（7）用例的排序和分包
a)排序：（8）最後總結：用例是否用對了？判斷標準：是否加強了和涉眾的聯絡b)大量用例時的組織：按執行者分包；按主題分包；按開發團隊分包；按發布情況分包。
（9）需求啟發:
a)研究文件5、類圖:（1）物件具有狀態、行為和標識b)問卷調查
c)訪談
d)觀察
e)研究競爭對手
a)狀態：當前屬性值的組合，是行為的累積結果（2）類：共享乙個公用結構和公用行為的物件集合b)行為：物件根據狀態和接收訊息作出的反應
c)標識：和其他物件相區分
（3）識別類及其屬性：閱讀用例文件，抽取對應於業務實體或事件的詞彙；將詞彙分類、抽取出合適的類和屬性
（4）識別類之間的泛化：超類的物件集合包含子類的物件集合
（5）識別類之間的關聯：關聯的幾種表現形式
6、序列圖：
（1）通過畫序列圖完成責任分配
（2）分析工作流時三種版型的類：
a)邊界類：用例的每個執行者對映乙個邊界類。責任：輸入、輸出、過濾。（3）序列圖和類圖的對映：b)控制類（可選）：乙個用例對映乙個控制類。責任：控制事件流，負責為實體類分配責任。
c)實體類：乙個用例有多個實體類參與，乙個實體類可以參與多個用例。責任：業務行為的主要承載體。
a)訊息的傳入：類物件所具有的操作－－責任（4）序列圖繪製要點：b)訊息的傳出：類物件完成操作所需合作－－協作
a)位置：每個用例下面，對應用例的路徑（5）總的責任分配原則：低耦合，高內聚b)基本路徑：一張圖
c)簡單的擴充套件點：可以合併到基本路徑圖
a)耦合：描述設計的組成部分之間的相互依賴。沒有耦合，無法一起行動；耦合太高，無法轉彎類間要保持低耦合。目的：復用。（6）責任分配：b)內聚：描述模組內各元素的緊密結合程度。類內各元素要保持高內聚。小類，短方法－－明確責任。
a)專家原則：根據資源分配責任，各盡其才，各施其能7、狀態圖：（1）把某物件從所有的序列圖中單獨拿出來考察b)老闆原則：由老闆傳遞訊息。當出現以下情況時，發給a的訊息先通過b處理和中**b聚合a（aggregation）；b組合a（composition ）
c)可視原則：兩個物件之間有訊息傳遞，相應類應有關聯；不要與陌生人說話
（2）狀態－－在系統中表現出相同行為的屬性值組合
（3）屬性值變化導致行為發生變化－轉換
（4）在源狀態下，當事件發生時，如果符合警戒條件，則執行活動，進入目標狀態
（5）狀態圖的作用：設計好了狀態圖之後，可以使用工具進行**對映，則不需要人工編寫複雜的狀態判斷**
8、設計：
（1）分析和設計：
a)分析：強調業務概念（2）**映b)設計：強調平台實現
UML基礎 節選
在乙個系統中，類之間存在多種關係，如下所示。繼承 inheritance 繼承是指乙個類從其父類派生而來，繼承了父類的屬性和方法。基於類的繼承叫做一般化 generalization 基於介面的繼承，叫做實現 realization 關聯 association 類之間的關聯大多用來表示變數例項持有...
UML基礎概念
uml是物件導向分析與設計的專業語言，是軟體開發過程中相關人員溝通交流的語言，因此它在表達和理解抽象的軟體上起著重要的作用。uml圖分為兩大類 動態圖 用來描述系統行為的各個方面 查閱uml官方文件，會發現關於uml的標準規範已經是十分的完善，但是由於uml想要表達太多的語義，因此uml看起來也顯得...
UML建模基礎
用例模型是主要的uml代表，也是行為建模的焦點。用例模型定義用例 參與者以及這些建模元素之間的關係。活動模型能夠用圖來表示用例中的事例流。活動模型填補了用例模型中系統行為的高層表示與互動模型中行為的底層表示之間的空隙。節點是動作，連線是判斷條件。類建模整合幷包含了所有其它建模活動。類模型標識類和它們...