UML和我們之前學習的軟體工程密不可分，兩者強強聯合，為軟體的開發奠定了重要的基礎。UML圖和文件把整個系統的巨集觀和微觀，一一展現在我們的面前。

　　寫軟體文件就像建造大樓前的圖紙一樣重要，沒有合理的規劃、分析，僅僅憑空想象，是不足以完成這一浩大的工程的。

一、插入文件的UML圖——必選項

　　用例圖存在於軟工文件的需求分析階段，《軟體需求說明書》中有一項是需求規定，它的子專案對功能的規定，可以放置我們的用例圖。

ＰＳ：用例圖的作用就是從使用者的角度描述系統靜態功能。

　　類圖存在於《概要設計說明書》，功能需求與程式關係可以放置類圖。

ＰＳ：類圖主要用來描述系統所包含的類、類的內部結構和類之間的關係。

　　類圖、包圖、時序圖存在於《詳細設計說明書》中，程式系統的結構可以先放置一個巨集觀的包圖，然後在放置類圖。在設計實現可以放置細化的類圖，並標註出返回值和引數。流程圖可以被時序圖完全替換。

ＰＳ：包圖是非正式的ＵＭＬ圖，但是它卻能夠把用例或類之類模型元件組織為組。是需求、設計的高階概述，並從邏輯上讓複雜的圖模組化。時序圖通過描述物件之間傳送訊息的時間順序顯示多個物件之間的動態協作。時序圖中的物件源自於類、用例。是直接從用例圖和類圖中拖拽過來的。

   物件圖就是類圖的例項化。類圖之於物件圖，就好像人類之於張三。

二、插入文件的UML圖——可選項

　　還有一些圖也可以放在詳細設計裡面，但是要根據系統設計的必要，擇優而取。

　　活動圖就是變體的流程圖，但是它比流程圖更高階一些，它能夠進行併發活動而流程圖不能。另外流程圖是程式導向的思想，活動圖是物件導向的思想。

　　狀態圖描述一個物件在其生命週期中的動態行為，表現為一個物件所經歷的狀態序列，引起狀態轉移的事件，及因狀態轉移而伴隨的動作。　　

　　時序圖和協作圖相似，就是側重點不同。時序圖側重於物件間訊息傳遞時間的先後，協作圖側重於物件間互動過程和物件間聯絡。

　　構件圖、部署圖存在於系統的實現階段。

三、機房收費系統——查漏補缺

　　結合了之前的軟工文件，還有如今的UML圖，發現自己還是有很多可改進的地方，暫時記錄在這裡，下次機房的時候會更加註意這些細節。

　　軟體需求：原型圖（沒畫）、IPO圖（沒畫）、用例圖。

　　詳細：包圖、類圖、時序圖。包圖要注意兩個包之間的關係，下圖代表Ａ要呼叫Ｂ中的方法。所以劃分包的時候，一定要考慮呼叫關係。

　　類圖抽象方式可以總體分成兩種：１．根據資料庫表抽象。２．根據功能抽象。以　　

　　時序圖我畫的也很不標準，以下是應該修改的地方：

　

四、總結

　　一圖勝過萬語千言。ＵＭＬ圖真的是人類智慧的結晶，直觀的圖形讓我們對整個軟體系統瞭然於胸。一開始畫圖的時候雖然有些磕磕絆絆，但是後來，隨著查資料的增多，對它的瞭解也深刻了許多。

　　要有全域性觀。九種圖並不是單獨存在的個體，畫圖的時候一定要把它們畫到一個檔案裡面，這樣才不會把它們的關係割裂開。另外對比學習真的很重要，比如順序圖、協作圖，活動圖、流程圖等等，因為特殊性，才由了它存在的價值。就像人一樣，因為不同，所以每個人都有值得我們學習的地方。

　　要堅持。當你堅持做一件事情的時候，你才會發現，什麼是柳暗花明。　　

　　

希望我的部落格能夠對大家有所幫助，也希望大家能夠給我提出改進的建議！