By Don Awalt and Rick McUmber
RDA Corporation
摘要：所有偉大的架構師都掌握了在抽象的不同層次上概念化解決方案的技能。通過將解決方案組織到離散的層次，架構師可以專注於解決方案的單個方面而忽略所有剩餘的複雜性。展示將抽象層次應用到 IT 解決方案的技術，並將其與其他工程學科相比較。
本頁內容
 |
將抽象層次應用到 IT 解決方案 |
|
抽象層次：所有工程師的強大武器 |
|
應用抽象層次時的核心原則 |
|
將抽象層次應用到 IT 系統 |
|
簡單框架：四個抽象層次 |
|
通過迭代發展層次 |
|
重訪抽象層次核心原則 |
|
擴展層次以支持企業解決方案 |
|
優點 |
|
小結 |
|
自我評估 |
將抽象層次應用到 IT 解決方案
企業架構師正受到其所面臨的大量複雜性的挑戰。開發一個能夠自動處理企業任務的獨立的部門應用程序是一回事。而設計並組成一個支持上萬 IT 使用者的滿是應用程序、服務器和數據庫（全都支持多種企業活動）的 IT 實驗室全球網絡，則完全是另外一回事。要組合這些複雜性，IT 網絡必須隨時可用、響應迅速並保護企業寶貴的信息資產。除所有這些之外，IT 網絡還必須足夠靈活以支持企業永遠變化的需要，並且採用出現的新技術。
一些架構師在這種複雜性方面明顯非常出色，而且在不斷進步。在我們的職業生涯中，能與一些真正偉大的分析師和架構師並肩工作是非常幸運的。反思這些經驗，我們已經分析出是什麼造就了傑出的架構師。
無一例外，所有偉大的架構師都掌握了在截然不同的抽象層次上概念化解決方案的技能。通過將解決方案組織到離散的層次，架構師可以將精力集中在解決方案的單個方面而忽略所有剩餘的複雜性。他們一旦穩定了解決方案的某個部分，接下來就能繼續處理其他方面，從而不斷地將層次發展並完善到最終可以被實現的粘合模型中。
大多數軟件開發人員懂得應該將解決方案分解到抽象層次。但是在實際的項目中，這是非常難於付諸實踐的。當遇到第一個困難時，在急於開始編碼時是很容易放棄這些層次的。偉大的架構師會經受這些挑戰並在整個項目的生命週期中嚴格保持這些層次。他們意識到，如果不這樣做，最終將淹沒在複雜性中。
本文展示了將抽象層次應用到 IT 解決方案的技術。首先，我們會通過一個簡單的示例演示此方法，然後提出一個基於正式抽象層次的系統產品的結構。
抽象層次：所有工程師的強大武器
其他的工程學科，比如土木工程師，幾個世紀以來一直利用抽象層次複製複雜性。讓我們學習一下其他更成熟的工程學科是如何應用抽象層次的，就從電子工程師開始吧，他們設計每次更新換代都變得更加複雜的計算機系統。
硬件工程師
系統設計師使用抽象層次爲計算機系統建模。每個層次都是定義完善的，並提供了該系統的一個不同角度。許多系統是在三個主要層次上設計的：系統、子系統和組件，如圖 1 所示。
分層使工程師能夠將龐大數量的複雜性集成到一個單一的工作計算機系統中。在其原子部分的層次上確切瞭解一臺計算機是不可能的。在單獨一塊 Intel Itanium_ 芯片上有大約 25,000,000 個晶體管。
對 IT 相關學科來說，這種把複雜性分解到抽象層的方法當然不是惟一的。類似的方法被用於從航空工程到微生物學的無數其他學科。
應用抽象層次時的核心原則
所有工程師在應用抽象層次時都遵循這套核心原則。當把抽象層次應用到軟件時，這些原則也同樣適用。
這些層次的數量和範圍是定義完善的，以便工程師能夠在複雜的系統上協作，所有團隊成員必須共享對層次的同一理解。只要設計師做出設計決定，他們必須將那些決定歸檔到相應的細節層次。
三個抽象層次定義如下：
圖 i. 定義的三個抽象層次
圖 ii.抽象層次的一個簡單框架
每個層次內的多個視圖
一個單個層次內的複雜性可以變得非常多，以至於使人無法一次全部掌握。在這種情況下，工程師通過多個視圖將設計展現於單個層次內。每個視圖展現設計的一個單獨方面，但保持在相同的抽象層次上。舉例來說，母板工程師爲板的每個層創建一個視圖，從而爲每層的連接路徑的設計建模。
圖 1. 計算機系統的抽象層次
必須保持層次間的一致性
爲了讓系統按預期方式運行，每個後續的層必須是其父層的適當改進。如果計算機系統設計師從 IDE 總線切換到 SCSI 總線，那麼所有設備的接口規範也必須切換到 SCSI。如果層次沒有同步，那麼系統就不會按預期方式在頂層執行。
將抽象層次應用到 IT 系統
既然我們已經分析了其他學科是如何應用抽象層次的，現在就讓我們將此技術應用於 IT 解決方案1。下列部分展示了應用抽象層次爲典型 IT 應用程序的需求、設計和實現建模的技術。這些技術是通過一個針對假想零售商的簡單的、指導性的在線定單系統示例來展示的。在我們的示例中，我們不僅包括了體系結構，而且擴展了範圍以包括系統需求和業務環境 — 如同由零售業所定義的。
簡單框架：四個抽象層次
我們的簡單示例定義 IT 解決方案的如下四個抽象層次：
| • |
域 |
| • |
業務處理 |
| • |
邏輯 |
| • |
物理 |
在每個層次內，我們既展示了該特定層次行爲的動態視圖，又展示了其靜態視圖。動態視圖爲對象之間的消息建模，而靜態視圖爲對象之間的結構和關係建模。
域抽象層次
應用了上面的範圍規則，零售商就會作爲域層次中的黑盒子中心的演員。客戶作爲外部的演員。域層次是從客戶的角度來建模的。只爲購買交互建模。用於完成購買的通訊形式不包括在這個層次，但是會在業務處理層次引入。
圖 2. 關於從零售商處購買物品的域層次動態視圖
圖 3. 關於從零售商處購買物品的域層次靜態視圖
動態視圖
域層次內的動態視圖爲客戶和零售商之間的交互建模。下圖彙總了域環境，幷包含了簡單的業務交互使用案例描述。
圖 4. 關於從零售商處購買物品的業務處理層次動態視圖
靜態視圖
域層次的靜態視圖爲類結構和在使用案例中出現的它們的對象的關係建模。換句話說，它說明了在這個抽象層次上，爲了完成購買交易客戶需要了解什麼對象。 圖 5 展示了域層次靜態視圖的類關係圖。
圖 5. 關於從零售商處購買物品的業務處理層次靜態視圖
客戶是 Person 的實例。客戶和零售商之間的關係被具體化爲 Account。所有的 Purchase 都與客戶的 Account 相關。Purchase 與每個被購買的 Item 相關。每個 Item 都與特定的 Product 相關，這裏 Product 遵循元類模式。Product 的實例實際上本身就是類。將其他 Product 添加到 Catalog 完全是一個數據驅動過程，而且不會對類模型產生影響，因此將 Product 建模爲一個元類會使我們的模型更加靈活。圍繞這些類，每個 Payment 都與其 Purchase 相關。
如您可能看到的，這個層次的模型對大多數零售商（無論類型爲在線或傳統，大型或小型）來說是有代表性的。這說明了爲什麼 [Industry] 域模型確實應該將公司定義爲黑盒子中心的演員。同一個行業中的公司傾向於支持帶有其外部演員的同一套業務交互。此外，域模型排除了公司的特定業務處理，這是因爲在同一行業中的公司之間它們會有相當大的變化。
域層次嚴格集中在從外部演員的角度看到的業務交互。對此我們必須注意，不要將用於完成交互的實現機制包括進來。這些細節屬於下一個抽象層次。因此，在本例中，我們只爲瀏覽、選擇、購買和支付建模。我們不爲如何完成這些交互（通過電話、美國郵政、電子郵件、Web 應用程序、親自前往、支票、信用卡或現金）建模。
業務處理抽象層次
下一個抽象層次爲公司的業務處理建模，以實現在域層次捕獲的交互。系統層次“內部縮放”公司的黑盒子，並標識爲完成業務交易而協作的所有員工和系統。在這個層次，要開發的系統作爲黑盒子中心的演員。
應用了系統層次的範圍規則，在線定單系統就作爲黑盒子中心的演員。客戶和員工作爲外部演員。系統層次是從客戶和員工的角度來建模的。客戶在線執行購買。支付是通過信用卡完成的。通過將物品運送到客戶的收貨地址履行定單。出貨通知是由電子郵件發送的。
動態視圖
動態視圖重演了域層次購買交易，這次公開了零售商的內部業務處理。圖 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 數據庫服務器組成的。
動態視圖
邏輯層上的動態視圖跟蹤通過系統主要組件的消息流。如示例所示，在提交 ConfirmOrder Web 表單的時候，圖 6 跟蹤這一消息流。
圖 6. 從零售商處在線購買物品的邏輯層次動態視圖
靜態視圖
這個層次的靜態視圖也將我們的視角切換到系統內部。儘管業務處理層次爲出現在業務處理中的真實抽象建立了模型，這個層次將抽象建模爲其在系統中所要被表示的那樣。在實際的系統中，架構師會爲每個軟件層（表示層、業務層和數據訪問層）設計類。爲了保持本文的簡潔，圖 7 只展示了業務層的靜態設計，以便說明系統層抽象是如何針對設計進行改進的。
圖 7. 從零售商處在線購買物品的邏輯層次靜態視圖
架構師對系統層類進行改進以設計業務層接口。
因爲系統中的所有賬戶和客戶都是零售商的，所以創建一個單一的 Company 實例並使其與所有賬戶相關聯是不切實際的，因此該層次中省略了 Company。我們只是存儲 Payment 所帶的信用卡號和賬單郵寄地址，並非爲每個 CreditCardAccount 創建一個單獨的實例。此外，對系統來說，爲每個出售的 Item 創建一個實例是不切實際的，因此從模型中刪除了 Item，並改爲由模型跟蹤 LineItem 中訂購的物品數量以及在新 ShippedItems 類中附帶的物品數量。
架構師還定義業務層公開的服務間隔。對於本示例，業務層爲 Account、UserAccount、Order、Shipment 和 Catalog 導出了 Create、Read、Update 和 Delete (CRUD) 服務。橢圓形指出了 CRUD 間隔。
請注意，即使本層次的類不是業務處理類的合適超集，架構師也可以通過直接改進業務處理類、將視角由系統外部更改爲系統內部來實現這個設計。
物理抽象層次
物理抽象層次捕獲系統實現的結構。系統作爲一個節點的網絡實現，每個節點都配置有硬件和軟件。邏輯視圖中的三個軟件層（表示層、業務層和數據層）是以代碼形式被物理實現，並部署到這些節點上。邏輯視圖中的持久類物理存儲在 SQL Server 數據庫的關係表中。
動態視圖
動態視圖跟蹤經過物理配置節點的消息流。ConfirmOrder HTTP post 從客戶的瀏覽器通過 Internet 通過零售商的防火牆流動到 Web 服務器，在那裏 Microsoft Windows 將其轉發到 IIS，IIS 又將其傳遞到 Microsoft ASP.NET，然後 ASP.NET 調度 ConfirmOrder.aspx。幸運的是，現代開發工具將我們與多數物理網絡隔離開來。但是，架構師需要了解物理層以避免網絡瓶頸和安全暴露。
靜態視圖
靜態視圖（圖 8）將邏輯視圖中的持久類改進爲其物理表示形式。在我們的零售示例中，業務層類存儲在下列 SQL Server 表中。
圖 8. 從零售商處在線購買物品的物理層次靜態視圖
映射到關係表和屬性的類作爲列實現。一對一關係和一對多關係使用一個外鍵來實現。開放式併發通過給每個被“凝結”的父類分配一個 datetime 字段來實現。
在設計邏輯層次時，架構師主要集中關注於實現系統功能。在確信包含了系統功能之後，架構師就能夠專注於在物理層次優化實現。
通過迭代發展層次
建立了這個框架後，架構師通過幾次迭代對解決方案加以發展。每次迭代都合併額外的功能 — 發票、待交定單、親自訂購、電話訂購等等。在每種情況下，架構師都更新適當的抽象層次，然後將這些更新改進到物理實現層。
重訪抽象層次核心原則
讓我們對照核心抽象層次原則來測試我們的示例。
| • |
這些層次的數量和範圍是定義完善的：我們有四個不同的層次：公司黑盒子、系統黑盒子、系統內的邏輯設計以及物理實現。 |
| • |
每個層次內的多個視圖：在這個簡單示例中，我們在每個層次上展示了一個動態視圖和靜態視圖。 |
| • |
必須保持層次間的一致性：如果對域模型作出了更改，則更改也一定會影響到較低層次。舉例來說，如果零售商決定爲其產品提供維護合同，分析師就會將MaintenanceContract 添加到域模型，並將其改進爲其物理表現形式。對於維護大型系統來說，同步所有層次是很重要的。因爲提交了增強請求，所以分析師執行對相應細節層次的影響評估。一些增強請求影響域層次（並且因此影響所有後續層次）。其他請求隻影響物理層次。 |
擴展層次以支持企業解決方案
既然我們已經展示了帶有四個抽象層次的簡單示例，現在就讓我們擴展這個方法來支持 IT 企業的解決方案。圖 9 展示了一個 Rational 統一過程 (Rational Unified Process，RUP) 配置，它將項目產品組織到定義完善的抽象層次中。
表中的層次描述如下。
圖 9. 將項目產品組織到定義完善的抽象層次中的 RUP 配置
| • |
域。域層次捕獲項目的業務環境。 | ||||||||||||
| • |
項目洞察力。項目洞察力對系統將會有的對企業的業務影響進行通訊。它以投資回報分析量化了這個影響。項目洞察力表示該項目的最高抽象層次。 | ||||||||||||
| • |
業務處理。系統層次爲公司內的業務處理建模。對於極其複雜的單位來說，這個層次可以再細分到子層次：部門、部門間以及部門內。 | ||||||||||||
| • |
UI 規範。UI 規範設計了實現業務處理的用戶界面。它是由 UI 設計文檔和功能 UI 原型組成的。 | ||||||||||||
| • |
詳細要求。詳細要求指定了系統要求的最低層次抽象。它包括諸如數據類型格式和詳細業務規則等詳細信息。它還包括專業性要求，例如，性能、可用性、安全性、國際化、配置、可擴展性和靈活性要求等。 | ||||||||||||
| • |
體系結構。系統的體系結構被組織到六個視圖中：
|
優點
將系統產品組織到離散的抽象層次有若干優點：
| • |
它將系統要求分離到三個不同的抽象層次：業務處理、UI 規範和詳細要求。我們不會再用令企業用戶感到不知所措的單個整體功能規範了。取而代之，我們在三個改進的詳細層次中對系統要求進行通訊。 |
| • |
分析師和架構師可以將複雜性控制在一個單一的、集成的系統模型中。 |
| • |
架構師可以專注於系統的單個方面，並將那些決策集成到整個解決方案中。 |
| • |
抽象層次形成了系統產品的結構。舉例來說，軟件體系結構文檔爲每個視圖專設了一個小節。 |
| • |
抽象層次提供從要求到設計再到實現的直接可跟蹤能力。可跟蹤能力使小組能夠在評測更改請求時執行精確的影響評估。 |
| • |
在使用同一框架開發幾個系統之後，會在每個抽象層次形成模式。單位可以編錄這些模式和每個抽象層次內的其他最佳實踐。這個最佳實踐的目錄會作爲過程改進計劃的基礎。 |
小結
爲了處理複雜性，所有工程學科都應用正式抽象層次。軟件也不例外。爲了實現抽象層次的優點，項目必須：
| • |
正式標識層次，每個層次都有定義完善的範圍。 |
| • |
將一個層次內的複雜性分開到多個視圖。 |
| • |
在層次間保持一致性。 |
通過一個簡單的示例，本文演示瞭如何應用抽象層次，然後將該方法擴展到支持企業 IT 解決方案。它提供了一個 RUP 配置框架，該框架將系統產品組織到定義完善的抽象層次。
自我評估
| • |
您當前的項目是否應用了抽象層次？ |
| • |
層次是否定義完善？ |
| • |
項目團隊是否很好地理解了這些層次？ |
| • |
如果複雜性在一個層次中變得過大，團隊是否將其分離到視圖中呢？ |
| • |
團隊是否在層次間保持一致性？ |
| • |
您的項目會從抽象層次中獲益嗎？ |
偉大的架構師本能地遵循這些原則。我們其餘的人就必須有意識地應用抽象層次，並運用規則在整個項目生命週期中保持這些層次。
資源
Cockburn, Alistair. Writing Effective Use Cases. New Jersey: Addison-Wesley, 2001
Kroll, Per and Kruchten, Philippe. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Boston MA: Pearson Education and Addison-Wesley, 2003
DeMarco, Tom and Plauger, P J Structured Analysis and System Specification. Prentice Hall PTR, 1979
要獲得 DoD 標準 2167A 的聯機副本，請訪問 http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html。
腳註
1 很多人已經成功地將抽象層次應用於軟件。Ed Yourdon 和 Tom DeMarco 在 1979 年提出了結構化分析和結構化系統設計的概念。美國政府的許多分支機構標準化了 DoD 的 2167A 標準，它要求系統由有層次的硬件和軟件配置項組成。DBA 社區經常應用細節層次爲關係數據庫建模。特別地，Bachman 工具集和 James Martin 的信息工程方法學 (Information Engineering Methodology，IEM) 先爲數據庫邏輯建模，然後再爲其物理建模。在 Google 上鍵入“software levels of abstraction”進行搜索會返回若干個結果，但其中大多數來自於學術社區，而且其內容看起來集中在正式計算機語言方面。
關於作者
Don Awalt 是 RDA Corporation 的創始人和 CEO，該公司是一家自定義軟件工程公司，成立於 1988 年，在華盛頓特區、巴爾的摩、亞特蘭大、費城和芝加哥都設有辦事處。作爲微軟認證金牌夥伴 (Microsoft Gold Certified Partner)，該公司專注於使用 .NET Framework 開發企業 Web 和富客戶端系統。Don 目前是 Microsoft 華盛頓特區的區域總監，他以前曾經擔任費城首任區域總監。Don 經常在行業活動中演講，這些活動包括 Tech Ed、Developer Days、MSDN 活動和各種 SQL Server 及 Windows 活動。他是 SQL Server Magazine 和 PC Tech Journal Magazine 的特約編輯，並且也爲其它出版物撰寫稿件。Don 所擅長的技術領域包括 Web 服務、SQL Server、現代編程語言的發展，以及在 Microsoft 的 Prescriptive Architecture Group (PAG) 中可以看到的許多體系結構和處理工作。可以通過 [email protected] 聯繫到 Don。
Rick McUmber 是 RDA 的質量和最佳實踐總監。他爲 IBM 和 Rational Software Corporation 一共工作了 11 年，致力於爲美國運輸部、國防部、NASA 和加拿大國防部開發系統。從 1994 年以來，他一直在 RDA 工作，致力於爲其客戶開發業務解決方案。可以通過 [email protected] 聯繫到 Rick。