是有代表性的。這說明了為什么 [Industry] 域模型確實應該將公司定義為黑盒子中心的演員。同一個行業中的公司傾向于支持帶有其外部演員的同一套業務交互。此外，域模型排除了公司的特定業務處理，這是因為在同一行業中的公司之間它們會有相當大的變化。
域層次嚴格集中在從外部演員的角度看到的業務交互。對此我們必須注意，不要將用于完成交互的實現機制包括進來。這些細節屬于下一個抽象層次。因此，在本例中，我們只為瀏覽、選擇、購買和支付建模。我們不為如何完成這些交互（通過電話、美國郵政、電子郵件、Web 應用程序、親自前往、支票、信用卡或現金）建模。
業務處理抽象層次
下一個抽象層次為公司的業務處理建模，以實現在域層次捕獲的交互。系統層次“內部縮放”公司的黑盒子，并標識為完成業務交易而協作的所有員工和系統。在這個層次，要開發的系統作為黑盒子中心的演員。
應用了系統層次的范圍規則，在線定單系統就作為黑盒子中心的演員�？蛻艉蛦T工作為外部演員。系統層次是從客戶和員工的角度來建模的�？蛻粼诰�執行購買。支付是通過信用卡完成的。通過將物品運送到客戶的收貨地址履行定單。出貨通知是由電子郵件發送的。
動態視圖
動態視圖重演了域層次購買交易，這次公開了零售商的內部業務處理。圖 4 匯總了業務處理環境，并包含了關于系統及其演員之間的交互的簡單使用案例描述。
靜態視圖
這個層次的靜態視圖對類模型做了改進，以捕獲在業務處理層次使用案例中出現的對象。換句話說，“為了在線創建一個定單并履行該定單，客戶和雇員需要理解哪些對象？”圖 5 展示了業務處理層次靜態視圖的類關系圖。我們修改域類模型以捕獲在這個抽象層次上的角度。Person、Account 和 Company 抽象保持不變，Catalog 和 Product 也一樣。但是，用 Order 替換了來自域模型的抽象 Purchase 事件。
Order 包括 LineItem，它與 Catalog 中的 Product 相關聯。因為這個層次為公司的內部業務處理建模，所以我們需要獲得現有的庫存（最小庫存單元 (SKU) 的一個屬性，它表示在一個特定位置的物品的庫存）。我們也為客戶的 UserAccount 建模，它提供對在線系統的訪問。Payment 是通過使用 CreditCardAccount 來完成的。Location 代表美國的一個地理位置，它作為賬單郵寄地址，同時也作為 Order 的收貨地址。Shipment 包含 Shipment 中包括的 Item。
我們在系統抽象層次創造方法來簡化業務處理，因此該層次通常需要很多創造力。為此，通常使用業務處理層次上的若干不同形式來實現單個域層次交易。舉例來說，一次購買可以通過在線、電話、郵件、傳真一個定單表格或者親自到零售店來完成。對于每一種形式，都需要在業務處理層次為其建模。請注意，盡管對零售商來說 Credit Authorizer 是一個外部演員，但是它還是在這個層次引入，這是因為只需要它實現在該層次首次出現的業務處理。
最后，請注意該系統是技術獨立的。我們的在線購買系統可以用任何 Web 技術實現。在系統黑盒子內選擇技術是一個體系結構決策。
邏輯抽象層次
邏輯層在系統黑盒子內縮放，從而公開高級別的系統設計。架構師選擇技術并定義高級系統結構。在我們的簡單示例中，系統是由承載表示層、業務層和數據訪問層的 Microsoft IIS/Microsoft ASP.NET 服務器和承載持久性數據的 Microsoft SQL Server 數據庫服務器組成的。
動態視圖
文章來源于領測軟件測試網 http://www.kjueaiud.com/
