統一建模語言（不同圖的表示法）
類圖
領域模型（分析模型）
互動圖（順序圖和協作圖）
UML活動圖
UML狀態圖
GRASP:（軟體職責分配，任何多於兩個類程式，每個類中寫哪些方法，兩個物件之間如何互動）與GOF（設計模型)；

UML是什麼？
標準定義：統一建模語言是描述、構造和文件化系統製品的視覺化語言；是一個龐大的圖形化表示法體系
1、是一種用面向物件（OOA/D）方法進行分析設計用於軟體開發的工具；
        隱藏在後面的是一種面向物件的想法，重要的是OOAD
2、表達我們想法的工具(首先要有想法)
3、學習各種表示法（用不同的圖形來描述）
4、是一個文件化的東西，把想法用某種方式固定下來
5
 
、用UML實際上就是寫文件（用圖形）
與程式語言之間的某些東西是可以直接對映的但是不把它當成程式語言；

UML不是什麼？
UML不是OOA/D，也不是方法，僅僅是一種圖形表示法
如果不掌握物件思想，那麼UML或任何case工具將毫無意義
需要一種用於OOA/D的語言，即是一種思考的工具，也是一種溝通的形式，因此將在OOAD中應用UML

應用UML的三種方式？
草圖：最常用的方式；草稿：可以隨時丟棄，在分析中逐步精華，中間很多過程是要丟棄的，不斷髮生變化，用於溝通；------最終得到藍圖
藍圖：比較完善的設計方案；可以基於藍圖開發，但不一定有這些圖形；軟體開發的差不多了才畫，這種情況下的圖比較穩定，並且是為了以後的需要（eg、軟體非常複雜，在圖中把關鍵的部分畫出來，以便以後的人員來維護和理解系統）
 

程式語言：通常不把其當成程式語言，UML類圖裡面有類的概念，其可以對映到面向物件裡面的一個類，atribute可以對映到java中的變數,operation（操作）可以對映到方法，但並不是所有東西都可以對映

UML失敗的地方？
在分析和設計中設計的不好的話，設計和開發脫節的過程，開發中需求不斷的變化，這時設計圖就沒多少意義，此時建議變化非常大的話藍圖不用畫的太細；
UML使用？
從大的概念上非常簡略的用它，不應該寫的非常細，需要畫才畫，並且其只具有指導性的意義，指導程式設計；
演算法的話，一般用流程圖來描述，更好的方法用一段程式碼

如何將UML作為一種程式語言？（就畫幾張圖）
MDD：（ Model-Driven Development模型驅動開發）eg:在圖中設計上user(string
 
)，password(string)，id(int)然後可以通過MDD的工具生成程式碼包括egSSH的有實體類，有Hamlet對映檔案，有配置檔案，usermanager介面、實現useraction，jsp(form表單);可以根據平臺無關模型生成平臺相關模型再根據平臺相關模型生成程式碼

如何提高自己的分析和設計能力？
寫程式碼，多想，why?why not that？

什麼是建模？
理解：給現實世界建立一種能被人理解的模型（eg 如何從A地到B地，方法：語言描述或畫圖並用圖例，但是全都表示在一個圖裡面會看不懂）；
對現實世界的描述，從各角度。軟體需要從概念（幹嘛）、需求，給誰用等多方面理解，描述完了就需要實現，捕獲完需求以後需要對需求進行分析，結果就得到模型（概念模型），需求可以通過需求文件、用例圖來分析；-----》（1、分析概念（eg:課程管理系統：有學生、課程、班級，老師，課程名稱等，以及之間的關係，並建立關聯）得到概念及概念之間的聯絡）-----》實現（採用BS還是CS，什麼架構等）----》設計（提交資料，接收、儲存等，類之間的關係，依賴等）需要靜態及動態來理解
軟體建模包含：靜態（概念模型【都有哪些東西】，客戶端+伺服器（負載均衡，so需要多臺伺服器）+分散式部署（資料庫）等）和動態【互動】

UML的要素？
1、表示法--圖形：畫出來，圈表示一個介面，框表示一個類，線表示訊息
2、過程(uml與過程無關，但最好用於RUP)
3、工具（Rational Rose），可以在紙上啥的畫

分析？
對問題和需求的調查研究
面對物件的分析？
在問題域內發現和描述物件：ge學生（本科與研究生）

設計？
滿足需求的概念上的解決方案，eg物件及其屬性
面對物件設計？
如何定義軟體物件以及它們之間如何協作以實現需求。eg(東北人都是活雷鋒：東北人繼承人--屬性，活雷鋒（表示一種精神、行為（動作）--介面），關係：實現，)

如何將UML用於面向物件的設計？
eg:
1、你要做什麼？

用例：描述怎麼用（互動），情節的描述，幹什麼
領域模型（類似於業務模型）

2、從中抽象出概念————類圖（靜態）【在傳統的軟體開發中此過程類似設計資料庫表（欄位外來鍵ER圖等），若是面向物件的方式來開發抽象出概念】
分析：抽出概念，暫時先不考慮骰子的屬性，不要先陷入細節中，需要逐步分解，需求分析和功能分析都是如此，從大方向確定其模組，逐步進行功能分解。

各物件之間究竟是如何互動才能實現（遊戲者請求骰子展示結果這些過程需要物件完成）

3、各物件之間如何互動———–順序圖(動態建模)，某個action，dao等並分析出其中各有哪些方法

需要和骰子游戲進行互動，骰子游戲物件又跟兩個骰子物件進行互動

箭頭表示呼叫的方向：誰呼叫誰

eg;遊戲者呼叫骰子游戲，骰子游戲呼叫另一個物件骰子，so投擲這個動作實際上是由骰子本身完成的並還提供獲取點數的功能，投擲以後就會產生點數這個概念，這個遊戲就需要獲得點數；此種設計方案把點數產生的職責交給骰子，（why交給骰子，一扔骰子需要提供點數，why不將點數獲得寫在骰子游戲裡面，因為不符合面向物件的習慣，職責分配，寫給骰子可以改變規則，對所有的骰子游戲都是一樣的——GRASP（我要完成某個功能，該功能交給誰完成））

箭頭的指向表示這個功能是誰完成的

4、進一步分析–設計階段（實現）
中間的箭頭表示關聯性，2表示多重名稱，箭頭表示導航性