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