UML和模式應用5:細化階段(8)---邏輯架構和UML包圖


1.前言

  • 本章是從面向分析的工作過度到軟件設計
  • 典型的OO系統設計的基礎是若干架構層,如UI層、應用邏輯(領域)層
  • 本章簡要考察邏輯分層架構和相關UML表示法

2.邏輯架構和層

  • 邏輯架構

邏輯架構是軟件類的宏觀組織結構,它將軟件類組織成包(命名空間)、子系統和層,並未決定如何在不同的操作系統進程或網絡中物理的計算機上對這些元素進行部署

對類、包或子系統的粗粒度的分組,具有對系統主要方面加以內聚的職責。較高層可以調用較低層的服務,OO系統通常包括的層:

用戶界面

應用邏輯和領域對象,表示領域概念的軟件對象

技術服務,提供支持性技術服務的常用對象和子系統,例如數據庫接口或錯誤日志,這些服務通常獨立於應用,可以在多個層復用

注:1. 在嚴格的分層架構中(如網絡協議棧),層只能調用與其相鄰的下層的服務;

       在寬松的分層架構中(如信息系統),較高層可以調用其下任何層的服務。

      2. 邏輯架構並非一定要組織成層,但這種方式極為常見

3.軟件架構

  • 軟件架構是一組重要決策,涉及軟件系統的組織,對結構元素及組成系統所使用接口的選擇,結構和行為元素到規模更大子系統的組成,以及指導該組織結構的架構風格
  • 軟件架構的共同主題:必須與宏觀事物有關-----動機、約束、組織、模式、職責和系統之連接的重要思想

4.UML包圖

  • UML包圖常用於描述系統的邏輯架構-----層、子系統、包(就java語言)
  • 層可以建模為UML包
  • UML包圖提供了組織元素的方式,可以組織任何事物:類、其他包、用例
  • UML的依賴線可顯示包之間的依賴性(耦合),以便開發者能夠看到系統內大型事物之間的耦合,依賴線使用帶箭頭的虛線,箭頭指向被依賴的包
  • UML包代表命名空間,兩個不同的包內可以有名稱相同的類名
  • UML包內可以嵌套其它UML包,如java::util::Date

5.准則:使用層進行設計

 

圖 信息系統邏輯架構中常見的層

  • 使用層的本質思想

將系統的大型邏輯結構組織為獨立的、職責相關的離散層,具有清晰、內聚的關注分離。較低的層是低級別和一般性服務,較高的層是與應用相關的

協作和耦合是從較高層到較低層進行的,要避免從較低層到較高層的耦合

  • 使用層有助於解決的問題

源碼的變更波及整個系統---大部分系統是高度耦合的

應用邏輯與用戶界面交織在一起,因此應用邏輯無法復用

潛在的一般性技術服務或業務邏輯與更特定於應用的邏輯交織在一起,無法復用

不同的關注領域之間高度耦合。難以為不同開發者清晰的界定和分配任務

  • 不同應用領域,層的數量和用途有所不同

如信息系統、操作系統等

  • 使用層的好處

總的說,使用層可以做到關系分離、高級服務與低級服務分離、特定於應用的服務與一般的服務分離

減少耦合和依賴性、增強內聚性、提高潛在的復用性並且概念更加清晰

封裝和分解了相關的復雜度

較高級的技術服務層(如UI層、應用層和領域層)可以用新的實現替換。較低級的技術服務層不太可能

較低層包含可復用功能

某些層(主要是領域層和技術服務層)可以是分布式的

通過邏輯划分,有助於團隊開發

  •  幾個主要概念

領域對象:表示問題領域空間的事物,並且與應用或業務邏輯有關

領域層   :包含領域對象,處理應用邏輯的層

領域層與領域模型的關系: 領域層是軟件的一部分,領域模型是概念角度分析的一部分。可以利用來自領域模型的靈感創建領域層,獲得現實世界和軟件設計之間的低表示差異。

層:       架構中的層表示對系統在垂直方向的划分

分區:   架構中的層表示對系統在水平方向的划分,形成相對平行的子系統,如技術服務層可以划分為安全和統計等分區

 

圖 層和分區

5.1 准則:內聚職責;使關系分離

  • 同一層內的對象在職責上應該具有緊密關聯,不同層中對象的職責則不應該混淆。

例如:UI層中的對象關注UI工作,如創建窗口和小部件、捕獲鼠標和鍵盤事件等;應用邏輯層對象關注應用邏輯,如計算銷售總額或稅金等

UI對象不應該處理應用邏輯

5.2 准則:為領域層和應用邏輯層創建領域對象

創建軟件對象,使其名稱和信息類似於真實世界的領域,並為其分配應用邏輯職責

 5.3 准則:不要將外部資源表示為最底層

大部分系統依賴於外部資源或服務,將外部資源表示為領域層中的子領域,而提供外部資源的一般性服務可以視為技術服務分區

將外部資源(如某個數據庫)表示為“低於”基礎層的層,是對邏輯視圖和架構部署視圖的混淆

 

圖 對外部資源-數據庫訪問的表示對比

 6. 准則:模型--視圖分離原則

6.1 模型--視圖分離原則的內容

  • 不要將非UI對象直接與UI對象連接或耦合(例如sale軟件對象引用java swing JFrame窗口對象)

因為窗口與某個應用相關,而(理想情況下)非窗口對象可以在新應用中重用或附加到新界面

  • 不要在UI對象中加入應用邏輯(例如稅金的計算)

UI對象應該只初始化UI元素,接收UI事件(如鼠標點擊)、將應用邏輯的請求委派到非UI對象

6.2 觀察者模式

觀察者模式是對模型--視圖分離准則的合理擴展,即領域對象只能通過PropertyListener(Java中的常用接口)的接口向視圖UI對象發送消息

6.3 為何要分離模型--視圖?

支持內聚的模型定義,這些定義只注重領域過程,而非用戶界面

允許對模型和用戶界面層分別進行開發

使界面的需求變更對領域層的影響最小化

允許新視圖能夠方便的連接到現有的領域層之上,而不會對領域層產生影響

允許對同一模型對象同時使用多個視圖

允許模型層的運行不依賴於用戶界面層

允許簡模型層能夠簡便的移植到另一用戶接口框架下

7. SSD(順序圖)、系統操作和層之間的聯系

從UI層發送到領域層的消息是SSD中所描述的系統操作,如下圖:

圖 SSD 系統操作和層的關系

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM