充滿生活的味道！

今日學習版本管理軟件——SVN，我在以前的工作中正是使用SVN做為版本管理的。使團隊合作更加輕松、方便、快捷。

SVN在當今軟件項目開發中占的比重較大，在外國的軟件行業中幾乎全部使用SVN進行版本管理的。在國內的大中型企業也在使用，可能存在部分小型公司沒有使用。

在當今開源的世界中SVN的應用屢見不鮮，今日的課程就是學習如何假設SVN與CVS服務器，還有SVN與CVS的客戶端使用。Eclipse的經典更不用說，她真是一個和諧的大家庭！

SVN和CVS的配置在互聯網，或其官網“http://www.subversion.org.cn/ ”已經非常全面細至了。

我們平時自己寫個項目時，都將代碼備份到自己的本地其他邏輯空間中，定期也將代碼發到自己的郵箱中備份。但Google為我們提供了免費的代碼托管“http://code.google.com/intl/zh-CN/projecthosting/ ”使用起來十分方便！

我十分喜歡Google！

UML，是我在整套課程中比較期盼的內容。雖說是對UML的期盼，更是對CMM標準化項目開發的期盼。軟件工程的概念是參照建筑工程等流程提出來的，與建筑工程相同，軟件工程需要可行性分析、需求分析、概要設計、詳細設計...。建筑需要圖紙，軟件也需要圖紙，設計軟件圖紙的工具就是UML（統一建模語言）。

到傳智播客學習，了解和運用軟件工程也是我的重要目標之一。因為我受夠了沒有經過軟件工程標準化開發，而直接編碼所帶來的痛苦。今日的課程內容比較簡單，上課的氛圍比較輕松。有機會聽徐老師談一談國內的軟件公司現狀。CMM是印度人總結出來的被國際公認并普遍使用的軟件工程規范，最高等級應該是CMM5。但十分遺憾的是中國的真正意義上的CMM5等級的這種軟件企業并不多，為什么？要搞一個CMM5的認證來，與我們社會中想搞一個學位證書的概念差不多。可想這種卑劣的文化！殘害著自己的民族。在這個社會里一切都不會超過人情世故。

我對這種標準化的工程流程十分關注，國內在這方面做的比較好的是大連。但大連是中國最大的軟件外包產業，幾乎全在為日本工作。所以這種CMM5的高層（設計層）都是由日本人來完成的，中國的“打字員”只需要按照日本人設計的詳細文檔，把代碼敲到電腦里并測試通過就可以了。我們知道編碼只是軟件開發中的一小部分而已，非常慚愧！

不在其位莫思其事！

老徐說給我們提供UML的課程是為了讓大家在以后的工作中能看懂UML圖。UML的畫圖工具很簡單，難在你用豐富的經驗畫出優美的軟件框架和詳細設計來。

一、軟件工程

簡要學習一下軟件工程，軟件工程是由軟件危機引起的。軟件危機就引起了瀑布模型，從瀑布模型又升級出來RUP來。

一幅美麗的用來形容軟件工程問題的漫畫：

1.瀑布模型

模型的特點是：

1). 各階段間具有順序性和依賴性： 后一階段工作必須在前一階段工作完成后才能進行。

2). 質量保證機制的依賴性。即每一步都必須循序漸進，及早消除故障隱患，保證本階段的工作的質量，從而達到保證整體軟件質量的目的。

3). 推遲實現原則。前一階段工作做的越細， 越扎實，后一階段工作進行的就越順利，強調”寧慢求好”。因此，各階段工作總是一拖再拖，致使整個工期推遲實現。顯然瀑布模型不能滿足呈爆炸狀增長的社會應用需求。

2. 統一軟件開發過程：RUP(Rational Unified Process，RUP)

一個通用的軟件流程框架， 以架構為中心， 用例驅動的迭代化開發流程。 RUP 是從幾千個軟件項目的實踐經驗中總結出來的， 對于實際的項目具有很強的指導意義。RUP 用二維坐標來描述。 橫軸通過時間來組織， 是過程展開的生命周期特征， 體現開發過程的動態結構；縱軸以內容來組織， 體現開發過程的靜態結構。

有關瀑布模型和RUP的資料網上有很多，在次就不多做總結了。

三、UML

UML(United Modeling Language，統一建模語言)：是一種基于面向對象的可視化建模語言。

UML采用了一組形象化的圖形(如類圖)符號作為建模語言，使用這些符號可以形象地描述系統的各個方面。

UML通過建立圖形之間的各種關系(如類與類之間的關系)來描述模型。

UML中有二類圖（共10種）：

1).靜態模型圖：描述系統的靜態結構

類圖、對象圖、包圖、組件圖、部署圖

2).動態模型圖：描述系統行為的各個方面

用例圖、時序圖、協作圖、狀態圖、活動圖。

其中藍色為重點圖例，其他的圖例比較少用。

在畫圖之前我們有必要復習一下類的四種關系：

u 關聯關系(association)

u 依賴關系(dependency)

u 泛化關系(generalization)

u 實現關系(realization)

我們在hibernate中有學習到這四種關系，原本我以為那只是在hibernate中使用。沒想到在UML中也有，其實這四種關系應該是軟件工程中的規范了。那hiberante也是使用了這種規范進行相關開發的，這樣可以促進hibernate路線的正確性，這太好了！

我們使用的是IBM的RationalRoseUML設計工具，使用工具具體圖畫的操作就不說明了。

1.用例圖

用例圖(Use Case Diagram)： 也稱為用戶模型圖， 是從軟件需求分析到最終實現的第一步， 它是從客戶的角度來描述系統功能。

用例圖包含 3 個基本組件：

1) 參與者(Actor)： 與系統打交道的人或其他系統即使用該系統的人或事物。在UML中參與者用人形圖標表示。

2) 用例(Use Case)： 代表系統的某項完整的功能。在UML中使用一個橢圓來表示。

3) 關系： 定義用例之間的關系：

a) 泛化關系：表示同一業務目的(父用例)的不同技術實現(各個子用例)。 在UML中，用例泛化用一個三角箭頭從子用例指向父用例。以下是某購物網站為用戶提供不同的支付方式。

b) 包含關系：一個用例可以包含其他用例具有的行為， 并把它包含的用例行為作為自身行為的一部分。 在 UML 中包含關系用虛線箭頭加 “<<include>>”， 箭頭指向被包含的用例。

c) 擴展關系：如果在完成某個功能的時候偶爾會執行另外一個功能， 則用擴展關系表示。在 UML 中擴展關系用虛線箭頭加 “<<extend>>”， 箭頭指向被擴展的用例。

藍線部分為：泛化關系。紅線部分為：包含關系。綠線部分為：泛化關系。

2.類圖

類圖是面向對象系統建模中最常用的圖，是定義其他圖的基礎。

類圖主要是用來顯示系統中的類， 接口以及它們之間的關系。

類圖包含的主要元素有類， 接口和關系。 其中關系有關聯關系， 泛化關系， 依賴關系和實現關系。 在類圖中也可以包含注釋和約束。

這里的關系十分重要，我們來一一看一下。

1). 泛化關系（繼承關系）：用來表示類與類, 接口與接口之間的繼承關系. 泛化關系有時也稱為”is a kind of”關系。

2). 實現關系：用來表示類與接口之間的實現關系。

3).依賴關系：比如我們上班需要交通工具，交通工具可以是公交車、私家車、電動車或自行車，步行也可以。這就是一依賴關系，使用某一個對象或對象的方法來完成一種功能。但與它不存在固定對應關系。

4).關聯關系：對于兩個相對獨立的系統，當一個系統的實例與另一個系統的一些特定實例存在固定的對應關系時，這兩個系統之間為關聯關系。

多對多雙向關聯，可以自動生成代碼哦：

關聯關系中有一個難點，上面的圖是多對多雙向關聯。我也可以映射出一對多和多對一的意向關聯。但一對多關系中還有聚合關系和組成關系。

聚合關系：是更強形式的關聯。強調部分和整體邏輯結構，但不強調生命周期。對應的屬性具有get/set方法。例如計算機包含鍵盤和鼠標，但如果計算機不在了鍵盤和鼠標可以存。我們也可以為計算機換鍵盤和鼠標：

UML中組成關系：是更強形式的聚合，不僅強調部分和整體，而且還強調生命周期。僅有get方法。比如人有頭和手，如果主體不在了，那么部分肯定也不存在了。也不能更換。

5).導航性：

導航性表示可從源類的任何對象到目標類的一個或多個對象遍歷。 即：給定源類的一個對象， 可以得到目標類的所有對象。 可以在關聯關系上加上箭頭表示導航方向。

只在一個方向上可以導航的關聯稱為單向關聯，用一個帶箭頭的方向表示; 在兩個方向上都可以導航的關聯稱為雙向關聯， 用一條沒有箭頭的實線表示。

3. 時序圖

時序圖用于描述對象之間的傳遞消息的時間順序， 即用例中的行為順序。

當執行一個用例時， 時序圖中的每條消息對應了一個類操作或者引起轉換的觸發事件。

在 UML 中， 時序圖表示為一個二維的關系圖， 其中， 縱軸是時間軸， 時間延豎線向下延伸。 橫軸代表在協作中各個獨立的對象。 當對象存在時， 生命線用一條虛線表示， 消息用從一個對象的生命線到另一個對象的生命線的箭頭表示。 箭頭以時間的順序在圖中上下排列。

時序圖中的基本概念：

對象：時序圖中對象使用矩形表示，并且對象名稱下有下劃線。將對象置于時序圖的頂部說明在交互開始時對象就已經存在了。如果對象的位置不在頂部，表示對象是在交互的過程中被創建的。

生命線：生命線是一條垂直的虛線。表示時序圖中的對象在一段生命周期內的存在。每個對象底部中心的位置都帶有生命線。

消息：兩個對象之間的單路通信。從發送方指向接收方。在時序圖中很少使用返回消息。

激活：時序圖可以描述對象的激活和鈍化。激活表示該對象被占用以完成某個任務。鈍化指對象處于空閑狀態，等待消息。在 UML 中，對象的激活時將對象的生命線拓寬為矩形來表示的。矩形稱為計劃條或控制期。對象就是在激活條的頂部被激活的。對象在完成自己的工作后被鈍化。

對象的創建和銷毀：在時序圖中， 對象的默認位置是在圖的頂部。這說明對象在交互開始之前就已經存在了。如果對象是在交互過程中創建的，那么就應該將對象放到中間部分。如果要撤銷一個對象，在其生命線終止點處放置“ X”符號。

5.活動圖

活動圖就是流程圖，但在UML工具中可以加入泳道：

6.狀態圖

通過建立對象的生存周期模型來描述對象隨時間變化的動態行為。比如hibernate中持久化對象的三種狀態：臨時狀態、持久化狀態、游離狀態。

狀態圖的基本概念：

狀態：用圓角矩形表示。狀態名稱表示狀態的名字，通常用字符串表示。一個狀態的名稱在狀態圖所在的上下文中應該是唯一的。

轉換：用帶箭頭的直線表示。一端連著源狀態，一端連著目標狀態。

初始狀態：每個狀態圖都有一個初始狀態。此狀態代表狀態圖的起始位置。初始狀態只能作為轉換的源，不能作為轉換的目標，并且在狀態圖中只能有一個。初始狀態用一個實心圓表示。

終止狀態：模型元素的最后狀態，是一個狀態圖的終止點。終止狀態在一個狀態圖中可以有多個。

7．協作圖、對象圖、包圖

不畫了，用處不大且非常簡單。

8.組件圖

組件圖用來建立系統中各組件之間的關系，各組件通過功能組織在一起。

Javabean，ejb，jsp都是組件。在UML中，組件使用在左側有兩個小矩形的大矩形來表示。

組件圖可以用來設計系統的整體構架：

9.部署圖

部署圖用來幫助開發者了解軟件中的各個組件駐留在什么硬件位置，以及這些硬件之間的交互關系。

節點：用來表示一種硬件，可以是打印機，計算機等。節點的標記符號是一個三維框，在框的左上方包含了節點的名稱。

通信關聯：節點通過通信關聯建立彼此的關系，采用從節點到節點繪制實線來表示關聯。

一下子搞出來這么多東西，這么一看UML貫穿軟件設計的各個階段。讓人感覺很好！

一定要學好軟件工程，努力在工作中總結經驗！