這個層次的靜態視圖也將我們的視角切換到系統內部。盡管業務處理層次為出現在業務處理中的真實抽象建立了模型，這個層次將抽象建模為其在系統中所要被表示的那樣。在實際的系統中，架構師會為每個軟件層（表示層、業務層和數據訪問層）設計類。為了保持本文的簡潔，圖 7 只展示了業務層的靜態設計，以便說明系統層抽象是如何針對設計進行改進的。
圖 7. 從零售商處在線購買物品的邏輯層次靜態視圖
架構師對系統層類進行改進以設計業務層接口。
因為系統中的所有賬戶和客戶都是零售商的，所以創建一個單一的 Company 實例并使其與所有賬戶相關聯是不切實際的，因此該層次中省略了 Company。我們只是存儲 Payment 所帶的信用卡號和賬單郵寄地址，并非為每個 CreditCardAccount 創建一個單獨的實例。此外，對系統來說，為每個出售的 Item 創建一個實例是不切實際的，因此從模型中刪除了 Item，并改為由模型跟蹤 LineItem 中訂購的物品數量以及在新 ShippedItems 類中附帶的物品數量。
架構師還定義業務層公開的服務間隔。對于本示例，業務層為 Account、UserAccount、Order、Shipment 和 Catalog 導出了 Create、Read、Update 和 Delete (CRUD) 服務。橢圓形指出了 CRUD 間隔。
請注意，即使本層次的類不是業務處理類的合適超集，架構師也可以通過直接改進業務處理類、將視角由系統外部更改為系統內部來實現這個設計。
物理抽象層次
文章來源于領測軟件測試網 http://www.kjueaiud.com/
