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