系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模2
一、上章回顧
上篇文章《系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模1》主要簡單的介紹了建模中使用的標(biāo)準(zhǔn)建模語言UML的相關(guān)內(nèi)容,包括用例圖與類圖的使用方法及如何建模。相信大家對UML建模語言已經(jīng)有了初步的認
識,還請大家謹(jǐn)記UML不同的建模圖形的用處。比如,用例圖主要用來描述系統(tǒng)的功能需求。類圖主要用來描述實體間的關(guān)系。謹(jǐn)記這些就可以幫助我們在系統(tǒng)架構(gòu)的
過程中深入的分析。
首先向大家道歉,上篇中有部分描述錯誤的地方,可能對大家造成一定的錯誤引導(dǎo)。
這是上篇給出的圖,我描述的是組合關(guān)系。
特別更正為:
這是正確的結(jié)果。箭頭指向聚合類。描述的信息并無任何錯誤。希望能對大家指正。
二、摘要
本文主要從系統(tǒng)架構(gòu)中的建模開始講解,本文講述的內(nèi)容主要是我在工作和學(xué)習(xí)過程中的總結(jié)和經(jīng)驗,不足之處還請大家多多批評指出,有更好的建議也可以留言
說明。本意主旨是為不熟悉系統(tǒng)架構(gòu)建模過程和不知道如何使用建模工具,或者不熟悉如何根據(jù)需求去建立模型的角度出發(fā),簡單的闡述了在系統(tǒng)架構(gòu)的過程中我們應(yīng)
該從什么樣的角度出發(fā)去分析需求并且建立抽象模型。這應(yīng)該說是架構(gòu)師必備的技能。
本文由淺入深,本篇將簡單的介紹如何使用使用UML建模中的各個結(jié)構(gòu)圖與行為圖,去完成抽象模型的建立。
本文主要講解以下幾個建模圖形:順序圖、組件圖、狀態(tài)圖、活動圖、部署圖。當(dāng)然本文也只是講述了基本理論介紹及如何設(shè)計使用,系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)
用架構(gòu)-系統(tǒng)建模[下篇] 將會詳細的講解通過具體實例講解如何使用這些已經(jīng)介紹的抽象模型圖形去描述。
三、本章內(nèi)容
1、上章回顧。
2、摘要。
3、本章內(nèi)容。
4、建模中的抽象模型圖。
5、本章總結(jié)。
6、系列進度。
7、參考文獻。
8、下篇預(yù)告。
四、建模中的抽象模型圖。
1、順序圖。
介紹
順序圖也稱序列圖,主要用來系統(tǒng)中的某個流程的詳細步驟。順序圖能夠給出流程中一系列對象的交互順序。通過順序圖可以讓我們更好的了解如何實現(xiàn)某個用例
的方法。我們知道用例圖用來描述系統(tǒng)的功能需求。而順序圖清晰的描述了某個用例也就是系統(tǒng)功能的的實現(xiàn)方法。
詳解
在順序圖中包含的元素:
對象:用來標(biāo)識流程中的詳細步驟中的對象。
活動條:用來標(biāo)識當(dāng)前對象是活動的,如果想表示某個對象是活動的,那么必須使用一個虛線+活動圖的形式來構(gòu)建。
例如我們現(xiàn)在要標(biāo)示一個簡單的做公交車的刷卡流程:
IC卡刷卡操作。
相關(guān)解釋說明:
公交卡,首先放在刷卡終端上,終端讀取卡中的余額信息,然后刷卡終端與終端中的扣款程序?qū)ο蠼换ィ劭畛绦蚋鶕?jù)讀取的余額信息,與刷卡終端中的固定刷卡
金額對比,如果當(dāng)前IC卡的余額大雨刷卡終端的固定金額則,扣除金額,并且返回一個消息,提示刷卡成功的操作。
途中的實線表示調(diào)用被調(diào)用對象的方法,虛線表示當(dāng)被調(diào)用對象執(zhí)行成功后,返回的虛線上表示返回值的邏輯名稱,這樣可以提高了可讀性。
在公交卡與活動條之間,應(yīng)有一個虛線鏈接。
在上圖中我們使用了活動條,活動條作為生命線的一部分。我們并沒有定義對象的創(chuàng)建和銷毀,因此我們來看UML建模語言提供的描述對象的創(chuàng)建與銷毀實例。
上圖中的X符號的圖標(biāo)代表的時候?qū)ο蟮匿N毀。創(chuàng)建對象通過new來創(chuàng)建,上圖中,我用中文描述“創(chuàng)建對象”來完成對象的創(chuàng)建,那么在生命線下的的X符號代
表銷毀對象,從內(nèi)存中移除對象。當(dāng)然這個對象的銷毀對不同的開發(fā)語言有這不同的處理方式。C++中的銷毀對象,必須調(diào)用析構(gòu)函數(shù)來銷毀對象。C#與JAVA語言中
則只是說明當(dāng)前需要銷毀的對象沒有被其他的對象引用,那么這類語言編譯器提供垃圾回收器來完成回收。
注意:當(dāng)某個對象引用了另外一個對象,該對象有責(zé)任銷毀被引用對象并且必須顯示銷毀該被引用對象時,那么必須要顯示的發(fā)送被引用對象銷毀的通知消息。白
話文來說就是顯示的調(diào)用被引用對象的銷毀方法。
順序途中的同步與異步。
順序圖中的同步與異步與我們平時書寫代碼中的同步與異步的解釋意思差不多。這里不過多解釋,通過圖例說明:
客戶去餐廳吃飯,首先要點餐,必須等待點餐完了才能上菜。意思就是可以這樣簡單描述。A簡單調(diào)用B方
法,必須等待,等到B方法執(zhí)行完畢后,繼續(xù)執(zhí)行。
函數(shù)A調(diào)用函數(shù)B,如果B需要的時間特別長,那么此時A可以去繼續(xù)執(zhí)行做其他的事情比如做和函
數(shù)C交互,等B函數(shù)執(zhí)行完了,只需要回調(diào)通知A,B函數(shù)執(zhí)行完了即可。在函數(shù)調(diào)用中的術(shù)語就是回調(diào)。
UML建模語言中同步與異步消息的標(biāo)識格式:
UML提供了一些順序圖的高級功能:例如可以通過順序圖實現(xiàn)流程的控制。具體的實現(xiàn)工具是通過UML提出的交互框來實現(xiàn)流程條件的控制。
交互框其實就是定義了流程控制圖中的控制邏輯,基于交互框定義流程執(zhí)行的條件。如果滿足這個條件,那么則執(zhí)行交互框中已定義好的順序步驟。否則不做任何
操作。交互框中除了定義流程控制的條件外,還有一些自己特殊的操作符,具體的操作符及其作用,如下列表:
每個關(guān)鍵字代表的含義都有相應(yīng)的描述。大家應(yīng)該都可以看明白,上述的所有含義都是針對交互框來說的。
總結(jié)
如果在系統(tǒng)功能中有特殊需求,那么順序圖中的交互框是可以支持嵌套的。嵌套交互框的話,會提高順序圖的復(fù)雜度,降低可讀性。因此我們設(shè)計時的原則盡量把復(fù)
雜的流程拆分成幾個簡單的,分別繪制順序圖來完成相應(yīng)步驟。
2、組件圖。
簡介
眾所周知,組件圖是用來描述系統(tǒng)中的各組件之間的關(guān)系。首先我們必須知道組件的定義是什么,然后組件之間有哪些關(guān)系。理清楚這些,我們在以后的設(shè)計中才能
派上用場。UML語言對組件的定義已發(fā)生了巨大變化。在之前的版本里面,UML如下定義組件的:
UML1.1語言中對組件的描述:把某個文件或者可以運行的程序稱之為組件。但是我們知道,UML出現(xiàn)組件圖以前,組件一般用來描述COM組件或者其他的組件,因此造成沖突,所以隨著后續(xù)UML語言的發(fā)布,修改了原有的含義。
UML2.x語言中對組件的的描述:組件是獨立的,是運行在一個系統(tǒng)中的封裝單位,提供了一系列的服務(wù)。
通過上述UML語言中的變遷,目前的理解是:一個系統(tǒng),可以隨意更換系統(tǒng)中的某個組建。而不會影響系統(tǒng)的運行。這可以理解為類似,大家熟悉IOC容器的都應(yīng)該
知道,運行在IOC容器中的對象,可以看作組件,那么替換其中的提供某一服務(wù)的組件,只要滿足該組件服務(wù)的相關(guān)契約就能自動完成替換。而不會影響系統(tǒng)的運行。
每個組件都封裝了一些特殊的行為,實現(xiàn)了特定的服務(wù)。
組件之間的關(guān)系有哪些呢?我們通過下圖來看看,組件直接可能存在的關(guān)系:
組件直接的關(guān)系基本上來說就這2種。下面會舉例區(qū)別2中關(guān)系。
組件圖提供的服務(wù):組件圖為系統(tǒng)架構(gòu)師提供了解決方案的自然形式。組件圖允許架構(gòu)師驗證系統(tǒng)的必需功能是由組件來完成的。組件是可以復(fù)用的。
詳解
組件圖中包含的元素:
下面我們分別講解:
(1)、組件:我們知道組件是組件圖中最基本的組成元素,組件上面已經(jīng)講述了組件的定義。這里就不在多介紹,組件圖組成的基本單位即組件。
(2)、容器:可以為多個組件提供服務(wù)的管理容器,容器中的組件相互交互。
(3)、包:可以看作一個子系統(tǒng),其實也可以看作是特殊的組件。
(4)、約束:用于定義接口規(guī)范。
(5)、給組件圖中的相應(yīng)元素添加相應(yīng)注釋信息。
組件上可以定義自己的接口。例如上圖,人這個組件提供了2個接口。Thinking與Sleep接口。
組件關(guān)系的建模:
我們來看看組件之間的關(guān)系的表示,根據(jù)上面講解的組件的關(guān)系有依賴和泛化,參考類圖中的依賴和泛化。
依賴關(guān)系,標(biāo)識一個組件依賴另外一個組件,如果被依賴組件無法正常運行,那么該組件也無法運行。
泛化關(guān)系。標(biāo)識一個組件與其他多個組件的關(guān)系為繼承關(guān)系。
總結(jié):
通過上面的學(xué)習(xí)我們知道:組件圖主要是為系統(tǒng)架構(gòu)師對整個系統(tǒng)的解決方案的自然形成,可以通過組件圖的形式把系統(tǒng)的大體功能進行區(qū)分和設(shè)計。通過組件圖把
系統(tǒng)功能進行抽象和分離。然后通過順序圖把功能流程細分成多個步驟,然后通過類圖去構(gòu)建每個流程步驟中的每個類應(yīng)具有的個方法。***形成一個完整的設(shè)計文
檔。
3、狀態(tài)圖。
簡介
狀態(tài)圖其實是針對一個對象(實體、組件其他元素等)來說的。主要是描述了,對象的行為如何改變狀態(tài)的反映。我們研究UML狀態(tài)圖的目的就是為了搞清楚,對
象狀態(tài)的變化與行為的關(guān)系。建模對象的實時行為。創(chuàng)建狀態(tài)圖的條件:當(dāng)對象行為的改變與狀態(tài)有關(guān)的時候才創(chuàng)建狀態(tài)圖。狀態(tài)圖反映了對象如何改變狀態(tài)相應(yīng)行為
的變化和展示對象的生命周期的創(chuàng)建和刪除的全過程。
詳細
狀態(tài)圖可建模的對象:
用例:可以描述用例圖中的某個用例狀態(tài)的變化。
類:可以描述某個類的狀態(tài)的變化。
子系統(tǒng):可以描述某個子系統(tǒng)中狀態(tài)的變化。
整個系統(tǒng):類似(WF)工作流中的流程,每個節(jié)點其實就相當(dāng)于一個狀態(tài)。
上面簡單的繪制了一個去餐廳吃飯的狀態(tài)變化,每個狀態(tài)變化的行為都有描述,當(dāng)然我這里只是簡單的舉例說明狀態(tài)圖的變化,并沒有詳細分析的所有可能狀態(tài)都畫出來。
具體的狀態(tài)還請大家自己練習(xí)畫出來,此處只是簡單的舉例說明。
狀態(tài)圖中的元素:
狀態(tài)標(biāo)記:
狀態(tài)圖中可以標(biāo)識一個或多個初始狀態(tài),也可以包含一個或多個結(jié)束狀態(tài)。
狀態(tài)圖中不同狀態(tài)之間的關(guān)系:
轉(zhuǎn)移關(guān)系,用來描述對象的狀態(tài)從一個狀態(tài)轉(zhuǎn)移到另外一個狀態(tài)的處理流,箭頭指向轉(zhuǎn)移后的狀態(tài)。
狀態(tài)圖中提供了類似流程圖中的判定的功能元素:決策點。
通過元素決策點來完成:
決策點,用來決策跳向不同的狀態(tài)。
具體用例如下:
就是起到了一個決策的作用。這里不在復(fù)述。
狀態(tài)圖中的同步:
狀態(tài)圖中的同步主要是為了說明并發(fā)工作流的分岔和聯(lián)合。下圖描述了狀態(tài)圖中的同步條:
初始狀態(tài)進入到同步條中分岔同步執(zhí)行操作A與B,分別進入A狀態(tài)、B狀態(tài),然后分別執(zhí)行A1,B1聯(lián)合進入到結(jié)束狀態(tài)。
一個對象可以通過同步操作同事?lián)碛卸鄠€狀態(tài)。有時候一個對象還可以擁有不同層次的多個狀態(tài)。當(dāng)單個狀態(tài)擁有獨立的附加子狀態(tài)時就可以在狀態(tài)圖中使用層次結(jié)
構(gòu)的狀態(tài)。
組合狀態(tài)就是這樣的比較復(fù)雜的狀態(tài)結(jié)構(gòu)圖,有時候我們需要把一個復(fù)雜的狀態(tài)細化成多個子狀態(tài)的合成,那么這個復(fù)雜的狀態(tài)就可以叫組合狀態(tài)。
下面舉例說明:
組合狀態(tài)B,也即復(fù)合狀態(tài)B,內(nèi)部可能有比較復(fù)雜的狀態(tài)(C-D狀態(tài))。這種只是組合狀態(tài)B中存在單個狀態(tài)變化流程的情況,還可能組合狀態(tài)B中包含更多的狀態(tài)流。
那么我們就要用如下的狀態(tài)圖完成:
上圖中1代表的是下單的流程,2代表付款流程。
總結(jié)
通過上面的學(xué)習(xí)我想大家對狀態(tài)圖有了一定的了解,那么我們來總結(jié)下,如何建模狀態(tài)圖。
***步:我們知道建模狀態(tài)圖,首先需要抽象出來要建模的對象。
第二步:我們基于這個對象分析出該對象具有的所有狀態(tài)及發(fā)生狀態(tài)改變的行為。
第三步:標(biāo)識每個對象狀態(tài)的起始狀態(tài)與結(jié)束狀態(tài)。
第四步:開始創(chuàng)建對象的狀態(tài)圖,分析是否有必要創(chuàng)建復(fù)雜的組合狀態(tài)。
系統(tǒng)架構(gòu)設(shè)計的過程中,我們首先要分析出哪些對象需要使用狀態(tài)圖來描述。如果某個對象具有復(fù)雜的行為,那么可以使用活動圖來建模比使用狀態(tài)圖更適合。每個
狀態(tài)圖必須至少有一個起始狀態(tài)和結(jié)束狀態(tài)。并且詳細的分析對象發(fā)生狀態(tài)改變的行為。從某個狀態(tài)轉(zhuǎn)移到另外一個狀態(tài)的行為是什么。在某些情況下,如果對象的某
個狀態(tài)無法清晰的表達時,可以通過創(chuàng)建組合狀態(tài)來進一步細化該狀態(tài),這樣能更清晰的表達對象的狀態(tài)變化。
五、本章總結(jié)。
本章主要講述了UML建模圖形中的順序圖、狀態(tài)圖、組件圖。并且分析了什么情況下使用各種UML建模圖進行建模。并且通過簡單實例說明如何使用。等UML所有的
建模圖形介紹完畢后,我將針對如何我目前遇到一些問題進行分析講解,如何遇到功能需求進行功能的分離及建模。希望大家多多提出寶貴意見。
六、系列進度。
1、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)系列之--開卷有益
2、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[上篇]
3、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[中篇](上)
4、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[中篇](下)
5、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[下篇]
不斷更新中(請持續(xù)關(guān)注…)
七、參考文獻。
http://www.uml.org--官方UML Web站點。
http://www.rational.com/uml/resources/documentation/index.jsp--提供具體UML規(guī)范的多種不同版本。
http://www.rational.com/rose--關(guān)于IBM Rational Rose ?這個商業(yè)UML建模工具的信息。
http://www.rational.com/xde--關(guān)于IBM Rational XDE?這個與IBM的Eclipse開發(fā)平臺緊密集成的商業(yè)UML建模工具的信息。
http://argouml.tigris.org--關(guān)于Argo UML這個用Java構(gòu)建的開放源代碼UML建模工具的信息。
http://uml.sourceforge.net/index.php--關(guān)于Umbrello UML Modeller這個用于KDE的開放源代碼UMl建模工具的信息。
八、下篇預(yù)告。
下一篇將把本章沒有講述完畢的活動圖與部署圖講解完畢,其他的不常用的建模圖形可能只是簡單的講解,不會像這幾篇文章那樣具有說明的講解。由于本人才疏
學(xué)淺,可能對UML建模的認識不夠深入,還請各位多多支出寶貴意見,我將在后續(xù)的文章中不斷的改進和學(xué)習(xí),將自己掌握的內(nèi)容寫出來,一方面是幫助不熟悉UML的
朋友盡快的上手,另外也可以讓自己加深印象。
作者:CallHot-何戈洲
出處:http://www.cnblogs.com/hegezhou_hot/
關(guān)于作者:專注于微軟平臺項目架構(gòu)、管理和企業(yè)解決方案。熟悉設(shè)計模式、極限編程、架構(gòu)設(shè)計、敏捷開發(fā)和項目管理。現(xiàn)主要從事WinForm、ASP.NET、等方面的項目開發(fā)、架構(gòu)、管理工作。如有問題或建議,請多多賜教!
【編輯推薦】
- 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之開卷有益
- 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模1
- 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模2
- 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模3
- 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模4