?
前兩天買了一本《大象 Thinking in UML》，其實本就有學習UML的念頭，但都因這樣那樣的事兒耽擱了，當然，也有些惰性在作祟......
閑話少說，這本書看完了一章，發現還是不錯的，先把這兩天的學習情況總結一下：
一、UML來龍去脈的第一章：
從現實情況而言，面向過程方法在復雜度不是很大的項目中應該說是適用的，但是對于規模較大、復雜度較高的項目而言，應該盡可能考慮面向對象的方法，也就是OOA/OOD/OOP。
=>說明方法方式是死的，活學活用+實踐總結才是正解。
面向對象的方法的重點和難點在于抽象、如何抽象才能貼近現實之需？我們需要解決及面對以下三點問題：
1）現實環境怎樣映射到對象環境？
2）用對象的角度怎樣來描述現實環境？
3）怎樣驗證對象環境的描述是正確反映了現實環境的實際的？
當然，答案就是UML，確切地說，UML是工具，我個人覺得作者應該在這個時侯先不緊跟著就提UML，應該先說說RUP，在說UML會比較好。我的理解是：要回答上述三個問題，答案應該是各種軟件工程方法，比如RUP，同時運用的工具是UML，這么理解比較好。
UML中，有用例（use case）、類、包等等，稱之為元模型；規則和圖形稱之為表示法或視圖（View）。
一般整個建模的過程是：
1）先從現實世界->業務模型：
?整個面向對象方法圍繞這這四個基本因素：人、事、物以及規則。
?這時候用例即事（要實現的業務目標），參與者（actor）即人，業務場景（business scenario）和用例場景（use case scenario）是規則，業務對象模型（business object model）是物。
2）業務模型->概念模型：
上面的業務模型就是開始，得到了業務模型后，要把業務模型轉換為計算機能夠理解的模型：先過渡到概念模型吧。
UML通過概念化的過程（conceptual）建立分析模型，分析模型向上映射了原始需求，向下為計算機實現規定了高層次的抽象，承上啟下。
人：用戶，邊界類（boundary）：事，實體類（entity）：物，控制類（control）：規則。
概念模型描繪出了軟件藍圖，比如造汽車，已經在圖紙上繪制了汽車所有的零部件，以及如何組裝這些零部件的步驟。
3）概念模型->設計模型：
汽車藍圖描繪出來后，就是樣建造零部件，以及生產汽車了。
從軟件開發角度而言，就是要把概念模型實例化，實例化的情況因使用的技術不同而不同，如選擇的軟件架構和框架、選擇的語言實現、中間件等等，不同的技術有不同的實現，這很容易理解。
?
經過上述3個步驟，就回答了前面的三個問題，就是貫穿各個階段，使用UML工具來加于輔助解決。
接下來介紹RUP：統一過程。
說明了RUP和UML的關系，是緊密的，但不是一回事兒，這很重要，RUP是一個軟件開發過程中的龐大知識體系，是內功，UML是語言，是招式或武器，RUP中大量使用UML，但UML并不是只能在RUP中使用。
好了，今天先到這里吧，后面繼續......
?
-顯示所有緩存 清除所有緩存)
)
