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