UML和模式應(yīng)用中常用術(shù)語有哪些

這篇文章給大家分享的是有關(guān)UML和模式應(yīng)用中常用術(shù)語有哪些的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

領(lǐng)域建模
如果采用敏捷建模方法,創(chuàng)建領(lǐng)域模型的目的是為了快速理解和溝通大致的關(guān)鍵概念,***不是目的.
如果我們認為某概念類X不是現(xiàn)實世界中的數(shù)字或文本,那么X可能是概念類而不是屬性.
例如Store應(yīng)該是Sale的屬性還是單獨的概念類
在現(xiàn)實世界中,商店不會被認為是數(shù)字或文本,這一術(shù)語表示的是合法的實體,組織和占據(jù)空間的事物,因此Store應(yīng)該是概念類.

關(guān)聯(lián)(關(guān)系)的大部分將作為導航和可見性路徑在軟件中加以實現(xiàn),但是,領(lǐng)域模型不是數(shù)據(jù)模型,添加關(guān)聯(lián)是為了突出我們對重要關(guān)系的大致理解,而非記錄對象或數(shù)據(jù)結(jié)構(gòu).
以"類名-動詞短語-類名"的格式為關(guān)聯(lián)命名,其中的動詞短語構(gòu)成了可讀的和有意義的順序.
諸如"擁有"或"使用"這樣簡單關(guān)聯(lián)名稱通常是拙劣的,因為這種名稱不會增強我們對領(lǐng)域的理解.

通俗的說,大部分屬性類型應(yīng)該是簡單數(shù)據(jù)類型,比如數(shù)字和布爾.通常屬性的類型不應(yīng)該是復雜的領(lǐng)域概念.
應(yīng)該通過關(guān)聯(lián)而不是屬性來表示概念類之間的關(guān)系.

順序圖
UML和模式應(yīng)用的順序圖應(yīng)該為每個用例的主成功場景,以及頻繁發(fā)生的或復雜的替代常見繪制順序圖.
在對軟件應(yīng)用將如何工作進行詳細設(shè)計之前,***將其行為作為"黑盒"來調(diào)查和定義,系統(tǒng)行為描述的是系統(tǒng)做什么,而無需解釋如何做.
系統(tǒng)時間應(yīng)該在意圖的抽象級別而非物理的輸入輸出設(shè)備級別來描述,比如enterItem要優(yōu)于scan,因為前者即捕獲了操作的意圖,又保留了抽象性,而無需涉及到使用什么樣的接口來捕獲系統(tǒng)事件.系統(tǒng)事件的名稱以動詞開始,這樣可以提高清晰程度,因為這樣可以強調(diào)這些事件是命令或請求.

GRASP
RDD是思考OO軟件設(shè)計的一般性隱喻.把軟件對象想象成具有某種職責的人,他要與其他人協(xié)作以完成工作.RDD使我們把OO設(shè)計看作是有職責對象進行協(xié)作的共同體.

控制器
在正常情況,控制器應(yīng)該把需要完成的工作委派給其他的對象.控制器只是協(xié)調(diào)或控制這些活動,本身不完成大量工作.

高類聚
UML和模式應(yīng)用中高類聚模式是對現(xiàn)實世界的類比,顯而易見,如果一個人承擔了過多不相關(guān)的工作,特別是本應(yīng)該委派給別人的工作,那么此人一定沒有很高的工作效率.
"不要和陌生人說話"
該約束限制了你應(yīng)該在方法里給哪些對象發(fā)送消息,它要求在方法里只應(yīng)該給以下對象發(fā)送消息:
this對象
方法的參數(shù)
this的屬性
作為this屬性的集合中的元素
在方法中創(chuàng)建的對象
其意圖是避免客戶與間接對象和對象之間的對象連接產(chǎn)生耦合
直接對象是客戶的熟人,間接對象是陌生人,客戶應(yīng)該和熟人講話,而避免和陌生人講話.

架構(gòu)分析
變化點和進化點
變化點:當前現(xiàn)有系統(tǒng)或需求中的變化之處
進化點:現(xiàn)有需求中不存在,但可能在將來發(fā)生,推測性的變化點.
決定在何處花費精力進行必要的設(shè)計,預防將來可能的變化,這是架構(gòu)設(shè)計師的藝術(shù)

架構(gòu)分析關(guān)注的四個方面:
1)特別關(guān)注非慣性的需求,包括對應(yīng)用的業(yè)務(wù)或者市場環(huán)境的熟悉.同時,功能性需求也不能忽略;它提供了處理這些架構(gòu)因素的上下文,更進一步,識別功能性需求的可變性對架構(gòu)分析也至關(guān)重要
2)涉及系統(tǒng)級別的,大尺度的,涉及面廣的問題.解決這些問題通常涉及到大尺度或者基礎(chǔ)的設(shè)計決策.
3)對相互依賴的關(guān)聯(lián)的權(quán)衡,例如改善安全性可能會影響到實行效率和可用性,這些決策大都會影響成本.
4)對可選方案的規(guī)劃和評估.一個熟練的架構(gòu)師既可以提供構(gòu)建新系統(tǒng)的解決方案,也可以對中備選方案進行評估.
架構(gòu)分析指的是在功能需求的上下文中識別和解決非功能性需求.

異常
給一個異常命名,這個名字要能夠描述這個異常為什么被拋出,而不是要描述拋出者.這樣做,能夠使程序員更容易理解問題,并且突出了眾多異常的相似之處的本質(zhì)

感謝各位的閱讀！關(guān)于“UML和模式應(yīng)用中常用術(shù)語有哪些”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！