在學習UML建模的時候腹泌，我們還需要思考一個軟件模型從0->1這樣一個誕生的過程需要經(jīng)過什么，為什么模型需要這樣建，為什么要這樣輸出?建模的目的是幫助我們更好的理解面向對象的軟件開發(fā)和對軟件系統(tǒng)的整體有更深入和清晰的理解。

模型是論點，靜態(tài)圖是論據(jù)想际，動態(tài)圖是論證。建立什么模型溪厘，首先要先確定的是該項目該項目要采用什么樣的生命周期胡本。

今天要整理的是模型相關的知識,主要包括以下:

用例模型，是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型畸悬，它可以作為客戶和開發(fā)人員之間的契約侧甫，是需求工作流程的結果，可當作設計工作流程和測試工作流程的輸入使用傻昙。

之前關于用例我們有三個層次的解釋闺骚，關于用例模型同樣有三個不同的對應的區(qū)分:業(yè)務用例、概念用例妆档、系統(tǒng)用例僻爽。

統(tǒng)一過程是一種演進式的軟件過程，在整個產(chǎn)品生命周期之內充滿了許多小規(guī)模的迭代须板，而每一次迭代的開始幾乎都是從識別用例開始碰镜，從用例被實現(xiàn)而結束。

以上的三種用例模式分別是用于在軟件開發(fā)的不同周期階段發(fā)生作用的习瑰，業(yè)務用例模式用于識別和規(guī)定業(yè)務需求绪颖，概念模型用于分析和確認業(yè)務需求，而系統(tǒng)用例模式用來規(guī)定系統(tǒng)開發(fā)需求甜奄。這三者之間是漸漸精化的關系柠横。

一、業(yè)務用例模型

業(yè)務用例模型位于統(tǒng)一過程的先啟階段课兄，在業(yè)務建模的核心工作流中完成牍氛。需要明確一點，業(yè)務模型是業(yè)務范圍烟阐，建立的目的是為現(xiàn)存的業(yè)務和客戶預想中的真實業(yè)務建立模型搬俊，是為了理解客戶的業(yè)務紊扬，不能帶有計算機思考在里面。業(yè)務用例模型采用業(yè)務用例來繪制唉擂，表達業(yè)務的觀點餐屎。

業(yè)務用例場景:說明用例執(zhí)行的過程啤挎。
業(yè)務用例規(guī)約: 說明用例的使用者驻谆、目標卵凑、場景、相關業(yè)務規(guī)則胜臊、業(yè)務實體等勺卢。
業(yè)務用例規(guī)則: 說明客戶執(zhí)行業(yè)務用例必須遵循的法律、慣例象对、規(guī)定黑忱。
業(yè)務對象模型: 描述業(yè)務模型中關鍵的業(yè)務對象，以及如何貢獻于業(yè)務目標勒魔。
業(yè)務對象實現(xiàn)視圖: 將業(yè)務用例實現(xiàn)用實現(xiàn)關系連接到業(yè)務用例甫煞，每一個業(yè)務用例代表了業(yè)務用例目標的一種實現(xiàn)方式。
實現(xiàn)場景: 說明每一個業(yè)務用例實現(xiàn)的步驟冠绢。

二抚吠、概念用例模型

概念用例模式也位于先啟階段，是業(yè)務用例建模的一個子集弟胀。在統(tǒng)一過程中楷力，沒有強調概念用例的建立，一般來說業(yè)務用例的粒度很大孵户，描述時很粗略萧朝，而系統(tǒng)用例需要使用軟件開發(fā)的需要，所以會比較精細夏哭，而概念模型的建立是居于兩者之間的一個過渡检柬。我們使用它來分解業(yè)務復雜的業(yè)務模型。

概念用例視圖: 該視圖得到的概念用例用包含竖配、泛化何址、拓展關系連接到基本業(yè)務用例。表示這些來源以及他們服務于哪個或者哪些業(yè)務用例械念。
概念用例分析: 從模型中選出重要的業(yè)務用例場景集中起來头朱，進行分析如何實現(xiàn)。
分析類視圖: 分析類視圖繪制出從概念用例分析過程中抽象出來的分析類的靜態(tài)關系龄减。
分析場景: 使用分析類繪制對象交互圖项钮，從對象的角度去實現(xiàn)概念用例分析場景。

獲取概念用例:

可以觀察現(xiàn)有的業(yè)務場景，發(fā)現(xiàn)那些經(jīng)常出現(xiàn)的名稱烁巫，可能就是關鍵的概念用例署隘。

什么時候使用概念用例模型呢？一般來說亚隙，面臨的軟件規(guī)模很龐大磁餐，復雜，有7-8個泳道存在阿弃，或者說你想早點獲得系統(tǒng)原型诊霹，可以建立概念模型。如果業(yè)務領域規(guī)模很小渣淳，業(yè)務用例粒度較小脾还，簡單，就不比使用概念模型了入愧。

三鄙漏、系統(tǒng)用例模型

系統(tǒng)用例模型用于統(tǒng)一過程中先啟階段的后期以及精化階段的早期。實際上棺蛛，系統(tǒng)建模就是我們說的需求獲取怔蚌。也可以直接省略系統(tǒng)，叫用例模型這說法了旁赊。

用例規(guī)約：用例規(guī)約應采用文檔形式描述參與者如何啟動和終止用例彤恶，參與者如何使用用例完成目標钞钙，用例的執(zhí)行事件流，相應的規(guī)則等內容声离。
補充規(guī)約:補充規(guī)約應說明與用例相關的非功能性需求芒炼。例如響應時間、可靠性术徊、可用性本刽。
業(yè)務規(guī)則、用例實現(xiàn)赠涮、用例場景子寓、分析對象跟以上的內容差不多。

如何獲取系統(tǒng)用例呢笋除？

如果建立系統(tǒng)用例時斜友，已經(jīng)存在業(yè)務用例了，可以從業(yè)務用例中推導出來垃它。因為推導系統(tǒng)用例的方法是分析業(yè)務用例場景鲜屏，尤其是活動圖烹看。因為采用活動圖繪制業(yè)務用例場景時將業(yè)務主角和業(yè)務工人作為泳道，因此特別方便觀察他們的職責（活動）洛史。系統(tǒng)用例可以從這些職責里抽取出來惯殊。 一 開始，可以簡單地把每個泳道中的活動都作為一 個用例也殖，以泳道作為參與者土思，把它們繪制出來。然后考慮以下問題：

在觀察一些用例時忆嗜，如果參與者不使用計算機來使用這個用例己儒，則可以排除。還有如果使用計算機實現(xiàn)代價很大霎褐，可以考慮排除址愿。

觀察剩下的候選用例该镣，分析參與者使用它們的目的冻璃。目的通常可以從參與者關心的結果看出來损合。雖然候選用例可能有不同的名字省艳，但是如果它們的結果是相同的或相似的，應當考慮合并嫁审。

例如雖然審批A文件跋炕、審查B文件是兩個不同的候選用例，但是它們的結果都導致某業(yè)務得到批準律适，那么可以考慮合并為一 個審查文件用例辐烂。合井后，審批 A 文件和審查 B 文件是括曆 件用例的泛化捂贿。

抽象用例

觀察剩下的候選用例纠修，分析參與者使用它們的方式。使用方式可以從用例場景里歸納出來厂僧。如查詢A報表和杳詢B報表是兩個不同的目的扣草，有不同的結果。但是它們選擇查詢條件的過程是一樣的颜屠，可以考慮抽象出一 個設置查詢條件的用例辰妙，查詢 A 報表和查詢 B 報表都包含這個用例。

補充用例

向用例模型中加入那些與業(yè)務實現(xiàn)無關但是對系統(tǒng)運行必須的非業(yè)務性需求甫窟，例如使用管理用戶賬號密浑、備份系統(tǒng)數(shù)據(jù)等。

如果你的分析工作中包含有概念用例模型粗井，那么充分利用它尔破。概念用例會為系統(tǒng)用例的獲取提供很好的參考敬锐。

四、領域模型

從領域模型的基本概念來講呆瞻，這里說的領域模型與領域驅動設計的定義是一致的台夺，都是通過抽象現(xiàn)實世界當中的事物，以概念化的手段痴脾，以模型的方式定義颤介。基本概念一致赞赖，但是在《大象UML》這本書中滚朵，講述的定義領域模型的方法以及領域模型定義出來以后的實際用途與《領域驅動設計》一書的確是不同的。

《領域驅動設計》一書倡導的領域建模實際上是一 種由內而外前域、先內功后招式的方法辕近。先追求“真理與規(guī)律 ”，再用它來實現(xiàn) “外在的表現(xiàn)”匿垄。它要求建模團隊里有資深的領域專家移宅，在領域專家的帶領下，從業(yè)務需求當中找出那些體現(xiàn)了業(yè)務本質的事物椿疗、規(guī)則和結構漏峰，并為之建模，目標是定義出業(yè)務運行的規(guī)律和原理届榄，在此基礎上再去搭建具體應用程序的設計浅乔。這種方法實質上是先搭建業(yè)務架構，再實現(xiàn)具體業(yè)務铝条。

這里講的領域模型建模方法是使用用例驅動的模式靖苇，先明確業(yè)務，通過對用例場景班缰、業(yè)務對象模型來找出某一個問題的解決方案贤壁。遵循的是用例驅動方法 ( UDO ) , 而不是領域驅動方法 ( DDD ) 。關于用力驅動和領域驅動的取舍鲁捏，我就不做更多深入芯砸。

領域模型是采用業(yè)務對象建立起來的 一 種模型，我們把領域模型當中使用到的業(yè)務對象稱為領域類给梅。一般來說假丧，領域類有三種典型的形式：

? 業(yè)務對象實體，表示業(yè)務中使用到或產(chǎn)生的東西动羽。如定單包帚、賬號、合同等运吓。
? 系統(tǒng)需要處理的現(xiàn)實世界中的對象和概念渴邦。如商品疯趟、買家、賣家等谋梭。
? 將要發(fā)生或已經(jīng)發(fā)生的事件信峻。如購買、撤單瓮床、付費等盹舞。
領域模型研究的是高于特定業(yè)務場景的一般規(guī)律，從所有業(yè)務對象用例場景對象交互模型當中抽象出來更高級別的業(yè)務對象模型隘庄，它表示了對業(yè)務對象結構和交互的一般規(guī)律踢步，揭示了業(yè)務運行的本質和核心。

實際工作中丑掺，建立好的領域模型是很難的获印，我們必須對整個業(yè)務領域了解的非常透徹才可能，要求建模者具有深厚的行業(yè)知識背景街州，或者具高超的抽象能力兼丰，井且遍歷了絕大部分的業(yè)務用例場景。

對于較小的項目菇肃，或者業(yè)務比較簡單的項目地粪，我們并不需要建立完整的業(yè)務領域模型。但總有某項業(yè)務或某個對象相對比較復雜琐谤，這時我們可以僅僅針對該業(yè)務或對象來建立 一 個小型的局部領域模型。

五玩敏、分析模型

分析類用于獲取系統(tǒng)中的主要的職責蔟斗忌，他們代表系統(tǒng)的原型類，是系統(tǒng)必須處理的主要抽象概念旺聚。分析模型使用分析類來建立系統(tǒng)原型织阳。

在統(tǒng)一過程中，分析類被定義為一種可選的模型砰粹，是從需求向設計模型轉化的過渡唧躲。

如何使用分析模型:

六爽航、軟件架構和框架模型

從以前的軟件發(fā)展到現(xiàn)在蚓让，基本會采用現(xiàn)成的乾忱、開源或自發(fā)的軟件框架，也越來越忠實軟件架構的建立历极。

統(tǒng)一過程是以架構為中心的開發(fā)模式窄瘟，如果說用例代表了一個軟件項目對需求的定義和理解，架構就代表了對系統(tǒng)的定義和理解了趟卸。軟件架構在較高的抽象上寞肖，將系統(tǒng)規(guī)劃為一些獨立的邏輯部件，各司其職衰腌。

現(xiàn)實中新蟆，很多人把架構和框架搞混，框架是針對某個問題領域的通用解決方案右蕊，它通常集成了最佳實踐和可復用的基礎架構琼稻，可以減少開發(fā)工作量、指導和規(guī)范作用饶囚。

架構是系統(tǒng)藍圖帕翻，是大樓的結構、外觀和功能性設計萝风，需要考慮抗震嘀掸，防火等功能」娑瑁框架是建設大樓中一些成熟的工藝的應用睬塌，比如樓梯成型等等⌒颍框架是解決方案揩晴，加速和提高系統(tǒng)質量的半成品。

軟件架構分為兩者: 業(yè)務架構和技術架構贪磺。

業(yè)務架構

業(yè)務架構是在先啟階段完成的硫兰，在精化階段得以改進，目標是為業(yè)務領域建立一個而維護和拓展的邏輯結構寒锚，描述業(yè)務的構成劫映。

業(yè)務架構不僅僅是使用一張圖來表示那么簡單泳赋，需要寫一份文檔:

描述每一個領域包的職責、與其他領域包的關系腮郊，例如門戶網(wǎng)站負責什么摹蘑，與購物中心如何交互。
對一些重要的領域轧飞，例如購物中心衅鹿，使用領域模型來解釋他如何運作撒踪。
下圖可以看到業(yè)務架構與核心模型的關系。用例模型大渤、領域模型所描述的業(yè)務流程制妄，通過抽象可得到業(yè)務架構。

軟件架構

軟件架構需要在業(yè)務架構的基礎上引入計算機環(huán)境泵三。軟件環(huán)境和硬件環(huán)境耕捞。軟件架構需要說明業(yè)務架構如何分布在計算機環(huán)境中，得以進行烫幕。

一個典型的軟件架構包含兩個視角俺抽，廣度視角和深度視角。

關于架構和框架這里不做深入描述弛饭。

七、設計模型

設計模型就是我們所熟知的詳細設計萍歉，采用設計類繪制侣颂，它主要考慮實現(xiàn)語言、架構枪孩、框架憔晒、編程模型、規(guī)范销凑，目標是有程序邏輯來實現(xiàn)用例丛晌。

待續(xù)。斗幼。