本文主要從系統架構中的模組化開始講解，本文講述的内容主要是我在工作和學習過程中的總結和經驗，不足之處還請大家多多批評指出，有更好的建議也可以留言
說明。本意主旨是為不熟悉系統架構模組化過程和不知道如何使用模組化工具，或者不熟悉如何根據需求去建立模型的角度出發，簡單的闡述了在系統架構的過程中我們應
該從什麼樣的角度出發去分析需求并且建立抽象模型。這應該說是架構師必備的技能。
本文由淺入深，本篇将簡單的介紹如何使用使用UML模組化中的各個結構圖與行為圖，去完成抽象模型的建立。
1、摘要。
2、本章内容。
3、模組化工具介紹及使用。
4、模組化中的抽象模型圖。
5、本質總結。
6、系列進度。
7、下篇預告。
介紹模組化工具之前，我們先來簡單介紹下模組化語言的定義。模組化語言就是基于一系列規則、符号、圖表、關鍵字的圖形化或文本語言。模組化語言的主要作用是對模
型的結構與行為進行描述。并且能夠将知識和資訊通過模型傳遞給熟悉該描述語言的人。
當今的模組化語言其實并不少，其中比較有規模的如下圖：
不過最流行、最常用的當屬UML模組化語言(Unified Modeling Language) 統一模組化語言。經過不斷的發展，目前UML已成為業界公認的标準的模組化語言。
我們先來了解下UML模組化語言的起源：
回顧20世紀晚期--準确地說是1997年，OMG組織（Object Management Group對象管理組織）釋出了統一模組化語言（Unified Modeling Language，
UML）。UML的目标之一就是為開發團隊提供标準通用的設計語言來開發和建構計算機應用。UML提出了一套IT專業人員期待多年的統一的标準模組化符号。通過使用
UML，這些人員能夠閱讀和交流系統架構和設計規劃--就像建築勞工多年來所使用的建築設計圖一樣。
到了21世紀--準确地說是2003年，UML已經獲得了業界的認同。在我所見過的專業人員的履歷中，75%都聲稱具備UML的知識。然而，在同絕大多數求職人員面
談之後，可以明顯地看出他們并不真正了解UML。通常地，他們将UML用作一個術語，或對UML一知半解。大家對UML缺乏了解的這種狀況，促進我撰寫這篇關于UML
模組化。當閱讀完本文時，您還不具備足夠的知識可以在履歷上聲稱自己掌握了UML，但是您已具有了進一步鑽研該語言的良好起點。
既然UML語言如此流行，本系列中也隻用UML語言來進行模組化，本系列中的後續章節也将基于UML模組化圖來完成相應的設計。
學習過UML語言的開發人員都知道UML分為以下幾類模型圖：
通過上圖我們知道UML的分類，分為結構型與行為型模組化圖形。下面的内容将詳細的講述每種模組化圖形的使用場景及如何使用。
我們先從行為型的模組化圖形來開始講起：
我想用例圖大家都應該基本上有所了解，隻要使用過UML模組化的除了基本的流程圖基本上大家都會的使用外，用例圖用過是最常見的一種模組化圖形。
用例圖中主要包含的元素：系統、參與者、用例、關系。
用例圖主要的應用場景：一般用例圖用來描述需求中的系統應具有的功能,系統參與者(使用者,維護者、外部系統或者使用者等)與系統如何互動進行一個模
型話的描述。
用例圖的目的：幫助開發團隊以一種可視化的方式了解系統的功能需求。
一般使用如下方式來進行操作：
是用來描述系統中的某個子產品與參與者的一次互動過程。
系統參與者與用例之間的具體關系通過如下連線标示：
這幾類不同的連線來辨別不同的用例之間或者用例與參與者或者2個參與者直接直接的關系。
UML定義了3類标準的關系：
第一種：包含，通過一條直線連結2個用例,是以是用例之間的關系連結，表述了箭頭的開始一端包含箭頭指向的一端的用例。
第二種：擴充，通過一個反向的直線來辨別某個用例擴充了另外一個用例的行為，一般情況下箭頭指向的用例即是被擴充的用例。
第三種：泛化，用來辨別具有同質關系的參與者與參與者或者用例與用例之間的關系，泛化類似繼承關系。箭頭指向的為父元素。
除了以上的3中關系還有一種未列在規範關系的我們把它叫做關聯關系。這種關系是用來描述用例與參與者直接的關系的。是通過一條直線來完成連結的，泛化關系
描述了連結的2個部分存在某種程度的傳遞。一般情況下，我們可以系統的功能情況分析出系統中的主動發和被動方。
如何使用用例圖:
第一步：先把系統按照功能進行劃分，比如一個簡單的内容管理系統。先把他細化，細化成多個子產品功能。每個子產品的功能相對獨立，但是可能又與另外一個有交
互。
第二步：把功能需求抽象,達到高内聚，低耦合的标準，然後分析出該子產品功能的參與者是什麼，例如使用者是誰？或者細分成角色,與該子產品互動還可能是資料庫？
等,把所有互動的對象分析出。
第三步：把系統子產品中的每個功能子產品看是否能再按照子功能進行細分，細分後形成具體的用例。
第四步：分析用例與參與者之間的關系，分析同質對象(參與者與參與者、用例與用例)之間的關系。
第五步：根據以上四步完成模組化。在模組化的過程如果發現某塊功能不清晰或者參與者不清晰，可重複前4步。
類圖也是UML模組化中最常用的一種結構圖，類圖用來标示系統的靜态結構。靜态結構是由類型及關系構成。
類圖表示不同的實體（人、事物和資料）如何彼此相關；換句話說，它顯示了系統的靜态結構。類圖可用于表示邏輯類，邏輯類通常就是業務人員所談及的事物種
類--搖滾樂隊、CD、廣播劇；或者貸款、住房抵押、汽車信貸以及利率。類圖還可用于表示實作類，實作類就是程式員處理的實體。實作類圖或許會與邏輯類圖顯示一
些相同的類。然而，實作類圖不會使用相同的屬性來描述，因為它很可能具有對諸如Vector和HashMap這種事物的引用。
類圖其實就是一個長方形，内部分成3個區域。每個區域的含義不同。
類圖中也有命名空間的概念，是通過包來實作的如果想定義該類在某個命名空間中，則在定義類名時按照如下類似格式标示
命名空間 :: 類名 [必須按照這樣的形式才可以]。
類圖中的有3類修飾符，每種修飾符标示的含義不同。
具體用法如下：
了解成具體的類代碼的格式如下：
public class Product
{
Public string ProductName;
public void GetProductLists(string sWhere)
{
//TODO….
}
}
如果在類圖中的屬性定義與函數成員的定義是斜體表示的話，則表名該成員是虛成員。
如果在類圖中的屬性定義與函數成員的定義是帶下劃線的話，則表名該成員是靜态成員。
當然這是最基本的類圖，還有一種特殊的，類圖支援參數化類型即是.NET中的特殊類型[泛型格式]标示。
具體的表示形式如：該符号在類的右上角有個長方形其中可輸入類型如上圖。
類圖中屬性包含的元素：
通路修飾符：Public、Protected、Private
特性/屬性名稱：特性/屬性名稱
類型：可以是自定義類型或者是系統類型。
預設值：即特性/屬性的預設值，如果有的話。
重複性：可以用來定義多個對象的集合，特性值中包含的對象個數。
類圖中操作包含的元素：
操作名稱：函數名稱
操作清單：函數的參數清單。
傳回值：函數的傳回值，如果有的話。
函數參數清單中的參數方向：
首先我們知道，我們在設計類的時候就是把獨立的功能放在一個類中，不同的類之間進行互動，那麼我們在類圖中如何去表述這樣的類之間的關系呢？
類圖直接的關系：
1、關聯關系：關聯辨別2個類直接存在關系。是通過一條線來表示，關聯關系中包含了2種特殊的關系：聚合群組合
聚合代表的2個類直接是has-a的關系，即部分與整體的關系，具體的圖示通過一條虛線帶有菱形箭頭，箭頭指向的方向即是整體的部分，代表該類包含另一部分。
組合舉例：組合關系的标示與聚合比較類似，唯一差別實心的菱形。
組合與聚合的差別：
在聚合關系中被包含對象可能不完全依賴容器對象，也就是說ProductName不完全依賴Product。如果Product對象銷毀，但是可能ProductName對象沒有被銷
毀。可以這麼想想産品的分類不會因為産品銷毀而不存在。
組合關系中則是比聚合的關聯程度更高,Product完全包含ProductName。如果銷毀Product時，那麼ProductName也一定被銷毀。産品從資料庫被删除了，那
麼與産品相關的的資料列屬性也被删除了，這裡隻是舉例子，可能不太合适。
泛化關系：存在2個類之間。一個類是另外一個類的子類，表示一個類是另外一個類的特例。
表示方法：通過一個帶有空的三角形箭頭的線段辨別，箭頭指向父類型。
依賴關系描述為：一個類型必須依靠另外一個類才能實作相應的功能。最簡單的了解方式：依賴注入中的構造函數注入。
具體的表示方法：一個帶有箭頭的虛線段。箭頭方向标示被依賴的類型。
本章主要是對UML有個簡單的介紹及詳細介紹了如何建構UML圖形中的用例圖與類圖。這是我們在模組化時常用的2類圖形。也是必須掌握的模組化圖形。
同時通過本質我們應該大腦中對UML有個新的認識，UML模組化可以讓我多個角度的去分析問題，然後不斷的改進設計，同時能很清晰的表達功能需求功能的分離群組合
關系。本文隻是簡單的抛磚引玉，不足之處，在所難免，請大家批評指出。六、系列進度。
1、系統架構師-基礎到企業應用架構系列之--開卷有益
2、系統架構師-基礎到企業應用架構-系統模組化[上篇]
3、系統架構師-基礎到企業應用架構-系統模組化[中篇](上)
4、系統架構師-基礎到企業應用架構-系統模組化[中篇](下)
5、系統架構師-基礎到企業應用架構-系統模組化[下篇]
不斷更新中(請持續關注…)
七、下篇預告。
下一篇中将介紹UML模組化過程中其他的比較常用的UML模組化圖形：順序圖、元件圖、狀态圖等。
本文轉自何戈洲部落格園部落格，原文連結：http://www.cnblogs.com/hegezhou_hot/archive/2010/09/10/1822887.html，如需轉載請自行聯系原作者