本節(jié)向大家介紹一下有關(guān)UML和模式應(yīng)用方面的知識(shí)，主要包括領(lǐng)域建模，順序圖，高類聚和架構(gòu)分析等內(nèi)容，相信通過本節(jié)的介紹大家對(duì)UML和模式應(yīng)用一定有所了解。下面是有關(guān)UML和模式應(yīng)用中常用術(shù)語。

領(lǐng)域建模
　　如果采用敏捷建模方法,創(chuàng)建領(lǐng)域模型的目的是為了快速理解和溝通大致的關(guān)鍵概念,***不是目的.　　
　　如果我們認(rèn)為某概念類X不是現(xiàn)實(shí)世界中的數(shù)字或文本,那么X可能是概念類而不是屬性.
　　例如Store應(yīng)該是Sale的屬性還是單獨(dú)的概念類
　　在現(xiàn)實(shí)世界中,商店不會(huì)被認(rèn)為是數(shù)字或文本,這一術(shù)語表示的是合法的實(shí)體,組織和占據(jù)空間的事物,因此Store應(yīng)該是概念類.
　　
　　關(guān)聯(lián)(關(guān)系)的大部分將作為導(dǎo)航和可見性路徑在軟件中加以實(shí)現(xiàn),但是,領(lǐng)域模型不是數(shù)據(jù)模型,添加關(guān)聯(lián)是為了突出我們對(duì)重要關(guān)系的大致理解,而非記錄對(duì)象或數(shù)據(jù)結(jié)構(gòu).　　
　　以"類名-動(dòng)詞短語-類名"的格式為關(guān)聯(lián)命名,其中的動(dòng)詞短語構(gòu)成了可讀的和有意義的順序.
　　諸如"擁有"或"使用"這樣簡單關(guān)聯(lián)名稱通常是拙劣的,因?yàn)檫@種名稱不會(huì)增強(qiáng)我們對(duì)領(lǐng)域的理解.
　　
　　通俗的說,大部分屬性類型應(yīng)該是簡單數(shù)據(jù)類型,比如數(shù)字和布爾.通常屬性的類型不應(yīng)該是復(fù)雜的領(lǐng)域概念.　　
　　應(yīng)該通過關(guān)聯(lián)而不是屬性來表示概念類之間的關(guān)系.
　　　　
順序圖
　　UML和模式應(yīng)用的順序圖應(yīng)該為每個(gè)用例的主成功場景,以及頻繁發(fā)生的或復(fù)雜的替代常見繪制順序圖.
　　在對(duì)軟件應(yīng)用將如何工作進(jìn)行詳細(xì)設(shè)計(jì)之前,***將其行為作為"黑盒"來調(diào)查和定義,系統(tǒng)行為描述的是系統(tǒng)做什么,而無需解釋如何做.
　　系統(tǒng)時(shí)間應(yīng)該在意圖的抽象級(jí)別而非物理的輸入輸出設(shè)備級(jí)別來描述,比如enterItem要優(yōu)于scan,因?yàn)榍罢呒床东@了操作的意圖,又保留了抽象性,而無需涉及到使用什么樣的接口來捕獲系統(tǒng)事件.系統(tǒng)事件的名稱以動(dòng)詞開始,這樣可以提高清晰程度,因?yàn)檫@樣可以強(qiáng)調(diào)這些事件是命令或請(qǐng)求.
　　　　
GRASP
　　RDD是思考OO軟件設(shè)計(jì)的一般性隱喻.把軟件對(duì)象想象成具有某種職責(zé)的人,他要與其他人協(xié)作以完成工作.RDD使我們把OO設(shè)計(jì)看作是有職責(zé)對(duì)象進(jìn)行協(xié)作的共同體.
　　　　
控制器
　　在正常情況,控制器應(yīng)該把需要完成的工作委派給其他的對(duì)象.控制器只是協(xié)調(diào)或控制這些活動(dòng),本身不完成大量工作.
　　　　
高類聚
　　UML和模式應(yīng)用中高類聚模式是對(duì)現(xiàn)實(shí)世界的類比,顯而易見,如果一個(gè)人承擔(dān)了過多不相關(guān)的工作,特別是本應(yīng)該委派給別人的工作,那么此人一定沒有很高的工作效率.　　
　　"不要和陌生人說話"
　　該約束限制了你應(yīng)該在方法里給哪些對(duì)象發(fā)送消息,它要求在方法里只應(yīng)該給以下對(duì)象發(fā)送消息:
　　this對(duì)象
　　方法的參數(shù)
　　this的屬性
　　作為this屬性的集合中的元素
　　在方法中創(chuàng)建的對(duì)象
　　其意圖是避免客戶與間接對(duì)象和對(duì)象之間的對(duì)象連接產(chǎn)生耦合
　　直接對(duì)象是客戶的熟人,間接對(duì)象是陌生人,客戶應(yīng)該和熟人講話,而避免和陌生人講話.
　　　　
架構(gòu)分析
　　變化點(diǎn)和進(jìn)化點(diǎn)
　　變化點(diǎn):當(dāng)前現(xiàn)有系統(tǒng)或需求中的變化之處
　　進(jìn)化點(diǎn):現(xiàn)有需求中不存在,但可能在將來發(fā)生,推測性的變化點(diǎn).　　
　　決定在何處花費(fèi)精力進(jìn)行必要的設(shè)計(jì),預(yù)防將來可能的變化,這是架構(gòu)設(shè)計(jì)師的藝術(shù)
　　　　
架構(gòu)分析關(guān)注的四個(gè)方面:
　　1)特別關(guān)注非慣性的需求,包括對(duì)應(yīng)用的業(yè)務(wù)或者市場環(huán)境的熟悉.同時(shí),功能性需求也不能忽略;它提供了處理這些架構(gòu)因素的上下文,更進(jìn)一步,識(shí)別功能性需求的可變性對(duì)架構(gòu)分析也至關(guān)重要
　　2)涉及系統(tǒng)級(jí)別的,大尺度的,涉及面廣的問題.解決這些問題通常涉及到大尺度或者基礎(chǔ)的設(shè)計(jì)決策.
　　3)對(duì)相互依賴的關(guān)聯(lián)的權(quán)衡,例如改善安全性可能會(huì)影響到實(shí)行效率和可用性,這些決策大都會(huì)影響成本.
　　4)對(duì)可選方案的規(guī)劃和評(píng)估.一個(gè)熟練的架構(gòu)師既可以提供構(gòu)建新系統(tǒng)的解決方案,也可以對(duì)中備選方案進(jìn)行評(píng)估.
　　架構(gòu)分析指的是在功能需求的上下文中識(shí)別和解決非功能性需求.
　　
　　異常
　　給一個(gè)異常命名,這個(gè)名字要能夠描述這個(gè)異常為什么被拋出,而不是要描述拋出者.這樣做,能夠使程序員更容易理解問題,并且突出了眾多異常的相似之處的本質(zhì).本節(jié)關(guān)于UML和模式應(yīng)用方面的內(nèi)容介紹到這里，謝謝關(guān)注。

【編輯推薦】

1. 專家推薦 UML入門經(jīng)典
2. UML面向?qū)ο笾R(shí)入門
3. 統(tǒng)一建模語言(UML) 版本 2.0
4. UML學(xué)習(xí)手冊(cè)新手必備
5. UML面向?qū)ο蠼ＶR(shí)簡介