UML:
Unified Modeling Language (UML)又稱統一建模語言或標准建模語言，是始於1997年一個OMG標准，它是一個支持模型化和軟件系統開發的圖形化語言，為軟件開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。
UML規范用來描述建模的概念有，類、對象、關聯、職責、行為、接口、用例、包、順序、協作，以及狀態
UML可以輔助我們分析和設計復雜的系統，它用於幫助軟件開發人員進行思考和記錄思路的結果；
uml本身是一套符號的規定，就像數學符號和化學符號一樣，之所以出現這些符號定義，是因為這些符號背后對應着一套思想和方法，這些符號用於幫助描述這套思想和方法的，這些符號是由這套思想和方法催生的。要學uml，就是要借助這些符號來掌握背后的思想和方法，這些符號雖然必須掌握，但它遠不如它背后對應的思想和方法重要。
必須熟練掌握了某種面向對象的編程語言和跟着實施了若干個軟件項目，才適合學習uml和理解uml中的一些內容，才會有好的學習效果。很難想象一個沒有在鐵路工地上工作過的人，怎么去設計鐵路！！！ UML解決編碼前的設計問題，而不解決編碼過程的實施問題，我們前面學習的各種編程技術是解決編碼過程的實施，必須有了這些基礎才能理解和運用UML。
UML的特點:
UML(統一建模語言): 是一種基於面向對象的可視化建模語言.
UML 本身定義了一套圖形符號，采用這些符號(如類圖)作為建模語言, 使用這些符號可以形象地描述系統的各個方面,它用於幫助軟件開發人員進行思考和記錄思路的結果。
UML 通過建立圖形之間的各種關系(如類與類之間的關系)來描述模型關系。
UML解決編碼前的設計問題，而不解決編碼過程的實施問題，我們前面學習的各種編程技術是解決編碼過程的實施，必須有了這些基礎才能理解和運用UML。
通用性
可視性
分析設計專用語言，凌駕於所有開發語言之上
業界的最佳實踐和成功經驗
面向對象的語義
UML不能做什么？
是一種描述語言，不能直接用於驗證
只是一種表示方式，而不是建模方法
UML要結合一種程序開發方法
軟件工程:
1968年在聯邦德國召開的北大西洋公約軟件可靠性會議(NATO)上,首次提出"軟件工程"的概念,提出了在軟件生產中采用工程化的方法,采用一系列科學的、現代化的方法技術來開發軟件.這種工程化的思想貫穿到軟件開發和維護的全過程.
軟件生命周期: 軟件的產生直到報廢的生命周期
軟件生命周期內有：問題定義, 可行性分析, 總體描述, 系統設計,編碼, 調試和測試, 驗收與運行, 維護升級到廢棄等階段
1、問題的定義及規划(可行性分析報告和軟件開發計划): 此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性。
2、需求分析(需求分析說明書和初步的用戶手冊): 在確定軟件開發可行的情況下，對軟件需要實現的各功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發項目的成功打下良好的基礎。
3、軟件設計(概要設計、詳細設計): 此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計一般分為總體設計和詳細設計。
4、程序編碼(提交源程序及清單): 此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標准的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。
5、軟件測試(提交軟件維護測試報告): 在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題並加以糾正。整個測試過程分單元測試（白盒）、集成測試（黑盒，功能測試、強度性能測試）以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計划並嚴格按照測試計划進行測試，以減少測試的隨意性。
6、運行維護（提交軟件維護報告): 軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成並投入使后，由於多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。
軟件開發流程:
1,瀑布模型:
特點：
1). 各階段間具有順序性和依賴性: 后一階段工作，必須在前一階段工作完成后才能進行。
2). 質量保證機制的依賴性。即每一步都必須循序漸進，及早消除故障隱患，保證本階段的工作的質量，從而達到保證整體軟件質量的目的。
3). 推遲實現原則。前一階段工作做的越細, 越扎實，后一階段工作進行的就越順利，強調”寧慢求好”。因此，各階段工作總是一拖再拖，致使整個工期推遲實現。顯然瀑布模型不能滿足呈爆炸狀增長的社會應用需求
2,螺旋迭代:
螺旋模型沿着螺線進行若干次迭代，圖中的四個象限代表了以下活動：
（1） 制定計划：確定軟件目標，選定實施方案，弄清項目開發的限制條件；
（2） 風險分析：分析評估所選方案，考慮如何識別和消除風險；
（3） 實施工程：實施軟件開發和驗證；
（4） 客戶評估：評價開發工作，提出修正建議，制定下一步計划。
螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟件的重用，有助於將軟件質量作為特殊目標融入產品開發之中。
但是，螺旋模型也有一定的限制條件，具體如下：
（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟件開發。
（2） 如果執行風險分析將大大影響項目的利潤，那么進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟件項目。
（3） 軟件開發人員應該擅長尋找可能的風險，准確地分析風險，否則將會帶來更大的風險 一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然后從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最后，評價該階段的結果，並設計下一個階段。
極限編程（Extreme Programming，XP）
TDD (Test-Driven Development):以不斷的測試推動代碼的開發，既簡化了代碼，又保證了軟件質量
“Extreme”（極限）是指，對比傳統的項目開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它XP所不提倡的，則一概忽略（如開發前期的整體設計等）。一個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，能夠做到一周40小時工作制而不拖延項目進度。
40小時工作制：
結對編程：技術是一個非常簡單和直觀的概念：兩位程序員肩並肩地坐在同一台電腦前合作完成同一個設計、同一個算法、同一段代碼或者同一組測試。
結對編程的好處是，一個人編寫代碼時另一個人在思考。思考者的頭腦中保持總體概念，不僅手頭問題的這一段，而且還有XP指導方針。例如，如果兩個人都在工作，就不太可能會有其中一個說“我不想首先寫測試”而離開。如果編碼者遇到障礙，他們就交換位置。如果兩個人都遇到障礙，他們的討論可能被在這個區域工作的其他人聽到，可能給出幫助。這種結對方式，使事情順暢、有章可循。也許更重要的是，他能使程序設計更具有社交性和娛樂性。
敏捷開發:是一種以人為核心、迭代、循序漸進的開發方法.
在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。
RUP
統一軟件開發過程(Rational Unified Process,RUP): 一個通用的軟件流程框架, 以架構為中心, 用例驅動的迭代化開發流程. RUP 是從幾千個軟件項目的實踐經驗中總結出來的, 對於實際的項目具有很強的指導意義.
RUP 用二維坐標來描述. 橫軸通過時間來組織, 是過程展開的生命周期特征, 體現開發過程的動態結構; 縱軸以內容來組織, 體現開發過程的靜態結構.
軟件生命周期的四個階段：初始、細化、構造、交付；
初始: “獲得項目的基礎”. 該階段的主要人員是項目經理和系統設計師. 所要完成的主要任務包括對系統的可行性分析; 創建基本的需求; 識別系統的關鍵任務.
細化: 主要目標是創建可執行構件基線; 精化風險評估; 捕捉大部分的系統功能需求用例; 為構造階段創建詳細需求. 該階段並不是要創建可執行的系統, 而是展現用戶所期望的需求.
構建: 完成所有的需求, 分析和設計. 該階段的制品將演化成最終系統
交付: 將完整的系統部署到用戶所處的環境中.
9個核心工作流.=6個核心過程工作流+ 3個核心支持工作流 ；
盡管6個核心過程工作流類似於傳統瀑布模型中的幾個階段, 但迭代過程中的階段是完全不同的, 這些工作流在整個生命周期中一次又一次被訪問.
9個核心工作流在項目中輪流被使用, 在每一次迭代中以不同的重點和強度重復.
UML的圖形分類：
1，用例圖：用例建模的最主要功能就是用來表達系統的功能性需求或行為,規范系統的邊際；
2，類圖：用於描述系統中的對象類本身的組成和對象類之間的各種靜態關系；
3，領域模型圖：領域模型(domain model),概念模塊,領域對象模型、分析對象模型、在開始項目分析時都會創建領域模型；
4，活動圖：活動圖本質上就是流程圖,它描述了為了完成某一個目標需要做的活動以及這些活動的執行順序；
5，狀態圖：用來描述一個特定對象的所有可能的狀態，以及由於各種事件而引起狀態之間的變化和轉移。一般使用狀態圖描述業務實體對象；
6，時序圖：時序圖（Sequence Diagram）是強調消息時間順序的交互圖。時序圖描述類系統中類和類之間的交互，它將這些交互建模成消息交換。時序圖是一個模型，用於描述對象組如何隨着時間在某些行為方面進行協作。
7，部署圖：部署圖用來幫助讀者了解軟件中的各個組件駐留在什么硬件位置，以及這些硬件之間的交互關系。
用例建模是UML建模的一部分，用例建模的最主要功能就是用來表達系統的功能性需求或行為。
1,參與者（Actor）：參與者不是特指人，是指系統以外的，在使用系統或與系統交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是其他系統等等。需要注意的是，參與者不是指人或事物本身，而是表示人或事物當時所扮演的角色。參與者在畫圖中用簡筆人物畫來表示;
2,用例是是系統為參與者提供的功能。對於對用例的命名，我們可以給用例取一個簡單、描述性的名稱，一般為帶有動作性的詞。用例在畫圖中用橢圓來表示，橢圓下面附上用例的名稱：
要求：能看懂用例圖即可；
用例：用例是文本形式的場景描述，是一種通過用戶的使用場景來獲取需求的技術。編寫用例時要避免使用技術術語，而應該用最終用戶或者領域專家的語言。用例一般是由軟件開發者和最終用戶共同創作的。
區別用例和用例圖。
用例的三個重要概念：參與者，場景，系統邊界
創建用例圖流程：
1.找出系統涉眾發現和定義涉眾(先詢問客戶的公司有哪些部門,部門里面有不同的職位:角色)
2.畫定業務邊界
3.獲取用例
4.繪制用例場景圖
5,編寫用例描述文檔；
6.繪制業務實體模型（領域模型）
7.繪制詞匯表
用例圖只是簡單地用圖描述了一下系統，但對於每個用例，我們還需要有詳細的說明，這樣就可以讓別人對這個系統有一個更加詳細的了解，這時我們就需要寫用例描述。
對於用例描述的內容，一般沒有硬性規定的格式，但一些必須或者重要的內容還是必須要寫進用例描述里面的。用例描述一般包括：簡要描述（說明）、前置（前提）條件、基本事件流、其他事件流、異常事件流、后置（事后）條件等等。下面說說各個部分的意思：
簡要描述：對用例的角色、目的的簡要描述；
前置條件：執行用例之前系統必須要處於的狀態，或者要滿足的條件；
基本事件流：描述該用例的基本流程，指每個流程都“正常”運作時所發生的事情，沒有任何備選流和異常流，而只有最有可能發生的事件流；
其他事件流（擴展點）：表示這個行為或流程是可選的或備選的，並不是總要執行它們；
異常事件流：表示發生了某些非正常的事情所要執行的流程；
后置條件：用例一旦執行后系統所處的狀態；
類圖:
用於描述系統中的對象類本身的組成和對象類之間的各種靜態關系。
類之間的關系：泛化（繼承）、依賴、關聯、聚合與組合
依賴關系:
關聯關系：
聚合關系：
聚合關系（Aggregation）表示的是整體和部分的關系，整體與部分可以分開。聚合關系是關聯關系的特例，所以他具有關聯的導航性與多重性。
使用帶空心菱形的實線來表示：
組合關系:
也是整體與部分的關系，但是整體與部分不可以分開。
組合關系使用實心菱形：
繼承關系:
泛化關系實際上就是繼承關系，他是依賴關系的特例
使用空心的三角形：
活動圖;
在UML里,活動圖本質上就是流程圖,它描述系統中事物或對象的變化流程。
開始狀態：一個活動圖一定有一個且只有一個開始狀態，開始狀態用一個實心圓表示；
結束狀態：一個活動圖必須有至少一個結束狀態，可以有多個結束狀態（正常結束狀態和分支流程結束狀態）；
活動：代表一個動作；
活動流：代表活動（流程）的運行方向；
分支：代表流程中的判斷或者選擇；
分叉和匯合：分叉代表流程中並行執行的流程；匯合代表並行執行的流程的匯總；
泳道：泳道可以規划出參與活動的各個角色；
時序圖（Sequence Diagram）是強調消息時間順序的交互圖。時序圖描述系統中類和類之間的交互，它將這些交互建模成消息交換。時序圖是一個模型，用於描述對象組如何隨着時間在某些行為方面進行協作。
時序圖是一種強調消息時序的交互圖，他由活動者（Actor）、對象（Object）、消息（Message）、生命線（Lifeline）和控制焦點（Focus of control）組成。在UML中，對象表示為一個矩形，其中對象名稱標有下划線；消息在時序圖中由有標記的箭頭表示；生命線由虛線表示，控制焦點由薄薄的矩形表示(也稱可為Activation Bar “活動條”)。
狀態圖：用來描述一個特定對象的所有可能的狀態，以及由於各種事件而引起狀態之間的變化和轉移。
狀態圖的要素：開始狀態/狀態/事件/轉移/結束狀態